19章データベースにおけるカオスエンジニアリング
19.1 なぜカオスエンジニアリングが必要なのか？
NetflixがChaos Monkey（https://oreil.ly/H2ouw）を2011年にオープンソース化してからというもの、このプログラムは人気を集め続けています。分散システムを作りたいなら、クラスタに対してChaos Monkeyに悪さをさせてみると、より耐障害性のある、堅牢で、信頼性の高いシステムを構築するのに役立つでしょう†1。
[†1] この章の内容には、以前PingCAPのブログで公開されたものが一部含まれます（https://oreil.ly/-P8tK）。
TiDB（https://oreil.ly/n5xBc）は主にPingCAPによって開発された、オープンソースで、分散型で、トランザクション処理と分析処理のハイブリッド型（Hybrid Transactional / Analytical Processing、HTAP）†2の性質を備えたデータベースです。あらゆるデータベースのユーザにとって最も重要な資産であるデータそのものを保存します。私たちのシステムで最も基本的かつ重要な要件の1つは、耐障害性です。従来は、システムが本番利用に耐えるものであることを保証するためにユニットテストと統合テストを実行していましたが、クラスタがスケールし、複雑性やデータ量がペタバイトレベルにまで増加すると、これらのテストがカバーできる範囲は氷山の一角に過ぎません。カオスエンジニアリングは自ずと私たちにマッチするものでした。本章では、私たちが行っている実践内容と、特にTiDBのような分散システムがカオスエンジニアリングを必要とする背景について詳細にご紹介します。 ...
Get カオスエンジニアリング ―回復力のあるシステムの実践 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
