[アップデート] AWS AppConfig Agent が EC2 でもサポートされるようになりました

いわさ

2023.07.23

いわさです。

AWS AppConfig ではアプリケーション上で使用する構成値や機能フラグを定義し、アプリケーションや環境ごとにデプロイ管理することが出来るサービスです。

通常アプリケーションから利用する際には AppConfig の API へアクセスして値を取得するか、あるいは取得した値を頻繁に参照する場合は独自にキャッシュ管理を行う必要があります。
しかし、そのあたりの管理を簡素化するために Lambda Extension やサイドカーコンテナ向けに、定期的に AppConfig リソースをポーリングしてローカルキャッシュ管理してくれるエージェント AppConfig Agent というものが提供されていました。

これまでは EC2 ではエージェントを利用することが出来なかったのですが、先日のアップデートでサポートされるようになりました。

今回ドキュメントに従って Amazon Linux 2023 にセットアップして使ってみたのですが、うまく起動せずにトラブルシュートが必要だったので試したことなどを残しておきたいと思います。

事前準備 AppConfig 構成

今回エージェントからリモートの AppConfig 構成を取得するので適当なフィーチャーフラグを定義しておきます。

定義した構成は環境を指定してデプロイする必要があるので、環境も定義します。

導入してみる

今回 EC2 でサポートされた環境は以下です。

カーネルバージョン 4.15 以降を実行している Linux ベースの EC2 インスタンスで利用可能
x86_64 および ARM64 アーキテクチャをサポート

導入手順ですが、次の公式ドキュメント手順を参考にしています。

ドキュメントから少しコマンドの置き換えなどをしていますが、Amazon Linux 2023 (x86) で試してみたいと思います。

失敗した

次のようにユーザーデータを定義し、自動でインストールと起動を行ってみましょう。公式ドキュメントによるとこれでデフォルト設定で動作するはず。

#!/bin/bash
dnf install -y https://s3.amazonaws.com/aws-appconfig-downloads/aws-appconfig-agent/linux/x86_64/latest/aws-appconfig-agent.rpm
systemctl start aws-appconfig-agent

セッションマネージャーでアクセスしてみます。
アクセス後、ローカルホストの2772ポートへ HTTP リクエストを送信することでエージェントからキャッシュされた値を取得することが出来ます。
初回はリモートアクセスするので遅いとか、オプションでプリフェッチさせるとか色々あるのですが、今回はデフォルトでいきます。

sh-5.2$ curl "http://localhost:2772/applications/hoge0723appconfig/environments/hoge0723env1/configurations/hoge0723feature"
curl: (7) Failed to connect to localhost port 2772 after 0 ms: Couldn't connect to server

アクセスしてみたところ上記のように 2772 ポートへのリクエスト送信に失敗してしまいました。
ステータスなど確認してみると実行されたエージェントが失敗しています。

root@ip-172-31-33-199 bin]# systemctl status aws-appconfig-agent
● aws-appconfig-agent.service - aws-appconfig-agent
     Loaded: loaded (/etc/systemd/system/aws-appconfig-agent.service; enabled; preset: disabled)
     Active: activating (auto-restart) (Result: exit-code) since Sat 2023-07-22 23:29:01 UTC; 13s ago
    Process: 2962 ExecStart=/opt/aws/aws-appconfig-agent/bin/aws-appconfig-agent (code=exited, status=1/FAILURE)
   Main PID: 2962 (code=exited, status=1/FAILURE)
        CPU: 4ms

Jul 22 23:29:01 ip-172-31-33-199.ap-northeast-1.compute.internal systemd[1]: aws-appconfig-agent.service: Main process exited, code=exited, status=1/FAILURE
Jul 22 23:29:01 ip-172-31-33-199.ap-northeast-1.compute.internal systemd[1]: aws-appconfig-agent.service: Failed with result 'exit-code'.

オプションで環境変数を使うことでエージェントの動作をカスタマイズさせることが出来ると公式ドキュメントには記載されていますが、エージェント（/opt/aws/aws-appconfig-agent/bin/aws-appconfig-agent）を直接実行したところリージョンの指定がない場合にエラーとなることがわかりました。

[root@ip-172-31-33-199 system]# /opt/aws/aws-appconfig-agent/bin/aws-appconfig-agent
[appconfig agent] 2023/07/22 23:34:34 INFO AppConfig Agent 2.0.580
[appconfig agent] 2023/07/22 23:34:34 FATAL agent initialization failed for multiple reasons:
[appconfig agent] 2023/07/22 23:34:34 FATAL     an AWS region is required, but was not found
[appconfig agent] 2023/07/22 23:34:34 FATAL     an AWS region is required, but was not found
[root@ip-172-31-33-199 system]# /opt/aws/aws-appconfig-agent/bin/aws-appconfig-agent --help
Usage:
  -P, --prefetch_list string                           configurations to fetch immediately on startup (default "[]")
  -p, --poll_interval duration                         duration, in seconds, between checks for a configuration update (default 45s)
      --max_connections int                            maximum connections per host used by the agent (default 3)
  -t, --request_timeout duration                       duration, in milliseconds, the agent will wait for a service response (default 3000ms)
  -r, --service_region string                          AWS region to use for service calls
      --proxy_url string                               the url for a configured proxy (http or https)
      --proxy_headers string                           headers to be passed to the configured proxy (default "[]")
      --role_arn string                                IAM role the agent should assume when making service calls
      --role_external_id string                        the external id to set when the agent assumes a role
      --role_session_name string                       the session name to set when the agent assumes a role
      --http_port int                                  port number (1-65535) to use for the localhost proxy (default 2772)
      --access_token string                            if specified, the bearer token value required to retrieve configuration data
      --evidently_event_batch_size int                 events per project to batch before sending to Evidently (1-50) (default 40)
      --evidently_batch_collection_duration duration   duration to wait for events before sending to Evidently (default 30s)
      --evidently_configurations string                AppConfig configuration path(s) for Evidently projects (default "[]")
  -l, --log_level string                               the verbosity of output logs (debug, info, warn, error, none) (default "info")
      --log_path string                                the disk location where logs are written (if unset, logs are written to stderr)

