한빛출판네트워크

지연율, 오류, 성능, 효율성, 그리고 블랙박스 모니터링에 초점을 맞춤으로써 고성능 시스템 구현하기

이제 당신은 (이제는 블록체인을 활용해서) 최신의 웹 애플리케이션을 만들 수 있고, 사용자들은 그런 것들을 좋아할 것입니다. 접속률은 높아질 것이고, 이제 큰 압박을 느끼기 시작할 것입니다. 그리고 어느 날 아침에 일어나보면 사이트가 밤새 느려져 있고, 사용자들이 불평하고 있다는 것을 알게 될 것입니다. 문제를 어디에서 찾을 수 있을까요?

당신이 웹사이트나 내부 애플리케이션을 개발하는 개발자이든, 이런 것들을 포괄하는 시스템을 관리하는 관리자이던 간에, 당신의 업무는 이런 작업들이 한번 동작하기 시작하면 멈추지 않게 하는 것입니다. 시스템 오류나, 버그가 담긴 배포, 그리고 사용률의 증가는 관리할 필요가 있는 문제로 직결됩니다. 이런 문제를 파악하기 위해서는 모니터링을 해야 합니다.

그러나 모니터링은 어떤 것들이 잘못되었을 때, 단순히 경고를 보내는 것 이외에도 다른 것들을 할 수 있습니다. 모니터링을 통해서 문제들을 디버깅할 수 있게 도와주고, 미래에는 이런 문제가 발생하지 않도록 막을 수 있습니다. 그러면 어떤 항목들을 모니터링 해야 할까요?

1. Latency (지연율)

웹페이지가 빠르게 접근될수록 사용자는 불편을 느끼지 않습니다. 이 반대도 존재하는데, 지연율이 높아지면, 사용자의 불만족을 야기하게 되고, 어쩌면 현재의 시스템에 문제가 있다는 것을 나타내는 첫번째 경고가 될 수 있습니다. 자원에 치중한 기능을 수행한다는 것은 보통 더 많은 사용자들의 요청이 동반된다는 것을 의미합니다. 그래서 서버가 죽는다면, 지연율은 커지게 됩니다. 사실 지연율은 충돌의 증가로 인해서 반응이 비선형적으로 증가하는 경향이 있습니다. 그래서 현재 지연율이 낮게 증가하더라도, 미래에는 더 큰 지연율 증가로 나타날 수 있습니다. 그렇기 때문에 빠른 탐지는 이런 문제들을 해결할 수 있는 약간의 시간을 제공해줍니다.

지연율은 일반적으로 두가지 측면에서 측정할 수 있습니다. 첫번째는 사용자 측면이고, 다른 하나는 시스템 측면입니다. 사용자 브라우저 내에서 관측 수단을 가지게 되면 자바스크립트나 정적 요소들이 커지면서 사용자 경험이 느려지는 것과 같은 문제들을 파악할 수 있게 됩니다. 이런 측정방식은 사용자 각각의 하드웨어나, 네트워크 환경, 인터넷 연결 방식으로 인해 큰 분산을 가지게 될 것입니다. 백엔드 시스템에서 측정하게 되면 이전보다는 덜 오차가 생기겠지만 전체 사용자 경험을 파악할 수 없을 것입니다. 그렇기 때문에 두가지 측면에서 모두 측정하는 것이 바람직합니다. 브라우저 단계에서 지연율을 측정하면 출시로 인해서 발생한 프론트엔드 상의 문제를 파악할 수 있고, 백엔드상에서 모니터링하면 그 나머지들을 파악할 수 있습니다.

하지만 이렇게 지연율 정보를 얻고 난 후에는 어떤 것을 할 수 있을까요? 할 수 있다면 밀리초 단위로 지연율이 증가하는 것을 확인할 수 있겠지만, 당신이 잠든 새벽 3시에도 깰 만큼 중요한 이유는 아닐 것입니다. 이때 좋은 것은 서비스 차원의 동의(SLA)에 기반해서 경고 수준을 정하는 것입니다. 만약 이런 SLA를 가지고 있지 않다면, 뭔가 급박하게 비정상적이라고 나타낼 수 있을 만한 수치를 경고 수준으로 선택하십시오. 예를 들어 평소의 지연율이 50ms에서 100ms 사이에 분포되어 있다면, 200ms 정도가 좋은 경고 수준이 될 것입니다.

이렇게 즉각적인 반응이 필요한 경고 이외에도, 매주, 매달, 그리고 분기별로 개발속도나 시스템이 얼마나 동적인지를 나타내는 지연율 수치를 되돌아보는 것도 현명합니다. 이런 수치를 되돌아봄으로써 경향을 미리 파악하는 것은 경고 때문에 기술자들을 고생시키는 것보다 더 좋습니다.

2. Errors (오류)

