AWS

【AWS Dev Day Tokyo2019】Chaos Engineering 〜入門と実例〜を聞いて

AWS DevDay Tokyo 2019が10/3、10/4で開催されていたので参加してきました。

私は以下のセッションを聞いてきました。

  • 第1回 AWS Fargate かんたんデプロイ選手権
  • Chaos Engineering 〜入門と実例〜
  • ベンダーロックインとの正しい付き合い方と開発におけるリスク評価
  • マイクロサービスを支えるインフラアーキテクチャ
  • KinesisとLambdaでつくるServerlessなログ基盤
  • マルチリージョン・マルチアカウント対応の柔軟な構築ツールを作ってみた
  • Step Functionsを使ったバッチ基盤を考える

どれも面白いセッションでしたが、中でも一番面白かったのは「Chaos Engineering 〜入門と実例〜」です。

もともとChaos Engineeringの概念自体はNoOps Meetup Tokyo #8のセッションで紹介されていたため知ってはいましたが、より詳細に歴史と概要を知ることができました。

Chaos Engineeringとは

こちらのQiita記事がよくまとめられていてわかりやすいです。
カオスエンジニアリングと聞いてカオスになった人必見

私の業務ではコンテナ技術に触れる機会がないためあまり馴染みがなかったのですが、Kubernetesを用いたマイクロサービスを使用している企業さんであれば耳にしたことがあると思います。

Chaos Engineeringとはマイクロサービスアーキテクチャにおける障害対策の考え方の一つです。

モノリシックな環境でシステム構築をしてきた人には信じられないですが、Chaos Engineeringは本番環境で実際に障害を起こして、サービスに影響がでないかどうかを確認するという考え方です。NoOpsで初めて聞いたときはびっくりしましたね。

 

なぜそんなことをするのか

クラウドは障害が起きることが前提であるから。

クラウドを利用する上で自動回復するサービスが基本的に良いとされています。AutoScalingとかですね。
モノリシックな時代の障害を起こさないから障害に対する考え方も質も変わって生きている中で、マイクロサービスアーキテクチャでは機能ごとに疎結合に結びついており、障害時にどこまで影響が出るのかを把握することが難しいことが課題としてあるそうです。

クックパッドの本番環境で動作しているマイクロサービス群は70以上あるという。その全てが密に連携しているわけではないが、障害が起きたとき、どこで何が起きているか分からないし、その影響がどこまで波及するか予測するのが不可能になってきていた。実際、Aというサービスが参照するBというサービスがさらにチェックするCというサービスのレスポンスタイムが遅くなったことが原因で、スマホの画面に何も表示できなくなる……といった恐れが現実のものになってきたという。

日本企業が「カオスエンジニアリングやっていく宣言」を出せた理由 より

そんななかで実際に障害が起きたときに被害を最小限にしようというのがカオスエンジニアリングです。日頃から継続して様々な障害を起こしていれば実際に起きても対応できるよねって発想がロックすぎて痺れますね。

 

感想

Chaos Engineeringの歴史から入門するまでの流れが非常に分かりやすくこんな取り組みをしている企業がNetflix以外にもあるんだといういい刺激にもなりました。

私もいつかコンテナサービスで運用することが出来たときは、一度導入の検討をしてみたいです。実際に導入する勇気があれば…

こちらにクラスメソッドさんのレポートもあるので興味がある方はぜひ御覧ください。
【AWS Dev Day Tokyo 2019 セッションレポート】 Chaos Engineering 〜入門と実例〜

クラスメソッドさん他のセッションについてもまとめてくれてます。いつもお世話になっております。
AWS DevDay Tokyo 2019 – シリーズ –