目次

• はじめに
• KBOS/KBIにおける障害に対する取り組み
• 監視・運用の課題
• 改善策: CloudWatch Metric Streamsの導入
  • 注意点①: グローバルリソース
  • 注意点②: CloudWatch Metric Streamsではリソースを絞れない
  • 注意点③: コスト
  • 切替対象の選定
• Datadog側の設定変更 〜アイレット様〜
• CloudWatch Metric Streamsを導入後の効果
• まとめ

はじめに

こんにちは、KDDIアジャイル開発センター株式会社 (以下、KAG) のエンジニア、橋爪です。 法人・ビジネス向けサービスである「KDDIビジネスオンラインサポート」(以下、KBOS) および「KDDI Business ID」(以下、KBI) の開発を担当しております。

KBOSではご契約サービス情報の一元管理や契約内容変更のお申込、KBIではクラウドサービスのIDをセキュアに一元管理ができます。 約5万社、約20万人のお客さまにご利用いただいております (※2023/4時点)。

今回は同じKDDI Digital Divergence Holdingsのアイレット株式会社様 (以下、アイレット様) とご協力し、 KBOS/KBIのシステム監視を改善した事例をご紹介します。

なお、この取り組みはアイレット様のホームページでも事例として掲載していますので、ぜひ併せてご覧ください。

Datadog 監視におけるCloudWatch Metric Streams を活用し、アラート検知のタイムラグを低減！

KBOS/KBIにおける障害に対する取り組み

KBOS/KBIはAWS上でシステムを構築しており、監視はDatadogに集約しています。 システム異常は起こらないことが理想ですが、残念ながら避けられないこともあります。 お客さまの立場に立って、迅速に問題を検知し、少しでも早く復旧できるようにシステムや体制を事前に構築しておくことが重要です。 KBOS/KBIでは、DatadogのSyntheticを使った外形監視を導入しており、万が一大きな障害が発生しても迅速に検知できるようにしております。

監視・運用の課題

一方で以前から、メトリクスのアラート通知や、Datadog上のメトリクス表示にはタイムラグがあり、 システムの迅速な状況把握には課題がありました。 DatadogからAWSのメトリクス取得は、GetMetricData APIのポーリングで行っており、そのレイテンシーが約15分であったためです。

改善策: CloudWatch Metric Streamsの導入

そこで、CloudWatch Metric StreamsでAWSからメトリクスを取得し、 Kinesis Firehoseを介してDatadogに転送することによりレイテンシー短縮化を実現しました。

図: GetMetricData APIのポーリングとCloudWatch Metric Streams

CloudWatch Metric StreamsとKinesis Firehoseの具体的な構築手順はDatadogやAWSのドキュメントに記載があります。 そのため本記事では割愛させていただきますが、注意点だけご紹介します。

注意点①: グローバルリソース

Route 53やCloudFrontなどグローバルリソースにも適用するには、 us-east-1 (バージニア北部) リージョンにもCloudWatch Metric StreamsとKinesis Firehoseの構築が必要です。

注意点②: CloudWatch Metric Streamsではリソースを絞れない

GetMetricData APIのポーリングでは、EC2、ELB、Lambda、RDS、SQSなどに限ってDatadogがメトリクス収集するリソースをタグベースで絞ることができました。

AWSリソースの除外 (Datadog公式)

しかし、CloudWatch Metric Streamsでは、指定したAWSサービスの全リソースがDatadogに転送されます (※2023/4時点)。

踏み台用のEC2や、運用で使っているLambdaなどは、タグによりメトリクス収集を除外していました。 しかし、CloudWatch Metric Streamsに切り替えると、以前は除外していたリソースもメトリクスが転送されるようになりました。 これによりDatadogのコストも増えてしまう点には注意が必要です。

CloudWatch Metric Streamsでもメトリクス転送するリソースをタグベースで絞れる機能があればよかったのですが、 今後のDatadogやAWSの対応に期待しましょう！

注意点③: コスト

インターネットを検索すると、CloudWatch Metric Streamsへの切替により、コスト削減になるという話を見かけます。 コスト削減も期待していましたが、実際に確認したところ、AWS側のコストはわずかながら増える結果となってしまいました。

切替対象の選定

以上の観点を考慮し、すべてのAWSサービスをCloudWatch Metric Streamsに切り替えるのでなく、 特定のAWSサービスのみをCloudWatch Metric Streamsに切り替えました。 CloudWatch Metric Streamsの設定画面で「選択された名前空間」を選べば対象のAWSサービスを選択できます。 (選択しなかったAWSサービスはこれまでどおりGetMetricData APIのポーリングでメトリクスが取得されます。)

具体的には、Datadogのモニターを使ってアラート監視していたり、ダッシュボードなどでよく見たりするメトリクスのAWSリソースはCloudWatch Metric Streamsへ切り替えました。 そして、EC2やLambdaなどリソースを絞りたいAWSサービスはAPIポーリングのままにしました。

図: コストの内訳の変化

Datadog側の設定変更 〜アイレット様〜

KAGではAWS側を構築しましたが、Datadog側の対応はアイレット様にご依頼しました。 具体的には、CloudWatch Metric Streamsへの切替による、Datadogでの監視の影響調査や、モニターのdelay値を短縮する設定を実施いただきました。 Datadog側のモニター設定でもいろいろと注意点があります。 詳細な内容については、アイレット様の技術ブログで紹介されていますので、ぜひご覧ください。

CloudWatch Metric Streamsを導入後の効果

CloudWatch Metric Streamsの導入により、監視を改善できました。

以前はメトリクス異常が発生してから、その通知まで15〜20分ほどかかっていましたが、 CloudWatch Metric Streamsの導入後は、5〜7分ほどに短縮しました。 また、Datadogダッシュボードのメトリクスのレイテンシーは3〜4分ほどに短縮しました。

これにより、メトリクス異常の検知やシステムの状態把握、意思決定や対応の速度が改善できました。

図: Datadogダッシュボードでトラフィック量を可視化しています (メトリクスのタイムラグが3~4分ほどになっていることが分かります)

まとめ

本記事では、CloudWatch Metric Streamsの導入により、メトリクスのレイテンシーを短縮し、監視体験を向上できることをご紹介しました。 しかし、CloudWatch Metric Streamsを導入すると、コストがわずかながら増加するという課題も明らかとなりました。 そのため、メトリクス収集するリソースを絞りたいEC2やLambdaについては、APIポーリングのままにしました。 それ以外で、メトリクスのレイテンシーを短縮したいAWSサービスだけを厳選してCloudWatch Metric Streamsに切り替えるという選択をしました。

これからCloudWatch Metric Streamsへの切替を検討している方には、 切り替える対象のAWSサービスを選定することや、自分の目でコストの変化をチェックしておくことをおすすめします。

最後に、ご協力いただいたアイレット様と、私と同じチームの戸谷洋紀様に、深く感謝申し上げます。 以上です！ここまでお読みいただき、ありがとうございました。ご参考になれば幸いです。次回もお楽しみに！