1. 아마존 비즈니스 민첩성의 비밀
해당 포스트는 도메인 주도 설계로 시작하는 마이크로 서비스 개발 책을 개인적으로 요약한 내용입니다.
1.1 성공한 인터넷 기업들과 비즈니스 민첩성
성공한 인터넷 기업들은 자신만의 특화된 서비스를 제공하려는 시도를 누구보다 빨리 실행했고 사용자 피드백을 반영해 끊임없이 서비스를 개선한다.
1.1.1 아마존의 배포 속도
11.6초 아마존의 배포 속도이다. 우리나라 쇼핑몰 기준으로 봤을 때 평균 배포 주기는 1주일 정도이다. 긴급 배포가 필요한 경우에는 주중에 1번 더 배포를 한다. 그렇다면 국내 쇼핑몰의 성장 속도는 빨라야 3일이라는 소리이다. 11.6초마다 변화하는 아마존과 비교하면 어디가 더 우위에 있을지 답은 자명하다.
1.1.2 클라우드 인프라의 등장
전형적인 시스템 인프라 구성을 보면 서비 구입부터 운영체제 설치까지 고려해야 할 점이 많다. 이 과정을 모두 끝내기 위해서는 적게는 며칠 많게는 몇 주가 소요된다.
그런데 최근에는 클라우드 인프라의 등장으로 모든 문제가 해결이 되었다. 몇번의 클릭만으로도 서버가 생성이 되며 개발 환경 구축이 끝나게 된다.
1.1.3 클라우드 인프라에 어울리는 애플리케이션의 조건
클라우드 인프라는 사요앟면 사용량에 따라 비용을 유연하게 조절할 수 있다. 예를 들면 쇼핑몰에 1주일간 할인 행사를 진행한다고 가정을 하면 그 세일 기간 동안에 용량을 증설하고, 세일 기간이 지나면 다시 원래의 용량으로 줄이는 것이다.
스케일 업 스케일 아웃
스케일 업(수직 확장) : 기존 시스템 자체의 물리적 용량을 증가시켜 성능을 높이는 바업ㅂ이다. 사용량이 많아진다는 것은 데이터 처리가 증가한다는 것이고 시스템을 담을 그릇도 커져야 한다.
스케일 아웃(수평 확장) : 기존 시스템과 용량이 같은 다수의 장비를 병행 추가해서 가용성을 높이는 방법이다. 즉 용량을 분산시켜 전체적으로 장애 없이 운영하게 된다.
1.2 마이크로서비스란 무엇인가?
1.2.1 모노리스와 마이크로서비스 비교
전통적인 구조인 모노리스 구조는 보통 3티어(클라이언트, 서버, 데이터베이스)를 사용하였다. 아무리 작은 배포라도 서비스 전체를 빌드하여 배포해야만 했다. 서비스가 커지게 되면 시스템을 복제하여 로드 밸런싱을 통해 트래픽을 분산 처리하게 된다.
반면 마이크로서비스는 확장 시에는 특정 기능별로 독립적으로 확장할 수 있고, 특정 서비스를 변경할 필요가 있다면 해당 서비스만 빌드해서 배포하면 된다. 또 각 서비스가 독립적이어서 서로 다른 언어로 개발하는 것도 가능하므로 각 서비스의 소유권을 분리해 서로 다른 팀이 개발 및 운영할 수 있다.
1.2.2 SOA와 마이크로서비스
모듈화 개념의 발전 흐름
구조적(structured) 방법론 → 객체지향(object-oriented) 방법론 → CBD(Component Based Development) → SOA(Service Oriented Architecture)
SOA는 MSA와 비슷하지만 구체화하기 어렵고 성공 사례가 적다. MSA는 아마존, 넷플릭스와 같은 증명된 성공 사례가 있는 구조라고 할 수 있다.
Polygolt : 특정 서비스를 구축하는데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식을 의미
1.3 마이크로서비스를 위한 조건은 무엇인가?
1.3.1 조직의 변화: 업무 기능 중심 팀
하나의 어플리케이션을 만들 때는 여러 팀의 의사소통이 필요하다. (기획팀, 개발팀, 디자인팀, QA팀 등등...) 여러 팀들의 의사소통이 필요한 만큼 업무가 지연되기 마련이다. 마이크로서비스팀의 구조는 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀을 만드는 것을 의미한다.
한 팀에 다양한 역할(기획자, 디자이너, 프론트엔드, 백엔드, 설계자, 테스터)로 구성되어 있고 빠른 의사소통을 할 수 있다.
아마존에서는 이런 팀을 'two pizza team'이라고 표현을 하는데 이는 피자 두 판으로 서로 빈번히 의사소통하며 함께 식사할 수 있는 정도의 팀원 수를 의미한다.
1.3.2 관리체계의 변화: 자율적인 분권 거버넌스, 폴리그랏
마이크로서비스팀이 되면서 회사에 종속적일 필요성이 없게 되었다. 회사에 규칙에 맞게 개발을 해야 하거나 그럴 필요가 없어졌기 때문이다. 다양한 언어를 선택할 수 있으며 기능에 따라서 DB도 선택할 수 있는 것이다.
이것을 폴리그랏 프로그래밍 폴리그랏 저장소라고 부른다.
1.3.3 개발 생명주기의 변화: 프로젝트가 아니라 제품 중심으로
예전에는 프로젝트 팀에서 프로젝트를 끝내면 운영 조직으로 프로젝트를 넘겨 운영팀에서 운영되도록 하였다. 프로젝트가 끝나기 전에는 새로운 기능이 추가되긴 힘들었고 운영으로 넘어간 순간부터 추가할 수 있었다. 마이크로서비스가 도입되므로 해당 팀에서 개발부터 운영까지 맡게 되었다. 애자일 방식으로 2~3주 동안 스프린트를 진행하여 개발과 배포를 하게 된다. 따라서 제품을 개발하고 끝내는 것이 아닌 지속적으로 개선되고 발전시킬 제품으로 보는 것이다.
1.3.4 개발 환경의 변화 : 인프라 자동화
마이크로서비스에서는 수동으로 배포하는 방법은 바람직하지 않다. 따라서 여러 개의 마이크로서비스를 빠르게 배포하기 위한 방법이 필요하다.
가장 좋은 방법은 자동화다. 개발 지원 환경을 자동화하는 데는 소스코드를 빌드하는 도구와 빌드와 동시에 테스트하는 도구, 가상화된 인프라에 배포하는 도구가 모두 필요하다.
이러한 개발환경, 개발지원 환경을 자동화하는 것을 모두 통틀어 인프라 자동화라고 하기도 한다.
이러한 과정을 빌드/배포 파이프라인이라고 하며 일반적으로 '소스코드 빌드' → '개발 환경 배포' → 스테이징 환경 배포' → '운영 환경 배포'로 구성된다.
1.3.5 저장소의 변화 : 통합 저장소가 아닌 분권 데이터 관리
모노리스 시스템에서는 통합 디비로 모든 서비스를 관리를 하기 때문에 단일 데이터베이스를 유지할 수 있었다. 하지만 마이크로서비스는 서비스별 다양한 데이터베이스를 사용하기 때문에 데이터를 동기화할 필요성이 있다.
각 서비스의 데이터는 API를 통해 접근할 수 있으며 이벤트를 이벤트 큐 방식으로 전달을 한다. 예를 들어 주문과 배송의 서비스가 나눠져 있는 상황이라고 가정했을 때 주문이 들어오고 배송 쪽에서 취소가 되는 상황이 생길 수 있다. 이런 경우 다음과 같이 처리하여 비즈니스 일관성을 맞출 수 있다.
A. 주문 서비스가 주문 처리 트랜잭션을 수행한다.
1. 동시에 주문 이벤트를 발행한다.
2. 주문 이벤트가 메시지 큐로 전송된다.
3. 배송 서비스가 주문 이벤트를 인식한다.
B. 배송 서비스가 주문 처리에 맞는 배송 처리 트랜잭션을 수행한다. (비즈니스 일관성 만족)
1. 배송 처리 실패 이벤트를 발행한다.
2. 배송 처리 실패 이벤트가 메세지 큐로 전송된다.
3. 주문 서비스가 배송 처리 실패 이벤트를 인식한다.
C. 배송 처리 트랙잭션 중 오류로 트랜잭션이 실패한다.
D. 주문 서비스가 배송 처리 실패 이벤트를 인식한다.
1.3.6 위기 대응 방식의 변화 : 실패를 고려한 설계
아마존 부사장인 버너 보겔스는 '소프트웨어는 모두 실패한다'라고 말한 바 있다. 완벽한 소프트웨어는 없다는 뜻이다. 예전에는 하드웨어의 스펙을 높이고 소스의 실패를 줄이면 된다고 생각을 했다. 하지만 최근에는 실패에 대해서도 빠르게 대응할 수 있는 방안을 찾는 쪽으로 변화하였다. 넷플릭스는 '카오스 몽키'라는 장애를 일부러 발생시키는 도구를 만들어 탄력적인 아키텍처가 제대로 동작하는지 점검한다.
1.4 정리
MSA를 말 그대로 아키텍처나 기술로 생각하는 경향이 있지만 그렇지 않다. 다양한 사람들의 의견을 받아 나누는 논의 중에 진정한 가치 있는 아이디어가 나오고, 협업을 통해 개발하며, 또 다른 사람들의 피드백을 통해 끊임없이 개선해야 하는 창의적인 활동이다.
즉, MSA는 다양한 사람들이 만나서 협업하는 방식, 조직 문화의 진화된 결과물이라 생각해야 한다.
'MSA' 카테고리의 다른 글
| [MSA] BackEnd For FrontEnd 패턴에 대해서 (0) | 2025.01.02 |
|---|---|
| [도메인 주도 설계로 시작하는 마이크로서비스개발] 3. 마이크로서비스 애플리케이션 아키텍처 (0) | 2021.11.21 |
| [도메인 주도 설계로 시작하는 마이크로서비스개발] 2. MSA의 이해 (0) | 2021.11.08 |
