現地時間の 1月 10日 夜 （日本時間だと 1月 11日のお昼ごろ） ～ 1月 12日の夕方にかけて発生していた Dropbox の大規模障害ですが、公式 Blog （Dropbox Tech Blog） にて、今回の障害に関する詳細がアップされ、サービスの復旧と、ユーザーデータに関しては影響がなかったことが報告されました。
On Friday evening our service went down during scheduled maintenance. The service was back up and running about three hours later, with core service fully restored by 4:40 PM PT on Sunday.
For the past couple of days, we've been working around the clock to restore full access as soon as possible. Though we've shared some brief updates along the way, we owe you a detailed explanation of what happened and what we've learned.
「（現地時間の）金曜の夕方、定期メンテナンス中にサービスが落ちた。日曜日の夕方の時点で、主要なサービスは完全に復旧した。」 と報告されています。
下記の、ステータス情報によると、最初に障害が把握できてから、復旧が確認されるまでに 48時間以上かかったことがわかりますので、かなり長時間にわたる大規模な障害だったことがわかります。
ちなみに、一部で Dropbox がハッキング被害によりサービスダウンという噂が流れていましたが、こちらに関しては障害発生当初、公式に否定されています。
Dropbox site is back up! Claims of leaked user info are a hoax. The outage was caused during internal maintenance. Thanks for your patience!
— Dropbox (@Dropbox) January 11, 2014
何が起こったのか？
では今回の障害の原因は？ ということで、下記のように説明されています。
What happened?
We use thousands of databases to run Dropbox. Each database has one master and two slave machines for redundancy. In addition, we perform full and incremental data backups and store them in a separate environment.
On Friday at 5:30 PM PT, we had a planned maintenance scheduled to upgrade the OS on some of our machines. During this process, the upgrade script checks to make sure there is no active data on the machine before installing the new OS.
A subtle bug in the script caused the command to reinstall a small number of active machines. Unfortunately, some master-slave pairs were impacted which resulted in the site going down.
Your files were never at risk during the outage. These databases do not contain file data. We use them to provide some of our features (for example, photo album sharing, camera uploads, and some API features).
To restore service as fast as possible, we performed the recovery from our backups. We were able to restore most functionality within 3 hours, but the large size of some of our databases slowed recovery, and it took until 4:40 PM PT today for core service to fully return.
要点だけ訳すと、
- Dropbox では数千のデータベースを使用しており、各データベースは冗長化のため、1つのマスタに対して 2つのスレーブを持っている。またそれらの完全、及び差分バックアップを別々の環境に取っている。
- 金曜日に OS のアップデートを行うメンテナンス計画を立てていた。
- OS のアップデートを実行する前に、マシン上にアクティブなデータがないかをスクリプトがチェックする。
- このチェックスクリプトにバグがあり、何台かのアクティブなサーバに OS の再インストールコマンドが実行された。
- 運の悪いことにこれによっていくつかのマスタ、スレーブのペアに障害が発生し、サービスに接続できない状態になった。
- しかし、この障害によってユーザーのデータは危険にさらされてはいない。なぜなら、落ちたデータベースは API を提供するためのものだったから。
- 我々は全力でバックアップからデータの復元を行った。結果としてほとんどの機能を復元できた。
- ただ、データがとても巨大だったため、バックアップからの復旧にとても時間がかかってしまった。
ということで、メンテナンスに使用したチェックスクリプトのバグによるデータベース障害によるダウン。バックアップからデータを復旧させたが、データがでかくて時間がかかっちゃった。っていう話のようです。この障害によるユーザーデータへの影響はなし。
To speed up our recovery, we developed a tool that parallelizes the replay of binary logs. This enables much faster recovery from large MySQL backups. We plan to open source this tool so others can benefit from what we've learned.
で、あわせて
「今後、より高速にバックアップからの復旧を行うため、バイナリログのリプレイを並列化するツールを開発した。またこれをオープンソース化することも計画している。」
との発表もされています。
