실무자 관점에서 다룬 마이크로서비스 아키텍처(2판)

★ 이 책의 대상 독자 ★



마이크로서비스의 기본 원칙과 기술적 측면을 설명해, 다양한 독자에게 흥미를 제공할 것이다.



■ 개발자: 적합한 기술 스택을 선택할 수 있는 가이드라인을 제공하는 2부가 도움될 것이다. 예시로 제공되는 프로젝트는 기술의 기초를 배우는 토대 역할을 한다. 예시 프로젝트에 포함된 마이크로서비스는 스프링 프레임워크(Spring Framework)를 사용해 자바(Java)로 작성한다. 그러나 예시에 사용된 기술은 마이크로서비스를 통합한다. 따라서 추가적인 마이크로서비스는 다른 언어로 작성될 수 있다. 3부에서는 개발자가 앞으로 더욱 중요하게 생각하는 운영 주제를 포함했다. 1부에서는 아키텍처 개념의 기본 원리를 설명한다.



■ 아키텍트: 1부는 마이크로서비스에 대한 기본 지식을 제공한다. 마이크로서비스 아키텍처를 구현하기 위한 실제 레시피와 기술을 제시하는 2부와 3부가 도움될 것이다. 마이크로서비스에 대한 주제를 통해 아키텍트에 중점을 두지만 기술을 자세히 다루지 않는 점을 참고하길 바란다.



■ 데브옵스와 운영 전문가: 3부의 레시피는 로그 분석, 모니터링, 마이크로서비스 추적과 같은 운영 측면의 기술적 평가가 가능한 견고한 토대를 제공해 유익할 것이다. 2부에서는 도커, 쿠버네티스, 클라우드 파운드리와 같은 배포 기술을 소개하고 일부 운영상의 문제도 해결하는 방법을 소개한다. 1부에서는 마이크로서비스 아키텍처 접근 방법의 배경에 대해 설명한다.



■ 관리자: 마이크로서비스 아키텍처 접근법의 장점과 구체적인 문제점에 대한 개요를 부분적으로 설명한다. 기술적 세부 사항에 관심이 있다면 2부와 3부를 읽는 것이 좋다.



독자가 소프트웨어 아키텍처와 소프트웨어 개발에 대한 기본 지식이 있다고 가정한다. 이 책의 예시 대부분은 사전 지식 없이 실행할 수 있는 방법으로 문서화돼 있다. 그리고 다른 프로그래밍 언어를 사용하는 마이크로서비스에 사용할 수 있는 기술에 중점을 둔다. 그러나 예시는 스프링 부트와 스프링 클라우드 프레임워크를 사용해 자바로 작성됐다.



★ 이 책의 구성 ★



1부 - 아키텍처 기본 내용

1부에서는 마이크로서비스 기반 아키텍처의 기본 원리를 소개한다.

■ 1장에서는 마이크로서비스라는 용어를 정의한다.

■ 마이크로서비스 아키텍처는 마이크로(micro) 아키텍처와 매크로(macro) 아키텍처라는 두개의 레벨을 갖고 있다. 전역적인 결정과 지역적인 결정을 나타낸다. 2장에서는 이를 설명한다.

■ 때로는 레거시 시스템은 마이크로서비스로 마이그레이션(migration)돼야 한다. 3장에서 마이그레이션을 다룰 것이다.



2부 - 기술 스택

2부의 중점 내용은 기술 스택이다.

■ 도커는 많은 마이크로서비스 아키텍처의 기반 기술이다. 또한 소프트웨어 롤아웃(roll-out)과 서비스 운영을 용이하게 한다. 이는 4장에서 설명한다.

■ 5장은 마이크로서비스를 구현할 때 사용할 수 있는 기술을 설명한다.

■ 6장은 마이크로서비스를 위한 특히 유용한 접근법으로서 독립 시스템(SCS)을 설명한다. SCS는 UI뿐만 아니라 로직을 포함하는 마이크로서비스에 중점을 둔다.

■ SCS에서 통합을 통해 얻을 수 있는 가능성은 웹 프론트엔드의 통합이다. 프론트엔드 통합은 마이크로서비스 간의 결합도를 낮추고 고도의 유연성을 제공한다. 자세한 내용은 7장을 살펴보자.

