本当は恐ろしい分散システムの話

Copyright©2017 NTT corp. All Rights Reserved.
本当は恐ろしい分散システムの話
2017年10月30日
NTT ソフトウェアイノベーションセンター
分散処理基盤技術プロジェクト
熊崎宏樹@kumagi

2Copyright©2017 NTT corp. All Rights Reserved.
諸説あるが、ここでの定義は「部分的な故障を許容するシステム」の事
複数台のコンピュータを接続して信頼性を高めたり
データが途中で化けても再送したり訂正したり
一部のコンピュータが突然故障しても引き継いだり
故障を設計の一部に組み込む事が必須となる
分散システムとは

• 世はまさに分散システム戦国時代
• Hadoopを皮切りに次々出てくる巨大分散OSS
• シリコンバレーでも分散ミドルウェアベンチャーが多数出現
• 高信頼なシステムを作ろうと思った場合には複数台のマシンによる高可用構成
が前提になる
• Google、Facebook、Amazon等はもちろん
• 金融、流通などのエンタープライズな領域でも当然前提となる
• 大抵のWebサービスも高信頼が期待される
• NTTグループももちろん例外ではない
分散システム everywhere

Google社でのマシンクラスタの一年
• ネットワーク再接続：2日スパンで5%のネットワークが張り替えられる
• 20回ラックが壊れる：40～80マシンが唐突に消失し復旧に1～6時間
• 5回ラックが動作不安定：40～80マシンが50%のパケットロス
• 8回のネットワークメンテ：30分程度ランダムでネットワークが落ちる
• 12回のDNSリロード：数分使えなくなる
• 3回のルータ故障：1時間程度トラフィックを大規模に変更しないといけない
• 何十回もDNSが謎の遅延
• ～1000マシンが壊れる
• 数千ディスクが壊れる
• 遅いディスク、不良メモリ、設定ミス、初期不良などなど
• DC間通信もいろんな理由（野犬・サメ・酔ったハンター(!?)）で途切れる
ハードウェアは壊れる
https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiP04LkvZ
bXAhUCXbwKHX14B3kQFggnMAA&url=https%3A%2F%2Fresearch.google.com%2Fpeople%2Fjeff%2FStanford-DL-
Nov-2010.pdf&usg=AOvVaw1N1pT7z_TQRmehAK0r-OPV

• MTBF(平均故障間隔時間)が30年あるマシンを使うとすると
• 30台を同時に動かすと年間1台壊れる
• 10000台を同時に動かすと毎日1台壊れる
• なおMTBF30年は高信頼なメインフレーム級
• MTBFを2倍にしても頻度が半分になるだけ
• 高速な処理をしようと思ったら台数も使うので当然壊れやすくなる
信頼性はソフトウェアで作れ！
壊れにくいハードウェアを使えば良いのか？
オススメ資料 http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf

Microsoftのデータセンタでは
• 毎日5.2個の装置が壊れる
• 40.8本のリンクが壊れる
• 復旧平均時間(Mean Time to Repair)は5分から1週間
• 1障害あたりおよそ59,000個のパケットが消失
• ネットワークの冗長構成を取ってもエラー率が43%減るだけ
HPのマネージドネットワークのサポートチケットを見ると全顧客の中で
• 優先度最高のネットワークは平均2時間45分の長さの障害が発生し
• 優先度関係なしに平均4時間18分の障害が起きる
AmazonのDynamoはそもそも伝統的なデータベースの複製手法がAmazon
内のネットワーク分断に耐えられないというのが出発点(察し)
ネットワークは壊れる
https://www.microsoft.com/en-us/research/publication/understanding-
network-failures-data-centers-measurement-analysis-implications/
http://citeseerx.ist.psu.edu/viewdoc/summary
?doi=10.1.1.472.5105

「ネットワーク構成エラー、ブラック
ホール、パケット消失、ブラウンアウト
は業界全体にまたがる議題である」
ネットワークは壊れる
http://perspectives.mvdirona.com/2010/04/stonebraker-on-cap-theorem-and-databases/

