Google ドライブサービスの設計: 毎日数千万のアクティブユーザー向けのクラウドストレージサービスを作成します。

この記事は最初に公式アカウントで公開されました: さらなる AI (power_ai)、注目を歓迎します、プログラミングと AI 乾物は間に合うように配達されます!

Google Drive、Dropbox、Microsoft OneDrive、Apple iCloud などのクラウドストレージサービスは、近年非常に人気が高まっています。この章では、Google ドライブを設計するように求められます。

設計に入る前に、Google ドライブについて少し理解してみましょう。Google ドライブは、ドキュメント、写真、ビデオ、その他のファイルをクラウドに保存するのに役立つファイルストレージおよび同期サービスです。どのコンピュータ、スマートフォン、タブレットからでもファイルにアクセスできます。これらのファイルは、友人、家族、同僚と簡単に共有できます[1]。図 15-1 と図 15-2 は、それぞれブラウザとモバイルアプリで Google ドライブがどのように見えるかを示しています。

画像-20230525205244319

画像-20230525205255735

ステップ 1 - 問題を理解し、設計の範囲を決定する

Google ドライブの設計は大規模なプロジェクトであるため、質問をしてプロジェクトを絞り込むことが重要です。

候補者: 最も重要な機能は何ですか?
インタビュアー: ファイルのアップロードとダウンロード、ファイルの同期、通知。

候補者: これはモバイルアプリですか、Web アプリですか、あるいはその両方ですか?
インタビュアー: 両方です。

候補者: サポートされているファイル形式は何ですか?
インタビュアー: あらゆる種類の文書です。

候補者: ファイルを暗号化する必要がありますか?
インタビュアー: はい、ストレージ内のファイルは暗号化する必要があります。

候補者: ファイルサイズの制限はありますか?
インタビュアー: はい、ファイルは 10GB 以下でなければなりません。

候補者: この製品には何人のユーザーがいますか?
インタビュアー: 毎日 1,000 万人のアクティブユーザー。

この章では、次の機能に焦点を当てます。

追加ファイル。ファイルを追加する最も簡単な方法は、ファイルを Google ドライブにドラッグアンドドロップすることです。
ダウンロードファイル。
複数のデバイス間でファイルを同期します。1 つのデバイスにファイルが追加されると、そのファイルは他のデバイスに自動的に同期されます。
ファイルの履歴バージョンを表示します。
友人、家族、同僚とファイルを共有します。
ファイルが編集、削除、または共有されたときに通知を送信します。

この章で説明されていない機能には次のようなものがあります。

Google ドキュメントでの編集と共同作業。Google ドキュメントでは、複数の人が同じ文書を同時に編集できます。これは私たちの設計の範囲を超えています。

要件を明確にすることに加えて、非機能要件を理解することも非常に重要です。

信頼性。ストレージシステムにとって、信頼性は非常に重要です。データの損失は容認できません。
同期速度が速い。ファイルの同期に時間がかかりすぎると、ユーザーはイライラして製品を放棄してしまいます。
帯域幅の使用量。製品が不必要なネットワーク帯域幅を大量に消費する場合、特にモバイルデータプランを契約している場合、ユーザーは不満を抱くでしょう。
スケーラビリティ。システムは高トラフィックを処理できる必要があります。
高可用性。一部のサーバーがオフラインになったり、速度が低下したり、予期しないネットワークエラーが発生したりしても、ユーザーは引き続きシステムを使用できる必要があります。

おおまかな見積もり

アプリの登録ユーザーが 5,000 万人、毎日のアクティブユーザーが 1,000 万人だとします。
ユーザーには 10GB の無料スペースが与えられます。
ユーザーが 1 日に 2 つのファイルをアップロードし、平均ファイルサイズが 500 KB であるとします。
読み取りと書き込みの比率は 1:1 です。
合計割り当てスペース: 5,000 万 * 10GB = 500PB
アップロード API の 1 秒あたりのクエリ数 (QPS): 1000 万 * 2 アップロード / 24 時間 / 3600 秒 = ~240
ピーク QPS = QPS * 2 = 480

ステップ 2 - 大まかな設計を提案し、承認を得る

最初から高レベルの設計図を示すことで、少し異なるアプローチを採用します。まずは簡単なことから始めます。すべてを 1 つのサーバー内に構築します。その後、数百万のユーザーをサポートできるように徐々にスケールアップします。この演習を通じて、この本で取り上げられている重要なトピックのいくつかを再理解します。

