クラウドでは、自社のアプリケーションやサービスがどのように構築され、利用されているかを定期的かつ詳細に確認することが重要です。これは、インスタンスのサイズを適正化したり、データベースを微調整したり、ストレージ使用量を変更したり、ロードバランサーをより適切に設定したり、さらにはアプリケーションを再構築したりするための機会を特定するための最良の方法です。
例えば、20台のインスタンスがすべて10%のCPU使用率で稼働している場合、より小さなインスタンスを使用したり、より多くの作業をインスタンスに集約したりすることを検討します。このように、クラウドの利用と支出について考えることで、環境を最適化し、迅速にコストを削減することができます。
クラウドアーキテクチャの最適化には、3つの主な目的があります。
- クラウドサービスをより有効に活用することで、パフォーマンス、可用性、エンドユーザー・エクスペリエンスを向上させる。
- コストとパフォーマンスの微妙なバランスを取りながら、クラウド利用を最適化する
- 現在のクラウド支出を正当化するためのビジネス上および技術上の指標を把握し、成長に応じてより大きなクラウド予算を確保するための根拠とすることができます。
このチュートリアルでは、 New Relic platform を使用して、クラウドのアーキテクチャと支出を最適化するために活用すべきすべてのデータを取得する方法を紹介します。
1.アプリケーションとクラウド環境の計測
以下の製品やインテグレーションがインストルメント化されていることを確認してください。
楽器 | 詳細 |
|---|---|
計測インフラストラクチャ:インフラストラクチャ エージェントの要件をまだ確認していない場合は、確認してください。インフラストラクチャには 、アマゾン ウェブ サービス (AWS) 、 Microsoft Azure 、 オンホスト統合など、いくつかのタイプの統合が付属しています。インフラストラクチャ エージェントをホストにインストールすると、すぐにエージェントが収集する幅広いメトリクスにすぐにアクセスできるようになります。 | |
APM でアプリケーションをインストゥルメントします。そうすることで、基盤となるクラウドサービスを最適化しながら、アプリケーションのパフォーマンスを監視することができます。これにより、インフラへの変更が実際にアプリケーションのパフォーマンスを向上させているかどうかを確認することができます。 | |
InfrastructureのAmazonとの統合により、インフラ、ダッシュボード、アラートなど、プラットフォームのあらゆる場所でAWSのデータを監視することができます。 | |
AWS環境でホストされている場合、New Relicは、 AWS Billing の統合により、クラウドの支出を監視することができます。New Relic の AWS Billing 統合を活用するには、 Connect AWS Billing documentation の手順に従ってください。 |
2. ダッシュボードを作成して、異常なインフラストラクチャ メトリックを表示します。可能な場合は AWS の予算を含める
Dashboards では、データに関する強力なカスタムクエリを作成し、その結果を共通のダッシュボードに表示されるウィジェットで視覚化することができます。また、クエリの結果を アラート に直接フィードすることができ、そこで確認された逸脱に関する通知を即座に受け取ることができます。
このステップでは、パフォーマンスと使用状況 (CPU、メモリ、ディスク、データベースなど) に関連する異常なインフラストラクチャ メトリックを表示する必要があります。利用可能な場合は、AWS 予算を含めます。
アプリケーションごとに個別のを作成し、それらのダッシュボードを、ここに示すように 1 つのデータ アプリに収集します。 この AWS プロダクション概要データ アプリには、AWS プロダクション予算に関連するウィジェットのセットが表示されます。 データ アプリは、一連のトピックを段階的に説明し、環境やサービス全体の概要を明確に示すプレゼンテーションに最適です。
3.最適化のためのリソースの特定
このステップでは、New Relicが取得したメトリクスを使って、どのリソースを最適化すべきかを判断する方法を紹介します。
上のダッシュボードのサンプルでは、左側のCPU使用率のウィジェットから、このアプリケーションが多くのサイズのインスタンスを使用していることがわかります。c4.xlarge」インスタンス（珊瑚色）は、常に約20%のCPU容量しか消費していないことに注目してください。しかし、中央のウィジェット（ライトグリーン）で「c4.xlarge」のメモリ使用量を分析すると、このインスタンスのメモリ使用量は20%から80%の範囲であることがわかります。これは、このアプリケーションがCPUよりもメモリに集中していることを示唆しています。この場合、インスタンスタイプを計算最適化インスタンスからメモリ最適化インスタンスに変更する必要があります。なお、これらの最適化を行った際のアプリケーションの平均応答時間は、ダッシュボードの右側のチャートで確認することができます。
これは、最適化の候補となりうるクラウドベースのリソースを特定する方法の一例です。
最適化のためのアーキテクチャを特定したので、次に進みます。インスタンスのサイズを適切に調整する、データベースを微調整する、ストレージの使用方法を変更する、ロード バランサーをより適切に構成する、またはアプリケーションを再構築するなど、最終的な目標は、新しく最適化されたアーキテクチャを他のアーキテクチャと比較できるようにすることです。ステップ 2 でキャプチャした異常。異常の詳細については、目標と異常の確立のチュートリアルを参照してください。
4.オプションアラートの設定
NRQL クエリのアラート条件を作成することができます。必要に応じて、必ず 完全なドキュメント を参照してください。
このクエリを使用して、アラートを設定します。
SELECT latest(`provider.actualAmount`) as '$ Actual', latest(`provider.forecastedAmount`) as '$ Forecast', max(`provider.limitAmount`) as '$ Limit' FROM FinanceSample WHERE provider = 'BillingBudget' AND `provider.budgetName` = '[Your Cloud Budget]'データにクエリを書いてダッシュボードに表示することができれば、それを使って 警告条件 を簡単に生成することができます。
異常クエリ
New Relic では、データに対して「異常クエリ」を作成することもできます。 これらは、結果に厳しい制限を設けずに記述するクエリです。 むしろ、 New Relicアラート マシンにパフォーマンス データを学習させ、データが異常値から大きく外れたときに集計します。
異常クエリを作成するには、 アラート コンソールに移動し、アラート ポリシーに移動して、新しいアラート ポリシーを追加します。次に、次の手順に従います。
警告ポリシーを作成します。ポリシーに簡潔で分かりやすい名前を付け、「インシデントの優先度」を選択します。次に、「警告ポリシーの作成」を選択します。
条件を作成します。 選択する NRQL
クエリを定義し、最近のパフォーマンスに基づいたシンプルなスライダーと視覚化を使用して、New Relic アラートがどの程度制限的にデータを分析するかを決定します。
グラフの下部にあるスライダーは、予算のしきい値 (青い線) の周りの灰色の帯を増減します。表示されている設定では、最近のデータに基づいてインシデントがゼロになるはずであり、それが探しているものです。ただし、青い線が灰色の帯から急上昇または急降下した場合は、すぐに通知されます。
アラートは、クラウドの支出やパフォーマンス データについて積極的に把握するのに役立つ優れた手段です。
もっと詳しく知る
- Proactive alerting and incident orchestration チュートリアルでは、上記のベストプラクティスのいくつかについて詳しく説明しています。