• 分散システムの故障時の挙動を議論する際の有名な分類法
• Consistency(一貫性)：データの一貫性が壊れない。つまり書き込みが消えたりしない
• Availability(可用性)：システムが応答を返してサービスが利用できる
• Partition Tolerance(分断耐性)：クラスタ内のネットワークが遮断しても耐える
• この頭文字CAPのうち、2つまでしか原理的に満たせない、とする定理
• ネットワーク遮断時の挙動として一貫性を取るか可用性を取るかの2択を主に論じる
• ツッコミどころは多数ある
• ネットワークが遮断しても耐えるって時点で可用性を満たしているのでは
• ネットワークが遮断された場合、多数派が生き残ってサービスを継続し、少数派が死んだ場合そ
れは耐えたと呼べるのか？
• 耐えるの定義が曖昧？
• あまりこの言説に振り回されてはいけない
• 一部のシステムの一部の側面しか切り取って議論できていない
CAP定理
https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86

Partitionに耐えると言ったな？
• 分散システムのOSSの多くも障害時の挙動を定義している
• Redis Sentinelという仕組みで障害発生時もセーフと言っているRedis
障害耐えます！
データ消えません！
CAPのうちCPです！

• 仮想マシン(物理マシンやLXCコンテナも選択可能)とiptablesを用いて意図的
にネットワーク障害を再現するFault Injection Test
Jepsen Test
https://aphyr.com/posts/281-jepsen-on-the-perils-of-network-partitions

• みんなで書き込んでみる
R1 R2 R3 R4 R5
0,5,10,15… 1,6,11,16... 4,9,14,19……. ….

R1 R2 R3 R4 R5
0,5,10,15… 1,6,11,16... 4,9,14,19……. ….
Redisクラスタ全てにデータが複製されていく

• ファイヤウォールを挟み込んでみるも書き込みが続く
• なおこの間もクライアントには書き込み成功というAckが返る
Partitionさせてみる
R1 R2 R3 R4 R5
0,5,10,15… 1,6,11,16... 4,9,14,19……. ….

• しばらくしてRedis Sentinelがクラスタの大きい方に書き込むよう指示する
R1 R2 R3 R4 R5
0,5,10,15… 1,6,11,16... 4,9,14,19……. ….

ファイヤウォールを撤去してRedisに対して問い合わせしてみると
合計2000件の書き込みリクエストのうち
成功と返ってきたのが1998件
実際に保存されていたのが872件→書いたデータの56%が消えた！
R1 R2 R3 R4 R5
https://aphyr.com/posts/283-jepsen-redis

これに対しRedis作者は
「良い攻撃だ。
システムとしてSplit-Brainに耐えるためにはRedis
Sentinelは仕組みとして最適解とは思えないし、ここに
更に改良を加えて穴を塞ぐ、例えば少数派になった
Masterが書き込みを拒否するなどは現実的ではない
(注：なおこれは後日実装された)。
だがそもそも壊れたマシンから正しくFail Overするため
に作ったのがRedis Sentinelであって、ユーザお手製の
スクリプトで同じような事をするよりは依然として99%
マシな選択肢である。」
@antirez
http://antirez.com/news/55

•分散システムのネットワークを分断していじめてみるとい
ろんなシステムが意外とあっさりと壊れる
•「CAPのうちAとPを採用しています！」とか謳っていても
そのAすら守れていない事が割とある
•異常系の挙動はバグの温床なので掘ってみると楽しい
• http://jepsen.io/services によると、分散システムのコンサル
ティングのサービスなども展開しているので興味のある人はぜひ
ここまでのまとめ

• いろんなデータストアを壊している
• Consulやetcdなどはやはり壊れにくい
• MongoDBは壊れる
• PostgreSQLのレプリケーションも不味い
• MariaDB+Galera ClusterはAnomalyが起
きる
• CassandraのCRDTは良さそうだが
Lightweight Transaction含めてAPとしても
CPとしても不味いバグがいくつも見つかったの
でDataStaxのチームがJepsenTestを取り入
れるに至った
Jepsen Testの一連のブログポスト群
https://aphyr.com/tags/Jepsen

分散システムは実は危うい綱渡り

