MTTR은 "평균 재부팅 시간"이 아닙니다

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

오늘날 속도를 중시하는 시대의 모토는 '빠르게 실패하라'입니다. DevOps든 비즈니스든, 디지털 경제에서 운영하려면 가동 시간을 가능한 한 완벽에 가깝게 유지해야 합니다.

이 철학은 이론적으로는 훌륭하지만, 실제로는 더 많은 장애를 초래하는 경우가 많습니다. 근본 원인을 찾는 것(MTTR)보다 가용성(가동 시간) 보장에만 집중하면서, 우리는 전례 없는 속도로 귀중한 데이터를 잃고 있습니다. 현실을 직시해야 합니다. 가동 시간에만 신경 쓰면 MTTR은 평균 해결 시간(Mean Time to Resolution)이 아니라 평균 재부팅 시간(Mean Time to Reboot)이 됩니다. 그리고 장애의 원인을 규명해 해결하지 못하면 같은 문제가 다시 발생하는 것을 막을 수 없습니다.

이러한 접근 방식은 비즈니스에 해롭습니다.

실제로 손실되는 것은 패킷이 아니라 아주 적은 금액의 수익입니다. 거래마다 1센트에도 못 미치는 금액을 빼돌려 수백만 달러를 모으는 고전적인 범죄 수법이 보여 주듯, 아무리 적은 금액도 중요합니다. 구성 요소나 서비스, 서버가 응답하지 않는 매 순간마다 경험적 가치와 실질적 가치가 모두 손실됩니다. 소비자는 성능 저하나 다운타임을 용납하지 않으며, 기업의 회계 장부 역시 그 어느 쪽도 감당할 수 없습니다.

처리량과 대역폭을 조금이라도 안다면, 두 지표 모두 기반 시스템이 초당 처리할 수 있는 패킷 수를 토대로 산정된다는 사실을 알 것입니다. 이는 네트워크뿐 아니라 트랜잭션과 상호 작용하는 모든 구성 요소에도 적용됩니다. 앱, 애플리케이션 서비스, 라우터, 스위치, 데이터베이스가 모두 해당합니다. 네트워크에 연결되어 있다면 동일한 계산의 적용을 받으며, 패킷을 전달할 수 있는 용량에 따라 제약을 받습니다.

경고: 수학 내용이 이어집니다

오늘날의 네트워크 속도 덕분에 우리는 바로 그 작업을 초당 수백만 개의 패킷을 처리하는 속도로 수행하고 있습니다. 물론 비즈니스 트랜잭션은 주로 HTTP 트랜잭션이 (말 그대로) 거미줄처럼 얽힌 구조를 통해 이루어지며, 각각의 트랜잭션은 비즈니스 수행에 필수적인 정보를 전달합니다. 트랜잭션 처리에 필요한 패킷 수는 필요한 데이터의 양에 따라 달라집니다. 평균적으로 패킷 하나에는 1,500바이트의 데이터가 담깁니다(이것이 MTU입니다). 따라서 트랜잭션을 나타내는 JSON 페이로드를 담은 HTTP 기반 메시지에 4,500바이트가 필요하다면(물론 암호화 후 기준), 이는 약 3개의 패킷에 해당합니다. 넉넉하게 잡아 일반적인 디지털 비즈니스 트랜잭션 하나에 5개의 패킷이 필요하다고 해보겠습니다. 10Gbps 네트워크는 초당 1,500만 개에 조금 못 미치는 패킷을 처리할 수 있습니다. 충분한 컴퓨팅 용량이 있다고 가정하면, 이는 300만 건의 트랜잭션에 해당한다고 볼 수 있습니다. 각 트랜잭션의 가치가 1센트의 일부(3분의 1)라고 가정해 보겠습니다. 그러면 초당 100만 달러입니다.

물론 실제로 그 정도의 속도나 규모로 트랜잭션을 처리하는 곳은 없습니다. 대부분의 기업에는 필요하지 않을 정도의 속도로 데이터를 처리한다는 데 이견이 없는 Visa조차 자사의 처리 용량이 초당 약 24,000건의 트랜잭션이라고 밝히고 있습니다. 각 트랜잭션의 가치를 동일하게 1센트의 3분의 1로 가정해도 여전히 초당 8,000달러입니다.

