Dropboxの分散ストレージのアーキテクチャの機能

Habrahabrの読者の注意は、 昨年の 11月7日から8日にモスクワ近郊のスコルコヴォで開催されたHighLoad ++会議の段階でのVyacheslav Bakhmutovのスピーチのビデオのトランスクリプト（出版物の最後）で示されます 。



私の名前はBakhmutov Gloryです。Dropboxで働いています。 私はサイト信頼性エンジニア（SRE）です。 Goが大好きで、宣伝しています。 みんなでgolangshowポッドキャストを録音します。

Dropboxとは何ですか？

これは、ユーザーがファイルを保存するクラウドストレージです。 5億人のユーザーがあり、20万を超えるビジネスがあり、膨大な量のデータとトラフィック（1日あたり12億を超える新しいファイル）があります。



概念的には、アーキテクチャは2つの大きな要素です。 最初の部分はメタデータサーバーであり、ファイル、ファイル間の接続、ユーザー情報、ある種のビジネスロジックに関する情報を保存し、これらはすべてデータベースに接続されます。 2番目の大きな部分は、ユーザーデータを保存するブロックストレージです。 当初、2011年には、すべてのデータがAmazon S3に保存されていました。 2015年に、すべてのエクサバイトを自分自身にダウンロードすることができたとき、独自のクラウドストレージの作成について話しました。



マジックポケットと呼びます。 Goで書かれており、一部はRustで書かれており、Pythonでもかなり書かれています。 Magic Pocketのアーキテクチャは、クロスゾーンであり、いくつかのゾーンがあります。 アメリカでは、これらは3つのゾーンであり、Pocketで結合されます。 ヨーロッパにはポケットがありますが、アメリカ人と交差することはありません。ヨーロッパ人は自分のデータをアメリカに持ちたくないからです。 それらの間のゾーンはデータを複製します。 ゾーン内にセルがあります。 これらのセルを制御するマスターがいます。 ゾーン間に複製があります。 各セルには、このデータが保存されているサーバーを監視するボリュームマネージャーがあり、非常に大きなサーバーがあります。



各サーバーで、これはすべてバケットに結合され、バケットは1 GBです。 ユーザーから保存するデータブロックは4 MBであり、それらを操作することは非常に難しいため、データを削除、クリア、デフラグするとき、どこかでデータをスローするときにバケットを使用します。 Magic Pocketのすべてのコンポーネントについては、技術ブログで詳しく説明されていますが、それらについては説明しません。



SREの観点からアーキテクチャについて説明します。 この観点から、データの可用性とセキュリティは非常に重要です。 これは何？



可用性は複雑な概念であり、サービスごとに異なる方法で計算されますが、通常は完了したリクエストの数とリクエストの総数の比率であり、通常9、999、9999、99999で表されます。しかし、実際には災害またはこの問題をどれだけ修正するかによる問題。 どのように修正しても、本番環境で、または単にバージョンをロールバックします。

安全性とは何ですか？

安全性はどのように計算しますか？ 一部のデータを取得して、ハードドライブに保存します。 次に、それらがディスクに同期されるまで待つ必要があります。 これはばかげていますが、多くの人はこの手順を単にスキップするnosqlソリューションを使用しています。

安全性はどのように計算されますか？

AFRがあります-これは年間のディスクエラー率です。 特定のハードドライブで発生するエラー、エラーの発生頻度に関するさまざまな統計情報があります。 これらの統計に慣れることができます：







その後、データを異なるハードドライブに複製して、耐久性を向上させることができます。 RAIDを使用して、レプリカを異なるサーバーまたは異なるデータセンターに保存することができます。 そして、1バイトを失う確率と同じくらいマルコフ連鎖を考慮すると、27ナインについて何かを得ます。 エクサバイトのデータがあるDropboxスケールでも、近い将来に1バイトも失われることはありません。 ただし、これはすべて一時的なものであり、オペレーターエラー、またはコード内の論理エラーです。データはありません。