[root@ip-172-31-33-199 system]# /opt/aws/aws-appconfig-agent/bin/aws-appconfig-agent -r ap-northeast-1
[appconfig agent] 2023/07/22 23:35:58 INFO AppConfig Agent 2.0.580
[appconfig agent] 2023/07/22 23:35:58 INFO serving on localhost:2772

次のように記載があったので省略した場合もうまく実行リージョンくらいは取得してくれるのかと思ってました。IMDS 周りだろうか？

If left undefined, the agent attempts to determine the current Region. If it can't, the agent fails to start.

リージョン指定が必須という前提と解釈し指定してみる

構成ファイルの内容を見てみると、プリフェッチやログなどデフォルトからほぼ変えたほうが良いだろうというものが多かったので構成ファイルでリージョン指定する方向で対処してみます。
公式ドキュメントだと次のような指定方法が紹介されていました。

[Service]
Environment=LOG_LEVEL=DEBUG

ただ、この形式だと環境変数が認識されなかったのでユニットファイルの設定はこちらを参考に設定しました。
最終的にユーザーデータで次のように指定しています。

#!/bin/bash
dnf install -y https://s3.amazonaws.com/aws-appconfig-downloads/aws-appconfig-agent/linux/x86_64/latest/aws-appconfig-agent.rpm
mkdir /etc/systemd/system/aws-appconfig-agent.service.d
cat << 'EOF' > /etc/systemd/system/aws-appconfig-agent.service.d/overrides.conf
[Service]
Environment="SERVICE_REGION=ap-northeast-1"
EOF
systemctl daemon-reload
systemctl start aws-appconfig-agent

起動後にセッションマネージャーでアクセスしてみると、おっ良さそうです。

sh-5.2$ systemctl status aws-appconfig-agent
● aws-appconfig-agent.service - aws-appconfig-agent
     Loaded: loaded (/etc/systemd/system/aws-appconfig-agent.service; enabled; preset: disabled)
    Drop-In: /etc/systemd/system/aws-appconfig-agent.service.d
             └─overrides.conf
     Active: active (running) since Sun 2023-07-23 01:07:28 UTC; 1min 42s ago
   Main PID: 2197 (aws-appconfig-a)
      Tasks: 5 (limit: 1114)
     Memory: 7.6M
        CPU: 43ms
     CGroup: /system.slice/aws-appconfig-agent.service
             └─2197 /opt/aws/aws-appconfig-agent/bin/aws-appconfig-agent

リクエストも送信してみましょう。

sh-5.2$ curl "http://localhost:2772/applications/hoge0723appconfig/environments/hoge0723env1/configurations/hoge0723feature" | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    51  100    51    0     0    188      0 --:--:-- --:--:-- --:--:--   189
{
  "flag1": {
    "enabled": true
  },
  "flag2": {
    "enabled": true
  }
}

フラグを更新しデプロイする

では AppConfig の設定をエージェントから取得出来るようになったので、値の更新とデプロイを行ってみます。
次のようにフラグをひとつ変更してみます。

更新した構成バージョンを EC2 がリクエストしようとしている環境にデプロイします。

デプロイが完了したら、先程と同様にエージェント経由で取得してみましょう。
エージェントオプションでカスタマイズ出来ますが、デフォルトでは 45 秒でポーリングしていますので少しだけタイムラグがあるはず。
何度かアクセスしてみます。

sh-5.2$ curl "http://localhost:2772/applications/hoge0723appconfig/environments/hoge0723env1/configurations/hoge0723feature" | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    51  100    51    0     0  16042      0 --:--:-- --:--:-- --:--:-- 17000
{
  "flag1": {
    "enabled": true
  },
  "flag2": {
    "enabled": true
  }
}
sh-5.2$ curl "http://localhost:2772/applications/hoge0723appconfig/environments/hoge0723env1/configurations/hoge0723feature" | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    52  100    52    0     0   6134      0 --:--:-- --:--:-- --:--:--  6500
{
  "flag1": {
    "enabled": false
  },
  "flag2": {
    "enabled": true
  }
}

おっ、変更が反映されましたね。良さそうです。

さいごに

本日は AWS AppConfig Agent が EC2 でもサポートされるようになったので使ってみました。
これまで自前でポーリングやキャッシュを管理していた方は、エージェントをぜひ試してみてください。

なお、Systems Manager のパラメータストアと AppConfig の使い分けにたまに悩むときがあったのですが、環境やデプロイ管理出来る点は改めて AppConfig のおもしろいところだなと再認識しました。エージェントと併せてうまく使えると便利ですね。

[アップデート] AWS AppConfig Agent が EC2 でもサポートされるようになりました

事前準備 AppConfig 構成

導入してみる

失敗した

リージョン指定が必須という前提と解釈し指定してみる

フラグを更新しデプロイする

さいごに

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

[アップデート] AWS AppConfig Agent が EC2 でもサポートされるようになりました

事前準備 AppConfig 構成

導入してみる

失敗した

リージョン指定が必須という前提と解釈し指定してみる

フラグを更新しデプロイする

さいごに

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜フィンテック / リテール 業界案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

関連記事

[Startup Day 2023] [セッションレポート]「AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話」を聞いてきました

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！