[마이크로서비스 : 패턴과 핵심 기술] MSA 도입을 위한 역량 및 필요조건

< Microservices 도입 조건 >

 

MSA의 도입 필요 조건

MSA의 도입 조건은 크게 2가지로 나눠 볼 수 있다

• 사업/조직적 측면
• 기술적 측면

 

 

사업/조직적 측면

• MSA가 중장기적 Business benefit을 올릴 수 있다는 합의가 있어야 한다
  • MSA 도입 자체가 시간/비용 측면으로 지출이 있기 떄문이다
  • 따라서 MSA 도입으로의 이익이 보장되지 않으면 전환하기 힘들다
• 고위 경영진의 강력한 Commitment 및 용기
  • Jeff Bezos의 메일과 같이 MSA 도입을 위한 고위 경영진의 추진력이 필요하다
  • 잘 동작하는 시스템을 건드리기 싫은 두려움
• MSA 도입은 단순 기술 도입이 아닌 조직과 프로세스의 개선 작업이 필요하다
  • 비즈니스 역량에 기반한 조직 구성
  • 프로세스나 방법론의 개선 필요 -> ex) 애자일 방법론 도입
  • 조직의 구성이 아키텍처에 반영된다
• DevOps 문화가 정착되어야 한다
  • 데브옵스와 MSA는 밀접한 관련이 있다
  • 빠른 개발, 빌드, 배포를 위해 데브옵스 문화의 정착이 필요하다
• 사내 교육 및 학습을 위한 자원 투자가 필요하다
  • MSA 도입 과정에서 발생하는 문제들을 해결하기 위한 기술, 도구, 아키텍처, 프로세스 등을 조직에 내재화해두어야 성공적인 도입이 가능하다

 

 

기술적 측면

• Rapid Provisioning
  • 서비스 별로 빠른 sqaure 등의 MSA의 장점을 극대화하기 위해 필요하다
  • 클라우드 환경
  • 인프라 자동화, Docker/Kubernetes
• 정교한 Monitoring 및 장애 관리
  • MSA에서는 서비스가 분리되어 있기 때문에 모니터링이 보다 복잡해진다
  • 따라서 다양한 레벨의 모니터링이 필요하다
  • 모든 서비스에 대한 실시간 모니터링을 통해 한 서비스의 장애가 다른 서비스의 장애로까지 이어지는 것을 방지한다
• 자동화된 배포
  • MSA의 운영을 위해서는 수동 배포가 힘들다
  • End to end 배포 파이프라인 구축

 

 

 

MSA 언제 시작할까?

• MSA 도입 전, 장점과 단점을 제대로 파악해야 한다
• MSA의 장점
  • 빠르게 변화하는 비즈니스 환경에 민첩하게 대응 가능
  • 작은 서비스 단위로 확장 가능
  • 일부의 장애가 시스템 전체 장애로 이어지지 않음
  • 서비스 단위로 자율적 배포 가능
  • 서비스마다 적잘한 기술을 도입하여 Polyglot 적용
• MSA의 단점
  • 성능 - 내부 호출마다 느리다
  • 메모리 - jvm 등 중복적인 자원 사용
  • 모니터링 어려움
  • 배포 어려움
  • 장애 대응 어려움
  • 테스팅 어려움
  • 트랜잭션 처리 어려움
• 사실 도입 시기의 정확한 답은 없지만 아래의 경우를 모두 만족시키는 경우 도입한다
• MSA 도입 비용이 크다는 점을 인식한다
• MSA로 얻을 수 있는 Business benefit이 MSA의 단점보다 크다고 판단되었을 때 적용한다
• Monolithic에 단점들이 현재 Business에 미치는 부정적인 영향이 너무 클 때
  • 시스템의 Scale Out 비용이 큼
  • 빌드/배포 시간이 오래걸려서 잦은 배포가 어려움
  • 작은 버그에도 시스템 전체 실패가 가능함
  • 코드 수정 시 영향도 파악이 어려움

 

 

 

MSA 도입 전, 던져봐야 할 질문

• SW와 관련된 현재 조직의 문제 및 목표는 무엇인가?
• MSA가 조직의 문제 및 목표를 어떻게 해결해줄 수 있는가? -> 현재 문제를 MSA 도입으로 해결이 가능한가?
• 추가적인 리소스(비용/인력)를 투입할 수 있는 여력이 있는가?
• 조직의 Engineering 역량이 MSA를 도입할 만큼 충분한가? -> 부족한 경우 교육 및 신기술 내재화 필요

 

 

 

