Shared File System(NFS, Ceph) 사용 시 'File Lock' 메커니즘의 한계는?

Shared File System(NFS, Ceph) 사용 시 'File Lock' 메커니즘의 한계는?

엔터프라이즈 분산 환경에서 메시지 브로커(ActiveMQ 등)의 고가용성(HA)을 구성하는 가장 고전적이고 성능이 뛰어난 아키텍처는 '공유 파일 시스템(Shared File System)'을 활용하는 방식입니다. 마스터(Master)와 슬레이브(Slave) 노드가 동일한 물리적 혹은 논리적 스토리지(NAS, SAN, Ceph 등)를 마운트하여 데이터를 공유함으로써, 데이터의 일관성을 완벽하게 유지하면서도 빠른 디스크 I/O를 달성할 수 있습니다.

이 아키텍처가 정상적으로 작동하기 위한 절대적인 전제 조건은 오직 단 하나의 노드만이 파일에 쓰기 권한을 가져야 한다는 것입니다. 이를 통제하는 핵심 기술이 바로 운영체제(OS) 레벨의 '파일 락(File Lock)' 메커니즘입니다.

하지만 온프레미스의 고가 SAN 장비가 아닌, 일반적인 NFS(Network File System)나 Ceph와 같은 소프트웨어 정의 스토리지(SDS) 위에서 이 파일 락에 전적으로 의존하는 것은 인프라 전체를 마비시킬 수 있는 거대한 시한폭탄을 안고 가는 것과 같습니다. 본 가이드에서는 네트워크 기반 공유 스토리지에서 파일 락이 가지는 태생적인 한계와, 장애 상황에서 발생하는 치명적인 문제점들을 상세히 해부합니다.

---

1. 완벽해 보이는 설계: File Lock의 기본 동작 원리

공유 스토리지를 사용하는 브로커의 페일오버(Failover) 시나리오는 매우 단순하고 우아하게 설계되어 있습니다.

1. Lock 쟁취: 클러스터가 구동되면, 마스터 브로커가 가장 먼저 공유 폴더(예: KahaDB 디렉토리) 내의 lock 파일에 대해 운영체제 레벨의 배타적 잠금(Exclusive Lock)을 요청하고 획득합니다.
2. 무한 대기: 늦게 부팅된 슬레이브 브로커는 lock 파일이 이미 선점된 것을 확인하고, 파일 락이 풀릴 때까지 디스크 입출력을 멈춘 채 끝없이 폴링(Polling)하며 대기(Standby)합니다.
3. 권한 승계: 마스터 브로커 프로세스가 종료되거나 서버 전원이 차단되면, 운영체제가 해당 프로세스가 쥐고 있던 파일 락을 자동으로 회수하여 해제합니다.
4. 승격: 락이 풀린 것을 감지한 슬레이브가 즉시 새로운 락을 쟁취하고 새로운 마스터로 승격하여 클라이언트의 요청을 처리합니다.

이론상으로는 완벽한 이 구조는, "프로세스가 죽으면 OS가 락을 즉시 해제해 준다"는 가정이 네트워크 너머의 분산 파일 시스템에서도 100% 동일하게 작동할 때만 성립합니다.

---

2. NFS 환경의 치명적 함정: '고스트 락(Ghost Lock)'의 저주

가장 대중적인 공유 스토리지 프로토콜인 NFS 환경에서 페일오버를 시도할 때 인프라 엔지니어가 가장 흔하게 마주하는 재앙이 바로 고스트 락(Ghost Lock), 혹은 Stale Lock 현상입니다.

• 네트워크 단절과 상태의 괴리: 마스터 서버의 프로세스가 정상적으로 종료(Graceful Shutdown)되었다면 NFS 클라이언트가 NFS 서버 측으로 락 해제 신호를 명확히 보냅니다. 하지만 마스터 서버의 랜선이 뽑히거나 하드 크래시(커널 패닉)로 돌연사한 경우, NFS 서버 입장에서는 마스터 클라이언트가 죽었는지 아니면 단순히 네트워크가 일시적으로 지연되는 것인지 알 방도가 없습니다.
• 영원히 풀리지 않는 락: 과거 널리 쓰이던 NFSv3는 태생적으로 상태를 저장하지 않는(Stateless) 프로토콜에 NLM(Network Lock Manager)을 억지로 얹은 구조입니다. 마스터가 죽었음에도 NFS 서버는 락 만료(Timeout)를 제대로 처리하지 못하고 이 파일 락을 영구적으로 유지하려 듭니다.
• 서비스 전체 마비: 마스터는 이미 죽었는데 파일 락은 풀리지 않으므로, 슬레이브 브로커는 영원히 대기 상태에 머물게 됩니다. 클라이언트들은 갈 곳을 잃고 전체 서비스가 완벽하게 마비됩니다. 결국 엔지니어가 NFS 서버에 접속하여 강제로 락 상태를 초기화하거나 서비스를 재시작해야만 하는 수동 복구의 악몽이 펼쳐집니다.

---

