Honeycomb インシデントレポート: 2026年5月4日および7日のKafkaメンテナンス

5月4日にEUインスタンスで、5月7日にUSインスタンスで、Honeycombは過去5年間で唯一の計画メンテナンスセッションを実施し、大規模な計画停止を伴いました。メンテナンスウィンドウ中、Honeycombはイベントの受付を継続していましたが、作業中は最近のデータがクエリできませんでした。EUインスタンスでは約25分、USインスタンスでは約1時間半でした。この期間中、ダッシュボードやクエリには最近のデータの欠落が表示され、トリガーやSLOは通常どおり動作しませんでした。データは失われず、ウィンドウ終了後にすべてバックフィルされました。多くの皆さまにとって、準備していたよりも悪い体験となり、心よりお詫び申し上げます。私たちが正しく対応できなかったのは、準備でした。

このメンテナンスの目的は、Honeycombのイベント取り込みの中心にある10年前のKafkaクラスタを、より信頼性が高くスケーラブルな新しいクラスタに置き換えることでした。Honeycombの歴史においてこのようなメンテナンスウィンドウが稀であるため、既存の積極的な顧客コミュニケーションのプロセスは、このようなイベントに十分対応できるように調整されていませんでした。

スケジュールの選択における目標の対立、影響範囲に関する誤解、事前にユーザーにメンテナンスを周知するための適切なコミュニケーション経路の選定に関する課題が、私たちが多くの顧客の期待を満たせなかった要因となりました。

お客様がこのメンテナンスウィンドウで体験した内容は、私たちが自らに課している基準を満たすものではありませんでした。事前通知の範囲が十分ではなく、顧客に影響する内容の説明も、多くの皆さまが実際に体験した内容に備えるには不十分でした。

影響を伴うメンテナンスウィンドウをスケジュールするのに良いタイミングはなく、利用可能な選択肢の中から最善の時間を選択しようとしました。これは一度限りのインフラ移行であり、今後このような性質の計画メンテナンスを実施する予定はありません。とはいえ、この経験を活かして、顧客コミュニケーション、事前通知、スケジュール決定に関する明確なプロセスを確立します。

このレポートでは、これらの課題を整理し、エンジニアリング計画、コミュニケーションの作成と検証、これらの変更を明確なタイムラインで伝達する新しいプロセスを含む、改善策を特定します。

タイムライン

技術的背景

Honeycombは設立から10年間、イベント取り込みパイプラインの中心コンポーネントとしてKafkaクラスタを運用してきました。フロントエンドの取り込みサービスが吸収したすべてのイベントは検証され、その後Kafkaクラスタにトピックごとに挿入されます。Honeycombは必要なセマンティクスを提供するため、Kafkaとのやり取りを厳密に制御しています。イベントが通過するアーキテクチャは、簡単に次のように説明できます:

  • 取り込みサービスは顧客から送信されたすべてのテレメトリイベントを検証し、それらをKafkaに挿入する役割を担います。メッセージのエンキューは、Honeycombがメッセージバッチの取り込み成功ステータスを返すために必要です。
  • すべてのイベントは単一のKafkaトピックに入ります。このトピックは水平スケーラビリティのために複数のパーティションに分割されます。各Honeycombチームには1つ以上の環境があり、各環境には1つ以上のデータセットが含まれます。各環境は複数のトピックパーティションに分割されてパーティション化されます。各トピックパーティションは耐障害性のために3つのアベイラビリティゾーン(AZ)にレプリケートされます。
  • Honeycombの取り込みサービスは、個々のイベントをトピックパーティションに割り当てる方法を制御し、Kafkaノードやリーダー、さらにはパーティション全体が利用できなくなってもトラフィックを安全に処理できるようにしています。
  • Honeycombのクエリサービス（「Retriever」）はKafkaと1:1の密接な結合を維持しています。クエリサービスにはKafkaパーティションと同じ数のシャードがあり、各シャードには2つのクエリノード（異なるAZに配置）があります。
  • 消費データの整合性を確保するため、各Retrieverノードはすべてのイベントを消費し、その進捗のマーカーとしてKafkaが生成したオフセットを保存します。イベントのスキップや二重消費を防ぐためのさまざまな整合性チェックが実施されています。これらのオフセットは複数の冗長領域に保存されます。
  • SLO処理、Service Maps、異常検知機能などの他のサービスも同じトピックパーティションから消費します。ただし、これらは各イベントを分析用に1回だけ処理するためにより伝統的なKafka Consumer Groupを使用し、生成されたデータは別の場所に保存します。

