가시성 패턴

팁

이 콘텐츠는 Azure용 클라우드 네이티브 .NET 애플리케이션 설계 eBook 에서 발췌한 것으로, .NET 문서에서 제공되거나 오프라인 상태에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.

PDF 다운로드

애플리케이션의 코드 레이아웃을 지원하기 위해 패턴이 개발된 것처럼 신뢰할 수 있는 방식으로 애플리케이션을 운영하기 위한 패턴이 있습니다. 애플리케이션 유지 관리에 유용한 세 가지 패턴인 로깅, 모니터링 및 경고가 등장했습니다.

로깅을 사용하는 경우

아무리 주의하더라도 애플리케이션은 거의 항상 프로덕션에서 예기치 않은 방식으로 작동합니다. 사용자가 애플리케이션 관련 문제를 보고할 때 문제가 발생했을 때 앱에서 무슨 일이 있었는지 확인할 수 있으면 유용합니다. 애플리케이션이 실행되는 동안 수행하는 작업에 대한 정보를 캡처하는 가장 많이 시도되고 실질적인 방법 중 하나는 애플리케이션이 수행하는 작업을 기록하도록 하는 것입니다. 이 프로세스를 로깅이라고 합니다. 언제든지 프로덕션에서 오류 또는 문제가 발생할 때 목표는 비프로덕션 환경에서 오류가 발생한 조건을 재현하는 것입니다. 적절한 로깅을 사용하면 개발자가 테스트하고 실험할 수 있는 환경에서 문제를 복제하기 위해 따라야 하는 로드맵이 제공됩니다.

클라우드 네이티브 애플리케이션으로 로깅할 경우 과제

기존 애플리케이션에서 로그 파일은 일반적으로 로컬 컴퓨터에 저장됩니다. 실제로 Unix 같은 운영 체제에는 일반적으로 /var/log 아래에 로그를 포함하도록 정의된 폴더 구조가 있습니다.

그림 7-1. 모놀리식 앱에서 파일에 로그

단일 컴퓨터의 플랫 파일에 로그하는 기능의 유용성은 클라우드 환경에서 크게 감소합니다. 로그를 생성하는 애플리케이션이 로컬 디스크에 액세스할 수 없거나, 컨테이너가 물리적 컴퓨터를 중심으로 순서를 섞기 때문에 로컬 디스크가 매우 일시적일 수 있습니다. 여러 노드에서 모놀리식 애플리케이션을 간단하게 스케일 업하는 것만으로도 적절한 파일 기반 로그 파일을 찾기가 어려울 수 있습니다.

그림 7-2. 스케일링된 모놀리식 앱에서 파일에 로그

마이크로 서비스 아키텍처를 사용하여 개발된 클라우드 네이티브 애플리케이션도 파일 기반 로거와 관련된 몇 가지 문제가 있습니다. 사용자 요청은 이제 서로 다른 컴퓨터에서 실행되는 여러 서비스에 걸쳐 있을 수 있으며 로컬 파일 시스템에 전혀 액세스할 수 없는 서버리스 함수를 포함할 수 있습니다. 많은 서비스 및 컴퓨터에서 사용자 또는 세션의 로그를 상호 연결하는 것은 매우 어려운 일입니다.

그림 7-3. 마이크로 서비스 앱에서 로컬 파일에 로그

마지막으로 일부 클라우드 네이티브 애플리케이션은 사용자 수가 많습니다. 각 사용자가 애플리케이션에 로그인할 때 100줄의 로그 메시지를 생성한다고 가정해 봅니다. 개별적으로는 관리가 가능하지만 해당 로그에 100,000명 이상의 사용자를 곱해 보세요. 로그를 효과적으로 사용할 수 있으려면 특수 도구가 필요할 만큼 로그 볼륨이 커집니다.

클라우드 네이티브 애플리케이션에서 로그

모든 프로그래밍 언어에는 로그 작성을 허용하는 도구가 있으며 일반적으로 이 로그를 작성하는 오버헤드는 낮습니다. 대부분의 로깅 라이브러리는 런타임에 튜닝할 수 있는 다양한 종류의 위험한 상태를 로그하는 기능을 제공합니다. 예를 들어 Serilog 라이브러리는 다음 로깅 수준을 제공하는 .NET에 대한 인기 있는 구조적 로깅 라이브러리입니다.

• 자세한 정보 표시
• 디버그
• 정보
• 경고
• 오류
• Fatal