• システムに障害(Fault)を意図的に注入(Inject)するテスト
• 異常時の挙動を観察できる
• 分散システムは複雑なので、様々なレイヤーで様々な異常が注入されうる
Fault Injection Testとは？(1/2)
システムコール
NICドライバ DISKドライバ
プロトコル
スタック
ファイルシステム
ブロックデバイス
アプリケーション
プロトコル
スタック
Jepsen Test

• 原理的にはあらゆるレイヤーの境界に異常を入れ込む事ができる
• アプリケーションの掌握範囲が定義できる部分でソフトウェアの品質を評価す
る事ができる
Fault Injection Testとは？(2/2)
プロトコル
スタック
プロトコル
スタック
Jepsen Test

• 分散システムの故障箇所はネットワークだけとは限らない
• ディスクも壊れるしそこまでの境界もどこかが壊れるかもしれない
Disk故障
プロトコル
スタック
プロトコル
スタック

• 153万台のHDDを41カ月走らせたら合計400,000ブロック以上でチェックサ
ム不整合
• 出典:An Analysis of Data Corruption in the Storage Stack
• 100万台のHDDを32カ月走らせたら8.5%のニアラインディスクと1.9%の
エンタープライズディスクで1つ以上のエラーか潜在エラー
• 出典:An Analysis of Latent Sector Errors in Disk Drives
HDDもSSDも壊れる！

• RAID-1やRAID-5を組めばマシになるとは言えせいぜい
数倍程度
• 壊れるものは壊れる
• 3多重などで保存する分散ストレージは多い
• ソフトウェアのレイヤーで多重化するのは当たり前
• これによってハードウェアの故障に耐えると主張する
• しかしディスク内のデータが壊れる事に対して無力な分散
システムが割とある
• ファイルシステム層でのFault Injectionによってディス
ク故障時の分散システムの挙動を観察するという研究
冗長性があることは耐障害性を意味しない！
Redundancy Does Not Imply Fault Tolerance:
Analysis of Distributed Storage Reactions to
Single Errors and Corruptions

• errfsというファイルシステムを使って、嘘のエラーや化けたデータをアプリ
に見せる
• これによってここより下のレイヤーでの故障も表現できる
Diskの故障を再現(1/2)
プロトコル
スタック
プロトコル
スタック
errfs

• 書き込まれたデータがディスク上で化けたり、読み書きの際にエラーが発生す
る状況をファイルシステムで再現する
Diskの故障を再現(2/2)
プロトコル
スタック
errfs
X=10
プロトコル
スタック
errfs
X=?
X=0

• ext4やxfsはデータのチェックサムを行わないのでディスク内のデータが化けてもお
構いなしにアプリに見せてしまう
• つまり化けたデータが読める実験設定は妥当
• btrfsやzfsはチェックサムを行うので化けたデータがユーザに見える前に読み出しエ
ラーとして報告できる
• zfsはcopiesパラメータ次第で故障に耐える事もできるそうだが実験スコープ外
• ファイルシステムそのもののメタデータは壊さない
• そこが壊れたときに耐えるかはファイルシステムの責任でありアプリのバグと切り分けにくくなる
• 状況を分けてそれぞれで挙動をテスト
• 「読んだらデータが0化けしてる」
• 「読んだらデータがランダムになってる」
• 「読もうとしたらIOエラーで拒否される」
• 「書こうとしたら読み込みオンリーのファイルシステムだからと拒否される」
• 「書こうとしたらディスクに空き容量がないからと拒否される」
• 化けるデータを持っているのはクラスタ内のリーダーなのか、単一プロセスもしくは
ミドルウェア全体の観点から見て壊れるか、どのファイルが壊れるかを個別に調査
• 一度に化ける/壊れるエラーは一か所だけ。少なくともこれは耐えて欲しい。
実験設定

• 定期的にディスクにデータを保存するインメモリストレージRedis
• 保存したデータが化けたらどうなる？
• 一箇所ぐらいは耐えて欲しい
永続化すると言ったな？
障害耐えます！
データ消えません！

• ユーザデータの中でも最近の操作を保存するappend only fileを対象に
チェックサムをしていないので壊れたデータがそのまま放置される
• そのファイルの中身が再同期によってLeaderからFollowerに上書きされる
• Leaderのデータ化けがそのままFollowerに伝搬
Redis with errfs(1/4)
Leader Follower Follower

