서비스 조율과 상태 관리

AWS에서 애플리케이션 개발하기

Ricardo Sueiras

Principal Technologist

서비스 조율

 

• 워크플로를 완료하려면 여러 서비스가 함께 작동해야 합니다.
• 이를 위해 조율 전략이 필요합니다.
• 두 가지 접근 방식: 오케스트레이션과 코레오그래피.

오케스트레이션

 

• 중앙 오케스트레이터가 워크플로를 조율합니다.
• 오케스트레이터가 순서를 제어하고 다음에 실행할 서비스를 결정합니다.
• 재시도, 조건부 로직, 오류 처리에 유용합니다.
• AWS에서는 Lambda, ECS, DynamoDB 전반에 걸쳐 Step Functions로 구현합니다.

오케스트레이션

 

• 워크플로 로직이 한곳에 모여 있어 디버깅과 모니터링이 쉽습니다.
• 단점: 중앙 의존성이 생깁니다.

코레오그래피

• 중앙 제어자가 없습니다.
• 각 서비스가 독립적으로 이벤트에 반응합니다.
• 각 서비스는 관련 이벤트를 수신하고 자신의 작업을 수행합니다.
• 어떤 서비스도 전체 워크플로를 알 필요가 없습니다.
• 느슨한 결합과 확장성을 향상시킵니다.

 

코레오그래피

• AWS에서는 EventBridge, SNS, SQS를 사용합니다.
• 확장성이 뛰어납니다.
• 단점: 워크플로가 커질수록 이해와 디버깅이 어려워집니다.

 

이벤트 기반 아키텍처

• 서비스는 이벤트를 생성하고 소비하며 통신합니다.
• 서비스 간 느슨한 결합을 촉진합니다.
• 높은 확장성을 촉진합니다.
• 이벤트의 병렬 처리를 가능하게 합니다.
• 기존 서비스를 수정하지 않고도 새 서비스를 구독시킬 수 있습니다.

 

이벤트 기반 아키텍처

 

• EDA 구현 시 트레이드오프:
• 최종 일관성을 고려해 설계하세요.
• 멱등성을 구현하세요.
• 오류 처리가 더 복잡해집니다.

멱등성

 

• 동일한 작업을 여러 번 실행해도 결과는 같습니다.
• 비동기 및 이벤트 기반 시스템에서 핵심 설계 원칙입니다.
• 분산 시스템은 중복 이벤트를 전달할 수 있습니다(재시도, 네트워크 장애, 재처리).
• 시스템의 정확성과 신뢰성을 유지합니다.

데드 레터 큐

 

• 비동기 통신에서 발생하는 장애를 관리합니다.
• 문제가 되는 "포이즌(poison)" 메시지를 격리합니다.
• 재시도가 반복적으로 실패하면 메시지는 DLQ로 이동합니다.
• 기본 처리 흐름은 계속 실행됩니다.

데드 레터 큐

• 메시지 순서가 중요하지 않을 때 사용하세요.
• 가끔 데이터 손실이 허용되는 비중요 시스템에서는 생략하세요.
• 메시지 순서를 반드시 유지해야 할 때는 피하세요.

 

상태 관리

• 상태 관리는 클라우드 네이티브 앱의 기본 요소입니다.
• 상태란 상호작용 사이에 보존되는 모든 데이터를 의미합니다.
• 서버에 상태를 로컬로 저장하면 확장성과 복원력이 제한됩니다.

 

상태 관리

• 상태 관리는 무엇을 만드는지에 따라 트레이드오프가 달라집니다.
• 외부 상태는 확장성과 복원력을 향상시킵니다.
• 비용: 지연 시간과 복잡성이 증가합니다.
• 고려할 사항: 일관성, 캐싱, 데이터 접근 패턴.

 

상태 저장형(Stateful)

 

• 세션 데이터가 서버에 유지됩니다.
• 요청은 반드시 동일한 인스턴스로 라우팅되어야 합니다(스티키 세션).
• 확장 유연성이 제한됩니다.
• 인스턴스가 실패하면 세션도 사라집니다.

무상태형(Stateless)

 

• 모든 요청은 독립적으로 처리됩니다.
• 서버에 상태를 저장하지 않습니다.
• 상태는 외부 시스템에 존재합니다.
• 클라우드 네이티브 앱에 선호되는 방식입니다.
• 어떤 인스턴스든 모든 요청을 처리할 수 있어 수평 확장이 간단합니다.

연습해 봅시다!

AWS에서 애플리케이션 개발하기