API は最新のアプリケーションのバックボーンです。 Spring Boot を使用して API の構(gòu)築を始めたとき、私は機(jī)能を提供することに集中しすぎて、復(fù)元力という 1 つの重要な側(cè)面を見(jiàn)落としていました。 API が障害を適切に処理し、さまざまな狀況に適応できる能力こそが API を真に信頼できるものにするということを、私は苦労して學(xué)びました。その過(guò)程で私が犯したいくつかの間違いと、それをどのように修正したかを説明しましょう。うまくいけば、あなた自身の旅でこれらの落とし穴を避けることができます。

間違い 1: タイムアウト構(gòu)成を無(wú)視する

何が起こったか: 私の初期のプロジェクトの 1 つで、サードパーティ サービスへの外部呼び出しを行う API を構(gòu)築しました。私は、これらのサービスは常に迅速に応答するものと考えており、タイムアウトを設(shè)定する必要はありませんでした。トラフィックが増加し、サードパーティ サービスの速度が低下し始めるまでは、すべてが順調(diào)に見(jiàn)えました。私の API は応答を待って無(wú)期限にハングするだけです。

影響: API の応答性が急激に低下しました。依存するサービスに障害が発生し始め、ユーザーは長(zhǎng)い遅延に直面し、恐ろしい 500 內(nèi)部サーバー エラーに見(jiàn)舞われた人もいました。

私がそれを修正した方法: そのとき、タイムアウト構(gòu)成の重要性に気づきました。 Spring Boot を使用してそれを修正する方法は次のとおりです。

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder
                .setConnectTimeout(Duration.ofSeconds(5))
                .setReadTimeout(Duration.ofSeconds(5))
                .additionalInterceptors(new RestTemplateLoggingInterceptor())
                .build();
    }

    // Custom interceptor to log request/response details
    @RequiredArgsConstructor
    public class RestTemplateLoggingInterceptor implements ClientHttpRequestInterceptor {
        private static final Logger log = LoggerFactory.getLogger(RestTemplateLoggingInterceptor.class);

        @Override
        public ClientHttpResponse intercept(HttpRequest request, byte[] body, 
                                          ClientHttpRequestExecution execution) throws IOException {
            long startTime = System.currentTimeMillis();
            log.info("Making request to: {}", request.getURI());

            ClientHttpResponse response = execution.execute(request, body);

            long duration = System.currentTimeMillis() - startTime;
            log.info("Request completed in {}ms with status: {}", 
                    duration, response.getStatusCode());

            return response;
        }
    }
}

この構(gòu)成には、適切なタイムアウトを設(shè)定するだけでなく、外部サービスのパフォーマンスの監(jiān)視に役立つログも含まれます。

間違い 2: サーキットブレーカーを?qū)g裝していない

何が起こったのか: 私たちが依存していた社內(nèi)サービスが數(shù)時(shí)間ダウンしたことがありました。私の API は狀況を適切に処理できませんでした。代わりに、失敗したリクエストを再試行し続け、すでにストレスがかかっているシステムにさらなる負(fù)荷を加えました。

カスケード障害は、分散システムにおける最も困難な問(wèn)題の 1 つです。 1 つのサービスに障害が発生すると、システム全體がダウンするドミノ効果が発生する可能性があります。

影響: 繰り返される再試行によりシステムに負(fù)荷がかかり、アプリケーションの他の部分の速度が低下し、すべてのユーザーに影響を及ぼします。

私がそれを解決した方法: そのとき、私はサーキットブレーカーのパターンを発見(jiàn)しました。 Spring Cloud Resilience4j を使用することで、このサイクルを斷ち切ることができました。

@Configuration
public class Resilience4jConfig {

    @Bean
    public CircuitBreakerConfig circuitBreakerConfig() {
        return CircuitBreakerConfig.custom()
                .failureRateThreshold(50)
                .waitDurationInOpenState(Duration.ofSeconds(60))
                .permittedNumberOfCallsInHalfOpenState(2)
                .slidingWindowSize(2)
                .build();
    }

    @Bean
    public RetryConfig retryConfig() {
        return RetryConfig.custom()
                .maxAttempts(3)
                .waitDuration(Duration.ofSeconds(2))
                .build();
    }
}

