😺

AWSでSLOを計測、Amazon CloudWatch Application Signals (Preview)

2023/12/06に公開

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

AWS re:Invent 2023 期間中に Amazon CloudWatch Application Signals (Preview) が発表されました。

Application Signals について

新しくリリースされた Application Signals はどのような機能を持っているのでしょうか。
User Guide Application Signals を要約します。

  • アプリケーションからメトリクスとトレースを収集 (自動計装エージェントにより)
  • call volume, availability, latency, faults, and errors などの主要キーを表示
  • ダッシュボードを作らなくても、アプリケーションのパフォーマンス目標を可視化
  • SLO を作成、監視が可能
  • サービスマップが自動的に作成される
  • サービスマップ内で SLI を追跡可能
  • CloudWatch RUM、Cloudwatch Synthetics Canary、AWS Service Catalog AppRegistry と連携可能

プレビューでのサポートされている言語とアーキテクチャ

2023/12/06 時点でサポートされている言語は Java です。JVM 8/11/17 がサポート対象です。プレビューなので手堅いところだと思います。GA 時には主要言語がサポートされていると期待しています。

EKS、ECS、EC2 でサポート、テストされています。
CloudWatch エージェントと AWS Distro for OpenTelemetry が動けば他のサービスでもいけそうですが、今のところは上記3つのみのようです。

プレビューでのサポートされているリージョン

2023/12/06 時点でサポートされているリージョンは以下の通りです。

  • バージニア北部
  • オハイオ
  • シドニー
  • 東京
  • アイルランド

Application Signals 導入時の考慮

アプリケーションに既にオブザーバビリティツールが導入されている場合は、それを削除する必要があります。手動計装している場合は、コードからそれらを削除します。

Application Signals は AWS Distro for OpenTelemetry Java 自動計装エージェントを使用しています。既存で OpenTelemetry を使用している場合は互換性に期待がふくらみますが、互換性は保証されていないようなのでこちらも削除が必要です。

このあたりは、プレビューで試用しながらフィードバックを送るのが良さそうです。

何が嬉しいのか

CloudWatch で SLO を測定することは簡単ではありませんでした。
瞬間瞬間のインジケーターとしてのメトリクスを表示することは問題なくできますが、ローリングウィンドウでのメトリクスを表示するには大変な工夫が必要です。
例えば、「過去30日間で 99パーセンタイルのレイテンシが 100ms 以下である割合が 99.9% 以上であること」という SLO を CloudWatch で表現するには CloudWatch スペシャリストを探さないとなりません。

Application Signals では SLO 測定に必要なローリングウィンドウとエラーバジェットがデフォルトで表示されるようになりました。
これは大きなアップデートだと個人的に思います。モダンな運用を商用ツールを使わずに実現できるようになりました。

img
https://aws.amazon.com/jp/blogs/aws/amazon-cloudwatch-application-signals-for-automatic-instrumentation-of-your-applications-preview/

(余談)
SLO に関して深く知りたい方は以下の書籍がおすすめです。

やってみた

実機で試してみました。
計装方法はユーザーガイドに記載されています。

EKS
ECS
EC2

ダッシュボード

アプリケーションを実装してしばらくアクセステストを流した後です。
CloudWatch 画面の左にペインに Application Signals が追加されています。

img


管理しているサービスを Application Signals に登録しておくとここで一覧表示可能です。
スクリーンショットは1つのサービスだけですが、複数サービスを監視することが現代では多いと思います。かなり有用ではないでしょうか。

Alt text

サービス

アプリケーションに環境変数を与えて起動します。いくつか環境変数がありますが、OTEL_RESOURCE_ATTRIBUTES の $SVC_NAME に指定した値がマネジメントコンソール上でサービス名になります。

    {
      "name": "OTEL_RESOURCE_ATTRIBUTES",
      "value": "aws.hostedin.environment=$HOST_ENV,service.name=$SVC_NAME"
    }

サービスオペレーション

API ごとの SLI が自動で表示されます。
レイテンシー(P99/P90/P50)、ボリューム(コール数)、障害率、エラー率、可用性が取得できています。
運用をする、もしくは運用相当のテストをし、各 SLI の現実的な値を判断します。現実的な値が判断できたら、それを基に SLO を設定します。

Alt text

依存関係

このアプリケーションの依存関係が表示されます。
複数の DynanoDB と SNS を使用しているのでその通りに表示されています。

