Amazon Web Services 한국 블로그

Amazon EventBridge 스키마 레지스트리 정식 출시

Amazon EventBridge는 애플리케이션을 하나로 연결할 때 손쉽게 사용할 수 있는 서버리스 이벤트 버스입니다. Amazon EventBridge는 AWS 서비스, 사용자의 애플리케이션 및 SaaS(서비스형 소프트웨어) 파트너 통합의 데이터를 사용할 수 있습니다. 지난 해 re:Invent에서 소개된 미리 보기용 EventBridge 스키마 레지스트리 및 검색은 이벤트의 구조(스키마)를 중앙 위치에 저장하는 한 방법이며, Java, Python 및 Typescript용으로 이벤트를 처리하는 코드를 생성하여 코드의 이벤트를 간편하게 사용할 수 있도록 합니다.

오늘 부터 EventBridge 스키마 레지스트리가 정식 출시되었고 리소스 정책에 대한 지원이 추가되었습니다. 리소스 정책을 사용하면 여러 AWS 계정과 조직에서 스키마 리포지토리를 공유할 수 있습니다. 이렇게 하면 여러 팀의 개발자가 다른 팀에서 공유 레지스트리에 추가한 스키마를 검색하고 사용할 수 있습니다.

EventBridge 스키마 레지스트리 리소스 정책 활용 사례
회사에서는 일반적으로 여러 개발 팀이 서로 다른 서비스에 대한 작업을 수행합니다. 좀 더 구체적인 설명을 위해, 서로 통신해야 하는 서비스에 대한 작업을 수행하는 두 팀을 예로 들어보겠습니다.

  • CreateAccount 개발 팀은 웹/모바일 클라이언트의 요청을 수신하여 회사의 새 고객 계정을 생성하는 프런트엔드 API에 대한 작업을 수행합니다.
  • FraudCheck 개발 팀은 새로 생성된 계정의 데이터를 확인하여 이 계정이 가짜일 위험을 예측하는 백엔드 서비스 작업을 수행합니다.

각 팀은 자체 AWS 계정을 사용하여 애플리케이션을 개발합니다. EventBridge를 사용하면 다음과 같은 아키텍처를 구현할 수 있습니다.

  • 프론트엔드 CreateAccount 애플리케이션은 Amazon API Gateway를 사용하여 Python으로 작성된 AWS Lambda 함수를 통해 요청을 처리합니다. 새 계정이 생성되면 Lambda 함수가 ACCOUNT_CREATED 이벤트를 사용자 지정 이벤트 버스에 게시합니다.
  • 백엔드 FraudCheck Lambda 함수는 Java로 작성되었으며 ACCOUNT_CREATED 이벤트가 수신되면 Amazon Fraud Detector(re:Invent에서 미리 보기로 소개된 완전관리형 서비스)를 호출하여 계정이 가짜 계정일 위험을 예측합니다. 위험이 특정 임계값보다 높으면 Lambda 함수가 예방 조치를 취합니다. 예를 들어 데이터베이스에 해당 계정이 가짜인 것으로 플래그를 지정하거나 이벤트 버스에 FAKE_ACCOUNT 이벤트를 게시할 수 있습니다.

두 팀이 작업 조정을 통해 이벤트의 구문을 확인하고 EventBridge를 사용하여 이러한 이벤트를 처리하는 코드를 생성하려면 어떻게 해야 할까요?

먼저, 회사 조직 내에 액세스할 수 있는 권한을 사용하여 사용자 지정 이벤트 버스를 생성합니다.

그러면 CreateAccount 팀이 EventBridge 스키마 검색을 사용하여 서비스에서 게시 중인 ACCOUNT_CREATED 이벤트에 대한 스키마를 자동으로 입력합니다. 이 이벤트에는 방금 생성된 계정의 모든 정보가 포함됩니다.

이벤트 기반 아키텍처에서 서비스는 관심이 있는 특정 유형의 이벤트를 구독할 수 있습니다. ACCOUNT_CREATED 이벤트를 수신하려면 이러한 이벤트를 FraudCheck 함수로 보내는 규칙을 이벤트 버스에 생성합니다.

CreateAccount 팀은 리소스 정책을 사용하여 FraudCheck 팀의 AWS 계정에 검색된 스키마에 대한 읽기 전용 액세스 권한을 제공합니다. 이 정책의 Principal은 권한을 받는 AWS 계정입니다. Resource는 공유되는 스키마 레지스트리입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GiveSchemaAccess",
      "Effect": "Allow",
      "Action": [
        "schemas:ListSchemas",
        "schemas:SearchSchemas", 
        "schemas:DescribeSchema",
        "schemas:DescribeCodeBinding",
        "schemas:GetCodeBindingSource",
        "schemas:PutCodeBinding"
      ],
      "Principal": {
        "AWS": "123412341234"
      },
      "Resource": [
        "arn:aws:schemas:us-east-1:432143214321:schema/discovered-schemas",
        "arn:aws:schemas:us-east-1:432143214321:schema/discovered-schemas*"
      ]
    }
  ]
}

이제 FraudCheck 팀은 ACCOUNT_CREATED 이벤트에 대해 검색된 스키마의 콘텐츠를 검색할 수 있습니다. 리소스 정책을 사용하면 여러 계정과 조직에서 레지스트리를 사용할 수 있게 되지만 콘솔에 자동으로 표시되지는 않습니다. 공유 레지스트리에 액세스하려면 FraudCheck 팀이 AWS Command Line Interface(CLI)를 사용하여 레지스트리의 전체 ARN을 지정해야 합니다.

