첫 걸음 내딛기
소개
애플리케이션 통합은 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션 내에서 분리되어 있는 구성 요소 간 커뮤니케이션을 활성화하는 일련의 서비스입니다. Amazon Web Services(AWS)는 클라우드에서 실행되는 다양한 워크로드 세트를 지원하기 위해 6개 이상의 애플리케이션 통합 서비스를 제공합니다.
조직과 워크로드에 가장 적합한 통합 서비스를 선택하는 것이 어려울 수 있습니다. 이 의사 결정 가이드는 올바른 질문을 통해 요구 사항을 파악하고 워크로드에 적합한 통합 서비스를 평가 및 선택하는 방법에 대한 명확한 지침을 제공하는 데 도움이 됩니다.
이 8분 30초 분량의 클립은 AWS re:Invent 2022에서 AWS 기업 전략 이사 그레그르 호페(Gregor Hohpe)의 프레젠테이션을 1시간 동안 녹화한 것입니다. 사용 가능한 AWS 애플리케이션 통합 서비스에 대한 개요를 제공합니다.
읽을 시간
20분
용도
워크로드에 가장 적합한 AWS 애플리케이션 통합 서비스를 결정하는 데 도움이 됩니다.
레벨
초보자
최종 업데이트 날짜
2023년 5월 31일
적용 대상 서비스
이해
AWS가 제공하는 기준, 환경 및 통합 서비스 제품군을 탐색하고 이해하려면 몇 가지 모범 사례를 검토해 보는 것이 좋습니다. 이러한 모범 사례는 선택한 서비스(또는 서비스 제품군)에 관계없이 적용됩니다.
환경에서 통합 이해
일부 조직에서는 오픈 소스 통합을 유지하는 데 필요한 시간보다 더 많은 시간을 할애하는 것이 일반적입니다. 이러한 투자를 할 때 커뮤니티 소스 및/또는 기업 또는 재단의 지원을 고려하는 것이 좋습니다. 이러한 프로젝트에 대한 투자는 재정적일 뿐만 아니라 이러한 구성 요소 및 관련 통합을 일반적으로 업데이트해야 하므로 지식 자본 및 잠재적인 기술 부채에 대한 투자이기도 합니다. 자세한 내용은 AWS 오픈 소스 블로그를 참조하세요.
아키텍처 특성 이해
광범위한 아키텍처를 지원하는 기능이 중요합니다. AWS에서 아키텍처를 구축할 때 내리는 결정을 이해하는 데 도움이 되는 가이드로 AWS Well-Architected Framework를 활용하는 것이 좋습니다. 또한 Well-Architected Framework를 사용하면 클라우드에서 안정적이고 확장 가능하며 안전하고 효율적이며 비용 효율적인 시스템을 설계하고 운영하기 위한 아키텍처 모범 사례를 배울 수 있습니다.
통합 서비스 조합 사용
목적별 서비스를 사용하는 경우 서비스 조합이 사용 사례에 가장 적합할 수 있습니다. 다음에는 AWS 고객이 여러 서비스를 조합하여 사용하는 몇 가지 일반적인 방법이 나열되어 있습니다.
- Amazon EventBridge 또는 Amazon Simple Notification Service(SNS) 이벤트를 다운스트림 소비자를 위해 버퍼로서 Amazon Simple Queue Service(Amazon SQS) 대기열로 라우팅합니다.
- EventBridge 파이프를 사용하여 스트림(Kinesis Data Streams 또는 Amazon Managed Streaming for Apache Kafka(Amazon MSK)) 또는 대기열(SQS 또는 Amazon MQ)에서 직접 이벤트를 가져오고 EventBridge 버스로 이벤트를 전송하여 소비자에게 푸시합니다.
- 분석 데이터를 수집하고 보기 위해 EventBridge 또는 SNS 이벤트를 Kinesis Data Streams 또는 Amazon MSK로 라우팅합니다.
정의
기준, 환경, 전략적 방향 및 사용 가능한 서비스(배포 호스팅 방식 및 관리 방식 모두 포함)에 대한 명확한 그림이 있으면 통합 요구 사항을 식별해야 합니다. 기존 통합 플랫폼 또는 메시지 브로커로 마이그레이션하는 경우 요구 사항 중 일부를 이미 알고 있을 수 있습니다. 하지만 클라우드 환경으로 이동하는 경우 이러한 요구 사항이 어떻게 변경되는지 설정해야 합니다.
메시징 또는 스트리밍 플랫폼
이러한 플랫폼은 특정 비즈니스 기능을 수행할 것으로 예상됩니다. 필요한 기능을 고려할 때 다음 예시 사용 사례를 사용하세요.
예 1:
서로 다른 클레임 유형(자동차, 주택 또는 생명)에 대한 메시지로 여러 유형의 클레임을 받으며 서로 다른 비즈니스 규칙을 적용하는 보험사를 예로 들어 보겠습니다. 이는 메시지 소비자가 메시지의 헤더 속성을 기반으로 클레임을 다른 대상으로 라우팅하는 기능이 있어야 함을 의미할 수 있습니다.
예 2:
비행 상태 업데이트가 Advanced Messaging Queuing Protocol(AMQP)과 같은 프로토콜을 사용하여 수하물 또는 게이트 작업과 같은 연결된 모든 시스템에 알려야 하는 항공사를 예로 들어 보겠습니다. 기능 및 비즈니스 사용 사례 프리미티브에서 가장 중요한 결정 사항은 가장 적합한 메시징 플랫폼을 구성할 옵션을 찾는 것입니다. 사용 사례에 따라 플랫폼의 적합성을 결정할 수 있는 다양한 옵션이 있습니다.
시장 채택: 이 플랫폼은 거대한 고객 커뮤니티에서 널리 채택되었으며 대부분의 사용 사례에 적합합니다. 발생할 수 있는 모든 문제에 대해 활발한 지원 커뮤니티와 함께 시도되고 테스트되었습니다. 개발 리소스에 사용할 수 있는 충분한 교육이 있는 위험도가 낮은 결정입니다.
사용 사례에 가장 적합: 이러한 플랫폼은 항공사, 물류 또는 의료 서비스와 같은 특정 산업 사용 사례에 맞게 조정됩니다. 미리 만들어진 템플릿을 채택할 수 있으므로 이러한 사용 사례에 가장 적합할 수 있습니다. 이러한 플랫폼은 쉽게 시작할 수 있지만 시장에서의 채택 수준과 유연성이 부족할 수 있습니다. 이러한 유형의 플랫폼을 채택하려면 검증 및 사내 전문 지식 구축에 많은 시간과 리소스가 필요할 수 있습니다.
최신: 클라우드 규모 배포, 멀티테넌시, 재해 복구 및 서버리스 유형의 가격 책정을 처리하기 위해 차세대 아키텍처로 구축된 플랫폼입니다. 이러한 유형의 플랫폼을 사용하려면 장기적으로 실행할 수 있도록 워크로드의 일부 리팩터링이 필요할 수 있습니다. 이는 클라우드
네이티브 플랫폼을 사용하고 최신 애플리케이션의 잘 설계된 원칙을 사용하는 데 중점을 둡니다.
예 3:
메시징 플랫폼이 다중 리전에 걸쳐 있어야 하는 대규모 대출 처리 워크플로의 일부인 경우 메시징 플랫폼도 동일한 비즈니스 요구 사항을 지원해야 합니다. 만약 비상 상황에서 비즈니스가 이전 상태로 복구하고 롤백할 수 있는 기능이 필요하다면, 기본 메시징 또는 스트리밍 플랫폼도 시스템의 상태를 다시 생성할 수 있는 스냅샷 또는 재생 기능을 갖추어야 합니다.
선택하는 통합 플랫폼은 대출 신청의 비동기 처리를 용이하게 하거나 다단계 미디어 처리 워크플로를 위한 저장 및 전달 채널 역할을 해야 합니다. 비즈니스 프로세스의 중요도에 따라 메시징 또는 스트리밍 플랫폼에서 필요한 기능이 결정됩니다.
고려 사항
클라우드의 주요 애플리케이션 통합 아키텍처를 고려할 때 각 통합 지점에 대한 기능 요구 사항을 결정하는 다양한 방법이 있습니다.
다음은 애플리케이션 통합 서비스를 선택할 때 고려해야 할 몇 가지 기준입니다.
-
관리형 서비스 및 운영 오버헤드 -
오픈 소스 -
워크로드 특성 -
빠른 반복 및 기능 속도 -
애플리케이션 이식성 -
자동화 이식성 -
조직 규모 및 기술
-
운영 부담을 AWS로 이전하는 관리형 서비스를 표준화하여 클라우드로 전환하여 운영 비용을 줄이는 것을 고려하세요. 추상화 수준을 높이면 개발자와 운영자들이 무차별적인 태스크가 아닌 각자 고유의 가치 창출 활동에 집중할 수 있습니다.
-
오픈 소스 에코시스템에서 잘못된 선택을 하면 추상화와 자체 개발된 통합에 갇힐 수 있습니다. 또한 다양한 오픈 소스 구성 요소가 함께 작동하도록 만드는 책임은 선택한 조직에게 있기도 합니다. 이로 인해 조직은 오픈 소스 통합을 유지 관리하는 데 상당한 시간을 소비하게 될 수 있습니다.
-
적합한 통합 서비스를 선택할 때 애플리케이션 간에 전송해야 하는 메시지의 특성을 이해하는 것이 중요합니다. 메시지 형식, 크기, 보존 및 우선 순위와 같은 주요 특성에 따라 통합 서비스를 결정할 수 있습니다.
일부 통합 서비스는 작은 텍스트 기반 메시지에 더 적합하지만 일부 통합 서비스는 텍스트 및 바이너리와 같은 여러 형식을 지원하고 더 큰 메시지 크기를 제공하도록 설계되었습니다. 일부 시나리오에서는 메시지 순서와 함께 재생 기능의 필요성도 중요한 요소가 될 수 있습니다.
예를 들어, Amazon SNS와 Amazon SQS에서 제공하는 FIFO 기능을 사용하여 메시지 순서를 구현할 수 있습니다. Lambda 함수를 비동기적으로 호출하는 EventBridge 또는 SNS와 같은 풀 또는 푸시 기반 아키텍처를 사용하는 것도 고려하고 있습니다.
풀 기반 아키텍처는 SQS 또는 Kinesis Data Streams와 같은 서비스를 사용할 수 있습니다. 여기서 메시지는 대기열 또는 스트림에 저장된 다음, 소비 시스템에서 검색할 수 있습니다. Amazon MQ와 같은 메시징 서비스는 더 큰 메시지 페이로드에 대한 기능을 제공하며 무제한 보존 기능을 제공합니다. 그러나 재생 기능은 제공하지 않습니다. -
빠르게 구축하고 반복하는 것이 주된 목적이라면 서버리스 서비스가 최고의 가치를 제공할 수 있습니다. 서버리스 서비스를 사용하면 인프라를 관리하지 않고도 애플리케이션을 구축할 수 있습니다. 보일러 플레이트 코드를 작성하는 데 소요되는 시간을 줄이기 위해 관리 기능과 통합을 제공합니다.
새로운 아이디어를 테스트할 때 서버리스의 또 다른 이점은 이러한 서비스가 사용량 기준 요금을 제공한다는 것입니다. 코드는 서비스가 호출될 때만 실행되므로 실험에 선행 투자가 필요하지 않습니다.
-
많은 애플리케이션은 Advanced Message Queuing Protocol(AMQP) 또는 MQ Telemetry Transport(MQTT)와 같은 특정 프로토콜을 사용하여 메시징 서비스에 연결합니다. 또는 특정 메시징 프로토콜을 사용하는 라이브러리 종속성이 있습니다. 이러한 라이브러리 또는 프레임워크의 예로는 Spring Boot, Celery 또는 MassTransit이 있습니다.
여러 가지 이유로 이러한 애플리케이션을 보존해야 할 수 있습니다. 이러한 경우 통합 서비스의 선택은 애플리케이션의 이식성을 갖는 데 필요한 프로토콜의 지원에 따라 달라집니다. -
인프라 및 배포 도구와의 호환성을 제공하고 온프레미스에서 호스팅하는 것과 동일한 통합 시스템(예: Apache ActiveMQ, RabbitMQ, Apache Kafka)을 실행하는 서비스가 필요할 수 있습니다.
관리형 오픈 소스 서비스(예: Amazon MQ 및 Amazon MSK)는 클라우드의 이점을 제공하는 동시에 온프레미스 배포에 사용되는 많은 인기 배포 도구와 호환됩니다.
애플리케이션 리팩터링이 옵션인 경우 서버리스 서비스를 사용하여 이 기능을 기본적으로 제공할 뿐만 아니라 다양한 AWS 서비스와의 풍부한 통합을 활용할 수 있습니다. -
조직의 기술은 올바른 통합 서비스를 결정할 때 중요한 요소입니다. 팀이 자체 관리형 제품에 익숙하고 요구 사항을 충족하는 경우 해당 제품에 대한 관리형 서비스를 사용하면 영향을 최소화할 수 있습니다. 이렇게 하면 서비스에 대한 모범 사례를 적용하고 부가가치 활동에 집중할 수 있습니다.
선택
이제 애플리케이션 통합 요구 사항을 평가하는 데 사용할 기준을 알았으므로, 사용자 환경의 워크로드에 적합한 AWS 서비스를 선택할 준비가 되었습니다.
메시징 서비스는 다양한 소프트웨어 시스템과 엔드 디바이스를 지원합니다. 이러한 소프트웨어 시스템과 엔드 디바이스는 서로 다른 플랫폼에서 서로 다른 프로그래밍 언어를 사용하여 정보를 교환하고 통신하는 경우가 많습니다.
스트리밍 데이터는 수천 개의 데이터 소스에서 연속적으로 생성되는 데이터로서, 보통 데이터 레코드를 작은 크기(KB 단위)로 동시에 전송합니다. 여기에는 모바일이나 웹 애플리케이션을 사용하는 고객이 생성하는 로그 파일, 전자 상거래 구매, 게임 내 플레이어 활동, 소셜 네트워크의 정보, 주식 거래소, 지리공간 서비스, 연결된 디바이스의 텔레메트리, 데이터 센터의 계측 등 다양한 데이터가 포함됩니다.
워크플로는 사람들이 작업을 완료하는 방법을 처음부터 끝까지 설명합니다. 워크플로는 체크리스트에 일련의 단계로 표시되거나 단계를 시각화하는 다이어그램으로 표시될 수 있습니다.
AWS Step Functions는 비즈니스 크리티컬 애플리케이션을 구축하기 위해 AWS Lambda 함수 및 기타 AWS 서비스와 통합할 수 있는 서버리스 오케스트레이션 서비스입니다. Step Functions의 그래픽 콘솔을 사용하여 애플리케이션의 워크플로를 일련의 이벤트 기반 단계로 볼 수 있습니다.
Amazon Managed Workflows for Apache Airflow
Amazon Managed Workflows for Apache Airflow(Amazon MWAA)는 Apache Airflow를 위한 관리형 오케스트레이션 서비스로, 클라우드에서 대규모로 데이터 파이프라인을 설정하고 운영할 수 있습니다. Apache Airflow는 워크플로라고 하는 프로세스와 태스크의 시퀀스를 프로그래밍 방식으로 작성, 예약 및 모니터링하는 데 사용되는 오픈 소스 도구입니다.
사용
이제 각 AWS 애플리케이션 통합 서비스가 무엇을 하는지, 어떤 서비스가 자신에게 적합한지 명확하게 이해했을 것입니다. 사용 가능한 각 AWS 애플리케이션 통합 서비스를 사용하는 방법을 알아보고 이에 대해 자세히 알아보기 위해 각 서비스의 작동 방식을 살펴볼 수 있는 경로를 제공했습니다. 다음 섹션에서는 시작하는 데 도움이 되는 심층 설명서, 실습 자습서 및 리소스에 대한 링크를 제공합니다.
-
Amazon SNS
-
Amazon SQS
-
Amazon EventBridge
-
Amazon MQ
-
Amazon Kinesis Data Streams
-
Amazon MSK
-
AWS Step Functions
-
Amazon MWAA
-
Amazon SNS
-
Amazon DynamoDB 및 Amazon SNS로 턴제 게임 구축
Amazon DynamoDB 및 Amazon SNS를 사용하여 멀티플레이어 턴제 게임을 구축하는 방법을 알아봅니다.
이벤트 기반 아키텍처 구축
Amazon SNS를 게시 서비스로 사용하고 Amazon SQS를 구독자로 사용하여 간단한 게시/구독 구현을 구축하는 방법을 알아봅니다.
-
Amazon SQS
-
분산 애플리케이션 간 메시지 전송
Amazon SQS 콘솔을 사용하여 메시지 대기열을 생성 및 구성하고, 메시지를 전송하고, 해당 메시지를 수신 및 삭제한 다음, 대기열을 삭제합니다.
-
Amazon EventBridge
-
Amazon EventBridge 시작하기
EventBridge의 기본은 이벤트를 대상으로 라우팅하는 규칙을 만드는 것입니다. 이 가이드에서는 기본 규칙을 생성합니다.
Amazon EventBridge를 사용하여 이벤트 기반 애플리케이션 구축
Amazon EventBridge에서 제공하는 서버리스 이벤트 버스를 사용하여 SaaS 애플리케이션 및 AWS 서비스를 비롯한 여러 애플리케이션을 연결하여 이벤트 기반 애플리케이션을 구축하는 방법을 알아봅니다.
-
Amazon MQ
-
연결된 메시지 브로커 생성
Amazon MQ 메시지 브로커를 설정하고, 코드를 다시 작성하지 않은 상태에서 Java 애플리케이션을 연결하는 방법에 대해 알아봅니다.
RabbitMQ 브로커 생성 및 연결
AWS Management Console을 사용하여 RabbitMQ 브로커를 생성하고 여기에 애플리케이션을 연결하는 방법을 알아봅니다.
AWS Serverless를 사용하여 Amazon MQ 브로커에 배포 및 게시
AWS SAM을 사용하여 서버리스 백엔드와 Amazon MQ 브로커를 한 번에 배포하는 방법을 안내해 드립니다.
-
Amazon Kinesis Data Streams
-
Amazon Kinesis Data Streams 소개
Amazon Kinesis Streams를 사용하여 실시간 스트리밍 데이터를 수집, 처리 및 분석하여 귀중한 인사이트를 얻는 방법을 설명합니다.
Amazon Kinesis Data Streams 시작하기
기본 Kinesis Data Streams 데이터 흐름 원칙과 Kinesis 데이터 스트림에서 데이터를 입력하고 가져오는 데 필요한 단계를 알아봅니다.
Amazon Kinesis Data Streams를 사용하여 가용성이 높은 스트림 구축
기본 작업 리전에서 서비스 중단, 지연 또는 중단이 발생할 경우 가용성이 높은 Kinesis 데이터 스트림을 생성하기 위한 다양한 전략을 비교하고 대조합니다.
Amazon Kinesis Data Streams용 예제 자습서
이 자습서는 Amazon Kinesis Data Streams 개념과 기능을 이해하는 데 도움이 되도록 설계되었습니다.
-
Amazon MSK
-
Amazon MSK 사용 시작하기
이 자습서에서는 MSK 클러스터를 만들고, 데이터를 생성 및 사용하고, 지표를 사용하여 클러스터의 상태를 모니터링하는 방법의 예를 보여줍니다.
MSK 서버리스 클러스터 사용 시작하기
이 자습서에서는 MSK Serverless 클러스터를 만들고, 이 클러스터에 액세스할 수 있는 클라이언트 컴퓨터를 만들고, 클라이언트를 사용하여 클러스터에 주제를 만들고 해당 주제에 데이터를 쓰는 방법에 대한 예를 보여줍니다.
Amazon MSK 실습
이 실습은 개인 또는 기업 AWS 계정이나 워크숍 스튜디오를 사용하는 이벤트에 대해 AWS 계정 팀이 프로비저닝한 계정에서 실행할 수 있습니다.
-
AWS Step Functions
-
AWS Step Functions 시작하기
이 자습서에서는 신용 카드 신청을 처리하기 위한 기본 워크플로를 만드는 과정을 안내합니다.
Step Functions 소개
이 과정에서는 애플리케이션 내에서 워크플로 관리를 시작하는 데 도움이 되는 Step Functions의 주요 구성 요소를 소개합니다.
AWS Step Functions 및 Amazon EventBridge 스케줄러를 사용하여 서버리스 워크플로 예약
정해진 일정에 따라 EventBridge 스케줄러를 사용하여 상태 머신을 호출하는 방법을 보여줍니다.
-
Amazon MWAA
-
Amazon Managed Workflows for Apache Airflow 시작하기
이 가이드에서는 Amazon MWAA를 시작하는 데 필요한 전제 조건과 필수 AWS 리소스에 대해 설명합니다.
CD 파이프라인에서 aws-mwaa-local-runner 구성
이 자습서에서는 Amazon Managed Workflows for Apache Airflow의 aws-mwaa-local-runner를 사용하여 Apache Airflow 코드를 로컬에서 테스트하여 GitHub에서 지속적 전달(CD) 파이프라인을 구축하는 과정을 안내합니다.
Amazon MWAA 사용자의 DAG 하위 집합에 대한 액세스 제한
개별 Amazon MWAA 사용자가 특정 DAG 또는 DAG 집합만 보고 상호 작용하도록 제한하는 방법을 보여줍니다.
분석 워크숍을 위한 Amazon MWAA
위에서 언급한 많은 서비스를 포함하는 데이터 및 ML 파이프라인을 구축하고 오케스트레이션하는 방법을 배우면, AWS에서 파이프라인/워크플로를 관리하기 위해 Airflow의 일부로 사용할 수 있는 후크 및 연산자에 대해 익숙해지고 더 잘 이해할 수 있습니다.
살펴보기
환경에 가장 적합한 워크로드를 결정한 후에는 이러한 리소스를 검토하여 접근 방식을 구현하는 것이 좋습니다. 서비스별 리소스는 이전 섹션에서, 일반 이벤트 기반 아키텍처 리소스는 다음 섹션에서 확인할 수 있습니다.
가용성이 높고 안전하며 유연하고 비용 효율적인 아키텍처를 만드는 데 도움이 되는 참조 아키텍처 다이어그램을 살펴보세요.
시작하는 데 도움이 되는 백서를 살펴보고 이벤트 기반 아키텍처에 대한 모범 사례를 알아보세요.
최신 기술을 파악하고 애플리케이션을 현대화하는 데 도움이 되는 블로그를 살펴보세요.