Kibanaはダッシュボードの読み込み時間を最大25％短縮 - その背後にあるポーリング戦略を紹介

継続的なポーリングにより、KibanaのダッシュボードとDiscoverの読み込みが最大25％速くなりました。Kibanaは、定期的なチェックの合間にスリープする代わりに、HTTP接続を開いたままに維持し、準備ができたらすぐにElasticsearchのクエリ結果を配信するようになりました。HTTP/2+（9.0以降のKibanaのデフォルト）では、自動的に有効になるため、設定は不要です。HTTP/1では、Kibanaは接続プールの枯渇を防ぐために従来のポーリングに戻ります。

Kibanaがダッシュボードを読み込む際にデータを取得する方法

ダッシュボードを開くと、ほとんどのパネル（内部的には、これらを埋込と呼びます）が1つ以上のElasticsearchクエリを開始します。しかし、同期検索の単純な呼び出しと応答の代わりに、非同期検索のパワーを使います（ドキュメント）。

非同期検索では、クエリ結果が特定のHTTPリクエスト外でもElasticsearch内で利用可能な状態に保たれます。これが重要な理由を以下に挙げます。

• ネットワークの不安定性に耐性が高く、データの読み込みを安定させます
• バックグラウンド検索機能により、ユーザーは長時間実行されるダッシュボードやDiscoverセッションを待つ間も、Kibanaで他の作業を行うことができます

最初のクエリが送信された後、Kibanaは検索を監視して完了を検出し、結果のセットを取得します。

従来のポーリングがKibanaのダッシュボードのロード時間に与える影響

従来のポーリングでは、Kibanaはクエリを送信し、最初の接続を閉じてから、Elasticsearchの完了を定期的にチェックします。

Elasticsearchは、クエリ送信後に検索を完了して結果を返すまでの短い時間を設けています。もし検索がこれほど速く完了する場合、それは単純な呼び出しと応答のやり取りに相当します。しかし、長時間の検索の場合、最初の接続は切断され、Kibanaは検索の完了を定期的に確認し始めます。これはポーリングと呼ばれます。

従来のポーリングのパフォーマンス上の課題

上の図をご覧いただくと、このアプローチのパフォーマンス上の欠点がお分かりいただけるかもしれません。検索はKibanaのスリープインターバルのいずれかで終了する可能性が最も高く、そのため時間の無駄につながります。

最悪のシナリオ（検索がスリープ期間の始めに完了する場合）では、ポーリングインターバルの全期間が無駄になります。

バックオフ戦略の影響

ポーリング時にはバックオフ戦略を適用するのが標準的な方法です。これは、検索の期間が長くなるほど、ポーリングの頻度が低くなることを意味します。

しかし、これはまた、検索の期間に応じて潜在的な時間損失が比例して増加することを意味します。

ポーリング間隔がノコギリ状のレイテンシパターンを作り出す仕組み

これらの要素を合わせると、失われた時間は段階的なノコギリ状の関数となります。

ここで、ピークは最悪のシナリオ、谷は最良のシナリオを表しています。これは、従来のポーリングコストが、検索期間（およびネットワーク条件）に応じて、ゼロからポーリング間隔の全期間まで変化することを示しています。

継続的なポーリング：Kibanaが待ち時間を排除する仕組み

従来のポーリングの問題は、KibanaとElasticsearchの間にある根本的な連携不足です。理想は、Kibanaが結果が利用可能になったことを即座に認識することです。では、ほぼすべての時間をElasticsearchのチェックに費やし、待機時間をまったく設けないポーリングパターンに逆転させたらどうなるでしょうか？

長時間のポーリングとスリープ期間の廃止を組み合わせることで、結果は準備ができ次第すぐに提供されます。

HTTP/1の陳腐化

その理論は堅実なものです。では、継続的なポーリングをオンにすると、なぜこのKibana導入はそれほど陳腐化して見えるのでしょうか？

重要なのは、この導入がHTTP/1上で実行されていることです。HTTP/1では、HTTPリクエストはTCP接続に1:1でマップされます。そのため、複数の長時間にわたるポーリングリクエストがブラウザの限られた接続プールを占有し、他のリクエストがキューに溜まってしまいます。

一方、HTTP/2+では、ネットワークリクエストは多重化によってTCP接続を共有できるため、この問題は発生しません。

つまり、HTTP/2+では継続的なポーリングは利点となりますが、HTTP/1では欠点となります。

KibanaがHTTPプロトコルを検出して最適なポーリングを行う方法

HTTP/2は推奨されているプロトコルであり、Kibanaのデフォルトは9.0以降であるため、このパフォーマンス向上を実装しないのはもったいないでしょう。一方、HTTP/1のエクスペリエンスは非常に陳腐化しているため、プロトコルをまだアップグレードしていないオンプレミス導入でリスクを冒すことは許されません。答えは明確です。どのプロトコルが使用されているかを検出し、最適なポーリング戦略を適用する必要があります。

Kibanaサーバーがどのプロトコルを使用しているかを知ることは確かに可能です。しかし、そこには落とし穴があります：制限要因はブラウザの接続プールです。つまり、本当に重要なのはブラウザが何を使用しているかということです。

プロキシの関係で、これらは必ずしも同じではありません。

最適化をサーバープロトコルに基づいて行うと、2つの誤りのどちらかが起こり得ます。

1. 適用すべきでないのに継続的なポーリングを適用し、エクスペリエンスを低下させる。
2. 継続的ポーリングを適用すべき場合に適用せず、最適化の機会を逃す。

幸いなことに、最新のブラウザは PerformanceObserver を使用することで、完了したリクエストの最後のネットワークホップのプロトコルを検出する方法を提供しています。そこで、最初のクエリ送信のプロトコルを監視し、それに基づいて最適化します。

ラボでの結果：継続的ポーリングと従来のポーリングとの比較（Kibana）

継続的なポーリングを検証するために、1秒から23秒の範囲でクエリが遅延するダッシュボードを作成し、最適化を有効にした状態と有効にしていない状態での読み込み時間を測定しました。次に、継続的なポーリングが有効なダッシュボードと有効でないダッシュボードを読み込み、その結果を（賞品のかかったレースのように楽しんで）測定しました。

このパターンは、元のノコギリ型の図を踏襲しています。クエリの期間によっては、効果が小さい場合もあれば、数秒に及ぶ場合もあります。

まとめ

この最適化により、従来のポーリング方式に内在する遅延を、より効率的な継続的ポーリング方式に置き換えることに成功しました。主な課題は、HTTP/1環境でのパフォーマンス低下を防ぐために、この最適化を条件付きで実装することでした。私たちはこの課題を、ブラウザの PerformanceObserver を使って、最終ネットワークホップで使用されているプロトコルを確実に検出することで解決しました。

ラボでのテストによりこの理論が検証され、継続的なポーリングによって結果が準備でき次第すぐに得られることが示されました。平均して、これはユーザーエクスペリエンスの有意義な改善につながり、データの読み込みを最大25％高速化します。

この取り組みは、ユーザーが洞察を得るまでの時間を短縮するという私たちのコミットメントにおける、最新のステップです。KibanaをElasticsearchデータに対してより透明性の高いプロキシにすることで、私たちの影響が及ぶ範囲内でのパフォーマンスの限界を押し広げます。ぜひ今後の続報をお待ちください。

（2025年、トーマス・ナイリンクはKibanaのダッシュボードのパフォーマンスを向上させる方法と動機について優れた概要を紹介しました。これはその取り組みをアップデートしたものです。

よくあるご質問