백업을 만들려다 시작된 확인이다.
“무료니까 어느 날 갑자기 사라질 수도 있는 것 아닌가.” 이 막연한 걱정을 실제 정책과
내 서버 수치로 확인해봤더니, 예상과 다른 결론이 나왔다.
이 글은 Ampere A1(2 OCPU / 12GB, Ubuntu) 인스턴스 기준이다.
수치는 실제 측정값이고, 도메인과 IP 같은 식별 정보는 넣지 않았다.이 서버를 어떻게 세웠는지는
OCI 무료 서버에 도메인 붙이고 HTTPS 적용하기에 적었다.
0. 가장 흔한 오해
검색하면 “CPU 사용률이 10% 미만이면 회수된다”는 설명이 제일 많이 나온다.
절반만 맞다. 이 문장만 믿고 CPU를 태우는 스크립트를 돌리는 사람이 많은데,
적어도 A1에서는 불필요한 일이다.
1. 조건은 세 개이고, 전부 만족해야 한다
Oracle이 밝힌 유휴 판정 기준은 7일 연속으로 아래를 모두 만족하는 경우다.
- CPU 사용률 95백분위 < 10%
- 네트워크 사용률 < 10%
- 메모리 사용률 < 10%
핵심은 AND라는 점이다. 하나만 넘겨도 유휴로 판정되지 않는다.
그리고 세 번째 조건에는 단서가 붙는다.
| shape | 판정 조건 |
|---|---|
| Ampere A1 | CPU + 네트워크 + 메모리 (셋 다 만족해야 함) |
| AMD E2.1.Micro | CPU + 네트워크 (둘만 만족하면 대상) |
메모리 조건은 A1에만 적용된다.
즉 A1이 오히려 유리하다. 빠져나갈 구멍이 하나 더 있다.
반대로 AMD 마이크로 인스턴스는 조건이 둘뿐이라 더 쉽게 걸린다.
2. 내 서버를 대입해봤다
# 메모리
free -m
# CPU (load average / 코어 수)
nproc && uptime
# 컨테이너별 실사용
docker stats --no-stream --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}'
결과는 이랬다.
| 조건 | 내 서버 | 판정 |
|---|---|---|
| CPU 95백분위 < 10% | load 0.10 / 2코어 ≈ 5% | 해당 |
| 네트워크 < 10% | 방문자 거의 없음 | 해당 |
| 메모리 < 10% | 16% (1.9GB / 11.9GB) | 벗어남 |
세 조건 중 둘이 걸렸고, 메모리 하나가 나를 구하고 있었다.
load average는 95백분위가 아니다. 위 명령들은 어림짐작용이다.
정확한 값은 OCI 콘솔의 인스턴스 메트릭(Compute → Instances → 인스턴스 →
Resources → Metrics)에서 7일 구간으로 봐야 한다.
3. 나를 지키고 있던 건 “안 쓰는 앱”이었다
메모리 16%를 만들어준 것이 무엇인지 봤더니 이랬다.
| 컨테이너 | 메모리 |
|---|---|
| Spring Boot 앱 | 317 MB |
| MariaDB | 131 MB |
| WordPress | 113 MB |
그런데 저 Spring 앱은 며칠 전에 끄려고 했던 것이다.
원래 포트폴리오용으로 만든 개인 대시보드인데 목표가 바뀌면서 쓸 일이 없어졌고,
“안 쓰는데 리소스만 먹으니 내리자”고 생각하던 참이었다.
내렸으면 메모리가 10% 아래로 떨어지면서 세 조건이 모두 충족됐을 것이다.
무료 인스턴스에서 “안 쓰니까 끄자”는 정리가 회수를 부를 수 있다.
서버를 비울수록 회수 대상에 가까워지는 구조다. 직관과 반대다.
4. CPU를 태우라는 조언에 대하여
lookbusy나 유사 도구로 CPU를 인위적으로 점유하는 방법이 널리 퍼져 있다.
권하지 않는다.
- A1이라면 불필요하다. 조건이 셋이고 AND이므로, 메모리 하나만 10%를 넘기면 된다.
12GB 인스턴스에서 1.2GB는 평범한 앱 하나로도 넘긴다. - 전기와 CPU 사이클을 태우는 것 외에 얻는 게 없다.
- 정책의 취지는 놀고 있는 자원의 회수다. 바쁜 척을 만드는 대신
실제로 쓸모 있는 것을 하나 올려두는 편이 낫다. 결과도 같고 얻는 것도 있다.
무엇을 올릴지 모르겠다면 이런 것들이 메모리를 자연스럽게 차지한다.
- 개인용 대시보드나 메모 앱
- 자체 호스팅 서비스 (RSS 리더, 북마크, 위키 등)
- 데이터베이스 컨테이너
5. “정지되면 다시 켜면 되지”의 함정
여기가 이 글에서 가장 중요한 부분이다.
유휴로 판정되면 인스턴스는 통지 후 약 1주일 뒤에 정지된다. 즉시 삭제되는 것은 아니다.
정지된 인스턴스는 원칙적으로 다시 켤 수 있다.
단, 해당 shape의 용량이 그 리전에 남아 있을 때만이다.
A1은 인기가 많아 Out of capacity 오류가 일상적이다. 신규 생성 때만 겪는 문제가
아니라 정지된 인스턴스를 재시작할 때도 같은 벽에 부딪힌다.
즉 “정지는 회복 가능하다”는 전제가 A1에서는 성립하지 않을 수 있다.
정지가 아니라 종료(terminate)된 사례도 보고되어 있다. 종료 시 부트 볼륨은 기본적으로
보존되지만, 그 보존을 전제로 계획을 세울 수는 없다.
6. 확실한 해법: PAYG 전환
유휴 회수 정책은 Always Free 계정에만 적용된다.
계정을 종량제(Pay As You Go)로 전환하면 이 정책의 대상에서 빠진다.
그리고 전환한 뒤에도 Always Free 한도 안에서만 쓰면 과금되지 않는다.
신용카드 등록이 필요하다는 점, 한도를 넘기는 순간 과금된다는 점은 감수해야 한다.
| 유휴 회수 | 비용 | |
|---|---|---|
| Always Free 유지 | 대상 | 0원 |
| PAYG 전환 (한도 내) | 대상 아님 | 0원 |
| PAYG 전환 (한도 초과) | 대상 아님 | 사용량만큼 과금 |
무료 한도만 쓸 자신이 있다면 PAYG 전환이 가장 확실하다.
자신이 없다면 예산 알림(Budgets)을 함께 걸어두면 된다.
7. 그래도 결론은 백업이다
여기까지 확인하고 나서도 원래 하던 일로 돌아왔다. 백업이다.
유휴 회수는 서버를 잃는 여러 경로 중 하나일 뿐이다. 디스크 장애, 실수로 인한 삭제,
워드프레스를 노린 공격 — 어느 쪽이든 결과는 같다.
그리고 정책을 아무리 잘 피해도 그중 어느 것도 막아주지 않는다.
한 가지만 덧붙이면, 백업을 같은 서버에 두면 백업이 아니다.
인스턴스가 회수되면 백업도 함께 사라진다. 그 이야기는 다음 편에서 다룬다.
체크리스트
- [ ] 내 인스턴스의 shape 확인 (A1인지 AMD 마이크로인지)
- [ ] OCI 콘솔 메트릭에서 7일 구간 CPU·메모리·네트워크 확인
- [ ] A1이라면 메모리가 10%를 넘는지 확인 — 여기 하나만 걸어두면 된다
- [ ] “안 쓰는 컨테이너 정리”를 하기 전에 메모리 여파를 먼저 계산
- [ ] 재시작 가능성에 기대지 말 것 (A1은 용량 부족으로 못 켤 수 있다)
- [ ] 가능하면 PAYG 전환 + 예산 알림
- [ ] 서버 밖에 백업
이어지는 글
- OCI 무료 서버에 도메인 붙이고 HTTPS 적용하기 — 이 서버를 세운 과정
- systemd 서비스에서 restic 백업이 30배 느려진 이유 — 그래서 만든 백업에서 겪은 일
다음 편
- 백업이 없는 줄도 몰랐던 이야기 — restic으로 서버 밖에 매일 백업하기
[…] OCI Always Free 인스턴스는 언제 회수되는가 — 이 백업을 만들게 된 계기 […]