このアーキテクチャは、現在はレガシーインフラとなっている自己管理型のKafkaノードで支えられており、それらは最後に稼働するコンポーネントでした。それ自体は問題ではありませんが、長年使用してきたサードパーティの階層型ストレージアプローチが問題になりつつありました:

  • ハードなノード障害後の復旧時間は、最初はノードあたり約8〜12時間でしたが、48〜72時間を超えるようになりました。
    • 毎年テストしているAZ全体の障害では、2つ目のAZ障害が発生した場合、適切に復旧して劣化を軽減するまでに1週間かかるリスクがありました。
  • 古いインフラではクラスタのスケーリングが困難になりました。
  • オープンソースコミュニティの同等物が利用可能でした。

Kafkaインフラ自体にもいくつかの欠陥がありました。最大のものは、Kafkaオフセットとの密接な結合により、Kafkaトピックパーティションでクォーラムを失うと、計画外の緊急移行が必要になり、数日間読み取り不能になる可能性があることでした。これは2025年12月5日に発生し、理論上のリスクではありませんでした。

今回の移行では、Kafkaが動作するインフラをEC2からEKSに変更し、依存している階層型ストレージの実装をプロプライエタリからオープンソースに置き換え、ZooKeeperをKRaftに置き換え、手動のchef管理ノードからStrimzi管理のオープンソースノードへの移行を目指しました。

ゼロダウンタイム移行は可能ですが、それを実現するために必要な作業量と計画は、より複雑な準備期間中に数ヶ月間脆弱な状態に留まる可能性があります。移行自体にもリスクがあり、特に正確なオフセットIDに敏感なワークロードの場合、何らかの問題が発生すれば数時間のダウンタイムとデータ損失または重複につながる可能性があります。

一方で、2025年12月5日の障害に対応するために必要だった復旧メカニズムは、より高速だがユーザーに影響が目立つ移行の基盤となりました。データ損失なしで1〜2時間の取り込み遅延を許容することで、クラスタ間で書き込みを切り替え、すべてのアプリケーションでコンシューマーオフセットをリセットできるのです。

後者のアプローチの利点は、ゼロダウンタイムアプローチの9〜12ヶ月ではなく、2〜3ヶ月以内にスケーリング能力を大幅に向上させられる点です。これにより、ノード交換遅延の迅速な回復、需要増加への早期対応、および選択した移行パスに関わらずツールボックスに必要な大規模障害時の十分に練習された災害復旧パスが得られます。

ゼロダウンタイムプロセスを準備する間、信頼性とスケーリング作業を複数四半期遅らせるリスクを冒すよりも、確実に制限されたダウンタイムを取る方が安全であると判断しました。

移行

Honeycombは高可用性向けに設計されており、これまでユーザーに長期的な影響を与える計画メンテナンスを実施したことがないため、最新の正式なコミュニケーション プロセスは整備されておらず、十分に練習されていませんでした。一般的に、内部SLOは共有SLAよりもはるかに厳格であり、日常業務でダウンタイムが想定されていないため、運用計画について顧客に伝えることはほとんどありません。

過去に顧客向け運用通知の最も一般的なユースケースは、毎年実施するAZフェイルオーバーテストでした。これは実際にはダウンタイムを想定していませんが、最悪の事態に備えて計画しています。以前は、エンジニアがステータスページ通知を通じてこの作業について顧客に通知していました。これらのケースでは顧客が影響を検知しなかったため、このプロセスがどれだけ広範囲で効果的であったかについての顧客フィードバックはなく、それが定型的なアプローチになっていました。

Kafka移行を担当するチームはこの慣行を認識していました。彼らは過去のパターンに基づいてEU HoneycombインスタンスのKafka移行に関するステータスページ事前通知を作成し、Honeycomb内部でも伝達しました。

顧客とより頻繁に話をして擁護する立場にあるフィールド担当のHoneycomb従業員は、実際のダウンタイムを考慮すると、自分たちや顧客が対応するには通知が短すぎると感じました。議論の結果、皆がより徹底的に準備できるように、両方の移行を数週間延期することに合意しました。

