KubeConサンディエゴ最終日のキーノートはカオスエンジニアリング
2019年11月にサンディエゴで開催されたKubeCon North Americaの最終日、午前中のキーノートにアメリカの量販大手Targetがユースケースとして登壇した。内容は、カオスエンジニアリングを専業とするGremlinとの共同の事例紹介である。
筆者はクラウドネイティブなコンピューティングシステムとしてカオスエンジニアリングに注目しており、2019年3月に開催されたOpen Source Leadership SummitではCNCFのCTOであるChris Aniszczyk氏にCNCFにおけるカオスエンジニアリングの位置付けについて質問したことがある。その際の回答は、「カオスエンジニアリングはCNCFではワーキンググループとして議論されている、インキュベーションプロジェクトとしてホストするには時期尚早」というものだった。その時から約半年を過ぎて、Targetというエンタープライズ企業がカオスエンジニアリングを実践していることを受けて、カオスエンジニアリングをKubeCon参加者に紹介する必要があるということで、今回のキーノート登壇ということとなったのであろう。
カオスエンジニアリングは動画配信サービスのNetflixが社内で開発していたChaos Monkeyというツールが最初の実装と言われているが、より広くカオスエンジニアリングを理解するためにはそのコンセプト自身を理解するべきだろう。日本語のドキュメントも用意されているので参照されたい。
ここで特徴的なのは「本番環境での実行」という部分だろう。意図的にシステムを壊してその復旧を自動化するという部分において、常にソフトウェアの更新が行われているアジャイル、DevOpsの環境では意図的にシステムを停止させたり、壊したりする実験をテスト環境に対して行っていても意味がないというのはその通りだ。またその前提としてソフトウェアの開発から配備までが自動化されていることがあるのは、未だにアジャイル開発、DevOpsが実装されていない日本のエンタープライズ企業においては注意すべきポイントだ。
まだDevOpsなどが実装されていない企業においては、テスト環境でカオスエンジニアリングを実験してみるというのが前段階としては必要であろう。
またゲームデイというコンセプトで「カオスエンジニアリングを実験する日を決めて集中的に開発チームと運用チームが協力しあう」という方法論もツールの枠を超えてユニークである。
前置きが長くなったが、今回のキーノートを紹介しよう。
まずカオスエンジニアリングの定義という意味で、ここでは「カオスエンジニアリングはシステムの弱点を発見するための計画された実験である」であるとして、単にシステムを壊すためのツールではないことが強調された。
またカオスエンジニアリングを実施する際のポイントとして、「仮説を立てること」「実験すること」「結果を分析すること」「適用領域を拡げること」最後に「その結果を共有すること」を挙げて、計画的、組織的に取り組むべきであると解説した。最後の共有は外部への共有という意味ではなく、組織内の開発、運用、ビジネスに責任を持つ部門すべてのステークホルダーがその結果を共有することで、よりよいシステムの実現に近づけるという意味である。
Targetの規模について解説したこのスライドでは、2箇所のデータセンターで5000以上のアプリケーションが稼働していることを紹介。これによりTargetが全米に1800店舗を持っている大手であることがわかる。日本のユニクロの国内の店舗数が約900であることを考えると、日本の約25倍の面積を持つアメリカに、2倍の規模で店舗が配置されている規模感である。
そして2017年から段階的にカオスエンジニアリングの導入が開始され、最終的に自動化が行われるのが2020年という予定になっていることも紹介された。
またTargetでは、カオスエンジニアリングをTRAP(Target Resiliency Automation Platform)と名付けてシステムの一部に取り込んでいることも紹介された。
社内への啓蒙のために作られたと思われるレストランのメニューを模したカオスエンジニアリングのアタックの内容を紹介したスライドでは、この後デモで実行されるレイテンシーの追加や「ブラックホール」と呼ばれる特定のトラフィックをすべて消してしまうアタックなどが紹介された。
システムのシャットダウンだけではなく、システムの時間を変えるなどと言った細かい不具合も織り込まれている辺りに、多くのシステムにおいてカオスエンジニアリングを実装してきたGremlinの経験が活かされているように思える。
またKubernetes環境においては、リソースを消費させてオートスケーリングが実行されるかを試すアタックとネットワークにレイテンシーを追加したり、パケットを故意にロスさせたりするアタックによって、「どのプロセスがどのような影響を受けるのか?」を検証することが推奨された。
最後に今後のTargetの方向として、利用の拡大、本番環境での実施、機械学習の応用などが解説された。「カオスエンジニアリングにおけるOKR(Objective and Key Result)の拡大」としてGoogleやIntelなどが利用している目標設定の指針が使われていることにも注目したい。
デモは、特定のプロセスに対してレイテンシーを追加することで、ユーザーの体験がどれだけ変わるのか? を見せた形になった。ここで興味深いのは、Gremlinのダッシュボードからは1秒の遅延を加えただけなのに、全体として1秒以上の遅延が再現されたことだ。一つのプロセスのへ悪影響が、依存関係にある他のプロセスに対しても伝搬していくことが明らかになったというわけだ。この辺りからも、複数のPodが連携して稼働するKubernetesの複雑さが目の当たりになる場面となった。
実際のセッションは20分程度なので、ぜひ動画を見て内容を確認して欲しい。
3日目に行われたカオスエンジニアリングのキーノート:Keynote: Finding the Joy in Chaos Engineering - Ana Medina & Lenny Sharpe
最後にFNLの伝説的なヘッドコーチであるMarv Levyの言葉、「There will be many failures sprinkled among the success you enjoy(輝かしい成功の中には多くの失敗が散りばめられている)」を引用して、失敗することの重要性を説いてステージを降りた。3日目のキーノートにカオスエンジニアリングが紹介されたことで、CNCFにおいてもカオスエンジニアリングの重要性が認識されてきたことを感じたキーノートとなった。
ちなみにGremlinは展示ブースでも大人気で、キャラクターの顔を模したぬいぐるみがみるみるうちになくなっていったことからも分かるように、悪さをする、モノを壊すというキャラクターとして大成功していることはメモしておきたい。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- KubeCon+CloudNativeCon NA 2020 IntuitとMayaDataによるカオスエンジニアリングのセッション
- CNCFのサンドボックスプロジェクト、カオスエンジニアリングのLitmus Chaosを紹介
- CNDT 2022、ChatworkのSREがSLO策定にカオスエンジニアリングを使った経験を解説
- 写真で見るKubeCon North America 2019ショーケース
- KubeCon North America:座談会で見えてきた退屈なKubernetesの次の世界
- KubeCon NA 2021からサービスメッシュの2セッションを紹介
- KubeCon@San Diego前日に開催のOpenShiftのコミュニティイベント
- カオスエンジニアリングのOSS、LitmusChaosの概要を解説するCNCFのウェビナーを紹介
- KubeCon NA 2020、サービスメッシュのLinkerdの概要とユースケースを紹介
- 分散処理システムの検証をサービスとして提供するJepsenに注目