예외 처리 및 재시도

Neptune에서 강력한 애플리케이션을 구축하려면 특히 데이터베이스에서 반환되는 오류를 처리할 때 예상치 못한 상황에 대비해야 하는 경우가 많습니다. 서버 측 예외에 대한 가장 일반적인 응답 중 하나는 실패한 작업을 다시 시도하는 것입니다. 복원력이 뛰어난 시스템에는 재시도 로직이 필수적이지만 모든 오류를 동일한 방식으로 처리해야 하는 것은 아니라는 점을 인식해야 합니다. 일반적인 재시도 동작에 의존하는 대신 신중한 접근 방식을 통해 보다 안정적이고 효율적인 애플리케이션을 구축할 수 있습니다.

재시도 로직이 중요한 이유

재시도 로직은 분산 애플리케이션의 중요한 구성 요소입니다. 네트워크 불안정성, 임시 리소스 제약 또는 동시 수정 충돌과 같은 일시적인 문제로 인해 작업이 실패할 수 있습니다. 대부분의 경우 이러한 실패는 영구적인 문제를 나타내지 않으며 기다렸다가 다시 시도하여 해결할 수 있습니다. 견고한 재시도 전략을 구현하면 분산 시스템에서 불완전한 환경의 현실을 인식하여 수동 개입의 필요성을 줄이면서 더 강력한 안정성과 연속성을 보장할 수 있습니다.

무차별 재시도의 위험

기본적으로 모든 오류를 재시도하면 의도하지 않은 여러 결과가 발생할 수 있습니다.

• 경합 증가 - 높은 동시성으로 인해 실패한 작업을 반복적으로 재시도하면 전체 경합이 악화될 수 있습니다. 이로 인해 트랜잭션이 실패하고 성능이 저하될 수 있습니다.

• 리소스 소진 - 무차별 재시도는 클라이언트와 서버 측 모두에서 추가 시스템 리소스를 사용할 수 있습니다. 이로 인해 제한이 발생하거나 서비스가 저하될 수 있습니다.

• 클라이언트의 지연 시간 증가 - 과도한 재시도는 특히 각 재시도에 대기 기간이 포함된 경우 클라이언트 애플리케이션에 상당한 지연을 일으킬 수 있습니다. 이는 사용자 경험과 다운스트림 프로세스에 부정적인 영향을 미칠 수 있습니다.

실제 재시도 전략 개발

복원력이 뛰어나고 효율적인 애플리케이션을 구축하려면 애플리케이션에서 발생할 수 있는 특정 오류 조건에 맞게 조정된 재시도 전략을 개발합니다. 다음은 접근 방식을 안내하기 위한 몇 가지 고려 사항입니다.

• 재시도 가능한 오류 식별 - 모든 예외를 재시도해야 하는 것은 아닙니다. 예를 들어 구문 오류, 인증 실패 또는 잘못된 쿼리는 재시도를 트리거해서는 안 됩니다. Neptune은 오류를 재시도해도 안전한 오류 코드와 일반 권장 사항을 제공하지만 사용 사례에 맞는 로직을 구현해야 합니다.

• 지수 백오프 구현 - 일시적인 오류의 경우 지수 백오프 전략을 사용하여 재시도 간의 대기 시간을 점진적으로 늘립니다. 이렇게 하면 경합을 완화하고 계단식 실패 위험을 줄일 수 있습니다.

• 초기 일시 중지 길이 고려 - 쿼리가 성공하는 데 필요한 리소스를 릴리스할 충분한 시간이 서버에 부여되지 않은 경우 첫 번째 재시도를 너무 빠르게 수행하면 동일한 오류로 끝날 수 있습니다. 올바른 상황에서 더 오래 일시 중지하면 요청 낭비와 서버 부담을 줄일 수 있습니다.

• 백오프에 지터 추가 - 지수 백오프가 효과적이지만 많은 클라이언트가 동시에 실패하고 함께 재시도하는 경우에도 동기화된 재시도 폭풍이 발생할 수 있습니다. 백오프 지연에 작은 무작위 변형인 지터를 추가하면 재시도를 분산시켜 모든 클라이언트가 동시에 재시도하여 로드가 다시 급증할 가능성을 줄일 수 있습니다.

• 재시도 제한 - 무한 루프 및 리소스 소진을 방지하기 위해 적절한 최대 재시도 횟수를 설정합니다.

• 모니터링 및 조정 - 애플리케이션의 오류율을 지속적으로 모니터링하고 필요에 따라 재시도 전략을 조정합니다. 특정 작업에 대한 재시도가 많은 경우 작업을 최적화할 수 있는지 직렬화할 수 있는지 고려합니다.

예제 시나리오

올바른 재시도 전략은 장애의 특성, 워크로드 및 관찰된 오류 패턴에 따라 달라집니다. 다음 표에는 몇 가지 일반적인 장애 시나리오와 재시도 전략 고려 사항이 각각에 적용되는 방식이 요약되어 있습니다. 추가 컨텍스트에 대한 설명 단락은 다음과 같습니다.

시나리오	재시도 가능 여부	백오프 및 지터	초기 일시 중지	재시도 제한	모니터링 및 조정
짧은 쿼리에서 가끔 발생하는 CME	예	짧은 백오프, 지터 추가	짧음(예: 100ms)	높음	CME 속도 상승 감시
장기 실행 쿼리에서 빈번한 CME	예	더 긴 백오프, 지터 추가	더 김(예: 2초)	보통	경합 조사 및 감소
비용이 많이 드는 쿼리의 메모리 제한	예	긴 백오프	Long(예: 5~10초)	낮음	쿼리 최적화, 영구적일 경우 알림
중간 쿼리 제한 시간	가능	중간 백오프, 지터 추가	보통(예: 1초)	낮음에서 중간	서버 로드 및 쿼리 설계 평가