지연율이 사용자 측면에서 굼뜬 것처럼 느껴지는 것이라면, 오류는 더 명백한 문제들을 야기하는 경향이 있습니다. 오류가 발생하는 요소로는 시스템상의 버그일 수도 있고, 새로운 브라우저상의 나쁜 반응, 혹은 로드가 증가하면서 발생하는 타임아웃 등을 들 수 있습니다. 이런 것들은 고장이나 심각한 문제를 발생시킬 수 있습니다.

보통은 프론트엔드 전체에서부터 데이터가 저장되는 백엔드까지 모든 단계에서 발생하는 오류에 대해서 알기를 원할 것입니다. 하지만 위와 같은 경향은 매번 오류가 발생할 때마다 경고를 받을 필요가 있다는 것을 의미하는 것은 아닐 것입니다. 예를 들어 만약 데이터베이스상에서의 오류가 애플리케이션에서 발생하는 오류로 인해 발생하는 것이라면, 애플리케이션 오류로 인한 경고면 충분할 것일텐데, 그 이유는 해당 경보가 데이터베이스의 오류와 그 이상의 것들을 다 포함하기 때문입니다. 하지만 그래도 애플리케이션 오류가 데이터베이스를 야기하는 것인지를 확인하기 위해서는 대시보드 상에서 두 오류에 대해서는 여전히 보여줘야 합니다. 다르게 표현하면, 만약 상위 시스템에 오류를 발생시킬 수 없는 별도의 백엔드 시스템이 있을 경우, 애플리케이션 오류 경고로는 그런 오류를 잡을 수 없기 때문에 별도의 백엔드 시스템에 대한 경보를 할 필요는 있습니다.

오류에 대한 경고와 이 정보를 담을 대시보드를 만들 때, 단순히 오류의 수를 보여주는 것보다는 전체 요청 수 대비 오류의 비율을 사용하는 것이 좋습니다. 예를 들어, 초당 오류율은 접속량이 큰 동안에는 일반적으로 보이겠지만, 적은 부하가 가해지는 시점에는 나쁜 신호로 보여질 수 있습니다. 오류 비율이 5%라는 것을 알고 있는 점도 비교할 때 측면에서는 조금 더 도움이 되며, 접속량이 커지더라도 경보에 대한 수준을 갱신할 필요가 없어지게 됩니다.

결국, 기억해야 할 것은 모든 오류들이 동등하지 않다는 것입니다. 만약 당신이 사용자가 파일을 업로드 할 수 있고, 이를 처리하며, HTTP를 통해서 이를 전달하는 시스템을 가지고 있다고 가정해봅시다. 만약 저장소 백엔드가 시간초과 오류가 발생한다면, 당신의 시스템은 명백하게 문제가 발생한 것입니다. 하지만 특정 사용자가 잘못 형성된 요청을 사용하는 경우라면, 이런 잘못된 요청이 충분히 쌓여서 고장난 프론트엔드 단에서 조사할 필요가 생길 때까지는 해당 오류를 무시할 수도 있습니다. 이와 유사하게 사용자의 오류나 완전히 처리되지 않은 파일을 업로드하거나 또는 업로드된 파일이 유실이 된다던 지와 같은, 정의되어 있지 않은 요청에 대해서는 무시하게끔 할 수도 있습니다. 하지만 잘못된 요청처럼 이런 오류가 많이 발생할 경우에는 관리자에게 경고할 필요는 존재합니다.

3. Throughput (성능)

앞에서 소개한 오류 비율에 대해서 이해하기 위해서는, (성능과 같이) 당신이 전달하고 있는 요청의 수에 알 필요가 있습니다. 성능 이슈로 인해 디버깅을 할 때 현재의 성능에 대해서 이해하고 있는 것을 통해 같은 시간동안 접속량이 증가해서 결국 저장공간 문제를 야기하는지를 알 수 있습니다.

이런 성능에 대한 즉각적인 디버깅을 넘어서 성능에 대한 모니터링은 현재의 접속량이 지난 몇달이나 몇 년동안 얼마나 증가했는지에 대해서 이해할 수 있도록 도와줍니다. 이는 자원 할당 계획에 있어서 중요한 부분인데, 이를 통해 미래에는 접속량이 어떻게 될지를 예측하는데 도움을 주게 됩니다. 당신은 아마 자원과 예산에 대해서 간략하게 표현하길 원치 않을 것이고, 그렇다고 과다로 쓰는 것도 원하지 않을 것입니다.

단순한 요청 횟수보다도 더 중요하게 고려해야 할 요소들이 있습니다. 바로 요청이 어디서 왔는지를 추적하는 것과 처리되는 작업들이 저렴하고 비싼 건지의 여부도 추적하는 것이 도움이 됩니다. 예산 같은 경우는 CPU나 네트워크 대역폭 같은 것으로 수치화를 시킬 수 있습니다. 또는 사용자가 지질학적으로 어디에 위치해 있는지를 알아서 이에 맞게끔 데이터 센터를 위치시킬 수도 있습니다.

4. Utilization (효율성)

