클라우드 네이티브 자바 (스프링 마이크로서비스 아키텍처와 데브옵스를 실천하는 | 클라우드 기반 서비스의 모든 것)

조쉬 롱

저자 조쉬 롱(Josh Long)
스프링 개발 애드버킷(Advocate)이자 <인포큐닷컴InfoQ.com>의 자바 큐 편집자이며, 『스프링 레시피 2판』(에이프레스)을 비롯한 여러 권의 책을 저술했다. 그는 더서버사이드 자바 심포지움(TheServerSide Java Symposium), 스프링원(SpringOne), 오스콘(OSCON), 자바존(JavaZone), 데복스(Devoxx), 자바투데이즈(Java2Days) 등 국제적인 여러 컨퍼런스에 발표자로 참여했다. 스프링 소스 코드 작업을 하지 않을 때는 지역 자바 사용자 그룹이나 커피 숍에 주로 머무른다. 기술의 한계를 극복할 수 있는 솔루션을 좋아하며, 관심 분야는 확장성, BPM(Business Process Management), 그리드 처리, 모바일 컴퓨팅, '스마트'라는 수식어를 달고 있는 다양한 시스템이다. 스프링 소스 블로그(blog.springsource.org)에 글을 쓰며, 개인 블로그(joshlong.com)도 운영 중이다.

[1부 기초]
1장 클라우드 네이티브 애플리케이션
아마존 사례
플랫폼의 약속
패턴
확장성
신뢰도
애자일성
넷플릭스 사례
__마이크로서비스
__일체형 쪼개기
__넷플릭스 OSS
__클라우드 네이티브 자바
12요소 방법론
__코드베이스
__의존 관계
__설정__지원 서비스
__빌드, 릴리스, 실행
__프로세스
__포트 바인딩
__동시성
__처분성
__개발/운영 짝맞춤
__로그
__관리 프로세스
정리

2장 부트캠프: 스프링 부트와 클라우드 파운드리 소개
스프링 부트
스프링 이니셜라이저
스프링 툴 스위트 시작하기
__스프링 툴 스위트 설치
__스프링 이니셜라이저로 새 프로젝트 생성
스프링 가이드
__STS에서 스프링 가이드 따라하기
설정
클라우드 파운드리
정리

3장 12요소 애플리케이션 설정
혼동스러운 설정
스프링 프레임워크의 설정 지원
__설정 정보 이해를 위한 PropertyPlaceholderConfigurer 클래스
__Environment 추상화와 @Value
__프로파일
스프링 부트 방식의 설정
스프링 클라우드 설정 서버로 중앙 집중형 설정 사용하기
__스프링 클라우드 설정 서버
__스프링 클라우드 설정 클라이언트
__보안
새로고침 가능한 설정
정리

4장 테스트
테스트의 구성
스프링 부트 애플리케이션 테스트
통합 테스트
__테스트 슬라이스
__모의 기법 활용
__@SpringBootTest로 서블릿 컨테이너 설정
__슬라이스
전 구간 테스트
__분산 시스템 테스트
__컨슈머 주도 계약 테스트
__스프링 클라우드 컨트랙트
정리

5장 애플리케이션 마이그레이션
계약
애플리케이션 환경 마이그레이션
__바로 가져다 쓰는 빌드팩
__커스텀 빌드팩
__컨테이너화된 애플리케이션
애플리케이션을 클라우드로 옮기기 위한 가벼운 리팩토링
__지원 서비스 연동
__스프링을 이용한 서비스 짝맞춤
정리

[2부 웹 서비스]
6장 REST API
레너드 리차드슨의 성숙도 모델
스프링 MVC를 이용한 간단한 REST API
컨텐트 협상
__바이너리 데이터 읽고 쓰기
__구글 프로토콜 버퍼
에러 처리
하이퍼미디어
__미디어 타입과 스키마
API 버저닝
REST API 문서화
클라이언트
__편리한 REST 클라이언트 제품
__RestTemplate
정리

7장 라우팅
DiscoveryClient 추상화
클라우드 파운드리 라우트 서비스
정리

