서비스 중단에는 막대한 비용이 듭니다. 그 원인이 공격이든 소프트웨어 또는 하드웨어 장애든 크게 중요하지 않습니다. 현대 디지털 경제에서 API와 웹 앱에 대한 의존도가 높아지면서 서비스 중단으로 인한 분당 비용도 증가하고 있습니다.
일부 기업에는 이러한 비용이 실로 엄청납니다. 2013년 당시 Amazon이 40분간 서비스 중단을 겪으면서264만 달러의 손실을 본 것으로 추산됩니다. 계산하기 귀찮은 분들을 위해 환산하면 초당 1,100달러입니다. 이것도 끔찍하다고 생각한다면 Google의 사례를 살펴보세요. Google은 같은 해 5분간의 서비스 중단으로 분당 10만 9천 달러(또는 초당 1,816.67달러)라는 엄청난 손실을 보았으며, 총액은 무려 54만 5천 달러에 달했습니다. 단 5분 만에 말입니다. 엄밀히 말해 이것이 유일한 서비스 중단이었다면, IT 부서가 달성해야 하는 것으로 알려진 그 유명한 ‘파이브 나인(99.999%)’ 가용성에 해당합니다.
서비스 중단은 얼마나 자주 발생할까요? 아무래도 너무 자주 발생하는 것 같습니다. 아직 보지 못했다면 Pingdom의 실시간 서비스 중단 지도를 한번 살펴보세요. 전 세계 70만 명이 넘는 사용자로부터 수집한 데이터를 기반으로 만들어졌습니다. 섬뜩할 정도로 흥미로운 이 지도는 지난 한 시간 동안 전 세계에서 발생한 서비스 중단을 보여줍니다. 서비스 중단을 밝은 섬광으로 표현한 것도 인상적입니다. 사용자에게 얼마나 큰 파장을 일으키는지 확실히 실감하게 해줍니다.
즉, 원치 않는 영향을 준다는 뜻입니다.
디지털 경제는 이 문제를 더욱 악화시킵니다. 올해 초 Amazon의 S3 장애로 수많은 고객 앱과 웹사이트가 마비되었습니다. 하지만 이 문제를 퍼블릭 클라우드 제공업체의 탓으로 돌리려 한다면, builtwith.com 사이트를 잠깐만 살펴봐도 그런 생각은 금세 사라질 것입니다. CDN과 API를 활용하는 사이트의 비율은, 그로 인해 다른 누군가의 가동 시간에 의존하게 된다는 점을 고려하면 놀라울 정도로 높습니다. 외부 API나 서비스에 하나도 의존하지 않는 사이트를 찾기는 어렵습니다. 외부 서비스가 중단되면 해당 사이트도 함께 중단되므로 다운타임이 발생할 가능성이 커집니다.
기본적으로 IT 업계가 ‘파이브 나인(99.999%)’을 기준으로 삼은 이유는 100% 가용성을 달성하는 것이 불가능하기 때문입니다. 경제가 디지털 영역으로 전환되면서 초당 비용이 급증하는 오늘날, 핵심은 다운타임을 최소화하는 것입니다. 다시 말해, 짧은 평균 해결 시간(MTTR)을 요구하는 목표를 설정하는 것은 다운타임을 없애려는 노력만큼, 어쩌면 그보다 더 중요합니다.
Puppet Labs의 2016년 DevOps 현황 보고서에서 ‘고성과 조직’을 평가하는 핵심 지표 중 하나는 MTTR입니다. MTTR은 서비스 장애(예: 예기치 않은 중단 또는 서비스 성능 저하)가 발생했을 때 서비스를 복구하는 데 걸리는 시간으로 정의됩니다. 보고서의 평가에 따르면 최고 성과 조직은 1시간 미만이 걸리는 반면, 중간 및 저성과 조직은 ‘하루 미만’이 걸립니다. 보고서는 “다시 말해, 고성과 조직의 MTTR은 저성과 조직보다 24배 빨랐다”고 설명합니다.
질문이 서비스 장애가 발생할지 ‘여부’가 아니라 ‘언제’ 발생하는지였다는 점에 주목해야 합니다. 장애는 발생하기 마련이라는 전제하에, 핵심은 해결에 걸리는 시간을 최소화하는 것입니다. IHS가 2016년에 실시한 설문조사에 따르면 “설문 응답자들은 평균적으로 매월 5건의 서비스 중단을 겪으며, 월평균 중단 시간은 27시간”으로, 이로 인해 중견 조직은 평균 1달러, 대규모 조직은 최대 6천만 달러의 비용을 부담합니다.
머피의 법칙이 여전히 무어의 법칙과 콘웨이의 법칙보다 우세하다고 가정한다면, 불가피한 다운타임에 따른 시간과 비용을 줄이기 위해 MTTR을 최소화하는 것이 해답입니다.
즉, 가시성이 매우 중요하며 이를 위해서는 모니터링이 필요합니다. 아주 광범위한 모니터링이 필요합니다. 하지만 웹사이트나 웹 앱, API만 모니터링해서는 안 됩니다. 전체 스택을 모니터링해야 합니다. 네트워크부터 앱 서비스, 애플리케이션 자체에 이르기까지 모두 살펴봐야 합니다. 모든 사람이 이렇게 하는 것은 아니며, 하더라도 일관성 없이 수행하는 경우가 많습니다.
2017년 xMatters|Atlassian DevOps 성숙도 설문조사를 살펴보면, 응답자의 50%가 운영팀에서 중대 인시던트를 선언할 때까지 기다린 후 대응한다고 답했습니다. 놀랍게도 기업의 3분의 1은 고객을 통해 서비스 중단 사실을 알게 된다고 답했습니다.
디지털 경제에서는 매 순간이 중요합니다. 비용이 발생하기 때문만이 아니라 미래 수익에도 부정적인 영향을 미치기 때문입니다. 브랜드 가치와 고객 신뢰가 하락하면 구매와 사용자 수가 줄어들고, 결국 성장이 정체됩니다. 이는 조직이 나아가야 할 방향이 아닙니다.
모니터링은 서비스 중단을 일으키는 문제를 감지하기 위한 첫 단계입니다. 하지만 모니터링만으로는 MTTR을 단축할 수 없습니다. 소통이 필요합니다. 관련 이해관계자에게 최대한 신속하게 알리고 문제 해결에 필요한 정보를 제공하면 더 빠르게 문제를 해결할 수 있습니다. 즉, 공유는 DevOps의 네 가지 핵심 축 중 하나로, MTTR 개선의 핵심입니다. 아직 기업 차원에서 DevOps의 다른 측면을 도입하지 않았더라도 공유만큼은 최우선 과제로 격상하는 것을 고려해야 합니다. ChatOps를 통하든 이메일, 모바일 앱 또는 동적으로 업데이트되는 위키 페이지를 이용하든, 모니터링을 통해 얻은 정보를 조직 전체에 폭넓게 공유하는 것이 매우 중요합니다.
스위치나 서버의 작은 이상은 대수롭지 않아 보일 수 있지만, 방치하면 중요 애플리케이션이 의존하는 서비스의 절반이 중단되는 결과로 이어질 수 있습니다. Viavi가 실시한 2017년 네트워크 현황 조사에 따르면, 네트워크 및 시스템 관리자의 65%가 애플리케이션 문제를 해결할 때 가장 큰 어려움으로 “문제의 원인이 네트워크, 시스템 또는 애플리케이션 중 어디에 있는지 파악하는 것”을 꼽았습니다. 가시성을 높이고 전체 스택을 모니터링하면 이 문제를 해결하는 데 도움이 됩니다. 근본 원인을 파악하는 담당자가 데이터 경로의 모든 구성 요소의 상태와 건전성에 관한 정보를 최대한 많이 확보할 수 있기 때문입니다.
가시성은 IT의 미래를 좌우하는 핵심 요소입니다. 가시성이 없으면 장애가 발생하기 전에 대응하는 데 필요한 수준의 자동화를 달성할 수 없습니다. 또한 가시성이 없으면 평균 복구 시간(MTTR)을 실질적으로 단축할 수 없으며, 비즈니스를 지속 가능한 속도로 성장시키기도 어렵습니다.
가시성은 보안과 마찬가지로 IT의 발전을 이끄는 전략 체계에서 최우선 요소로 다뤄져야 합니다. 장애는 언제든 발생할 수 있으며, 조직이 브랜드와 수익에 미치는 피해를 최소화하면서 신속하고 효율적으로 복구할 수 있게 해 주는 것이 바로 가시성이기 때문입니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.