온프레미스 인프라 학습 ③ — DB·백업·운영과 흔한 착각
TL;DR
- 스냅샷 ≠ 백업 — 스냅샷만 믿고 복구 테스트를 안 하면, 정작 필요할 때 복구 경로가 없습니다.
- MOP·CMDB — 야간 작업·변경은 롤백 계획(MOP) 없이 손대지 않고, 물리·논리·하이퍼바이저는 하나의 대장(CMDB)으로 관리합니다.
- DB 장애는 Alert log(DB) vs OS log를 먼저 구분해야 원인을 좁힐 수 있습니다.
- 3편 마무리 — 3~4주차는 “숫자 읽기”에서 운영·거버넌스로, 그리고 개인 프로젝트에 적용하는 단계로 넘어갑니다.
들어가며
1편에서 스토리지 계층, 2편에서 가상화·OS·네트워크를 정리했습니다. 이제 남은 건 DB와 그 위를 감싸는 백업·운영입니다. 여기서 무너지면 앞선 두 편에서 잡은 계층 감각이 있어도 소용없습니다 — 복구할 백업이 없거나, 무슨 작업을 했는지 기록이 없으면 원인 파악부터 막힙니다.
인프라 생존기 : 무너진 성벽의 기록을 계속 읽으며 정리한 3편은 시리즈 마무리이기도 합니다. 기술 용어보다 “왜 운영·거버넌스가 기술만큼 중요한가”에 방점을 찍었습니다.
DB — RAC/ASM, 로그 구분, scope creep
| 용어 | 한 줄 정의 |
|---|---|
| RAC (Real Application Clusters) | 여러 노드가 하나의 DB를 나눠 처리하는 다중 노드 클러스터 |
| ASM (Automatic Storage Management) | RAC 노드들이 같이 쓰는 공유 디스크 그룹 |
| Alert log vs OS log | Alert log는 DB 내부 이벤트, OS log(syslog 등)는 서버 자체 이벤트 — 장애 시 둘을 섞으면 원인이 엉킵니다 |
| 복구 중 scope creep | DR 테스트·장애 복구 도중 “이왕 하는 김에” 다른 작업까지 끼워 넣는 것 |
RAC는 DB를 여러 노드로 나눠서 가용성을 올리지만, 그만큼 ASM 공유 디스크 그룹이 흔들리면 노드 전체가 같이 흔들립니다. 1편의 스토리지 계층(LUN·SAN)이 그대로 DB 가용성의 바닥이 되는 셈입니다.
장애가 나면 제일 먼저 할 일은 Alert log(DB)와 OS log를 분리해서 보는 겁니다. DB가 느린 게 쿼리 문제인지, 아니면 OS 레벨 I/O·메모리 문제가 DB까지 올라온 건지 — 로그 출처를 안 가르면 애먼 곳을 고칩니다.
복구 중 scope creep은 은근히 자주 나오는 실수입니다. DR 테스트나 장애 복구 도중에 “이참에 패치도 하자”고 끼워 넣으면, 원래 복구해야 할 범위가 흐려지고 롤백 지점도 헷갈립니다. 복구는 정해진 범위만, 정해진 순서대로가 원칙입니다.
백업·운영 — NetBackup, MOP, APM, CMDB
| 용어 | 한 줄 정의 |
|---|---|
| NetBackup | 엔터프라이즈급 백업 솔루션. 복구 경로(/ vs /test 등) 혼동 주의 |
| 스냅샷 ≠ 백업 | 스냅샷은 순간 상태 기록일 뿐, 복구 테스트를 거치지 않으면 백업이 아닙니다 |
| MOP (작업계획서) | 변경·야간작업의 절차·롤백·영향도를 문서로 남기는 것 |
| APM | 앱 트랜잭션 trace — “스토리지 탓”이라는 감을 팩트로 반박하는 도구 |
| Inventory / CMDB | 물리·논리·하이퍼바이저를 하나로 묶는 단일 대장 |
스냅샷 ≠ 백업이 3편에서 가장 강조하고 싶은 포인트입니다. 스냅샷은 “지금 이 순간 상태”를 잡아둔 것뿐이라, 스토리지 자체가 손상되면 스냅샷도 같이 날아갈 수 있습니다. 진짜 백업인지 확인하는 유일한 방법은 실제로 복구해보는 것입니다. 복구 경로를 운영 서버(/)가 아니라 테스트 경로(/test)로 착각하고 진행하는 실수도 NetBackup에서 흔합니다.
MOP 없이 진행한 야간 작업은 문제가 생겼을 때 “무엇을 어떻게 되돌려야 하는지”를 아무도 모르는 상태를 만듭니다. 절차·영향도·롤백 방법을 미리 적어두는 것 자체가 장애 대응 시간을 줄이는 가장 싼 방법입니다.
APM은 “DB가 느리다”, “스토리지가 느리다” 같은 감을 트랜잭션 trace라는 팩트로 바꿔줍니다. 2편의 grep·nmon과 같은 맥락 — 팩트 확인 도구 없이는 책임 소재를 놓고 뺑뺑이만 돕니다.
Inventory/CMDB는 “이 서버가 물리인지 논리인지, 어느 하이퍼바이저 위에 있는지”를 한 곳에서 확인할 수 있게 합니다. 장애 상황에서 이 대장이 없으면, 원인 파악보다 “이게 뭐였더라”를 알아내는 데 시간을 더 씁니다.
자주 나오는 착각 6가지
| 패턴 | 예시 | 대응 |
|---|---|---|
| 레이어 무시 | VM만 알고 AG·LUN·RAC 구조 모름 | 계층 구조도부터 다시 보기 |
| 절대값 착각 | Latency·CPU 숫자가 작으니 괜찮다고 판단 | 평소 대비 변화량(Δ) 확인 |
| 용어장난 | quota=용량, UAK=User라고 오해 | 용어表로 정확한 정의 확인 |
| 기록 회피 | 전화·구두로만 전달, 로그 rotation 모름 | MOP·공유 채널로 기록 남기기 |
| 허세 보고 | “다 해놨습니다”라고만 보고 | 복구 테스트·로그로 증명 |
| 팩트 vs 감 | “스토리지 탓”이라고 감으로 단정 | nmon·APM·grep으로 확인 |
여섯 가지 다 결국 같은 이야기입니다 — 확인하지 않은 것을 사실처럼 말하지 말자. 스토리지든 DB든 백업이든, 로그와 숫자로 확인한 것만 사실로 취급하는 습관이 1~3편을 관통하는 핵심입니다.
핵심 에피소드 바로가기
| 글 | 한 줄 | 링크 |
|---|---|---|
| 1 | du·용량 진실 | 1편 |
| 12~13 | Swap 100% 방치 | 12편 |
| 22 | APM으로 앱 병목 증명 | 22편 |
| 32~34 | 베어메탈=논리 서버 착각 | 32편 |
| 45 | Write Latency 100배 | 45편 |
| 50 | grep 한 줄로 버그 규명 | 50편 |
| 56~57 | AG / VM 계층 공백 | 56편 |
| 58~59 | NetBackup·스냅샷 착각 | 58편 |
3~4주차 학습 로드맵
2주차까지 “숫자 읽기”를 잡았다면, 3주차부터는 운영·거버넌스로 넘어갑니다.
| 글 | 주제 |
|---|---|
| 27~34편 | Inventory, Physical/Logical 구분 |
| 42편 | 실무의 정석 #1 — 주간 작업 |
| 52편 | 실무의 정석 #2 — UAK |
4주차는 여기서 배운 것을 개인 프로젝트에 그대로 적용해보는 단계로 잡으면 됩니다. 예를 들면 이런 식입니다.
- 토이 프로젝트 DB가 느려지면, 쿼리부터 의심하기 전에 호스트 I/O·메모리도 같이 확인
- 개인 서버·NAS를 쓴다면 스냅샷만 믿지 말고 한 번은 실제로 복구해보기
- 변경 작업 전에 짧게라도 “뭘 바꾸고, 문제 생기면 어떻게 되돌릴지” 한 줄 메모(미니 MOP)
- 서버·VM·디스크 목록을 노션이나 메모 앱에 한 곳에 정리해두기 (미니 CMDB)
거창한 도구 없이도, “확인하고 기록하는 습관”만 옮겨오면 4주차 목표는 달성입니다.
마무리
3편에 걸쳐 스토리지 → 가상화·OS·네트워크 → DB·백업·운영까지 온프레미스 계층을 훑었습니다. 인프라는 정직합니다. 로그와 숫자는 거짓말하지 않고, 확인하지 않은 것을 사실처럼 말하는 순간부터 문제가 시작됩니다.
더 깊이 파고들고 싶다면 아래 자료를 참고하면 좋습니다.
- Brendan Gregg — Linux Performance
- Oracle 공식 문서 — RAC Administration · ASM Administration
- IBM — Storage Scale (GPFS)
시리즈 전체 원문은 인프라 생존기 : 무너진 성벽의 기록에서 이어서 읽을 수 있습니다.
Comments