[금융 IT] SI 프로젝트의 가용성 테스트
본 포스팅은 레거시 환경에서의 가용성 테스트를 다루고 있습니다.
💡 가용성(Availability)이란 서버와 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도를 말한다.
가용성 테스트란 시스템이나 애플리케이션이 정상적으로 작동하면서, 지속적으로 서비스를 제공할 수 있는 능력을 검증하는 테스트이다.
가용성 테스트의 중요성
가용성 테스트는 SI 이행 프로세스에서 인프라 담당자(AA, TA, DA)가 수행하는 핵심 테스트이다. SI 사이클에서 빠져서는 안될 필수적인 항목으로서, 가용성 테스트를 하는 목적은 다음과 같이 정리해볼 수 있다.
- 시스템이 장애 상황에서도 정상적으로 작동하는 지 확인한다.
- 서비스 중단 시간(Downtime)을 최소화할 수 있는지 검증한다.
- 시스템의 복구 능력(Recovery Capability)를 평가한다.
테스트 시나리오
가용성 테스트는 진행하기에 앞서, 프로세스 기동 종료 절차를 파악하고 테스트 케이스를 정리한 뒤, 테스트 시나리오를 작성하여 점검해야 한다. SW 레벨에서 AA(Application Architect)로서 가용성 테스트를 진행한다고 가정했을 때, 테스트 시나리오는 다음과 같이 구성할 수 있다.
- 서비스 정상 유무 확인
- 부하 발생
- 프로세스 강제 종료
- 서비스 점검
- 프로세스 기동
- 서비스 점검
가용성 테스트는 일반적으로 운영(Production) 환경에서 진행된다. 다만 특수한 상황에서는 테스트(test) 혹은 다른 환경에서 진행하는 경우도 있다. 테스트를 진행하는 중에는 지속적인 모니터링이 필요하며, 시나리오의 각 단계에서 적절한 증적을 남기는 것이 중요하다.
많은 시스템이 클라우드로 전환되고 있지만, 금융권에서는 대부분 레거시한 구성인 것이 아직은 현실이다. 다음과 같이 서버가 이중화되어 있다고 가정해보자.
시스템 내의 WEB, WAS, REDIS, MQ 등 모든 애플리케이션이 가용성 테스트 대상이 된다(AA 기준). 이제 가용성 테스트 시나리오를 작성해보자.
1) 서비스 정상 유무 확인
프로세스가 잘 떠있는 지를 확인한다.ps -ef 로 프로세스를 확인하고, date 명령어로 시간을 함께 체크하여 터미널 사진을 증적으로 남긴다.
2) 부하 발생(LoadRunner)
서비스에 부하를 주고, 시스템의 동작을 모니터링한다. 주요 업무 기능이 정상적으로 동작하고 있는 지를 검증한다. 증적은 모니터링 지표(그래프)로 남긴다. 금융권에서는 일반적으로 LoadRunner라는 부하테스트 도구를 많이 사용한다.
3) 프로세스 강제 종료
1번 서버의 프로세스를 강제 종료(kill)하여, 장애 상황을 재현한다. date 명령어와 함께 수행하여 종료 시간을 증적으로 남긴다. 프로세스가 강제 종료되는 경우, 지표가 잠시 떨어지긴 하지만 곧 다시 원래 상태로 돌아가게 된다.
4) 서비스 점검
1번 프로세스가 종료된 후, 로드밸런서를 통해 여전히 부하가 들어가는 상태에서 서비스가 정상적으로 동작하는 지 체크한다. 모니터링 지표(그래프)를 증적으로 남긴다. 자동 복구 매커니즘(FailOver)이 있다면, 잘 작동하는 지 검증한다.
5) 프로세스 기동
종료했던 프로세스를 다시 기동한다. (FailBack)
많은 금융권에서는 자동화되거나
6) 서비스 점검
프로세스가 기동된 후, 서비스가 정상적으로 동작하는 지를 검증한다.
모니터링 지표(그래프)를 증적으로 남긴다.
이처럼 서버가 이중화 또는 삼중화되어 있고, 로드밸런서를 통해 트래픽의 유입되는 경우, AA 가용성 테스트에서 검증 대상은 사실 로드밸런서라고 할 수 있다. 위의 그림처럼 이중화된 구성에서 1번 프로세스가 종료되었을 때, 로드밸런서는 2번 프로세스로 트래픽을 전환하여, 서비스가 정상적으로 동작할 수 있도록 해야한다. 반대로 2번이 종료되었을 때도, 1번으로 트래픽을 잘 로드해주어야 한다. 정상 복구 후에도 트래픽 재분배가 이루어져야 한다. 프로세스를 하나씩 죽여가며 서비스의 가용성을 확인하는 것은 결국 로드밸런서의 가용성을 테스트하는 것이나 다름 없다. 즉, 로드밸런서가 장애 감지와 트래픽 전환을 정확히 수행하는 것이 매우 중요하며, 가용성의 핵심이라고 할 수 있다.
이처럼 위 그림에서는 가용성을 로드밸런서가 책임지지만, 다른 아키텍처의 경우는 다를 수 있다. 예를 들어 솔루션을 사용하여 가용성 보장과 FailOver(FailBack)을 진행하고 있을 수도 있고, DB 입장에서 WAS가 가용성의 포인트가 되는 경우가 있을 수도 있다. 가용성 테스트에서 중요한 것은 가용성의 대상이 되는 포인트이며, 포인트가 무엇인 지를 파악할 수 있어야 한다
테스트가 수행되기 전에는, 계획한 대로 모든 시나리오가 문제없이 마무리 되기를 기대한다. 그러나 모든게 자동화되지 않고, 아직까지는 사람의 손이 타는 시스템에서, 실수는 발생하기 마련이다. 그러한 실수가 테스트를 진행하면서 많이 해결되고 검증된다. 테스트의 중요성을 뼈저리게 느끼고 있는 요즘이다.
오늘은 레거시 환경에서 가용성 테스트의 가장 기본적인 구성에 대해 알아보았다. 가용성 테스트는 새로운 시스템을 구축하는 SI 프로젝트에서 필수적인 단계로서, 고객에게 시스템의 장애 상황에서도 서비스가 중단되지 않도록 보장한다.
클라우드 환경에서의 가용성 테스트는 레거시 환경과는 다르다. 다음 포스팅에서는 MSA 환경의 가용성 테스트에 대해 알아보자.