以下に示す単一サーバーのセットアップから始めましょう。

ファイルをアップロードおよびダウンロードするための Web サーバー。
ユーザーデータ、ログイン情報、ファイル情報などのメタデータを追跡するデータベース。
ファイルを保存するためのストレージシステム。ファイルを保存するために 1 TB のストレージ容量を割り当てます。

私たちは数時間かけて、Apache Web サーバー、MySql データベース、およびアップロードされたファイルを保存するための *drive/ というディレクトリを root として設定しました。drive/* ディレクトリの下には、ネームスペースとも呼ばれる一連のディレクトリがあります。各名前空間には、そのユーザーによってアップロードされたすべてのファイルが含まれます。サーバー上のファイル名は元のファイル名のままです。名前空間と相対パスを連結することにより、各ファイルまたはフォルダーを一意に識別できます。

図 15-3 は、左側に */drive* ディレクトリがどのように表示されるかを示し、右側には展開されたビューが示されています。

画像-20230525205317891

APIインターフェース

API インターフェースはどのようなものですか? 主に 3 つの API インターフェイスが必要です: ファイルのアップロード、ファイルのダウンロード、ファイルリビジョンの取得。

1. ファイルを Google ドライブにアップロードする

次の 2 種類のアップロードがサポートされています。

シンプルなアップロード。ファイルサイズが小さい場合は、このアップロードタイプを使用してください。
アップロードを再開できます。ファイルサイズが大きく、ネットワークが停止する可能性が高い場合は、このアップロードタイプを使用してください。

再開可能なアップロード API の例を次に示します。

https://api.example.com/files/upload?uploadType=resumable

パラメータ:

UploadType=再開可能
data: アップロードするローカルファイル。

再開可能なアップロードは、次の 3 つの手順で実行されます [2]。

再開可能な URL の最初のリクエストを送信します。
データをアップロードし、アップロードのステータスを監視します。
アップロードが中断された場合は、アップロードを再開します。

2. Googleドライブからファイルをダウンロードする

API の例: https://api.example.com/files/download

パラメータ:

path: ダウンロードしたファイルのパス。

パラメータの例:
{ "path": "/recipes/soup/best_soup.txt" }

3. ファイルのリビジョンを取得する

API の例: https://api.example.com/files/list_revisions

パラメータ:

path: リビジョン履歴を取得するファイルへのパス。
limit: 返されるリビジョンの最大数。

パラメータの例:
{ "path": "/recipes/soup/best_soup.txt", "limit": 20 }

すべての API インターフェイスはユーザー認証を必要とし、HTTPS を使用します。Secure Sockets Layer (SSL) は、クライアントとバックエンドサーバー間のデータ送信を保護します。

シングルサーバーモードの終了

さらに多くのファイルがアップロードされると、図 15-4 に示す空き容量の警告が最終的に表示されます。

画像-20230525205344911

残りのストレージは 10 MB のみです。ユーザーはファイルをアップロードできなくなったため、これは緊急事態です。最初に思い浮かぶ解決策は、データをシャーディングして複数のストレージサーバーに保存することです。図15-5は、user_idに基づくシャーディングの例を示しています。

画像-20230525205355571

徹夜でデータベースのシャーディングを設定し、それを注意深く監視します。すべてが再びスムーズに動作し始めました。火は消し止められましたが、ストレージサーバーに障害が発生した場合のデータ損失の可能性についてはまだ心配しています。周りに尋ねると、バックエンドの達人である友人の Frank が、Netflix や Airbnb などの多くの大手企業がストレージに Amazon S3 を使用していると教えてくれました。「Amazon Simple Storage Service (Amazon S3) は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。」[3]。それが適切であるかどうかを確認するために、いくつかの調査を行うことにしました。

たくさん読んだ後、S3 ストレージシステムについてしっかりと理解し、ファイルを S3 に保存することにしました。Amazon S3 は、リージョン内およびリージョン間のレプリケーションをサポートしています。リージョンとは、アマゾンウェブサービス (AWS) がデータセンターを有する地理的エリアです。図 15-6 に示すように、データは同じリージョン内 (左) およびリージョン間 (右) でレプリケートできます。データ損失を防止し、可用性を確保するために、冗長ファイルは複数のリージョンに保存されます。バケットは、ファイルシステム内のフォルダーのようなものです。

