Chubby @a2-ito, 2021.3.19

Publication The Chubby lock service for loosly-coupled distributed systems https://research.google/pubs/pub27897/ 2006 Mike Burrows 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI)

概要 Google 社内の分散ロックサービス Chubby の実装 coarse-grained reliable storage (low-volume) Paxos そのものの話はありません high performance よりも、高可用性、高信頼性

Introduction

a Chubby instance 10,000 台 のクライアントを捌く 1Gbit/s Ethernet Chubby cell は1つのセンタに配置される ただし、少なくとも1つのレプリカが数千キロメートル離れた遠いところに置 かれる

Lock Service か Client Paxos Library か Client Paxos Library サーバが不要 開発者にフレームワークを提供 Lock Service プロトタイプや既存のコードへの簡単な実装 サーバ台数の削減 慣れ親しんだ Lock-based インターフェース 単一のクライアントでも高い可用性と安全性

設計思想 key desigin descisions Lock servicse Serve small- les 期待する使用用途 イベント通知 キャッシング ACL coarse-grained locks リーダ選出

Chubby's design

アーキテクチャ server と client library optional として proxy server が使われる cell と呼ばれる複数サーバで構成される（通常5台） "replica"

single replica Tushar Chandra, Robert Griesemer, Joshua Redstone, Paxos made live: an engineering perspective, PODC '07

システム構成 サーバとクライアント(with client library) から成る replicas は Paxos を使ってマスタ選出＆ログのレプリケーションを行う クライアントは master location requests を送って master を探す master 以外の replica はマスタの識別子を返却 master だけがリクエストを捌く Write は合意形成で確定、Read はマスタのみで返却

Files, directories and handles ファイルシステムインターフェース /ls/foo/wombat/pouch ls : lock service foo : the name of the Chubby cell wombat/puch : 任意 シンボリックリンクやハードリンクは使えない

Locks and sequencers

lock の種類 mandatory lock ロックを掛けたプロセス以外からの、read() や write() をできなくする advisory lock 基本的には mandatory lock と同じ システム的に 強制しているかどうか が違う 他のプロセスが advisory lock を実装していないと意味がない Linux/Unix のシステムコール fctnl

Chubby における lock Chubby では advisory lock を採用 mandatory locking のためには拡張的な修正が必要 利用者側の負担増 アプリケーションをシャットダウンしなければならなくなる 開発者目線だと結局アサーション(lock X is held)によるチェックしか実装さ れない（ので mandatory にする意味が薄い）

分散システムにおける lock の複雑性 通信の不確実性・障害独立性により、分散システムにおける locking は複雑 解決法 virtual time [11] virtual synchony [1] [11] JEFFERSON, D. Virtual time. ACM TOPLAS, 3 (1985), 404–425. [1] BIRMAN, K. P., AND JOSEPH, T. A. Exploiting virtual synchrony in distributed systems. In 11th SOSP (1987), pp. 123–138.

Sequencer lock 保持者は sequencer を利用することができる Sequencer 側の確認 Name of the lock Lock mode (exclusive or shared) Lock genera9on number

Events Chubby クライアントは各種イベント通知を受け取る Events le contents modi ed Chubby master failed over a handle has become invalid lock acquired con icting lock request

API Open/Close node name func Open() func Close() Poison - キャンセルコール func Poison() Read/Write full contents func GetContentsAndStat() func GetStat() func ReadDir() func SetContents() ...

Caching クライアントは整合性が担保された形でデータをキャッシュする リース あるクライアントが特定のファイル X を修正すると、X をキャッシュしているク ライアントに invalidations がマスタから送られる

Sessions and KeepAlives Chubby session : cell と クライアントの関係 KeepAlive : 定期的なハンドシェイクによってメンテされる クライアント向けの イベントの送信 や invalidations で使われる

Fail-overs フェールオーバが発生すると、メモリ上のセッションやロックは破棄される マスタのフェールオーバーがすぐ終わったら lease 期限が切れる前に新しいマスタとコミュニケーションを開始 マスタのフェールオーバーが時間掛かったら クライアントはキャッシュを削除して、grace priod 分 (45s) 待機 jeopardy

Database implementation 最初のデザインでは、 Berkeley DB [20] を使用していた Berkeley DB はログの replication に分散合意を使用している BDB の B-tree コードは広く使われているが、replication はそんなに使われ ていない そこまできちんとメンテされない → replication のコードを使うのはリ スクと判断 結果、WALロギングや snapshotting を使用するシンプルDB実装を作った [2] [20] OLSON, M. A., BOSTIC, K., AND SELTZER, M. Berkeley DB. In USENIX (June 1999), pp. 183–192. [2] BIRRELL, A., JONES, M. B., AND WOBBER, E. A simple and e cient implementation for small databases. In 11th SOSP (1987), pp. 149–154.

Backup 数時間毎に、各Chubby cell は 別の建物にある GFS にスナップショットを作成す る 別の建物を使用することで、バックアップが建物の損傷に耐えることができ、バ ックアップによってシステムに循環する依存が発生しないことが保証される 同じセンタの GFS cell は、リーダ選出に同じ Chubby cell を使っているかも しれない

Mirroring ミラーリングは高速 ファイルが小さい イベントメカニズムにより動作 ネットワークの問題が起きなければ、１秒未満で世界中にコピーされる

The global Chubby cell global と呼ばれる特別な cell 5つのレプリカが広範囲に点在 ほとんどの組織からアクセス可能 Usage Chubby’s own ACLs モニタリングサービスへの存在の advertise 大きなデータセット(Bigtable cells)や con guration les のポインタ

Scaling

scaling のメカニズム 膨大な数のクライアントを扱う必要がある E ective scaling techniques master とのコミュニケーションを減らす 任意の数の Chubby cell リース時間の拡張 (KeepAlivesプロセスの削減) caching protocol-conversion その他のアプローチ (2006時点では、production未使用らしい) Proxy Partitioning

Proxy proxy は以下のサーバ負荷を軽減できる KeepAlive read requests write request は減らせない(キャッシュが使えないため) Chubby の負荷としては read よりも KeepAlive の方が遥かに大きい

Paritioning ディレクトリによって namespace をパーティショニングする N 個のパーティション hash(D) mod N Patitioning によって read/write は減らすことができるが KeepAlive トラフィッ クは減らせない :(

Experience

Use and behavior 61 outages over a period of a few weeks 52 outages < 30 seconds => すごい 4 caused by network maintenance 2 caused by suspected network connectivity problems 2 caused by software errors 1 caused by overload Overload 90,000 セッションから 同時100万 read アクセス

Java Client Google インフラの大部分は C++ で記述されているが、Java コードも増えてき ている Java クライアントライブラリをメンテするのは大変 C++ のクライアントライブラリは 7,000 行 Java ユーザは protocol-conversion サーバを使用

Use as a name service lock service だが、name server としての利用が人気 Chubby DNS server with protocol-conversion server

Lessons Learned Developers rarely consider availability 開発者は、失敗する確率はわずかだと思って実装する Chubby のちょっとした障害を考慮した実装をしてほしい Fine-grained locking could be ignored 不必要なコミュニケーションは削減しなければならない Poor API choices have unexpected a ects キャンセルのための呼び出し Close() and Poison() server state を棄却する Cencel() を追加するかも RPC use a ects transport protocols KeepAlive RPC に UDP を採用

Summary Chubby は coarse-grained な分散システムのための分散ロックサービス replicas client-side caching noti cation le system interface Google の primary internal name service Bigtable usage To elect a master To allow the master to discover the servers its controls To permit clients to nd the master