블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'분산 거버넌스'에 해당되는 글 2

  1. 2016.02.25 MSA의 중복 개발에 대한 단상 (3)
  2. 2015.03.18 마이크로서비스 아키텍쳐(MSA)는 선택이 아니라 필수다
 

MSA의 중복 개발에 대한 단상


조대협 (http://bcho.tistory.com)


어제 우연한 기회로, API Academy 세미나에 다녀왔습니다.

발표자는 Mike Amundsen  이라는 분으로, CA의 API 아카데미의 일원이며, OReilly 출판사를 통해서 REST API에 대한 저서를 집필한 분이기도 합니다.

http://www.oreilly.com/pub/au/1192





API 아카데미였지만, 결국 MSA와 조직 문화 소통으로 수렴되는 내용이었습니다만, MSA 에 관련하여 재미있는 접근이 있어서 남겨놓고자 합니다.


예로 든것중의 하나가 API를 외부용, 내부용, 그리고 특정한 파트너용 3가지로 나누어서 접근을 하였는데, 이 접근 방식보다 특이했던 것이 구현의 주체입니다.


일반적인 생각으로는 유사한 API라면, API를 만들어놓고, 차이가 나는 부분만 Mediation을 통해서 재 사용하는 개념을 접근하였습니다.


예를 들어 GET /users/{userid} 라는 API가 있을때, 이 API를 내부용으로 만들어놓고, 이 API를 wrapping해서, 추가 인증/인가 기능을 추가하여 외부용, 파트너용으로 제공하는 방법이 일반적인 방식인데,


Amunsen 은 다른 접근 방법을 제시했습니다. "외부용,내부용,파트너용 API를 각각의 팀이 따로 만든다"

였습니다. 데이타가 같으니 일관성은 보장이 될터이고, 각 팀으로 서비스를 나눠서 각팀이 각각의 API를 만들게 되면, 기동성이 늘어나고, 고객의 요구 사항이 각각 다르니 거기에 기민하게 대응할 수 있다는 논리입니다.


중복 개발이나, 종속성에 대한 문제가 발생할 수 는 있겠지만, 오히려 이게 맞는 접근 방법이 아닌가도 싶습니다.

MSA의 근본적인 목적은 작은 서비스로 나눠서 개발의 기민성을 확보하고, 고객의 요구 사항을 빠르게 반영하는데 있는데, 공통 API를 재사용하게 되면, 재 사용성 자체는 올라갈지 모르겠지만, 반대로 의존성때문에 전체 프로젝트 일정에 문제가 생길 수 있습니다.


같은 논리로, 웹,모바일 백앤드가 있을때, 팀의 크기가 크다면, 공통 API 시스템을 쓸것이 아니라, 각자 API 백앤드 시스템을 만들어서 기민성을 확보하는 것도 하나의 예가 되겠습니다.


중복 개발과 낭비는 있겠지만, 기민성 확보와 각각의 팀이 컨택스트와 도메인을 완전하게 이해할 수 있다는 점에서, 이 방식도 충분히 고려해볼만한 가치가 있지 않을까 합니다.

마이크로서비스 아키텍쳐에 대한 소고



간만에 낚시성 제목을 달아봤는데, MSA (마이크로 서비스 아키텍쳐)가 필수라는 이야기는 꼭 틀린말이라고 볼 수 는 없습니다. 특히나 개발팀의 규모가 큰 경우나, 지리적으로 개발팀이 나눠져 있는 경우에는 서비스 단위로 나눠서 각 팀이 서비스를 개발하고, 독립된 기술과 개발 체계를 가지면서 빠르게 개발해 나가는게 효율적이기 때문에, 규모가 어느정도 되는 팀에서는 효율성이 높습니다.


중앙에서 통제할 필요 없이, 각자가 알아서 설계하고, 만들고, 테스트 하고 운영하기 때문입니다.

이것을 분산 거버넌스라고 하는데, 관리나 의사결정의 권한을 중앙의 팀이 중앙 통제하지 않고, 각자의 팀에 자율적으로 맏기고, 책임도 맏긴다는 이야기 입니다.


그러면 분산 거버넌스를 하면,중앙 거버넌스가 필요하지 않냐?


MSA글을 보면, 보통 분산 거버넌스와 이에 대한 필요성과 장점에 대해서만 이야기를 한다.

그러나, MSA에 과연 중앙 거버넌스가 필요하지 않을까?


개인적인 생각으로는 이 또한 강한 중앙 거버넌스가 필요하다.

첫번째로, API로 서비스를 제공하기 위해서는 API 표준이 맞아야 한다. 헤더 구조, URI 컨벤션, Granuality (서비스 크기), 에러 추적을 위한 로깅 메세지의 표준화가 필요하다.

두번째로, 서비스의 기능에 대해서, 어떤 기능이 필요한지, 필요하다면 기능이 어떤 동작을 어떻게 하는지에 대한 정확한 스펙에 대한 정의가 필요하다 이건 서비스를 제공하는 팀 보다는 서비스를 사용하는 팀 입장에서 해야 한다.

세번째로, 이러한 서비스를 엮을려면, 필요에 따라서 aggregation API를 만들거나 또는 서비스 자체에 기능을 추가해야 하는데, 팀 이기주의로 인하여 타팀으로 일을 떠넘기는 현상이 생길 수 있기 때문에 중앙에서 이를 조율할 필요가 있다.


실제로 MSA와 유사한 구조로 서비스를 개발해본 경험으로 보면, 이러한 중앙 통제가 필요하고 거기에 드는 추가적인 비용 (코디네이션/조율)이 만만하지 않다.


또한 다른 문제점중의 하나는 각 서비스팀별 개발 수준이나 품질 수준이 다르기 때문에, 기능을 추가하고자 할때도 어느 서비스(즉 팀으로 보낼것인가)를 고민해야 한다는 것이다.


MSA의 도입은, 각 서비스 개발팀의 수준이 높아야 권한을 분산할 수 있고, 또한 중앙집중형 거버넌스 조직을 통해서 표준화등이 강력하게 이루어져야 한다.


결론적으로 난이도가 높은 아키텍쳐 스타일이라는 이야기이고, 전사 개발팀 차원에서의 많은 투자가 필요할듯 하다.


SSAG에서 토론글 중, 홍성진님이 재미있는 링크를 올려주셔서 첨부합니다

http://siliconangle.com/furrier/2011/10/12/google-engineer-accidently-shares-his-internal-memo-about-google-platform/