MSA 도입은 어떻게 시작하는 것이 좋은가?

• 처음부터 전부 MSA로 전환하려고 시도하는 것은 금물
  • MSA 전환 작업 자체가 굉장히 복잡도가 높은 작업이다
  • 기존 Monolithic 서비스의 크기가 굉장히 크고 각각의 기능의 결합도가 높은 상태일 가능성이 크다
  • 이를 한번에 MSA로 분리하면 결합도가 높아지게 된다
• 작게 시작해야 한다
  • Monolithic 시스템에서 작은 일부 기능부터 분리한다
  • 신규 기능을 새로운 마이크로 서비스로 개발한다
• 조직 내에서 첫 성공을 경험하는 것이 중요하다
  • 분리하는 과정에서 수많은 장애들을 맞닥뜨릴 가능성이 크다
  • 따라서 이를 분리하는 과정에서 경험을 쌓고 중요한 기능들을 서비스로 분리해나가야 한다

 

 

 

어떤 부분부터 분리할까?

• 비즈니스 변화에 민첩하게 대응해야 하는 기능
• 요구사항 변경이 빈번하여 빌드/배포를 자주해야 하는 기능
  • 모노리틱 시스템에서는 하나의 기능때문에 전체 시스템을 빌드/배포 하는 경우가 있다
  • 따라서 변경이 빈번한 서비스 먼저 분리하면 전체 서비스를 빌드/배포할 일이 적어진다
• 유연한 수평 확장이 필요한 기능
• 그러나 가장 처음에는 중요도가 낮고 작은 모듈부터 분리해야 한다

 

 

 

MSA는 필수인가?

• 아니다!
• 많은 상황에서 Monollithic도 충분히 좋은 경우가 있다
• MSA의 선택은 기술의 문제가 아니다
• MSA로의 전한 비용은 상당히 높기 때문에 무조건적으로 전환할 필요는 없다
• Business benefit 증가의 확신이 드는 경우에 MSA를 도입하는 것이 좋다

 

 

 

은탄환은 없다

• There is no silver bullet - Fred Brooks
  • 한 번에 늑대인간을 죽일 수 있는 은탄환은 없다
  • 즉, 모든 것을 만족시키는 SW는 존재하지 않는다는 명언이다
  • 장점이 존재하면 단점 또한 반드시 존재한다
• MSA를 도입하면 현재 겪고 있는 문제가 모두 해결된다? ❌
• MSA도 하나의 대안일 뿐이다
• MSA가 모든 문제를 해결해 주지 않는다
• 오히려 많은 종류의 새로운 문제를 만들어 내기도 한다
• Architecture Trade Offs
  • 모든 SW 아키텍처는 장/단점이 존재한다
  • 따라서 모든 장단점을 고려하여 SW 아키텍처를 선택해야 한다
• MSA와 Monolithic도 명확한 장/단점이 존재한다
• Monolithic의 모든 장점을 그대로 살리면서 MSA를 도입하는 것은 불가능하다
• 모든 것을 다 만족시키는 Super Architecture는 없다

 

 

 

Microservice are not the goal

• Microservice는 선택 가능한 대안이지 그 자체가 목적이 아님을 명심하자!
• Microservice를 통해 이루고자 하는 목적을 확실하게 이해하고 있어야 한다
• 가장 위험한 생각 : MSA가 Netflix에서도 잘 맞았으니, 우리 시스템에도 좋겠지!
• 절대 아니다.

 

---

< Microservices의 역량 모델>

 

마이크로 서비스 역량 모델

• 마이크로 서비스는 최신 기술이고, 현재도 발전하는 중이기 때문에 표준 아키텍처나 표준 역량 모델이 부재이다
• 벤더 사 및 도서 등에서 역량 모델을 제공하지만, 벤더 사에 맞춘 모델이기 때문에 표준 모델이라고 보기 어렵다
• MSA를 도입하고 운영하기 위한 역량 모델
• 현재 강의에선 Rajesh RV가 제안한 역량 모델을 소개한다
• https://www.amazon.com/-/ko/gp/product/B01N3YVPJH/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i1

Rajesh RV가 제안한 역량 모델

 

 

 

역량 분류

