[MSA] 도메인 주도로 설계하는 마이크로서비스 개발 - 1장

회사에서 신규로 MSA 개념을 도입하여 시스템을 설계하는 팀에 투입되게 되었다. 

MSA 라는 개념 자체가 처음이라 기본적인 개념을 이해하는 것이 필요할 것 같아 정리해보는 글. 

 

<도메인 주도로 설계하는 마이크로서비스 개발> 이라는 책을 참고하여 정리하려고 한다. 

 

 

 도메인 주도로 설계하는 마이크로서비스 개발

http://book.naver.com/bookdb/book_detail.naver?bid=18832445

도메인 주도 설계로 시작하는 마이크로서비스 개발

---

 1장.아마존 비즈니스 민첩성의 비밀

1장. 아마존 비즈니스 민첩성의 비밀

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

  1.1.1 성공사례 : 아마존의 배포 속도 

    - "11.6초" : 아마존의 비즈니스 서비스가 배포되는 주기 (2011년 Velocity 컨퍼런스에서 언급된 숫자)

    -> 2019년 국내 AWS 컨퍼런스 기준 초당 1.5번으로 서비스 배포 주기가 빨라짐 

    - 비즈니스 민첩성을 지원할 수 있는 인프라와 애플리케이션이 등장한 것이 원인

 

  1.1.2 클라우드 인프라의 등장

     - 전형적인 시스템 인프라 구축 과정 : 서버 도입 - 네트워크 구축 - 각 서버마다 OS, S/W 설치. 며칠에서 몇주가 소요

    - 클라우드 인프라의 등장으로 필요한 시점에 몇 번의 클릭으로 손쉽게 인프라 구축 가능 

       (아마존의 AWS, 마이크로소프트의 Azure, 구글의 CGP 등)

 

  1.1.3 클라우드 인프라에 어울리는 애플리케이션의 조건 

    - 클라우드 인프라 사용시 사용량에 따라 비용을 유연하게 조정할 수 있다

    * 스케일 업과 스케일 아웃

     - 스케일 업 (수직확장) : 기존 시스템 자체의 물리적 용량을 증가시켜 성능을 높이는 방법

     - 스케일 아웃 (수평 확장) : 기존 시스템과 용량이 같은 다수의 장비를 병행 추가해서 가용성을 높이는 방법   

    * 클라우드 프렌들리와 클라우드 네이티브 

     - 클라우드 프렌들리 애플리케이션 : 큰 덩어리로 클라우드 환경에 올라갈 수 있게만 한 애플리케이션

     - 클라우드 네이티브 애플리케이션 : 독립적으로 분리되어 배포될 수 있는 조각으로 구성된 애플리케이션

  시스템이 비즈니스 민첩성을 잘 지원하기 위해서는 클라우드 인프라를 효율적으로 활용하도록 애플리케이션 조각으로 구성된 클라우드 네이티브 애플리케이션이 가장 효과적이다. 

 

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

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

   - 모노리스 : 하나의 단위로 개발되는 일체식 애플리케이션으로 보통 3 티어로 구성된다 (3티어라 불리는 사용자 인터페이스와 데이터베이스, 서버 쪽 애플리케이션)

   - 확장이 필요한 경우 특정 기능만 확장할 수 없고 반드시 전체 애플리케이션을 동시에 확장해야 한다. 보통 로드 밸런서를 앞에 두고 여러 인스턴스 위에 큰 덩어리를 복제해 수평으로 확장하는 형태가 된다. 

   - 이런 상황에서 변경이 발생하면? 여러 개의 모노리스가 수평으로 확장된 상태이므로 여러 개의 모노리스 시스템 모두를 전부 다시 빌드하고 배포해야 함. 또한 데이터베이스는 하나이므로 탄력적 대응이 불가하여 사전에 스케일 업을 통해 용량을 증설해야 한다. 

  - 마이크로서비스 : 여러 서비스 인스턴스가 모여 하나의 비즈니스 애플리케이션을 구성. 각기 저장소가 다르므로 업무 단위로 모듈 경계가 명확하게 구분된다. 

  - 확장 시 특정 기능별로 독립적으로 확장할 수 있고, 특정 서비스를 변경할 필요가 있다면 해당 서비스만 빌드해서 배포하면 된다. 

  - 각 서비스가 독립적이므로 서로 다른 언어로 개발하는 것도 가능하므로 각 서비스의 소유권을 분리해 서로 다른 팀이 개발 및 운영할 수 있다. 

 

  1.2.2. SOA와 마이크로 서비스 

  - 모듈화 개념의 발전 흐름 : 구조적 방법론 -> 객체지향 방법론 -> CBD -> SOA 

  - 넓게 보면 여러개의 응집된 비즈니스 서비스의 집합으로 시스템을 개발한다는 점에서 SOA와 MSA는 개념적으로 유사하다. 이상적이었지만 성공을 증명하지 못했던 SOA가 클라우드 인프라의 등장으로 하드웨어를 유연하게 다룰 수 있게 되면서 비로소 실현되어 성공적으로 증명된 시스템 구조가 MSA이다. 

  - 마틴 파울러가 정의한 마이크로서비스 "마이크로서비스는 여러 개의 작은 서비스 집합으로 개발하는 접근 방법이다. 각 서비스는 개별 프로세스에서 실행되고, HTTP 자원 API 같은 가벼운 수단을 사용해서 통신한다. 또한 서비스는 비즈니스 기능 단위로 구성되고, 자동화된 배포 방식을 이용하여 독립적으로 배포된다. 또한 서비스에 대한 중앙 집중적인 관리는 최소화하고, 각 서비스는 서로 다른 어넝와 데이터, 저장 기술을 사용할 수 있다." 

  - 폴리클랏(Polyglot)하다 : 특정 서비스를 구축하는 데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식 

  - CBD/SOA의 접근법에서는 애플리케이션은 모듈별로 분리했으나 데이터 저장소까지는 분리하지 못했지만 MSA에서는 아래의 두 가지 개념으로 모듈화 방식을 강화하며 실현했다. 

    1. 서비스별 저장소를 분리해서 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화한다. 즉, 다른 서비스의 저장소에 접근하는 수단은 API밖에 없다. 

    2. REST API 같은 가벼운 개방형 표준을 사용해 각 서비스가 느슨하게 연계되고 누구나 쉽게 사용할 수 있다. 

 

 

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

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

    - 콘웨이 법칙 : 시스템을 개발할 때 항상 시스템의 모양이 팀의 의사소통 구조를 반영하는 것

    - 과거에는 하나의 애플리케이션을 만드는데 UI팀, 서버개발팀, DB팀과 같이 기술별로 팀이 나눠져 있음. 팀 간의 의사결정도 느리고 의사소통도 어려움

    - 마이크로서비스팀은 업무 기능 중심의 팀이어야 한다. 다양한 역할 (기획자, 디자이너, 개발자, 설계자, 테스터 등)로 구성되고, 이 팀은 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 모두 갖춘다. 이 팀은 Cross-Functional Team 이라고도 부른다. (아마존에서는 'two-pizza team' 이라고 부른다. 피자 두판으로 함께 식사할 수 있는 정도의 인원수) 

 

  1.3.2 관리체계의 변화 : 자율적인 분권 거버넌스, 폴리글랏

   - "You built it, you run it."

   - 마이크로서비스팀으로 구성된 조직은 빠르게 서비스를 만드는 것을 최우선 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아 적용한다. 

 

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

   - 마이크로서비스팀의 개발은 비즈니스의 갑작스런 트렌드 변화에 유연하게 대처해야 하고 개발뿐만 아니라 운영을 포함한 소프트웨어의 전체 생명주기를 책임져야 한다. 즉 제품 중심의 애자일(agile) 개발 방식을 채용한다. 

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

 

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

   - 개발과 운영을 동시에 수행하는 데브옵스 개발환경, 인프라 자동화가 전제되는 것이 마이크로서비스 개발 과정의 필수 조건이다. 

 

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

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

   - 그런데 이러한 구조에서 반드시 등장하는 문제가 각 저장소에 담긴 데이터의 비즈니스 정합성 이슈이다. 이때 비동기 이벤트 처리를 통한 협업을 강조한다. 

   - 결과적 일관성 (Eventual Consistency) : 두 서비스의 데이터가 일시적으로 불일치하는 시점에 있고 일관성이 없는 상태지만 결국에는 두 데이터가 같아진다는 개념. 즉, 여러 트랜잭션을 하나로 묶지 않고 별도의 로컬 트랜잭션을 각각 수행하고 일관성이 달라진 부분은 체크해서 보상 트랜잭션으로 일관성을 맞추는 개념 

 

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

   - 다양한 실패에 대비해서 완벽히 테스트할 수 있는 환경을 마련해야 하고, 시스템의 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 한다 (ex. 서킷 브레이커 패턴, 넷플릭스의 카오스 몽키)