공부는 해도 해도 끝이 없구먼

Rajesh RV 역량 모델

- 핵심 역량

- 지원 역량

- 인프라스트럭처 역량

- 프로세스 및 통제 역량

1. 핵심 역량 : 서비스 별 배포 되는 SW 패키지에 필수 요소

    <단일 서비스 내 패키징 되는 SW 컴포넌트들>

    - 서비스 Listener :

        - HTTP 등의 리스너가 애플리케이션에 내장되어 있어야 함 (Ex. Spring Boot와 같은 Self Contained 방식 필요)

    - EndPoint :

        - HTTP 요청을 받아 처리 할 API가 애플리케이션 내부에 있어야 함

        - 다양한 프로토콜 및 동기/비동기 등 사용 가능

    - 서비스 구현 :

        - 각 서비스의 핵심 로직을 구현

        - 응집도 높고 단일 책임의 원칙을 지켜야 함

        - 외부 시스템에 영향을 받으면 안됨.  =>Spring Data, Spring Message 등으로 해결

        - 계층형 아키택처 사용 권고

    - 데이터 저장 :

        - 각 서비스 마다 상태나 데이터를 저장할 데이터 소스가 있어야 함

        - 데이터 소스는 하나의 서비스에 한정 되어야 하고, 다양한 기술을 이용 가능 (Ex. Polyglot Persistence, NoSQL 등)

2. 지원 역량 : 지원 기술 및 설계 패턴

    - Service Discovery :

        - 서비스/인스턴스 개수가 많아 복잡해져 생기게 됨

        - 물리적인 정적인 정보를 동적으로 바꾸게 함

        - 서비스 간에 다른 서비스의 물리적인 주소를 유지하지 않음

        - 유연하게 인스턴스 및 서비스를 추가 삭제 가능함

    - Config Server :

        - 설정정보를 애플리케이션에서 완전히 분리.

        - 중앙 Config에서 설정관리, 저장 백엔드로는 Git, DBMS사용.

        - 설정정보 변경 시 서비스 재배포 없이 적용 가능

    - Service Gateway :

        - 다양한 서비스들에 대한 단일 진입점

        - 인증, 인가, 로깅, 필터링 등의 공통 처리 수행

    - SW Defined Load Balancer

        - MSA에서는 인프라 토폴로지가 매우 복잡

        - 서비스를 호출하는 클라이언트에서 SW로 로드밸런서 수행

    - Circuit Breaker

        - 서비스의 장애는 언제든 발생 가능하고 장애 방지 설계 필요

        - 한 서비스의 장애는 다른 서비스들에 전파되어 전체 시스템 장애로 이어질 수 있음

        - 특정 서비스 장애는 그 서비스만의 장애로 격리

        - 서비스 간의 Circuit Breaker라는 컴포넌트가 삽입 됨 (장애발생 판단되면 Circuit 차단)

    - Distributed Tracing

        - 서비스 간 모든 호출에 추적 ID를 삽입

        - 추적 ID를 Key로 하여 단일 API 트랜잭션의 활동을 파악

    - Data Lake

        - MSA에서는 데이터 파편화 가능성 존재

        - 비정형 원시 데이터를 그대로 저장

        - 데이터 분석 할 시점에 데이터 가공에 대해 고민

        - 실시간 이용 (Kafka 등)

    - Messaging

        - 메시징을 이용한 서비스 간 협력 설계 방식을 권고

        - 메시징은 서비스 간 결합도를 낮출 수 있음

        - 고가용성 메시징 솔루션이 필요

3. 인프라스트럭처 역량 : 컨테이너 및 컨테이너 오케스트레이션

    - 클라우드 :

        - On Demand

        - 대용량 확장 가능한 환경

        - 몇 번의 클릭만으로 리소스 사용 가능 (Ex. Auto Scaling으로 자동화된 Provisioning)

        - 다양한 자원/서비스 제공 (자원, DB, AI etc)

    - 컨테이너 런타임 :

        - 컨테이너 기술을 이용하여 빠른 환경 구성 및 배포 가능

        - 컨테이너 이미지는 런타임 코드가 동시에 존재 (Docker, etc)

    - 컨테이너 오케스트레이션 :

        - 많은 수의 컨테이너 관리 가능

        - 배포/모니터링 비용 최소화 (Kubernetes, ECS, Mesos/Marathon etc)

