Gremlinのカオスエンジニアリングを効果的に実践するための基礎コースで学んだことまとめ4 ~ Network攻撃のユースケースとビジネスイニシアティブ ~

ハイ、千葉県民です。

今回は基礎コースで学べたGremlinでできるNetwotk攻撃による技術的/ビジネスイニシアティブについてまとめていこうと思います。

Netwotk攻撃は信頼できないネットワークの状態に対してテストします。

• Blackhole
• DNS
• Latency
• Packet Loss

の4つの攻撃が可能となっています。

Netwotk攻撃の技術的なユースケースとビジネスイニシアティブ

Netwotk攻撃の一般的なユースケース紹介します。

Blackhole攻撃

サービス間のネットワークトラフィックをドロップして、到達不能な依存関係をテストします

技術的なユースケース

• 依存関係の失敗をテスト

  依存関係はエンジニアリングチームがコントロールすることができないため、アプリケーションは依存関係の失敗を許容し、回避するように設計されなければなりません。

  Blackhole攻撃を利用することにより、依存関係に障害が発生した場合、アプリケーションがクラッシュするのではなく正常にデグレードすることを検証することができます。また、フェイルオーバー、エラーメッセージ、リトライなどのエラー処理メカニズムをテストすることもできます。 依存関係がクリティカルかノンクリティカルかを判断するのにも役立ちます。

• クラスタの耐障害性の検証

  高可用性クラスターは、ノードの状態を監視し、冗長性を提供し、フェイルオーバーを処理することで、停止の影響を軽減することができます。

  Blackhole攻撃は、クラスタが応答しないノードを適切に処理し、障害から回復し、健全なノードにトラフィックを負荷分散し、スプリットブレインを回避できるかどうかを検証できます。

• モニタリングとアラート機能の検証

  応答のないノード、切断されたノード、または故障したノードを検出できることは、信頼性を高めるために重要です。 監視ツールはネットワーク障害が発生しているノードを検出し、自動修復プロセスを開始するか、エンジニアに通知するように設定されている必要があります。

  Blackhole攻撃を利用することにより、監視ツールとアラートツールが正しく設定されているかどうかをテストし、チームに迅速に通知することができます。

ビジネスイニシアティブ

• 事業継続計画と災害復旧計画

  Blackhole攻撃はシステムやサービスが突然失われた場合を想定して行われます。 システムがビジネスにとって重要なものであれば、できるだけ早くサービスを復旧させる計画を立てることが重要です。

  安全かつ管理された方法で、システム全体の停止をシミュレートすることができるため、実際の災害のようなストレスを感じることなく、インシデント対応や復旧計画を実践することができるのがBlackhole攻撃の強みとも言えます。

• クラウドへの移行を効率化

  クラウドでは、可用性はクラウド・プロバイダーの可用性に依存します。ネットワーク障害によりクラウドプロバイダーの一部がオフラインになった場合、自社のシステムにも影響が及ぶ可能性があります。

  Blackhole攻撃はこのようなことに事前に備えることができ、結果としてサービスの耐障害性を高め、予期せぬダウンタイムを回避することができます。

DNS攻撃

DNSの停止を想定したテストを行い、フォールバックDNSサーバーとDNSリゾルバの設定の両方を検証できます

技術的なユースケース

• DNSプロバイダーの障害に備える

  DNSは現代のネットワークにおいて重要な役割を果たしていますが、DNSの障害はシステムの停止を引き起こすことも多いです。

  DNS攻撃を実行することで、DNSの障害を事前にシミュレートし、他のDNSサービスへのフォールバック能力、オンラインに戻った後のプライマリサービスへのトラフィックの再ルーティング、障害時のサービスの運用維持をテストすることができます。

ビジネスイニシアティブ

• 可用性と稼働率の向上

  DNSが停止すると、すべてのシステムが正常に動作していても、WebサイトやWebサービスがオフラインになったように見えてしまいます。

  DNS攻撃を利用して、DNSの停止に備え、その影響を軽減し、可用性と稼働率を向上させることができます

Latency攻撃

アウトバウンドのネットワークトラフィックに制御された遅延を注入することで、様々なネットワーク条件下でのシステムの応答性をテストします

技術的なユースケース

• クラウドへの移行

  クラウド環境では、オンプレミスのデータセンターと比較して、特にリソースが複数のアベイラビリティ・ゾーンやリージョンに分散している場合、より多くのレイテンシーが発生する可能性があります。

  クラウドへ移行する前にLatency攻撃を行うことにより、レイテンシーの高い環境でアプリケーションがどのように動作するかを判断することができます

• 不安定なネットワーク状態や接続性の悪さをシミュレート

  クラウドプロバイダーのネットワークが飽和状態になったり、ユーザーにはデータの上限や帯域幅の制限があったり、ユーザーがホスティングプロバイダーから離れた場所にいたりすると、安定した高速なインターネット接続が保証されるわけではありません。

  Latency攻撃はこのような状況を再現することができます。実際にシステムがどのように動作するのかを示すことができますし、 様々なネットワーク条件の中で一貫して良好なユーザーエクスペリエンスを実現するために、アプリケーションを最適化することができます。

• ロードバランシングルールの設定

  多くのネットワークゲートウェイやロードバランシングツールは、レイテンシーに基づいてノード間のトラフィックを自動的にリルートすることができます。

  Latency攻撃を特定のノード、アベイラビリティゾーン、あるいはリージョン全体に対して実行し、トラフィックがより高速なリソースにルーティングされ直しているかどうかを検証することで、設定が正しいのかを確認できます。

