2025-04-08T19:56:24
This commit is contained in:
128
docs/webflux/09_성능 최적화와 디버깅.md
Normal file
128
docs/webflux/09_성능 최적화와 디버깅.md
Normal file
@@ -0,0 +1,128 @@
|
||||
아래는 **"스프링부트 웹플럭스 시리즈"**의 **9장: 성능 최적화와 디버깅"**에 대한 초안입니다. 8장에서 테스트를 마무리한 웹플럭스 애플리케이션을 기반으로 성능 분석, 최적화 기법, 그리고 디버깅 방법을 다룹니다. 실습 예제는 간략히 유지하며, 초보자도 이해할 수 있도록 자연스럽고 친근한 문체로 작성했습니다.
|
||||
|
||||
---
|
||||
|
||||
## 9. 성능 최적화와 디버깅
|
||||
|
||||
이제 웹플럭스 애플리케이션이 제법 모양을 갖췄습니다. 하지만 실무에서는 성능과 안정성이 중요하죠. 이번 장에서는 웹플럭스 애플리케이션의 성능을 분석하고 최적화하는 방법을 알아보고, 비동기 환경에서 디버깅하는 팁도 배워보겠습니다. 성능을 쥐어짜고 문제를 해결하는 재미를 느껴보세요. 시작합시다!
|
||||
|
||||
### 웹플럭스 애플리케이션의 성능 분석
|
||||
|
||||
성능을 최적화하려면 먼저 현재 상태를 파악해야 합니다. 웹플럭스는 비동기/논블로킹으로 작동하니, 병목 지점이 어디인지 찾는 게 핵심입니다. 간단한 방법부터 시작해보죠.
|
||||
|
||||
1. **부하 테스트**: `Apache JMeter`나 `wrk` 같은 도구로 애플리케이션에 부하를 줘봅니다. 예를 들어, 7장의 `/users` 엔드포인트를 테스트하려면:
|
||||
```bash
|
||||
wrk -t10 -c100 -d30s http://localhost:8080/users
|
||||
```
|
||||
- `-t10`: 10개 스레드, `-c100`: 100개 동시 연결, `-d30s`: 30초간 실행.
|
||||
결과로 초당 요청 수(Requests/sec)와 지연 시간(Latency)을 확인할 수 있습니다.
|
||||
|
||||
2. **메트릭 수집**: 스프링 부트 Actuator를 추가해 성능 지표를 모니터링합니다. `build.gradle`에 의존성을 추가하세요:
|
||||
```gradle
|
||||
implementation 'org.springframework.boot:spring-boot-starter-actuator'
|
||||
```
|
||||
`application.yaml`에 설정 추가:
|
||||
```yaml
|
||||
management:
|
||||
endpoints:
|
||||
web:
|
||||
exposure:
|
||||
include: health,metrics
|
||||
```
|
||||
애플리케이션을 실행 후 `http://localhost:8080/actuator/metrics`에 접속하면 요청 처리 시간, 메모리 사용량 등을 볼 수 있습니다.
|
||||
|
||||
3. **프로파일링**: VisualVM이나 IntelliJ Profiler로 CPU와 메모리 사용을 분석합니다. 예를 들어, `/users/stream` 엔드포인트가 느리다면 프로파일러로 호출 스택을 확인해보세요.
|
||||
|
||||
### 논블로킹 코드 최적화 기법
|
||||
|
||||
웹플럭스의 성능은 논블로킹 처리에 달려 있습니다. 몇 가지 최적화 팁을 적용해보죠.
|
||||
|
||||
1. **불필요한 블로킹 제거**:
|
||||
기존 코드에 동기 호출(예: `Thread.sleep`)이 있다면 제거하거나 비동기로 바꿉니다. 예를 들어:
|
||||
```java
|
||||
// 비추천
|
||||
public Mono<String> slowMethod() {
|
||||
Thread.sleep(1000); // 블로킹
|
||||
return Mono.just("Done");
|
||||
}
|
||||
|
||||
// 추천
|
||||
public Mono<String> fastMethod() {
|
||||
return Mono.just("Done").delayElement(Duration.ofSeconds(1));
|
||||
}
|
||||
```
|
||||
|
||||
2. **병렬 처리 활용**:
|
||||
`Flux`로 여러 작업을 병렬로 처리할 수 있습니다. 예를 들어, 사용자 목록을 가져와 외부 API로 추가 데이터를 조회한다고 가정하면:
|
||||
```java
|
||||
public Flux<User> enrichUsers() {
|
||||
return userRepository.findAll()
|
||||
.parallel()
|
||||
.runOn(Schedulers.parallel())
|
||||
.flatMap(user -> fetchAdditionalData(user))
|
||||
.sequential();
|
||||
}
|
||||
```
|
||||
- `parallel()`과 `Schedulers.parallel()`로 병렬 실행.
|
||||
|
||||
3. **캐싱 적용**:
|
||||
자주 조회되는 데이터는 캐싱으로 부하를 줄입니다. `reactor-cache`를 추가해 구현해보세요:
|
||||
```gradle
|
||||
implementation 'io.github.resilience4j:resilience4j-reactor'
|
||||
```
|
||||
```java
|
||||
private final CacheMono<String, User> userCache = CacheMono.from(Caffeine.newBuilder().build());
|
||||
public Mono<User> getCachedUser(Long id) {
|
||||
return userCache.lookup(id.toString(), userRepository.findById(id));
|
||||
}
|
||||
```
|
||||
|
||||
### 리액티브 애플리케이션 디버깅 방법
|
||||
|
||||
비동기 코드는 디버깅이 까다로울 수 있습니다. 스택 트레이스가 복잡하고, 문제가 어디서 발생했는지 찾기 어렵죠. 몇 가지 디버깅 팁을 소개합니다.
|
||||
|
||||
1. **로그 추가**:
|
||||
`doOn` 연산자로 흐름을 추적합니다. `UserController`의 `getUserById`에 적용해보죠:
|
||||
```java
|
||||
@GetMapping("/{id}")
|
||||
public Mono<User> getUserById(@PathVariable Long id) {
|
||||
return userRepository.findById(id)
|
||||
.doOnSubscribe(sub -> log.info("Fetching user with ID: {}", id))
|
||||
.doOnNext(user -> log.info("Found user: {}", user))
|
||||
.doOnError(err -> log.error("Error: ", err))
|
||||
.switchIfEmpty(Mono.error(new UserNotFoundException("User with ID " + id + " not found")));
|
||||
}
|
||||
```
|
||||
- `log`는 `org.slf4j.Logger`를 사용 (클래스 상단에 선언 필요).
|
||||
|
||||
2. **리액터 디버깅 모드**:
|
||||
`reactor-tools`를 추가해 스택 트레이스를 개선합니다:
|
||||
```gradle
|
||||
implementation 'io.projectreactor:reactor-tools'
|
||||
```
|
||||
애플리케이션 시작 시 활성화:
|
||||
```java
|
||||
public static void main(String[] args) {
|
||||
Hooks.onOperatorDebug();
|
||||
SpringApplication.run(Application.class, args);
|
||||
}
|
||||
```
|
||||
에러 발생 시 더 자세한 스택 트레이스가 출력됩니다.
|
||||
|
||||
3. **StepVerifier로 확인**:
|
||||
테스트 중에 디버깅할 때는 `StepVerifier`로 스트림을 단계별로 검증합니다. 8장의 예제를 참고하세요.
|
||||
|
||||
### 실습: 성능 개선 확인
|
||||
|
||||
`/users` 엔드포인트에 캐싱을 추가하고 부하 테스트로 성능 변화를 확인해보세요:
|
||||
1. 캐싱 없는 상태에서 `wrk`로 테스트.
|
||||
2. 캐싱 추가 후 다시 테스트.
|
||||
3. 결과를 비교하며 응답 시간 감소를 확인.
|
||||
|
||||
### 마무리
|
||||
|
||||
성능 분석과 최적화로 웹플럭스의 잠재력을 끌어올리고, 디버깅으로 문제를 빠르게 잡아냈습니다. 비동기 환경은 처음엔 어색할 수 있지만, 이런 도구와 기법을 익히면 실무에서 큰 힘이 됩니다. 다음 장에서는 실전 프로젝트로 마이크로서비스를 구축하며, 웹플럭스를 더 큰 무대에 올려보겠습니다. 이번 장에서 애플리케이션이 더 단단해진 느낌이 드시길 바랍니다!
|
||||
|
||||
---
|
||||
|
||||
이 장은 성능 분석과 디버깅 실무 팁을 중심으로 구성했으며, 간단한 실습으로 이해를 도왔습니다. 추가 예제나 조정이 필요하면 말씀해주세요!
|
||||
Reference in New Issue
Block a user