Dropbox

【トラブルシューティング】大規模障害の原因および再発防止策について公開

トラブルシューティング
0 0
Read Time:1 Minute, 9 Second
Dropbox
Dropbox

Dropbox が、2014 年 1 月 10 日 18:40 頃から発生していた同社のサービスへのアクセスが行えない状態になっていた問題について、定期メンテナンス中に発生した事象であったことと技術的な問題についての詳細を発表しています。

なお、コア サービスの復旧までには約 2 日後の 2014 年 1 月 12 日 16:40 頃に復旧したとのことです。

目次






サービス ダウンについて

  • Dropbox ではサービスを提供するために何千もの DB(データ ベース)を利用しており、各 DB(データ ベース)では冗長性のためにマスターとなる 1 台と 2 台のレプリカで構成されています。
  • さらに、データのフル バックアップと増分バックアップを別の環境で行っています。
  • 今回、2014 年 1 月 10 日 17:30 頃から一部の機器の OS のアップデートを行うためのメンテナンスが計画されており、新しい OS をインストールする前にアップグレード スクリプトがアクティブなデータないことを確認するように構成されていました。
  • しかしながら、このアップグレード スクリプト内にバグが含まれていたことにより、少数のアクティブな DB(データ ベース)に対して OS のインストールが実行されてしまいました。
  • これにより、いくつかのマスターとレプリカのペアが影響を受け、サービスがダウンしました。
  • なお、これらの DB(データ ベース)は一部の機能を提供するために利用しているものであったため、アイテムのデータは含まれておらず、ユーザーのアイテムに対しての影響はありませんでした。
  • ※ フォト アルバム野共有、カメラのアップロード、一部の API 機能など
  • 今回はサービスをできるだけ早急に復旧させるためにバックアップからの復旧を行っており、ほとんどの機能が 3 時間以内に復旧させることができましたが、一部の DB(データ ベース)のサイズが大きかったために、復旧までに時間を要し、コア サービスが完全に復旧するまでに 2014 年 1 月 12 日 16:40 頃までかかりました。

再発防止策

  • Dropbox は数年間で急速に成長し、何億人物ユーザーをサポートするようになり、日常的にインフラストラクチャーのアップグレードを行っています。
  • その際には各インフラストラクチャーの本番環境をリモートで検証するスクリプトも実行しています。
  • 今回のケースは、そのスクリプト内のバグが原因で本番環境を提供するインフラストラクチャーの一部でアップグレードが実行されました。
  • 今回、スクリプトを実行する前にインフラストラクチャーがローカルで状態をチェックするレイヤーを追加したことで、重要なプロセスを実行していると認識したインフラストラクチャーは、潜在的にサービス ダウンを引き起こすような操作を拒否するようになりました。

迅速なディザスター リカバリー

  • 大規模なインフラストラクチャーを運用する場合、複数のレプリカを運用するというスタンダードな方法がサービスの冗長性を提供しますが、これらのレプリカに障害が発生した場合の選択肢はバックアップからのリストアのみとなります。
  • しかしながら、バックアップから MySQL のデータをリカバリーするために利用される標準ツールでは大規模なデータ セットを扱うには時間がかかります。
  • 今回、リカバリーを高速化するためにバイナリー ログの復元を並列化するツールを開発することで、大規模な MySQL のバックアップからのリカバリーを大幅に高速化しています。
  • なお、今後は、このツールをオープン ソース化する予定です。

Dropbox 関連記事一覧

関連リンク



Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください