퇴근하고 샤워 딱 끝내고 넷플릭스 켰는데 휴대폰 진동이 미친 듯이 울리는 거야. 등골이 서늘해지는 그 쎄한 기분. IT 밥 먹는 엔지니어라면 다들 알지? 다급한 고객의 목소리가 들렸어. 노드 하나가 죽었다고 난리가 났대. 아, 진짜 짜증이 명치끝에서 확 솟구치다가도 어쩌겠어. 먹고살려면 가야지. 현장 가기 전에 톨게이트 운전하면서 상황부터 파악하려고 사진 한 장을 보내달라고 했어. 화면에 찍힌 에러 메시지는 `Correctable Memory Error Threshold Exceeded`. 그래, 딱 봐도 램 불량이구나 하고 생각이 들었지.
근데
고객 설명을 듣다 보니까 상황이 좀 이상하게 돌아가고 있었어. 고작 메모리 모듈
하나 뻑난 건데 클러스터 전체에 행(Hang)이 걸려버렸어. 게다가 CVM(Controller
VM)이 degraded 상태로 빠져버렸다는 거야. 상식적으로 도무지 앞뒤가 안 맞잖아?
메모리 하나 죽었다고 전체 서비스가 뻗어버리는 게 말이 돼? 이게 무슨 동네 조립
PC도 아니고 엔터프라이즈 장비인데,,
글로벌 SRE가 던진 충격적인 단어, 'ECC 스톰(Storm)'
밤 공기 가르면서 현장으로 달려가면서 바로 벤더 케이스 오픈을 때렸지. 현장 도착하자마자 글로벌 SRE가 원격 붙어서 로그를 미친 듯이 까보기 시작했어. 한참 로그를 뒤지던 그 친구가 내 귀를 의심할 만한 단어를 툭 던지더라. "지금 이거 2번 노드에 ECC STOM 현상이 터졌네요." 스톰? 폭풍? 장난해? 이게 대체 뭔 개소린가 싶었어. 엔지니어가 천천히 설명해 주는데 듣고 나니까 그제야 무릎을 탁 치게 되더라. 원래 서버용 DIMM 메모리에 자잘한 bit 오류가 생기면 ECC 모듈이 알아서 오류를 수정하면서 돌아가. 이게 정상적인 방어 기제지. 근데 램이 완전히 맛이 가서 이 찌꺼기 같은 오류가 초당 수천수만 개씩 미친 듯이 쏟아지면 어떻게 될까? 이걸 쉽게 비유해 볼게. 불량품을 걸러내는 컨베이어 벨트가 있어. 가끔 하나씩 나오는 불량품은 작업자가 휙휙 던져버리면 그만이야. 근데 쏟아지는 물건의 99%가 불량품이면? 작업자는 그거 쳐내느라 아예 정상적인 업무를 못 하게 되겠지? 딱 그 짝이었어. 쏟아지는 자잘한 오류들을 고치는 데 CPU 자원을 전부 다 끌어다 쓰는 거야. CPU가 램 뒤치다꺼리 하느라 정작 자기가 해야 할 시스템 스토리지 I/O 처리나 클러스터 운영을 놔버린 거지. 한마디로 메모리 하나가 CPU 멱살을 잡고 전체 시스템을 마비시킨 어처구니없는 나비효과였어. |
| HPE ILO에서 DIMM Error 확인 모습 |
해결책은 허탈할 정도로 1차원적이었다
그럼 이 폭풍을 어떻게 잠재우냐고 SRE한테 물었지. 난 뭐 대단한 히든 커맨드를 날리거나 긴급 패치를 씌우는 줄 알았어. 근데 돌아온 대답이 아주 심플하더라. "그 문제의 메모리 뽑고 새 거 꽂으세요. 그럼 끝나요." 아... 진짜 허탈하더라. 거창한 이름에 비해 해결책은 그냥 완전 아날로그 물리 치료였어. 고객한테 상황 브리핑 쫙 해주고 파트 수급해서 바로 물리적으로 갈아 끼웠지. 램 슬롯 양쪽 탭 딸깍 소리 나게 꽂아 넣고 전원 버튼 누를 때 그 쫄깃함 다들 알 거야.노드 부팅되고 다시 전원 올리니까 거짓말처럼 뻗어있던 클러스터 CVM 상태가 싹 정상으로 돌아오더라. ILO 들어가서 하드웨어 상태 로그 까보니까 언제 그랬냐는 듯이 초록불 띄우면서 깨끗해져 있었어. 진짜 허탈하면서도 어이가 없었지만 어쨌든 서비스는 살렸고 고객도 고맙다며 안도했으니 그걸로 된 거지 뭐.
도마뱀의 꼬리 자르기? 벤더사의 징글징글한 생존 메커니즘
상황 다 종료하고 스크립트 정리해서 고객한테 완료 보고하고 나오는데, 고객도 계속 찝찝해 하더라고. 고작 램 하나가 전체를 흔든 게 설계 결함 아니냐면서 말이야. 나도 동의했지. 근데 나중에 사무실 복귀해서 아키텍처 문서를 딥하게 파보니까 그제야 퍼즐이 맞춰지더라. CVM degraded 상태는 시스템 오류로 인한 단순한 '장애'가 아니었어. 시스템이 다 같이 안 죽으려고 스스로 살기 위해 발동한 처절한 방어 기제였던 거야. 도마뱀이 천적한테 위협을 느끼면 자기 꼬리 자르고 도망가잖아. 딱 그거야. 노드 하나가 상태가 메롱이면 클러스터 전체의 데이터 정합성과 안정성을 갉아먹게 돼. 그래서 아예 그 미친 노드를 클러스터에서 강제로 격리시키고 남은 정상 노드들끼리 똘똘 뭉쳐서 서비스를 유지하려는 무서운 생존 메커니즘이었어. 시스템 입장에선 꼬리를 자른 거지. |
| CVM Degraded 상태 확인 모습 |
이 경험을 통해 알게 된 시스템 방어막 꿀팁 (실패하지 않는 법)
현장 뛰는 초보 엔지니어들, 화면에 뜬 에러 로그 딱 한 줄만 보고 덤비면 진짜 멘탈 영혼까지 탈곡된다. CVM Degraded가 떴을 때 단순히 "아 CVM 죽었네" 하고 넘기지 말고 무조건 의심해 봐야 할 진짜 원인들을 현장 경험 녹여서 정리해 줄게.- 네트워크의 배신: 스위치 포트 빵꾸나서 대역폭이 갑자기 쪼그라들거나 패킷이 질질 샐 때 시스템은 칼같이 노드를 왕따시킨다. 케이블부터 찍어봐.
- 하드웨어의 역습: 오늘 내 썰처럼 물리적인 불량 디스크, SATADOM 문제, 혹은 겉보기엔 멀쩡한데 뒤에서 ECC 오류 미친듯이 뿜어내는 램 불량. 무조건 하드웨어 로그부터 긁어서 교차 검증해.
- 소프트웨어 엉킴: CPU 소프트 락업 현상. CPU 머리가 굳어버려도 방어 기제는 어김없이 발동한다. 하드웨어가 정상이면 커널 로그를 파봐.
다들 필드에서 현명한 엔지니어가 되길 바라겠습니다. 오늘도 적당히 장애있는 하루 보내시길 바랍니다.
0 댓글