二つのツールでAWS Lambdaをデプロイしてみた
目次
この記事はアイソルート Advent Calendar 16日目の記事です。
こんにちは。
クラウドソリューショングループ2のkongsです。
年末を迎えるにあたり、ITエンジニアとしてこの1年で学んだことを振り返る時間を取りたいと思います。
私にとって、今年にもっとも力を注ぎ、成果を感じた分野は、AWSクラウドおよびそれに関連する周辺技術でした。
この1年間を通して、AWSクラウドのさまざまな側面や、ユースケースごとにどのような技術やツールを選択すべきかについて、多くのことを学びました。
多くのクラウドエンジニアが一度は悩むであろう「AWS Lambda を用いたサーバーレスアプリのデプロイには、どのツールを使うべきか？」というテーマについて、本日はお話ししたいと思います。
AWS Lambdaとは
記事の続きに入る前に、まずAWS Lambdaについて簡単に再確認しておきましょう。
AWS Lambdaとは、イベントに応じてコードを実行できるサーバーレスのコンピューティングサービスです。
関数のように「呼び出されたときだけ実行される」という特性を持ち、短時間で完結する処理に最も適しています。
この特性で、サーバーレスアプリがフルスタックの Web アプリとは異なる存在であり、AWS Lambda を利用したアプリの要件も特別なものです。
開発者は、AWS Lambda 上にアプリをデプロイするときに、軽量で高速、かつアプリの透明性を確保できるデプロイプロセスを求めます。
そのため、サーバーレス向けのデプロイに特化した機能を提供するツールが必要とされてきました。
これまでの年月の中で、こうしたユースケースに特化したツールがいくつか登場しています。
本記事では、それらを紹介しつつ、サーバーレスアプリのデプロイという観点で、どれほど利便性があるのかを分析していきます。
事前の準備
まず、デプロイの詳しい手順を入る前に、事前に準備が必要なポイントを伝えておきます。
今回のAWS Lambdaのデプロイに必要なものは以下となります：
- AWSのアカウント
- アドミンレベルの権限（AdministratorAccess）
- そちらのアカウントが利用できるアクセスキー
- 手元のCLIにAWS CLIのインストールとAWSの設定
① Serverless Framework(v4)
サーバーレスデプロイと聞いて、まず思い浮かぶツールとして多くの人が挙げるのが Serverless Framework でしょう。
Serverless Framework は、クラウドプロバイダーをまたいでサーバーレスアプリケーションを構築・デプロイ・管理するためのツールです。
YAML ファイルを用いて関数、イベント、リソースを定義することで、インフラ設定やアプリケーションのデプロイを簡素化し、開発者がインフラ管理ではなくアプリケーションロジックに集中できるようにします。
間違いなく、Serverless Framework はサーバーレスデプロイに特化した機能をいち早く提供したツールの一つです。
しかし近年の変更により、その継続的な利用が本当に最適な選択肢なのかを、改めて考え直す開発者も増えてきています。
Serverless Frameworkによるデプロイ
以下のコマンドを実行することで、Serverless Frameworkのバージョン4がインストールできます：
npm install serverless@4そして、次のコマンドを実行することで、Serverless Frameworkのプロジェクトが初期化されます。
npx serverlessテンプレートの選択ステップでは”AWS/Node.js/Simple Function”を選んで、またアカウントのサインアップが必要です。
そちらの設定が完了したら、”handler.js”のファイルに以下のコードを使用します：
export.hello = async (event) => {
return {
statusCode: 200,
body: JSON.stringify({
message: 'こちらはただのデモです。',
})
};
};
最後に、次のコマンドで実行すると、Lambda関数がデプロイされます：
npx serverless deploy実際に表示されたエンドポイントをたたくと、設定されたメッセージが返信されます。
注意点
残念ながら、バージョン4への最近のアップグレードにより、Serverless Framework はもはや純粋なオープンソースツールではなくなりました。現在では、一定の条件を満たす組織に対して、新しいサブスクリプションモデルの採用が義務付けられ、月間利用量に応じて必要なクレジットを購入する必要があります。
とはいえ、サーバーレスアプリケーションのデプロイという観点において、Serverless Framework は依然として最も扱いやすいツールの一つであることに変わりはありません。軽量で使いやすく、長期的なメンテナンスも期待できるツールを求めているのであれば、（サブスクリプションコストを考慮した上で）Serverless Framework は十分に検討する価値のある選択肢でしょう。
② Terraform
Terraform は、HashiCorp が提供する Infrastructure as Code（IaC）ツールで、宣言的な設定言語を用いてクラウドおよびオンプレミス環境のインフラを定義・プロビジョニング・管理することができます。多種多様なプロバイダーに対応しており、インフラ構成をバージョン管理したり、再利用したり、一貫した実行計画（execution plan）を通じて安全に更新したりすることが可能です。
Terraform は、多くの開発者がサーバーインフラの管理に採用する代表的な IaC ツールですが、サーバーレスアプリケーションのデプロイ用途としては、一般的に適切な選択肢とは言えません。これは、Terraform が IaC ツールとして非常に強力である一方で、サーバーレスのユースケースに対しては操作や設定が煩雑になりがちであるためです。
Terraformの機能によるデプロイ
Terraform自身はいくつかの特殊機能があります。
一つは“モジュール”という機能で、一般的に使用されるサービスのテンプレートと近しいものです。
詳しい説明は以下のリンクを参照してください：
https://developer.hashicorp.com/terraform/language/modules
もう一つの機能は専用のレジストリがあることです。
https://registry.terraform.io/
こちらのレジストリはTerraform専用のプラグインライブラリと近しいもので、様々な開発者が提供されたプラグインやテンプレートを導入することにより作業が便利となります。
今回のAWS Lambdaをデプロイするため、Lambda関数のファイルをzipする機能が必要で、”archive_file”というプロバイダーを使用します。
実際デプロイしてみたら、以下のLambda関数が作成されました：
また、コマンド実行で動作確認したら、予想されたメッセージが返信されます：
Terraform の評価
Terraform の導入自体は（まだ採用していないチームにとっては）大きな決断になりますが、提供されている機能を賢く利用すれば、様々なリソースが簡単にデプロイできます。
これは、すでに Terraform を利用しているチームにとって特に有効であり、同じ AWS クラウド環境の中で、複数の分断されたツールを管理する負担を減らしたい場合に適した選択肢です。
これは、すでに Terraform を利用しているチームにとって特に有効であり、同じ AWS クラウド環境の中で、複数の分断されたツールを管理する負担を減らしたい場合に適した選択肢です。
また、定期的に Terraform Registry を確認することで、有用そうなプラグインがないかをチェックすることを強くおすすめします。これは Terraform 自身が公式に提供している機能であり、同様のツールにはあまり見られない特徴でもあります。もしかすると、現在抱えている開発上の課題を一気に解決してくれるプラグインに出会えるかもしれません。
ただし、普通のチームの観点ではTerraformの導入とは非常に大きな投資となります。単に AWS Lambda のようなシンプルなサーバーレスツールをデプロイする目的だけで Terraform を導入することは、あまりおすすめできません。
結論
IT分野にはさまざまな技術やトレンドの変化が速いと感じています。
過去使用された最適なツールだとしても現在の変化により最適ではなくなる可能性が全然あります。
日々の情報取集や検証により、あらたな知識やノウハウをキャッチアップすることはITエンジニアとしてやるべき行動であり、今回の検証でも自身の学習につなげることができました。
今後もこちらの工夫を継続し、組織全体のクラウドノウハウを高めていきます。
今後クラウド分野の専門家として成長していくことを目指しています。
クラウドに関するご相談がありましたら、ぜひお気軽にご連絡ください。