最終的な移行日時を選ぶ際には複数の要因が影響しました:

  • エンジニアリングは、組織の大多数がオンラインで、何か問題が発生した場合のサポートが可能な日程を希望しました。最善の場合の見積もりでは影響は1時間程度でしたが、最悪の場合は最大6時間かかる可能性がありました。
  • エンジニアリングは、最近の経験をできる限り活用し、すべての訓練や練習で得た情報の劣化を避けるため、移行をできるだけ近接した日程で実施したいと考えました。
  • 取り込みが長時間遅延するため、顧客のSLOやトリガーアラートに影響が出ます。一部のアラートは「ハートビート」（システムに入るデータを監視するもの）として発報し、一部は1〜2時間以上のウィンドウを持つもの（例: 顧客が実行する1日の支出急増に関するアラートなど）は継続して動作する可能性があるため、顧客が自システムのアクティブな監視を必要とする可能性がありました。顧客のエンジニアリングチームは、ピークトラフィック時間外で、従業員の平日業務時間内にこれを処理することを好むだろうと考え、顧客の取り込みデータでピークトラフィック仮定を検証することで、各クラスタの顧客の大多数に適合する時間を選択しました。
  • ほとんどの顧客は24時間365日稼働するビジネスを運営しているため、計画停止に理想的な時間はありません。

議論の結果、EUクラスタには5月4日（一部の国で祝日）が選ばれました。これにより、ほとんどの顧客のビジネスに大きな影響を与えたり夜中に起こしたりすることなく、日中の移行が可能になりました。

USクラスタ移行にはそのような日程がなく、次の祝日は5月25日で、安心できるほど先ではありませんでした。内部の妥協として5月7日に移行を実施し、NYSEとNasdaqの取引時間後に時間をずらすことで、多くの顧客のピークタイム後でありながら、多くの顧客にとって業務時間内または少なくとも日中になるようにしました。

すべてのステークホルダーが提起した優先事項を満たす時間は特定できませんでしたが、選択されたウィンドウは重複する制約を考慮した「最も悪いわけではない」選択肢に見えました。

移行は技術的には計画どおりに進行しました。EUでの取り込みデータのクエリ可能になるまでの遅延は25分に制限され、USでは約1時間30分に制限され、異常なデータ損失は検出されず、移行はAWS us-east-1の熱イベントを回避するのにちょうど間に合うタイミングで完了しました。

コミュニケーション

振り返ってみると、このメンテナンスイベントについて十分でタイムリーな顧客コミュニケーションに失敗したことは明らかです。複数の顧客が影響を受けて驚き、動揺したというフィードバックを受け取りました。

イベントの事前通知はまずステータスページで共有されました。ステータスページには購読メカニズムがありますが、これは任意であり、顧客はこれらの通知を受け取るために事前にサインアップする必要があります。

提案された移行時間に応じて顧客の誤検知アラームがいくつ発報し、本物のアラームがいくつ発報しなくなるかを評価する内部影響分析の後、顧客成功、サポート、エンジニアリングの担当者による協力で追加のコミュニケーションが再作成され、組織内の他の人々によってレビューされました。

送付したコミュニケーションには次のような影響の説明が含まれていました。「イベント取り込みは中断なく継続します。Honeycombはメンテナンスウィンドウ中もデータを継続して受け付けます。ただし、切り替え期間中に表示されるデータにギャップが生じる可能性があります。これは想定内です。すべてのデータはメンテナンスウィンドウ終了後約3時間以内にバックフィルされ、完全に表示されます。」さらに、イベント欠落を監視するトリガーが発報すること、特定の値を監視するものは発報しないこと、その他の機能に遅延が生じる可能性があることを警告しました。

この影響リストは、当時Honeycomb内で把握していた内容を反映している点で重要であり、重要なことに、「取り込み」の意味と想定される遅延の曖昧さから、2つの大きく異なる解釈が生じました:

  1. システム設計に近く、過去数週間に実施した移行プロセスに精通しているHoneycomb従業員は、この影響を「取り込みは継続するが、すべてのインデックス作成は一時停止され、その後追いつく」「データがクエリ可能になるまでの遅延は最大3時間程度になる可能性がある」と理解しました。
  2. 他の人々はこれを「3時間の期間にわたってデータに何らかのラグが生じる」、つまり例えばデータが一貫して10分遅れるが、数時間続く、という意味だと解釈しました。