画像-20230525205416700

S3 にファイルがあれば、データ損失を心配することなく安心して眠ることができます。将来同様の問題が発生するのを防ぐために、改善できる領域についてさらに調査を行うことにしました。以下のエリアが見つかります。

ロードバランサー: ネットワークトラフィックを分散するためにロードバランサーを追加します。ロードバランサーはトラフィックが均等に分散されるようにし、Web サーバーがダウンした場合にはトラフィックを再分散します。
Web サーバー: ロードバランサーを追加した後、トラフィック負荷に基づいて Web サーバーを簡単に追加/削除できます。
メタデータデータベース: データベースをサーバーから移動して、単一障害点を回避します。同時に、可用性とスケーラビリティの要件を満たすようにデータのレプリケーションとシャーディングを設定します。
ファイルストレージ: ファイルストレージには Amazon S3 が使用されます。可用性と耐久性を確保するために、ファイルは 2 つの別々の地理的リージョンにレプリケートされます。

上記の改善を適用すると、Web サーバー、メタデータデータベース、およびファイルストレージが単一サーバーから正常に分離されました。更新された設計を図 15-7 に示します。

画像-20230525205441151

同期の競合

Google ドライブのような大規模なストレージシステムでは、同期の競合が時々発生します。2 人のユーザーが同じファイルまたはフォルダーを同時に変更すると、競合が発生します。この対立をどのように解決すればよいでしょうか? 私たちのポリシーは、最初に処理されたバージョンが優先され、最後に処理されたバージョンが競合を受けるというものです。図 15-8 は、同期競合の例を示しています。

画像-20230525205450653

図 15-8 では、ユーザー 1 とユーザー 2 が同じファイルを同時に更新しようとしましたが、ユーザー 1 のファイルがシステムによって最初に処理されました。ユーザー 1 の更新操作はスムーズに進みますが、ユーザー 2 では同期の競合が発生します。ユーザー 2 の競合を解決するにはどうすればよいでしょうか? 私たちのシステムは、同じファイルの 2 つのコピー、つまりユーザー 2 のローカルコピーとサーバーからの最新バージョンを提示します (図 15-9)。ユーザー 2 は、2 つのファイルをマージするか、一方のバージョンをもう一方のバージョンで上書きするかを選択できます。

画像-20230525205501137

複数のユーザーが同じドキュメントを同時に編集している場合、ドキュメントの同期を維持するのは困難です。興味のある読者は参考文献[4][5]を参照してください。

高度な設計

図 15-10 は、私たちが提案する高レベルの設計を示しています。システムの各コンポーネントを調べてみましょう。

画像-20230525205518122

ユーザー: ユーザーはブラウザまたはモバイルアプリケーションを通じてアプリを使用します。

チャンクサーバー: チャンクサーバーは、チャンクをクラウドストレージにアップロードします。ブロックストレージ (ブロックレベルストレージとも呼ばれます) は、クラウド環境にデータファイルを保存するためのテクノロジーです。ファイルは複数のブロックに分割でき、各ブロックには一意のハッシュ値があり、メタデータデータベースに保存されます。各ブロックは独立したオブジェクトとして扱われ、ストレージシステム (S3) に保存されます。ファイルを再構築するには、チャンクが特定の順序で連結されます。チャンクサイズに関しては、Dropbox を参照します。Dropbox では、最大チャンクサイズが 4MB に設定されています [6]。

クラウドストレージ: ファイルは小さなチャンクに分割され、クラウドストレージに保存されます。

コールドストレージ: コールドストレージは、非アクティブなデータ、つまりファイルが長期間アクセスされていないデータを保存するために使用されるコンピュータシステムです。

ロードバランサー: ロードバランサーは、API サーバー間でリクエストを均等に分散します。

API サーバー: これらのサーバーは、アップロードプロセスを除くほぼすべての処理を担当します。API サーバーは、ユーザー認証、ユーザープロファイルの管理、ファイルメタデータの更新などに使用されます。

メタデータデータベース: ユーザー、ファイル、ブロック、バージョンなどのメタデータを保存します。ファイルはクラウドに保存され、メタデータデータベースにはメタデータのみが含まれることに注意してください。

メタデータキャッシュ: 一部のメタデータは高速に取得できるようにキャッシュされます。