이 다양한 로그 수준은 로깅의 세분성을 제공합니다. 애플리케이션이 프로덕션에서 제대로 작동하는 경우 중요한 메시지만 로그하도록 구성할 수 있습니다. 애플리케이션이 잘못 동작하는 경우 로그 수준을 늘려서 더 자세한 로그를 수집할 수 있습니다. 이를 통해 디버깅의 용이성과 성능 간에 균형을 유지할 수 있습니다.

고성능 로깅 도구와 세부 정보 표시의 튜닝 가능성 덕분에 개발자는 자주 로그하게 됩니다. 많은 사람들이 각 메서드의 시작과 종료를 로그하는 패턴을 선호합니다. 이 접근 방식은 지나치게 들릴 수 있지만 개발자가 더 적은 로깅을 원하는 경우는 거의 없습니다. 실제로 문제가 있는 메서드를 중심으로 로깅을 추가하는 용도로만 배포를 수행하는 것은 드문 일이 아닙니다. 너무 적은 로깅이 아니라 너무 많은 로깅에 지나칠 정도로 신경쓰는 것이 좋습니다. 일부 도구는 이 종류의 로깅을 자동으로 제공하는 데 사용할 수 있습니다.

클라우드 네이티브 앱에서 파일 기반 로그를 사용하는 것과 관련된 문제 때문에 중앙 집중식 로그가 선호됩니다. 로그는 애플리케이션에서 수집하며 로그를 인덱싱하고 저장하는 중앙 로깅 애플리케이션에 전달됩니다. 이 클래스의 시스템은 매일 수십 기가바이트의 로그를 수집할 수 있습니다.

또한 많은 서비스에 걸쳐 있는 로깅을 빌드할 때 몇 가지 표준 사례를 따르는 것이 유용합니다. 예를 들어 긴 상호 작용을 시작할 때 상관 관계 ID를 생성한 다음, 해당 상호 작용과 관련된 각 메시지에 로그하면 모든 관련 메시지를 더 쉽게 검색할 수 있습니다. 단일 메시지만 찾고 상관 관계 ID를 추출하여 모든 관련 메시지를 찾으면 됩니다. 또 다른 예제는 서비스가 사용하는 언어 또는 로깅 라이브러리에 관계없이 모든 서비스에 대해 로그 형식이 동일한지 확인하는 것입니다. 이 표준화를 사용하면 로그를 훨씬 더 쉽게 읽을 수 있습니다. 그림 7-4에서는 마이크로 서비스 아키텍처가 워크플로의 일부로 중앙 집중식 로깅을 활용하는 방법을 보여 줍니다.

그림 7-4. 다양한 소스의 로그는 중앙 집중식 로그 저장소로 수집됨

잠재적인 앱 상태 이슈를 탐지하고 이에 대응하는 과제

일부 애플리케이션은 중요 업무용이 아닙니다. 내부적으로만 사용될 수 있으며, 문제가 발생하면 사용자가 담당 팀에 문의할 수 있으며 애플리케이션을 다시 시작할 수 있습니다. 그러나 고객은 일반적으로 사용하는 애플리케이션에 대한 기대치가 더 높습니다. 사용자가 알기 전에 또는 사용자가 알리기 전에 애플리케이션에 문제가 발생할 때 이를 알고 있어야 합니다. 그렇지 않으면 문제에 관한 처음 아는 것이 애플리케이션이나 조직을 조롱하는 소셜 미디어 게시물이 미친듯이 올라오는 것을 발견할 때일 수 있습니다.

고려해야 할 몇 가지 시나리오는 다음과 같습니다.

• 애플리케이션의 한 서비스가 계속 실패하고 다시 시작되어 간헐적으로 응답이 느려집니다.
• 하루 중 어느 때에 애플리케이션의 응답 시간이 느립니다.
• 최근 배포 후 데이터베이스에 대한 부하가 세 배가 되었습니다.

제대로 구현된 모니터링은 문제가 발생할 수 있는 조건에 대해 알려 주므로 사용자에게 큰 영향을 미치기 전에 근본적인 상태를 해결할 수 있습니다.

클라우드 네이티브 앱 모니터링

일부 중앙 집중식 로깅 시스템은 기본 로그 외부에서 원격 분석을 수집하는 추가적인 역할을 수행합니다. 데이터베이스 쿼리 실행 시간, 웹 서버의 평균 응답 시간, 운영 체제에서 보고한 CPU 부하 평균 및 메모리 압력 등의 메트릭을 수집할 수 있습니다. 로그와 함께 이 시스템에서는 전체로서 시스템 및 애플리케이션의 노드 상태를 전체적으로 파악할 수 있습니다.