データの可用性とセキュリティを実際にどのように改善しますか？

私はそれを4つのカテゴリに分けます。これらは次のとおりです。

1. 分離;
2. 保護;
3. コントロール;
4. 自動化

自動化は非常に重要です。



絶縁が起こります：

• 物理的
• 論理的
• 操作可能。

物理的な分離。 DropboxまたはDropboxのような企業の規模では、データセンターと通信することが非常に重要です。データセンター内でのサービスの位置、サービスへのエネルギーの供給方法、およびこれらのサービスのネットワーク可用性の種類を知る必要があります。 常にバックアップする必要があるデータベースサービスを1つのラックに保持したくありません。 持っているすべてのバックアップが400 Mbpsであり、十分なチャネルがないとしましょう。 このスタックを深く掘り下げるほど、意思決定のコストは高くなり、難しくなります。 どれだけ低くなるかはあなたの決定ですが、もちろん、データベースのすべてのレプリカを1つのラックに入れるべきではありません。 エネルギーがオフになり、データベースがなくなるためです。



機器メーカーの観点から、これをすべて別の次元で見ることができます。 異なる機器メーカー、異なるファームウェア、異なるドライバーを使用することが非常に重要です。 なんで？ 機器メーカーはソリューションが信頼できると言っていますが、実際には嘘をついており、そうではありません。 まあ、少なくとも彼らは爆発しません。



このすべてに基づいて、重要なデータをインフラストラクチャのバックアップのどこかに置くだけでなく、外部インフラストラクチャにも置くことが重要です。 たとえば、Googleクラウドを使用している場合は、重要なデータをAmazonに入れ、その逆も同様です。 インフラがなくなると、どこからでもバックアップが取られるからです。



論理的な分離。 ほとんどすべての人が彼女に関するすべてを知っています。 主な問題：1つのサービスで問題が発生し始めると、他のサービスでも問題が発生し始めます。 あるサービスのコードにバグがあった場合、このバグは他のサービスに広がり始めます。 間違ったデータを取得しています。 これに対処する方法は？



弱いつながり！ しかし、ほとんど機能しません。 疎結合ではないシステムがあります。 これらは、ZooKeeperのデータベースです。 負荷がZooKeeperに送られた場合、クォーラムクラスターは低下し、その後すべてが低下しました。 同じくらいのデータベースで。 マスターに大きな負荷がかかっている場合、ほとんどの場合、クラスター全体が落ちます。

Dropboxでは何をしましたか？

これは、アーキテクチャの高レベルの図です。 2つのゾーンがあり、それらの間に非常にシンプルなインターフェイスを作成しました。 それは実際に置かれ、取得され、保管のためです。 すべてをもっと複雑にしたかったので、私たちにとっては非常に困難でした。 しかし、ゾーン内ではすべてが非常に複雑であり、ZooKeeperとデータベース、クォーラムが存在するため、これは非常に重要です。 そして、それはすべて定期的に、一度にまっすぐに落ちます。 そして、残りのゾーンをキャプチャしないように、それらの間にこのシンプルなインターフェースがあります。 1つのゾーンが落ちた場合、2番目のゾーンが機能する可能性が最も高くなります。



操作上の絶縁。 コードをさまざまなサーバーにどれだけうまく分散させても、論理的にどのように分離されていても、何か間違ったことをする人が必ずいます。 たとえば、Odnoklassnikiには問題がありました。何かが機能しないすべてのBashシェルサーバーをロールアウトし、すべてのサーバーが切断されました。 このような問題も発生します。



彼らはまた、すべてのプログラマーとシステム管理者がリラックスするためにどこかに行けば、システムは彼らが働くときよりもはるかに安定して動くだろうと冗談を言いました。 そして、本当にそうです。 フリーズ期間中、多くの企業はこの年末年始の前に凍結の練習をしているため、システムはより安定して動作します。



