TOP> コラム一覧>

いまさら聞けないLambdaのお話し

はじめに

こんにちは、園田です。

前回に引き続き、「いまさら聞けない」シリーズを開催したいと思います。
いまさら聞けないシリーズの第5弾は「Lambda」になります。

すでにLambdaを使ってる人から見たらLambdaって説明するところあるの?
という感じですが、一度も使ったことが無いとなかなかこれが何なのか良く分からないサービスかなと思います。

今回はLambdaのユースケースなども含めて記載していきたいと思います。

AWS サービス別資料

https://aws.amazon.com/jp/events/aws-event-resource/archive/?cards.sort-by=item.additionalFields.SortDate&cards.sort-order=desc&awsf.tech-category=*all
※フィルターにてサービス名(今回だとLambda)を入力してください。

ラムダ? ああ、FFタクティクスの主人公ね。という方も是非見てみてください。

そもそもLambdaってなに?

いまさらシリーズ恒例のXXXXってなに?、という質問ですが、Lambdaについては何?と聞かれても中々説明が難しいですね。

流行りの生成AIさんに聞いてみましょう。

■生成AIさんの回答

Lambdaとは、AWS(Amazon Web Services)が提供するサーバーレスコンピューティングサービスです。
ユーザーはコードを記述してアップロードするだけで、AWSがインフラストラクチャの構築や管理、セキュリティの設定などを全て行ってくれます。
イベント駆動で自動的にシステムを伸縮させることができ、様々なアプリケーションやサービスを効率的に実行できます。

完璧な回答ですね。

完璧だけどよく分からないというのが生成AIさんの回答の特徴ですね。

という訳で、生成AIさんが回答してくれた内容について説明したいと思います。

サーバーレスコンピューティングってなに?

生成AIさんが回答してくれた、サーバーレスコンピューティングサービスですが、そもそもこれのイメージが難しいですね。

なので、ちょっと違うお話をしましょう。

園田はこんな感じでブログを書いているのですが、このブログの記載にはパーソナルコンピューター(以下、PC)を使っています。

PCが無いころ、記事を書くとなるとワープロになりますね。
ワープロの前はタイプライター、もしくは手書きですかね。
PCですが、意外と便利でExcelやパワーポイントで資料を作ったり、Webで記事を見たりすることもできます。

この辺の作業は園田が勝手にやっているのでどうでもいいのですが、定期的な処理をしている場合などはもうちょっと楽したいー。
という訳で、Excelでマクロとかを組んで自動化をさせるわけですね。

業務処理の話になると、例えば店舗から売り上げデータを集計して、必要なデータを取り出してちょっとだけ加工してDBに格納する。

みたいなことも実施していると思います。
この辺のプログラムは一般的にはバッチ処理と言われており、プログラマーの方が頑張ってプログラムを作ったプログラムを夜中に処理を実行させているわけです。

これらのExcelマクロやバッチ処理になりますが、プログラムを実行させるPCや、サーバが必要となります。

Excelマクロとかについては個人が実施するのでまぁ特に問題にはなりませんが、バッチ処理を実施するにあたり以下のような問題が発生します。

  1. サーバが障害になってバッチが動かないと困る。可用性を上げるために冗長化を考えようとか。
  2. バッチ処理は1時間で終わるのでそれ以外の時間はなにもしていないので勿体ないみたいな問題です。

2の「勿体ない」についてはオンプレミス環境の場合、既にサーバは購入済みで追加の費用は発生しないのであまり問題にはなりませんが、よくよく考えると何も処理してない状態がある。というのは勿体ないわけです。
(とはいえ、1つのサーバに色々機能を持たせるとメンテナンス性が悪くなるので、ある程度は独立させたいところです)

で、これらの問題を解決するために開発されたサービスがAmazon Lambdaになります。

要するに、

  • 可用性(冗長構成にする・しないとか)を気にしなくてよくて
  • 勿体なくない

状態でプログラムを実行できるサービスがLambdaです。
素敵ですね。

で、結局Lambdaってなに?

で、結局Lambdaってなに?、という話になってしまうのですが、Lambdaは実際に触ったことが無いと分かり難いサービスですね。
なので、ちょっと実際の画面を見てみましょう。

こんな感じです。今回は「hello」というLambda関数を作ってみました。

「hello」というLambda関数

内容としては、「Lambdaからのメッセージです」というメッセージが表示されるだけという、何の役にも立たないプログラムです。いわゆる「Hello world」です。

プログラムやったことが無い。
という人も「Hello world」ぐらいならなんとか出来るよーという方もいるかと思います。
ちなみにこのLambdaを実行(「テスト」のタブからテストを実施)すると「Lambdaからのメッセージです」というメッセージが出力されます。

今回画面にlambda_function.pyという記載があるとおり、「Python」で書かれています。
流行ってますからねー。Python。

で、Lambdaの基本はこれだけです。
まとめると、「何かしらの言語」で「プログラムを書いて」(記載したプログラムをzip等で固めてアップも可能)、「実行させる」というものになります。

