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

More Related Content

What's hot

BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドAkihiro Suda
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化Kumazaki Hiroki
 
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】Masahito Zembutsu
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」Masahito Zembutsu
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法についてYuji Otani
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能Kohei Tokunaga
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Masahito Zembutsu
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウトMasahiko Sawada
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)NTT DATA Technology & Innovation
 
こわくない Git
こわくない Gitこわくない Git
こわくない GitKota Saito
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けモノビット エンジン
 
分散システムの限界について知ろう
分散システムの限界について知ろう分散システムの限界について知ろう
分散システムの限界について知ろうShingo Omura
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
MQTTとAMQPと.NET
MQTTとAMQPと.NETMQTTとAMQPと.NET
MQTTとAMQPと.NETterurou
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Akihiro Suda
 
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Masahito Zembutsu
 

What's hot (20)

BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化
 
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウト
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
こわくない Git
こわくない Gitこわくない Git
こわくない Git
 
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
 
分散システムの限界について知ろう
分散システムの限界について知ろう分散システムの限界について知ろう
分散システムの限界について知ろう
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
 
MQTTとAMQPと.NET
MQTTとAMQPと.NETMQTTとAMQPと.NET
MQTTとAMQPと.NET
 
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
 

Viewers also liked

4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗toshihiro ichitani
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
 
自作仮想化基盤 「n0stack」の紹介
自作仮想化基盤 「n0stack」の紹介自作仮想化基盤 「n0stack」の紹介
自作仮想化基盤 「n0stack」の紹介Takeshi Take
 
プロダクトに 1 から Vue.js を導入した話
プロダクトに 1 から Vue.js を導入した話プロダクトに 1 から Vue.js を導入した話
プロダクトに 1 から Vue.js を導入した話Shohei Okada
 
CSS2017キャンドルスターセッション
CSS2017キャンドルスターセッションCSS2017キャンドルスターセッション
CSS2017キャンドルスターセッションUEHARA, Tetsutaro
 
If文から機械学習への道
If文から機械学習への道If文から機械学習への道
If文から機械学習への道nishio
 
やさしいGitの内部構造 - yapcasia2013
やさしいGitの内部構造 - yapcasia2013やさしいGitの内部構造 - yapcasia2013
やさしいGitの内部構造 - yapcasia2013DQNEO
 
【メモ】一般的に設計書に定義される項目例
【メモ】一般的に設計書に定義される項目例【メモ】一般的に設計書に定義される項目例
【メモ】一般的に設計書に定義される項目例Hirokazu Yatsunami
 
わかった気になるMySQL
わかった気になるMySQLわかった気になるMySQL
わかった気になるMySQLyoku0825
 
Property-Based Testing for Godly Tests
Property-Based Testing for Godly TestsProperty-Based Testing for Godly Tests
Property-Based Testing for Godly Testsgarbles
 
Defending your workloads with aws waf and deep security
Defending your workloads with aws waf and deep securityDefending your workloads with aws waf and deep security
Defending your workloads with aws waf and deep securityMark Nunnikhoven
 
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツールC/C++プログラマのための開発ツール
C/C++プログラマのための開発ツールMITSUNARI Shigeo
 
Docker on Heroku のはじめ方
Docker on Heroku のはじめ方Docker on Heroku のはじめ方
Docker on Heroku のはじめ方Takashi Abe
 
Tableau Serverを利用した組織レベルでのデータ分析
Tableau Serverを利用した組織レベルでのデータ分析 Tableau Serverを利用した組織レベルでのデータ分析
Tableau Serverを利用した組織レベルでのデータ分析 Hortonworks Japan
 
MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術yoku0825
 
普通の人でもわかる Paxos
普通の人でもわかる Paxos普通の人でもわかる Paxos
普通の人でもわかる Paxostyonekura
 
「俺たちのポータル」~ガルーンユーザーがお手本にしたいポータル活用術~
「俺たちのポータル」~ガルーンユーザーがお手本にしたいポータル活用術~「俺たちのポータル」~ガルーンユーザーがお手本にしたいポータル活用術~
「俺たちのポータル」~ガルーンユーザーがお手本にしたいポータル活用術~Cybozucommunity
 
闇深めだったサービスのスタイルガイド作成までの真実
闇深めだったサービスのスタイルガイド作成までの真実闇深めだったサービスのスタイルガイド作成までの真実
闇深めだったサービスのスタイルガイド作成までの真実Yuriko Okabe
 
20120706-readablecode
20120706-readablecode20120706-readablecode
20120706-readablecodeMasanori Kado
 

Viewers also liked (20)

4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
自作仮想化基盤 「n0stack」の紹介
自作仮想化基盤 「n0stack」の紹介自作仮想化基盤 「n0stack」の紹介
自作仮想化基盤 「n0stack」の紹介
 
