Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

95,784 views

Published on

分散システムのFault Injectionの話

NTTデータテクノロジーカンファレンス2017で発表する際に用いたプレゼン資料
https://oss.nttdata.com/hadoop/event/201710/index.html

Published in: Engineering

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

  1. 1. Copyright©2017 NTT corp. All Rights Reserved. 本当は恐ろしい分散システムの話 2017年10月30日 NTT ソフトウェアイノベーションセンター 分散処理基盤技術プロジェクト 熊崎 宏樹@kumagi
  2. 2. 2Copyright©2017 NTT corp. All Rights Reserved. 諸説あるが、ここでの定義は「部分的な故障を許容するシステム」の事 複数台のコンピュータを接続して信頼性を高めたり データが途中で化けても再送したり訂正したり 一部のコンピュータが突然故障しても引き継いだり 故障を設計の一部に組み込む事が必須となる 分散システムとは
  3. 3. 3Copyright©2017 NTT corp. All Rights Reserved. • 世はまさに分散システム戦国時代 • Hadoopを皮切りに次々出てくる巨大分散OSS • シリコンバレーでも分散ミドルウェアベンチャーが多数出現 • 高信頼なシステムを作ろうと思った場合には複数台のマシンによる高可用構成 が前提になる • Google、Facebook、Amazon等はもちろん • 金融、流通などのエンタープライズな領域でも当然前提となる • 大抵のWebサービスも高信頼が期待される • NTTグループももちろん例外ではない 分散システム everywhere
  4. 4. 4Copyright©2017 NTT corp. All Rights Reserved.
  5. 5. 5Copyright©2017 NTT corp. All Rights Reserved. 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
  6. 6. 6Copyright©2017 NTT corp. All Rights Reserved. • MTBF(平均故障間隔時間)が30年あるマシンを使うとすると • 30台を同時に動かすと年間1台壊れる • 10000台を同時に動かすと毎日1台壊れる • なおMTBF30年は高信頼なメインフレーム級 • MTBFを2倍にしても頻度が半分になるだけ • 高速な処理をしようと思ったら台数も使うので当然壊れやすくなる 信頼性はソフトウェアで作れ! 壊れにくいハードウェアを使えば良いのか? オススメ資料 http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf
  7. 7. 7Copyright©2017 NTT corp. All Rights Reserved. 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
  8. 8. 8Copyright©2017 NTT corp. All Rights Reserved. 「ネットワーク構成エラー、ブラック ホール、パケット消失、ブラウンアウト は業界全体にまたがる議題である」 ネットワークは壊れる http://perspectives.mvdirona.com/2010/04/stonebraker-on-cap-theorem-and-databases/
  9. 9. 9Copyright©2017 NTT corp. All Rights Reserved. • 分散システムの故障時の挙動を議論する際の有名な分類法 • Consistency(一貫性):データの一貫性が壊れない。つまり書き込みが消えたりしない • Availability(可用性):システムが応答を返してサービスが利用できる • Partition Tolerance(分断耐性):クラスタ内のネットワークが遮断しても耐える • この頭文字CAPのうち、2つまでしか原理的に満たせない、とする定理 • ネットワーク遮断時の挙動として一貫性を取るか可用性を取るかの2択を主に論じる • ツッコミどころは多数ある • ネットワークが遮断しても耐えるって時点で可用性を満たしているのでは • ネットワークが遮断された場合、多数派が生き残ってサービスを継続し、少数派が死んだ場合そ れは耐えたと呼べるのか? • 耐えるの定義が曖昧? • あまりこの言説に振り回されてはいけない • 一部のシステムの一部の側面しか切り取って議論できていない CAP定理 https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
  10. 10. 10Copyright©2017 NTT corp. All Rights Reserved. Partitionに耐えると言ったな? • 分散システムのOSSの多くも障害時の挙動を定義している • Redis Sentinelという仕組みで障害発生時もセーフと言っているRedis 障害耐えます! データ消えません! CAPのうちCPです!
  11. 11. 11Copyright©2017 NTT corp. All Rights Reserved. • 仮想マシン(物理マシンやLXCコンテナも選択可能)とiptablesを用いて意図的 にネットワーク障害を再現するFault Injection Test Jepsen Test https://aphyr.com/posts/281-jepsen-on-the-perils-of-network-partitions
  12. 12. 12Copyright©2017 NTT corp. All Rights Reserved. • みんなで書き込んでみる Partitionに耐えると言ったな? R1 R2 R3 R4 R5 0,5,10,15… 1,6,11,16... 4,9,14,19……. ….
  13. 13. 13Copyright©2017 NTT corp. All Rights Reserved. • みんなで書き込んでみる Partitionに耐えると言ったな? R1 R2 R3 R4 R5 0,5,10,15… 1,6,11,16... 4,9,14,19……. …. Redisクラスタ全てにデータが複製されていく
  14. 14. 14Copyright©2017 NTT corp. All Rights Reserved. • みんなで書き込んでみる • ファイヤウォールを挟み込んでみるも書き込みが続く • なおこの間もクライアントには書き込み成功というAckが返る Partitionさせてみる R1 R2 R3 R4 R5 0,5,10,15… 1,6,11,16... 4,9,14,19……. ….
  15. 15. 15Copyright©2017 NTT corp. All Rights Reserved. • しばらくしてRedis Sentinelがクラスタの大きい方に書き込むよう指示する Partitionさせてみる R1 R2 R3 R4 R5 0,5,10,15… 1,6,11,16... 4,9,14,19……. ….
  16. 16. 16Copyright©2017 NTT corp. All Rights Reserved. ファイヤウォールを撤去してRedisに対して問い合わせしてみると 合計2000件の書き込みリクエストのうち 成功と返ってきたのが1998件 実際に保存されていたのが872件→書いたデータの56%が消えた! Partitionさせてみる R1 R2 R3 R4 R5 https://aphyr.com/posts/283-jepsen-redis
  17. 17. 17Copyright©2017 NTT corp. All Rights Reserved. これに対しRedis作者は 「良い攻撃だ。 システムとしてSplit-Brainに耐えるためにはRedis Sentinelは仕組みとして最適解とは思えないし、ここに 更に改良を加えて穴を塞ぐ、例えば少数派になった Masterが書き込みを拒否するなどは現実的ではない (注:なおこれは後日実装された)。 だがそもそも壊れたマシンから正しくFail Overするため に作ったのがRedis Sentinelであって、ユーザお手製の スクリプトで同じような事をするよりは依然として99% マシな選択肢である。」 @antirez http://antirez.com/news/55
  18. 18. 18Copyright©2017 NTT corp. All Rights Reserved. •分散システムのネットワークを分断していじめてみるとい ろんなシステムが意外とあっさりと壊れる •「CAPのうちAとPを採用しています!」とか謳っていても そのAすら守れていない事が割とある •異常系の挙動はバグの温床なので掘ってみると楽しい • http://jepsen.io/services によると、分散システムのコンサル ティングのサービスなども展開しているので興味のある人はぜひ ここまでのまとめ
  19. 19. 19Copyright©2017 NTT corp. All Rights Reserved. • いろんなデータストアを壊している • Consulやetcdなどはやはり壊れにくい • MongoDBは壊れる • PostgreSQLのレプリケーションも不味い • MariaDB+Galera ClusterはAnomalyが起 きる • CassandraのCRDTは良さそうだが Lightweight Transaction含めてAPとしても CPとしても不味いバグがいくつも見つかったの でDataStaxのチームがJepsenTestを取り入 れるに至った Jepsen Testの一連のブログポスト群 https://aphyr.com/tags/Jepsen
  20. 20. 20Copyright©2017 NTT corp. All Rights Reserved. 分散システムは実は危うい綱渡り
  21. 21. 21Copyright©2017 NTT corp. All Rights Reserved. • システムに障害(Fault)を意図的に注入(Inject)するテスト • 異常時の挙動を観察できる • 分散システムは複雑なので、様々なレイヤーで様々な異常が注入されうる Fault Injection Testとは?(1/2) システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション Jepsen Test
  22. 22. 22Copyright©2017 NTT corp. All Rights Reserved. • 原理的にはあらゆるレイヤーの境界に異常を入れ込む事ができる • アプリケーションの掌握範囲が定義できる部分でソフトウェアの品質を評価す る事ができる Fault Injection Testとは?(2/2) システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション Jepsen Test
  23. 23. 23Copyright©2017 NTT corp. All Rights Reserved. • 分散システムの故障箇所はネットワークだけとは限らない • ディスクも壊れるしそこまでの境界もどこかが壊れるかもしれない Disk故障 システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション
  24. 24. 24Copyright©2017 NTT corp. All Rights Reserved. • 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も壊れる!
  25. 25. 25Copyright©2017 NTT corp. All Rights Reserved. • RAID-1やRAID-5を組めばマシになるとは言えせいぜい 数倍程度 • 壊れるものは壊れる • 3多重などで保存する分散ストレージは多い • ソフトウェアのレイヤーで多重化するのは当たり前 • これによってハードウェアの故障に耐えると主張する • しかしディスク内のデータが壊れる事に対して無力な分散 システムが割とある • ファイルシステム層でのFault Injectionによってディス ク故障時の分散システムの挙動を観察するという研究 冗長性があることは耐障害性を意味しない! Redundancy Does Not Imply Fault Tolerance: Analysis of Distributed Storage Reactions to Single Errors and Corruptions
  26. 26. 26Copyright©2017 NTT corp. All Rights Reserved. • errfsというファイルシステムを使って、嘘のエラーや化けたデータをアプリ に見せる • これによってここより下のレイヤーでの故障も表現できる Diskの故障を再現(1/2) システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション システムコール NICドライバ DISKドライバ プロトコル スタック errfs ブロックデバイス アプリケーション
  27. 27. 27Copyright©2017 NTT corp. All Rights Reserved. • 書き込まれたデータがディスク上で化けたり、読み書きの際にエラーが発生す る状況をファイルシステムで再現する Diskの故障を再現(2/2) システムコール NICドライバ DISKドライバ プロトコル スタック errfs ブロックデバイス アプリケーション X=10 システムコール NICドライバ DISKドライバ プロトコル スタック errfs ブロックデバイス アプリケーション X=? X=0
  28. 28. 28Copyright©2017 NTT corp. All Rights Reserved. • ext4やxfsはデータのチェックサムを行わないのでディスク内のデータが化けてもお 構いなしにアプリに見せてしまう • つまり化けたデータが読める実験設定は妥当 • btrfsやzfsはチェックサムを行うので化けたデータがユーザに見える前に読み出しエ ラーとして報告できる • zfsはcopiesパラメータ次第で故障に耐える事もできるそうだが実験スコープ外 • ファイルシステムそのもののメタデータは壊さない • そこが壊れたときに耐えるかはファイルシステムの責任でありアプリのバグと切り分けにくくなる • 状況を分けてそれぞれで挙動をテスト • 「読んだらデータが0化けしてる」 • 「読んだらデータがランダムになってる」 • 「読もうとしたらIOエラーで拒否される」 • 「書こうとしたら読み込みオンリーのファイルシステムだからと拒否される」 • 「書こうとしたらディスクに空き容量がないからと拒否される」 • 化けるデータを持っているのはクラスタ内のリーダーなのか、単一プロセスもしくは ミドルウェア全体の観点から見て壊れるか、どのファイルが壊れるかを個別に調査 • 一度に化ける/壊れるエラーは一か所だけ。少なくともこれは耐えて欲しい。 実験設定
  29. 29. 29Copyright©2017 NTT corp. All Rights Reserved. • 定期的にディスクにデータを保存するインメモリストレージRedis • 保存したデータが化けたらどうなる? • 一箇所ぐらいは耐えて欲しい 永続化すると言ったな? 障害耐えます! データ消えません!
  30. 30. 30Copyright©2017 NTT corp. All Rights Reserved. • ユーザデータの中でも最近の操作を保存するappend only fileを対象に チェックサムをしていないので壊れたデータがそのまま放置される • そのファイルの中身が再同期によってLeaderからFollowerに上書きされる • Leaderのデータ化けがそのままFollowerに伝搬 Redis with errfs(1/4) Leader Follower Follower
  31. 31. 31Copyright©2017 NTT corp. All Rights Reserved. • ユーザデータの中でも最近の操作を保存するappend only fileを対象に チェックサムをしていないので壊れたデータがそのまま放置される • そのファイルの中身が再同期によってLeaderからFollowerに上書きされる • Leaderのデータ化けがそのままFollowerに伝搬 • ユーザが読みに来たらもちろん壊れたデータが読める Redis with errfs (2/4) Leader Follower Follower ギャー!!
  32. 32. 32Copyright©2017 NTT corp. All Rights Reserved. • redisメタデータの中でもappend only fileのRedisメタデータが壊れた場合 が致命的で、プロセスがクラッシュ • フォロワーがクラッシュする分には全体にとって問題はない Redis with errfs (3/4) Leader Follower Follower ぐえっ
  33. 33. 33Copyright©2017 NTT corp. All Rights Reserved. • redisメタデータの中でもappend only fileのRedisメタデータが壊れた場合 が致命的で、プロセスがクラッシュ • フォロワーがクラッシュする分には全体にとって問題はない • リーダーのappend only fileのメタデータが壊れた場合、タイミングによっ てリーダーがそれを転送してからクラッシュするのでクラスタ全体仲良く全員 クラッシュする悲惨な事態に Redis with errfs (4/4) Leader Follower Follower ギョエー!
  34. 34. 34Copyright©2017 NTT corp. All Rights Reserved. Leader Follower メタデータ化け クラスタ丸ごと死亡 クラッシュ ユーザデータ化け 化けたデータがユーザから観測される 更に化けデータが伝播 リーダー昇格時に化 けデータ観測 Redisのディスク障害挙動まとめ N多重で保存しているのに、1箇所の故障がN多重全部壊すことがある
  35. 35. 35Copyright©2017 NTT corp. All Rights Reserved. これに対しRedis作者は 「AOFの全エントリにチェックサムつけるのはサイズも膨 れるので、やるにしてもオプトインだと思う。 Redis4系ではCRC64を全エントリにつけようかと思って いる(注: これは実際に実装された)」 @antirez https://github.com/antirez/redis/issues/3730
  36. 36. 36Copyright©2017 NTT corp. All Rights Reserved. • 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)しに行くので、そのデータが 化けてたら化けデータが伝搬する 他のシステムたち
  37. 37. 37Copyright©2017 NTT corp. All Rights Reserved. • 割と名の知れた分散システムでも平気で壊れている事はある • どれもコミュニティに報告して何かしらの対応はしてもらっている • システム毎に戦略は様々だが、みんな大なり小なり壊れている • ZKがAdler32というチェックサムを使っているが衝突しがちで良くなさそう? • データ化けを検出した場合、プロセス単体ではクラッシュするのがよくある • クラッシュ後の再起動でデータを読んで再度クラッシュするから永久に立ち上がれないケースがあっ てつらい • ZooKeeper,MongoDB,LogCabinはデータ化けが発生したらリーダーから降格する仕組みまで作り こんであってすごい • 特にZKはクラッシュするのはわざとではないらしい • 一方、化けたメタデータをクラスタ中にまき散らしてパンデミックする奴もいる • ファイル作成に失敗したときに無限リトライしてディスクリプタ使い果たすZooKeeperさん… • リカバリの仕方も様々で、手元のログだけから化けた部分を切り捨てるKafkaや、隣 のマシンから正しいデータを貰うZooKeeperなど差がある • せっかく冗長構成しているんだから有効活用すればいいのにね • ReadRepairや再同期やリーダー選出の過程で化けたデータが伝搬する事がよくある から気をつけるべし • 読み出したデータ間で食い違いがあった際に、最新タイムスタンプで上書きするのがReadRepair 考察
  38. 38. 38Copyright©2017 NTT corp. All Rights Reserved. • ストレージのデータは容易に化ける一方で化けるものだという前提で作りこま れていないシステムが多い • 「多重で保存しているから多少壊れても大丈夫です」と言われたら疑ってかか るべき • 壊れたデータをご丁寧に伝搬するケースさえある • 壊れたら壊れっぱなしとか、単一プロセスでのリカバリーとの区別が曖昧で最新データが共 有されないケースも多い • 異常時の挙動について定義・ドキュメント化すらされていないものが多い • これは作者やコミュニティと一緒に仕様を策定しなくてはならない • 例えば3多重のデータの全部が壊れている場合などの諦め方など ここまでのまとめ
  39. 39. 39Copyright©2017 NTT corp. All Rights Reserved. 故障が伝搬しないように 分散システムを作る事すら 実はまだ人類には難しい
  40. 40. 40Copyright©2017 NTT corp. All Rights Reserved. • 異常を注入すれば異常時の挙動の知見が貯まるが、どんな異常でも良いわけで はない • 全プロセスを同時に強制的にkillしてもシステムは停止するが知見は得られない • ソフトウェアとユーザの間には何らかの「契約」があり、そこの境界付近こそ 探る価値がある • 契約あるところにFault Injectionあり 進撃のFault Injection
  41. 41. 41Copyright©2017 NTT corp. All Rights Reserved. • データベースが満たす特性の金字塔 • Atomicity: トランザクションは完全に行ったか全く行われないかのどちらか • Consistency: 一貫性のある状態にしかならない • Isolation: 実行途中のトランザクションが他のトランザクションから観測されない • Durability: ユーザに完了を報告したトランザクションは電源が落ちようが消えない • これはユーザとの契約の一つである ACIDトランザクション
  42. 42. 42Copyright©2017 NTT corp. All Rights Reserved. • DBMSを過酷な環境に置いて本当にACIDを守っているかを確認する • データを化けさせるのは一切なし • 任意の瞬間に電源が落ちた状況だけ模倣する • ACIDという概念はデータ化けに関しては触れていないので契約外の問題 • ファイルシステムとデータベースのそれぞれのレイヤーで仕様理解ミスなどで 適切なディスクIOを発行できずにACIDを満たせないパターンを探索する • この過程をTorturing(拷問)と呼ぶ Torturing Databases for Fun and Profit https://www.usenix.org/node/186197
  43. 43. 43Copyright©2017 NTT corp. All Rights Reserved. iSCSI経由でデータベースを駆動させ、その過程で発行されたiSCSIレベルでの コマンドを全て記録していく Torturing Databases for Fun and Profit概要(1/4) ファイルシステムsyscall read() write() fsync() iSCSI IOコマンドを記録
  44. 44. 44Copyright©2017 NTT corp. All Rights Reserved. 記録された系列の途中のポイントまでをリプレイした別のハードディスクを作る Torturing Databases for Fun and Profit概要(2/4) ファイルシステムsyscall read() write() fsync() iSCSI
  45. 45. 45Copyright©2017 NTT corp. All Rights Reserved. リプレイされたディスクの上でシステムを起動すると、電源断のときと同じよう な挙動を経て(fsck,DBのシステムリカバリ)再びDBが使えるようになる そのDBにACID違反がないか検査 Torturing Databases for Fun and Profit概要(3/4) ファイルシステムsyscall iSCSI fsckrecovery
  46. 46. 46Copyright©2017 NTT corp. All Rights Reserved. これを様々なリプレイ断面で試していくと、DBがACIDに違反している事を見 つける事ができる Torturing Databases for Fun and Profit概要(4/4) ファイルシステムsyscall iSCSI fsckrecovery
  47. 47. 47Copyright©2017 NTT corp. All Rights Reserved. • 本当に全断面を探索すると時間が掛かりすぎるので、効率的にACID違反が見 つかる勘所を優先的に探す • 同じLBAに何度も書いている場合メタデータの可能性が高い • LBAが急に飛んだ場合、B+ツリーのsplitとかヘッダの可能性が高い • 1つのSCSIコマンドの上で複数のブロックに書いている場合headコマンドで暗黙のうちに atomicに動く事を期待し勝ち • ファイルを切り替えている場合、内部で複雑な事をしているからバグの温床 • mmap使ったデータが書き戻される瞬間は大抵意図的ではない • なおこれらの勘所は全件探索から見つけた • 可能性の高そうな断面をスコア付けしてスコアが高い順に試すと効率的に ACID違反を見つけられる • ファイルシステムによる挙動の差でリカバリーできる場合とできない場合も比 べる事ができる 細かい話
  48. 48. 48Copyright©2017 NTT corp. All Rights Reserved. ユーザとの契約を守れていない状況一覧
  49. 49. 49Copyright©2017 NTT corp. All Rights Reserved. ユーザとの契約を守れていない状況一覧 NTFS上でしか動かなくて名前を隠す必要があって有名な謎の商用DBがDurability違反 完全に無傷と言えたのはXFS上のLMDBとKVS-Aだけ TokyoCabinetはmmapを誤用している箇所があって 未コミットでリカバリ不能なデータがディスクに書き戻されてしまう
  50. 50. 50Copyright©2017 NTT corp. All Rights Reserved. ACIDすら守る事は難しい
  51. 51. 51Copyright©2017 NTT corp. All Rights Reserved. • ACIDも契約である以上はFault Injectionの対象とすることができる • 電源断時の挙動は頻度こそ低いが自動的にテストしやすい部類ではある • 日頃お世話になっているデータベースも踏み抜かれていないバグはある • この実験で判明したバグはおよそ停電からの復旧時にのみ見つかる系統のバグ • データベース実装者であってもシステムコールの細かい挙動を把握しきってい ないと見られるケースが多々あった。 • なおこれらのバグは軒並み実装者へ報告した所ポジティブな回答を得られたとのこと データベースの拷問まとめ
  52. 52. 52Copyright©2017 NTT corp. All Rights Reserved. • 手元の環境では動くけれどお客さんの環境に持っていったら何故か動かない • 分散システムの世界でも「テストでは耐えるのにプロダクション環境では何故 か耐えない」という問題に対策しなくてはならない システムエンジニアあるある
  53. 53. 53Copyright©2017 NTT corp. All Rights Reserved. • Netflix社はプロダクション環境で異常系機能が正しく働く事を確認する方法 としてChaos Engineeringを提唱している • 顧客が触れる環境を直接破壊するので一見して狂気の沙汰に見えるが、それを 遂行する度量がすごい その猿、凶暴につき
  54. 54. 54Copyright©2017 NTT corp. All Rights Reserved. • データセンタ内のマシンをランダムに選んで強制シャットダウンさせる狂気的 プログラムChaos Monkey • 兄弟分にAWSリージョン丸ごと落とすChaos Kongなどもいる • 良く調べてみると狂気ではないエンジニアリングの一環 • 書籍Chaos Engineeringから抜粋して紹介 その猿、凶暴につき https://github.com/Netflix/chaosmonkeyhttp://www.oreilly.com/webops-perf/free/chaos- engineering.csp
  55. 55. 55Copyright©2017 NTT corp. All Rights Reserved. • Netflixのサービス内インフラはマイクロサービス化されており、個々のマイ クロサービス毎に部署が存在し、その信頼性に責任を負っている • 下の図は想像で補った NetflixのChaos Engineering 課金部 動画フロント部 推薦部動画管理部 セール情報部
  56. 56. 56Copyright©2017 NTT corp. All Rights Reserved. • もし推薦部が壊れたら顧客単位での推薦を諦めてただの売上ランキングで代用 • このようにChaos Engineeringに失敗した場合でも、どうやったら顧客への影響を最小化 できるか(Blast Radiusの最小化)を常に検討する NetflixのChaos Engineering 課金部 動画フロント部 推薦部動画管理部 セール情報部
  57. 57. 57Copyright©2017 NTT corp. All Rights Reserved. • カナリア分析 • 新規コードを入れる際には小さなクラスタを作り、そちらに一部のトラフィックを振り分け る形で実装する(おそらくロードバランサの仕事) • その小さなクラスタと既存のクラスタの間で様々なメトリクスを比較し、極端な差異がない 事を自動的に確認する仕組みがある NetflixのChaos Engineering Load Balancer 既存クラスタ 新コード環境 VM VM VM VM VM VM 同じかな?
  58. 58. 58Copyright©2017 NTT corp. All Rights Reserved. • Chaos Engineeringの導入は複数のステップから成る 1. 何がそのサービスの正常稼働をメトリクスなのかを明らかにする • Netflixの場合その一つに顧客が動画を再生開始した毎秒の合計回数を表すStream-start Per Second(SPS)を採用 2. それらのメトリクスを一望できるモニタリング環境を作る 3. 異常系での挙動の仮説を組み立てる 4. その仮説を検証できる破壊範囲最小の異常系動作を設計する 5. 試験環境で手動テストする 6. 落ちたら本当に困る部分のサービスは即座に正常な環境へ切り戻す措置を用意する 7. プロダクション環境で手動テストして挙動をモニタリングする 8. 充分自信が持てたらランダムでテストが発生するプロダクション環境に放り込む • いきなり最後のステップに挑んではいけない サルと和解せよ
  59. 59. 59Copyright©2017 NTT corp. All Rights Reserved. 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を初めとする異常系テストをどちらか というと憎んでいるとのこと • この動画はそこ抜きにも面白い • 性能のかじ取りが難しいとか
  60. 60. 60Copyright©2017 NTT corp. All Rights Reserved. • それでも頭の固い人は言う「プロダクション環境で壊すなんて狂気の沙汰だ」 • Chaos Engineeringには2つの軸があると主張する SophisticationとAdoption Sophistication Adoption ?
  61. 61. 61Copyright©2017 NTT corp. All Rights Reserved. • Sophistication(洗練さ)とは異常耐性部分の成熟度を示す • Elementary • テストは手動でテスト環境のみ • その故障がビジネスにどの程度の影響を与えるかは検討スコープ外 • 定性的な性質が主眼 • Simple • プロダクションさながらのテスト環境を整備して試験 • コードベースは自動的にセットアップ可能 • テストの実行や結果は手動集計 • Sophisticated • プロダクション環境でテストを走らせる • コードは自動デプロイ、テストも自動実行、結果も自動集計。ビジネス観点での定量的評価 • Advanced • 異常時の切り戻しまで含めて全て自動化 • 開発の細かなステップでひたすらデプロイ • 収益に与える影響まで全て集計して報告 SophisticationとAdoption
  62. 62. 62Copyright©2017 NTT corp. All Rights Reserved. • Adoption(採用度)とは企業文化レベルでの受け入れ度合い • In the Shadows • 一部の物好きが試しに導入を試みる • 企業は公式には認めていない • Investment • 企業は公式にChaosな実験をしようと言い出す • 一部の重要なサービスにエンジニアがChaosEngineering用の時間を割くようになる • Adoption • Chaos Engineering専用のチームができる • 異常時のレポートをChaosな回帰テスト向けにフィードバックし始める • 重要なサービスは確実にChaos実験される • Cultural Expectation • 全ての重要なサービスとほとんどの重要でないサービスがChaos実験を行う • むしろChaos実験は何らかの正当化なしには逃れられない • この度合いの高さがテストの幅と深さのカバレッジを引き上げる SophisticationとAdoption
  63. 63. 63Copyright©2017 NTT corp. All Rights Reserved. • Chaos Engineeringはエンジニアに命じればシステムが丈夫にな る魔法ではない • 企業の文化のレベルで分散システムの信頼性への投資を決断しての賜物 • エンジニアの努力と周囲の理解の両立が不可欠 何が言いたいのか
  64. 64. 64Copyright©2017 NTT corp. All Rights Reserved. • 分散システムの世界は恐ろしい • 複雑で状況もレイヤーも多岐に渡るため未発見のバグが次々見つかり続ける • 大抵は再現させる事すら難しいので再現率を上げる方法として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
  65. 65. 65Copyright©2017 NTT corp. All Rights Reserved. • Chaos Engineeringの先陣を切っているNetflixのエンジニアによる書籍 • システムをただ壊せばよいわけではなく、仮説を立て、実験設定を検討し、実際に検証し、 更にはプロダクション環境でもその仕組みが動く事を保障するためにどうするか • 企業のエンジニアリング文化とどのように折り合っていくかが書いてある • 本の末尾にJepsenを初めとしたFault Injectionのコードベースが列挙されておりそこから 芋づる式にFault Injection系の情報が出てくる 更に知りたい人は http://www.oreilly.com/webops-perf/free/chaos-engineering.csp
  66. 66. 66Copyright©2017 NTT corp. All Rights Reserved. • このスライドで紹介したバグは現在最新版のOSSでは既に解消されているケー スが多々あります。詳細は都度ご確認ください。 注意事項
  67. 67. 67Copyright©2017 NTT corp. All Rights Reserved. 以後 予備スライド(質疑応答時間ないから要らなかった)
  68. 68. 68Copyright©2017 NTT corp. All Rights Reserved. redis/zookeeper/kafkaの挙動(論文から抜粋)
  69. 69. 69Copyright©2017 NTT corp. All Rights Reserved. MongoDB/LogCabin/CockroachDBの挙動(論文から抜粋)
  70. 70. 70Copyright©2017 NTT corp. All Rights Reserved. cassandraと凡例(論文から抜粋)

×