さぁ、今日もlambdaを触っていきます！

参考URL

クラウドメソッドさんの記事を参考にしてやってます。

APIゲートウェイのバージョン管理（lambda連携）
https://dev.classmethod.jp/cloud/aws/version-management-with-api-gateway-and-lambda/

前回までのおさらい　lambdaのエイリアス設定

最初の状態ではAPIゲートウェイに紐づいている$LATESTの結果が返ってきます。
では、実際に紐づけを行う前に$LATESTがどのようになっていて、エイリアスでprodステージとdevステージとの違いが分かるように整理しておきます。

そこでちょっと、おさらいなのですが、lambdaのエイリアスとバージョン管理の方法にも触れておきます。

１．lambdaでバージョンを作成

２．エイリアスの作成

どちらも、lambda上のGUIから操作して簡単に作成可能でした。
ちなみに削除する際は「エイリアス」→「バージョン」の順で設定を削除します。
※逆に操作しようとするとエラーが発生します。

ではこれを応用して、APIゲートウェイのバックエンドで動作させるlambdaの関数を本番と開発で分け、かつ、そのバージョン管理も行えるようにしてみようっていうのが、記事の主旨になります。

でちなみにいろいろと操作してたので、4版までバージョン発行を行ってしまったので、少し表示に違和感がありますが、↓のような感じでエイリアスを用意しておきます。

どちらのlambda関数ともに単にバージョンと数字を返すだけの単純な関数が設定されています。
前回の記事にも記載しましたが、prodは固定で変更することはできず、以下の通り、「バージョン1」の値を返します。

一方、devのほうは「バージョン2」の値を返します。
それから、APIゲートウェイのほうも設定を用意しておきます。

まず、リソースは分かりやすく「dev」としておきます。

次にメソッドはGetの定義を用意しておきます。

メソッドを用意したら、デプロイしていきましょう！
今回はテストなので、APIキーは流用で構成しておきます。

スロットリングとかクォータの設定がないのは、前回の記事を踏襲しています。

APIゲートウェイとlambdaのエイリアス設定を連携する

まずはAPIゲートウェイ側の設定を変更していきます。

作成したAPIゲートウェイの[統合リクエスト]をクリックします。
そこで[Lambda関数]に入力している関数名の末尾に以下の変数を追加して保存します。

追加変数

:${stageVariables.alias}

保存すると以下のようにAWSCLIのコマンドが発行されるので、コマンドを控えておきます。

AWSCLIのコマンド

aws lambda add-permission --function-name "arn:aws:lambda:*******:${stageVariables.alias}" --source-arn "arn:aws:execute-api:*******:*******:kcgilegeu5/*/GET/dev" --principal apigateway.amazonaws.com --statement-id ******* --action lambda:InvokeFunction

ただ、このコマンドを実際に実行する際には「dev」と「prod」でlambdaのエイリアスが分かれますので、"arn:aws:lambda:*******:${stageVariables.alias}"の:${stageVariables.alias}をdevとprodに変更して2回実行する必要があります。

実際に実行してみると以下のような感じでコマンドが戻ってくると思います。

実行結果

{
    "Statement": "{\"Sid\":\"******\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"apigateway.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:******:******:function:cm-kanechanee-APITest01:dev\",\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:execute-api:******:******:kcgilegeu5/*/GET/dev\"}}}"
}

次にprodのステージ設定をまだ作成していないので、作成します。
ステージの作成はステージの設定からではなく、デプロイから行います。

デプロイが終わったら、ステージ変数を追加していきます。
クラスメソッドさんの記事にも記載されていますが、ステージ変数はあの[統合リクエスト]の画面で追加した変数名として、利用することができます。つまり、今回のケースでは__lambdaで作成したエイリアスを指定できる__ということになりますね。

ステージ変数はステージごとに異なる値を設定でき、${stageVariables.xxxxx}で利用することができます。

この状態でprodのエンドポイントに対して、curlでアクセスしてみると

prodエンドポイントへのアクセス

curl https://*********/prod/test01 -H 'x-api-key:******'

アクセス結果

"version1"

lambdaで設定しているエイリアスの通り、prodエイリアスで設定している"version1"の出力を返しました。
この時点ではまだ、devエイリアスには何も紐づけていないので、試しに新しいバージョンを作成して紐づけてみます。

ではlambda側で新しいバージョンを作成してみます。

新しいバージョンは"version2"を出力するという内容にします。
この状態でlambda側のエイリアスdevをこの新しく作成したバージョン2と紐づけておきます。

lambdaのエイリアスとバージョンの紐づけを変更する場合、[バージョンとエイリアスの切り替え]から[エイリアス:dev]を選択します。

そこからエイリアスの設定画面に移って、画面下のほうに存在する[バージョン]のプルダウンメニューからエイリアス:devと紐づけるバージョンを選択します。

次に、実験として、この時点でlambda側の$LATESTの内容を"version3"に変えてみます。
この時点ではまだ、lambdaのdevとAPIゲートウェイのdevステージは紐づいていないので、仮に$LATESTを変更したらAPIゲートウェイのエンドポイントをたたいた出力結果は"version3"が返ってくるはずです。
※つまり、devはlambdaとは連携しない構成となっているはず。

では試しに、変えてみましょう！

さぁ変えてみましたよ。これでdevのエンドポイントへアクセスしてみるとどうなるのでしょうか？

devエンドポイントへのアクセス

curl https://*********/dev/test01 -H 'x-api-key:******'

アクセス結果

"version3"

ちゃんと、"version3"が返ってきました！
ちなみにprodステージに反映させたデプロイの設定をdevステージにも同様に反映させることが可能です。
APIゲートウェイの[ステージ]でdevステージを選択し、[デプロイ履歴]を選択すると、prodステージで反映したデプロイの履歴が残っているので、選んだ状態で[デプロイの変更]をクリックし、devステージへ適用します。

↓のように✔の位置が変わればOKです！

あとはprodと同様にステージ変数でdevと設定してあげれば、lambdaのdevエイリアスと紐づけることができます。

この状態でアクセスすると結果は先ほど、lambdaでdevエイリアスに紐づけた"version2"の結果が返ってくるはずです。

devエンドポイントへのアクセス

curl https://*********/dev/test01 -H 'x-api-key:******'

アクセス結果

"version2"

最初、この記事を読んだときはややこしかったのですが、実際に触ってみると覚えることができました。
やっぱり、こういった技術は触れて覚えていくことが一番大事ですね。

明日もまた、別のlambdaの勉強記事をアップしたいと思います。