Google は数十億ドル規模の企業です。これは、World Wide Webおよびその他の世界における大きな勢力の 1 つです。同社は分散コンピューティング システムを利用して、データへのアクセス、作成、変更に必要なインフラストラクチャをユーザーに提供しています。確かに Google は物事をスムーズに進めるために最先端のコンピューターとサーバーを購入していますよね?
間違っている。 Google の業務を支えているマシンは、多くの機能を備えた最先端のパワー コンピューターではありません。実際、これらはLinuxオペレーティング システムで動作する比較的安価なマシンです。 Web 上で最も影響力のある企業の 1 つが、どうして安価なハードウェアに依存できるのでしょうか?これは、ハードウェアの弱点を補いながら、既製のサーバーの長所を活用するGoogle ファイル システム( GFS ) によるものです。それはすべてデザインにあります。
Google は GFS を使用して巨大なファイルを整理および操作し、アプリケーション開発者が必要な研究開発リソースを利用できるようにします。 GFS は Google 独自のものであり、販売されていません。しかし、同様のニーズを持つ組織にとっては、ファイル システムのモデルとして機能する可能性があります。
GFS の詳細の一部は、Google 以外の誰にとっても謎のままです。たとえば、Google は GFS の運用に何台のコンピューターを使用しているかを明らかにしていません。 Google の公式文書では、同社はシステム内に「数千」のコンピュータがあるとしか述べていません (出典: Google)。しかし、この秘密のベールにもかかわらず、Google は GFS の構造と運用の多くを一般に公開しました。
では、GFS は正確に何をするのでしょうか、そしてなぜそれが重要なのでしょうか?次のセクションで調べてください。
GFS チームは、書き換えではなく追加ファイル用にシステムを最適化しました。これは、Google 内のクライアントがファイルを上書きする必要がほとんどないためです。代わりに、ファイルの末尾にデータを追加します。 GFS 内のファイルのデータを上書きすることは依然として可能ですが、システムはそれらのプロセスをあまり効率的に処理しません。
Google ファイル システムの基本
Google の開発者は、従来のコンピュータ ファイル システムを使用して操作するのが難しい大きなファイルを日常的に扱っています。ファイルのサイズは、GFS の設計に関してプログラマーが下さなければならない決定の多くを左右しました。もう 1 つの大きな懸念は、システムに容量を追加しやすいことを指すスケーラビリティです。システムの容量を簡単に増やすことができれば、システムは拡張可能です。システムの成長に伴って、システムのパフォーマンスが低下することがあってはなりません。 Google では、すべてのファイルを処理するために非常に大規模なコンピューターネットワークが必要であるため、スケーラビリティが最大の懸念事項となっています。
ネットワークは非常に巨大であるため、ネットワークの監視と維持は困難な作業です。 GFS の開発中に、プログラマーは、システムの稼働を維持するために必要な管理業務の多くを可能な限り自動化することを決定しました。これはオートノミック コンピューティングの重要な原理であり、人間の介入を必要とせずにコンピューターがリアルタイムで問題を診断し、解決できるという概念です。 GFS チームの課題は、自動監視システムを作成するだけでなく、それがコンピューターの巨大なネットワーク全体で動作できるように設計することでした。
チームのデザインの鍵となったのは、簡素化のコンセプトでした。彼らは、システムが複雑になるにつれて、問題がより頻繁に発生するという結論に達しました。シンプルなアプローチは、システムの規模が大きくても制御が容易です。
その哲学に基づいて、GFS チームはユーザーが基本的なファイル コマンドにアクセスできるようにすることを決定しました。これらには、 open 、 create 、 read 、 write 、ファイルを閉じるなどのコマンドが含まれます。チームには、 appendとsnapshot という特殊なコマンドもいくつか含まれていました。彼らは、Google のニーズに基づいて特殊なコマンドを作成しました。 Append を使用すると、クライアントは以前に書き込まれたデータを上書きせずに、既存のファイルに情報を追加できます。スナップショットは、コンピュータの内容の簡単なコピーを作成するコマンドです。
GFS 上のファイルは非常に大きくなる傾向があり、通常は数ギガバイト (GB) の範囲になります。これほど大きなファイルにアクセスして操作すると、ネットワークの帯域幅が大量に消費されてしまいます。帯域幅は、ある場所から別の場所にデータを移動するシステムの容量です。 GFS は、ファイルをそれぞれ 64 メガバイト (MB) のチャンクに分割することでこの問題に対処します。すべてのチャンクは、チャンク ハンドルと呼ばれる一意の 64 ビットの識別番号を受け取ります。 GFS はより小さなファイルを処理できますが、開発者はそのような種類のタスク用にシステムを最適化していません。
すべてのファイル チャンクが同じサイズであることを要求することにより、GFS はリソース アプリケーションを簡素化します。システム内のどのコンピュータが容量に近づいているか、どのコンピュータが十分に使用されていないかを簡単に確認できます。また、あるリソースから別のリソースにチャンクを移植して、システム全体のワークロードのバランスをとることも簡単です。
GFS の実際の設計は何ですか?読み続けて調べてください。
分散コンピューティングとは、複数のコンピューターをネットワークで接続し、それぞれのリソースを集合的に活用することです。各コンピュータは、そのリソースの一部 (メモリ、処理能力、ハード ドライブ容量など) をネットワーク全体に提供します。ネットワーク全体を巨大なコンピューターに変え、個々のコンピューターがプロセッサーおよびデータ ストレージ デバイスとして機能します。
Google ファイル システム アーキテクチャ
Google は GFS をコンピューターのクラスターに編成しました。クラスタは単なるコンピュータのネットワークです。各クラスターには数百、場合によっては数千のマシンが含まれる場合があります。 GFS クラスター内には、クライアント、マスター サーバー、チャンクサーバーの 3 種類のエンティティがあります。
GFS の世界では、「クライアント」という用語は、ファイル要求を行うエンティティを指します。リクエストは、既存のファイルの取得と操作から、システム上での新しいファイルの作成まで多岐にわたります。クライアントは、他のコンピュータまたはコンピュータ アプリケーションにすることができます。クライアントは GFS の顧客と考えることができます。
マスターサーバーはクラスターのコーディネーターとして機能します。マスターの義務には、マスターのクラスターのアクティビティを追跡する操作ログの維持が含まれます。操作ログは、サービスの中断を最小限に抑えるのに役立ちます。マスター サーバーがクラッシュした場合、操作ログを監視している代替サーバーが代わりに使用できます。マスターサーバーは、チャンクを説明する情報であるメタデータも追跡します。メタデータは、チャンクがどのファイルに属しているか、およびチャンクがファイル全体のどこに収まるかをマスター サーバーに伝えます。起動時に、マスターはクラスター内のすべてのチャンクサーバーをポーリングします。チャンクサーバーは、マスターサーバーにインベントリの内容を通知することで応答します。その瞬間から、マスターサーバーはクラスター内のチャンクの場所を追跡します。
アクティブなマスター サーバーは、クラスターごとに一度に 1 つだけです (ただし、ハードウェア障害が発生した場合に備えて、各クラスターにはマスター サーバーのコピーが複数あります)。これはボトルネックを解決するのに適したレシピのように聞こえるかもしれません。結局のところ、数千台のコンピューターのクラスターを調整するコンピューターが 1 台しかない場合、データトラフィックの渋滞が発生するのではありませんか? GFS は、マスター サーバーが送受信するメッセージを非常に小さく保つことで、この厄介な状況を回避します。マスターサーバーは実際にはファイルデータをまったく処理しません。それはチャンクサーバーに任せます。
チャンクサーバーは GFS の主力製品です。これらは 64 MB のファイル チャンクを保存する役割を果たします。チャンクサーバーはマスターサーバーにチャンクを送信しません。代わりに、要求されたチャンクをクライアントに直接送信します。 GFS はすべてのチャンクを複数回コピーし、異なるチャンクサーバーに保存します。各コピーはレプリカと呼ばれます。デフォルトでは、GFS はチャンクごとに 3 つのレプリカを作成しますが、ユーザーは必要に応じて設定を変更し、作成するレプリカの数を増減できます。
日常的なプロセス中にこれらの要素はどのように連携するのでしょうか?次のセクションで調べてください。
GFS は、レプリカをプライマリ レプリカとセカンダリ レプリカの 2 つのカテゴリに分類します。プライマリ レプリカは、チャンクサーバーがクライアントに送信するチャンクです。セカンダリ レプリカは、他のチャンクサーバー上のバックアップとして機能します。マスターサーバーは、どのチャンクがプライマリまたはセカンダリとして機能するかを決定します。クライアントがチャンク内のデータを変更すると、マスター サーバーはセカンダリ レプリカを持つチャンクサーバーに、最新の状態を保つためにプライマリ チャンクサーバーから新しいチャンクをコピーする必要があることを通知します。
Google ファイル システムの使用
ファイルリクエストは標準のワークフローに従います。読み取りリクエストは単純です。クライアントはマスター サーバーにリクエストを送信し、システム上の特定のファイルを見つけることができる場所を見つけます。サーバーは、それぞれのチャンクのプライマリ レプリカの場所を応答します。プライマリ レプリカは、マスター サーバーから問題のチャンクのリースを保持します。
現在リースを保持しているレプリカがない場合、マスター サーバーはチャンクをプライマリとして指定します。これは、クライアントの IP アドレスとレプリカを含むチャンクサーバーのアドレスを比較することによって行われます。マスターサーバーは、クライアントに最も近いチャンクサーバーを選択します。そのチャンクサーバーのチャンクがプライマリになります。次に、クライアントは適切なチャンクサーバーに直接接続し、チャンクサーバーがレプリカをクライアントに送信します。
書き込みリクエストはもう少し複雑です。クライアントは依然としてマスター サーバーにリクエストを送信し、マスター サーバーはプライマリ レプリカとセカンダリ レプリカの場所を応答します。クライアントはこの情報をメモリ キャッシュに保存します。そうすることで、クライアントが後で同じレプリカを参照する必要がある場合に、マスター サーバーをバイパスできます。プライマリ レプリカが使用できなくなったり、レプリカが変更された場合、クライアントはチャンクサーバーに接続する前にマスター サーバーに再度問い合わせる必要があります。
次に、クライアントは、最も近いレプリカから始めて最も遠いレプリカで終わるまで、すべてのレプリカに書き込みデータを送信します。最も近いレプリカがプライマリであるかセカンダリであるかは関係ありません。 Google は、このデータ配信方法をパイプラインに例えています。
レプリカがデータを受信すると、プライマリ レプリカはファイルへの各変更に連続したシリアル番号を割り当て始めます。変化は突然変異と呼ばれます。シリアル番号は、各突然変異を順序付ける方法をレプリカに指示します。次に、プライマリは、自身のデータに突然変異を順番に適用します。次に、セカンダリ レプリカに書き込みリクエストを送信し、同じアプリケーション プロセスに従います。すべてが正常に機能する場合、クラスター全体のすべてのレプリカに新しいデータが組み込まれます。アプリケーション プロセスが終了すると、セカンダリ レプリカはプライマリ レプリカに報告を返します。
その時点で、プライマリ レプリカはクライアントに報告を返します。プロセスが成功した場合は、ここで終了します。そうでない場合、プライマリ レプリカは何が起こったのかをクライアントに伝えます。たとえば、1 つのセカンダリ レプリカが特定の変更による更新に失敗した場合、プライマリ レプリカはクライアントに通知し、変更アプリケーションをさらに数回再試行します。セカンダリ レプリカが正しく更新されない場合、プライマリ レプリカはセカンダリ レプリカに書き込みプロセスを最初からやり直すように指示します。それが機能しない場合、マスターサーバーは影響を受けるレプリカをガベージとして識別します。
GFS は他に何を行い、マスター サーバーはガベージに対して何を行うのでしょうか?読み続けて調べてください。
クライアントが、特に大きなファイルの複数のチャンクに影響を与える書き込みリクエストを作成した場合、GFS は書き込みリクエスト全体をチャンクごとの個別のリクエストに分割します。プロセスの残りの部分は通常の書き込みリクエストと同じです。
その他の Google ファイル システム機能
GFS が提供する基本サービスとは別に、システムをスムーズに実行し続けるのに役立つ特別な機能がいくつかあります。システムの設計中に、GFS 開発者は、システムのアーキテクチャに基づいて特定の問題が必ず発生することを認識していました。彼らは安価なハードウェアを使用することを選択したため、大規模なシステムの構築がコスト効率の高いプロセスになりました。また、システム内の個々のコンピューターが常に信頼できるとは限らないことも意味しました。価格の安さは、故障する傾向のあるコンピューターと密接に関係していました。
GFS 開発者は、個々のコンポーネントの本質的な信頼性の低さを補う機能をシステムに組み込みました。これらの機能には、マスターとチャンクのレプリケーション、合理化されたリカバリ プロセス、リバランス、古いレプリカの検出、ガベージの削除、チェックサムが含まれます。
GFS クラスターごとにアクティブなマスターサーバーは1 つだけですが、マスター サーバーのコピーは他のマシンに存在します。シャドウ マスターと呼ばれる一部のコピーは、プライマリ マスター サーバーがアクティブな場合でも、限定的なサービスを提供します。これらのリクエストはいかなる形でもデータを変更しないため、これらのサービスは読み取りリクエストに限定されます。シャドウ マスター サーバーは常にプライマリ マスター サーバーよりも若干遅れますが、通常はほんの数秒の問題です。マスターサーバーのレプリカはプライマリマスターサーバーとの接続を維持し、操作ログを監視し、チャンクサーバーをポーリングしてデータを追跡します。プライマリマスターサーバーに障害が発生して再起動できない場合、セカンダリマスターサーバーが代わりに使用できます。
GFS はチャンクを複製して、ハードウェアに障害が発生した場合でもデータを利用できるようにします。レプリカは、異なるラックの異なるマシンに保存されます。そうすれば、ラック全体に障害が発生した場合でも、データは別のマシン上にアクセス可能な形式で存在します。 GFS は、一意のチャンク識別子を使用して、各レプリカが有効であることを確認します。レプリカのハンドルの 1 つがチャンク ハンドルと一致しない場合、マスター サーバーは新しいレプリカを作成し、それをチャンクサーバーに割り当てます。
また、マスター サーバーはクラスター全体を監視し、チャンクをあるチャンクサーバーから別のチャンクサーバーに移動することによってワークロードのバランスを定期的に再調整します。すべてのチャンクサーバーはほぼ容量で実行されますが、フル容量で実行されることはありません。マスターサーバーはチャンクも監視し、各レプリカが最新であることを確認します。レプリカがチャンクの識別番号と一致しない場合、マスター サーバーはそれを古いレプリカとして指定します。古いレプリカはゴミになります。 3 日後、マスター サーバーはガベージ チャンクを削除できます。これは安全対策です。ユーザーはガベージ チャンクが完全に削除される前にそれを確認し、不要な削除を防ぐことができます。
データの破損を防ぐために、GFS はチェックサムと呼ばれるシステムを使用します。システムは、64 MB の各チャンクを 64 キロバイト (KB) のブロックに分割します。チャンク内の各ブロックには独自の 32 ビット チェックサムがあり、フィンガープリントのようなものです。マスターサーバーはチェックサムを調べることによってチャンクを監視します。レプリカのチェックサムがマスター サーバーのメモリ内のチェックサムと一致しない場合、マスター サーバーはレプリカを削除し、新しいレプリカを作成して置き換えます。
Google は GFS でどのようなハードウェアを使用していますか?次のセクションで調べてください。
GFS コンポーネントは、ハートビートとハンドシェイクと呼ばれる電子メッセージを通じてシステムを更新します。これらの短いメッセージにより、マスター サーバーは各チャンクサーバーのステータスを最新の状態に保つことができます。
Google ファイル システム ハードウェア
Googleは、 GFSを実行するために現在使用しているハードウェアについては、GFSが既製の安価なLinuxサーバーの集合であること以外にはほとんど語っていない。しかし、Google は公式 GFS レポートの中で、GFS のパフォーマンスに関するいくつかのベンチマーク テストを実行するために使用した機器の仕様を明らかにしました。このテスト機器は現在の GFS ハードウェアを正確に表現したものではないかもしれませんが、Google が保存および操作する大量のデータを処理するためにどのようなコンピューターを使用しているかを知ることができます。
テスト機器には、1 台のマスター サーバー、2 台のマスター レプリカ、16 台のクライアント、および 16 台のチャンクサーバーが含まれていました。これらはすべて、同じ仕様の同じハードウェアを使用しており、すべて Linuxオペレーティング システムで実行されていました。それぞれにデュアル 1.4 ギガヘルツ Pentium III プロセッサ、2 GB のメモリ、および 2 つの 80 GBハード ドライブが搭載されていました。比較すると、現在、いくつかのベンダーが、Google がテストで使用したサーバーの 2 倍以上強力な消費者向け PC を提供しています。 Google の開発者は、GFS が小規模な機器を使用して効率的に動作できることを証明しました。
マシンを接続するネットワークは、100 メガバイト/秒 (Mbps) の全二重イーサネット接続と 2 台の Hewlett Packard 2524 ネットワーク スイッチで構成されていました。 GFS 開発者は、16 台のクライアント マシンを 1 つのスイッチに接続し、他の 19 台のマシンを別のスイッチに接続しました。彼らは 2 つのスイッチを 1 ギガバイト/秒 (Gbps) の接続でリンクしました。
最先端のハードウェア技術に後れをとることで、グーグルは機器やコンポーネントを格安で購入できるようになる。 GFS の構造は、いつでも簡単にマシンを追加できるようになっています。クラスタがフルキャパシティに近づき始めた場合、Google はシステムに安価なハードウェアを追加して、ワークロードのバランスを再調整できます。マスター サーバーのメモリが過負荷になっている場合、Google はマスター サーバーをアップグレードしてメモリを増やすことができます。このシステムは本当に拡張性があります。
Google はどのようにしてこのシステムを使用することにしたのですか? Googleの採用方針を評価する人もいる。 Google は、大学院を卒業したばかりのコンピュータ サイエンス専攻者を採用し、GFS のようなシステムを実験するために必要なリソースとスペースを提供することで定評があります。また、多くのコンピュータ システム開発者 (Google の創設者を含む) が持っていると思われる、「自分の持っているものでできることは何でもする」という考え方から来ていると言う人もいます。最終的に Google が GFS を選択したのは、世界中の情報を整理するという同社の定められた目標の追求に役立つ種類のプロセスを処理することを目的としているからでしょう。
コンピューター システムと関連トピックについて詳しくは、次のページのリンクをご覧ください。
帯域幅はデータをある場所から別の場所に移動するシステムの容量を指しますが、遅延はシステム コマンドと対応する応答の間の遅延を指します。一般に、ほとんどのシステム管理者は、高帯域幅と低遅延を追求します。 Google アプリケーションは非常に大きなファイルを処理するため、Google 開発者は帯域幅をより重視しています。