通知サービス: これは、特定のイベントが発生したときに通知サービスからクライアントにデータを配信できるようにするパブリッシャー/サブスクライバーシステムです。私たちの特定のケースでは、ファイルが他の場所で追加/編集/削除されると、通知サービスが関連するクライアントに通知し、クライアントが最新の変更を取得できるようにします。

オフラインバックアップキュー: クライアントがオフラインで最新のファイル変更をプルできない場合、オフラインバックアップキューにこの情報が保存され、クライアントがオンラインのときにそれらの変更を同期できるようになります。

Google ドライブの高レベルの設計について説明しました。これらのコンポーネントの一部は複雑であり、詳細に検討する必要があります。これらについては、詳細な説明で詳しく説明します。

ステップ 3 - 深さの設計

このセクションでは、チャンクサーバー、メタデータデータベース、アップロードプロセス、ダウンロードプロセス、通知サービス、記憶域スペースの節約、および障害処理について詳しく説明します。

ブロックサーバー

頻繁に更新される大きなファイルの場合、更新のたびにファイル全体を送信すると、大量の帯域幅が消費される可能性があります。送信されるネットワークトラフィックを最小限に抑えるための 2 つの最適化を提案します。

増分同期。ファイルが変更されると、同期アルゴリズム [7][8] を使用してファイル全体を同期するのではなく、変更されたブロックのみが同期されます。
圧縮。ブロックを圧縮すると、データサイズを大幅に削減できます。したがって、ファイルの種類に応じた圧縮アルゴリズムを使用してブロックを圧縮します。たとえば、テキストファイルの圧縮には gzip と bzip2 を使用します。画像やビデオを圧縮するには、さまざまな圧縮アルゴリズムが必要です。

私たちのシステムでは、チャンクサーバーがファイルのアップロードという面倒な作業を行います。チャンクサーバーは、クライアントからのファイルを処理し、ファイルをチャンクに分割し、各チャンクを圧縮して暗号化します。ファイル全体をストレージシステムにアップロードするのではなく、変更されたチャンクのみが転送されます。

図 15-11 は、新しいファイルが追加されたときにチャンクサーバーがどのように動作するかを示しています。

画像-20230525205536338

ファイルは小さな塊に分割されます。
各ブロックは、圧縮アルゴリズムを使用して圧縮されます。
セキュリティのため、各ブロックはクラウドストレージに送信される前に暗号化されます。
チャンクをクラウドストレージにアップロードします。

図 15-12 は、増分同期を示しています。これは、変更されたブロックのみがクラウドストレージに転送されることを意味します。強調表示された「ブロック 2」と「ブロック 5」は、変更されたブロックを表します。増分同期では、これら 2 つのチャンクのみがクラウドストレージにアップロードされます。

画像-20230525205547497

チャンクサーバーを使用すると、増分同期と圧縮が提供されるため、ネットワークトラフィックを節約できます。

高い一貫性の要件

私たちのシステムはデフォルトで強い一貫性を必要とします。異なるクライアントが異なるファイルを同時に表示することは許容されません。システムは、メタデータキャッシュとデータベース層に強力な一貫性を提供する必要があります。

メモリキャッシュはデフォルトで結果整合性モデルを採用します。これは、異なるレプリカが異なるデータを持つ可能性があることを意味します。強い一貫性を実現するには、次のことを確認する必要があります。

キャッシュされたコピーは、プライマリデータベース内のデータと一致します。
データベースの書き込み時にキャッシュを無効にして、キャッシュとデータベースが同じ値を保持するようにします。

リレーショナルデータベースでは ACID (原子性、一貫性、分離性、耐久性) プロパティが維持されるため、強整合性を実現するのは簡単です [9]。ただし、NoSQL データベースはデフォルトでは ACID プロパティをサポートしません。ACID プロパティは、同期ロジックにプログラムで導入する必要があります。私たちの設計では、ACID をネイティブにサポートするリレーショナルデータベースを選択します。

メタデータデータベース

図 15-13 は、データベーススキーマの設計を示しています。これは、最も重要なテーブルと興味深いフィールドのみが含まれているため、非常に簡略化されたバージョンであることに注意してください。

画像-20230525205603475

ユーザー: ユーザーテーブルには、ユーザー名、電子メール、プロフィール写真など、ユーザーに関する基本情報が含まれています。

デバイス: デバイステーブルにはデバイス情報が格納されます。Push_id は、モバイルプッシュ通知の送受信に使用されます。ユーザーは複数のデバイスを持つことができることに注意してください。

