ストリーミングの概要
Oracle Cloud Infrastructure Streamingは、大量のデータ・ストリームをリアルタイムで収集および消費するための、スケーラブルで耐久性の高いフルマネージド・ソリューションを提供します。ストリーミングは、パブリッシュ/サブスクライブ・メッセージング・モデルでデータが連続して順番に生成および処理されるユース・ケースに使用します。
ストリーミングは次に使用できます:
- メッセージング
- ストリーミングを使用して、大規模システムのコンポーネントを分離します。プロデューサおよびコンシューマは、非同期メッセージ・バスとしてストリーミングを使用し、独立して自己のペースで動作できます。
- メトリックおよびログの収集
- 従来のファイル・スクレイピング方法の代替手段としてストリーミングを使用し、クリティカルな運用データをより迅速に索引付け、分析およびビジュアライゼーションに利用できるようにします。
- Webまたはモバイル・アクティビティ・データの収集
- ストリーミングを使用して、Webサイトまたはモバイル・アプリケーションからアクティビティ(ページ・ビュー、検索、その他のアクションなど)を取得します。この情報は、リアルタイムのモニタリングおよび分析に加え、データ・ウェアハウス・システムではオフライン処理およびレポート作成のために使用できます。
- インフラストラクチャおよびアプリケーション・イベント処理
- クラウド・コンポーネントの統合エントリ・ポイントとしてストリーミングを使用して、監査、会計および関連アクティビティのライフサイクル・イベントをレポートします。
ストリーミングの機能
ストリーミングには次の機能があります:
- フルマネージド
- ストリーミングは、基礎となるインフラストラクチャからプロビジョニング、デプロイメント、メンテナンス、セキュリティ・パッチ適用およびレプリケーションまで、フルマネージドです。モニタリングおよびデフォルト・メトリックとの統合により、操作が簡単になります。
Oracleはストリーム・パーティションを管理し、コンシューマ・グループはメッセージ・オフセットを処理できます。
- 耐久性および可用性
- ストリーミング・サービスに公開されたメッセージは、使用可能な場合、3つの可用性ドメイン間で同期的にレプリケートされます。単一の可用性ドメインを持つリージョンでは、データは複数のフォルト・ドメイン間でレプリケートされます。これにより、可用性ドメインまたはフォルト・ドメインに障害が発生しても、データが失われることはありません。その結果、耐久性の高いデータになります。
Oracle Cloud Infrastructureは、ストリーミングのサービス・レベル合意(SLA)を提供します。詳細は、「Oracle Cloud Infrastructureサービス・レベル合意」ページを参照してください。
- セキュリティ
-
ストリーミング・データは、保存中と転送中の両方で暗号化されるため、メッセージの整合性が保証されます。特定のコンプライアンスまたはセキュリティ標準を満たす必要がある場合は、Oracleに暗号化を管理させたり、Oracle Cloud Infrastructure Vaultサービスを使用して独自の暗号化キーを安全に格納および管理したりできます。
Oracle Cloud Infrastructure Identity and Access Management (IAM)との統合により、どのユーザーおよびサービスがどのキーにアクセスできるか、およびそれらのリソースで何を実行できるかを制御します。
プライベート・エンドポイントは、テナンシ内の指定された仮想クラウド・ネットワーク(VCN)へのアクセスを制限し、そのストリームにインターネットを介してアクセスできないようにします。
詳細は、ストリームの保護を参照してください。
- ストリーム処理
- StreamingとOracle Cloud Infrastructure Connector Hubを統合すると、ストリームをデータ・ソースとして指定できます。Oracle Cloud Infrastructure Functionsを使用してストリームのメッセージを変換し、変換されたメッセージをオブジェクト・ストレージまたはその他のサポートされているコネクタ・ハブ・ターゲットに出力しながら、Streamingの順序保証を維持します。
- Kafka互換性
- ストリーミングにより、独自のApache Kafkaクラスタのホスト時に必要なインフラストラクチャの設定、メンテナンスおよび管理の負荷を軽減できます。
ストリーミングは、ほとんどのKafka APIと互換性があり、Kafka用に記述されたアプリケーションを使用して、コードをリライトせずにストリーミング・サービスとの間でメッセージを送信および受信できます。詳細は、Kafka APIの使用を参照してください。
また、ストリーミングでは、Kafka Connectエコシステムの利点を活用し、即時利用可能なKafkaソースとシンク・コネクタを使用して、ファーストパーティ製品やサードパーティ製品と直接連携できます。詳細は、Kafka Connectの使用を参照してください。
ストリーミングの仕組み
次に、ストリーミングの仕組みを示します:
プロデューサは、メッセージをストリーム(追加専用ログ)に公開します。これらのメッセージは、スケーラビリティのためにOracle管理のパーティション間に分散されます。
パーティションを使用すると、メッセージを複数のノード(またはブローカ)に分けることによってストリームを分散できます。各パーティションを別個のマシンに配置して、同時に複数のコンシューマが1つのストリームを読み取ることができます。
コンシューマは、1つ以上のパーティションからメッセージを読み取ります。コンシューマは、パーティションがホストされている場所に関係なく、任意のパーティションから読み取ることができます。ストリーム内の各メッセージは、オフセット値でマークされるため、コンシューマは中断された場合に停止した場所を特定できます。パーティションからのメッセージは、生成されたときと同じ順序で配信されることが保証されます。
詳細は、次を参照してください:
ストリーミングの概念
ストリーミングの理解および作業には、次の概念が非常に重要です。
- ストリーム
- メッセージのパーティション化された追加専用ログ。
- ストリーム・プール
-
共有Kafkaやセキュリティ設定など、ストリームの編成および管理に使用できるグループ。
- パーティション
- ストリームの断片。パーティションを使用すると、メッセージを複数のノードで分割することによってストリームを分散できます。これにより、同時に複数のコンシューマが1つのストリームから読み取ることができます。
- カーソル
-
ストリーム内のロケーションへのポインタです。このロケーションは、パーティション内の特定のオフセットまたは時間を指すポインタでも、グループの現在のロケーションを指すポインタでもかまいません。
- メッセージ
- ストリームに公開されるBase64でエンコードされたメッセージ。ストリーミングは、スキーマに依存せず、XML、JSON、CSV、およびgzipなどの圧縮フォーマットを含む任意のメッセージ・フォーマットを受け入れます。プロデューサとコンシューマは、メッセージ・フォーマットについて合意する必要があります。
- プロデューサ
- ストリームにメッセージを公開するエンティティ。
- コンシューマ
- 1つ以上のストリームからメッセージを読み取るエンティティ。
- コンシューマ・グループ
- ストリーム内のすべてのパーティションからのメッセージを消費するように調整するインスタンスのセット。特定のパーティションからのメッセージは、任意の時点でグループ内の単一のコンシューマによってのみ消費できます。
- インスタンス
- コンシューマ・グループのメンバー。インスタンスは、グループ・カーソルの作成時に定義されます。グループ・メンバーシップは対話を通じて維持されます。対話がないとタイムアウトが発生し、インスタンスはコンシューマ・グループから削除されます。
- キー
- 関連メッセージのグループ化に使用する識別子。
- オフセット
- パーティション内のメッセージの場所。パーティション内の各メッセージは、そのオフセットによって識別されます。コンシューマは、選択したオフセットから始まるメッセージを読み取ることができます。オフセットを使用すると、中断した場合にストリームからの読取りを再開できます。
ストリームの利点
ストリームには、従来のメッセージング・キューと比較して次のようないくつかの利点があります:
- 構成可能なメッセージ永続性
- データの保持期間を制御できます。ストリーム内のメッセージは不変であり、ストリームの構成された保持期間全体にわたり使用できます。
- リプレイ
- ストリームのメッセージはコンシューマによる処理時にすぐに削除されないため、構成された保持制限内で、ストリーム内のすべてのメッセージをいつでもリプレイできます。
- メッセージ保証
- 各メッセージは、少なくとも1回配信されることが保証されます。オフラインになる前にコンシューマがメッセージをコミットできない場合など、メッセージが複数回配信される場合もあります。
- 順序保証
- ストリーム内のメッセージは、パーティションごとに、生成されたときと同じ順序で配信されます。
- クライアント側のカーソル
- クライアント・アプリケーションは、読取り対象のメッセージを制御およびトラッキングし、必要に応じてカーソルを移動して柔軟性を最大限に高めることができます。
- 水平スケール
- パーティションにより、複数のコンシューマのニーズを満たすようにスループットをスケール・アップする機会が提供され、柔軟性が向上します。
- コンシューマ・グループ
- コンシューマ・グループは、複数のコンシューマにメッセージをバランスのとれた方法で配信するために必要なすべての調整を処理します。この管理は、すべてのメンバーのかわりにコンシューマ・グループによって処理されるため、オーバーヘッドの削減と操作性の簡素化を実現できます。