Take it easy

마이크로 서비스의 통합은 어떻게 말하면 느슨한 결합의 분리를 의미한다. 하나의 마이크로 서비스가 다른 마이크로 서비스와 통신하는 방법

에 대한 여러가지 방법에 대해서 공부하려 한다.

- 공유 데이터베이스 

가장 단순하지만 마이크로 서비스 아키텍쳐가 추구하는 방법이 아니다. 강한 응집력과 느슨한 결합력을 잃게 되는 것만으로 피해야하는 통합
(통신) 방법이다.

- 오케스트레이션과 코레오그래피

오케스트레이션 방식은 지휘자처럼 프로세스를 안내하고, 구동하는 하나의 Master에 의존한다. 반면 코레오 그래피 방식은 발레 무용수들이 자신의 역할을 알고 주변의 다른 무용수에 반응하는 것처럼 시스템 각 부분에 작업 내용을 알리고 세부 사항을 수행하게 한다.

 중앙 관리 권한에 많은 권한이 있는 것 오케스트레이션 방식에 대비해서 이벤트를 발산하고, 그것을 체크하여 수행하는 방식인 코레오 그래피 방식은 느슨한 결합을 이끌어낸다. (이때 일이 제대로 수행되는지 모니터하고 추적하기 위한 추가 작업이 필요하다.)

- 원격 프로시저 호출 (Repote Procedure Call) RPC

 마이크로 서비스의 경우 다양한 언어와 프레임워크로 개발 될 수 있기 때문에, 프로토콜을 맞춰서 통신해야 하는 비용이 발생한다. 이럴 때 RPC를 이용하여 언어에 구애받지 않고, 원격에 있는 프로시저를 호출하여 비즈니스 로직에 집중할 수 있게 된다.

- REST 

 클라이언트가 요청/응답 통신을 사용하는 경우 요청을 서비스에 보낸 다음, 서비스가 요청을 처리하고 다시 응답을 보낸다. 요청/응답 통신은 특히 클라이언트 앱에서 실시간 UI(라이브 사용자 인터페이스)에 대한 데이터를 쿼리하는 데 적합.

-  버전관리의 가장 좋은 방법은 애초에 결함을 만들어내지 않는 것 

 관심 없는 데이터의 변경들을 무시할 수 있도록 독자를 구현하는 것 (관대한 독자 패턴)

 '전송할 때는 보수적으로, 받아들일 때는 자유롭게' (포스텔 법치)

 버전관리시의 하위 호환성이 깨지는 경우와 아닌 경우를 알 수 없을까? -> 유의적 버전 관리 (Major.Minor.Patch) 

전체적으로 여러가지 통신 방법들이 있고, 이것들로 각 마이크로 서비스를 어떻게 통합할 것이고, 문제를 해결할 것인지에 대한 고민들이 있는 부분인 것 같다. 책의 내용을 요약하는 것보다 내 것으로 만들어서 그에 대한 생각을 정리하고 싶었지만 굉장히 많은 내용을 다루고 있어 그런 부분이 어려웠고 각 기술들에 대해서 깊게 공부하는 시간을 가져야겠다는 생각을 하게 했다.  (gRPC, 메시지 큐 등에 대한 정리도 추가로 할 시간을 만들어보아야 겠다. )

이는 마이크로서비스 아키텍처 구축을 공부하면서 생각을 정리한 것입니다.. 관련된 내용에 대해서 더 알고 싶은 경우에는 해당 책을 보는 것을 권유합니다.

좋은 마이크로 서비스를 구성하기 위해서는 느슨한 결합과 강한 응집력에 대한 고민은 필수적이다.

느슨한 결합이 잘 되어 있으면 하나의 서비스를 변경했을 때 다른 서비스는 변경이 되지 않으며, 이를 통해서 다른 변경없이 특정 서비스를 변경하고 배포할 수 있다. 강한 응집력이 잘되어 있으면 특정 행위에 대한 변경이 한 곳에서 이루어지는 것이다. 이는 같은 행위가 여러 곳에 분산되면 한 행위의 수정을 위해 여러 서비스를 변경 배포해야하는 문제가 발생하게 된다. "느슨한 결합" 그리고 "강한 응집력" 이 두 가지를 지키지 않으면 마이크로 서비스의 큰 장점을 잃을 수 있기 때문에 이를 효과적으로 컨트롤할 수 잇는 방법을 찾아야 한다.

