COLUMN

2. AWS AppConfigの使い方

それでは、実際に利用して行きたいと思います。

まずは「アプリケーションを作成」を選択していきます。

次に名前と、説明を埋めていきます。

拡張機能を関連付けるという項目がありました。公式ページで検索してみたところ下記のようです。

“AWS AppConfigデプロイが完了するたびに Slack にメッセージを送信するウェブフックへの通知を受け取りたいですか? 設定がデプロイされる前に、設定プロファイルを Amazon Simple Storage Service (Amazon S3) バケットにバックアップしますか? 構成をデプロイする前に、構成データをスクラブして機密情報を探したいですか? エクステンションを使用して、このようなタスクなどを実行できます。カスタムエクステンションを作成することも、AWS付属のオーサリングエクステンションを使用することもできますAWS AppConfig。”

引用: AWS AppConfig拡張機能について

現時点ではデプロイが分かっていないので、デプロイの通知の重要性が良くわかっていません。

EventBridgeやSQS、SNSを設定できるようです。AWSサービスの起点になるものが選べるようです。今回はデプロイが完了しても何もしないので、設定せず進みます。

「アプリケーションを作成」を押したところ、正常に作成されましたというメッセージが出てきました。まだ何も設定値を投入していないので、この辺りもParameter Storeと大きな違いです。設定プロファイルと機能フラグと環境のタブがあり、それぞれ作成できるようになっています。作成方法のマニュアル等は一切見ないでここまで進めていますが、おそらく設定プロファイルと機能フラグにて作成したら勝手に環境が作られるのでは？と考えています。ですので、ここは設定プロファイルと機能フラグを作成します。

機能フラグと自由形式の設定が可能なようです。自由形式の方はS3やパラメータストア、Secrets Managerから呼び出せるみたいですね。他サービスを呼び出すメリットが分からないので、機能フラグを選択します。

ぱっと見た感じまだ設定値にいきつかないようです。

ここでも拡張機能を関連付けられるようです。初期に設定したものとの違いがあるのでしょうか。

特に通知しないので何も設定せず進みます。

保存中のデータの暗号化の設定も出来るようです。

特に設定せず、「機能フラグ設定プロファイルを作成」を押下。

また、正常に作成された通知がされました。設定値を入力するまでにアプリケーション、設定プロファイルと機能フラグの作成と来ており、やや階層が深い気がしますが何か便利さがあるのかもしれません。しかし、やっとここで新しいフラグを追加ボタンが来ましたので、設定値の投入が出来そうです。

入力値が増えてきました。

フラグが有効な状態にトグルがありますので、有効にします。

名前とキーが設定できるようなので、KEY1とします。

短期フラグのチェックボックスがありますが、設定しません。

属性 – オプション

機能フラグKEY1の下にようやく設定値が設定できるということなのでしょうか。

タイプは、文字列、数値、ブール値、文字列配列、数値配列が選べて制約も設定できます。設定値を第三者が編集することを前提にしているということでしょうか。これは、Parameter Storeでは無かった機能です。

文字列

正規表現

数値

最小、最大の設定

ブール値

文字列配列

数値配列

下記のように設定しました。制約の範囲に当てはまらないデータを入れて「フラグを追加」ボタンを押してみます。

期待した動作と違います。正規表現の指定方法が間違っているのかもしれません。

色々試したのですが、正規表現に関してはエラーが出ず正常終了してしまいました。

最終的に下記の設定になりました。

「新しいバージョンを保存」を押下します。

エラーになりました。

試しに、正規表現がエラーと表示されなかった箇所を削除してから再度実行したところ、うまくいきました。

作成時にエラーにならないだけで、内部的にはエラーになっている？ということなのでしょうか。

下記のように設定して、「新しいバージョンを保存」を押したところうまくいきましたので、文字列の場合は誤った設定が保存出来てしまうようです。これが私だけの環境なのか、全体の問題かは分かりません。先に進みたいと思います。

ここまで来てやっと設定値を読み込めるようになったのかと思ったら、まだ「デプロイを開始」ボタンが残っていましたので、押します。

「環境を作成」ボタンがあります、AWSはオプションを作成過程中で作ってくれることがあるので、助かります。

ドキュメントをちゃんと読んでいませんが、振り分ける為の環境だと思いますので、devとしておきます。

モニターはCloudwatchアラームの為のロール設定のようです。デプロイが失敗したときに利用するのでしょうか。

おなじみの拡張機能の関連付け。

「環境を作成」ボタンを押下したところ下記のページに戻ってきました。

デプロイ戦略が選択できます。

• AppConfig.AllAtOnce (Quick)

  DeploymentTime: 0分

  BakeTime: 10分

  Percentage: 100%

  GrowthType: LINEAR

  この設定では、全てのリソースに対して一度にデプロイメントを行います。また、デプロイ後10分間の確認時間が取られます。

• AppConfig.Linear50PercentEvery30Seconds (Test/Demo)

  DeploymentTime: 1分

  BakeTime: 1分

  Percentage: 50%

  GrowthType: LINEAR

  この設定では、30秒ごとに50%ずつリソースにデプロイします。デプロイ後には1分間の確認時間が設定されています。

• AppConfig.Canary10Percent20Minutes (AWS Recommended)

  DeploymentTime: 20分

  BakeTime: 10分

  Percentage: 10%

  GrowthType: EXPONENTIAL

  最初に10%のリソースにデプロイし、その後20分ごとにデプロイメントを拡大します。各デプロイ後に10分の確認時間が設定されています。

