서버리스 애플리케이션을 위한 AWS 메시징 서비스와 아키텍처 구현 패턴

대부분의 서버리스 애플리케이션 아키텍처는 AWS Lambda 서비스와 다양한 AWS 서비스, 마이크로서비스 및 조합하여 만듭니다. 이중 메시징 서비스 는 분산 애플리케이션이 서로 통신할 수 있도록 하는 데 중요하며 대부분 서버리스 워크로드에 기본적으로 사용됩니다.

메시징 서비스를 적절하게 사용하는 경우, 탄력성, 가용성 및 확장성을 향상시킬 수 있습니다. 또한, AWS 클라우드를 넘어 통신할 수 있도록 하고 향후 서비스 기능 및 버전에 대한 확장성을 제공할 수 있습니다.

이 글에서는 AWS에서 제공하는 기본 메시징 서비스와 이를 서버리스 애플리케이션 아키텍처에서 사용하는 방법을 비교합니다. 그리고, AWS 서버리스 애플리케이션 모델 (AWS SAM) 기반으로 배포하는 방법도 보여줍니다. (이 글의 예제는 GitHub 리포지토리 에서 받을 수 있으며, README.md에서 배포하고 각각의 예를 실행하는 방법에 대해 설명합니다.)

AWS 메시징 서비스 종류

서버리스 개발자에게 가장 유용한 세 가지 메시징 패턴은 큐, 발행(Pub)/구독(Sub) 및 이벤트 버스입니다. AWS에서는 각각 Amazon Simple Queue Service (SQS) , Amazon Simple Notification Service (SNS) 및 Amazon EventBridge 에서 제공합니다. 이들 서비스는 완전 관리형으로 고가용성을 제공하므로, 별도로 관리할 인프라가 없습니다. 세 가지 모두 Lambda와 통합되어, AWS SDK 를 통해 람다 함수을 대상으로 호출 및 메시지를 게시 할 수 있습니다.

Amazn SNS를 사용하면 인프라 내에서 안정적으로 메시지를 보낼 수 있습니다. 다운스트림 대상을 사용할 수 없는 경우, 강력한 재시도 메커니즘 을 사용합니다. 전송 정책이 소진되면, 향후 재전송을 위해 선택적으로 배달 못한 편지 대기열로 보낼 수 있습니다. SNS는 주제를 사용하여 논리적으로 메시지를 채널로 분리하고 Lambda 함수는 이들 주제와 상호 작용합니다.

Amazon SQS는 서버리스 애플리케이션을 위한 대기열을 제공합니다. 큐를 사용하여 워크로드의 서로 다른 서비스 간에 메시지를 보내고, 저장 및 수신할 수 있습니다. 대기열은 분산 시스템에서 내결함성을 제공하고 애플리케이션의 다른 부분을 분리하는 데 도움이 되는 중요한 메커니즘입니다. SQS는 탄력적으로 확장되며 대기열당 메시지 수에는 제한이 없습니다. 서비스는 다운스트림 소비자가 처리할 때까지 메시지를 지속적으로 유지합니다.

Amazon EventBridge는 서버리스 이벤트 버스 서비스로 내부 AWS 서비스, 외부 SaaS(Software as a Service) 공급자 및 자체 애플리케이션 간의 이벤트 라우팅을 단순화합니다. 이벤트 버스를 사용하여 라우팅을 논리적으로 분리하고 규칙을 사용하여 라우팅 로직을 구현합니다. 서비스 수준에서 수신 메시지를 필터링 및 변환하고 Lambda 함수를 비롯한 여러 대상으로 이벤트를 라우팅할 수 있습니다.

Amazon SQS 대기열 구성하기

첫번째 예제는 2개의 Lambda 함수와 SQS 대기열이 있는 서버리스 애플리케이션을 정의하는 AWS SAM 템플릿을 보여줍니다.

AWS::SQS::Queue 리소스를 사용하여 AWS SAM 템플릿에서 SQS 대기열을 선언할 수 있습니다.

  MySqsQueue:
    Type: AWS::SQS::Queue

대기열에 게시하려면 게시자 기능에 메시지를 보낼 수 있는 권한이 있어야 합니다. AWS SAM 정책 템플릿을사용하여 하나의 특정 큐에 보내는 메시지를 수있는 정책을 적용 할 수 있습니다.

      Policies:
        - SQSSendMessagePolicy:
            QueueName: !GetAtt MySqsQueue.QueueName

