AWS Lambda

2026年5月31日 19:30

分類：
料金：使用したコンピューティング時間分
特徴：サーバーのプロビジョニングや管理を行うことなくコードを実行できます。ほぼあらゆる種類のアプリケーションやバックエンドサービスに対応したコードを、管理作業なしで実行できます。コードをアップロードするだけで、Lambda がコードの実行と高可用性でのスケーリングに必要なすべての処理を自動的に行います。

公式ガイド

🚀 サーバーを捨てる覚悟はあるか？AWS Lambdaがもたらした「重労働」からの解放と運用のリアル

クラウドの進化とは、開発者をいかにインフラという「物理的な制約」から解放するかという歴史そのものである。本コラムでは、AWSの公式技術セミナー「AWS Black Belt Online Seminar」の『AWS Lambda Part1』を基軸に、サーバーレスコンピューティングの本質を深く掘り下げる。ビジネスにおけるアプリケーション開発の真の目的は、他社との差別化につながる「価値」の創出であり、サーバーのセットアップやパッチ適用といった「差別化につながらない重労働（Undifferentiated Heavy Lifting）」ではない。動画では、物理マシンから仮想マシン、コンテナを経てサーバーレスへと至るコンピューティングの変遷を辿りながら、Lambdaの基本構造や設定、イベントソースの分類、同期・非同期の挙動、VPCアクセス、そして実務で最も重要な同時実行数の制約やライフサイクル（コールドスタート）までが論理的に解説されている。本稿では、テクニカルコンサルタント「なかじー」の視点から、この古典的かつ極めて重要なセッションをPSC（目的・現状・制約）のフレームワークと5つの内部フィルターを用いて徹底的に精査し、単なるトレンドに終始しない「現場の実装」のための知見へと昇華させる。

動画情報

チャンネル名: Amazon Web Services Japan 公式
動画公開日: 2019-04-19
動画タイトル原文: 【AWS Black Belt Online Seminar】 AWS Lambda Part1

動画解説

セミナーは、AWSジャパンの西谷氏による丁寧な挨拶と、Black Beltオンラインセミナーの概要説明から始まります。西谷氏は、Lambdaに関するBlack Beltセミナーが実に3年ぶりの開催であることを明かし、最近の個人的なエピソードとして、5歳になる娘から「パパの顔はなんで骸骨なの？」と質問されて回答に窮したというユーモラスな話を披露し、参加者の緊張をほぐします。その後、将来のロードマップやAWS IoT Greengrassについては本セッションの対象外であるという注意点が告げられた後、当初は2回構成を予定していたものの、資料のボリュームがあまりにも膨大になったため急遽全3回に拡張し、今回のPart1では「Lambdaをまだ使い始めていない状態」を対象とした基礎概念に特化して解説するという全体のロードマップが示されます。

差別化につながらない重労働

ここから本編へと進み、西谷氏はまず「デベロッパーの真の目的とは何か」という根本的な問いを投げかけます。ビジネスにおいてアプリケーションを開発する目的は、自社のサービスを差別化する価値を届けることにあり、開発者は本来、ビジネスロジックの実装に全ての時間を割きたいはずであると主張します。しかし、現実の運用現場では、サーバーを所有することによってOSやネットワークのセットアップ、ランタイムの管理、キャパシティプランニング、負荷に応じたスケーリングの設計、耐障害性を担保するための冗長化、端的な例ではwebサーバーで1台で済む負荷であっても高可用性のために2台構成にする必要性、そして絶え間ないセキュリティパッチの適用といった多大な作業に追われることになります。さらに、APIを公開する際の後方保護のためのスロットリング実装や、差別化を生まない定型的な認証・認可の仕組みづくりなど、開発者のリソースを消費する課題は尽きません。オンプレミス環境であれば、これらのインフラ調達だけで見積もりや発注、納品を経て数ヶ月のリードタイムを要することもあります。AWSではこれらを「差別化につながらない重労働（Undifferentiated Heavy Lifting）」と定義しており、これらがいかに開発者の俊敏性を奪っているかを浮き彫りにします。

ゼロメンテナンス

この課題を解決するために歩んできたコンピューティングの進化の歴史が提示されます。かつての物理マシン時代は、正確な予測が不可能な中で数年先を見据えたキャパシティプランニングを行う必要があり、調達後の後戻りが極めて困難でした。その後に登場した仮想マシンは、ハードウェアから抽象化されることで弾力性と俊敏性を劇的に向上させましたが、OSの管理やメンテナンスの手間は依然として残されていました。さらに進化したコンテナ技術は、環境の一貫性を担保し、軽量なデプロイとプロセスの隔離による高い起動速度をもたらしました。そして、これら全ての進化の先に行き着いたのがサーバーレスであり、連続的な自動スケール、組み込みの耐障害性、そして「ゼロメンテナンス」という究極の運用形態を実現します。

西谷氏はサーバーレスの定義として、インフラのプロビジョニングや管理が不要であること、リクエスト数に応じてシームレスに自動スケールすること、事前コストがなく実際の処理量のみに対して支払う「価値に対する支払い」であること、そして高い可用性が最初から組み込まれていることの4つを挙げます。AWSにおけるEC2、Fargate、Lambdaの使い分けにおいては、自由度が高いプラットフォームほど管理の手間が増大するという表裏一体の関係性があるため、設計のベストプラクティスとしては、最も制約が大きく管理の手間が少ないLambdaからファーストチョイスとして検討し、どうしても要件を満たせない場合においてのみ、自由度の高いコンテナや仮想マシンへと選択肢を広げていくべきだという実務的なアプローチを提示します。

Lambdaの歴史

Lambdaの歴史を振り返ると、2014年に発表され2015年4月に一般利用可能（GA）となりました。発表当初は「イベントドリブンコンピューティング」と称されており、サーバーレスという言葉は使われていませんでしたが、2015年夏にAPI Gatewayがリリースされたことで、今日広く知られるサーバーレスのアーキテクチャモデルが確立されました。このモデルの本質は、イベントソースにおける状態の変化（S3へのオブジェクト配置、DynamoDBの更新、HTTPSリクエストなど）をトリガーとしてLambda関数が起動し、必要に応じてダウンストリームのデータベースや外部のサービス（SlackやTwilioなど）へ処理を繋いでいくというビルディングブロックの連鎖にあります。

