인터넷서점 인터파크도서

모놀리스로 남을 것인가? 마이크로서비스로 진화할 것인가! 23가지 마이크로서비스 마이그레이션 패턴과 수많은 현장 사례를 통해 알아보는, 서두르지 않고 차근차근 모놀리스를 떠나기 위한 마이크로서비스 마이그레이션과 도입에 관한 모든 것! 어떻게 하면 모놀리스 시스템의 엉킴을 풀고 마이크로서비스 아키텍처로 무사히 마이그레이션할 수 있을까? 어떻게 하면 비즈니스를 평상시처럼 운영하면서 안정적으로 마이그레이션할 수 있을까? 이 책은 기존 모놀리스 시스템에서 마이크로서비스 아키텍처로 전환하기 위한 증명된 기법을 상세히 설명한다. 수많은 실제 사례, 통찰력 있는 23가지 마이크로서비스 마이그레이션 패턴, 모놀리스에서 출발해 마이크로서비스 플랫폼으로 전환하기 위한 현실적인 조언 등을 담았으며, 초기 계획부터 애플리케이션과 데이터베이스 분해 과정까지 시종일관 성공적인 마이크로서비스 도입과 마이그레이션을 위한 여러 시나리오와 전략을 소개한다. 이 책에서 여러분은 기존 아키텍처를 마이그레이션하기 위한, 다수의 검증된 패턴과 기법을 배울 수 있다.

| 이 책에서 다루는 내용 | ■ 재구축 대신 마이크로서비스 마이그레이션을 고려하는 조직을 위한 이상적인 해결책 ■ 기업이 마이크로서비스 도입에 관한 의사결정을 내리고 마이그레이션 시점을 판단하는 과정에 대한 절차와 조언 ■ 커뮤니케이션, 통합, 레거시 시스템 마이그레이션 방법 ■ 다양한 마이그레이션의 패턴과 적용 대상 ■ 데이터베이스 동기화 전략을 중심으로 보는 데이터베이스 마이그레이션 사례 ■ 다양한 아키텍처적인 리팩터링 패턴을 비롯한 애플리케이션 분해 ■ 참조 무결성과 트랜잭션 무결성을 망가뜨릴 경우에 발생하는 영향력과 새로운 실패 모드를 비롯한, 데이터베이스 분해와 관련된 세부사항 | 이 책의 구성 | 이 책에서는 기존 시스템을 마이크로서비스 아키텍처로 분해하는 과정에서 어떻게 생각하고 실행할지에 대한 내용을 철저히 분석했다. 우리는 마이크로서비스 아키텍처와 관련된 많은 주제를 살펴볼 것이지만, 초점은 서비스의 분해 측면에 있다. 마이크로서비스 아키텍처에 대한 개괄을 알고 싶다면 나의 전작 『마이크로서비스 아키텍처 구축』 책으로 시작하기 바란다. 실은, 두 책을 함께 읽기를 강력하게 권장한다. 1장 ‘더도 덜도 아닌 딱 마이크로서비스’에는 마이크로서비스가 무엇인지에 대한 개요를 담았으며, 마이크로서비스 아키텍처로 이끈 사상을 자세히 살펴본다. 마이크로서비스를 처음 접하는 사람들이야 꼭 챙겨 읽어야 하지만, 경험이 풍부한 사람들도 1장은 건너뛰지 말기 바란다. 기술의 혼란 속에서, 마이크로서비스의 중요한 핵심 사상이 간혹 간과되는 경우가 있다. 바로 이런 개념을 이 책에서 거듭해서 다룰 것이다. 마이크로서비스를 좀 더 제대로 이해하면 좋으나, 마이크로서비스가 여러분에게 적합한지를 파악하는 것은 전혀 다른 문제다. 2장 ‘마이그레이션 계획하기’에서는 마이크로서비스가 자신에게 적합한지 여부를 평가하는 방법을 알려주며, 모놀리스에서 마이크로서비스 아키텍처로 전환 과정을 관리하는 방법에 대한 매우 중요한 몇 가지 지침을 제공한다. 여기서는 도메인 주도 설계부터 조직 변경 모델에 이르기까지, 심지어 마이크로서비스 아키텍처를 채택하지 않는 경우에도 큰 도움이 되는 중요한 토대를 다룰 것이다. 3장 ‘모놀리스 분할’과 4장 ‘데이터베이스 분해’에서는 모놀리스 분해, 실제 예제 탐색, 마이그레이션 패턴 추출 등과 관련된 기술적 측면을 철저하고 상세하게 살펴본다. 3장에서는 애플리케이션 분해 측면을 집중해서 다루고, 4장에서는 데이터 문제를 매우 상세하게 설명한다. 정말로 모놀리스 시스템에서 마이크로서비스 아키텍처로 이동하기를 원하면, 데이터베이스 일부를 분리해야 할 것이다! 5장 ‘마이크로서비스 도입 과정에서 직면하는 문제와 해법‘에서는 마이크로서비스 아키텍처가 성장함에 따라 여러분이 직면할 문제를 몇 가지 살펴본다. 마이크로서비스 시스템은 장점도 많지만, 이전에는 겪어보지 못한 많은 복잡성과 문제도 따라온다. 5장에서는 마이크로서비스와 관련된 문제가 발생할 때 문제를 발견하는데 도움이 되는 방법, 그리고 마이크로서비스와 관련해 점점 커지는 난관을 해소할 방법을 제공한다. 마지막으로, 한국어판 특별 부록 ‘기술의 진화로 짚어보는 마이크로서비스 도입의 허와 실’을 수록해 목표나 결과가 아닌, 여정으로서 바라보는 마이크로서비스에 관한 통찰을 담았다. | 이 책의 독자 대상 | ■ 마이크로서비스의 전반적인 개념을 이해하고자 하는 분 ■ 모놀리스에서 마이크로서비스 아키텍처로 전환 과정을 알고싶은 분 ■ 모놀리스 분해...

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

