該当する結果がありません

一致する検索結果がありませんでした。

お探しのものを見つけるために、以下の項目を試してみてください。

  • キーワード検索のスペルを確認してください。
  • 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。
  • 下記に示すよく使用される検索語句のいずれかを試してみてください。
  • 新しい検索を開始してください。
急上昇中の質問

よくある質問

すべて開く すべて閉じる

    全般的な質問

  • Oracle Cloud Infrastructure Streaming(OCIストリーミングとは?

    Oracle Cloud Infrastructure Streamingサービスは、フルマネージドでスケーラブルな耐久性のあるストレージオプションを提供し、ほぼリアルタイムで消費および処理できるデータの継続的で大量のストリームを提供します。

    詳細については、次のトピックを参照してください。ドキュメント

  • ストリーミングサービスはどこで利用できますか?

    現在ストリーミングサービスを実行している地域のリストについては、ドキュメントをご参照ください。

  • APIエンドポイントとは何ですか?

    APIエンドポイントは次のように構成されています。https://streaming.$_REGION.oci.oraclecloud.com

    変数の例として:

    • us-phoenix-1
    • us-ashburn-1
  • OCIストリーミングは私の代わりに何を管理しますか?

    OCIストリーミングは完全に管理されています。基盤となるインフラストラクチャからプロビジョニング、デプロイ、メンテナンス、セキュリティパッチ、レプリケーション、コンシューマグループに至るまで管理されているため、アプリ開発が容易になります。

  • Oracle Cloud Infrastructure Streamingはどのように復元性を提供しますか?

    OCIストリーミング内にストリームを作成すると、Oracleは3つの異なるAD(または単一のADリージョンのフォールトドメイン)に分散された3つのストリーミングノードを自動的に作成および管理し、ストリームの可用性とデータの耐久性を維持できるようにします。

  • OCIストリーミングで何ができますか?

    OCIストリーミングを使用すると、ほぼリアルタイムでデータを発行し、データを取得できます。メッセージから複雑なデータストリーム処理まで、使用例の数はほぼ無制限です。

    以下は、ストリーミングの多くの可能な使用法の一部です。

    • メッセージ:ストリーミングを使用して、大規模システムのコンポーネントを分離します。ストリーミングは、負荷スパイクを平坦化するのに十分な容量を備えたプル/バッファベースの通信モデルと、複数のコンシューマに同じデータを個別に供給する機能を提供します。キースコープの順序付けと耐久性の保証により、高スループットの可能性により、そのようなシステムを適切にスケーリングしながら、さまざまなメッセージパターンを実行するための信頼性の高いプリミティブが提供されます。
    • メトリックとログの取り込み:従来のファイルスクレイピングアプローチの代わりにストリーミングを使用して、重要な運用データを、インデックス作成、分析、視覚化に迅速に利用できるようにします。
    • ウェブ/モバイルアクティビティのデータの取り込み:ストリーミングを使用して、Webサイトまたはモバイルアプリからのアクティビティ(ページビュー、検索、またはユーザーが行う可能性のあるその他のアクションなど)をキャプチャします。この情報は、リアルタイムの監視と分析、およびオフラインでの処理とレポート作成のためのデータウェアハウジングシステムで使用できます。
    • インフラストラクチャとアプリのイベント処理:クラウドコンポーネントの統合エントリポイントとしてストリーミングを使用し、監査、会計、および関連アクティビティのライフサイクルイベントのレポート作成をします。
  • OCIストリーミングの使用方法を教えてください?

    OCIストリーミングの使用を開始するには:

    • OCIストリーミングコンソールまたはCreateTopic APIを使用して新しいストリームを作成
    • プロデューサーからトピックへのデータの発行(詳細なドキュメントをご参照ください)
    • ストリームからデータを読み取って処理するコンシューマーを構築
  • OCIストリーミングの制限はどれくらいですか?

    全体的に、アクセスできるスループットの量に制限はありません。適切な数のパーティションでストリームをプロアクティブに設計する必要があるだけです。

    システムのハード制限は次のとおりです。

    • 最大7日間の保存期間。
    • 一意のメッセージの最大サイズは1 MBです
    • 各パーティションは、1秒あたり5回の読み取りAPI呼び出しを処理できます。書き込みリクエストがいくつあっても、1秒あたり最大1MBまでです。
    • 各パーティションは、1秒あたり1MBの最大合計データ書き込み率と1秒あたり2MBの読み取り率をサポートできます。
    • 各テナンシーには5つのパーティションの制限がありますが、もっとたくさんのパーティションのリクエストが可能- お問い合わせ
  • Oracle Cloud Infrastructure CLIを使ったストリーミングの使用方法を教えてください。

    例はこちらにあります GitHub oci-cli バイナリに含まれています。

  • パーティションにはどのようにアクセスすればよいですか?

    APIでは、パーティションは文字列で表されます。

    5つのパーティションを持つストリームを作成する場合、文字列「0」、「1」、「2」、「3」、または「4」を使用してアクセスできます。

    数値として表されるパーティション識別子に頼らないでください。

    オフセットは密ではありません。メッセージオフセットは常に1ずつ増加することが想定されますが、1ずつ増加しないこともあります。将来のオフセットの計算には使用しないでください。

    たとえば、同じパーティションで2つのメッセージを公開する場合、最初のメッセージのオフセットは42、2番目のメッセージのオフセットは45(オフセット43と44が存在しない)になります。

    キーコンセプト

  • ストリームとは何ですか?

    ストリームは、メッセージを含む追加専用のログファイルとして表示されます。

  • パーティションとは?

    ストリームは、スケーラビリティーのためにいくつかのパーティションに分割されます。パーティションを使用すると、メッセージを複数のノード(またはブローカー)に分割することでストリームを分散できます。各パーティションを別々のマシンに出力して、複数のコンシューマーがトピックから並行して読み取ることができるようになります。

  • メッセージとは?

    64ビットでエンコードされたメッセージは、トピックに発行するものです。

  • オフセットとは何ですか?

    パーティション内の各メッセージには、オフセットと呼ばれる識別子があります。コンシューマーは特定のオフセットから始まるメッセージを読み取ることができ、選択した任意のオフセットポイントから読み取ることができます。コンシューマーは最新の処理済みオフセットをコミットすることもできるため、停止して再起動した場合にメッセージを再生したり、見落としたりすることなく作業を再開できます。

  • キーとは何ですか?

    キーは、関連するメッセージをグループ化するために使用される識別子です。

    ストリームの作成

  • 新しいストリームを作成するには?

    コンソールまたはAPIを使用して、新しいストリームを作成できます。こちらのAPIをご覧ください。

    ストリームは、特定のリージョンとテナンシー用に作成され、オプションで専用コンパートメント用にも作成できます。Steamのデータはリージョン全体に複製され、サービスを中断することなくADの損失やネットワークの分割を許容し、リージョンに組み込みの高い可用性を提供します。

  • プロビジョニングにはどのくらい時間がかかりますか?

    プロビジョニングにかかる時間は、パーティションの数によって異なります。新しいパーティションの作成には最大10秒かかります。

  • 必要なパーティションの数はどう決定すればよいですか?

    ストリームのパーティションの数は、アプリケーションのスループットの期待値によります(期待されるスループット=平均調整サイズ x 1秒あたりに書き込まれるレコードの最大数)。

  • ストリームにリクエストできる最小スループットはいくつですか?

    Oracle Cloud Infrastructureストリームのスループットは、パーティションによって定義されます。パーティションは、1秒あたり1MBのデータ入力と2秒あたり2MBのデータ出力を提供します。

  • パーティションに送信できるリクエストの数は?

    1秒あたり1,000件のリクエストをパーティションに送信できます。

  • SDKの使用方法を教えてください。
  • SDKはどこにありますか?
  • 使用言語を増やす予定はありますか?

    ストリーミングSDKは、他のOCI SDKの実行と同じ言語をサポートしています。特にストリーミングサービスではサポートされる 言語の追加はありません。

  • ストリーミングに必要なAPIのリストはどこにありますか?

    ストリームへのデータの公開

  • データをストリームに発行する方法を教えてください。

    ストリームが作成されてアクティブになると、メッセージを公開できます。公開には、Write API(putMessages)を使用できます。メッセージはストリーム内のパーティションに公開されます。複数のパーティションがある場合、メッセージが公開されるパーティションは、メッセージのキーを使用して計算されます。

  • nullキーを送信した場合、データはOCIストリーミングにどう格納されますか?

    キーがnullの場合、パーティションは値のサブセットを使用して計算されます。nullキーのあるメッセージの場合、パーティションスキームが変更される可能性があるため、同じ値のメッセージが同じパーティションに送信されることを想定しないでください。nullキーを送信すると、メッセージはランダムなパーティションに効果的に出力されます。

  • OCIストリーミングでメッセージの順序を確実にする方法を教えてください。

    同じ値のメッセージが同じパーティションに送られるようにするには、それらのメッセージに同じキーを使用する必要があります。

  • メッセージの永続性を確保する方法を教えてください。

    OCIストリーミングAPIがputMessageをエラーなしで確認すれば、このメッセージは永続的になります。

  • OCI Streaming streamのデータの一貫性をどのようにして確保しますか?

    保証OCIストリーミングライナーは、パーティションキーへ読み込みおよびの書き込みをします。

  • 許可されている最大数を超えるデータを送信するとどうなりますか?

    クライアントのリクエストが制限を超えると、OCIストリーミングはリクエストを拒否し、エラー例外メッセージを送信します。

  • いつスロットルされますか?

    次のしきい値を超えると、スロットルメカニズムがアクティブになります。

    • GetMessages:1秒あたり5回の呼び出しまたはパーティションあたり1秒2MB
    • PutMessages:パーティションあたり1秒MB
    • 管理およびコントロールプレーン操作(CreateCursor、listStreamなど):ストリームあたり1秒に5回の呼び出し。
  • メッセージをバッチ処理する必要はありますか?

    次の理由により、メッセージのバッチ処理を推奨しています。

    • サービスに送信されるPutリクエストの数を減らして、スロットルを回避
    • スループットを向上

    メッセージのバッチサイズは1MBを超えてはなりません。この制限を超えると、スロットリングメカニズムがトリガーされます。

  • 1MBを超えるメッセージの処理はどうすればよいですか?

    次のいずれかの方法が使用できます。Object Storageを介してメッセージをチャンキングまたは送信する。

  • チャンキング

    大きなペイロードは、ストリーミングサービスが受け入れることができる複数の小さなチャンクに分割できます。

    チャンクは、通常の(チャンクされていない)メッセージ格納と同じ方法でサービスに格納されます。唯一の違いは、コンシューマはチャンクを保持し、すべてのチャンクが収集されたときにそれらを実際のメッセージと結合する必要があることです。

    パーティション内のチャンクは、通常のメッセージと織り交ぜることができます。

  • Object Storage

    大きなペイロードがObject Storageに出力され、そのデータへのポインターのみが転送されます。レシーバーはこのタイプのポインターペイロードを認識し、Object Storageからデータを透過的に読み取り、エンドユーザーに提供します。

  • サービスが受け入れる日付形式はどれですか?

    よくある間違いは、誤った日付形式を提供することです。

    ストリーミングサービスは、すべての日付のタイムゾーンを含むISO-8601をサポートします。

  • メッセージの公開中に、ストリーミングサービスからパーティション番号とオフセットを取得するにはどうすればよいですか?

    PutMessagesResultsEntryのクラスは以下のメソッドを提供します。

    • メッセージが公開されたパーティション番号を提供するgetPartition
    • 公開されたメッセージのオフセットを提供するgetOffset
  • メッセージの公開をしないで、ストリーミングサービスからパーティション番号とオフセットを取得するにはどうすればよいですか?

    現時点では、メッセージを公開せずに最新の公開メッセージを表示する方法はありません。

    グループまたはパーティションごとに、最新のコミットされたオフセットを表示するメカニズムがあります。getGroupエンドポイントを調べます。

    ストリームからのデータ使用 - シングルコンシューマ

  • ストリームからデータを読み取って使用する方法を教えてください。

    メッセージの消費には、次のことが必要です。

  • OCI Streaming Streamからデータを使用する方法をいくつか教えてください。

    OCIストリーミングは、2種類の消費APIを提供します。

    • データを読み取るパーティションとオフセットを正確に制御する低レベルの検査
    • アプリ開発を簡素化する負荷グループ、調整、オフセット追跡をサービスにオフロードするコンシューマ・グループ
  • コンシューマ・グループはどのように機能しますか?

    コンシューマは、グループの一部としてメッセージを消費するよう構成できます。ストリームパーティションはグループのメンバー間で分散されるため、単一のパーティションからのメッセージは単一のコンシューマにのみ送信されます。

    パーティションの割り当ては、コンシューマがグループに参加またはグループから脱退するときに再調整されます。

  • コンシューマへのメッセージ重複を回避するにはどうすればよいですか?

    コンシューマアプリケーションで重複を処理することを推奨しています。

  • コンシューマの遅延はどうすればわかりますか?

    コンシューマの遅延の有無(消費よりも速く生産している場合)を知りたい場合は、メッセージのタイムスタンプと現在の時刻の差を使用できます。この数値を増えると、新しいコンシューマを生成して、最初のコンシューマの一部からパーティションを引き継ぐことができます。

  • 単一のコンシューマとは何ですか?

    単一のコンシューマは、1つ以上のストリームからメッセージを読み取るエンティティです。

    このエンティティは、単独で存在またはコンシューマ・グループの一部として存在することもできます。

  • カーソルとは?

    ストリーム内の場所へのポインターです。この場所は、パーティション内の特定のオフセットや時間へのポインタ、またはグループの現在の場所へのポインタである場合があります。

  • 使用できるカーソルタイプを教えてください。

    次のカーソルタイプが使用できます。TRIM_HORIZON、AT_OFFSET、AFTER_OFFSET、AT_TIME、LATEST。詳細については、キュメンテーションを参照してください。

  • メッセージを消費するたびにカーソルを再生成する必要がありますか?

    いいえ、カーソルはループの外で作成される必要があります。カーソルを作成したら、GetMessagesメソッドを消費してメッセージの消費を開始できます。GetMessagesを呼び出すたびに、次のGetMessages呼び出しで使用するカーソルが返されます。

    返されたカーソルはnullではなく、5分で期限切れになります。消費し続ける限り、カーソルを再作成する必要はありません。

    GetMessages、Commit、およびHeartbeatはすべて、後続の呼び出しに使用する新しいカーソルを返します。

    Javaコードスニペットは、ドキュメントにあります。

    いくつかのエラーケースでは、新しいカーソルを作成する必要があります。これを障害対策の一部として処理することを推奨しています。

  • テナントBに属するコンシューマは、テナントAに属するストリームからのメッセージを消費できますか?

    これは、ポリシーを介して消費できます。テナントAは、テナントBにストリームプルアクセスを許可するポリシーを作成する必要があります

  • オフセットの処理方法を教えてください。

    グループカーソルを使用していない場合、処理されたオフセットの格納はコンシューマで管理する必要があります。

    グループ・コンシューマを使用している場合、処理されたオフセットは、失敗のケースでコミットできます。

    カーソルを作成するときに、どのカーソルのタイプを使用するか指定します。アプリケーションがメッセージの消費を開始するとき、到達または停止したオフセットを保存する必要があります。

    このシナリオは、ストリームごとに1つのパーティションのみを使用して、デモまたは概念実証を行うときに実用的です。複数のパーティションがある生産環境では、コンシューマグループの使用を推奨しています。

  • getMessageの呼び出しからメッセージはいくつ取得できますか?

    GetMessageRequest クラスのgetLimit()メソッドは、メッセージの最大数を返します。10,000まで任意の値を指定できます。デフォルトでは、サービスは可能な限り多くのメッセージを返します。

    ストリームのスループットを超えないように、平均メッセージサイズを検討してください。

    ストリーミングサービスのgetMessageバッチサイズは、特定のストリームに公開された平均メッセージサイズに基づいています。

    ストリームからのデータ消費 - コンシューマ・グループ

  • コンシューマ・グループはどのように機能しますか?

    詳細な説明については、ドキュメントをご参照ください。

  • コンシューマ・グループを使用するメリットはありますか?

    コンシューマ・グループには次のメリットがあります。

    • 各インスタンスは1つ以上のパーティション(「自動的に」割り当てられている)からメッセージを受信し、同じメッセージは(異なるパーティションに割り当てられている)他のインスタンスでは受信されません。このようにして、インスタンスの数を増やすことができます(1つのインスタンスが1つのパーティションのみを読み取るようにします)。この場合、グループに参加する新しいインスタンスは、どのパーティションにも割り当てられずに、partitionsanアイドル状態の数内に入ります。
    • インスタンスを一部の手段として持つことは、さまざまなコンシューマ・グループからのメッセージを公開/登録のパターンパーティションがすべてのインスタンスに送信されるようできます。同じコンシューマ・グループ内では、ルールは次の最初の画像に示すとおりですが、異なるグループにわたって、インスタンスは同じメッセージを受信します(2番目の画像を参照)。これは、パーティション内のメッセージが、さまざまな方法でメッセージ処理する異なるアプリケーションにとって重要な場合に役立ちます。興味のあるすべてのアプリケーションが、パーティションから同じメッセージをすべて受信するようにします。
    • コンシューマ・グループのもう1つのメリットは、リバランス機能です。インスタンスがグループに参加するときに、十分なパーティションがある場合(つまり、パーティションごとに1つのインスタンスの制限に達していない場合)、リバランスが開始されます。パーティションは現在のインスタンスと新しいインスタンスに再割り当てされます。同様に、インスタンスがグループを離れると、パーティションは残りのインスタンスに再割り当てされます。
    • オフセットのコミットは自動で管理されます。
  • インスタンスとは何ですか?

    インスタンスはコンシューマ・グループのメンバーのことです。グループカーソルが作成されるときに定義されます。

    パーティションの読み取りは、コンシューマ・グループ内のインスタンス間で分散されます。

    インスタンス名は、オフセット管理に関連する操作のグループのメンバーを識別します。

    コンシューマ・グループのメンバーごとに一意のインスタンス名を使用することを推奨しています。

  • インスタンスに名前を付ける上でベストプラクティスはありますか?

    ベストプラクティスは、有用な情報を連結した文字列を使用することです。

  • どのタイムアウトに注意する必要がありますか?

    次のストリーミングサービスのコンポーネントにはタイムアウトがあります。

    • カーソル:メッセージを消費し続ける限り、新しいカーソルを作成する必要はありません。メッセージの消費が5分を超えて停止した場合は、カーソルを再作成する必要があります。
    • インスタンスインスタンスがメッセージの消費を30秒以上停止すると、そのインスタンスはコンシューマ・グループから削除され、そのパーティションが別のインスタンスに再割り当てされます(再分散がトリガーされます)。
  • インスタンスは、タイムアウトするまでにハートビートする必要がありますか?

    コンシューマ・グループ内の各インスタンスは、30秒のタイムアウトの前にハートビートする必要があります。たとえば、メッセージの処理に時間がかかりすぎる場合は、インスタンスがハートビートを送信することを推奨しています。

  • インスタンスがタイムアウトするとどうなりますか?

    30秒のタイムアウトに達すると、インスタンスはコンシューマ・グループから削除され、そのパーティションは別のインスタンスに再割り当てされます(可能な場合)。この事象はリバランスと呼ばれます。

  • コンシューマ・グループ内のリバランスとは何ですか?

    リバランスとは、(同じコンシューマ・グループに属する)インスタンスのグループが、特定のストリームに属するパーティションの専用セットを相互に所有するように分散するプロセスです。

    コンシューマ・グループのリバランス操作が正常に終了すると、ストリーム内のすべてのパーティションは、グループ内の1つまたは複数のコンシューマインスタンスによって所有されます。

  • 効果的なパーティションキーを生成する方法を教えてください。

    均一な分散を確実にするには、メッセージキーに適切な値を作成する必要があります。そのためには、ストリーミングデータの選択性とカーディナリティを検討してください。

    • カーディナリティ:特定の用途ケースに基づいて生成される可能性のある一意のキーの総数を検討してください。キーカーディナリティが高いほど、分散がよくなります。
    • 選択性:各キーを持つメッセージ数を検討してください。選択性が高いほど、キーあたりのメッセージ数が多くなり、ホットスポットの発生につながります。

    低い選択性で高いカーディナリティを目指します。

  • メッセージはどのパーティションに送られますか?

    ストリーミングサービスでは、キーが寄せ集められ、パーティションの決定に使用されます。同じキーのメッセージは同じパーティションに行きます。キーが異なるメッセージは、異なるパーティションまたは同じパーティションに送信される場合があります。

  • メッセージを特定のパーティションに強制的に送ることはできますか?

    プロデューサーとして、メッセージの送信先のパーティションを明示的に管理する方法はありません。

    データがキーといっしょに送信される場合、プロデューサーはデータを特定のパーティションに強制できません。

  • StreamClientインスタンスをスレッド間で共有できますか?

    はい、StreamClientはスレッドセーフです。

    オブジェクトがステートレスの場合、呼び出し間でデータを保持する必要はありません。変更する状態がないため、1つのスレッドが、オブジェクトの操作を呼び出す別のスレッドの結果に影響を与えることはありません。このため、ステートレスクラスは本質的にスレッドセーフです。

  • 現在のパーティションにはいくつのメッセージがありますか?

    コンシューマのラグは、ストリーミングサービスにではまだ実装されていません。

    各メッセージに対して生成されたオフセットは、putMessage呼び出しの成功毎に返されます。

    メッセージのオフセットは、getMessage呼び出しによって返されるすべてのメッセージに含まれます。

    パーティションごとに生成されたオフセットと消費されたオフセットの差分を追跡することで、ラグを特定できます。

  • メッセージの消費が遅れているかどうかを確認する方法を教えてください。

    コンシューマが遅れているかどうか(消費よりも速く生産している場合)を判別するには、メッセージのタイムスタンプを使用します。コンシューマが遅れている場合は、新しいコンシューマを生成して、最初のコンシューマからいくつかのパーティションを引き継ぐことを検討してください。単一のパーティションで遅れている場合、回復する方法はありません。

    次のオプションを検討してください。

    • ストリームのパーティション数を増やします。
    • 問題の原因がホットスポットである場合は、メッセージキーの戦略を変更してください。
    • メッセージの処理時間を短縮するか、リクエストを並行して処理します。

    特定のパーティションで消費するメッセージがいくつ残っているかを知りたい場合は、タイプのカーソルを使用して、次のLATESTpublishedメッセージのオフセットを取得し、現在使用しているオフセットでデルタを作成します。

    密度オフセットがないため、スペースが確保されます。ただし、プロデューサーが生成を停止した場合、その情報を取得するためだけに大まかな見積もりを行うことはできません(次の公開メッセージのオフセットを取得することはできないためです)。

  • コンシューマAにパーティション1のカーソルがあるが、30秒のタイムアウトの前にパーティションが新しいコンシューマに再割り当てされる場合、予想される動作は何ですか?

    再割り当ては、コミットとタイムアウト時のみ発生します。commitOnGet = true処理に30秒以上かかる場合は、ハートビートの使用を推奨しています。

    カスタムコミットロジックの記述は複雑であり、競合状態と考慮事項でいっぱいです。内部状態が変化するケースが多く、クライアントが対応する必要があります。

  • コンシューマ・グループのインスタンスが非アクティブになるとどうなりますか?

    はい、StreamClientはスレッドセーフです。

    コンシューマ・グループのインスタンスは、30秒以上ハートビートを送信しない場合、またはプロセスが終了した場合、非アクティブであると見なされます。

    これが発生すると、非アクティブなインスタンスによって以前に消費されたパーティションを処理するために、コンシューマ・グループ内でリバランスが発生します。

  • 以前は非アクティブであったコンシューマ・グループのインスタンスがグループに再び参加するとどうなりますか?

    このようなインスタンスは、新しいインスタンスと見なされます。リバランスがトリガーされ、インスタンスにはメッセージの消費を開始するためのパーティションが割り当てられます。

    ストリーミングサービスは、同じパーティション(終了前に割り当てられたパーティション)がこのインスタンスに再割り当てされるかどうかについては保証しません。

  • 以前に非アクティブだったコンシューマ・グループのインスタンスがグループに再び参加すると、重複したメッセージは消費されますか?

    ストリーミングサービスは、「少なくとも1回」のセマンティクスをコンシューマ・グループに提供します。メッセージループでオフセットがいつコミットされるかを検討します。メッセージのバッチをコミットする前にコンシューマがクラッシュした場合、そのバッチは別のコンシューマに渡される可能性があります。パーティションが別のコンシューマに与えられると、コンシューマは最新のコミットされたオフセットを使用して消費を開始します。コンシューマは、コミットされたオフセットの前はメッセージを受け取りません。

  • オフセットコミットはどのように処理すればよいですか?

    ストリーミングサービスは、thegetCommitOnGetisがtrueに設定されている場合、コンシューマ・グループのオフセットコミットを自動的に処理します。

    アプリケーションの複雑さを軽減するため、この方法の使用を推奨しています。つまり、アプリケーションはコミットメカニズムを実装すべきではありません。

    この設定を上書きしてカスタムオフセットコミットメカニズムを実装するには、コンシューマ・グループの作成時にgetCommitOnGettoをfalseに設定します。

  • CommitOnGetはどのように機能しますか?

    CommitOnGetは、前のリクエストからのオフセットがコミットされることを意味します。この機能の説明は、次の例を参考にしてください。

    コンシューマA

    • AはgetMessagesを呼び出し、オフセットが1〜100の任意のパーティションからメッセージを受信します。
    • Aは100個すべてのメッセージを正常に処理します
    • AがgetMessagesを呼び出すと、ストリーミングサービスはオフセット100をコミットし、オフセット101〜200のメッセージを返します。
    • Aは15のメッセージを処理してから、予告なくオフラインになります(30秒以上)。

    オーケストレーションシステムは新しいコンシューマBを開始:

    • BがgetMessagesを呼び出すと、ストリーミングサービスはコミットされた最新のオフセットを使用して、オフセット101〜200のメッセージを返します。
    • Bメッセージループを続行します。

    この例では、メッセージは失われませんでしたが、オフセット101〜115は少なくとも1回は処理されました。つまり、メッセージは複数回処理された可能性があります。

    この例では、メッセージの一部(15)が処理され、障害Beventの後に新しいコンシューマに再配信される可能性がありますが、データは失われません。

  • 複数のパーティションストリーム内の単一パーティションの保持期間を超えたオフセットの更新方法を教えてください。

    現在、コンシューマ・グループの個々のパーティションを更新することはできません。

    updateGroup呼び出しの現在の動作は、すべてのパーティションのcommittedOffsetをリセットすることです。これにより、他の正常なコンシューマに割り当てられたパーティションの不要な古いメッセージが取得されてしまいます。

  • ハートビートを送信する必要があるのはなぜですか?

    コンシューマ・グループでは、メッセージを消費しているインスタンスは、30秒のタイムアウトに達する前にハートビートを送信する必要があります。インスタンスがハートビートの送信に失敗した場合、ストリーミングサービスはインスタンスが非アクティブであると見なし、パーティションの再割り当てをトリガーします。

  • 既にコミットされているカーソル文字列を使用してハートビートを送信した場合、予想される動作は何ですか?

    コミットされた呼び出しから取得されたカーソルには、オフセットがあってはなりません。ハートビートは、カーソル内のパーティションのタイムアウトを延長します。

    空のカーソルに対してハートビートを実行しても何も起こりません。以前にコミットされたカーソルがリバランスをトリガーする場合があります。

    カーソルがコミットされた後、(コミット呼び出しによって返されたものではなく)カーソルに対してハートビートが行われると、含まれているオフセットのタイムアウトと同じように更新されます。

  • コンシューマの障害からどのように回復すればよいですか?

    障害から回復するには、(パーティションごとに)処理した最後のメッセージのオフセットを保存して、コンシューマを再起動する必要がある場合にそのメッセージからの消費を開始できるようにする必要があります。

    注意:5分で期限切れになりますので、カーソルを保存しないでください。

    処理した最後のメッセージのオフセットを保存するためのガイダンスは提供されていないため、任意の方法(別のストリーム、Kiev、マシン上のファイル、オブジェクトストレージなど)が使用できます。

    コンシューマが再起動したら、最後に処理したメッセージのオフセットを読み取り、タイプのカーソルを作成して、取得したオフセットをAFTER_OFFSETで指定します。

    OCIストリーミングストリームの管理

  • 後でパーティションの数は変更できますか?

    最大スループットより少し高いパーティションを割り当てることを推奨しています。現在、ストリームが作成された後のパーティション数の変更はサポートされていないため、これはアプリケーションのスパイク管理に役立ちます。

  • トピックの持続性を変更できますか?

    デフォルトでは、データは24時間保存されます。ストリームの作成中は、最大7日間の保持期間を設定できます。保存期間を定義すると、編集できなくなります。

  • OCIストリーミングストリームの操作とパフォーマンスを監視するにはどうすればよいですか?

    OCIストリーミングのコンソールは、データの入出力のスループットなど、運用メトリックとパフォーマンスメトリックの両方を提供します。OCIストリーミングはOCIテレメトリとも統合されているため、ストリームのテレメトリメトリックの収集、表示、分析が可能です。

    セキュリティと暗号化

  • ストリームへのアクセスを管理および制御する方法を教えてください。

    同じテナンシーのすべてのストリームに、一意の不変名がつけられています。すべてのストリームにコンパートメントが割り当てられています。したがって、Oracle Cloud Infrastructureアクセス管理ポリシーのすべての機能を使用して、テナンシー、コンパートメント、または単一のストリームレベルで細かいルールを記述することもあります。

    アクセスポリシーは、「で許可する」の形式で指定します。

  • OCIストリーミングからデータを送信または使用するときの認証方法を教えてください。

    インターネットAPIはOracle Identityサービスを使用しています。Oracle Identityサービスは、ユーザーを認証し、ブラウザ(ユーザー名/パスワード)とコード(APIキー)の両方からそういったAPIへのアクセスを承認する便利な方法を提供します。

    ドキュメンテ―ションはこちらをご覧ください。

  • OCIストリーミングの使用時のデータの安全性

    OCIストリーミングはデフォルトで安全で、ユーザーデータは、静止時と動作中の両方で暗号化されます。アカウントとデータストリームの所有者のみが、作成したストリームリソースにアクセスできます。OCIストリーミングは、データへのアクセスを制御するユーザー認証をサポートしています。Oracle Cloud Infrastructure IAMポリシーを使用して、ユーザーおよびユーザーグループに選択的に権限を付与できます。HTTPSプロトコルを使用して、SSLエンドポイントを介してOCIストリーミングからデータを安全に出力および取得できます。

  • データは暗号化できますか?

    自分が発行するデータを所有します。OSSに送信する前にデータを暗号化できます。

  • データをOCIストリーミングストリームに送信してから取得するまでのデータの暗号化ライフサイクルについて教えてください。

    取り込み(プロデューサー - ストリーミングゲートウェイ):SSL(HTTPS)により移動中に暗号化されたデータ。

    ストリーミングサービスの内部:ゲートウェイSSLが終了すると、ストリームごとのAES-128キーでデータ到着時に暗号化され、持続性のためにストレージレイヤーに送信されます。

    消費時:暗号化されたデータはOSSから読み取られて、ゲートウェイノードによって復号化され、SSLを介してコンシューマに送信されます。

    消費時:暗号化されたデータはOCIストリーミングから読み取られて、ゲートウェイノードによって復号化され、SSLを介してコンシューマに送信されます。

  • OCIストリーミングの暗号化にはどの暗号化アルゴリズムが使用されますか?

    OCIストリーミングは、暗号化にAES-GCM 128アルゴリズムを使用します。

    監視

  • ストリームはどこで監視できますか?

    ストリーミングは OCI監視サービスと完全に統合されています。ストリーミングメトリックの説明はこちらです。

  • ストリーミングサービスはどのメトリックを出力しますか?

    ストリーミングサービスの監視は、プロデューサーとコンシューマに焦点が当てられています。ストリーミングサービスによって発行されるメトリックのリストについては、ドキュメンテ―ションをご覧ください。

  • ストリーミングサービスのモニタリングに利用できる統計情報を教えてください。

    コンソールで使用可能な各メトリックは、次の統計を提供します。

    • レート、合計、平均値
    • 最小、最大、カウント
    • P50、P90、P95、P99、P99.9

    これらの統計は4つの時間間隔を提供

    • 自動
    • 1分
    • 5分
    • 1時間
  • どのメトリックにアラームを設定すればよいです?

    プロデューサーの場合、次のメトリックにアラームを設定することを検討してください。

    • メッセージのLatency:networkを出力します。
    • メッセージの合計スループットの出力:
      • 合計スループットの重要な増加は、パーティションあたり1秒1MBの制限に達し、その事象がスロットルメカニズムをトリガーすることを示す場合があります。
      • 重要な減少は、クライアントプロデューサーに問題があるか、停止しようとしていることを意味します。
    • メッセージスロットルレコードの出力:メッセージがスロットルされたときに通知を受け取ることは重要です。
    • メッセージ失敗の出力:運用チームが理由の調査を開始できるように、メッセージの出力が失敗した場合に通知を受け取ることは重要です。

    コンシューマの場合、次のメトリックに基づいて同じアラームを設定することを検討してください。

    • メッセージのレイテンシを取得
    • メッセージ全体のスループットを取得
    • スロットルされたメッセージの取得
    • メッセージ失敗の取得
  • アラームを受け取ったらどうすればいいですか?

    アラームがトリガーされた場合、担当チームメンバーはアラームを調査して状況を評価する必要があります。

    問題がクライアント(プロデューサーまたはコンシューマ)に関連している場合、チームメンバーはそれを解決するか、Devチームでさらに調査する必要があります。

    問題がサーバーに関連している場合、チームメンバーはストリーミングサービスのサポートに連絡する必要があります。

  • ストリームが正常であるかの確認方法を教えてください。

    正常なストリームとは、アクティブなストリームのことです。正常に受信されたメッセージは、正常に消費されます。

    サービスへの書き込みは永続します。ストリームを生成でき、応答が成功すれば、ストリームは正常です。

    データが取り込まれた後、構成された保持期間の間、コンシューマはデータにアクセスできます。

    メッセージAPI取得の呼び出しが高いレベルの内部サーバーエラーを返してくる場合、サービスは正常ではありません。

    ストリームが正常だと、メトリックも正常です。

    • メッセージのレイテンシの出力レベルが低いです。
    • メッセージ出力の合計スループットは、パーティションあたり1秒1MB近いです。
    • メッセージのスロットルレコードの出力は、0に近いです。
    • メッセージ失敗の出力は、0に近いです。
    • メッセージのレイテンシの出力レベルが低いです。
    • メッセージの合計スループットの出力は、パーティションあたり1秒2MB近いです。
    • メッセージのスロットルリクエストの出力は、0に近いです。
    • メッセージ失敗の出力は、0に近いです。

    エラーの種類と意味

  • APIエラーのリストはどこにありますか?

    APIエラーの詳細は、ドキュメントにあります。

  • 部分的な障害とは何ですか?

    ストリーミングサービスは、パーティションごとのスロットルによる部分的な障害をサポートします。部分的な障害のケースでは、サービスは200のステータスコードを返し、応答ペイロードで障害を示します。

    リクエスト全体がスロットルされると、429のステータスコードが返されます。

  • 「許可されたパーティションの数を超えています」というエラーが表示されるのはなぜですか?

    テナンシーの制限を増やすには、Oracleストリーミングサービスにお問い合わせください。

    価格と請求

  • OCIストリーミングの価格設定はどうされていますか?

    OCIストリーミングは、シンプルな従量課金制を採用しています。事前の費用や最低料金はなく、使用したリソースに対してのみお支払いただきます。

    • GET / PUTリクエストの価格(データ転送のギガバイト)

    OCIストリーミングの実際の価格については、価格ガイドを参照してください。

    データプロデューサーが毎秒500レコードを集計し、各レコードが2kBであるシナリオを考えてみましょう。お客様は、データの2倍の速度でデータを出力/取得したいと思っています。また、お客様はこのデータを7日間保存したいと思っています。

    1日あたりの価格計算(例として)

    各レコードサイズ = 4kB(4kB未満のレコードの場合は4kBに切り上げ)

    • このシナリオでは、1日あたりに生成されるデータの合計量 = 500 *4 *24 *60 *60 kB = 172.8 GB
    • 取得したデータの総量 = Produceの2倍 = 2 *172.8GB = 345.6GB
    • 1日あたりのリクエスト出力 = $172.8 *$xx = $A
    • 1日あたりのリクエスト出力価格 = $345.6 *$xx = $A
    • データストレージコスト= $172.8 *24 *7 *$yy = $C
    • 1日あたりの合計請求額 = $(A + B + C)

    オプション:

    • 拡張データの保持は、デフォルトの24時間保持(1時間あたりのストレージのギガバイト)を超える追加日数によって決まるオプションのコストです。
  • OCIストリーミングの無料枠はありますか?

    OCIストリーミングには無料枠がありません。