• 핵심 역량
  • 없으면 안되는 역량 (like 물)
  • 서비스 별 배포되는 SW 패키지에 필수 요소
  • ex) 엔드포인트, 데이터 베이스 등..
• 지원 역량
  • 지원 기술 및 설계 패턴 (like 비타민)
  • 필수적이진 않지만 없는 경우 MSA 운영 및 도입이 힘들 수 있다
  • 장기적으로 봤을 때 필수적인 역량
• 인프라스트럭처 역량
  • 컨테이너 및 컨테이너 오케스트레이션
• 프로세스 및 통제 역량
  • Devops 및 문서화 등

 

 

 

핵심 역량

• 단일 서비스 내에 패키징 되는 SW 컴포넌트들
• 당연히 있어야 하는 컴포넌트들이다
  1. 서비스 Listener
  2. Endpoint
  3. 서비스의 구현 (Application)
  4. 데이터 저장

 

 

1. 서비스 Listener - 핵심 역량

• HTTP 등의 Listener가 애플리케이션에 내장되어 있어야 한다
  • Web Server, Web Application Server
  • Spring Boot와 같은 Self Contained 방식이 필요하다
• 이전에는 tomcat 등의 WAS가 설치되어 있고 앱을 WAS에 배포하는 형식이었다
• MSA의 민첩한 배포, 운영의 장점을 살리기 위해서는 자체 내쟝형 Listenr가 필요하다 (설치 과정 단축)

 

 

2. Endpoint - 핵심 역량

• HTTP 요청을 받아 처리할 API가 애플리케이션 내부에 있어야 한다
• 다양한 프로토콜 사용이 가능하다
• 동기/비동기 방식 모두 가능하다

 

 

3. 서비스 구현 - 핵심 역량

• 각 서비스의 핵심 로직의 구현
• 서비스의 로직은 단일 책임의 원칙을 지켜야 한다
• 서비스 로직은 최대한 응집도 높게 구현되어야 한다
• 계층형 아키텍처를 사용하는 것이 좋다
• Hexagonal architecture (육각형 아키텍처)
  
  • Ports and Adapters Pattern으로 2005년에 처음으로 소개되었다
  • Application을 외부 기술과 분리시키는 패턴
  • 비즈니스 핵심 로직이 외부 시스템에 영향을 받지 말아야 한다
  • 모바일/웹 등 UI에 따라서도 외부 시스템에 영향을 받지 말아야 한다

hexagoanl architecture

스프링에서 제공하는 hexagonal architecture

 

 

 

4. 데이터 저장 - 핵심 역량

• 각 서비스마다 상태나 데이터를 저장할 데이터소스가 있어야 한다
• 데이터 소스는 하나의 서비스에 한정되어야 한다
• 다양한 기술을 이용 가능 - Polyglot Persistence, NoSQL

 

 

 

인프라스트럭처 역량

성공적인 MSA 구축/운영을 위해서는 인프라 역량이 필수적이다

1. 클라우드
2. 컨테이너 런타임
3. 컨테이너 오케스트레이션

 

 

 

1. 클라우드 - 인프라 역량

• 전통적인 인프라 구성
  • On Premise
  • 데이터 센터
  • 이러한 환경에서는 탄력적으로 자원을 확장하기가 어렵다
  • 트래픽으로 인해 서버 증설이 필요한 경우에도 바로바로 증설이 어렵다
• 전통적인 프로세스
  • 장기 수요 예측
  • 용량 산정
  • 하드웨어 주문
  • 데이터 센터 입고
  • OS 설치, 네트워크 설정...
• 클라우드 인프라 구성
  • On Demand
  • 트래픽이 몰려와서 추가적인 서버 자원이 필요할 때마다 추가 사용이 가능하다
  • 대용량 확장 가능한 환경
• 몇 번의 클릭만으로 리소스 사용이 가능하다
  • Auto Scaling으로 자동화 된 Provisioning
• 다양한 자원/서비스 제공
  • 컴퓨팅 자원, DB, NoSQL, Big Data, AI

 

 

 

2. 컨테이너 런타임 - 인프라 역량

• 각 서비스들이 다양한 기술을 사용할 수 있다
  • 각 기술마다 배포 방법이 달라지기 떄문에 인프라 역량이 필요하다