アンケート結果を交えたデータでは、実際の活用領域としてWebシステムやデータ処理パイプラインが多く、API GatewayやDynamoDBとの組み合わせが圧倒的な主流であることが示されます。

Lambda関数のメカニズム

続いて、実装者が把握すべきLambda関数の具体的なメカニズムに話が及びます。Lambda関数はサービス側が管理する隔離されたコンテナ内で実行されますが、重要な原則として「1つのコンテナが同時に複数のイベントを並行処理することはない」というシングルスレッド的な分離が行われます。コードや非依存関係のライブラリはジップなどの形式でパッケージングしてアップロードされ、内部的にS3へ暗号化保存されます。実行時には指定した「ハンドラー」が呼び出され、JSON形式のイベントデータが引数として渡されて処理が実行されます。開発者が管理すべき基本設定はメモリ、タイマー（タイムアウト）、実行ロールの3つに集約され、メモリは128MBから3008MBまで選択可能で、この容量に比例してCPUの処理能力も割り当てられます。

タイムアウトは最大900秒（15分）まで設定でき、不要な実行による過度な課金を防ぐ役割を持ちます。
また、他のAWSリソースへのアクセス権限を制御するためにIAMロール（実行ロール）の指定が必須となります。

実行環境のベースはAmazon Linuxであり、C言語などで書かれたネイティブライブラリを組み込む場合は、この実行環境とのバイナリ互換性を担保するために、同じ環境上で事前にコンパイルを行う必要があるという開発上の注意点が語られます。

イベントソース

Lambda関数は、何らかのイベント（状態の変化）をトリガーにして起動する「イベント駆動型（イベントドリブン）」のコンピューティングサービスです。この起動のきっかけを与えるAWSサービスやアプリケーションのことを「イベントソース」と呼びます。
イベントソースは、その動作メカニズムによって大きく3つのタイプに分類されます。ここを理解することが、適切なアーキテクチャ選定の第一歩となります。

ポーリングベースとそれ以外

イベントソースの動作特性については、ポーリングベースとそれ以外に明確に分類されます。ポーリングベースの中には、KinesisやDynamoDB Streamsのような「ストリームベース」のものと、SQSのような「非ストリームベース」のものがあります。

ポーリングベース（ストリームベース）
Lambdaのインフラ側が、これらストリームサービスのデータを定期的に見に見に行き（ポーリング）、新しいレコードが存在する場合に関数を自動的に実行します。
該当サービス：Amazon Kinesis Data Streams、Amazon DynamoDB Streams

ポーリングベース（ストリーム非ベース）
ストリームではないキューイングサービスですが、こちらもLambda側が裏側で自動的にキューを監視（ポーリング）し、メッセージがたまると関数を引き当てて実行します。
該当サービス：Amazon SQS（Simple Queue Service）

それ以外のイベントソース（プッシュ型）
Lambda側が監視するのではなく、イベントソース側で「オブジェクトが生成された」「HTTPリクエストが届いた」といった状態変化が起きた瞬間に、Lambda関数を直接呼び出す（プッシュする）形態です。
該当サービス：Amazon S3、Amazon API Gateway、Amazon SNSなど

同期／非同期呼び出し

Lambda関数を呼び出す（実行する）方法には、「同期呼び出し」と「非同期呼び出し」の2つのインボケーションタイプが存在します。

カスタムアプリケーションからSDKを介して呼ぶ場合や、AWS CLIを用いて手動でテスト実行する際などは、呼び出し側で明示的にタイプを指定できます。なお、AWSサービスがイベントソースとなる場合は、サービスごとにどちらのタイプで呼び出すかがあらかじめ仕様として固定されており、ユーザーが任意に変更することはできません。

非同期呼び出し（Invocation Type: Event）
リクエストがLambdaのシステム側に正常に受け付けられたかどうか（ステータスコード202）のみを呼び出し元に即座に返却します。実際の関数の実行完了や処理結果を待たずに呼び出し元へ制御が戻るため、呼び出し側の処理をブロックしません。大量の処理を並列でバックグラウンドに流し込みたい場合（例：S3へのファイルアップロードを契機とした非同期データ処理など）に最適です。

同期呼び出し（Invocation Type: RequestResponse）Lambda関数の処理が完全に終了するまで呼び出し元は待機（ブロック）し、関数が返した処理結果（レスポンス）をその場で受け取ります。API Gatewayを介したWebアプリケーションのバックエンドAPIや、処理の成否をその場で判定して次のステップに進みたいシステム連携などで利用されます。この場合、Lambda関数側のコード内でレスポンスの内容を正しくセットしてあげる必要があります。

イベントソース

ポーリングベースのサービスでは、Lambda側が「イベントソースマッピング」と呼ばれる設定情報を保持・管理してくれるため、開発者が自分でポーリングを行うコードを書く必要は一切ありません。この「Lambdaが自らデータを取りに行くのか、外部からプッシュされるのか」という構造の違いが、この後解説するエラー時の挙動に直結してきます。

リトライ(ストリームベースではない)

分散システムにおいて、エラーハンドリングの設計はシステムの信頼性を左右する最重要項目です。Lambdaでは、エラーの発生元（イベントソースのタイプ）や呼び出しタイプによって、自動リトライの挙動が大きく異なります。ここを曖昧にしていると、「データが消失した」「同じ処理が何度も重複して走ってしまった」というトラブルを引き起こします。
① ストリームベースではないイベントソース：同期呼び出しの場合
関数内でエラー（コードの例外、タイムアウトなど）が発生した場合、レスポンスのヘッダーに Function Error という項目が含まれて呼び出し元に返されます。また、権限不足や同時実行数上限による制限、コードのバグなどに応じて特定のステータスコードが返却されます。
Lambda側での自動リトライは行われません。リトライを行うかどうか、あるいはどのようにハンドリングするかは、呼び出し元のAWSサービス側が持つ独自のリトライポリシー、もしくはクライアントアプリケーション側の実装に完全に委ねられます。