특정 모델에 대해 경계가 정해진 적용 가능성, 콘텍스트를 제한한느 것은 팀원들로 하여금 무엇에 대해 일관성을 유지하고, 무엇을 독립적으로 개발할 수 있는 지 명확하게 공유할 수 있게 하는 것을 "경계가 있는 콘텍스트" 라고 한다. 각 콘텍스트 내에는 외부와 통신할 필요가 없는 것과 다른 외부로 통신하는 것이 함께 존재하고, 명백한 인터페이스로 어떤 모델이 다른 콘테스트와 공유될지를 결정한다.

 어떤 모델을 공유하고, 어떤 모델을 공유하지 않는 지를 명확하게 고려하게 되면 우리가 피해야 할 강한 경합 (우리는 느슨한 결합을 하고 싶다.)을 피할 수 있게 된다. 또한, 서로 조화를 이루는 비지니스들이 존재하는 도메인 내부의 경계를 설정함으로 높은 응집력을 이룰 수 있다. 이렇게 관련된 기능을 모으고, 내외부의 공유를 설정하는 작업을 통해서 모듈화를 이루고, 이를 모델링하게 되면 이는 마이크로 서비스의 후보가 될 수 있다. ( 애플리케이션의 관점에서 각 기능에 대해서 관련된 것들을 구역화하고, 이들의 모델의 내부와 외부에 대한 인터페이스를 설정하게 되면 그 구역화를 기점으로 마이크로 서비스를 이룰 수 있는 것을 의미하는 것이다.)

이러한 마이크로 서비스를 이룰 때 고려해야할 점 중 하나는 조직 구조와의 관계성에 대한 고민이다. 각 작은 서비스에 대해서 한 팀에서 다루면 큰덩어리의 한 묶음으로 관리하여 테스팅 단순화를 도모할 수 있고, 각 작은 서비스가 다른 팀이 하게 되면 최상위 계층의 마이크로 서비스가 될 수 있다. 

모놀리식 시스템을 어떻게 하면 구역화하고 어떻게 마이크로 서비스들의 묶음으로 수정할 수 있을 지에 대한 고민을 하게 되는 것 같다. 무엇보다 중요한 쟁점은 마이크로 서비스의 장점을 살리고, 그것을 이용하는 방법에 달린 것 같다. 더 고민해봐야할 것들이다.  

이는 마이크로서비스 아키텍처 구축을 공부하면서 생각을 정리한 것입니다.. 관련된 내용에 대해서 더 알고 싶은 경우에는 해당 책을 보는 것을 권유합니다.

아키텍트는 건축가보다는 도시 설계자에 가까운 의미로 접근해야한다고 한다.

나무를 보지 말고, 숲을 보라는 의미인건가? 나는 개발자로서 마이크로 서비스 아키텍쳐를 이해하려고 이 책을 봐서 그런지 아직 아키텍트라가 어떤 일을 하는지에 대한 감이 오지 않았다.

아키텍트는 앞서 생각했던 각기 다른 기술로 서비스를 할 경우에 발생하는 조직 내부의 문제 등을 최소화하기 위해서 일련의 규칙을 정하고, 올바른 방향으로 나아가도록 방향을 제시하는 것으로 시작되는 것이라고 생각한다. 이를 기반으로 큰 틀을 정하고, 각 서비스에 자율성을 부여하며 그것들이 하나의 응집력 있는 애플리케이션을 이루도록 하는 것.

이러기 위해서는 시스템의 상태를 일관되게 살펴볼 수 있어야 하고, 인터페이스 기술의 표준을 최소화 해야하며, 오동작에 대해 방어할 수 있는 시스템을 만들어야한다. 

또한, 개발자들이 약간의 노력으로 이런 지침들을 따를 수 있게 하는 것 또한 아키텍트의 능력이다. 그 방법으로는 본보기나 서비스 템플릿을 제공하는 것이다. 서비스 템플릿을 제공하는 경우에 개발자들로 하여금 잘못된 코딩을 줄여 시간을 단축할 수 있지만, 자칫 잘못하면 프로그래밍 언어의 선택을 제한할 수 있다. 

추가로 아키텍트의 담당 업무 중 하나는 거버넌스 (Governance)이다. 이는 "기업의 목적이 이해관계자의 요구, 조건, 섡택을 평가함으로써 달성될 수 잇음을 보장한다. 우선순위 및 의사 결정을 통해 방향을 설정하고, 합의된 방향과 목표에 대한 성과, 규칙 준수, 과정을 모니터링한다. "

 이렇게 본 아키텍트는 기술 적용과 규칙을 정했을 때 발생하는 트레이드 오프를 올바르게 결정하기 위해 끊임없는 고민을 해야하는 것 같다. 그 고민들의 결과물이 더 나은 서비스, 그리고 개발자들이 물 만난 물고기처럼 헤엄 칠 수 있는 환경을 제공하는 것이 아닐까? 