[옮긴이의 글] 쿠버네티스, 클라우드 네이티브, 마이크로서비스 아키텍처 등 최근 클라우드 생태계를 중심으로 개발과 운영을 포괄하는 첨단 기술에 대한 이야기가 여기저기서 들리고 있다. 물론, 간단한 개인 블로그 서비스를 만드는 학습 과정에서 복잡한 개발 기법을 적용해보기란 사실상 불가능하고, 분초를 다투는 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장은 마이크로서비스 아키텍처를 구성하는 사람들에게 가장 큰 고민거리를 안겨주는 데이터베이스를 집중적으로 다룬다. 마이크로서비스로 마이그레이션할 때 겪는 어려움은 클라우드로 데이터베이스를 마이그레이션할 때 겪는 어려움과 유사한 점이 많지만, 마이크로서비스에서는 단순한 샤딩을 넘어서 업무별로 데이터베이스를 분할해야 하므로 더 큰 장벽이 기다리고 있다. 이런 어려움으로 인해, 기껏 애플리케이션을 분해해놓고 데이터베이스는 공유해서 사용하는 경우가 얼마나 많은가! 그렇다고 죄책감을 느끼지는 말자. 이 책은 완벽한 마이크로서비스를 추구하는 대신 모듈식 모놀리스만으로도 좋은 성과를 올리는 사례도 보여주므로 정말 급진적인 마이크로서비스로 가야 할지 아니면 관리가 용이한 형태의 모놀리스로 남을지를 고민하는 분들께서도 읽어보시면 위안과 도움을 얻으리라고 생각한다. 아무쪼록 이 책이 마이크로서비스라는 강적을 앞에 두고 고민이 많은 개발자와 관리자들에게 오아시스가 되었으면 좋겠다. 작년에 우연치 않게 마이크로서비스로 다양한 프로젝트를 진행하는 여러 개발자분들과 기술적인 내용을 토론할 기회가 많았었는데, 이 책을 번역하면서 마이크로서비스를 채택하는 과정에서 발생하는 현업의 어려움을 이해하는 데 큰 도움이 되었다. 회의와 토론 과정에서 직간접으로 도움을 주신 여러 개발자분들께 지면을 빌려 감사의 말씀을 드린다.

샘 뉴먼 [저]

샘 뉴먼(Sam Newman)은 소트웍스 사에서 고객사의 사내 시스템을 설계하는 아키텍트로 일하고 있다. 여러 나라 여러 분야의 회사들과 협업하며 개발과 IT 운영 영역을 넘나들어 왔다. 그에게 어떤 일을 하는지 묻는다면 ‘사람들과 함께 더 나은 소프트웨어 시스템을 만드는 일을 합니다’라고 답할 것이다. 샘은 기사를 쓰고, 컨퍼런스에서 발표하며, 가끔 오픈 소스 프로젝트에 커밋하고 있다.

박재호 [저]

포항공과대학교 컴퓨터공학과 학부와 대학원을 졸업했다. 임베디드 시스템 개발, 기업용 백업 소프트웨어 개발, 방송국 콘텐츠 수신 제한 시스템 개발과 운영 지원, 클라우드에서 동작하는 서비스 개발에 이르기까지 다양한 실무 경험을 토대로 고성능 고가용성 시스템을 설계한다. 코스닥 상장사 엑셈 CTO로 인공지능과 스마트팩토리 관련 개발을 총괄했으며, 전 아이콘(ICON) 치프 아키텍트로 퍼블릭 블록체인 개발과 운영에 대한 경험이 풍부하다. 집필과 번역한 책이 40여 권에 이른다. 최근에는 유튜브 채널(https://www.youtube.com/c/박재호dev)을 열고 개발자를 위한 다양한 지식을 전달하고 있다.