[도메인 주도 마이크로서비스 개발] 1. 아마존 비즈니스 민첩성의 비밀

여는글 

 

차선 활동이 애자일 개발 프랙티스 중 하나인 테스트 코드 작성과 지속적 통합을 통한 코드 품질 향상이었다. 당시 SI 현장에는 형상관리 체계나 꾸준히 빌드하는 팀 자체가 드물었기 때문에 젠킨스, 소나큐브 기반의 소스코드 품질향상 활동을 전파하기 위해 노력했다. 

 

이 책은 우리 팀의 4~5년간의 시행착오와 좌충우돌 노력의 산물이다. 소프트웨어 공학이라는 학문이 역사가 오래된 다른 인문학이나 과학, 공학 분야와 달리 법칙과 공식, 선언에 의거하지 않고 역사도 짧은 편이라 완벽한 정답이란 없다고 생각한다.

따라서 앞서간 여러 훌륭한 선배들이나 현시대에 탁월한 활약을 보이고 있는 여러 구루들의 경험을 통해 배우고 우리의 경험과 접목해서 이해하고 정리해 나아가야 한다고 본다. 

 

이 책이 마이크로서비스, 클라우드 , MSA, DDD 등의 키워드에 허우적거리는 초심자들, 특히 기존 SI 개발 현장의 방식에 익숙하지만 마이크로서비스 애플리케이션 개발을 처음 시작하는 분들을 위한 입문서가 되길 바란다. 

 

1장에서는 클라우드 환경에서 마이크로서비스가 왜 필요한지, 기존 모노리스 애플리케잇ㄴ과 무엇이 다른지를 다뤘고, 마이크로서비스의 특성을 살펴본다. 

 

2장과 3장에서는 마이크로서비스가 작동하기 위한 환경인 외부 아키텍처와 패턴, 애플리케이션 아키텍처를 통해 전반적인 마이크로 서비스 아키텍처의 큰 그림을 설명한다. 

 

4장에서는 애자일 프로세스 내에서의 마이크로서비스 설계, 개발 프로세스를 설명하며, 

 

5장에서는 이벤트 스토밍을 포함한 단순한 마이크로서비스 설계의 과정들을 설명한다. 

 

6장부터 10장까지는 사례 연구로 간단한 아키텍처를 만들고, 마이크로서비스를 설계 및 개발하고 실제 클라우드 환경에 배포하는 과정을 설명한다. 

 

 

성공한 인터넷 기업들과 비즈니스 민첩성

 

성공한 유니콘 기업들의 공통점이 있다면 이미 익숙한 비즈니스에 새로운 비즈니스 개념과 기술을 융합해 자신만의 특화된 서비스를 제공한다는 점이다. 

이러한 기업들은 자신만의 특화된 서비스를 제공하려는 시도를 누구보다 빨리 실행했고 사용자 피드백을 반영해 끊임없이 서비스를 개선한다. 빠른 배포 주기는 비즈니스의 민첩성을 간접적으로 보여주는 지표라 할 수 있다.

 

클라우드 인프라의 등장

 

수많은 스타트업이 생겨나고 참신한 서비스를 빠르게 선보이는 것을 보면 이러한 클라우드 인프라가 얼마나 강력하게 비즈니스 개발의 민첩성을 촉진하는지 알 수 있다.

 

클라우드 인프라에 어울리는 애플리케이션의 조건[쇼핑몰 예제 책 참고]

 

사용한 단위 만큼만 비용을 지불하므로 애플리케이션 블록이 작으면 작을수록 효율적이다. 특히 사용량이 증가할 운영 시점이라면 서비스 비용을 유연하게 관리할 수 있다. 

 

스케일 업과 스케일 아웃

 

스케일 업(수직 확장)은 기존 시스템 자체의 물리적 용량을 증가시켜 성능을 높이는 방법이다. 사용량이 많아진다는 것은 데이터 처리가 증가한다는 것이고 시스템을 담을 그릇도 커져야 한다. 

스케일 아웃(수평 확장)은 기존 시스템과 용량이 같은 다수의 장비를 병행 추가해서 가용성을 높이는 방법이다. 즉, 사용량을 분산시켜 전체적으로 장애 없이 운영되게 한다. 

 

마이크로서비스란 무엇인가? 

 

모노리스와 마이크로서비스 비교

논리적인 단일체로서 아무리 작은 변화에도 새로운 버전으로 전체를 빌드해서 배포해야 한다. 그리고 일체식 애플리케이션은 단일 프로세스에서 실행된다. 사전에 성능을 감당하기 위해 스케일 업을 통해 용량을 증설해야 한다. 

 

마이크로서비스는 서버 측이 여러 개의 조각으로 구성돼 각 서비스가 별개의 인스턴스로 로딩된다. 각기 저장소가 다르므로 업무 단위로 모듈 경계가 명확하게 구분된다. 또 각 서비스가 독립적이어서 서로 다른 언어로 개발하는 것도 가능하므로 각 서비스의 소유권을 분리해 서로 다른 팀이 개발 및 운영할 수 있다. 

 

SOA와  마이크로서비스

 

모듈화 개념의 발전 흐름

구조적 방법론 -> 객체지향 밥법론 -> CBD -> 컴포넌트를 모아 비즈니스적으로 의미 있고 완결적인 서비스 단위로 모듈화하는 SOA(Service Oriented Architecture)

 

넓게 보면 여러 개의 응집된 비즈니스 서비스의 집합으로 시스템을 개발한다는 점에서 SOA와 MSA는 개념적으로는 큰 차이가 없다. 그러나 SOA는 구체적이지 않고 이론적이며, 실제 비즈니스 성공 사례가 많지 않았다. 반면 MSA는 클라우드 인프라 기술의 발전과 접목되어 아마존과 넷플릭스에 의해 구체화되고 비즈니스 성공 사례로 널리 공유된 바 있다. 

 