プロダクトに 1 から Vue.js を導入した話
プロダクトに 1 から Vue.js を導入した話プロダクトに 1 から Vue.js を導入した話
プロダクトに 1 から Vue.js を導入した話
 
とにかく楽してVue.jsでTypeScriptを使いたい
とにかく楽してVue.jsでTypeScriptを使いたいとにかく楽してVue.jsでTypeScriptを使いたい
とにかく楽してVue.jsでTypeScriptを使いたい
 
CSS2017キャンドルスターセッション
CSS2017キャンドルスターセッションCSS2017キャンドルスターセッション
CSS2017キャンドルスターセッション
 
If文から機械学習への道
If文から機械学習への道If文から機械学習への道
If文から機械学習への道
 
やさしいGitの内部構造 - yapcasia2013
やさしいGitの内部構造 - yapcasia2013やさしいGitの内部構造 - yapcasia2013
やさしいGitの内部構造 - yapcasia2013
 
【メモ】一般的に設計書に定義される項目例
【メモ】一般的に設計書に定義される項目例【メモ】一般的に設計書に定義される項目例
【メモ】一般的に設計書に定義される項目例
 
わかった気になるMySQL
わかった気になるMySQLわかった気になるMySQL
わかった気になるMySQL
 
Property-Based Testing for Godly Tests
Property-Based Testing for Godly TestsProperty-Based Testing for Godly Tests
Property-Based Testing for Godly Tests
 
Defending your workloads with aws waf and deep security
Defending your workloads with aws waf and deep securityDefending your workloads with aws waf and deep security
Defending your workloads with aws waf and deep security
 
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツールC/C++プログラマのための開発ツール
C/C++プログラマのための開発ツール
 
Docker on Heroku のはじめ方
Docker on Heroku のはじめ方Docker on Heroku のはじめ方
Docker on Heroku のはじめ方
 
Tableau Serverを利用した組織レベルでのデータ分析
Tableau Serverを利用した組織レベルでのデータ分析 Tableau Serverを利用した組織レベルでのデータ分析
Tableau Serverを利用した組織レベルでのデータ分析
 
MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術
 
普通の人でもわかる Paxos
普通の人でもわかる Paxos普通の人でもわかる Paxos
普通の人でもわかる Paxos
 
「俺たちのポータル」~ガルーンユーザーがお手本にしたいポータル活用術~
「俺たちのポータル」~ガルーンユーザーがお手本にしたいポータル活用術~「俺たちのポータル」~ガルーンユーザーがお手本にしたいポータル活用術~
「俺たちのポータル」~ガルーンユーザーがお手本にしたいポータル活用術~
 
闇深めだったサービスのスタイルガイド作成までの真実
闇深めだったサービスのスタイルガイド作成までの真実闇深めだったサービスのスタイルガイド作成までの真実
闇深めだったサービスのスタイルガイド作成までの真実
 
20120706-readablecode
20120706-readablecode20120706-readablecode
20120706-readablecode
 

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

TEE (Trusted Execution Environment)は第二の仮想化技術になるか?
TEE (Trusted Execution Environment)は第二の仮想化技術になるか?TEE (Trusted Execution Environment)は第二の仮想化技術になるか?
TEE (Trusted Execution Environment)は第二の仮想化技術になるか?Kuniyasu Suzaki
 
Io t security-suzki-20170224
Io t security-suzki-20170224Io t security-suzki-20170224
Io t security-suzki-20170224Kuniyasu Suzaki
 
次世代の企業ITインフラを支えるエンジニアとは
次世代の企業ITインフラを支えるエンジニアとは次世代の企業ITインフラを支えるエンジニアとは
次世代の企業ITインフラを支えるエンジニアとはTrainocate Japan, Ltd.
 
クラウドで変わるシステム・エンジニアリング
クラウドで変わるシステム・エンジニアリングクラウドで変わるシステム・エンジニアリング
クラウドで変わるシステム・エンジニアリングNaoto MATSUMOTO
 
Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Yukio Kumazawa
 
Azure IaaS 解説
Azure IaaS 解説Azure IaaS 解説
Azure IaaS 解説wintechq
 
ディペンダブルなクラウドコンピューティング基盤を目指して
ディペンダブルなクラウドコンピューティング基盤を目指してディペンダブルなクラウドコンピューティング基盤を目指して
ディペンダブルなクラウドコンピューティング基盤を目指してKazuhiko Kato
 
Software for Edge Heavy Computing @ INTEROP 2016 Tokyo
Software for Edge Heavy Computing @ INTEROP 2016 TokyoSoftware for Edge Heavy Computing @ INTEROP 2016 Tokyo
Software for Edge Heavy Computing @ INTEROP 2016 TokyoShohei Hido
 