• タイムアウトと再試行のしきい値の微調整

  タイムアウトを適切に設定しないと、ユーザはサーバからの応答をいつまでも待つことになります。応答が長いと、ユーザーは競合のサービスに移る可能性が高いでしょう。

  Latency攻撃で、タイムアウトがリクエストの処理に指定された時間以上かからないことを検証します。また、同時にリトライ機構の検証にもなります。 一時的なネットワークの切断など、短時間のエラーでリクエストが失敗するリスクを低減できます。

• コンカレンシーコントロール(並行性制御)のテスト

  メッセージングキューや分散データベースなど、時間に敏感なワークロードでは、レイテンシーによってデータの整合性、分散ロック管理、レプリケーションなどに問題が生じることがあります。

  Latency攻撃でこれらのメカニズムを先取りしてテストし、回復力があり、予期せぬ動作が発生しないことを確認します

ビジネスイニシアティブ

• ピーク時のトラフィックイベントに備え、ユーザーエクスペリエンスを向上させる

  ピーク時のトラフィックイベントでは、ネットワークトラフィックが大幅に増加するため、ネットワークのレイテンシーが増大します。その結果、不安定になったり、エラーが増えたりすることがあります。

  Latency攻撃を実行することで、高レイテンシーのイベントを積極的に再現し、レイテンシーがシステムに与える影響を観察、緩和し、イベント発生時の準備を整えることができます。

• クラウドへの移行を効率化

  オンプレミスからクラウドのプラットフォームやサービスに移行する際、ネットワークのレイテンシーはパフォーマンスの要因となります。クラウドのインフラやサービスは、すべてネットワーク上で通信しており、サービスが分散している場合は、レイテンシーの量が増加します。

  オンプレミスでLatency攻撃を実行することにより、クラウド移行前にレイテンシーの増加がアプリケーションに与える影響を観察することができます。

パケットロス攻撃

送信ネットワークパケットの一定割合がドロップまたは破損した場合のシステムのエンドユーザー・エクスペリエンスをテストする。

技術的なユースケース

• 高データスループットを必要とするストリーミングサービスのテスト

  音声やビデオ会議、マルチプレイヤーゲーム、メディアストリーミングなどのサービスは、スループットを最大化するために、ブロードキャストやマルチキャストサービスでは、TCPではなくUDP接続を使用することがよくあります。これにより、スループットが向上し、より多くのユーザーをサポートできるようになりますが、その代償として、信頼性が低下し、パケットがドロップする可能性があります。

  パケットロス攻撃を実行すると、ストリームの品質やバックエンドシステムの負荷にどのような影響を与えるかを検証することができます。

• グレースフル・デグラデーション（Graceful Degradation）・メカニズムのテスト

  グレースフル・デグラデーションとは、システムの中核機能を維持しながら、システムの負荷を軽減する方法です。

  例) ユーザーがビデオ会議を利用していて、利用可能な帯域が低下した場合、ビデオ会議プラットフォームは、ビデオの品質を低下させたり、ビデオを完全に停止して残りの帯域をオーディオに割り当てたりして調整します

  パケットロス攻撃は段階的な劣化メカニズムをテストし、インシデントが発生してもユーザーエクスペリエンスが維持されることを確認するのに有効です。

• QoS（クオリティ・オブ・サービス）ポリシーのテスト

  ネットワークがある種のトラフィック（例：ビデオのストリーミング）で飽和状態になると、他のアプリケーションでも遅延やパケットの損失が発生する可能性があります。 QoS（Quality of Service）ポリシーは、帯域幅が制限されたときに特定の種類のトラフィックに優先順位をつけることで、このような事態を防ぐことができます。

  パケットロス攻撃はこのような状況をシミュレートし、QoSポリシーの検証や微調整に役立てることができます

ビジネスイニシアティブ

• トラフィックピーク時の対策

  パケットロスやパケット破損は、トラフィックが多くネットワークが混雑している時に顕著になります。

  パケットロス攻撃は、ネットワークトラフィックが大幅に増加しても、データの損失や破損が発生しないようにするために役立ちます。

• データの完全性の確保

  アプリケーションによっては、パケットの損失や破損がデータの損失につながる場合があります。

  パケットロス攻撃の実行でシステムサービスが確実にパケットロスを検出し、再送信できるかどうかを検証することができます。 データ規制を遵守しなければならないアプリケーションでは特に有効な手段となります。

• ユーザー・エクスペリエンスの向上

  音声やビデオ会議、マルチプレイヤーゲーム、メディアストリーミングなど、多くのアプリケーションがパケットロスの影響を受けます。

  パケットロス攻撃を利用することで、リアルタイムシステムが信頼性の低いネットワークに対応できるようになり、ユーザーエクスペリエンスの向上につながります。

最後に

GremlinのNetwork攻撃における技術的なユースケースとビジネスイニシアティブに関して学んだことをまとめてみました。

計4回にわたり、Gremlinのカオスエンジニアリングを効果的に実践するための基礎コースで学んだことの中から、技術的及びビジネスイニシアティブに関してのことをまとめています。 カオスエンジニアリングの実行に際して役に立てれば幸いでございます。

例に挙げられているユースケースなどを自身のアプリケーションやシステムで当てはまるか確認し、カオスエンジニアリング実行の計画、目標を立てていきましょう。