- はじめに
- サービスクォータとは
- サービスクォータを把握しないで生じる問題
- New Relicでサービスクォータの情報を収集する方法
- APIポーリング設定方法
- 連携された情報で作成したダッシュボード
- ダッシュボードの表示間隔によって情報が表示されない
- サービスクォータに関するダッシュボードおよびアラート設定方法
- まとめ
- 宣伝
はじめに
こんにちは。マネージドサービス部の福田です。
みなさんサービスクォータの使用状況ちゃんと把握しておりますでしょうか。
今回はNew Relicで実現できるサービスクォータ管理のお話になります。
サービスクォータとは
サービスクォータとは、AWSの各サービスに設定されている利用上限のことです。以下の2つの目的で設定されています
- AWSサービスの安定性と信頼性を確保するため
- ユーザーの意図しない過剰な利用やコスト発生を防ぐため
※多くのクォータはAWSへリクエストを送ることで上限を緩和できます。
サービスクォータを把握しないで生じる問題
例えばあるチームが、Webサービスの大規模なキャンペーンを計画していました。
キャンペーン時の急激なアクセス増加に対応するため、AutoScalingを導入することにしました。
開発環境でテスト実施し、問題なく動作することを確認したので本番環境で同じ設定を適用しましたが キャンペーン開始直後にエラーが発生し、アクセス急増したにもかかわらずインスタンスが起動されませんでした。
原因を確認すると開発環境では既にEC2インスタンス数のクォータが引き上げられていたが
本番環境ではデフォルトの制限値のままになっておりサービスクォータの制限に引っかかり
新しくインスタンスを作成することが出来ませんでした。
このケースでは、事前に各環境のリソース制限を確認し、必要に応じて上限緩和を行っておくことで、避けられたはずのトラブルでした。
上限緩和申請は、承認までの時間が異なり、数時間で承認される場合もあれば、数日かかるケースもありますのでサービスクォータの利用状況を把握することは重要になります。
New Relicでサービスクォータの情報を収集する方法
構成図
以下方法が考えられるかと思います。
- Trusted Advisorの情報を収集する
- New RelicのAPIポーリングによりTrusted Advisorの情報を取得します。
- Service QuotasのAPIから情報を取得する
- Lambdaを用いてService QuotasのAPIから情報を取得し、取得した情報をNew Relicへ送る方法です。
今回のお話は「Trusted Advisorの情報を収集する」内容になります。
APIポーリング設定方法
New RelicのUI通りに実施すれば問題なく進めると思うので詳細は割愛します。
New Relic の Infrastracture メニューからAWSの画面より設定画面に移動
CloudFormationやTerraform、手動での設定方法が存在する。
手動設定でも画面に沿って進めば簡単に設定が可能
連携された情報で作成したダッシュボード
構成としては以下になっております。
- 複数のAWSアカウント、リージョンごとの情報を横断的に把握するためにダッシュボード変数の利用
- クォータのステータスおよび詳細情報把握できる内容
このダッシュボードを作成する中で詰まりかけた内容がダッシュボード表示間隔になります。
以降はその内容についてお話しします。
ダッシュボードの表示間隔によって情報が表示されない
先ほど表示したダッシュボードの表示間隔は7日間としておりますが
7日以内（1時間や6時間、3日など）にするとダッシュボードにて全て「0」と表示されることがありました。
原因を調べてみると以下内容がわかりました。
AWS側
AWSのドキュメントに以下記載がありました。
最小更新間隔は、チェックの結果により異なります。個々のチェックをリフレッシュすることも、または [まとめ] ダッシュボードの右上隅にある [すべてを更新] を選択してすべてのチェックを一括で更新することもできます。Trusted Advisor ダッシュボードにアクセスすると、直近の 24 時間以内に更新されなかったチェックは、自動的に更新されます。これには、数分かかる場合があります。チェックタイトルの右側に最新の更新日時が表示されます。また、ビジネス、エンタープライズ On-Ramp、またはエンタープライズサポートのお客様の場合、Trusted Advisor データは毎週自動で更新されます。
つまりTrusted Advisorのダッシュボードにアクセスしないとデータの更新は最長で7週間後になるようです。
New Relic側
New RelicのTrusted Advisor IntegrationもIntegration 有効化後に更新された情報のみが取得されるようです。
このためIntegration 有効化後にAWS側のTrusted Advisorの更新をかけるか、AWS による週次のリフレッシュのタイミングで収集されるまで待つしかありません。
Trusted Advisor Integrationの注意点
以上のことからTrusted Advisor Integrationの注意点は以下になります。
- Trusted Advisor Integration有効化後に更新されたデータのみ取得される
- AWS側でのTrusted Advisor更新がないと、データは収集されない
- 最大で7週間データ更新待つ必要がある
- リアルタイム情報ではなく過去7日間の情報を活用することになる
サービスクォータに関するダッシュボードおよびアラート設定方法
Trusted Advisor Integrationを使用した設定
過去7日間の情報に基づいたアラートおよびダッシュボードを実装します。
設定に必要な作業もNew Relic側のAPIポーリングの設定のみになるのである程度運用が落ち着いているシステムや
過去7日間のデータに基づいた情報でもいいのであればこちらを採用する形でいいと思います。
Service QuotasのAPIの情報を使用した設定
Service QuotasのAPIの情報を取得するタイミングによってはリアルタイムの情報を元にアラートおよびダッシュボードの実装が可能です
APIポーリングに比べるとService QuotasのAPI取得するための仕組み化とその仕組みの運用体制も必要になります。
とはいえリアルタイムの情報を元にアラート通知をしたい、Trusted Advisorでは収集されていないService Quotas情報にも対応したい場合はこちらを採用することになるかと思います
（参考）Trusted Advisorで収集される情報について
Service Quotasは250以上のAWSサービスのクォータを管理します。
Trusted AdvisorではService Quotasの一部のクォータを確認することが可能です。
ちなみに本記事を書いた際にTrusted Advisorで確認できた情報は以下です（あくまでも参考レベルでお願いします）
実環境の情報は以下URLを参考にご確認いただければと思います。
| サービス | チェック概要 |
|---|---|
| Auto Scaling | 以下使用量をチェックします - 起動設定数 - グループ数 |
| CloudFormation | - スタック数 |
| DynamoDB | 以下使用量をチェックします - アカウントあたりの書き込みプロビジョンドスループット - アカウントあたりの読み込みプロビジョンドスループット |
| EBS | 以下使用量をチェックします - Cold HDD (sc1) ボリュームのストレージ容量 - アクティブスナップショット数 - スループット最適化 HDD (st1) ボリュームのストレージ容量 - プロビジョンド IOPS (SSD) ボリュームの集計 IOPS - プロビジョンド IOPS SSD (io1) ボリュームのストレージ容量 - プロビジョンド IOPS SSD (io2) ボリュームのストレージ容量 - マグネティック (標準) ボリュームのストレージ容量 - 汎用 SSD (gp2) ボリュームのストレージ容量 - 汎用 SSD (gp3) ボリュームのストレージ容量 |
| EC2 | 以下使用量をチェックします - EC2 オンデマンドインスタンス数 - リザーブドインスタンスのリース数 - EC2-Classic Elastic IP アドレス数 - VPC Elastic IP アドレス数 |
| ELB | 以下使用量をチェックします - アプリケーションロードバランサー数 - クラシックロードバランサー数 - ネットワークロードバランサー数 |
| IAM | 以下使用量をチェックします - インスタンスプロファイル数 - グループ数 - サーバー証明書数 - ポリシー数 - ユーザー数 - ロール数 |
| Kinesis | - リージョンあたりのシャード数 |
| Lambda | - コードストレージの使用量 |
| RDS | 以下使用量をチェックします - DBインスタンス数 - DBセキュリティグループ数 - DBパラメータグループ数 - DB手動スナップショット数 - イベントサブスクリプション数 - オプショングループ数 - クラスター数 - クラスターパラメータグループ数 - クラスターロール数 - サブネットグループ数 - サブネットグループあたりのサブネット数 - セキュリティグループあたりの認証数 - マスターあたりのリードレプリカ数 - リザーブドインスタンス数 - 合計ストレージクォータ |
| Route 53 | 以下使用量をチェックします - トラフィックポリシー数 - トラフィックポリシーのインスタンス数 - ホストゾーン数 - 再利用可能な委託セット数 - 最大ヘルスチェック数 |
| SES | - 1日あたりの送信クォータ |
| VPC | 以下使用量をチェックします - VPC数 - インターネットゲートウェイ数 |
まとめ
AWS Trusted Advisorを通じてサービスクォータの監視を行うことができ、New Relicと連携することで複数アカウント・リージョンにまたがる統合的な監視が可能になります。
監視方法としてはTrusted Advisor IntegrationとService Quotas APIの2つがあり、システムの要件に応じて適切な方法を選択することが重要です。
| 特徴 | Trusted Advisor Integration | Service Quotas API |
|---|---|---|
| 設定内容 | APIポーリング設定のみ | Lambdaなどの実装が必要 |
| 更新頻度 | 最大7週間 | リアルタイム可能 |
| 取得データ | 一部のクォータのみ | 全てのクォータ |
| 運用負荷 | 低い | 運用体制の整備が大変 |
| 想定利用シーン | - リアルタイム性を重視しない場合 - 簡易的な状況把握で十分 |
- リアルタイム性を重視 - Trusted Advisor非対応のクォータも把握したい |
宣伝
弊社では、お客様環境のオブザーバビリティを加速するための伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。
