마이크로 서비스의 복원력 및 고가용성

예기치 않은 오류를 처리하는 것은 특히 분산 시스템에서 해결해야 할 가장 어려운 문제 중 하나입니다. 개발자가 작성하는 대부분의 코드에는 예외 처리가 포함되며 테스트에 가장 많은 시간이 소요됩니다. 문제는 오류를 처리하기 위해 코드를 작성하는 것보다 더 많이 관련됩니다. 마이크로 서비스가 실행되는 컴퓨터가 실패하면 어떻게 되나요? 이 마이크로 서비스 오류(자체적으로 어려운 문제)를 감지해야 할 뿐만 아니라 마이크로 서비스를 다시 시작해야 합니다.

마이크로 서비스는 오류에 대한 복원력이 있어야 하며 가용성을 위해 다른 컴퓨터에서 자주 다시 시작할 수 있어야 합니다. 또한 이 복원력은 마이크로 서비스를 대신하여 저장된 상태, 마이크로 서비스에서 이 상태를 복구할 수 있는 상태 및 마이크로 서비스가 성공적으로 다시 시작할 수 있는지 여부로 내려옵니다. 즉, 컴퓨팅 기능의 복원력(프로세스는 언제든지 다시 시작될 수 있음)뿐만 아니라 상태 또는 데이터의 복원력(데이터 손실 없음 및 데이터는 일관성 유지)이 있어야 합니다.

복원력 문제는 애플리케이션 업그레이드 중에 오류가 발생하는 경우와 같은 다른 시나리오에서 더욱 복잡해집니다. 배포 시스템과 함께 작동하는 마이크로 서비스는 최신 버전으로 계속 이동할 수 있는지, 아니면 이전 버전으로 롤백하여 일관된 상태를 유지할 수 있는지 여부를 결정해야 합니다. 계속 진행할 수 있는 충분한 컴퓨터를 사용할 수 있는지 여부 및 이전 버전의 마이크로 서비스를 복구하는 방법을 고려해야 합니다. 이 방법을 사용하려면 전체 애플리케이션 및 오케스트레이터가 이러한 결정을 내릴 수 있도록 마이크로 서비스가 상태 정보를 내보내야 합니다.

또한 복원력은 클라우드 기반 시스템이 동작해야 하는 방식과 관련이 있습니다. 앞서 설명한 것처럼 클라우드 기반 시스템은 오류를 수용해야 하며 자동으로 복구를 시도해야 합니다. 예를 들어 네트워크 또는 컨테이너 오류가 발생할 경우 클라이언트 앱 또는 클라이언트 서비스에는 메시지 전송을 다시 시도하거나 요청을 다시 시도하는 전략이 있어야 합니다. 대부분의 경우 클라우드의 오류는 부분적이기 때문에. 이 가이드의 복원력 있는 애플리케이션 구현 섹션에서는 부분 오류를 처리하는 방법을 설명합니다. 이 문서에서는 이 주제를 처리하는 다양한 정책을 제공하는 Polly와 같은 라이브러리를 사용하여 .NET에서 지수 백오프 또는 회로 차단기 패턴을 사용한 재시도와 같은 기술을 설명합니다.

마이크로 서비스의 상태 관리 및 진단

명백해 보일 수 있고 종종 간과되기도 합니다만, 마이크로서비스는 자신의 상태 및 진단을 보고해야 합니다. 그렇지 않으면 작업 관점에서 인사이트가 거의 없습니다. 독립적인 서비스 집합 간의 진단 이벤트를 상관시키고, 기계 시계 오차를 처리하여 이벤트 순서를 이해하는 것은 어려운 일입니다. 합의된 프로토콜 및 데이터 형식을 통해 마이크로 서비스와 상호 작용하는 것과 동일한 방식으로, 궁극적으로 쿼리 및 보기를 위해 이벤트 저장소에서 끝나는 상태 및 진단 이벤트를 기록하는 방법에 대한 표준화가 필요합니다. 마이크로 서비스 접근 방식에서는 여러 팀이 단일 로깅 형식에 동의하는 것이 핵심입니다. 애플리케이션에서 진단 이벤트를 보는 일관된 접근 방식이 있어야 합니다.

건강 상태 검사

상태는 진단과 다릅니다. 건강은 마이크로서비스가 현재 상태를 보고하여 적절한 조치를 취하는 것입니다. 가용성을 유지하기 위해 업그레이드 및 배포 메커니즘을 사용하는 것이 좋은 예입니다. 프로세스 충돌 또는 컴퓨터 재부팅으로 인해 서비스가 현재 비정상 상태일 수 있지만 서비스는 여전히 작동 중일 수 있습니다. 업그레이드를 수행하여 상황을 악화시키는 것은 필요하지 않습니다. 가장 좋은 방법은 먼저 조사를 수행하거나 마이크로 서비스가 복구되는 시간을 허용하는 것입니다. 마이크로 서비스의 상태 이벤트는 정보에 입각한 의사 결정을 내리는 데 도움이 되며 사실상 자가 복구 서비스를 만드는 데 도움이 됩니다.

이 가이드의 ASP.NET Core 서비스에서 건강검진 구현하기 섹션에서는 마이크로서비스에서 새로운 ASP.NET HealthChecks 라이브러리를 사용하는 방법을 다룹니다. 이 라이브러리를 통해 마이크로서비스는 상태를 모니터링 서비스에 보고하여 적절한 조치를 취할 수 있습니다.