• AppConfig.Linear20PercentEvery6Minutes (AWS Recommended)

  DeploymentTime: 30分

  BakeTime: 30分

  Percentage: 20%

  GrowthType: LINEAR

  6分ごとに20%ずつリソースにデプロイします。デプロイ後には30分間の確認時間が取られます。

となっています。今回は調査なので、AppConfig.AllAtOnce (Quick)を選択したいと思います。

このような画面になりました。

右上の「デプロイをロールバック」ボタンが気になりますが、設定値を読み込むアプリが今のところないので、そのままにします。

3.呼び出しアプリの作成

引用:Using AWS AppConfig Feature Flags

上記ページを参考に、Lambdaで動くアプリを作成し、ロールを設定し動作確認しました。

from datetime import datetime, timedelta
import json
import boto3
 
APPCONFIG_APPLICATION_NAME = "cloudsolution-test"
APPCONFIG_CONFIG_PROFILE_NAME = "cloudsolution-test-function"
APPCONFIG_ENVIRONMENT_NAME = "dev"
AWS_REGION = "ap-northeast-1"
 
cached_config_data = {}
cached_config_token = None
cached_token_expiration_time = None
 
def get_config():
    global cached_config_token
    global cached_config_data
    global cached_token_expiration_time
    appconfigdata = boto3.client("appconfigdata", region_name=AWS_REGION)
 
    # If we don't have a token yet, call start_configuration_session to get one
    if not cached_config_token or datetime.now() >= cached_token_expiration_time:
        start_session_response = appconfigdata.start_configuration_session(
            ApplicationIdentifier=APPCONFIG_APPLICATION_NAME,
            EnvironmentIdentifier=APPCONFIG_ENVIRONMENT_NAME,
            ConfigurationProfileIdentifier=APPCONFIG_CONFIG_PROFILE_NAME,
        )
        cached_config_token = start_session_response["InitialConfigurationToken"]
 
    get_config_response = appconfigdata.get_latest_configuration(
        ConfigurationToken=cached_config_token
    )
    # Response always includes a fresh token to use in next call
    cached_config_token = get_config_response["NextPollConfigurationToken"]
    # Token will expire if not refreshed within 24 hours, so keep track of
    # the expected expiration time minus a bit of padding
    cached_token_expiration_time = datetime.now() + timedelta(hours=23, minutes=59)
    # 'Configuration' in the response will only be populated the first time we
    # call GetLatestConfiguration or if the config contents have changed since
    # the last time we called. So if it's empty we know we already have the latest
    # config, otherwise we need to update our cache.
    content = get_config_response["Configuration"].read()
    if content:
        try:
            cached_config_data = json.loads(content.decode("utf-8"))
            print("received new config data:", cached_config_data)
        except json.JSONDecodeError as error:
            raise ValueError(error.msg) from error
 
    return cached_config_data
 
def lambda_handler(event, context):
 
    # 設定の内容を表示
    content = get_config()
    print(content)
 
    # Lambda 関数のレスポンス
    return {
        'statusCode': 200,
        'body': 'Config retrieved successfully'
    }
 

設定したデータが取得出来たことが分かりました。

4.Parameter Storeとの違い

しかし、これだけでは手間暇かけて設定した割には設定値に制限を設けられる利点しかありません。

公式サイトにParameter Storeの使い分けの記述がありました。

“Q: AWS Systems Manager のパラメータストアと AWS AppConfig はそれぞれいつ使用すべきですか?

AWS Systems Manager のパラメータストアは、秘密またはプレーンテキスト構成値を保存、取得、および管理する能力を提供する機能です。パラメータストアの一般的な使用には、データベース文字列とライセンスコードをパラメータ値として保存することが含まれます。セルフマネージドの方法で値を保存、取得する必要がある場合は、パラメータストアを使用してください。AWS AppConfig はランタイムに更新されたアプリケーションを安全にリリースし、構成をパラメータとして保存することができるようにするアプリケーション構成管理サービスです。特定の状況で変更をロールバックすることができる制御された環境で安全に検証してデプロイできる複雑なセットのアプリケーション構成をモデル化する必要がある場合、AWS AppConfig を使用する必要があります。”

引用: AWS Systems Manager のよくある質問

とあります。

下記のような使い分けになりそうです。

AWS Systems Manager パラメータストア

用途: 秘密の情報や設定値を安全に保存・管理する。

特徴:

秘密の情報（例：データベースの接続情報）や設定値を保存できる。

必要な時にこれらの値を取り出して使える。

いつ使うべきか:

単純に設定値や秘密の情報を保存して、アプリケーションから簡単にアクセスしたい時。

アプリケーションのコードの外で設定値を管理したい時。

AWS AppConfig

用途: アプリケーションの設定をリアルタイムで更新・管理する。

特徴:

アプリケーションの設定を逐次更新して、リアルタイムでアプリケーションに適用できる。

更新の際にエラーがあれば、変更を元に戻して前の状態に戻せる。

いつ使うべきか:

アプリケーションの動作をリアルタイムで調整したい時。

変更によって問題が起きた場合に、すぐに元の状態に戻せる安全な方法で更新したい時。

5.AppConfigの使いどころ

アプリケーションの稼働中にデプロイすることなく設定値を変更したい場合は下記のケースが該当すると思います。

• フィーチャートグル
• パフォーマンスチューニング
• A/Bテスティング
• セキュリティ設定の調整
• サービスの利用制限

管理画面なしに、実装できるのはアドバンテージかもしれません。

また、設定値の変更は開発者を必要とせず運用者で実施が可能になる点も素晴らしいと思います。