• 수백/수천 개+ 의 인스턴스에 배포해야 한다
• 컨테이너 기술을 이용하여 빠른 환경 구성 및 배포가 필요하다
  • 컨테이너 이미지에는 런타임과 코드가 동시에 존재한다
  • 별도의 설정 없이 환경 설정 및 배포가 가능해진다
• Docker, ...

 

 

 

3. 컨테이너 오케스트레이션 - 인프라 역량

• 많은 수의 컨테이너의 관리 역량이 필요하다
  • 각 서비스 하나당 컨테이너 한 개를 사용하게 된다 (컨테이너 ~= 인스턴스)
  • 따라서 각 서비스에 따른 컨테이너를 관리할 수 있어야 한다
• 배포, 모니터링, 장애 관리 등 운영 관리 비용을 최소화하기 위함
• Kubernetes, ECS, Mesos/Marathon

 

---

< Microservices 역량 모델 2 >

 

지원 역량

• 이 요소들이 없어도 MSA 사용이 불가능한 것은 아니지만, 실제로는 거의 사용을 못하는 수준에 이른다
• 즉, 필수는 아니지만 운영하려면 반드시 필요하다
• 종류
  1. Service Discovery
  2. Config Server
  3. API Gateway
  4. SW Defined Load Balancer
  5. Circuit Breaker
  6. Distributed Tracing
  7. Data Lake
  8. Messaging

 

 

1. Service Discovery - 지원 역량

• MSA를 도입하면 서비스 개수 및 인스턴스 개수가 급증할 수 있다
• 전체 Topology가 복잡해진다
• 한 서비스에서 다른 서비스를 호출 시 물리적인 정보를 유지하는 것이 비효율적이다
• ex) 서비스 A의 ip 값들을 유지하는 것은 비효율적임 (바뀔 수도 있으니까)
• 중앙에서 시스템의 모든 서비스에 대한 정보를 유지한다
• 새로운 인스턴스가 생성되면 중앙 에이전트에게 자신의 정보를 등록한다
• 서비스 간에는 다른 서비스의 물리적인 주소를 유지하지 않는다
• 유연하게 인스턴스 및 서비스를 추가/삭제가 가능해진다

service discovery

 

 

 

2. Config Server - 지원 역량

• 기존에는 설정 정보를 자체 설정 파일이나 OS 환경 변수로 관리한다
• MSA를 도입하면 설정 관리가 복잡해진다
• ex) 20개 서비스 X 5개 환경 (개발, Staging, QA 환경 등) => 100개의 설정 파일 필요
• 환경마다 매번 새롭게 빌드/패키징을 해야하는 문제가 있다
• 서비스의 인스턴스가 100개면? -> 100개 모두 재배포가 필요해진다
• 설정 파일이 잘못 관리되면 서비스 장애 발생 가능성이 높아진다
• 이러한 문제를 해결하기 위해 Config Server는 설정 정보를 Application 파일에서 완전히 분리한다
• 중앙 Config Server에서 설정을 관리한다
• 저장 Backend로는 Git, DBMS를 사용하낟
• 서비스는 Application 기동될 때 중앙 서버에서 Config 정보를 Fetch한다
• 설정 정보 변경 시 서비스 재배포 없이 반영이 가능하다

 

 

 

3. Service Gateway - 지원 역량

• 다양한 서비스들에 대한 단일 진입점을 제공한다
• 인증, 인가, 로깅, 필터링 등의 공통 처리 로직을 수행한다
• 서비스에 문제 발생 시 요청을 차단하거나 대안 경로로 변경하는 등의 기능을 수행한다

 

 

 

4. SW Defined Load Balancer - 지원 역량

전통적인 로드 밸런서 vs MSA 로드 밸런서

• MSA에서는 인프라 토폴로지가 매우 복잡해진다
  • 서비스/인스턴스 개수가 많고 서비스 간 의존성이 복잡해진다
  • 인스턴스들의 제거, 생성이 매우 빈번하게 일어난다
• 따라서 MSA에서 전통적인 로드밸런서 사용은 비효율적이다
• 서비스를 호출하는 클라이언트에서 SW로 Load Balancing을 수행한다

 

 

 

5. Circuit Breaker - 지원 역량

