AWS学習11日目:API Gateway × Lambda × DynamoDB
今日のテーマ
AWS学習11日目は、外部からAWS内部の処理を呼び出す入口となる API Gateway を学びました。
10日目までは、EventBridgeをきっかけにLambdaを実行する自動処理を作っていました。
今回は、外部から送られたrequestをAPI Gatewayで受け取り、LambdaからDynamoDBのテーブルをScanし、その結果をresponseとして返す構成を作りました。
今日できたこと
- API Gatewayの基本単語を学習した
- API Gateway・Lambda・DynamoDBの連携を体験した
今日のハンズオン
今回は、これまで学んだLambdaとDynamoDBを、API Gatewayを使って外部から呼び出せる構成にしました。
基本単語学習
今日覚えた用語は次の10個です。
| 用語 | 現時点での理解 |
|---|---|
| API | 外部のシステムから内部の機能やデータを利用するための接続方法 |
| API Gateway | APIの入口としてrequestを受け取り、内部の処理へ渡すサービス |
| endpoint | APIへrequestを送るためのURL |
| HTTP method | APIで実行したい処理の種類 |
| route | HTTP methodとパスを組み合わせ、呼び出す処理を決める設定 |
| integration | API GatewayとLambdaなど、システム同士の連携 |
| request | APIへ送る要求 |
| response | APIから返される応答 |
| status code | API通信の成功・失敗などを表す番号 |
| CORS | ブラウザから別のオリジンにあるAPIを呼び出す際のアクセス制御 |
APIとは何か
APIは、外部のアプリケーションやシステムから、内部にある機能やデータを利用するための接続方法です。
現時点での理解
APIは、外部のシステムから内部の機能やデータへアクセスするための窓口と通信方法。
API Gatewayとは何か
API Gatewayは、AWS上でAPIの入口を作るサービスです。
外部から送られたrequestを受け取り、Lambdaなどの内部処理へ渡します。
処理結果は、API Gatewayを通じてresponseとして呼び出し元へ返されます。
自分の言葉で説明
API Gatewayは、APIの入口。
API Gateway自体がDynamoDBのデータを処理するのではなく、requestをLambdaなどへ渡す役割を持ちます。
endpointとは何か
endpointは、APIへrequestを送るためのURLです。
例えば、次のようなURLがendpointになります。
https://example.execute-api.ap-northeast-1.amazonaws.com/demoStage/
自分の言葉で説明
endpointは、APIの入口となるURL。
利用者やアプリケーションは、このendpointにrequestを送ります。
HTTP methodとは何か
HTTP methodは、APIに対してどのような処理を要求するかを表します。
代表的なmethodは次のとおりです。
| HTTP method | 主な用途 |
|---|---|
| GET | データを取得する |
| POST | データを作成する |
| PUT | データを更新する |
| DELETE | データを削除する |
今回の構成では、DynamoDBのデータを取得するため、GETが合う処理です。
routeとは何か
routeは、HTTP methodとパスを組み合わせて、どの処理を呼び出すかを決める設定です。
例えば、タスクを取得するAPIなら次のように設計できます。
GET /tasks
この場合、
-
GET:データを取得する -
/tasks:処理対象はタスク
という意味になります。
自分の言葉で説明
routeは、APIの処理を指定するもの。
より正確には、HTTP methodとパスを使って、どの処理へrequestを渡すか決める設定 と理解しました。
requestとresponse
API通信は、requestとresponseの組み合わせで成り立ちます。
request
requestは、APIへ送る要求です。
今回であれば、DynamoDBのデータを取得する要求をAPI Gatewayへ送ります。
response
responseは、requestに対してAPIから返される応答です。
今回は、DynamoDBのScan結果をresponseとして返しました。
| 用語 | 今回の処理 |
|---|---|
| request | DynamoDBのデータを取得してほしい |
| response | Scanで取得したitemの一覧 |
status codeとは何か
status codeは、API通信の結果を番号で表したものです。
代表的なstatus codeは次のとおりです。
| Status code | 意味 |
|---|---|
| 200 | 正常に処理できた |
| 400 | requestの内容に問題がある |
| 403 | APIを利用する権限がない |
| 404 | 対象が見つからない |
| 500 | サーバー側の処理でエラーが発生した |
CORSとは何か
CORSは、ブラウザ上のWeb画面から、異なるオリジンにあるAPIを呼び出す際に関係するアクセス制御です。
例えば、LifeOSのWeb画面とAPI Gatewayのendpointが異なるドメインにある場合、ブラウザ側でCORSの設定が必要になることがあります。
現時点での理解
CORSは、フロントエンドからAPIを呼び出す際に関係する接続制御。
ハンズオン
今日作った構成
今回作ったのは、API GatewayからLambdaを呼び出し、DynamoDBのテーブル全体をScanして結果を返す構成です。
各サービスの役割
| サービス | 今回の役割 |
|---|---|
| API Gateway | 外部からrequestを受け取る |
| Lambda | DynamoDBをScanし、responseを作る |
| DynamoDB | データを保存する |
| IAM execution role | LambdaへDynamoDBの操作権限を与える |
| CloudWatch Logs | Lambdaの処理内容を記録する |
API Gateway側で行ったこと
- REST APIを用意した
- endpointを確認した
- HTTP methodを設定した
- Lambdaとのintegrationを設定した
Lambda側で行ったこと
- API Gatewayからrequestを受け取った
- DynamoDBのテーブルのScan結果をresponseとして返した
- CloudWatch Logsへログを出力した
CloudWatch Logsで確認したこと
CloudWatch Logsでは、Lambdaがrequestを受け取り、DynamoDBへアクセスしている流れを確認しました。
確認できたこと
- API GatewayからLambdaが呼び出された
- Lambdaがrequestを受け取った
- LambdaがDynamoDBへScanを実行した
- DynamoDBからデータを取得した
- Lambdaがresponseを返した
つまずいたこと
今回は特に大きなつまずきはありませんでした。
LifeOSではどう使えそうか
API Gatewayは、LifeOSのWeb画面やスマートフォンからAWS側の処理を呼び出す入口として使えそうです。
タスク一覧を取得する例
LifeOSで考えられるAPI
| Method・Path | 処理 |
|---|---|
| GET /tasks | タスク一覧を取得 |
| GET /tasks/{taskId} | 特定のタスクを取得 |
| POST /tasks | 新しいタスクを追加 |
| PUT /tasks/{taskId} | タスクを更新 |
| DELETE /tasks/{taskId} | タスクを削除 |
資格学習として覚えておきたいこと
Cloud Practitionerだけでなく、SAAやDeveloper Associateに向けても、API GatewayとLambdaの組み合わせは重要そうです。
| ポイント | 内容 |
|---|---|
| API | 外部から内部の機能を利用する接続方法 |
| API Gateway | APIの作成・公開・管理を行う入口 |
| endpoint | APIを呼び出すURL |
| HTTP method | GET、POSTなど処理の種類 |
| route | methodとpathで処理先を決める |
| integration | API GatewayとLambdaなどの連携 |
| request | APIへ送る要求 |
| response | APIから返される応答 |
| status code | API通信の結果 |
| CORS | ブラウザからAPIを呼ぶ際のアクセス制御 |
特に重要そうな比較
| 比較 | 覚えておきたいこと |
|---|---|
| API GatewayとLambda | API Gatewayは入口、Lambdaは処理 |
| requestとresponse | 要求と応答 |
| endpointとroute | endpointは接続先URL、routeは処理の振り分け |
| GETとPOST | 取得と作成 |
| ScanとQuery | 全件走査とキー指定の効率的な取得 |
| API GatewayとEventBridge | 外部requestによる起動と、イベント・スケジュールによる起動 |
現時点でまだ曖昧なこと
- REST APIとHTTP APIの違い
- API Gatewayのstageとdeploy
- path parameterとquery string parameter
- request bodyの扱い方
- status codeの正しい返し方
- CORSの具体的な設定方法
- CognitoやAuthorizerによる認証・認可
今日できるようになったこと
- APIが外部から内部処理を利用する接続方法だと説明できる
- API GatewayがAPIの入口だと説明できる
- endpointがAPIを呼び出すURLだと説明できる
- API GatewayからLambdaを呼び出せる
- LambdaからDynamoDBをScanできる
- DynamoDBの取得結果をresponseとして返せる
- CloudWatch Logsで処理の流れを確認できる
次回
次回は、Cognitoと、今日作ったAPIを「動けばよい」状態から、成功・失敗を正しく返せるAPIへ整理します。
Discussion