アクセス制御。 リリースプロセス：これらはすべて積極的にテストされ、その後、たとえば会社が使用するステージングでテストされます。 さらに、1つのゾーンに変更を分散します。 すべてが正常であることを確認したらすぐに、他の2つのゾーンに配置します。 何かが正常でない場合は、それらからデータを複製します。 これはすべてストレージです。 製品サービスは1日に1回絶えず更新しています。

保護。 データを保護するにはどうすればよいですか？

これは操作の検証です。 これは、このデータを回復する機会です。 これはテスト中です。 操作検証とは何ですか？



システムの最大のリスクはオペレーターです。

物語があります。 アポロ計画で働いていたマーガレット・ハミルトンは、テスト中のある時点で、娘が彼女のところに来てレバーを回し、システム全体が戻ってきました。 このレバーは、このアポロのナビゲーションシステムをクリアしました。 ハミルトンはNASAに目を向け、そのような問題があると言って、彼女は弁護を申し出た。 船が飛ぶ場合、この船のデータはクリアされません。 しかし、NASAは、宇宙飛行士は専門家であり、決してこのレバーを回さないと述べました。 次の飛行で、宇宙飛行士の一人が誤ってこのレバーを回し、すべてがクリアされました。 問題の明確な説明があり、このナビゲーションデータを復元できました。

同様の例がありました。JSSHというツールがあります。これは、多くのサーバーでコマンドを実行できる分散シェルです。







実際、このコマンドでは、再インストール状態のサーバーでmemcacheを実行する必要があります。つまり、サーバーは動作しなくなり、更新する必要があります。 upgrade.shスクリプトを実行する必要があります。 通常、これはすべて自動的に行われますが、手動で行う必要がある場合もあります。



問題があります。すべての引用符を実行する必要がありました。







すべて引用符がないため、すべてのmemcachにlifecycle = restart引数を設定し、すべて再起動しました。 これはサービスにあまり影響しませんでした。 オペレーターのせいではありません。何でも起こり得ます。

私たちは何をしましたか？

このような問題が発生しないように、コマンド構文（gsh）を変更しました。 ライブサービス（DB、memcache、ストレージ）で破壊的な操作を実行することは禁止されています。 つまり、データベースを停止して本番環境から削除することなく、memcacheを使用してデータベースをリロードすることは決してありません。 このような操作をすべて自動化しようとしています。







最後にこの操作に2つのスラッシュを追加しました。その後、スクリプトを示しました。そのような小さな修正により、将来このような問題を回避できました。



2番目の例。 これはSQLAlchemyです。 これは、データベースを操作するためのPythonライブラリです。 そして、更新、挿入、削除のために、whereclauseと呼ばれる引数があります。 その中で、削除したいもの、更新したいものを指定できます。 ただし、whereclauseではなく、whereを転送すると、sqlalchemyは何も言わず、単にwhereなしですべてを削除します。これは非常に大きな問題です。 ProxySQLなど、いくつかのサービスがあります。 これはMySQLのプロキシであり、多くの破壊的な操作（DROP TABLE、ALTER、whereのない更新など）を禁止できます。 また、このProxySQLでは、スマートクエリによってランダムにマスターにならないように、不明なクエリを調整し、その数を制限できます。



回復。 バックアップを作成するだけでなく、これらのバックアップが復元されることを確認することも非常に重要です。 Facebookは最近、彼らが絶えずバックアップを作成し、これらのバックアップから絶えず回復する方法について語る記事を投稿しました。 基本的に同じものがあります。

短時間のオーケストレータの例を次に示します。







1つのサーバーに最大32個のデータベースがあり、それらを常に移動しているため、データベースクローンを常に作成していることがわかります。 したがって、私たちは常にクローンを作成しています。 絶えず昇進はマスターやスレーブなどに行きます。 また、膨大な数のバックアップ。 Amazon S3でもバックアップを行います。 しかし、私たちは常に回復しています。 バックアップしたすべてのデータベースが復元できることを確認しない場合、実際にはこのバックアップはありません。

