Here is an introduction by kanda.motohiro@gmail.com of the abstract of the paper "The RAMCloud Storage System" appeared in ACM Transactions on Computer Systems, Vol. 33, No. 3.
以下は、ACM Transactions on Computer Systems, Vol. 33, No. 3 The RAMCloud Storage System の kanda.motohiro@gmail.com による概要の紹介です。
The RAMCloud Storage System
JOHN OUSTERHOUT, ARJUN GOPALAN, ASHISH GUPTA, ANKITA KEJRIWAL,
COLLIN LEE, BEHNAM MONTAZERI, DIEGO ONGARO, SEO JIN PARK,
HENRY QIN, MENDEL ROSENBLUM, STEPHEN RUMBLE, RYAN STUTSMAN,
and STEPHEN YANG , Stanford University
RAMCloud は、巨大スケールのデータセットへの低遅延のアクセスを提供するストレージシステムです。低遅延を実現するために、RAMCloud は、常に、全てのデータを DRAM に格納します。大きな容量（１PB 以上）をサポートするために、それは、数千のサーバのメモリを、一つのコヒーレントなキーバリューストアにまとめ上げます。RAMCloud は、DRAM をベースとするデータの永続性を保証するために、バックアップコピーを二次記憶域に維持します。それは、同じログストラクチャード機構を使って、DRAM と二次記憶域を管理します。その結果、高性能と効率的なメモリの使用が得られます。RAMCloud は、通信に、ポーリングをベースとするアプローチを使い、カーネルをバイパスして、NIC と直接通信します。このアプローチにより、クライアントは、いかなる RAMCloud 記憶域サーバからも、小さなオブジェクトを 5μs 以下で読むことができ、小さなオブジェクトの永続的ライトはほぼ 13.5μs で済みます。RAMCloud は、オンラインでデータの複数コピーを持ちません。その代わりに、クラッシュからとても速く（１から２秒）回復することで、高可用性を提供します。RAMCloud のクラッシュ回復機構は、同時並行してはたらくクラスタ全体のリソースを活用します。このため、回復性能は、クラスタサイズとともにスケールします。
Categories and Subject Descriptors: D.4.7 [Operating Systems]: Organization and Design—Distributed;
D.4.2 [Operating Systems]: Storage Management—Main memory; Secondary storage; Distributed memo-
ries; D.4.5 [Operating Systems]: Reliability—Fault tolerance
General Terms: Design, Experimentation, Performance, Reliability
Additional Key Words and Phrases: Datacenters, large-scale systems, low latency, storage systems
ACM Reference Format:
John Ousterhout, Arjun Gopalan, Ashish Gupta, Ankita Kejriwal, Collin Lee, Behnam Montazeri, Diego
Ongaro, Seo Jin Park, Henry Qin, Mendel Rosenblum, Stephen Rumble, Ryan Stutsman, and Stephen Yang.
2015. The RAMCloud storage system. ACM Trans. Comput. Syst. 33, 3, Article 7 (August 2015), 55 pages.
DOI: http://dx.doi.org/10.1145/2806887
This work was supported by C-FAR (one of six centers of STARnet, a Semiconductor Research Corporation
program, sponsored by MARCO and DARPA); the National Science Foundation under grant 096385; the
Gigascale Systems Research Center and the Multiscale Systems Center (two of six research centers funded
under the Focus Center Research Program, a Semiconductor Research Corporation program); and Stan-
ford Experimental Data Center Laboratory affiliates Cisco, Emulex, Facebook, Google, Huawei, Inventec,
Mellanox, NEC, NetApp, Samsung, SAP, and VMware. S. Rumble was supported by a Natural Sciences and
Engineering Research Council of Canada Postgraduate Scholarship. D. Ongaro was supported by the Junglee
Corporation Stanford Graduate Fellowship. S. J. Park was supported by a Samsung Scholarship.
Authors’ addresses: J. Ousterhout, A. Kejriwal, C. Lee, B. Montazeri, D. Ongaro, S. J. Park, H. Qin, M.
Rosenblum, and S. Yang, Computer Science Department, 353 Serra Mall, Stanford, CA 94305-9030; A.
Gopalan, Tintri, 303 Ravendale Dr, Mountain View, CA 94043; A. Gupta, Facebook, 1 Facebook Way, Menlo
Park, CA 94025; S. Rumble, Google Switzerland GmbH, Brandschenkestrasse 110, 8002 Zürich, Switzerland;
R. Stutsman, School of Computing, University of Utah, Salt Lake City, UT 84112.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted
without fee provided that copies are not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. Copyrights for components of this work owned
by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request
permissions from permissions@acm.org.
2015 Copyright is held by the owner/author(s). Publication rights licensed to ACM.
ACM 0734-2071/2015/08-ART7 $15.00
DOI: http://dx.doi.org/10.1145/2806887
ACM Transactions on Computer Systems, Vol. 33, No. 3, Article 7, Publication date: August 2015.
１． はじめに
DRAM と、その前の、コアメモリは、オペレーティングシステムの最初期から、ストレージシステムにおいて重要な役割を果たしてきました。例えば、１９７０年台の UNIX の初期バージョンは、メモリ上のバッファのキャッシュを使って、ファイルシステムの性能を高めました[Ritchie and Thompson 1974]。この１５年にわたって、ストレージシステムにおける DRAM の使用は、大スケールのウェブアプリケーションの要求に迫られて、加速してきました。これらアプリケーションは、とても大きなデータセットを操作し、その負荷は、ディスクとフラッシュだけでは満足できません。この結果、アプリケーションは、長期に渡るデータをますます多く DRAM に置くようになっています。２００５年までには、全ての著名なウェブ検索エンジンはその検索インデックスを全て、DRAM に置きました。また、memcached [Memcached 2011] のような大規模なキャッシュシステムが Facebook, Twitter, Wikipedia, そして YouTube などのアプリケーションのために広く使われるようになりました。
DRAM の役割は増していますが、アプリケーション開発者にとって、DRAM ベースのストレージの完全な性能ポテンシャルを捉えるのはいまだ、難しいです。多くの場合、DRAM はデータベースのような何か他のストレージシステムのキャッシュとして使われます。このアプローチは、開発者がキャッシュと元となる記憶域の一貫性を管理するように強制します。そしてその性能は、キャッシュミスと元となる記憶域のオーバーヘッドによって制限されます。他の場合には、DRAM はアプリケーション固有の方法で管理されます。それは高性能を提供しますが、開発者に高い複雑性のコストを課します。Redis [2014] と Cassandra [2014] のようないくつかの最近のシステムは、DRAM にあるデータをアクセスするための汎用の機能を提供し始めました。しかしそれらの性能は、DRAM ベースのストレージの完全な性能ポテンシャルとは遠いです。
この論文は、RAMCloud を述べます。それは汎用の分散ストレージシステムであり、常に、全てのデータを DRAM に持ちます。RAMCloud は全部で３つの属性を組み合わせます。低遅延、大規模、そして永続性です。最先端のネットワークの元で使われた場合、RAMCloud は、遠隔アクセスを極めて低遅延で提供します。我々の QDR Infiniband を使った８０ノードの開発クラスタでは、クライアントは任意の１００バイトのオブジェクトを５マイクロ秒以下で読むことができ、永続的ライトは１３．５マイクロ秒ほどかかります。100,000 ノードのある大きなデータセンターで、小さなリードは１０マイクロ秒以下で終わることを期待でき、それは今日、一般的に使われているストレージシステムに比べて５０から１０００倍、速いです。
RAMCloud の２つめの属性は、大規模です。未来のウェブアプリケーションをサポートするために、私達は RAMCloud を、クラスタが少なくても 10,000 サーバまで増加しても良いように設計しました。RAMCloud はそれら全てのメモリを一つのコヒーレントなキーバリューストアにまとめ上げます。これにより、ストレージ容量は、１PB 以上にできます。
RAMCloud の３つめの属性は、永続性です。RAMCloud は全てのデータを DRAM に持ちますが、それはさらにデータのバックアップコピーを二次記憶域に維持し、高レベルの永続性と可用性を保証します。これにより、アプリケーション開発者は、個別の永続的ストレージシステムを管理したり、あるいはメモリ上と永続的ストレージとの間の一貫性を維持する必要から解放されます。
RAMCloud のような低遅延ストレージシステムが、大規模なデータセットを現在可能な負荷を超えて操作するアプリケーションの新しいクラスの開発を刺激することができればと願います。２節は、現在のストレージシステムの高遅延がいかに、大規模アプリケーションを制限しているかを示して、RAMCloud の動機を示します。３から９節は、RAMCloud のアーキテクチャを示します。それは、遅延、スケール、そして永続性という問題を解決するための３つの異なる視点から行われます。
ストレージ管理。RAMCloud は、同じログストラクチャードアプローチを使って、メモリと二次記憶域にあるデータ両方を管理します。これにより、バックアップコピーは効率的に作ることができ、RAMCloud は複製されたディスクの永続性と、DRAM の低遅延を提供できます。ログストラクチャードアプローチはまた、クラッシュリカバリを単純にし、malloc のような伝統的記憶域アロケータに比べて二倍、効率的に DRAM を使うこともできます。RAMCloud は、ログクリーニングに、独特の２レベルアプローチを使います。これは、DRAM 領域利用率を最大化するとともに、二次記憶域への I/O バンド幅要求を最小化します。
遅延。RAMCloud は、パケットを送受信するために NIC と直接、通信することで、カーネル呼び出しと割り込みに関連するオーバーヘッドを避けます。また、来るパケットを待つために、ポーリングアプローチを使います。低遅延を達成するための私達の最大の挑戦は、最適のスレッドアーキテクチャを見つけることでした。現在の実装は、許される柔軟性のレベルを提供するために、大きな遅延のペナルティを払います。
クラッシュリカバリ。クラッシュリカバリ問題は、RAMCloud の設計のほぼ全ての側面に影響しました。遅延にインパクトを与えることなく、高レベルの永続性と可用性を達成することは特に挑戦的でした。RAMCloud は、冗長な複製をオンラインで DRAM に維持する代わりに、クラッシュの後、素早く（典型的には１から２秒で）失われたデータを再構成することで高可用性を提供するという点で、普通とは違うアプローチを取ります。それは、バックアップデータをクラスタ全体にばらまき、二次記憶域からデータを回復するために数百の同時実行してはたらくサーバを使うことによる速いクラッシュリカバリを実装します。
私達はこの論文で述べる全ての機能を実際に動作しているシステムに実装しました。それは、実際のアプリケーションに使うことのできる十分に高い品質を持っていると私達は期待します。RAMCloud ソースコードは自由に入手可能です。この論文は、２０１４年９月時点の RAMCloud 1.0 に対応します。表１は、鍵となるいくつかの性能測定結果をまとめました。これらについては、論文の残りでより詳しく議論します
私達の RAMCloud の紹介において、いくつかのテーマが、繰り返し現れます。最初のテーマは、ランダム化の使用です。RAMCloud がスケーラブルであるために、それは出来る限り、中央集権的機能を避けなくてはいけません。そして私達は、ランダム化は、単純でかつ、効果的な分散アルゴリズムを作るためのパワフルなツールであることに気が付きました。２つめのテーマは、私達が、システム全体にわたって、対処が必要な独立したエラーケースを最小化するように努めたことです。それは、フォールトトレランスの複雑さを減らすためです。６節で、これが、エラーの対処を、とても高いレベルあるいはとても低いレベルで行うことをしばしば意味することを議論します。３つめのテーマは、システムの設計が、メモリ容量やネットワーク速度のような元となる技術のスケーリングによっていろいろな方法で影響を受け続けたということです。技術のインパクトは、複数の技術が異なる割合で進化するときに特に厳しいです。２節は、均一でないスケーリングが、RAMCloud の開発をどのように動機付けたかを議論します。そして、１０節はそれがまたどのようにシステムを制限するかを述べます。
以降は、論文からの抜粋と、私の感想です。
このプロジェクトは、２００９年から始まり、この論文は２０１５年に出た、いわば総括です。トランザクションサポートなど、進行中の課題もあり、終わったわけではないようです。
オブジェクトというか、レコードはテーブルに属します。キーは６４KB まで、値は１MB までです。オブジェクトは、キーのハッシュで、ノードに分散配置されます。あるノードにあるテーブルの一部を、タブレットと呼びます。
コーディネータノードが１台あり、テーブルの配置からクラスタメンバーシップ他を、維持します。ZooKeeper もしくは、LogCabin にそれを格納します。コーディネータが落ちたら、スタンバイのコーディネータが代わりを努めます。
クライアントライブラリは、まず、コーディネータに問い合わせて、実際にオブジェクトを持つストレージサーバにアクセスします。情報はクライアントライブラリでキャッシュされます。無効になったらクライアントでリトライします。
この論文での最大構成は、８０ノード、それぞれが４０GB のメモリを持つので、総計３．２TB です。ノード間接続は、 Infiniband, ノードのディスクは SSD です。TCP ソケットを普通に使う実装もあります。
オブジェクトはキーのハッシュで決まるマスターノードのメモリに書かれた後、デフォルト３つのノードの二次記憶域に書かれます。二次記憶域のデータは、マスターノードが落ちてメモリが失われた時にだけ使われます。これらバックアップへの書き込みは、ディスクのライト完了を待ちません。電源喪失しても、フラッシュする時間くらいはあるだろう、と論文にあります。ずるい。
強一貫性 strong consistency をサポートする、とありますが、これで大丈夫なのでしょうか。オブジェクト書き込みは、 raft, zab のコンセンサスプロトコルを使わないのでしょうか。ログのシーケンス番号が大きければいいのでしょうか。クライアントが読み書きするのは、マスターだけなので、複製の同期、という問題は無いのでしょうか。
マスターノードが落ちた時の回復は独特です。４０GB のメモリを持つとした時、そのバックアップが一つのディスクにあるならば、SSD でも１秒で４０GBは読めません。コーディネータは、複数のリカバリマスタを選び、失われたメモリの一部分の回復を任せます。メモリは８MB のセグメントごとに、クラスタ内のノードに分散してバックアップされています。リカバリマスタは、自分の担当のメモリのバックアップを持っているノードのディスクから回復します。クラスタのノード数が増えれば、リカバリマスタも増え、読むディスクも増えるため、回復時間は、１，２秒で済む、スケールする、というしかけです。回復で使う複製は、一つだけを選びます。
以上