• 서비스의 장애는 언제든지 발생 가능하고, 장애 방지 설계가 필요하다
• MSA에서 한 서비스의 장애는 다른 서비스들에 전파되어 결국 전체 시스템 장애로 이어질 수 있다
• 특정 서비스의 장애는 그 서비스 만의 장애로 격리해야 한다
• 따라서 서비스 간의 Circuit Breaker라는 컴포넌트가 삽입된다
• 특정 서비스의 장애가 발생했다고 판단되면 Circuit Breaker에 의해 Circuit이 차단된다

 

 

 

6. Distributed Tracing - 지원 역량

• 하나의 API 호출이 다양한 서비스에 분산되므로 에러 추적이 어렵다
• 장애 발생 시 어떤 서비스에서 장애가 시작되었는지 판단이 어렵다
• 서비스 간 모든 호출에 추적 ID를 삽입한다
• 추적 ID를 Key로 하여 단일 API 트랜잭션의 활동을 파악한다

 

 

 

7. Date Lake - 지원 역량

• MSA에서는 데이터 파편화 가능성이 존재한다
• 각각의 서비스들이 발생시키는 비정형 원시 데이터를 그대로 저장한다
  • 대용량 비정형 데이터 저장, 처리 기술 발달로 인해 가능해졌다 -> Hadoop, HDFS
• 데이터를 저장할 때가 아닌 분석할 시점에 데이터 가공에 대한 고민을 하게 된다
• 전통적인 ETL이 아닌 실시간 Data Ingestion 도구를 사용한다
  • Flume, Kafka, Logstash...

 

 

 

8. Messaging - 지원 역량

• MSA는 메시징을 이용한 서비스 간 협력 설계 방식을 권고한다 -> 동기 보단 비동기 방식을 권고
• 메시징(이벤트) 주도 설계는 서비스 간 결합도를 낮출 수 있다 (비동기 방식)
• 고가용성의 메시징 솔루션이 필요하다
• RabbitMQ, ActiveMQ, Kafka, AWS Kinesis

 

 

 

프로세스 및 통제 역량

1. DevOps
2. 자동화 도구
3. 컨테이너 레지스트리
4. 문서화
5. 참조 아키텍처 및 라이브러리

 

 

1. DevOps - 프로세스 및 통제 역량

• 애자일과 DevOps는 MSA 성공을 위한 필수 요소 중 하나이다
• 지속적 통합, 자동화된 배포, 자동화 된 QA 등이 필요하다
• DevOps 조직을 구성하여 한 팀에서 개발, 배포, 운영, 모니터링이 되어야 한다
• 애자일을 도입하여 짧은 개발 주기로 반복적으로 개발하여 빠르게 delivery해야 한다

 

 

2. 자동화 도구 - 프로세스 및 통제 역량

• 다수의 이기종 서비스를 테스트 및 배포/운영해야하기 때문에 자동화 도구가 필수적이다
• 테스트 자동화
• 배포 자동화
• 모니터링 및 경보 자동화

 

 

3. 컨테이너 레지스트리 - 프로세스 및 통제 역량

• MSA에서 컨테이너 사용은 필수적이다
• 컨테이너의 핵심인 이미지 등의 관리가 필요하다
• 코드 형상 관리와 유사하다
• Docker Hub, GCCR, ECR...

 

 

문서화

• 서비스들은 인터페이스를 통하여 통신한다
• 따라서 인터페이스의 문서화가 중요하다
• 일반 Method 호출보다 복잡하기 때문에 다양한 정보가 들어 있어야 한다
  • 필수/선택 파라미터
  • 버전
  • 응답정보
  • 에러코드
• 웹으로 쉽게 열람할 수 있어야 한다
• Spring REST Docs, Swagger...

 

 

 

참조 아키텍처 및 라이브러리

• 탈중앙화된 방식은 비효율성을 야기할 수 있다
  • 서로 다른 아키텍처로 인한 유지 보수성 악화
  • 동일한 기능의 재개발이 발생할 수 있다
• 조직의 기술별 참조 모델이 중요하다
  • 참조 아키텍처는 프레임워크화 할 수도 있다
• 중복 개발을 막기 위해 사내 오픈소스 라이브러리 활동을 하기도 한다
  • 검색이 가능해야 한다
  • 개발한 경우 보상이 이뤄지기도 한다

 

MSA의 역량 모델

---

< Microservices 성숙도 모델 >

 

MSA 성숙도 모델