② ストリームベースではないイベントソース：非同期呼び出しの場合
非同期呼び出しでエラーが発生した場合、Lambdaは自動的に最大2回までリトライを試みます（最初の実行と合わせて合計3回実行されます）。
リトライは即座に行われるのではなく、一定の遅延（ディレイ）を挟んで実行されますが、この遅延時間をユーザーがコントロールすることは現時点でできません。
もし3回とも実行に失敗した場合、デフォルトのままではそのイベントデータはシステムから消滅（破棄）してしまいます。これを防ぐために必須となるのが「デッドレターキュー（DLQ）」の設定です。DLQとしてAmazon SQSキュー、またはAmazon SNSトピックを指定しておくことで、どうしても処理できなかった未処理のイベントデータを安全に退避させ、後からエンジニアが原因調査や再処理（ペイロードの再投入）を行うことができます。

リトライ(ストリームベース)

③ ポーリングベース：ストリームベース（Kinesis / DynamoDB Streams）の場合

ストリームベースのポーリングでは、データの順序性を厳格に守ることが求められます。そのため、データ処理でエラーが発生した場合、Lambdaはデータの有効期限が切れて削除されるまで、そのデータを何度も何度も愚直にリトライし続けます。（※有効期限は、KinesisやDynamoDB Streamsのサービス側の保持期間設定に準じます。例えば24時間〜数日間など）。
　ここで最も注意すべきなのは、エラーが発生したレコードの処理が成功するか、あるいは期限切れで消滅するまで、その「シャード」からのデータ読み込みが完全にブロック（停止）してしまうという点です。つまり、1つのデータエラーのせいで、同じシャードに後から入ってきた新しい正常なレコードの処理がすべて後ろで詰まってしまう「ヘッドオブラインブロッキング」が発生します。

④ ポーリングベース：ストリーム非ベース（Amazon SQS）の場合
SQSをイベントソースとする場合、バッチ内のメッセージ処理でエラーが起きると、そのメッセージは自動的にSQSキューへと戻されます（メッセージの「可視性タイムアウト」が経過した後、再び別のLambdaインスタンスなどによって再処理されます）。
ストリームベースとの決定的な違いは、後続の新しいメッセージの処理は一切ブロックされないという点です。エラーになったメッセージを横目に、新しく届いたメッセージはどんどん並列で処理されていきます。

VPCアクセス機能

本番システムにおいて、VPC（Virtual Private Cloud）内にあるAmazon RDS（リレーショナルデータベース）やAmazon ElastiCache（キャッシュクラスター）に対して、インターネットを経由させずにセキュアにアクセスしたいケースは多々あります。Lambdaには、これを安全に実現するための「VPCアクセス」機能が提供されています。
　設定自体は、Lambda関数に対してアクセス対象 of VPC、サブネット、およびセキュリティグループを指定するだけと非常にシンプルです。関数の新規作成時だけでなく、既存の関数に対して後から動的に変更することも可能です。

ここでインフラ設計上、絶対に守るべきベストプラクティスがあります。それは、「アベイラビリティゾーン（AZ）ごとに、必ず1つ以上のサブネットを指定しておくこと」です。万が一、特定のAZで大規模な障害が発生した場合や、サブネット内のIPアドレスが枯渇してしまった場合でも、別の健全なAZにあるサブネットを利用してLambda関数が継続して実行できるため、システムの高可用性を維持するために不可欠な設計となります。

VPCアクセスの内部メカニズムと権限の裏側
LambdaのVPCアクセスは、EC2などで使われているネットワーキング機能である「Elastic Network Interface（ENI）」を裏側で作成・利用することで実現しています。このENIの作成・アタッチ・削除といったライフサイクルは、Lambdaサービス側によって完全に自動コントロールされています。Lambda関数が実行されると、指定されたサブネット内からDHCPによって動的にプライベートIPアドレスが切り出され、生成されたENIに割り当てられます。
　この仕組みを正常に稼働させるためには、Lambda関数に紐付ける「実行ロール（IAMロール）」に対して、AWSLambdaVPCAccessExecutionRole という管理ポリシーがあらかじめアタッチされている必要があります。このポリシーによって、LambdaサービスがユーザーのVPC内にENIを作成・管理するための適切なEC2権限が許可されます。

⚠️ 設計時に絶対に知っておくべき注意点と運用の罠
非常に強力なVPCアクセス機能ですが、その仕様を正しく理解していないと、本番環境で「原因不明のシステム停止」を引き起こす、いくつかの大きな罠が存在します。

罠その1：インターネットアクセスの即時遮断
VPCアクセスを設定した瞬間から、そのLambda関数はインターネットへ直接アクセスすることができなくなります。Lambdaに紐付けられるENIにはパブリックIPアドレスが割り当てられないためです。
「VPC内のRDSからデータを取得しつつ、外部の決済API（SaaS）を叩きたい」というようなケースでは、VPC内にNATインスタンスまたはNATゲートウェイを構築し、Lambdaを配置するサブネットのルートテーブルでNAT経由の外向き経路（0.0.0.0/0）を通すようにネットワークトポロジーを明示的に設計する必要があります。

罠その2：IPアドレス・ENIの枯渇エラーと「サイレントロスト」の恐怖
突発的なトラフィックのスパイクなどによってLambdaの同時実行数が急激に増加した際、指定したサブネット内の空きプライベートIPアドレスや、作成可能なENIのキャパシティが不足していると、関数の実行は失敗（Exceptionが発生）します。ここで最も恐ろしい運用の罠は、「非同期呼び出しの場合、この枯渇エラーはCloudWatch Logsに一切記録されない（ログが出ない）」という点です。
　なぜなら、ENIの作成やIP確保に失敗した段階では、Lambdaのコードを実行するための「コンテナ自体を立ち上げることができない」ため、ログを出力するための仕組みすら起動しないからです。「CloudWatchのメトリクス上ではエラー数が跳ね上がっているのに、CloudWatch Logsを見に行ってもログが1行も出力されていない……」という極限状態に陥った場合、このIPアドレス・ENIの枯渇問題を真っ先に疑ってください。

