관찰 가능성 패턴

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

로깅을 사용하는 경우

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

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

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

그림 7-1. 모놀리식 앱의 파일에 로깅합니다.

단일 컴퓨터의 플랫 파일에 로깅하는 유용성은 클라우드 환경에서 크게 줄어듭니다. 로그를 생성하는 애플리케이션은 로컬 디스크에 액세스할 수 없거나 컨테이너가 실제 머신을 중심으로 섞이기 때문에 로컬 디스크가 매우 일시적일 수 있습니다. 여러 노드에서 모놀리식 애플리케이션을 간단하게 확장하더라도 적절한 파일 기반 로그 파일을 찾기가 어려울 수 있습니다.

그림 7-2. 크기가 조정된 모놀리식 앱의 파일에 로깅합니다.

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

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

마지막으로 일부 클라우드 네이티브 애플리케이션의 사용자 수가 높습니다. 각 사용자가 애플리케이션에 로그인할 때 100줄의 로그 메시지를 생성한다고 상상해 보십시오. 격리에서는 문제가 관리 가능하지만, 사용자 수가 100,000명 이상이 되면 로그 양이 커져 로그를 효과적으로 사용하기 위해 특수한 도구가 필요하게 됩니다.

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

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

• 장황한
• 디버그
• 정보
• 경고
• 오류
• 치명적

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

로깅 도구의 고성능 및 세부 정보의 튜닝성은 개발자가 자주 로그하도록 장려해야 합니다. 많은 사람들이 각 메서드의 진입 및 종료를 로깅하는 패턴을 선호합니다. 이 방법은 과잉처럼 들릴 수 있지만 개발자가 로깅을 줄이길 원하는 경우는 거의 없습니다. 실제로 문제가 있는 메서드를 중심으로 로깅을 추가하는 목적으로만 배포를 수행하는 것은 드문 일이 아닙니다. 너무 적은 것보다 너무 많은 로그를 기록하는 쪽을 선택하세요. 일부 도구를 사용하여 이러한 종류의 로깅을 자동으로 제공할 수 있습니다.

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

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

그림 7-4. 다양한 원본의 로그는 중앙 집중식 로그 저장소로 수집됩니다.

잠재적인 앱 상태 문제 감지 및 대응과 관련된 문제

일부 애플리케이션은 중요 업무용이 아닙니다. 내부적으로만 사용되며 문제가 발생하면 사용자가 담당자에게 문의할 수 있으며 애플리케이션을 다시 시작할 수 있습니다. 그러나 고객은 사용하는 애플리케이션에 대한 기대치가 더 높은 경우가 많습니다. 사용자가 알기 전이나 알리기 전에, 애플리케이션에 문제가 발생하는 것을 먼저 알아야 합니다. 그렇지 않으면 문제에 대해 가장 먼저 아는 것은 애플리케이션이나 조직을 비하하는 소셜 미디어 게시물의 성난 홍수를 발견할 때일 수 있습니다.

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

• 애플리케이션의 한 서비스가 계속 실패하고 다시 시작되어 간헐적으로 느린 응답이 발생합니다.
• 하루 중 일부 시간에는 애플리케이션의 응답 시간이 느립니다.
• 최근 배포 후 데이터베이스에 대한 로드가 세 배로 증가했습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

경고에서 가장 해로운 패턴 중 하나는 사람이 조사할 수 없을 정도로 많은 경고를 발생시키는 것입니다. 서비스 소유자는 이전에 조사하고 양성으로 확인된 오류에 빠르게 둔감해질 것입니다. 그러면 참 오류가 발생했을 때 수백 개의 거짓 양성 노이즈에서 사라질 것입니다. 늑대를 울었던 소년의 비유는 아이들에게 이 매우 위험에 대해 경고하라는 말을 자주 들었습니다. 발생하는 경고가 실제 문제를 나타내는지 확인하는 것이 중요합니다.