시나리오 1: 짧은 쿼리에서 가끔 발생하는 CME

짧고 간단한 업데이트 중에가 자주 ConcurrentModificationException 나타나지 않는 워크로드의 경우 이러한 오류는 일반적으로 일시적이며 재시도해도 안전합니다. 첫 번째 재시도 전에 짧은 초기 일시 중지(예: 100밀리초)를 사용합니다. 이 시간을 통해 모든 짧은 잠금을 지울 수 있습니다. 이를 짧은 지수 백오프 및 지터와 결합하여 동기화된 재시도를 방지합니다. 재시도 비용이 낮기 때문에 재시도 한도를 높이는 것이 좋습니다. 여전히 CME 속도를 모니터링하여 데이터의 경합 증가 추세를 파악합니다.

시나리오 2: 장기 실행 쿼리에서 빈번한 CME

애플리케이션에 장기 실행 쿼리에서 CMEs가 자주 표시되는 경우 이는 더 심각한 경합을 시사합니다. 이 경우 더 긴 초기 일시 중지(예: 2초)로 시작하여 잠금을 유지하는 현재 쿼리를 완료하는 데 충분한 시간을 제공합니다. 더 긴 지수 백오프를 사용하고 지터를 추가합니다. 과도한 지연 및 리소스 사용을 방지하려면 재시도 횟수를 제한합니다. 경합이 지속되면 워크로드에서 패턴을 검토하고 업데이트를 직렬화하거나 동시성을 줄여 근본 원인을 해결하는 것이 좋습니다.

시나리오 3: 비용이 많이 드는 쿼리에 대한 메모리 제한

알려진 리소스 집약적인 쿼리 중에 메모리 기반 오류가 발생하는 경우 재시도는 서버가 리소스를 릴리스할 수 있도록 긴 초기 일시 중지(예: 5~10초 이상) 후에만 가능합니다. 반복 실패는 쿼리 또는 워크로드 변경 없이 해결할 가능성이 낮으므로 긴 백오프 전략을 사용하고 낮은 재시도 제한을 설정합니다. 지속적인 오류는 알림을 트리거하고 쿼리 복잡성 및 리소스 사용량을 검토하라는 메시지를 표시해야 합니다.

시나리오 4: 중간 쿼리 제한 시간

다소 비용이 많이 드는 쿼리의 제한 시간은 보다 모호한 경우입니다. 때때로 서버 로드 또는 네트워크 조건의 일시적인 급증으로 인해 제한 시간이 초과된 경우 재시도가 성공할 수 있습니다. 시스템을 복구할 기회를 주기 위해 중간 정도의 초기 일시 중지(예: 1초)로 시작합니다. 동기화된 재시도를 방지하려면 중간 백오프를 적용하고 지터를 추가합니다. 반복 제한 시간은 쿼리 또는 서버 용량에 더 깊은 문제가 있을 수 있으므로 재시도 제한을 낮음에서 중간으로 유지합니다. 패턴 모니터링: 제한 시간이 자주 발생하는 경우 쿼리에 최적화가 필요한지 또는 Neptune 클러스터가 과소 프로비저닝되었는지 평가합니다.

모니터링 및 관찰성

모니터링은 재시도 전략의 중요한 부분입니다. 효과적인 관찰성은 재시도 로직이 얼마나 잘 작동하는지 이해하는 데 도움이 되며 워크로드 또는 클러스터 구성에 주의가 필요할 때 조기 신호를 제공합니다.

MainRequestQueuePendingRequests

이 CloudWatch 지표는 Neptune의 입력 대기열에서 대기 중인 요청 수를 추적합니다. 값이 상승하면 쿼리가 백업 중임을 나타내며, 이는 과도한 경합, 과소 프로비저닝된 리소스 또는 재시도 폭풍의 징후일 수 있습니다. 이 지표를 모니터링하면 재시도 전략이 대기열 문제를 일으키거나 복잡하게 만드는 시기를 파악할 수 있으며 실패가 에스컬레이션되기 전에 접근 방식을 조정하라는 메시지를 표시할 수 있습니다.

기타 CloudWatch 지표

CPUUtilization, TotalRequestsPerSecond및 쿼리 지연 시간과 같은 다른 Neptune 지표는 추가 컨텍스트를 제공합니다. 예를 들어 CPU 및 I/O가 높고 대기열 길이가 늘어나면 클러스터에 과부하가 걸리거나 쿼리가 너무 크거나 너무 빈번하다는 의미일 수 있습니다. 이러한 지표에 CloudWatch 경보를 설정하여 비정상적인 동작을 알리고 오류 또는 재시도 급증을 기본 리소스 제약 조건과 연관시킬 수 있습니다.

Neptune 상태 및 쿼리 APIs

Gremlin용 Neptune 상태 API와 OpenCypher 및 SPARQL용 유사 APIs는 클러스터에서 수락되고 실행되는 쿼리를 실시간으로 볼 수 있어 병목 현상을 진단하거나 재시도 로직의 영향을 실시간으로 이해하는 데 유용합니다.

이러한 모니터링 도구를 결합하여 다음을 수행할 수 있습니다.

• 재시도가 대기열에 추가되고 성능이 저하되는 경우를 감지합니다.

• Neptune 클러스터를 확장하거나 쿼리를 최적화할 시기를 식별합니다.

• 재시도 전략이 더 깊은 문제를 마스킹하지 않고 일시적인 장애를 해결하는지 확인합니다.

• 새로운 경합 또는 리소스 소진에 대한 조기 경고를 받습니다.

특히 애플리케이션의 동시성과 복잡성이 증가함에 따라 정상적인 Neptune 배포를 유지하려면 사전 모니터링 및 알림이 필수적입니다.