テスト中

単体テストと統合テストが有用であることは誰もが知っています。 アクセシビリティの観点から見ると、テストはMTTR（リカバリの時間）であり、本質的に0です。このバグは本番ではなく、本番前に発見され、修正されたためです。 可用性は曲がっていません。 これも非常に重要です。

制御

誰かが常に台無しにします。プログラマーかオペレーターのどちらかが何か間違ったことをします。 これは問題ではありません。 すべてを見つけて修正できる必要があります。



ストレージには膨大な数の検証者がいます。







ここにあるように、実際には5ではなく8です。 ストレージコード以外にも確認コードがあります。 内部トラフィックの25％があります-これは確認です。 最下位レベルでは、ディスクスクラバーが機能します。これは、ハードドライブからブロックを読み取り、チェックサムをチェックするだけです。 なぜこれを行うのですか？ ハードドライブが横たわっているため、SMARTは横たわっています。 メーカーがこれらのハードドライブを返さなければならないため、SMARTにエラーを検出させることは有益ではありません。 したがって、これは常にチェックする必要があります。 そして、問題が見つかるとすぐに、このデータの回復を試みます。



ゴミ検査官がいます。 何かを削除、移動、またはデータを破壊する場合、まずこのデータを特定のバスケットに入れてから、このデータを確認して本当に削除するかどうかを確認します。 たとえば、2週間保管されます。 削除されたデータのこの2週間分の容量があります。これは非常に重要であるため、それに費やします。 また、ストレージへのトラフィックの一部であり、これらの操作はKafkaに保存されます。 次に、ストレージでこれらの操作を繰り返します。 ブラックボックスとしてのストレージに目を向けて、実際に到着したトラフィックデータと記録されているトラフィックデータがあるかどうかを確認します。



データが1つのストレージから別のストレージに複製されていること、つまり、それらが相互に対応していることを常にチェックします。 データが1つのストレージにある場合、別のストレージにある必要があります。



検証者-これは、高品質で高品質の耐久性を実現する場合に非常に重要です。



また、テストしていない検証者は、本質的に何も検証しないことを知っておくことが非常に重要です。 彼らは本当にあなたが望むことをするということはできません。



したがって、災害復旧テスト（DRT）を実行することは非常に重要です。 これは何ですか これは、たとえば、他のサービスが依存する内部サービスを完全に無効にし、何かが機能していないと判断できるか、またはすべてが正常であると判断できる場合です。 迅速に対応し、修復し、すべてを復元してください。 これは非常に重要です。なぜなら、本番環境で問題をキャッチするからです。 生産は、トラフィックがまったく異なるという点でステージングとは異なります。 異なるインフラストラクチャがあります。 たとえば、ステージングでは、1つのラックに複数のサービスを配置できますが、Webサービス、データベース、ストレージなどのサービスは異なります。 そして本番環境では、まったく異なる場合があります。



データベースにWebサービスが含まれていたため、時間内にバックアップできなかったため、このような問題が発生しました。 これも監視する必要があります。



私たちの判断を証明することは非常に重要です。 つまり、何かが落ちて、それを復元する方法を知っているなら、このスクリプトを書きました。何かが落ちたら、それが本当に起こることを証明しなければなりません。 コードが変化しているため、インフラストラクチャが変化しているため、すべてが変化する可能性があります。 彼らは眠らないので、それは勤務中の人にとってもプラスで穏やかです。 彼らは夜に目を覚ますのが好きではないので、問題を抱えているかもしれません。 これは事実です、心理学者はこれを研究しました。



アテンダントが何らかの問題があることを知っている場合、彼らはこれの準備ができています。 彼らは、実際の問題が発生した場合の回復方法を知っています。 これは本番環境で定期的に行う必要があります。

自動化

最も重要なこと。 サーバーの数が線形または指数関数的に増加すると、人の数は線形に生まれません。 彼らは生まれ、研究していますが、ある程度の周期性があります。 また、サーバーの数に相当する人数を増やすことはできません。