ネームスペース: ネームスペースはユーザーのルートディレクトリです。

ファイル: ファイルテーブルには、最新のファイルに関連するすべてが保存されます。

File_version : ファイルのバージョン履歴を保存します。ファイルの改訂履歴の整合性を維持するために、既存の行は読み取り専用です。

Block : ファイルブロックに関連するすべてを保存します。すべてのブロックを正しい順序で連結することで、どのバージョンのファイルでもリファクタリングできます。

アップロードプロセス

クライアントがファイルをアップロードすると何が起こるかについて説明します。このプロセスをよりよく理解するために、図 15-14 に示すシーケンス図を描きます。

画像-20230525205617620

図 15-14 では、ファイルメタデータの追加とクラウドストレージへのファイルのアップロードという 2 つのリクエストが並行して送信されます。どちらのリクエストもクライアント 1 からのものです。

ファイルのメタデータを追加します。
1. クライアント 1 は、新しいファイルのメタデータを追加するリクエストを送信します。
2. 新しいファイルのメタデータをメタデータデータベースに保存し、ファイルのアップロードステータスを「保留中」に変更します。
3. 通知通知サービスは新しいファイルを追加しています。
4. 通知サービスは、ファイルがアップロードされていることを関連するクライアント (クライアント 2) に通知します。
ファイルをクラウドストレージにアップロードします。
2.1 クライアント 1 はファイルのコンテンツをチャンクサーバーにアップロードします。
2.2 チャンクサーバーは、ファイルをチャンクに分割し、それらのチャンクを圧縮、暗号化して、クラウドストレージにアップロードします。
2.3 ファイルがアップロードされると、Cloud Storage はアップロード完了コールバックをトリガーします。リクエストは API サーバーに送信されます。
2.4 メタデータデータベースでファイルのステータスを「アップロード済み」に変更します。
2.5 通知通知サービスのファイルのステータスが「アップロード済み」に変わりました。
2.6 通知サービスは、ファイルが完全にアップロードされたことを関連クライアント (クライアント 2) に通知します。

ファイルを編集する場合も同様の流れなので説明は省略します。

ダウンロードプロセス

ファイルが他の場所に追加または編集されると、ダウンロードプロセスがトリガーされます。クライアントは、ファイルが別のクライアントによって追加または編集されたことをどのようにして知るのでしょうか? クライアントがそれを知る方法は 2 つあります。

クライアント A がオンラインで、ファイルが別のクライアントによって変更された場合、通知サービスはクライアント A に何か変更があったことを通知するため、最新のデータを取得する必要があります。
別のクライアントによるファイルの変更中にクライアント A がオフラインになった場合、データはキャッシュに保存されます。オフラインクライアントが再びオンラインになると、最新の変更がプルされます。

クライアントは、ファイルが変更されたことを認識すると、まず API サーバー経由でメタデータをリクエストし、次にチャンクをダウンロードしてファイルを構築します。図 15-15 に詳細なプロセスを示します。スペースの制約のため、図には最も重要なコンポーネントのみが示されていることに注意してください。

画像-20230525205656698

通知サービスは、どこかのファイルが変更されたことをクライアント 2 に伝えます。
クライアント 2 は、新しいアップデートが利用可能であることを認識すると、メタデータを取得するリクエストを送信します。
API サーバーはメタデータデータベースを呼び出して、変更されたメタデータを取得します。
メタデータは API サーバーに返されます。
クライアント 2 はメタデータを取得します。
クライアントはメタデータを受信すると、チャンクをダウンロードするリクエストをチャンクサーバーに送信します。
チャンクサーバーは、まずクラウドストレージからチャンクをダウンロードします。
Cloud Storage はチャンクをチャンクサーバーに返します。
クライアント 2 は、すべての新しいブロックをダウンロードしてファイルを再構築します。

通知サービス

ファイルの一貫性を維持するには、ローカルで実行されたファイル変更を他のクライアントに通知して競合を減らす必要があります。通知サービスはこの目的のために構築されました。高レベルでは、通知サービスにより、イベントの発生時にデータをクライアントに送信できます。以下にいくつかのオプションがあります。

長いポーリング。Dropbox はロングポーリングを使用します [10]。
ウェブソケット。WebSocket は、クライアントとサーバーの間に永続的な接続を提供します。コミュニケーションは双方向です。

