クラウドネイティブアプリケーションでの同期通信と非同期通信のデコード

クラウドネイティブ アプリケーションの設計には、相互に効率的に通信する必要があるマイクロサービスとサーバーレス コンポーネントの複雑なシステムの管理が含まれます。同期通信は HTTP または gRPC 呼び出しを使用し、指定された時間範囲内で応答を待機し、リアルタイムのフィードバックを提供するため、即時の応答が必要なシナリオに適しています。非同期通信では、メッセージ ブローカー (RabbitMQ や Kafka など) を利用して、即時の応答を必要とせずにメッセージを交換し、システムのスケーラビリティを強化します。各通信モードの長所と短所を理解することで、アーキテクトはこれらの独立した要素を効果的に調整して、高性能、スケーラブル、信頼性の高いクラウドネイティブ アプリケーションを提供するシステムを設計できます。

多くの独立した部品で構成される複雑なマシンを構築し、それぞれがその機能を実行しますが、そのためにはすべての部品が相互に効果的に通信する必要があることを想像してください。これは、相互接続されたマイクロサービスとサーバーレス コンポーネントで構成されるクラウドネイティブ アプリケーションを設計するときに直面する課題です。この記事では、アプリケーション境界の内外でこれらの独立した要素を効果的に調整できる、堅牢で回復力のある通信システムの設計の詳細を検討します。

これらのきめ細かいサービスでは、内部および外部の対話にさまざまな同期または非同期通信方法が使用されます。同期通信では、あるサービスが HTTP または gRPC を使用して別のサービスを呼び出し、指定された時間枠内の応答を待ってから続行します。対照的に、非同期通信では、即時の応答を期待せずにメッセージを交換します。 RabbitMQ や Kafka などのメッセージ ブローカーは仲介者として機能し、メッセージをバッファリングして信頼性の高い配信を保証します。クラウドネイティブ アプリケーションでは、多くの場合、通信パターンを組み合わせて使用​​することが実用的なアプローチになります。同期通信から始めましょう。

同期通信とは何ですか?

同期コミュニケーションは会話のようなものです。 1 つのサービス (サービス A とします) がリクエストを発行し、別のサービス (サービス B) または外部 API からの応答を待ちます。これは、質問をして答えを待つのと似ています。サービス A は HTTP 経由でリクエストを送信し、待機します。サービス B からの応答を待つか、最大待機時間が経過するまで待機します。この待機期間中、サービス A は、応答を待つためにアクティビティを一時停止するのと同じように、一時的にブロックされます。このモードはリクエスト/レスポンス モードと呼ばれることが多く、実装は比較的簡単です。ただし、その広範な使用には、慎重な検討が必要な課題が生じる可能性があります。

同期通信の課題

同期通信はクラウド ネイティブ ツールキットの強力なツールですが、慎重な検討を必要とする独自の課題も伴います。

時間的結合

ソリューション全体で同期通信に過度に依存すると、時間的結合の問題が発生する可能性があります。これは、多数の同期呼び出しが連鎖し、クライアント アプリケーションが応答を受信するまでの待機時間が長くなる場合に発生します。

可用性の依存関係

同期通信では、すべての通信サービスが同時に利用できる必要があります。バックエンド サービスに予期しない負荷がかかると、クライアント アプリケーションがタイムアウト エラーで失敗し、全体的なパフォーマンスに影響を与える可能性があります。

ネットワーク品質への影響

ネットワーク品質は、利用可能な帯域幅やサービス バックエンド サービス間を通過する応答に必要な時間など、同期通信のパフォーマンスに直接影響を与える可能性があります。

これらの課題にもかかわらず、同期通信は特定のシナリオでは非常に貴重な場合があります。次のセクションでは、同期通信がより良い選択となる可能性があるいくつかのユースケースを検討してみましょう。

同期通信を使用する場合

場合によっては、同期通信を使用する方が適切な選択となることがあります。

リアルタイムのデータ アクセスまたは保証された結果

即時またはリアルタイムのフィードバックが必要な場合、同期通信により効率が向上します。たとえば、顧客が電子商取引 Web サイトで注文を行うと、電子商取引フロントエンドは在庫システムをチェックして商品の在庫があることを確認する必要があります。アプリケーションは注文の処理を続行する前に在庫システムからの応答を待つ必要があるため、これは同期操作です。

