AWS

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

한크크 2024. 3. 15. 17:08

#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 패턴
        • 분산 애플리케이션에서 여러 트랜잭션 그룹으로 조정하여 일관성을 유지하도록 하는 패턴

 

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

 

반응형
저작자표시 비영리 변경금지