• ユーザデータの中でも最近の操作を保存するappend only fileを対象に
チェックサムをしていないので壊れたデータがそのまま放置される
• そのファイルの中身が再同期によってLeaderからFollowerに上書きされる
• Leaderのデータ化けがそのままFollowerに伝搬
• ユーザが読みに来たらもちろん壊れたデータが読める
Redis with errfs (2/4)
ギャー！！

• redisメタデータの中でもappend only fileのRedisメタデータが壊れた場合
が致命的で、プロセスがクラッシュ
• フォロワーがクラッシュする分には全体にとって問題はない
ぐえっ

• redisメタデータの中でもappend only fileのRedisメタデータが壊れた場合
が致命的で、プロセスがクラッシュ
• フォロワーがクラッシュする分には全体にとって問題はない
• リーダーのappend only fileのメタデータが壊れた場合、タイミングによっ
てリーダーがそれを転送してからクラッシュするのでクラスタ全体仲良く全員
クラッシュする悲惨な事態に
ギョエー！

Leader Follower
メタデータ化けクラスタ丸ごと死亡クラッシュ
ユーザデータ化け
化けたデータがユーザから観測される
更に化けデータが伝播
リーダー昇格時に化
けデータ観測
Redisのディスク障害挙動まとめ
Ｎ多重で保存しているのに、1箇所の故障がＮ多重全部壊すことがある

これに対しRedis作者は
「AOFの全エントリにチェックサムつけるのはサイズも膨
れるので、やるにしてもオプトインだと思う。
Redis4系ではCRC64を全エントリにつけようかと思って
いる（注: これは実際に実装された）」
@antirez
https://github.com/antirez/redis/issues/3730

• ZooKeeper v3.4.8: リーダーのディスクがいっぱいになってもリーダーの変更が行
われないので延々とクライアントにはエラーを返しつつリーダー引き継ぎが起きずシ
ステムが読み出しオンリーになってしまった
• Kafka v0.9: リーダーのreplication_checkpoint_tmpのwriteに失敗すると
リーダー変更も起きずにシステム丸ごと利用不能になった
• MongoDB v3.2.0: しっかりチェックサムしているので目立ったエラーがないし、
リーダーがクラッシュせず自主的に降格してデータ復旧したりする。だがディスクが
いっぱいのときにジャーナルを書けないとクライアントに失敗と返す（ディスクが
余っているフォロワーにリーダーを引き継いでも良さそうではある）
• CockroachDB beta-20160714: 大抵クラッシュするけどRaftでリーダーが代替
わりして復旧する。でもリーダーのデータが化けるとRedis同様にフォロワーに伝搬
してクラスタごと崩壊する
• Cassandra v3.7: チェックサムをしていないがデータ圧縮モードの時だけ展開失敗
でエラーに気づける。読み出しの際にダイジェストの不一致を検知したら一番最近の
タイムスタンプを持つデータで上書き (Read-Repair)しに行くので、そのデータが
化けてたら化けデータが伝搬する
他のシステムたち

• 割と名の知れた分散システムでも平気で壊れている事はある
• どれもコミュニティに報告して何かしらの対応はしてもらっている
• システム毎に戦略は様々だが、みんな大なり小なり壊れている
• ZKがAdler32というチェックサムを使っているが衝突しがちで良くなさそう？
• データ化けを検出した場合、プロセス単体ではクラッシュするのがよくある
• クラッシュ後の再起動でデータを読んで再度クラッシュするから永久に立ち上がれないケースがあっ
てつらい
• ZooKeeper,MongoDB,LogCabinはデータ化けが発生したらリーダーから降格する仕組みまで作り
こんであってすごい
• 特にZKはクラッシュするのはわざとではないらしい
• 一方、化けたメタデータをクラスタ中にまき散らしてパンデミックする奴もいる
• ファイル作成に失敗したときに無限リトライしてディスクリプタ使い果たすZooKeeperさん…
• リカバリの仕方も様々で、手元のログだけから化けた部分を切り捨てるKafkaや、隣
のマシンから正しいデータを貰うZooKeeperなど差がある
• せっかく冗長構成しているんだから有効活用すればいいのにね
• ReadRepairや再同期やリーダー選出の過程で化けたデータが伝搬する事がよくある
から気をつけるべし
• 読み出したデータ間で食い違いがあった際に、最新タイムスタンプで上書きするのがReadRepair
考察

