1장. 마이크로서비스<br/><br/>__마이크로서비스란?<br/>__자율 서비스<br/>__소규모 서비스<br/>__마이크로서비스의 이점<br/>____독립적인 배포<br/>____지속적인 혁신<br/>____확장과 리소스 활용의 개선<br/>____기술 다양성<br/>____소규모 팀<br/>____오류 격리<br/>__도전<br/>____복잡성<br/>____네트워크 혼잡 및 대기시간<br/>____데이터 일관성<br/>____테스트<br/>____통합과 버전 관리<br/>____서비스 검색과 라우팅<br/>____모니터링과 로깅<br/>____기량과 경험<br/>____가동시간 서비스 수준 계약(SLA)<br/>__모범 사례<br/>____캡슐화<br/>____데브옵스 원칙과 문화<br/>____자동화<br/>____모니터링<br/>____결함 허용<br/>__요약<br/><br/><br/>2장. Azure의 컨테이너<br/><br/>__VM과 컨테이너, 프로세스<br/>____가상 머신이나 프로세스에서 컨테이너를 사용하는 시기<br/>__Azure의 컨테이너<br/>__도커가 있는 Azure VM 만들기<br/>____Windows에서 SSH 공개 키 생성<br/>____Mac OS X에서 SSH 공개 키 생성<br/>____가상 머신 이미지 선택<br/>____Windows에서 SSH와 Git Bash를 사용해 VM 연결하기<br/>____Mac OS X에서 SSH와 Git Bash를 사용해 VM 연결하기<br/>____도커 컨테이너 기초<br/>__요약<br/><br/><br/>3장. 애플리케이션 설계<br/><br/>__어디서 시작할지 결정하기<br/>____코스 그레인드 서비스<br/>____마이크로서비스로 시작하기<br/>__서비스와 인터페이스 정의<br/>____애플리케이션 분해<br/>____서비스 설계<br/>__서비스 vs. 서비스 통신<br/>____동기 요청/응답<br/>____비동기 메시징<br/>__모놀리스에서 마이크로서비스로<br/>__Flak.io 전자상거래 샘플<br/>____Flak.io<br/>____요구사항<br/>____아키텍처 개요<br/>____고려사항<br/>__요약<br/><br/><br/>4장. 개발 환경 설정<br/><br/>__로컬 개발을 위한 도커 사용하기<br/>____로컬 개발용 도커<br/>____운영 유효성 검증을 위한 도커<br/>____빌드/테스트 호스트로서 도커<br/>__개발자 구성<br/>____로컬 개발<br/>____로컬 및 클라우드<br/>____클라우드 전용<br/>____도커 인증 관리<br/>____기본 이미지 선택<br/>____이미지의 계층구조 만들기<br/>__로컬 개발 환경 설정<br/>____도커 도구 설치<br/>____개발자 도구 설치<br/>____Windows 유틸리티 설치<br/>____OS X 유틸리티 설치<br/>__로컬 개발을 위한 도커<br/>____로컬 개발 설정<br/>____로컬 도커 호스트 시작<br/>____도커 호스트에 연결하기<br/>____샘플 복제하기<br/>____도커 컨테이너에서 라이브 리로드 사용하기<br/>____볼륨<br/>____운영 환경을 위한 마이크로서비스 준비<br/>____도커 컴포즈<br/>__도커 문제 디버깅<br/>____도커 호스트에 연결할 수 없다.<br/>____컨테이너가 시작되지 않는다.<br/>____컨테이너 실행 진단하기<br/>__요약<br/><br/><br/>5장. 서비스 오케스트레이션과 연결<br/><br/>__오케스트레이션<br/>__프로비저닝<br/>____코드로서의 인프라<br/>____Azure 리소스 관리자<br/>____Azure 컨테이너 서비스<br/>____ACS 리소스 공급자<br/>____멀티벤터 프로비저닝<br/>__스케줄링과 클러스터 관리<br/>____문제점<br/>____스케줄링 솔루션<br/>____도커 스웜<br/>____큐버네티스<br/>____아파치 메소스<br/>____아파치 메소스를 사용한 다양한 작업 부하 실행<br/>__서비스 검색<br/>____서비스 등록<br/>____서비스 조회<br/>____서비스 레지스트리<br/>____다양한 기술<br/>____기타 기술<br/>____애플리케이션/API 게이트웨이<br/>____오버레이 네트워킹<br/>__요약<br/><br/><br/>6장. 데브옵스와 지속적인 업데이트<br/><br/>__데브옵스 개요<br/>____현대의 데브옵스<br/>____데브옵스 문화<br/>____연속 통합과 지속적인 전달, 연속 배포<br/>____Azure에서 환경 만들기<br/>__지속적인 업데이트를 사용한 마이크로서비스 배포<br/>____서로 다른 환경에서의 애플리케이션 구성 변경<br/>____연속 통합<br/>____QA 환경의 테스트<br/>____스테이징 배포<br/>____운영 환경의 테스트<br/>__지속적인 업데이트 도구 선택<br/>____온프레미스 또는 호스팅?<br/>____최고의 솔루션 또는 통합 솔루션?<br/>____도구에서 필요한 확장을 제공하는가?<br/>____젠킨스와 팀 서비스, 뱀부, Tutum의 비교<br/>____도커 클라우드(이전엔 Tutum)<br/>__요약<br/><br/><br/>7장. 모니터링<br/><br/>__호스트 머신 모니터링<br/>__컨테이너 모니터링<br/>____모니터링 서비스<br/>__모니터링 솔루션<br/>____Azure 진단<br/>____Application Insights<br/>____OMS<br/>____도커의 권장 솔루션<br/>__요약<br/><br/><br/>8장. Azure 서비스 패브릭<br/><br/>__서비스 패브릭 개요<br/>____서비스 패브릭 하위시스템<br/>____클러스터 관리<br/>__리소스 스케줄링<br/>____서비스 패브릭 애플리케이션<br/>____사용자 지정 애플리케이션(기존 애플리케이션)<br/>____컨테이너 통합<br/>__서비스 검색<br/>__프로그래밍 모델<br/>____상태 비저장 서비스<br/>____상태 저장 서비스<br/>____신뢰할 수 있는 액터(Reliable Actors)<br/>____신뢰할 수 있는 서비스(Reliable Services)<br/>__애플리케이션 수명주기<br/>____서비스 업데이트<br/>____애플리케이션 업그레이드<br/>____테스트 용이성 프레임워크<br/>__요약<br/><br/>부록. ASP.NET Core 1.0과 마이크로서비스<br/><br/>__ASP.NET의 새로운 버전<br/>____시작하기<br/>____알맞은 ASP.NET 도커 이미지 선택하기<br/>____Visual Studio 2015 도구<br/>____ASP.NET 마이크로서비스 모범 사례