■ 8장에서 소개할 웹 프론트엔드 통합 레시피는 다이내믹 콘텐츠 로딩에 대한 링크와 자바스크립트를 이용한다. 해당 통합 방법은 구현하기 쉽고 잘 설계된 웹 기술을 사용한다.

■ 서버는 ESI(Edge Side Includes)를 사용해 통합할 수 있다. ESI는 시스템이 고성능과 신뢰성을 달성할 수 있도록 웹 캐시에서 구현된다. 이는 9장에서 설명한다.

■ 비동기 통신 개념은 10장에서 다룬다. 비동기 통신은 안정성을 향상시키고 시스템의 결합도를 낮춘다.

■ 11장에서는 아파치 카프카(Apache Kafka)를 소개한다. 아파치 카프카는 메시지를 보내는 비동기 기술의 한 예다. 카프카는 메시지를 영구적으로 저장할 수 있고 비동기 처리에 대한 다양한 접근 방법을 제공한다.

■ 12장에서는 비동기 통신의 대안으로 Atom을 설명한다. Atom은 REST 인프라를 사용하고 구현과 운영이 매우 쉽다.

■ 13장에서는 동기 마이크로서비스의 개념을 구현하는 방법을 설명한다. 동기 통신 방법이 응답 시간과 신뢰성과 관련해 어려움을 제기할 수 있지만 마이크로서비스 간의 동기 통신이 실제로 사용되는 경우가 많다.

■ 14장에서 소개할 넷플릭스 스택(Netflix Stack)은 서비스 탐색이 가능한 유레카(Eureka)를 제공할 뿐만 아니라 로드 밸런싱을 위한 립본(Ribbon), 복원력을 위한 히스트릭스(Hystrix), 라우팅을 위한 주울(Zuul)을 제공한다. 넷플릭스 스택은 특히 자바 커뮤니티에서 널리 사용하고 있다.

■ 15장에서 소개할 컨설(Consul)은 서비스 탐색(Service Discovery) 대안 가운데 하나다. 컨설은 다양한 기능을 포함하고 있고 다양한 기술과 함께 사용할 수 있다.

■ 16장은 마이크로서비스의 운영과 통신을 지원하는 마이크로서비스 플랫폼 개념을 설명한다.

■ 17장에서 소개할 쿠버네티스는 도커 컨테이너를 실행할 수 있는 마이크로서비스 플랫폼이면서 서비스 탐색과 로드 밸런싱을 위한 솔루션도 제공한다. 마이크로서비스는 쿠버네티스와 독립적이다.

■ 18장의 PaaS(Platform as a Service)는 또 다른 마이크로서비스 플랫폼이다. 클라우드 파운드리(Cloud Foundry)를 예시로 들어 설명한다. 클라우드 파운드리는 매우 유연하며 퍼블릭 클라우드뿐만 아니라 회사 내부 컴퓨팅 센터에서도 실행할 수 있다.



3부 - 운영

굉장히 많은 마이크로서비스를 안전하게 운영하는 것은 큰 도전 과제다. 3부에서는 이 문제를 해결할 수 있는 방법을 논의한다.

■ 19장에서는 운영의 기본 원칙과 마이크로서비스 운영이 왜 어려운지 설명한다.

■ 20장에서는 모니터링을 다루고 프로메테우스(Prometheus) 툴을 소개한다. 프로메테우스는 다차원 데이터 구조를 지원하며 수많은 마이크로서비스 인스턴스의 메트릭을 분석할 수 있다.

■ 21장은 로그 데이터 분석에 중점을 둔다. 데이터 분석 툴로 일래스틱 스택을 설명한다. 일래스틱 스택은 매우 인기가 있으며 많은 양의 로그 데이터를 분석하기 위한 좋은 토대가 된다.

■ 22장에서는 추적 기술을 통해 마이크로서비스 간의 호출을 추적하는 집킨(Zipkin)을 사용한다. 집킨은 다양한 플랫폼을 지원하고 추적 분야에서 사실상 표준이다.

■ 서비스 메시 기술은 마이크로서비스 간의 네트워크 트래픽에 프록시를 추가한다. 프록시는 모니터링, 로그 분석, 추적, 기타 탄력성, 보안과 같은 기능을 지원한다. 23장에서는 서비스 메시의 예시로 이스티오(Istio)를 설명한다.



