애플리케이션이 서버가 아닌 이유: 프로덕션 모니터링에 애플리케이션과 인프라 모두가 필요한 이유

애플리케이션을 구축하고 이를 프로덕션 환경에서 건강하게 유지하는 것은 두 가지 다른 엔지니어링 문제입니다.

빠른 수동 테스트 중에는 성공적으로 시작하고, 요청에 응답하며, 완벽해 보이는 애플리케이션을 가질 수 있습니다. 하지만 실제 사용 환경에서는 요청이 느려지고, 오류가 발생하거나, 애플리케이션이 완전히 응답하지 않을 수도 있습니다.

이런 일이 발생했을 때, 어디를 살펴봐야 할까요?

애플리케이션? 서버? 네트워크? 디스크?

정답은 무엇이 실패했는지에 달려 있습니다. 이것이 바로 프로덕션 모니터링이 애플리케이션과 그 아래의 인프라 모두를 살펴봐야 하는 이유입니다.

애플리케이션 상태만으로는 절반의 그림일 뿐이다

애플리케이션 모니터링은 소프트웨어 자체가 무엇을 하고 있는지에 초점을 맞춥니다.

모니터링 설정에 따라 유용한 신호에는 다음이 포함됩니다:

• 런타임 오류 및 충돌 (Runtime errors and crashes)
• 애플리케이션 가용성 (Application availability)
• 다운타임 (Downtime)
• 실패한 요청 및 예상치 못한 동작 (Failed requests and unexpected behavior)

이러한 신호들은 다음과 같은 질문에 답하는 데 도움이 됩니다:

• 애플리케이션이 여전히 실행 중인가?
• 프로세스가 충돌했는가?
• 서비스가 사용자에게 사용 가능한가?
• 런타임 오류가 발생하고 있는가?

하지만 애플리케이션은 자체 코드 외부의 무언가 때문에 문제를 겪을 수 있습니다.

예를 들어, 서버가 디스크 공간 부족 상태에 빠지기 때문에 데이터베이스 작업이 실패하기 시작할 수 있습니다. CPU 사용량이 지속적으로 높으면 요청이 느려질 수 있습니다. 그렇지 않으면 건강한 애플리케이션이라도 근본적인 서버가 사용 불가능하면 도달할 수 없게 될 수 있습니다.

애플리케이션 레벨의 신호만 살펴보는 것은 이러한 문제를 조사하기 더 어렵게 만들 수 있습니다.

서버 자체에도 상태 지표가 있다

애플리케이션을 실행하는 인프라는 그 자체로 유용한 신호를 생성합니다.

• CPU 사용량 (CPU usage): 지속적으로 높은 CPU 활용률은 워크로드가 가용 컴퓨팅 용량을 압도하고 있음을 나타낼 수 있습니다.
• 디스크 공간 (Disk space): 거의 가득 찬 디스크는 로그, 임시 파일, 데이터베이스 및 기타 쓰기 작업에 영향을 줄 수 있습니다.
• 네트워크 지연 시간 (Network latency): 증가하는 지연 시간은 관련 네트워크 경로상의 어딘가에 연결성 또는 성능 문제가 있음을 나타낼 수 있습니다.

서버 가용성: 기반 서버가 사용 불가능해지면, 해당 서버에 호스팅된 애플리케이션은 이전에 코드가 정상이었는지 여부와 관계없이 도달할 수 없게 될 수 있습니다.

이러한 지표들은 모든 사고의 근본 원인을 자동으로 식별하지는 않습니다. 하지만 문제를 조사하는 데 더 많은 정보를 제공합니다.

중요한 점은 애플리케이션 상태(application health)와 서버 상태(server health)가 관련되어 있지만, 같은 것은 아니라는 것입니다.

소규모 팀이 둘 다 필요한 이유

대규모 엔지니어링 조직은 지표(metrics), 로그(logs), 추적(traces), 경고 라우팅(alert routing), 인프라 모니터링을 위한 별도의 도구로 정교한 관측 가능성 스택(observability stacks)을 구축할 수 있습니다.