@Service
@Slf4j
public class ResilientService {

    private final CircuitBreaker circuitBreaker;
    private final RestTemplate restTemplate;

    public ResilientService(CircuitBreakerRegistry registry, RestTemplate restTemplate) {
        this.circuitBreaker = registry.circuitBreaker("internalService");
        this.restTemplate = restTemplate;
    }

    @CircuitBreaker(name = "internalService", fallbackMethod = "fallbackResponse")
    @Retry(name = "internalService")
    public String callInternalService() {
        return restTemplate.getForObject("https://internal-service.com/data", String.class);
    }

    public String fallbackResponse(Exception ex) {
        log.warn("Circuit breaker activated, returning fallback response", ex);
        return new FallbackResponse("Service temporarily unavailable", 
                                  getBackupData()).toJson();
    }

    private Object getBackupData() {
        // Implement cache or default data strategy
        return new CachedDataService().getLatestValidData();
    }
}

この簡(jiǎn)単な追加により、API 自體、內(nèi)部サービス、サードパーティ サービスが過(guò)負(fù)荷になるのを防ぎ、システムの安定性を確保しました。

間違い 3: エラー処理が弱い

何が起こったのか: 初期の頃、私はエラー処理についてあまり考えていませんでした。私の API は、一般的なエラー (すべての HTTP 500 など) をスローするか、スタック トレースで機(jī)密の內(nèi)部詳細(xì)を公開(kāi)します。

影響: ユーザーは何が問(wèn)題だったのか混亂し、內(nèi)部詳細(xì)の公開(kāi)により潛在的なセキュリティ リスクが生じました。

修正方法: Spring の @ControllerAdvice アノテーションを使用してエラー処理を一元化することにしました。私がやったことは次のとおりです:

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder
                .setConnectTimeout(Duration.ofSeconds(5))
                .setReadTimeout(Duration.ofSeconds(5))
                .additionalInterceptors(new RestTemplateLoggingInterceptor())
                .build();
    }

    // Custom interceptor to log request/response details
    @RequiredArgsConstructor
    public class RestTemplateLoggingInterceptor implements ClientHttpRequestInterceptor {
        private static final Logger log = LoggerFactory.getLogger(RestTemplateLoggingInterceptor.class);

        @Override
        public ClientHttpResponse intercept(HttpRequest request, byte[] body, 
                                          ClientHttpRequestExecution execution) throws IOException {
            long startTime = System.currentTimeMillis();
            log.info("Making request to: {}", request.getURI());

            ClientHttpResponse response = execution.execute(request, body);

            long duration = System.currentTimeMillis() - startTime;
            log.info("Request completed in {}ms with status: {}", 
                    duration, response.getStatusCode());

            return response;
        }
    }
}

これにより、エラー メッセージが明確かつ安全になり、ユーザーと開(kāi)発者の両方が役立ちました。

間違い 4: レート制限を無(wú)視する

何が起こったのか: ある晴れた日、プロモーション キャンペーンを開(kāi)始したところ、API へのトラフィックが急増しました。これはビジネスにとって朗報(bào)でしたが、一部のユーザーが API にリクエストをスパム送信し始め、他のユーザーのリソースが枯渇してしまいました。

影響: すべてのパフォーマンスが低下し、苦情が殺到しました。

修正方法: これに対処するために、Redis で Bucket4j を使用してレート制限を?qū)g裝しました。以下に例を示します:

@Configuration
public class Resilience4jConfig {

    @Bean
    public CircuitBreakerConfig circuitBreakerConfig() {
        return CircuitBreakerConfig.custom()
                .failureRateThreshold(50)
                .waitDurationInOpenState(Duration.ofSeconds(60))
                .permittedNumberOfCallsInHalfOpenState(2)
                .slidingWindowSize(2)
                .build();
    }

    @Bean
    public RetryConfig retryConfig() {
        return RetryConfig.custom()
                .maxAttempts(3)
                .waitDuration(Duration.ofSeconds(2))
                .build();
    }
}

@Service
@Slf4j
public class ResilientService {

