애플리케이션 및 인프라 복원력
복원력은 일시적인 오류에서 복구하는 능력입니다. 앱의 복구 전략은 사용자에게 미치는 영향을 최소화하면서 정상적인 기능을 복원합니다. 클라우드 환경에서는 오류가 발생할 수 있으며, 앱은 이에 대해 가동 중지 시간과 데이터 손실을 최소화하여 대응해야 합니다. 앱이 오류를 정상적으로 처리하는 동안 사용자는 문제가 있음을 알아 채지 못하는 것이 이상적입니다.
마이크로 서비스 환경은 불안할 수 있기 때문에 앱에서 부분 오류를 예상하고 처리하도록 설계해야 합니다. 부분 오류의 예로는 코드 예외, 네트워크 중단, 응답하지 않는 서버 프로세스, 하드웨어 오류가 있습니다. Kubernetes 클러스터 내의 다른 노드로 컨테이너를 이동하는 것과 같은 계획된 활동도 일시적인 오류를 야기할 수 있습니다.
복원력 접근 방식
복원력 있는 애플리케이션을 설계할 때는 빠른 실패와 정상적인 성능 저하 중에서 선택해야 하는 경우가 종종 있습니다. 빠른 실패는 문제가 발생할 때 애플리케이션이 복구나 문제 해결을 시도하는 대신 즉시 오류나 예외를 throw하는 것을 의미합니다. 이렇게 하면 문제를 빠르게 식별하고 해결할 수 있습니다. 정상적인 성능 저하는 일부 구성 요소가 실패하더라도 애플리케이션은 제한된 용량에서 계속 작동하려는 것을 의미합니다.
클라우드 네이티브 애플리케이션에서는 서비스가 실패를 신속하게 처리하지 않고 정상적으로 처리하는 것이 중요합니다. 마이크로 서비스는 분산되어 있고 독립적으로 배포할 수 있기 때문에 부분 오류가 발생할 수 있습니다. 빠른 실패는 한 서비스의 오류가 여러 종속 서비스를 빠르게 중단시켜 전체 시스템 복원력을 저하할 수 있습니다. 대신 마이크로 서비스는 내부 및 외부 서비스 오류를 예측하고 허용하도록 코딩되어야 합니다. 이러한 정상적인 성능 저하를 통해 일부 서비스가 중단되더라도 전체 시스템이 계속 작동되게 할 수 있습니다. 중요한 사용자 대면 기능을 지속하여 완전한 중단을 방지할 수 있습니다. 또한 정상적인 오류는 중단된 서비스가 시스템의 나머지 부분에 영향을 미치기 전에 복구하거나 자체 복구할 수 있는 시간을 벌어줍니다. 따라서 마이크로 서비스 기반 애플리케이션의 경우 정상적인 성능 저하가 오류 격리 및 신속한 복구와 같은 복원력 모범 사례에 더 잘 부합합니다. 이는 로컬 인시던트가 시스템 전체에 영향을 미치는 것을 예방합니다.
복원력이 있는 정상적인 성능 저하를 지원하는 두 가지 기본 방법은 애플리케이션과 인프라입니다. 각 접근 방식에는 장점과 단점이 있지만 두 방법 모두 상황에 따라 적합할 수 있습니다. 이 모듈에서는 코드 기반 및 인프라 기반 복원력을 구현하는 방법을 설명합니다.
코드 기반 복원력
코드 기반 복원력을 구현하기 위해 .NET에는 복원력 및 일시적인 오류 처리를 위한 Microsoft.Extensions.Http.Resilience 확장 라이브러리가 있습니다.
이 라이브러리는 이해하기 쉬운 흐름 구문을 사용되어 스레드로부터 안전한 방식으로 오류 처리 코드를 빌드할 수 있습니다. 오류 처리 동작을 정의하는 몇 가지 복원력 정책이 있습니다. 이 모듈에서는 HTTP 클라이언트 작업에 다시 시도 전략과 회로 차단기 전략을 적용합니다.
재시도 전략
다시 시도 정책은 이름 그대로의 의미가 있습니다. 오류 응답이 수신되면 짧은 대기 후 요청이 다시 시도됩니다. 다시 시도는 매번 대기 시간을 늘립니다. 시간 증가는 선형적 또는 기하급수적이 될 수 있습니다.
다시 시도가 최대 횟수에 도달하면 이 전략을 포기하고 예외를 throw합니다. 사용자의 관점에서 앱은 일반적으로 일부 작업을 완료하는 데 더 오래 걸립니다. 앱에서 사용자에게 작업을 완료할 수 없음을 알리기 전에 시간이 걸릴 수도 있습니다.
회로 차단기 전략
회로 차단기 전략은 특정 횟수의 실패 반복 이후 통신을 일시 중지하여 대상 서비스를 중단합니다. 서비스에 심각한 문제가 발생하여 일시적으로 대응할 수 없는 경우가 있을 수 있습니다. 연속 오류가 특정 횟수에 도달한 후에는 연결 시도가 일시적으로 중지되고 회로가 열립니다. 이 대기 중에는 서비스 연결을 시도하지 않아도 대상 서비스에 대한 추가 작업이 즉시 실패합니다. 대기 시간이 경과된 후에 다시 작업을 시도합니다. 서비스가 성공적으로 응답하면 회로가 닫히고 시스템이 정상으로 되돌아갑니다.
인프라 기반 복원력
인프라 기반 복원력을 구현하기 위해 ‘서비스 메시’를 사용할 수 있습니다. 서비스 메시는 코드 변경 없는 복원력 구현 외에도 트래픽 관리, 정책, 보안, 강력한 ID, 가시성을 제공합니다. 이러한 작업 기능은 앱에서 분리되어 인프라 계층으로 이동했습니다.
코드 기반 접근 방식과 비교
인프라 기반 복원력 접근 방식은 실시간으로 클러스터 조건에 동적으로 적응할 수 있는 메트릭 기반 보기를 사용할 수 있습니다. 이 접근 방식은 클러스터를 관리하는 또 다른 차원을 추가하지만 코드를 추가하지는 않습니다.
코드 기반 접근 방식을 사용하는 경우:
- 적절한 재시도 매개 변수와 시간 제한 매개 변수를 추측해야 합니다.
- 특정 HTTP 요청에 집중합니다.
앱의 코드에서 인프라 오류에 대응할 적절한 방법은 없습니다. 동시에 수십만 개의 요청이 처리된다는 것을 고려할 때 지수 백오프(시간 요청 수)로 다시 시도해도 서비스 요청이 너무 많아질 수 있습니다.
반대로 인프라 기반 접근 방식은 앱 내부를 인식하지 못합니다. 예를 들어 복잡한 데이터베이스 트랜잭션은 서비스 메시에 보이지 않습니다. 이러한 트랜잭션은 코드 기반 접근 방식을 통해서만 오류로부터 보호할 수 있습니다.
이후 단원에서는 코드의 .NET HTTP 복원력과 Linkerd 서비스 메시를 사용하여 마이크로 서비스 기반 앱의 복원력을 구현해 봅니다.