1891件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術(NTT Tech Conference ...
1891件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術(NTT Tech Conference ...1891件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術(NTT Tech Conference ...
1891件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術(NTT Tech Conference ...NTT DATA Technology & Innovation
 
Cloudianを利用したソリューション (Cloudian Summit 2012)
Cloudianを利用したソリューション (Cloudian Summit 2012)Cloudianを利用したソリューション (Cloudian Summit 2012)
Cloudianを利用したソリューション (Cloudian Summit 2012)CLOUDIAN KK
 
Cloudianを利用したソリューション (Cloudian Summit 2012)
Cloudianを利用したソリューション (Cloudian Summit 2012)Cloudianを利用したソリューション (Cloudian Summit 2012)
Cloudianを利用したソリューション (Cloudian Summit 2012)CLOUDIAN KK
 
SIプロジェクトでのインフラ自動化の事例 (第1回 Puppetユーザ会 発表資料)
SIプロジェクトでのインフラ自動化の事例 (第1回 Puppetユーザ会 発表資料)SIプロジェクトでのインフラ自動化の事例 (第1回 Puppetユーザ会 発表資料)
SIプロジェクトでのインフラ自動化の事例 (第1回 Puppetユーザ会 発表資料)NTT DATA OSS Professional Services
 
クラウド2.0のもたらす破壊力と大企業内でのイノベーション
クラウド2.0のもたらす破壊力と大企業内でのイノベーションクラウド2.0のもたらす破壊力と大企業内でのイノベーション
クラウド2.0のもたらす破壊力と大企業内でのイノベーションOsaka University
 
6万行の TypeScript 移行とその後
6万行の TypeScript 移行とその後6万行の TypeScript 移行とその後
6万行の TypeScript 移行とその後Shingo Sasaki
 
Linuxセキュリティ強化エッセンシャル
Linuxセキュリティ強化エッセンシャルLinuxセキュリティ強化エッセンシャル
Linuxセキュリティ強化エッセンシャルToshiharu Harada, Ph.D
 
闘うITエンジニアのためのLinuxセキュリティ講座
闘うITエンジニアのためのLinuxセキュリティ講座闘うITエンジニアのためのLinuxセキュリティ講座
闘うITエンジニアのためのLinuxセキュリティ講座Toshiharu Harada, Ph.D
 
OSSではじめるオープン・スタンダードのクラウド @201304
OSSではじめるオープン・スタンダードのクラウド @201304OSSではじめるオープン・スタンダードのクラウド @201304
OSSではじめるオープン・スタンダードのクラウド @201304Shinichiro Arai
 
クラウド時代を生き残る経営戦略策定のススメ「クラウドは敵か?味方か?」(山口・岡山)
クラウド時代を生き残る経営戦略策定のススメ「クラウドは敵か?味方か?」(山口・岡山)クラウド時代を生き残る経営戦略策定のススメ「クラウドは敵か?味方か?」(山口・岡山)
クラウド時代を生き残る経営戦略策定のススメ「クラウドは敵か?味方か?」(山口・岡山)Serverworks Co.,Ltd.
 
Node-redでプロトタイピング
Node-redでプロトタイピングNode-redでプロトタイピング
Node-redでプロトタイピングMakoto SAKAI
 
Secure architecting on OCI (Oracle Cloud Infrastructure) 2021年3月16日
Secure architecting on OCI (Oracle Cloud Infrastructure) 2021年3月16日Secure architecting on OCI (Oracle Cloud Infrastructure) 2021年3月16日
Secure architecting on OCI (Oracle Cloud Infrastructure) 2021年3月16日Masanori KAMAYAMA
 

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

TEE (Trusted Execution Environment)は第二の仮想化技術になるか?
TEE (Trusted Execution Environment)は第二の仮想化技術になるか?TEE (Trusted Execution Environment)は第二の仮想化技術になるか?
TEE (Trusted Execution Environment)は第二の仮想化技術になるか?
 
Io t security-suzki-20170224
Io t security-suzki-20170224Io t security-suzki-20170224
Io t security-suzki-20170224
 
次世代の企業ITインフラを支えるエンジニアとは
次世代の企業ITインフラを支えるエンジニアとは次世代の企業ITインフラを支えるエンジニアとは
次世代の企業ITインフラを支えるエンジニアとは
 
クラウドで変わるシステム・エンジニアリング
クラウドで変わるシステム・エンジニアリングクラウドで変わるシステム・エンジニアリング
クラウドで変わるシステム・エンジニアリング
 
Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用
 
Azure IaaS 解説
Azure IaaS 解説Azure IaaS 解説
Azure IaaS 解説
 
ディペンダブルなクラウドコンピューティング基盤を目指して
ディペンダブルなクラウドコンピューティング基盤を目指してディペンダブルなクラウドコンピューティング基盤を目指して
ディペンダブルなクラウドコンピューティング基盤を目指して
 
Software for Edge Heavy Computing @ INTEROP 2016 Tokyo
Software for Edge Heavy Computing @ INTEROP 2016 TokyoSoftware for Edge Heavy Computing @ INTEROP 2016 Tokyo
Software for Edge Heavy Computing @ INTEROP 2016 Tokyo
 
1891件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術(NTT Tech Conference ...
1891件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術(NTT Tech Conference ...1891件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術(NTT Tech Conference ...
1891件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成するsyzkallerのテスト自動化技術(NTT Tech Conference ...
 
Cloudianを利用したソリューション (Cloudian Summit 2012)
Cloudianを利用したソリューション (Cloudian Summit 2012)Cloudianを利用したソリューション (Cloudian Summit 2012)
Cloudianを利用したソリューション (Cloudian Summit 2012)
 
Cloudianを利用したソリューション (Cloudian Summit 2012)
Cloudianを利用したソリューション (Cloudian Summit 2012)Cloudianを利用したソリューション (Cloudian Summit 2012)
Cloudianを利用したソリューション (Cloudian Summit 2012)
 
SIプロジェクトでのインフラ自動化の事例 (第1回 Puppetユーザ会 発表資料)
SIプロジェクトでのインフラ自動化の事例 (第1回 Puppetユーザ会 発表資料)SIプロジェクトでのインフラ自動化の事例 (第1回 Puppetユーザ会 発表資料)
SIプロジェクトでのインフラ自動化の事例 (第1回 Puppetユーザ会 発表資料)
 
クラウド2.0のもたらす破壊力と大企業内でのイノベーション
クラウド2.0のもたらす破壊力と大企業内でのイノベーションクラウド2.0のもたらす破壊力と大企業内でのイノベーション
クラウド2.0のもたらす破壊力と大企業内でのイノベーション
 
6万行の TypeScript 移行とその後
6万行の TypeScript 移行とその後6万行の TypeScript 移行とその後
6万行の TypeScript 移行とその後
 
Linuxセキュリティ強化エッセンシャル
Linuxセキュリティ強化エッセンシャルLinuxセキュリティ強化エッセンシャル
Linuxセキュリティ強化エッセンシャル
 
闘うITエンジニアのためのLinuxセキュリティ講座
闘うITエンジニアのためのLinuxセキュリティ講座闘うITエンジニアのためのLinuxセキュリティ講座
闘うITエンジニアのためのLinuxセキュリティ講座
 
OSSではじめるオープン・スタンダードのクラウド @201304
OSSではじめるオープン・スタンダードのクラウド @201304OSSではじめるオープン・スタンダードのクラウド @201304
OSSではじめるオープン・スタンダードのクラウド @201304
 
クラウド時代を生き残る経営戦略策定のススメ「クラウドは敵か?味方か?」(山口・岡山)
クラウド時代を生き残る経営戦略策定のススメ「クラウドは敵か?味方か?」(山口・岡山)クラウド時代を生き残る経営戦略策定のススメ「クラウドは敵か?味方か?」(山口・岡山)
クラウド時代を生き残る経営戦略策定のススメ「クラウドは敵か?味方か?」(山口・岡山)
 
Node-redでプロトタイピング
Node-redでプロトタイピングNode-redでプロトタイピング
Node-redでプロトタイピング
 
Secure architecting on OCI (Oracle Cloud Infrastructure) 2021年3月16日
Secure architecting on OCI (Oracle Cloud Infrastructure) 2021年3月16日Secure architecting on OCI (Oracle Cloud Infrastructure) 2021年3月16日
Secure architecting on OCI (Oracle Cloud Infrastructure) 2021年3月16日
 

More from Kumazaki Hiroki

An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介Kumazaki Hiroki
 
トランザクション入門
トランザクション入門 トランザクション入門
トランザクション入門 Kumazaki Hiroki
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについてKumazaki Hiroki
 
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法Kumazaki Hiroki
 
キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達Kumazaki Hiroki
 
What is jubatus? How it works for you?
What is jubatus? How it works for you?What is jubatus? How it works for you?
What is jubatus? How it works for you?Kumazaki Hiroki
 
よくわかるHopscotch hashing
よくわかるHopscotch hashingよくわかるHopscotch hashing
よくわかるHopscotch hashingKumazaki Hiroki
 
冬のLock free祭り safe
冬のLock free祭り safe冬のLock free祭り safe
冬のLock free祭り safeKumazaki Hiroki
 

More from Kumazaki Hiroki (17)

An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介An overview of query optimization in relational systems 論文紹介
An overview of query optimization in relational systems 論文紹介
 
トランザクション入門
トランザクション入門 トランザクション入門
トランザクション入門
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについて
 
Cache obliviousの話
Cache obliviousの話Cache obliviousの話
Cache obliviousの話
 
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
 
Jubatus hackathon2
Jubatus hackathon2Jubatus hackathon2
Jubatus hackathon2
 
キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達キャッシュコヒーレントに囚われない並列カウンタ達
キャッシュコヒーレントに囚われない並列カウンタ達
 
What is jubatus (short)
What is jubatus (short)What is jubatus (short)
What is jubatus (short)
 
What is jubatus? How it works for you?
What is jubatus? How it works for you?What is jubatus? How it works for you?
What is jubatus? How it works for you?
 
よくわかるHopscotch hashing
よくわかるHopscotch hashingよくわかるHopscotch hashing
よくわかるHopscotch hashing
 
冬のLock free祭り safe
冬のLock free祭り safe冬のLock free祭り safe
冬のLock free祭り safe
 
MerDy
MerDyMerDy
MerDy
 
Bloom filter
Bloom filterBloom filter
Bloom filter
 
SkipGraph
SkipGraphSkipGraph
SkipGraph
 
Lockfree list
Lockfree listLockfree list
Lockfree list
 
Lockfree Priority Queue
Lockfree Priority QueueLockfree Priority Queue
Lockfree Priority Queue
 
Lockfree Queue
Lockfree QueueLockfree Queue
Lockfree Queue
 

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

  • 1. Copyright©2017 NTT corp. All Rights Reserved. 本当は恐ろしい分散システムの話 2017年10月30日 NTT ソフトウェアイノベーションセンター 分散処理基盤技術プロジェクト 熊崎 宏樹@kumagi
  • 2. 2Copyright©2017 NTT corp. All Rights Reserved. 諸説あるが、ここでの定義は「部分的な故障を許容するシステム」の事 複数台のコンピュータを接続して信頼性を高めたり データが途中で化けても再送したり訂正したり 一部のコンピュータが突然故障しても引き継いだり 故障を設計の一部に組み込む事が必須となる 分散システムとは
  • 3. 3Copyright©2017 NTT corp. All Rights Reserved. • 世はまさに分散システム戦国時代 • Hadoopを皮切りに次々出てくる巨大分散OSS • シリコンバレーでも分散ミドルウェアベンチャーが多数出現 • 高信頼なシステムを作ろうと思った場合には複数台のマシンによる高可用構成 が前提になる • Google、Facebook、Amazon等はもちろん • 金融、流通などのエンタープライズな領域でも当然前提となる • 大抵のWebサービスも高信頼が期待される • NTTグループももちろん例外ではない 分散システム everywhere
  • 4. 4Copyright©2017 NTT corp. All Rights Reserved.
  • 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. 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. 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. 8Copyright©2017 NTT corp. All Rights Reserved. 「ネットワーク構成エラー、ブラック ホール、パケット消失、ブラウンアウト は業界全体にまたがる議題である」 ネットワークは壊れる http://perspectives.mvdirona.com/2010/04/stonebraker-on-cap-theorem-and-databases/
  • 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. 10Copyright©2017 NTT corp. All Rights Reserved. Partitionに耐えると言ったな? • 分散システムのOSSの多くも障害時の挙動を定義している • Redis Sentinelという仕組みで障害発生時もセーフと言っているRedis 障害耐えます! データ消えません! CAPのうちCPです!
  • 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. 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. 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. 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. 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. 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. 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. 18Copyright©2017 NTT corp. All Rights Reserved. •分散システムのネットワークを分断していじめてみるとい ろんなシステムが意外とあっさりと壊れる •「CAPのうちAとPを採用しています!」とか謳っていても そのAすら守れていない事が割とある •異常系の挙動はバグの温床なので掘ってみると楽しい • http://jepsen.io/services によると、分散システムのコンサル ティングのサービスなども展開しているので興味のある人はぜひ ここまでのまとめ
  • 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. 20Copyright©2017 NTT corp. All Rights Reserved. 分散システムは実は危うい綱渡り
  • 21. 21Copyright©2017 NTT corp. All Rights Reserved. • システムに障害(Fault)を意図的に注入(Inject)するテスト • 異常時の挙動を観察できる • 分散システムは複雑なので、様々なレイヤーで様々な異常が注入されうる Fault Injection Testとは?(1/2) システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション Jepsen Test
  • 22. 22Copyright©2017 NTT corp. All Rights Reserved. • 原理的にはあらゆるレイヤーの境界に異常を入れ込む事ができる • アプリケーションの掌握範囲が定義できる部分でソフトウェアの品質を評価す る事ができる Fault Injection Testとは?(2/2) システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション Jepsen Test
  • 23. 23Copyright©2017 NTT corp. All Rights Reserved. • 分散システムの故障箇所はネットワークだけとは限らない • ディスクも壊れるしそこまでの境界もどこかが壊れるかもしれない Disk故障 システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション
  • 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. 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. 26Copyright©2017 NTT corp. All Rights Reserved. • errfsというファイルシステムを使って、嘘のエラーや化けたデータをアプリ に見せる • これによってここより下のレイヤーでの故障も表現できる Diskの故障を再現(1/2) システムコール NICドライバ DISKドライバ プロトコル スタック ファイルシステム ブロックデバイス アプリケーション システムコール NICドライバ DISKドライバ プロトコル スタック errfs ブロックデバイス アプリケーション
  • 27. 27Copyright©2017 NTT corp. All Rights Reserved. • 書き込まれたデータがディスク上で化けたり、読み書きの際にエラーが発生す る状況をファイルシステムで再現する Diskの故障を再現(2/2) システムコール NICドライバ DISKドライバ プロトコル スタック errfs ブロックデバイス アプリケーション X=10 システムコール NICドライバ DISKドライバ プロトコル スタック errfs ブロックデバイス アプリケーション X=? X=0
  • 28. 28Copyright©2017 NTT corp. All Rights Reserved. • ext4やxfsはデータのチェックサムを行わないのでディスク内のデータが化けてもお 構いなしにアプリに見せてしまう • つまり化けたデータが読める実験設定は妥当 • btrfsやzfsはチェックサムを行うので化けたデータがユーザに見える前に読み出しエ ラーとして報告できる • zfsはcopiesパラメータ次第で故障に耐える事もできるそうだが実験スコープ外 • ファイルシステムそのもののメタデータは壊さない • そこが壊れたときに耐えるかはファイルシステムの責任でありアプリのバグと切り分けにくくなる • 状況を分けてそれぞれで挙動をテスト • 「読んだらデータが0化けしてる」 • 「読んだらデータがランダムになってる」 • 「読もうとしたらIOエラーで拒否される」 • 「書こうとしたら読み込みオンリーのファイルシステムだからと拒否される」 • 「書こうとしたらディスクに空き容量がないからと拒否される」 • 化けるデータを持っているのはクラスタ内のリーダーなのか、単一プロセスもしくは ミドルウェア全体の観点から見て壊れるか、どのファイルが壊れるかを個別に調査 • 一度に化ける/壊れるエラーは一か所だけ。少なくともこれは耐えて欲しい。 実験設定
  • 29. 29Copyright©2017 NTT corp. All Rights Reserved. • 定期的にディスクにデータを保存するインメモリストレージRedis • 保存したデータが化けたらどうなる? • 一箇所ぐらいは耐えて欲しい 永続化すると言ったな? 障害耐えます! データ消えません!
  • 30. 30Copyright©2017 NTT corp. All Rights Reserved. • ユーザデータの中でも最近の操作を保存するappend only fileを対象に チェックサムをしていないので壊れたデータがそのまま放置される • そのファイルの中身が再同期によってLeaderからFollowerに上書きされる • Leaderのデータ化けがそのままFollowerに伝搬 Redis with errfs(1/4) Leader Follower Follower
  • 31. 31Copyright©2017 NTT corp. All Rights Reserved. • ユーザデータの中でも最近の操作を保存するappend only fileを対象に チェックサムをしていないので壊れたデータがそのまま放置される • そのファイルの中身が再同期によってLeaderからFollowerに上書きされる • Leaderのデータ化けがそのままFollowerに伝搬 • ユーザが読みに来たらもちろん壊れたデータが読める Redis with errfs (2/4) Leader Follower Follower ギャー!!
  • 32. 32Copyright©2017 NTT corp. All Rights Reserved. • redisメタデータの中でもappend only fileのRedisメタデータが壊れた場合 が致命的で、プロセスがクラッシュ • フォロワーがクラッシュする分には全体にとって問題はない Redis with errfs (3/4) Leader Follower Follower ぐえっ
  • 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. 34Copyright©2017 NTT corp. All Rights Reserved. Leader Follower メタデータ化け クラスタ丸ごと死亡 クラッシュ ユーザデータ化け 化けたデータがユーザから観測される 更に化けデータが伝播 リーダー昇格時に化 けデータ観測 Redisのディスク障害挙動まとめ N多重で保存しているのに、1箇所の故障がN多重全部壊すことがある
  • 35. 35Copyright©2017 NTT corp. All Rights Reserved. これに対しRedis作者は 「AOFの全エントリにチェックサムつけるのはサイズも膨 れるので、やるにしてもオプトインだと思う。 Redis4系ではCRC64を全エントリにつけようかと思って いる(注: これは実際に実装された)」 @antirez https://github.com/antirez/redis/issues/3730
  • 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. 37Copyright©2017 NTT corp. All Rights Reserved. • 割と名の知れた分散システムでも平気で壊れている事はある • どれもコミュニティに報告して何かしらの対応はしてもらっている • システム毎に戦略は様々だが、みんな大なり小なり壊れている • ZKがAdler32というチェックサムを使っているが衝突しがちで良くなさそう? • データ化けを検出した場合、プロセス単体ではクラッシュするのがよくある • クラッシュ後の再起動でデータを読んで再度クラッシュするから永久に立ち上がれないケースがあっ てつらい • ZooKeeper,MongoDB,LogCabinはデータ化けが発生したらリーダーから降格する仕組みまで作り こんであってすごい • 特にZKはクラッシュするのはわざとではないらしい • 一方、化けたメタデータをクラスタ中にまき散らしてパンデミックする奴もいる • ファイル作成に失敗したときに無限リトライしてディスクリプタ使い果たすZooKeeperさん… • リカバリの仕方も様々で、手元のログだけから化けた部分を切り捨てるKafkaや、隣 のマシンから正しいデータを貰うZooKeeperなど差がある • せっかく冗長構成しているんだから有効活用すればいいのにね • ReadRepairや再同期やリーダー選出の過程で化けたデータが伝搬する事がよくある から気をつけるべし • 読み出したデータ間で食い違いがあった際に、最新タイムスタンプで上書きするのがReadRepair 考察
  • 38. 38Copyright©2017 NTT corp. All Rights Reserved. • ストレージのデータは容易に化ける一方で化けるものだという前提で作りこま れていないシステムが多い • 「多重で保存しているから多少壊れても大丈夫です」と言われたら疑ってかか るべき • 壊れたデータをご丁寧に伝搬するケースさえある • 壊れたら壊れっぱなしとか、単一プロセスでのリカバリーとの区別が曖昧で最新データが共 有されないケースも多い • 異常時の挙動について定義・ドキュメント化すらされていないものが多い • これは作者やコミュニティと一緒に仕様を策定しなくてはならない • 例えば3多重のデータの全部が壊れている場合などの諦め方など ここまでのまとめ
  • 39. 39Copyright©2017 NTT corp. All Rights Reserved. 故障が伝搬しないように 分散システムを作る事すら 実はまだ人類には難しい
  • 40. 40Copyright©2017 NTT corp. All Rights Reserved. • 異常を注入すれば異常時の挙動の知見が貯まるが、どんな異常でも良いわけで はない • 全プロセスを同時に強制的にkillしてもシステムは停止するが知見は得られない • ソフトウェアとユーザの間には何らかの「契約」があり、そこの境界付近こそ 探る価値がある • 契約あるところにFault Injectionあり 進撃のFault Injection
  • 41. 41Copyright©2017 NTT corp. All Rights Reserved. • データベースが満たす特性の金字塔 • Atomicity: トランザクションは完全に行ったか全く行われないかのどちらか • Consistency: 一貫性のある状態にしかならない • Isolation: 実行途中のトランザクションが他のトランザクションから観測されない • Durability: ユーザに完了を報告したトランザクションは電源が落ちようが消えない • これはユーザとの契約の一つである ACIDトランザクション
  • 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. 43Copyright©2017 NTT corp. All Rights Reserved. iSCSI経由でデータベースを駆動させ、その過程で発行されたiSCSIレベルでの コマンドを全て記録していく Torturing Databases for Fun and Profit概要(1/4) ファイルシステムsyscall read() write() fsync() iSCSI IOコマンドを記録
  • 44. 44Copyright©2017 NTT corp. All Rights Reserved. 記録された系列の途中のポイントまでをリプレイした別のハードディスクを作る Torturing Databases for Fun and Profit概要(2/4) ファイルシステムsyscall read() write() fsync() iSCSI
  • 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. 46Copyright©2017 NTT corp. All Rights Reserved. これを様々なリプレイ断面で試していくと、DBがACIDに違反している事を見 つける事ができる Torturing Databases for Fun and Profit概要(4/4) ファイルシステムsyscall iSCSI fsckrecovery
  • 47. 47Copyright©2017 NTT corp. All Rights Reserved. • 本当に全断面を探索すると時間が掛かりすぎるので、効率的にACID違反が見 つかる勘所を優先的に探す • 同じLBAに何度も書いている場合メタデータの可能性が高い • LBAが急に飛んだ場合、B+ツリーのsplitとかヘッダの可能性が高い • 1つのSCSIコマンドの上で複数のブロックに書いている場合headコマンドで暗黙のうちに atomicに動く事を期待し勝ち • ファイルを切り替えている場合、内部で複雑な事をしているからバグの温床 • mmap使ったデータが書き戻される瞬間は大抵意図的ではない • なおこれらの勘所は全件探索から見つけた • 可能性の高そうな断面をスコア付けしてスコアが高い順に試すと効率的に ACID違反を見つけられる • ファイルシステムによる挙動の差でリカバリーできる場合とできない場合も比 べる事ができる 細かい話
  • 48. 48Copyright©2017 NTT corp. All Rights Reserved. ユーザとの契約を守れていない状況一覧
  • 49. 49Copyright©2017 NTT corp. All Rights Reserved. ユーザとの契約を守れていない状況一覧 NTFS上でしか動かなくて名前を隠す必要があって有名な謎の商用DBがDurability違反 完全に無傷と言えたのはXFS上のLMDBとKVS-Aだけ TokyoCabinetはmmapを誤用している箇所があって 未コミットでリカバリ不能なデータがディスクに書き戻されてしまう
  • 50. 50Copyright©2017 NTT corp. All Rights Reserved. ACIDすら守る事は難しい
  • 51. 51Copyright©2017 NTT corp. All Rights Reserved. • ACIDも契約である以上はFault Injectionの対象とすることができる • 電源断時の挙動は頻度こそ低いが自動的にテストしやすい部類ではある • 日頃お世話になっているデータベースも踏み抜かれていないバグはある • この実験で判明したバグはおよそ停電からの復旧時にのみ見つかる系統のバグ • データベース実装者であってもシステムコールの細かい挙動を把握しきってい ないと見られるケースが多々あった。 • なおこれらのバグは軒並み実装者へ報告した所ポジティブな回答を得られたとのこと データベースの拷問まとめ
  • 52. 52Copyright©2017 NTT corp. All Rights Reserved. • 手元の環境では動くけれどお客さんの環境に持っていったら何故か動かない • 分散システムの世界でも「テストでは耐えるのにプロダクション環境では何故 か耐えない」という問題に対策しなくてはならない システムエンジニアあるある
  • 53. 53Copyright©2017 NTT corp. All Rights Reserved. • Netflix社はプロダクション環境で異常系機能が正しく働く事を確認する方法 としてChaos Engineeringを提唱している • 顧客が触れる環境を直接破壊するので一見して狂気の沙汰に見えるが、それを 遂行する度量がすごい その猿、凶暴につき
  • 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. 55Copyright©2017 NTT corp. All Rights Reserved. • Netflixのサービス内インフラはマイクロサービス化されており、個々のマイ クロサービス毎に部署が存在し、その信頼性に責任を負っている • 下の図は想像で補った NetflixのChaos Engineering 課金部 動画フロント部 推薦部動画管理部 セール情報部
  • 56. 56Copyright©2017 NTT corp. All Rights Reserved. • もし推薦部が壊れたら顧客単位での推薦を諦めてただの売上ランキングで代用 • このようにChaos Engineeringに失敗した場合でも、どうやったら顧客への影響を最小化 できるか(Blast Radiusの最小化)を常に検討する NetflixのChaos Engineering 課金部 動画フロント部 推薦部動画管理部 セール情報部
  • 57. 57Copyright©2017 NTT corp. All Rights Reserved. • カナリア分析 • 新規コードを入れる際には小さなクラスタを作り、そちらに一部のトラフィックを振り分け る形で実装する(おそらくロードバランサの仕事) • その小さなクラスタと既存のクラスタの間で様々なメトリクスを比較し、極端な差異がない 事を自動的に確認する仕組みがある NetflixのChaos Engineering Load Balancer 既存クラスタ 新コード環境 VM VM VM VM VM VM 同じかな?
  • 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. 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. 60Copyright©2017 NTT corp. All Rights Reserved. • それでも頭の固い人は言う「プロダクション環境で壊すなんて狂気の沙汰だ」 • Chaos Engineeringには2つの軸があると主張する SophisticationとAdoption Sophistication Adoption ?
  • 61. 61Copyright©2017 NTT corp. All Rights Reserved. • Sophistication(洗練さ)とは異常耐性部分の成熟度を示す • Elementary • テストは手動でテスト環境のみ • その故障がビジネスにどの程度の影響を与えるかは検討スコープ外 • 定性的な性質が主眼 • Simple • プロダクションさながらのテスト環境を整備して試験 • コードベースは自動的にセットアップ可能 • テストの実行や結果は手動集計 • Sophisticated • プロダクション環境でテストを走らせる • コードは自動デプロイ、テストも自動実行、結果も自動集計。ビジネス観点での定量的評価 • Advanced • 異常時の切り戻しまで含めて全て自動化 • 開発の細かなステップでひたすらデプロイ • 収益に与える影響まで全て集計して報告 SophisticationとAdoption
  • 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. 63Copyright©2017 NTT corp. All Rights Reserved. • Chaos Engineeringはエンジニアに命じればシステムが丈夫にな る魔法ではない • 企業の文化のレベルで分散システムの信頼性への投資を決断しての賜物 • エンジニアの努力と周囲の理解の両立が不可欠 何が言いたいのか
  • 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. 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. 66Copyright©2017 NTT corp. All Rights Reserved. • このスライドで紹介したバグは現在最新版のOSSでは既に解消されているケー スが多々あります。詳細は都度ご確認ください。 注意事項
  • 67. 67Copyright©2017 NTT corp. All Rights Reserved. 以後 予備スライド(質疑応答時間ないから要らなかった)
  • 68. 68Copyright©2017 NTT corp. All Rights Reserved. redis/zookeeper/kafkaの挙動(論文から抜粋)
  • 69. 69Copyright©2017 NTT corp. All Rights Reserved. MongoDB/LogCabin/CockroachDBの挙動(論文から抜粋)
  • 70. 70Copyright©2017 NTT corp. All Rights Reserved. cassandraと凡例(論文から抜粋)