[1장] 더도 덜도 아닌 딱 마이크로서비스</br>마이크로서비스란 무엇인가?</br>__독립적인 배포 가능성</br>__비즈니스 도메인을 중심으로 하는 모델링</br>__데이터 소유권 문제</br>__마이크로서비스의 장점</br>__마이크로서비스가 야기하는 문제점</br>__사용자 인터페이스</br>__기술</br>__규모</br>__소유권</br>모놀리스</br>__단일 프로세스 모놀리스</br>__분산 모놀리스</br>__외부 블랙박스 시스템</br>__모놀리스의 문제점</br>__모놀리스의 장점</br>결합도와 응집력</br>__응집력</br>__결합도</br>더도 덜도 아닌 딱 도메인 주도 설계</br>__집계</br>__경계 컨텍스트</br>__집계와 경계 컨텍스트를 마이크로서비스에 매핑</br>__더 읽을거리</br>정리</br></br>[2장] 마이그레이션 계획하기</br>목표 이해하기</br>__3가지 핵심 질문</br>왜 마이크로서비스를 선택하려 하는가?</br>__팀 자율성 향상</br>__시장 출시 시간 단축</br>__부하를 다루기 위한 비용 효율적인 확장</br>__견고성 향상</br>__개발자 수 늘리기</br>__신기술 수용</br>마이크로서비스는 어떤 경우에 나쁜 선택일까?</br>__불분명한 도메인</br>__스타트업</br>__고객 설치형 소프트웨어와 관리형 소프트웨어</br>__좋은 이유를 못 찾겠다!</br>균형 조정</br>사람들과 함께 여정을 떠나다</br>조직 변화 구현</br>__위기감 조성</br>__혁신 추진체 구성</br>__비전과 전략 수립</br>__변화 비전 전달</br>__광범위한 조치를 위한 직원의 자율권 강화</br>__단기적인 성과 창출</br>__이익 통합과 더 많은 변화 추구</br>__혁신 문화의 정립</br>점진적인 마이그레이션의 중요성</br>__운영 환경은 중요하다</br>변화에 드는 비용</br>__가역적 결정과 비가역적 결정</br>__실험을 시도해볼 만한 곳</br>우리가 시작해야 할 지점은?</br>도메인 주도 설계</br>__작업 범위를 얼마나 넓게 잡아야 할까?</br>__이벤트 스토밍</br>__우선순위 지정을 위한 도메인 모델 사용</br>결합된 모델</br>팀 재구성하기</br>__변화하는 구조</br>__만병통치약은 없다</br>__변화 일으키기</br>__전문 기술 변경하기</br>전환이 순조로운지 어떻게 확인할까?</br>__정기 점검 사항</br>__정량적인 측정</br>__정성적인 측정</br>__매몰 비용 오류 방지</br>__새로운 방식에 마음을 열자</br>정리</br></br>[3장] 모놀리스 분할</br>모놀리스를 그대로 둘 것인가, 바꿀 것인가?</br>__잘라 내기, 복사 또는 재구현?</br>__모놀리스 리팩터링</br>마이그레이션 패턴</br>패턴: 교살자 무화과 애플리케이션</br>__작동 원리</br>__적용 대상</br>__사례: HTTP 리버스 프록시</br>__데이터?</br>__프록시 옵션</br>__프로토콜 변경</br>__사례: FTP</br>__사례: 메시지 가로채기</br>__그 밖의 프로토콜</br>__교살자 무화과 패턴의 다른 예</br>기능을 마이그레이션하는 동안 동작 방식 변경하기</br>패턴: UI 컴포지션</br>__사례: 페이지 컴포지션</br>__사례: 위젯 컴포지션</br>__사례: 마이크로 프론트엔드</br>__적용 대상</br>패턴: 추상화에 의한 분기</br>__작동 원리</br>__대체 메커니즘을 위한 분기 검증</br>__적용 대상</br>패턴: 병행 실행</br>__사례: 신용파생 가격 비교</br>__사례: 홈게이트 목록</br>__검증 기법</br>__스파이 사용</br>__깃허브 사이언티스트</br>__어둠의 출시와 카나리아 릴리스</br>__적용 대상</br>패턴: 협업자 데코레이터</br>__사례: 멤버십 프로그램</br>__적용 대상</br>패턴: 변경 데이터 캡처</br>__사례: 멤버십 카드 발급</br>__변경 데이터 캡처 구현</br>__적용 대상</br>정리</br></br>[4장] 데이터베이스 분해</br>패턴: 공유 데이터베이스</br>__패턴 다루기</br>__적용 대상</br>그러나 수행할 수 없다!</br>패턴: 데이터베이스 뷰</br>__공개된 계약으로서 데이터베이스</br>__표현할 뷰</br>__한계</br>__소유권</br>__적용 대상</br>패턴: 데이터베이스 래핑 서비스</br>__적용 대상</br>패턴: 서비스로서 데이터베이스(DaaS) 인터페이스</br>__매핑 엔진 구현</br>__뷰와의 비교</br>__적용 대상</br>소유권 양도</br>__패턴: 집계를 외부에 공개하는 모놀리스</br>__패턴: 데이터 소유권 변경</br>데이터 동기화</br>패턴: 애플리케이션에서 데이터 동기화</br>__1단계: 데이터 대량 동기화</br>__2단계: 이전 스키마에서 읽고 쓰기를 동기화</br>__3단계: 새 스키마에서 읽고 쓰기를 동기화</br>__이 패턴을 사용하는 사례</br>__적용 대상</br>패턴: 예광탄 기록</br>__데이터 동기화</br>__사례: 스퀘어의 주문 처리</br>__적용 대상</br>데이터베이스 분리</br>__물리적 데이터베이스 분리 vs 논리적 데이터베이스 분리</br>데이터베이스를 먼저 분할할까, 아니면 코드를 먼저 분할할까?</br>__데이터베이스를 먼저 분할</br>__코드를 먼저 분할</br>__데이터베이스와 코드를 함께 분할</br>__그렇다면 무엇을 먼저 분할해야 할까?</br>스키마 분리 사례</br>패턴: 테이블 분할</br>__적용 대상</br>패턴: 외래 키 관계를 코드로 이동</br>__조인 이동</br>__데이터 일관성</br>__적용 대상</br>__사례: 공유 정적 데이터</br>트랜잭션</br>__ACID 트랜잭션</br>__여전히 ACID이지만 원자성이 부족한가?</br>__2단계 커밋</br>__분산 트랜잭션? 그냥 아니라고 말하자</br>사가 패턴</br>__사가 실패 모드</br>__사가 패턴 구현</br>__사가와 분산 트랜잭션의 비교</br>정리</br></br>[5장] 마이크로서비스 도입 과정에서 직면하는 문제와 해법 </br>서비스가 늘어날수록 고충도 커지게 마련</br>규모에 맞는 소유권</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>기존 호환성을 깨뜨리는 파괴적 변경</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>리포팅</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>모니터링과 트러블슈팅</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>로컬에서 개발하는 동안 겪는 개발자 경험</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>너무 많은 것들을 실행</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>전 구간 테스트</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>전역 최적화와 지역 최적화 비교</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>견고성과 회복탄력성</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>외톨이 서비스</br>__문제가 드러나는 방식</br>__문제가 드러나는 시점</br>__잠재적인 해법</br>정리</br></br>마치면서</br></br>부록 A 참고문헌</br>부록 B 패턴 목록</br>부록 C 한국어판 특별 부록: 기술의 진화로 짚어보는 마이크로서비스 도입의 허와 실</br>

