성능 테스트를 위한 격리 - 단순한 모델

성능 테스트와 반복

성능 테스트는 실제 부하를 받는 환경과 동일한 환경에서 이뤄질수록 의미가 높습니다. 하지만 정말 운영환경과 동일한 환경을 여러 목적을 위해 유지하는 것은 팀이나 기업의 사정에 따라 쉬운 일은 아닙니다. 그렇다고 운영 중인 시스템에 영향을 미칠 수 있는 환경에서 성능을 테스트해 보는 것은 아주 위험천만한 일입니다. 만약, 성능을 확인하기 위해 운영환경과 아주 동일한 환경을 마련하기가 어렵다면 우리는 어떤 방법을 쓸 수 있을까요?

관련 글

• 성능 테스트를 위한 격리 - 단순한 모델
• 성능 테스트를 위한 격리 - hoverfly
• 성능 테스트를 위한 격리 - 시뮬레이션

미니어처

성능 테스트는 반복 수행해보기에는 부담스럽기는 합니다. 하지만 성능 테스트를 자주 수행할 수 있고 그 부담을 줄일 수 있다면 개발팀에는 든든한 도구임에는 분명합니다. 따라서, 성능 테스트를 반복 수행할 수 있는 틀을 고민해봅니다. 영화 기법 중에 거대한 자연재해나 경관을 표현하기 위해서 미니어처 세트를 이용한 기법이 있습니다. 이 방법은 비용도 줄일 수 있지만 실제에서는 확인하기 힘든 장면이나 촬영 방식도 진행 가능케 도와주기도 합니다.

성능 테스트에도 동일한 기법을 사용할 수 있을 것입니다. 하지만 현실을 축소하는데에는 모든 요소가 선형적으로 줄어들지는 않습니다. 어떤 요소는 로그 그래프를 따라 줄어들고 어떤 요소는 지수 그래프를 따라 줄어들기도 하며, 시간과 같은 요소는 설계에 따라 전혀 줄어들지 않을 수도 있습니다.

 

하지만 기본적으로 현실을 정밀하게 축소할 수 있다면 부담이 적은 테스트를 수행해볼 수 있음은 분명합니다. 그렇다면 어떻게 현실 축소의 정밀함을 얻을 수 있을까요? 여러 산술적인 비례를 계산하거나 할 수 있습니다. 예를 들어 CPU 부하나 메모리 사용량 등은 부하 크기에 선형적으로 대응할 것이라 추측해볼 수 있습니다. 하지만, 사실 몇 분은 이미 고개를 갸우뚱하고 있을 듯싶네요. 이러한 지표들도 실상은 비즈니스마다 그 양상은 다를 수밖에 없으며 예측하기에는 너무 복합적입니다.

 

따라서, 우리는 두 가지 방법을 사용할 수 있습니다.

• 가능하다면 운영과 동일한 스펙을 사용한다.
• 축소가 필요한 스펙이라면 실험적인 데이터를 수집하자.

사실 여유가 가능하다면 스펙을 축소하지 않는 것이 가장 예측도 쉽고 편합니다. 따라서, 몇몇 요소들은 기왕이면 운영과 동일한 스펙을 기준삼을 수 있는지 검토해 보았습니다. 대표적으로 "시간"들은 운영과 동일할 수 있도록 고려하였습니다. 예를 들어 처리 시간을 알고 싶다던가 지연 시간을 확인하고 싶다면 "시간"을 산술적으로 변환해야 하는 설계는 피하려고 하였습니다.

단순한 예측모델

성능의 특이점에 영향을 주는 요소는 보통 다음과 같습니다.

• 어플리케이션 처리 능력
• 병목 지점인 데이터베이스의 동시처리 능력

따라서, 이 두 요소를 모두 변수로 두고 수식을 세우면 식은 연립방정식을 풀어야 답을 낼 수 있습니다. 하나만 남기고 상수로 바꿀 수 있다면 식은 훨씬 쉬운 형태를 띨 수 있습니다. 이 요소들을 어떻게 다루는 것이 가장 편할까요?

 

어떤 자원의 동시처리 능력은 보통 그 규모와 로그 그래프적인 상관관계를 보이기도 합니다. 따라서, 어플리케이션의 스펙과 데이터베이스의 스펙을 모두 변수로 사용하면 꽤 힘든 산술 변환이 필요합니다.

 

