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

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

4.

5.

ハードウェアは壊れる 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-DLNov-2010.pdf&usg=AOvVaw1N1pT7z_TQRmehAK0r-OPV Copyright©2017 NTT corp. All Rights Reserved. 5

https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiP04LkvZbXAhUCXbwKHX14B3kQFggnMAA&url=https://research.google.com/people/jeff/Stanford-DL-Nov-2010.pdf&usg=AOvVaw1N1pT7z_TQRmehAK0r-OPV

6.

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

http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf

7.

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

8.

http://perspectives.mvdirona.com/2010/04/stonebraker-on-cap-theorem-and-databases/

9.

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

https://ja.wikipedia.org/wiki/CAP定理

10.

11.

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

https://aphyr.com/posts/281-jepsen-on-the-perils-of-network-partitions

12.

13.

14.

15.

16.

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

https://aphyr.com/posts/283-jepsen-redis

17.

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

http://antirez.com/news/55

18.

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

http://jepsen.io/services

19.

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

https://aphyr.com/tags/Jepsen

20.

21.

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

22.

Fault Injection Testとは？(2/2) • 原理的にはあらゆるレイヤーの境界に異常を入れ込む事ができる • アプリケーションの掌握範囲が定義できる部分でソフトウェアの品質を評価する事ができるアプリケーションアプリケーションシステムコールシステムコールプロトコルファイルシステムスタックブロックデバイス NICドライバプロトコルファイルシステムスタックブロックデバイス DISKドライバ NICドライバ DISKドライバ Jepsen Test Copyright©2017 NTT corp. All Rights Reserved. 22

23.

Disk故障 • 分散システムの故障箇所はネットワークだけとは限らない • ディスクも壊れるしそこまでの境界もどこかが壊れるかもしれないアプリケーションアプリケーションシステムコールシステムコールプロトコルファイルシステムスタックブロックデバイス NICドライバ DISKドライバプロトコルファイルシステムスタックブロックデバイス NICドライバ DISKドライバ Copyright©2017 NTT corp. All Rights Reserved. 23

24.

HDDもSSDも壊れる！ • 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 Copyright©2017 NTT corp. All Rights Reserved. 24

25.

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

https://www.usenix.org/conference/fast17/technical-sessions/presentation/ganesan

26.

Diskの故障を再現(1/2) • errfsというファイルシステムを使って、嘘のエラーや化けたデータをアプリに見せる • これによってここより下のレイヤーでの故障も表現できるアプリケーションアプリケーションシステムコールシステムコール errfs プロトコルスタックブロックデバイス NICドライバ DISKドライバプロトコルファイルシステムスタックブロックデバイス NICドライバ DISKドライバ Copyright©2017 NTT corp. All Rights Reserved. 26

27.

Diskの故障を再現(2/2) • 書き込まれたデータがディスク上で化けたり、読み書きの際にエラーが発生する状況をファイルシステムで再現する X=0 X=10 アプリケーションアプリケーションシステムコールシステムコール errfs プロトコルスタックブロックデバイス NICドライバ DISKドライバ X=? errfs プロトコルスタックブロックデバイス NICドライバ DISKドライバ Copyright©2017 NTT corp. All Rights Reserved. 27

28.

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

29.

30.

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

31.

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

32.

33.

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

34.

35.

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

https://github.com/antirez/redis/issues/3730

36.

他のシステムたち • 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)しに行くので、そのデータが化けてたら化けデータが伝搬する Copyright©2017 NTT corp. All Rights Reserved. 36

37.

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

http://mail-archives.apache.org/mod_mbox/zookeeper-dev/201701.mbox/<CAC==nPSLTNobc_GqcrejHYUpxHcNDxBTno [email protected]>

38.

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

39.

40.

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

41.

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

42.

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

https://www.usenix.org/node/186197

43.

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

44.

45.

Torturing Databases for Fun and Profit概要(3/4) リプレイされたディスクの上でシステムを起動すると、電源断のときと同じような挙動を経て(fsck,DBのシステムリカバリ)再びＤＢが使えるようになるそのDBにACID違反がないか検査 fsck recovery syscall ファイルシステム iSCSI Copyright©2017 NTT corp. All Rights Reserved. 45

46.

47.

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

48.

49.

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

50.

51.

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

52.

53.

54.

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

55.

56.

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

57.

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

58.

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

59.

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

https://www.youtube.com/watch?v=kb-m2fasdDY

60.

61.

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

62.

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

63.

64.

今日のまとめ • 分散システムの世界は恐ろしい • 複雑で状況もレイヤーも多岐に渡るため未発見のバグが次々見つかり続ける • 大抵は再現させる事すら難しいので再現率を上げる方法として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 Copyright©2017 NTT corp. All Rights Reserved. 64

65.

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

http://www.oreilly.com/webops-perf/free/chaos-engineering.csp

66.

67.

68.

69.

70.

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

kumagi

関連スライド

分散システムについて語らせてくれ

あなたの知らないハッシュテーブルの世界

C言語で苦しむロックフリー入門（仮

冬のLock-Free祭り

STMの設計と進化

トランザクションの設計と進化

各ページのテキスト