• ストレージのデータは容易に化ける一方で化けるものだという前提で作りこま
れていないシステムが多い
• 「多重で保存しているから多少壊れても大丈夫です」と言われたら疑ってかか
るべき
• 壊れたデータをご丁寧に伝搬するケースさえある
• 壊れたら壊れっぱなしとか、単一プロセスでのリカバリーとの区別が曖昧で最新データが共
有されないケースも多い
• 異常時の挙動について定義・ドキュメント化すらされていないものが多い
• これは作者やコミュニティと一緒に仕様を策定しなくてはならない
• 例えば3多重のデータの全部が壊れている場合などの諦め方など
ここまでのまとめ

故障が伝搬しないように
分散システムを作る事すら
実はまだ人類には難しい

• 異常を注入すれば異常時の挙動の知見が貯まるが、どんな異常でも良いわけで
はない
• 全プロセスを同時に強制的にkillしてもシステムは停止するが知見は得られない
• ソフトウェアとユーザの間には何らかの「契約」があり、そこの境界付近こそ
探る価値がある
• 契約あるところにFault Injectionあり
進撃のFault Injection

• データベースが満たす特性の金字塔
• Atomicity: トランザクションは完全に行ったか全く行われないかのどちらか
• Consistency: 一貫性のある状態にしかならない
• Isolation: 実行途中のトランザクションが他のトランザクションから観測されない
• Durability: ユーザに完了を報告したトランザクションは電源が落ちようが消えない
• これはユーザとの契約の一つである
ACIDトランザクション

• DBMSを過酷な環境に置いて本当にACIDを守っているかを確認する
• データを化けさせるのは一切なし
• 任意の瞬間に電源が落ちた状況だけ模倣する
• ACIDという概念はデータ化けに関しては触れていないので契約外の問題
• ファイルシステムとデータベースのそれぞれのレイヤーで仕様理解ミスなどで
適切なディスクIOを発行できずにACIDを満たせないパターンを探索する
• この過程をTorturing(拷問)と呼ぶ
Torturing Databases for Fun and Profit
https://www.usenix.org/node/186197

iSCSI経由でデータベースを駆動させ、その過程で発行されたiSCSIレベルでの
コマンドを全て記録していく
Torturing Databases for Fun and Profit概要(1/4)
ファイルシステムsyscall
read()
write()
fsync()
iSCSI
IOコマンドを記録

記録された系列の途中のポイントまでをリプレイした別のハードディスクを作る
ファイルシステムsyscall
read()
write()
fsync()
iSCSI

リプレイされたディスクの上でシステムを起動すると、電源断のときと同じよう
な挙動を経て(fsck,DBのシステムリカバリ)再びＤＢが使えるようになる
そのDBにACID違反がないか検査
ファイルシステムsyscall iSCSI
fsckrecovery

これを様々なリプレイ断面で試していくと、DBがACIDに違反している事を見
つける事ができる
ファイルシステムsyscall iSCSI
fsckrecovery

• 本当に全断面を探索すると時間が掛かりすぎるので、効率的にACID違反が見
つかる勘所を優先的に探す
• 同じLBAに何度も書いている場合メタデータの可能性が高い
• LBAが急に飛んだ場合、B+ツリーのsplitとかヘッダの可能性が高い
• 1つのSCSIコマンドの上で複数のブロックに書いている場合headコマンドで暗黙のうちに
atomicに動く事を期待し勝ち
• ファイルを切り替えている場合、内部で複雑な事をしているからバグの温床
• mmap使ったデータが書き戻される瞬間は大抵意図的ではない
• なおこれらの勘所は全件探索から見つけた
• 可能性の高そうな断面をスコア付けしてスコアが高い順に試すと効率的に
ACID違反を見つけられる
• ファイルシステムによる挙動の差でリカバリーできる場合とできない場合も比
べる事ができる
細かい話

ユーザとの契約を守れていない状況一覧

