Azure에서 마이크로서비스 기반 애플리케이션을 만드는 데 흥미를 가진 사람들을 대상으로 한다. 이 책을 통해 마이크로서비스 기반 애플리케이션의 이점과 도전, 모범 사례에 관한 저자의 실전 경험과 지식을 배울 수 있다. 특히 Azure에서 마이크로서비스 기반 애플리케이션을 만들거나 기존의 레거시 애플리케이션을 해체하고 다시 마이크로서비스로 구축하는 데 필요한 핵심 지식을 얻을 수 있다.

[목 차]

1장. 마이크로서비스

__마이크로서비스란?
__자율 서비스
__소규모 서비스
__마이크로서비스의 이점
____독립적인 배포
____지속적인 혁신
____확장과 리소스 활용의 개선
____기술 다양성
____소규모 팀
____오류 격리
__도전
____복잡성
____네트워크 혼잡 및 대기시간
____데이터 일관성
____테스트
____통합과 버전 관리
____서비스 검색과 라우팅
____모니터링과 로깅
____기량과 경험
____가동시간 서비스 수준 계약(SLA)
__모범 사례
____캡슐화
____데브옵스 원칙과 문화
____자동화
____모니터링
____결함 허용
__요약


2장. Azure의 컨테이너

__VM과 컨테이너, 프로세스
____가상 머신이나 프로세스에서 컨테이너를 사용하는 시기
__Azure의 컨테이너
__도커가 있는 Azure VM 만들기
____Windows에서 SSH 공개 키 생성
____Mac OS X에서 SSH 공개 키 생성
____가상 머신 이미지 선택
____Windows에서 SSH와 Git Bash를 사용해 VM 연결하기
____Mac OS X에서 SSH와 Git Bash를 사용해 VM 연결하기
____도커 컨테이너 기초
__요약


3장. 애플리케이션 설계

__어디서 시작할지 결정하기
____코스 그레인드 서비스
____마이크로서비스로 시작하기
__서비스와 인터페이스 정의
____애플리케이션 분해
____서비스 설계
__서비스 vs. 서비스 통신
____동기 요청/응답
____비동기 메시징
__모놀리스에서 마이크로서비스로
__Flak.io 전자상거래 샘플
____Flak.io
____요구사항
____아키텍처 개요
____고려사항
__요약


4장. 개발 환경 설정

__로컬 개발을 위한 도커 사용하기
____로컬 개발용 도커
____운영 유효성 검증을 위한 도커
____빌드/테스트 호스트로서 도커
__개발자 구성
____로컬 개발
____로컬 및 클라우드
____클라우드 전용
____도커 인증 관리
____기본 이미지 선택
____이미지의 계층구조 만들기
__로컬 개발 환경 설정
____도커 도구 설치
____개발자 도구 설치
____Windows 유틸리티 설치
____OS X 유틸리티 설치
__로컬 개발을 위한 도커
____로컬 개발 설정
____로컬 도커 호스트 시작
____도커 호스트에 연결하기
____샘플 복제하기
____도커 컨테이너에서 라이브 리로드 사용하기
____볼륨
____운영 환경을 위한 마이크로서비스 준비
____도커 컴포즈
__도커 문제 디버깅
____도커 호스트에 연결할 수 없다.
____컨테이너가 시작되지 않는다.
____컨테이너 실행 진단하기
__요약


5장. 서비스 오케스트레이션과 연결

__오케스트레이션
__프로비저닝
____코드로서의 인프라
____Azure 리소스 관리자
____Azure 컨테이너 서비스
____ACS 리소스 공급자
____멀티벤터 프로비저닝
__스케줄링과 클러스터 관리
____문제점
____스케줄링 솔루션
____도커 스웜
____큐버네티스
____아파치 메소스
____아파치 메소스를 사용한 다양한 작업 부하 실행
__서비스 검색
____서비스 등록
____서비스 조회
____서비스 레지스트리
____다양한 기술
____기타 기술
____애플리케이션/API 게이트웨이
____오버레이 네트워킹
__요약


6장. 데브옵스와 지속적인 업데이트

__데브옵스 개요
____현대의 데브옵스
____데브옵스 문화
____연속 통합과 지속적인 전달, 연속 배포
____Azure에서 환경 만들기
__지속적인 업데이트를 사용한 마이크로서비스 배포
____서로 다른 환경에서의 애플리케이션 구성 변경
____연속 통합
____QA 환경의 테스트
____스테이징 배포
____운영 환경의 테스트
__지속적인 업데이트 도구 선택
____온프레미스 또는 호스팅?
____최고의 솔루션 또는 통합 솔루션?
____도구에서 필요한 확장을 제공하는가?
____젠킨스와 팀 서비스, 뱀부, Tutum의 비교
____도커 클라우드(이전엔 Tutum)
__요약


7장. 모니터링

__호스트 머신 모니터링
__컨테이너 모니터링
____모니터링 서비스
__모니터링 솔루션
____Azure 진단
____Application Insights
____OMS
____도커의 권장 솔루션
__요약


8장. Azure 서비스 패브릭