마틴 파울러 

 

마이크로서비스는 여러 개의 작은 서비스 집합으로 개발하는 접근 방법이다. 각 서비스는 개별 프로세스에서 실행되고, HTTP 자원 API 같은 가벼운 수단을 사용해서 통신한다. 

 

폴리글랏(Polyglot)하다

CBD/SOA의 접근법에서는 애플리케이션은 모듈별로 분리했으나 데이터 저장소까지는 분리하지 못했다. 

 

마이크로서비스를 위한 조건은 무엇인가? 

 

조직의 변화: 업무 기능 중심 팀

하나의 애플리케이션을 만드는 데는 세 팀 간의 의사소통이 필요하다. 따라서 시스템도 이러한 의사소통 구조를 그대로 반영하고, 이러한 팀 구조에서는 팀 간의 의사결정도 느리고 의사소통도 어렵다. 

업무 기능 중심 팀은 역할 또는 기술별로 팀이 분리되는 것이 아니라 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀이 되어 서비스를 만드는 것을 의미한다. 이 팀은 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 모두 갖추고 있다. 의사소통도 원활하고 의사결정도 빠르게 진행될 수 있다. 느슨한 연관관계를 맺는 마이크로서비스

 

 

개발 생명주기의 변화: 프로젝트가 아니라 제품 중심으로 

 

기존에는 대부분의 애플리케이션 개발 모델이 프로젝트 단위였다. 그래서 필요한 기술을 사용하는 인력들이 한시적으로 모여 장기간의 프로젝트를 통해 개발을 완료하고 나면 이를 운영 조직에 넘기는 방식으로 진행됐다. 즉, 개발 조직과 운영 조직이 분리돼 있다. 

비즈니스의 갑작스런 트렌드 변화에 유연하게 대처해야 하고 개발뿐만 아니라 운영을 포함한 소프트웨어의 전체 생명주기를 책임져야 한다. 따라서 소프트웨어를 완성해야 할 기능들의 집합으로 보는 것이 아니라 비즈니스를 제공하는 제품(product)으로 바라보고, 우선 개발한 뒤에 반응을 보고 개선하는 방식으로 소프트웨어를 개발환다. 

 

이 같은 방식은 약 2~3주 단위의 스프린트(Sprint)를 통해 소프트웨어를 개발 및 배포해서 바로 피드백을 받아 소프트웨어에 반영할 수 있게 해준다. 

 

즉, 마이크로서비스는 계속 피드백을 받아 지속적으로 변화, 개선되고 향상되는 존재다. 

 

개발 환경의 변화: 인프라 자동화

 

마이크로서비스는 독립적으로 배포된다. 

화려하게 등장한 이유는 클라우드라는 가상 인프라 발전에 기인한다. 

 

단기간에 제품을 빨리 개발하고 피드백을 받기 위해서는 이러한 개발지원 환경의 자동화가 반드시 갖춰져야 한다. 이 같은 환경은 개발과 운영을 동시에 수행하는 데브옵스를 궁극적으로 가능하게 하므로 데브옵스 개발 환경이라 속칭하기도 한다. 

인프라 자동화라고 하기도 한다. 마이크로서비스 개발 과정의 필수조건이 돼야 한다. 

이러한 빌드/배포 파이프라인 프로세스는 도구를 통해 자동화해야 한다. 

 

저장소의 변화: 통합 저장소가 아닌 분권 데이터 관리

 

마이크로서비스는 폴리글랏 저장소 접근법을 선택하며, 서비스별로 데이터베이스를 갖도록 설계한다. 즉, 각 저장소가 서비스별로 분산돼 있어야 하며, 다른 서비스의 저장소를 직접 호출할 수가 없고 API를 통해서만 접근해야 한다는 의미다. 

 

이러한 구조에서는 비즈니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요하다. 여기서 반드시 등장하는 문제가 있는데 , 데이터의 비즈니스 정합성을 맞춰야 하는 데이터 일관성 문제다. 

 

이를 해결하기 위해 두 서비스를 단일 트랜잭션으로 묶는 방법이 아닌 비동기 이벤트 처리를 통한 협업을 강조한다. 

 

위기 대응 방식의 변화: 실패를 고려한 설계

 

아마존의 부사장인 버너 보겔스는 '소프트웨어는 모두 실패한다'라고 말한 바 있다. 내결함성

실패하지 않는 시스템을 만드는 것보다 실패에 빠르게 대응할 수 있는 시스템을 만드는 편이 더 쉽고 효율적이다. 

이를 위해서는 다양한 실패에 대비해서 완벽히 테스트할 수 있는 환경을 마련해야 하고, 시스템의 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 한다. 이러한 예로 서킷 브레이커 패턴(회로 차단기 처럼 각 서비스를 모니터링하고 있다가 한 서비스가 다운되거나 실패하면 이를 호출하는 서비스 연계를 차단하고 적절하게 대응)

 

 

혁신의 동력이 단지 우수한 기술과 개인 역량에만 의존하는 것은 아니라는 점을 알 수 있다. 

다양한 사람들의 의견을 받아 나누는 논의 중에 진정 가치 있는 아이디어가 나오고, 협업을 통해 개발하며, 또 다른 사람들의 피드백을 통해 끊임없이 개선해야 하는 창의적인 활동이다. 

즉, MSA는 다양한 사람들이 만나서 협업하는 방식, 조직 문화의 진화된 결과물이라고 생각해야 한다.