ユーザとの契約を守れていない状況一覧
NTFS上でしか動かなくて名前を隠す必要があって有名な謎の商用ＤＢがDurability違反
完全に無傷と言えたのはXFS上のLMDBとKVS-Aだけ
TokyoCabinetはmmapを誤用している箇所があって
未コミットでリカバリ不能なデータがディスクに書き戻されてしまう

ACIDすら守る事は難しい

• ACIDも契約である以上はFault Injectionの対象とすることができる
• 電源断時の挙動は頻度こそ低いが自動的にテストしやすい部類ではある
• 日頃お世話になっているデータベースも踏み抜かれていないバグはある
• この実験で判明したバグはおよそ停電からの復旧時にのみ見つかる系統のバグ
• データベース実装者であってもシステムコールの細かい挙動を把握しきってい
ないと見られるケースが多々あった。
• なおこれらのバグは軒並み実装者へ報告した所ポジティブな回答を得られたとのこと
データベースの拷問まとめ

• 手元の環境では動くけれどお客さんの環境に持っていったら何故か動かない
• 分散システムの世界でも「テストでは耐えるのにプロダクション環境では何故
か耐えない」という問題に対策しなくてはならない
システムエンジニアあるある

• Netflix社はプロダクション環境で異常系機能が正しく働く事を確認する方法
としてChaos Engineeringを提唱している
• 顧客が触れる環境を直接破壊するので一見して狂気の沙汰に見えるが、それを
遂行する度量がすごい
その猿、凶暴につき

• データセンタ内のマシンをランダムに選んで強制シャットダウンさせる狂気的
プログラムChaos Monkey
• 兄弟分にAWSリージョン丸ごと落とすChaos Kongなどもいる
• 良く調べてみると狂気ではないエンジニアリングの一環
• 書籍Chaos Engineeringから抜粋して紹介
その猿、凶暴につき
https://github.com/Netflix/chaosmonkeyhttp://www.oreilly.com/webops-perf/free/chaos-
engineering.csp

• Netflixのサービス内インフラはマイクロサービス化されており、個々のマイ
クロサービス毎に部署が存在し、その信頼性に責任を負っている
• 下の図は想像で補った
NetflixのChaos Engineering
課金部
動画フロント部
推薦部動画管理部
セール情報部

• もし推薦部が壊れたら顧客単位での推薦を諦めてただの売上ランキングで代用
• このようにChaos Engineeringに失敗した場合でも、どうやったら顧客への影響を最小化
できるか(Blast Radiusの最小化)を常に検討する
課金部
動画フロント部
推薦部動画管理部
セール情報部

• カナリア分析
• 新規コードを入れる際には小さなクラスタを作り、そちらに一部のトラフィックを振り分け
る形で実装する（おそらくロードバランサの仕事）
• その小さなクラスタと既存のクラスタの間で様々なメトリクスを比較し、極端な差異がない
事を自動的に確認する仕組みがある
Load Balancer
既存クラスタ新コード環境
VM VM VM VM VM VM
同じかな？

• Chaos Engineeringの導入は複数のステップから成る
1. 何がそのサービスの正常稼働をメトリクスなのかを明らかにする
• Netflixの場合その一つに顧客が動画を再生開始した毎秒の合計回数を表すStream-start Per
Second(SPS)を採用
2. それらのメトリクスを一望できるモニタリング環境を作る
3. 異常系での挙動の仮説を組み立てる
4. その仮説を検証できる破壊範囲最小の異常系動作を設計する
5. 試験環境で手動テストする
6. 落ちたら本当に困る部分のサービスは即座に正常な環境へ切り戻す措置を用意する
7. プロダクション環境で手動テストして挙動をモニタリングする
8. 充分自信が持てたらランダムでテストが発生するプロダクション環境に放り込む
• いきなり最後のステップに挑んではいけない
サルと和解せよ

Uberの経験
https://www.youtube.com/watch?v=kb-m2fasdDY
• Uberの中の人が登壇している動画「GOTO 2016 • What I Wish I Had
Known Before Scaling Uber to 1000 Services • Matt Ranney」に
よると、Uberの人々はChaos Monkeyを初めとする異常系テストをどちらか
というと憎んでいるとのこと
• この動画はそこ抜きにも面白い
• 性能のかじ取りが難しいとか

