AWS Lambda、便利ですね。ログを収集する際に一処理やらせたり、DBのテーブルに残っているレコード数を定期的にMackerelに送ったりと、運用・監視関連で特に活用しています。
ただ、VPCの内部におきたいとか、S3の特定のバケットだけにアクセスできる権限を与えたい(IAMで)とか、ちょっと実践的なことをやろうとすると途端に面倒な設定が増えてきます。Serverless Frameworkを使ってみたところいい感じにコードで管理できたので、あちこちで使うようになりました。
そんな使い方をしている中で、serverless.ymlにいつも書く設定を3つほど、取り上げてみます。
デフォルトのアクセス先(デプロイ先)は本番環境以外にする
Serverless FrameworkというよりはAWS CLIの設定かもしれませんが、両方とも、デフォルトでアクセスするのは開発環境など、本番以外の環境にしておきます。間違ったオプションでうっかり実行してしまったときも、本番環境ではないので傷は浅くてすみます。
serverless.ymlだと、provider.profileとcustom.defaultProfileでしょうか。
provider:
profile: ${opt:profile, self:custom.defaultProfile}
＜その他の設定＞
custom:
defaultProfile: default
＜その他の設定＞
このようにしておけば、slsコマンドを叩いた時、–profile オプションをつけていなければAWS CLIのdefaultのプロファイルが使われます。本番環境に対して操作を行う場合、
sls --profile 本番環境のプロファイル名とすれば、本番環境のプロファイルを使うようになります。
defaultProfileの値は、slsコマンドで–profileオプションを指定しなかった場合のプロファイル名ですので、「開発のときに使うプロファイルがある」というのであれば、それを設定するのもよいでしょう。ただ、awsコマンドとslsコマンドでデフォルトのプロファイルが異なるというのは、オペレーションミスを招く要因になりそうです。
ランタイムのスペック(メモリサイズ)と実行時間、リージョンを明記する
Lambdaは、スペックの高いランライムを使ったり、実行時間が長かったりすると、費用がかさみます。
特に、開発中は予期しない動きをすることがありますので、defaultに任せず明記することをおススメします。
serverless.ymlですと、providerの下の設定項目です。
provider:
memorySize: 128
region: ap-northeast-1
timeout: 60
＜その他の設定＞メモリサイズによって、ネットワーク帯域やCPU性能(割り当て?)が変わるようですが、プログラムが意図したとおりに動くようになるのが先です。動くようになってから、調整しましょう。
Pythonのコマンド名をコマンドラインで指定できるようにする
外部のライブラリを使おうとすると、pythonのコマンドがないというエラーが出ることがあります。
serverless.ymlに、以下のような設定を加えます。
custom:
pythonRequirements:
dockerizePip: false
pythonBin: ${opt:pythonBin, self:provider.runtime}
＜その他の設定＞slsコマンド実行時に、–pythonBinオプションでpythonの実行ファイル名を指定できるようになります。実行ファイル名がランタイムと異なっていても、このオプションでエラーを回避できるようになります。
何を管理するかよく検討しましょう
Serverless Frameworkは、AWSではLambdaをうまく扱うためのフレームワークです。関連するリソースも扱えますが、何でもかんでもこれで管理するというのはやめましょう。
どこまで管理するのか、いろいろ意見があると思いますが、
- Lambdaを実行するために必要な権限(IAMなど)はあつかう
- 実行する際に必要になるリソース、例えば、アクセスするRDSや呼出元となるSQSなどは、別に管理
としています。状況によって分け方は変わってくるので、どこかにベストプラクティスとしてまとめてあると助かるのですが…。
Serverless Frameworkにいつも設定する内容を3つ、取り上げました。
- デフォルトのアクセス先は本番環境以外にする
- ランタイムのスペックと実行時間、リージョンを明記する
- Pythonのコマンド名をコマンドラインで指定できるようにする
あなたはどのような設定をしていますか?
コメント