【ITニュース解説】Latency Numbers Every Data Streaming Engineer Should Know

システムエンジニアを目指す上で、データ処理の遅延時間である「レイテンシ」を理解することは非常に重要である。これは単なる抽象的な概念ではなく、システムが実際にどのように動作するかを決定する物理的な現実なのだ。有名な「プログラマが知るべきレイテンシの数値」が、L1キャッシュへのアクセスが数ナノ秒であるのに対し、ディスクシークが10ミリ秒かかるという具体的な数値で我々の認識を深めたように、ストリーミングデータの世界でも、それぞれの処理がどれくらいの時間を要するのかを具体的に把握する必要がある。例えば、遠隔のデータセンター間で同期レプリケーションを行うのに100ミリ秒以上かかるのは、メモリ上で1万個のイベントを処理する時間と同じくらいのコストがかかる、と理解することが、効率的なシステム設計には不可欠となる。

ストリーミングシステムのレイテンシは、その用途に応じて大きく三つのカテゴリに分けられる。一つ目は「ウルトラローレイテンシ」で、これは10ミリ秒未満の極めて短い遅延が求められる領域だ。高頻度取引や自動運転システムのようなリアルタイム制御、eスポーツのような対戦型ゲームなどがこれに該当する。このレベルの遅延を実現するには、単一のクラウド可用性ゾーン（AZ）内で全ての処理を完結させ、データ永続化のためのディスク書き込み同期（fsync）を極力行わず、場合によっては特殊なハードウェアや通信技術を用いる必要がある。人間が画面操作を「即時」と感じる閾値が約100ミリ秒であることを考えると、ウルトラローレイテンシは人間の知覚を超えた速度で、機械のために最適化されていることがわかる。

二つ目は「ローレイテンシ」で、10ミリ秒から200ミリ秒程度の遅延を指す。これは、ほとんどのインタラクティブなリアルタイムアプリケーションが目指す領域だ。ライブダッシュボード、不正検知のようなリアルタイムアラート、レコメンデーションエンジンなどのオンライン機械学習機能、チャットシステムなどが含まれる。このカテゴリでは、マイクロバッチではなくイベントごとの処理を行い、異なるAZ間でのレプリケーションも許容される。ただし、積極的なバッチ処理は控えめにし、SSDストレージの使用が一般的だ。多くの代表的なストリーミングプラットフォームがこの要件を満たすことができる。

三つ目は「レイテンシ緩和」で、200ミリ秒から数分程度の遅延が許容される場合だ。この領域では、コスト最適化と大量データ処理が主な目的となる。ニアリアルタイムのETL（データ抽出・変換・ロード）、数分ごとに更新されるビジネスインテリジェンスダッシュボード、日次レポート作成などのバッチ指向の分析、データレイクへのデータ取り込みなどが該当する。この場合、積極的なバッチ処理や、地理的に離れたリージョン間でのデータレプリケーションが可能となり、比較的安価なストレージの使用や高いデータ圧縮率を適用できるため、インフラコストを大幅に削減できる。Netflixの事例では、Kafkaにデータを保持するよりもデータレイクのIcebergに保存する方が38倍もコストを削減できたという。

レイテンシはハードウェアとネットワークの物理的な制約によって大きく左右される。ストレージに関しては、メモリへのアクセスが約100ナノ秒であるのに対し、SSDの読み取りは150マイクロ秒、HDDのシークは5〜20ミリ秒と、その速度は大幅に異なる。特に、データ永続化のためのディスク書き込み同期（fsync）は、HDDの場合5〜20ミリ秒かかり、ウルトラローレイテンシの予算全体を消費してしまう可能性があるため、慎重な選択が求められる。ネットワークに関しても、データが光ファイバー内を移動する速度が物理的な上限となるため、同一データセンター内であれば1ミリ秒未満で済むが、異なるクラウド可用性ゾーン間では1〜4ミリ秒、異なるリージョン間では30〜200ミリ秒以上もの往復時間（RTT）がかかる。この物理的な制約は、いかなる分散ストリーミングシステムにおいても避けることのできない基盤となる。

ストリーミングプラットフォーム、特にApache Kafkaのようなシステムでは、設定がレイテンシに直接影響する。プロデューサーがメッセージを送信する際の確認レベル（acks設定）は、データがどれだけのレプリカに書き込まれたことを待つかによって、数ミリ秒から数十ミリ秒の遅延差を生む。また、メッセージをまとめて送信するまでの待機時間（linger.ms）を設定することで、意図的にレイテンシを増やしてスループットを向上させるトレードオフも存在する。コンシューマーがブローカーからデータを取り出す頻度も重要で、ポーリング間隔の誤設定はエンドツーエンドの遅延を大幅に悪化させる可能性がある。さらに、Apache IcebergやDelta Lakeといったデータレイクのテーブルフォーマットでは、データが可視化されるまでの遅延は、どれくらいの頻度で新しいデータのコミットを行うかというコミット間隔によって決まる。例えば、10分間隔でコミットすれば、平均5分の遅延が発生することになる。

エンドツーエンドのレイテンシは、プロデューサーからコンシューマー、そして最終的な処理が完了するまでの全行程で発生する遅延の合計だ。この遅延を評価する際には、平均値だけでなく、P50（中央値）、P95（95パーセンタイルの値）、P99（99パーセンタイルの値）といったパーセンタイル値を追跡することが非常に重要となる。平均値が良好でも、P99の値が極端に高い場合、一部のユーザーや処理では非常に大きな遅延が発生しており、真の意味でのリアルタイムシステムとは言えないからだ。システムの故障シナリオ、例えばブローカーのフェイルオーバーやJavaのガベージコレクション（GC）による一時停止、ネットワーク分断なども、レイテンシに大きな影響を与える。

ストリーミングシステムの設計において、同期処理と非同期処理のどちらを選ぶかは、耐久性とレイテンシの間での根本的なトレードオフとなる。同期レプリケーションは、データが複数のノードに書き込まれるまでプロデューサーを待機させるため、データ損失のリスクは低いが、その分レイテンシは高くなる。一方、非同期レプリケーションは、ローカルへの書き込みが完了した時点でプロデューサーに確認を返し、バックグラウンドでレプリケーションを行うため、低レイテンシを実現できるが、一時的にデータが単一ノードにしか存在しない期間が発生する。また、処理自体も、各ステップを順次待機する同期処理よりも、複数のステップを並行して実行する非同期処理の方が、全体的なレイテンシを削減できる場合が多い。ただし、非同期処理は、応答の順不同や部分的な障害への対応がより複雑になる。

最後に、レイテンシは単なる技術的な指標ではなく、システムを設計し、予算を組み、エンジニアリングを行う対象となる「機能」そのものだと理解すべきだ。物理法則は動かせない限界を設定する。例えば、大陸を横断するデータ転送は80ミリ秒未満では不可能である。低レイテンシを実現するには高いコストがかかり、その価値に見合うかどうかを常に検討する必要がある。そして、平均値ではなくパーセンタイルでレイテンシを監視し、それぞれのミリ秒がスループットや耐久性との間のトレードオフであることを認識することが重要だ。目標は、最速のシステムを構築することではなく、それぞれのビジネス要件とレイテンシ予算に最適なシステムを構築することにある。これらの数値を理解することで、あなたは要求された要件が物理的に可能か、経済的に妥当か、そして最終的にあなたのストリーミングアーキテクチャに最も適しているかを自信を持って判断できるようになるだろう。そして、「リアルタイム」という言葉の真の意味を理解し、実際に必要なタイミングでデータを配信できるシステムを設計できるようになるのだ。