🤔 서버는 3대인데 왜 응답이 10초 이상이 걸릴까?

JY·2025년 10월 20일

Spring

목록 보기

6/7

⚠️ Issue

Python-Ansible 기반으로 리눅스 서버들을 일괄 관리하는 웹 서비스를 개발하던 중, E2E 테스트 단계에서 응답 속도 문제가 치명적으로 드러났다.

서비스는 Ansible 플레이북을 실행하기 전에, 대상 서버들이 실제로 살아 있는지(Port, SSH, Ping 등) 사전 점검하는 로직을 포함하고 있었는데, 등록된 서버가 단 3대뿐임에도 전체 상태 조회에 10초 이상이 소요되거나, 심한 경우 프론트엔드 렌더링이 아예 실패하는 상황까지 발생했다.

웹 대시보드 입장에서는 사용자가 “상태 새로고침” 한 번 했을 뿐인데, 결과가 오기까지 지연이 발생하거나 타임아웃으로 인해 빈 화면이 노출되는 셈이었다.
운영 환경에서는 수십~수백 대의 서버가 등록될 수 있다는 점을 고려하면, 3대에서 이미 10초라면 100대 이상에서는 서비스가 사실상 동작할 수 없는 구조라는 냉정한 결론이 나온다.

조사 결과, 문제의 핵심 원인은 단순했다.

서버 점검이 순차적으로 진행되면서, 응답이 없는 서버에 대해 타임아웃(최대 10초) 을 매번 기다리고 있기 때문이었다.

즉, "서버 개수 × 타임아웃" 만큼 대기하는 구조가 숨어 있었고, 이 방식은 서버 수가 늘어날수록 응답 시간이 선형적으로 느려지는 병목 구조를 만들고 있었다.

✅ 아키텍쳐 및 병목 발생지점 - 구조를 이해하면 문제는 더 명확해진다.

해당 서비스는 웹에서 모든 서버의 현재 상태를 한 번에 조회한 뒤, 이상이 없는 서버들에 대해서만 Ansible 플레이북을 실행하도록 설계되어 있었다. 즉, “서버 상태 조회”는 Ansible 실행 이전의 사전 필터링 역할을 하는 핵심 단계였고, 이 단계가 느려지는 순간 전체 시나리오가 모두 느려질 수밖에 없는 구조였다.

서비스 레이어의 의존성 관계는 아래와 같았다.

[LinuxServerService]
  ├─ linuxServerRepository            ← DB 서버 목록 조회 (Mongo/SQL 등 영속성)
  ├─ inspector : SshRemoteInspector   ← 서버 상태 확인(Ping, SSH 연결, 포트 체크 등 네트워크 I/O)
  ├─ deployer : SshDeployer           ← 실제 배포/명령 실행 책임 (SSH 명령, 스크립트 수행)
  ├─ props : AnsibleProperties        ← YAML/Properties 설정 매핑 (환경 변수/경로/timeout 등)
  └─ mongoTemplate                    ← 필요 시 커스텀 쿼리용


[SshRemoteInspector]
  ├─ CommandBuilder   ← nc/ssh 명령 생성
  └─ ProcessRunner    ← 명령 실행 + 타임아웃 제어

문제의 흐름은 단순했다.

사용자 요청 → Service → Repository에서 서버 목록 조회
               → inspector.probNetwork(server1)
               → inspector.probNetwork(server2)
               → inspector.probNetwork(server3)
               → ... 모든 서버 확정 후 응답 반환

이 방식은 코드 상으로는 무난해 보인다. 하지만 “네트워크 I/O는 언제든 느릴 수 있다”는 단 하나의 현실적인 조건을 간과하고 있었다. 예를 들어, 다음과 같은 상황이 발생했다고 하자.

server1 : 200~300ms 내 응답
server2 : 200~300ms 내 응답
server3 : 아예 응답 없음 (포트 타임아웃 8~10초)

순차 구조에서는 server3의 타임아웃이 끝날 때까지 전체 로직이 멈춰서 기다릴 수밖에 없다. 결국 결과는 아래와 같이 된다.

0.3초 + 0.3초 + 10초 = 약 10.6초

이건 딱 3대일 때 이야기다.

서버가 10대가 되고, 그중 3대만 응답이 없으면? → 최대 30초
서버가 100대가 되면? → 100초 ~ 수백 초

바로 이 지점에서 “순차 처리”는 확장 불가능한 구조(Non-Scalable Architecture) 로 판정된다.

즉, 이 문제는 속도의 문제가 아니고 “구조적 병목” 의 문제였다.

⛔ 순차식 방식의 한계