8장 엣지 서비스
Greetings 서비스
간단한 엣지 서비스
넷플릭스 페인
넷플릭스 주울을 통한 필터링과 프록시
__커스텀 주울 필터
엣지 서비스의 보안
OAuth
__서비스 쪽 애플리케이션
__HTML5와 자바스크립트 단일 페이지 애플리케이션
__사용자 없는 애플리케이션
__신뢰할 수 있는 클라이언트
스프링 시큐리티
스프링 클라우드 시큐리티
__스프링 시큐리티 OAuth 인가 서버
__Greetings 자원 서버 보안 조치
__OAuth 보안이 적용된 단일 페이지 애플리케이션 만들기
정리

[3부 데이터 통합]
9장 데이터 관리
데이터 모델링
__관계형 데이터베이스 관리 시스템
__NoSQL
스프링 데이터
__스프링 데이터 애플리케이션의 구조
__도메인 클래스
__리포지토리
__도메인 데이터를 위한 자바 패키지 구성
JDBC를 사용한 RDBMS 접근 시작해보기
스프링의 JDBC 지원
스프링 데이터 예제
스프링 데이터 JPA
__계정 서비스
__통합 테스트
스프링 데이터 몽고디비
__주문 서비스
__통합 테스트
스프링 데이터 네오포제이
__재고 서비스
__통합 테스트
스프링 데이터 레디스
__캐싱
정리

10장 메시징
스프링 인티그레이션을 사용한 이벤트 주도 아키텍처
__메시징 종단점
__간단한 컴포넌트에서 복잡한 시스템으로
메시지 브로커, 브릿지, 경쟁적 컨슈머 패턴, 이벤트 소싱
__발행-구독
__점대점
스프링 클라우드 스트림
__스트림 프로듀서
__스트림 컨슈머
정리

11장 배치 처리와 태스크
배치 작업
스프링 배치
__첫 번째 배치 작업
스케줄링
메시징을 사용한 스프링 배치 작업의 원격 파티셔닝
태스크 관리
프로세스 중심의 워크플로우 통합
메시징을 사용한 분산
정리

12장 데이터 통합
분산 트랜잭션
장애의 격리와 단계적 성능 저하
사가 패턴
CQRS
__불만 접수 API
__불만 접수 통계 API
스프링 클라우드 데이터 플로우
__스트림
__태스크
__REST API
__데이터 플로우 클라이언트
정리

[4부 운영 환경]
13장 관측 가능한 시스템
만들면 운영까지
마이크로서비스 살인 미스테리
12요소 운영
새로운 계약
관측성
푸시와 풀 기반의 관측성 차이와 분석
스프링 부트 액추에이터를 사용한 애플리케이션 현재 상태 수집하기
메트릭
/info 종단점을 사용해서 서비스 분별하기
정상동작 상태 확인
감사 이벤트
애플리케이션 로깅
__로그 출력의 지정
__로그 수준의 지정
분산 추적
__스프링 클라우드 슬루스로 실마리 찾기
__어느 정도의 데이터라야 충분할까
__오픈 집킨: 수천 개의 추적만큼 가치 있는 한 장의 사진
__그 밖의 플랫폼과 기술
대시보드
__히스트릭스 대시보드를 사용한 서비스 모니터링
__코드센트릭 스프링 부트 어드민
__오디나 마이크로서비스 대시보드
__피보탈 클라우드 파운드리의 앱스매니저
치유
정리

14장 서비스 브로커
지원 서비스의 수명 주기
플랫폼으로서의 관점
스프링 클라우드 클라우드 파운드리 서비스 브로커로 사용자 정의 서비스 브로커 구현하기
__간단한 아마존 S3 서비스 브로커
__서비스 카탈로그
__서비스 인스턴스의 관리
__서비스 바인딩
__서비스 브로커의 보호
배포
__보쉬를 이용한 릴리스
__클라우드 파운드리를 활용한 릴리스
아마존 S3 서비스 브로커 등록하기
아마존 S3 서비스 인스턴스 생성하기
__서비스 인스턴스 활용하기
S3 클라이언트 애플리케이션
전체적인 동작 확인하기
정리