したがって、これらの人々のために作業を行う自動化が必要です。

自動化とは何ですか？

自動化では、インフラストラクチャからメトリックを収集することが非常に重要です。 私のレポートではメトリックについては何も言いませんでした。メトリックはサービスの中心であり、これを言及する必要はありません。これはサービスの最も重要な部分だからです。 メトリックがない場合、サービスが機能しているかどうかはわかりません。 したがって、メトリックを迅速に収集することが非常に重要です。 たとえば、メトリックが1分に1回収集され、問題が1分以内にある場合、そのことはわかりません。 迅速に対応することも非常に重要です。 たとえば、1分が経過したなど、人が反応した場合、何かが起こったときに、バグがメトリックにあったという事実に何かが置かれ、アラートが表示されます。 5分間のポリシーがあります。 この時点でアラートに応答して、何かを開始する必要があります。 あなたは何かを始め、理解し始めます。実際、問題に応じて、あなたの問題は平均10〜15分で解決されます。 オートメーションを使用すると、この問題に取り組む前にこの問題に関する情報を提供するという意味で、高速化することはできますが、解決することはできません。



このようなNaoruツールがあります-偏執的な自動化です。







オートメーションはいくつかのコンポーネントで構成されています。



いくつかのアラートで構成されています。 サーバーに接続し、使用可能であることを確認する単純なPythonスクリプトにすることができます。 これは、使用するものに関係なく、NagiosまたはZabbixからのものです。 主なものは、それがすぐに来るということです。 次に、それをどうするかを理解する必要があり、診断する必要があります。 たとえば、サーバーが利用できない場合、SSH経由で接続、IPMI経由で接続を試み、応答がないか、フリーズするか、何か他のものがあれば、何らかの治療を処方する必要があります。



さらに、オートメーションを作成するときは、すべてがオペレーターを通過する必要があります。 自動化を行うというポリシーがあり、約3〜6か月でオペレーターによって解決されます。



問題に関するすべての情報を収集しました。この情報はオペレーターに漏れます。そのようなサーバーは何らかの理由で利用できず、何をする必要があるかを示し、オペレーターに確認を求められます。 オペレーターは非常に重要な知識を持っています。 彼は今、サービスに何らかの問題があることを知っています。 たとえば、彼は、このサーバーで他の何かが実行されているため再起動できないことを知っています。 したがって、単純に再起動することはできません。 そのため、オペレーターは問題に遭遇するたびに、この自動化スクリプトにいくつかの改善を加え、改善するたびに改善を行います。



大きな問題があります。これはオペレーターの怠inessです。 彼らは自動化を自動化し始めます。 ここにyesが自動的に挿入されます。







したがって、しばらくの間、yes / noではなく、「はい、これが本当に欲しい」と書きました。 別のレジスタで、これが実際にコンソールであることをランダムにチェックしました。 これは非常に重要です。



フックを持つことも重要です。 すべてが常にチェックできるわけではないからです。 フックは非常に簡単です。たとえば、ZooKeeperがサーバー上で実行されている場合、グループのすべてのメンバーが動作していることを確認する必要があります（エラーのあるスクリプト）。







これらのフックはフロー全体に配置され、アラートの後に診断プラグインなどにフックがあります。 サービス用に独自のフックを作成できます。



次は、問題の解決策です。







とても簡単です。 たとえば、このサーバーを再起動します。 パペット、シェフなどを実行する



これがナオルです。 これは事後対応型の修復です。 これにより、イベントに非常に迅速に対応し、非常に迅速に修復することができます。



オープンソースのソリューションもあります。 最も人気のあるのは、ロシア人のStackStormです。 彼らには非常に良い解決策があり、非常に人気があります。 リーマンやOpsGenieなどの独自のソリューションでこれを行うこともできます。



