最も適切なメッセージング・サービスの識別
メッセージング・サービスを選択する際の考慮事項について学習し、デシジョン・マトリックス表を使用して、ビジネス・ニーズに基づいてOCIサービスの様々なオプションおよび制限を確認します。
メッセージング・サービスの選択に関する考慮事項
次の評価要素を考慮して決定します。
振付またはオーケストレーション
分離された様々なコンポーネントが連携して機能するように編成される2つのアーキテクチャ・アプローチは、振分けとオーケストレーションです。振り返りは、各成分が独立して動作するという原則を採用していますが、次の行動をいつ実行するかを調べて監視します。メッセージ・ブローカがキューを次のコンポーネントに送信します。コンポーネントは非常に自律型で、簡単に拡張できます。欠点は、各コンポーネントがソリューション全体におけるその役割をより深く理解する必要があり、さらに複雑になることです。メッセージ・ブローカは重要な要素であり、シンプルさによりワークロードが削減され、スループットが向上します。
オーケストレーションとは、オーケストラのように組み立てられたコンポーネントの概念を指します。各コンポーネントはタスクを知ってから、指揮者またはオーケストレータがアクションの実行を要求するまで待機する必要があります。したがって、コンダクタはすべてのコンポーネントを指示するインテリジェンスを理解し、持つ必要があります。指揮者の役割は、ソリューション全体のスケーラビリティとレジリエンスに直接影響し、拡張性と弾力性に重要な役割を果たします。
一部のオーケストレーション製品には、コレオグラフ化機能(ブローカの追加など)や、ブローカ化された通信の効果を達成するためにコンポーネントを使用するサービスを作成する機能が含まれます。
メッセージまたはイベントごとの支払対比一括購入
ソリューションに対するコストへの影響に基づいて、様々な支払いモデルを検討します。一括購入で未使用のメッセージ量が発生する可能性がある場合は、メッセージごとに支払うことを選択できます。サービスの最小フットプリント・コストはより少ない使用量に分散する必要があるため、メッセージまたはイベントごとに支払うと、ボリュームが増える可能性があります。
単一または複数のメッセージ・コンシューマ
キューとトピックの違いは、メッセージはキューで1回のみ使用できます。トピックには様々なコンシューマを含めることができます。キューおよびトピックには、コンシューマ・タイプの多数のインスタンスを含めることができます。単一のトピックまたはキューに接続された同じコンシューマ・タイプの複数のインスタンスは、多くの場合、次に使用可能なコンシューマが次のメッセージを使用できる競合条件として記述されます。
読取り後のメッセージ保持
一部のメッセージ・ブローカは、リソースを管理するために、読取り後(またはすべてのコンシューマがメッセージを読んだ後)にメッセージを削除します。Apache Kafkaは、コンシューマがメッセージをどこまで処理したかを追跡しますが、一度読み取ると削除しません。これにより、問題が発生した場合にメッセージを再生できます。したがって、Kafkaは、データ・ストアおよびメッセージ・ブローカとして機能し、メッセージ・データ・ストアでのデータ分析の作成をサポートします。
保証付きオーダー
メッセージが格納されている順序ではなく、受信順に配信されることを保証すると、複雑さが生じ、パフォーマンスに影響します。待機時間の問題は、ブローカを介して作業するときに発生することがあります。これは、消費者がメッセージを取得して、消費前に正しい順序に挿入する必要がある遅延メッセージがないことを確認できるようにするためです。
たとえば、メッセージの順序付けは、取り消されるオーダーを表すイベントに不可欠です。オーダー作成のメッセージには、メッセージがオーダーに従っていない場合にアプリケーションの問題が発生する可能性があります。
注文の問題やオフセット・ブローカ制約の軽減に役立つアプリケーションレベルのパターンと戦略があります。
非同期操作
ブローカ・メカニズムを使用する利点は、メッセージ・プロバイダがコンシューマについて知る必要がなく、プロバイダを遅らせないことです。ブローカーは、消費者が誰であるか、利用可能かどうかを知り、消費者に問題(パフォーマンスなど)がある場合は伝送を管理します。ブローカを使用すると非同期通信が可能になり、プロバイダとコンシューマが同期している必要はありません。
「Maximum Message Rate」、「Message Retention Period」、および「Maximum Retention Volume」
これらの要因はすべて、サーバーレス・ソリューションの提供コストに影響を及ぼし、多くの場合、設定にハード制限が必要です。ソフトウェアは期待に応えるため、常に均一なパフォーマンスを提供するわけではありません。期待を制御し、予測可能な動作を提供するための制限を設定できます。これらの制限を理解して、構築しているソリューションに影響する可能性があるかどうかを判断する必要があります。
たとえば、株主取引システムは株価の変更時にメッセージを受信します。各メッセージは小さいですが、更新頻度が高いため、メッセージ・ボリュームは高くなります。スループットが低いがメッセージ・サイズが大きいブローカでは、この要件をサポートできません。
業界標準入力サポートおよび業界標準出力サポート
業界標準の形式およびプロトコルを使用してメッセージの送受信を行うと、メッセージング・メカニズムを再構成して、異なるデプロイメントおよび実装プロバイダで使用できるようになります。共通ライブラリを利用して、通信の低レベルな仕組みに対処し、ベンダーの結束を減らすことができます。
第三者アダプタのサポート
メッセージ・プロバイダとコンシューマの開発を支援するため、サード・パーティのアダプタによるサポートにより開発オプションが増加すると、メリットが得られます。
コンパートメント当たりの個々のデプロイメント
個々のメッセージング・チャネルまたはフローを特定のコンパートメントにデプロイし、ソリューション内のサービスが、共通のコントロール・サーフェイスを介して粒度の細かい集合的なセキュリティ制御を行うことができるようにします。このアプローチでは、すべての要素がコンパートメント・レベルで制御できることを前提としています。チャネルごとにコンパートメントレベルの制御に対応できないソリューションは、代替を提供できます。代替アプローチには、構成に関する追加の考慮事項が必要な場合があります。
OCI IAM認証の使用
Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)は、セキュリティを他のプロバイダにフェデレートできる場合に、堅牢なエンタープライズ・クラスのセキュリティを提供します。単一のIAMプロバイダ(フェデレーションを使用するかどうかに関係なく)を操作することで、データ・フロー・アクセスのセキュリティ制御をより管理しやすくなります。
データは転送中および保存時に暗号化されます
サービスを通過するデータが機密である場合、送信中および配信までブローカによって保持されている間は保護する必要があります。メッセージが失われないようにするには、機密メッセージをブローカ暗号化メカニズムで暗号化する必要があります。
メッセージ変換
採用されているアーキテクチャの原則によっては、ブローカがメッセージの書式設定を翻訳できる必要がある場合があります。メッセージ・プロバイダまたはコンシューマは、共通のデータ・セマンティクスを理解したり、プロバイダまたはコンシューマがデータのフォーマットをどのように希望するかを理解する必要はありません。この考慮事項は、使用されているプロトコルの変更にも及ぶ可能性があります。たとえば、RESTからSTOMPへの変換などです。
監査証跡
分散アプリケーションの問題を修正するために、監査証跡によって、メッセージの送受信先を追跡できます。監査証跡は、国別仕様要件に準拠する必要がある場合に役立ちます。したがって、サービスがこの要件をどのようにサポートできるかを学ぶ必要がある場合があります。
決定マトリックスのレビュー
次の意思決定マトリクスを使用して、OCIサービスの使用可能な選択肢と、特定のサービスを選択する際の考慮事項または評価要素について学習します。
| サービス/係数 | キュー | ストリーミング | 通知 | Oracle Integration (Gen2, Gen3) | Autonomous Database (TEQおよびAQ) |
|---|---|---|---|---|---|
| 振分けとオーケストレーション |
振り付け |
振り付け | 振り付け | 振分けおよびオーケストレーション(統合構成によって異なります) | 振分けおよびオーケストレーション(統合構成によって異なります) |
| メッセージまたはイベントごとの支払と一括購入 | Per API call + multiplier for messages > 64 KB |
Per GB data transfer + Storage |
通信チャネルに依存します。送信数量による価格設定。 | 1時間当たり5000の統合コールのブロック単位の価格 | いいえ、データベースの価格です |
| メッセージの1つまたは複数のコンシューマ |
シングル・コンシューマ。(競合条件は許可されますが、メッセージごとにコンシューマは1つのみです)。 |
単一および複数 | 単一および複数 | 単一および複数(統合定義に依存) | 単一および複数 |
| 読取り後のメッセージ保持 | いいえ | はい | いいえ | はい(統合定義によって異なります) | はい |
| 保証されたオーダー | 最高努力 | はい、パーティション内です | いいえ | はい(統合定義によって異なります) | 一部(優先度に関するルールを設定でき、消費オーダーを決定できます) |
| 非同期操作 | はい | はい | はい | はい(統合定義によって異なります) | はい |
| 入力に対応した業界標準 | REST API, STOMP | Kafka Connect | OCIイベントからのクラウド・イベント、アラーム | 複数の異なるアダプタ |
JMSおよびSQL REST APIを提供することで、カスタムORDS実装をさらに公開 |
| サードパーティ・アダプタのサポート |
オープンソースの STOMP実装 |
Kafka準拠のツール、ライブラリまたはSDK | いいえ | 幅広い業界アダプタRESTインタフェースまたは標準のJMSクライアントから生成できます。 |
標準JMS標準ライブラリの使用 SQLは広くサポートされています。 |
| 出力でサポートされる業界標準 | STOMP、REST API | Kafka Connect | 電子メール、Slack、PagerDuty、HTTP/S | 複数の異なるアダプタ | JMSおよびSQL |
| 最大メッセージ率 | 10MBPS |
パーティション当たり1MB/秒 1秒当たり最大250の |
HTTP/Sの場合は60/分 電子メールの場合は10/分 通知トピックの60/分 |
指定なし | データベースのサイズ設定に依存します。 |
| メッセージ保存期間 | 7日間(構成されている場合はさらに短く) | 7日 | 配信の再試行が終了するまで | 未定義 | 構成可能 |
| 最大保存ボリューム | キュー当たり2GB (テナンシ当たり20GB) | 保持は、パーティション当たり1MB/秒の最大書込み速度で7日間決定されます。 | メッセージ・レートおよび配信再試行期間の機能。 | なし | データベース構成に依存 |
| メッセージを送信するためのOCI SDKまたはCLIによるサポート | はい | はい | はい | いいえ | いいえ |
| コンパートメント当たりの個々のデプロイメント | はい | はい | はい |
いいえ。個々の統合ではなく、コンパートメント・レベルで分離されたOracle Integrationインスタンス |
いいえ。データベース・インスタンスは、個々のキューではなくコンパートメントに整列します。 |
| IAM認証(RBACなど)を使用します。 | はい | はい | はい | はい | はい |
| データは転送中および保存時に暗号化されます。 | はい | はい | はい | はい | データベース構成に依存 |
| メッセージ変換 | いいえ | いいえ |
制限あり。 電子メールなどに適したフォーマット。エンドポイントがOracle Functionsを使用している場合、Functionsはメッセージを変換できます。 |
はい | はい(ストアドSQLプロシージャ) |
| 監査証跡 | はい(ロギングを使用) | はい(ロギングを使用) | はい(ロギングを使用) | はい(ロギングとともにOracle Integrationを含む) | はい |
このマトリックスは、以下の情報を使用して解釈できます。
- 支払モデル: メッセージごと、または容量の一括購入を参照します。
- 競合状態: キューに複数のコンシューマがある場合、コンシューマは「競合状態」であると表現されます。これは、次のメッセージがコンシューマによって処理され、別のメッセージに対する準備が整うためです。
- RESTベースのエンドポイント: 一部のサービスはRESTベースのエンドポイントを提供します。RESTペイロードがOpen API仕様を使用してモデル化されている場合、ペイロード固有のSDKを提供できない可能性があります。そのような場合、APIゲートウェイ・サービスを使用してSDKを生成できます。詳細は、APIリソース用のSDKの生成に関するOCIドキュメントを参照してください。
マトリックスは、OCIサービスに加えて、次のテクノロジを参照します。
- STOMP: 単純(またはストリーミング)テキスト指向メッセージング・プロトコル。これは、STOMPクライアントが任意の STOMPメッセージブローカと通信して、多数の言語、プラットフォーム、およびブローカ間で簡単かつ広範囲のメッセージング相互運用性を実現できるように、相互運用可能なワイヤ形式を提供します。
- STOMP実装: 既知の STOMP準拠のメッセージサーバーを参照します。
- Kafka Connect: このツールは、Apache Kafkaと他のシステム間でデータを確実にストリーミングおよびスケーリングできるようにします。Kafkaとの間で大規模なデータ収集を移動するコネクタをすばやく定義できます。
テクノロジに関する追加情報は、「探索」セクションで確認できます。