이 책에서 다루는 내용
■ 재구축 대신 마이크로서비스 마이그레이션을 고려하는 조직을 위한 이상적인 해결책
■ 기업이 마이크로서비스 도입에 관한 의사결정을 내리고 마이그레이션 시점을 판단하는 과정에 대한 절차와 조언
■ 커뮤니케이션, 통합, 레거시 시스템 마이그레이션 방법
■ 다양한 마이그레이션의 패턴과 적용 대상
■ 데이터베이스 동기화 전략을 중심으로 보는 데이터베이스 마이그레이션 사례
■ 다양한 아키텍처적인 리팩터링 패턴을 비롯한 애플리케이션 분해
■ 참조 무결성과 트랜잭션 무결성을 망가뜨릴 경우에 발생하는 영향력과 새로운 실패 모드를 비롯한, 데이터베이스 분해와 관련된 세부사항


이 책의 구성
이 책에서는 기존 시스템을 마이크로서비스 아키텍처로 분해하는 과정에서 어떻게 생각하고 실행할지에 대한 내용을 철저히 분석했다. 우리는 마이크로서비스 아키텍처와 관련된 많은 주제를 살펴볼 것이지만, 초점은 서비스의 분해 측면에 있다. 마이크로서비스 아키텍처에 대한 개괄을 알고 싶다면 나의 전작 『마이크로서비스 아키텍처 구축』 책으로 시작하기 바란다. 실은, 두 책을 함께 읽기를 강력하게 권장한다.

