추천 API가 느려졌는데 로그인도 함께 지연됩니다. 공유 워커나 연결 풀이 원인이라면 어떻게 격리하나요?

기능이 논리적으로 분리돼 있어도 같은 스레드 풀이나 연결 풀을 쓰면 장애가 전파될 수 있습니다. 저는 요청 경로별로 공유하는 실행 자원을 먼저 그려 보겠습니다. 느린 외부 기능이 모든 워커를 차지하면 핵심 기능도 실행하지 못하기 때문입니다.

워커 10개를 두 기능이 공유하는 상황에서 추천 요청 10개가 외부 응답을 기다리면, 로그인 코드가 가벼워도 실행할 워커를 얻지 못할 수 있습니다. 로그인용 실행 예산을 따로 확보하면 추천의 대기가 그 예산까지 차지하지 못합니다. 다만 두 풀 아래의 DB가 같다면 그 공통 병목은 그대로 남습니다.

추천 API가 느려지는 동안 로그인 요청까지 지연된다면, 두 기능이 같은 풀에서 기다리는지 확인하겠습니다. 핵심 기능에 필요한 실행·연결 예산을 따로 확보하고, 느린 의존성에는 제한된 전용 풀을 둘 수 있습니다. 배의 구획처럼 한쪽이 차도 다른 쪽을 유지하는 벌크헤드 격리입니다. 단, 풀을 분리했다고 호스트 CPU와 메모리, 공통 DB까지 독립된 것은 아닙니다.

격리를 너무 잘게 하면 한쪽 자원이 놀아도 다른 쪽이 못 쓰는 비용이 생깁니다. 저는 중요도와 실패 상관관계가 다른 경계부터 나누고, 정상 시 이용률과 장애 시 핵심 기능의 지연을 비교하겠습니다. 선택 기능이 실패하면 제한 시간 안에 생략할 수 있게 하되 핵심 기능의 결과는 정직하게 돌려줘야 합니다. 검증은 일부 의존성만 지연·실패시키면서 다른 기능의 성공률이 유지되는지 보는 방식으로 하겠습니다.

코드의 경계가 아니라 자원의 경계를 나눕니다

추천과 로그인이 다른 클래스에 있어도 같은 실행 자원을 쓰면 한쪽의 지연이 다른 쪽으로 번집니다. 한 기능이 사용할 자원의 범위를 제한해 실패가 퍼지는 범위를 줄이는 접근을 벌크헤드 격리(bulkhead isolation)라고 부릅니다. 한 세입자의 과도한 사용이 다른 세입자의 성능을 떨어뜨리는 현상은 시끄러운 이웃 문제(noisy neighbor)입니다. 둘 다 공유 자원에서 생기지만, 모든 사용자를 별도 서버로 분리해야만 해결되는 것은 아닙니다. 중요한 요청이 필요한 최소 용량을 다른 요청이 모두 가져가지 못하게 하는 것이 출발점입니다.

먼저 추천과 로그인 요청이 지나가는 실행기, HTTP 연결 풀, DB 연결 풀, 메모리 버퍼를 그리겠습니다. 워커만 나눴는데 추천 호출이 공용 HTTP 연결을 모두 사용한다면 로그인은 여전히 연결을 기다립니다. DB 연결을 따로 확보해도 같은 DB의 CPU나 I/O를 추천 쿼리가 포화시키면 영향이 남습니다. 무엇을 격리했고 무엇이 아직 공유되는지 명시해야 합니다. 별도 프로세스도 CPU·메모리 제한과 저장소 용량을 나누지 않으면 완전한 장애 격리가 아닙니다.

예약 용량과 이용률 사이에서 선택합니다

로그인에 최소 실행 예산을 보장하고 추천에는 작은 상한을 두면 장애 중에도 핵심 경로가 살아남기 쉽습니다. 반면 평소 로그인이 한산해도 추천이 예약 자원을 못 쓰면 자원이 낭비될 수 있습니다. 공용 여유 용량을 빌려 쓰는 방식을 추가할 수 있지만, 빌려 간 요청이 취소 불가능한 긴 외부 호출이라면 로그인 폭주 때 즉시 회수할 수 없습니다. 따라서 예약분은 실제로 보호하고 공유분만 탄력적으로 쓰는 식으로 구분하겠습니다. 단순히 높은 우선순위를 붙이는 것만으로 이미 점유된 연결이 돌아오지는 않습니다.

한쪽이 가득 찼을 때의 동작도 기능별로 정합니다. 추천 목록은 짧은 데드라인 뒤 생략하거나 유효한 캐시로 대체할 수 있습니다. 핵심 기능을 유지하면서 선택 기능의 품질을 낮추는 것을 점진적 기능 저하(graceful degradation)라고 부릅니다. 하지만 로그인 권한 조회가 실패했는데 캐시가 없다는 이유로 허용으로 처리하면 안 됩니다. 대체 결과가 사용자 계약과 보안을 지키는지 확인해야 합니다. 또한 추천 실패를 숨긴 HTTP 200만 집계하면 장애가 안 보이므로 선택 기능의 누락률은 별도로 남기겠습니다.

격리의 효과는 부분 장애에서 확인합니다

정상 부하 시험만으로는 격리가 잘됐는지 알기 어렵습니다. 추천 API만 느리게 만들고 로그인 입력률을 유지해 로그인 p99·성공률·연결 대기를 측정하겠습니다. 추천 대기열 상한과 메모리도 함께 봐야 합니다. 인스턴스를 늘렸을 때 각 전용 풀의 합계가 외부 시스템 한도를 넘지 않는지도 확인합니다. 이처럼 장애가 미치는 최대 범위를 장애 영향 범위(blast radius)라고 정리할 수 있습니다. 목표는 모든 기능이 언제나 정상인 상태가 아니라, 한쪽 실패가 약속한 경계를 넘지 않고 핵심 기능이 회복 가능한 상태를 유지하는 것입니다.