最初の解釈の方が技術的には正確で影響の深刻度もはるかに高かったですが、後者の解釈が、どのコミュニケーション経路を選択するかや、フィールドサイドで顧客の準備にどれだけ計画を立てるかに影響を与えました。

最終的に、メールコミュニケーションを担当する組織の一部に連絡してメッセージを送信してもらいました。過去の経験から、広範囲のメール送信がスパムトラップを引き起こす可能性があるため、配信可能性が高い顧客メールのリストにフィルタリングする対策を講じました。フィルタは「過去90日以内にアクティブだったチームオーナー」に絞られましたが、実際には少なすぎました。Honeycombのパワーユーザーすべてがチームオーナーではなく、後で判明したところ、メール選択メカニズムではすべての関連ユーザーが可視化されていませんでした。

共有チャットチャネルなどの代替手段も検討されましたが、過去にメンテナンス以外の目的で使用される傾向があったため採用されませんでした。移行スケジュールがほとんどのチームが担当者と会う前に進んでしまったため、対面で伝える時間が取れたチームは少なく、それでも影響の過小評価により、最初から追加対策はほとんど計画されていませんでした。

EU移行は十分に早く完了し、影響を受けた顧客も少なく、苦情や質問が移行中に寄せられることはなく、準備とスケジューリングが適切だったという認識を強めました。しかしUSクラスタの移行では、私たちが的外れだったという直接的なフィードバックがありました。改めて、この件で顧客に影響を与えたことをお詫び申し上げます。

分析

事後分析から3つのテーマが浮かび上がりました:

  • スケジューリングの課題
  • コミュニケーションの課題
  • 影響を伴うメンテナンスへの備え

スケジューリングの課題

移行の時間と重要性のトレードオフを考慮し、移行はメンテナンスイベントの数ヶ月前から計画されていました。これは成長という点で戦略的ロードマップの重要な部分となっていました。しかし、メンテナンスイベントに関するコミュニケーションのプロセスが欠如していたため、顧客対応チームメンバーは、コミュニケーション調整のためにこれらの計画に体系的に関与することは、移行直前までありませんでした。

顧客対応チームメンバーとエンジニアが調整を始めた際、（社内および顧客との）追加の調整時間が必要であることがわかりました。しかし、ローンチ、運用およびリスク管理の懸念、成長のためのスケーリングニーズなど、競合する予定されたイベントにより、待つことは現実的ではありませんでした。

その時点で2つの大きな緊張点が生じました:

  1. 最悪の結果を最小限に抑え、顧客が自システムを何らかのフォールバックメカニズムで監視できるように、顧客が近くにいて積極的に対応できる方法で移行を実施する必要性。
  2. 業務時間中（24時間365日のアラートとインシデントサポート付き）にHoneycombを必要とする顧客への影響を最小限に抑える方法で移行を実施する必要性。

この妥協案は、EUでは祝日の日中移行を可能にし、うまく機能しました。EUクラスタは規模も小さく、主にEU拠点の顧客を含み、USクラスタの所要時間の1/3で移行が完了しました。

より長く存在するUS環境にはそのような妥協案は存在せず、ユーザー基盤も大きく、APACやEMEAを含む世界中に広く分散しています。

技術的ロードマップの今後数年間、影響を伴うメンテナンスを実施する必要はないと予想しています。

しかし、将来的に顧客に影響を及ぼす可能性のあるメンテナンスイベントを実施する場合、次の2つが必要であることは明らかです:

  • 影響を受けるすべての人に適切にコミュニケーションし、回避策を提供するためには、はるかに長い事前通知が必要です。
  • 許容可能または理想的な時間帯に関する意思決定支援と、回避策の提供またはサポート。

コミュニケーションの課題

率直に言って、皆さまに十分な事前通知で十分な人数に連絡できず、送った通知の影響の記述も不正確でした。

これらのイベントを調査する中で、次の要素に注目しました:

  • 運用、請求/トランザクション、マーケティングの起源が混在する、所有権と目的が異なる3つのメールシステム。
  • 目的が混在する共有チャットチャネル（エンタープライズ顧客の70%）。
  • 障害時に使用され、購読をサポートし、エンジニアが制御するステータスページ。
  • すべてのエンタープライズ顧客がアカウントチームとのコミュニケーションを同じ方法で好むわけではなく、定期的な週次または月次のリズムを好むチームもあれば、より非同期で対応するチームもあります。
  • 顧客から連絡を受けるサポートエンジニアとそのポータル。サポートエンジニアはエンジニアリングとフィールドチームの間のやり取りに最適なグループと見なされています。ただし、Honeycombから顧客へのコミュニケーションチャネルは一切所有していません。