1장 ‘더도 덜도 아닌 딱 마이크로서비스’에는 마이크로서비스가 무엇인지에 대한 개요를 담았으며, 마이크로서비스 아키텍처로 이끈 사상을 자세히 살펴본다. 마이크로서비스를 처음 접하는 사람들이야 꼭 챙겨 읽어야 하지만, 경험이 풍부한 사람들도 1장은 건너뛰지 말기 바란다. 기술의 혼란 속에서, 마이크로서비스의 중요한 핵심 사상이 간혹 간과되는 경우가 있다. 바로 이런 개념을 이 책에서 거듭해서 다룰 것이다.

마이크로서비스를 좀 더 제대로 이해하면 좋으나, 마이크로서비스가 여러분에게 적합한지를 파악하는 것은 전혀 다른 문제다. 2장 ‘마이그레이션 계획하기’에서는 마이크로서비스가 자신에게 적합한지 여부를 평가하는 방법을 알려주며, 모놀리스에서 마이크로서비스 아키텍처로 전환 과정을 관리하는 방법에 대한 매우 중요한 몇 가지 지침을 제공한다. 여기서는 도메인 주도 설계부터 조직 변경 모델에 이르기까지, 심지어 마이크로서비스 아키텍처를 채택하지 않는 경우에도 큰 도움이 되는 중요한 토대를 다룰 것이다.

3장 ‘모놀리스 분할’과 4장 ‘데이터베이스 분해’에서는 모놀리스 분해, 실제 예제 탐색, 마이그레이션 패턴 추출 등과 관련된 기술적 측면을 철저하고 상세하게 살펴본다. 3장에서는 애플리케이션 분해 측면을 집중해서 다루고, 4장에서는 데이터 문제를 매우 상세하게 설명한다. 정말로 모놀리스 시스템에서 마이크로서비스 아키텍처로 이동하기를 원하면, 데이터베이스 일부를 분리해야 할 것이다!

5장 ‘마이크로서비스 도입 과정에서 직면하는 문제와 해법‘에서는 마이크로서비스 아키텍처가 성장함에 따라 여러분이 직면할 문제를 몇 가지 살펴본다. 마이크로서비스 시스템은 장점도 많지만, 이전에는 겪어보지 못한 많은 복잡성과 문제도 따라온다. 5장에서는 마이크로서비스와 관련된 문제가 발생할 때 문제를 발견하는데 도움이 되는 방법, 그리고 마이크로서비스와 관련해 점점 커지는 난관을 해소할 방법을 제공한다.

마지막으로, 한국어판 특별 부록 ‘기술의 진화로 짚어보는 마이크로서비스 도입의 허와 실’을 수록해 목표나 결과가 아닌, 여정으로서 바라보는 마이크로서비스에 관한 통찰을 담았다.

이 책의 독자 대상
■ 마이크로서비스의 전반적인 개념을 이해하고자 하는 분
■ 모놀리스에서 마이크로서비스 아키텍처로 전환 과정을 알고싶은 분
■ 모놀리스 분해, 마이그레이션 패턴 추출, 데이터베이스 분해 등과 관련된 기술적 측면이 궁금한 분
■ 마이크로서비스 도입 과정에서 직면하는 문제와 해법을 얻고자 하는 분
■ 시스템 배포 및 테스팅, 유지 보수에 관심 있는 IT 업계 종사자
■ 대용량 시스템의 효율적 분산 설계에 관심 있는 기업 CEO 및 경영진

이 책에서 다루는 마이크로서비스 마이그레이션 패턴 23가지
■ 경계 컨텍스트 단위의 저장소 패턴
■ 공유 데이터베이스 패턴
■ 교살자 무화과 애플리케이션 패턴
■ 다중 스키마 저장소 패턴
■ 데이터베이스 래핑 서비스 패턴
■ 데이터베이스 뷰 패턴
■ 데이터 소유권 변경 패턴
■ 데이터 접근 계층으로 작동하는 모놀리스 패턴
■ 변경 데이터 캡처 패턴
■ 병행 실행 패턴
■ 서비스 인터페이스로서 데이터베이스(DaaS) 인터페이스 패턴
■ 애플리케이션에서 데이터 동기화 패턴
■ 예광탄 기록 패턴
■ 외래 키를 코드로 이동 패턴
■ 전용 참조 데이터 스키마 패턴
■ 정적 참조 데이터 라이브러리 패턴
■ 정적 참조 데이터 서비스 패턴
■ 중복 정적 참조 데이터 패턴
■ 집계를 외부에 공개하는 모놀리스 패턴
■ 추상화에 의한 분기 패턴
■ 테이블 분할 패턴
■ 협업자 데코레이터 패턴
■ UI 컴포지션 패턴