• 조직의 성숙도 상태를 진단
• 현재 우리의 단계는 어디인가 판단 가능한 모델
• 다음 단계로 가려면 무엇을 해야할지에 대한 길잡이가 될 수 있다
• 현재까지는 MSA를 위한 표준 성숙도 모델은 없다
• de facto 모델도 부재
• 논문, 저서, 벤더 등에서 각자의 성숙도 모델을 발표하였다
• 여기서는 2개의 성숙도 모델을 소개한다
  • Rajesh RV가 제안한 성숙도 모델
  • Rishi Singh가 제안한 성숙도 모델 

 

 

 

Rajesh RV 제안 성숙도 모델

 

 

 

Rishi Singh 제안 성숙도 모델

• 총 9가지 영역에서 4단계의 성숙도 모델 제안
• 4단계 : Early, Inception, Expanding, Mature
• Expanding 단계가 현실적인 MSA 수준
• Mature는 다소 이상적인 수준

 

 

 

Functional Decompostion (기능적 분할 영역)

• Early : Business 역량에 따른 기능 분, 기능들이 결합도 높게 합쳐진 상태
• Inception : Modular Monolith, 서비스간 명확한 Interface
• Expanding : 도메인 주도 설계에 의한 잘 분할된 서비스
• Mature : 이벤트 기반의 협력, 조회와 명령의 분할 (CQRS)

 

 

 

Data 영역

• Early : 서비스 간 저장소 공유, ACID 기반 Transaction
• Inception : 일부 새로운 서비스들에 대한 독립된 저장소
• Expanding : 모든 서비스들의 독립적인 저장소, Polyglot Persistence, Eventual Consistecy
• Mature : Event 기반 데이터 관리, Event Sourcing, CQRS

 

 

 

Testing 

• Early : 수동/자동 Testing 혼재
• Inception : 완전 자동화된 Testing 수행
• Expanding : Chaos Engineering (일부러 장애를 유발하는 테스팅)
• Mature : Consumer Driven Contract, 고객 페르소나 기반 E2E Testing

 

 

 

Infrastructure 영역

• Early : Continuous Intergration/Build
• Inception : Continuous Deployment, 중앙 집중형 Logging
• Expanding : Container/Orchestration, 설정 외부화
• Mature : 완전 자동화된 Privisioning 지원하는 PaaS

 

 

 

Deployment 영역

• Early : Script 기반, 호스트 당 다중 서비스 배포
• Inception : VM 당 단일 서비스 배포
• Expanding : Container 당 단일 서비스 배포, Immutable Infra (새롭게 배포되면 기존 자원들은 삭제되고 새롭게 배포되는 버전의 자원이 구성됨), Blue/Green Deployment(기존 버전과 새로운 버전이 공존함)
• Mature : Multi-Datacenter 배포

 

 

 

Monitoring

• Early : Application Performance Monitoring (APM)
• Inception : Centralized Logging System (APM + 중앙화된 로깅 시스템)
• Expanding : Container Monitoring (컨테이너에 배포된 서비스 모니터링)
• Mature : Distributed Tracing (다중 서비스 간의 서비스 추적), Trace as a Service (클라우드에서 제공되는 서비스), Synthetic Transaction (자동화된 시나리오로 테스트 하고 모니터링함)

 

 

 

Governance 영역

• Early : 중앙집중화된 Governance
• Inception : 일부 Monolith, 일부 Microservices의 Shared Covernance Model로 과도기적 형태
• Expanding : 완전한 분산된 Governance
• Mature : 참조 아키텍처 및 참조 방법론 등의 지원 (약간의 중앙집중화를 포함하여 효율성 증가)

 

 

 

Team Structure 영역

• Early : Dev, AQ, Ops 등 기술별 조직
• Inception : 일부 Cross Functional 팀 (과도기적 형태)
• Expanding : 제품 기반 개발팀(기획, 디자인, 개발, QA) 과 이를 지원하는 Platform팀 (운영, 모니터링 등)
• Mature : 완전한 제품 기반 DevOps 팀 (팀별 서비스 운영)

 

 

 

Architecture 영역

• Early : ESB를 사용하는 SOA 기반의 아키텍처 또는 Modular Monolith 구조
• Inception : Monolith 시스템에 신규 기능을 Microservice로 개발하는 과도기적 형태
• Expanding : 모든 비즈니스 기능이 Microservice로 분리되어 서로 Network 인터페이스로 협력
• Mature : Event 기반, Serverless 도입