• それでも頭の固い人は言う「プロダクション環境で壊すなんて狂気の沙汰だ」
• Chaos Engineeringには2つの軸があると主張する
SophisticationとAdoption
Sophistication
Adoption
？

• Sophistication(洗練さ)とは異常耐性部分の成熟度を示す
• Elementary
• テストは手動でテスト環境のみ
• その故障がビジネスにどの程度の影響を与えるかは検討スコープ外
• 定性的な性質が主眼
• Simple
• プロダクションさながらのテスト環境を整備して試験
• コードベースは自動的にセットアップ可能
• テストの実行や結果は手動集計
• Sophisticated
• プロダクション環境でテストを走らせる
• コードは自動デプロイ、テストも自動実行、結果も自動集計。ビジネス観点での定量的評価
• Advanced
• 異常時の切り戻しまで含めて全て自動化
• 開発の細かなステップでひたすらデプロイ
• 収益に与える影響まで全て集計して報告

• Adoption(採用度)とは企業文化レベルでの受け入れ度合い
• In the Shadows
• 一部の物好きが試しに導入を試みる
• 企業は公式には認めていない
• Investment
• 企業は公式にChaosな実験をしようと言い出す
• 一部の重要なサービスにエンジニアがChaosEngineering用の時間を割くようになる
• Adoption
• Chaos Engineering専用のチームができる
• 異常時のレポートをChaosな回帰テスト向けにフィードバックし始める
• 重要なサービスは確実にChaos実験される
• Cultural Expectation
• 全ての重要なサービスとほとんどの重要でないサービスがChaos実験を行う
• むしろChaos実験は何らかの正当化なしには逃れられない
• この度合いの高さがテストの幅と深さのカバレッジを引き上げる

• Chaos Engineeringはエンジニアに命じればシステムが丈夫にな
る魔法ではない
• 企業の文化のレベルで分散システムの信頼性への投資を決断しての賜物
• エンジニアの努力と周囲の理解の両立が不可欠
何が言いたいのか

• 分散システムの世界は恐ろしい
• 複雑で状況もレイヤーも多岐に渡るため未発見のバグが次々見つかり続ける
• 大抵は再現させる事すら難しいので再現率を上げる方法としてFault Injectionは有力な手
法の一つ
• システムが喧伝する原則すら守れていない物が多い
• 大事な時に限ってこのバグを踏んで七転八倒するのが世の常
• Chaos Engineeringという方法でプロダクション環境の信頼性を高める努力
がある
• キワモノ扱いする人も居るがちゃんと追ってみるとよく検討されている
今日のまとめ
A distributed system is one in which the failure of a computer you
didn’t even know existed can render your own computer unusable.
—Leslie Lamport

• Chaos Engineeringの先陣を切っているNetflixのエンジニアによる書籍
• システムをただ壊せばよいわけではなく、仮説を立て、実験設定を検討し、実際に検証し、
更にはプロダクション環境でもその仕組みが動く事を保障するためにどうするか
• 企業のエンジニアリング文化とどのように折り合っていくかが書いてある
• 本の末尾にJepsenを初めとしたFault Injectionのコードベースが列挙されておりそこから
芋づる式にFault Injection系の情報が出てくる
更に知りたい人は
http://www.oreilly.com/webops-perf/free/chaos-engineering.csp

• このスライドで紹介したバグは現在最新版のOSSでは既に解消されているケー
スが多々あります。詳細は都度ご確認ください。
注意事項

以後予備スライド(質疑応答時間ないから要らなかった)

redis/zookeeper/kafkaの挙動(論文から抜粋)

MongoDB/LogCabin/CockroachDBの挙動(論文から抜粋)

cassandraと凡例(論文から抜粋)

本当は恐ろしい分散システムの話

本当は恐ろしい分散システムの話

Recomendados

Más contenido relacionado

Was ist angesagt?

Was ist angesagt?(20)

Destacado

Destacado(20)

Similar a 本当は恐ろしい分散システムの話

Similar a 本当は恐ろしい分散システムの話(20)

Más de Kumazaki Hiroki

Más de Kumazaki Hiroki(17)

Último

Último(7)

本当は恐ろしい分散システムの話