추천평
이 책에서 다루는 ‘마이크로서비스 마이그레이션’의 접근 방식을 팀의 업무에 실제로 적용해본 경험이 있다. 하지만, 기대와는 달리 실제 적용 후 많은 비효율과 문제가 발견되었고, 문제를 하나씩 해결하며 안정적인 서비스를 런칭하고 운영하기까지의 과정에는 부단한 노력이 필요했다.

새로운 개념을 서비스에 적용하는 과정에서 시행착오를 거듭하는 것은 피할 수 없는 과정인 듯하다. 이 과정에서 절실히 필요한 것은 앞서 경험해본 누군가, 혹은 팀의 지식이라고 생각한다. 이러한 지식을 통해 우리는 시행착오를 줄일 수 있을 뿐만 아니라, 서비스의 성공 확률 또한 높일 수 있지 않을까?

서로 다른 특성을 지닌 다양한 도메인의 서비스들은 저마다 마이크로서비스 개념을 도입하는 과정에서 겪게 될 문제도 각기 다를 것이다. 이렇게 다양한 환경에서, 이 책은 나 혹은 우리 팀 만의 방법으로 변화를 받아들이기 위해 필요한 공통적인 고민을 다룬다. 몇 주, 혹은 몇 달 뒤 마주치게 될 문제와 그에 따른 고민을 미리 해보고, 해결 방안을 확인하고자 하는 분들께 이 책을 추천한다. 이론적인 지식만이 아닌 실제 경험에 근거한 사례와 방법론, 이를 바탕으로 한 조언은 분명 도움이 될 것이다.
- 김준기 / beNX R&D 센터 실장

애자일, 마이크로서비스 플랫폼, 소프트웨어 개발 기술 전수 등으로 잘 알려진 피보탈의 한국 지사장으로 일하던 시절, 메이저 금융 그룹이나 엔터프라이즈 기업들의 회장님이나 사장님들을 뵐 기회가 많았다. 샌프란시스코의 피보탈랩 연구소와 미팅을 하다 보면 의외로 관심사가 한결 같았다. “우리 핵심 금융 소프트웨어들을 시장의 요구에 맞춰 빠르게 개선하고 싶은데, 피보탈 랩이 이 분야에서 가장 잘한다고 해서 들으러 왔습니다.” 영업하는 입장에서 상당히 고무적이기도 한 핵심 가치를 포함한 이런 질문 속에 담긴, 구체적인 실행 방법을 묻는 회장님, 행장님들의 인사이트에 놀라곤 했지만 막상 실무진과의 협업은 이와 같지 않았다. “서비스를 오브젝트 단위로 쪼개야 하나요?” “데브옵스의 정확한 정의는 무엇인가요?” “저희 개발팀 성과 측정과는 매우 다르네요.” 류의 엔터프라이즈에서 살아남기 위한 ‘직원’들의 질문이었다

C레벨 및 임원들은 이미 사업의 방향을 인지하고 있었지만, 실무진들이 원하는 ‘How to’에는 기술적인 질문뿐만 아니라 권한이 없는 상태에서 마이크로서비스를 과연 도입해야 하는지, 해야 한다면 어떤 방식으로 조직에 적용해야 하는지가 어려운 문제였다. 그리고 이런 문제들은 아마존 웹 서비스에서, 또는 피보탈에서도 직접 고객이 프로젝트를 수행하지 않으면 얻기 힘든 답변이었기도 하다.

이 책에서는 마이크로서비스의 다양한 측면에 대해 조명한다. 사실 대부분의 금융 소프트웨어가 지닌 문제는 기술의 최신화에 대한 어려움만은 아닐 것이다. 이벤트 스토밍, 도메인 주도 설계, 테스트 주도 개발 등보다 선행되어야 할 것은 적절한 사업 모델을 반영한 애플리케이션의 선정, 그리고 대상 애플리케이션에 능력 있는 개발자들이 도전할 수 있는 환경을 마련하는 것일테다. 이 책은 그러한 ‘해보지 않은 분들’을 위한 미지의 영역을 다루고 있다. 마이크로서비스, 클라우드 네이티브, 그리고 콘웨이의 법칙 등 최신 트렌드에 대해 한 번이라도 들어봤다면 이 책의 좋은 독자인 동시에 한국의 엔터프라이즈 기업들이 원하는 인재일 것이다.
- 노경훈 / 아마존 웹서비스 코리아 Head of Financial Services Industry

