이 블로그에서는 제가 직접 경험한 여러 실무 사례를 바탕으로, 근본 원인이 결국 세 가지 IIS 웹사이트 제한 설정으로 귀결되었던 문제들을 공유하고자 합니다. 겉으로 보기에 이 설정들은 UI에서 매우 직관적으로 느껴지지만, 실제 운영 환경에서는 예기치 못한 주요 장애의 원인이 되기도 합니다.
저는 이러한 설정들이 애플리케이션에 요청이 도달하기도 전에 타임아웃, 연결 끊김, 그리고 기괴한 성능 문제를 일으키는 것을 수없이 보았습니다. 앱 레벨에서는 모든 것이 정상으로 보이지만, 그 아래 단계에서 이미 문제가 발생하고 있다는 점이 이 설정들을 까다롭게 만드는 이유입니다.
이 글의 목적은 간단합니다. 여러분이 이러한 문제 패턴을 조기에 인식하도록 돕는 것입니다. 이러한 제한 설정들이 어떻게 작동하는지 이해하면 문제를 더 빠르게 핀포인트로 짚어낼 수 있고, 불필요한 문제 해결에 쏟는 시간을 줄일 수 있습니다.
자, 하나씩 파헤쳐 보겠습니다.
서론
IIS 호스팅 애플리케이션에서 성능 문제나 예상치 못한 연결 끊김을 조사할 때 흔히 간과하는 부분 중 하나가 바로 웹사이트 제한(Website Limits) 설정입니다.
이 설정은 다음 경로에서 확인할 수 있습니다:
IIS 관리자 → 사이트 → 작업 → 구성 → 제한(Limits)
이 설정들은 서버가 연결과 네트워크 사용량을 처리하는 방식을 제어하는 데 결정적인 역할을 합니다.
이 글에서는 가장 일반적으로 사용되는 세 가지 설정에 집중하겠습니다.
- 연결 타임아웃 (Connection Timeout)
- 대역폭 사용량 제한 (Limit Bandwidth Usage)
- 연결 수 제한 (Limit Number of Connections)
1. 연결 타임아웃 (초 단위)
기능
이 설정은 연결이 비활성 상태이거나 완료되지 않았을 때 IIS가 연결을 종료하기 전까지 유지하는 시간을 정의합니다.
- 기본값: 120초 (2분)
- 적용 대상:
- 유휴(Idle) 연결
- 느린 업로드
- 부하 상황에서 너무 오래 대기 중인 요청
중요성
다음과 같은 시나리오에서 영향이 두드러집니다:
- 실행 시간이 긴 API 호출
- 대용량 파일 업로드
- 클라이언트 네트워크 속도가 느린 경우
- 부하 발생 시 대기 열(Queue) 대기 시간이 길어질 때
잘못 설정되었을 때 발생하는 일반적인 문제
| 시나리오 | 관찰된 문제 |
|---|---|
| 너무 낮음 | 요청이 중간에 조기 종료됨 |
| 너무 높음 | 불필요하게 연결이 유지되어 자원 낭비 |
| 부하 발생 시 | 간헐적인 실패 및 타임아웃 발생 |
전형적인 오류 현상:
- 클라이언트: 연결 재설정(Connection reset) / 사이트에 연결할 수 없음
- 프록시: 502 / 504 오류
- 업로드: 부분 업로드 후 실패
실무 튜닝 가이드
설정값을 높여야 할 때:
- API 실행 시간이 오래 걸릴 때
- 사용자가 대용량 파일을 업로드할 때
설정값을 낮춰야 할 때:
- 유휴 연결이 너무 많을 때
- 느린 클라이언트 공격(Slow-client attacks)이나 연결 독점(Connection hoarding)을 방지해야 할 때
핵심 통찰: 이 설정은 HTTP.sys 수준에서 작동합니다. 즉, 요청이 애플리케이션에 도달하기 전에 실패할 수 있습니다.
2. 대역폭 사용량 제한 (바이트 단위)
기능
해당 웹사이트의 최대 아웃바운드 대역폭을 제한합니다. 체크박스를 활성화하면 IIS가 응답 속도를 제한(Throttling)합니다.
유용한 경우
- 멀티 테넌트(Multi-tenant) 서버
- 공유 인프라 환경
- 단일 애플리케이션이 네트워크를 독점하는 것을 방지할 때
잘못 설정되었을 때의 영향
| 조건 | 영향 |
|---|---|
| 너무 낮음 | 페이지 로딩 속도 저하 |
| 너무 엄격함 | 다운로드 시간이 매우 길어짐 |
| 작업량과 불일치 | CPU/메모리가 정상임에도 사용자 불만 제기 |
전형적인 증상:
- 페이지 로딩이 느림
- 파일 다운로드가 멈춤
- 스트리밍 버퍼링이 자주 발생함
- 업스트림 게이트웨이 타임아웃(504) 발생
실무 튜닝 가이드
사용할 때:
- 여러 애플리케이션 간에 공정한 자원 사용이 필요할 때
- 공유 호스팅 환경을 운영할 때
피해야 할 때:
- 전용 프로덕션 환경
- 성능이 최우선인 경우
중요 참고: 이 설정은 서버 부하를 줄여주는 것이 아니라, 단지 응답 속도를 늦추는 것뿐입니다.
3. 연결 수 제한
기능
웹사이트에 허용되는 최대 동시 연결 수를 제어합니다.
- 체크박스를 통해 활성화
- 제한치에 도달하면 IIS가 새로운 연결을 거부함
사용 이유
- 자원 고갈 방지
- 특정 애플리케이션의 과도한 트래픽 격리
- 공유 환경에서의 트래픽 제어
너무 낮게 설정되었을 때의 문제
| 시나리오 | 관찰된 문제 |
|---|---|
| 트래픽 급증 | 요청 거부됨 |
| 높은 동시성 | API 호출 실패 |
| 프록시 뒤에 위치 | 502 / 503 응답 발생 |
전형적인 오류 패턴:
- HTTP 503 (Service Unavailable)
- 앱 프로세싱이 시작되기도 전에 연결 실패
핵심 통찰 (프로덕션 환경에서 매우 중요)
설령 이 값을 **무제한(Unlimited)**으로 설정하더라도: 시스템은 여전히 CPU, 메모리, 스레드 및 백엔드 종속성에 의해 제한을 받습니다.
이 값을 무작정 늘리는 것은:
- 성능 문제를 해결해주지 않습니다.
- 오히려 부하 상황에서 장애를 증폭시킬 수 있습니다.
실무 튜닝 가이드
제한을 설정할 때:
- 제어된 백프레셔(Back-pressure)가 필요할 때
- 공유 시스템을 보호해야 할 때
장애 발생 시 무분별한 제한 상향은 피하십시오. 대신 다음을 먼저 조사해야 합니다:
- CPU 사용률
- 애플리케이션 풀 큐(Queue)
- 스레드 고갈(Thread starvation)
- 종속 서비스의 지연
문제 해결 팁 (Troubleshooting TIPS)
사용자가 다음과 같은 증상을 보고할 때:
- 무작위 502 / 504 오류
- 업로드 실패
- 간헐적인 연결 끊김
항상 다음을 먼저 확인하세요:
- 연결 타임아웃
- 대역폭 제한
- 연결 수 캡(Cap)
이유: 이 설정들은 여러분의 코드가 실행되기도 전에 요청을 거절하거나 종료할 수 있기 때문입니다.
요약
| 설정 | 제어 항목 | 일반적인 문제 |
|---|---|---|
| 연결 타임아웃 | 유휴 요청 유지 시간 | 타임아웃, 연결 끊김 |
| 대역폭 제한 | 응답 속도 | 속도 저하 |
| 연결 수 제한 | 동시 요청 수 | 503 오류 |
실무 사례: IIS 웹사이트 제한이 프로덕션 장애를 일으키는 경우
구성을 이해하는 것도 중요하지만, 장애 발생 시 패턴을 인식하는 것이 진짜 실력입니다. 아래는 IIS 웹사이트 제한이 프로덕션 시스템에 직접적인 영향을 미쳤던 실제 사례들입니다.
시나리오 1: 간헐적인 502 / 504 오류 (연결 타임아웃 불일치)
상황
- 애플리케이션이 Azure Application Gateway / Nginx / ARR 뒤에 호스팅됨
- 사용자가 무작위 실패 및 API 호출 실패를 보고함
관찰된 현상
- IIS 로그: 일부 요청에 대해 **sc-status = 200 (성공)**으로 기록됨
- 하지만 사용자: 게이트웨이로부터 502 / 504 오류를 받음
근본 원인
- IIS 연결 타임아웃 = 120초
- 업스트림 프록시 타임아웃 = 60초
결과: 프록시가 먼저 타임아웃되어 504를 반환하지만, IIS는 계속 처리 중이라 클라이언트는 정상적인 응답을 받지 못함.
해결 방법
계층 간 타임아웃 설정 맞춤:
- 앱 게이트웨이 / 프록시 타임아웃 ≥ IIS 연결 타임아웃
- IIS 타임아웃을 실제 요청 처리 시간에 맞게 조정
핵심 교훈
타임아웃은 개별적으로 보지 말고 항상 **체인(Chain)**으로 취급해야 합니다.
시나리오 2: 대용량 파일 업로드 실패 (연결 타임아웃 너무 낮음)
상황
- 사용자가 대용량 파일(100MB+)을 업로드함
- 특히 네트워크가 느린 환경에서 업로드가 무작위로 실패함
관찰된 현상
- 업로드가 중간에 중단됨
- 애플리케이션 예외 로그가 남지 않음
- 연결이 갑자기 끊김
근본 원인
- 클라이언트가 요청 본문(Request body)을 천천히 보내는 동안 IIS 연결 타임아웃에 도달함
- 업로드가 완료되기 전에 HTTP.sys가 연결을 강제 종료함
해결 방법
- 연결 타임아웃 증가
- 느린 네트워크 시뮬레이션을 통해 검증
핵심 교훈
연결 타임아웃은 유휴 상태뿐만 아니라 느린 요청 본문 전송 시에도 적용됩니다.
시나리오 3: 트래픽 급증 시 HTTP 503 발생 (연결 수 제한 너무 낮음)
상황
- 이벤트나 배포 직후 트래픽이 갑자기 급증함
- API가 실패하기 시작함
관찰된 현상
- IIS 로그: 503 Service Unavailable
- 사용자: 무작위 접속 실패
- CPU 사용률: 50% 미만 (시스템은 과부하 상태가 아님)
근본 원인
- "연결 수 제한"이 활성화되어 있었고, 설정값이 너무 낮았음
- 임계치에 도달하자마자 IIS가 새로운 연결을 거부함
해결 방법
- 연결 수 제한 상향 조정 또는 필요 없는 경우 제한 해제
- 실제 동시 접속자 수와 설정된 제한 값 비교 검증
핵심 교훈
503 오류가 항상 서버 과부하를 의미하는 것은 아닙니다. 의도적인 제한 설정에 의한 거부일 수 있습니다.
시나리오 4: 리소스는 널널한데 사이트가 느림 (대역폭 제한 활성화)
상황
- 사용자가 페이지 로딩과 다운로드가 매우 느리다고 보고함
관찰된 현상
- CPU/메모리: 정상
- 스레드 경합 없음
- 하지만 응답 시간(Response time)이 비정상적으로 높음
근본 원인
- IIS에 **"대역폭 사용량 제한"**이 활성화되어 있었고, 값이 매우 낮게 설정됨
- IIS가 의도적으로 응답 속도를 늦추고 있었음
해결 방법
- 대역폭 제한 비활성화 또는 현실적인 수준으로 상향
핵심 교훈
대역폭 제한은 시스템 병목이 아니라 인위적인 느림을 유발합니다.
시나리오 5: 부하 상황에서의 무작위 끊김 (연결 타임아웃 + 대기열 지연)
상황
- 높은 트래픽 발생 시 일부 요청은 성공하고 일부는 실패함
관찰된 현상
- 요청이 애플리케이션 풀 큐(App pool queue)에서 대기함
- 실행이 시작되기도 전에 요청이 실패함
근본 원인
- 요청이 대기열에서 너무 오래 대기하여 실행 전에 연결 타임아웃에 도달함
해결 방법
- 단기적으로 타임아웃 증가
- 근본 원인 해결: 스레드 고갈 해결 또는 느린 백엔드 종속성 최적화
핵심 교훈
타임아웃은 요청 실행이 시작되기 전에도 발생할 수 있습니다.
기억해야 할 문제 해결 패턴
IIS 문제를 분석할 때 증상을 보고 빠르게 매칭해 보세요:
| 증상 | 의심되는 설정 |
|---|---|
| 502 / 504 (간헐적) | 연결 타임아웃 불일치 (프록시 vs IIS) |
| 업로드 실패 | 연결 타임아웃 |
| 부하 시 503 오류 | 연결 수 제한 |
| 리소스는 괜찮은데 무조건 느림 | 대역폭 제한 |
| 무작위 연결 끊김 | 타임아웃 또는 대기열(Queue) 지연 |
마무리 제언
실제 운영 환경에서 IIS 제한 설정은 단독으로 작용하기보다 기존 시스템의 동작을 증폭시키는 역할을 합니다. 잘 관리된 시스템은 다음과 같은 특징을 가집니다:
- 모든 계층(L7, 프록시, IIS, App)의 타임아웃이 일관되게 정렬되어 있음
- 불필요한 제한 설정을 지양함
- 제한 설정을 문제를 덮는 용도가 아닌, 시스템 보호 용도로 사용함