どちらのオプションも適切に機能しますが、次の 2 つの理由からロングポーリングを選択します。

通知サービスとの通信は双方向ではありません。サーバーはファイルの変更に関する情報をクライアントに送信しますが、その逆は行いません。
WebSocket は、チャットアプリケーションなどのリアルタイムの双方向通信に適しています。Google ドライブを使用すると、通知が頻繁に送信されず、大量のデータフローが発生しません。

ロングポーリングでは、各クライアントが通知サービスへのロングポーリング接続を確立します。ファイルへの変更が検出された場合、クライアントはロングポーリング接続を閉じます。接続を閉じるということは、クライアントがメタデータサーバーに接続して最新の変更をダウンロードする必要があることを意味します。応答を受信した直後、または接続がタイムアウトになった直後、クライアントは接続を開いたままにするために新しいリクエストを送信します。

保管スペースを節約する

ファイルのバージョン履歴をサポートし、信頼性を確保するために、同じファイルの複数のバージョンが複数のデータセンターに保存されます。すべてのファイルのリビジョンを頻繁にバックアップすると、ストレージ容量がすぐにいっぱいになる可能性があります。ストレージコストを削減するための 3 つの手法を提案します。

データブロックの重複排除。アカウントレベルで冗長なブロックを削除することは、スペースを節約する簡単な方法です。2 つのブロックは、同じハッシュを持つ場合は同一です。
賢明なデータバックアップ戦略を採用します。次の 2 つの最適化戦略を適用できます。
- 制限の設定: 保存されるバージョンの数に制限を設定できます。制限に達すると、最も古いバージョンが新しいバージョンに置き換えられます。
- 貴重なバージョンのみを保存する: 一部のファイルは頻繁に編集される可能性があります。たとえば、大幅に変更されたドキュメントの各編集バージョンを保存すると、ファイルが短期間に 1000 回以上保存されることになる場合があります。不要なコピーを避けるために、保存されるバージョンの数を制限できます。最近のバージョンをより重視します。実験を行うと、最適な保存バージョン数を見つけることができます。
使用頻度の低いデータをコールドストレージに移動します。コールドデータは、数か月または数年間アクティブ化されていないデータです。Amazon S3 Glacier [11] のようなコールドストレージは、S3 よりもはるかに安価です。

トラブルシューティング

大規模なシステムでは障害が発生する可能性があり、それに対処するための設計戦略を採用する必要があります。面接官は、次のシステム障害にどのように対処するかに興味を持つかもしれません。

ロードバランサーの障害: ロードバランサーに障害が発生すると、スタンバイロードバランサーがアクティブになり、トラフィックを引き継ぎます。ロードバランサーは通常、ロードバランサー間で送信される定期的な信号であるハートビートを使用して監視されます。ロードバランサーが一定期間ハートビートを送信しない場合は、障害があるとみなされます。
チャンクサーバーの障害: 1 つのチャンクサーバーに障害が発生すると、他のサーバーが未処理のタスクまたは保留中のタスクを引き継ぎます。
クラウドストレージの障害: S3 バケットが異なるリージョンで複数回レプリケートされます。あるリージョンでファイルが利用できない場合は、他のリージョンからファイルを取得できます。
API サーバーの障害: これはステートレスサービスです。API サーバーに障害が発生した場合、ロードバランサーはトラフィックを他の API サーバーにリダイレクトします。
メタデータキャッシュの失敗: メタデータキャッシュサーバーが複数回レプリケートされます。ノードがダウンしても、他のノードにアクセスしてデータを取得できます。新しいキャッシュサーバーを起動して、障害が発生したノードを置き換えます。
メタデータデータベースの障害。
- マスターノードの障害: マスターノードに障害が発生した場合、スレーブノードの 1 つを新しいマスターノードとして昇格させ、新しいスレーブノードを起動します。
- スレーブノードの障害: スレーブノードに障害が発生した場合、別のスレーブノードを読み取り操作に使用し、別のデータベースサーバーを起動して障害が発生したノードを置き換えることができます。
通知サービスの障害: すべてのオンラインユーザーは、通知サーバーへの長時間ポーリング接続を維持します。したがって、各通知サーバーには多くのユーザーが接続されます。2012 年の Dropbox のプレゼンテーション [6] によると、各マシンには 100 万以上のオープン接続があります。サーバーに障害が発生すると、ロングポーリング接続はすべて失われるため、クライアントは別のサーバーに再接続する必要があります。サーバーは多数のオープン接続を維持できますが、失われたすべての接続を一度に再接続することはできません。失われたすべてのクライアントとの接続を再確立するプロセスは比較的時間がかかります。
オフラインバックアップキューの失敗: キューが複数回複製されます。1 つのキューに障害が発生した場合、キューのコンシューマはバックアップキューに再サブスクライブする必要がある場合があります。

