탄력적인 API 구축: 제가 저지른 실수와 이를 극복한 방법-java지도 시간-php.cn

집

Java

java지도 시간

탄력적인 API 구축: 제가 저지른 실수와 이를 극복한 방법

Mary-Kate Olsen

Jan 04, 2025 pm 03:48 PM

Building Resilient APIs: Mistakes I Made and How I Overcame Them

API는 최신 애플리케이션의 중추입니다. Spring Boot로 처음 API 구축을 시작했을 때 기능 제공에 너무 집중한 나머지 한 가지 중요한 측면인 복원력을 간과했습니다. 나는 실패를 우아하게 처리하고 다양한 조건에 적응하는 API의 능력이 API를 진정으로 신뢰할 수 있게 만드는 것임을 힘들게 배웠습니다. 그동안 제가 저지른 몇 가지 실수와 이를 수정한 방법을 안내해 드리겠습니다. 여러분의 여정에서 이러한 함정을 피할 수 있기를 바랍니다.

실수 1: 시간 초과 구성 무시

무슨 일이 있었나요? 초기 프로젝트 중 하나에서 제3자 서비스를 외부 호출하는 API를 구축했습니다. 나는 그러한 서비스가 항상 신속하게 응답할 것이라고 생각했으며 시간 초과 설정을 귀찮게 하지 않았습니다. 트래픽이 증가하고 타사 서비스의 속도가 느려지기 전까지는 모든 것이 괜찮아 보였습니다. 내 API는 응답을 기다리며 무기한 정지됩니다.

영향: API의 응답성이 급격히 떨어졌습니다. 종속 서비스가 실패하기 시작했고 사용자는 오랜 지연에 직면했습니다. 심지어 일부는 끔찍한 500 내부 서버 오류를 겪기도 했습니다.

수정 방법: 그때 저는 시간 초과 구성의 중요성을 깨달았습니다. 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;
        }
    }
}

로그인 후 복사

이 구성에는 적절한 시간 초과를 설정할 뿐만 아니라 외부 서비스 성능을 모니터링하는 데 도움이 되는 로깅도 포함됩니다.

실수 2: 회로 차단기를 구현하지 않음

무슨 일이 있었나요: 우리가 의존하던 내부 서비스가 몇 시간 동안 다운된 적이 있었습니다. 내 API가 상황을 적절하게 처리하지 못했습니다. 대신 실패한 요청을 계속 재시도하여 이미 스트레스를 받은 시스템에 더 많은 부하를 추가했습니다.

계단식 오류는 분산 시스템에서 가장 어려운 문제 중 하나입니다. 하나의 서비스가 실패하면 전체 시스템을 다운시키는 도미노 현상이 발생할 수 있습니다.

영향: 반복적인 재시도로 인해 시스템이 과부하되어 애플리케이션의 다른 부분이 느려지고 모든 사용자에게 영향을 미쳤습니다.

고친 방법: 그때 회로 차단기 패턴을 발견했습니다. 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();
    }
}

로그인 후 복사

이 간단한 추가로 내 API가 내부 서비스나 타사 서비스를 압도하는 것을 방지하여 시스템 안정성을 보장했습니다.

실수 3: 취약한 오류 처리

무슨 일이 있었나요: 초기에는 오류 처리에 대해 별로 생각하지 않았습니다. 내 API에서는 일반적인 오류(예: 모든 경우에 HTTP 500)가 발생했거나 스택 추적에 민감한 내부 세부 정보가 노출되었습니다.

영향: 사용자는 무엇이 잘못되었는지 혼란스러워했고, 내부 세부정보가 노출되어 잠재적인 보안 위험이 발생했습니다.

수정 방법: 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;
        }
    }
}

로그인 후 복사

이를 통해 오류 메시지가 명확하고 안전해져서 사용자와 개발자 모두에게 도움이 되었습니다.

실수 4: 속도 제한 무시

무슨 일이 있었나요: 어느 화창한 날, 프로모션 캠페인을 시작했는데 API 트래픽이 급증했습니다. 이는 비즈니스에 좋은 소식이었지만 일부 사용자는 API에 스팸 요청을 보내기 시작했고 이로 인해 다른 사용자는 리소스가 부족해졌습니다.

영향: 모두의 성능이 저하되었고 불만이 쇄도했습니다.

수정 방법: 이 문제를 처리하기 위해 Redis와 함께 Bucket4j를 사용하여 속도 제한을 구현했습니다. 예는 다음과 같습니다.

@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가 남용되지 않도록 보호됩니다.

실수 5: 관찰 가능성을 간과함

무슨 일이 일어났나요? 제작 과정에서 문제가 발생할 때마다 마치 건초 더미에서 바늘을 찾는 것과 같았습니다. 적절한 로깅이나 지표가 마련되어 있지 않아 문제를 진단하는 데 예상보다 시간이 오래 걸렸습니다.

영향: 문제 해결이 악몽이 되어 문제 해결이 지연되고 사용자가 불만을 느꼈습니다.

수정 방법: 상태 확인을 위해 Spring Boot Actuator를 추가하고 메트릭 시각화를 위해 Prometheus를 Grafana와 통합했습니다.

@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 Stack(Elasticsearch, Logstash, Kibana)을 사용하여 구조화된 로깅을 구현했습니다. 이로 인해 로그의 실행 가능성이 훨씬 높아졌습니다.