하지만 소규모 팀과 독립 개발자들은 종종 다른 문제를 겪습니다. 바로 설정해야 할 너무 많은 도구와 무언가 고장 났을 때 확인해야 할 장소가 너무 많다는 것입니다.

목표는 가능한 모든 지표를 수집하는 것이 아닙니다. 문제가 발생했음을 감지하고 조사를 시작하기에 충분한 유용한 신호(signals)를 수집하는 것이어야 합니다.

실용적인 시작점은 다음과 같습니다:

1. 애플리케이션이 사용 불가능해지는 시점을 파악합니다.
2. 중요한 런타임 실패(runtime failures)를 감지합니다.
3. 기반 서버의 리소스 압박을 확인합니다.
4. 주의가 필요할 때 담당자에게 경고 알림을 보냅니다.
5. 문제를 조사할 명확한 경로를 갖춥니다.

경고 알림 전달 방식(Alert delivery)도 중요합니다. 대시보드는 보고 있을 때 유용합니다. 반면, 경고 알림은 다른 일을 하고 있을 때 유용합니다.

이메일, Slack, Telegram은 개발자들이 이미 사용하는 워크플로우로 알림을 라우팅하는 다양한 방법을 제공합니다.

애플리케이션 및 서버 모니터링 통합하기

이것이 CrescoDB의 여섯 번째 기둥인 Monitor를 통해 우리가 해결하려는 문제입니다.

CrescoDB는 빌드(Build), 소유(Own), 검증(Verify), 배포(Deploy), 운영(Operate), 모니터(Monitor) 전반에 걸쳐 라이프사이클 도구(lifecycle tooling)를 확장하고 있습니다.

Monitor를 통해 우리는 애플리케이션과 그 기반 서버 모두의 가시성을 확보합니다. 여기에는 애플리케이션 충돌, 런타임 오류 및 다운타임뿐만 아니라 CPU 사용량, 디스크 공간, 네트워크 지연 시간(network latency), 서버 가용성과 같은 서버 신호가 포함됩니다.

문제가 발생했을 때, 알림은 이메일, Slack, Telegram을 통해 전송될 수 있습니다.

우리의 목표는 하나의 대시보드가 모든 프로덕션(production) 사고를 없앤다고 주장하는 것이 아닙니다. 개발자들에게 의존하는 여러 계층에서 무슨 일이 일어나고 있는지 더 명확하게 보여주는 것입니다.

모니터링은 배포 워크플로우에 속해야 합니다.

배포는 소프트웨어 라이프사이클의 끝이 아닙니다.

배포 후에도 애플리케이션은 계속 실행되어야 하고, 사용자에게 응답하며, 자원을 책임감 있게 사용하고, 조건이 변함에 따라 가용성을 유지해야 합니다.

그렇기 때문에 우리는 라이프사이클을 다음과 같이 생각합니다:

빌드(Build) → 소유(Own) → 검증(Verify) → 배포(Deploy) → 운영(Operate) → 모니터링(Monitor)

각 단계는 다른 관심사를 다루지만, 서로 협력하여 작동합니다. 검증은 출시 전에 문제를 포착하는 데 도움을 줍니다. 배포는 애플리케이션을 실행되게 합니다. 운영은 그것이 계속 실행되도록 유지합니다. 모니터링은 주의가 필요할 때 무언가를 드러내는 데 도움을 줍니다.

우리는 개발자들이 프로덕션 신뢰성을 사후 처리(afterthought)로 다룰 필요가 없기 때문에, CrescoDB를 이러한 연결된 워크플로우를 중심으로 구축하고 있습니다.

개발자를 위한 질문

여러분의 애플리케이션 중 하나가 실패하기 시작할 때, 문제의 원인이 애플리케이션에 있는지 아니면 그것을 실행하는 인프라(infrastructure)에 있는지 얼마나 빨리 알 수 있습니까?

그리고 두 가지 모두를 모니터링하기 위해 무엇을 사용합니까?

우리는 그 워크플로우를 더 간단하게 만들기 위해 CrescoDB를 구축하고 있습니다. https://crescodb.com에서 확인해 보실 수 있습니다.