関連タスクのオーケストレーション

サービスが、それぞれが前のタスクに依存する一連のタスクを実行する必要がある状況では、同期通信によって順序を維持できます。 。これは、タスクの順序が重要なワークフローに特に適しています。

トランザクションの整合性の維持

複数のコンポーネント間でデータの一貫性を維持することが重要な場合、同期通信はアトミック トランザクションの維持に役立ちます。これは、データの整合性が重要な金融取引などのシナリオに関連します。

同期通信は強力なツールですが、課題もあります。良いニュースとして、非同期通信のオプションもあります。これは、同期メソッドと連携できる補完的なスタイルです。次のセクションでこれについてさらに詳しく見てみましょう。

非同期通信とは何ですか?

非同期通信モードは、サービス間の通信に動的かつ効率的な方法を提供します。同期通信とは異なり、非同期通信では、サービスは即時の応答を待たずにリクエストを開始できます。このモデルでは、応答は即時ではない場合や、別のチャネル (コールバック キューなど) に非同期で到着する場合があります。この通信モデルは、アドバンスト メッセージ キュー プロトコル (AMQP) などのプロトコルや、メッセージ ブローカーやイベント ブローカーなどのメッセージング ミドルウェアに依存します。

このメッセージング ミドルウェアは、最小限のビジネス ロジックを備えた仲介者として機能します。ソースまたはプロデューサー サービスからメッセージを受信し、それらを目的のコンシューマ サービスに配信します。メッセージング ミドルウェアを統合すると、この分離されたアプローチの復元力と耐障害性が大幅に向上します。非同期通信にはさまざまな実装が含まれます。これらをさらに詳しく見てみましょう。

1 対 1 の通信

1 対 1 のメッセージ通信では、プロデューサーはメッセージ ブローカーを使用してメッセージを受信者に特別にディスパッチします。通常、メッセージ ブローカーはキューに依存して、信頼性の高い通信を確保し、少なくとも 1 回などの配信保証を提供します。実装はコマンド パターンに似ており、渡されたメッセージはサブスクライバ サービスがアクションをトリガーするために使用するコマンドとして機能します。

その使用法を説明するために、オンライン小売店の例を考えてみましょう。オンライン ビジネスは、Web サイトの信頼性に大きく依存します。このモデルはフォールト トレランスとメッセージ保証を提供し、顧客が Web サイトで注文すると、バックエンド フルフィルメント システムが処理する注文を確実に受け取ります。メッセージ ブローカーは、バックエンド システムがシャットダウンされてもメッセージを保持し、処理できるときにメッセージを配信します。たとえば、電子商取引アプリケーションでは、顧客が注文を行うと、メッセージ ブローカーを使用して、注文の詳細をメッセージとして注文サービス (プロデューサー) からフルフィルメント サービス (消費者) に送信できます。これは1対1のコミュニケーションの例です。

クラウドでの非同期 1 対 1 通信

1 対 1 メッセージ モードを拡張したものが、非同期リクエスト/レスポンス モードです。この場合、ディスパッチャは応答を期待せずにメッセージを送信します。ただし、一部の特定のシナリオでは、コンシューマーは同じメッセージ ブローカー インフラストラクチャ キュー内のキューを利用して実稼働サービスに応答する必要があります。消費者からの応答には、最初の要求または応答アドレスに関連付けられた ID などの追加のメタデータが含まれる場合があります。プロデューサーは即時の応答を期待していないため、別のプロデューサー ワークフローがこれらの応答を管理します。注文が行われると、フルフィルメント サービス (消費者) がフロントエンド注文サービス (プロデューサー) に応答し、顧客が Web サイトで更新できるようにします。

クラウドにおける非同期の 1 対 1 の要求と応答の通信

単一コンシューマ通信は、2 つのサービスがポイントツーポイントで通信する場合に便利です。ただし、パブリッシャーが特定のイベントを複数のサブスクライバーに送信する必要がある状況があり、その場合は次のパターンになります。

1 対多の通信

