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

오늘날 속도의 모토는 '빠르게 실패하라'입니다. DevOps든 비즈니스든, 디지털 경제에서 운영되려면 가능한 한 완벽에 가까운 가동 시간이 필요합니다.

이 철학의 이론은 훌륭하지만, 실제로는 더 큰 실패만 초래할 뿐입니다. 근본 원인(MTTR)을 찾는 데 집중하지 않고 가용성(가동 시간)을 보장하는 데만 집중하다 보니 전례 없는 속도로 귀중한 데이터가 손실되고 있습니다. 사실 가동 시간만이 중요할 때 MTTR은 평균 해결 시간(Mean-Time-to- Resolution )이 아닌 평균 재부팅 시간(Mean-Time-to- Reboot) 이 됩니다. 그리고 해결책이 없다면, 즉 다운타임에 대한 이유가 없다면, 그 일이 다시 일어나는 것을 막을 수 없습니다.

이런 접근 방식은 사업에 해롭습니다.

아시다시피, 패킷을 버리는 게 아니라 페니의 일부를 버리는 거예요. 그리고 거래에서 극히 일부만을 빼돌려 수백만 달러를 늘리는 고전적인 범죄 수사에서 알 수 있듯이, 극히 일부라도 소중합니다. 구성요소, 서비스, 서버가 응답하지 않는 매 순간 경험적, 실존적 가치를 잃게 됩니다. 소비자는 성능 저하나 다운타임을 용납하지 않을 것이고, 기업 원장 역시 둘 중 어느 것도 용납하지 않을 것입니다.

그리고 처리량과 대역폭에 대해 아는 게 있다면 두 가지 계산의 근거가 기본 시스템에서 처리할 수 있는 초당 패킷 수에 있다는 걸 알 것입니다. 이는 네트워크에서만 적용되는 것이 아니라, 거래와 상호 작용하는 모든 구성 요소에도 적용됩니다. 앱. 애플리케이션 서비스. 라우터. 스위치. 데이터베이스 네트워크에 연결되어 있는 경우 동일한 계산에 따라야 하며 패킷을 전달하는 용량에 따라 제약을 받습니다.

경고: 수학을 앞서가다

오늘날의 네트워크 속도는 초당 수백만 개의 패킷을 처리하는 속도로 정확히 그러한 작업을 수행하고 있음을 보여줍니다. 물론, 사업 거래는 주로 HTTP 거래의 (문자적) 웹을 통해 이루어지고, 각 거래는 사업 수행에 중요한 정보를 전달합니다. 거래를 수행하는 데 필요한 패킷 수는 필요한 데이터 양에 따라 달라집니다. 평균 패킷은 1500바이트의 데이터를 전달합니다(MTU). 따라서 거래를 나타내는 JSON 페이로드를 담은 HTTP 기반 메시지가 암호화 이후에 4500바이트가 필요하다면, 이는 약 3개의 패킷에 해당합니다. 그러니 관대한 마음으로 일반적인 디지털 비즈니스 거래에 5개의 패킷이 필요하다고 가정해 봅시다. 10Gbps 네트워크는 초당 약 1,500만 개의 패킷을 처리할 수 있습니다. 충분한 컴퓨팅 용량이 있다고 가정하면 이는 300만 개의 거래에 해당한다고 말할 수 있습니다. 모든 거래의 가치가 1페니의 일부(3분의 1)에 불과하다고 가정해 봅시다. 즉 초당 100만 달러입니다.

지금은 아무도 그런 속도나 규모로 거래를 처리하지 않습니다. 심지어 Visa(대부분 기업에 필요하지 않은 속도로 데이터를 처리한다고 확신함)조차도 초당 약 24,000건의 거래를 처리할 수 있다고 주장합니다. 거래 가치를 1페니의 3분의 1로 가정하더라도 초당 8,000달러가 됩니다.

요점은 라우터, 스위치, 네트워크 및 애플리케이션 서비스 인프라, 앱 인프라, 구성 요소로 구성된 거래 체인의 실패는 매우 심각한 문제라는 것입니다. 비용이 많이 듭니다. 장애가 발생하면 패킷이 처리되지 않고, 패킷이 나타내는 돈도 그만큼 손실되기 때문입니다. 그리고 디지털 경제의 어느 부분도 패킷 전달에 의존하지 않는 부분은 없습니다.

지금까지의 답은 "빠르게 실패하라"는 주문에 있습니다. 실패한 X나 Y나 Z 또는 그 어떤 구성 요소의 새 인스턴스를 만들어내면 됩니다. 하지만 그 구성 요소는 *어떤 이유로* 실패했으며, 그 이유를 밝혀내고 해결하는 것이 매우 중요합니다. 빠르게. 실패와 복구 사이에는 여전히 사업적 가치를 저하시키는 값비싼 순간이 있기 때문입니다. 한 번 실패하면, 다시 실패할 가능성이 높습니다. 그리고 또.

가시성: MTTR이 자리 잡고 있는 초석

디지털 경제에서 성공을 거두려면 가시성이 매우 중요한 이유가 바로 여기에 있습니다. 가시성을 통해 모든 운영 부서가 실패 원인을 찾아 해결할 수 있기 때문입니다. 안타깝게도 속도 때문에 가시성이 희생되는 경우가 많습니다. 거래의 문자 그대로의 속도가 아닌, 가치 실현 시간을 의미합니다. 우리는 앱을 더 빠르고 더 자주 출시하려는 서두름으로 인해 실패를 완화하는 데 필요한 가시성을 확보하는 데 적절하게 투자하지 못했습니다.

사실, DevOps의 "빠른 실패" 철학은 그러한 실패에 대한 대응이라고 주장할 수도 있습니다. DevOps는 실패 원인을 찾아 해결할 수 있는 능력이 없기 때문에 시간을 낭비하는 것보다 가용성을 복구하는 것이 더 낫다고 판단했습니다. 기업이 애플리케이션을 배포하기 위해 멀티 클라우드 방식을 채택함에 따라 이러한 능력은 점점 더 찾기 어려워지고 있습니다.

2018년에 멀티 클라우드의 가시성 과제를 언급한 사람은 3분의 1도 안 되었습니다(31%). 2019년에는 그 숫자가 3분의 1 이상으로 늘어났습니다(39%). 멀티 클라우드의 최대 과제로 성능과 보안을 꼽았습니다. 가시성은 모니터링, 분석 및 알림을 하나로 모아 언제든지 시스템 상태에 대한 귀중한 통찰력을 제공하는 포괄적인 "관찰 가능성"의 중요한 구성 요소입니다. 특히 장애가 발생했을 때 이 기능이 중요한 이유는 시스템 상태가 여러 IT 영역에 분산되어 있어서 정보 공유가 가능하지 않을 수도 있고, 단순히 재부팅 만으로 문제를 빠르게 해결할 수도 있기 때문입니다.

분산 추적을 통해 서비스 메시가 가치를 추가하는 기능은 가시성을 강화하는 훌륭한 예입니다. 하지만 컨테이너화된 세계에서 실행되는 애플리케이션을 확장하고 보안하는 전체 애플리케이션 서비스 체인을 포함하도록 이를 확장해야 합니다. 여기에는 실행 체인의 일부일 수 있는 퍼블릭 클라우드에서 실행되는 분산 구성 요소와 애플리케이션이 포함됩니다. 가동 중지나 성능 저하를 유발하는 문제를 찾아 해결하려면 환경, 인프라, 애플리케이션 전반에 대한 가시성이 필요합니다.

조직이 MTT 재부팅 보다는 MTT 해결 에 대한 성공 측정으로 돌아가려면 가시성이 필수적입니다.