最終的に、この種のメンテナンスに関する確立された手順がない中で、さまざまな目的で使用され、所有者が散在する断片化されたツールと所有者のセットにより、十分だと考えたコミュニケーションを即興で作成せざるを得ませんでした。しかし、顧客からのフィードバックで聞いたように、十分に広範ではなく、多様ではなく、明確ではなく、事前でもありませんでした。

影響を伴うメンテナンスへの備え

Honeycombの歴史上過去10年間にこのような影響を伴うメンテナンスを実施した必要が一度もなく、リスクなしにメンテナンスを延期することもできなかったため、Honeycomb内の関係者は早い段階で適切なプロセスがないことが明らかでした。この調査の包括的なテーマは、時間的プレッシャーの下で要件をその都度把握していくことへの対応です。

この調査で特定された課題は、将来に向けて明確化とフォローアップが必要と思われます:

  • 影響を伴うイベントや安定性に関する今後のニーズについての認識を維持すること。
  • 組織内でのメンテナンスの事前通知に関する要件を明確にすること。
  • メンテナンスの事前通知に使用するメカニズムを事前に定義すること。
  • コミュニケーション ツールとチャネルの増殖と断片化、所有権の散在により、関与する人やその知識に基づいて時間の経過とともに不整合が生じる可能性があること。
  • 事前通知の作成と公開には組織のすべての部門からの部門横断的なサポートが必要であり、全体的な成果（インシデントコマンド時のような一時的なものであっても）に対する明確なリードが必要です。
  • このようなメンテナンスのスケジュールを決定する際の目標の対立はまだ完全に解決されておらず、事前のガイドラインが役立つでしょう。
  • データ欠落による無意味で対応不能なアラートの発報を防ぐため、メンテナンスウィンドウ中にアラームをサイレンスできるようにすべきです。

今後このような計画を使用する必要はないと予想していますが、最初にプロトコルを確立することによる利点はあります。このインシデントで表面化した部門間のコミュニケーションギャップは、対処するためのさらなる努力が必要です。

今後のプロトコル

このレポートで明らかになった分析とイベントに沿って、将来的にこのような影響を伴うメンテナンスを適切にサポートするためのプロトコルと対応するランブックを確立しました。今後このようなメンテナンスを計画していないとしてもです。詳細はこのレポートの範囲外ですが、いくつかの主要な要素をここで提供します。

  • 内部調整のためのより長いタイムライン。プロジェクトには、エンジニアリングと他の内部チームの間の通知時間の増加が必要です。これにより、影響を適切に分析し、回避策を設計し、効果的なコミュニケーションと準備を実施し、顧客にも同じことを行うためのより多くの時間を与えることができます。
  • より明確な内部説明責任とサポート。コミュニケーションとスケジューリングの両方について、曖昧さを排除し、驚きのリスクを低減するための明確な所有権構造を確立しました。また、影響のより正確な理解を確保するため、さまざまな部門へのより早期の部門横断的な関与も計画しています。
  • 顧客が懸念を提起するためのより多くの時間。確立したガイドラインは、早期の直接コミュニケーションと早期警告のための余地を設け、フィードバックを収集して回避策とスケジューリングに組み込むことを可能にします。
  • 提供される回避策。メンテナンスの影響を最小限に抑える、または適切に管理するための有用な回避策を、私たち自身とユーザーの両方に提供することを期待しています。
  • より広範で明確なコミュニケーション。メンテナンス通知に使用する特定の所有者、ステークホルダー、チャネルを持つより広範なコミュニケーションチャネルを特定しました。メッセージングとその有効性の検証に関するガイダンスが整備され、今後は明確な行動喚起を期待しています。

ほとんどの計画は現実と出会うと不完全ですが、以前に概説した構造は、必要とされる不確実性と即興の量を減らし、遭遇する可能性のある驚異に対処するためのバッファスペースを増やすことで役立つはずだと考えています。

この計画を必要としないことを願っていますが、災害復旧訓練やその他の緊急時対応策と同様に、それらを準備しておくことで、Honeycombはより信頼できるパートナーとなるでしょう。