パフォーマンスに関する考慮事項

Foundry でストリームを作成する準備を進める際は、ストリームを定義する低遅延とスループットの要件を検討することが重要です。このページでは、ストリームのユースケースにおける低遅延とスループットの両方のパフォーマンスについて、検討すべき問いを紹介します。

低遅延

低遅延とは、ストリームのレコードが処理される速さを指します。低遅延はリアルタイムストリームを定義するパフォーマンスの中核的な要素であり、レコードがストリームで処理されてから宛先に到着するまでに期待される速さは、実際の業務に影響を及ぼすことがあります。たとえば、即座の対応が必要な航空便の遅れやサプライチェーンの問題に対して、アラートがどれだけ速く発動するかは、ストリームの低遅延によって決まります。低遅延に影響する要因は多岐にわたりますが、特に重要な考慮事項を以下に示します。

低遅延に影響する要因

• ソースはどれくらいの速さでデータを生成していますか？
  • Foundry がデータを取り込める速さは、データが生成される速さを超えることはできないため、データソースがデータを速く生成できることを確認してください。
• データがネットワーク境界を越えるのにどれくらいの時間がかかりますか？
  • Foundry にデータを取り込む際、データはネットワーク境界を越える必要があることが多く、ネットワーク設定、ファイアウォール、その他の要因によって低遅延に影響が生じることがあります。
• エンドツーエンドのパイプラインにはいくつの段階がありますか？
  • Foundry のストリーミングでは、同じコードリポジトリまたは Pipeline Builder のグラフに定義されたパイプラインの変換処理を同じ物理ハードウェア上に配置し、低遅延を自動的に最適化します。パイプラインに段階が追加されると（たとえば、複数のリポジトリや Builder パイプラインを連結した場合）、同じ最適化を実行できなくなり、低遅延に追加の影響が生じます。
• データは外部システムに送信されていますか？
  • レコードに低遅延でアクセスできるようにするには、宛先システムが低遅延でデータを処理できる必要があります。Foundry は時系列やオントロジーなどの最適化された宛先を提供していますが、データが外部システムに送信される場合、そのシステムは低遅延の要件を満たす必要があります。
• データの一貫性モデルは何ですか？
  • データの一貫性は、エンドツーエンドの低遅延に大きく影響します。exactly-once 保証（たとえば、レコードが必ずちょうど1回処理される保証）を必要とするデータでは、パイプラインの原子性を確保するためにオーバーヘッドが加わり、低遅延にも影響します。一方、パイプラインを at-least-once 保証（たとえば、各レコードが必ず1回以上処理されるものの、複数回処理される場合もある保証）で実行できる場合、システムはパイプラインを自動的に最適化して実行を高速化します。

ストリーミングパイプラインのエンドツーエンドの低遅延

標準的なストリーミングパイプラインは、次の段階を15秒未満で実行できます。

• 取り込み： 約1～2秒
• 変換： exactly-once が有効な場合（デフォルト）は約5秒、at-least-once が有効な場合は1秒
• 基盤データストアへの同期（オブジェクトストレージ同期または時系列同期）： exactly-once が有効な場合（デフォルト）は約5秒、at-least-once が有効な場合は1秒

上記のとおり、ストリーミングパイプラインのエンドツーエンドの低遅延に影響する主要な要因は3つあります。

1. トランスフォームの数に基づくパイプラインの複雑さ。
2. パイプラインが at-least-once モードと exactly-once モードのどちらで実行されているかに基づく一貫性モデル。
3. トランスフォームにおける時間ベースのウィンドウと集計。たとえば、30秒のウィンドウで集計するよう指定した場合、集計によってデータの低遅延には暗黙的に30秒が追加されます。

スループット

スループットとは、一定の時間内に処理できるレコードの量です。低遅延パイプラインのパフォーマンスを測定するうえで、スループットは低遅延と同じくらい重要であることが多く、特に重要な考慮事項を以下に示します。

• ソースは単位時間あたりに何件のレコードを生成していますか？
  • Foundry のストリーミング機能は、そのままで高いスループットを備えています。ただし、ソースストリームの生成速度が極めて高い場合は、次の対応ができます。
    • ストリームで使用するパーティションの数を増やして、より大量のデータに対応します。
    • 既存のストリームの種類を「HIGH THROUGHPUT」に設定します。この設定により、ソースが1回のバッチで送信するレコードの数が増えます。ストリームの「Total Lag」メトリクスが0より大きい場合に推奨されます。この設定は、低遅延を直接犠牲にしてスループットを向上させるため、設定を進める前にストリームの「Total Throughput」メトリクスを確認し、「HIGH THROUGHPUT」の適用がストリームに適していることを確認してください。
• パイプラインの処理部分は、CPU をどの程度使用しますか？
  • スループットは、処理の遅れによって制限されることがよくあります。処理のスループットを向上させる方法は数多くあり、そのほとんどは処理クラスターのサイズを拡張することで対応できます。
• 宛先システムはどれくらいの速さでレコードを受信できますか？
  • ストリームの宛先システムがレコードの生成速度に追いつく速さで受信できない場合、宛先システムも遅れの原因となります。これによりバックプレッシャー ↗が発生し、スループットが低下して低遅延にも影響が生じることがあります。Foundry のストリーミング製品は、極めて高いスループットに対応できるよう最適化され、設計されています。ただし、独自の宛先に書き込むようにストリーミングパイプラインを設定する場合は、生成されるレコードの量に宛先が対応できることを確認してください。

高度な考慮事項

• データパイプラインを深く理解しているユーザーにとって、ネットワーク帯域幅もストリームのパフォーマンスのボトルネックとなる可能性がある要因です。ネットワーク帯域幅が最適でない場合の兆候には、ラグが0ではないこと、期待されるスループットを下回ること、レコードがドロップされることがあります。これらの症状を緩和するには、ストリームにデータ圧縮を適用できます。ただし、適用する前に次の点に留意してください。
  • データ圧縮は、繰り返しの文字列を含む大量のストリームで最も効果を発揮します。
  • 低遅延の改善を主に重視する少量のストリームでは、データ圧縮を有効にすると、最適でない条件でのデータ圧縮に時間がかかるため（たとえば、一意の文字列が少量しかない場合）、低遅延がさらに悪化します。