では、1つずつ見ていきましょう。

何かしらの言語

何かしらと記載しましたが、Lambdaは記載できる言語とバージョンが決まっています。2025年12月現在だと、

  • .net 8
  • Java 11、17、21、25
  • Node.js 20、22、24
  • Python 3.10~3.14
  • Ruby 3.2~3.4
になります。

基本的には最新の言語が推奨されています。

注意点としては、たとえばPythonだと過去のバージョン(3.0~3.9)はサポート対象外となります。
Lambdaがリリースされたのは2014年ですが、当時はNode.jsのバージョンは4.3でした。(Node.jsのリリース頻度多すぎですよ。)

このNode.js4.3のLambdaはどうなったかというと、現在動かす(実行する)ことが出来ません。
なお、Pythonだと過去のバージョン(3.0~3.8)はサポート対象外ですが、動かすことはできます。
とはいえ、動くだけでプログラムの修正は出来ない状態となっています。

何が言いたいかというと、Lambdaを使う = プログラムのアップデートに追随する必要があります。
オンプレミス環境やEC2上でプログラム動かす際はサポートが切れようが基本動かなくなったりしませんし、プログラムの修正も可能です。

LambdaはAWSのマネージドサービスとなるため、塩漬けすることが出来ません。

生成AIさんが答えてくれた通り、「AWSがインフラストラクチャの構築や管理、セキュリティの設定などを全て行ってくれます。」という記載の通りです。

AWSが管理してくれるという事については、基本的にはプラスが多いのですが、マイナスもあるという事はきちんと認識しておきましょう。

「プログラムを書いて」

頑張って指定の言語でプログラムを書きましょう。
最近は生成AIさんが結構頑張ってくれるので、力を借りたいところです。

現状は便利なライブラリ使うのが当たり前なので、モジュールをインポートするぜー。
と行きたいところですが、lambdaの場合、そもそも標準でモジュールがインポートされていないので自分でインポートしないといけません。

具体的にはモジュールも含めてプログラムをzipで固めて、アップするというやり方を取る必要があります。
サーバでプログラムしている場合はモジュールなんて用意されているに決まってますが(少なくともプログラマー視点では)、Lambdaだと逐一自分で用意する必要があるのが不便なところです。(そういうサービスです)

なお、都度モジュールを用意するのが大変なので、Lambda Layersという機能がリリースされています。
これを使う事でライブラリを共通化することが出来ます。

Lambda Layersの使い方はそんなに難しくないので、とりあえず使ってみてください

「実行させる」

で、どうやって実行させるんだよー。というお話ですが、先ほどの画像をもう一度貼らせてもらいます。

「hello」というLambda関数、トリガーを追加

ここで見ていただきたいのが、「トリガーを追加」の部分です。
要するに、「どのような場合」にこのLambdaを実行するかを定義することが出来るというものです。

実際の画面の画像を貼ろうと思いましたが、ちょっと分かり難かったので言葉で説明します。
例えば、以下のようなトリガーで実行というのが可能です。

  • Event Bridge(CloudWatch Event)
  • S3
  • SNS
  • SQS

ほかにもいっぱいありますが、多くても混乱するだけなので代表的なもののみ記載しておきます。

一番分かり易いのは「Event Bridge(CloudWatch Event)」ですね。
Event Bridgeと連携することで、

  • 特定の時間にLambdaを実行(所謂cronでの実行)
  • CloudWatchでトリガー発生時にLambdaを実行
というようなことが可能です。

他にもS3トリガーであれば、

  • 特定のS3にファイルがアップされたらLambdaを実行(Lambda内でアップされたファイルを読み込んで処理を実行)
というようなことが可能です。

こちらは生成AIさんが記載している「イベント駆動で自動的にシステムを伸縮させることができ、様々なアプリケーションやサービスを効率的に実行できます。」の「イベント駆動で」の部分ですね。

これまでは何かをトリガーとしてプログラムを実行させるという事は意外と難しい状況でした。(頑張ってファイルがあったらプログラムを実行とかしてました)

Lambdaは各AWSのサービスをトリガーと出来るので、先ほどの

  • S3にファイルがアップされたら
    とか
  • SQSでキューにたまったら
    とか
  • DynamoDBに書き込みをしたら
などの条件設定が可能です。

生成AIさんは「イベント駆動」と言ってますが、大体イベントドリブン(event driven)という言い方が一般的かなと思います。

Lambdaの費用

高いか安いかでいうと高いです。
費用体系はこんな感じです。

X86 CPU
0.0000166667 ドル(USD)/秒
Arm CPU
0.0000133334 ドル(USD)/秒
メモリ(128MBごと)
0.0000000021 ドル(USD)/ミリ秒

単位が小さすぎて良く分かりませんね。

具体的にはX86、512MBのlambdaを1時間使った場合の費用は「0.08988012」となり、約0.09ドル(USD)と考えるとおおよそ13.5円になります。(1ドル、150円の場合)