AWS SAM 템플릿은 대기열 이름을 환경 변수로 Lambda 함수에 전달합니다. 이 함수는 AWS.SQS 클래스의 sendMessage 메서드를 사용하여 메시지를 게시합니다.

const AWS = require('aws-sdk')
AWS.config.region = process.env.AWS_REGION 
const sqs = new AWS.SQS({apiVersion: '2012-11-05'})

// The Lambda handler
exports.handler = async (event) => {
  // Params object for SQS
  const params = {
    MessageBody: `Message at ${Date()}`,
    QueueUrl: process.env.SQSqueueName
  }
  
  // Send to SQS
  const result = await sqs.sendMessage(params).promise()
  console.log(result)
}

SQS 대기열은 메시지를 수신하면 Lambda 함수에 게시합니다. AWS SAM에서 통합하기 위해 컨슈머 기능에 SQSPollerPolicy 정책을부여합니다. 람다 함수의 이벤트 소스는 10개의 일괄 처리로 대기열에서 메시지를 수신하도록 설정됩니다.

  QueueConsumerFunction:
    Type: AWS::Serverless::Function 
    Properties:
      CodeUri: code/
      Handler: consumer.handler
      Runtime: nodejs12.x
      Timeout: 3
      MemorySize: 128
      Policies:  
        - SQSPollerPolicy:
            QueueName: !GetAtt MySqsQueue.QueueName
      Events:
        MySQSEvent:
          Type: SQS
          Properties:
            Queue: !GetAtt MySqsQueue.Arn
            BatchSize: 10

여기서 컨슈머 기능의 페이로드는 SQS의 메시지입니다. 아래는 메시지의 Body 속성의 배열로 볼 수 있습니다. 각 함수의 CloudWatch 로그에서 이를 확인할 수 있습니다.

Amazon SNS 주제 구성하기

두 번째 예제는 3개의 Lambda 함수와 SNS 주제로 서버리스 애플리케이션을 정의하는 AWS SAM 템플릿을 보여줍니다.

AWS::SNS:Topic 리소스를 사용하여 SNS 주제 및 구독할 Lambda 함수를 선언 합니다.

  MySnsTopic:
    Type: AWS::SNS::Topic
    Properties:
      Subscription:
        - Protocol: lambda
          Endpoint: !GetAtt TopicConsumerFunction1.Arn    
        - Protocol: lambda
          Endpoint: !GetAtt TopicConsumerFunction2.Arn

AWS::Lambda::Permission 각각에 대해 Lambda 함수를 호출할 수 있는 권한을 SNS 서비스에 정의합니다.

  TopicConsumerFunction1Permission:
    Type: 'AWS::Lambda::Permission'
    Properties:
      Action: 'lambda:InvokeFunction'
      FunctionName: !Ref TopicConsumerFunction1
      Principal: sns.amazonaws.com

SNSPublishMessagePolicy 정책 템플릿은 주제에 메시지를 보내기 위해 게시 기능에 권한을 부여합니다. 람다 함수의 AWS.SNS 클래스에서 publish메서드는 게시 작업을 처리합니다.

const AWS = require('aws-sdk')
AWS.config.region = process.env.AWS_REGION 
const sns = new AWS.SNS({apiVersion: '2012-11-05'})

// The Lambda handler
exports.handler = async (event) => {
  // Params object for SNS
  const params = {
    Message: `Message at ${Date()}`,
    Subject: 'New message from publisher',
    TopicArn: process.env.SNStopic
  }
  
  // Send to SQS
  const result = await sns.publish(params).promise()
  console.log(result)
}

컨슈머 기능에 대한 페이로드는 SNS의 메시지입니다. 이 메시지에는 Subject 및 Message 속성을 배열에서 찾을 수 있고, 람다 함수에 대한 CloudWatch 로그에서 이를 확인할 수 있습니다.

SQS와 SNS 구성의 차이점

SQS 대기열과 SNS 주제는 다른 기능을 제공하지만, 둘 다 다운스트림 Lambda 함수에 게시할 수 있습니다. SQS 메시지는 구독자가 성공적으로 처리할 때까지 최대 14일 동안 대기열에 저장됩니다. SNS는 메시지를 보관하지 않으므로 주제에 대한 구독자가 없으면 메시지가 삭제됩니다.

