最新のアプリケーションの API ゲートウェイ パターンとベスト プラクティス

API ゲートウェイは、全企業トラフィックの平均 83% を処理し、クライアント アプリケーションの単一のエントリ ポイントとして機能します。 適切に設計された API ゲートウェイは、クライアント/サーバー通信を簡素化し、セキュリティ ポリシーを適用し、すべてのサービスにわたる可観測性を提供します。設計が不十分だとボトルネックや単一障害点になります。

このガイドでは、Web アプリケーション、ERP システム、および e コマース プラットフォームの API ゲートウェイ アーキテクチャ パターン、テクノロジーの選択、実装のベスト プラクティスについて説明します。

重要なポイント

• API ゲートウェイは、横断的な問題 (認証、レート制限、ロギング) を一元化し、サービス間の重複を排除します。
• ゲートウェイ レベルでのレート制限により、バックエンド サービスをトラフィックの急増や悪用から保護します
• サーキット ブレーカー パターンにより、ダウンストリーム サービスが正常でない場合の連鎖的な障害を防止します
• ゲートウェイを介した API のバージョン管理により、API サーフェスの下位互換性のある進化が可能になります

---

コアゲートウェイパターン

パターン 1: リクエストのルーティング

ゲートウェイは、URL パス、ヘッダー、またはその他の要求属性に基づいて、要求を適切なバックエンド サービスにルーティングします。

# Nginx as API gateway
upstream api_service {
    server api-1:3001;
    server api-2:3001;
}

upstream auth_service {
    server auth:9000;
}

upstream web_service {
    server web:3000;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    location /api/v1/ {
        proxy_pass http://api_service;
    }

    location /auth/ {
        proxy_pass http://auth_service;
    }

    location / {
        proxy_pass http://web_service;
    }
}

パターン 2: 認証と認可

すべてのサービスに認証を実装することを避けるために、ゲートウェイでの認証を一元化します。

// NestJS middleware for JWT validation at the gateway level
@Injectable()
export class GatewayAuthMiddleware implements NestMiddleware {
  constructor(private readonly jwtService: JwtService) {}

  async use(req: Request, res: Response, next: NextFunction) {
    // Skip public endpoints
    if (this.isPublicEndpoint(req.path)) {
      return next();
    }

    const token = this.extractToken(req);
    if (!token) {
      throw new UnauthorizedException('Missing authentication token');
    }

    try {
      const payload = await this.jwtService.verifyAsync(token);
      req['user'] = payload;
      next();
    } catch {
      throw new UnauthorizedException('Invalid token');
    }
  }

  private extractToken(req: Request): string | undefined {
    // Check cookie first, then Authorization header
    return req.cookies?.ecosire_auth
      || req.headers.authorization?.replace('Bearer ', '');
  }

  private isPublicEndpoint(path: string): boolean {
    const publicPaths = ['/health', '/api/v1/products', '/api/v1/blog'];
    return publicPaths.some(p => path.startsWith(p));
  }
}

パターン 3: レート制限

// Rate limiting configuration per endpoint type
const rateLimits = {
  public: { windowMs: 60000, max: 100 },     // 100 req/min for public APIs
  authenticated: { windowMs: 60000, max: 500 }, // 500 req/min for authenticated users
  admin: { windowMs: 60000, max: 1000 },       // 1000 req/min for admin
  webhooks: { windowMs: 60000, max: 50 },       // 50 req/min for webhooks
};

パターン 4: サーキットブレーカー

ダウンストリーム サービスに障害が発生した場合、サーキット ブレーカーは連鎖的な障害を防ぎます。

[Closed] --> (failures exceed threshold) --> [Open] --> (timeout expires) --> [Half-Open]
    ^                                                                            |
    |                                        (success)                           |
    +--------------------------------------------------------------------<-------+
    |                                        (failure)                           |
    |                                           +-------->  [Open]

州:

• クローズ: リクエストは通常​​通り通過します。トラックの失敗数。
• オープン: サービスを呼び出すことなく、すべてのリクエストは即座に失敗します。キャッシュされた/フォールバック応答を返します。
• ハーフオープン: 1 つのリクエストの通過を許可します。成功した場合は、回路を閉じます。失敗した場合は、再度開きます。

パターン 5: 応答のキャッシュ

# Cache GET responses for public endpoints
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=60m;

location /api/v1/products {
    proxy_pass http://api_service;
    proxy_cache api_cache;
    proxy_cache_valid 200 5m;
    proxy_cache_valid 404 1m;
    proxy_cache_key "$scheme$request_method$host$request_uri";
    add_header X-Cache-Status $upstream_cache_status;
}

---

API バージョン管理戦略

推奨事項: URL パスのバージョン管理。これは、ゲートウェイ レベルでのルーティングが最も明示的で、デバッグしやすく、最も簡単です。

重大な変更と重大でない変更

---

ゲートウェイテクノロジーの比較

ほとんどの SMB の場合: Nginx で十分です。ルーティング、SSL 終端、レート制限、およびキャッシュをミリ秒未満のオーバーヘッドで処理します。高度なプラグイン機能 (OAuth2、リクエスト変換、分析) が必要な場合は、Kong にアップグレードしてください。

