これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
前回のコラムでは、2003年に発表された論文「The Google File System」から、Google File System（GFS）について、システム全体の概要を紹介しました。今回は、高いスループットを実現するファイルアクセスの仕組みと、データの信頼性を担保する仕組みを解説します。
前回説明したように、GFSでは、1つのファイルは64MBのチャンクに分割されて、多数のチャンクサーバーに分散保存されます。この際、冗長化のために、1つのチャンクは複数のチャンクサーバー（デフォルトでは3箇所）に保存されます。3箇所に保存する場合であれば、マスターサーバーによって、それぞれのチャンクに対して、1台のプライマリーサーバーと2台のセカンダリーサーバーが割り当てられます。
そして、例えば、クライアントがファイルに追記を行う場合、クライアントは、マスターサーバーからチャンクサーバーの情報を取得して、書き込み対象のデータを送信します。この際、図1に示すように、3台のチャンクサーバーに対して直列にデータを流します。つまり、1台目のチャンクサーバーは、クライアントからデータの受信を開始すると、そのデータをメモリー上のキャッシュに保存すると同時に、そのデータを即座に次のチャンクサーバーへと転送を開始します。3台のチャンクサーバーは、それぞれ異なるラックにあるため、クライアントに近い方から順に転送した場合、転送経路上のネットワークスイッチやNICは、その帯域をフル活用することができます。
図1 チャンクサーバーへのデータ送信経路
仮に、クライアントが3つのチャンクサーバーに並列にデータを転送した場合、クライアントのNICからは、先の場合に比べて3倍のデータを転送する必要があり、ネットワーク転送速度は明らかに遅くなります。GFSを構成するクラスター環境では、IPアドレスのレンジからラックの位置関係がわかるようになっており、物理的なネットワーク経路を意識して、最適な書き込み順序を実現しています。ちなみに、イーサネットワークは全二重通信ですので、受信経路と送信経路は、同じNIC／ケーブルを用いても問題ない点に注意してください。
また、3台のチャンクサーバーのキャッシュにデータを転送すると同時に、クライアントからは、プライマリーサーバーに対して、データ受信確認の問い合わせが送られます（図2）。これを受けたプライマリーサーバーは、さらに、セカンダリーサーバーに受信確認を行います。すべてのチャンクサーバーのデータ受信を確認すると、クライアントは、改めて、プライマリーサーバーに書き込みの指示を出します。すると、プライマリーサーバーは、キャッシュ上のデータをチャンクファイルに書き込むと同時に、セカンダリーサーバーにも書き込みの指示を出します。
図2 データの受信確認と書き込み処理
また、複数のクライアントが、同一のチャンクに書き込み処理を行った場合は、プライマリーサーバーが書き込み順序の制御を行い、セカンダリーサーバーに対しても同じ順序で書き込みを行うように指示を出します。図1と図2を比較すると分かるように、実データの転送と、データの整合性を保証するための制御命令について、異なる通信経路が使用されています。現代的な用語で言えば、データプレーンとコントロールプレーンの分離と言ってもよいでしょう。
GFSでは、複数のチャンクサーバーにデータを複製保存することで、データの冗長性を確保しますが、その他にもデータの信頼性を担保する仕組みが用意されています。例えば、それぞれのチャンクには、バージョン番号とチェックサムが付与されており、マスターサーバーは、各チャンクの最新のバージョン番号を保持しています。クライアントからのアクセス要求があると、マスターサーバーは、各レプリカのバージョン番号を確認して、最新でないものがあった場合は、再レプリケーションによって更新を行います。何らかの理由で一部のチャンクが更新されずに残っていた場合でも、誤って古いデータを返すことはありません。
また、クライアントがGFS上のファイルにリードアクセスを行う場合、チャンクサーバー上では、ディスクから読み出したチャンク全体について、チェックサムを計算して、チャンクが破損していないことを確認します（図3上）。チャンクの破損が検出された場合、正常なチャンクを再レプリケーションしてデータの整合性を回復します。なお、これは、チャンクの一部のデータのみが必要な場合であっても、必ず、チャンク全体を読み込むことを意味します。前回説明したように、GFSは、シリアルな読み込み処理に最適化して設計されていますので、この点は問題にはなりません。
図3 チェックサムによるチャンクの破損検出
一方、ファイルの追記処理によって、チャンクの末尾にデータが追加される場合は、既存のチェックサムを元にして、データを追記した状態のチェックサムを計算します（図3下）。チャンク全体のデータを読み取ってチェックサムを再計算する必要はありません。追記前のチャンクが破損していた場合が心配になるかも知れませんが、そのような場合は、チャンク全体としてチェックサムに不整合が発生しますので、前述のリード処理の際にチャンクの破損が検知されることになります。
なお、ファイルの追記ではなく、上書き処理の際は、チャンク全体を読み込んでチェックサムの再計算が行われます。これは、上書き処理における性能上のオーバーヘッドとなりますが、GFSはファイルの追記処理に最適化されているので、この点もやはり問題にはなりません。
今回は、Google File System（GFS）におけるファイルアクセスと、データの信頼性を担保する仕組みを説明しました。冒頭の論文では、この他にも、マスターサーバー上のメタデータの整合性を担保する仕組み、あるいは、マスターサーバーの障害時にマスターサーバーを切り替える処理、さらには、ファイルシステムのスナップショット機能など、興味深い仕組みが解説されています。興味のある方は、ぜひ一度、論文にも目を通してみてください。
そして、次回からは、GFSを利用した上位のミドルウェアとして、BigtableとMegastoreを解説していきます。これらは、Google Cloud Platformにおいて、「Cloud Bigtable」、および、「Cloud Datastore」として提供されている、分散型データベースサービスの基礎となる技術です。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
