ikemonn's blog

技術ネタをちょこちょこと

The Google File System を読んだ

The Google File System を読んだ。

どんなもの?

  • Googleのサービスの特性に最適化させた、大規模分散システム用のスケーラブルなファイルシステム
    • 廉価で故障しやすいHW上で稼働することを前提とし、耐障害性がある
    • aggregateのパフォーマンスが高い
    • BigTableにも使われてる

先行研究とくらべて何がすごい?

  • 何千台もの一般的なサーバで動く
    • 故障するのが前提で耐障害性とリカバリを担保
  • 一般的なファイルシステムに比べて、大きなファイルを扱うことを前提としている
    • KB単位ではなくGB単位
  • 新しいデータはappendしてoverwriteしない
  • レスポンスタイムよりも帯域幅に重きを置いている
    • サービスの特性上bulk処理が大半を占めるから

技術や手法の肝は?

f:id:ikemonn:20170627234137p:plain

  • Architecture
    • single masterとmulit chunkserverで構成されている
    • fileは固定サイズ(64MB)のchunkに分割される
      • 利点
        • ファイルサイズが大きいので、小さいファイルに比べて何度もやりとりをする必要がなく通信のoverheadが少ない
        • 通信の回数が少なくなるのでmasterサーバへの負荷が少なくなる
        • masterサーバに保存されるmetaデータのサイズが小さくなる
      • 欠点
        • 同じファイルへのアクセスが多いとhotspotになる
          • Googleのサービスの特性上、複数のchunkファイルをシーケンシャルに読むのであまり問題にならない
    • chunkserverはlocalにchunkをlinuxのファイル形式で保存する
      • ファイル操作はchunck handle(uniqueなidのようなもの)とrangeを使っておこなわれる
    • master server
    • メタデータ
      • 3種類ある
        1. fileとchunkのnamespace (operation logとin memory)
        2. fileからchunkへのmapping (operation logとin memory)
        3. . chunkのreplicaがどのchunkserverになるか (in memoryのみ)
    • chunk server
      • デフォルトで3台のchuckサーバにデータがreplicateされる(primaryとsecondary)

f:id:ikemonn:20170627234152p:plain

Interaction

  1. clientがmasterに問い合わせて、対象chunk&現在leaseを持っているserverと他のreplicaの情報を得る
  2. masterはprimaryとsecondaryの情報をclientに返す(clientはこれをcacheする)
  3. clientがデータを任意の順番で全てのreplicaにpushする
  4. 全てのreplicaにデータが行き届いたら、clientがprimaryにwrite requestを送る
  5. primaryがsecondaryにwrite requestを送る
  6. 全てのsecondaryがprimaryに書き込み完了を通知すると処理が終わる
  7. primaryがclientに通知(エラーがあったらclient側でretryする)

  8. GC

    • アプリケーションによってファイルが消されても、masterはdelete処理をlogに書き込むだけで実体はすぐには消さない
      • renameされて、deletetion timestampが振られる
    • masterのファイルシステムnamespaceのregular scanの際に、3日(変更可能)が過ぎたファイルは削除される

どうやって有効と検証した?

f:id:ikemonn:20170627234211p:plainf:id:ikemonn:20170627234215p:plain

  • A: R&Dで数百人のエンジニアが利用しているCluster
  • B: 本番データで利用しているCluster

  • readはwriteよりも速い

    • 本番環境でもwriteよりもreadの処理が多いことを想定している
    • BがAよりもreadの効率が悪い
  • master opsは200~500 Ops/sを安定して出せている
    • masterの処理がボトルネックにならない
    • 初期のGFSではmasterの処理がボトルネックになっていた(sequential scan)が、master data構造をnamespaceでbinary searchするのに効率的な構造にすると速くなった

議論はある?

  • さまざまな問題の中でも一番大きかったのはdiskとLinux関係の問題
    • 複数versionのIDE protocolをサポートしているようにように思えたdiskが、実は最新バージョンしかサポートしてなかった
      • だいたい動くけれど、たまに動かなくてデータが壊れるのでchecksumをいれるようにした

次に読むべき論文は?

↑も面白そうだけれど、Chubbyを読む