技術部所属、インフラエンジニアの廣田です。
こちらはRetty Advent Calendar 2021 Part2の25日目のエントリーとなります。
去る2021年12月1日、Amazon DevOps Guruの拡張機能となる、Amazon DevOps Guru for RDSがリリースされました。
個人的に関心があり、試しに軽く触ってみたのですが、なかなか有用なサービスである事が理解出来た為、この機会にAmazon DevOps Guruの紹介がてら、これらのサービスについて簡単にまとめてみました。
Amazon DevOps Guruとは
Amazon DevOps Guru(以降はDevOps Guruとする)は、2020年12月1日にプレビューが公開され、2021年5月4日に一般公開された、AWSの機械学習系サービスの1つです。
このサービスは、Amazonが長年に渡るAmazon.comの運用で培ってきた技術や経験を元に強化した機械学習を応用し、ユーザーのアプリケーションを構成するAWS上のインフラリソースから、関連するメトリクスやログ、イベント、トレースといったデータを自動的に収集して分析にかけ、通常の運用パターンから逸脱する様な挙動を検知すると、インサイトとしてそれがアプリケーションにどういった影響を及ぼす可能性があるのかを報告し、その問題の原因を推察した上で、解消する為の推奨事項までを提示してくれるといったものになります。
検知される問題としては、リクエストやレイテンシーの急上昇、エラー率の増加、ディスクスペースの不足、不正なコードのデプロイメント、メモリリーク等、AWSサービスのリソースに応じて発生しうる諸問題に広く対応している模様です。
また、DevOps Guruで検出されたインサイトは、Systems ManagerのOpsCenterと連携し、OpsItemとして作成する事が可能となっており、OpsCenterを利用しての運用タスク管理や、Automationによる対応作業の自動化を検討したり、通知にはSNSが使用出来る為、AWS Chatbotとの連携であったり、Atlassian OpsgenieやPagerDuty等のインシデント管理系SaaSとの統合も図れます。
このサービスを利用する事により、アプリケーションのパフォーマンスや可用性の改善といった、システム障害を未然に防ぐ為のプロアクティブな対応であったり、障害発生時のリアクティブな対応における平均修復時間(MTTR)を軽減させるといった、Amazonの機械学習を通した支援を受ける事が出来る様になる訳です。
ユーザーが運用するアプリケーションのインフラ監視を広くカバーしてくれるフルマネージドなサービスであり、導入は分析対象となるリソースを指定して有効化するだけ、といった具合でハードルも低く、細かな監視設定やその基盤構築に関する専門的な知識も必要としない為、導入や運用コストの面から述べると非常に有用なサービスと言えます(特に、監視体制が整っていない様な現場においては、この恩恵は大きいかと思います)。
分析対象となるAWSサービスと料金
DevOps Guruが分析対象とするAWSサービスは、2021年12月25日の時点ですと、EC2(Auto Scaling Group)やECS、Lambda、RDS、S3、Route53等を始めとした、全25種類に渡っており、AWS上でシステム構築する場合に利用されるケースの多い主要なサービスは、概ねカバーされています。
料金は、分析対象となるAWSサービスのリソース数×時間と、DevOps Guruに対するAPIコール数の単位でそれぞれに従量課金される体系となっており、この内、リソース数に対しては、AWSサービスに応じて2パターンの料金が定められています。
- 分析料金
- リソースAグループ(Lambda関数とS3バケット)：1つにつき\$0.0028/時間 (1日で\$0.0672、30日で\$2.016)
- リソースBグループ(上記以外)：1つにつき\$0.0042/時間 (1日で\$0.1008、30日で\$3.024)
- APIコール
- 1回につき\$0.00004 (1万回で\$0.4)
この料金は全てのリージョンで統一されており、無料利用枠の方も存在していまして、リソースA/Bグループに対してそれぞれ合計7200時間/月と、APIコール1万回/月が3ヶ月まで無料となります(より詳細な情報は、公式の料金ページの方をご覧ください)。
AWSの監視サービスにはCloudWatchアラームがあり、そちらと比較してみると料金的には割高にも見えますが、ある1つのリソースを監視対象として考えた場合、CloudWatchアラームであれば、複数の観点で問題を検知する為には、その観点毎に個別のアラームを閾値等を調整した上で設置する必要があるものの、DevOps Guruですと、単純にリソースを分析対象に含めるだけで済み、問題も継続的なリソースのデータ観測結果に基づいて検知される為、誤検知する可能性が少なくなるのと、アプリケーションの成長等に伴った閾値の調整も不要となり、加えて、問題が検知されれば、その問題の箇所と推測される原因の特定、対応すべき推奨事項の提示までされる点を考慮すると、妥当な料金かなという印象です。
導入方法について
以下の動画が簡潔で分かり易い為、まずは初めに視聴してみる事をお勧めします。
実際に手を動かしたい方には、公式にDevOps GuruのWorkshopも用意されていますので、Sandbox用途のAWSアカウント等があれば、そちらを一通り実施してみるのが手っ取り早いです(無料利用枠が無くなっていると幾ばくかの課金が生じますので、実施後には必ずリソースのクリーンアップを行いましょう)。
catalog.us-east-1.prod.workshops.aws
なお、DevOps Guruを利用する上で、分析対象を決定(分析カバレッジの境界を設定)する際には注意が必要となります。
分析対象の決定方法には3通りありまして、上述のWorkshopですとCloudFormationのStackを指定し、そこで定義されているリソースのみを検出しているのですが、この他に、AWSアカウント内の分析可能なリソース全てを検出する方法と、特定のタグが付与されたリソースのみを検出する方法とがあります。
盲目的にAWSアカウント内の全てのリソースを検出してしまうと、内包する検出可能なリソースの数によっては、膨大な課金が生じてしまう可能性があるのと、1つのAWSアカウント内で複数のアプリケーション等を運用している場合ですと、意図しない形でリソースがまとめられてしまう為、アプリケーションやステージをAWSアカウントレベルで完全に分離でもしていない限りは、全てのリソースを選択するのは、管理上あまり望ましくはありません。
アプリケーション毎に関連するリソースの構築を全てCloudFormationで実施されている場合であれば、Stackを指定するのが推奨されますが、構築が自動化されておらず手動であったり、CloudFormation以外のIaCツールを利用しているのであれば、リソースに対してDevOps Guru専用のタグ付けを行い、アプリケーション単位で関連するリソースを適切にまとめた形で、分析対象に検出させる様にする事を勧めます。
ちなみに、DevOps Guruには、基本的には無料で利用出来るコスト見積りツールも用意されており、各分析対象の検出方法に応じてリソースを洗い出し、それぞれの時間毎の料金と月額を算出してくれますので、DevOps Guruの利用を開始する前には、必ず実行しておくのが良いでしょう(ただし、分析対象となるリソースがあまりに多すぎると、見積りの実行が終わらなくなるケースがあった為、現状、その場合はAWSサポートに問い合わせて対応する必要があるので、気を付けてください)。
ここまでが、DevOps Guruの紹介となります。
Amazon DevOps Guru for RDSとは
冒頭に記述している通り、こちらはDevOps Guruの拡張機能で、Amazon Aurora PostgreSQL / MySQLのリソースに対する、Performance Insightsが収集するDBロードや、パフォーマンスカウンター、OSのメトリクスを、DevOps Guruで分析するデータに含める事が出来る様になりました。
これにより、デッドロック、接続要求過多、SQLクエリの性能劣化、CPUやI/Oの競合、メモリの問題や、その他にもアプリケーションの品質に影響を及ぼす可能性のあるリレーショナル・データベースに纏わる様々な問題を、DevOps Guruが検知して原因を分析の上、解決策の推奨まで支援してくれる様になる為、リレーショナル・データベースに対する深い知識を有していないユーザーであっても、トラブルシュートが容易になり、パフォーマンス改善に費やす時間を短縮する事が可能になります。
現場によっては、Performance Insightsを有効にして可視化をしてはみたものの、その収集されたデータの見方が分からなかったり、分析出来る程の知見も無く、満足に活用出来ていないといったケースも往々にしてあるかと思いますので、その様な状態なのであれば、DevOps Guru for RDSを導入して有効活用する事が勧められます。
なお、2021年12月25日時点では、この機能はAmazon Auroraのみに対応しており、RDSのPerformance Insightsは対象外となっているのですが、将来的に対応する予定がある旨は公式に告知されておりますので、いずれはRDSでも使える様になるかと思います。
for RDSの料金
DevOps Guru for RDSの利用自体に追加料金はかかりません。
ただし、DevOps Guru for RDSの利用は、Amazon AuroraのインスタンスがPerformance Insightsを有効化している事が前提となっている為、分析対象としたい既存のインスタンスがPerformance Insightsを無効にしていると、有効化によってRDS側にその分の使用料金が生じる場合があります(保存期間を7日以上の長期保存にしたり、無料利用枠を超えるAPIコールがあった等)。
導入方法について
分析対象とするAmazon AuroraインスタンスのPerformance Insightsを有効化するだけです。
その為、Performance Insights有効化済みのインスタンスを、既にDevOps Guruで分析対象にしていた場合であれば、自動的にDevOps Guru for RDSも利用している事になります。
現状、Auroraクラスターを新規作成する場合、デフォルトではPerformance Insightsが有効化された状態になっている為、コスト削減目的で意図的に無効化していたり、Performance Insightsがリリースされる前から存在していたインスタンスで、そのまま有効化していないものでもなければ、利用に際しての作業は何も生じません。
なお、Performance Insightsの有効化は、インスタンスの変更から実施する必要がありますが、Performance Insightsの変更だけであれば、データベースのダウンタイムや再起動、フェイルオーバーは生じませんので、無効化していたインスタンスであったとしても、DevOps Guru for RDSを利用する為にかかる運用上の負担は特に無いかと思います。
Performance Insightsの有効化/無効化の具体的な手順については、公式ドキュメントを参照してください。
以上、Amazon DevOps Guru for RDSの紹介でした。
結びに
ここまでに記述してきた通り、DevOps Guruというサービス自体は、アプリケーションのパフォーマンスや運用の改善を支援してくれる、非常に有用なものであるという事は分かりました。
ただし、DevOps Guruに対応している各AWSサービスのリソースにおいて、実際にどの様な問題を検知する事が出来るのかは、公開されている公式の資料類を参照しても、全体的なざっくりした記述があるだけで、それぞれ具体的には明示されておらず、ブラックボックスになっています。
DevOps Guruが分析対象とするデータはCloudWatchメトリクス、Config、CloudTrailといったところがベースになっている事から、標準のCloudWatchメトリクスを利用してCloudWatchアラームで監視を行っている場合であれば、そこについては概ね代替が利き易いのではないかと推察します。
監視項目やその内容を明示的に設定する事が出来ない以上、決まった固定の閾値等の設定をもって監視したい内容をDevOps Guruで代替する事は難しいですが、冗長化前提のリソースにおいて、負荷状況に合わせて柔軟に閾値を調整する必要がある様な監視内容であれば、DevOps Guruに集約していけると、誤検知や運用の手間も省けるので、十分に検証を行いながら上手く併用していくのが良いのではないかと考えます。
どの様なケースで利用するにせよ、コストが増加する事はほぼ確実なので、導入にあたっては事前の見積りが重要となりますが、その辺りを加味すると、大きな組織や大規模のサービスを運用しており、人員や監視体制が整っている様な環境よりも、人員の足りていない中小規模の組織とかで、監視体制が整っていない環境や、新規サービスを構築する場合等の方が、享受出来るメリットは大きく感じるので、DevOps Guruの導入もし易いのではないでしょうか。
個人的にはお薦めのサービスなので、DevOps Guruは積極的に活用していきたく、今後、Rettyにおいても導入を検討していければと思っています。