결론과 부록

마지막 장인 24장에서 마이크로서비스의 전망을 살펴본다.

부록 A에서는 소프트웨어 설치, 부록 B에서는 빌드 툴인 메이븐(Maven), 부록 C에서는 도커와 도커 컴포즈(Docker Compose)를 사용해 예시 환경을 실행하는 방법을 설명한다.



★ 옮긴이의 말 ★



저는 처음 근무했던 알티캐스트에서 셋톱박스 미들웨어 개발에 참여했습니다. 미들웨어는 운영체제 또는 하드웨어 벤더의 인터페이스를 연동하는 포팅 레이어, JVM, 애플리케이션 관리 레이어, 통신 레이어, 서비스 정보 관리 레이어 등 다양한 모듈을 하나의 바이너리로 생성한 다음 하드웨어 플래시 롬에 저장해 셋톱박스에 자바 애플리케이션을 돌아가도록 했습니다. 모놀리스(Monolith) 구조였고 모듈별 강한 응집도, 낮은 결합도를 목표로 하고 모듈별 담당자를 둬서 생산성을 높였습니다. 단점이라면 하나의 문제만으로도 전체적인 품질을 떨어뜨릴 수 있다는 것이었습니다.

이후에 근무하던 NHN 시절에는 네이버와 한게임 플랫폼을 각각 마이크로서비스 아키텍처(MSA)와 비슷한 상태로 실험 및 개발, 운영했습니다. 또한 쓰리프트(thrift)와 같은 자체 IDL을 서비스에 사용하기도 했습니다. 그리고 서비스마다 API 서버를 구축해 유기적인 결합 상태로 운영했습니다. 저도 여기에 동참해 동료들과 함께 공통 모듈을 개발하기도 했습니다.

하지만 너무 많은 서버 노드로 인해 패킷이 손실되기도 하고 어디서 문제가 생기는지 추적하는 것이 어려워졌습니다. 점차 인원이 줄어들면서 모듈 또는 서비스 운영이 힘들어졌고, 스프링을 적용한 모놀리스 아키텍처를 선호하기도 했습니다. 독립 시스템의 통신 비용, 비교적 낮은 성능, 복잡한 프로토콜, 이유를 알 수 없는 패킷 손실, 유지 보수 인력 등의 부족으로 더욱 모놀리스 아키텍처를 추구하게 됐습니다.

모놀리스 아키텍처에서 사용하는 언어는 하나이고 코드 저장소를 함께 사용합니다. 그래서 문제 파악이 쉽고 통신 비용이 거의 없습니다. 내부 모듈 간의 통신은 호출로 사용하고 외부 통신에만 프로토콜을 사용하니 간결하고 효율성이 높습니다. 따라서 문제 해결이 더욱 쉽기에 개발 인력이 적어도 운영할 수 있는 구조가 됩니다. 그러나 개발자의 자유도는 떨어지고 점차 높아지는 코드의 복잡성(모듈의 결합도가 느슨해짐)으로 인해 코드 유지 보수 시간과 배포 시간이 길어지는 단점이 있습니다.

요즘에는 SOA(Service Oriented Architecture), 애자일, DDD(Domain Driven Design), 함수형 언어의 부흥, 클라우드, 아파치 카프카, 폴리그랏(Polyglot), 데브옵스, 도커 기술(쿠버네티스, 이스티오)이 트렌드에 맞게 마이크로서비스 아키텍처가 다시 부흥하고 있습니다.

마이크로서비스 아키텍처의 단점을 이겨낼 수 있는 도커, 비동기 통신 기술, 서킷 브레이커, 추적, 서비스 탐색, 서비스 메시 등 수많은 기능들이 생기고 데브옵스 툴이 계속 오픈소스로 나오면서 개발과 운영이 쉬워지고 있습니다. 이제는 넷플릭스와 아마존처럼 복잡한 비즈니스를 마이크로서비스 아키텍처로 개발 및 운영하는 것이 성공 사례가 되고 있습니다.

