시스템 관련 사고를 방지하는 가장 좋은 방법은 프로덕션 단계에 들어가기 전에 시스템을 테스트하여 장애 상황에 대비하는 것입니다. 즉, 시스템의 안정성, 다시 말해 이상적인 조건보다 낮은 조건에서도 시스템을 사용할 수 있다는 점을 얼마나 신뢰할 수 있는지 확인하도록 명시적으로 설계된 테스트를 실행하는 것입니다. 문제는 이러한 테스트를 실행하는 방법과 처음에 실행할 테스트를 파악하는 것입니다.
Gremlin은 서비스 단계에서 실행할 수 있는 사전에 구축된 안정성 테스트 세트를 제공합니다. 일반적인 장애 모드에 대한 복원력을 검증하고 서비스가 안정성에 대한 모범 사례를 충족하는지 확인하기 위해 이러한 테스트를 설계했습니다. 이 블로그에서는 이러한 테스트를 실행해야 하는 이유와 서비스의 안정성에 대한 방법을 설명합니다.
(1) 최신 분산 시스템이 신뢰할 수 있는 것으로 간주되려면 일반적으로 다음 기능이 필요합니다.
(2) 수요에 따라 자동으로 확장하여 트래픽이 많은 경우에도 고성능을 유지합니다.
(3) 서비스가 실패할 경우 다시 온라인으로 전환할 수 있도록 최소한 하나의 중복 시스템이 준비되어 있습니다.
(4) 다른 대안책을 사용하거나 다른 서비스와의 연결이 끊어진 상태를 견뎌냅니다.
(5) 열악하거나 불안정한 네트워크 성능(예: 대기 시간)을 해결하거나 견뎌냅니다.
다시 말해, 우리 시스템은 확장 가능하고, 중복되며, 네트워크 중단에 탄력적이어야 하며 대기 시간을 견딜 수 있어야 합니다.
이는 Gremlin이 신뢰성 테스트를 그룹화하는 데 사용하는 범주이기도 합니다. 예를 들어 확장성 범주에는 CPU 및 메모리에 대한 별도의 테스트가 포함됩니다. 결국, CPU 사용량이 높을 때만큼 RAM 사용량이 높을 때 서비스를 확장하는 것이 중요합니다. 마찬가지로, 중복 범주에는 호스트 중단 및 가용 영역 중단에 대한 별도의 테스트가 포함됩니다. 서비스는 정상 호스트와 마찬가지로 정상 영역으로 조치를 취할 수 있어야 합니다.
기존의 QA 테스트와 마찬가지로 신뢰성 테스트는 프로덕션 단계에 들어가기 전에 결함을 포착합니다. Gremlin은 다음을 포함하여 최신 분산 시스템에 일반적인 오류 모드를 테스트합니다.
(1) 서비스가 하나 이상의 호스트 장애를 견딜 수 있을 만큼 중복됩니까?
(2) 증가하는 수요에 맞게 자동으로 확장할 수 있습니까?
(3) 서비스가 느리거나 실패한 종속성에 대해 복원력이 있습니까?
우리는 이러한 가정된 상황을 정기적으로 테스트해야 하며 그렇지 않으면 고객에게 영향을 미치는 예상치 못한 일이 발생할 수 있다는 위험을 감수해야 합니다. 회귀 테스트와 마찬가지로 정기적인 안정성 테스트를 통해 코드 및 인프라에 대한 변경 조치사항으로 버그가 발생하거나 오래된 버그가 발견되지 않게 합니다. 다음은 정기적인 신뢰성 테스트를 실행하지 않을 때 예상되는 부분입니다.
확장성은 분산 시스템 및 클라우드 네이티브 애플리케이션의 고유한 이점입니다. AWS, Azure 및 GCP와 같은 클라우드 플랫폼의 주요 장점 중 하나는 자동 확장을 지원한다는 것입니다. 수요가 특정 임계값에 도달하면 플랫폼이 새로운 시스템을 자동으로 프로비저닝 및 배포하여 용량을 추가하고 전체 리소스 포화도를 낮출 수 있습니다. 자동 확장 조정이 없는 경우 시스템 사용량을 지속적으로 모니터링하고 필요할 때 새로운 시스템을 수동으로 배포해야 하거나 수요가 너무 높은 수준에 도달하면 사용 가능한 모든 리소스가 고갈될 위험이 있습니다. 두 상황 모두 충돌로 인한 시간, 비용, 노력 또는 가동 중지 시간이 소요될 수 있습니다.
복잡한 시스템의 불행한 현실은 언제 어떤 이유로든 실패할 수 있다는 것입니다. 클라우드 제공업체는 시스템이 안정적이거나 최소한 신속하게 장애 조치될 수 있도록 노력하지만 서비스와 애플리케이션이 동일한 작업을 수행할 수 있도록 하는 것은 엔지니어의 몫입니다. 일부 시나리오에서는 영역 또는 리전 중단과 같이 클라우드 공급자가 즉시 해결할 수 없는 방식으로 부정적인 영향을 미칠 수 있습니다.
최신 애플리케이션은 종종 외부 종속성에 의존합니다. 아래와 같은 경우에 해당됩니다.
(1) 부하 분산, 데이터베이스 및 메시지 대기열과 같은 클라우드 공급자 서비스
(2) 우리 팀이 유지 관리하는 서비스
(3) 우리 조직의 다른 팀에서 관리하는 서비스
외부 데이터베이스에 연결하는 웹 서비스가 있다고 가정했을 때 네트워크 문제나 시스템 충돌로 인해 서비스가 데이터베이스에서 연결 해제될 경우 우리 서비스는 어떻게 반응할까요? 데이터베이스를 사용할 수 없음을 인식하고 오류 메시지를 반환할까요? 연결을 계속 시도하다가 결국 포기할까요? 아니면 연결 끊김 및 시간 초과 또는 충돌을 인식하지 못할까요? 네트워크 중단 사고가 발생할 경우 시스템이 받게 되는 영향을 가정해보면 쉽게 시스템 안정성 테스트에 대한 중요도를 인식하게 됩니다.
마이크로서비스 기반 애플리케이션은 모놀리식 애플리케이션보다 대기 시간(네트워크 트래픽 지연)에 훨씬 더 취약합니다. 수십 개의 라우터, 스위치, 게이트웨이 및 방화벽을 통해 수백 마일을 이동할 수 있는 인터넷을 통해 트래픽을 보내는 서비스의 경우 특히 그렇습니다. 이러한 지연은 일반적으로 경미하지만(종종 몇 밀리초 단위로), 각 네트워크 패킷에 대해 합산되면 애플리케이션이 빠르게 느려지거나 느려질 수 있습니다.
이것은 Kubernetes와 같은 분산 시스템의 주요 단점 중 하나입니다. Kubernetes에서 서비스 간 통신은 거의 대부분 네트워크를 통해 발생합니다. 고속 네트워크에 Kubernetes 클러스터를 배포하더라도 네트워크 포화도나 안정성의 변화는 서비스에 상당한 영향을 미칠 수 있습니다. 이것이 특히 데이터베이스 및 파일 저장소와 같은 중요한 종속 수단과 통신할 때 다양한 대기 시간 수준을 허용하는 서비스 기능을 사전에 테스트해야 하는 이유입니다.
Gremlin을 사용하여 서비스에 대한 안정성 테스트를 쉽게 실행할 수 있습니다. 서비스를 정의하고 Golden Signals를 연결한 후 실행하려는 테스트를 찾아 다음 실행을 클릭하기만 하면 됩니다. 서비스의 종속성을 자동으로 감지하기 때문에 중단을 시뮬레이션하거나 대기 시간을 추가하여 종속성 오류를 빠르고 쉽게 테스트할 수 있습니다. 테스트가 실행되는 동안 Gremlin은 Golden Signals를 통해 서비스를 지속적으로 모니터링하여 가용성, 응답성, 상태 및 안정성을 보장합니다.
시스템 안정성 테스트를 시작하고 개선할 준비가 되었다면 데모를 받아보세요.
서울특별시 강남구 테헤란로5길 7 13층
E : sales@osckorea.com
T : 02-539-3690
.png)
