서버 트래픽은 항시 변화하며, 서버 트래픽에 따라 각종 서버 리소스의 물리적 사용 가능 용량은 계속 변화합니다. 리소스 부족 시 서버 어플리케이션은 오동작을 일으키고 서비스 전체에 장애를 초래할 수 있습니다. 또한, 서버에서 동작하는 다른 서비스 어플리케이션이 100% 항상 정상적으로 동작한다고 보장할 수는 없는 것이며, 서버 운영체제를 포함하여 어떠한 이유로든 서비스 장애는 발생할 수 있습니다. 기계적인 모니터링을 통하여 하루 24시간, 일주일에 7일, 매 순간 서버의 리소스 상태를 감시하고 트래픽 과잉, 메모리 부족, 디스크 부족 등 위험 상태에 도달하면 서버 관리자에게 메일 등으로 알려주어 사전 또는 사후에 대응할 수 있도록 합니다.
모니터링을 하는 주요 이유를 요약하면 다음과 같습니다.
서비스나 웹사이트가 항상 정상적으로 유지되도록 하기 위해
사용자 또는 고객에게 일관된 성능으로 서비스를 제공하기 위해
서비스 장애 발생 이전에 서버의 비정상적 상태을 미리 감지하여 사전에 대응하기 위해
서버 상태 기록을 통해 어떤 요일, 어떤 시간대에 사용자가 몰리는지 알고 기술적으로 그리고 마케팅적으로 이용하기 위해
장애대응을 하는 이유
현재 모바일 서비스는 서버와 연동되어 동작하는 경우가 많습니다. 일반적으로 개발 아웃소싱을 줄 때 서버는 한번 만들어두면 그냥 놔두고 신경쓰지 않아도 되는 것으로 착각하기 쉽습니다. 서버 운영비를 지출하기도 아깝다고 생각하기 때문이고 별일 있겠나 싶은 마음도 있을 것입니다.
서비스가 활성화되지 못해 서버 트래픽이 더이상 늘어나지 않는다면 서버에도 별 문제가 발생하지 않을 것입니다. 하지만 서비스가 활성화되어 사용자 유입이 늘어나 서버 트래픽이 크게 늘어나게 되면 서버는 곧 장애 상황에 직면하게 됩니다. 언제 발생하지 모르는 서비스 장애상황에 24시간 대응하기 위해 3교대 인력을 확보하는 것도 부담스러운 일입니다. 따라서 서버 모니터링과 서버 장애대응은 전문적으로 수행할 수 있는 업체에 맡기는 것이 현명한 선택입니다.
장애대응을 하는 주요 이유를 요약하면 다음과 같습니다.
장애 발생 시 마다 서버를 단순 리부팅하는 원시적인 방법에서 탈피
장애 발생 시 직접 기술적인 처리가 가능한 전문인력이 대응
장애 발생 시 사전에 고객사와 협의하여 미리 정의한 '장애대응 메뉴얼'을 통해 체계적으로 대응