# Node.js 앱 확장 및 자동 확장

Source: https://support.kapsulehost.com/ko-kr/site-scaling-and-autoscale

자동 스케일링은 CPU 부하가 변함에 따라 Node.js 앱을 실행하는 인스턴스 수를 늘리고 줄여서, 바쁜 시간대에는 용량을 늘리고 한가한 시간대에는 비용을 줄여줍니다. 이 가이드는 KPanel 탭, 모든 설정, 과금 대상, 그리고 앱을 안전하게 스케일링하는 방법을 다룹니다.

## KPanel에서 스케일링 설정 위치

1. [KPanel](https://kpanel.kapsulehost.com)에 로그인합니다.
2. 왼쪽 사이드바에서 **웹사이트**를 클릭한 다음 해당 사이트를 클릭합니다.
3. 사이트의 왼쪽 메뉴에서 **성능**를 연 다음 **스케일링**을 엽니다.

직접 주소는 `/websites/<site-id>/autoscale`입니다. 이전의 `/websites/<site-id>/scaling` 주소도 여전히 작동하며 같은 곳으로 연결됩니다.

![KPanel의 Node.js 앱 자동 스케일링 설정](https://support.kapsulehost.com/help/screenshots/site-scaling-and-autoscale.a7af79de.webp)

> **Note:** 이 탭은 Node.js 사이트에만 표시됩니다. WordPress, WooCommerce, 정적 사이트, PHP, Python, Ruby 사이트의 메뉴에는 나타나지 않습니다. 이 메커니즘이 Node.js 프로세스 클러스터를 스케일링하기 때문입니다.

## 하나의 탭, 하나의 설정

예전에는 KPanel에 **스케일링**과 **자동 스케일**이라는 두 개의 탭이 하나의 설정 세트 위에 존재했습니다. 이 둘은 같은 설정을 보는 두 가지 방식일 뿐이었고, 혼란만 가중시켰기 때문에 이제는 실시간 상태, 설정, 최근 스케일 이벤트, 현재 결제 기간의 사용량 및 비용 패널을 모두 한곳에 담은 단일 **스케일링** 탭으로 통합되었습니다.

## 작동 방식

앱은 프로세스 클러스터로 실행됩니다. 자동 스케일링은 실행 중인 인스턴스 전체의 평균 CPU를 감시하며, 설정한 임계값에 따라 인스턴스를 추가하거나 제거합니다.

클러스터 모드가 필요합니다. 앱이 아직 클러스터 모드로 실행되고 있지 않다면, 자동 스케일링을 활성화할 때 자동으로 전환되며 이 과정에서 짧은 재시작이 발생합니다. 이 일이 일어날 때 페이지에서 알려줍니다.

## 실시간 상태 읽기

상태 카드에는 세 가지가 표시됩니다:

- **Instances**: 현재 실행 중인 인스턴스 수.
- **평균 CPU**: 해당 인스턴스들의 평균 CPU.
- **Cluster**: 앱이 클러스터 모드인지 여부. "아니오"로 표시되면 자동 스케일링을 활성화하면 전환됩니다.

앱이 전혀 실행되고 있지 않으면, 카드는 0을 표시하는 대신 그 사실을 알려줍니다.

탭에는 가장 최근 스케일 이벤트 시각을 나타내는 **마지막 스케일**도 표시되며, 이벤트가 없으면 **never**로 표시됩니다.

## 설정 항목

| 설정 | 범위 | 무엇을 하는가 |
|---|---|---|
| 최소 인스턴스 | 1에서 16 | 하한선. 이 값 아래로는 절대 스케일 다운되지 않음 |
| 최대 인스턴스 | 1에서 16 | 상한선. 이 값 위로는 절대 스케일 업되지 않음 |
| CPU % 이상 확장 | 5에서 99 | 평균 CPU가 이 값을 넘으면 인스턴스 추가 |
| CPU % 이하 축소 | 1에서 95 | 평균 CPU가 이 값 아래로 떨어지면 인스턴스 하나 제거 |
| 쿨다운 (초) | 30에서 3600 | 스케일 작업 간 최소 대기 시간 |

메인 스위치는 설정 카드 상단의 토글입니다. 자동 스케일링이 꺼져 있으면 설정 항목이 흐리게 표시되며 앱은 현재 인스턴스 수를 그대로 유지합니다.

합리적인 초기 값:

- **최소 인스턴스는 1 또는 2.** 단일 인스턴스 재시작으로 인해 앱이 오프라인이 되는 상황을 용납할 수 없다면 2로 설정하세요.
- **최대 인스턴스**는 상한값이 아니라, 피크 시점에 기꺼이 지불할 의향이 있는 수준으로 설정하세요.
- **스케일 업은 약 70퍼센트 부근으로.** 사용하지 않는 여유 용량에 비용을 지불하지 않을 만큼 충분히 높으면서도, 요청이 쌓이기 시작하기 전에 용량을 추가할 시간이 있을 만큼 낮게 설정합니다.
- **스케일 다운은 약 30퍼센트 부근으로.** 두 임계값 사이에 넓은 간격을 두세요.
- **쿨다운은 몇 분 정도로.** 이 설정은 가장 과소평가되는 항목입니다.

> **Warning:** 두 CPU 임계값을 너무 가깝게 설정하면 요동(flapping)이 발생합니다. 클러스터가 스케일 업한 직후, 부하가 더 넓게 분산되어 바로 스케일 다운 임계값 아래로 떨어지고, 스케일 다운되었다가 다시 급증하는 과정이 반복됩니다. 두 임계값 사이에 넓은 간격을 두고, 넉넉한 쿨다운을 사용하세요. 요동은 비용을 발생시키고 앱을 불안정하게 만듭니다.

## 스케일 이벤트

탭에는 최근 스케일 이벤트가 최신순으로 나열되며, 각 항목은 방향, 변경 전후의 인스턴스 수, 트리거된 CPU 수치, 그리고 시각을 보여줍니다.

앱이 오작동했을 때 확인해야 할 로그가 바로 이것입니다. 몇 분 사이에 스케일 업/다운 이벤트가 몰아서 발생했다면 임계값이 너무 가깝거나 쿨다운이 너무 짧다는 뜻입니다. 한 번 스케일 업된 후 다시 내려오지 않았다면 부하가 계속 높게 유지되었다는 뜻이며, 이는 설정 문제가 아니라 용량 문제입니다. 예상했던 이벤트가 전혀 없다면 CPU가 임계값을 넘은 적이 없거나 자동 스케일링이 꺼져 있다는 뜻입니다.

## 자동 스케일링 비용

플랜의 기본 할당량을 초과하는 인스턴스는 초 단위로 계측되어 과금됩니다. 탭에는 현재 기간에 대해 다음이 표시됩니다:

- **사용된 인스턴스 시간**: 시간과 분 단위로 표시되며, 그 아래에 원시 인스턴스 초 값이 함께 표시됩니다.
- **현재까지 사용 금액**: 이번 기간에 현재까지 사용한 금액.
- **월말 예상치**: 지금까지의 사용량을 바탕으로 추정한 월말 예상치.
- **Tracking**: 기록된 전체 사용량 구간 중 실제로 과금된 구간 수.
- **기간 진행률**: 해당 월의 전체 일수 중 경과한 일수.

초당 요금은 같은 패널 상단에 표시되므로, 과금 기준이 되는 수치를 해당 사용량 바로 옆에서 항상 확인할 수 있습니다.

> **Tip:** 예상치는 주의 깊게 지켜봐야 할 숫자입니다. 이는 지금까지의 사용량을 바탕으로 추정한 값이므로, 월초에 유난히 바빴던 한 주가 있으면 수치가 과장될 수 있습니다. 며칠 지난 시점과 월 중순에 다시 확인한 뒤 결론을 내리세요. 수치가 원하는 것보다 높다면, 스케일 업 임계값을 올리기보다는 최대 인스턴스 수를 낮추세요. 상한선은 절대적인 한계이지만, 임계값은 단지 힌트일 뿐입니다.

최소값까지 스케일 다운하면 계측이 중단됩니다. 자동 스케일링을 완전히 끄면 앱은 현재 인스턴스 수를 그대로 유지하므로, 비용 절감이 목적이라면 끄기 전에 먼저 최소값으로 낮추세요.

## 앱을 안전하게 스케일링 가능하게 만들기

페이지에는 경고가 표시되며, 이것이 가장 중요한 내용입니다. Node.js 앱은 여러 인스턴스에 걸쳐 깔끔하게 스케일링되려면 클러스터 안전(cluster-safe)해야 합니다.

실제로 이는 다음을 의미합니다:

**메모리 내 세션 상태를 사용하지 말 것.** 로그인한 사용자의 세션이 한 인스턴스의 메모리에만 있으면, 다른 인스턴스로 요청이 들어갈 때마다 로그아웃됩니다. 세션을 공유 저장소로 옮기세요.

**정확성을 위해 의존하는 메모리 내 캐시를 사용하지 말 것.** 각 인스턴스는 자신만의 캐시를 가집니다. 일관성이 보장되어야 하는 캐시는 반드시 공유되어야 합니다.

**다시 읽을 것으로 기대하는 로컬 파일시스템 쓰기를 하지 말 것.** 한 인스턴스가 로컬 디스크에 쓴 업로드 파일은 다른 인스턴스에서 보이지 않습니다. 공유 스토리지에 쓰세요.

**보호되지 않은 예약 작업을 사용하지 말 것.** 앱 내부에서 타이머가 실행되면 모든 인스턴스가 이를 실행하므로, 인스턴스가 네 개면 야간 작업이 네 번 실행됩니다. 예약 작업은 cron 작업으로 옮기거나 잠금(lock)으로 보호하세요. [Cron Jobs](https://support.kapsulehost.com/ko-kr/cron-jobs)를 참고하세요.

**인스턴스 수가 고정되어 있다고 가정하지 말 것.** 인스턴스 인덱스로 작업을 분할하는 로직은 인스턴스 수가 바뀌는 순간 깨집니다.

앱에 위 사항 중 하나라도 해당한다면, 자동 스케일링을 활성화하기 전에 먼저 수정하세요. 클러스터 안전하지 않은 앱은 간헐적이고 재현하기 어려운 방식으로 오류를 일으킵니다. 어떤 인스턴스가 어떤 요청을 처리했는지에 따라 결과가 달라지기 때문입니다.

## 문제 해결

**토글이 활성화되지 않습니다.** 활성화하려면 사이트 쓰기 권한이 필요합니다. 읽기 전용 역할에서는 컨트롤이 비활성화됩니다.

**자동 스케일링을 활성화했더니 앱이 재시작되었습니다.** 예상된 동작입니다. 클러스터 모드로 전환하려면 재시작이 필요하며, 한 번만 발생합니다.

**사용자가 무작위로 로그아웃됩니다.** 전형적인 클러스터 비안전 증상입니다. 세션이 메모리에 있고 요청이 서로 다른 인스턴스로 들어가고 있는 상태입니다.

**인스턴스가 스케일 업된 후 다시 내려오지 않았습니다.** 부하가 스케일 다운 임계값 위에 계속 머물러 있거나, 트래픽과 무관하게 무언가가 CPU를 높게 유지하고 있는 것입니다. 이벤트 목록을 확인하고 앱이 실제로 무엇을 하고 있는지 살펴보세요.

**예약 작업이 여러 번 실행되었습니다.** 모든 인스턴스가 이를 실행했기 때문입니다. cron 작업으로 옮기거나 잠금을 추가하세요.

**아무것도 스케일링되지 않습니다.** 토글이 켜져 있는지, 앱이 실행 중인지, 클러스터 모드가 활성화되어 있는지 확인하세요. 그런 다음 이벤트 목록에서 CPU가 실제로 스케일 업 임계값을 넘었는지 확인하세요.

**비용이 예상보다 높습니다.** 이벤트 목록에서 요동 현상이 있는지 확인한 다음, 최대 인스턴스 수를 낮추세요.

## 관련 페이지

- CPU가 실제로 병목인지 확인하려면 [Site Performance and APM](https://support.kapsulehost.com/ko-kr/site-performance)을 참고하세요.
- 스케일링이 실제로 가용성을 개선하고 있는지 확인하려면 [Site Uptime Monitoring](https://support.kapsulehost.com/ko-kr/site-uptime-monitoring)을 참고하세요.
- 정확히 한 번만 실행되어야 하는 예약 작업에 대해서는 [Cron Jobs](https://support.kapsulehost.com/ko-kr/cron-jobs)를 참고하세요.
- 인스턴스를 늘리는 대신 더 큰 머신이 필요하다면 [Resizing a Cloud Server](https://support.kapsulehost.com/ko-kr/cloud-servers-resize)를 참고하세요.