SNS 주제는 여러 대상에게 브로드캐스트될 수 있습니다. 이 동작을 팬아웃이라고 합니다. Lambda 함수 전체에서 작업을 병렬화하거나 여러 환경(예: 테스트 또는 개발)에 메시지를 보내는 데 사용할 수 있습니다. SNS 주제는 최대 12,500,000명의 구독자를 가질 수 있어 확장성이 뛰어난 팬아웃 기능을 제공합니다. 대상에는 HTTP/S 엔드포인트, SMS 문자 메시지, SNS 모바일 푸시, 이메일, SQS 및 Lambda 기능이 포함될 수 있습니다.

AWS SAM 템플릿에서 다음 내장 함수를사용하여 ARN, 대기열 및 주제 이름과 같은 속성을 검색할 수 있습니다.

	Amazon SQS	Amazon SNS
채널 유형	대기 줄	주제
ARN 가져오기	!GetAtt MySqsQueue.Arn	!Ref MySnsTopic
이름 가져오기	!GetAtt MySqsQueue.QueueName	!GetAtt MySnsTopic.TopicName

Amazon EventBridge 구성하기

세번째 예제는 2개의 Lambda 함수 및 EventBridge 규칙을 기반으로 서버리ㅡ 애플리케이션을 정의하는 AWS SAM 템플릿입니다.

기본 이벤트 버스는 모든 AWS 계정에 이미 있습니다. AWS::Events::Rule 리소스를 사용하여 이벤트 버스의 이벤트를 필터링하는 규칙을 선언합니다.

  EventRule: 
    Type: AWS::Events::Rule
    Properties: 
      Description: "EventRule"
      EventPattern: 
        source: 
          - "demo.event"
        detail: 
          state: 
            - "new"
      State: "ENABLED"
      Targets: 
        - Arn: !GetAtt EventConsumerFunction.Arn
          Id: "ConsumerTarget"

이 규칙은 이벤트 패턴에 일치하는 JSON 속성을 설명합니다. 이 패턴과 일치하는 이벤트는 대상 목록으로 라우팅됩니다. 대상 목록에서 Lambda 함수를 호출할 수 있는 권한을 EventBridge 서비스에 제공합니다.

  PermissionForEventsToInvokeLambda: 
    Type: AWS::Lambda::Permission
    Properties: 
      FunctionName: 
        Ref: "EventConsumerFunction"
      Action: "lambda:InvokeFunction"
      Principal: "events.amazonaws.com"
      SourceArn: !GetAtt EventRule.Arn

AWS SAM 템플릿은 IAM 정책 설명을 사용하여, 이벤트 버스에 이벤트를 넣을 수 있는 권한을 게시 기능에 부여합니다.

  EventPublisherFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: code/
      Handler: publisher.handler
      Timeout: 3
      Runtime: nodejs12.x
      Policies:
        - Statement:
          - Effect: Allow
            Resource: '*'
            Action:
              - events:PutEvents

그런 다음, 람다 함수에서는 AWS.EventBridge 클래스의 putEvents 메서드를 사용합니다. 이 메서드는 EventBridge에 이벤트가 영구적으로 저장된 후 반환됩니다.

const AWS = require('aws-sdk')
AWS.config.update({region: 'us-east-1'})
const eventbridge = new AWS.EventBridge()

exports.handler = async (event) => {
  const params = {
    Entries: [ 
      {
        Detail: JSON.stringify({
          "message": "Hello from publisher",
          "state": "new"
        }),
        DetailType: 'Message',
        EventBusName: 'default',
        Source: 'demo.event',
        Time: new Date 
      }
    ]
  }
  const result = await eventbridge.putEvents(params).promise()
  console.log(result)
}

컨슈머 기능의 페이로드는 EventBridge의 메시지입니다. 아래는 Subjecct 및 Message 게시 기능의 속성을 포함한 메시지 배열입니다. 람다 함수에 대한 CloudWatch 로그에서 이를 확인할 수 있습니다.

Amazon EventBridge와 SNS 비교

Amazon SNS와 EventBridge는 유사한 점이 많습니다. 둘 다 게시자와 구독자를 분리하고 메시지 또는 이벤트를 필터링하고 팬인 또는 팬아웃 기능을 제공하는 데 사용할 수 있습니다. 그러나 각 서비스의 대상 및 기능 목록에는 차이가 있으며 서비스 선택은 사용 사례의 요구 사항에 따라 다릅니다.