★ 이 책에서 다루는 내용 ★

■ 마이크로서비스 아키텍처의 차이점과 사용 시기
■ 마이크로서비스 아키텍처의 맥락에서 도커 컨테이너 이해
■ 도커 이미지 구축과 가져오기, 계층화 시키기
■ 도커 볼륨과 컨테이너, 이미지, 태그, 로그 다루기
■ 도커 스웜과 도커 컴포즈, 도커 네트워크 사용
■ Azure 포털과 Azure 리소스 관리자, 명령줄, docker-machine, 도커 툴박스를 통한 로컬 도커 호스트 만들기
■ 마이크로서비스 애플리케이션을 지원하는 개발과 데브옵스 환경 구축
■ 도커의 지속적인 업데이트 옵션 활용
■ Azure의 클러스터와 컨테이너 오케스트레이션 기능을 사용해 최대한의 복원력으로 컨테이너 기반 마이크로서비스 애플리케이션 운영과 확장
■ Azure 진단과 Visual Studio Application Insights, Microsoft Operations Management Suite를 사용한 마이크로서비스 애플리케이션 모니터링
■ Azure 서비스 패브릭으로 마이크로서비스 애플리케이션을 빠르고 효과적으로 개발하기


★ 이 책의 대상 독자 ★

Azure에서 마이크로서비스 기반 애플리케이션을 만드는 데 흥미를 가진 사람들을 대상으로 한다. 이 책을 읽은 후 마이크로서비스 기반 애플리케이션의 이점과 도전에 관한 견고한 이해를 갖게 될 것이다.


★ 지은이의 말 ★

