[AWS Hero 특집] Amazon CloudWatch Events에서 서버리스 파이프라인 구축하기

AWS 서버리스 히어로인 Forrest Brazeal 의 기고 글입니다. Forrest 는 Trek10에서 Think FaaS 서버리스 팟캐스트를 진행하는 Trek10, Inc.의 수석 클라우드 아키텍트이며, 서버리스 커뮤니티의 워크숍 및 이벤트에 참석해 정기적으로 강연을 하기도 합니다.

이벤트와 서버리스는 마치 구운 콩과 바비큐 같습니다. 서버리스 사고방식에 따르면, 비즈니스 가치를 창출하는 코드와 구성에 집중해야 합니다. 그리고 이는 대부분의 경우 외부 세계에서 나타나는 사물에 대응하는 구조화된 데이터, 즉 이벤트와의 작업을 의미합니다. 저는 폴링하는 동안 리소스를 잡아먹는 장기 실행 서버 작업을 관리하는 대신, 이벤트 트리거에만 응답하도록 작동하는 서비리스 애플리케이션을 생성할 수 있습니다.

AWS에서 이벤트에 관한 작업을 수행할 때 요구 사항에 따라 Amazon Kinesis Data Streams, Amazon Simple Notification Service(SNS), Amazon Simple Queue Service(SQS) 등 많은 옵션을 사용할 수 있습니다. 최근에 저는 ‘이벤트’라는 단어가 서비스 이름에 정말 잘 들어맞는 Amazon CloudWatch Events 서비스를 사용하고 있습니다.

CloudWatch Events: 서버리스 이벤트 처리의 일급 비밀

저는 처음에 CloudWatch를 Lambda 로그를 수집하고 예약한 대로 함수를 실행할 수 있는 서비스라고 생각했습니다. 하지만, CloudWatch Events에서 CloudWatch API를 사용하여 나만의 사용자 지정 이벤트를 게시할 수도 있었습니다. 이 서비스는 SNS와 비슷한 요금과 보증을 제공하고, 전체 AWS 서비스를 대상으로 지원합니다.

무엇보다, 이벤트 버스를 프로비저닝하지 않아도 됩니다. CloudWatch 콘솔에 있으니까요. 이제 boto3 AWS SDK for Python을 사용하여 이벤트를 게시할 수 있습니다.


import boto3
cw = boto3.client('cloudwatch')
cw.put_events(
    Entries=[
        {
            'Source': 'my.app.event',
            'DetailType': 'MY_EVENT_TYPE',
            'Detail': '{"my_data":"As a JSON string"}'
        }
    ]
)

정리하면, CloudWatch Events는 임의의 소비자 수를 지원하는 완전관리형 이벤트 파이프를 제공해주었고, 이를 통해 저는 원하는 모든 종류의 JSON 문자열을 삭제할 수 있습니다. 서버리스 앱을 구축하는 데 정말로 유용한 기능입니다.

이벤트 중심 아키텍처 실현

저는 Trek10에서 매일 클라이언트를 위한 클라우드 네이티브 솔루션을 구축합니다. 그리고 종종 레거시 시스템을 서버리스로 마이그레이션하는 강력한 방법으로 이벤트 중심 아키텍처를 사용하곤 합니다. 그러면 다운스트림 통합 등을 더 쉽게 수행할 수 있습니다. 다음은 제가 즐겨 사용하는 몇 가지 패턴입니다.
• 레거시 데이터베이스 스트랭글링
• 이벤트 소싱 애플리케이션 설계

레거시 데이터베이스 스트랭글링

“스트랭글러 패턴”은 래퍼 API 뒤에 레거시 시스템을 숨기고 사용자를 새 인터페이스로 점진적으로 마이그레이션합니다. Trek10에서 이전에 이에 대한 글을 쓴 바 있습니다. 이벤트는 보고 및 분석 사용 사례를 여는 뛰어난 방법이기도 하고, 동시에 레거시 데이터베이스에서 로드가 줄어들면서 스트리밍은 클라우드로 변화하고 있습니다. 다음 다이어그램은 이벤트에 레거시 데이터베이스를 쓰는 과정을 보여줍니다.

이 패턴은 다른 방식으로도 활용할 수 있습니다. CloudWatch Events에 새 데이터를 쓰고, 이를 최신 데이터 원본으로 이용하고, 레거시 시스템으로 다시 데이터를 동기화하는 두 번째 소비자를 생성할 수 있습니다.

이벤트 소싱 애플리케이션 설계

이벤트 소싱이란, 시스템 상태의 변화를 이벤트로 처리하고, 다른 다운스트림 애플리케이션에서 이용할 수 있는 원장이나 버스에 해당 이벤트를 게시하는 방법을 말합니다.

중앙화된 버스로 CloudWatch Events를 사용해 다음 이벤트 검증 플로우 다이어그램에 표시된 대로, 삭제된 이벤트 레코드를 사용 가능하게 설정할 수 있습니다.