이 책은 마이크로서비스의 정의와 모놀리스서비스를 마이크로서비스로 전환하는 방법을 설명하는 패턴을 포함하고 있다. 그러나 그보다 중요한 것은 저자가 보유한 마이크로서비스에 관련한 광대한 지식과 경험이다.

얼마 전, 이전 회사의 동료와 우리가 같이 만들었던 서비스를 마이크로서비스라 부를 수 있는지에 관해 열띤 논의를 한 적이 있었는데, 이 책의 구체적인 내용을 제시했다면 싱겁게 끝날 논의였을 것이다.

그만큼, 마이크로서비스 아키텍처 플랫폼을 개발하고 있는 입장에서 이 책 『마이크로서비스 도입, 이렇게 한다』는 마이크로서비스가 왜 필요한지를 명확히 설명해 줄 수 있는 귀중한 자료다. 마이크로서비스에 대한 개념을 알고 싶거나, 마이크로서비스를 구현하고자 하는 모든 이에게 필독서로 추천한다.
- 안승규 / SKT 클라우드 네이티브 개발팀 수석 소프트웨어 엔지니어, 『쿠버네티스 패턴』 역자

흔히 “창업(創業)보다는 수성(守成)이 어렵다”라는 말을 한다. 새로운 업을 일으키는 것도 어렵지만 그 업의 성공을 유지하는 것은 보기보다 더 어렵고 중요하다는 것을 포착한 고서 정관정요(貞觀之治) 출연진의 명언이 아닐까 한다. 개발자 입장에서 나름대로 해석하자면 새로운 시스템을 새로운 기술로 만드는 일도 분명 난관이 있지만 남이 구축하고 물려준 오래된 레거시 시스템을 분석해 신기술을 적용하며 중단없이 신규 시스템으로 이전하는 것은 몇 배나 더 고된 일일 것이다(물론, 그래서 성취감도 더 크다).

저자의 이전 저작인 『마이크로서비스 아키텍처 구축』(원제: Building Microservices)이 마이크로서비스의 개념을 훌륭히 소개했다면, 이 책은 레거시 시스템을 마이크로서비스 기반 시스템으로 성공적으로 전환하는 데 필요한 모든 것(마이그레이션 전략, 마이그레이션을 위한 최적화된 조직 구조, 점진적 전환, 모놀리스 앱과 데이터베이스를 분리하는 방법과 패턴, 전환 과정에 도사리고 있는 실수까지)저자의 지식과 경험의 정수를 체계적으로 정리했다.

2018년 거대한 레거시 계정 시스템을 클라우드 네이티브와 마이크로서비스 아키텍처로 동시에 전환하면서 2019년 말 이 책의 원서를 접했다. 1년간 고민하고 시행착오를 거치면서 체득한 우리의 마이그레이션 지식과 방법이 너무나도 체계적으로, 학문적으로 잘 정리되어 있어 놀랍고도 반가웠으며, 그제서야 책으로 출간한 저자와 출판사가 원망스럽기도 했다(1년만 더 빨리 내주시지...). 최근 레거시 시스템의 마이그레이션은 IDC에서 클라우드로, 기능을 유지하며 모놀리스 앱을 더 작은 앱으로, 단일 데이터베이스에서 이기종으로, 그리고 장애 없이 무중단으로 전환을 요하는 고난이도 종합 프로젝트가 되어 가는 것 같다.

이런 추세에 번역의 달인 박재호 님의 글로 이 책이 출간되어 독자의 한 사람으로서 무척 기쁘다. 한국 독자들의 마이그레이션 업무에 큰 도움이 될 것을 기대한다.
- 정성권 / 삼성전자 수석 엔지니어, 『마이크로서비스 아키텍처 구축』, 『스프링 마이크로서비스 코딩 공작소』 역자

평균 6명으로 구성된 10개 팀이 마이크로서비스들로 구성된 온라인 서비스의 API를 개발하고 운영 중이다. 이 API 를 다른 9개 팀들이 사용하고 있는 상태에서 API의 업데이트와 테스트를 어떻게 처리해야 다른 팀의 문제 없는 애플리케이션 동작을 지원할 수 있을까? 또는 다른 9개 팀에서 동일한 기능을 중복해 개발하는 것은 어떻게 방지할 것인가? 이런 경우 각각의 팀은 서로 어떻게 커뮤니케이션 해야 할까? 또 각 조직의 목표는 어떤 방식으로 구성해야 할까?