    private final CircuitBreaker circuitBreaker;
    private final RestTemplate restTemplate;

    public ResilientService(CircuitBreakerRegistry registry, RestTemplate restTemplate) {
        this.circuitBreaker = registry.circuitBreaker("internalService");
        this.restTemplate = restTemplate;
    }

    @CircuitBreaker(name = "internalService", fallbackMethod = "fallbackResponse")
    @Retry(name = "internalService")
    public String callInternalService() {
        return restTemplate.getForObject("https://internal-service.com/data", String.class);
    }

    public String fallbackResponse(Exception ex) {
        log.warn("Circuit breaker activated, returning fallback response", ex);
        return new FallbackResponse("Service temporarily unavailable", 
                                  getBackupData()).toJson();
    }

    private Object getBackupData() {
        // Implement cache or default data strategy
        return new CachedDataService().getLatestValidData();
    }
}

これにより、公正な使用が保証され、API が悪用から保護(hù)されました。

間違い 5: 可観測(cè)性を見(jiàn)落とす

何が起こったのか: 本番環(huán)境で何か問(wèn)題が発生するたびに、それは干し草の山から針を探すようなものでした。適切なロギングやメトリクスが用意されていなかったため、問(wèn)題の診斷に必要以上に時(shí)間がかかりました。

影響: トラブルシューティングが悪夢(mèng)となり、問(wèn)題解決が遅れ、ユーザーにストレスを與えました。

修正方法: ヘルスチェックのために Spring Boot Actuator を追加し、メトリクスの視覚化のために Prometheus と Grafana を統(tǒng)合しました:

@RestControllerAdvice
@Slf4j
public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {

    @ExceptionHandler(HttpClientErrorException.class)
    public ResponseEntity<ErrorResponse> handleHttpClientError(HttpClientErrorException ex, 
                                                             WebRequest request) {
        log.error("Client error occurred", ex);

        ErrorResponse error = ErrorResponse.builder()
                .timestamp(LocalDateTime.now())
                .status(ex.getStatusCode().value())
                .message(sanitizeErrorMessage(ex.getMessage()))
                .path(((ServletWebRequest) request).getRequest().getRequestURI())
                .build();

        return ResponseEntity.status(ex.getStatusCode()).body(error);
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleGeneralException(Exception ex, 
                                                              WebRequest request) {
        log.error("Unexpected error occurred", ex);

        ErrorResponse error = ErrorResponse.builder()
                .timestamp(LocalDateTime.now())
                .status(HttpStatus.INTERNAL_SERVER_ERROR.value())
                .message("An unexpected error occurred. Please try again later.")
                .path(((ServletWebRequest) request).getRequest().getRequestURI())
                .build();

        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(error);
    }

    private String sanitizeErrorMessage(String message) {
        // Remove sensitive information from error messages
        return message.replaceAll("(password|secret|key)=\[.*?\]", "=[REDACTED]");
    }
}

ELK スタック (Elasticsearch、Logstash、Kibana) を使用して構(gòu)造化ログも実裝しました。これにより、ログがはるかに実用的になりました。

テイクアウト

回復(fù)力のある API を構(gòu)築するのは長(zhǎng)い旅であり、間違いはプロセスの一部です。私が學(xué)んだ重要な教訓(xùn)は次のとおりです:

1. 外部呼び出しのタイムアウトは常に構(gòu)成してください。
2. 回路ブレーカーを使用してカスケード障害を防止してください。
3. エラー処理を一元化して明確かつ安全にします。
4. トラフィックの急増を管理するためにレート制限を?qū)g裝します。

これらの変更により、API 開(kāi)発への取り組み方が変わりました。同じような課題に直面したことがある方、または他のヒントをお持ちの方がいらっしゃいましたら、ぜひお話をお聞かせください!

終了注記: 復(fù)元力はユーザーが追加する機(jī)能ではなく、システムに最初から組み込む特性であることに注意してください。これらのコンポーネントはそれぞれ、動(dòng)作するだけでなくストレス下でも確実に動(dòng)作し続ける API を作成する上で重要な役割を果たします。

以上が回復(fù)力のある API の構(gòu)築: 私が犯した間違いとそれをどのように克服したかの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。