YAZエンジニアが運営するメディア

AWS Lambdaを利用して開発していると、 「開発中のコードを変更したら、本番環境にも反映されてしまうのでは？」 と気になることがあります。

そのようなときに活用できるのが、 AWS Lambdaのバージョニング機能です。

Lambdaでは、現在編集中のコードを表す $LATESTとは別に、 その時点のコードをVersionとして固定できます。

この記事では、 Amazon API Gatewayのdev / prdステージと AWS Lambdaのバージョニングを組み合わせ、 開発環境と本番環境で異なるLambdaコードを実行する方法を解説します。

この記事の対象者

• AWSを学び始めた方
• Lambdaのバージョニングを初めて利用する方
• API GatewayとLambdaを組み合わせて利用したい方
• 開発環境と本番環境を分ける仕組みを学びたい方

Lambdaのバージョニングとは？

AWS Lambdaでは、現在編集中の最新コードを $LATESTとして管理しています。

コードを変更して「Deploy」を行うと、 $LATESTの内容が更新されます。

一方、Lambdaでは$LATESTの現在の状態を Version 1、Version 2……のように固定できます。

発行したVersionは、その時点のコードを固定したものとして扱われるため、 その後$LATESTを変更しても、 すでに発行したVersionの内容は変わりません。

API Gatewayのステージとは？

Amazon API Gatewayでは、 同じAPIに対して複数のステージを作成できます。

今回は、以下の2つのステージを作成します。

今回構築する構成

今回は、API Gatewayのステージごとに 呼び出すLambdaを切り替えます。

この構成にすることで、 $LATESTのコードを変更しても、 prdが固定Versionを参照している限り、 本番環境のコードは変更されません。

使用するAWSサービス

1. Lambdaの本番用Versionを作成する

はじめにLambda関数を作成し、 本番用として使用するコードをVersionとして固定します。

手順1：Lambda関数を作成する

1. AWSマネジメントコンソールで「Lambda」を検索します。
2. 「関数の作成」を選択します。
3. 「一から作成」を選択します。
4. 関数名を入力します。
5. ランタイムでPython 3.xを選択します。
6. 「関数の作成」を選択します。

手順2：本番用コードを作成する

作成したLambda関数のコードを、 以下の内容へ変更します。

import json

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps({
            "message": "Production Version 1",
            "version": "1"
        })
    }

入力後、「Deploy」を選択します。

手順3：本番用コードをテストする

Versionを発行する前に、 現在のコードが正常に動作することを確認します。

1. Lambda画面の「Test」を選択します。
2. 初回は新しいテストイベントを作成します。
3. イベント名にtest-lambdaと入力します。
4. イベントJSONは{}のまま保存します。
5. 再度「Test」を選択します。

実行結果で、以下の内容を確認します。

この時点ではまだVersionを発行していないため、 $LATESTが実行されています。

手順4：本番用Versionを発行する

コードが正常に動作することを確認できたら、 その時点のコードを本番用として固定します。

1. Lambda関数画面の「アクション」を選択します。
2. 「新しいバージョンを発行」を選択します。
3. 必要に応じて説明を入力します。
4. 「発行」を選択します。

2. $LATESTを開発用コードに変更する

本番用のVersionを固定できたので、 次に$LATESTを開発用コードへ変更します。

Version 1の画面を開いている場合は、 Lambda関数名を選択して通常の関数画面へ戻ります。

以下のコードへ変更し、「Deploy」を選択します。

import json

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps({
            "message": "Development Latest",
            "version": "latest"
        })
    }

3. API Gatewayを作成する

手順1：REST APIを作成する

1. AWSマネジメントコンソールで「API Gateway」を検索します。
2. 「APIを作成」を選択します。
3. REST APIを選択します。
4. 必要な項目を入力してAPIを作成します。

手順2：/helloリソースを作成する

作成したREST APIに、 /helloリソースを作成します。

手順3：GETメソッドを作成する

作成した/helloリソースへ、 GETメソッドを追加します。

今回はLambda関数名を直接指定せず、 ステージ変数を利用します。

4. dev / prdステージを作成する

手順1：devステージを作成する

APIをデプロイし、 新しいステージとしてdevを作成します。

作成後、ステージ変数に以下を設定します。

devではVersion番号を付けません。 Versionを指定しないことで、 $LATESTが呼び出されます。