この通信方法は、単一のコンポーネント (パブリッシャー) が複数のコンポーネントおよびサービス (サブスクライバー) にイベントをブロードキャストする必要がある場合に非常に役立ちます。 。 1 対多のコミュニケーションでは、オンライン フォーラムと同様にトピックの概念が使用されます。

これは、複数のユーザーが記事を投稿し、フォロワーが好きな時間に読んで必要に応じて応答できるオンライン フォーラムのようなものです。同様に、アプリケーションには、プロデューサー サービスが書き込み、コンシューマー サービスが読み取りできるトピックを含めることができます。これは、実際のアプリケーションで最もよく使われるパターンの 1 つです。

電子商取引プラットフォームには製品の価格を更新するサービスがあり、複数のサービス (サブスクリプション サービス、推奨サービスなど) でこの情報が必要であることをもう一度考えてみましょう。価格の更新はトピックへのメッセージとして送信できます。メッセージブローカー内。関心のあるすべてのサービス (加入者) は、トピックを聞いて価格の更新を受け取ることができます。これは 1 対多の通信の例です。このパターンを実装するために利用できるツールはいくつかありますが、Apache Kafka、Redis Pub/Sub、Amazon SNS、Azure Event Grid などが最も一般的な選択肢です。

クラウドでの非同期 1 対多通信

非同期通信の課題

非同期通信には多くの利点がありますが、 、それはまた、独自の一連の課題をもたらします。

復元力と耐障害性

多数のマイクロサービスとサーバーレス コンポーネントがあり、それぞれに複数のインスタンスがあるため、障害は避けられません。インスタンスがクラッシュしたり、過剰な状態になったり、一時的な障害が発生したりする可能性があります。さらに、送信者はメッセージの処理を待機しないため、エラーが発生してもすぐには気付かない可能性があります。次の戦略を採用する必要があります。

再試行メカニズム: 一時的な障害に対して失敗したネットワーク呼び出しを再試行します。

サーキット ブレーカー モード: リソースのボトルネックを回避するために、失敗したサービスへの繰り返し呼び出しを防止します

分散トレース

非同期通信は複数のサービスにまたがる可能性があるため、システム全体のパフォーマンスの監視が困難になります。分散トレースを実装すると、ログとメトリクスを結び付けてトランザクション フローを理解するのに役立ちます。

複雑なデバッグと監視

非同期通信は、操作が直線的なフローに従わないため、デバッグと監視がより困難になる可能性があります。これらのシステムを効果的にデバッグおよび監視するには、多くの場合、特殊なツールと技術が必要になります。

リソース管理

非同期システムには、長時間にわたる接続やバックグラウンド処理が含まれることが多く、リソース管理の問題が発生する可能性があります。メモリ リークや CPU の過剰使用を防ぐために、リソースを効率的に管理するように注意する必要があります。

これらの課題を理解すると、クラウド ネイティブ アプリケーションでより堅牢で回復力のある非同期通信システムを設計するのに役立ちます。

最後の言葉

同期通信モードと非同期通信モードの選択は二者択一ではなく、アプリケーションの特定の要件に基づいた戦略的な決定です。

同期通信は実装が簡単で即時フィードバックが提供されるため、リアルタイムのデータ アクセス、関連タスクのオーケストレーション、トランザクションの整合性の維持に適しています。ただし、時間的な結合、可用性への依存、ネットワーク品質への影響などの課題にも直面しています。

一方、非同期通信を使用すると、サービスは即時の応答を待たずにリクエストを開始できるため、システムの応答性とスケーラビリティが向上します。柔軟性があり、即時のフィードバックが必要ないシナリオに最適です。ただし、復元力、耐障害性、分散トレース、デバッグ、監視、リソース管理の点で複雑さが生じます。

要約すると、クラウド ネイティブ アプリケーション向けの強力で回復力のある通信システムを設計するには、同期および非同期の通信パターンを深く理解する必要があります。各パターンの長所と短所を慎重に検討し、要件に合わせることにより、アーキテクトはアプリケーション境界内外の独立した要素を効果的に調整するシステムを設計して、高性能、スケーラブル、信頼性の高いクラウドネイティブ アプリケーションを提供できます。

以上がクラウドネイティブアプリケーションでの同期通信と非同期通信のデコードの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。