요점은 라우터, 스위치, 네트워크 및 애플리케이션 서비스 인프라, 앱 인프라와 각종 구성 요소로 이루어진 트랜잭션 체인에 장애가 발생하는 것은 매우 심각한 문제™라는 것입니다. 장애가 발생하면 패킷이 처리되지 않고, 그 패킷이 나타내는 금전적 가치도 처리되지 않으므로 막대한 비용이 발생합니다. 디지털 경제에서 패킷 전달에 의존하지 않는 영역은 없습니다.

지금까지의 해법은 "빠르게 실패하라(fail fast)"라는 원칙, 즉 X든 Y든 Z든 장애가 발생한 구성 요소의 새 인스턴스를 곧바로 가동하는 것이었습니다. 하지만 그 구성 요소가 실패한 데에는 *분명한 이유가 있으며*, 그 이유를 밝혀내 해결하는 것이 무엇보다 중요합니다. 신속하게 말입니다. 장애 발생부터 복구까지의 짧은 순간에도 비즈니스 가치의 손실을 초래하는 값비싼 시간은 계속 흐르기 때문입니다. 한 번 실패했다면 다시 실패할 가능성이 큽니다. 그리고 또다시 실패할 것입니다.

가시성: MTTR을 지탱하는 핵심 요소

이것이 바로 디지털 경제에서 성공하는 데 가시성이 매우 중요한 이유입니다. 모든 운영 조직이 장애의 원인을 찾아 해결할 수 있게 해 주는 것이 바로 가시성이기 때문입니다. 안타깝게도 가시성은 속도를 위해 희생되는 경우가 많습니다. 여기서 속도란 트랜잭션의 실제 처리 속도가 아니라 가치 실현까지 걸리는 시간을 의미합니다. 애플리케이션을 더 빠르고 더 자주 시장에 출시하려고 서두르는 동안, 우리는 장애를 완화하는 데 필요한 가시성을 확보하기 위한 투자를 충분히 하지 않았습니다.

실제로 DevOps의 "빠른 실패" 철학은 이러한 실패에 대한 대응이라고 볼 수도 있습니다. 장애의 원인을 찾아 해결할 수 없다면 시간을 낭비하기보다 가용성을 복구하는 편이 낫다고 DevOps는 판단한 것입니다. 조직들이 애플리케이션 배포에 멀티 클라우드 방식을 도입하면서 이러한 역량을 확보하기는 갈수록 더 어려워지고 있습니다.

2018년에는 멀티 클라우드의 가시성 문제를 언급한 응답자가 3분의 1 미만(31%)이었지만, 2019년에는 그 비율이 3분의 1 이상(39%)으로 증가해 성능 및 보안과 함께 멀티 클라우드의 가장 큰 과제로 꼽혔습니다. 가시성은 모니터링, 분석, 알림을 통합하여 언제든 시스템 상태에 관한 유용한 인사이트를 제공하는 포괄적인 "옵저버빌리티"의 핵심 요소입니다. 이는 장애 발생 시 특히 중요합니다. 시스템 상태 정보가 여러 IT 부서에 분산되어 있고, 이들 부서가 정보를 공유할 수도 있고 공유하지 않을 수도 있기 때문입니다. 이러한 정보 공유는 단순한 재부팅이 아니라 신속한 해결로 이어질 수 있습니다.

서비스 메시가 분산 추적을 통해 가치를 더하는 기능은 가시성을 확보하는 훌륭한 사례입니다. 하지만 이를 확장하여 컨테이너 환경에서 실행되는 애플리케이션의 확장성과 보안을 지원하는 애플리케이션 서비스의 전체 체인을 포괄해야 합니다. 여기에는 실행 체인의 일부일 수 있는 퍼블릭 클라우드에서 실행되는 분산 구성 요소와 애플리케이션도 포함됩니다. 다운타임이나 성능 저하를 유발하는 문제를 찾아 해결하려면 환경, 인프라 및 애플리케이션 전반에 걸친 가시성이 필요합니다.

조직이 MTT재부팅이 아닌 MTT해결을 기준으로 다시 성공을 측정하려면 가시성이 반드시 필요합니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물