この現象をデバッグ・確認したい場合は、Lambdaのコンソールから「テスト実行（同期実行）」を手動で行うことで、画面上に直接「ENIが作成できなかった」旨のExceptionを表示させ、エラー内容を確実にキャプチャすることができます。

罠その3：必要なENIキャパシティの算出見積もり式
サブネットのCIDR設計（IPアドレスの個数確保）を誤らないために、必要ENI数の計算目安の式を必ず覚えておきましょう。

大抵のワークロードではこの計算式で算出された値以下に収まりますが、稀にそれ以上のENIを消費するケースもあります。
サブネットを設計する際は、CIDRの枠を十分に大きく確保（例：/24以上など）しておくことが鉄則です。また、AWSアカウント全体で作成可能なENIの総数（デフォルトでは「利用可能なEC2インスタンス数 × 5」などの制限）にも引っかかる可能性があるため、大規模なシステムを構築する前には、事前にAWSサポートへ制限緩和申請（上限緩和）を投げておく運用が極めて重要となります。

同時実行数（Concurrency）

さらにセッションは、運用設計の核心である「同時実行数（Concurrency）」の管理へと進みます。同時実行数とは、ある特定の瞬間に並行して走っている関数の総数であり、AWSアカウントごとにデフォルトで「1000」という上限が設けられています。これを超過したリクエストに対しては、ステータスコード429のスロットリングエラーが即座に返却されます。同時実行数の見積もり方はイベントソースごとに異なり、ストリームベースであればシャード数に依存し、それ以外のWeb APIなどの場合は「秒間呼び出し回数 × 平均実行時間」の数式で算出します。スケーリングの特性として、負荷のスパイクが発生した際に一瞬で対応できる「初期バースト制限」が存在し、東京リージョンでは一律で1000に設定されています。これを超える急激な負荷の増加に対しては、アカウントの上限をどれだけ引き上げていたとしても、1分間に500ずつしか同時実行数が増加しないというプラットフォーム固有の制約があるため、突発的なスパイク耐性を設計する上での極めて重要な留意点として語られます。

最後に、Lambda関数の内部的なライフサイクルが明かされます [58:04]。リクエストを受けた際に、利用可能なコンテナが存在しない場合に発生するのが「コールドスタート」です。このフェーズでは、VPCアクセスのためのENI作成、コンテナのプロビジョニング、パッケージのロード、そしてランタイムの初期化とグローバルスコープのコード実行が行われるため、ハンドラーが実際に動くまでに大きな遅延が生じます。一方、一度動いたコンテナを再利用してこれらの初期化プロセスをスキップし、即座にハンドラーを実行する仕組みを「ウォームスタート」と呼びます。西谷氏は、定期的なリクエストが安定して入っていればコンテナは自動的に維持されるため、コールドスタート対策として巷で行われている定期的なポーリング処理は、多くの場合において無駄であると指摘します。また、Lambdaの固有の挙動として、ハンドラーの処理が終了した瞬間にバックグラウンドのプロセスは全て一時的に凍結され、次回のウォームスタート時にそのまま再開されるため、非同期のバックグラウンドスレッドを関数内で安易に走らせるべきではないという実装上の罠が指摘されます。最後に、月間100万回までの無料枠や、100ミリ秒単位の実行時間課金、メモリ容量に連動する単価設定といった経済的なコスト構造を振り返り、基礎編としてのPart1が締めくくられます。

技術解説

テクニカルコンサルタントの「なかじー」だ。クラウドの黎明期から今日に至るまで、数多くのシステム構築と、それに伴う泥臭い運用の摩擦（フリクション）を肌で感じてきた身として、このAWS LambdaのBlack Beltセミナーを改めて精読すると、非常に感慨深いものがある。同時に、ここで語られている「公式仕様」と「現場の実装」のギャップは、時代を経てもなお、多くのプロジェクトマネジメントにおいて意思決定の岐路となっている。

私の15年のキャリアを振り返ると、クラウド以前のデータセンターのあの独特の「空気感」が脳裏をよぎる。肌を刺すような凍える冷気、防音イヤーマフがなければ耳を痛めるほどのサーバーファンの爆音、そして大量のシリコンと配線が熱を帯びたときに漂う、あの特有の乾燥した匂いだ。当時は、新しいサービスを立ち上げるために、何枚もの稟議書に社印を押し、ベンダーと価格交渉をし、ラックに納品されるまで数ヶ月も待つのが当たり前だった。サーバーを「所有する」ということは、それ自体が巨大な資産であり、同時に引き返せないリスク、つまり重い足枷でもあったのだ。

西谷氏が本セミナーの冒頭で語った、5歳の娘さんから「パパの顔はなんで骸骨なの？」と問われたというエピソード [02:38] には、ユーモアの裏に、当時のエンジニアたちが抱えていた目に見えない疲弊が象徴されているように思えてならない。夜中にサーバーがハングアップし、アラートの呼び出し音で叩き起こされ、目の下にクマを作ってコンソールに向き合っていた我々世代のエンジニアにとっては、自虐的なリアリティを帯びて聞こえる。そうした「差別化につながらない重労働（Undifferentiated Heavy Lifting）」 [04:34] からいかにして脱却するか。これが、サーバーレスという思想の本質的な「目的（Objective）」である。

目的、現状、制約（PSC）の観点からこの技術を整理してみよう。まず「目的」は、ビジネスロジックの実行だけにリソースを集中させ、市場への投入速度（Time to Market）を極限まで高めることだ。「現状」は、インフラの保守運用、セキュリティパッチの適用、突発的なアクセススパイクに対するキャパシティ管理に多くのエンジニアリングリソースが奪われていること。 flocking（群生）するバグとの戦いに追われる日常。そして「制約」は、限られた予算、不確実なアクセス予測、そして高度なインフラ知識を持つ人材の不足である。Lambdaというテクノロジーは、このPSCのコンテキストにおいて、まさに現状の課題を制約の範囲内でエレガントに解決するためのブレイクスルーとして登場した。