한편 세그먼트사의 사례와 같이 마이크로서비스 아키텍처의 단점이 너무 많아 모놀리스 아키텍처로 되돌아간 사례도 있습니다(http://www.ciokorea.com/news/39258). 서비스가 너무 많아 어느 코드 저장소에 어느 프로젝트가 있는지 모르는 경우, 마이크로서비스에서 사용된 언어가 달라 동일한 코드를 각각 구현하다 보니 비슷한 코드들이 산재된 경우, 비슷한 코드를 라이브러리 버전 업을 할 때 관련된 많은 서비스의 라이브러리를 완벽하게 처리하지 못하는 경우 등 다양한 단점이 발생할 수 있습니다.

이 책을 번역하면서 소프트웨어의 본질에 대해 다시 돌아보게 됐습니다. 또한 모놀리스 아키텍처든 마이크로서비스 아키텍처든 모듈, 사람, 정책과 관련된 전략이 중요하다는 것을 알게 됐습니다. 모놀리스 아키텍처에서 마이크로서비스 아키텍처로 변경하려는 작업은 시스템 아키텍처를 완전히 바꾸기 때문에 신중할 필요가 있고 반드시 전략이 필요합니다. 이 책은 마이크로서비스에 대한 전략과 기술을 잘 설명하고 있습니다. 잘 들여다보면 각 개발 팀은 지방 분권 체제를 가진 국가처럼 지방자치단체장의 리더십으로서의 적절한 권한, 책임을 가집니다. 따라서 리더십을 전혀 생각하지 않고 마이크로서비스를 단순히 개발 팀이 원하는 언어를 사용해 마음대로 개발하는 것은 이 원칙에 맞지 않습니다. 국가 수장의 리더십을 존중하듯이 마이크로서비스 아키텍처에 대한 정책을 개발 팀이 존중하고 따라야 합니다.

이 책은 마이크로서비스 아키텍처와 다양한 기술만 나열하지 않습니다. 소프트웨어의 모듈이 무엇인지, 마이크로서비스 아키텍처에서 중요한 부분이 무엇인지 강조합니다. 그리고 스프링 프레임워크와 도커, 도커 컴포즈(docker compose) 기반의 예시로 위에 소개한 툴을 설명합니다.

이 책은 개발자, 아키텍트, 데브옵스, 관리자 모두에게 도움이 되는 좋은 책입니다. 역자가 최근에 사용해본 좋은 기술과 고민을 이 책에서 잘 소개하고 있으니 많은 도움이 될 것입니다.

0장. 소개



0.1 이 책의 구성

0.2 이 책의 대상 독자

0.3 사전 지식

0.4 빠른 시작

0.5 감사의 말

0.6 웹사이트



1장. 마이크로서비스



1.1 마이크로서비스: 정의

1.2 마이크로서비스를 사용하는 이유

1.3 도전 과제

1.4 변형

1.5 결론



2장. 마이크로 아키텍처와 매크로 아키텍처



2.1 바운디드 컨텍스트와 전략적 설계

2.2 기술적 마이크로와 매크로 아키텍처

2.3 운영: 마이크로 아키텍처 또는 매크로 아키텍처

2.4 마이크로 아키텍처를 선호한다!

2.5 조직 측면

2.6 독립 시스템 아키텍처 원칙

2.7 변형

2.7 결론



3장. 마이그레이션



3.1 마이그레이션을 수행하는 이유

3.2 일반적인 마이그레이션 전략

3.3 대안 전략

3.4 빌드, 운영, 조직

3.5 변형

3.6 결론



4장. 도커



4.1 마이크로서비스에서 도커를 사용하는 이유

4.2 도커 기본 내용

4.3 도커 설치와 도커 커맨드

4.4 도커 머신으로 도커 호스트 설치

4.5 도커파일

4.6 도커 컴포즈

4.7 변형

4.8 결론



5장. 기술 관점의 마이크로 아키텍처



5.1 요구 사항

5.2 리액티브

5.3 스프링 부트

5.4 Go

5.5 변형

5.6 결론



6장. 독립 시스템



6.1 독립 시스템에 대한 근거

6.2 정의

6.3 예제

6.4 SCS와 마이크로서비스

6.5 도전 과제

6.6 장점

6.7 변형

6.8 결론



7장. 개념: 프론트엔드 통합



7.1 프론트엔드: 모놀리스 또는 모듈화

7.2 옵션

7.3 자원 지향 클라이언트 아키텍처

7.4 도전

7.5 장점

7.6 변형

7.7 결론



8장. 레시피: 링크와 클라이언트 통합하기



8.1 개요

8.2 예시

8.3 변형

8.4 실험

8.5 결론



9장. 레시피: ESI를 사용한 서버 측 통합



9.1 ESI: 개념

9.2 예시

9.3 바니시

9.4 레시피 변형

9.5 실험

9.6 결론



10장. 개념: 비동기 마이크로서비스



10.1 정의

10.2 이벤트

10.3 도전 과제

10.4 장점

10.5 변형

10.6 결론



11장. 레시피: 메시징과 카프카



11.1 메시지 지향 미들웨어

11.2 카프카의 아키텍처

11.3 카프카 이벤트

11.4 예시

11.5 레시피 변형

11.6 실험

11.7 결론



12장. 레시피: Atom 및 REST로 비동기 통신



12.1 Atom 포맷

12.2 예시

12.3 레시피 변형

12.4 실험

12.5 결론



13장. 개념: 동기 마이크로서비스



13.1 정의

13.2 장점

13.3 도전 과제

13.4 변형

13.5 결론



14장. 레시피: 넷플릭스 스택 기반의 REST



14.1 예시

14.2 유레카: 서비스 탐색

14.3 라우터: 주울

14.4 로드 밸런싱: 립본

14.5 복원력: 히스트릭스

14.6 레시피 변형

14.7 실험

14.8 결론



15장. 레시피: 컨설을 이용한 REST와 아파치 httpd 서버



15.1 예시

15.2 서비스 탐색: 컨설

15.3 라우팅: 아파치 httpd 서버

15.4 컨설 템플릿

15.5 컨설과 스프링 부트

15.6 DNS와 레지스트레이터

15.7 레시피 변형

15.8 실험

15.9 결론



16장. 개념: 마이크로서비스 플랫폼



16.1 정의

16.2 변형

16.3 결론



17장. 레시피: 쿠버네티스와 도커 컨테이너



17.1 쿠버네티스

17.2 쿠버네티스 예시

17.3 세부 예시

17.4 쿠버네티스의 추가 기능

17.5 레시피 변형

17.6 변형

17.7 결론



18장. 레시피: 클라우드 파운드리의 PaaS



18.1 PaaS: 정의

18.2 클라우드 파운드리

18.3 클라우드 파운드리 예시

18.4 레시피 변형

18.5 실험

18.6 서버리스

18.7 결론



19장. 개념: 운영



19.1 운영이 중요한 이유

19.2 마이크로서비스 운영을 위한 접근 방법

19.3 살펴본 기술의 효과

19.4 결론



20장. 레시피: 프로메테우스를 이용한 모니터링



20.1 기본 내용

20.2 마이크로서비스의 메트릭

20.3 프로메테우스 통계

20.4 프로메테우스 예시

20.5 레시피 변형

20.6 실험

20.7 결론



21장. 레시피: 일래스틱 스택을 활용한 로그 분석



21.1 기본 내용

21.2 일래스틱 스택을 사용해 로그 저장하기

21.3 예시

21.4 레시피 변형

21.5 실험

21.6 결론



22장. 레시피: 집킨으로 추적하기



22.1 기본 사항

22.2 집킨으로 추적하기

22.3 예시

22.4 레시피 변형

22.5 결론



23장. 레시피: 서비스 메시, 이스티오



23.1 서비스 메시란?

23.2 예시

23.3 이스티오의 동작 방식

23.4 프로메테우스와 그라파나로 모니터링하기

23.5 재거로 추적하기

23.6 로깅

23.7 복원력

23.8 도전 사항

23.9 장점

23.10 변형

23.11 실험

23.12 결론



24장. 정리



부록 A. 환경 설치

부록 B. 메이븐 커맨드

부록 C. 도커와 도커 컴포즈 커맨드

에버하르트 볼프 아키텍트와 컨설턴트로서 15년 이상의 경력을 쌓았다. 비즈니스와 기술의 교차점을 고민하는 독일 INNOQ의 연구원이다. 국제 콘퍼런스에서 발표했으며 강연자로서 저자로서 마이크로서비스와 지속적 배포와 관련된 100개 이상의 기사와 책을 저술했다. 최신 아키텍처 즉, 클라우드, 지속적 배포, 데브옵스, 마이크로서비스에 관심을 두고 있다.