わざと障害を起こす！？カオスエンジニアリングは不必要?実施する目的について

近年、多くの企業がITによるサービス開発を行っています。非IT企業であっても、ネットショップや自社サイトの運営を行うのは普通の事になっていますし、1つの会社の中でも・在庫管理システム・人事給与システム・会計システム・販売管理システムなど、様々なシステムが導入されています。これらの開発に当たり、「カオスエンジニアリング」という手法が用いられる事があります。今回は、このカオスエンジニアリングについて見ていきましょう。

カオスエンジニアリングとは

カオスエンジニアリングとは[/caption] カオスエンジニアリングとは、Netflixがシステム運用に取り入れている本番環境に意図的に障害を発生させ、その影響を観察する実験を通して、システムの可用性、信頼性を高めていく取り組みです。アメリカでは、サービスがダウンしている時間に売上機会の損失や信頼性に直結するEC・金融機関などで注目されています。カオスエンジニアリングでは、設計段階では想定できなかった挙動に関しても確認することが出来ます。カオスエンジニアリングにおけるテスト例としては以下のような物があります。〇ハードウェアの故障〇ネットワークの遅延〇リソース不足・過度の負荷〇依存関係の障害〇機能的なバグ（例外）この様な障害は、通常の製作過程における単体テストや結合テストでは、バグを発見することが出来ません。そのため、カオスエンジニアリングを行い、システムの精度を上げて行く必要があります。

カオスエンジニアリングのメリット

カオスエンジニアリングのメリットは、分散システムにおいて、問題点を発見しやすくなる点です。現在のシステムは、大きく「集中システム」と「分散システム」に分けられます。集中システムは、ひとつのパソコンで多くの役割を引き受けるシステムです。ひとつのパソコンで、システムを運用しているため、障害が起きた際の原因がそのパソコンの中にあるため、原因を特定しやすいという特徴があります。一方、分散システムは、多数のパソコンをネットワークで接続し、それぞれが役割分担をして稼働するシステムです。特徴としては、障害が起きた際にどのパソコンに問題があるのかが分かりづらい点です。複数の機器が動作をしているため、それぞれの機器が障害が起きた際の原因になりえるためです。しかし、カオスエンジニアリングを用いて実際の本番環境での実験を行うことで、障害が起きた際の問題点やその対策方法を見つけることが出来ます。

カオスエンジニアリングのデメリット

カオスエンジニアリングのデメリットとして、スケジュールを組むのが難しい点です。通常のテストは、本番環境ではなくテスト環境で行います。そのため、テストを行う際に障害が起きても実際のサービスが止まる訳ではない為、サービスの稼働中でも実施することが出来ます。一方、カオスエンジニアリングを行う本番環境では、テストで障害が起きた際にサービスが止まってしまう可能性があります。サービスが止まってしまうと、・ユーザからのクレーム・ユーザが離れてしまい売上低下・ブランディングの低下などのリスクがあります。そのためテストの日程は、サービスが稼働していていないメンテナンス中や保守日に行う必要があります。そのため、カオスエンジニアリングのデメリットとして、テストの日程を決めるのが難しい点が挙げられます。

カオスエンジニアリングの目的

カオスエンジニアリングの目的[/caption] カオスエンジニアリングの目的は、実際の本番環境で状況を悪化させ、システムを観察および監視し、対応した上でシステムの信頼性を向上させることです。障害発生時のサービスの挙動を大規模もシミュレーションすることは難しいです。シミュレーションが困難なため、障害発生時のサービスの挙動を知るためには実際に本番環境で障害を起こす必要があります。障害時のサービスの挙動を知ることは、動作が安定したサービスを運用していくには大切なことになります。カオスエンジニアリングを行うことで、「もしも〇〇な状況になれば、この部分はこう動く」ということを把握しておくことで、もしもの時に迅速に対応出来ます。更に、それらの「カオス」に対してサービス提供に関する問題は起きないと分かれば、それはサービスの信頼性として大きなポイントとなります。そのため、今のシステムの現状の把握や、リスクの回避、システムを安定稼働させるための方法論と言えます。