또한 GitHub 및 NuGet 패키지로 사용할 수 있는 AspNetCore.Diagnostics.HealthChecks라는 우수한 오픈 소스 라이브러리를 사용할 수도 있습니다. 이 라이브러리는 독특한 방식으로 두 가지 유형의 상태 검사를 수행합니다.

• 활동성: 마이크로 서비스가 활성 상태인지, 즉 요청을 수락하고 응답할 수 있는지 확인합니다.
• 준비 상태: 마이크로 서비스의 종속성(데이터베이스, 큐 서비스 등)이 준비되었는지 확인하여 마이크로 서비스가 수행해야 하는 작업을 수행할 수 있도록 합니다.

진단 및 로그 이벤트 스트림 사용

로그는 예외, 경고 및 간단한 정보 메시지를 포함하여 애플리케이션 또는 서비스가 실행되는 방법에 대한 정보를 제공합니다. 일반적으로 각 로그는 이벤트당 한 줄의 텍스트 형식이지만 예외는 여러 줄에 걸쳐 스택 추적을 표시하는 경우가 많습니다.

모놀리식 서버 기반 애플리케이션에서 디스크의 파일(로그 파일)에 로그를 쓴 다음 모든 도구를 사용하여 분석할 수 있습니다. 애플리케이션 실행은 고정 서버 또는 VM으로 제한되므로 일반적으로 이벤트 흐름을 분석하기에는 너무 복잡하지 않습니다. 그러나 오케스트레이터 클러스터의 여러 노드에서 여러 서비스가 실행되는 분산 애플리케이션에서 분산 이벤트를 상호 연결할 수 있는 것은 어려운 일입니다.

마이크로 서비스 기반 애플리케이션은 이벤트 또는 로그 파일의 출력 스트림을 단독으로 저장하려고 하지 않아야 하며, 중앙 위치로의 이벤트 라우팅을 관리하려고 시도하지 않아야 합니다. 투명해야 합니다. 즉, 각 프로세스는 실행 중인 실행 환경 인프라에서 수집되는 표준 출력에 이벤트 스트림을 작성해야 합니다. 이러한 이벤트 스트림 라우터의 예로는 여러 원본에서 이벤트 스트림을 수집하고 출력 시스템에 게시하는 Microsoft.Diagnostic.EventFlow가 있습니다. 여기에는 개발 환경 또는 Azure Monitor 및 Azure Diagnostics와 같은 클라우드 시스템에 대한 간단한 표준 출력이 포함될 수 있습니다. 또한 Splunk 또는 미들웨어와 같이 실시간으로 로그를 검색, 경고, 보고 및 모니터링할 수 있는 유용한 타사 로그 분석 플랫폼 및 도구도 있습니다.

상태 및 진단 정보를 관리하는 오케스트레이터

마이크로 서비스 기반 애플리케이션을 만들 때 복잡성을 처리해야 합니다. 물론 단일 마이크로 서비스는 간단하게 처리할 수 있지만 수십 또는 수백 가지 유형과 수천 개의 마이크로 서비스 인스턴스는 복잡한 문제입니다. 안정적이고 응집력 있는 시스템을 갖추려면 마이크로 서비스 아키텍처를 빌드하는 것만이 아니라 고가용성, 주소 지정 가능성, 복원력, 상태 및 진단이 필요합니다.

그림 4-22. 마이크로 서비스 플랫폼은 애플리케이션의 상태 관리를 위한 기본 사항입니다.

그림 4-22에 표시된 복잡한 문제는 스스로 해결하기 어렵습니다. 개발 팀은 비즈니스 문제를 해결하고 마이크로 서비스 기반 접근 방식을 사용하여 사용자 지정 애플리케이션을 빌드하는 데 집중해야 합니다. 복잡한 인프라 문제를 해결하는 데 집중해서는 안 됩니다. 그렇다면 마이크로 서비스 기반 애플리케이션의 비용은 엄청납니다. 따라서 서비스를 빌드 및 실행하고 인프라 리소스를 효율적으로 사용하는 어려운 문제를 해결하기 위해 오케스트레이터 또는 마이크로 서비스 클러스터라고 하는 마이크로 서비스 지향 플랫폼이 있습니다. 이 방법은 마이크로 서비스 접근 방식을 사용하는 애플리케이션을 빌드하는 복잡성을 줄입니다.

다른 오케스트레이터는 비슷하게 들릴 수 있지만 각 오케스트레이터가 제공하는 진단 및 상태 검사는 다음 섹션에서 설명한 대로 OS 플랫폼에 따라 기능과 완성도가 다릅니다.

추가 리소스

• Twelve-Factor 앱입니다. XI. 로그: 로그를 이벤트 스트림으로 처리
  https://12factor.net/logs

• Microsoft Diagnostic EventFlow 라이브러리 GitHub 리포지토리.
  https://github.com/Azure/diagnostics-eventflow

• Azure Diagnostics란?
  https://learn.microsoft.com/azure/azure-diagnostics

• Azure Monitor 서비스에 Windows 컴퓨터 연결
  https://learn.microsoft.com/azure/azure-monitor/platform/agent-windows

• 의도한 내용을 기록하기: 의미 기반 로깅 애플리케이션 블록 사용
  https://learn.microsoft.com/previous-versions/msp-n-p/dn440729(v=pandp.60)

• 스플렁크 (주) 공식 사이트입니다.
  https://www.splunk.com/

• 미들웨어(Middleware ) 공식 사이트입니다.
  https://middleware.io/

• EventSource 클래스 ETW(Windows용 이벤트 추적)에 대한 API
  https://learn.microsoft.com/dotnet/api/system.diagnostics.tracing.eventsource