

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 통신 메커니즘
<a name="communication-mechanisms"></a>

 마이크로서비스 패러다임에서는 애플리케이션의 다양한 구성 요소가 네트워크를 통해 통신해야 합니다. 이에 대한 일반적인 접근 방식에는 REST 기반, GraphQL 기반, gRPC 기반 및 비동기식 메시징이 포함됩니다.

## REST 기반 통신
<a name="rest-based-communication"></a>

 마이크로서비스 간의 동기 통신에 광범위하게 사용되는 HTTP/S 프로토콜은 종종 RESTful APIs 통해 작동합니다. API Gateway는 트래픽 관리, 권한 부여, 모니터링 및 버전 관리와 같은 작업을 처리하여 백엔드 서비스에 대한 중앙 집중식 액세스 포인트 역할을 하는 API를 구축하는 간소화된 방법을 제공합니다.

## GraphQL 기반 통신
<a name="graphql-based-communication"></a>

 마찬가지로 GraphQL은 REST와 동일한 프로토콜을 사용하지만 단일 엔드포인트에 대한 노출을 제한하여 동기 통신을 위한 광범위한 방법입니다. 를 사용하면 AWS 서비스 및 데이터 스토어와 직접 상호 작용하는 GraphQL 애플리케이션을 생성 및 게시하거나 비즈니스 로직을 위한 Lambda 함수를 통합할 AWS AppSync수 있습니다.

## gRPC 기반 통신
<a name="grpc-based-communication"></a>

 gRPC는 동기식, 경량, 고성능, 오픈 소스 RPC 통신 프로토콜입니다. gRPC는 HTTP/2를 사용하고 압축 및 스트림 우선 순위 지정과 같은 더 많은 기능을 지원하여 기본 프로토콜을 개선합니다. 이진 인코딩된 Protobuf 인터페이스 정의 언어(IDL)를 사용하므로 HTTP/2 이진 프레이밍을 활용합니다.

## 비동기식 메시징 및 이벤트 전달
<a name="asynchronous-messaging-and-event-passing"></a>

비동기식 메시징을 사용하면 서비스가 대기열을 통해 메시지를 전송하고 수신하여 통신할 수 있습니다. 이를 통해 서비스는 느슨하게 연결된 상태를 유지하고 서비스 검색을 촉진할 수 있습니다.

메시징은 다음 세 가지 유형으로 정의할 수 있습니다.
+  **메시지 대기열:** 메시지 대기열은 메시지의 발신자(생산자)와 수신자(소비자)를 분리하는 버퍼 역할을 합니다. 생산자는 메시지를 대기열에 대기열에 추가하고 소비자는 메시지를 대기열에서 제거하고 처리합니다. 이 패턴은 비동기 통신, 로드 레벨링 및 트래픽 버스트 처리에 유용합니다.
+  **게시-구독:** 게시-구독 패턴에서 메시지가 주제에 게시되고 관심 있는 여러 구독자가 메시지를 수신합니다. 이 패턴을 사용하면 이벤트 또는 메시지를 여러 소비자에게 비동기적으로 브로드캐스팅할 수 있습니다.
+  **이벤트 기반 메시징:** 이벤트 기반 메시징에는 시스템에서 발생하는 이벤트를 캡처하고 이에 대응하는 작업이 포함됩니다. 이벤트는 메시지 브로커에 게시되며 관심 있는 서비스는 특정 이벤트 유형을 구독합니다. 이 패턴을 사용하면 느슨한 결합이 가능하고 서비스가 직접 종속성 없이 이벤트에 대응할 수 있습니다.

 이러한 각 메시지 유형을 구현하기 위해는 Amazon SQS, Amazon SNS, Amazon EventBridge, Amazon MQ 및 Amazon MSK와 같은 다양한 관리형 서비스를 AWS 제공합니다. 이러한 서비스에는 특정 요구 사항에 맞게 조정된 고유한 기능이 있습니다.