EventBridge는 SNS에서 사용할 수 없는 두 가지 새로운 기능을 제공합니다. 첫 번째는 SaaS(Software as a Service) 통합입니다. 이를 통해 지원되는 SaaS 공급자가 EventBridge 이벤트 버스에서 계정의 파트너 이벤트 버스로 직접 이벤트를 보낼 수 있는 권한을 부여할 수 있습니다. 이는 폴링 또는 웹훅 구성의 필요성을 대체하고 SaaS 이벤트를 AWS 계정으로 직접 수집하는 확장성이 뛰어난 방법을 생성합니다.

두 번째 기능은 이벤트에 대한 OpenAPI 스키마를 더 쉽게 검색하고 관리할 수 있는 스키마 레지스트리기능 입니다. EventBridge는 스키마 검색을 사용하여 이벤트 버스를 통해 라우팅된 이벤트를 기반으로 스키마를 유추할 수 있습니다. 이것은 Python, Java 및 TypeScript와 같은 유형 안전 언어용 IDE에 직접 코드 바인딩을 생성하는 데 사용할 수 있습니다. 이는 이벤트에서 직접 클래스 및 코드 생성을 자동화하여 개발을 가속화하는 데 도움이 될 수 있습니다.

이 표에서는 두 서비스의 주요 기능을 비교합니다.

	Amazon SNS	Amazon EventBridge
대상 수	1000만(소프트)	규칙당 5개 대상
가용성 SLA	99.9%	99.99%
서비스 할당량	100,000개의 주제. 주제당 12,500,000개의 구독.	100개의 이벤트 버스. 이벤트 버스당 300개의 규칙.
게시 처리량	지역에 따라 다릅니다. 조정 가능한 할당량.	지역에 따라 다릅니다. 조정 가능한 할당량.
입력 변환	아니오	예 – 자세히 보기
메시지 필터링	예 – 자세한 보기	예, IP 주소 일치를 포함 자세히 보기
최대 메시지 크기	256KB	256KB
청구	64KB당	64KB당
체재	Raw 또는 JSON	JSON
AWS CloudTrail에서 이벤트 수신	아니오	예
대상	HTTP(S), SMS, SNS 모바일 푸시, 이메일/이메일-JSON, SQS, Lambda 함수	AWS Lambda , Amazon SQS , Amazon SNS , AWS Step Functions , Amazon Kinesis Data Streams , Amazon Kinesis Data Firehose , API Gateway REST API 엔드포인트 및 Amazon Redshift 클러스터 등
SaaS 통합	아니오	예 – 자세히 보기
스키마 레지스트리 통합	아니오	예 – 자세히 보기
배달 못한 편지 대기열 지원	예	예 – 자세히 보기
FIFO 주문 가능	예	아니오
공개 가시성	공개 주제 생성 가능	공공 버스 생성 불가능
가격	$0.50/백만 요청 + 가변 전송 비용 + 데이터 전송 비용	$1.00/백만 이벤트
청구 가능한 요청 크기	1 요청 = 64KB	이벤트 1개 = 64KB
AWS 프리 티어 적격	예	아니오
교차 리전 기능	모든 리전에서 Amazon SNS 주제에 대한 AWS Lambda 함수를 구독 가능	대상은 동일한 리전에 있어야 함 (리전 간에 다른 이벤트 버스에 게시 가능)
재시도 정책	SQS/Lambda의 경우 23일 동안, SMTP, SMS 및 모바일 푸시의 경우 6시간 동안 재시도	최대 24시간 동안 재시도를 포함하여 대상에 최소 한 번 이벤트 전달

Amazon SNS와 SQS를 결합하여 메시지 처리하기

Amazon SNS에는 23일 동안 최대 100,010번의 전송을 시도가 발생하는 강력한 재시도 정책이 있습니다. 다운스트림 서비스를 사용할 수 없는 경우, 다시 온라인 상태가 될 때 이러한 재시도에 압도될 수 있습니다. 이때 SQS 대기열을 추가하여 이 문제를 해결할 수 있습니다. 네번째 예제는 SNS 주제에 대한 SQS 대기열 구독을 결합합니다.

SNS 주제와 구독자 사이에 SQS 대기열을 추가하면 두 가지 이점이 있습니다. 첫째, 메시지가 대기열에 영구적으로 저장되기 때문에 메시지 배달에 탄력성을 추가합니다. 둘째, 컨슈머에 대한 메시지 속도를 조절하여 서비스가 누락된 메시지를 따라잡음으로써 발생하는 트래픽 버스트를 완화하는 데 도움이 됩니다.