__서비스 패브릭 개요
____서비스 패브릭 하위시스템
____클러스터 관리
__리소스 스케줄링
____서비스 패브릭 애플리케이션
____사용자 지정 애플리케이션(기존 애플리케이션)
____컨테이너 통합
__서비스 검색
__프로그래밍 모델
____상태 비저장 서비스
____상태 저장 서비스
____신뢰할 수 있는 액터(Reliable Actors)
____신뢰할 수 있는 서비스(Reliable Services)
__애플리케이션 수명주기
____서비스 업데이트
____애플리케이션 업그레이드
____테스트 용이성 프레임워크
__요약


부록. ASP.NET Core 1.0과 마이크로서비스

__ASP.NET의 새로운 버전
____시작하기
____알맞은 ASP.NET 도커 이미지 선택하기
____Visual Studio 2015 도구
____ASP.NET 마이크로서비스 모범 사례

★ 추천의 글 ★
지난 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와 클라우드에 관한 놀라운 제품 통찰력을 보유하고 있다. 이 책에서 제공하는 기술을 사용해 여러분이 만들어 낼 것을 기대하고 있겠다.

- 코리 샌더스(Corey Sanders)
Partner Director of Program Management, Azure

★ 이 책에서 다루는 내용 ★

■ 마이크로서비스 아키텍처의 차이점과 사용 시기
■ 마이크로서비스 아키텍처의 맥락에서 도커 컨테이너 이해
■ 도커 이미지 구축과 가져오기, 계층화 시키기
■ 도커 볼륨과 컨테이너, 이미지, 태그, 로그 다루기
■ 도커 스웜과 도커 컴포즈, 도커 네트워크 사용
■ 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에서 도커를 사용해 마이크로서비스를 만드는 데 필요한 도구를 제공하고자 한다.

★ 지은이의 말 ★

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

보리스숄
Microsoft Azure 컴퓨트 팀의 수석 프로그램 관리자며, 서비스 패브릭 사용자 지정 애플리케이션 오케스트레이션과 컨테이너 통합, Azure의 OSS 개발과 컨테이너 기반 워크로드에 대한 데브옵스 스토리를 검토한다. 전에는 대규모 분산 클라우드 애플리케이션과 IaaS 개발자 도구, 클라우드 환경의 프로비저닝, 전체 ALM 라이프 사이클에 대한 아키텍처와 구현 패턴에 초점을 맞추고 Visual Studio 클라우드 도구 팀을 이끌었다. 또한 Microsoft 서비스로 글로벌 클라우드 및 SharePoint 솔루션에 아키텍트로 일한 경험이 있다. 다양한 이벤트의 연사로 활동한 것 외에도 Azure 개발과 클라우드 애플리케이션 진단에 관련된 많은 글을 썼고 『SharePoint 2010 Development with Visual Studio 2010 한국어판』(아이티포럼, 2012)의 공저자기도 하다.

트렌트스완슨
전형적인 기업가다. Full Scale 180의 공동 창립자 겸 컨설턴트로 Microsoft의 가장 큰 고객 중 일부와 일하면서 Microsoft Azure 플랫폼으로 애플리케이션을 마이그레이션하고 빌드하는 일을 도왔다. 오늘날 Microsoft Azure에서 실행되는 가장 규모가 큰 몇 가지 애플리케이션을 구축에 참여했는데, 이 중 일부는 도커와 마이크로서비스 아키텍처를 활용한다. Microsoft Patterns and Practices 팀과 함께 클라우드 애플리케이션을 위한 개발 가이드와 모범 사례도 개발하며, 클라우드 디자인 패턴에 대한 책을 공동 저술하기도 했다. Krillan과 Threadsoft의 공동 창립자로서, 도커와 Node.js, Go, Mesos를 사용해 마이크로서비스 아키텍처 스타일 기반 애플리케이션을 구축했다. B&S Enterprises의 공동 창립자로 상업용 건물 관리를 위한 다양한 IoT 기술을 적용하고 있다.

대니얼페르난데스
Visual Studio와 Team Services, ASP.NET, Azure 일부 영역에 대한 개발자 콘텐츠 팀을 관리하는 수석 책임자다. 이전에는 Visual Studio와 Visual Studio Code, Visual Studio Team Services를 사용한 도커 연속 통합을 포함해 도커에 대한 개발자 경험을 관리하는 수석 프로그램 관리자로 일했다. 트위터에서는 @danielfe로 찾을 수 있다.
옮긴이 김도균
2012년 조직의 일원으로 15년간의 삶을 정리하고, 독립 IT 기술자가 되어 5년째 자기 시간의 주인으로 포트폴리오 인생을 살고 있다. 2003년부터 IT 관련 기술서 번역에 참여해오고 있으며, 에이콘 출판사에서 출간한 (2016), <처음 배우는 C#>(2015), (2015), (2015), (2014), (2012), <윈도우 7 완벽 가이드>(2010)를 번역했다. 개발자를 위한 IT 매거진인 ‘마이크로소프트웨어’에 오랫동안 기술자와 삶에 관해 칼럼을 써오고 있으며, <나홀로 개발자를 위한 안드로이드 프로그래밍의 모든 것>(에이콘, 2013)을 비롯해 여러 권의 저서에 참여했다.
16년 차 Microsoft의 공인 강사(MCT)며 Microsoft MVP를 5회 수상했다. Microsoft 기술 교육 전문 기업인 러닝웨이의 수석 강사로 활동하고 있고, 독립 IT 기술자의 저술 강연 상호부조 네트워크인 GoDev(www.godev.kr)에서 해적들을 이끌고 있는 선장이다.