마이크로서비스는 “그런 게 있다고 하더라”는 시대를 지나, 실제 도입을 통해 이미 다양한 성공과 실패 사례가 발생하고 있지만 아직도 많은 사람에겐 베일에 싸여 있으며 어려운 분야 중 하나다. 당장 눈앞에 닥친 ‘마이크로서비스로 구현하라’는 상부의 지시 그리고 현재 조직 내부에 구성되어 있는 일을 처리하는 방법과 문화, 특히 KPI와 같은 것들은 담당자 입장에서는 매우 설정하기 어려운 과제다.

이 책은 마이크로서비스에 대해 알려지지 않은 부분들에 대한 아이디어를 제공한다. 프로젝트를 막 시작해야 하는 팀 구성원들이 함께 읽어 공통된 이해를 가지려는 시도는 그렇지 않은 경우에 비해 월등한 결과를 안겨 줄 것이다. 마이크로서비스는 알려진 기술적 과제보다는 알려지지 않은 조직적 문제에 당면할 가능성이 훨씬 높기 때문이다. 이 책이 특별한 이유는 마이크로서비스의 특정 부분을 기술하는 것에 그치지 않고 조직과 경험에 의해 예측될 수 있는 예상 가능한 문제에 대한 언급, 그리고 예제를 통한 구현 기법의 소개가 함께 이뤄지기 때문이다.

엔터프라이즈 규모의 마이크로서비스라면 ‘공통’으로 사용되고 유지되는 것들에 대한 해법이 필요할 것이다. 어느날 갑자기 CTO가 나타나, 올해부터 팀을 10개로 나누고 각각 개발해야 하는 모듈을 던져주는 식의 해법은 재앙을 낳을 뿐이다. 이런 것들에 대한 현실적 이해가 필요하다면, 그리고 변화에 대해 인지하고 있다면 이 책을 꼭 살펴보기 바란다.
- 정윤진 / DBS 코어/컨슈머 뱅킹 기술 및 운영 부분 SVP, 『클라우드 네이티브 자바』 역자

우리는 애플리케이션 아키텍처를 바라보는 혁명의 시기에 놓여 있다. IDC에 따르면 2022년까지 모든 새로운 애플리케이션의 90%가 마이크로서비스 아키텍처를 기반으로 만들어질 것이다. 데브옵스와 마찬가지로 마이크로서비스를 채택하면 민첩성과 유연성이 향상되어 기업은 제품과 서비스를 더 빨리 출시할 수 있다. 많은 기업에서 기존 앱을 마이크로서비스 기반 아키텍처로 마이그레이션하려고 계획 중이다. 그러나 먼저 몇 가지 중요한 질문이 있다. 시스템에서 동작하는 다른 모든 작업을 중지하지 않고 기존 시스템의 아키텍처를 어떻게 재구성할까? 마이크로서비스는 얼마나 커야 마땅할까? 마이크로서비스가 적절하지 않은 경우는 언제일까? 모놀리스를 분할할 때 채택할 수 있는 마이그레이션 패턴에는 어떤 것이 있을까?

이 책은 이런 질문에 대한 답변, 그 이상을 제공하며, 데브옵스 엔지니어는 물론 애플리케이션 개발자와 아키텍트에게 반드시 필요한 책이다. 또한 마이크로서비스 구현에 대한 세부사항을 제공할 뿐만 아니라 마이크로서비스 아키텍처와 관련된 문제점을 파고들며, 심지어 마이크로서비스로 향하는 여정이 여러분에게 적합한지 이해하는 과정에 도움을 준다.

오라일리 베스트셀러인 『마이크로서비스 아키텍처 구축』을 집필한 저자 샘 뉴먼은 모놀리스에서 마이크로서비스로 마이그레이션하는 경로를 포괄적으로 안내하기 위해 풍부한 경험을 활용한다. 뉴먼은 마이크로서비스를 확장함에 따라 증가하는 고충을 관리하는 가장 좋은 방법에 대해, 계획부터 구현은 물론이고 그 너머에 이르기까지 점진적이고 논리적인 방식으로 기술하며 상세한 지침을 속속들이 제공한다.

- 카르틱 크리슈나스와미 / 엔진엑스(NGINX) 제품 마케팅 이사

★지은이의 글★
몇 년 전, 우리 중 몇 명이 마이크로서비스에 대해 흥미로운 이야기를 떠들기 시작했다. 그 이후에 벌어진 상황은 여러분도 잘 아는 이야기다. 마이크로서비스는 전 세계 수백 개 회사의 기본 아키텍처가 되었으며(마이크로서비스가 야기한 문제들을 해결하기 위해 많은 사람이 스타트업을 시작했을지도 모른다), 사람들은 수평선 너머로 사라질지도 모를 기회를 잡기 위해 시류에 편승했다.