最初に高いと言いましたが、Lambdaは常時動かすことを想定しておらず、必要な時のみ稼働させる(費用が発生する)と意味では大変お安く利用が可能です。(単価自体は高いですが、サーバが1日中稼働するのに対し、実際費用な稼働が1時間のみの場合、Lambdaは1時間の課金で済みます)

なお、Lambdaの処理させる場合において、X86 CPUを使う必要はありません。値段の安いArmにしておきましょう。
「インテル、入ってない」です。これも歴史の流れですかねー。

Lambdaの問題

Lambda凄いよねー。というお話をしていたような気がしますが、意外と問題もあるよ。
というお話ですね。

以下のような問題があります。

メモリが足りなくなるとエラー終了する

Lambdaのメモリは128MB~10240MBで選択が可能です。
で意外とメモリを食います。
(ファイナルファンタジー6(SFC)は、24メガビットロムなので3MBなんですけどー。時代が違うとはいえ、しょぼい処理でメモリを1GBぐらい食われるとびっくりします。)

まぁ、メモリ消費するのは仕方ないのですが、メモリが無くなると実行が中断されてしまいます。
再実行も出来ますが、再実行はせずエラーを検知する仕組みを作ったほうが良いでしょう。

MAX15分(900秒)しか処理が出来ない

Lambdaのタイムアウト上限は15分(900秒)となります。
なので1つのLambdaファンクションは900秒以内に処理を終える必要があります。

要するにあんまり長い処理は出来ないという事です。
処理が長くなる場合、処理を分ける。分けた処理はStep Functionとかで制御させましょう。
(正直Lambdaの根本思想として15分もあれば十分です。長い時間使いたいという場合、そもそもミスマッチなので本当にLambdaを使うのか再検討しましょう)

処理が終わるとターミネイトされる

Lambdaは処理が終わるとターミネイトされます。
当然データはロストします。必要なデータはS3等の外部ストレージに出力する設定としましょう。

また、API Gtewayと組み合わせてサーバレスでユーザからのリクエストを受け付けるといった場合にも注意が必要です。

大体DBにデータを取りに行ったり書き込んだりしますが、リクエストを受け付けてLambdaが起動。
必要に応じてDBにアクセス。
処理が終わるとターミネイト。
という形になりますので、RDBを利用している場合、

  • セッション上限に達する
  • 新規でコネクションを張るので負荷が上がる
などの問題が発生します。

Lambda + RDBを利用する際は、必ず「RDS Proxy」を利用するようにしましょう。

意外(?)とエラー検知が難しい

オンライン処理にlambdaを使う場合、ユーザがリトライしてしまうので意外とエラーに気がつきません。
(必ず再現するエラーとかは流石に気づきますよ。)
なので結構真面目に使うよ。
という場合はきちんとLambdaを監視する必要があります。

この辺の監視はDatadogとかNewRelicとかのツールを使ったほうがいいですね。
検討しましょう。
AWS X-Rayを使ったとしても可視化のためにはツールを入れておいた方が良いです。
(1日1回のバッチ処理ぐらいであれば、不要かもしれませんね。)

塩漬けできない

マネージドサービスなので、プログラム言語のアップデートに追随する必要があります。
塩漬けは出来ません。

そもそもしちゃいないですが、塩漬けするならコンテナ最高、と思っています。

終わりに

という訳で、「いまさら聞けないLambdaの話」でした。
すごいいまさら感がある記事ですが、どうでしたでしょうか。

昔話になりますが、Lambdaがリリースされたのは2014年になります。
この2014年は園田がAWSの部署に異動した年で、はじめてre:Inventに参加した年でもあります。
(実際にはその前からCTCのデータセンターからAWSのDirectConnectを使ったサービスをリリースしたいということで設計、設定をしてましたが、ノーカン扱いにしてください。)

実は当時re:Inventでlambdaがリリースされたと言われたときは、全く良く分からなかったんですよね。
「なんだろ、これ?」みたいな感想だったと記憶しています。

ただ、2015年になると意外とみんな使ってる。2016年になると使って当たり前。みたいな状況になっていた事が印象的でした。

一度使ってしまえば、Lambdaは全然難しくないです。
こんな素晴らしい機能がクラウドだと簡単に使えるなんて改めてすごいなーと思います。

まずは一歩を踏み出して、Lambdaを使って当たり前。の状態まで意識を持って行きましょう。多分、思っているより「すぐ」ですよ。

ではまた、別の記事でお会いしましょう。

お問い合わせ

【著者プロフィール】

園田 一史(そのだ かずし)

伊藤忠テクノソリューションズ株式会社 クラウドアーキテクト

AWSの導入・運用支援サービス「CUVIC on AWS(キュービック オンエーダブリューエス)」の運営を担当。大規模DCのNW設計・構築、また国産IaaS型クラウドサービスの企画・導入・設計を歴任。物理・仮想基盤の設計、構築経験を活かし、AWSの導入・構築の支援をサポート。2019年~2025年APN Ambassadorに選任。

園田 一史(そのだ かずし)

pagetop