모니터링 도구의 메트릭 수집 기능은 애플리케이션 내에서 수동으로 공급할 수도 있습니다. 신규 사용자 등록 또는 주문과 같이 특히 관심 있는 비즈니스 흐름을 계측하여 중앙 모니터링 시스템에서 카운터를 증분시킬 수 있습니다. 이 측면을 기반으로 모니터링 도구를 통해 애플리케이션 상태뿐만 아니라 비즈니스 상태를 모니터링할 수 있습니다.

쿼리는 로그 집계 도구에서 생성하여 특정 통계 또는 패턴을 찾은 다음, 사용자 지정 대시보드에 그래픽 형식으로 표시할 수 있습니다. 팀은 애플리케이션과 관련된 통계를 순환 표시하는 대형 벽걸이 디스플레이에 투자하는 경우가 많습니다. 이렇게 하면 문제가 발생할 때 쉽게 확인할 수 있습니다.

클라우드 네이티브 모니터링 도구는 단일 프로세스 모놀리식 애플리케이션 또는 분산형 마이크로 서비스 아키텍처인지 여부에 관계없이 앱에 대한 실시간 원격 분석 및 인사이트를 제공합니다. 여기에는 앱의 데이터 수집을 허용하는 도구와 앱 상태에 대한 정보를 쿼리하고 표시하는 도구가 포함됩니다.

클라우드 네이티브 앱의 중요한 문제에 대응하는 과제

애플리케이션의 문제에 대응해야 하는 경우 적절한 담당자에게 경고하는 방법이 필요합니다. 이것은 세 번째 클라우드 네이티브 애플리케이션 가시성 패턴이며 로깅 및 모니터링에 따라 달라집니다. 문제를 진단하고 경우에 따라 모니터링 도구에 공급할 수 있으려면 애플리케이션에 로깅이 적용되어 있어야 합니다. 애플리케이션 메트릭 및 상태 데이터를 한 곳에서 집계하려면 모니터링이 필요합니다. 이 기능이 설정되고 나면 특정 메트릭이 허용 가능한 수준을 벗어나면 경고를 트리거하는 규칙을 만들 수 있습니다.

일반적으로 경고는 특정 조건이 적절한 경고를 트리거하여 팀 멤버들에게 긴급한 문제를 알리도록 모니터링을 기반으로 계층화됩니다. 경고가 필요할 수 있는 몇 가지 시나리오는 다음과 같습니다.

• 애플리케이션의 서비스 중 하나가 가동 중지 시간 1분 후에 응답하지 않습니다.
• 애플리케이션이 1% 이상의 요청에 실패한 HTTP 응답을 반환합니다.
• 주요 엔드포인트에 대한 애플리케이션의 평균 응답 시간이 2,000ms를 초과합니다.

클라우드 네이티브 앱의 경고

모니터링 도구에 대한 쿼리를 만들어 알려진 오류 조건을 찾을 수 있습니다. 예를 들어 쿼리는 들어오는 로그를 통해 웹 서버의 문제를 나타내는 HTTP 상태 코드 500 표시를 검색할 수 있습니다. 이 중 하나가 검색되는 즉시 조사를 시작할 수 있는 원래 서비스의 소유자에게 메일 또는 SMS를 보낼 수 있습니다.

하지만 일반적으로 단일 500 오류만으로는 문제가 발생했음을 확인할 수 없습니다. 사용자가 암호를 잘못 입력했거나 잘못된 형식의 데이터를 입력했음을 의미할 수 있습니다. 경고 쿼리는 평균 500 오류 수보다 많이 검색된 경우에만 발생하도록 만들 수 있습니다.

경고의 가장 해로운 패턴 중 하나는 사람이 조사할 너무 많은 경고를 발생시키는 것입니다. 서비스 소유자는 이전에 조사하고 심각하지 않은 것으로 확인된 오류에 빠르게 둔감해질 것입니다. 이후 실제 오류가 발생할 때 해당 오류는 수백 개 가양성의 노이즈에서 주목을 받지 못합니다. 양치기 소년의 비유는 아이들에게 바로 이 위험에 관해 경고하기 위해 자주 언급됩니다. 발생하는 경고가 실제 문제를 나타내는지 확인하는 것이 중요합니다.

이전다음