우리 세 사람은 2009년 Microsoft Azure 클라우드 플랫폼이 시장에 처음 등장한 이후로 여기서 작업해왔다. 이 플랫폼을 사용한 공동 작업은 플랫폼을 만들고 플랫폼에서 애플리케이션을 만드는 것부터 Azure 개발 도구를 만들고 경험하는 것까지 꽤 광범위했다. 게다가 많은 고객과 파트너들이 Microsoft Azure에서 대규모 클라우드 기반 애플리케이션을 만들 수 있도록 지원했다. 지난 몇 년 동안 복원력과 확장성 있는 애플리케이션 설계부터 데브옵스 모범 사례, 고객과의 상호작용에서 Azure 플랫폼 기능과 Azure 도구, 기술 문서에 이르기까지 많은 교훈을 적용할 수 있었다.
하지만 몇 가지 질문과 문제가 계속해서 뒤따랐다. 예를 들자면 이런 질문이다. 개발 머신에서 돌아가는 것이 클라우드 환경에서도 돌아갈 것이라고 어떻게 보장할 수 있을까? 한 구성 요소에 대한 사소한 변경이 있는 경우 전체를 업데이트하지 않도록 애플리케이션 구조를 어떻게 짜야 할까? 다운타임 없이 가능한 빨리 업데이트를 배포하는 방법이 뭘까? 구성과 환경 변경은 어떻게 다뤄야 할까?
2013년에 이러한 도전을 다루며 아키텍처적 접근 방식으로 마이크로서비스를 사용하는 넷플릭스와 아마존, 다른 사업체에 관해 많은 업계 리더, 고객과 얘기하기 시작했다. 성공적인 아키텍처들(내부 및 외부 고객)과 하나씩 비교했고 그들이 이미 마이크로서비스 패턴의 많은 특성을 구현했다는 것을 알았다. 예를 들어 작업량을 기준으로 한 클라우드 서비스 애플리케이션 설계나 애플리케이션을 개별 컴포넌트/서비스의 수명을 갖는 다수의 서비스로 분해하는 것 등이다. 분명히 아키텍처는 이러한 방향으로 진화하고 있었고, ‘마이크로서비스’라는 용어가 대중화 됐을 때 많은 아키텍트와 개발자는 자신들이 이 방향으로 향하고 있음을 알았다.
도커(Docker)로 들어가 보자. 도커는 배포에 따른 부하와 하나의 서비스를 하나의 호스트에 배치하는 비용을 줄인다. 배포 부하가 줄어들면 마이크로서비스 아키텍처에서 늘어나는 공통 서비스의 배포를 관리하고 폴리글랏(polyglot) 환경에서 배포 메커니즘을 표준화하는 데 도움을 준다. 컨테이너와 함께 클라우드 환경에서 제공하는 프로그래밍 인프라는 마이크로서비스 아키텍처로 가는 길을 깔았다.
그러나 알맞은 아키텍처 접근 방식과 도구가 방정식의 절반이고, 개발/테스트 환경 구성과 데브옵스 플로우 자동화, 가상 머신들에서 도커 컨테이너를 지휘하고 계획하는 방법과 다른 서비스에서 마이크로서비스를 발견하는 방법, 해당 환경과 서비스를 모니터링하는 방법에 관한 개념적 사고가 나머지 절반을 이룬다.
우리는 최근 2년 동안 도커를 위한 Visual Studio 도구 세팅 엔지니어링 팀과 Azure 서비스 패브릭 컴퓨트(Service Fabric Compute) 엔지니어링 팀 양쪽에서 마이크로서비스와 도커 시나리오를 다루거나 다른 고객들과 작업했다.
어렵게 배운 교훈을 공유하고 Azure에서 도커를 사용해 마이크로서비스를 만드는 데 필요한 도구를 제공하고자 한다.

★ 옮긴이의 말 ★

컨테이너 가상화 환경에서 애플리케이션을 관리하고 실행하기 위한 오픈소스 플랫폼으로 등장한 도커는 단시간에 붐을 일으켰다. 특히 이상은 높았으나 실현이 힘들었던 SOA 사상의 참담한 실패 이후 도커는 마이크로서비스 아키텍처를 뒷받침 해주는 역할로서 늘어나는 공통 서비스의 배포 관리를 단순화해주고 다양한 환경에서 배포 메커니즘의 표준화를 이끌었다.

클라우드 기술의 발전과 관련 산업의 성장과 함께 기존의 컨테이너 기술이 재조명되고 프로그래밍 가능한 인프라가 실현됨에 따라 마이크로서비스 아키텍처로 가는 많은 장애물이 제거됐다. 이 책은 클라우드 서비스, 그 중에서도 Microsoft Azure에서 도커를 활용해 마이크로서비스를 구현하는 기술과 환경, 도구에 초점을 맞췄다. Azure 위에서 마이크로서비스를 구현해보고 싶어 하는 독자들이 궁금해 할 만한 대부분의 내용을 다루고 있다. 마이크로서비스를 구현하기 위해 어디서 시작해야 할지, 어디로 가야 할지, 걸림돌이 무엇인지 궁금하다면, 이 책에서 그 답을 얻을 수 있으리라 생각한다.