ステップ 4 - まとめ

この章では、Google Driveをサポートするためのシステム設計を提案します。強力な一貫性、低いネットワーク帯域幅、高速な同期により、これは興味深い設計になっています。私たちの設計は、ファイルメタデータの管理とファイルの同期という 2 つのプロセスで構成されています。通知サービスもシステムの重要な部分です。ロングポーリングを使用して、クライアントとファイルの変更の同期を保ちます。

システム設計面接の他の質問と同様、完璧な解決策はありません。どの企業にも独自の制約があり、それらの制約に適合するシステムを設計する必要があります。設計とテクノロジーの選択のトレードオフを理解することが重要です。もう少し時間があれば、さまざまなデザインの選択について話し合うことができます。

たとえば、チャンクサーバーを経由せずに、クライアントから直接クラウドストレージにファイルをアップロードできます。この方法の利点は、ファイルをクラウドストレージに一度転送するだけで済むため、ファイルのアップロードが高速になることです。私たちの設計では、ファイルは最初にチャンクサーバーに転送され、次にクラウドストレージに転送されます。ただし、新しいアプローチにはいくつかの欠点があります。

まず、同じチャンキング、圧縮、暗号化ロジックを異なるプラットフォーム (iOS、Android、Web) に実装する必要があります。これはエラーが発生しやすく、多大なエンジニアリング作業が必要になります。私たちの設計では、このロジックはすべて、チャンクサーバーという 1 つの集中管理された場所に実装されています。
第 2 に、クライアント側は簡単にハッキングされたり操作されたりする可能性があるため、クライアント側に暗号化ロジックを実装することは理想的ではありません。

システムのもう 1 つの興味深い開発は、オンライン/オフラインロジックを別のサービスに移動することです。私たちはそれをプレゼンスサービスと呼んでいます。プレゼンスサービスを通知サーバーの外に移動することで、他のサービスはオンライン/オフライン機能を簡単に統合できます。

ここまで到達できておめでとうございます! 今すぐ自分を叱咤激励してください。素晴らしい！

参考文献

[1] Googleドライブ：https://www.google.com/drive/

[2] ファイルデータのアップロード: https://developers.google.com/drive/api/v2/manage-uploads

[3] Amazon S3：https://aws.amazon.com/s3

[4] 差分同期: https://neil.fraser.name/writing/sync/

【5】差分同期 YouTube解説：https://www.youtube.com/watch?v=S2Hp_1jqpY8

[6] Dropbox を拡張する方法: https://youtu.be/PE4gwstWhmc

[7] A. トリッジェル、P. マッケラス (1996)。rsync アルゴリズム。

[8] ライブラリ同期。(nd)。2015 年 4 月 18 日取得、https://github.com/librsync/librsync より

[9] ACID:https://en.wikipedia.org/wiki/ACID

[10] Dropbox セキュリティホワイトペーパー: https://www.dropbox.com/static/business/resources/Security_Whitepaper.pdf

[11] Amazon S3 Glacier：https://aws.amazon.com/glacier/faqs/

こんにちは、開発7年、外資系5年、インターネット2年のベテランドライバー、しさんです。アーサンやラオメイには勝てますが、PRコメントでダメになったこともあります。長年にわたり、私はパートタイムで働いたり、起業したり、プライベートな仕事を引き継いだり、仕事を混ぜたりしてきました。お金を儲けたし、お金を失った。その過程で、私が最も深く感じたのは、何を学ぶにしても、学び続けなければならないということです。粘り強く続けることができれば、コーナー追い越しを達成するのは簡単です！だから、私が今やっていることをやるには遅すぎるかどうかは聞かないでください。それでも方向性が分からない場合は、私 [パブリックアカウント: More AI (power_ai)] をフォローしてください。そこでは、コーナリングや追い越しのための資本を蓄積するのに役立つ、最先端の情報やプログラミングの知識を頻繁に共有します。