Hello from Lambda！AWSでサーバーレスに触ってみた #1

こんにちは。クラウドサービス部の小池です。
まだ暑い日が続いていますが、いかがお過ごしでしょうか。

そう切り出すと怖い話でも始めそうですが、当記事で取り上げるのは「サーバーレスを構築する」お話です。

サーバーがない状態でどうやってシステムを構築するのか、想像できますか？実際に手を動かしてみないと、ピンときませんよね。

そんな疑問に応えるために、サーバーレス初心者向けの連載を始めます。全5回でお送りするこの連載は、オンプレからスキルシフト中の「クラウド初心者」エンジニアや、資格試験で「サーバーレス」の言葉や機能を覚えたものの、実際に触れたことのない初心者エンジニアの入門編です。

連載を通じて、サーバーレスを始めとしたクラウドネイティブの技術を身近に感じていただけるようになったら嬉しいです。

WHY サーバーレス？

「サーバーレス？もうみんな理解しているよね？」なんて声が聞こえてきそうですが......、空耳ですね。ライターの自己紹介にも書いていますが、私は外国語学部出身ながら、オンプレミスのインフラ技術者としてキャリアを重ねてきました。ところがここ数年、時代に取り残されぬようクラウドへのスキルシフトを余儀なくされています。

個人的には、昔ながらの冷え冷えのデータセンターで、自分の手でサーバー機器をラックマウントしてLANケーブルを挿していると、ハードウェアに愛着が湧いてマシンに愛を注げるのですが、クラウドは真逆を行く存在。今やハードウェアはクラウド事業者に任せるのが基本で、データセンターどころかマシンルームに入ったことのない若手技術者も増えています。

オンプレミスを長く利用していたお客様もクラウドリフトを終えつつあり、次の取り組みとしてクラウドネイティブ志向や、サーバーレス構成についての話題が増えています。そこで、私も本気でこの分野のことを考えてみました。

何故ハードウェアを持たなくなってきたのかというと、その根底には「モノは壊れる」という現実があるのではないでしょうか。

オンプレミスでもクラウドでも、サーバーやストレージが壊れても業務を続けられるように設計することは共通の思想です。その中で、ハードウェアが壊れたときの修理対応をクラウド事業者に任せ、私たちは業務継続に専念するほうが、運用管理の手間を削減してコスト効率も高まります。

サーバーはどこかには存在しているものの、日常的に見えない場所にあるため壊れることをあまり気にしなくてもいい。この考え方がさらに発展し、今ではハードウェアどころか、仮想サーバーやOSすら持たず「処理能力」のみを購入するという、サーバーレスの選択肢が出てきたのです。

しかし、サーバーが手元にあれば「構築する」というイメージが湧きますが、サーバーがないのに「構築する」とはどういうことなのでしょうか？実際に手を動かしてみないと、なかなか理解できない部分もあるかと思います。そこで、20年目のインフラ技術者として、ハンズオンでこの挑戦に取り組んでみることにしました。

ここからは、AWSが公開しているハンズオン^※のセクション1をもとに実際に手を動かした結果や、前提知識が足りなくて迷ったところ、理解を深めるポイントを詳しく解説します。画面遷移は多少変わっていますが、ハンズオン手順の通りに構築は問題なくできます。「サーバーレス構築とは何なのか」について理解し、公式ハンズオンの隙間を埋める手がかりとして、この記事をご覧ください。

※ サービス連携の体験ハンズオン

Hello from Lambda！

AWSでサーバーレスと言えば、真っ先に思い浮かぶサービスが「AWS Lambda」です。そして、プログラミングの基本中の基本といえば、あの「Hello World!」。もはや伝説なのか定番なのかわかりませんが、なぜかプログラミングの最初は定型文の挨拶ですね。

Lambda関数の作成画面でも、最低限の情報を入力して「作成」ボタンを押すと、デフォルトで「Hello from Lambda!」と表示する関数コードができます。今回は「サーバーレスを構築してみる」初回の取り組みとして、このデフォルトのコードを動かすところまでやってみました！

作業環境

Webブラウザ	Firefox
作業する リージョン	AWS東京リージョン[アジアパシフィック(東京) ap-northeast-1 ]
利用する サービス	AWS Lambda（イベント発生時にコードを実行）| AWS

Lambda関数とは

Lambda（ラムダ）とは、ギリシャ文字の第11文字ですが、プログラミング黎明期には「無名関数」のことを、そう呼んでいました。関数をひとことで言えば、「処理される実行コード」といったところでしょうか。

AWS Lambdaでは、実行させたいプログラムに加えて、いつ実行するのかを決めるトリガー、実行の記録を残すログ、処理した結果をどうするかを定義しておくだけで、やりたいことを手軽に実現できます。実行時間の制約など詳細はまた別の話として、Lambdaの基本的な仕組みを押さえておくと、サーバーレスの可能性がぐっと広がります。

Lambda関数を作ってみた

ハンズオン手順の画面遷移に従い、マネージメントコンソールへ入力した項目は以下の通りです。

提示されていた手順以外で設定した項目は、タグの有効化でした。個人アカウントであれば不要かもしれませんが、今回は複数メンバーと共有する自社の検証アカウントを使用しているため、セキュリティやコスト観点から、自分が作成したリソースを後から追跡できるようタグづけをしています。ランタイムのバージョンは、検証時の最新版を使用しています。