カオスエンジニアリングの必要性

カオスエンジニアリングの必要性[/caption] 近年のシステム開発において、オンプレミスで運用されていたシステムの多くが、クラウドへの移行を行っています。クラウドへ移行することにより、機器を自社で調達する必要がないため、初期費用が安く済み、拡張性が高くなるといったメリットがあるからです。一方で、クラウドでのサービス提供をすることで、・他社の情報も同じサーバーに入り、ログインIDや会社コードで識別されるようになったため、サーバー1台あたりのデータ量が増える・全世界からアクセスが可能なため、アクセスが集中化することもある・サーバーの一部を公開領域にする必要がある・場合によってはIotも導入されるなど、オンプレミスにはない仕様が当然増えます。そのため、あらゆる「カオス」を想定し、サービスの安定稼働を目指す必要があるのです。

カオスエンジニアリングのやり方

カオスエンジニアリングのやり方[/caption] カオスエンジニアのやり方としては、以下の通りになります。 1.実サービスが稼働している本番環境を用意するカオスエンジニアリングは、本番環境での挙動を確認するため、本番環境を用意します。 2.現状の状態を測定する障害時の状況を正確に確認するには、通常時の状態を知っておく必要があります。 3.テストの為の仮説を立てる通常のテストと同様に仮説を立てます。通常時の挙動と比較し、障害時にはどの様な挙動になるかを仮説することにより、テストの有意性を高めます。 4.意図的に障害を引き起こすサーバーのクラッシュ、ハードドライブの誤動作、ネットワーク接続の切断などの現実的なイベントをシミュレートさせます。 5.実験結果を見る対照群と実験群の定常状態を比較して仮説を検定します。また、カオスエンジニアリングを行うには、専用のツールが必要になります。有名なツールとしては、以下の3つが挙げられます。

Chaos Monkey

Chaos Monkeyは、NetflixがAWS上で公開しているオープンソースツールです。その名の通り、野生のサルに武器を持たせ、データセンターやクラウドシステムの中に解き放つようなイメージのツールになります。挙動としては、AWSのインスタンスをランダムに停止します。

pumba

pumbaは、Chaos Monkeyのような挙動をDockerのコンテナレベルで行うカオスエンジニアリングツールです。他にもネットワークのエミュレート機能等もあり、ネットワーク遅延やパケットロス、トラフィックへのレートリミットも引き起こすことができます。また、pumbaでは1回だけの動作もしくは一定間隔で動作を続けるといった挙動が出来ない点が特徴になります。

Gremlin

Gremlinは、AWSやMicrosoft Azure、Google Cloud Platformなどで発生するさまざまな障害を疑似的に発生させることができるツールです。リソース制限や環境の状態変更、ネットワーク変動のシミュレーションや個々の要求に対する影響などによるシステムに障害を挿入するための、攻撃用のフレームワークを提供しています。

Azure Chaos Studio

Azure Chaos Studio は、Azure で構成されるワークロードに対して意図的に障害を発生させて回復性などの確認を行うことが出来るツールです。発生させることが出来る障害としては、CPU 負荷、物理メモリ負荷、仮想メモリ負荷、ディスク I/O 負荷等が挙げられます。

安定したシステム開発ならAMELAに

安定したシステム開発ならAMELAに[/caption] 今回は、カオスエンジニアリングという手法について見てきました。多くのシステムが開発される一方で、・バグがなくて当たり前・24時間365日動いて当たり前というように、ユーザーの基準はどんどんと上がっています。もしも不備のあるシステムを出してしまうと、単にそのサービスが失敗に終わるだけではなく、会社の名前にも傷がつきます。ですので、こういったカオスエンジニアリングなどを通して、より安全でより安定的に動くシステムの開発が求められているのです。もしも現在システム開発を検討している場合や、すでに導入されているシステムのカスタマイズなどを希望されている場合、是非AMELAにご相談下さい。