Atlassianは、自動インシデント作成システムにデータを供給するインシデント検出プラットフォームを、Apache Kafka、Kubernetes上のApache Flink、OpenTelemetryを利用して再構築した。18か月の作業後に公開された測定結果によると、イベントがメトリクスに到達するまでの時間は40秒超から10秒未満に短縮された。一方、50%のサンプリングを使用した場合、持続的な処理能力は1日あたり約5億イベントから10億イベント超へ増加した。
このプロジェクトは、完全な成功談として提示されているわけではない。監視対象範囲にあるインシデントの再現率は約60%から上昇し、2026年6月には86%のピークに達したが、8月には64%へ低下した。また、適合率は目標水準を下回り続けたため、チームは検出器自体の品質と、計測環境を整備した製品および実験のカバレッジを分けて考えるようになった。
イベントストリームを中心に構築されたプラットフォーム
Atlassianは数百万人のテナント向けに10を超えるクラウド製品を運用しており、これらの製品はユーザーのインタラクションから毎日数十億件のイベントを生成する。イベントにはタスクの開始と結果、テナント、ユーザー、実験、HTTPステータスコードに関するデータが含まれる。プラットフォームはこのデータを利用して、次の3つの質問に迅速に答える。問題は存在するか、影響の規模はどの程度か、そしてどのチームにどの重大度で通知すべきか、である。
新しい設計では、アプリケーション内でストリーム全体を消費するのではなく、Apache Kafkaのバスでイベントをフィルタリングする。約770行のYAMLからなる購読フィルターは、コード設定の一部として保存される。その後、Apache Flink 1.20の単一アプリケーションがKubernetes上でイベントを処理し、テナントデータを付加して、OpenTelemetry経由でメトリクスを送信し、60秒間のウィンドウでインシデントの影響を集計する。
チームは集計データの保存にApache Parquetを使用し、キー・バリューにはマルチリージョンストアを利用した。Impact APIは影響を受けたユーザー数とテナント数に関する回答を提供する。AutoHOTエンジンはアラートをインシデントに変換し、重大度マトリクスを適用し、一過性のアラートを抑制したうえで、影響を毎分再評価する。
性能とコストの改善
- 仮想マシンの台数は、キュー層とキャッシュ層を含めて約90台から、4つのKubernetesコンテナへ減少した。
- 月間運用費は約2万ドルから約650ドルへ低下し、約97%の削減となった。
- データを失うことなく、約20分以内にKafkaイベントを再生することで、処理停止からの復旧が可能になった。
- 影響ダッシュボードのクエリ時間は約10秒から約1秒へ短縮された。
- 2週間にわたる並行稼働中、旧経路との一致率は99.9%に達した。
この設計では、影響を受けた一意のユーザー数を計算するため、ユーザーIDを保存する代わりにHyperLogLogを採用し、誤差は約1.5%となった。また、Kafkaの再生時に行が重複して増えないよう、ストレージキーにはidempotentなキーを使用した。チームはStatsD経由の旧メトリクス名を維持したため、移行時にSLOダッシュボードと既存の検出器を変更せずに継続できた。
なぜ性能指標だけでは不十分なのか
インシデントの結果は、データパイプラインを高速化しても、必ずしもカバレッジが向上するわけではないことを示している。9か月間に263件の重大インシデントが発生したが、監視環境を整備した実験に影響したのは117件、つまり44.5%だけだった。これらのインシデントのうち80件が検出され、同期間における重大インシデント全体に対するシステムの捕捉率はわずか30.4%だった。
適合率もアラートの種類によって異なった。システムが自動作成したSev2インシデントの適合率は会計年度中に約85%だった一方、より低重大度の早期警告の適合率は70%から79%の間で推移した。揺らぎの抑制により、却下された一過性アラートのチケットは約80%減少した。その一方で、メトリクスシステムの遅延により、データの減少がゼロとして扱われ、誤アラートの波が発生した。これには、データ量減少の検出器に最低120秒の遅延を追加することで対処した。
残された未解決の制約
最大の論理的問題は、沈黙が正常に見えてしまう可能性があることだ。データベース全体が停止すると、ページの読み込みが妨げられ、その結果、失敗イベント自体が生成されない可能性がある。また、イベントパイプラインそのものが停止すると、検出器が盲目になる可能性がある。そのためチームは、データ量の減少を検出する検出器とメトリクスの鮮度チェックを追加し、エッジの5xxエラーや合成プローブなど、独立したシグナルを組み込む計画を立てている。
チームは、インシデントの検出とその影響の測定が別々の問題であることも確認した。あるインシデントではチケットが早期に作成されたが、システムが推定した影響は約2,000ユーザーだったのに対し、実際の数は8万ユーザーを超えていた。また、Impact APIは、事前集計やキャッシュなしに読み取り時点でHyperLogLogスケッチをマージしていたため、約100人の同時ユーザーからの負荷で機能しなくなった。
さらに重要な弱点は、イベントゲートウェイ、Kafka購読、Flinkジョブが1つのリージョンで稼働している一方、意思決定エンジンは2つのリージョンでアクティブ・アクティブ方式で稼働している点である。つまり、リージョン障害が発生すると、コンピューティングは正常なままでも、検出そのものの情報源が停止する可能性がある。
certi.newsによる編集部の見解
Atlassianの経験における本質的な価値は、FlinkやKafkaを個別に選択したことではなく、バスでのフィルタリング、idempotentなキー、OpenTelemetry自体によるプラットフォーム監視、recallとcoverageの区別といったアーキテクチャ上の判断を、検証可能な運用指標に結び付けた点にある。結果は、効率改善によってコストと時間を明確に削減できる一方、計測上のギャップや、顧客向けのシグナルを生成しないインシデントを自動的に解決できるわけではないことを示している。
Atlassianは、検出器をOpenTelemetry経由で供給される時系列ストアへ移行し、Flinkパイプラインをリージョン間のアクティブ・アクティブ方式へ拡張し、Impact APIの前段に日次集計とキャッシュを追加する計画である。また、監視環境を整備した範囲内で、recallと適合率の双方を90%超にし、Sev3インシデントの検出時間のP90を90分未満にすることを目標としている。これらは将来の目標であり、公開資料によれば達成済みの結果ではない。