이는 마이크로서비스 아키텍처 구축을 공부하면서 생각을 정리한 것입니다.. 관련된 내용에 대해서 더 알고 싶은 경우에는 해당 책을 보는 것을 권유합니다.

마이크로 서비스는 Mirco Service, 초소형 서비스를 말한다. 한 가지 앱에서 지원해야 할 서비스가 많아지면 당연하게 그 크기느 커질 수 있겠지만 마이크로 서비스 아키텍쳐는 그것들을 많이 세분화하여 작은 서비스의 여러개의 묶음으로 표현하려는 것이다. 처음에는 이것에 대해서 그럴 수 있고, 간단하다는 생각을 하였는데, 이것이 생각보다 약속할 것도 많고 설계시에 까다로운 부분들이 존재하다는 것을 알 수 있었다.

 분리된 각 서비스는 자율성을 가질 수 있다. 그렇기에 각 서비스마다 다른 기술을 적응시킬 수 있다. 이는 서비스 끼리의 의사소통은 네트워크 호출로 이루어지기 때문에 가능하다. " 각 서비스는 독립적이고 자율성을 가지며 다른 서비스와는 네트워크로만 통신한다. "라고 보았을 때 중복 코드가 무수히 많아질 것이라는 생각도 따라온다. 또한, 네트워크 통신에 대한 규칙에 얽메일 수 있고 주고 받는 데이터가 바뀔 때 독립성이 모호해지는 것이 아닌가 하는 생각에도 빠진다. 이는 어쩌면 끊임 없이 '다른 변경 없이 특정 서비스만을 변경하고 배포하는가?' 에 대해서 고민해야하는 방법이다.

 그렇기에 마이크로 서비스는 초기 설계와 개발하면서 진행 될 수 많은 토론과 회의 그리고 고민이 필요하다는 생각으로 연결 되었다. 자연스럽게 이런 노력과 시간이 의미가 있는 방법론인가? 생각하였고, 내가 일하면서 불편했던 것들의 단점들을 보완한다는 결론에 이르렀다.

 첫 번째는 매우 작은 서비스들로 세분화 되었기 때문에 몇몇 부분에서는 새로운 기술을 도입하려고 해도 리스크가 적다는 것이다. 문제를 해결하려고 할 때 이를 해결 할 수 있는 기술이나 방법을 찾아본 적이 있을 것이다. 하지만 모놀리식 서비스로 구성되었을 경우에는 새로운 기술에 대한 리스크에 고민과 고민의 수 많은 연결고리에서 현재 적용된 시스템에 영향을 미치지 않는 방법을 찾기 위한 시간을 보내야 했다. 하지만 세분화된 마이크로 서비스에서는 이러한 리스크가 작아지는 것을 느낄 수 있을 것이다.

두 번째는 독립성을 가지고 세분화된 마이크로 서비스는 배포에서도 큰 장점을 가질 수 있다. 모놀리그식 서비스로 구성된 것의 경우 작은 수정에도 전체 애플리케이션을 배포해야하는 번거로움이 있다. 하지만 마이크로 서비스의 경우 해당 서비스에 대한 배포만 하면 된다. 신속하고 빠르게 배포하고 더 자주 배포할 수 있을 것이다.

다른 장점들이 있지만 기존의 모놀리그 식에서 느꼈던 단점을 보완하는 이 두가지의 장점이 내게 와닿았다. (이는 아직 마이크로 서비스에 대한 학습과 이해가 부족해서 일 수 있다.)

마이크로 서비스에 대해서 잠깐 보았을 때 느껴진 것은 장점이 많지만 이는 모든 것의 만능열쇠는 아니라는 것 그리고, 세분화를 할 때 생각해야하는 수 많은 고리들에 대한 깊은 고민을 해야하는 것이다. 

어떻게 하면 이런 장점을 극대화시키면서 서비스를 구축할 수 있을지 고민해봐야겠다.

이는 마이크로서비스 아키텍처 구축을 책을 통해 공부하면서 생각을 정리한 것입니다. 관련된 내용에 대해서 더 알고 싶은 경우에는 해당 책을 보는 것을 권유합니다.