ここで、コンサルタントとしての私の5つの内部フィルターを使って、Lambdaの実装におけるリアルを自己検閲（検証）してみたい。

第一のフィルターは「実現性（Feasibility）」だ。コードをアップロードするだけで、月2回のリクエストから秒間数千回までシームレスにスケールするという仕様は [13:23]、理論上完璧に見える。しかし、現場での実現性を担保するには「1コンテナ1イベント」 [26:36] という制約を骨の髄まで理解していなければならない。Lambdaは伝統的なWebサーバーのように、1つのプロセスで大量のスレッドを立ち上げてリクエストを並行処理するアーキテクチャではない。リクエストの数だけコンテナが立ち上がる。この挙動を無視して、関数内部で重厚なフレームワークを立ち上げたり、大量の並行接続を前提とした設計を行ったりすれば、たちまちパフォーマンスは崩壊する。

第二のフィルターは「再現性（Reproducibility）」である。環境の一貫性を保つため、LambdaはAmazon Linuxの実行環境を公開している [35:01]。しかし、スクリプト言語のデータベースドライバーなど、OSのネイティブエクステンション（C拡張など）に依存するライブラリを扱う場合、ローカル環境で単純にパッケージングしただけでは、クラウド上でエラーを吐いて動かなくなる。ステージング環境と本番環境で全く同じ挙動を「再現」するためには、Docker等を用いて、Lambdaの実行環境と同一の環境上で事前にビルド・コンパイルを行うというパイプラインの構築が必須となる。これを怠るプロジェクトは、必ずデプロイの直前で手痛いフリクションを経験することになる。

第三のフィルターは「保守性（Maintainability）」だ。ここで最も大きな議論を呼ぶのが「VPCアクセス」 [47:13] の設計である。RDSなどのリレーショナルデータベースに接続するためには、LambdaをVPC内に配置する必要がある。セミナーが開催された当時、VPC内のLambdaは起動のたびにENI（Elastic Network Interface）を動的に作成していたため、コールドスタート時に大きな遅延が発生していた [58:04]。この挙動は、保守性を著しく低下させる要因だった。さらに、サブネット内のIPアドレス枯渇問題 [47:13] は、今なお運用上の大きなリスクである。同時実行数が増大した際に、指定したサブネットのIPが足りなくなれば、関数はエラーを出すこともログを残すこともなく静かに消え去る。この「沈黙のエラー」を防ぐための監視設計こそが、保守性の極みである。

第四のフィルターは「経済性（Cost Efficiency）」、すなわち「Pay for Value（価値に対する支払い）」 [13:23] の検証だ。100ミリ秒単位の課金は、アクセスが極端に少ないスタートアップの新規事業や、夜間にしか動かないバッチ処理においては、文字通り「コストゼロ」からのスタートを可能にする圧倒的な経済性を持つ。しかし、24時間365日、絶え間なく大量のトラフィックが流入し続ける大規模なシステムにおいてLambdaを使い続けると、データ転送量や実行時間の累積により、常時起動のサーバーを置いておいた方が遥かに安上がりだったという「コストの逆転現象」が容易に発生する。経済性を最適化するためには、メモリ容量を増やすことで逆にCPU能力が向上し、実行時間が短縮されて総コストが下がるという「パワーチューニング」の仕様 [31:25] を逆手に取った、実地での検証が不可欠だ。

第五のフィルターは「安全性（Security）」である。Lambdaはデフォルトで隔離されたサンドボックス環境で実行されるため、マルチテナントの脆弱性に対しては極めて強固だ。しかし、ガバナンスの観点から現場の首を絞めるのが「実行ロール（IAM）」 [31:25] と「リソースポリシー」 [51:34] の管理である。開発のスピードを優先するあまり、すべての関数に広範な権限を与えてしまうアンチパターンが後を絶たない。最小権限の原則に従い、関数ごとに必要なリソースへのアクセスのみを定義したIAMポリシーを1つずつ作成・管理することは、開発初期には非常な摩擦となる。だが、この安全性のフリクションを最初期に受け入れるかどうかが、後に組織の重大なインシデントを防ぐ境界線となる。

また、本セミナーで最も論理的な美しさと運用の厳しさが同居しているのが「同時実行数（Concurrency）」の自動スケーリング仕様である [53:38]。東京リージョンにおける初期バースト制限が「1000」であり、それを超える急激なスパイクに対しては、1分間に500ずつしかスケールアップしないという制約 [56:54] は、突発的なアクセス集中を処理しようとするビジネスにとって、目に見えない「ガラスの天井」となる。アカウント全体の上限を引き上げて安心しているプロジェクトマネージャーに対し、私はいつもこの仕様書を突きつける。数万の同時アクセスが数秒の間に押し寄せる世界では、Lambdaであっても事前のバッファリング（SQSによる平滑化）がなければ、システムは一瞬で429エラーの海に溺れることになる。

さらに、関数のライフサイクルにおける「バックグラウンドプロセスの凍結と再開」 [01:00:02] という仕様も、知識の考古学的な観点から非常に興味深い。多くの開発者が、ハンドラーがレスポンスを返した後も、裏側でログの非同期送信や分析データの処理が勝手に走り続けると思い込んでいる。しかし仕様上、レスポンスが返った瞬間に、そのコンテナのCPUサイクルは完全に一時停止される。次にウォームスタートで呼び出されるまで、その裏側のスレッドは時間の止まったカプセルのようにフリーズするのだ。現場のソースコードのIssueを読み解くと、この「凍結仕様」によるバグが実に多く散見される。

いま、私たちの日常の裏側で動いている無数のデジタル資産やサービスを眺めるとき、サーバーという「実体」を意識することはほとんどなくなった。スマートフォンの画面をタップし、瞬時にデータが処理されるその裏側で、目に見えないコンテナがミリ秒単位で生成され、役割を終えて霧のように消え去っていく。かつてデータセンターの冷気に震えながらハードディスクの交換をしていたあの時代から、私たちは遥か遠い場所へ来てしまった。

