こんにちは！オルターブースの池田です！
最近ようやく涼しくなってたなーと思ったら、気づいたら街はハロウィンムードにいつの間にか変わってました🎃
さて、今回はシステムの「回復力 (Resilience, レジリエンス)」についてと、Azure Chaos Studioに軽く触れてみたいと思います。
きっかけとしては先日、東京の九段下で開催されていたSRE NEXT2023へ参加し、改めてシステムの回復力には「日頃の備え」が重要と認識した為です。
回復力 (Resilience, レジリエンス)について
回復力のあるシステムについてIPAの高回復力システム基盤導入ガイドでは下記のように記載されています。
組織の事業継続のための情報システム対策では、情報システムを停止させないための対策と、 万が一情報システムが停止してしまった場合に迅速に復旧するための事前準備の両方が重要です。 高回復システム基盤とは、 大規模災害や大規模システム障害に対して一定の強度 (情報システムを停止させないための対策が施されていること)をもち、 万が一停止した場合でも、目標とする時間内に情報システムを復旧することができるように設計・構築されたシステム基盤をいいます。
https://www.ipa.go.jp/archive/files/000004631.pdf
情報システムを停止させないための対策 と 迅速に復旧するための事前準備の両方が重要とあります。 クラウドにおいてはWell-Architected Frameworkの信頼性の柱。これらをしっかりと理解する必要があると改めて考え、自身も再度読み込みました。
耐障害性の評価
回復性テスト計画の一環としてカオスエンジニアリングがあります。 システムに意図的に障害を引き起こし、有事をシュミレートし、分析、対応することによりシステムの信頼性を向上させることに繋げます。
今回はAzure Chaos Studio を使い、Azure Functionsの障害を意図的に発生させてみます。
8月3日にStop App Serviceが追加された事で、Azure FunctionsのPremium プラン、専用 (App Service) プランであれば検証が可能だと考えました。
Azure Chaos Studio
前準備としてPremium プランのAzure Functionsをデプロイしておきます。 当たり前ですが、現在は「実行中」のステータスです。
検索バーからChaos Studioを検索し、対象から作成したAzure FunctionsをターゲットにChaos Studio を有効にします。
次に実験から作成、新しい実験を選択します。
Permissionsタブではシステム割当IDを選択します。
実験デザイナー画面ではアクションの追加 から障害の追加 、Stop App Serviceを選択し、ターゲットリソースに作成したAzure Functionsを選択します。
全て入力を終え、作成後に早速「開始」を選択したところ、私の環境ではエラーが出ました。
The target resource(s) could not be resolved. Error Code: AccessDenied. Target Resource(s): Session ID: ********
どうやら権限不足のようなので、作成したAzure Functionsへ移動し、すでに設定されている「カオス実験」のマネージドIDに対して権限を付与してあげます。
「カオス実験」に戻り「開始」を押下し、しばらくするとアクションが実行された事が確認できます。
Azure Functionsでも停止状態に変化しました。
プランによりますが、Azure Functionsに対しても障害をシュミレートできる事が分かりました。 システムの一部としてAzure Functionsを利用しているケースは多いと思うので単一障害発生時対応の訓練などにも効果的かと感じました。
参考
最後に
今回は耐障害性の評価としてAzure Chaos Studio を触れてみました。 本当に軽く触れただけなので、ここから「日頃の備え」としていくには...についてはしっかり考える必要があると思っています。
拙い内容で恐縮ですが、最後までご覧いただき有難うございました！
