서버를 운영하다 보면 서버 장에 대응에 대한 고민이 생긴다. 서버란 어찌되었건 “끊김이 없어야 하는 것”이다. 단 몇분이라도 서버에 장애가 발생하면 사용자는 불편을 느낄 뿐더러 신뢰성을 잃을수 조차 있다. 쇼핑몰 서버에서 피크 타임시 발생하는 장애는 하루 매출의 반 이상을 잃게 할 수도 있다. 특정 목적의 서비스 중이라면 SLA에 따라 보상금까지 물어야 할 수도 있다.

이해가 쉽도록 “서버”를 “방송”으로 바꾸어보자. 방송사의 장비에 불량이 생겨서 몇 분 동안 검은 화면만 송출되었다고 생각하면 얼마나 큰 일인지 생각할 수 있을거다. 자체 방송중에 검은화면만 나와도 큰 일인데, 광고 타임에 검은 화면만 나왔다면 (계약에 따라) 손해배상을 해야 할 수도 있다.

증상을 조기에 알아낸다고 해도 수정·패치 작업에는 또 긴 시간이 필요하다. IT운영 인력이 부족할 경우 ‘증상이 있음’을 알아내는것 조차 어려울 수 있다. 그렇기에 가장 중요한것은 애초에 장애가 나지 않도록 하는 것이다.

어느 호스팅사에서 월 1만원짜리 웹 호스팅을 받고있다고 하자. 당장 보이는건 해당 호스팅 업체에 있는 내 사이트밖에 없다. 하지만 그 아래에는 서버의 위치 (가정집, 사내, IDC)와 회선 정보, 그리고 서버 관리능력과 안정성이 깔려있다. 사실 이런 걱정을 모두 호스팅사에 넘기기 위해 (Managed) 웹 호스팅을 쓰는것은 맞지만, 어쨋든 장애가 나면 손해는 내가 보는것이다.

단순한 웹서버라고 해도 안을 까보면 상당히 많은 구성요소가 깔려있다. 당장 글을 쓰면서 생각나는것만 해도 서버의 지리적 위치, 인터넷(회선·대역폭), 내부 장비(스위치등 일체), 전기, 무정전 시스템, 네임 시스템 서버, 물리적인 서버, 그리고 그 안에 설치된 소프트웨어 Nginx·Apache등 웹 서버 프로그램, DBMS (MySQL, PostgreSQL, MongoDB등), CGI등 백엔드 처리 프로그램등 여러가지가 떠오른다. CDN을 사용하고 있다면 Cloudflare와 같은 맨 앞단도 생각해 봐야한다.

이들중 하나만이라도 장애가 발생하면 해당 웹 서버는 접속이 불가능해 진다. 물리 서버가 고장나서 전원이 켜지지 않는것을 생각해 보자. 그 외에도 서버내에 돌아가야 할 프로그램이 죽어서 작동되지 않는 경우나 근처에서 인터넷 공사를 해서 잠시 순단될 때도 매 한가지로 접속이 되지 않는다.

이렇듯 하나만 죽어도 모든 서비스가 중지될 수 있는 지점을 단일 실패지점이라고 한다. 단일 실패지점은 물리적 장비가 될 수도 있고, 소프트웨어적인 부분이 될수도 있다. 어쨋든 중요한것은 단일 실패지점을 없에고 장애를 완화하고 대응이 끝날때 까지 버티는것이 필요하다.

근데 이것을 어떻게 버티냐? 물으면 가장 먼저 다중화를 꺼낼 수 있다. 똑같은 웹 서버를 두개 만들어서 운영하는 것이다. 하나의 장비에 불량이 나면 다른 하나가 대신해서 처리를 할 수 있다. (자세한건 failover를 찾아보자) 정전이 발생하여 전기가 끊기는것도 여러 위치에 서버를 두는것으로 해결할 수 있다. 해당 지역에 천재지변이 발생하는것도 어느정도 버틸 수 있다. 서울에 서버를 하나 두고, 부산에 서버를 하나 두는것으로서 어떻게든 버티게 할 수 있다. (지리적 분산) 인터넷을 여러개 붙이는것으로 한쪽 인터넷이 죽었을때 버티게 할 수도 있다. (Windows Network Teaming 등)