Alt text

Synthetic Canary

Synthetic Canary を X-Ray 有効にした状態で設定すると、TRACE ID が紐付けられてこちらに表示されます。

Alt text

クライアントページ

CloudWatch RUM を使用している場合は、クライアントページの情報も表示されます。
たぶん。。。
申し訳ないですが、RUM がうまく動かなかったので、この画面は見れませんでした。

サービスマップ

X-Ray そのままです。サービスマップが表示されます。
異常が発生しているリソースは赤く表示されています。

Alt text

サービスレベル目標 (SLO)

私が一番関心ある画面です。SLO です。
達成度、エラーバジェット、SLI が表示されています。やりました。やってくれました。これがほしかった。

Alt text


ここに表示されているガジェットは CloudWatch ダッシュボードに追加可能です。

Alt text

取得するシグナルを削減する

プレビュー時点では、Application Signals の 料金 はシグナル単位となっています。
受信するシグナルを適切にしぼらないと、莫大な料金が発生します。

CloudWatch Agent の設定ファイル内にルールを記述し、受信するシグナルを制限することができます。
設定ファイルの記述ポイントは以下です。

  • logs ブロックに書く。traces ブロックは logs を自動的に参照する
  • tracesreplace アクションのみをサポート

Enable CloudWatch Application Signals
AWS AppSignals Processor for Amazon Cloudwatch Agent

例えば、POST /api/users だけを受信するには以下のように記述します。

{
  "traces": {
    "traces_collected": {
      "app_signals": {}
    }
  },
  "logs": {
    "metrics_collected": {
      "app_signals": {
        "rules": [
          {
            "selectors": [
              {
              "dimension": "Operation",
              "match": "POST /api/users"
            }
          ],
            "action": "keep",
            "rule_name": "keep01"
        }
      }
    }
  }
}

GET のみを受信したくない場合は以下です。

{
  "traces": {
    "traces_collected": {
      "app_signals": {}
    }
  },
  "logs": {
    "metrics_collected": {
      "app_signals": {
        "rules": [
          {
            "selectors": [
              {
              "dimension": "Operation",
              "match": "GET *"
            }
          ],
            "action": "drop",
            "rule_name": "drop01"
        }
      }
    }
  }
}

試してみたい方へ

AWS で Ops を勉強するための教科書として名高い One Observability Workshop にはやくもワークショップが追加されています。
Application Signals を簡単に体験してみたい方は、こちらを試してみてはいかがでしょうか。

構成要素

構成要素を簡略化して書くと以下になると思います。

img

aws-otel-java-instrumentation の最新版、2023/12/06時点だと V1.31.1 以降で Application Signals 対応していると思われます。
PR 見るとそれっぽい追加が散見されます。

ADOT 自動計装エージェントからのテレメトリデータ受け口は CloudWatch Agent となっています。
CloudWatch Agent の設定ファイルには新しく app_signals という設定項目が追加されています。
既存の xray でも otlp でもなく app_signals です。
個人的には、ADOT Collector にも app_signals レシーバーが追加されると選択肢の幅が広がってよいかなと思います。CloudWatch Agent は ADOT 自動計装エージェントからのメトリクスを受け取ってくれないのでつらい。

{
  "traces": {
    "traces_collected": {
      "app_signals": {}
    }
  },
  "logs": {
    "metrics_collected": {
      "app_signals": {}
    }
  }
}

CloudWatch Logs に /aws/appsignals/generic というロググループが作成されています。EMF であろうログが送られています。上の設定が効いています。

まとめ

なかなかピンこないアップデートかもしれませんが、Ops 大好きな私からすると大きなアップデートです。
SLO の実装自体が難しいものですし、CloudWatch を駆使するのも楽しくはない作業です。
Application Signals によってモダンな設計に一歩も二歩も近づけると思います。GA される際にはさらなる機能が追加されることを期待しています。

参考

Observe your applications with Amazon CloudWatch Application Signals (Preview)
Amazon CloudWatch Application Signals for automatic instrumentation of your applications (preview)
Four APM features to elevate your observability experience
User Guide Application Signals
aws-otel-java-instrumentation

宣伝

2023-12-18(月)に私が運営している OpsJAWS では AWS re:Invent 2023 運用系アップデートをテーマにした勉強会を開催します。
このイベントでも Application Signals について話します。ぜひご参加ください。

Discussion