AWS SAM 템플릿에서 이를 빌드하려면 먼저 두 개의 리소스와 SNS 구독을 정의합니다.

  MySqsQueue:
    Type: AWS::SQS::Queue

  MySnsTopic:
    Type: AWS::SNS::Topic
    Properties:
      Subscription:
        - Protocol: sqs
          Endpoint: !GetAtt MySqsQueue.Arn

마지막으로 AWS::SQS::QueuePolicy 리소스를 사용하여 대기열에 게시할 SNS 주제에 대한 권한을 제공합니다.

  SnsToSqsPolicy:
    Type: AWS::SQS::QueuePolicy
    Properties:
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Sid: "Allow SNS publish to SQS"
            Effect: Allow
            Principal: "*"
            Resource: !GetAtt MySqsQueue.Arn
            Action: SQS:SendMessage
            Condition:
              ArnEquals:
                aws:SourceArn: !Ref MySnsTopic
      Queues:
        - Ref: MySqsQueue

이를 테스트하기 위해 SNS 주제에 메시지를 게시한 다음 사용하여 SQS 대기열 길이를 검사할 수 있습니다.

$ aws sns publish --topic-arn "arn:aws:sns:us-east-1:123456789012:sns-sqs-MySnsTopic-ABC123ABC" --message "Test message"
$ aws sqs get-queue-attributes --queue-url "https://sqs.us-east-1.amazonaws.com/123456789012/sns-sqs-MySqsQueue- ABC123ABC " --attribute-names ApproximateNumberOfMessages

결과는 다음과 같습니다.

이 패턴의 또 다른 용도는 SQS 대기열을 사용하여 아키텍처에서 메시지를 필터링하려는 경우입니다. SNS 주제를 대기열 앞에 배치하면 SNS의 메시지 필터링 기능을 사용할 수 있습니다 . 이렇게 하면 필요한 메시지만 대기열에 게시됩니다. AWS SAM에서 메시지 필터링을 사용하려면 AWS:SNS:Subcription 리소스를 사용하세요.

  QueueSubcription:
    Type: 'AWS::SNS::Subscription'
    Properties:
      TopicArn: !Ref MySnsTopic
      Endpoint: !GetAtt MySqsQueue.Arn
      Protocol: sqs
      FilterPolicy:
        type:
        - orders
        - payments 
      RawMessageDelivery: 'true'

Amazon EventBridge와 SNS 기능 결합

다섯번째 예제에서는 SNS 주제를 EventBridge 규칙의 대상으로 구성하는 방식입니다.

AWS SAM 템플릿으로 위의 그림을 구성하면 아래와 같습니다.

Resources:
  MySnsTopic:
    Type: AWS::SNS::Topic

  EventRule: 
    Type: AWS::Events::Rule
    Properties: 
      Description: "EventRule"
      EventPattern: 
        account: 
          - !Sub '${AWS::AccountId}'
        source:
          - "demo.cli"
      Targets: 
        - Arn: !Ref MySnsTopic
          Id: "SNStopic"

기본 이벤트 버스는 모든 AWS 계정에 이미 존재하므로 별도로 선언할 필요가 없습니다. 이벤트 버스가 SNS 주제에 일치하는 이벤트를 게시하려면 AWS::SNS::TopicPolicy를 사용하여 리소스 권한을 정의 합니다.

  EventBridgeToToSnsPolicy:
    Type: AWS::SNS::TopicPolicy
    Properties: 
      PolicyDocument:
        Statement:
        - Effect: Allow
          Principal:
            Service: events.amazonaws.com
          Action: sns:Publish
          Resource: !Ref MySnsTopic
      Topics: 
        - !Ref MySnsTopic

EventBridge에는 규칙당 대상이 5개로 제한됩니다. 수백 또는 수천 개의 대상에 이벤트를 보내야 하는 경우 먼저 SNS에 게시한 다음 해당 대상을 주제에 구독하면 이 제한을 해결할 수 있습니다. 두 서비스 모두 대상이 다르며 이 패턴을 사용하면 EventBridge 이벤트를 SMS, HTTP(s), 이메일 및 SNS 모바일 푸시로 전달할 수 있습니다.