独自のソリューションがあります。 Facebookからは、これはFBAR（facebookの自動修復）です。 Linkedinの看護師。 彼らは閉じていますが、彼らは常にこれらの決定について話します。 たとえば、Facebookは最近、ツール全体でラック全体を移動する問題に関するレポートを作成しました。

しかし、自動化はリアクティブ（ここと現在）であるだけでなく、長期間にわたって実行する必要がある自動化でもあります。 たとえば、1万台のサーバーを更新し、それらを再起動する必要があります。 たとえば、ドライバー、カーネル、その他の操作を更新する必要があります。 これには、月、年などの長い時間がかかる場合があります。 リアクティブシステムでは、これを常に監視することはできません。



したがって、まだそのようなWheelhouseシステムがあります。



仕組みの仕組みがあります 。 次に、何があるかを説明します。







基本的に、1つのマスターを持つデータベースクラスターがあります。 Aと2つのスレーブがあります。 このマスターを置き換える必要があります。たとえば、カーネルを更新する必要があります。 それを置き換えるには、スレーブを整理し、そのマスターをデプロモートし、削除する必要があります。 Dropboxには要件があります。このような構成には、クラスターに常に2つのスレーブが必要です。 このクラスターには特定の状態があります。 HostAは運用中です。マスターであり、まだリリースされていません。2つのスレーブがありますが、この操作には3つ必要です。



これをすべて行う何らかのステートマシンがあります。







replace_loop（青い矢印）から、サーバーが運用中であり、十分なスレーブがないことがわかり、別のスレーブを選択する状態になります。 この状態になり、master'a new slaveで新しいクローンを作成する作業を開始します。 Orchestratorのどこかで始まります。お待ちしています。 作業が完了し、すべてが正常であれば、次のステップに進みます。 失敗した場合は、失敗状態に進みます。 次に、このホストの運用環境に新しいスレーブを追加し、Orchestratorでこの作業を開始し、待機してreplace_loopに戻ります。



現在、次のようなものがあります。







1つのホストがマスターであり、3つのスレーブがあります。 十分なスレーブがあるという条件を満たす。 その後、プロモート状態に進みます。







これは実際には非推奨です。 マスターをスレーブにし、ある種のスレーブマスターにする必要があるからです。 ここではすべて同じです。 Orchestratorでの作業が追加され、条件が確認されるなど、残りの手順はほぼ同じです。 その後、実稼働環境からマスターを削除し、トラフィックを削除します。 このサーバーに関係する人がサーバー上の何かを更新できるように、インストーラーでmasterを削除します。



このブロックは非常に小さいですが、より複雑なブロックに関係しています。 たとえば、スイッチのドライバが変更されているため、ラック全体を別のラックに移動する必要がある場合、ラック全体を切断してスイッチをリロードするだけです。 さまざまなサービスの状態図、それらを消す方法、上げる方法について多く説明しました。 それはすべて動作します。 数学的にも、システムが常に稼働状態にあることを証明できます。 なぜプロシージャモードではなくSTMを介してこれが行われるのですか？ たとえば、クローン作成に時間がかかる場合、クローン作成には1時間程度かかることがあるため、何か他のことが起こり、システムの状態が変化します。 状態マシンの場合、どの状態とそれにどのように応答するかを常に知っています。



現在、これを他のプロジェクトで使用しています。 データの可用性とセキュリティを高めるために使用できるこれらの4つの方法。 特定のソリューションについては話しませんでした。どの大企業でも、意思決定は全員が行うからです。 もちろん、MySQLを使用するデータベースなど、ある種の安定ブロックを使用しますが、その上にグラフストレージを台無しにしました。 レプリケーションには半同期を使用しましたが、Apache BookKeeperのような独自のレプリケーションがあり、proxdbも使用しています。 しかし、一般的に、私たちはすべて独自のソリューションを持っているので、それらはおそらくあなたのものに見えないため、それらについては言及しませんでした。 ただし、これらの方法は、オープンソースの有無にかかわらず、どのソリューションでも使用できます。 アクセシビリティを向上させるため。



それだけです、ありがとう！