AWS AppConfig でホストされた構成が利用可能になりました

記事タイトルとURLをコピーする

2020年6月16日のアップデートです。

AWS AppConfig がホストされた構成のリリースを発表

なお、AWS AppConfigは2019年11月に発表されたサービスであり、AWS Systems Managersの一部でもあります。

AWS は、AWS AppConfig でホストされる構成の立ち上げを発表します。 これは、AWS AppConfig へのオンボーディングを簡素化して、顧客が構成を数秒でデプロイできるようにする新機能です。AWS AppConfig では、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、AWS Lambda、モバイルアプリケーション、IoT デバイス、オンプレミスサーバーでホストされているアプリケーション間で、検証、制御、モニタリングしながらアプリケーション設定を容易かつ迅速にデプロイできます。

AppConfigは、アプリケーションの設定をデプロイするためのサービスです。
AppConfigを使うには、今まではアプリケーションの設定を、S3オブジェクトSystemsManagerドキュメントSystemsManagerパラメータストアのいずれかに保存する必要がありました。

今回のアップデートで、AWS AppConfig でホストされた構成(AWS AppConfig hosted configuration)への保存も選択できるようになりました。

4つの保存領域の比較はこちらに記載がありますが、AWS AppConfig でホストされた構成の利点は、サーバサイド暗号化(Server-side encryption)に唯一対応していることと、設定が楽になることです。

と、ここまで書きましたが、私自身AppConfigを使ったことが無かったので、以下で実際に試してみます。

サンプルアプリケーション

AppConfigはアプリケーションの設定をデプロイするサービスなので、何かサンプルアプリケーションを作って試してみます。 今回はPythonで運勢をSlackに通知してくれるアプリを作成しました。 登録したメンバーに対して、運勢を教えてくれます。

まずはAppConfigを使わずに普通にコードを書いてみます。 これを後でAppConfigを利用するように改造します。

import requests,json,random

# webhookURL
webhook_url = "https://hooks.slack.com/services/xxxxxxxxxxxxxxx"

# おみくじの中身
omikuji = [ "大吉","中吉", "小吉", "吉", "末吉", "凶", "大凶" ]

# 通知先メンバー
members = {
    "MemberList": [
        {
            "name": "たかし",
            "id"  : "11111111111"
        },
        {
            "name": "けんじ",
            "id"  : "22222222222"
        },
        {
            "name": "つとむ",
            "id"  : "33333333333"
        },
        {
            "name": "のぼる",
            "id"  : "44444444444"
        }
    ]
}

# 送信するテキスト
text = "本日の運勢です。\n"
for member in members["MemberList"]:
  text += "<@" + member["id"] + ">" + "あなたは" + random.choice(omikuji)  + "\n"

# Slackに送信
requests.post(webhook_url, data = json.dumps({
        "text": text
}));

実行すると、Slackに以下のような通知が送信されます。

このコードの問題としては、メンバーが変わるとコードの修正も必要なことです。

そこで設定をコードの外に出して別管理することにします。 設定をコードの外に出すというのはよくあり、どこに出すかというと、環境変数、設定ファイル、データベース等があると思います。 また、AWSでもパラメータストアというのがあり、そこで管理することも可能です。

今回は、この通知先メンバーに関する設定をAppConfigに移動させ、そこで管理してみます。

AppConfigの導入

Applicationの作成

AWS Systems Manager > AppConfig > Create configuration data

アプリケーション名をつけます。 今回は、omikujiという名前にしてみました。

Environmentの作成

環境名をつけます。 今回はDevelopmentにしました。

Configuration profileの作成

Configuration profile名をつけます。 今回はメンバー情報の設定なので、team-Aとしてみました。

Configuration sourceとして、AWS AppConfig hosted configurationを選択します。

保存するアプリケーションの設定を記載します。 YAML、JSON、Textと選択可能ですが、今回はJSONにしました。

Add validatorsというページが表示されますが、AWS AppConfig hosted configurationでは、validatorは使えないと記載があったので、ここでは何も選択せずに次にいきます。

Deployの開始

AppConfigのデプロイは、AppConfig側がPushするのではなく、アプリケーション側からのPullで実行されます。 したがって、基本的には実際に設定が適用されるタイミングはアプリケーション側の仕様によります。 「AppConfig側でDeploy実行」後に「クライアントからのPull」という順序です。 ただし、AppConfigにはデプロイ戦略という設定項目もあり、そこでいくらかは調整をすることは可能です。

項目
Environment Development
Hosted configuration version 1
Deployment strategy AppConfig.AllAtOnce(Quick)

今回はデプロイ戦略(Deployment strategy)をAllAtOnceとしているので、即座に設定反映させるようにしました。 これでAppConfig側の準備は完了です。

サンプルアプリケーションのAppConfig対応

AppConfigに設定を参照しにいくように修正します。 boto3がAppConfigをサポートしているので、これを使います。

ClientIdは、なんでもいいようです。 また、バージョン番号を指定しない場合は、最新バージョンになるようです。

import requests,json,random,boto3

# webhookURL
webhook_url = "https://hooks.slack.com/services/T68N3KXME/B016FUJV2QG/xxxxxxxxxxxxxxx"

# おみくじの中身
omikuji = [ "大吉","中吉", "小吉", "吉", "末吉", "凶", "大凶" ]

# 通知先メンバー
client = boto3.client('appconfig')
response = client.get_configuration(
    Application='omikuji',
    Environment='Development',
    Configuration='team-A',
    ClientId='watanabe'
)
config = response["Content"].read().decode('utf-8')
members = json.loads(config)

# 送信するテキスト
text = "本日の運勢です。\n"
for member in members["MemberList"]:
  text += "<@" + member["id"] + ">" + "あなたは" + random.choice(omikuji)  + "\n"

# Slackに送信
requests.post(webhook_url, data = json.dumps({
        "text": text
}));

これで実行し、上手くいきました。 今後、メンバーに変更があった時も、プログラムコードを修正せずにAppConfigの修正だけで済むようになりました。

設定を更新する

メンバーにたろうが追加されたとします。 AppConfigの設定を更新する必要があるので、新しいバージョンを作成します。

Create hosted configuration version

設定を追加します。

新バージョンをデプロイ

Start deployment

バージョンで先ほど作成した2を選択します。

Deploymentsに Version 2 が見えるようになります。 今回はデプロイ戦略(Deployment strategy)で、AppConfig.AllAtOnceを選択しているので、全てのクライアントからのリクエストに即座に反映されるはずです。 なお、Bakingと表示されるのが少し気になるかと思いますが、この時点で新しいバージョンを利用可能です。

ベイク時間(bake time)について

ベイク時間(bake time)はCloudWatchアラームがデプロイを完了とみなすまでにかかる時間であり、デフォルトで10分になっていました。 CloudWatchアラームと連携させない場合は、ベイク時間は関係ありません。

ベイク時間(bake time)についての説明は、ステップ 4: デプロイ戦略を作成するに記載があります。

まとめ

今回初めてAppConfigを触ってみました。 アプリケーション設定の保存やデプロイに利用できるサービスとわかりました。

しかし、AWSもデプロイやCIに利用できるサービスが多くなってきて、使い分けが難しいですね。 AWS Systems Manager のよくある質問には、以下のような質問が並んでいました。

  • Q: AWS AppConfig が AWS CodeDeploy と異なる点は?
  • Q: AWS Systems Manager パラメータストアと AWS AppConfig はそれぞれいつ使用すべきですか?
  • Q: AWS AppConfig が AWS Config と異なる点は?

渡辺 信秀 (記事一覧)