AWS Lambda 함수 없이도 이러한 서비스를 사용하여 메시지를 변환하고 필터링할 수 있습니다. SNS는 입력 변환을 지원하지 않지만 EventBridge 규칙에서 이 작업을 수행할 수 있습니다. 메시지 필터링은 두 서비스 모두에서 가능하지만 EventBridge는 보다 풍부한 콘텐츠 필터링 기능을 제공합니다.

AWS CloudTrail은 AWS 계정의 서비스 전반에서 활동을 기록하고 모니터링할 수 있습니다. 이 서비스는 이벤트에 대한 유용한 소스가 될 수 있습니다. 예를 들어 Amazon S3의 객체에 동적 대응을 하거나 개발 환경의 변화에 대응 가능합니다. 기본적으로 EventBridge와 통합되어 수십 개의 서비스 에서 대규모로 이벤트를 수집할 수 있습니다.

앞서 말씀 드린대로 EventBridge를 사용하면 AWS 계정 외부에서 이벤트를 소싱하여 SaaS(Software as a Service) 공급자 목록과의 통합을 제공할 수 있습니다. 이 기능을 사용하면 Zendesk , PagerDuty 및 Auth0 같은 SaaS 제공업체의 계정에서 이벤트를 수신할 수 있습니다 . 이러한 이벤트는 파트너 이벤트 버스 계정으로 전달된 다음, 필터링되어 SNS 주제로 라우팅될 수 있습니다.

또한, 이 패턴을 사용하면 다른 AWS 계정 및 다른 AWS 리전의 Lambda 함수에 이벤트를 전달할 수 있습니다. 다른 리전 및 계정의 SNS 주제에서 Lambda를 호출할 수 있습니다. SNS 주제를 공개적으로 읽기 전용으로 만들어 다른 제3자가 사용할 수 있는 확장 가능한 엔드포인트로 만드는 것도 가능합니다. SNS에서는 포괄적인 액세스 제어를 통해 이 패턴에 통합할 수 있습니다.

Amazon EventBridge와 SQS로 내결함성 마이크로서비스 구축

Amazon EventBridge는 이벤트를 마이크로서비스와 같은 대상으로 라우팅할 수 있습니다. 다운스트림 실패의 경우, 서비스는 최대 24시간 동안 이벤트를 재시도합니다. 메시지를 저장하고 다시 시도하는 데 더 오랜 시간이 필요한 워크로드의 경우, 각 마이크로 서비스의 SQS 대기열에 이벤트를 전달할 수 있습니다. 이렇게 하면 다운스트림 서비스가 복구될 때까지 해당 이벤트를 영구적으로 저장합니다. 이 패턴을 사용하면, 메시지 전달을 조절하여 대규모 트래픽 버스트로부터 마이크로서비스를 보호합니다.

여섯번째 예제에서는 EventBridge와 SQS를 결합하는 방식을 정의합니다.

AWS SAM 템플릿에 선언된 리소스는이전 예제와 유사하지만, AWS::SQS::QueuePolicy 리소스를 사용하여 EventBridge에 적절한 권한을 부여합니다.

  EventBridgeToToSqsPolicy:
    Type: AWS::SQS::QueuePolicy
    Properties:
      PolicyDocument:
        Statement:
        - Effect: Allow
          Principal:
            Service: events.amazonaws.com
          Action: SQS:SendMessage
          Resource:  !GetAtt MySqsQueue.Arn
      Queues:
        - Ref: MySqsQueue

마무리

이벤트 기반 메시징은 서버리스 애플리케이션의 중요한 부분이며 AWS 서비스는 대기열, 게시/구독 및 이벤트 라우팅 기능을 제공합니다. 이 글에서는 Amaazon SNS, SQS 및 EventBridge의 주요 기능과 이들이 워크로드에 대해 다양한 기능을 제공하는 방법을 검토하였습니다. 이들 서비스를 각각 결합하여, 복잡한 문제를 해결하는 패턴을 구현할 수 있습니다. (이 글의 예제는 GitHub 리포지토리 에서 받을 수 있으며, README.md에서 배포하고 각각의 예를 실행하는 방법에 대해 설명합니다.)

분산 아키텍처 구축에 대해 자세히 알아보려면, How to Use Amazon EventBridge to Build Decoupled, Event-Driven Architectures의 학습 경로를 참고하세요.

– James Beswick, AWS Serverless Developer Advocate

이 글은 AWS Compute 블로그 Choosing between messaging services for serverless applications와 Building resilient serverless patterns by combining messaging services의 한국어 번역입니다.

Amazon Web Services 한국 블로그