최근 면접본 회사는 MSA(Micro Service Architecture)식 개발을 한다고 하였고, 더 최근에 기술과제를 수행하고 그에 대한 피드백을 받았는데, 디자인 패턴에 대한 공부를 병행하는 것을 추천받았다. 때마침 길벗 출판사에서 "마이크로서비스 패턴"이라는 책을 출간했다. 또한 서평단을 모집한다는 소식에 망설이지않고 바로 지원했다. 결과는 .... (두둥)
집에 책이 도착했다. 신나는 마음으로 열어보았다. 처음에는 책 내용을 정리해서 같이 적을까 하다가. 적어둔 내용이 (절반정도 적었었는데... ㅠ) 싹 날아가버려서 ... 도저히 다시 그정도의 요약을 하기는 힘들 것 같다.
아뿔사... 대상 독자를 보니 CTO, 기술 부사장, 아키텍트, 개발자 등을 얘기하고있다. '개발자'라고 포괄적인 범위 외에는 뭔가 다들 개발 년차가 최소 두자리수는 넘어 갈 것 같은 직책이다. (약간 의기소침 해지지만... 가볍게! 가볍게! 언젠가 나도 이런 포지션이 오지 않을까? 생각보다 금방 다가올지도 모른다. 적어도 처음 다가왔을 때, 그게 뭐지? 보다는 아...? 정확하게는 모르지만 그거? 정도는 되면 처음 보는 것 보다는 쉽게 와닿지 않을까? 하는 큰 그림을 그려본다)
챕터의 순서와 간략한 소개를 진행해본다.
1장. 모놀리식 지옥에서 벗어나라
미국의 FTGO(Food to Go)의 예를 들면서 내용을 진행하고있다. 미국 온라인 배달 업계를 선도하는 회사라고 한다. 우리나라의 '배달의 민족' 정도의 포지션이 아닐까 한다. FTGO가 사업초기와 같이 작은 규모일 때는 문제점이 없었지만, 규모가 엄청나게 커진 FTGO는 모놀리식 지옥에 빠져있는 상황이고 이를 극복하기 위해 마이크로 서비스 패턴을 적용하려고한다.
먼저 모놀리식 아키텍처의 장점을 알아보자
모놀리식 아키텍처의 장점
개발이 간단하다
애플리케이션을 쉽게 변경할 수 있다.
테스트하기 쉽다.
배포하기 쉽다.
확장하기 쉽다.
(하지만 거대한 모놀리스는 이러한 장점들의 의미가 퇴색하기 시작한다)
모놀리식 지옥에 빠지게 되는 이유
너무 복잡해서 개발자가 주눅 든다.
개발이 더디다.
커밋부터 배포에 이르고 길고 험난한 여정
확장하기 어렵다
모놀리스는 확실하게 전달하기 어렵다
갈수록 한물간 기술 스택에 발목이 붙잡힌다
모놀리스 지옥을 벗어나기 위한 해법으로 마이크로서비스 아키텍처를 제시한다.
마이크로서비스 아키텍처의 특징
확장 큐브와 마이크로서비스 (확장 큐브라는 3차원 확장 모델)
마이크로서비스는 모듈성을 갖고 있다.
서비스마다 DB가 따로 있다
FTGO 마이크로서비스 아키텍처
마이크로서비스 아키텍처와 SOA
마이크로서비스 아키텍처의 장점
크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있다.
서비스 규모가 작아 관리하기 쉽다.
서비스를 독립적으로 배포/확장할 수 있다.
마이크로서비스 아키텍처 덕분에 팀이 자율적으로 움직인다.
결함 격리가 잘된다.
새로운 기술을 실험하고 도입하기 쉽다.
마이크로서비스가 만병 통치약은 아니다. 마냥 장점만 있는게 아니다.
마이크로서비스 아키텍처의 단점
딱 맞는 서비스를 찾기가 쉽지 않다.
분산 시스템은 너무 복잡해서 개발, 테스트, 배포가 어렵다.
여러 서비스에 걸친 기능을 배포할 때에는 잘 조정해야 한다.
마이크로서비스 아키텍처 도입 시점을 결정하기가 어렵다.
또한 책에서는 패턴과 패턴 언어를 소개하면서 마이크로서비스 아키텍처 패턴 언어를 설명하고 있다.
패턴은 아래와 같이 총 세 계층으로 분리되고 각 계층 중 주요 패턴 그룹을 하나씩 설명한다.
인프라 패턴(infrastructure pattern)
애플리케이션 인프라(application infrastructure)
애플리케이션 패턴(application pattern)
2장. 분해 전략
마이크로서비스 아키텍처란 무엇인가?로 시작하여서 소프트웨어 아키텍처의 정의, 아키텍처 스타일 그리고 마이크로서비스 아키텍처는 또 무엇인지에 대한 설명을 곁들이고있다. (이번 장의 구성이 나에게는 생소한 내용들임에도 불구하고 딱히 구선생님(Google)의 도움없이 잘 헤쳐나갔다)
또한 마이크로서비스 아키텍쳐의 정의와 예시 모델들을 통해서 이해하기 쉽게 설명하고있다.
3장. 프로세스 간 통신
요즘에는 서비스에 적용 가능한 IPC(Inter-Process Communication) 기술이 정말 많다. HTTP, REST, gRPC... 동기 요청/응답 기반의 통신 메커니즘도 있고, AMQP, STOMP 등 비동기 메시지 기반의 통신 메커니즘도 있다. 메시지 포맷 역시 JSON, XML처럼 인간이 읽을 수 있는 포맷부터 아브로나 프로토콜 버퍼처럼 효율적인 이진 포맷등 매우 다양하다.
서비스 API에 알맞은 IPC를 선택하기 전에 클라이언트/서비스 간 상호 작용 스타일을 잘 살펴보면, 요건에서 벗어나는 일 없이 특정 IPC 기술의 세부 내용에 빠져 헤매는 일을 방지할 수 있고, 상호 작용 스타일의 선택의 중요성을 설명하고 있다.
첫째, 클라이언트/서비스 상호 작용 스타일은 두 가지 기준으로 분류할 수 있다.
일대일 1) 요청/응답 2) 비동기 요청/응답 3) 단방향 알림
일대다 1) 발행/구독 2) 발행/비동기 응답
둘째, 동기/비동기 여부이다.
동기
비동기
또한 마이크로서비스 API를 정의에 대한 설명을 하고있다.
API는 어떤 IPC를 사용하느냐에 따라 그 내용이 결정된다. 메시징으로 통신하는 API는 메시지 채널, 메시지 타입, 메시지 포맷으로 정의한다. HTTP로 통신하는 API는 URL, HTTP 동사, 요청/응답 포맷으로 구성된다.
서비스 API는 시간에 따라 조금씩 발전한다. 걱정하지마라 이 책에서는 API를 발전시키기 위한 방법도 제시한다. (정말 이정도면 A to Z가 아닌가? 많이 친절한 서적인 것 같다. 추가적으로 지금까지 작성한 글을 보니 13장중에서 이제 3장을 적고있는데 이미 스압(스크린 압박)이 느껴진다. 서평이라는 것이 책의 내용을 요약하는 것은 아니고 책이 어떤지를 평하는 것이 목적이니 이후 내용은 간략하게 챕터를 언급하고 넘어가겠다.)
이후의 Chapter
4장. 트랜잭션 관리: 사가
5장. 비즈니스 로직 설계
6장. 비즈니스 로직 개발: 이벤트 소싱
7장. 마이크로서비스 쿼리 구현
8장. 외부 API 패턴
9장. 마이크로서비스 테스트 1부
10장. 마이크로서비스 테스트 2부
11장. 프로덕션 레디 서비스 개발
12장. 마이크로서비스 배포
13장. 마이크로서비스로 리팩터링
부록. 실습 환경 구성
Q. 이 책 어때요?
전체적인 책의 구성이 잘되어있다. 앞서 설명했듯이 디자인 패턴에 대한 공부를 따로 한적이 없는 신입 개발자(정확히는 신입을 지망하는...)도 이해하는데 그렇게 어렵지 않았다. 책을 처음부터 꼼꼼히만 읽는다면 궁금증이 생기는 부분에 대해서는 미리 전제를 깔고 간다거나 혹은 (친절하게도) 뒷장에서 설명을 해준다는 언급을 미리 해주고 뒷장에서 자세한 설명을 해준다. 내 성격상 글을 읽다가 이해가 안되면 (구gle선생님)바로바로 찾아보는 편인데 가끔 배경지식이 거의 없는 글을 볼때는 책보다 구글을 더 많이 봐서 책을 읽는 속도가 많이 느려지기도 했다. 그렇게 이해를 위해서 긴 시간을 투자해서 앞장들을 보면서 왔는데 알고보니 뒷장에서 설명이 자세하게 되어있는 경우... 그 허탈함은 이루 말할 수가 없다. 이런 독자의 수고를 덜어주는 구성도 좋았다.
아직까지 다른 디자인 패턴 책을 본적이 없어서 다른 책들도 이렇게 친절하게 A to Z 식의 설명을 해주는지는 모르겠지만, 디자인 패턴이라는게 그렇게 쉬운 주제가 아니라고 생각한다(아마 나만 그렇게 생각하는게 아니지 않을까?). 그러한 주제다보니 사실 읽기전부터 걱정도 많이 됐었는데 막상 책을 읽으면서 우려했던 일(= 이게 무슨말이지...? 의 늪)은 벌어지지 않았다. 오히려 이번 계기로 디자인 패턴에 대한 기본적인 지식뿐만 아니라 마이크로 서비스 아키텍쳐, 모놀리식 아키텍처에 대해서도 알게 되었고(난 지금까지 모놀리식 아키텍처를 따르고 있었구나...? 라는 걸 알게됐다), 마이크로서비스 패턴을 따르는데 발생하는 문제점을 해결하기 위한 전략 및 방법론에 대해서도 이런게 있구나!? 정도의 지식을 얻을 수 있었다. '마이크로서비스 패턴'이 지금 애초당시에 한번 읽은 것 가지고는 온전히 내 것이 되기에는 쉽지 않은 주제이기에 2~3번은 더 읽어봐야 어디가서 좀 안다고 말 하지 않을까 싶다.
