[aws summit seoul 2023] 12가지 디자인 패턴으로 알아보는 클라우드 네이티브 마이크로서비스 아키텍처

#aws summit seoul 2023 에서 발표된 12가지 디자인 패턴으로 알아보는 클라우드 네이티브 마이크로서비스 아키텍처 영상을 보고 정리한 내용입니다. 

 

클라우드 네이티브란 ?

• 현대적이고 역동적인 클라우드 환경에서 확장 가능한 애플리케이션을 개발하고 운영
• 탄력적이고 관리 가능하며 관찰 가능한 느슨하게 결합된 시스템
• 자동화를 통해 빈번하면서도 예측 가능한 변경을 수행
• Build and Architect -> Everything as Code -> Continuous Delivery -> Observability -> Modern Data Management -> DevSecOps -> Continuous Deployment -> Everything as a Service -> Cloud Operations

 

마이크로서비스 아키텍처 설계 원칙

• 자율성과 기술 다양성을 확보한 팀
• Front Door 로서 API
• 낮은 결합도와 높은 응집도
• 자동화 된 빌드/배포/테스트

 

현대화 된 애플리케이션 특징

• 확장 가능한 서비스 (MSA)
• API를 통한 연결
• 지속적 배포
• 내결함성
• 보안 기능 내장
• 상태 및 지속성의 관리

 

디자인 패턴과 원칙

• 디자인 패턴 - 재사용 가능한 솔루션을 만들어 내는 것 

• Well Architected -> 목표
  • 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속성을 만족하는 아키텍처
• 공통적인 설계 원칙
  • 필요 용량에 대한 추측 불필요
  • 운영 규모에 맞게 시스템 테스트
  • 자동화 적용
  • 아키텍처는 지속적으로 진화해야 함
  • 아키텍처 변화는 데이터를 기반으로 이뤄져야 함
  • 게임데이와 같은 이벤트를 통해 새로운 기술의 연습과 학습을 통해 개선해야 함 

 

12가지 디자인 패턴

•  API 관리 및 소비
  • API G/W 패턴
    • api g/w 를 통해 서비스를 노출하는 형태
    • api g/w 에는 비즈니스 로직이 포함되면 안됨
  • Backend for Frontends 패턴
    • 데스크탑, 모바일 등 단말의 요구사항에 맞는 백엔드 서비스를 만드는 것
    • 하나의 백엔드로 요구사항을 맞추기 쉽지 않음 (복잡해짐)
    • 모바일은 더 적은 API, Push notification 등 필요 -> 별도 BFF 를 구현함
  • Migraiton 
    • Strangler Fig 패턴
      
      • 기존 서비스를 유지하면서 Reverse Proxy 를 사용하여 점진적 새로운 마이크로 서비스로 전환하는 패턴
  • Data 관리
    • database per service 패턴
      • 각 서비스 별로 특징에 맞게 데이터베이스를 사용하는 패턴
      • 각 서비스에 대한 의존성을 낮출 수 있음
    • CQRS and Event Sourcing 패턴
      • CQRS - 읽기 (Query), 쓰기 (Command) 저장소를 분리
      • Event Sourcing - 발생되는 애플리케이션 상태 변경을 이벤트로 저장 , 저장된 이벤트를 다른 애플리케이션이 활용하는 방식
      • 성능, 안정성, 확장성 확보에 좋음
    • Materialized View 패턴
      
      • 계산된 결과와 같은 데이터를 materialized view 로 미리 구성해서 실행부 가깝게 배치
    • Event Delivery
      
      • Pub - Sub 패턴
        • 메시지 브로커를 통해 이벤트 기반의 비동기 방식으로 유연하고 확장성 있게 처리
  • 연결성 및 조합
    • Sidecar 패턴
      • 통신, 로깅과 같은 기능을 별도 컨테이너를 생성하여 기존 컨테이너를 보조하는 방식
    • Service Mesh 패턴
      • 통신을 처리하는 프록시가 핵심
      • sidecar proxy 를 통해서만 각 서비스 간 통신
    • Service Choreography 패턴
      • 비동기 방식으로 서비스 간 낮은 결합성을 구현하기 위한 패턴
      • 서비스 간 Message Queue / Bus 를 두고 이벤트를 기반으로 연결
      • 서비스 추가/삭제가 유연, 전체적인 애플리케이션 구조를 이해하거나 흐름을 추적하기 어려움 (분산 추적 서비스 필요)
    • Service Orchestration 패턴
      • 복잡한 비즈니스 로직을 구현하기 위해서 오케스트레이터가 중앙에서 서비스 흐름 제어
      • choreography 대비 서비스 흐름을 한눈에 파악하기 쉬움
    • Saga 패턴
      • 분산 애플리케이션에서 여러 트랜잭션 그룹으로 조정하여 일관성을 유지하도록 하는 패턴

 

마무리 - 마이크로 서비스는 ..

• 작고 서비스 목적에 맞게 만들어야 함 - 서비스 간 독립성과 경량화
• 서비스 간 결합도 낮추기 - 결합도 높을수록 복잡도 증가, 유연성 저하 -> 유지보수 어려움
• 독립적 테스트와 배포가 가능해야 함
• 서비스마다 독립적으로 확장/축소 가능해야 함
• 목적에 맞는 데이터베이스와 툴 사용