関数の作成	一から作成	選択
関数名	rkoike-handson-function ※ 冒頭部はユーザ固定読み替えしてください	入力
ランタイム	Python 3.12	デフォルト
アーキテクチャ	x86_64	デフォルト
アクセス権限	基本的なLambdaアクセス権限で新しいロールを作成	デフォルト
タグの有効化	UserName	個人名入力

アーキテクチャに選択肢がありました！どこかのデータセンターにある「x86_64」ベースのマシン上でこの関数は動くのですね。

でき上がりの画面はこちらです。デフォルトでこのようなレスポンスを返すコードが作成されています。

'statusCode': 200,
'body': json.dumps('Hello from Lambda!')

Lambda関数を動かしてみた

青いテストボタン押して、実行した結果はこちらです。

Execution resultタブが現れ、Function Logsが表示されました。もともとシンプルなコードなので、当然そのレスポンスのみですが、ちゃんと実行されてログが記録されたようです。使われたメモリ量（Max memory used）や所要時間（Time）も読み取れます！

Lambda関数のお財布事情

さて、ここまではハンズオン手順通りやってみた結果を共有しましたが、実際に利用する際に気になるのは費用の問題です。

サーバーのハードウェアやOSのライセンス料が不要とはいえ、毎回の実行コストが高ければ「サーバーレス」のメリットが薄れてしまいますよね。AWS Lambdaの従量課金は以下の表^※のような体系です（2024年9月3日現在）。

※ 以下の表はAWS Lambda料金からの抜粋です。
料金 - AWS Lambda ｜AWS

まずは実行時間に対する課金です。

アーキテクチャ	期間	リクエスト
x86 価格
最初の60億GB秒/月	GB-秒あたり0.0000166667USD	リクエスト100万件あたり0.20USD
次の90億GB秒/月	GB-秒あたり0.000015USD	リクエスト100万件あたり0.20USD
150億GB秒/月以上	GB-秒あたり0.0000133334USD	リクエスト100万件あたり0.20USD

実行時に使われるメモリ量への課金もあります。

メモリ	1ミリ秒あたりの料金
128MB	0.0000000021USD
512MB	0.0000000083USD
1,024MB	0.0000000167USD

メモリ	1ミリ秒あたりの料金
128MB	0.0000000021USD
512MB	0.0000000083USD
1,024MB	0.0000000167USD

さらに一時的に使われるストレージも課金があります。

エフェメラル ストレージ

GB-秒あたり0.000000037USD

エフェメラル ストレージ

GB-秒あたり0.000000037USD

他にもオプションはありそうですが、いずれにしろ小数点以下の桁が大きいものばかりで結局値段がわからないと思いましたね？分解して確認してみましょう。

メモリ	128MB
エフェメラルストレージ	512MB
タイムアウト	3秒
SnapStart	None

これに対し、呼び出して実行される時間分の課金がされるわけです。しかし、呼び出して実行される時間、しかもGB秒単位というのはどこを見ればいいのでしょうか。

手がかりがここにありました。Lambda > 関数 > 今回作った関数のページでモニタリングのタブを下の方へスクロールすると、「Recent invocations」という表があります。これの一番右が「BilledDurationInMS」すなわち「請求期間（ミリ秒単位）」です。

この数値を料金計算ツールCreate estimate: Configure AWS Lambda^※に入力してみます。必要な情報を1つ仮定。今は検証中なので、仮にリクエストの頻度を以下のように設定します。

※ Create estimate: Configure AWS Lambda

1営業日当たり2,000回＊20営業日＝40,000リクエスト／月

無料枠を使わなくても、今回の利用でかかったコストはまさかの0.01USD......！1ドル150円で換算しても2円もしません！！データセンターにサーバーを置いていたら、待機電力だけで遥かにかかりますね（極端な比較ですが）。

ただし、今回の試算はあくまでもお試しレベルのものです。実際にかかる費用は、同時実行数や処理内容、頻度によって変わるので、その点はしっかり考慮してください。

おわりに

さて、作ってみたHello from Lambda、次はどう活用しましょうか。せっかくなので、ハンズオンを進めて他のサービスとの連携を試してみようと思います。例えば、S3イベントトリガーにしたり、SNSなどと連携させたりして新しい可能性を探ってみたいところです。

次回の連載では、S3のイベント通知を使ったLambdaとの連携と、Lambda関数の実行後にユーザにEmailで通知する機能作成をご紹介します。ぜひお楽しみに。

なお、ラックはセキュリティの会社ですが、筆者のようなスキルシフト中のエンジニアだけでなく、経験豊富なクラウド技術者やコンサルタントが多数在籍しています。AWSだけではなく、OCI、Azure、Google Cloudも取り扱い、クラウド移行からクラウドネイティブ支援、サーバーレス構築まで、幅広くサポートしますので、お気軽にご相談ください。

関連記事

• S3イベント連携 with Lambda！AWSでサーバーレスに触ってみた #2
• Hello from SQS to Lambda！AWSでサーバーレスに触ってみた #3
• Hello from Lambda in API Gateway！AWSでサーバーレスに触ってみた #4
• Lambdaのログを見てみよう＆検証リソースお片付け！AWSでサーバーレスに触ってみた #5

プロフィール