# 리소스 소모 (Resource Consumption)

## 1. 개요
**리소스 소모(Resource Consumption)**란 컴퓨터 시스템의 하드웨어 및 소프트웨어 자원(CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등)이 특정 프로세스나 작업을 수행하기 위해 사용되는 양을 의미합니다.

컴퓨팅 환경에서 리소스는 한정된 자원이며, 특정 프로세스가 과도하게 리소스를 점유할 경우 다른 프로세스의 실행이 지연되거나 시스템 전체의 응답 속도가 저하되는 성능 저하 현상이 발생합니다. 최악의 경우 시스템이 완전히 멈추는 프리징(Freezing)이나 강제 종료 등의 불안정성으로 이어지므로, 효율적인 리소스 관리와 모니터링은 시스템의 가용성(Availability)과 안정성을 확보하는 데 필수적입니다. 단순한 사용량 측정을 넘어, 할당된 자원 대비 처리 성능의 효율성을 분석하고 임계치(Threshold)를 관리하는 것이 핵심입니다.

### 목차
* [2. 주요 리소스 유형 및 측정 지표](#2-주요-리소스-유형-및-측정-지표)
* [3. 리소스 소모의 주요 원인](#3-리소스-소모의-주요-원인)
* [4. 리소스 소모 분석 및 진단 방법](#4-리소스-소모-분석-및-진단-방법)
* [5. 임계치 설정 및 알람 (Threshold & Alerting)](#5-임계치-설정-및-알람-threshold--alerting)
* [6. 리소스 최적화 전략](#6-리소스-최적화-전략)
* [7. 클라우드 환경의 리소스 과금 모델](#7-클라우드-환경의-리소스-과금-모델)
* [8. 리소스 고갈 시 발생하는 현상과 대응](#8-리소스-고갈-시-발생하는-현상과-대응)

## 2. 주요 리소스 유형 및 측정 지표
시스템 운영 시 모니터링해야 할 핵심 리소스 항목과 그 측정 지표는 다음과 같습니다.

| 리소스 항목 | 주요 측정 지표 | 단위 | 주요 확인 사항 |
| :--- | :--- | :--- | :--- |
| **CPU** | Usage %, Load Average, **CPU Steal, I/O Wait** | %, $\text{load}$ | 프로세서 사용률, 대기 큐 길이, 가상화 환경 자원 탈취, 디스크 응답 대기 시간 |
| **RAM** | Used/Free Memory, Swap | GB, MB | 가용 메모리 잔량, 스왑 메모리 사용 여부(메모리 부족 징후) |
| **Disk** | IOPS, Throughput, Latency | IOPS, MB/s, ms | 초당 입출력 횟수, 데이터 전송 속도, 디스크 응답 지연 시간 |
| **Network** | Bandwidth, Packet Loss | Mbps, % | 네트워크 대역폭 점유율, 패킷 손실률, 연결된 세션 수 |

## 3. 리소스 소모의 주요 원인
리소스 소모의 급증은 크게 소프트웨어의 논리적 결함과 하드웨어의 물리적 제약이라는 두 가지 관점에서 분석할 수 있습니다.

### 3.1 소프트웨어 레벨의 논리적 오류
*   **비효율적인 알고리즘:** 시간 복잡도($O(n^2)$ 이상)가 높은 알고리즘을 사용하여 CPU 연산량이 기하급수적으로 증가하는 경우입니다.
*   **메모리 누수 (Memory Leak):** 할당된 메모리를 적절히 해제하지 않아 사용 가능한 메모리가 지속적으로 감소하는 현상입니다.
*   **과도한 컨텍스트 스위칭 (Context Switching):** 너무 많은 스레드나 프로세스를 생성하여 CPU가 실제 작업보다 상태 전환(Context Switch)에 더 많은 자원을 소모하는 현상입니다.
*   **데드락 (Deadlock):** 두 개 이상의 프로세스가 서로의 자원을 기다리며 무한 대기 상태에 빠져 CPU 자원을 낭비하거나 시스템을 정지시키는 경우입니다.

### 3.2 하드웨어 제약 및 병목 현상
*   **I/O 병목 (I/O Bottleneck):** CPU 처리 속도에 비해 디스크 읽기/쓰기 속도가 느려 CPU가 I/O 완료를 기다리며 유휴 상태(I/O Wait)에 머무는 현상입니다.
*   **네트워크 대역폭 제한:** 처리해야 할 데이터 양에 비해 네트워크 인터페이스의 전송 용량이 부족하여 패킷 지연 및 손실이 발생하는 경우입니다.

## 4. 리소스 소모 분석 및 진단 방법
시스템의 현재 상태를 진단하기 위해 OS별로 제공하는 다양한 모니터링 도구를 활용합니다.

### 4.1 OS별 대표 모니터링 명령어
```bash
# [Linux/Unix]
top       # 실시간 CPU, 메모리 사용량 및 프로세스 목록 확인
htop      # top의 확장 버전 (시각적 인터페이스 제공)
vmstat 1  # 1초 간격으로 가상 메모리, 프로세스, CPU 활동 통계 출력
iostat -x  # 디스크 I/O 상세 통계 확인
netstat -tnlp # 현재 네트워크 연결 상태 및 포트 확인

# [Windows]
taskmgr   # 작업 관리자 (GUI 기반 리소스 확인)
resmon    # 리소스 모니터 (상세 CPU, 메모리, 디스크, 네트워크 분석)
perfmon   # 성능 모니터 (장기적인 성능 데이터 수집 및 분석)
```

### 4.2 리소스 측정 도구 비교
| 도구 구분 | 도구명 | 주요 특징 | 장점 | 단점 |
| :--- | :--- | :--- | :--- | :--- |
| **CLI 도구** | `top`, `htop` | 실시간 프로세스 모니터링 | 가볍고 즉각적인 확인 가능 | 이력 관리(History) 불가 |
| **에이전트 기반** | `Prometheus`, `Zabbix` | 시계열 데이터 수집 및 알람 | 장기 추세 분석, 자동 알림 | 설치 및 설정 복잡도 높음 |
| **APM 도구** | `Datadog`, `New Relic` | 애플리케이션 내부 트랜잭션 추적 | 코드 레벨의 병목 지점 파악 | 높은 도입 비용 (유료) |

## 5. 임계치 설정 및 알람 (Threshold & Alerting)
모니터링 도구를 활용하는 궁극적인 목적은 리소스가 위험 수준에 도달하기 전 대응하는 것입니다. 이를 위해 각 리소스별로 **임계치(Threshold)**를 설정하고 알람 체계를 구축합니다.

*   **경고(Warning) 단계:** 리소스 사용량이 평소보다 높으나 서비스 영향은 적은 상태 (예: CPU 70% $\sim$ 80% 지속 시 알람 $\rightarrow$ 원인 분석 및 스케일 아웃 검토)
*   **심각(Critical) 단계:** 서비스 지연이나 장애가 발생할 가능성이 매우 높은 상태 (예: 메모리 90% 이상, 디스크 잔여 용량 10% 미만 $\rightarrow$ 즉시 긴급 대응 및 프로세스 최적화)
*   **알람 전송 경로:** Slack, Email, PagerDuty 등을 통해 담당자에게 실시간 통보하여 MTTR(Mean Time To Repair)을 단축합니다.

## 6. 리소스 최적화 전략
리소스 소모를 줄이고 시스템 효율을 극대화하기 위한 기술적 방안입니다.

### 6.1 일반 최적화 전략
*   **캐싱(Caching) 전략:** 반복적으로 요청되는 데이터는 Redis, Memcached와 같은 인메모리 저장소에 저장하여 디스크 I/O 및 DB 부하를 줄입니다.
*   **비동기 처리 (Asynchronous Processing):** 즉각적인 응답이 필요 없는 작업은 메시지 큐(RabbitMQ, Kafka)를 이용해 백그라운드에서 처리하여 사용자 응답 시간을 단축합니다.
*   **데이터 구조 최적화:** 데이터 특성에 맞는 적절한 자료구조(예: List $\rightarrow$ Hash Map)를 선택하여 탐색 및 처리 시간을 단축합니다.
*   **리소스 제한 (Quota/Limit):** 컨테이너 환경(Docker, Kubernetes)에서 `cpu limit` 및 `memory limit`을 설정하여 특정 서비스가 전체 시스템 자원을 독점하는 것을 방지합니다.

### 6.2 코드 레벨 최적화 예시
비효율적인 루프나 메모리 할당을 개선함으로써 리소스 소모를 획기적으로 줄일 수 있습니다.

*   **불필요한 객체 생성 방지:** 루프 내부에서 매번 새로운 객체를 생성하는 대신, 외부에서 생성 후 재사용하여 GC(Garbage Collection) 부하를 줄입니다.
*   **시간 복잡도 개선:** 중첩 루프($O(n^2)$)를 해시 맵을 이용한 단일 루프($O(n)$)로 변경하여 CPU 연산량을 감소시킵니다.
*   **Lazy Loading 적용:** 모든 데이터를 한 번에 로드하지 않고, 실제 필요한 시점에 로드하여 초기 메모리 점유율을 낮춥니다.

### [사례 연구] 최적화 전후 성능 비교
**시나리오:** 대량의 로그 데이터를 읽어 통계를 내는 배치 프로그램

| 구분 | 최적화 전 | 최적화 후 |
| :--- | :--- | :--- |
| **처리 방식** | 전체 로그 파일을 메모리에 한 번에 로드 | 스트림(Stream) 방식 순차 읽기 및 병렬 처리 |
| **메모리 사용량** | 16GB $\rightarrow$ 32GB (급증) | 2GB (일정하게 유지) |
| **처리 시간** | 120분 | 20분 |
| **결과** | OOM(Out of Memory) 발생 위험 높음 | 시스템 안정성 확보 및 처리 속도 6배 향상 |

## 7. 클라우드 환경의 리소스 과금 모델
클라우드 컴퓨팅(AWS, Azure, GCP 등)에서는 리소스 소모가 곧 비용으로 직결됩니다.

*   **종량제 모델 (Pay-as-you-go):** 사용한 CPU 시간, 메모리 용량, 네트워크 전송량(Egress)에 따라 비용을 지불합니다.
*   **예약 인스턴스 (Reserved Instances):** 일정 기간 사용을 약정하여 리소스를 확보하고 할인 혜택을 받는 모델입니다.
*   **오토 스케일링 (Auto-scaling):** 트래픽 증가 시 리소스를 자동으로 확장(Scale-out)하고, 감소 시 축소(Scale-in)하여 비용 효율성을 최적화합니다.
*   **주의사항:** 클라우드 환경에서는 '좀비 리소스'(사용하지 않지만 할당되어 있는 자원)가 비용 낭비의 주원인이 되므로 주기적인 리소스 정리가 필요합니다.

## 8. 리소스 고갈 시 발생하는 현상과 대응
리소스가 임계치에 도달하면 시스템은 자가 보호 기제나 장애 현상을 보입니다.

### 8.1 주요 장애 현상 및 에러 메시지
*   **OOM Killer (Out of Memory Killer):** 리눅스 커널이 메모리 부족 시 시스템 붕괴를 막기 위해 우선순위가 낮은 프로세스를 강제로 종료시키는 현상입니다.
    *   *에러 사례:* `Out of memory: Kill process 1234 (mysqld)`, `kernel: Out of memory: Kill process`
*   **스래싱 (Thrashing):** 메모리 부족으로 인해 가상 메모리와 물리 메모리 간의 페이지 교체(Paging)가 너무 빈번하게 일어나, 실제 작업보다 페이지 교체에 더 많은 CPU 시간을 쓰는 현상입니다.
*   **타임아웃 (Time-out):** CPU나 네트워크 리소스 고갈로 인해 요청에 대한 응답이 정해진 시간 내에 오지 않아 연결이 끊기는 현상입니다.
    *   *에러 사례:* `HTTP 504 Gateway Timeout`, `java.net.SocketTimeoutException: Read timed out`
*   **리소스 부족 일반 에러:**
    *   *메모리:* `java.lang.OutOfMemoryError: Java heap space`, `malloc failed: Cannot allocate memory`
    *   *디스크:* `No space left on device`, `Disk quota exceeded`
    *   *파일 핸들:* `Too many open files`

### 8.2 대응 및 재발 방지
1.  **긴급 조치:** 부하가 높은 프로세스 강제 종료(`kill -9`), 서비스 재시작, 임시 리소스 증설(Vertical Scaling).
2.  **아키텍처 개선:**
    *   **Scale-out:** 서버 대수를 늘려 부하를 분산하는 로드 밸런싱 도입.
    *   **Circuit Breaker:** 특정 서비스의 리소스 고갈이 전체 시스템으로 전이되지 않도록 연결을 차단하는 서킷 브레이커 패턴 적용.
    *   **Rate Limiting:** API 요청 횟수를 제한하여 과도한 리소스 소모를 사전에 방지.