---

ゲートウェイでの可観測性

リクエストのロギング

log_format gateway '$remote_addr - $remote_user [$time_local] '
                   '"$request" $status $body_bytes_sent '
                   '"$http_referer" "$http_user_agent" '
                   '$request_time $upstream_response_time '
                   '$http_x_request_id';

access_log /var/log/nginx/gateway.log gateway;

メトリクスの収集

これらのメトリクスをゲートウェイ レベルで追跡します。

• **エンドポイント、メソッド、ステータス コード別の リクエスト レート
• レイテンシー分布 (P50、P95、P99) エンドポイント別
• エンドポイントおよびエラー タイプ別のエラー率
• クライアントによるレート制限ヒット
• キャッシュ ヒット率 (エンドポイント別)
• アップストリーム応答時間 と合計応答時間

---

ゲートウェイでのエラー処理

一貫したエラー応答

ゲートウェイは、さまざまなバックエンド サービスからのエラー応答を正規化する必要があります。

{
  "error": {
    "code": "SERVICE_UNAVAILABLE",
    "message": "The requested service is temporarily unavailable",
    "requestId": "req_abc123",
    "timestamp": "2026-03-16T14:32:01Z"
  }
}

再試行とタイムアウトの構成

location /api/ {
    proxy_pass http://api_service;

    # Timeout configuration
    proxy_connect_timeout 5s;
    proxy_send_timeout 30s;
    proxy_read_timeout 30s;

    # Retry on connection errors only (not on 5xx)
    proxy_next_upstream error timeout;
    proxy_next_upstream_tries 2;

    # Custom error pages
    error_page 502 503 504 /api-error.json;
}

グレースフル デグラデーション

重要ではないバックエンド サービスがダウンしている場合、ゲートウェイはエラーを返す代わりに、キャッシュされた応答またはフォールバック データを提供できます。

---

ゲートウェイのセキュリティ パターン

検証のリクエスト

バックエンド サービスに転送する前にリクエストの構造を検証します。

• 不明なコンテンツタイプのリクエストを拒否する
• エンドポイントごとのリクエスト本文の最大サイズを強制する
• 必要なヘッダー (API バージョン、コンテンツ タイプ) を検証します。
• 疑わしいヘッダーの除去 (ホップバイホップヘッダー、サーバー内部ヘッダー)

管理エンドポイントの IP 許可リストへの登録

location /api/admin/ {
    allow 203.0.113.0/24;  # Office IP range
    allow 10.0.0.0/8;      # Internal network
    deny all;

    proxy_pass http://api_service;
}

リクエスト変換

ゲートウェイは、転送する前にヘッダーを追加、変更、または削除できます。

location /api/ {
    proxy_pass http://api_service;

    # Add security headers
    proxy_set_header X-Request-ID $request_id;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;

    # Remove internal headers from responses
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;
}

---

よくある質問

モノリシック アプリケーションには API ゲートウェイが必要ですか?

はい、でももっと簡単です。モノリスであっても、リバース プロキシとしての Nginx は、SSL 終端、レート制限、静的ファイル サービング、およびセキュリティ ヘッダーを提供します。モノリスには Kong や AWS API Gateway は必要ありませんが、インターネットとアプリケーション サーバーの間に何かが必要です。

API ゲートウェイのフェイルオーバーはどのように処理すればよいですか?

クラウド ロード バランサー (AWS ALB、Cloudflare) の背後で複数のゲートウェイ インスタンスを実行します。 1 つのゲートウェイ インスタンスに障害が発生した場合、ロード バランサーはトラフィックを正常なインスタンスにルーティングします。 Nginx の場合は、アクティブなヘルス チェックと、異常なアップストリームの自動削除を使用します。

API ゲートウェイで認証を処理する必要がありますか、それとも各サービスで処理する必要がありますか?

ゲートウェイは認証 (トークンが有効であることの検証) を処理する必要があります。個々のサービスは承認を処理する必要があります (認証されたユーザーに特定のアクションに対する権限があるかどうかを確認します)。この分離により、ゲートウェイが軽量に保たれ、サービスがきめ細かいアクセス制御の決定を行えるようになります。

API ゲートウェイで CORS をどのように処理すればよいですか?

サービス間で CORS ヘッダーが重複しないように、ゲートウェイ レベルで CORS を構成します。 Access-Control-Allow-Origin を特定のフロントエンド ドメインに設定します (本番環境では資格情報を使用して * を使用しないでください)。ゲートウェイでプリフライト OPTIONS リクエストを処理して、バックエンド サービスの負荷を軽減します。

---

次に何が起こるか

API ゲートウェイはインフラストラクチャへの玄関口です。可視化のために 監視、保護のために セキュリティ強化、容量計画のために 負荷テスト と組み合わせます。

API アーキテクチャに関するコンサルティングについては ECOSIRE にお問い合わせ、完全なインフラストラクチャ ロードマップについては DevOps ガイド をご覧ください。

---

ECOSIRE によって発行 -- 企業によるスケーラブルな API インフラストラクチャの構築を支援します。