검증 함수를 사용하면 애플리케이션 표준과 일치하는 이벤트만 “유효” 항목으로 표시되고, 다운스트림 소비자가 사용할 수 있습니다. 기본 버스는 많은 이벤트를 처리합니다. (여기서 서비스 로그가 등장합니다!) 따라서 중요한 이벤트와만 일치하는 규칙을 설정하는 것이 중요합니다.

CloudWatch Events는 인프라를 프로비저닝하거나 관리할 필요 없이 필터를 적용하고 소비자를 구독할 수 있는 단일 버스를 제공하여 이러한 패턴을 단순화합니다. 이것은 시작에 불과합니다.

사용 사례: CloudWatch Events에서 다중 계정 이벤트 처리

CloudWatch Events는 여러 AWS 계정 연결을 시작할 때 특히 더 흥미롭습니다. 전달되는 이벤트를 선택하는 필터링 규칙을 사용하면 서로 다른 계정에서 CloudWatch 이벤트 버스 간 신뢰 관계를 설정하기 쉽습니다.

예를 들어, AnyCompany라는 대기업의 위젯 처리 시스템을 가정합니다. AnyCompany에는 각자 AWS 계정을 사용하는 여러 개발 팀이 있습니다. 일부 서비스는 한 국가를 이동하거나 웨어하우스에 체크인할 때 위젯에 대한 정보를 생성합니다. 새로운 제품을 혁신하거나 보고서를 실행하기 위해 이러한 데이터가 필요한 서비스도 있습니다.

Service A는 새 위젯에 대한 정보를 생성하고, Service B는 실시간으로 위젯에 대한 집계를 확인하려고 하고, Service C는 보고를 위해 위젯에 대한 데이터 기록이 필요하다고 가정합니다. 전체 이벤트 플로우는 다음 다이어그램과 유사할 수 있습니다.

1. Service A는 다음 이벤트 본문을 사용하여 AWS 계정의 CloudWatch Events에 새 위젯 이벤트를 게시합니다.

{
            'Source': 'cwi.servicea',
            'DetailType': 'NEW_WIDGET',
            'Detail': '{"widget_id":"abc123"}'
}

2. 필터링 규칙은 cwi.servicea 태그가 지정된 이벤트를 중앙 이벤트 처리 계정으로 전달합니다. CloudFormation을 사용하여 다음과 같이 규칙을 정의할 수 있습니다.

CentralForwardingRule:
    Type: AWS::Events::Rule
    Properties:
      Description: Rule for sending events to central account
      EventPattern:
        source:
          - cwi.servicea
      Targets:
        - Arn: !Sub arn:aws:events:${CENTRAL_ACCOUNT_REGION}:${CENTRAL_ACCOUNT_ID}:event-bus/default
          Id: CentralTarget
          RoleArn: <IAM ROLE WITH ACCESS TO PUT CW EVENTS>

3. 이벤트는 해당 표준에 따라 검증됩니다.

4. 유효 항목이 새 소스, valid.cw.servicea를 포함하는 중앙 이벤트 버스에 다시 게시됩니다. 이 작업은 무한 루프를 피하기 위해 개별 이벤트는 한 번만 전달할 수 있기 때문에 중요합니다.

5. 필터링 규칙은 유효 이벤트를 Service B의 AWS 계정으로 전달합니다. 여기에서 AWS AppSync API에 연결된 DynamoDB 테이블을 업데이트합니다.

6. 두 번째 규칙은 Service C 계정에 동일한 이벤트를 전달합니다. 여기에서 이벤트는 Amazon Athena를 사용한 분석을 위해 Kinesis Data Firehose를 통해 Amazon S3 버킷으로 전달됩니다.

여기에서 CloudWatch Events가 제공하는 것은 대부분의 “플러그앤플레이” 서비스를 사용하는 분리된 시스템이며, 미래의 혁신을 위해 유연성을 열어두고 있습니다.

최대한 클라우드 활용

제가 CloudWatch Events를 사랑하는 가장 큰 이유는 무엇일까요? 그것은 바로 환상적인 클라우드 네이티브 서비스 때문입니다. 코드는 거의 필요하지 않으며, AWS 서비스 한도를 확인하는 것 외에는 운영 책임도 없습니다. 이 서비스 사용을 시작하기 위해 구축할 내용도 없습니다. 그럼에도 불구하고, 저는 별다른 수고를 들이지 않고도 복잡한 분산 애플리케이션을 지원할 수 있는 AWS 인프라의 강력한 기능을 사용하고 있습니다.

이 구현은 서버리스 앱의 이상적 형태에 꽤 가깝습니다. 언제라도 이벤트 중심 애플리케이션을 만들고, CloudWatch Events에서 지원할 수 있는 기능을 검토할 수 있습니다.

– Forrest Brazeal;

Amazon Web Services 한국 블로그