이런 현상에 나도 일부 책임이 있음을 인정한다. 2015년으로 거슬러 올라가자면, 당시 이 주제를 다루는 『마이크로서비스 아키텍처 구축』(원제 Building Microservices)이라는 책을 집필한 이후로 나는 마이크로서비스 아키텍처 유형을 이해하고자 하는 사람들을 도우며 함께 작업해왔다. 과장된 홍보 문구 사이에서 헤매는 기업들을 대상으로 마이크로서비스 도입이 적합한지 판단하는 작업을 돕고자 노력해왔다. (마이크로서비스 지향적이지 않은) 기존 시스템을 보유한 많은 고객들은 마이크로서비스 아키텍처를 채택하는 과정에서 도전에 직면했다. 다른 모든 작업을 중단하지 않고 기존 시스템의 아키텍처를 재구성하는 방법은 무엇일까? 이 문제가 바로 이 책이 해결하려는 주제다. 더 중요하게는, 이 책을 통해 마이크로서비스 아키텍처와 관련된 문제를 솔직하게 평가하고, 심지어 마이크로아키텍처로 향하는 여정의 시작이 각자에게 적합한지 이해하는 과정까지 돕고자 한다.


★옮긴이의 글★
쿠버네티스, 클라우드 네이티브, 마이크로서비스 아키텍처 등 최근 클라우드 생태계를 중심으로 개발과 운영을 포괄하는 첨단 기술에 대한 이야기가 여기저기서 들리고 있다. 물론, 간단한 개인 블로그 서비스를 만드는 학습 과정에서 복잡한 개발 기법을 적용해보기란 사실상 불가능하고, 분초를 다투는 MVP 서비스를 만드는 경우에는 그 무엇보다 비즈니스를 달성하기 위한 동작이 먼저이므로 확장 가능성과 안정성을 극대화하기 위한 복잡한 운영 기술을 처음부터 고려할 필요는 없어 보인다. 하지만 복잡하고 낯설다는 이유만으로 신기술에 대한 무조건적인 반대 입장을 펼치기 앞서, 이런 신기술들이 부지불식간에 우리의 일상에 스며들어 이미 어느 정도 자리를 잡고 있는지 확인할 필요가 있다.

여러 첨단 기술 중에서도 상위에 위치한 아키텍처 관점에서는 아무래도 마이크로서비스를 빼놓을 수가 없다. 마이크로서비스 이야기가 나올 때마다 단골 손님으로 등장하는 넷플릭스와 아마존을 제외하고 생각해봐도 월마트, 베스트바이, 쿠팡과 같은 대형 소매업종은 물론이고 우버나 배달의민족 같은 공유 플랫폼 서비스업종, 그리고 뱅크샐러드나 스포티파이 같은 일반 고객을 대상으로 하는 서비스업종에 이르기까지, 어느 정도 업계에서 자리를 잡은 회사라면 마이크로서비스를 직간접으로 고려하고 있거나 이미 도입했다. 마이크로서비스는 개발이나 운영 관점에서 복잡성을 떨어뜨리는 장점을 제공할 뿐만 아니라, 레거시를 클라우드로 전환하는 관점에서도 마이그레이션을 원활하게 만드는 특성이 있기 때문이다.

