ITのチカラで、デジタルビジネスへの変革を。

【AWS re:Invent 2019】カオスエンジニアリング

#AWS re:Invent 2019

こんにちは。

真木と申します。日商エレクトロニクス株式会社にてマーケティングマネージャーをさせて頂いております。

今回、2019年12月1日から、米国ラスベガスで開催中のAWS re:Invent 2019 についてレポートをさせて頂ております。世界中から65,000名も参加中の本イベント(日本からは1,700名の参加)は、セッションが3,000以上開催されるなど、途中休憩しながらの参加となっております。途中休憩すると喫煙者は私含めタバコを吸うことが多く、喫煙所に向かいます。

タバコの煙は、何もなければ一方方向に行きますが、外部要因(例えば、風とか息の圧力など)で、想像しない方向に行くものです。ベネチアンホテル(会場)で、カオスエンジニアリングの話(Performing chaos engineering in a serverless world, Gunnar Grosch, Evangelist and Co-founder, Opsio)を聞いて、ふとタバコの煙の流れを見てみました。

システム障害も同じで、想像し得る障害の場合(例えばフェイルオーバーしなかった)は、想像の範囲で障害復旧できますが、ある小さな事象が、想像しえない障害に発展する場合もあります。例えば、AWS Lambdaのファンクションが落ちた場合、想像しないが別のファンクションが起動しないような感じです。

それを見越して、わずかな障害を発生させ、想像し得ない障害をプロアクティブに予測し、いざ起こり得る障害に備える。学術的に言うと非線形統計力学。カオス=混沌ではなく、非線形な状態から事象をプロアクティブに予測する。株の予測などでも使われています(複雑系/フラクタル/カオスなどの非線形統計力学を利用)。

特に、カオスエンジニアリングの効果的なところは、サーバレス環境との事。そして監視、可視化はAPMで実現でき、僅かな障害のインパクトについては、AIOpsによるルートコーズで導き出せると考察します。

以下、セッション(AWS re:Invent 2019 「Performing chaos engineering in a serverless world」)のメモです。下記「カオスエンジニアリングの実験と実行」は物理学の実験に近いですね。実験は可視化され考察されるべきです。

Performing chaos engineering in a serverless world

Gunnar Grosch, Evangelist and Co-founder, Opsio

カオスエンジニアリング

物を壊すことでもなく、レジエンスエンジニアリングでもなく、製品のためのものでもなく、大規模なストリーミング会社(カオスエンジニアリングを採用しているNetflixと想定)のものでもありません。

あえて僅かな障害を起こし、その実験と実行をします。システムの弱点を見つけて、それらが壊れる前に修正します。そして、システムと組織に間の信頼性を構築します。

カオスエンジニアリングは、従来のインフラストラクチャとコンテナ化されたマイクロサービスを使用し、長年にわたってテストされてきました。しかし、サーバーレス機能やマネージドサービスとどのように連携すればよいのでしょうか。

カオスエンジニアリングのモチベーション

お客様は、なすべき経験を得ていますか?ダウンタイムなどの問題発生時、コストがかかりますか?監視と警告に不安はありませんか?今の組織は瞬断に対処する準備ができていますか?起こりうる障害に対応できますか?システムというものは全てが常に失敗します(“Everything fails, all the time!”,Werver Vogles CTO, Amazon)。システムに障害が発生した場合に何が起こるかを尋ねない、失敗するとどうなるか尋ねるべきものではありません。

カオスエンジニアリングの実験と実行

ステップ1:定常状態を定義する

時間経過に伴うシステムの通常動作の確認します。またシステムメトリックとビジネスメトリックの確認もします。ビジネス指標があると効果的です。定常状態は必ずしも連続しません。

ステップ2:仮説を立てる

「what if」を念頭に仮説をたてます。カオスはスタックされた任意の層に割り込みます。そして「if … then …」を考察します。必ず最初に既知の問題は修正しておきます。

ステップ3:実験を計画に実行する

実験を詳細に説明できるようにします。影響範囲が含まれるようにします。結果は、組織に通知します。もしもの時の「停止」ボタンも用意しておきます。

ステップ4:測定と学習

メトリックを使用し、仮説を証明または反証します。システムは発生させた障害に対して回復力があるか確認しましょう。予期しないことが起こったかどうかも確認です。進捗と成功は共有するようにします。

ステップ5:スケールアップ、または中止して修正する

学習し改善します。自信を持ってスケールアップできるかの確認します。スコープを拡大すると、新しい効果が明らかになります。

サーバーレスの課題

サーバーレスの利用時は、アプリケーションをビルドして実行します。サーバーについて考えることなく、管理するサーバーもありません。より少ない重荷を考慮し、多数のサービスから選択します。そうすると、機能およびサービス毎に課題がおきます。それを踏まえ、より詳細な構成を、アーキテクチャとして考える必要が出てきます。

カオスエンジニアリングはサーバーレスに最適

サーバーレスでカオスエンジニアリングの実験と実行をしましょう。

一般的なサーバーレスの弱点とは

エラー処理
タイムアウト値
イベント
フォールバック
フェイルオーバー

サーバレスカオスデモ

関数が呼び出される毎に、300msも手間がかかる場合はどうなるでしょうか?

関数がエラーコードを返すとどうなるのか?

コードに例外がある場合はどうなるのか?

仮説:機能に障害を発生させると、アプリケーションはグレースフルデグラデーションを使用します。

Try the Serverless Chaos Demo app:
https://demo.serverlesschaos.com

サマリー

Everything fails, all the time ! (Werver Vogles CTO, Amazon)

サーバーレスでは、アプリケーションの回復力はありません。

カオスエンジニアリングは、弱点を見つけて修正するのに役立ちます。

カオスエンジニアリングとは、構築したものに自信を持つことです。

ロケットサイエンスはありません!自分自身で成し遂げるのです!

-----------------

また機会を見て情報をアップします。

Yoshito Maki

この記事を書いた人

Yoshito Maki

マーケティング