ストーリー

API Gatewayとは

クライアントとマイクロサービス群の間に配置される単一のエントリーポイントです。

graph LR
    subgraph "Without API Gateway"
        C1["Client"] --> U1["User Service<br/>users.example.com"]
        C1 --> P1["Product Service<br/>products.example.com"]
        C1 --> O1["Order Service<br/>orders.example.com"]
    end

    subgraph "With API Gateway"
        C2["Client"] --> GW["API Gateway<br/>（単一URL）"]
        GW --> U2["User Service"]
        GW --> P2["Product Service"]
        GW --> O2["Order Service"]
    end

API Gatewayの主な責務

// API Gatewayが担う横断的関心事
interface ApiGateway {
  // 1. ルーティング
  route(request: Request): ServiceEndpoint;

  // 2. 認証・認可
  authenticate(token: string): Promise<AuthContext>;
  authorize(context: AuthContext, resource: string): boolean;

  // 3. レート制限
  rateLimit(clientId: string): boolean;

  // 4. レスポンスの集約（BFF: Backend for Frontend）
  aggregate(requests: ServiceRequest[]): Promise<AggregatedResponse>;

  // 5. プロトコル変換
  transformProtocol(request: HttpRequest): GrpcRequest;

  // 6. キャッシュ
  cache(key: string, response: Response, ttl: number): void;
}

BFF（Backend for Frontend）パターン

// API Gatewayでの集約例
// クライアントの1回のリクエストで複数サービスを呼び出し
app.get("/api/dashboard", async (req, res) => {
  const userId = req.user.id;

  // 並行して複数サービスを呼び出し
  const [user, orders, recommendations] = await Promise.all([
    userService.getProfile(userId),
    orderService.getRecentOrders(userId, { limit: 5 }),
    recommendationService.getForUser(userId, { limit: 10 }),
  ]);

  // クライアントに最適化された形で返却
  res.json({
    profile: { name: user.name, avatar: user.avatarUrl },
    recentOrders: orders.map(o => ({ id: o.id, status: o.status })),
    recommendations: recommendations.map(r => ({ id: r.id, title: r.title })),
  });
});

主要なAPI Gatewayソリューション

サービスメッシュとは

サービス間の通信を管理するインフラレイヤーです。各サービスにサイドカープロキシを配置します。

graph TD
    subgraph mesh["Service Mesh"]
        subgraph SA["Service A"]
            AppA["App"] --> SCA["Sidecar<br/>Envoy"]
        end
        subgraph SB["Service B"]
            AppB["App"] --> SCB["Sidecar<br/>Envoy"]
        end
        SCA <-->|"通信"| SCB

        CP["Control Plane<br/>Istio, Linkerd"]
        CP ---|"トラフィック管理"| SCA
        CP ---|"mTLS（相互TLS認証）"| SCB
    end

    note["API Gateway: クライアント ↔ サービス の通信を管理<br/>Service Mesh: サービス ↔ サービス の通信を管理"]

    classDef noteStyle fill:#fff,stroke:#999,color:#666
    class note noteStyle

サービスメッシュの主な機能

// サービスメッシュが提供する機能（コードを変更せずに利用可能）
const serviceMeshCapabilities = {
  // トラフィック管理
  trafficManagement: {
    loadBalancing: "ラウンドロビン、重み付け、最小接続数",
    circuitBreaker: "障害検知と自動遮断",
    retries: "自動リトライと指数バックオフ",
    timeout: "タイムアウト設定",
    canaryDeploy: "カナリアリリース（90%旧、10%新）",
  },

  // セキュリティ
  security: {
    mTLS: "サービス間の暗号化通信（自動証明書管理）",
    authz: "サービス間のアクセス制御ポリシー",
  },

  // オブザーバビリティ
  observability: {
    metrics: "リクエスト数、レイテンシ、エラー率",
    tracing: "分散トレーシング（自動計装）",
    logging: "アクセスログの自動収集",
  },
};

主要なサービスメッシュソリューション

API Gateway vs サービスメッシュ

graph LR
    Client["External<br/>Client"] -->|"North-South"| GW["API Gateway"]
    subgraph internal["Internal（Service Mesh）"]
        direction TB
        SA["ServiceA"] <-->|"East-West"| SB["ServiceB"]
        SC["ServiceC"] <-->|"East-West"| SD["ServiceD"]
        SA <--> SC
    end
    GW --> internal

まとめ

チェックリスト

• API Gatewayの6つの責務を説明できる
• BFFパターンのメリットを理解した
• サービスメッシュの仕組み（サイドカー）を説明できる
• API Gatewayとサービスメッシュの違いを説明できる

次のステップへ

次はサービスディスカバリとロードバランシングを学びます。サービスが動的にスケールする環境で、どうやって相手を見つけるかを理解しましょう。

推定読了時間: 30分