最初の一歩を踏み出す
はじめに
アプリケーション統合は、マイクロサービス、分散システム、サーバーレスアプリケーション内で疎結合の各コンポーネント間の通信を可能にする一連のサービスです。Amazon Web Services (AWS) は、クラウド内で実行されるさまざまな一連のワークロードをサポートするために、6 を超える数のアプリケーション統合サービスを提供しています。
組織やワークロードに最適な統合サービスを選択しにくい場合もあります。この意思決定ガイドは、適切な質問をして要件を明らかにするのに役立つとともに、ワークロードのための適切な統合サービスを評価および選択する方法について明確なガイダンスを提供します。
この 8 分半の短時間の動画は、AWS re:Invent 2022 における AWS の Enterprise Strategy 担当 Director である Gregor Hohpe による 1 時間のプレゼンテーションを録画したものの一部です。利用可能な AWS アプリケーション統合サービスの概要を説明します。
所要時間
20 分
目的
どの AWS アプリケーション統合サービスがワークロードに最適であるかを判断するのに役立ちます。
レベル
初心者
最終更新日
2023 年 5 月 31 日
対象サービス
理解
基準、環境、AWS が提供する一連の統合サービスを詳しく確認して理解するプロセスを開始する際には、いくつかのベストプラクティスを確認することをお勧めします。これらのベストプラクティスは、選択するサービス (またはサービススイート) にかかわらず適用できます。
環境における統合を理解する
一部の組織では、オープンソース統合のメンテナンスに、許容範囲を超える時間を費やしていることがよくあります。これらの投資を行う際には、コミュニティソース、および/または企業や財団からの支援を検討することをお勧めします。これらのプロジェクトへの投資は金銭的なものだけでなく、知識資本や潜在的な技術的負債への投資でもあります。なぜなら、これらのコンポーネントや関連する統合は通常、更新を必要とするからです。詳細については、AWS オープンソースブログをご覧ください。
アーキテクチャの特性を理解する
幅広いアーキテクチャをサポートできることが重要です。AWS でアーキテクチャを構築する際の意思決定を理解するためのガイドとして、AWS Well-Architected フレームワークを活用することをお勧めします。さらに、Well-Architected フレームワークを使用することで、信頼性、スケーラビリティ、安全性、効率性、コスト効率の高いシステムを設計して、クラウド内で運用するためのアーキテクチャのベストプラクティスを学ぶことができます。
統合サービスを組み合わせて使用する
目的別サービスでは、サービスを組み合わせて利用することが、ユースケースに最適である可能性があります。AWS のお客様がサービスを組み合わせて利用する一般的な方法をいくつか次に示します。
- ダウンストリームのコンシューマーのためのバッファとして、Amazon EventBridge または Amazon Simple Notification Service (Amazon SNS) イベントを Amazon Simple Queue Service (Amazon SQS) キューにルーティングする。
- EventBridge Pipes を利用して、ストリーム (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) などのプロトコルを使用して、フライトステータスの更新内容を、手荷物やゲート操作など、接続されているすべてのシステムに通知する必要がある航空会社について考えてみましょう。機能およびビジネスユースケースのプリミティブに関する大きな問題は、最適なメッセージングプラットフォームを構成する要素は何かということです。複数の選択肢があり、ユースケースに基づいてプラットフォームの適合性を判断できます。
市場での採用: このプラットフォームは大規模なお客様コミュニティに広く採用されており、ほとんどのユースケースに十分に適合します。発生し得る問題は、活発なサポートコミュニティによって十分に試行およびテストされています。開発リソース向けの十分なトレーニングを利用できるため、これは低リスクの意思決定です。
ユースケースに最適: これらのプラットフォームは、航空会社、物流、ヘルスケアなどの特定の業界のユースケースに合わせてカスタマイズされます。これらは、採用可能な既製のテンプレートを使用するユースケースに最適である場合があります。これらのプラットフォームは簡単に使用を開始できますが、市場での採用率が低く、柔軟性に欠ける場合があります。このタイプのプラットフォームの採用には、検証を実施し、社内で専門知識を構築するための、多大な時間とリソースが必要な可能性があります。
モダン: これらのプラットフォームは、クラウドスケールのデプロイ、マルチテナンシー、ディザスタリカバリ、サーバーレスの料金タイプに対応する次世代アーキテクチャを使用して構築されています。このタイプのプラットフォームを利用する場合、長期にわたって有用性を維持するために、ワークロードのリファクタリングが必要になる場合があります。クラウド
ネイティブプラットフォームを使用し、モダンアプリケーションの AWS Well-Architected 原則を採用することに重点を置いています。
例 3:
メッセージングプラットフォームが大規模なローン処理ワークフローの一部であり、かつ、それがマルチリージョンでなければならない場合、メッセージングプラットフォームも同じビジネス要件をサポートする必要があります。想定外の状況において、回復して以前の状態にロールバックする機能をビジネスが必要とする場合、基盤となるメッセージングプラットフォームまたはストリーミングプラットフォームも、システムの状態を再作成するためのスナップショット機能または再生機能を備えている必要があります。
選択する統合プラットフォームは、ローン申請の非同期処理を容易にしたり、複数ステップのメディア処理ワークフロー用にストアアンドフォワードチャネルとして機能したりする必要があります。ビジネスプロセスの重要度によって、メッセージングプラットフォームまたはストリーミングプラットフォームに必要な機能が決まります。
検討事項
クラウドでの主要なアプリケーション統合アーキテクチャを検討する場合、各統合ポイントの機能的な要件を決定するさまざまな方法があります。
アプリケーション統合サービスを選択する際に考慮すべき基準の一部を次に示します。
-
マネージドサービスと運用上のオーバーヘッド -
オープンソース -
ワークロードの特性 -
迅速なイテレーションと高速な機能提供 -
アプリケーションポータビリティ -
オートメーションポータビリティ -
組織の規模とスキル
-
運用上の負担を AWS に移すマネージドサービスで標準化することで運用コストを削減するために、クラウドに移行することをご検討ください。より高いレベルの抽象化により、デベロッパーとオペレーターは、差別化につながらない作業タスクではなく、独自の付加価値を生み出すための活動に注力できるようになります。
-
オープンソースのエコシステムで選択を誤ると、抽象化や自社開発の統合にロックインされてしまう可能性があります。さらに、さまざまなオープンソースコンポーネントを連携させる責任は、多くの場合、その選択を行った組織にあります。これにより、組織はオープンソース統合のメンテナンスに多大な時間を費やすことになる場合があります。
-
適切な統合サービスを選択する際には、アプリケーション間で送信する必要があるメッセージの特性を理解することが重要です。メッセージの形式、サイズ、保持、優先度などの主要な特性は、統合サービスを決定する際の考慮要素となります。
小さなテキストベースのメッセージにより適している統合サービスもあれば、テキストやバイナリなどの複数の形式をサポートし、より大きなメッセージサイズを提供するように設計されている統合サービスもあります。一部のシナリオでは、再生機能の必要性もメッセージの順位付け機能と並んで重要な要素となる可能性があります。
例えば、メッセージの順序付け機能は、Amazon SNS および Amazon SQS が提供する FIFO 機能を使用して実装できます。Lambda 関数を非同期的に呼び出す EventBridge や SNS など、プルまたはプッシュベースのアーキテクチャを採用することも検討対象となります。
プルベースのアーキテクチャでは、SQS や Kinesis Data Streams などのサービスを利用できます。この場合、メッセージはキューまたはストリームに保存され、消費するシステムはそのメッセージを取得できます。Amazon MQ などのメッセージングサービスは、より大きなメッセージペイロードに関する機能を提供し、無制限に保持します。ただし、再生機能は提供されません。 -
構築とイテレーションを迅速に行うことに主に重点を置いている場合、サーバーレスサービスは最高の価値をもたらす可能性があります。サーバーレスサービスでは、インフラストラクチャを管理することなく、アプリケーションを構築できます。これらはマネージド機能と統合を提供し、ボイラープレートコードの記述にかかる時間を削減します。
新しいアイデアをテストする場合のサーバーレスのもう 1 つの利点は、これらのサービスで使用量に基づく料金体系を利用できることです。コードはサービスが呼び出されたときにのみ実行されるため、実験では事前に投資する必要がありません。
-
多くのアプリケーションは、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 単位) で同時的にデータレコードが送信されます。モバイルアプリケーションやウェブアプリケーションを使用して、顧客によって生成されるログファイル、e コマースでの購入内容、ゲーム内でのプレイヤーのアクティビティ、さらにはソーシャルネットワーク、証券取引所の立会場、または地理空間サービスからの情報、およびデータセンター内の接続されたデバイスや計器からのテレメトリなど、広範なデータが含まれます。
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
-
Filter Messages Published to Topics with Amazon SNS and Amazon SQS
Amazon SNS のメッセージフィルタリング機能の使用方法をご覧ください。
Introducing message data protection for Amazon SNS
このブログ記事では、メッセージデータ保護とは何か、またその仕組みについて説明します。
Build a turn-based game with Amazon DynamoDB and Amazon SNS
Amazon DynamoDB と Amazon SNS を使用してマルチプレイヤーのターン制ゲームを構築する方法をご覧ください。
Building event driven architectures
Amazon SNS をパブリッシュサービス、Amazon SQS をサブスクライバーとして使用して、シンプルな Pub/Sub 実装を構築する方法をご覧ください。
-
Amazon SQS
-
Introduction to Amazon SQS
Amazon Simple Queue Service (SQS) の概要と、疎結合システムを使用する利点について説明します。
Send Fanout Event Notifications
Amazon SNS と Amazon SQS を使用して、ファンアウトメッセージングシナリオを実装する方法をご覧ください。
Orchestrate Queue-based Microservices
メッセージキューベースのマイクロサービスをオーケストレートするサーバーレスワークフローを設計および実行する方法をご覧ください。
Send Messages Between Distributed Applications
Amazon SQS コンソールを使用して、メッセージキューの作成と設定、メッセージの送信、メッセージの受信、受信したメッセージの削除、キューの削除を行います。
-
Amazon EventBridge
-
Amazon EventBridge の開始方法
EventBridge の基本は、イベントをターゲットにルーティングするルールを作成することです。このガイドでは、基本的なルールを作成します。
Build event-driven architectures
イベント駆動型設計の基本、ジョブに適した AWS のサービスの選択方法、コストとパフォーマンスの両方を最適化する方法をご覧ください。
Building event-driven applications with Amazon EventBridge
Amazon EventBridge が提供するサーバーレスイベントバスを使用して、SaaS アプリケーションや AWS のサービスなどの複数のアプリケーションを接続することにより、イベント駆動型アプリケーションを構築する方法をご覧ください。
-
Amazon MQ
-
Accelerating messaging modernization
Amazon MQ についてご紹介し、それをより深く理解するためにいくつかの実践ラボに参加できます。
Create a connected message broker
Amazon MQ メッセージブローカーを設定し、コードを書き直すことなく、Java アプリケーションを接続する方法をご覧ください。
RabbitMQ ブローカーの作成と接続
AWS マネジメントコンソールを使用して RabbitMQ ブローカーを作成し、それにアプリケーションをアタッチする方法をご覧ください。
ActiveMQ workshop
キュー、トピック、Amazon MQ の機能 (例: フェイルオーバーやブローカーのネットワーク) などのメッセージングの概念を詳しく見ていきます。
Deploy and publish to an Amazon MQ broker using AWS serverless
AWS SAM を利用して、サーバーレスバックエンドと Amazon MQ ブローカーをワンステップでデプロイする手順を説明します。
-
Amazon Kinesis Data Streams
-
Introduction to Amazon Kinesis Data Streams
Amazon Kinesis Streams を利用して、リアルタイムのストリーミングデータを収集、処理、分析し、貴重なインサイトを生み出す方法を説明します。
Getting started with Amazon Kinesis Data Streams
Kinesis Data Streams のデータフローに関する基本原則と、Kinesis Data Streams へのデータの入力や、Kinesis Data Streams からのデータの取得に必要なステップをご覧ください。
Build highly available streams with Amazon Kinesis Data Streams
主要な運用リージョンでサービスの中断、遅延、停止が発生した場合に備えて、可用性の高い Kinesis データストリームを作成するためのさまざまな戦略を比較対照します。
Example Tutorials for Amazon Kinesis Data Streams
これらのチュートリアルは、Amazon Kinesis Data Streams の概念と機能を理解するのにさらに役立つように設計されています。
Real Time Streaming with Amazon Kinesis
ユーザーが AWS 上でストリーミング分析アプリケーションを構築するのに役立つ一連のラボ演習を詳しく見ていきます。
-
Amazon MSK
-
Getting started using Amazon MSK
このチュートリアルでは、MSK クラスターを作成し、データを生成および消費し、メトリクスを使用してクラスターのヘルスをモニタリングする方法の例を示します。
Getting started using MSK Serverless clusters
このチュートリアルでは、MSK Serverless クラスターを作成し、それにアクセスできるクライアントマシンを作成するとともに、そのクライアントを使用してクラスター上にトピックを作成し、それらのトピックにデータを書き込む方法の例を示します。
Amazon MSK Labs
これらのラボは、個人もしくは企業の AWS アカウント、またはワークショップスタジオを使用するイベント用に AWS アカウントチームがプロビジョニングしたアカウントのいずれかで実行できます。
-
AWS Step Functions
-
Getting started with AWS Step Functions
これらのチュートリアルでは、クレジットカード申請を処理するための基本的なワークフローの作成について説明します。
Introduction to Step Functions
このコースでは、アプリケーション内でワークフローの管理を開始するのに役立つ Step Functions の主要なコンポーネントをご紹介します。
Create a 'first-to-respond' task request fanout pattern
e コマース企業のために配送を行うドライバーのグループを適所に配置する方法をご覧ください。
Design Patterns for AWS Step Functions
Step Functions のステートマシンに設計パターンを実装する方法と、各パターンを使用すべき理由をご覧ください。
Schedule a Serverless Workflow with AWS Step Functions and Amazon EventBridge Scheduler
EventBridge Scheduler を利用して、定義したスケジュールに基づいてステートマシンを呼び出す方法を示します。
AWS Step Functions Workshop
一連のインタラクティブなモジュールを通じて、AWS Step Functions の主な機能の使用方法をご覧ください。
-
Amazon MWAA
-
Get started with Amazon Managed Workflows for Apache Airflow
このガイドでは、Amazon MWAA の利用を開始するために必要な前提条件と必要な AWS リソースについて説明します。
Configuring the aws-mwaa-local-runner in a CD pipeline
このチュートリアルでは、Amazon Managed Workflows for Apache Airflow の aws-mwaa-local-runner を使用して GitHub で継続的デリバリー (CD) パイプラインを構築し、Apache Airflow のコードをローカルでテストするプロセスを説明します。
Restricting an Amazon MWAA user's access to a subset of DAGs
Amazon MWAA の個々のユーザーが、特定の DAG、または DAG のセットのみを表示および操作できるように制限する方法を示します。
Amazon MWAA for Analytics Workshop
上記のサービスの多くを含むデータおよび ML パイプラインの構築とオーケストレーションを学習することで、AWS でパイプライン/ワークフローを管理するために Airflow の一部として使用できるフックやオペレーターに慣れ親しみ、より深く理解できるようになります。
詳しく見る
ご使用の環境のワークロードに最適なアプローチを決定したら、アプローチの実装を開始するのに役立つ、これらのリソースを確認することをお勧めします。サービス固有のリソースは前のセクションで確認でき、一般的なイベント駆動型アーキテクチャのリソースは次のセクションで確認できます。
可用性、安全性、柔軟性、コスト効率の高いアーキテクチャを作成するのに役立てるため、リファレンスアーキテクチャ図を詳しくご覧ください。
使用を開始するのに役立つホワイトペーパーを参照して、イベント駆動型アーキテクチャに関するベストプラクティスを学びましょう。
ブログは、モダンテクノロジーに関する最新情報を入手し、アプリケーションをモダナイズするのに役立ちます。