부하 테스트의 목표는 현재 클러스터가 처리할 수 있는 부하와 다양한 부하 이정표에 도달할 때 클러스터 구성을 어떻게 변경하고 조정해야 하는지 파악하는 것이어야 합니다. 그 결과 이 정보가 필요하기 전에 사용자 증가와 부하를 처리하기 위해 클러스터를 조정하는 방법에 대한 계획을 세워야 합니다. 이렇게 하면 미리 계획하여 현재 구성의 용량을 초과하여 부하가 증가하더라도 서비스 중단 없이 애플리케이션과 데이터베이스의 성능을 원하는 SLA에 맞게 유지할 수 있습니다.
이 정보는 상당한 수의 테스트를 수행하지 않고는 누구도 제공할 수 있는 정보가 아니라는 점을 이해하세요. 액세스 패턴, 데이터 구조, 애플리케이션 코드, 네트워크, 하드웨어 등 고려해야 할 변수가 많습니다. 이는 자체 호스팅 데이터센터뿐만 아니라 클라우드 호스팅 환경에도 적용됩니다. 특정 사용 사례에 대해 이러한 선제적 부하 테스트를 수행하는 것만큼 좋은 방법은 없습니다.
참고: 클라우드 환경(AWS, Azure, Google Cloud 등)에서 Couchbase 클러스터를 호스팅하는 경우, Couchbase Kubernetes 자율 운영자를 활용하여 다양한 Couchbase 클러스터 구성을 생성하는 프로세스를 간소화할 수 있습니다. 이 도구를 사용하면 Kubernetes yaml 파일에서 클러스터 구성을 변경한 다음 클러스터에 대한 변경 사항을 자동으로 배포할 수 있습니다. 이 도구는 노드에 Couchbase를 설치 및 구성하고, 클러스터에서 노드를 추가 및 제거하고, 리밸런싱을 수행하는 등 많은 양의 시스템 관리 작업을 제거합니다.
SLA 지정
성능 테스트를 실행하기 전에 SLA(서비스 수준 협약)를 명확히 해야 합니다. "가능한 한 빨리"는 SLA가 아닙니다. 테스트 성능이 합격-불합격 상황이 될 수 있도록 SLA를 지정해야 합니다. 클러스터가 필요한 수준 또는 그보다 더 나은 성능을 발휘하고 있거나 그렇지 않은 경우입니다. 응답 시간을 결정하지 않으면 어떤 부하에서 성능이 허용할 수 없는 범위에 진입하여 필요한 수준으로 다시 성능을 발휘하기 위해 확장해야 하는지를 확인할 수 없습니다.
그렇다면 SLA의 요구 사항을 어떻게 결정할 수 있을까요? 제한된 시간 내에 완료해야 하는 가장 복잡한 프로세스부터 시작하세요. 사용자가 완료될 때까지 X초 이상 기다리지 않기를 바라는 사용자 상호 작용인 경우가 많습니다. 때로는 가능한 한 실시간이어야 하는 마이크로 서비스 프로세스일 수도 있습니다. 요컨대, 시작점과 종료점이 정의되어 있고 특정 시간 내에 완료해야 하는 특정 시간 창이 있는 프로세스여야 합니다.
프로세스가 완성되면 이 프로세스 중에 수행되는 데이터베이스 상호 작용의 수와 이러한 각 상호 작용의 특성을 식별해야 합니다. 데이터베이스 상호 작용이 식별되면 데이터베이스 상호 작용을 제거하여 기본 프로세스 타이밍을 확보해야 합니다. 이때 모의 객체가 필요합니다. 모의 객체를 사용하여 데이터베이스 상호 작용을 대체하면 실제 데이터베이스 상호 작용 없이도 실제 데이터베이스 상호 작용 결과 집합을 즉시 반환할 수 있습니다. 데이터베이스 상호 작용 없이 프로세스를 로드하면 전체 프로세스에 허용된 전체 시간에서 비데이터베이스 상호 작용 프로세스가 얼마나 많은 시간을 차지하는지 확인할 수 있습니다. 남은 시간은 모든 데이터베이스 상호 작용이 수행되어야 하는 시간입니다.
참고: 데이터베이스 상호 작용에 사용할 수 있는 시간을 파악한 후에는 한 걸음 물러나서 비즈니스 로직이 데이터베이스 상호 작용에 충분한 시간을 허용하고 있는지 확인해야 합니다. 비즈니스 로직이 SLA를 충족하는 데 허용된 시간을 모두 사용하고 있다면 SLA가 비현실적일 수 있으므로 다시 검토해야 합니다. 비즈니스 논리가 데이터베이스 상호 작용에 충분한 시간을 허용하지 않는다면 SLA를 늘리거나 비즈니스 논리를 간소화하거나 수행해야 할 데이터베이스 상호 작용 횟수를 줄여야 합니다.
데이터베이스 상호 작용의 수와 수행해야 하는 시간이 정해지면 몇 가지 계산을 통해 각 데이터베이스 상호 작용이 결과를 반환해야 하는 시간을 결정하는 것은 간단한 문제입니다. 여기에서 데이터베이스 상호 작용의 조합이 무엇인지 결정해야 합니다. 모두 K/V 액세스인가요? 모두 N1QL 쿼리인가요? 둘 다 혼합되어 있나요? N1QL 쿼리의 경우 모두 단순한 쿼리인가요, 아니면 복잡한 쿼리가 섞여 있나요? 상호 작용의 조합을 살펴봄으로써 K/V 액세스에는 하나의 SLA가, 단순한 N1QL 쿼리에는 또 다른 SLA가, 복잡한 쿼리에는 세 번째 SLA가 있는 확장된 데이터베이스 SLA 조합을 만들 수 있습니다. 이는 데이터베이스 상호 작용에 대한 평균 목표 SLA라는 점을 이해하세요. 모든 상호 작용이 특정 SLA를 충족하는 것은 아니지만 평균은 평균을 충족하거나 초과해야 합니다.
목표 SLA를 정의한 후에는 어느 정도의 성능 저하를 허용할 수 있는지 결정해야 합니다. 클러스터의 부하가 증가하면 애플리케이션과 데이터베이스의 성능이 모두 저하되기 시작하는 시점이 있습니다. 이 성능 저하를 어느 정도까지 허용할 수 있는지 결정해야 합니다. 이 수치는 더 이상 성능 저하를 허용할 수 없는 마지노선을 제공합니다. 이 수치는 클러스터가 처리할 수 있는 부하의 한계점이 됩니다. 이는 추가적인 성능 저하를 방지하기 위해 더 많은 부하를 처리하도록 클러스터를 재구성해야 하는 시점을 결정하는 로드 마일포스트 역할을 합니다. 이 테스트의 목표는 클러스터 구성에 대한 로드맵을 생성하여 각 클러스터 구성이 처리할 수 있는 부하량을 파악하고 부하 증가를 처리하기 위해 클러스터를 재구성할 시기를 알리는 마일포스트 마커를 결정하는 것임을 기억하세요.
현재 구성이 중단되는 위치 찾기
이제 전체 프로세스에 대한 목표 SLA가 있고, 비데이터베이스 상호 작용 평균 성능 시간을 알고 있으며, 데이터베이스 상호 작용이 무엇인지 계산했으므로 현재 Couchbase 클러스터 구성이 이러한 SLA를 충족할 수 있는지 확인해야 합니다.
먼저, pillowfight 또는 n1qlback과 같은 일반적인 부하 생성 도구에서 클러스터가 필요한 응답 시간 SLA를 충족합니까, 아니면 더 큰 처리 창을 제공하기 위해 SLA를 높여야 하나요? 이론적으로 SLA를 달성할 수 있다고 가정하면, 다음 질문은 현재 애플리케이션과 Couchbase 클러스터 구성이 SLA를 충족할 수 있는지 여부입니다. 애플리케이션과 데이터베이스 클러스터 모두 풀스택 비즈니스 프로세스에서 원하는 SLA를 달성할 수 있다는 것을 확인했다면 이제 부하를 늘려 모든 것이 어떻게 확장되는지 확인할 차례입니다.
현재 구성으로 SLA를 달성할 수 있다는 것을 확인했다면 즉시 목표 사용자/프로세스 부하로 부하를 늘려 성능을 확인할 수 있지만 이는 좋은 생각이 아닐 수 있습니다. 갑자기 부하를 크게 늘렸다가 더 이상 SLA를 충족하지 못한다는 사실을 알게 된다면 유용한 정보를 수집하지 못한 것입니다. 해당 부하 수준에 도달하기 전에 클러스터를 확장해야 한다는 것을 알 수 있지만 언제 확장해야 하는지 알 수 없습니다. 즉, 아직 실행 가능한 정보가 없는 것입니다.
현재 구성 성능이 원하는 SLA 이상으로 저하되는 시점을 결정하기 위해 응답 시간을 관찰하면서 부하를 서서히 추가하여 이 임계값을 초과하는 시점을 기록하는 것입니다. 또한 두 번째로 성능이 저하되는 SLA를 넘을 때까지 부하를 계속 늘려야 합니다. 클러스터를 확장해야 하는 시점과 도달하기 전에 클러스터 확장을 완료해야 하는 부하를 표시하는 두 가지 로드 마일포스트도 기록해 두어야 합니다.
다양한 성장 구성으로 테스트
클러스터의 성능을 허용할 수 없을 정도로 저하시키는 부하를 파악했다면, 다음 질문은 어떤 Couchbase 서비스가 부하를 처리할 수 없는지 파악해야 합니다. 문제가 되는 것은 K/V 액세스인가요? N1QL 쿼리인가요? 인덱스 서비스에 따라잡을 수 없을 정도로 많은 미결 업데이트 대기열이 있나요? 100%에 가까운 CPU 부하를 보이는 노드가 있나요? 이것들은 Couchbase 클러스터를 확장하는 방법을 결정하기 위해 찾아야 할 몇 가지 단서입니다.
부하가 걸린다고 판단한 특정 서비스에 한두 개의 노드를 추가한 후에는 성능을 저하시키는 부하를 다시 찾을 때까지 부하 확장 프로세스를 반복합니다. 노드를 추가한 결과 변화가 있었나요? 그렇지 않다면 확장할 서비스를 잘못 식별한 것일 수 있습니다. 노드를 추가한 결과 차이가 있었고 클러스터가 더 높은 부하를 처리할 수 있다면 확장을 위한 이정표가 몇 개 더 생긴 것입니다.
다시 이전과 동일한 분석을 반복하여 이번에는 어떤 서비스를 확장할지 결정합니다. 이전과 동일할 수도 있고 다른 서비스가 될 수도 있습니다. 핵심은 클러스터에 노드를 추가하여 부하 증가를 처리할 때마다 확장해야 하는 서비스에 노드를 추가하는지 확인하는 것입니다.
참고: 확장 중인 서비스가 인덱스 서비스인 경우, 노드를 추가하고 리밸런스를 실행한다고 해서 필요한 모든 구성이 변경되는 것은 아닙니다. 리밸런싱 중에 인덱스를 한 노드에서 다른 노드로 이동하려면, 리밸런싱 전에 인덱스가 있는 노드를 삭제하도록 표시해야 합니다. 그렇지 않으면 인덱스가 이동하지 않습니다. Kubernetes를 사용하여 실행 중인 클러스터에 한두 개의 노드만 더 추가하려는 경우, 부하를 분산하기 위해 기존 노드에서 새 노드로 개별 인덱스를 수동으로 이동해야 할 수 있습니다.
부하가 걸린 상태에서의 테스트 작업
클러스터 구성의 성능을 저하시키는 부하를 아는 것만으로는 확장 시작을 계획하는 데 충분한 정보가 될 수 없습니다. 또한 클러스터 구성을 변경하는 것이 가장 좋은 시기도 알아야 합니다. Couchbase 클러스터를 확장하는 것은 단순히 노드를 추가하고 전원을 켜기만 하면 되는 문제가 아닙니다. 클러스터는 새 노드가 클러스터의 일부로 부하를 받기 시작하기 전에 리밸런싱을 실행해야 합니다. 리밸런싱이 SLA에 어떤 영향을 미치나요? 리밸런싱과 동시에 어떤 부하를 계속 실행하면서 SLA를 계속 충족할 수 있나요?
이러한 질문에 답할 수 있는 유일한 방법은 매우 가벼운 부하에서 시작하여 노드 추가 리밸런스를 실행하면서 동시에 부하를 점차적으로 증가시키는 동일한 접근 방식을 취하는 것입니다. 리밸런스를 실행하는 동안 허용 가능한 부하를 파악한 후에는 사용 패턴을 살펴보고 구성 변경 리밸런스를 실행하는 것이 바람직한 요일과 시간을 파악할 수 있습니다.
여러 성장 목표 구성 식별
운영 프로세스의 유무에 관계없이 로드 용량에 대한 다양한 메트릭을 확보한 후에는 성장을 예측하고 이에 적응하기 위한 계획을 수립할 수 있습니다. 계획에는 클러스터를 확장할 시기, 확장 방법, 확장 예약 시기를 식별하기 위한 마일포스트 트리거가 포함되어야 합니다.
결과적인 성장 계획에는 각 확장 이벤트의 트리거 역할을 할 몇 가지 메트릭과 확장 작업의 일부로 수행해야 할 작업(예: K/V 노드 1개, 쿼리 노드 2개 추가)이 명시되어 있어야 합니다. 프로덕션 환경에서 이러한 마일포스트 트리거에 도달하면 클러스터에 대한 적절한 변경 일정을 예약하여 가장 빠른 적절한 시간(부하가 적은 시간)에 변경을 구현하세요. 클러스터 부하가 계절에 따라 달라지는 경우 이러한 스케일 업 및 다운은 미리 계획할 수 있으며, 미리 계획해야 합니다.
부하 변화가 계절적인 것이 아니라 유기적인 성장으로 인한 것이라면, 마일포스트 맵에 다음 클러스터 변경 마일포스트의 80% 표시 부근에 추가 마커를 포함해야 합니다. 이 80% 마커는 클러스터의 부하가 증가하고 있으므로 곧 클러스터 확장을 계획하고 필요한 준비를 해야 한다는 것을 팀에 알리는 "준비 완료" 마일포스트로 간주해야 합니다.
