이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
Blocking Non-blocking 실전 판단에서 붙잡아야 할 핵심 판단 기준은 무엇인가?기술 선택은 병목 위치와 운영 능력의 함수다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
Blocking Non-blocking 실전 판단판단 기준은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 Blocking Non-blocking 실전 판단이다. 실무에서 blocking, async, non-blocking을 선택하는 기준과 위험을 정리한다.
먼저 붙잡을 기준은 다음 문장이다. 기술 선택은 병목 위치와 운영 능력의 함수다. 이 문서는 이 기준을 Java/Spring 실행 흐름, JVM/OS 관찰 지표, 장애 판단 순서로 연결한다.
핵심 모델
- 판단 기준: 선택은 유행이 아니라 대기 시간, 동시성, 디버깅 비용의 합이다.
- Blocking 모델은 단순하고 dump 해석이 쉽지만 많은 동시 I/O에서 thread가 빠르게 찬다.
- Non-blocking 모델은 thread 점유를 줄일 수 있지만 blocking dependency가 남으면 장점이 줄어든다.
- Async는 실패, timeout, cancellation, backpressure 정책까지 함께 설계해야 한다.
- 팀이 장애 중 읽을 수 없는 모델은 성능상 이점보다 운영 비용이 더 클 수 있다.
문서별 핵심 구분
- blocking은 단순하고 관찰하기 쉽지만 thread를 많이 요구한다.
- non-blocking은 연결 수에 강하지만 디버깅과 backpressure 설계가 어렵다.
- 선택 기준은 트래픽, I/O 시간, 팀 운영 능력이다.
원리
Blocking과 non-blocking 중 하나가 항상 우월한 것은 아니다. 낮은 동시성, 짧은 DB I/O, 단순한 운영 요구에서는 MVC blocking 모델이 더 읽기 쉽고 dump 분석도 직접적이다.
Non-blocking 모델은 많은 idle connection이나 느린 network I/O를 적은 thread로 다룰 때 강하다. 대신 event loop를 막지 않는 코드 규칙, backpressure, metric, 디버깅 경험이 필요하다.
Async는 병목을 없애는 도구가 아니라 병목 위치를 바꾸는 도구다. 사용자 요청 thread에서 빠져나와도 별도 executor queue, downstream pool, callback 실행 위치가 새 병목이 될 수 있다.
Blocking Non-blocking 실전 판단 관점에서 중요한 점은 기술 선택을 트래픽 모양, I/O 대기 시간, CPU 비중, 팀 운영 능력의 함수로 보는 것이다. 새 모델로 바꾸기 전에 어떤 지표가 개선되어야 성공인지 먼저 정한다.
Java/Spring 연결
- MVC와 WebFlux 선택은 Controller 문법보다 DB driver, 외부 client, streaming 요구를 기준으로 한다.
- 대부분의 CRUD API가 JDBC blocking이면 MVC와 명확한 timeout/pool 관리가 더 단순할 수 있다.
- 긴 streaming, 많은 idle connection, non-blocking client 조합이면 WebFlux가 유리할 수 있다.
- Blocking dependency를 reactive chain에 섞을 때는 scheduler 격리와 timeout을 반드시 둔다.
- 장애 대응 문서에는 thread dump와 Reactor stack을 팀이 어떻게 읽을지까지 포함한다.
코드와 설정 예시
낮은 동시성 + 짧은 DB I/O + 단순 운영
-> MVC blocking + 명확한 timeout + 충분한 thread/pool 관찰
많은 idle connection + 느린 network I/O + backpressure 준비
-> non-blocking/event loop 검토
CPU heavy 작업
-> non-blocking 전환보다 작업량 감소, 별도 worker, batch 분리 검토예시는 선택 기준을 기술 이름이 아니라 병목 모양으로 나누기 위한 것이다. CPU heavy 작업은 non-blocking으로 바꿔도 core를 쓰며, 느린 I/O는 timeout과 backpressure 없이 모델만 바꿔도 장애가 남는다.
관찰 명령
top -H -p <pid>
jcmd <pid> Thread.print
curl -s localhost:8080/actuator/metrics/http.server.requestsBlocking Non-blocking 실전 판단 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
| Tomcat busy thread가 max 근처 | blocking I/O 또는 긴 요청 처리 | thread dump와 endpoint별 latency |
| executor queue가 계속 증가 | worker 부족 또는 downstream 지연 | active/queued/rejected 지표 |
| event loop thread CPU가 높음 | loop 안 CPU 작업 또는 blocking 호출 | JFR, thread name, stack trace |
| timeout 후 retry 급증 | backpressure 실패 | retry 로그와 downstream error rate |
Blocking Non-blocking 실전 판단에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
- 지연의 대부분이 CPU, DB, 외부 API, socket idle 중 어디인지 나눈다.
- 현재 모델에서 thread 점유가 병목인지 event loop blocking이 병목인지 확인한다.
- dependency client가 blocking인지 non-blocking인지 실제 구현을 확인한다.
- timeout, backpressure, retry, bulkhead가 모델에 맞게 있는지 본다.
- 모델 전환 전 병목을 만든 dependency와 운영 가시성을 먼저 고친다.
이 순서는 blocking/non-blocking 선택을 성능 구호가 아니라 운영 판단으로 바꾸기 위한 루틴이다.
실전 팁
- 현재 병목이 thread 점유인지, downstream latency인지, CPU 계산인지 먼저 나눈다.
- MVC에서 충분히 해결되는 문제라면 timeout, pool, bulkhead, pagination부터 고친다.
- non-blocking 전환 전에는 event loop blocking 검출, queue metric, backpressure 정책을 준비한다.
- JDBC, legacy SDK, 파일 I/O가 많은 서비스는 reactive 외피만 씌워도 효과가 제한적이다.
- 모델 전환의 성공 기준은 평균 latency가 아니라 p95/p99, thread 수, queue, error rate로 둔다.
주니어 팁
Blocking Non-blocking 실전 판단주제는 용어 정의보다 장애 때 어떤 증거로 확인할지까지 연결해 익힌다.- 정상 상태에서 이 문서의 관찰 명령을 실행해
Blocking Non-blocking 실전 판단기준선을 남긴다. - 장애 시에는
Blocking Non-blocking 실전 판단신호가 평소 기준선에서 벗어난 시각과 방향을 먼저 본다.
시니어 팁
Blocking Non-blocking 실전 판단주제의 영향이 pool, queue, retry, timeout으로 번지는 경로를 설계 리뷰에 포함한다.Blocking Non-blocking 실전 판단runbook에는 실행 명령, 정상 범위, 해석 기준, 금지할 대응을 같이 둔다.Blocking Non-blocking 실전 판단판단이 container, LB, 다중 인스턴스 환경에서도 같은 의미인지 확인한다.
Guru급 팁
Blocking Non-blocking 실전 판단주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
Blocking Non-blocking 실전 판단가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. Blocking Non-blocking 실전 판단조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
- “Reactive로 바꾸면 빨라진다”를 목표로 삼고 현재 병목을 측정하지 않는다.
- CPU bound 작업을 non-blocking으로 바꾸면 해결된다고 기대한다.
- blocking SDK를 event loop 안에서 호출한다.
- backpressure 없이 producer만 빠르게 만든다.
- 팀이 thread dump, event loop metric, reactive stack trace를 읽을 준비가 없다.
확인 질문
확인 질문
Blocking Non-blocking 실전 판단주제를 장애 중 확인할 때 Application 로그만으로 부족한 이유는 무엇인가?
- 로그는 코드 경로를 보여 주지만
Blocking Non-blocking 실전 판단의 JVM/OS 자원 상태, 대기 위치, 포화 방향은 별도 지표로 확인해야 하기 때문이다.Blocking Non-blocking 실전 판단관련 설정이나 pool 크기를 바꾸기 전에 확인할 것은 무엇인가?
- 먼저 변한 신호, 하위 자원 capacity, 변경이 완화인지 증폭인지 판단할 기준을
Blocking Non-blocking 실전 판단지표로 확인해야 한다.Blocking Non-blocking 실전 판단재발을 막기 위해 장애 기록에 무엇을 남겨야 하는가?
- 발생 시간, 영향 범위, 사용한 명령,
Blocking Non-blocking 실전 판단핵심 지표, 원인 판단, 완화 조치, 근본 수정, 남은 리스크를 남긴다.