手順2：prdステージを作成する

再度APIをデプロイし、 新しいステージとしてprdを作成します。

末尾の:1は、 LambdaのVersion 1を指定しています。

5. API GatewayからLambdaへの実行権限を設定する

ステージ変数を使用してLambdaを指定しているため、 API GatewayからLambdaを実行できるように権限を追加します。

AWSマネジメントコンソールから CloudShellを開きます。

手順1：dev用の実行権限を追加する

aws lambda add-permission \
  --function-name ojt-lambda-version-[名前]-01 \
  --statement-id apigateway-dev \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --region ap-northeast-1

手順2：prd用の実行権限を追加する

aws lambda add-permission \
  --function-name ojt-lambda-version-[名前]-01 \
  --qualifier 1 \
  --statement-id apigateway-prd \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --region ap-northeast-1

6. dev / prdの動作を確認する

手順1：devへアクセスする

API Gatewayのdevステージに表示されているURLの末尾へ /helloを付けてアクセスします。

以下のように表示されれば成功です。

{
  "message": "Development Latest",
  "version": "latest"
}

手順2：prdへアクセスする

以下のように表示されれば成功です。

{
  "message": "Production Version 1",
  "version": "1"
}

7. $LATESTを変更しても本番環境に影響しないことを確認する

最後に、 $LATESTを変更した際の dev / prdの動作を確認します。

Lambdaの$LATESTを以下のコードへ変更します。

import json

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps({
            "message": "Development Latest Updated",
            "version": "latest-v2"
        })
    }

変更後、「Deploy」を選択します。

devを再確認する

{
  "message": "Development Latest Updated",
  "version": "latest-v2"
}

devは$LATESTを参照しているため、 変更した内容が反映されます。

prdを再確認する

{
  "message": "Production Version 1",
  "version": "1"
}

prdはVersion 1を参照しているため、 $LATESTを変更してもレスポンスは変わりません。

8. 実際の運用ではどのように使う？

今回の構成を実際の開発・本番運用に置き換えると、 以下のような流れになります。

新しいVersionを本番へ反映する場合

例えばVersion 1を本番で利用しており、 新しいコードを本番へ反映する場合は、 動作確認後にVersion 2を発行します。

その後、prdのステージ変数を 以下のように変更します。

問題が発生した場合

Version 2を本番へ反映したあとに問題が見つかった場合は、 prdの参照先を以前のVersion 1へ戻すことができます。

このように以前の安定したVersionへ戻すことを ロールバックといいます。

9. よくあるエラー・確認ポイント

Versionの画面でDeployが押せない

発行済みのVersionは読み取り専用のため、 コードを編集できません。

Lambda関数名を選択して $LATESTの画面へ戻ってから編集します。

Version 1ではなくVersion 2以降になった

問題ありません。 prdのステージ変数やCloudShellの --qualifierを、 実際に発行されたVersion番号へ変更します。

APIへアクセスするとエラーになる

• URLの末尾に/helloが付いているか確認する
• LambdaとAPI Gatewayが同じリージョンか確認する
• dev / prdのステージ変数を確認する
• Lambdaの実行権限が追加されているか確認する

10. ハンズオン終了後のリソース削除

ハンズオン終了後は、 今回作成したリソースを削除します。

API Gatewayを削除する

API GatewayのAPI一覧から、 今回作成した ojt-api-version-[名前]-01 を削除します。

API自体を削除すると、 /hello、 GETメソッド、 dev / prdステージ、 ステージ変数もまとめて削除されます。

Lambdaを削除する

Lambdaの関数一覧から、 ojt-lambda-version-[名前]-01 を選択して削除します。

Lambda関数自体を削除すれば、 $LATESTや公開済みVersionを 個別に削除する必要はありません。

まとめ

今回の構成では、 devから$LATEST、 prdから固定Versionを呼び出すことで、 開発中のコード変更が本番環境へ直接影響しないことを確認できました。

また、新しいVersionへ切り替えることで本番リリースを行ったり、 問題が発生した際に以前のVersionへ戻したりできるため、 Lambdaを利用したアプリケーションを運用する際に役立つ仕組みです。

まずは今回のようにdev / prdで異なるVersionを呼び分け、 LambdaのバージョニングとAPI Gatewayのステージの仕組みに慣れてみてください。