Amazon Web Services 한국 블로그
Amazon SNS를 통한 이벤트 기반 컴퓨팅으로 AWS 주요 서비스 활용하기
모든 개발자가 그렇듯이 여러분은 점점 더 복잡해지는 비즈니스 문제를 풀어야 합니다. 이 때, 가장 중요한 성공 요소는 대규모 프로젝트를 작게 나눠서 관리하기 쉬운 요소로 분류할 수 있어야 합니다. 서비스 지향 아키텍처는 느슨하게 결합되어 독립적으로 확장이 되고, 재사용 가능성이 높은 서비스의 모음 형태로 시스템을 설계할 수 있습니다. 이에 대한 현대적인 개념이 바로 마이크로서비스(Microservices) 입니다. 각 서비스의 성능 및 확장성을 강화하기 위해 마이크로서비스는 세분화된 인터페이스 및 경량 프로토콜을 활용하는 방향으로 진화하고 있습니다.
그러나, 각 마이크로서비스 간 통신은 어려운 작업일 수 있습니다. 각 서비스는 대개 독립된 서버에 배포되며 컴퓨팅 또는 스토리지 리소스를 공유하지 않기 때문에, 유지 관리 및 재사용 가능성을 보존하기 위해 마이크로서비스 간의 높은 의존성을 피해야 합니다.
pub/sub 설계 패턴을 적용하면 마이크로서비스와 서버리스 아키텍처를 쉽게 분리하고 독립적으로 확장할 수 있습니다. Amazon SNS와 같은 pub/sub 메시징 서비스는 이벤트 게시자와 구독자를 정적으로 분리하는 동시에 해당 게시자와 구독자 간 메시지 교환을 동적으로 허용하는 이벤트 기반 컴퓨팅을 촉진합니다. 또한 이벤트 기반 아키텍처는 주로 예측하기 어렵고 비동기적인 복잡한 문제를 처리하는 데 필요한 응답성을 제공합니다.
이벤트 기반 컴퓨팅이란?
마이크로서비스의 관점에서 볼 때 이벤트 기반 컴퓨팅은 구독자 서비스가 게시자 서비스에 의해 트리거된 이벤트에 응답하여 작업을 자동으로 수행하는 모델입니다. 이 패러다임을 적용하면 워크플로우를 자동화하는 동시에 이러한 워크플로우를 수행하기 위해 집합적으로 그리고 독립적으로 동작하는 서비스를 분리할 수 있습니다. Amazon SNS는 AWS 클라우드의 이벤트 기반 컴퓨팅 허브로서 여러 AWS 게시자 및 구독자 서비스와 기본으로 통합되어 있습니다.
Amazon SNS 에 이벤트 게시를 기본 지원하는 AWS 서비스
여러 AWS 서비스가 SNS 게시자로 통합되어 있으므로 다양한 사용 사례에 대해 이벤트 기반 컴퓨팅을 기본적으로 트리거할 수 있습니다. 이 글에서는 특별히 아래에 설명된 AWS 컴퓨팅, 스토리지, 데이터베이스 및 네트워킹 서비스에 대해 다룹니다.
컴퓨팅 서비스
- Auto Scaling: 애플리케이션의 로드를 처리하는 데 필요한 Amazon EC2 인스턴스 수를 확보할 수 있도록 지원합니다. Auto Scaling 수명 주기 후크를 구성하여 Auto Scaling이 EC2 클러스터의 크기를 조정할 때 이벤트를 트리거할 수 있습니다. 예를 들어 새로 시작된 EC2 인스턴스의 로컬 캐시 스토어를 준비할 수 있으며, 곧 종료되려고 하는 다른 EC2 인스턴스에서 로그 파일을 다운로드할 수도 있습니다. 이를 수행하려면 SNS 주제를 Auto Scaling 그룹의 알림 대상으로 설정한 후 이 SNS 주제에 2개의 Lambda 함수를 구독합니다. 첫 번째 함수는 스케일아웃 이벤트 처리를 담당하고(프로비저닝 시 캐시 준비), 두 번째 함수는 스케일인 이벤트 처리를 담당합니다(종료 시 로그 다운로드).
- AWS Elastic Beanstalk: 여러 프로그래밍 언어로 개발된 웹 애플리케이션 및 웹 서비스를 배포 및 확장하는데 쉽게 활용할 수 있는 서비스입니다. Elastic Beanstalk 환경에 대해 이벤트 알림을 구성하면 중요한 이벤트가 SNS 주제에 자동으로 게시되고 주제 구독자에게 푸시될 수 있도록 할 수 있습니다. 예를 들어 이 이벤트 기반 아키텍처를 사용하여 연속 통합 파이프라인(예: Jenkins CI)을 조정할 수 있습니다. 새로운 환경이 생성될 때마다 Elastic Beanstalk가 해당 이벤트를 SNS 주제에 게시합니다. 그리고 이 이벤트는 구독하는 Lambda 함수를 트리거한 후 새로 생성된 Elastic Beanstalk 환경에 대한 CI 작업을 시작합니다.
- Elastic Load Balancing: 수신되는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너 또는 IP 주소로 식별되는 기타 리소스 전반에 자동으로 배포합니다. Classic Load Balancer에서 파생된 이벤트를 자동으로 처리하기 위해 Elastic Load Balancing 지표에서 CloudWatch 경보를 구성할 수 있습니다. 예를 들어 이러한 이벤트 기반 설계를 활용하면 Classic Load Balancer 뒤에 있는 Amazon ECS 클러스터의 지연 시간 프로파일링을 자동화할 수 있습니다. 이 예에서 ECS 클러스터가 로드 밸런서의 지연 시간 임계값을 초과할 때마다 CloudWatch는 해당 이벤트를 SNS 주제에 게시합니다. 그러면 구독하는 Lambda 함수가 트리거됩니다. 이 함수는 ECS 클러스터에서 작업을 실행하여 클러스터 자체에 호스팅된 지연 시간 프로파일링 도구를 트리거합니다. 이러한 방식으로 적절한 시간에 수행을 통해 지연 시간 문제 해결 역량을 강화할 수 있습니다.
스토리지 서비스
- Amazon S3: 많은 양의 데이터를 저장 및 검색할 수 있도록 구축된 객체 스토리지입니다. S3 이벤트 알림을 활성화하고 해당 알림을 SNS 주제에 자동으로 게시함으로써 다양한 워크플로우를 자동화할 수 있습니다. 예를 들어 지원자가 제출하는 이력서를 수신 및 저장하는 S3 버킷과 이러한 이력서를 원본 형식(예: Word 또는 텍스트)에서 배포할 수 있는 형식(예: PDF)으로 인코딩하는 EC2 인스턴스 플릿이 있을 수 있습니다. 이 예에서 새로운 파일이 입력 버킷에 업로드될 때마다 S3는 해당 이벤트를 SNS 주제에 게시하며, 결과적으로 이러한 메시지를 구독하는 SQS 대기열로 푸시합니다. 그런 다음, EC2 인스턴스에서 실행 중인 인코딩 작업자가 SQS 대기열에서 이러한 메시지를 폴링합니다. 그리고 원본 파일을 입력 S3 버킷에서 검색하고, PDF로 인코딩하며, 마지막으로 출력 S3 버킷에 저장합니다.
- Amazon EFS: AWS 클라우드에서 Amazon EC2 인스턴스에 사용할 수 있는 간단하고 확장 가능한 파일 스토리지를 제공합니다. EFS 시스템의 관리를 자동화하기 위해 EFS 지표에서 CloudWatch 경보를 구성할 수 있습니다. 예를 들어 EFS 시스템에서 실행되는 고도로 병렬화된 유전자 분석 애플리케이션을 생각해 볼 수 있습니다. 기본적으로 이 파일 시스템은 “범용” 성능 모드에서 인스턴스화됩니다. 이 성능 모드에서는 지연 시간을 단축할 수 있지만 결국에는 크기 조정 병목 현상이 발생할 수 있습니다. 이를 이벤트 기반 설계를 활용하여 자동으로 처리할 수 있습니다. 기본적으로 EFS 지표 “Percent I/O Limit”가 95%를 초과하는 즉시 CloudWatch는 이 이벤트를 SNS 주제에 게시하고 이 메시지를 구독하는 Lambda 함수로 푸시합니다. 이 함수는 “Max I/O” 성능 모드에서 새 파일 시스템을 자동으로 생성한 후 유전자 분석 애플리케이션을 이 새로운 파일 시스템을 이용하도록 전환합니다. 결과적으로 애플리케이션이 높은 I/O 처리 속도를 활용하기 시작합니다.
- Amazon Glacier: 데이터 보관 및 장기 백업을 위한 안전하고 내구성 있는 저비용 클라우드 스토리지 서비스입니다. 작업 완료 시 SNS 주제에 메시지를 게시할 수 있도록 Amazon Glacier 볼트에 알림 구성을 설정할 수 있습니다. Amazon Glacier에서 아카이브를 검색하는 작업은 2단계로 비동기 처리됩니다. 먼저, 작업을 시작한 후 작업이 완료되면 출력을 다운로드합니다. 따라서 SNS를 사용하면 Amazon Glacier 볼트를 폴링하지 않아도 작업 완료 여부를 확인할 수 있습니다. 일반적으로 SNS 주제에 SQS 대기열, Lambda 함수 및 HTTP 엔드포인트를 구독하여 Amazon Glacier 작업이 완료되었을 때 알림을 받을 수 있습니다.
- AWS Snowball: 대량의 데이터를 전송하는 데 보안 어플라이언스를 사용하는 페타바이트 규모의 데이터 전송 솔루션입니다. Snowball 알림을 활용하면 AWS로 데이터를 가져오고 AWS에서 데이터를 내보내는 것과 관련된 워크플로우를 자동화할 수 있습니다. 더 구체적으로 말하면, Snowball 작업 상태가 변경될 때마다 Snowball은 이 이벤트를 SNS 주제에 게시하고 결국 모든 해당 구독자에게 이벤트를 브로드캐스팅할 수 있습니다. 예를 들어 웹 브라우저를 통해 사용자에게 고해상도 위성 이미지를 배포하는 GIS(지리 정보 시스템)를 생각해볼 수 있습니다. 이 예에서 GIS 공급업체는 최대 80TB의 위성 이미지를 캡처할 수 있습니다. 그리고 Snowball 작업을 생성하여 이러한 파일을 온프레미스 시스템에서 S3 버킷으로 가져오고 Snowball의 작업 상태 변경 시 알림을 받을 SNS 주제 ARN을 제공합니다. Snowball 작업 상태가 “가져오는 중”에서 “완료됨”으로 변경되면 Snowball은 지정된 SNS 주제에 이 이벤트를 게시합니다. 그러면 구독하는 Lambda 함수로 이 메시지가 전달되고 마지막으로 대상 S3 버킷의 CloudFront 웹 배포가 생성됨으로써 최종 사용자에게 이미지가 제공됩니다.
- Amazon SNS의 Snowball 알림(AWS Snowball 사용 설명서)
- Amazon SNS의 Snowball 알림(AWS Snowball API 참조)
- CloudFront 시작
데이터베이스 서비스
- Amazon RDS: 클라우드에서 관계형 데이터베이스를 쉽게 설정, 운영 및 확장할 수 있게 해줍니다. RDS 이벤트가 발생할 때 RDS는 SNS를 이용해서 알림을 브로드캐스팅합니다. 일반적으로 이러한 알림은 SQS 대기열, Lambda 함수 및 HTTP 엔드포인트를 비롯하여 SNS에서 지원하는 모든 프로토콜을 통해 전달될 수 있습니다. 예를 들어 운영하는 소셜 네트워크 웹 사이트가 역동적으로 성장하여 컴퓨팅 및 데이터베이스 리소스를 확장할 필요가 있다고 가정해 보겠습니다. 이 경우 SNS 주제를 제공하여 RDS DB 인스턴스 이벤트를 수신할 수 있습니다. “로우 스토리지” 이벤트가 주제에 게시되면 SNS는 구독하는 Lambda 함수로 이벤트를 푸시하고, 결과적으로 RDS API를 활용함으로써 DB 인스턴스에 할당된 스토리지 용량을 늘립니다. 프로비저닝 자체는 지정된 DB 유지 관리 기간 내에 수행됩니다.
- Amazon ElastiCache: 클라우드에서 인 메모리 데이터 스토어 또는 캐시를 쉽게 배포, 운영 및 확장할 수 있게 하는 웹 서비스입니다. ElastiCache는 캐시 클러스터에서 중요한 이벤트가 발생할 때 Amazon SNS를 사용하여 메시지를 게시할 수 있습니다. 이 기능을 사용하면 캐시 클러스터의 개별 캐시 노드 엔드포인트에 연결된 클라이언트 장비의 서버 목록을 새로 갱신할 수 있습니다. 예를 들어 전자 상거래 웹 사이트는 관계형 데이터베이스를 오프로드하고 페이지 로드 시간을 단축하기 위한 목적으로 캐시 클러스터에서 제품 세부 정보를 가져옵니다. 이상적으로 말하면, 연결할 캐시 서버와 관련하여 업데이트된 목록이 각 웹 서버에 있는지 항상 확인하려고 합니다. 이 노드 검색 프로세스를 자동화하기 위해서는 ElastiCache 클러스터를 가져와서 이벤트를 SNS 주제에 게시할 수 있습니다. 따라서 ElastiCache 이벤트인 “AddCacheNodeComplete”가 게시되면 해당 주제는 전자 상거래 웹 사이트 서비스를 제공하는 모든 구독 HTTP 엔드포인트로 이 이벤트를 푸시하므로 이러한 HTTP 서버가 해당 캐시 노드 목록을 업데이트할 수 있습니다.
- Amazon Redshift: 표준 SQL 및 BI(비즈니스 인텔리전스) 도구를 사용하여 데이터를 간단하게 분석할 수 있게 하는 완전관리형 데이터 웨어하우스입니다. Amazon Redshift는 데이터 웨어하우스 워크플로우를 자동화할 수 있도록 SNS를 사용하여 관련 이벤트를 브로드캐스팅합니다. 예를 들어 클릭스트림 데이터를 Kinesis Firehose 스트림에 보내면 Amazon Redshift에 데이터가 로드되어 인기 있는 뉴스 및 읽기 기본 설정이 BI 도구에 표시되도록 하는 뉴스 웹 사이트를 생각해 볼 수 있습니다. 어떤 시점에서 이 Amazon Redshift 클러스터의 크기를 조정해야 할 수 있습니다. 그리고 클러스터는 준비 전용 모드로 전환됩니다. 따라서 이 Amazon Redshift 이벤트는 SNS 주제에 게시되며, 구독하는 Lambda 함수로 이 이벤트를 전달하고, 마지막으로 클릭스트림 데이터 업로드를 보류할 수 있도록 해당 Kinesis Firehose 전송 스트림을 삭제합니다. 나중에 Amazon Redshift가 유지 관리 기간이 종료된 이벤트를 게시하면 SNS는 그에 맞춰 구독하는 Lambda 함수에 알립니다. 그러면 이 함수는 Kinesis Firehose 전송 스트림을 다시 생성하고 Amazon Redshift로 클릭스트림 데이터 업로드를 재개할 수 있습니다.
- AWS DMS: 이 서비스를 통해 데이터베이스를 AWS로 빠르고 안전하게 마이그레이션할 수 있습니다. 소스 데이터베이스는 마이그레이션 중에도 운영 상태를 유지하며 데이터베이스를 사용하는 애플리케이션의 다운타임을 최소화할 수 있습니다. 또한 DMS 이벤트가 발생할 때 DMS는 SNS를 사용하여 알림을 제공하며 이를 통해 데이터베이스 마이그레이션 워크플로우를 자동화할 수 있습니다. 예를 들어 여러 테이블로 구성된 온프레미스 MS SQL 데이터베이스를 MySQL로 마이그레이션하는 데이터 복제 작업을 만들 수 있습니다. 이를 통해 소스 테이블에서 호환되지 않는 데이터 인코딩으로 인해 복제 작업이 실패한 경우 이러한 이벤트를 SNS 주제에 게시하고, 구독하는 SQS 대기열로 이러한 메시지를 푸시할 수 있습니다. 그러면 EC2에서 실행되는 인코더가 SQS 대기열에서 이러한 메시지를 폴링하고 소스 테이블을 호환 가능한 문자 세트로 인코딩한 후 DMS에서 해당 복제 작업을 다시 시작할 수 있습니다. 이는 자체 복구 데이터베이스 마이그레이션 프로세스에 대한 이벤트 기반 접근 방식입니다.
네트워킹 서비스
- Amazon Route 53: 가용성 및 확장성이 뛰어난 클라우드 기반 DNS(도메인 이름 시스템)입니다. Route 53 상태 검사는 웹 애플리케이션, 웹 서버 및 기타 리소스의 상태 및 성능을 모니터링합니다. CloudWatch 경보를 설정하면 Route 53 상태 검사의 상태가 변경되는 경우 자동화된 Amazon SNS 알림을 받을 수 있습니다. 예를 들어 상태 페이지를 통해 전 세계 판매자에게 플랫폼의 상태를 보고하는 온라인 결제 게이트웨이를 가정해 보겠습니다. 이 페이지는 EC2에 호스팅되며 DynamoDB에서 플랫폼 상태 데이터를 가져옵니다. 이 경우 Route 53 상태 검사에 대해 CloudWatch 경보를 구성할 수 있습니다. 그러면 경보 임계값을 초과하여 결제 게이트웨이가 더 이상 정상적이지 않은 것으로 감지되는 경우 CloudWatch는 이 이벤트를 SNS 주제에 게시한 후 구독하는 Lambda 함수로 이 메시지를 푸시하며, 마지막으로 상태 페이지를 기록하는 DynamoDB 테이블을 업데이트합니다. 이 이벤트 기반 접근 방식으로 판매자가 방문한 상태 페이지에 대한 모든 종류의 수동 업데이트를 방지할 수 있습니다.
- AWS Direct Connect(AWS DX): 온프레미스에서 AWS로의 전용 네트워크 연결을 손쉽게 구축할 수 있게 합니다. 이를 통해 네트워크 비용을 절감하고 대역폭 처리량을 증대하며 인터넷 기반 연결보다 더 일관된 네트워크 환경을 제공할 수 있습니다. CloudWatch 경보를 사용하여 물리적 DX 연결을 모니터링할 수 있으며 경보가 해당 상태를 변경하는 경우 SNS 메시지를 보낼 수 있습니다. 예를 들어 DX 연결 상태가 0(영)으로 바뀌는 경우 이는 연결이 끊어졌음을 나타냅니다. 이러한 경우 이 이벤트를 SNS 주제에 게시할 수 있으며 HTTP 엔드포인트를 통해 영향받는 서버로 이 메시지를 팬아웃할 수 있으므로 대신 다른 연결을 통해 해당 트래픽을 다시 라우팅할 수 있습니다. 이는 연결 복원력에 대한 이벤트 기반 접근 방식입니다.
AWS의 이벤트 기반 컴퓨팅에 관한 추가 정보
SNS 외에, 이벤트 기반 컴퓨팅은 Amazon CloudWatch Events에서도 구현되어 AWS 리소스의 변화를 나타내는 시스템 이벤트의 거의 실시간 스트림을 제공합니다. CloudWatch Events를 통해 다음을 비롯하여 하나 이상의 대상에 각 이벤트 유형을 라우팅할 수 있습니다.
- Amazon SQS 대기열
- Amazon EC2 인스턴스
- Amazon ECS 작업
- Amazon Kinesis Streams
- Amazon Kinesis Firehose 전송 스트림
- AWS Lambda 함수
- AWS Step Functions 상태 시스템
- AWS CodePipeline 파이프라인
여러 AWS 서비스가 CloudWatch에 이벤트를 게시합니다. 예를 들어 CloudWatch Events를 가져와서 AWS Glue에서 실행 중인 ETL(추출, 변환, 로드) 작업의 이벤트를 캡처하고 실패한 작업을 SQS 대기열로 푸시할 수 있습니다. 그러면 실패한 작업을 나중에 재시도할 수 있습니다.
마무리
Amazon SNS는 전 세계 AWS 고객이 이벤트 기반 컴퓨팅 허브로 사용할 수 있는 pub/sub 메시징 서비스입니다. EC2, S3 및 RDS와 같은 AWS 서비스에서 기본적으로 트리거한 이벤트를 캡처함으로써 확장, 테스트, 인코딩, 프로파일링, 브로드캐스팅, 검색, 장애 조치 등과 같은 모든 종류의 워크플로우를 자동화 및 최적화할 수 있습니다. 이 글에서는 채용 웹 사이트에서 과학 연구, 지리 시스템, 소셜 네트워크, 소매 웹 사이트 및 뉴스 포털에 이르기까지 다양한 비즈니스 사용 사례를 소개했습니다.
지금 바로 AWS Management Console에서 Amazon SNS를 방문하거나 AWS 10분 자습서, Amazon SNS 및 Amazon SQS로 팬아웃 이벤트 알림 보내기를 이용해서 시작해 보시기 바랍니다.
– Otavio Ferreira, AWS 메시징 소프트웨어 개발 매니저