aws schemas search-schemas \
    --registry-name arn:aws:schemas:us-east-1:432143214321:registry/discovered-schemas \
    --keywords ACCOUNT_CREATED

이렇게 하면 FraudCheck 팀이 CreateAccount 팀에 의해 생성된 스키마의 정확한 이름을 확인할 수 있습니다.

{
    "Schemas": [
        {
            "RegistryName": "discovered-schemas",
            "SchemaArn": "arn:aws:schemas:us-east-1:432143214321:schema/discovered-schemas/CreateAccount@ACCOUNT_CREATED",
            "SchemaName": “CreateAccount@ACCOUNT_CREATED",
            "SchemaVersions": [
                {
                    "CreatedDate": "2020-04-28T11:10:15+00:00",
                    "SchemaVersion": 1
                }
            ]
        }
    ]
}

스키마 이름을 알았으니 FraudCheck 팀은 스키마의 콘텐츠를 설명할 수 있습니다.

aws schemas describe-schema \
    --registry-name arn:aws:schemas:us-east-1:432143214321:registry/discovered-schemas \
    --schema-name CreateAccount@ACCOUNT_CREATED

결과에서 스키마는 OpenAPI 사양을 사용하여 설명됩니다.

{
    "Content": "{\"openapi\":\"3.0.0\",\"info\":{\"version\":\"1.0.0\",\"title\":\"CREATE_ACCOUNT\"},\"paths\":{},\"components\":{\"schemas\":{\"AWSEvent\":{\"type\":\"object\",\"required\":[\"detail-type\",\"resources\",\"detail\",\"id\",\"source\",\"time\",\"region\",\"version\",\"account\"],\"x-amazon-events-detail-type\":\"CREATE_ACCOUNT\",\"x-amazon-events-source\":\”CreateAccount\",\"properties\":{\"detail\":{\"$ref\":\"#/components/schemas/CREATE_ACCOUNT\"},\"account\":{\"type\":\"string\"},\"detail-type\":{\"type\":\"string\"},\"id\":{\"type\":\"string\"},\"region\":{\"type\":\"string\"},\"resources\":{\"type\":\"array\",\"items\":{\"type\":\"object\"}},\"source\":{\"type\":\"string\"},\"time\":{\"type\":\"string\",\"format\":\"date-time\"},\"version\":{\"type\":\"string\"}}},\"CREATE_ACCOUNT\":{\"type\":\"object\",\"required\":[\"firstName\",\"surname\",\"id\",\"email\"],\"properties\":{\"email\":{\"type\":\"string\"},\"firstName\":{\"type\":\"string\"},\"id\":{\"type\":\"string\"},\"surname\":{\"type\":\"string\"}}}}}}",
    "LastModified": "2020-04-28T11:10:15+00:00",
    "SchemaArn": "arn:aws:schemas:us-east-1:432143214321:schema/discovered-schemas/CreateAccount@CREATE_ACCOUNT",
    "SchemaName": “CreateAccount@ACCOUNT_CREATED",
    "SchemaVersion": "1",
    "Tags": {},
    "Type": "OpenApi3",
    "VersionCreatedDate": "2020-04-28T11:10:15+00:00"
}

FraudCheck 팀은 AWS Command Line Interface(CLI)에서 put-code-binding 명령을 사용하여 코드 바인딩을 생성(아직 생성되지 않은 경우)한 다음 코드 바인딩을 다운로드하여 이 이벤트를 처리할 수 있습니다.

aws schemas get-code-binding-source \
    --registry-name arn:aws:schemas:us-east-1:432143214321:registry/discovered-schemas \
    --schema-name CreateAccount@ACCOUNT_CREATED \
    --language Java8 CreateAccount.zip

FraudCheck 팀에서 사용할 수 있는 또 다른 옵션은 검색된 스키마의 Content를 복사하고 이스케이프되지 않은 JSON 문자열 뒤에 붙여 넣는 방법으로 AWS 계정에 새 사용자 지정 스키마를 생성하는 것입니다.

스키마를 자체 계정에 복사한 후 FraudCheck 팀은 AWS Toolkit IDE 플러그인을 사용하여 스키마를 보고, 코드 바인딩을 다운로드하고, IDE에서 직접 서버리스 애플리케이션을 생성할 수 있습니다. 이 단계를 간소화하기 위해 EventBridge 팀이 여러 계정에서 스키마 레지스트리를 사용하는 기능을 AWS Toolkit에 추가하는 작업을 진행 중입니다. 기대해 주십시오!

이벤트 버스는 여러 AWS 계정이 포함된 특정 팀에서 관리하는 경우가 많습니다. 단순한 설명을 위해 이 게시물에서는 CreateAccount 팀이 EventBridge 이벤트 버스를 구성한 것으로 가정했습니다. 계정이 추가되면 IAM을 사용하여 AWS Organizations의 AWS 계정 그룹과 리소스를 공유하는 권한을 간소화할 수 있습니다.

정식 출시
Amazon EventBridge 스키마 레지스트리는 바레인, 케이프타운, 밀라노, 오사카, 베이징 및 닝샤를 제외한 모든 상용 리전에서 이용 가능합니다. 스키마 레지스트리에 리소스 정책을 사용하는 방법에 대한 자세한 내용은 설명서를 참조하십시오.

스키마 레지스트리 리소스 정책을 사용하면 이벤트 기반 아키텍처에서 정보를 공유하는 여러 팀의 작업을 조정하기가 훨씬 쉬워집니다.

Danilo