0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@bk2

EC2経験者がAPI Gateway + Lambdaの最小構成を触ってみた

0
Posted at

EC2経験者がAPI Gateway + Lambdaの最小構成を触ってみた

はじめに

こんにちはニシグチです。AWSのサービスは業務でも少し触ったことがあります。

ただ、今まではVPC作成やEC2へWebサーバー・DBサーバーを構築するような、比較的EC2中心の構成が多く、
サーバーレス系のサービスはまだ十分に触れられていませんでした。なので、マネージドサービスやサーバーレス系にはまだ手を出せてないなと思い、今回アウトプットも兼ねて、サーバーレス構成を触ってみようと思います。

今まで触ったAWSのサービスは

  • VPC
  • ACM
  • Route 53
  • ELB(ALB)
  • EC2(EBS)
  • S3
  • CloudWatch
  • Systems Manager
  • EventBridge/SNS
  • CloudFormation
  • AWS Backup
  • Amplify

EC2のWebサーバーの状況管理やログ監査、通知したりするのに使ったサービスなどが今は多いですかねぇ。
勿論、SAAの資格取得するうえで上記以外のサービスも内容やクラウドを活用するうえでの設計運用知識については知っているのですが、知っていると使いこなせるは雲泥の差なんでね。

今回は、API Gateway と Lambda を使って、
HTTPリクエストからLambdaを呼び出す最小構成を触りながら理解を深めていこうと思います。

学習記録も兼ねて書いていこうと思うよ。それじゃあ始め！

今回作るもの

今回はハンズオンとして、まずは API Gateway → Lambda の最小構成を理解することを目的に進めます。

そのため、認証やネットワーク制御、VPC内部への閉じ込みといった構成を今回は考慮せず、
まずは自分のPCからAPIを呼び出してLambdaが実行され、
最終的に、自分のPCからAPIエンドポイントへアクセスし、API Gateway経由でLambdaが実行されるところまでをゴールにします。

最初から複雑な構成を意識するより、まずはサービス間の役割やデータの流れを理解することを優先しました。

使用サービス

  • API Gateway
    クライアントからのHTTPリクエストを受け取り、Lambdaを呼び出すための入口として使用する

  • Lambda
    今回のメイン処理を担当する。API Gatewayから呼び出され、リクエストに対してレスポンスを返す

  • CloudWatch Logs
    Lambdaの実行ログやエラー内容を確認するために使用する。処理の確認やデバッグに必要

  • IAM
    LambdaがCloudWatch Logsへログ出力するための権限などを設定する

Step1 Lambda単体の動作確認

まずはAPI Gatewayと接続する前に、Lambda単体で正常に動作することを確認します。

① Lambda関数作成

AWSコンソールからLambdaを開き、「関数の作成」をクリックします。

「一から作成」を選択し、以下を設定しました。

  • 関数名：sample-serverless-api
  • ランタイム：Python3.13

image.png

今回の実行ロールはデフォルト設定のままとしました。
CloudWatch Logsへログ出力するための基本権限が含まれているためです。

作成後

コードを以下のように変更します。

lambda_function.py
import json

def lambda_handler(event, context):
    print("event:", json.dumps(event, ensure_ascii=False))

    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "Hello from Lambda!"
        })
    }

ここで少し event と return の役割を整理しておきます。

私がいつも使っているDjangoなどでは request.method や request.body のように、フレームワークが扱いやすい形でリクエスト情報を渡してくれます。

一方でLambdaでは、呼び出し元から渡された入力情報が event に入ります。
今回はまだAPI Gatewayとは接続していないため、まずはLambdaのテストイベントを使って単体で動作確認します。

後ほどAPI Gatewayと接続すると、HTTPメソッド、パス、ヘッダー、bodyなどのリクエスト情報が event へ含まれるようになります。

return で返却した内容は、Lambdaの実行結果として返されます。
API Gatewayと接続した後は、この戻り値がHTTPレスポンスとしてクライアントへ返るイメージです。