15장 지속적 전달
지속적 통합을 넘어서
__플리커와 엣시의 존 알스포
__넷플릭스의 에이드리안 코크로프트
__아마존의 지속적 전달
파이프라인
테스트
마이크로서비스 환경에서의 지속적 전달
도구
__컨코스
__컨테이너
마이크로서비스의 지속적 전달
__컨코스 설치
__기본적인 파이프라인 디자인
__지속적 통합
컨슈머 주도 계약 테스트
__사용자 마이크로서비스의 파이프라인
데이터
운영 환경으로!

[5부 부록]
부록 A 자바 EE와 스프링 부트
부록 B [한국어판 특별부록] 클라우드 파운드리 환경의 준비와 활용

"자바 생태계에서 클라우드 네이티브 애플리케이션을 만드는 개발자라면 꼭 읽어야 할 필독서다. 회복력 있는(resilient) 서비스 제작, REST와 비동기 이벤트로 들어오는 데이터 흐름 관리, 테스트, 배포, 관측성(observability)과 관련된 핵심 작업까지 모든 것을 다루는 책이다."
- 대니얼 브라이언트 / 스펙토랩스(SpectoLabs) CTO

"클라우드 네이티브로의 여행을 떠나는 모든 이가 이 책에 담긴 정제된 통찰과 경험을 통해 많은 것을 배울 수 있다."
- 데이브 사이어 박사 / 스프링 프레임워크 기여자, 스프링 부트와 스프링 클라우드의 공동 설립자

아마존, 넷플릭스, 엣시 같은 회사는 전통적인 대기업과 비교해 어떤 차이가 있을까? 아마존과 넷플릭스는 클라우드 네이티브 방식으로 서비스를 만들고 운영하면서 경쟁력을 유지하고 앞서갈 수 있었다. 이 책은 자바 개발자가 스프링 부트, 스프링 클라우드, 클라우드 파운드리를 이용해서 더 나은 소프트웨어를 더 빨리 개발할 수 있는 실용적인 가이드를 제공한다. 많은 기업이 이미 클라우드 컴퓨팅, 테스트 주도 개발, 마이크로서비스, 지속적 통합 및 전달로 소프트웨어 개발 방식을 전향하고 있다. 이 책을 읽다 보면 레거시 애플리케이션을 클라우드 네이티브 애플리케이션으로 전환하는 데 도움을 주는 도구와 방법론에 자연스럽게 흠뻑 빠져들게 된다.

* 기본: 클라우드 네이티브 사고 방식의 장점을 알아본다. 스프링 부트 애플리케이션을 설정하고 테스트하는 방법과 레거시 애플리케이션을 클라우드로 옮기는 방법을 설명한다.
* 마이크로서비스: 스프링을 활용해서 HTTP 기반 RESTful 서비스를 만들어본다. 요청을 분산 시스템에 적절히 라우팅하는 방법을 알아보고 관문 역할을 하는 엣지 서비스를 구축한다.
* 데이터 통합: 스프링 데이터 프레임워크를 활용해서 데이터를 관리하는 방법과, 이벤트 주도, 메시징 중심 아키텍처를 지원하는 스프링을 사용해서 분산 서비스를 통합하는 방법을 알아본다.
* 배포 및 운영: 관찰 가능한 시스템을 만드는 방법을 알아본다. 서비스 브로커를 이용해서 상태 유지 서비스와 연결해보고, 지속적 전달에 담긴 진정한 의미를 이해한다.

예제 코드, 연습 등 보충 자료는 http://github.com/Cloud-Native-Java에서 내려받을 수 있다.

