Googleの徹底的なシステム障害への対応「SRE」の中身とは？

インターネット上でサービスを提供する企業では、いかに自社のシステム障害と向き合うかが重要です。検索エンジンやクラウド、メール、広告など、さまざまなサービスを提供しているGoogleが、自社が提唱しているシステム管理の方法論「SRE」に基づき、システム障害にどう対応しているかを実際の事例をもとに紹介しています。

SRE keeps digging to prevent problems | Google Cloud Blog
https://cloud.google.com/blog/products/management-tools/sre-keeps-digging-to-prevent-problems

SREはサイト・リライアビリティ・エンジニアリングの略で、「サイト信頼性エンジニアリング」と訳されることもあります。Googleのような大規模な企業では、他の企業ではめったに起こらないことが常に起こる可能性があり、他ではあり得ないような複雑な障害が起こり得るとのこと。そうした障害に対応するため、GoogleのSREは自社インフラが持つ多数の層に渡って障害を追跡できるよう、システムを構築することに優れていると語られています。

Google Cloud Blogでは、GoogleのSREがどんなアプローチなのかがよくわかる事例が紹介されています。Googleのトラフィックと負荷分散を担当するSREのチームが、エッジネットワークで異常な数のエラーを検出したケースでは、まず、障害の影響を軽減するため、担当チームはエラーが出ているマシンをサービスから分離。こうした分離をいち早く行えるのは、Googleがシステム全体で十分な処理能力を有し、冗長性を確保できているからであり、これはSREの重要な要素のひとつであるそうです。

チームはこうしたエラーが一過性のネットワーク異常によるものであるというノウハウを持っていたため、ネットワークを調査すると、あるサーバーラックでパケットロスが発生していることを確認。さらに調査を進めると、ルーターでBGPのルートフラッピングが発生していることがわかりました。ルートフラッピングはルーターそのものよりもマシンの障害を示唆していると判断し、チームはサーバーマシンのシステムログを参照することにしました。

ログを参照した結果、BGPでIPアドレスをアナウンスしているマシンのCPU温度が高くなっているとともに、CPU使用率が異常に高い割合となっていることが判明。隣接する他のマシンも確認しましたが、異常は検知されませんでした。

隣接するマシンでは熱暴走が確認されなかったところで、SREチームは社内のハードウェアを管理運用するチームに障害を報告し、サーバーマシンの修理を依頼。ハードウェアチームが調査した結果、ラックを支えるキャスターのひとつが破損していることがわかりました。

キャスターの破損によってラック全体が傾いてしまったため、CPU冷却用の冷却液の流れが停滞していました。その結果、CPUを正常に冷却できなくなり、CPUが熱暴走を起こしていました。

ハードウェアチームはすぐにキャスターを修理しましたが、問題はここで終わりません。「なぜ起こったのか」と「どう防止するか」を考える必要があります。ハードウェアチームは修理キットをサーバーマシンがあるすべての場所に常備し、キャスターを傷つけないようにラックを動かすプロセスを再考し、新しいラックをデータセンターに納入する際のラックの動かし方まで改善を行いました。

障害を防止する対策を徹底的に行った後、外部のフロントエンドシステムからハードウェアに至るまで、問題を隅々まで追跡したそうです。こうしたトラブルシューティングは、チーム内で明確なコミュニケーションを持ち、目標を共有し、問題の修正だけでなく、チーム全体で「将来の障害発生を防ぐこと」を意識することから生み出されているとのこと。

SREのチームは「すべての障害は未経験であるべきだ」という言葉をよく使うそうです。この例は、Googleが障害の初期症状を緩和した後に、根本的な原因を突き止め、障害が再発することを防ぐいい例であり、Googleがシステムを管理するためのSREの根底にあるものだと述べられています。