今回は動作確認用として、body に Hello from Lambda! を返却するシンプルな構成としました。

なお、print() で出力した内容はLambdaの戻り値には含まれず、CloudWatch Logs上で確認できます。

image.png

② Lambda単体テスト

作成したLambda関数を、まずはAPI Gatewayと接続せずに単体でテストします。

テストイベントには以下のJSONを指定しました。

{
  "test": "hello"
}

image.png
テストを実行すると、statusCode: 200 と Hello from Lambda! を含むレスポンスが返却されました。
これにより、Lambda関数が正常に実行され、return の内容が実行結果として返ることを確認できました。

image.png
CloudWatch Logsを確認すると、テストイベントとして渡した {"test": "hello"} が event として出力されていました。

これにより、Lambdaを呼び出した側から渡された入力情報が event に入ることを確認できました。

ここまでで Step1: Lambda単体の動作確認 は完了でOKです。

理解としては、今この状態です。

event  = 呼び出し元からLambdaに渡される入力
return = Lambdaの実行結果
print  = CloudWatch Logsに出るログ

次は Step2: API GatewayからLambdaを呼び出す に進めます。

Step2 API GatewayからLambdaを呼び出す

Step1では、Lambdaのテストイベントを使って単体で動作確認しました。

次に、API Gatewayを使ってHTTPリクエストからLambdaを呼び出せるようにします。

ここからは、Lambdaに渡される event の中身も、テストイベントではなくAPI Gateway経由のHTTPリクエスト情報になります。

① API Gatewayトリガーを追加する

Lambda関数の画面から「トリガーを追加」をクリックします。

今回は、HTTPリクエストを受けてLambdaを実行したいので、トリガーとしてAPI Gatewayを追加します。
image.png
トリガーは以下の設定で追加しました。

  • API：新規APIを作成
  • APIタイプ：HTTP API
  • セキュリティ：オープン

image.png
注意点として、セキュリティは今回学習用のためにオープンとしていますが、
オープンの場合、URLを知っている人であれば誰でもAPIを呼び出せる状態になります。

今回は学習用の一時的な構成として扱い、個人情報や機密情報は扱いません。

また、ハンズオン後は不要なリソースを削除します。
本番環境では、認証・認可、WAF、スロットリング、IAM権限の最小化などを検討する必要があります。

② APIエンドポイントからLambdaを呼び出す

LambdaにAPI Gatewayのトリガーを追加すると、APIエンドポイントが発行されます。
APIエンドポイントのURLをクリックして先程のLambda関数が呼び出されるか確認します。
image.png

APIエンドポイントへアクセスすると、Lambdaで返却している Hello from Lambda! が表示されました。
これにより、API Gateway経由でLambdaを呼び出せることを確認できました。
image.png

まとめ

今回は、API GatewayからLambdaを呼び出す最小構成を触ってみました。

普段Djangoなどのフレームワークを使っていますが、リクエストやレスポンスの扱いはフレームワーク側が吸収してくれます。
一方で、Lambdaでは呼び出し元から渡された情報が event に入り、return の内容が実行結果として返ることを確認できました。

また、API Gatewayをトリガーとして追加することで、HTTPリクエストからLambdaを実行できることも確認できました。

今回は本当に初歩的な構成ですが、サーバーレス構成に触れる最初の一歩として、
API Gateway、Lambda、CloudWatch Logs、IAMの役割を整理できたのは良かったです。
(本当はもうちょっとボリューム感のある記事にしたかったんだけど、記事書き切ることをまずはやってみたかったので簡単な内容にしました。)

以前、S3に画像をアップロードしたらLambdaを呼び出す構成も試したことがあり、イベント駆動の考え方を体感するきっかけになりました。

次回は、Lambdaと他のAWSサービスを組み合わせて、もう少しアプリケーションらしい構成にも触れてみたいと思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?