Tech Blog
カオスエンジニアリング
カオスエンジニアリング
カオスエンジニアリングの考え方を理解して開発力をアップする。 カオスエンジニアリングの考え方取り入れるとどうなるか。今日は、Kubernetesを活用する上で、理解したほうがよい「カオスエンジニアリング」について、取り上げようかと思います。
この考え方に基づいたクラウドサービスの開発を実践していくことで、様々な課題に対するアプローチの仕方が自社サービスにとって良い方向に持っていけるように対応できると筆者は考えています。
カオスエンジニアリングとは、一言で言いますと、一般的に回復力のあるシステムにしていこうという考え方です。システム開発において、集中型のシステムから、様々なシステム同士が連携する分散システムが主流になってきている背景があり、集中型のシステムで対応できない課題について対応していくための考え方が「カオスエンジニアリング」です。 本記事執筆時点のカオスエンジニアリングの普及度としては、世界規模で見た場合、「カオスエンジニアリングをやるべきか?」から「カオスエンジニアリングのベストプラクティス」は何かにシフトしている状況のようです。
これは、最近の基盤システムの方式であるクラウドシステム(kubernetes)を用いた方法が用いられることが背景としてあると筆者は考えます。
カオスエンジニアリングの導入効果はなにか。
カオスエンジニアリングの考え方の導入によるメリットとしてある効果は、システムに対する技術的に問題を解決するという考え方のアプローチではなく、ビジネス的に問題を解決できるようにするという効果があげられます。 例として、以下のシステム上の課題や問題に関して、カオスエンジニアリングの代表的な的な観点でチェックを行う事で課題や問題について対応する事が可能となります。
以下の考え方は「カオスエンジニアリング」のあくまでも入り口となる考え方です。その他にも、カオスエンジニアリングを活用することで、ビジネス的な観点で課題に取り組むことが出来る考え方とおもいますので是非、これらの情報について理解を深めていきたいと筆者は思いますし、当社でもそのような取り組みをしていることをアピールしたいと思い、記事にしてみました。
チェック観点(例)
・検知と障害にかかった時間はどれぐらい
・ユーザーは障害に気づいたか? どうやったら気づいたかどうかを把握できるか? どうすればユーザーに気づかれないようにできるか
・コンピュータがやるはずだったのに、人間がやらざるを得なかったことは何か?
・検知と障害にかかった時間はどれぐらい
・私たちが見落としていたことは何か?
・ダッシュボードやドキュメントが間違っていた所はどこか?
・検障害発生訓練等を高い頻度でやったほうが良いことは何か?
・同じ事象が意図せず発生したときに、オンコールのエンジニアがしなければならないことは何か
※参考「カオスエンジニアリングの考え方での課題問題へのチェック観点」
Hassy