この先、さらにテクノロジーが私たちの呼吸や皮膚の感覚と同化していくにつれ、インフラを「構成する」という概念そのものが、完全に歴史の教科書のなかの出来事へと変わっていくだろう。プログラミングとは、物理的な機械を操る作業ではなく、純粋な論理とビジネスモデルをそのまま空間に展開する行為へと変貌を遂げる。サーバーを所有するという「重労働」を捨て去ったその先に、私たちは一体どのような新しい価値を描くことができるのだろうか。その答えは、安易な提案を退け、仕様書の冷徹な論理と実務の摩擦に向き合い続けるエンジニアの、静かなコードの中にしか存在しない。

YouTube

https://pages.awscloud.com/rs/112-TZM-766/images/20190402_AWSBlackbelt_AWSLambda%20Part1&2.pdf

日本のエンジニアに贈る、Lambdaの深淵。2019年のBlack Beltから読み解くサーバーレスの本質 ⚡️🛠️

イントロ

クラウドネイティブな開発において、AWS Lambdaはもはや空気や水のように当たり前のインフラとなった。しかし、その「当たり前」の裏側にある公式仕様と、現場でのシビアな実装の間には、常に深い川が流れている。本動画『AWS Black Belt Online Seminar AWS Lambda Part2』は、Lambdaの「使い方」に徹底的にフォーカスし、プログラミングモデル、VPCアクセス、同時実行数、環境変数、レイヤー、核心的なコンポーネントであるカスタムランタイムといった実践的な仕様を網羅した珠玉の解説である。スピーカーであるAWSの西谷氏が、ガラガラの声を絞り出しながら語るその内容は、単なる機能紹介に留まらない。分散システムにおけるエラーハンドリングの過酷さや、ネットワーク遅延という物理的な制約に対して、エンジニアがどう目的（Purpose）を定め、現状（Situation）を把握し、制約（Constraint）を乗り越えるべきかという、設計の本質を突きつけてくる。

動画解説（メタデータ）

動画タイトル（原文）: 【AWS Black Belt Online Seminar】 AWS Lambda Part2

動画タイトル（和訳）: 【AWS Black Belt オンラインセミナー】 AWS Lambda パート2

動画説明（原文）: This seminar deeply explains how to use AWS Lambda, covering programming models, VPC access, concurrency management, environment variables, versioning, layers, and custom runtimes for production workloads.

動画説明（和訳）: 本セミナーでは、本番ワークロード向けに、プログラミングモデル、VPCアクセス、同時実行数管理、環境変数、バージョニング、レイヤー、カスタムランタイムを含むAWS Lambdaの使い方を深く解説します。

チャンネル名: Amazon Web Services Japan 公式

動画公開日: 2019-04-19

動画解説（詳細）

セミナーはスピーカーの西谷氏による挨拶と、前週に開催されたパート1からの継続であることの紹介から始まります。西谷氏は喉の調子を悪くしているという個人的な状況に触れつつも、強い意志を持って1時間の講義を進めていくことを宣言します。アジェンダとしては、今回はLambdaの使い方にのみ集中し、今後パート3、パート4とシリーズが続いていくことが明かされます。

まず最初に、Lambda関数の基本として、サポートされている言語やカスタムランタイムの概念、メモリ設定がCPU能力と比例すること、最大タイムアウトが15分であることといった基本スペックのおさらいが行われます。続いてプログラミングモデルの解説へと移り、エントリーポイントとなるハンドラー、実行環境の情報を持つコンテキスト、CloudWatch Logsへのロギング、術語としての例外処理について順を追って説明が進みます。ここで重要な原則として、Lambdaはステートレスに設計されなければならず、ローカルへのファイル書き込みなどは一時的なものとして扱い、データの永続化にはS3やDynamoDBを用いるべきであるという点が強調されます。開発を支援する機能として、サンプルコード集である設計図（Blueprints）や、Cloud9をベースにしたコンソールエディタでのテスト実行、そして依存関係を含めてZIPやJARで固めるデプロイパッケージの作成方法が紹介され、その際にはファイルの読み取り権限がグローバルに適切に付与されている必要があるという実務的な注意点が述べられます。

次に、多くのエンジニアが直面するVPCアクセスの設定についての解説に入ります。RDSやElastiCacheへのセキュアな接続を実現するために、サブネットやセキュリティグループを指定する仕組みが説明されます。これは内部的にENI（Elastic Network Interface）を利用して実現されますが、設定直後からインターネットへのアクセスが不可になるためNATゲートウェイが必要になること、また初回アクセス時（コールドスタート時）にはENIの作成に伴って10秒から60秒程度の大きな遅延が発生するという、運用上極めて重要な制約が詳しく語られます。

続いて、同時実行数の管理へと話が進みます。アカウント単位の上限を関数ごとに割り当てることで、下流のデータベースや外部APIに対する流量制御が可能になるというメリットが示され、さらにトラブル時に処理を即座に停止させる「一発終了ボタン」としてのスロットリングボタンの使い方がコンソール画面とともに紹介されます。また、コードを変更せずに値を渡せる環境変数についても触れられ、KMSによる自動暗号化や、機密情報をデプロイ前に暗号化する暗号化ヘルパーの仕組み、4KBのサイズ制限が解説されます。

さらに、システムのライフサイクル管理に不可欠なバージョニングとエイリアスの機能が説明されます。特定のバージョンにポインタを割り当てるエイリアスを利用することで、本番環境のコードを安全に切り替えられるだけでなく、ルーティング設定を使って2%だけ新しいバージョンにトラフィックを流すといったカナリアデプロイの具体的な実装方法が示されます。その後、2018年末に発表された新しい機能として、共通コンポーネントを分離して最大5つまで適用できるAWS Lambda レイヤーが紹介され、非圧縮で250MBというサイズ制限を維持しつつもビジネスロジックに集中できるメリットが語られます。コスト配分やグループ化に役立つタグ付けの解説を経て、非同期実行時に合計3回の試行でも処理が失敗した場合にイベントを取りこぼさないためのデッドレターキュー（DLQ）の仕組みへと移り、SQSやSNSへの送信エラーを監視する重要性が指摘されます。

