06
第 6 章

BFF と API Gateway の設計判断

この章で学ぶこと
1 API Gateway とは何か、どのような役割を担うか
2 共通処理の重複という課題と API Gateway による解決
3 Gateway + BFF 二層構成の動作確認とコード読解
4 構成の使い分け基準
解説

API Gateway とは

システム全体の共通の入口
すべてのクライアントからの API リクエストを最初に受け付けるサーバー
バックエンド API への中継
受け付けたリクエストを内部の適切なサービスへ転送する
共通処理の置き場所
すべてのリクエストが必ず通過するため、共通の処理を一箇所にまとめられる
位置づけ
課題
設計判断
実演
コード読解
まとめ
図解

BFF アーキテクチャの全体像

API Gateway が共通の入口として全リクエストを受け付け、BFF がフロントエンド固有の関心事を担う二層構成

位置づけ
課題
設計判断
実演
コード読解
まとめ
解説

API Gateway の役割

ルーティング
リクエストの URL パスに基づいて適切なサービスに振り分ける
レート制限
単位時間あたりのリクエスト数に上限を設け、バックエンド APIを過負荷から保護する
認証・認可とロギング
不正なリクエストをサービスに到達させず、全リクエストを一箇所で記録する
位置づけ
課題
設計判断
実演
コード読解
まとめ
図解

共通処理の重複（API Gateway がない場合）

各 BFF が認証検証・ルーティング・レート制限を個別に実装し、共通処理が重複している

位置づけ
課題
設計判断
実演
コード読解
まとめ
解説

API Gateway による解決

共通処理は Gateway 層に集約
各 BFF に重複していた認証検証・ルーティング・レート制限・ロギングを API Gateway に移す
フロントエンド固有の処理は BFF に残す
集約・整形・セッション管理・縮退は各フロントエンドの要件に合わせる
位置づけ
課題
設計判断
実演
コード読解
まとめ
図解

Gateway と BFF の責務分離

Gateway が横断的関心事、各 BFF がフロントエンド固有の関心事を担う

位置づけ
課題
設計判断
実演
コード読解
まとめ
解説

API Gateway を実現するミドルウェア

リバースプロキシ
nginx・HAProxy。ルーティングやレート制限などの基本機能を設定ファイルで定義する
API Gateway 専用製品
Kong・Apache APISIX。認証プラグインなど API 管理の豊富な機能を備える
クラウドマネージドサービス
Amazon API Gateway・Azure API Management。運用をクラウドに任せられる
本章では nginx を採用する
位置づけ
課題
設計判断
実演
コード読解
まとめ
コード

nginx の設定ファイル

Gateway のルーティングとレート制限を nginx の設定ファイルで定義する

nginx/nginx.conf
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s; server {    listen 80;     location /api/ {        limit_req zone=api_limit burst=5 nodelay;        limit_req_status 429;        proxy_pass http://bff:3000;    }}
位置づけ
課題
設計判断
実演
コード読解
まとめ
解説

limit_req_zone — レート制限のルール定義

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
$binary_remote_addr
クライアントの IP アドレスごとにリクエスト数を記録する
rate=10r/s
1 秒あたり 10 リクエストを基本レートとする
zone=api_limit:10m
IP アドレスごとの記録を保持する共有メモリ領域（10MB）
位置づけ
課題
設計判断
実演
コード読解
まとめ
解説

location /api/ — ルーティングとレート制限の適用

limit_req zone=api_limit burst=5 nodelay;proxy_pass http://bff:3000;
burst=5
基本レートの超過を瞬間的に 5 リクエスト分まで許容する
proxy_pass
リクエストを BFF（Docker ネットワーク内のホスト名 bff）に転送する
位置づけ
課題
設計判断
実演
コード読解
まとめ
実演

コンテナの起動

目的6 章のサンプル環境を起動し、5 つのコンテナが正常に動作していることを確認する
実行する
コマンド
$ cd ch06-gateway-bff$ docker compose up -d$ curl http://localhost:8080/health
※ Windows（PowerShell）では curl を curl.exe に読み替えてください
確認する
ポイント{"status":"ok"} が返ること
位置づけ
課題
設計判断
実演
コード読解
まとめ
図解

コンテナの構成

API Gateway（nginx）を経由して BFF が 3 つのバックエンド APIを集約する構成

位置づけ
課題
設計判断
実演
コード読解
まとめ
実演

Gateway 経由のリクエスト

目的Gateway 経由で BFF のダッシュボードエンドポイントにリクエストを送り、集約レスポンスを確認する
実行する
コマンド
$ curl http://localhost:8080/api/dashboard
※ Windows（PowerShell）では curl を curl.exe に読み替えてください
確認する
ポイントuser・orders・notifications の 3 つのデータが 1 つのレスポンスにまとまっていること
位置づけ
課題
設計判断
実演
コード読解
まとめ
実演

Gateway のレート制限の実演

目的Gateway 経由で 20 回連続リクエストを送り、レート制限により HTTP 429 が返ることを確認する
実行する
コマンド
bash / zsh
$ for i in $(seq 1 20); do    echo "Request $i: $(curl -s -o /dev/null      -w '%{http_code}' http://localhost:8080/api/dashboard)";  done
PowerShell
$ 1..20 | ForEach-Object {    $code = curl.exe -s -o NUL -w '%{http_code}'      http://localhost:8080/api/dashboard;    Write-Host "Request ${_}: $code"  }
確認する
ポイント途中から HTTP 429（Too Many Requests）が返ること
位置づけ
課題
設計判断
実演
コード読解
まとめ
解説

規模と Gateway 導入のメリット

フロントエンドが増えるほどメリットが大きい
横断的関心事の重複が増えるため、Gateway への集約効果が高まる
アプリケーション規模が大きくなるほどメリットが大きい
サービス数・チーム数が増えると、共通処理の一元管理による変更コスト削減の恩恵が大きくなる
フロントエンド 1 種類・小規模なら BFF のみで十分なケースが多い
位置づけ
課題
設計判断
実演
コード読解
まとめ
解説

責務分離とコストのトレードオフ

メリット：インフラ層とアプリケーション層の責務分離
ルーティング・レート制限の変更が BFF のコードに影響せず、BFF の集約ロジックの変更が Gateway に影響しない
コスト：インフラの増加
Gateway サーバーの構築・運用・監視が追加で必要になる
フロントエンドが 1 種類でも責務分離のために Gateway を導入する判断はあり得る
位置づけ
課題
設計判断
実演
コード読解
まとめ
まとめ

この章のまとめ

✓API Gateway はすべてのリクエストを受け付けるシステム全体の共通の入口である
✓横断的関心事（認証検証・ルーティング・レート制限・ロギング）は API Gateway に集約する
✓フロントエンド固有の関心事（集約・整形・セッション管理・縮退）は各 BFF に分離する
✓nginx の設定ファイルでルーティングとレート制限を定義し、API Gateway として機能させた
✓Gateway と BFF の二層構成はインフラ層とアプリケーション層の責務分離にもなる
✓構成の選択はクライアント数・横断的関心事の一元管理・責務分離の要否で判断する
次章: BFF のアンチパターン
位置づけ
課題
設計判断
実演
コード読解
まとめ