+  **Amazon Simple Queue Service(Amazon SQS) 및 Amazon Simple Notification Service(Amazon SNS):** 그림 8에서 볼 수 있듯이이 두 서비스는 서로 보완하며, Amazon SQS는 메시지를 저장할 수 있는 공간을 제공하고 Amazon SNS는 여러 구독자에게 메시지를 전달할 수 있습니다. 동일한 메시지를 여러 대상으로 전송해야 할 때 유효합니다.  
![의 메시지 버스 패턴을 보여주는 다이어그램 AWS](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/microservices-on-aws/images/message-bus-pattern.png)
+  **Amazon EventBridge:** 이벤트를 사용하여 애플리케이션 구성 요소를 함께 연결하는 서버리스 서비스로, 확장 가능한 이벤트 기반 애플리케이션을 더 쉽게 구축할 수 있습니다. 이를 사용하여 자체 개발 애플리케이션, AWS 서비스 및 타사 소프트웨어와 같은 소스에서 조직 전체의 소비자 애플리케이션으로 이벤트를 라우팅할 수 있습니다. EventBridge는 이벤트를 수집, 필터링, 변환 및 전달하는 간단하고 일관된 방법을 제공하므로 새 애플리케이션을 빠르게 구축할 수 있습니다. EventBridge 이벤트 버스는 이벤트 기반 서비스 간 이벤트의 many-to-many 라우팅에 매우 적합합니다.
+  **Amazon MQ:** JMS, AMQP 등과 같은 표준 프로토콜을 사용하는 기존 메시징 시스템이 있는 경우 좋은 선택입니다. 이 관리형 서비스는 작업을 중단하지 않고 시스템을 대체합니다.
+  **Amazon MSK(Managed Kafka): **메시지를 저장하고 읽기 위한 메시징 시스템으로, 메시지를 여러 번 처리해야 하는 경우에 유용합니다. 또한 실시간 메시지 스트리밍을 지원합니다.
+  **Amazon Kinesis:** 스트리밍 데이터의 실시간 처리 및 분석. 이를 통해 실시간 애플리케이션을 개발하고 AWS 에코시스템과 원활하게 통합할 수 있습니다.

 최상의 서비스는 특정 요구 사항에 따라 달라지므로 각 서비스가 제공하는 내용과 요구 사항에 맞는 방식을 이해하는 것이 중요합니다.

## 오케스트레이션 및 상태 관리
<a name="orchestration-and-state-management"></a>

 마이크로서비스 오케스트레이션은 오케스트레이터라고 하는 중앙 구성 요소가 마이크로서비스 간의 상호 작용을 관리하고 조정하는 중앙 집중식 접근 방식을 말합니다. 여러 마이크로서비스에서 워크플로를 오케스트레이션하는 것은 어려울 수 있습니다. 오케스트레이션 코드를 서비스에 직접 임베딩하는 것은 더 엄격한 결합을 도입하고 개별 서비스 교체를 방해하므로 권장되지 않습니다.

 Step Functions는 오류 처리 및 직렬화와 같은 서비스 오케스트레이션 복잡성을 관리하는 워크플로 엔진을 제공합니다. 이를 통해 조정 코드를 추가하지 않고도 애플리케이션을 빠르게 확장하고 변경할 수 있습니다. Step Functions는 AWS 서버리스 플랫폼의 일부이며 Lambda 함수, Amazon EC2, Amazon EKS, Amazon ECS, SageMaker AI AWS Glue등을 지원합니다.

![에서 호출한 마이크로서비스 워크플로 다이어그램 AWS Step Functions](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/microservices-on-aws/images/microservices-workflow-with-steps.png)


[Amazon Managed Workflows for Apache Airflow](https://aws.amazon.com/managed-workflows-for-apache-airflow/)(Amazon MWAA)는 Step Functions의 대안입니다. 오픈 소스 및 이식성을 우선시하는 경우 Amazon MWAA를 사용해야 합니다. Airflow에는 새로운 기능과 통합에 정기적으로 기여하는 대규모의 활성 오픈 소스 커뮤니티가 있습니다.