정리하면, 기존 구조의 문제는 딱 두 가지로 요약된다.

한계	설명
병렬성이 없음	여러 서버를 동시에 체크하지 못하고 “한 줄로 순서대로” 검사
Fail-Fast 부재	응답 없는 서버도 끝까지 기다리며 전체 응답을 가로막음

이 구조는 서버가 3대일 때는 “음… 느리지만 돌아가네” 수준일 뿐,
운영 단계에서 서버가 50대, 100대로 늘어나는 순간 시스템 전체가 무너진다.

따라서 개선 방향은 자연스럽게 도출된다.

✅ “동시에 검사하고, 응답 없는 서버는 빠르게 버리고, 전체 요청의 상한을 제한한다.”

✅ 해결 전략

여기서 적용한 개선 전략은 다음 3가지다.

전략	의미
Parallel(동시 실행)	서버 수와 상관없이 한 번에 점검
Fail-Fast(빠른 포기)	응답 없는 서버는 1~2초 내 TIMEOUT 처리
Global Timeout(전체 한도)	서버가 100대여도 전체 조회는 2~3초 내 완료

고작 “비동기 + 타임아웃” 같은 단순한 키워드가 아니다.
이 세 가지는 운영 가능한 시스템이 반드시 가져야 하는 네트워크 I/O 안정장치다.

🎯 개선된 코드 스냅샷

LinuxServerService.java

// 병렬 + Fail-Fast + Global Timebox
public NetworkStatusResponse probNetworkForServers(String groupName) throws Exception {
		List<LinuxServer> servers = linuxServerRepository.findByGroupName(groupName);
        if (servers.isEmpty()) return new NetworkStatusResponse(groupName, List.of());

        int poolSize = Math.min(
                Math.max(8, Runtime.getRuntime().availableProcessors() * 2),
                Math.max(8, servers.size()));
        ExecutorService ex = Executors.newFixedThreadPool(poolSize);

        try {
            List<CompletableFuture<NetworkStatusResponse.Item>> futures =
                    servers.stream()
                            .map(s -> CompletableFuture.supplyAsync(() -> {
                                                NetProbe np = inspector.probNetwork(
                                                        s.getUserId(),
                                                        s.getIpAddress(),
                                                        s.getPort()
                                                );

                                                return new NetworkStatusResponse.Item(
                                                        s.getId(),
                                                        s.getIpAddress(),
                                                        s.getUserId(),
                                                        np.state(),
                                                        np.detail()
                                                );
                                            }, ex)
                                            .orTimeout(2, TimeUnit.SECONDS) // 개별 Fail-Fast
                                            .exceptionally(e -> new NetworkStatusResponse.Item(
                                                    s.getId(),
                                                    s.getIpAddress(),
                                                    s.getUserId(),
                                                    NetState.TIMEOUT,
                                                    "timeout/" + e.getClass().getSimpleName()
                                            ))
                            ).toList();
            CompletableFuture<Void> all =
                    CompletableFuture.allOf(futures.toArray(new CompletableFuture[0]));
            try {
                // 전체 타임박스(예: 2500ms) — 다 안 끝나도 여기서 종료
                all.get(2500, TimeUnit.MILLISECONDS);
            } catch (Exception ignored) {}

            List<NetworkStatusResponse.Item> items = futures.stream()
                    .map(f -> f.getNow(null))
                    .filter(Objects::nonNull)
                    .toList();
            return new NetworkStatusResponse(groupName, items);
        } finally {
            ex.shutdown();
    }

CommandBuilder.java

개별 단계 타임아웃을 1–2초로 고정 (CommandBuilder에서 이미 단축된 옵션 사용)

nc -n -w 2, ssh -o ConnectTimeout=2 -o ConnectionAttempts=1).

✅ 개선 후 결과

항목	개선 전	개선 후
3대 서버 조회	10 ~ 12초	2 ~ 2.5초
렌더링 실패	빈번	없음
구조 확장성	취약	우수 (100대 이상 대응 가능)
사용자 경험	지연·끊김	즉시 응답

이번 이슈를 통해 얻은 교훈은 명확했다. 속도 최적화의 문제가 아닌 구조적 한계라는 점이다.

“네트워크 I/O를 다루는 서비스에서 순차 처리와 무제한 타임아웃은 반드시 병목을 만든다. 확장 가능한 구조를 원한다면 병렬성(Concurrency)과 타임박스(Time-bound)가 기본 전제가 되어야 한다.”

서비스는 이제 서버 수와 무관하게 안정적인 응답 속도를 유지하며,
운영자가 실시간으로 서버 상태를 빠르게 파악할 수 있는 형태로 개선되었다.