亮介2021.11.16この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。技術的・ビジネスイニシアティブについて基礎コースで学んだことをまとめた記事を投稿したものです。今回は、同じく基礎コースで学べたGremlinでできるカオスエンジニアリングの攻撃タイプごとによるユースケース、ビジネスイニシアティブについてまとめていこうと思います。Gremlinでは大きく3つの攻撃タイプに分けられています。Attacks)以上の3つです。本記事ではリソース攻撃について取り上げます。リソース攻撃は、コンピューティングリソースの消費量の急激な変化に対するテストを行います。リソース攻撃のユースケースとビジネスイニシアティブリソース攻撃の中には、4つのタイプの攻撃が存在しています。CPU攻撃CPU攻撃は、CPUの容量が制限されていたり、枯渇していても、アプリケーションが期待通りに動作することをテストします。私たちのシステムはCPUに負荷がかかっても動作を維持しなければいけませんが、重たい負荷を与える状況はCPU攻撃を用いることで重い負荷を再現できます。オンプレミスのデータセンターからパブリッククラウドの環境に移行する際にも有効です。Scalingとアラートの仕組みの検証クラウドプラットフォーム(AWSやAzureやGCP)のサービスだったり、オーケストレーションのツールは、設定に応じてアプリやシステムを自動でスケールアップできます。監視ツールやアラートツールはキャパが減ると通知してくれます。これらの閾値を決めるのはエンジニア次第となっています。CPU攻撃を行うことによって閾値に達した時にスケールするのか、アラートが通知されるのかを確認することができます。リソースクオータの検証コンテナでは、リソースクォータによって、1つのコンテナで利用できるリソースが制限されます。CPU攻撃を行うことにより、このクォータをテストしてリソースを使い切った時のアプリケーションの状態を把握することができます。オーケストレーションツールが期待通りにクォータを実行しているかどうかも確認できますビジネスイニシアティブピーク時のトラフィックイベントに備えるCPU攻撃は、トラフィックが増えるイベント(ブラックフライデーとか)の状況をシミュレートすることができます。このようなイベントでの影響を制御された環境で安全にシミュレートすることで、実際のイベント時に備えることができます。クラウドへの移行を効率化クラウドへの移行を開始する前にCPU攻撃を行うことにより、共有インフラ上のノイズや、CPU能力が下がったインスタンスの状態をシミュレートできます。以降作業を開始してから予想外の問題が発生することを防ぐことができます。運用コストの削減クラウド環境では本番トラフィックの予測に基づいてCPUキャパシティを過剰にしてしまいがちですが、CPU攻撃でさまざまなレベルのCPU下でのアプリケーションのパフォーマンスを測定できます。これによりキャパシティを調整できる情報を得ることになります。オートスケーリングを検証することで、キャパシティをリアルタイムに調整することが可能になり、更なるコスト削減が期待できます。Disk攻撃Disk攻撃は、ストレージスペースが限られていたり、利用できない場合のシステムやアプリケーションの動作をテストし、動的なストレージプロビジョニングシステムを検証します技術的なユースケースディスクの容量とスループットのテストDisk攻撃は、復元されたバックアップ、複製されたデータベース、大規模なログファイルなど、大規模なデータセットの読み書きをシミュレートするためによく使用されます。これによりワークロードを移行する前にディスク容量を確認できるだけでなく、ディスクスペースを埋めるプロセスがパフォーマンスにも影響を与えることも確認できます。大量のデータを読み書きすると、ディスクのスループットが低下し、アプリケーションのスループットが低下する原因となるので、大規模なDisk攻撃は容量、スループット、および同時実行性を同時にテストすることができます自動ディスククリーンアップ、圧縮、およびプロビジョニングのテスト私たちはディスク容量を追加するためにいくつかの自動化されたメカニズムを使用します。自動クリーンアップおよび圧縮ツール、シャーディング、ディスククォータシステムといったメカニズムをDisk攻撃によってテストし、期待通りに動作するかどうかを確認できます。他のリソースと同様に、私たちはディスクの使用状況を監視し、ディスク容量の不足による問題を回避する必要があります。監視と閾値を設定し、適切にアラート通知を受け取れるのか、問題の対応が自動で行われるのかなどを確認します。ビジネスイニシアティブ運用コストの削減クラウド環境では、高速で大容量のストレージは高価になりがちです。Disk攻撃で安価なストレージがワークロードに与える影響をシミュレートできるので、パフォーマンスを損なうことなくコスト削減ができる可能性があります。障害発生のリスクを低減ディスク容量の枯渇は予期せぬ障害を引き起こすことがあります。Disk攻撃でモニタリングやアラート機能を積極的にテストすることで、チームは重大なインシデントや停止の原因となるディスク使用量を排除できる可能性があります。IO攻撃IO攻撃は、重いIO操作のテストを行い、アプリケーションへの影響を把握することができます。技術的なユースケースストレージ移行の準備クラウド環境では高速なストレージは高価になりがちですが、クラウドへの移行はそういったソリューションソリューションへの移行を意味することが多いです。ストレージごとにIOPSが異なるので、アプリケーションのパフォーマンスにも影響します。IO攻撃で、低速なストレージ状況のパフォーマンスをシミュレートすることにより、ユーザーに与える影響を測定し、移行を開始する前に高速なストレージのコストメリットを判断することができます。ディスクを多用するワークロードのテストデータベースのように頻繁に、あるいは重いディスクアクセスを必要とするアプリケーションがありますが、重いIO操作は、CPUやRAMの使用率にも影響を与え、アプリケーションやシステムに意図しない副作用をもたらします。IO攻撃によりこれらのアプリケーションや操作をシミュレートし、影響を観察することが可能です。IO攻撃で基礎となるディスクに負荷をかけ、アプリケーションの応答性を測定することで、キャッシュの有効性を検証することができます。IO攻撃はディスク障害は発生しませんが、使用可能なIOPSをすべて消費してディスクが応答しなくなることで、ディスクが使用できない状態をシミュレートできます。これにより、ディスクにアクセスできなくなった時にキャッシュが有効に機能しているかどうかを確認できます。ビジネスイニシアティブピーク時のトラフィックに備えるブラックフライデーやサイバーマンデーのようなトラフィックのピーク時には、より多くのデータをディスクに書き込む必要があるのでスループットは低下します。IO攻撃を実行することで、この影響をシミュレートし、本番環境でのピークに備えて準備ができます。エンドユーザーエクスペリエンスの向上ディスクの待ち時間は、UXに影響を与えます。IO攻撃中にアプリケーションのパフォーマンスをテストすることにより、レイテンシーのある箇所を特定して最適化することが可能です。新製品の立ち上げを効率化メディアストリーミングやファイル共有サービスのように、高いディスクスループットを必要とするサービスを立ち上げる準備にIO攻撃が役に立ちます。サービスの利用が高い状況でも安定したパフォーマンスを提供しているかどうかの確認を行えます。Memory攻撃Memory攻撃は、システムのメモリ使用量をテストし、使用量が急激に増加しても耐えられるか、パフォーマンスを発揮できるかをテストします。技術的なユースケースメモリリークとアウトオブメモリ(OOM)エラーに備えるMemory攻撃を行うことによりメモリを消費し、アプリケーションのパフォーマンスや可用性に大きな影響を与える可能性があるメモリリークやOOMエラーが発生した時の状況の確認して本番環境への準備を行えますメモリを大量に消費するワークロードのテストインメモリキャッシュ、データベース、機械学習モデルなど、本質的にメモリを大量に消費するワークロードでの確認が導入前に確認できます。キャパシティプランニングやインフラの最適化に役に立ったりもします。Scalingのしきい値の設定と検証、リソースクォータ(cgroupsやKubernetesのリソース制限など)の設定の検証、アラートのしきい値の検証など、クラウド移行の準備に役立ちます。ビジネスイニシアティブピーク時のトラフィックに備えるCPUと同様に、メモリ使用量もアクセスの増加に応じて変化します。ブラックフライデーやサイバーマンデーのようなトラフィックの多いイベントの前に、Memory攻撃を行うことで、このような状況をシミュレートし、準備をすることができます。運用コストの削減CPUと同様に、Memory攻撃を行い、変化するメモリ環境下でのアプリケーションの安定性を検証し、より良い容量計画と潜在的なコスト削減が可能になります。最後にGremlinのリソース攻撃における技術的なユースケースとビジネスイニシアティブに関して学んだことをまとめてみました。例に挙げられているユースケースなどを自身のアプリケーションやシステムで当てはまるか確認し、カオスエンジニアリング実行の計画、目標を立てていきましょう。Attacks)に関することをまとめます。亮介2021.11.29Gremlinのシナリオを使ってTLS/SSL証明書の有効期限をテストしてみる。