Slide 1

Slide 1 text

Chubby @a2-ito, 2021.3.19

Slide 2

Slide 2 text

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)

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Introduction

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Chubby's design

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Locks and sequencers

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

分散システムにおける 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.

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Scaling

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Experience

Slide 32

Slide 32 text

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 アクセス

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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 を採用

Slide 36

Slide 36 text

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