자원 할당 계획은 현재 충분한 자원을 가지고 있다는 것을 가정해야 하지만, 항상 이런 케이스가 존재하는 것은 아닙니다. 때로는 성장이 예상치를 넘어설 수도 있고, 특정 기능 동작으로 인해 계획되지 않은 예산이 소비됨으로써 접속 불량이나 갑작스런 기기의 고장으로 나타날 수 있습니다. 이 때 효율성이 등장하게 됩니다. 효율성이란 현재의 시스템이 최대로 가용할 수 있는 자원 에 얼마나 가까운지를 표현하는 수치입니다. 일반적으로 CPU에 대해서 정의되지만, 때로는 네트워크 대역폭이나, 저장공간, 혹은 램과 같이 다른 자원으로 대체될 수 있습니다.

이렇게 현재 접속량에 대해서 보유한 기기가 얼마나 효율성을 가지는지 정의하는 것은 당신이 이런 접속 증가 추세를 활용해서 하드웨어나 자산이 얼마나 필요한지를 예측할 수 있게 도와줍니다. 예를 들어 하나의 CPU를 통해서 초당 100개의 요청을 처리할 수 있고, 미래에는 초당 200개의 요청을 처리해야 한다면, 이 일을 처리하기 위해서는 적어도 2개의 CPU가 필요하다는 것을 알게 될 것입니다. 조심해야 할 것은 이렇게 접속량이 증가하게 되면, Universal Scalability Law에서 정의된 모델과 같이 자원이 선형의 추세보다는 더 빠르게 필요하다는 것입니다.

5. Blackbox monitoring (블랙박스 모니터링)

해당 기능이 동작하고 있을까요? 외부에서 당신의 서비스가 동작하는지를 모니터링하는 것을 보통 블랙박스 모니터링이라고 알고 있습니다. 내부에 있는 당신의 네트워크 상에서는 백엔드 서버상에서 잘 동작하는 것처럼 보일 수 있지만 중간에 부하 분산기나 잘못 설정된 인터넷 라우터가 있으면 사용자가 잘 접속하는 것을 막을 수 있습니다. 그렇기 때문에 접속이 잘 되는지를 확인하기 위해 몇 가지 항목에 대해서는 외부망에서 모니터링 하는 것이 필요합니다. 이를 통해 갑작스런 문제 발생시, 사용자가 서비스를 이용하는데 있어 이슈를 파악할 때 유용할 수 있습니다. 비록 이런 값들이 좋은 신호 대 오류 비율로 나타내기에는 어려운 부분이 있기도 합니다.

또한 유저 로그인과 같이 핵심 기능들이 잘 동작하는지 여부도 확인하는 것이 중요합니다. 저같은 경우에는 이를 회귀 방식보다는 아무것도 모르는 테스트 방식으로 처리할 것을 추천드립니다. 블랙박스 모니터링의 주요 목적으로는 현재의 시스템이 심각하게 고장났는지 여부를 확인하는 것이지만, 때로는 엄청나게 무겁고 복잡한 테스트시 약간 특이하거나 특별한 부분을 확인할 수 있는 경향을 가지고 있기도 합니다. 이때 이런 것만 찾는 모니터링을 할 경우 기술자는 어떤 오류를 찾아내는데 있어서 전력을 다하게 될 것입니다. 만약 사용자의 암호가 32자를 넘어서 로그인이 되지 않는 것과 같은 조금 미묘한 오류가 발생할 경우에는 위에서 언급한 수치나, 오류 로그, 그리고 사용자 버그 리포트 등을 통해서 효과적으로 잡을 수 있습니다.

현재의 시스템을 커버하는 모니터링 활용

위에서 소개한 지연율, 오류, 성능, 효율성, 그리고 블랙박스 모니터링을 적절히 조합하면, 아마 필요한 모든 것들이 만족될 것입니다. 물론 이런 5개의 영역이 모든 가능한 문제를 다 잡지 못할 수 있습니다. (가끔 이렇게 모든 문제를 잡지 못하고, 결과도 빠르게 감소할 것입니다.) 하지만 적어도 충분한 정보를 제공함으로써 시스템이 부드럽게 잘 동작함으로써 자신감을 주게 될 것입니다.

*****

저자 : Brian Brazil

Brian Brazil은 Robust Perception의 창립자이며, Prometheus의 개발자입니다. 그는 Prometheus 커뮤니티에 잘 알려져 있으며, 컨퍼런스에서도 프레젠테이션을 많이 진행했고, 그의 블로그는 커뮤니티 내에서 널리 읽혀지고 있습니다.

역자 : 강찬석

한 전자회사에서 시스템 소프트웨어 엔지니어로 있으면서 딥러닝 관련 연구를 하고 있습니다. 컴퓨터에 관해서 다양하고 광범위한 주제에 관심을 가지고 있으며, 배운 지식을 블로그(http://talkingaboutme.tistory.com)를 통해 공유하는 것을 더 좋아하는 사람입니다.

원문 : 5 things you should be monitoring