• F5 は、前日から1社の顧客に影響していた Distributed Cloud Global Log Receiver の機能低下を9月6日に解消した
  • 顧客トラフィックと Distributed Cloud Console のサービスは稼働を継続した一方、影響を受けたログの配信が遅れたのか、ログが失われたのか、後から取得可能になったのかを F5 は明らかにしていない

事実

F5 は、Distributed Cloud Global Log Receiver に影響する障害を9月6日の07:54 UTC に解消した。同社は9月5日から、サービスの機能低下に関する報告を調査していた。

F5 は、影響は1社の顧客に限られ、その顧客には直接連絡したと説明した。また、顧客トラフィックに影響はなく、Distributed Cloud Console のサービスは稼働を継続したとしている。Global Log Receiver はログデータの受信に使われるため、報告された問題はログ配信に関するもので、アプリケーショントラフィックそのものの問題ではなかった。

第三者の稼働状況追跡サービスは、検知から解消までを約12時間50分と記録した。この時間は障害を監視していた期間を示すもので、顧客トラフィックがその間ずっと利用できなかったことを意味しない。

分析

影響を受けた顧客にとって、問題はアプリケーショントラフィックを F5 経由で流すことではなかった。問題は、そのトラフィックの周辺で何が起きているかを把握・調査するためのログの受信に支障が出たことだった。アプリケーションは利用可能なままでも、セキュリティ・運用チームが使う情報には支障が生じ得る。

したがって、復旧は Global Log Receiver を再稼働させるだけでは終わらない。顧客は、障害中に生成されたログがどうなったのかも把握する必要がある。ログが遅れて届いたのか、配信されずに欠落したのか、サービス復旧後に利用可能になったのかという点だ。F5 の稼働状況に関する更新にはその詳細がないため、ログデータが恒久的に失われたとは確認できない。

BTW の読者にとって、トラフィックの稼働状況だけではこの障害を捉えられなかった。サービスを利用するチームは、こうした記録をセキュリティ調査や運用確認に使う場合、ログ配信を別に監視する必要がある。

今後の注目点

障害中に生成されたログの配信が遅れたのか、ログが欠落したのか、サービス復旧後に取得できるようになったのかを F5 が説明するか、また根本原因を公表するかに注目したい。Global Log Receiver に影響する機能低下が再発すれば、今回が1社の顧客に限られた単発の障害だったのか、繰り返されるサービス上の問題なのかを判断する材料にもなる。