[이 책의 구성]
1부 '기초'
1장 '클라우드 네이티브 애플리케이션'과 2장 '부트캠프: 스프링 부트와 클라우드 파운드리 소개'에서는 클라우드 네이티브 사고(thinking)의 필요성에 대해 살펴보고 스프링 부트와 클라우드 파운드리를 소개한다.
3장 '12요소 애플리케이션 설정'에서는 스프링 부트 애플리케이션을 설정하는 방법을 알아본다. 이 내용은 책 전반에 걸쳐 계속 나온다.
4장 '테스트'에서는 가장 단순한 컴포넌트에서 분산 시스템에 이르기까지 스프링 애플리케이션을 테스트하는 방법에 대해 알아본다.
5장 '애플리케이션 마이그레이션'에서는 일반적인 보통의 애플리케이션을 클라우드 파운드리와 같은 클라우드 플랫폼으로 이전하는 데 필요한 리팩토링을 가볍게 살펴보고, 여러분이 클라우드 플랫폼으로부터 필요한 가치를 얻을 수 있도록 도와줄 것이다.
2부 '웹 서비스'
6장 'REST API'에서는 스프링으로 RESTful HTTP 서비스를 만들어본다. 이 장에서 다루는 내용은 API 개발과 도메인 주도 개발에서 많이 사용된다.
7장 '라우팅'에서는 분산 시스템에서 요청(request)의 출입을 제어하는 일반적인 방법을 알아본다.
8장 '엣지 서비스'에서는 외부로부터의 요청을 받아들이는 첫 번째 관문 역할을 하는 서비스를 만드는 방법을 알아본다.
3부 '데이터 통합'
9장 '데이터 관리'에서는 스프링 데이터를 사용해서 스프링 애플리케이션에서 데이터를 관리하는 방법을 알아본다. 여기에서 다루는 내용은 도메인 주도 사고의 기초가 된다.
10장 '메시징'에서는 스프링의 이벤트 주도, 메시징 중심 아키텍처를 이용해서 분산 서비스와 데이터를 통합하는 방법을 알아본다.
11장 '배치 프로세스와 태스크'에서는 클라우드 파운드리 같은 클라우드 플랫폼의 확장성을 이용해서 오래 지속되는 작업부하를 처리하는 방법을 알아본다.
12장 '데이터 통합'에서는 분산 시스템에서 상태를 관리하는 몇 가지 방법을 알아본다.
4부 '운영 환경'
13장 '관측 가능한 시스템'에서는 관측성(observability)과 운영을 지원하는 시스템을 만드는 방법을 알아본다.
14장 '서비스 브로커'에서는 클라우드 파운드리 같은 플랫폼을 지원하는 서비스 브로커를 만드는 방법을 알아본다. 서비스 브로커는 메시지 큐, 데이터베이스, 캐시처럼 상태를 가진 서비스를 클라우드 플랫폼에 연결해준다.
15장 '지속적 전달'에서는 지속적 전달 뒤에 숨어있는 중요한 개념을 살펴본다. 이 책에서는 마지막 장에 해당하지만, 클라우드 네이티브를 향한 여러분의 여정에서는 출발점에 해당한다.
5부 '부록'
부록 A '자바 EE와 스프링 부트'에서는 스프링 부트 애플리케이션을 자바 EE 환경에 통합하는 방법을 살펴본다.
마지막으로, 한국어판 특별 부록 B '클라우드 파운드리 환경의 준비와 활용'에서는 클라우드 파운드리를 준비하고 애플리케이션을 배포하며 서비스를 준비하는 방법에 대해 알아본다.

[이 책의 독자 대상]
이 책은 스프링 부트, 스프링 클라우드와 클라우드 파운드리를 이용해서 더 나은 소프트웨어를 더 빠르게 만들고 싶어하는 자바/JVM 개발자를 주요 대상으로 한다. 마이크로서비스라는 용어에 대해 들어본 적이 있고, 하늘 높이 치솟는 스프링 부트의 인기를 느끼고 있으며, 오늘날 대부분의 기업들이 왜 클라우드 파운드리를 사용하는지 궁금하다면, 이 책은 바로 여러분을 위한 책이다.

