24년 동안 한 번도 꺼지지 않은 서버
2017년에 Computerworld에 실린 이야기인데, 지금 다시 읽어도 생각할 거리가 많아요. 1993년에 전원이 들어간 서버 한 대가 24년 가까이 계획에 없던 다운타임 없이 계속 돌아가다가, 드디어 은퇴를 앞두게 됐다는 내용이에요. 1993년이면 윈도우 3.1을 쓰던 시절이고 리눅스는 태어난 지 겨우 2년쯤 됐을 때예요. 그때 켠 기계가 스마트폰이 흔해지고 클라우드가 기본이 된 2017년까지 조용히 제 일을 하고 있었던 거죠.
이 서버는 Stratus라는 회사가 만든 폴트 톨러런트(fault-tolerant) 컴퓨터였어요. 이 기계가 어떻게 그렇게 오래 버텼는지, 그리고 요즘 우리가 쓰는 클라우드 방식과는 뭐가 다른지 하나씩 풀어볼게요.
폴트 톨러런트가 뭐냐면
먼저 비슷해 보이는 두 개념부터 구분해 볼게요. 많이 들어보셨을 고가용성(High Availability, HA) 은 고장이 나면 빨리 다른 곳으로 넘기는 방식이에요. 서버 A가 죽으면 대기 중이던 서버 B가 일을 이어받는 거죠. 그런데 넘어가는 몇 초에서 몇 분 동안은 서비스가 끊기고, 처리 중이던 요청이 날아갈 수도 있어요.
폴트 톨러런트는 목표가 더 높아요. 부품이 고장 나도 아무도 눈치채지 못하게 하는 게 목표거든요. CPU, 메모리, 전원 장치, 디스크 같은 핵심 부품을 두 벌씩 두고, 두 벌이 같은 명령을 한 박자도 어긋나지 않게 동시에 실행해요. 이걸 락스텝(lockstep) 이라고 불러요. 둘의 결과를 계속 비교하다가 한쪽이 이상한 값을 내면 그 부품만 떼어내고, 남은 쪽이 끊김 없이 계속 일해요.
비유하자면 회계사 두 명이 같은 장부를 동시에 계산하는 거예요. 둘의 답이 다르면 틀린 쪽을 바로 빼고, 남은 사람이 계산을 이어가요. 장부를 맡긴 사람은 그런 일이 있었는지도 모르고요.
여기에 핫스왑(hot swap), 그러니까 전원이 켜진 상태에서 부품을 갈아 끼우는 기능이 더해져요. 이런 기계들은 스스로 고장을 감지해서 제조사에 알리고, 제조사가 교체 부품을 보내주는 식으로 운영되는 경우가 많았어요. 사람이 알아채기도 전에 수리가 진행되는 셈이죠. 24년 무중단이 가능했던 건 기계 전체가 한 번도 고장 나지 않아서가 아니에요. 고장 나도 멈추지 않게 설계했기 때문이에요.
그런데 왜 이제는 꺼야 할까
아무리 튼튼해도 영원히 쓸 수는 없어요. 단종된 부품은 구하기 어려워지고, 그 운영체제와 애플리케이션을 아는 사람들은 은퇴하고, 비즈니스가 요구하는 기능도 바뀌니까요.
역설적인 부분도 있어요. 수십 년 동안 한 번도 재부팅하지 않은 서버는 다시 켜졌을 때 제대로 부팅될지 아무도 장담하지 못하는 서버이기도 하거든요. 그동안 바뀐 설정이 디스크에 제대로 저장됐는지, 부팅 절차를 기억하는 사람이 남아 있는지 알 수가 없어요. 게다가 커널 보안 패치 중에는 재부팅해야 적용되는 게 많아서, 요즘 기준으로 보면 가동 시간이 길다는 건 자랑이 아니라 경고 신호에 더 가까워요.
업계 맥락: 비싸고 튼튼한 한 대 vs 싸고 많은 여러 대
이런 철학은 지금도 살아 있어요. IBM 메인프레임(IBM Z)이나 Tandem에서 이어진 HPE NonStop 같은 시스템은 아직도 은행, 카드 결제망, 증권 거래 시스템 같은 곳에서 쓰여요. 1초만 멈춰도 돈이 새는 곳이니까요.
반면 클라우드는 정반대 길을 골랐어요. 하드웨어는 언젠가 반드시 고장 난다고 전제하고, 값싼 범용 서버를 여러 대 두고 소프트웨어 차원에서 중복성을 챙기는 거죠. 흔히 말하는 펫이 아니라 가축(pets vs cattle) 이라는 비유가 여기서 나와요. 이름 붙여서 애지중지 돌보는 서버 한 대 대신, 문제가 생기면 바로 버리고 새로 띄우는 서버 여러 대를 운영하는 방식이에요. 그래서 요즘은 서버 한 대의 가동 시간이 아니라 서비스 전체의 가용성(SLO) 으로 안정성을 재요.
두 방식 모두 정답이에요. 다만 해결하는 계층이 달라요. 폴트 톨러런트 하드웨어는 애플리케이션이 장애를 몰라도 되게 만들어 주고, 클라우드 방식은 애플리케이션이 장애를 알고 대처하도록 요구해요. 그래서 클라우드에서는 재시도, 멱등성(같은 요청을 여러 번 보내도 결과가 같은 성질), 분산 트랜잭션 같은 개념을 개발자가 직접 챙겨야 해요.
한국 개발자에게 주는 시사점
국내 금융권에는 아직 메인프레임과 코볼 기반 시스템이 많고, 이걸 새 시스템으로 옮기는 이른바 차세대 프로젝트가 계속 진행되고 있어요. 이 이야기에서 얻을 수 있는 교훈을 세 가지로 정리해 볼게요.
첫째, 안정성만큼 교체 가능성도 설계해야 해요. 너무 잘 돌아가는 시스템은 아무도 건드리지 않다가, 결국 아무도 이해하지 못하는 시스템이 돼요.
둘째, 재시작을 정기적으로 연습하세요. 쿠버네티스에서 파드를 주기적으로 재배포하거나 서버를 롤링 재부팅하는 게 번거로워 보여도, 다시 켤 수 있다는 걸 확인하는 가장 확실한 방법이에요.
셋째, 지식은 사람이 아니라 문서와 코드에 남겨야 해요. 인프라를 코드로 관리하는 IaC나 운영 런북(장애 대응 매뉴얼)이 중요한 이유가 바로 이거예요.
마무리
24년 무중단은 고장이 없어서가 아니라 고장을 견디도록 설계했기 때문에 가능했어요. 그리고 그렇게 튼튼한 시스템도 결국은 교체를 준비해야 해요.
여러분 회사에도 아무도 재부팅하기 무서워하는 서버나, 퇴사한 누군가만 알던 시스템이 있나요? 있다면 어떻게 다루고 계신지 댓글로 이야기 나눠봐요.
🔗 출처: Hacker News