具体的なタイトルと、記事冒頭100〜150文字で「誰向けか」「解決できること」を明示する。
はじめに
現在、業務でAWSを扱う可能性があるため、キャッチアップを進めています。
ただし、現時点ではまだ実際に手を動かして構築した段階には至っておらず、
主にドキュメントや資料ベースで理解を進めている状態です。
※実際に構築はしていないため、ドキュメントベースでの理解整理になります。
本記事は、AWSを学び始めたばかりで、DynamoDB / Lambda / API Gatewayの役割や関係性がイメージできていない方向けの記事です。
3つのサービスについて、初学者の視点で「それぞれの役割」と「どのように連携するのか」を整理します。
サーバーレス構成の全体像をざっくり理解できることを目指します。
全体像の理解
まず、3つのサービスの関係性をこう捉えました。
アクセス → API Gateway → Lambda → DynamoDB
本来であれば、サーバーを用意し、その中でリクエスト受付・処理・データ保存までを一括で担う必要があります。
一方でこの構成では、
- リクエスト受付：API Gateway
- 処理：Lambda
- データ保存：DynamoDB
のように、それぞれの役割がAWS上の別サービスに分割されています。
このことから、サーバーという単一の実行環境を用意しなくてもAPIを構築できる、「サーバーを持たずにAPIが作れる」構成 と理解しました。
各サービスの理解（自分なり）
API Gateway
HTTPリクエストの入り口です。
理解としては、
- ルーティング担当
- Lambdaに処理を渡す役割
また、
- 認証
- レート制限
なども担える点から、
API Gatewayは、マンションのエントランスにいる受付のような役割だと認識しました。
住人宛の来訪者が来た際に、
- 誰へ会いに来たか確認する（ルーティング）
- 入館可否を判断する（認証）
- 一度に人が押し寄せすぎていないか制御する（レート制限）
などを担当し、問題なければ各部屋（Lambda）へ案内します。
Lambda
関数単位で処理を書くサービスです。
上述の例を踏まえると、Lambdaは、マンションの各部屋にいる住人のような役割だと理解しました。
エントランスの受付（API Gateway）から来訪者が案内されてきた際に、
- 用件に応じて対応する（処理を実行する）
- 必要に応じて管理室の情報（DynamoDB）を参照する
- 対応結果を受付に返す（レスポンス）
といった 実対応 を担います。
また、この住人は普段から常に待機しているわけではなく、呼び出されたときにだけ対応する点も特徴です。
ただ、Lambdaは非常に便利な一方で、「スケーラブルであること」を前提としているため、いくつかの制約があります。
- 状態を持たない
- 実行時間に制限がある
- 初回実行時に遅延が発生する
- 同時実行数に上限がある
- ローカルファイルの扱いに制限がある
これらはすべて、「必要なときだけ起動し、スケールする」という仕組みを成立させるための制約だと理解しました。
そのため、状態を保持したい場合や長時間の処理が必要な場合は、他のサービスと組み合わせて設計する必要があると言えそうです。
DynamoDB
NoSQLデータベースです。
上述の例を踏まえると、DynamoDBは、マンションの管理室にある「住民台帳や記録を保管する場所」のような役割だと理解しました。
住人（Lambda）が対応を行う際に、
- 住民情報を確認する
- 過去の記録を参照する
- 新しい情報を書き込む
といった形で利用されます。
また、この管理室の記録は、
- 必要な情報にすぐアクセスできるよう整理されている
- 大量の情報でもスムーズに扱える
といった特徴があると認識しました。
一方で、
- 複数の台帳を横断して確認する（JOINのような操作）
- 後から柔軟に検索条件を変える
といった使い方はあまり得意でなく、
「どの情報を、どのように取り出すか」をあらかじめ考えて設計する必要がある
と理解しました。
そのため、RDBのように後から柔軟にデータを結合して使うというよりも、「想定する利用方法に合わせてデータを持つ」設計が重要だと感じました。
今後、設計を行う機会があれば、意識した設計を心がけます。
現時点での理解まとめ
3つの役割を整理すると：
| サービス | 自分の理解 |
|---|---|
| API Gateway | 入口 |
| Lambda | 処理 |
| DynamoDB | データ |
かなり単純化すると、
「役割分担されたAPI構成」
と捉えています。
また、それぞれの役割が分離されていることで、
- 必要な部分だけをスケールさせられる
- サーバー全体を管理する必要がない
- 各サービスに責務が分かれているため設計しやすい
といったメリットがある構成だと理解しました。
おわりに
今回はあくまで「理解整理」の段階でした。
ただ、この段階で
- 役割の整理
- 苦手そうなポイントの把握
ができたのは良かったと感じています。
本記事が、AWS初学者の方にとって「各サービスの役割や関係性をざっくりつかむ」きっかけになれば嬉しいです。
今後は、実際に動くものを触りつつ、ドキュメントの読み込みや研修を踏まえて理解を深めていきます。
本記事が参考になった方は、いいねしていただけると励みになります。