여기까지는 너무 뻔한 이야기처럼 들릴 것이다. 하지만, 최근에 의외의 곳에서 마이크로서비스를 적용한 사례를 목격했다. 기술적으로 상당히 앞서 있으면서도 보수적인 입장을 취하는 군사 부문에서 마이크로서비스를 채택했다면 믿어지겠는가? 그것도 최첨단 스텔스 폭격기에 말이다. 미 국방성 DSOP 프로그램 홈페이지에 들어가면 잘 정리된 아키텍처 다이어그램이 하나 등장한다(https://software.af.mil/dsop/ 참고).

이 다이어그램이 뜻하는 바는 명징하다. 군사용 소프트웨어와 관련해 애플리케이션 수명주기를 주에서 일 단위로, 개발 과정을 데브옵스로, 애플리케이션 아키텍처를 마이크로서비스로, 배포와 패키징을 컨테이너(도커와 쿠버네티스)로, 인프라스트럭처를 클라우드로 바꾸는 것이다.

2025년에 초기 배치될 B-21 스텔스 폭격기에는 폭격뿐만 아니라 전투 지휘와 정보 수집까지 포괄하는 다목적 임무가 부여될 예정이며, 이에 대응하기 위해 기능별로 서비스를 격리하고 필요에 따라 적재적소에 배포하는 마이크로서비스 아키텍처를 도입했다고 한다(https://www.theregister.com/2020/06/03/kubernetes_b_21_bomber/). 물론 실제 운영 과정에서 쿠버네티스를 사용한 컨테이너 관리는 기본이다. 군사 부문에서 할 수 있다면 민간 부문에서 하지 못할 이유가 있을까?

이렇듯 마이크로서비스는 급변하는 세계에 대응하기 위한 아키텍처로 주목을 받고 있다. 하지만 뭔가 단순하고 간단할 것 같은 이름에 속아서는 안 된다. 마이크로서비스의 ‘마이크로’가 실제로는 엄청난 엔지니어링과 도메인 지식을 요구한다는 사실을 알고 나면 허탈감을 느끼게 될 것이다. 전작 『마이크로서비스 아키텍처 구축』을 출간하며 마이크로서비스 전도사로 자리잡은 샘 뉴먼은 마이크로서비스에 대한 대중의 이해를 도우려 했던 자신의 시도가 세간의 사람들로 하여금 은총알로 여겨지는 마이크로서비스에 즉시 올라타야만 할 것 같은 시류에 편승하게 만들었다는 사실을 깨달았다. 따라서 좀 더 현실적인 문제에 접근함으로써, 마이크로서비스 아키텍처를 언제 어떤 경우에 도입해야 할지, 어떻게 해야 기존 레거시 시스템을 망가뜨리지 않고 점진적으로 마이그레이션할 수 있을지, 마이크로서비스 아키텍처에 감춰진 복잡한 문제점은 무엇인지 등을 솔직하게 드러내기 위해 이 책을 집필했다고 서문에서 고백한다. 아마도 마이크로서비스 아키텍처를 도입하려고 시도했거나 이미 도입한 많은 회사는 이 책에 언급된 다양한 상황에 직면했을 가능성이 매우 높으며, 앞으로 마이크로서비스를 검토하는 회사도 상황이 크게 다르지는 않을 것으로 본다.

개인적으로 이 책에서 가장 마음에 드는 부분은 3장 ‘모놀리스 분할’과 4장 ‘데이터베이스 분해’다. 3장은 레거시 시스템에서 출발해 마이크로서비스로 가는 여정 중에 참고할 내용을 시원하게 풀어낸다. 레거시 시스템을 완전히 버리고 마이크로서비스를 사용해 처음부터 다시 시작하면 성공 확률이 얼마나 될까? 이 책을 읽고 나면 기존 시스템에서 마이크로서비스로 옮기는 방식이 처음부터 마이크로서비스로 진행하는 방식에 비해 훨씬 위험성도 적고 효과도 좋다는 사실을 깨닫게 될 것이다. 이렇게 3장은 레거시에서 마이크로서비스로 마이그레이션할 때 도움을 주는 패턴을 체계적으로 정리한다. 4장은 마이크로서비스 아키텍처를 구성하는 사람들에게 가장 큰 고민거리를 안겨주는 데이터베이스를 집중적으로 다룬다. 마이크로서비스로 마이그레이션할 때 겪는 어려움은 클라우드로 데이터베이스를 마이그레이션할 때 겪는 어려움과 유사한 점이 많지만, 마이크로서비스에서는 단순한 샤딩을 넘어서 업무별로 데이터베이스를 분할해야 하므로 더 큰 장벽이 기다리고 있다.

이런 어려움으로 인해, 기껏 애플리케이션을 분해해놓고 데이터베이스는 공유해서 사용하는 경우가 얼마나 많은가! 그렇다고 죄책감을 느끼지는 말자. 이 책은 완벽한 마이크로서비스를 추구하는 대신 모듈식 모놀리스만으로도 좋은 성과를 올리는 사례도 보여주므로 정말 급진적인 마이크로서비스로 가야 할지 아니면 관리가 용이한 형태의 모놀리스로 남을지를 고민하는 분들께서도 읽어보시면 위안과 도움을 얻으리라고 생각한다. 아무쪼록 이 책이 마이크로서비스라는 강적을 앞에 두고 고민이 많은 개발자와 관리자들에게 오아시스가 되었으면 좋겠다.

작년에 우연치 않게 마이크로서비스로 다양한 프로젝트를 진행하는 여러 개발자분들과 기술적인 내용을 토론할 기회가 많았었는데, 이 책을 번역하면서 마이크로서비스를 채택하는 과정에서 발생하는 현업의 어려움을 이해하는 데 큰 도움이 되었다. 회의와 토론 과정에서 직간접으로 도움을 주신 여러 개발자분들께 지면을 빌려 감사의 말씀을 드린다.