日本語翻訳(部分編集あり)になります。技術解説であり、シフトライト、シフトレフト、及びセルフヒーリング(自己修復)を、どのように継続的デリバリとディプロイメントパイプラインに実装するか、その方法について説明するものです。このチュートリアルでは、フルスタックモニタリングのためにDynatraceを、パイプライン、ディプロイメント、オーケストレーション、コンピューティング、ストレージのためにAWSのサービスを選択していますが、同じことを他のクラウドプラットフォームやCI/CDツールに対しても適用できるはずです。ディプロイメント」(右側)までのデリバリパイプラインのフローを示しています。この中で、Dynatraceは、各ステージ間(クオリティゲート)で監視者の役割と、プロダクション環境でのセルフヒーリングをコントロールする役割を担っています。【画像】AWSとDynatraceを使用したシフトレフト(クオリティゲート)、シフトライト(モニタリングへのコンテキスト情報提供)、およびセルフヒーリング(自己修復)このチュートリアルでは、モダンなデリバリパイプラインにおける、フルスタックモニタリングの果たし得る役割を示しています。等)のモニタリングを自動でディプロイし有効化できること。使用される技術スタック(言語やフレームワーク等)に関係なく、すべてのプロセス、サービス、およびアプリケーションを自動で検出できること。シフトライト:ディプロイメント情報やメタデータをモニタリング環境にプッシュできること。ブルーとグリーンのディプロイメントを区別したり、ビルドまたはディプロイメントのリビジョン番号をプッシュし構成の変更を通知すること、など。シフトレフト:パイプラインを停止するか実行するかを決定するために、APIを介して特定のエンティティ(プロセス、サービス、アプリケーション、テストなど)のデータを取得できることセルフヒーリング(自己修復):発生したシステムトラブルの根本原因に対応する様な、インテリジェンスな自動自己修復ができること。GC設定不良の自動修正それではこれらの4つの要件を、上述のチュートリアルの中で実際にどう実装したか、解説していきます。自動化されたフルスタックモニタリングの実装例:DynatraceのOneエージェントテクノロジーは、それぞれ異なるエージェントで監視するような対象(Java、.NET、Webサーバー、ノード、Lambdaなど)や、それぞれ異なるツールで監視するような対象(ネットワーク、ログ、コンテナ、クラウド)も、1つのエージェントでまとめてフルスタックの自動監視を実現します。Oneエージェントを自動デプロイしています。以下は、私のCloudFormationテンプレートの抜粋です。任意のDynatraceテナントで機能するように、実際のダウンロードURLがパラメーター化されています。...",EC2インスタンスが起動すると、Dynatraceは次のスクリーンショットの様に、自動的にフルスタックの監視(フロントエンド、サーバサイド、インフラ、ログ、クラウド等)を開始します。スマートスケープが表示され、右側に各エンティティの一部のデータが自動的にキャプチャされています。APIからもアクセスできます。シフトライトの実装例:私にとってシフトライトとは、ディプロイメントまたは変更に関するコンテキスト情報を、監視プロセスにプッシュすることを意味します。獲得するコンテキスト情報が多ければ多いほど、問題の根本原因をより適切に検出することも、セルフヒーリングをより効果的に実装することもできます。メタデータ(タグ、プロパティなど)をフルスタック監視プロセスに渡すシフトライトの最初の実装は、自動化されたディプロイメントプロセスのメタデータを取得することです。等のタグなどのメタデータを自動でキャプチャします。これにより監視ツールでエンティティにタグを付け直す必要がなくなります。プラットフォームで既に指定したものを再利用するだけです。それらプラットフォームからのメタデータの自動キャプチャに加え、Dynatraceは環境変数、Javaプロパティなどからも、メタデータを抽出できます。エクスポートしています。Oneエージェントがプロセスグループのメタデータとして取り扱う特別な環境変数です。ビルド固有の情報を含む独自の環境変数やJavaプロパティがある場合、Dynatraceのカスタムプロセスグループ検出ルールを設定することで、これらを取得できます。CodeDeployスクリプトがどのように見えるかを示しています。【画像】ディプロイメントスクリプトを使用して、メタデータをDynatrace監視対象エンティティに渡します。呼ばれるものに相当します。APIは、カスタムタグ、時系列、またはカスタムイベントを監視対象エンティティ(ホスト、プロセスグループインスタンス、サービス、またはアプリケーション)にプッシュする機能を提供します。Dynatraceが監視しているサービスに対してプッシュしました。私見では、シフトレフトとは、次のきわめて重要な質問に答えるために、より多くのデータをライフサイクル初期に獲得することであると考えます。この変更は、プロダクションにプッシュしても良いようなものなのか、それとも悪いものなのか?そして、それが悪い変更であった場合は、決してパイプラインの先にプッシュさせてはいけません!パイプラインで確認すべきデータはパフォーマンス関連の監視データだけではありませんが(コード品質に関するメトリックも確認しましょう)、ビルド検証を自動化するために、多くの人がそれらをパイプラインに自動的に含めることにトライしています。使って、パイプラインによってプッシュされるサービスの異なる複数のメトリックを比較することで、ビルド検証プロセスを自動化させています。プッシュされようとしているカレントビルドを、他のベースラインビルドと比較したり、更にはプロダクションの稼働状況と比較します。Code)を示しており、メトリックを取得する先(どの環境か)と、これが良いビルドか悪いビルドかを判断する方法(しきい値の定義)について説明しています。【画像】ビルドまたは環境毎のメトリックを比較することにより、変更によって、パフォーマンスを改善させているか又は低下させているかどうか確認できます。従来、ビルド検証はパフォーマンスエンジニアによって手動で行われ、パフォーマンスエンジニアはさまざまな時間枠のさまざまなダッシュボードをプルアップし、親指を上げたり下げたりしていました。関数は、パイプラインの承認ステージにおいて、次のステージへの移行を許可または拒否します。すべてのビルド検証結果と比較されたすべてのメトリックは、私が作成したHTMLレポートからもアクセスできます。【画像】すべてのビルドについてのDynatraceによるビルド検証結果。新しいビルドのすべてのメトリックをベースラインと比較表示します!次のアニメーションは、これがパイプラインにどのように統合されるかを示しています。重要な点は、有効な比較となるように、十分な長さの負荷テストで十分なデータを取得して初めて、ビルド検証プロセスを実行できることです。このための”待機”は、DynamoDBテーブルに入力された検証リクエストと、十分な時間が経過したときにのみそのリクエストを実行するLambda関数の、それぞれを実行する期間によって実現されます。【画像】デプロイが成功すると、ビルド検証リクエストが発行されます。セルフヒーリングの実装例:テストをしたからプロダクションで順風満帆だ、という訳では決してありません。したがって、プロダクション環境で何か問題が発生した場合の状況を自動化する方法も検討する必要があります。AIは自動的に発生した問題を検出し、Oneエージェントが収集したフルスタックすべてのデータの中から、根本原因を自動で検出します。問題が検出されるたびに、Dynatraceは外部ツール(ServiceNow、PagerDuty、xMattersなど)に通知したり、Webhookを呼び出したりできます。Lambda関数を実装しました。Lambda関数は、問題に関するDynatraceからの付加的情報を獲得します。最新のディプロイメントが何で、いつ行われたか、などです。CodeDeployを呼び出して、プロダクション環境に以前のリビジョンをディプロイます。【画像】古典的なロールバックシナリオ。AIで検出された問題とその根本原因のデータを使用して問題を解決する以前のリビジョンをディプロイすることは、究極のセルフヒーリングプロセスではないことは理解しています。問題の根本原因と環境に応じて、システムを修復するための様々なアクションを実行する必要があります。ここでは、実際に私が関わった3つの問題と、Lambda関数などで修復用スクリプトを使って、システムをセルフヒーリングするために何をしなければならなかったについて説明しています。彼はDevOpsコミュニティへの定期的な寄稿者であり、技術カンファレンスでも頻繁に講演を行っており、blog.dynatrace.comで定期的に記事を公開しています。Hiyoshi@HH_DynatraceDynatraceに関する技術情報をポストします。upLoginユーザーは見つかりませんでした。