3. 분산 스토리지(CephFS, GlusterFS)의 한계: 락 전파 지연과 정합성

현대의 클라우드 네이티브 환경에서는 3중 복제 등을 지원하는 Ceph나 GlusterFS와 같은 분산 파일 시스템을 HA 스토리지로 도입하곤 합니다. 이들은 단일 고장점(SPOF)이 없다는 장점이 있지만, 분산 환경 특유의 CAP 정리(Consistency, Availability, Partition Tolerance)에 따른 한계를 지닙니다.

• 메타데이터 서버(MDS) 병목: CephFS 같은 구조에서는 파일의 락 정보를 메인 데이터 노드(OSD)가 아닌 메타데이터 서버(MDS) 클러스터가 관리합니다. 트래픽 폭주 시 MDS에 부하가 걸리면, 파일 락의 획득과 해제 상태가 클러스터 전체 노드에 동기화되는 데 미세한 지연(Propagation Delay)이 발생합니다.
• 가짜 스플릿 브레인(False Split-Brain): 네트워크 파티션(Network Partition)이 발생하여 마스터 브로커가 Ceph 스토리지 망과는 연결이 끊겼지만 클라이언트 망과는 연결이 살아있는 상황을 가정해 봅니다. Ceph MDS는 락 타임아웃을 선언하고 슬레이브에게 락을 넘겨줍니다. 슬레이브는 승격하여 데이터를 쓰기 시작하지만, 마스터 브로커는 자신이 락을 잃었다는 사실을 즉각적으로 인지하지 못하고 커널 버퍼에 남아있던 데이터를 비동기로 밀어 넣으려 시도합니다. 이는 스토리지 레벨에서의 데이터 오염(Corruption)으로 직결됩니다.

---

4. 가장 뼈아픈 부재: 'I/O Fencing' 메커니즘의 결여

파일 락에만 의존하는 HA 아키텍처의 근본적인 취약점은, 기존 마스터 노드의 입출력을 물리적으로 완벽하게 차단하는 'I/O 펜싱(Fencing)' 기능이 존재하지 않는다는 것입니다.

고급 클러스터링 솔루션(Pacemaker/Corosync 등)에서는 마스터 노드에 이상이 생기면 STONITH(Shoot The Other Node In The Head) 장치를 통해 대상 서버의 전원을 PDU 레벨에서 아예 차단해버립니다. 하지만 순수하게 ActiveMQ의 KahaDB 파일 락 아키텍처는 스토리지 단의 락에만 의존할 뿐, 좀비가 된 구형 마스터 브로커를 네트워크에서 강제로 격리하거나 프로세스를 죽일 수 있는 권한이 없습니다.

파일 시스템의 락이 어설프게 풀리거나 꼬이는 순간, 두 브로커가 동시에 하나의 저널 파일(db-*.log)에 쓰기를 시도하게 되고, 이는 B-Tree 인덱스(db.data)의 영구적인 손상으로 이어져 복구 불가능한 장애를 초래합니다.

---

5. 아키텍처 한계 극복을 위한 모범 튜닝 가이드 (Best Practices)

이러한 네트워크 파일 시스템의 태생적 한계를 인지했다면, 인프라 설계 시 다음의 아키텍처적 방어선을 반드시 구축해야 합니다.

A. NFSv4 도입 및 Lease Time 타이트 튜닝
어쩔 수 없이 NFS를 사용해야 한다면, 상태를 내장하고 있는(Stateful) NFSv4 프로토콜 사용을 엄격하게 강제해야 합니다. 또한 NFS 서버 설정에서 락 유예 시간(Lease Time / Grace Period)을 기본 90초에서 10초~30초 수준으로 대폭 줄여, 마스터 노드 크래시 시 슬레이브가 락을 획득하는 데 걸리는 다운타임을 최소화하도록 튜닝해야 합니다.

B. Lease Database Locker (JDBC) 병행 도입
파일 시스템의 락 관리 능력을 믿을 수 없다면, 데이터 저장(KahaDB)은 공유 파일 시스템에 맡기되, 마스터 권한을 결정하는 락(Lock) 관리 메커니즘은 고가용성이 보장된 RDBMS로 이관하는 하이브리드 방식을 채택해야 합니다. 데이터베이스의 Row Lock과 짧은 주기(Lease)를 활용하면 고스트 락 현상 없이 완벽한 타이 브레이커(Tie-breaker) 역할을 수행할 수 있습니다.

C. Shared-Nothing 아키텍처로의 전환 (Artemis Replication)
공유 스토리지 자체의 한계에 지쳤다면 패러다임을 완전히 전환해야 합니다. 최신 브로커인 ActiveMQ Artemis의 Native Replication을 도입하여 공유 스토리지를 완전히 제거하고, 브로커 노드 각자의 로컬 디스크를 네트워크를 통해 동기화하는 'Shared-Nothing' 방식으로 넘어가는 것이 클라우드 네이티브 환경에서 스플릿 브레인과 파일 락의 저주로부터 벗어나는 궁극적인 해결책입니다.