Azure와 도커의 세계는 변화가 빠르기 때문에 원서를 받고 가능한 빨리 번역을 진행했지만, 번역 기간 중에 Azure의 변화가 있었고, 관련 도구들의 변화도 있었다. 물론 이 책에서는 그런 변화를 반영했지만 시간이 흐르면 이 책에서 언급한 도구나 Azure의 모습은 바뀔 수 있다. 그렇더라도 기본 사상과 큰 그림, 구현 요소 등은 변하지 않으니 꽤 오랫동안 참고할 만한 책으로 남기를 기대한다.

2017년 5월
독립 IT 기술자, 김도균

지난 2년 동안 Azure는 단순한 .NET 기반 플랫폼에서 개방형 유연한 플랫폼으로 진화해 광범위한 운영 체제와 프로그래밍 언어, 프레임워크, 도구, IaaSinfrastructure-as-aservice용 데이터베이스와 장치, PaaSplatform-as-a-service, SaaSsoftware-as-a-service 워크로드를 지원하고 있다. Azure는 기존 고객과 신규 고객 모두를 대상으로 놀라운 성장율을 보이고 있다.
오늘날 대규모 컴퓨트 리소스에서 개발/테스트, SaaS 솔루션에 이르기까지 어떤 형태로든 클라우드의 사용을 고려하지 않는 산업은 없다. 유연성과 민첩성이 IT와 개발자가 Azure를 적용하는 첫 번째 이유다. Azure를 채택하는 고객의 전형적인 패턴은 개발/테스트 시나리오로 시작해서 기존 애플리케이션을 IaaS 기반 하이브리드 시나리오로 이동하고, 궁극적으로 클라우드 플랫폼을 최대한 활용하는 새로운 애플리케이션을 개발하는 것이다.
이제 Azure 클라우드 인프라는 거의 모든 시나리오를 수용하는 유연성을 제공한다. 따라서 고객은 애플리케이션 설계가 제한 요인임을 깨달았다. 많은 고객은 여전히 개별 애플리케이션 구성 요소를 독립적으로 업데이트, 버전 관리, 배포, 확장하기 어렵게 만든 모놀리식 애플리케이션을 설계하고 있다. 따라서 클라우드가 민첩하고 유연함에도 불구하고 애플리케이션 자체는 시장 동향과 고객 요구에 신속하게 대응하는 데 필요한 민첩성을 제공하지 못하고 있다.
지난 몇 달 동안 마이크로서비스 기반 애플리케이션은 이전에 불가능했던 민첩성과 관리 편리성을 가능케 하는 새로운 아키텍처 설계로 가장 많이 언급됐다. 도커 컨테이너는 밀도와 데브옵스, 개방형 기술 관점에서 마이크로서비스 기반 애플리케이션을 가능하게 하는 완벽한 기술로 존재감을 드러냈다. 도커와 결합한 마이크로서비스 기반 애플리케이션은 클라우드의 최신 애플리케이션 개발 판도를 크게 바꿔 놓을 것이다.
Azure에서 기반 기술과 고급 서비스를 제공해 다양한 유형의 마이크로서비스 기반 애플리케이션을 지원한다는 사실은 나를 흥분시킨다. Marathon/Chronos/Swarm과 함께 Apache Mesos에서 도커 컨테이너를 사용해 애플리케이션을 빌드하거나 자체 네이티브 마이크로서비스 애플리케이션 플랫폼인 서비스 패브릭에서 애플리케이션을 빌드할 수 있다. Azure에서는 시나리오에 맞는 적합한 선택지를 제공한다.
이제 막 컨테이너나 마이크로서비스에 발을 들였거나, 이미 이 주제를 다뤄봤거나에 상관없이 Azure에서 컨테이너 기반 마이크로서비스 애플리케이션을 만드는 방법을 이해하는 데 도움을 줄 것이다. 기본적인 내용에 대한 설명 외에도 마이크로서비스 개발자는 아키텍트가 알아야 하는 모범 사례를 파고든다.
저자들은 기본 주제와 고급 주제 모두를 아우르는 최고의 전문가다. 이들은 이러한 모델을 사용해 애플리케이션을 구축한 깊이 있는 실세계 경험을 갖췄으며, Azure와 클라우드에 관한 놀라운 제품 통찰력을 보유하고 있다. 이 책에서 제공하는 기술을 사용해 여러분이 만들어 낼 것을 기대하고 있겠다.

코리 샌더스 (Partner Director of Program Management)