後半の大きなテーマとして、カスタムランタイムの解説が行われます。Runtime APIと呼ばれるHTTPベースのインターフェースを通じて、linux互換であればPHPやCOBOLといった任意の言語をLambda上で動作させられる仕組みが明かされます。この際、実行ファイルとして「bootstrap」を含める必要があり、その内部で初期化処理（環境変数の読み込みやスタティックな接続の作成）と、無限ループによるイベントの待ち受けおよび実行処理という2つのタスクを実装しなければならないという、内部構造のディープな仕様がコード例とともに解説されます。

最後にモニタリングとトラブルシューティングの章へと進み、CloudWatchにおける各種メトリクス、特に呼び出し回数や実行時間、エラー数、スロットリング数の意味が正しく定義されます。ここで、Lambdaの呼び出しは「最低1回（At least once）」を保証しているだけであり、複数回実行される可能性を考慮してアプリケーション側で冪等性を担保する必要があるという極めて重要な運用のポイントが語られます。KinesisやDynamoDBといったストリームベースの監視においては、処理遅延を示す「IteratorAge」の重要性とシャード分割によるスケールアウトが説明され、SQS連携においては、大量のメッセージによる他関数への影響を防ぐために同時実行数の制限が推奨されます。最終的に、分散トレーシングを行うAWS X-Rayによるボトルネック検出や、CloudTrailによる監査ログの記録、標準出力を利用したデバッグ方法がまとめられ、アプリケーション管理の自動化ツールについては次回のパート3に引き継がれる形でセミナーは締めくくられます。

技術解説

1. 【PSC起点】サーバーレスアーキテクチャの目的と、ステートレスの物理的制約

我々がAWS Lambdaを採用する最大の目的（Purpose）は、インフラのプロビジョニングや管理という非本質的な重労働から解放され、ビジネスロジックの記述に集中することにある。しかし、そこには「実行環境の完全な抽象化」という現状（Situation）と、それに伴う「ステートレス」という強力な制約（Constraint）が存在する。

動画内で西谷氏が「インフラストラクチャとの直接的な関連性がない」と静かに語った言葉は、サーバーレスの核心を突いている [10:44]。Lambda関数が呼び出されるたび、裏側では軽量な仮想環境が動的に立ち上がる。エンジニアがコードの中でローカルファイルシステム（当時は最大512MB制限の/tmp領域）にデータを書き込んだり、子プロセスを生成したりしても、それはそのリクエストの有効期間中、すなわち「一瞬の儚い命」に過ぎない。次回の実行で同じインフラが使われる保証はどこにもないのだ [11:06]。

深夜2時、冷え切ったデータセンターのエアコンの風と、サーバーが発する独特の焦げたような匂いを想像してほしい。かつて我々は、そこに佇む物理サーバーのハードディスクにログを刻み、メモリにセッションを泥臭く保持していた。しかしLambdaの世界では、その「サーバーの温もり」すら存在しない。すべてのデータは、呼び出しの境界を越えて永続化される必要がある。ゆえに、Amazon S3やAmazon DynamoDBといった外部のステートフルなストレージへの保存が、実務においては「一択」となるのだ [11:39]。メモリ容量を128MBから3008MB（当時の上限仕様）まで64MB刻みで調整すれば、それに比例してCPUパワーも動的にスケールする [10:44]。だが、どれほどパワーを上げようとも、ステートレスという物理法則からは逃れられない。この制約を理解することこそが、サーバーレス設計の本当のスタートラインである。

2. VPC接続における「10〜60秒の遅延」という過去の現実と、Hyperplaneへの進化

実務における最大の鬼門、それがLambdaからVPC（Virtual Private Cloud）内のリソース、例えばAmazon RDSやAmazon ElastiCacheへのアクセスである [17:38]。動画が公開された2019年当時、LambdaをVPCに接続することは、アーキテクチャ上の巨大なトレードオフを意味していた。なぜなら、コールドスタート時に「10秒から60秒」という、Webアプリケーションとしては致命的な遅延が発生していたからだ [20:47]。

この遅延の正体は、VPC内に動的に作成されるENI（Elastic Network Interface）のプロビジョニング時間である [18:12]。Lambdaの実行基盤がIPアドレスをDHCPで取得し、ネットワークカードを仮想的に突き刺す。この物理的なネットワーク構築の重みが、関数の起動を著しく阻害していた。動画内で西谷氏が「Availability Zoneごとに1つ以上のサブネットを指定することがおススメ」と語った背景には、このENIの枯渇や作成遅延によるリクエストの失敗を少しでも防ぎたいという、現場の悲痛な防衛策があった [18:05]。

その後、AWSは「AWS Hyperplane」を用いたネットワークアーキテクチャの大幅な刷新を断行した。現在では、ENIはLambda関数の作成・更新時にあらかじめプロビジョニングされ、実行環境間で共有される仕組みへと進化したため、この10〜60秒という冷酷な遅延は過去のものとなった。しかし、5年、10年が経過した今でも、当時の資料を読み解く意義は大きい。なぜなら、「コンピュートの起動」と「ネットワークの結合」という本質的なコストの分離が、どのようにクラウドの歴史を変えてきたかという設計思想の変遷を、エンジニアとして五感で理解できるからだ。今なお、十分なIPアドレスを持つサブネットの設計やセキュリティグループの制御が極めて重要であるという現実は、何一つ変わっていない。

3. Runtime APIの登場が変えた、コンピュート抽象化の本質

2018年末のAWS re:Inventで発表され、この動画でも深く掘り下げられている「カスタムランタイム」と「Runtime API」の登場は、コンピュートの民主化における特異点であった [40:48]。それまでLambdaは、AWSが公式に用意したNode.jsやPython、Javaといった特定の言語環境という「檻」の中でのみ踊ることを許されていた。

