1장 : 아마존 비즈니스 민첩성의 비밀
1.1 : 성공한 인터넷 기업들과 비즈니스 민첩성
성공한 유니콘 기업들의 공통점 (ex. Amazon, Netflix, Uber)
- 익숙한 비즈니스 + 새로운 비즈니스 개념, 기술 = 자신만의 특화된 서비스 제공
- 사용자 피드백을 적극적으로 반영해 끊임없이 서비스 개선 (= 비즈니스 민첩성)
성공 사례 : 아마존의 배포속도
2011년을 기준으로 아마존의 비즈니스 서비스가 배포되는 주기는 11.6초라고 한다.
이는 11.6초마다 운영중인 코드가 바뀌고, 배포까지 된다는 말이다.
2019년을 기준으로는 아마존의 서비스의 배포주기가 초당 1.5번으로 향상됐다.
이러한 빠른 주기의 배포는 비즈니스의 민첩성을 간접적으로 나타내는 지표이다.
보통 서비스는 기획, 분석, 설계, 구현 과정이 길게는 몇 개월 짧게는 몇 주가 걸리기 마련이다. 하지만 아마존은 전체 과정이 독립적으로 완료되어 초당 1.5번씩 서비스가 변경, 개선되고 있다.
어떤한 긴급한 상황이 있어도 지속적으로 변화에 반응하기 때문에 경쟁에서 우위를 가질 수 밖에없다.
클라우드 인프라의 등장
전형적인 시스템 인프라 구축 과정은
서버실 공사 - 서버 장비 구입, 네트워크 연결 - 운영체제 및 S/W 설치
이렇게 진행이 됐었다. 적게는 며칠에서 몇 주, 길게는 몇 달이 걸리기도 했다.
이처럼 인프라 환경을 준비하는 작업은 그리 간단한 작업은 아니었다.
또한 서비스가 실패로 끝난다면 초기 투입된 인프라 비용을 회수할 수 없었다.
이러한 문제들이 클라우드 인프라의 등장으로 해결 됐다.
- 서비스 개발에 필요한 시스템 인프라를 준비하는데 오랜 시간이 들지 않는다. (클릭 몇번으로 개발 시스템 인프라를 마련할 수 있다)
- 실패로 끝난다면, 전형적인 인프라 구축에 비해 인프라 비용을 회수할 수 있다. (사용한 만큼의 금액만 지불하면 된다)
클라우드 인프라에 어울리는 애플리케이션 조건
클라우드 인프라는 사용량에 따라 금액을 달리할 수 있다
쇼핑몰에서 타임 세일을 진행한다고 가정 한다면, 시스템 용량을 증가 시켜야 한다.
이때, 전형적인 인프라는 처음부터 타임 세일을 고려해서 시스템 용량을 크게 할 것이고, 이는 되돌릴 수 없다.
하지만, 클라우드 인프라는 타임 세일을 하는 기간에만 늘리고, 다시 줄일 수 있어서 해당 기간에 추가되는 비용만 지불하면 된다.
스케일 업, 스케일 아웃 (수직, 수평 확장)
시스템 용량을 증가 시키는 방법에는 크게 2가지가 있다
- 스케일 업 : 물리적 용량을 늘린다
- 스케일 아웃 : 물리적 용량이 같은 장비를 병행 추가한다
특정 서비스만 탄력적으로
전체가 한 덩어리로 묶여 있는 애플리케이션을, 조각 단위로 분리하자
이를 통해 얻을 수 있는 이점은, 타임 세일을 하는 단위만 탄력적으로 증가 시킬 수 있어서 필요 없는 부분(조각)은 증가 X
1.2 : 마이크로서비스란 무엇인가?
모노리스와 마이크로서비스 비교
- 모노리스 : 전통적인 시스템 구조. 하나의 단위로 개발되는 일체식 애플리케이션
클라이언트 - 모노리스 (스케일 아웃 = 전체 확장) - 데이터베이스
아무리 작은 변화에도 전체를 빌드해서 배포해야 한다
또한 확장이 필요한 경우 전체 애플리케이션을 동시에 확장해야 한다
이 경우에 변경이 발생하면, 확정된 여러 개의 모노리스 시스템을 전부 다시 빌드하고 배포해야 한다
또한 애플리케이션은 확장은 가능하지만, 데이터베이스는 통합되어 1개이므로 탄력적으로 대응할 수 없다
- 마이크로서비스 : 서버 측이 여러 개의 조각으로 구성돼 각 서비스가 별개의 인스턴스로 로딩
클라이언트 - 서비스 A, 서비스 B, 서비스 C - 저장소 A, 저장소 B, 저장소 C
여러 서비스 인스턴스가 모여 하나의 비즈니스 애플리케이션을 구성
이에 따라 확장 시에는 해당 인스턴스만 확장하면 되고, 변경이 있을 경우 해당 인스턴스만 빌드 후 배포하면 된다
또한 각 서비스가 독립적이기 때문에 각각이 다른 언어로 구성할 수도 있고, 서로 다른 팀이 개발 및 운영할 수 있다
SOA와 마이크로서비스
모듈화의 단위가 기능별로 재사용할 수 있는 좀 더 큰 컴포넌트가 되는 CBD(Component Based Development)
컴포넌트를 모아 비즈니스적으로 의미 있고 완결적인 서비스 단위로 모듈화하는 SOA(Service Oriented Architecture)
사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식 폴리글랏(Polyglot)
CBD/SOA의 접근법에서는 애플리케이션은 모듈별로 분리해으나 데이터 저장소까지는 분리하지 못했다
즉, 여러 애플리케이션이 하나의 저장소를 통합해서 공유했다
따라서 데이터의 강한 결합으로 애플리케이션도 독립적으로 사용하기가 힘들었다
MSA의 차별화된 2가지 개념
- 서비스별 저장소 분리, 다른 서비스가 직접 호출하지 못하도록 캡슐화
- REST API 같은 가벼운 개방형 표준을 사용, 각 서비스가 느슨하게 연계
이렇게 2가지가 SOA와 구분하는 가장 큰 차이점이자 모듈화를 극대화 하는 특징이다
1.3 : 마이크로서비스를 위한 조건은 무엇인가?
조직의 변화 : 업무 기능 중심 팀
전통적인 일하는 방식
콘웨이 법칙 : 시스템을 개발할 때 항상 시스템의 모양이 팀의 의사소통 구조를 반영하는 것
- 기술별로 분리된 팀
UI 팀 (사용자 인터페이스) - 서버 개발팀 (서버) - DB팀 (데이터베이스)
이러한 팀 구조에서는 팀 간의 의사결정도 느리고 의사소통도 어렵다
마이크로 서비스팀의 구조
- 업무 기능 중심의 팀
역할 또는 기술별로 팀이 분리되는 것이 아니라 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀이 되어 서비스를 만드는 것
다양한 역할로 구성되고, 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 모두 갖추고 있다
같은 시간, 공간을 공유하기 때문에 의사 소통도 원활하고 의사결정도 빠르게 진행될 수 있다
이 팀은 관련된 서비스를 만들뿐만 아니라 개발 이후에 운영할 책임까지 진다
관리체계의 변화 : 자율적인 분권 거버넌스, 폴리글랏
마이크로서비스를 만드는 조직은 중앙의 강력한 거버넌스를 추구하지 않는다
빠르게 서비스를 만드는 것을 최우선 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아 적용한다
상품팀은 빠른 검색에 특화된 몽고디비 + Node.js
계약팀은 계약 서비스를 위해 오라클 + Java + Redis
이처럼 각 서비스 팀이 팀에 맞는 개발 언어 및 저장소를 선택하는 것을 각각 폴리글랏 프로그래밍, 폴리글랏 저장소라 한다
개발 생명주기의 변화 : 프로젝트가 아니라 제품 중심으로
기존에는 대부분의 애플리케이션 개발 모델이 프로젝트 단위였다.
장기간의 프로젝트 완성 - 운영조직에 넘김
또한 초기에 모든 일정을 계획했다
요구사항 정의 - 설계 - 개발
이에 따라 프로젝트 기간 중에 발생한 변경이나 새로운 아이디어를 포용하지 못했다
마이크로서비스팀은 갑작스런 트렌드 변화에 유연하게 대처해야 하고, 개발 뿐만 아니라 운영까지 책임져야 한다
비즈니스를 제공하는 제품으로 바라보고, 우선 개발한 뒤에 반응을 보고 개선하는 방식으로 소프트웨어 개발
즉, 폭포수 모델이 아닌 점진 반복적인 모델, 제품 중심의 애자일 개발 방식을 채용한다
2~3주 단위의 스프린트를 통해 개발 및 배포 후 바로 피드백을 받아 소프트웨어에 반영할 수 있게 한다
개발 환경의 변화 : 인프라 자동화
개발 환경 준비 (인프라) - 개발 (분석/설계/개발) - 개발지원과정(빌드/테스트/배포)
마이크로서비스는 독립적으로 여러 개로 쪼개진 상태이기 때문에 수동으로 배포하는 것은 바람직 하지 않다
마이크로서비스팀이 단기간에 제품을 빨리 개발하고 피드백을 받기 위해서는 개발지원 환경의 자동화가 반드시 갖춰져야 한다
개발 환경, 개발지원 환경을 자동화하는 것을 모두 통틀어 인프라 자동화라고 하기도 한다
이러한 인프라 자동화는 마이크로서비스 개발 과정의 필수조건이 되어야 한다
저장소의 변화 : 통합 저장소가 아닌 분권 데이터 관리
모노리스 시스템은 단일 통합 데이터베이스를 사용한다
스토리지 가격 및 네트워크 속도에 따른 데이터의 안정성과 효율성을 추구한 결과이다
마이크로서비스는 폴리글랏 저장소 접근법을 선택한다
각 저장소가 서비스별로 분산 되어야 하며, 다른 서비스의 저장소를 직접 호출할 수가 없고 API를 통해서만 접근해야 한다는 의미다
여기서 생기는 문제가 있다면 각 마이크로서비스의 저장소에 담긴 데이터의 비즈니스 정합성을 맞춰야 하는 데이터 일관성 문제이다
이를 위해 두 서비스를 비동기 이벤트 처리를 통한 협업을 강조한다
두 서비스의 데이터가 일시적으로 불일치하는 시점에 있고 일관성이 없는 상태지만 결국에는 두 데이터가 같아진다는 개념이다
위기 대응 방식의 변화 : 실패를 고려한 설계
시스템은 언제든 실패할 수 있으며, 실패해서 더는 진행할 수 없을 때도 자연스럽게 대응할 수 있도록 설계해야 한다
이러한 성격을 내결함성 이라 한다
실패하지 않는 시스템을 만드는 것보다 실패에 빠르게 대응할 수 있는 시스템을 만드는 편이 더 쉽고 효율적이다
이를 위해서는 다양한 실패를 대비해서 테스트할 수 있는 환경을 마련해야 하고,
시스템의 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 한다
