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