[옮긴이의 말]
“소프트웨어를 유지한다는 것은 ‘이전처럼 동작하게 하는 것'이 아니다. ‘변화하는 세상에서도 항상 유용하게 만드는 것’이다.” 스프링 부트 프로젝트의 리드인 피보탈의 필 웹(Phil Webb)은 스프링원 플랫폼 2017 발표(https://youtu.be/MQamx7-bCVI)에서 원자 이론학자 제시카 커(Jessica Kerr)의 말을 인용했다. 오늘날 웹 또는 모바일 기반의 서비스를 제공하는 대부분의 회사는 소프트웨어와 데이터를 다루는 능력, 그 자체가 곧 경쟁력이다. 아이디어를 동작하는 소프트웨어로 구현하고, 이 소프트웨어를 가능한 한 빨리 고객에게 전달해서 그 가치를 검증하는 일을 반복하는 것은 사업의 성패에 매우 중요하다.
필 웹은 그날 발표에서 스프링 프로젝트와 스프링 프레임워크가 발표된 해에 함께 출시된 노키아 6610의 전화기를 예로 들었다. 노키아 6610은 현재도 시장에서 구매할 수 있으며 심지어 수리도 가능하지만 오늘날 아무도 이 전화기를 쓰지 않는다. 대신, 모두가 더 많은 기능이 탑재된 최신 스마트폰을 사용한다. ‘전화기’에 대한 세상의 인식이 바뀌었기 때문이다. 이처럼 변화를 수용하지 못한 기기는 시장에서 외면을 받기 마련이다. 반면 스프링 프로젝트는 여전히 많은 서비스 애플리케이션에서 사용되고 있으며 심지어 최근에는 더욱 더 많은 사용자를 확보하는 중이다. 그 오랜 세월 동안 스프링은 꾸준히 시장의 변화를 반영해 왔기 때문이다. 이어서 필 웹은 스프링 부트 애플리케이션을 시작하고자 할 때 사용하는 스프링 이니셜라이저(http://start.spring.io)의 통계를 예로 들었다. 스프링 MVC에 적용된 다양한 뷰(View) 기술 중 타임리프(Thymeleaf)는 여전히 개발자들이 많이 사용하지만, 벨로시티(Velocity)의 경우는 그 사용량이 점점 줄어들다가 결국 사라졌다. 어느 시점에 스프링 이니셜라이저에서 이 벨로시티의 사용량이 제로가 된 이유는 스프링 팀에서 벨로시티를 더 이상 지원하지 않기로 결정했기 때문이다. 벨로시티 프로젝트는 더 이상 활발하게 진행되지 않고 업데이트가 이루어지지 않았기 때문에, 스프링 사용자들에게 안정성, 보안 등의 측면에서 악영향을 미칠수 있는 벨로시티를 제외했다는 것이다.
피보탈의 클라우드 파운드리 연구 개발 총괄인 온시 파쿠리(Onsi Fakuhouri)는 스프링원 플랫폼 2017 발표(https://youtu.be/_uB5bBsMZIk)에서 "우리가 개념적으로 설정한 목적지에 다다르는 과정은 상상에서처럼 올곧은 것이 아니라 수많은 난관과 어려움이 산재해 있으며, 그런 어려움을 모두 헤치고 막상 도착한 곳은 원했던 목적지가 아닐 수도 있다."고 말했다. 따라서 이런 거대한 위험을 안고 가는 것보다는, 관찰-선택-학습으로 이어지는 과정을 반복해야 한다고 덧붙였다. 우리가 초행길에서 목적지를 찾아 갈 때도 이런 방법을 적용해 볼 수 있다. 스마트폰에서 먼저 지도와 주변 지형을 살피고, 비교하고, 이동한다. 원하는 목적지에 더 빠르게 도달하려면 이 과정을 더 빠르게 반복할 수 있으면 된다.
스프링 프로젝트의 생존에서 우리는 온시가 말한 관찰-실행-학습의 반복 예를 살펴볼 수 있다. 스프링은 이 방법을 바탕으로 시장의 개발자들의 요구를 살피고, 이를 반영해서 그 결과를 관찰한다. 그 결과로 스프링 부트 프로젝트가 탄생했고, 스프링 클라우드 프로젝트가 탄생했다. 시장의 클라우드 기반 애플리케이션에 대한 요구는 더욱 더 강력해졌고, 이는 비단 더 높은 가용성 및 확장성뿐만 아니라 더 잦은 변화를 스프링 프레임워크에서 수용해야 함을 의미했다. 따라서 오늘날의 수많은 스프링 프로젝트는 시장의 변화에 대한 요구를 수용하고 적용했기 때문에 노키아 전화기가 처한 상황과는 다르게 성공적으로 살아남은 결과물인 것이다. 그리고 오늘도 다양한 스프링 프로젝트들이 이 과정을 반복하고 있다.
스프링 부트는 더 이상 우리가 XML 설정에 고통받지 않아도 되는 방법을 제공한다. 매번 반복해야 하는 동일한 설정은 스프링 부트 팀이 제공하고, 개발자들은 필요한 기능을 의존관계 주입을 통해 이전과는 다른 방법으로 사용할 수 있다. 이 외에도 스프링 부