この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
今回は基礎コースで学べたGremlinでできる状態攻撃(State Attacks)によるユースケース、ビジネスイニシアティブについてまとめていこうと思います。
状態攻撃は、停電、ノードの故障、クロックドリフト、アプリケーションのクラッシュなど、環境の予期せぬ変化に対するテストを行うことができます。
- Process Killer
- Shutdown
- Time Travel
の3つの攻撃が可能となっています。
状態攻撃のユースケースとビジネスイニシアティブ
一般的なユースケース紹介します。
Process Killer攻撃
特定のプロセスセットを終了させることで、アプリケーションのクラッシュや同様のイベントに対するテストを行います。
技術的なユースケース
- 自動再起動のテスト
systemdのようなWatchdogプロセスは故障したプロセスを自動的に検出して再起動しますし、Kubernetesのようなコンテナ・オーケストレーターは、故障したコンテナを検出して再起動してくれます。
Process Killer攻撃をすることで、
- Watchdogが適切に設定されているのか、落ちたプロセスを検出して再起動してくれるか
- 検知の閾値が低いか（長時間の停止を防ぐため）
- 再起動したプロセスでデータの損失や破損がないか
- クラスタ化されたワークロードのリーダー(Leader)の再決定
などを確認できます。
ビジネスイニシアティブ
-
サービスの可用性を最大限に高める
Process Killer攻撃を使って自動回復プロセスをテストし、ユーザー・エクスペリエンスを阻害することなくサービスが継続して稼働することを確認できます。
これはダウンタイムが削減されるだけでなく、ユーザー・エクスペリエンスが低下するリスクも軽減されます。
Shutdown攻撃
対象となるホスト・オペレーティング・システムを再起動またはシャットダウンすることで、ホストの障害に対する回復力をテストします
技術的なユースケース
- ワークロードの移行を確実に行うため
クラスタ化されたノードがシャットダウンプロセスを開始すると、そのノード上で稼働しているアプリケーションやサービスは、自動的に健全なインスタンスに移行する必要があります。これにより、稼働率と可用性が最大化されるとともに、データの損失や破損のリスクも軽減されます.
Shutdown攻撃をすることで、
- 対象となるインスタンス上のアプリケーションやサービスが停止し、健全なインスタンスに自動的に移行される
- 稼動中の接続やユーザーセッションは、サービスを中断することなく閉じられる
- ロードバランサーは、終了したインスタンスから自動的にトラフィックを排除
といったことが確認できます。
-
クラスタ化されたワークロードの高可用性の検証
KubernetesやKafkaなどのクラスター化されたシステムは、ノード障害に対応するように設計されていますが、これらのメカニズムが期待通りに動作することを検証することが重要です。
1つまたは複数のノードを停止させ、一貫性のない表示やスプリットブレインに入らずにクラスタが継続して動作することを確認することができます。
-
ノードの自動再起動やレプリケーションの検証
ノードは、オペレーティングシステムのアップデート、スケジュールされた再起動、クラウドプラットフォームからのリクエストなど、さまざまな理由で自動的に再起動することがありますが、Shutdown攻撃でこれらを再現することができます。
- シャットダウンしたノードを検出して対処するためのクラウドプラットフォームのメカニズムをテスト
- キャパシティプランニングの一環として、障害が発生したインスタンスの再起動にかかる時間を測定
- 短命のインスタンスを使用した場合の費用対効果を判断する
といったことが可能で、ノードの予期せぬシャットダウンやリブートを許容できるかどうかを確認します。
ビジネスイニシアティブ
-
サービスの可用性を最大限に高める、インフラのサイジング
Process Killer攻撃と同様に、自動レプリケーションやフェイルオーバーのプロセスが正しく機能しているかどうかを確認することで、チームのアップタイムを最大化します。 により、サービスの中断を軽減し、優れたカスタマーエクスペリエンスを提供することができます。
さらに、安価で短命なクラウドインスタンスの使用をシミュレートすることで、インフラのサイジングにも役立ちます。
Time Travel攻撃
サマータイム（DST）、ホスト間のクロックドリフト、SSL / TLS証明書の期限切れなどのシナリオをテストします
技術的なユースケース
- サマータイムとうるう年に備える
時計の変更は、システムやアプリケーション間の通信に問題を生じさせ、メッセージの破棄やタイムスタンプの誤認を引き起こしますが、サマータイムやうるう年は頻度が低いので十分なテストが行われないことがい多いです。
Time Travel攻撃を利用することでシステムの時計を1時間進めたり戻したりして、アプリケーションをテストし、データの整合性を検証することができます。
-
TLS 証明書の有効期限テストによるセキュリティの確保
証明書は一定の時間が経過すると期限切れとなり、更新や交換を行わなければ、通信が途絶えてしまいます。
Time Travel攻撃はクロックスキュー(Clock skew)が暗号化に与える影響をテストしたり、通知や自動更新プロセスをテストすることで、証明書の期限切れに先んじて対応することができます
-
エンド・オブ・エポック(End of Epoch)の問題に備える
2038年を例に挙げると、2038年の問題は32ビットのUnixベースのシステムが日付と時刻の値を保存する方法の制限に起因しています。 2038年1月19日には、この値がオーバーフローして、日付が1901年12月13日に戻ってしまいます
自分のシステムが保護されているかどうかわからない場合は、Time Travel攻撃を利用して日付を先に進めて積極的にテストすることができます。
-
ノード間のクロック同期（NTP）のテスト
データを共有するシステムでは、システムクロックの同期が必要になることが多く、NTPのようなサービスを使って管理するのが最適です。 メッセージの破棄やデータの衝突などの問題がおきますし、NTPが利用できず、時計がずれてしまうこともあります。
Time Travel攻撃を利用して、クロックのドリフトとNTPの停止を同時にシミュレートできるので、停止に備えて事前に準備することができます。
ビジネスイニシアティブ
-
セキュリティやコンプライアンスの観点
システムと顧客との間の安全な通信を可能にする暗号化方式は、時計の同期に依存しているため、システムの時計が不一致になると、システムの安定性や使い勝手に大きな影響を与えることになります。
Time Travel攻撃を利用することにより、時計の同期が取れなくなる可能性のある状況に備え、セキュリティやコンプライアンスへの影響を判断し、本番のインシデントに先立ってこの影響を軽減することができます。
最後に
Gremlinの状態攻撃における技術的なユースケースとビジネスイニシアティブに関して学んだことをまとめてみました。
例に挙げられているユースケースなどを自身のアプリケーションやシステムで当てはまるか確認し、カオスエンジニアリング実行の計画、目標を立てていきましょう。
次回はNetwork攻撃(Network Attacks)に関することをまとめます。