[B급 프로그래머] 대규모 서버 소프트웨어에서 작업하는 동안 배운 교훈

지난번에 전해드린 소식 가운데, Lessons Learned while Working on Large-Scale Server Software이라는 블로그 글이 있었는데, 독자 여러분을 위해 간략하게 정리해드리겠다.

1. 최악에 대한 계획을 세워라. 데이터베이스가 모두 내려가버리면 어떻게 되나? 모든 데이터가 다 날아가버리면 어떻게 되나? 시스템이 어떻게 실패하는지 이해하지 못하면 시스템이 어떻게 동작하는지도 이해하지 못한다.
2. CAP 이론은 진짜다. 나쁜 일이 일어나는 목록이 아니라 중요한 결정을 내리게 강제하는 이론이다. 독배를 들었으면, 여기에 집중하라.
3. 분산 컴퓨팅에 대한 오해는 진짜다. 네트워크는 빌어먹을 녀석이고, 대기 시간은 예측 불가능이고, 대역폭은 돈이 많이 들고 제약이 있고, 사람들은 당신의 네트워크에 침투하고, 구성 요소들은 이리저리 옮겨 다니고, 여러 팀과 회사가 시스템의 다양한 부분을 책임지고, 장비, 프로토콜, 직렬화 포맷은 엄청나게 다양하고... 시스템을 분산시켜야 한다면 다시 한번 생각하라. 어렵다.
4. 역압이냐 평균 분배냐? 둘 중 하나를 골라라. Queues Don't Fix Overload를 보시오!
5. 디버깅은 과학이다. 문제를 찾아 수정하는 과정에서 가설을 새우고 검증하라.
6. 포스텔의 법칙은 어렵다. "전송할 때는 보수적으로, 받아들일 때는 자유롭게" 다시 말해, "좋은 데이터를 보내고, 쓰레기를 받을 준비를 하라"! 최대한 엄격하게 구현을 시작하라. 명세를 엄걱하게 구현하고 아무 것도 망가뜨리지 않게 만들어라.
7. 네트워크를 신뢰하지 마라. 네트워크는 당신의 감정에 대해 신경 쓰지 않으며 당신의 신뢰에 보답하지도 않는다. 운영체제는 지역 컴퓨터를 벗어나 맺어진 연결에 대해 지역적으로 맺어진 연결과는 다르게 반응한다. 네트워크는 필요악이며, 즐거움을 찾을 장소는 아니다.
8. 브루루스시스템 너마저! 가장 신뢰하는 기반 구조는 궁극적으로 가장 아픈 곳이 된다(B급 프로그래머 생각: 주키퍼야 미안하다. ㅋㅋ). 누군가 이런 기반 구조를 너무나도 신뢰하면 곧 당신(또는 다른) 팀에 마법이 된다. 모든 사람은 건드리지 않고서 여기에 신뢰하는 방식을 배움에 따라, 압력 하에서 썩고 고통 받기 시작한다. 결국 기존 시스템과 중요한 시스템의 특성을 모두 갖춘 구성 요소에 대해 어렵게 확장하는 작업을 벌여야 한다. 시스템의 성공은 운영자에 달려 있다. 충분한 연습이 없다면 시스템의 가장 취약한 부분이 된다.
9. 빨리 죽이고 자주 죽이자. 오류 처리 방법에 대해 확신이 없으면, 죽여보자. 시끄럽고 빠르게 등장하는 오류는 찾기도 쉽고 수정도 쉽다. 수 일, 수 주, 수 달에 걸쳐 느릿느릿 시스템을 천천히 죽이는 오류는 진짜로 고통스럽다.
10. 버그 수정은 실패를 초래한다. 새로운 소프트웨어 설치와 배포는 시스템에 있어 새로운 변수를 도입하는 훌륭한 수단이 된다. 배포가 커지면 더욱 무시무시해진다. 배포하고 나서 아무 문제가 없으면 두려워해야 한다. 우리 모두 실수를 하므로, 모든 것이 너무나도 조용하게 잘 돌아가면 나중에 문제를 감지하기까지 시간이 오래 걸릴 수도 있다는 사실을 암시할지도 모른다.
11. 오래 시스템을 돌리야 그 때서야 버그가 나타날지도 모른다. 지속적인 개발은 오늘날 정도의 차이는 있지만 표준 관례다. 노드를 자주 재시작하면, 나타나기 전까지 오래 걸리는 이상한 동작, 손상, 확률이 낮은 이벤트가 숨겨진 채로 남을 것이다. (B급 프로그래머 생각: 상용 시스템에서도 이런 문제가 종종(응?) 등장하곤 한다. Boeing 787 software bug can shut down planes' generators IN FLIGHT를 참조하라!)
12. 완전한 재시작을 준비하자. 부하가 걸렸을 때 백지 상태에서 전체 시스템을 재시작할 준비를 하자.
13. 전역 변수 뿐만 아니라 전역 상태에 신경써라. 대규모 시스템, 특히 기존에 존재하는 시스템을 리펙터링할 경우, 문제 투성이가 될 수 밖에 없는 이유는 똑똑하고 산만한 양 쪽 사람들이 여러 가지 결정을 내렸고, 그 결과 모든 사람이 의지할 여러 부분을 눈에 보이지 않게 붙여놓았기 때문이다.
14. 이게 모두 사람 때문이다. 시스템은 사람에 의해 죽고 산다. 시스템을 계속해서 살아있게 만들고, 운영하고 이상하다는 사실을 잽싸게 눈치채는 방법을 배우기 위해 힘들게 배운 교훈은 바로 개발에 시간이 걸리며 이 과정에서 사람이 개입한다는 사실이다. 이런 유형의 지식은 일반적으로 개발한 팀 내부에 남아 있고 개인이 역할을 떠나거나 바꿀 때 사라지는 경향이 있다. 새로운 팀원이 팀에 합류하면, 비공식적으로 이런 지식이 전달된다(우연한 시물레이션, 코드 검토, 기타 방법). 하지만 결코 영속적인 방식으로 진행되는 않는다. 영속적인 정보를 구축하고 전달하는 방식은 아주 중요하다. 시스템을 구축할 때, 운영자가 올바로 일을 처리할 것으로 가정하면 안 된다. 사람으로 인한 실패를 예상하라. 실수를 회복할 수 있는 도구에 대해 생각하려고 노력하라.

그냥 일반적인 좋은 이야기를 늘어놓은 것이 아니다. 원문을 읽어가면서 차분하게 검토해보기 바란다.

EOB