しかし、Runtime APIというHTTPベースのシンプルなインターフェースが定義された瞬間、その檻は完全に破壊された [41:11]。Linux互換のバイナリさえ動けば、C++、PHP、さらにはCOBOLにいたるまで、あらゆる言語がサーバーレスの恩恵を受けられるようになった。動画内で紹介されているシェルスクリプトによるカスタムランタイムのコード例（bootstrap）は、実に見事である [46:39]。環境変数を読み込み、無限のwhileループの中でRuntime APIの/nextエンドポイントを叩いてイベントを待ち受ける。イベントが来たらビジネスロジック（ハンドラー）を実行し、その結果を/responseにPOSTする [47:40]。この、極限まで削ぎ落とされたメッセージングの構造こそが、Lambdaの正体なのだ。

余談として語られた、新言語Rubyのサポートが実はこのRuntime APIを使ってサービスチーム自身によって実装されたというエピソードは、このアーキテクチャの美しさを物語っている [41:48]。この仕様は、のちにLambdaがコンテナイメージ（OCIイメージ）のサポートへと進化するための揺るぎない布石となった。実務においてカスタムランタイムを自作することは、管理対象（ランタイム自体の脆弱性対応やバグ修正）を増やすというリスクを伴うため、慎重であるべきだ [49:34]。不具合があればすべての関数に波及するという重い現実がある [50:00]。しかし、この仕組みを理解することは、コンピュートがどう抽象化され、実行されているかという、OSレイヤーの手触りを感じるために不可欠な知識である。

4. 「最低1回（At-Least-Once）」の衝撃：実務における冪等性実装の一択という真実

分散システムを設計する上で、絶対に目を背けてはならない真実がある。それが、Lambdaが保証するメッセージングの到達クオリティが「最低1回（At-Least-Once）」であるという事実だ [53:27]。動画の終盤、モニタリングのセクションで西谷氏が発した「最低1回しか実行しないことではありません」という警告は、すべてのサーバーレスエンジニアの背筋を凍らせる [53:33]。

ネットワークの瞬断、リクエストのタイムアウト、呼び出し側の再試行。さまざまな要因により、同じイベントデータを持ったLambda関数が、同時に、あるいは時間差で「2回以上」実行される現実に、我々は常に晒されている。もし、その関数がユーザーの決済処理や、データベースのインクリメント処理だったとしたらどうなるか。二重決済という、サービス終了に直結する大障害が、深夜2時の暗闇の中で音もなく発生することになる。

これを防ぐ手段は、インフラ側での「監視・検知」ではなく、アプリケーション側での「冪等性（Idempotency）」の担保、これ一択である [53:52]。一意なリクエストID（べき等キー）をイベントから抽出し、DynamoDBなどの高速な分散ロック・分散KVSに記録する。すでに処理済みのIDであれば、実際の処理は行わずに前回のレスポンスを返す。この泥臭くも強固な実装を組み込むことなしに、Lambdaを本番環境で動かす資格はない。どれほど便利なCloudWatchメトリクス（InvocationsやErrors）を眺めていても、この論理的な二重実行を防ぐことはできないのだ [50:41]。仕様を盲信するな、現場の実装で語れ。それが分散システムの鉄則である。

5. 下流システム（RDBMS）を保護する流量制御と、予約された同時実行数の設計思想

Lambdaの美点の一つは、圧倒的な「自動スケール」である。イベントの波が押し寄せれば、Lambdaは数千、数万の同時実行数へと一瞬で膨れ上がる。しかし、この「無限の暴力」とも言えるスケーラビリティは、往々にして下流（Downstream）のシステムを物理的に破壊する。

典型的な例が、リレーショナルデータベース（RDBMS）への接続だ。MySQLやPostgreSQLといった伝統的なRDBMSは、コネクション数に厳密な上限を持つ。Lambdaが数千個立ち上がり、それぞれがVPCを経由してデータベースにコネクションを要求した瞬間、データベースのCPUは100%に張り付き、システム全体が沈没する。サーバーの悲鳴が聞こえるような、地獄の絵図である。

これを制御するために、動画内で詳しく解説されている「予約された同時実行数（Reserved Concurrency）」の設計が不可欠となる [21:19]。アカウント全体の上限（デフォルトで1000など）から、特定の関数に対して「同時実行数は最大100まで」と枠を予約・制限する [21:33]。これにより、下流のデータベースのコネクションプールを守るという「流量制御」が実現する [22:10]。さらに、予期せぬ無限ループやイベントの暴走が発生した際、コンソール上に用意された「スロットリングボタン」を押し、同時実行数を即座に「0」に固定して関数を一発終了させるという運用ノウハウは、実務における強力なセーフティネットである [23:07]。

のちにAWSは、このコネクション問題を解決するためにAmazon RDS Proxyというマネージドなプロキシサービスをリリースすることになるが、コアとなる思想は全く同じだ。コンピュートが無限にスケールする時代だからこそ、エンジニアは「あえてブレーキをかける」という制約の設計を、自らの意志で行わなければならない。

YouTube

https://pages.awscloud.com/rs/112-TZM-766/images/20190402_AWSBlackbelt_AWSLambda%20Part1&2.pdf

SNSコメント

Master AWS Lambda with this Black Belt seminar. Cover execution models, VPC access, custom runtimes via Runtime API, and concurrency controls for building resilient serverless architectures.

ハッシュタグ

#BeyondTheNext #TEC #創作大 #AWS #Lambda #Serverless #BlackBelt #Architecture #CloudComputing

SNSコメント

Dive deep into AWS Lambda basics with this classic AWS Black Belt Seminar. Learn about serverless architectural patterns, execution environments, event source behaviors, and crucial production metrics like concurrency limits and cold start lifecycles. Perfect for robust backend implementations.

ハッシュタグ

#BeyondTheNext #TEC #創作大賞2026 #オールカテゴリ部門 #AWSLambda #Serverless #AWSBlackBelt #システム設計 #インフラエンジニア