애플리케이션 처리 능력은 대부분의 경우 투입 자원과 선형적인 상관관계를 보입니다. 반대로 데이터베이스의 스펙 대비 성능은 선형적이지 않습니다. 게다가 데이터베이스는 프로비저닝이 까다로우며 운영에서 사용하는 데이터베이스의 확장성도 높지 않곤 합니다. 따라서, 성능 테스트 환경에서도 데이터베이스의 스펙을 고정하고 대신 원하는 성능지표가 운영과 어떤 비례를 보이고 있는지를 실험적으로 확인합니다.

이번엔 어플리케이션 처리 능력입니다. 애플리케이션 처리 능력은 (k8s 같은 리소스 매니징 환경 위에서) 다음과 같은 요소를 구분해볼 수 있습니다.

• 하나의 pod 에서 (지속적으로 혹은 순간적으로) 가능한 최대 처리량
• 투입 pod 수

우선적으로는 하나의 pod 의 스펙은 운영과 동일하게 유지하는 것이 가장 덜 부담스럽기 때문에 이 요소는 운영과 동일하게 유지하여 변수를 제거합니다. 그러면 투입 pod 수는 대부분 성능에 선형적인 관계를 보입니다. 아니라고 하더라도 이제 유일한 변수는 투입 pod 수뿐입니다.

 

정리하자면 다음과 같습니다.

• 데이터베이스는 축소한 특정 성능 지점으로 고정한다. (동일하고 단순한 산술 변환으로 운영 성능 영향 도출 가능)
• 하나의 pod 에 성능은 운영과 동일하게 고정한다.
• 투입 pod 수를 조정하여 원하는 성능에 필요한 리소스를 테스트한다.

이 방식에 쓸 최종 산술 변환식은 꽤 단순합니다.

운영 pod 수 = 성능 상수 * 투입 pod 수

성능 상수는 데이터베이스 성능 차이를 포함하여 복합적인 요소일 수 있으므로 경험적으로 테스트와 운영을 반복해서 관찰하여 더 정확한 성능 상수를 확인해가면 좋습니다.

 

이 과정은 미니어처 환경에 대한 예시입니다. 주요한 점은 가능한 운영과 동일하게 할 수 있는 요소, 그렇지 않다면 상수로 고정할 수 있도록 환경을 구축하는 것입니다. k8s 같은 환경은 이런 구성에 애플리케이션 리소스 측면의 편의를 제공합니다.

정리

Covid-19 시대를 지나오면서 우리 사회 내에서 바이러스를 검출하기 위한 검사들을 도입하였습니다. 이중에는 민감도 98%, 특이도 100%의 PCR 검사도 있고 민감도가 수행환경에 영향을 크게 받으며 50~90% 사이를 보이는 신속항원검사도 있습니다. 이렇게만 보면 신속항원검사를 해야 할 필요가 있나 싶지만 Covid-19 의 확산세가 사회 규모의 일정 이상으로 올라가자 가장 많이 활용한 방식은 신속항원검사였습니다. 왜냐하면 신속항원검사는 15분 만에 결과를 알려주는 간편함과 함께 PCR로는 할 수 없는 꽤 많은 반복수행을 통해 민감도를 누적할 수 있었기 때문입니다. 개별의 민감도가 조금 낮아도 이를 별 부담 없이 지속적으로 반복 수행하면 꽤 높은 민감도를 얻었던 것이죠.

지금 주장해본 글의 내용은 일면 부족한 면이 눈에 뜨일 수 있습니다. 특히나 최종 산술 변환식은 좀.. 뭐랄까요, 허술해 보이기까지 하죠. 사실 말하자면 좀 허술한 설계를 주장한 것이긴 합니다. 그것은 조금 허술하지만 자주 수행 가능한 성능 테스트도 우리에게 도움이 되지 않을까? 하는 주장입니다.

 

정리한 성능 테스트 설계는 최대한 변인을 통제하고 그럼에도 자원에 대한 결정이 가능한 모델로 설계하려 하였습니다. 아주 다행히도 k8s 를 배경으로 한 경우는 pod 라는 좋은 논리적/물리적 단위가 있었고요.

 

하지만 단지 테스트 설계가 단순해진다고 테스트의 수행에 부담이 전부 낮아진 것은 아닙니다. 이어지는 글 성능 테스트를 위한 격리 - hoverfly 에서 가장 큰 부담인 테스트 시나리오에 따른 데이터 수집에 관한 사례를 소개해보겠습니다.

 

긴 글 읽어주셔서 감사합니다.