GitHubが1月28日のサービス障害の詳細を公開。停電により内部のChatOpsシステムも落ちて初期対応が困難に。Redisクラスタの復旧に時間

2016年2月4日

GitHubは、1月28日に起きたサービス障害の詳細を報告した「January 28th Incident Report · GitHub」を公開しました。

January 28th Incident Report · GitHub

報告では、サービス障害はGitHub社内のChatOpsシステムも巻き込んで初期対応に時間がかかってしまったこと、一時的な停電がRedisクラスタの障害を引き起こしたため、その究明と復旧が作業の主な部分だったことなどが説明されています。

報告の要点をまとめました。

内部のChatOpsシステムも障害に

GitHubのサービス障害は、すでに報告されているように、自社データセンターにおける一時的な停電が最初の原因でした。

At 00:23am UTC on Thursday, January 28th, 2016 (4:23pm PST, Wednesday, January 27th) our primary data center experienced a brief disruption in the systems that supply power to our servers and equipment.

協定世界時2016年1月28日木曜日0時23分(日本時間午前9時23分)、主データセンターのサーバや機器への供給電源が一時的に停電した。

これによってデータセンターの内25%を上回るサーバといくつかのネットワーク機器がリブート。ロードバランサーやフロントエンドサーバは影響を受けなかったものの、リクエストを受け付けるサービスを提供しているサーバが動作不良となりHTTP 503を返すようになります。

Our early response to the event was complicated by the fact that many of our ChatOps systems were on servers that had rebooted.

障害の初期対応を困難にしたのは、ChatOpsシステム(訳注:チャットによってシステム運用の自動化を行うシステム)用サーバの多くがリブートされてしまったことだ。

ChatOpsサーバの冗長化はされていたものの、それでも障害の影響を受けて対応初期の混乱や遅延の原因となってしまったとしています。

One of the biggest customer-facing effects of this delay was that status.github.com wasn't set to status red until 00:32am UTC, eight minutes after the site became inaccessible.

この遅れによってもっとも影響を受けたお客様対応の1つがstatus.github.comで、状態報告が0時32分までレッドにならなかった。GitHubがアクセス不能になってから8分かかってしまった。

これについては今後改善をしていくとのこと。

なぜサービスが止まったのか、調査を開始

GitHubは少し前にDDoSアタックを受けたことがあったため、DDoSアタックが障害の原因となっていないかの調査を開始。

DDoSアタックが原因でないことが判明したため、調査チームはアラートを手がかりに関連する障害の原因追及に入ります。

The inability to reach all members of several Redis clusters led us to investigate uptime for devices across the facility. We discovered that some servers were reporting uptime of several minutes, but our network equipment was reporting uptimes that revealed they had not rebooted.

まず、接続できなくなったいくつかのRedisクラスタの全サーバのuptimeを調べたところ、uptimeが数分のサーバがいくつかあることを発見。一方でネットワーク機器のuptimeは再起動されていないことを示していた。

Using this, we determined that all of the offline servers shared the same hardware class, and the ones that rebooted without issue were a different hardware class.

これを手がかりに、オフラインになっているサーバは同じハードウェア系統に収まっており、リブートしたけれども問題が発生していないサーバは別のハードウェア系統にあることを把握した。

The affected servers spanned many racks and rows in our data center, which resulted in several clusters experiencing reboots of all of their member servers, despite the clusters' members being distributed across different racks.

障害の影響を受けたサーバはデータセンター内の多くのラックに広がっていた。これにより、クラスタのメンバサーバーは異なるラックに分散しているにもかかわらず、クラスタ内のメンバサーバのリブートにつながったのだ。

こうして障害の原因を調査していく中で、ようやく復旧方法についての見通しが立ってきます。

復旧作業開始

We needed to repair our servers that were not booting, and we needed to get our Redis clusters back up to allow our application processes to restart. Remote access console screenshots from the failed hardware showed boot failures because the physical drives were no longer recognized.

復旧には、ブートしていないサーバの修復と、アプリケーションプロセスが再スタートできるようにRedisクラスタを元に戻さなければならなかった。障害を起こしたハードウェアのリモートアクセスコンソールのスクリーンショットは、物理デバイスが認識されていないためブートが失敗していたことが分かった。

復旧チームはフロア電源を引き直してサーバを稼働状態に戻し、別の復旧チームはハードウェアを入れ替えてRedisクラスタを再構築。しかしこれらの作業は障害でオフライン状態のシステムに依存していたなどの理由によって容易ではなかったとのこと。

ようやくRedisクラスが復旧。

Once the Redis cluster data was restored onto standby equipment, we were able to bring the Redis-server processes back online. Internal checks showed application processes recovering, and a healthy response from the application servers allowed our HAProxy load balancers to return these servers to the backend server pool.

Redisクラスタのデータがスタンバイ用機器にリストアされ、Redisサーバプロセスをオンラインに戻すことができた。内部チェックによりアプリケーションプロセスが復旧したことが示され、アプリケーションサーバからの適切なレスポンスが帰ってきたことにより、HAProxyロードバランサーはバックエンドサーバプールからのレスポンスを返せるようになった。

この時点でGitHubのメンテナンスページが削除され、ステータスがイエローに復帰。障害発生からここまで、2時間6分が経過していました。

その後、正常動作をさらに確認し、データが失われていないことを確認した上で安全にサービスが復旧したことが確認されました。

今後の対応

GitHubはこうした障害によってGitHub内部の複雑なシステムによる挙動を学んだとしたうえで、こうした障害が起きないように対応をしていくと説明しています。

Updating our tooling to automatically open issues for the team when new firmware updates are available will force us to review the changelogs against our environment.

今回、ファームウェアのバグで電源回復後のデバイスが見えなくなるという問題があったため、ファームウェアのアップデート時にはChangelogなどをきちんとチェックすると。

We will be updating our application’s test suite to explicitly ensure that our application processes start even when certain external systems are unavailable and we are improving our circuit breakers so we can gracefully degrade functionality when these backend services are down.

また、アプリケーションのテストツールをアップデートし、外部に障害があってもきちんとプロセスがスタートすること、またバックエンドサービスが停止してしまったとしても適切に機能をデグレードできるようにすること。

Strengthening our cross-team communications would have shaved minutes off the recovery time. Predefining escalation strategies during situations that require all hands on deck would have enabled our incident coordinators to spend more time managing recovery efforts and less time navigating documentation.

そして技術面だけでなく、チーム間のコミュニケーションを強化することで復旧時間の短縮を図り、また問題が発生したときのエスカレーション手順をきちんと決めておくこと、なども対策として挙げています。

あわせて読みたい

クラウド クラウド障害 GitHub




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本