翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS アプリケーション統合サービスの選択
最初のステップを実行する
|
目的
|
ワークロードに最適な AWS アプリケーション統合サービスを特定するのに役立ちます。
|
|
最終更新日
|
2025 年 4 月 16 日
|
|
対象サービス
|
|
序章
アプリケーション統合は、マイクロサービス、分散システム、サーバーレスアプリケーション内の分離されたコンポーネント間の通信を可能にするサービスのスイートです。アマゾン ウェブ サービス (AWS) は、クラウドで実行されているさまざまなワークロードのセットをサポートするために、半ダースを超えるアプリケーション統合サービスを提供します。
組織やワークロードに最適な統合サービスを選択することは難しい場合があります。この決定ガイドは、要件を発見するために適切な質問をするのに役立ちます。また、ワークロードに適した統合サービスを評価および選択する方法について明確なガイダンスを提供します。
を理解する
モダナイゼーションの主な利点の 1 つは、運用上の責任をシフトできることです。これにより、リソースを解放して、付加価値とイノベーション主導のより多くのアクティビティを行うことができます。
スケーリング、セキュリティ設定、プロビジョニング、パッチ適用などを管理する Amazon Elastic Compute Cloud (Amazon EC2) でのメッセージブローカーのホスティングから、基盤となるすべてのインフラストラクチャが管理されるサーバーレスサービスまで、さまざまなレベルのモダナイゼーションで責任共有オプションがあります。
が提供する基準、環境、および統合サービスのスイートについて調べて理解を始めるときは AWS 、いくつかのベストプラクティスを確認することをお勧めします。これらのベストプラクティスは、選択したサービス (またはサービススイート) に関係なく適用されます。
環境内の統合を理解する
一部の組織では、オープンソースの統合を維持するよりも多くの時間を費やすことが一般的です。これらの投資を行う際には、コミュニティソースや企業や基盤からの支援を検討することをお勧めします。これらのプロジェクトへの投資は、財務だけでなく、ナレッジ資本や潜在的な技術的負債への投資でもあります。通常、これらのコンポーネントと関連する統合を更新する必要があるためです。詳細については、AWS オープンソースブログを参照してください。
アーキテクチャの特性を理解する
幅広いアーキテクチャをサポートする能力は重要です。WellAWS -Architected フレームワークをガイドとして使用して、アーキテクチャを構築する際の意思決定を理解することをお勧めします AWS。さらに、 Well-Architected フレームワークを使用すると、信頼性が高く、スケーラブルで、安全で、効率的で、費用対効果の高いシステムを クラウドで設計および運用するためのアーキテクチャのベストプラクティスを学ぶことができます。
統合サービスの組み合わせを使用する
専用サービスを使用している場合は、サービスの組み合わせがユースケースに最適な場合があります。以下に、 AWS 顧客がサービスの組み合わせを使用する一般的な方法をいくつか示します。
-
Amazon EventBridge または Amazon Simple Notification Service (Amazon SNS) イベントを、ダウンストリームコンシューマーのバッファとして Amazon Simple Queue Service (Amazon SQS) キューにルーティングします。
-
EventBridge Pipes を使用してストリーム (Amazon Kinesis Data Streams または Amazon Managed Streaming for Apache Kafka (Amazon MSK)) またはキュー (Amazon SQS または Amazon MQ) から直接イベントをプルし、EventBridge バスにイベントを送信してコンシューマーにプッシュアウトします。
-
EventBridge または Amazon SNS イベントを Kinesis Data Streams または Amazon MSK にルーティングして、分析を収集および表示します。
定義
基準、環境、戦略的方向性、利用可能なサービス (デプロイがホストするモダリティとマネージドモダリティの両方を含む) を明確に把握したら、統合要件を特定する必要があります。既存の統合プラットフォームまたはメッセージブローカーに移行する場合は、要件の一部が既にわかっている可能性があります。ただし、クラウド環境に移行した場合、これらの要件がどのように変化するかを確立する必要があります。
メッセージングまたはストリーミングプラットフォーム
これらのプラットフォームは、特定のビジネス機能を満たすことが期待されています。必要な機能を検討するときは、次のユースケースの例を使用します。
例 1:
さまざまなビジネスルールを持つさまざまなクレームタイプ (自動車、住宅、または生活) のメッセージとしてさまざまなクレームを受け取る保険会社を考えてみましょう。これは、メッセージコンシューマーに、メッセージのヘッダープロパティに基づいてクレームを別の宛先にルーティングする機能が必要であることを意味します。
例 2:
フライトステータスの更新で、アドバンストメッセージングキューイングプロトコル (AMQP) などのプロトコルを使用して、荷物やゲート操作などの接続されたすべてのシステムに通知する必要がある航空会社を考えてみましょう。機能ユースケースとビジネスユースケースのプリミティブに関する大きな疑問は、最適なメッセージングプラットフォームを構成するものです。ユースケースに基づいてプラットフォームの適合性を判断できる選択肢は複数あります。
-
市場導入: このプラットフォームは巨大な顧客コミュニティで広く採用されており、ほとんどのユースケースに適しています。これは、発生する可能性のある問題について、活気のあるサポートコミュニティで試され、テストされます。これは、開発リソースに十分なトレーニングを提供する低リスクの決定です。
-
ユースケースに最適: これらのプラットフォームは、航空会社、物流、医療などの特定の業界のユースケースに合わせて調整されます。これらは、導入可能な既製のテンプレートを持つユースケースに最適です。これらのプラットフォームは簡単に開始できますが、市場への導入レベルと柔軟性に欠ける可能性があります。このタイプのプラットフォームを採用するには、検証と社内での専門知識の構築に長い時間とリソースが必要になる場合があります。
-
最新: これらのプラットフォームは、クラウド規模のデプロイ、マルチテナンシー、ディザスタリカバリ、サーバーレスタイプの料金に対応するための次世代アーキテクチャで構築されています。このタイプのプラットフォームを使用すると、長期的な実行可能性のためにワークロードのリファクタリングが必要になる場合があります。クラウドネイティブプラットフォームを使用し、最新のアプリケーションの適切に設計された原則の使用に焦点を当てています。
例 3:
メッセージングプラットフォームが、マルチリージョンでなければならない大規模なローン処理ワークフローの一部である場合、メッセージングプラットフォームも同じビジネス要件をサポートする必要があります。雨の日の状況でビジネスが以前の状態に回復してロールバックする必要がある場合、基盤となるメッセージングまたはストリーミングプラットフォームには、システムの状態を再作成するスナップショット作成または再生機能も必要です。
選択した統合プラットフォームは、ローンアプリケーションの非同期処理を容易にするか、複数ステップのメディア処理ワークフローのストアアンドフォワードチャネルとして機能します。ビジネスプロセスの重要性によって、メッセージングまたはストリーミングプラットフォームに必要な機能が決まります。
考慮する
クラウド内の主要なアプリケーション統合アーキテクチャを検討する場合、各統合ポイントの機能要件を決定する方法はさまざまです。
以下は、アプリケーション統合サービスを選択するときに考慮すべき基準の一部です。
- Managed service and operation overhead
-
クラウドへの移行を検討し、運用上の負担を移行するマネージドサービスを標準化することで運用コストを削減します AWS。抽象化のレベルが高いほど、デベロッパーやオペレーターは差別化されていないタスクではなく、独自の付加価値アクティビティに集中できます。
- Open source
-
オープンソーステクノロジーの標準化を検討してください。オープンソースを使用すると、組織は適切なスキルを見つけ、ロックインに関するリスクを回避できます。
オープンソースエコシステムで間違った選択を行うと、抽象化や自社開発の統合に縛られる可能性があります。さらに、さまざまなオープンソースコンポーネントを連携させる責任は、多くの場合、選択する組織にあります。これにより、組織はオープンソースの統合の維持に多大な時間を費やす可能性があります。
- Workload characteristics
-
適切な統合サービスを選択するときは、アプリケーション間で送信する必要があるメッセージの特性を理解することが重要です。メッセージ形式、サイズ、保持期間、優先度などの主要な特性が、統合サービスの決定を左右する可能性があります。
一部の統合サービスは小さなテキストベースのメッセージに適していますが、一部の はテキストやバイナリなどの複数の形式をサポートし、より大きなメッセージサイズを提供するように設計されています。再生機能の必要性は、一部のシナリオでメッセージの順序付けとともに重要な要素になることもあります。
例えば、メッセージの順序付けは、Amazon SNS と Amazon SQS が提供する FIFO 機能を使用して実装できます。また、EventBridge や Amazon SNS が Lambda 関数を非同期的に呼び出すなど、プルまたはプッシュベースのアーキテクチャを持つことも考慮されます。
プルベースのアーキテクチャでは、Amazon SQS や Kinesis Data Streams などのサービスを使用できます。このサービスでは、メッセージがキューまたはストリームに保存され、消費システムによって取得されます。Amazon MQ などのメッセージングサービスは、より大きなメッセージペイロードに関する機能を提供し、保持期間は無制限です。ただし、リプレイ機能は提供されません。
- Rapid iteration and feature velocity
-
主要な焦点が構築と反復を迅速に行うことである場合、サーバーレスサービスが最善の価値を提供する可能性があります。サーバーレスサービスを使用すると、インフラストラクチャを管理せずにアプリケーションを構築できます。管理された機能と統合を提供し、ボイラープレートコードの記述にかかる時間を短縮します。
新しいアイデアをテストするときのサーバーレスのもう 1 つの利点は、これらのサービスが使用量ベースの料金を提供することです。コードはサービスが呼び出されたときにのみ実行されるため、実験には前払い投資は必要ありません。
- Application portability
-
多くのアプリケーションは、Advanced Message Queuing Protocol (AMQP) や MQ Telemetry Transport (MQTT) などの特定のプロトコルを使用してメッセージングサービスに接続します。または、特定のメッセージングプロトコルを使用するライブラリ依存関係があります。このようなライブラリやフレームワークの例としては、Spring Boot、Celery、MassTransit などがあります。
このようなアプリケーションは、さまざまな理由で保持することをお勧めします。このような場合、統合サービスの選択は、アプリケーションとの移植性に必要なプロトコルのサポートにも依存します。
- Automation portability
-
インフラストラクチャやデプロイツールと互換性があり、オンプレミスでホストするのと同じ統合システム (Apache ActiveMQ、RabbitMQ、Apache Kafka など) を実行するサービスが必要になる場合があります。
マネージド型オープンソースサービス (Amazon MQ や Amazon MSK など) は、オンプレミスのデプロイに使用される多くの一般的なデプロイツールと互換性がありながら、クラウドの利点を提供します。
アプリケーションのリファクタリングがオプションである場合は、サーバーレスサービスを使用してこの機能をネイティブに提供し、さまざまな AWS サービスとの豊富な統合を活用できます。
- Organization size and skills
-
組織のスキルは、適切な統合サービスを決定する際の重要な要素です。チームがセルフマネージド製品に精通していて、ニーズを満たしている場合は、同じ のマネージドサービスを持つことで、影響が最も少ない可能性があります。これにより、 はサービスのベストプラクティスを適用し、付加価値アクティビティに集中できます。
選択
アプリケーション統合のニーズを評価するために使用する基準がわかったので、環境内のワークロードに適した AWS サービスを選択する準備が整いました。
| サービスタイプ |
いつ使用するか? |
何に最適化されていますか? |
関連サービス |
|
キャパシティー
|
パブリッシャーとサブスクライバーを切り離し、同時に複数のサブスクライバーにイベントを送信する必要がある場合に使用します。
|
パブリッシャーとサブスクライバー間の非同期で疎結合された通信用に最適化されています。イベントはメッセージのルーティングと配信に柔軟性を提供し、イベントがアクションやワークフローの開始において中心的な役割を果たすイベント駆動型アーキテクチャに適しています。
|
Amazon EventBridge
Amazon SNS
|
|
メッセージング
|
複数の受信者に同時にメッセージをブロードキャストするために pub/sub メッセージングが必要な場合や、コンポーネント間で信頼性が高く非同期通信が必要な場合にpoint-to-pointメッセージングが必要な場合に使用します。
|
分散コンポーネント間の高スループット、スケーラブル、信頼性の高い非同期 pub/sub point-to-pointメッセージング用に最適化されています。
|
Amazon SNS
Amazon SQS
Amazon MQ
|
|
ストリーミング
|
リアルタイムストリーミングデータの処理と処理を伴うシナリオでは、Amazon Kinesis Data Streams や Amazon Managed Streaming for Apache Kafka (MSK) などのストリーミングサービスを使用します。
|
リアルタイム分析、リアルタイムモニタリング、データ探索、および高速データストリームの処理を必要とするその他のアプリケーションを必要とするユースケース向けに、大量のリアルタイムストリーミングデータの取り込み、処理、分析に最適化されています。
|
Amazon Kinesis Data Streams
Amazon MSK
|
|
ワークフロー
|
ワークフローや一連のタスクを組織的かつスケーラブルに設計、調整、管理する必要がある場合に使用します。
|
ビジネスプロセス管理、アプリケーションオーケストレーション、データパイプラインの自動化、マイクロサービスの調整などのユースケース向けに最適化されています。ワークフローは基盤となるインフラストラクチャの複雑さを抽象化するため、ワークフローの効果的な設計と管理に集中できます。依存関係とシーケンスを処理できるため、並列処理と条件分岐が可能になり、耐障害性、エラー処理、再試行が可能になり、信頼性の高いワークフロー実行が保証されます。
|
AWS Step Functions
Amazon MWAA
|
|
スケジューリング
|
データ処理、バックアップ、システムヘルスチェックなどのルーチンタスクを自動化する必要がある場合は、スケジューリングを使用します。タスクは、多くの場合、毎晩、毎時、毎分など、特定の時間または間隔で実行する必要があります。
|
再試行ロジックが組み込まれており、信頼性の高い時間ベースのタスク向けに最適化されています。正確なスケジューリングとさまざまな AWS サービスとの統合を必要とするワークフローに適しています。
|
Amazon EventBridge
|
使用アイテム
これで、各 AWS アプリケーション統合サービスの動作と、どちらが適切かを明確に理解できました。を使用して、利用可能な各 AWS アプリケーション統合サービスの詳細について調べる方法を調べるために、各サービスの仕組みを調べるための経路を用意しました。次のセクションでは、詳細なドキュメント、実践的なチュートリアル、開始するためのリソースへのリンクを提供します。
- Amazon SNS
-
-
Amazon SNS と Amazon SQS を使用してトピックに発行されたメッセージをフィルタリングする
Amazon SNS のメッセージフィルタリング機能を使用する方法について説明します。
チュートリアルを始める
-
Amazon SNS - トラブルシューティング
設定情報の表示、プロセスのモニタリング、Amazon SNS に関する診断データの収集方法について説明します。
ガイドを見る
-
Amazon DynamoDB と Amazon SNS を使用してターンベースのゲームを構築する
Amazon DynamoDB と Amazon SNS を使用してマルチプレイヤーのターンベースのゲームを構築する方法について説明します。
チュートリアルを始める
-
イベント駆動型アーキテクチャの構築
Amazon SNS を公開サービスとして使用し、Amazon SQS をサブスクライバーとして使用して、シンプルな pub/sub 実装を構築する方法について説明します。
ガイドを見る
-
Amazon SNS FIFO を使用したメッセージのアーカイブと再生
Amazon SNS FIFO に発行されたメッセージをアーカイブして再生する方法について説明します。これは、障害復旧や状態レプリケーションのシナリオに役立ちます。
ブログ記事を読む
- Amazon SQS
-
-
Amazon SQS の開始方法
このガイドでは、Amazon SQS コンソールを使用してキューとメッセージを管理する方法について説明します。
ガイドを見る
-
ファンアウトイベント通知の送信
Amazon SNS と Amazon SQS を使用してファンアウトメッセージングシナリオを実装する方法について説明します。
チュートリアルを始める
-
キューベースのマイクロサービスをオーケストレーションする
メッセージキューベースのマイクロサービスをオーケストレーションするサーバーレスワークフローを設計および実行する方法について説明します。
チュートリアルを始める
-
分散アプリケーション間でメッセージを送信する
Amazon SQS コンソールを使用して、メッセージキューの作成と設定、メッセージの送信、メッセージの受信と削除、キューの削除を行います。
チュートリアルを始める
- Amazon EventBridge
-
-
Amazon EventBridge の使用を開始する
EventBridge の基本は、イベントをターゲットにルーティングするルールを作成することです。このガイドでは、基本ルールを作成します。
ガイドを見る
-
Amazon EventBridge 入門チュートリアル
これらのチュートリアルは、EventBridge の機能とその使用方法について説明します。
チュートリアルを始める
-
他の との統合 AWS のサービス
以下のチュートリアルでは、EventBridge を他の と統合する方法を示します AWS のサービス。
チュートリアルを始める
-
イベント駆動型アーキテクチャを構築する
イベント駆動型設計の基本、ジョブ AWS のサービス に適した を選択する方法、コストとパフォーマンスの両方を最適化する方法について説明します。
チュートリアルを始める
-
Amazon EventBridge を使用したイベント駆動型アプリケーションの構築
SaaS アプリケーションを含む複数のアプリケーションを接続し AWS のサービス、Amazon EventBridge が提供するサーバーレスイベントバスを使用して、イベント駆動型アプリケーションを構築する方法について説明します。
チュートリアルを始める
-
Amazon EventBridge 用の Kafka コネクタ
このコネクタを使用すると、1 つ以上の Kafka トピックのレコードをイベントに変換し、それらのイベントを任意のイベントバスに送信できます。
ガイドを見る
-
Amazon EventBridge イベントバスのクロスアカウントターゲットの紹介
イベントバスを使用して、Amazon SQS、Amazon SNS AWS アカウント、 などの他の のターゲットにイベントを直接送信する方法について説明します AWS Lambda。
ブログ記事を読む
- Amazon MQ
-
-
接続されたメッセージブローカーを作成する
Amazon MQ メッセージブローカーをセットアップし、コードを書き換えずに Java アプリケーションを接続する方法について説明します。
チュートリアルを始める
-
クラウド内のメッセージブローカーに移行する
Amazon MQ を使用すると、Apache ActiveMQ や RabbitMQ などのクラウド内のメッセージブローカーに簡単に移行できます。
ガイドを読む
-
RabbitMQ ブローカーの作成と接続
を使用して RabbitMQ ブローカー AWS マネジメントコンソール を作成し、そのブローカーにアプリケーションをアタッチする方法について説明します。
チュートリアルを始める
-
RabbitMQ ワークショップ
このワークショップは、RabbitMQ を使用したメッセージングのさまざまな側面とパターンをカバーするラボのコレクションです。
ワークショップの開始方法
-
Amazon MQ for RabbitMQ でのクォーラムキューの紹介
RabbitMQ でクォーラムキューを使用すると、可用性とデータセキュリティがどのように向上するかについて説明します。
ブログ記事を読む
-
ActiveMQ ブローカーの作成と接続
を使用して基本的なブローカー AWS マネジメントコンソール を作成する方法について説明します。
チュートリアルを始める
-
ActiveMQ ワークショップ
キュー、トピック、フェイルオーバーなどの Amazon MQ の機能、ブローカーのネットワークなどのメッセージングの概念について説明します。
ワークショップの開始方法
-
サーバーレスを使用して AWS Amazon MQ ブローカーにデプロイして公開する
SAM を使用してサーバーレスバックエンドと Amazon MQ AWS ブローカーを 1 つのステップでデプロイする手順を説明します。
ブログ記事を読む
-
Maven 2 ベンチマークと を使用した Amazon MQ スループットの測定 AWS CDK
ActiveMQ Classic Maven Performance テストプラグインを使用して Amazon MQ のスループットを評価する方法について説明します。 ActiveMQ
ブログ記事を読む
- Amazon Kinesis Data Streams
-
-
Amazon Kinesis Data Streams の開始方法
基本的な Kinesis Data Streams データフローの原則と、Kinesis データストリームとの間でデータを配置および取得するために必要な手順について説明します。
ガイドを見る
-
Amazon Kinesis Data Streams を使用して高可用性ストリームを構築する
プライマリオペレーションリージョンでサービスの中断、遅延、停止が発生した場合に、高可用性の Kinesis データストリームを作成するためのさまざまな戦略を比較および対照します。
ブログ記事を読む
-
Amazon Kinesis Data Streams のチュートリアル例
これらのチュートリアルは、Amazon Kinesis Data Streams の概念と機能をさらに理解するのに役立つように設計されています。
チュートリアルを始める
-
Amazon Kinesis AWS Lambda での の使用
Kinesis ストリームからイベントを消費する Lambda 関数を作成する方法について説明します。
チュートリアルを始める
-
Amazon Kinesis を使用したリアルタイムストリーミング
ユーザーがストリーミング分析アプリケーションを構築するのに役立つ一連のラボ演習をご覧ください AWS。
チュートリアルを始める
- Amazon MSK
-
-
Amazon MSK の使用開始
このチュートリアルでは、MSK クラスターを作成し、データを生成および消費し、メトリクスを使用してクラスターのヘルスをモニタリングする方法の例を示します。
チュートリアルを始める
-
MSK Serverless クラスターの使用開始
このチュートリアルでは、MSK サーバーレスクラスターの作成方法と、作成したクラスターにアクセスできるクライアントマシンの作成、またクライアントを使用したクラスター上でのトピックの作成と、それらのトピックにデータを書き込む方法の一例をご説明します。
チュートリアルを始める
-
Amazon MSK ラボ
これらのラボは、ワークショップスタジオを使用するイベントのために AWS アカウントチームによってプロビジョニングされた個人 AWS アカウント 、企業、またはアカウントで実行できます。
ラボの使用を開始する
-
Amazon MSK 用の Express ブローカーを導入して Kafka クラスターに高スループットと高速スケーリングを実現
Express ブローカーが Kafka ワークロードのコストを削減し、耐障害性を高め、運用オーバーヘッドを削減する方法について説明します。
ブログ記事を読む
- AWS Step Functions
-
-
の開始方法 AWS Step Functions
これらのチュートリアルでは、クレジットカード申請を処理するための基本的なワークフローを作成する方法について説明します。
チュートリアルを始める
-
Step Functions の概要
本コースでは、アプリケーション内のワークフローの管理を開始するのに役立つ Step Functions の主要なコンポーネントを紹介します。
コースの開始方法
-
を使用した大規模なデータ処理 AWS Step Functions
Step Functions を使用して大規模なデータ処理アプリケーションを構築する方法について説明します。
ワークショップの開始方法
-
の設計パターン AWS Step Functions
Step Functions ステートマシンに設計パターンを実装する方法と、それぞれを使用する理由について説明します。
コースの開始方法
-
AWS Step Functions と Amazon EventBridge スケジューラを使用してサーバーレスワークフローをスケジュールする
定義したスケジュールに基づいて EventBridge スケジューラを使用してステートマシンを呼び出す方法を示します。
チュートリアルを始める
-
AWS Step Functions ワークショップ
一連のインタラクティブモジュール AWS Step Functions を通じて の主な機能を使用する方法について説明します。
ワークショップの開始方法
-
PrivateLink、VPC Lattice、EventBridge、Step Functions を使用して、VPC とアカウントの境界間で AWS リソースを安全に共有する
EC2 インスタンスや Amazon EKS コンテナサービスなどの AWS リソースを Amazon VPC と AWS アカウント 境界間で共有する方法について説明します AWS Step Functions。
ブログ記事を読む
-
の変数と JSONata を使用して開発者エクスペリエンスを簡素化する AWS Step Functions
変数とオープンソースのクエリおよび変換言語である JSONata を使用して、状態間のデータ共有を簡素化し、データ操作の複雑さを軽減します。
ブログ記事を読む
- Amazon MWAA
-
-
Apache Airflow 用 Amazon マネージド型ワークフローの使用開始
このガイドでは、Amazon MWAA の使用を開始するために必要な前提条件と AWS リソースについて説明します。
ガイドを見る
-
CD パイプラインaws-mwaa-local-runnerでの の設定
このチュートリアルでは、Amazon Managed Workflows for Apache Airflow の を使用して GitHub で継続的デリバリー (CD) パイプラインを構築し、Apache Airflow コードをローカルaws-mwaa-local-runnerでテストするプロセスについて説明します。
チュートリアルを始める
-
Amazon MWAA ユーザーのアクセスを DAGs
ここでは、個々の Amazon MWAA ユーザーに対して、特定の DAG または一連の DAGs の表示と操作のみを制限する方法を示します。
チュートリアルを始める
-
Amazon MWAA for Analytics ワークショップ
上記の多くのサービスを含むデータと ML パイプラインを構築およびオーケストレーションする方法について説明します。これにより、パイプライン/ワークフローを管理するために Airflow の一部として使用できるフックと演算子について知識を深め、理解を深めることができます AWS。
ワークショップの開始方法
Explore
環境のワークロードに最適なアプローチを決定したら、アプローチの実装を開始できるように、これらのリソースを確認することをお勧めします。サービス固有のリソースは前のセクションに、一般的なイベント駆動型アーキテクチャリソースは次のセクションにあります。
-
アーキテクチャ図
可用性、安全性、柔軟性、コスト効率に優れたアーキテクチャの作成に役立つリファレンスアーキテクチャ図をご覧ください。
アーキテクチャ図を調べる
-
ホワイトペーパー
開始に役立つホワイトペーパーを確認し、イベント駆動型アーキテクチャに関するベストプラクティスを学習します。
ホワイトペーパーを見る
-
ブログ
最新のテクノロジーを常に把握し、アプリケーションをモダナイズするのに役立つブログをご覧ください。
ブログを見る