4. 프로세스 및 통제 역량 : 데브옵스 및 문서화

    - DevOps

        - 에자일과 DevOps는 MSA 성공을 위한 필수 요소 중 하나

        - 지속적 통합, 자동화된 배포, 자동화된 QA

        - 에자일 도입하여 짧은 개발주기로 반복적으로 개발하여 빠르게 Delivery

    - 컨테이너 레지스트리

        - MSA에서 컨테이너는 필수적

        - 컨테이너의 핵심인 이미지 등의 관리 필요

        - 코드 형상 관리와 유사

        - Docker Hub, GCR... etc

    - 문서화

        - 서비스들은 인터페이스를 통하여 통신

        - 인터페이스의 문서화가 중요

        - 일반 Method 호출보다 복잡하기 때문에 다양한 정보가 들어 있어야함 (필수/선택 파라미터, 버전, 응답정보 등)

        - 웹으로 쉽게 열람할 수 있어야 함

        - Spring REST Docs, Swagger 등

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

        - 탈중앙화된 방식은 비효율성을 야기할 수 있음

        - 조직의 기술별 참조모델 중요 -> 프레임워크화 할 수도 있음

Rajesh RV 성숙도 모델

Rishi Singh 성숙도 모델

- 총 9가지 영역에서 4단계의 성숙도 모델 제안

- 4단계 : Early, Inception, Expanding, Mature

- Expanding 단계가 현실적인 MSA 수준

- Mature는 다소 이상적인 수준

1. 기능적 분할 영역

    - Early : Business 역량에 따른 기능 분할

    - Inception : Modular Monolith, 서비스간 명확한 Interface

    - Expanding : 도메인 주도 설계에 의한 잘 분할 된 서비스

    - Mature : 이벤트 기반의 협력, 조회와 명령의 분할

2. Data 영역

    - Early : 서비스간 저장소 공유, ACID 기반 트랜잭션

    - Inception : 일부 새로운 서비스들에 대해 독립된 저장소

    - Expanding : 모든 서비스들의 독립적인 저장소

    - Mature : Event 기반 데이터 관리, 이벤트소싱 CQRS

3. Testing 영역

    - Early : 수동/자동 Testing 혼재

    - Inception : 완전 자동화된 Testing 수행

    - Expanding : Chaos Enginerring

    - Mature : Consumer Driven Contract, 고객 페르소나 기반 E2E Testing

4.  Infrastructure 영역

    - Early : Continuous Integration/Buid

    - Inception : Continuous Deployment, 중앙집중형 Logging

    - Expanding : Container/Orchestration, 설정 외부화

    - Mature : 완전 자동화 된 Provisioning 지원하는 PaaS

5.  Deployment 영역

    - Early : Script 기반, 호스트 당 다중 서비스 배포

    - Inception : VM 당 단일 서비스 배포

    - Expanding : Container 당 단일 서비스 배포, Immutable Infra, Blue/Green Deployment

    - Mature : Multi-Datacenter 배포

6.  Monitoring 영역

    - Early : Application Performance Monitoring

    - Inception : Cetralized Logging System

    - Expanding : Container Monitoring

    - Mature : Distributed Tracing, Trace as a Service, Synthetic Transaction

7.  Governance 영역

    - Early : 중앙집중화된 Governance

    - Inception : 일부 Monolith, 일부 Microservices의 Shared Governance Model로 과도기적 형태

    - Expanding : 완전한 분산 된 Governance

    - Mature : 참조 아키텍처 및 참조 방법론 등의 지원

8.  Team Structure 영역

    - Early : Dev, QA, Ops 등 기술 별 조직

    - Inception : 일부 Cross Functional 팀

    - Expanding : 제품 기반 개발팀과 이를 지원하는 Platform 팀(운영, 모니터링 등)

    - Mature : 완전한 제품 기반 DevOps

9.  Architecture 영역

    - Early : ESB를 사용하는 SOA 기반의 아키텍처 또는 Modular Monolith 구조

    - Inception : Monolith 시스템에 신규 기능을 Microservice로 개발하는 형태

    - Expanding : 모든 비즈니스 기능이 Microservice로 분리 되어 서로 Network 인터페이스로 협력

    - Mature : Event 기반, Serverless 도입