물론 그 이전에 서버의 환경을 단순화 하는것이 선행 되어야 한다. 쓸모없는 레이어를 걷어 내야한다. 예를들어, 사내에 마련한 서버는 IDC 백본에 dedicated로 연결된 네트워크에 비해 잠재적인 장애 요인이 많을 수 밖에 없다. 백본에서 내 집까지 인터넷이 오기 위해서는 여러 단계의 스위치와 게이트웨이, 릴레이를 거친다. 

하지만 IDC는 그런 단계 자체가 매우 적으며, 특히 계획된 점검에 대해서는(공사등) 아주 사소한것도 사전에 공지를 해 주기에 충분히 대응할 수 있는 여력이 있다. 

다른 곳에서도 무언가 붙으면 붙을수록 장애의 가능성이 커진다. 스위치에 장애가 발생할 수도 있고, 방화벽에 장애가 발생할 수도 있다. 이용자를 위해 붙인 CDN도 잠재적인 장애지점이다. 사이트 개발때 붙여놓은 외부 스크립트도 장애의 원인이 될 수 있다. (물론 이 경우 완전 서버가 접속이 안되는건 아닐것이다)

실패지점을 찾아서 모두 없에버리는것은 사실 불가능에 가깝다. 가능하다고 해도 비용이 엄청 들어간다. 그래서 중요한것은 어디까지를 우리가 안고 갈것인지 정하는거다. 

인터넷에 장애가 걱정되어서 KT, SKT 인터넷을 모두 붙여서 쓰는것을 고려했다. 가능하다. 근데 그 선이 결국은 빌딩내 EPS에서 들어오는데, 여기 EPS에서 장애가 발생할 수 있다는 걱정이 들었다. 이러면 선을 아예 새로 깔아야한다. 이렇게 한단계 한단계 생각을 확장하면 해결 해야할 부분이 끝도 없다.

사내 서버실에 안정성을 위해 2+개의 서버를 두었다고 생각해 보자. 이때 정전이 발생했다. 이 경우 서버는 두대지만 빌딩내 전기선은 하나에서 들어온다. UPS를 달아서 커버를 하려 했지만, 스위치등 주변 장치까지 모두 커버하는것은 쉽지 않다. 정전을 몇시간이나 버틸지 고려함에 따라서 비용도 기하급수적으로 늘어난다. 

서버를 다중화 하는 과정에서 중앙에서 컨트롤을 해 주는 프로그램이 필요할 수도 있다. 해당 프로그램이 여러개 서버중 살아있는 서버로 연결을 주선해 준다던가, 상황을 보고 부하를 분산해 주는등의 기능을 할 수 있다. 그런데 이런 프로그램이 오히려 장애의 원인이 될 수도 있다. 

웹서버에 대해서 완벽한 대응체계를 두었다고 끝이 아니다. 잠시 신경쓰지 못한 네임서버나 메일 서버등에서 장애가 발생할 수도 있다. 웹서버 자체는 잘 돌고 있는데 NS가 죽으면서 이용자들이 접속불가를 호소할 수도 있다. 메일서버가 죽음으로서 “인증 메일”이 발송되지 못해서 이용자들이 항의할 수도 있다.

뭐… 쓰면서도 억지같다는 생각이 들긴 하지만, 어쨋든 하고픈 말은 레이어·구성요소가 늘어나면 늘어날 수록 장애가 발생할 여지가 많아진다는거다. 이걸 해결하려면 어쨋던 돈을 바르는수 밖에 없고 그 수준에 따라 기하급수적으로 금액이 올라간다. 그리고 다중화를 계속해도 어느 부분의 끝에는 결국 통합되는 교차점이 생긴다.