# Spring Cloud Gateway面接対策:ルーティング、フィルター、ロードバランシング > 技術面接に向けてSpring Cloud Gatewayをマスターします。ルーティング、フィルター、ロードバランシング、APIゲートウェイのパターンを扱う12問とコード例。 - Published: 2026-03-20 - Updated: 2026-05-01 - Author: SharpSkill - Tags: spring cloud gateway, microservices, api gateway, routing, technical interview - Reading time: 15 min --- Spring Cloud Gatewayは、SpringマイクロサービスアーキテクチャでAPIゲートウェイを実装するための標準的なソリューションです。技術面接では、ルーティングの構成、カスタムフィルターの作成、ロードバランシングの効果的な管理ができるかが評価されます。 > **面接準備のヒント** > > 採用担当者はゲートウェイのパターン、すなわち集中認証、レート制限、サーキットブレーカーへの理解を確認します。なぜ代替手段ではなくSpring Cloud Gatewayを選ぶのかを説明できることが差をつけます。 ## Spring Cloud Gatewayのアーキテクチャと基礎 ### 質問1: Spring Cloud Gatewayとは何か、なぜ使うのか Spring Cloud Gatewayは、Spring WebFluxとProject Reactorの上に構築されたリアクティブなAPIゲートウェイです。マイクロサービスへのすべてのリクエストの単一の入口として機能し、ルーティング、フィルタリング、ロードバランシングの機能を提供します。 ```java // GatewayApplication.java // Spring Cloud Gatewayの基本構成 @SpringBootApplication public class GatewayApplication { public static void main(String[] args) { // リアクティブなNettyサーバーを起動します(Tomcatではありません) SpringApplication.run(GatewayApplication.class, args); } } ``` ```yaml # application.yml # ゲートウェイの最小構成 spring: cloud: gateway: routes: # ユーザーサービスへのルート - id: user-service uri: http://localhost:8081 predicates: - Path=/api/users/** # 注文サービスへのルート - id: order-service uri: http://localhost:8082 predicates: - Path=/api/orders/** ``` Spring Cloud Gatewayの主な利点は次のとおりです。高いパフォーマンスを実現するノンブロッキングなアーキテクチャ、Spring Cloudエコシステムとのネイティブな統合、そして最新のリアクティブパターンへの対応です。 ### 質問2: Route、Predicate、Filterの概念を説明してください Spring Cloud Gatewayは3つの基本概念で構成されます。Routeは宛先を定義し、Predicateはルートを適用する条件を決め、Filterはリクエストとレスポンスを変換します。 ```java // RouteConfiguration.java // プログラムによるルート構成 @Configuration public class RouteConfiguration { @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() // 複数のpredicateを持つルート .route("product-service", r -> r // Predicate: URLパス .path("/api/products/**") // Predicate: HTTPメソッド .and() .method(HttpMethod.GET, HttpMethod.POST) // Predicate: ヘッダーが存在する .and() .header("X-Api-Version", "v2") // Filter: パスの書き換え .filters(f -> f .rewritePath("/api/products/(?.*)", "/products/${segment}") // Filter: ヘッダーの追加 .addRequestHeader("X-Gateway-Source", "spring-cloud-gateway") ) // 宛先のURI .uri("http://localhost:8083")) .build(); } } ``` 処理フローは次の順序で進みます。 ```text 受信リクエスト │ ▼ ┌─────────────────┐ │ Predicates │ → 条件を評価(path、method、header...) └────────┬────────┘ │ 一致あり ▼ ┌─────────────────┐ │ Pre-Filters │ → ルーティング前にリクエストを変更 └────────┬────────┘ │ ▼ ┌─────────────────┐ │ HTTP Proxy │ → 宛先サービスへ転送 └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Post-Filters │ → クライアントへ返す前にレスポンスを変更 └────────┬────────┘ │ ▼ クライアントへの応答 ``` ### 質問3: よく使われるpredicateには何がありますか Spring Cloud Gatewayは多様なルーティング条件のために多くの組み込みpredicateを提供しています。複数のpredicateを組み合わせると、洗練されたルーティングルールを構築できます。 ```yaml # application.yml # 一般的なpredicateの例 spring: cloud: gateway: routes: # 変数キャプチャを伴うpathルーティング - id: user-details uri: http://user-service predicates: - Path=/users/{userId} # HTTPメソッドによるルーティング - id: user-create uri: http://user-service predicates: - Path=/users - Method=POST # ヘッダーに基づくルーティング - id: mobile-api uri: http://mobile-service predicates: - Header=X-Client-Type, mobile # クエリパラメータによるルーティング - id: search-api uri: http://search-service predicates: - Query=q # ホストに基づくルーティング - id: admin-portal uri: http://admin-service predicates: - Host=admin.example.com # 時間に基づくルーティング - id: maintenance-mode uri: http://maintenance-service predicates: - Between=2026-03-20T02:00:00Z,2026-03-20T04:00:00Z ``` ```java // CustomPredicateFactory.java // カスタムpredicateの作成 @Component public class ApiKeyRoutePredicateFactory extends AbstractRoutePredicateFactory { public ApiKeyRoutePredicateFactory() { super(Config.class); } @Override public Predicate apply(Config config) { return exchange -> { // APIキーの存在と有効性を確認します String apiKey = exchange.getRequest() .getHeaders() .getFirst("X-Api-Key"); return apiKey != null && config.getValidKeys().contains(apiKey); }; } @Validated public static class Config { private List validKeys = new ArrayList<>(); public List getValidKeys() { return validKeys; } public void setValidKeys(List validKeys) { this.validKeys = validKeys; } } } ``` > **predicateの順序** > > predicateの順序は評価に影響しませんが、ルートの順序は重要です。ルートは順番に評価され、最初に一致したものが使用されます。 ## フィルターとリクエストの変換 ### 質問4: 前処理と後処理のフィルターはどのように動作しますか GatewayFilterは順序付きのチェーンで実行されます。「pre」フィルターはルーティング前にリクエストを変更し、「post」フィルターは宛先サービスから受け取った後にレスポンスを変更します。 ```java // LoggingFilter.java // グローバルなロギングフィルター @Component @Slf4j public class LoggingFilter implements GlobalFilter, Ordered { @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { // PRE-FILTER: ルーティング前 String requestId = UUID.randomUUID().toString(); long startTime = System.currentTimeMillis(); log.info("Request {} started: {} {}", requestId, exchange.getRequest().getMethod(), exchange.getRequest().getPath()); // リクエストIDをヘッダーに追加します ServerHttpRequest modifiedRequest = exchange.getRequest() .mutate() .header("X-Request-Id", requestId) .build(); // チェーンを継続し、レスポンスを処理します return chain.filter(exchange.mutate().request(modifiedRequest).build()) .then(Mono.fromRunnable(() -> { // POST-FILTER: レスポンス後 long duration = System.currentTimeMillis() - startTime; HttpStatusCode status = exchange.getResponse().getStatusCode(); log.info("Request {} completed: status={}, duration={}ms", requestId, status, duration); })); } @Override public int getOrder() { // 負の順序 = 最初に実行 return -1; } } ``` ```java // AuthenticationFilter.java // JWT認証フィルター @Component @RequiredArgsConstructor public class AuthenticationFilter implements GatewayFilter { private final JwtTokenValidator tokenValidator; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { String authHeader = exchange.getRequest() .getHeaders() .getFirst(HttpHeaders.AUTHORIZATION); // トークンの存在を確認します if (authHeader == null || !authHeader.startsWith("Bearer ")) { return handleUnauthorized(exchange, "Missing or invalid Authorization header"); } String token = authHeader.substring(7); // トークンをリアクティブに検証します return tokenValidator.validate(token) .flatMap(claims -> { // ユーザー情報でリクエストを補強します ServerHttpRequest enrichedRequest = exchange.getRequest() .mutate() .header("X-User-Id", claims.getSubject()) .header("X-User-Roles", String.join(",", claims.getRoles())) .build(); return chain.filter(exchange.mutate().request(enrichedRequest).build()); }) .onErrorResume(e -> handleUnauthorized(exchange, e.getMessage())); } private Mono handleUnauthorized(ServerWebExchange exchange, String message) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); exchange.getResponse().getHeaders().setContentType(MediaType.APPLICATION_JSON); String body = String.format("{\"error\": \"%s\"}", message); DataBuffer buffer = exchange.getResponse() .bufferFactory() .wrap(body.getBytes(StandardCharsets.UTF_8)); return exchange.getResponse().writeWith(Mono.just(buffer)); } } ``` ### 質問5: 役立つ組み込みフィルターは何ですか Spring Cloud Gatewayは、URLの書き換え、ヘッダーの変更、再試行、サーキットブレーカーなど、よくあるユースケースをカバーする組み込みフィルターを多数提供します。 ```yaml # application.yml # よく使う組み込みフィルター spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/orders/** filters: # パスの書き換え - RewritePath=/api/orders/(?.*), /orders/${segment} # リクエストヘッダーの追加 - AddRequestHeader=X-Gateway-Version, 1.0 # 機微なレスポンスヘッダーの削除 - RemoveResponseHeader=X-Powered-By - RemoveResponseHeader=Server # パスの接頭辞 - PrefixPath=/v2 # 接頭辞の削除 - StripPrefix=1 # エラー時の自動再試行 - name: Retry args: retries: 3 statuses: BAD_GATEWAY,SERVICE_UNAVAILABLE methods: GET backoff: firstBackoff: 100ms maxBackoff: 500ms factor: 2 # レート制限 - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20 key-resolver: "#{@userKeyResolver}" ``` ```java // RateLimiterConfiguration.java // ユーザー単位のレートリミッター構成 @Configuration public class RateLimiterConfiguration { @Bean public KeyResolver userKeyResolver() { // 認証済みユーザー単位の制限 return exchange -> Mono.just( exchange.getRequest() .getHeaders() .getFirst("X-User-Id") ).defaultIfEmpty("anonymous"); } @Bean public KeyResolver ipKeyResolver() { // IPアドレス単位の制限 return exchange -> Mono.just( Objects.requireNonNull(exchange.getRequest() .getRemoteAddress()) .getAddress() .getHostAddress() ); } } ``` ### 質問6: ボディを変更するフィルターはどう実装しますか リクエストやレスポンスのボディを変更するには、ModifyRequestBodyGatewayFilterFactoryまたはModifyResponseBodyGatewayFilterFactoryを使う特有の手法が必要です。 ```java // RequestBodyModificationFilter.java // リクエストボディを変更するフィルター @Component @RequiredArgsConstructor public class RequestBodyModificationFilter implements GlobalFilter, Ordered { private final ObjectMapper objectMapper; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { // JSONを伴うPOST/PUTリクエストのみを変更します if (!isJsonRequest(exchange)) { return chain.filter(exchange); } return DataBufferUtils.join(exchange.getRequest().getBody()) .flatMap(dataBuffer -> { byte[] bytes = new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); DataBufferUtils.release(dataBuffer); try { // JSONをパースして変更します Map body = objectMapper.readValue( bytes, new TypeReference>() {} ); // メタデータを追加します body.put("processedAt", Instant.now().toString()); body.put("gatewayVersion", "1.0"); byte[] modifiedBytes = objectMapper.writeValueAsBytes(body); // 変更後のボディで新しいリクエストを作成します ServerHttpRequest modifiedRequest = new ServerHttpRequestDecorator( exchange.getRequest() ) { @Override public Flux getBody() { return Flux.just( exchange.getResponse() .bufferFactory() .wrap(modifiedBytes) ); } @Override public HttpHeaders getHeaders() { HttpHeaders headers = new HttpHeaders(); headers.putAll(super.getHeaders()); headers.setContentLength(modifiedBytes.length); return headers; } }; return chain.filter(exchange.mutate().request(modifiedRequest).build()); } catch (IOException e) { return Mono.error(new RuntimeException("Failed to parse request body", e)); } }); } private boolean isJsonRequest(ServerWebExchange exchange) { MediaType contentType = exchange.getRequest().getHeaders().getContentType(); return contentType != null && contentType.isCompatibleWith(MediaType.APPLICATION_JSON); } @Override public int getOrder() { return Ordered.HIGHEST_PRECEDENCE; } } ``` ```java // ResponseBodyModificationConfig.java // レスポンスを変更するための構成 @Configuration public class ResponseBodyModificationConfig { @Bean public RouteLocator responseModifyingRoutes( RouteLocatorBuilder builder, ModifyResponseBodyGatewayFilterFactory modifyResponseBodyFilter ) { return builder.routes() .route("modify-response", r -> r .path("/api/users/**") .filters(f -> f.modifyResponseBody( String.class, String.class, MediaType.APPLICATION_JSON_VALUE, (exchange, responseBody) -> { // レスポンスを標準形式でラップします return Mono.just(String.format( "{\"success\": true, \"data\": %s, \"timestamp\": \"%s\"}", responseBody, Instant.now() )); } )) .uri("lb://user-service")) .build(); } } ``` ## ロードバランシングと耐障害性 ### 質問7: Spring Cloud LoadBalancerでロードバランシングをどう構成しますか Spring Cloud GatewayはSpring Cloud LoadBalancerと連携して、サービスインスタンス間でトラフィックを分散します。URIスキーム`lb://`によって自動ロードバランシングが有効になります。 ```yaml # application.yml # ロードバランシングの構成 spring: cloud: gateway: routes: - id: user-service # lb:// でロードバランシングを有効化 uri: lb://user-service predicates: - Path=/api/users/** # ロードバランサーの構成 loadbalancer: ribbon: enabled: false # Spring Cloud LoadBalancerを使用(Ribbonは使わない) # サービスごとの構成 configurations: default # ロードバランシング用ヘルスチェック health-check: path: user-service: /actuator/health interval: 10s # サービスディスカバリ(Eurekaなど) eureka: client: serviceUrl: defaultZone: http://localhost:8761/eureka/ ``` ```java // LoadBalancerConfiguration.java // ロードバランサーのカスタム構成 @Configuration @LoadBalancerClients(defaultConfiguration = CustomLoadBalancerConfig.class) public class LoadBalancerConfiguration { } // CustomLoadBalancerConfig.java // カスタムなロードバランシング戦略 public class CustomLoadBalancerConfig { @Bean public ReactorLoadBalancer loadBalancer( Environment environment, LoadBalancerClientFactory clientFactory ) { String serviceId = environment.getProperty( LoadBalancerClientFactory.PROPERTY_NAME ); // 既定はラウンドロビン return new RoundRobinLoadBalancer( clientFactory.getLazyProvider(serviceId, ServiceInstanceListSupplier.class), serviceId ); } @Bean public ServiceInstanceListSupplier serviceInstanceListSupplier( ConfigurableApplicationContext context ) { // インスタンスにヘルスチェックを追加 return ServiceInstanceListSupplier.builder() .withDiscoveryClient() .withHealthChecks() .withCaching() .build(context); } } ``` ```java // WeightedLoadBalancer.java // 重み付きロードバランサー @Component @RequiredArgsConstructor public class WeightedLoadBalancer implements ReactorServiceInstanceLoadBalancer { private final String serviceId; private final ObjectProvider supplierProvider; private final Random random = new Random(); @Override public Mono> choose(Request request) { return supplierProvider.getIfAvailable() .get() .next() .map(instances -> { if (instances.isEmpty()) { return new EmptyResponse(); } // メタデータから重みを計算します List weighted = instances.stream() .map(instance -> { int weight = Integer.parseInt( instance.getMetadata().getOrDefault("weight", "1") ); return new WeightedInstance(instance, weight); }) .toList(); // 重み付き選択 int totalWeight = weighted.stream() .mapToInt(WeightedInstance::weight) .sum(); int randomWeight = random.nextInt(totalWeight); int currentWeight = 0; for (WeightedInstance wi : weighted) { currentWeight += wi.weight(); if (randomWeight < currentWeight) { return new DefaultResponse(wi.instance()); } } return new DefaultResponse(weighted.get(0).instance()); }); } private record WeightedInstance(ServiceInstance instance, int weight) {} } ``` ### 質問8: ゲートウェイにサーキットブレーカーをどう実装しますか サーキットブレーカーは連鎖的な障害を防ぎます。Spring Cloud GatewayはResilience4jと連携し、より高度な障害管理を提供します。 ```yaml # application.yml # Resilience4jサーキットブレーカーの構成 spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/orders/** filters: # フォールバック付きサーキットブレーカー - name: CircuitBreaker args: name: orderServiceCB fallbackUri: forward:/fallback/orders resilience4j: circuitbreaker: configs: default: # 評価対象のリクエスト数 slidingWindowSize: 10 # 回路を開く失敗率の閾値 failureRateThreshold: 50 # 回路がオープンを保つ時間 waitDurationInOpenState: 30s # half-openで許容するリクエスト数 permittedNumberOfCallsInHalfOpenState: 3 # 自動状態遷移 automaticTransitionFromOpenToHalfOpenEnabled: true instances: orderServiceCB: baseConfig: default failureRateThreshold: 60 timelimiter: configs: default: timeoutDuration: 5s instances: orderServiceCB: timeoutDuration: 3s ``` ```java // FallbackController.java // フォールバックコントローラー @RestController @RequestMapping("/fallback") @Slf4j public class FallbackController { @GetMapping("/orders") public Mono>> ordersFallback( ServerWebExchange exchange ) { log.warn("Circuit breaker activated for orders service"); Map response = Map.of( "success", false, "error", "Service temporarily unavailable", "code", "SERVICE_UNAVAILABLE", "retryAfter", 30 ); return Mono.just(ResponseEntity .status(HttpStatus.SERVICE_UNAVAILABLE) .body(response)); } @PostMapping("/orders") public Mono>> ordersPostFallback() { Map response = Map.of( "success", false, "error", "Order creation temporarily unavailable", "code", "SERVICE_UNAVAILABLE", "message", "Please try again later" ); return Mono.just(ResponseEntity .status(HttpStatus.SERVICE_UNAVAILABLE) .body(response)); } } ``` ```java // CircuitBreakerEventListener.java // サーキットブレーカーのイベント監視 @Component @Slf4j @RequiredArgsConstructor public class CircuitBreakerEventListener { private final MeterRegistry meterRegistry; @EventListener public void onCircuitBreakerStateTransition( CircuitBreakerOnStateTransitionEvent event ) { CircuitBreaker.StateTransition transition = event.getStateTransition(); log.info("Circuit breaker {} state changed: {} -> {}", event.getCircuitBreakerName(), transition.getFromState(), transition.getToState()); // Micrometerメトリクス meterRegistry.counter( "circuit_breaker.state_transition", "name", event.getCircuitBreakerName(), "from", transition.getFromState().name(), "to", transition.getToState().name() ).increment(); } @EventListener public void onCircuitBreakerFailure(CircuitBreakerOnErrorEvent event) { log.error("Circuit breaker {} error: {}", event.getCircuitBreakerName(), event.getThrowable().getMessage()); } } ``` > **タイムアウトとサーキットブレーカー** > > サーキットブレーカーとHTTPクライアントの間で一貫したタイムアウトを設定してください。タイムアウトが長すぎるとスレッドを占有し、短すぎると誤検知が発生します。 ### 質問9: 指数バックオフ付きの再試行をどう実装しますか 指数バックオフを伴うインテリジェントな再試行は、苦戦中のサービスを過負荷にすることを避けつつ、成功率を最大化します。 ```yaml # application.yml # バックオフ付き再試行の構成 spring: cloud: gateway: routes: - id: payment-service uri: lb://payment-service predicates: - Path=/api/payments/** filters: - name: Retry args: # 試行回数 retries: 3 # 再試行を発火させるHTTPコード statuses: BAD_GATEWAY,SERVICE_UNAVAILABLE,GATEWAY_TIMEOUT # 冪等なHTTPメソッドのみ methods: GET,PUT # 再試行を発火させる例外 exceptions: - java.io.IOException - java.net.ConnectException - org.springframework.cloud.gateway.support.TimeoutException # 指数バックオフ backoff: firstBackoff: 100ms maxBackoff: 2000ms factor: 2 basedOnPreviousValue: true ``` ```java // CustomRetryFilter.java // ビジネスロジック付きカスタム再試行 @Component @Slf4j public class CustomRetryFilter implements GatewayFilter, Ordered { private static final int MAX_RETRIES = 3; private static final Duration INITIAL_BACKOFF = Duration.ofMillis(100); private static final double BACKOFF_MULTIPLIER = 2.0; private static final double JITTER_FACTOR = 0.1; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { return Mono.defer(() -> attemptRequest(exchange, chain, 0)); } private Mono attemptRequest( ServerWebExchange exchange, GatewayFilterChain chain, int attempt ) { return chain.filter(exchange) .onErrorResume(throwable -> { if (attempt >= MAX_RETRIES || !isRetryable(throwable, exchange)) { return Mono.error(throwable); } Duration backoff = calculateBackoff(attempt); log.warn("Retry attempt {} after {}ms for {} {}", attempt + 1, backoff.toMillis(), exchange.getRequest().getMethod(), exchange.getRequest().getPath()); return Mono.delay(backoff) .then(Mono.defer(() -> attemptRequest(exchange, chain, attempt + 1) )); }); } private boolean isRetryable(Throwable throwable, ServerWebExchange exchange) { // 冪等なメソッドのみ再試行 HttpMethod method = exchange.getRequest().getMethod(); if (!Set.of(HttpMethod.GET, HttpMethod.PUT, HttpMethod.DELETE) .contains(method)) { return false; } // 例外の種類を確認 return throwable instanceof ConnectException || throwable instanceof TimeoutException || throwable instanceof ServiceUnavailableException; } private Duration calculateBackoff(int attempt) { // ジッター付き指数バックオフ long baseBackoff = (long) ( INITIAL_BACKOFF.toMillis() * Math.pow(BACKOFF_MULTIPLIER, attempt) ); // ランダムなジッターを加える(±10%) double jitter = 1.0 + (Math.random() - 0.5) * 2 * JITTER_FACTOR; long finalBackoff = (long) (baseBackoff * jitter); return Duration.ofMillis(finalBackoff); } @Override public int getOrder() { return Ordered.LOWEST_PRECEDENCE - 1; } } ``` ## 高度なパターンとベストプラクティス ### 質問10: リクエストの集約はどう実装しますか 集約は複数のマイクロサービス呼び出しをクライアントへの単一のレスポンスにまとめ、レイテンシとフロントエンドの複雑さを削減します。 ```java // AggregationController.java // 複数サービスの集約 @RestController @RequestMapping("/api/aggregate") @RequiredArgsConstructor @Slf4j public class AggregationController { private final WebClient.Builder webClientBuilder; private final CircuitBreakerRegistry circuitBreakerRegistry; @GetMapping("/user-dashboard/{userId}") public Mono getUserDashboard(@PathVariable Long userId) { // 異なるサービスへの並列呼び出し Mono userMono = fetchUserProfile(userId); Mono> ordersMono = fetchRecentOrders(userId); Mono notificationsMono = fetchNotificationCount(userId); // 結果の集約 return Mono.zip(userMono, ordersMono, notificationsMono) .map(tuple -> DashboardResponse.builder() .user(tuple.getT1()) .recentOrders(tuple.getT2()) .notificationCount(tuple.getT3()) .generatedAt(Instant.now()) .build()) .timeout(Duration.ofSeconds(5)) .onErrorResume(this::handleAggregationError); } private Mono fetchUserProfile(Long userId) { return webClientBuilder.build() .get() .uri("lb://user-service/users/{id}", userId) .retrieve() .bodyToMono(UserProfile.class) .transform(CircuitBreakerOperator.of( circuitBreakerRegistry.circuitBreaker("user-service") )) .onErrorReturn(new UserProfile(userId, "Unknown", null)); } private Mono> fetchRecentOrders(Long userId) { return webClientBuilder.build() .get() .uri("lb://order-service/orders?userId={id}&limit=5", userId) .retrieve() .bodyToFlux(Order.class) .collectList() .transform(CircuitBreakerOperator.of( circuitBreakerRegistry.circuitBreaker("order-service") )) .onErrorReturn(Collections.emptyList()); } private Mono fetchNotificationCount(Long userId) { return webClientBuilder.build() .get() .uri("lb://notification-service/notifications/count/{id}", userId) .retrieve() .bodyToMono(NotificationCount.class) .transform(CircuitBreakerOperator.of( circuitBreakerRegistry.circuitBreaker("notification-service") )) .onErrorReturn(new NotificationCount(0, 0)); } private Mono handleAggregationError(Throwable error) { log.error("Dashboard aggregation failed: {}", error.getMessage()); return Mono.just(DashboardResponse.builder() .error("Partial data available") .generatedAt(Instant.now()) .build()); } } ``` ```java // DashboardResponse.java // 集約レスポンスのDTO @Data @Builder @NoArgsConstructor @AllArgsConstructor public class DashboardResponse { private UserProfile user; private List recentOrders; private NotificationCount notificationCount; private Instant generatedAt; private String error; } ``` ### 質問11: OAuth2でゲートウェイをどう保護しますか OAuth2との統合は認証をゲートウェイレベルで集中化し、各マイクロサービスでの重複ロジックを避けます。 ```yaml # application.yml # OAuth2リソースサーバーの構成 spring: security: oauth2: resourceserver: jwt: issuer-uri: https://auth.example.com/realms/myrealm jwk-set-uri: https://auth.example.com/realms/myrealm/protocol/openid-connect/certs ``` ```java // SecurityConfig.java // ゲートウェイのセキュリティ構成 @Configuration @EnableWebFluxSecurity public class SecurityConfig { @Bean public SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity http) { return http // ステートレスAPIなのでCSRFを無効化 .csrf(ServerHttpSecurity.CsrfSpec::disable) // 認可の構成 .authorizeExchange(exchanges -> exchanges // 公開エンドポイント .pathMatchers("/actuator/health", "/actuator/info").permitAll() .pathMatchers("/api/public/**").permitAll() .pathMatchers("/api/auth/**").permitAll() // 役割別のエンドポイント .pathMatchers("/api/admin/**").hasRole("ADMIN") .pathMatchers(HttpMethod.DELETE, "/api/**").hasRole("ADMIN") // それ以外は認証必須 .anyExchange().authenticated() ) // JWT付きのOAuth2リソースサーバー .oauth2ResourceServer(oauth2 -> oauth2 .jwt(jwt -> jwt .jwtAuthenticationConverter(jwtAuthenticationConverter()) ) ) .build(); } @Bean public ReactiveJwtAuthenticationConverter jwtAuthenticationConverter() { JwtGrantedAuthoritiesConverter grantedAuthoritiesConverter = new JwtGrantedAuthoritiesConverter(); // "roles"クレームから役割を抽出 grantedAuthoritiesConverter.setAuthoritiesClaimName("roles"); grantedAuthoritiesConverter.setAuthorityPrefix("ROLE_"); ReactiveJwtAuthenticationConverter converter = new ReactiveJwtAuthenticationConverter(); converter.setJwtGrantedAuthoritiesConverter( new ReactiveJwtGrantedAuthoritiesConverterAdapter(grantedAuthoritiesConverter) ); return converter; } } ``` ```java // TokenRelayFilter.java // 下流サービスへのトークン中継 @Component public class TokenRelayFilter implements GlobalFilter, Ordered { @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { return ReactiveSecurityContextHolder.getContext() .map(SecurityContext::getAuthentication) .filter(auth -> auth instanceof JwtAuthenticationToken) .cast(JwtAuthenticationToken.class) .map(JwtAuthenticationToken::getToken) .map(jwt -> { // 下流サービスへトークンを中継 ServerHttpRequest request = exchange.getRequest() .mutate() .header(HttpHeaders.AUTHORIZATION, "Bearer " + jwt.getTokenValue()) // トークンから抽出したユーザー情報を付与 .header("X-User-Id", jwt.getSubject()) .header("X-User-Email", jwt.getClaimAsString("email")) .build(); return exchange.mutate().request(request).build(); }) .defaultIfEmpty(exchange) .flatMap(chain::filter); } @Override public int getOrder() { // 認証後、ルーティング前 return SecurityWebFiltersOrder.AUTHENTICATION.getOrder() + 1; } } ``` ### 質問12: 監視とオブザーバビリティのベストプラクティスは何ですか ゲートウェイの監視は、マイクロサービスアーキテクチャでパフォーマンスや可用性の問題を素早く特定するために重要です。 ```yaml # application.yml # オブザーバビリティの構成 management: endpoints: web: exposure: include: health,info,metrics,prometheus,gateway metrics: tags: application: api-gateway distribution: percentiles-histogram: http.server.requests: true percentiles: http.server.requests: 0.5, 0.95, 0.99 tracing: sampling: probability: 1.0 spring: cloud: gateway: metrics: enabled: true tags: path: enabled: true ``` ```java // MetricsFilter.java // カスタムメトリクスフィルター @Component @RequiredArgsConstructor @Slf4j public class MetricsFilter implements GlobalFilter, Ordered { private final MeterRegistry meterRegistry; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { long startTime = System.nanoTime(); String path = exchange.getRequest().getPath().value(); String method = exchange.getRequest().getMethod().name(); // ルートから対象サービスを取得 Route route = exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_ROUTE_ATTR); String routeId = route != null ? route.getId() : "unknown"; return chain.filter(exchange) .doOnSuccess(v -> recordMetrics(exchange, startTime, routeId, "success")) .doOnError(e -> recordMetrics(exchange, startTime, routeId, "error")); } private void recordMetrics( ServerWebExchange exchange, long startTime, String routeId, String outcome ) { long duration = System.nanoTime() - startTime; HttpStatusCode status = exchange.getResponse().getStatusCode(); String statusCode = status != null ? String.valueOf(status.value()) : "0"; // レイテンシ用タイマー Timer.builder("gateway.request.duration") .tag("route", routeId) .tag("method", exchange.getRequest().getMethod().name()) .tag("status", statusCode) .tag("outcome", outcome) .register(meterRegistry) .record(duration, TimeUnit.NANOSECONDS); // リクエストカウンタ meterRegistry.counter( "gateway.requests.total", "route", routeId, "status", statusCode ).increment(); // 遅いリクエストのログ if (duration > TimeUnit.SECONDS.toNanos(1)) { log.warn("Slow request: {} {} - {}ms (route: {})", exchange.getRequest().getMethod(), exchange.getRequest().getPath(), TimeUnit.NANOSECONDS.toMillis(duration), routeId); } } @Override public int getOrder() { return Ordered.HIGHEST_PRECEDENCE; } } ``` ```java // TracingFilter.java // トレーシングコンテキストの伝播 @Component @RequiredArgsConstructor public class TracingFilter implements GlobalFilter, Ordered { private final Tracer tracer; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { // トレーシングのスパンを作成または取得 Span span = tracer.nextSpan() .name("gateway-request") .tag("http.method", exchange.getRequest().getMethod().name()) .tag("http.url", exchange.getRequest().getURI().toString()) .start(); // トレーシングヘッダーを注入 ServerHttpRequest request = exchange.getRequest() .mutate() .header("X-Trace-Id", span.context().traceId()) .header("X-Span-Id", span.context().spanId()) .build(); return chain.filter(exchange.mutate().request(request).build()) .doOnSuccess(v -> { HttpStatusCode status = exchange.getResponse().getStatusCode(); span.tag("http.status_code", status != null ? String.valueOf(status.value()) : "0"); span.end(); }) .doOnError(e -> { span.tag("error", e.getMessage()); span.end(); }); } @Override public int getOrder() { return Ordered.HIGHEST_PRECEDENCE + 1; } } ``` 主要メトリクス一覧: ```text | メトリクス | 説明 | |-----------------------------------|----------------------------------| | gateway.request.duration | ルート/ステータスごとのレイテンシ | | gateway.requests.total | リクエストカウンタ | | resilience4j.circuitbreaker.state | サーキットブレーカーの状態 | | http.server.requests | 標準HTTPメトリクス | | spring.cloud.gateway.routes | アクティブなルート | ``` > **推奨ダッシュボード** > > メトリクスを可視化するために、Spring Cloud GatewayとResilience4jのダッシュボードを備えたGrafanaを利用してください。P99レイテンシとエラー率にアラートを設定しましょう。 ## まとめ Spring Cloud Gatewayは、現代的なマイクロサービスアーキテクチャに欠かせない構成要素です。面接で押さえておくべき要点は次のとおりです。 **アーキテクチャと概念:** - ✅ Routes、Predicates、Filtersが基本モデル - ✅ WebFluxとNettyによるリアクティブアーキテクチャ - ✅ Spring Cloudエコシステムとのネイティブな統合 **主要な機能:** - ✅ 複数の条件に基づく動的ルーティング - ✅ リクエストとレスポンスの変換のためのpre/postフィルター - ✅ Spring Cloud LoadBalancerによるロードバランシング **耐障害性とセキュリティ:** - ✅ Resilience4jとフォールバックを伴うサーキットブレーカー - ✅ 指数バックオフとジッターを伴う再試行 - ✅ 集中化されたOAuth2/JWT認証 **オブザーバビリティ:** - ✅ ルートごとのタグを持つMicrometerメトリクス - ✅ コンテキスト伝播を伴う分散トレーシング - ✅ ヘルスチェックとactuatorエンドポイント Spring Cloud Gatewayを使いこなすことは、マイクロサービスのパターンとスケーラビリティの課題への深い理解を示します。これらのスキルは、堅牢で高性能なAPIゲートウェイを設計するうえで欠かせません。 --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/ja/blog/spring-boot/spring-cloud-gateway-interview-routing-filters