Observability in Practice: Running A Game Day With New Relic One And Gremlinの意訳です。

ソフトウェア開発には、バックアップは最後に行った復元と同じ程度に良いという古い真実があります。似たようなことがあなたのObservabilityプラットフォームのにもあてはまります。思いがけない障害に遭遇するまで、それがどのくらい良いものか知ることはできない。その時初めて、ダッシュボードに見えるスパイクと実際のシステムの動きを関連づけることができる、と。

New Relic Solution Architectはお客様と協力して、プラットフォームを使用するためのベストプラクティスを構築します。これらの顧客エンゲージメントに参加しているときは、New Relicが動作していることを示すためにシステム障害を待つことはできません。しかし、最近、いくつかのカオスエンジニアリングで制御されたシステム停止を作る機会がありました。Gremlinの友人たちから少し助けを借りて、カオスに直面した時のNew RelicのObservabilityプラットフォームの価値をお客様に示すことができました。

Gremlinによるカオスエンジニアリング

カオスエンジニアリングとは、システムの弱点を明らかにするために制御された実験を容易にすることです。これらの実験は一時的にシステムにストレスを与え、さまざまな条件でどのように応答するかをシミュレートします。ユーザーにとって問題になる前に問題を特定することが目標です。理想的には、グレムリンでは、4つのステップでこれを達成します。

  1. 優れたサイトの信頼性の実践とObservabilityを備えた状態で災害に備える
  2. 本番環境で自動テストを実行する
  3. 非運用システムにカオスを注入する
  4. 自動化されたカオスをどこにでも注入する

グレムリンは、最先端のカオスエンジニアリングプラットフォームです。Gremlinを使用すると、プラットフォームとアプリケーションインフラストラクチャのすべての層でカオス実験を安全かつセキュアに実行できます。レイテンシーの追加、ブラックホールによるネットワークトラフィックのドロップ、ホストのシャットダウン、CPU使用率のスパイク、DNSの攻撃などの実験を実行できます。

Gremlinではさまざまな攻撃を設定できます。

つまり、システムのさまざまな部分に安全で制御された方法でストレスをかけることができます。ただし、GremlinとNew Relicをペアにすると、システムが攻撃されたときの動作を詳細に把握できます。

GremlinとNew Relic:実際の顧客の問題を解決する

最近、グレムリンと協力して、顧客が企業ネットワークまたはアプリケーションにログインできなくなるランダムな問題が発生するのを支援する機会がありました。これらの問題を先取りし、適切なアラート、インシデント管理プロセス、および運用手順書を作成できるように  、お客様とのゲームデイを実施しました。

お見逃しなく:SRE として Adversarial Game Day (敵性ゲームデイ) を行う方法

ゲームデイは避難訓練です。これは、安全な環境で一般的な現実世界のシナリオを実践する機会です。何かを壊してから、チームが問題にどのように反応するかを観察します。適切な人がアラート通知を受けますか?ダッシュボードは正しい情報を提供していますか?チームはどのように反応しますか?彼らはどのくらい早く障害を解決することができますか?

このゲームデイでは、遅延を追加した場合に顧客のCassandraデータベースがどうなるかを確認したかったのです。Gremlinを使用して10ミリ秒のレイテンシを追加することで、ゲームの日を始めました。

New Relicは遅延をすぐに認識し、適切なアラートを発しました。このスクリーンショットでは、1つの攻撃に関連付けられた複数のメトリックが表示されています。

New Relicは、10ミリ秒のレイテンシの影響を容易に認識しましたが、実際の世界では、それはお客様のエンドユーザーにとっては小さなものです。そこで、レイテンシを100ミリ秒まで上げました。

その後、混沌が這い寄ります。

それは、New Relic Syntheticsからのいくつかの予期しないアラートで始まりました:応答時間の増加により複数のアラートが発生しました:

遅延が続くと、顧客のKubernetesクラスターでいくつかの重要なアラートが発生することがわかりました。

遅延により、クラスター内のいくつかのポッドのメモリ使用量が増加し、ハードメモリの制限に当たりました。

導入したCassandraの遅延は、アプリケーション全体に波及し、応答時間からネットワーク、アプリケーションをホストするクラスターまですべてに影響し、エンドユーザーエクスペリエンスに大きな影響を与えました。しかし、New Relicを導入することで、顧客はこれらの障害がデータベースに直接どのように影響したのかを正確に確認できました。

ゲームデイはチームワークです

最初の実験の後、顧客はKafkaクラスターとAmazon EC2インスタンスでレイテンシ実験を行いました。これらの各シナリオで、New Relicは攻撃を検知し、適切なオンコールチームにアラート通知しました。対応チームは、これらの状況のそれぞれで根本原因を探し出すことをシミュレートし、インシデント対応プロトコルを改善することができました。顧客は十分にふりかえりを行い、満足して、7時間でゲームの日を終了しました。

このゲームデイで使われたGremlinとNew Relicは、ユーザーに影響を与える前に顧客にとって重大な問題を特定しました。Gremlinを使用して実際の障害シナリオを安全にシミュレートすることにより、顧客のエンジニアリングチームとSREチームは、New Relicの監視とアラートに自信を持ち、インシデント対応プロトコルを磨き、問題の特定と解決にかかる時間を短縮しました。

実際、New Relicでは、私たちのユーザーが行う前から、Gremlinを使用してシステムを改善しソフトウェアの問題を積極的に発見しています。これはあらゆるObservabilityの実践にとって不可欠なツールです。


New Relic 担当者にNew Relicを使ったゲームデイについてもっと聞きたい方はこちらまで。

ソフトウェアエンジニア、インフラエンジニアなど自社開発や自社運用の現場で経験を積んだのち外資系ソフトウェアベンダーでのテクニカルサポートを経て現職。New Relicユーザーだった経験あり。コミュニティでの登壇活動も多く、Microsoft MVPを7年連続受賞中。Microsoft Certified Azure Solutions Architect Expert。得意分野はC#をはじめとするソフトウェア開発、Kubernetes関連技術およびパブリッククラウド。 View posts by .