스토리지 테스트란 무엇인가요? 유형은 무엇인가요? Concepts & 예

스토리지 테스트란 무엇인가요?

저장 테스트 이는 테스트 대상 소프트웨어 애플리케이션이 관련 데이터를 적절한 디렉터리에 저장하는지, 그리고 디스크 공간 부족으로 인한 예기치 않은 종료를 방지할 만큼 충분한 공간이 있는지 확인하는 데 사용되는 소프트웨어 테스트 유형입니다. 다른 말로는 스토리지 성능 테스트.

이 기법은 학문의 비기능적인 측면에 속합니다. 다른 형태의 기법들과 마찬가지로 말이죠. 비기능 테스트이는 특정 기능이 올바른 답을 도출하는지 여부에 대해서는 아무런 언급도 하지 않으며, 데이터 양과 I/O 압력이 증가함에 따라 시스템이 지속적으로 답을 도출할 수 있는지 여부에 대해서만 언급합니다.

스토리지 테스트가 필요한 이유

스토리지는 대부분의 애플리케이션이 접근하는 가장 느린 계층이므로, 그곳에서의 약점은 다른 모든 곳에 영향을 미칩니다. 전용 테스트 주기를 마련해야 하는 네 가지 이유가 있습니다.

• 저장 장치 속도가 느리면 응답 속도가 느려지고, 쿼리 실행 시간이 길어지며, 애플리케이션 가용성이 저하됩니다.
• 저장 속도가 느린 것은 서버 인프라 유지 관리에 부담을 줍니다.
• 이는 시스템 배포 전에 실제 저장 용량 한계를 파악하는 데 도움이 됩니다.
• 이는 하드웨어 장치가 교체되거나 업그레이드될 때 시스템이 어떻게 반응하는지 이해하는 데 도움이 됩니다.

아래 다이어그램은 스토리지 테스트를 이러한 맥락에서 보여줍니다. 애플리케이션, 파일 시스템 및 물리적 장치는 모두 동일한 경로상에 있으며, 경로상의 어느 한 곳에서 발생하는 지연은 사용자에게 영향을 미칩니다.

스토리지 테스트 유형

세 가지 접근 방식이 사용되며, 주요 차이점은 작업 부하가 실제 응용 프로그램과 얼마나 유사한가에 있습니다.

• 애플리케이션 테스트: 실제 운영 환경과 유사한 환경에서 샘플 쿼리를 사용한 애플리케이션 테스트.
• 애플리케이션 시뮬레이션: 대상 애플리케이션과 유사하게 동작하는 표준 소프트웨어를 사용하여 테스트를 수행합니다.
• 벤치마킹 : 인위적이고 반복 가능한 작업 부하를 생성하는 표준 벤치마킹 소프트웨어를 사용하여 테스트를 수행합니다.

첫 번째 방법은 가장 현실적인 결과를 제공하지만 이식성이 가장 떨어집니다. 세 번째 방법은 기기와 제조사 간에 비교할 수 있는 수치를 제공하지만 애플리케이션 자체의 동작 방식에 대해서는 거의 알려주지 않습니다.

공통 테스트 Concepts 저장 테스트 중에 참여함

이 세 가지 유형 각각은 아래에 요약된 바와 같이 서로 다른 활동 세트에 해당합니다.

스토리지 테스트의 주요 지표

저장 장치 성능 결과는 몇 가지 수치로 표시됩니다. 이 수치들은 서로 상충하기 때문에 어느 하나만으로 해석하면 잘못된 결론을 내리기 쉽습니다.

큐 깊이는 특히 주의해야 할 사항입니다. 한 번에 하나의 요청만 처리하면 단일 요청 지연 시간은 정확하게 측정되지만, IOPS와 처리량 수치는 실제보다 낮게 나타나므로 테스트에서는 느리게 보이지만 실제 운영 환경에서는 빠르게 보이거나 그 반대의 경우도 발생할 수 있습니다.

스토리지 테스트 수행 방법

저장 테스트의 신뢰도는 테스트가 수행된 조건에 따라 달라집니다. 아래 절차를 따르면 결과의 재현성을 확보할 수 있습니다.

• 1단계) 목표를 정의합니다. 실행 목적이 데이터베이스 준비 상태 검증, 처리량 한계 확인 또는 두 장치 비교인지 결정해야 합니다. 각 목표는 서로 다른 작업 부하를 수반하며, 이들을 혼합하면 실질적인 조치를 취할 수 없는 결과가 나옵니다.
• 2단계) 데이터 세트의 크기를 현실적으로 조정합니다. 캐시에 들어갈 만큼 작은 작업 세트는 스토리지 용량이 아닌 캐시 성능을 측정하는 지표입니다. 프로덕션 데이터 볼륨과 일치하거나, ​​최소한 캐시 크기를 훨씬 초과하도록 설정하십시오.
• 3단계) ​​읽기/쓰기 혼합 비율과 패턴을 선택합니다. 동일한 장치에서도 임의 액세스와 순차 액세스는 매우 다르게 동작하며, 70/30 읽기/쓰기 혼합 비율과 쓰기 전용 버스트도 마찬가지입니다. 기본값 대신 실제 운영 환경에서 모니터링한 결과를 바탕으로 혼합 비율을 설정하십시오.
• 4단계) 큐 깊이와 스레드 수를 설정합니다. 이러한 설정은 장치에 도달하는 동시 접속량을 제어하므로 모든 결과와 함께 기록해야 합니다. 이러한 설정을 포함하지 않고 제시된 수치는 재현할 수 없습니다.
• 5단계) 캐시를 정리하고 워밍업을 하세요. 실행 간 서버 및 장치 캐시를 삭제한 다음 첫 번째 간격의 데이터를 버려서 초기 접촉값이 아닌 정상 상태 값을 비교합니다.
• 6단계) 충분히 오래 달리세요. 짧은 시간 동안의 작업 실행은 SSD의 쓰기 버퍼가 소진되면 발생하는 쓰기 급증 현상을 숨기지만, 장시간의 작업 실행은 이를 드러냅니다.
• 7단계) 전체 스택을 모니터링합니다. 프로세서 사용률, 메모리 및 네트워크 사용량과 저장 용량 카운터를 함께 기록하여 다른 곳의 병목 현상이 저장 용량 부족으로 잘못 해석되지 않도록 합니다.
• 8단계) 반복하고 비교합니다. 동일한 구성을 여러 번 실행하고 로그를 보관하십시오. 빌드 간 성능 차이는 저장된 기준선과 비교했을 때만 확인할 수 있습니다.

부하 구동 측정에는 동일한 원칙이 적용되므로 이러한 측정은 일반적으로 함께 계획됩니다. 성능 시험 릴리스 후보 버전이 확정되기 전에 일정이 잡혔습니다.

저장 장치 테스트 도구

툴링은 크게 두 그룹으로 나뉘며, 대부분의 팀은 두 가지 모두 필요로 합니다.

• 합성 I/O 생성기. 다음과 같은 유틸리티 fioIometer와 Sysbench는 블록 크기, 읽기/쓰기 비율, 큐 깊이 및 지속 시간 등 정확하게 설명된 워크로드를 제공하므로 다른 장치에서 동일한 실행을 정확하게 반복할 수 있습니다.
• 애플리케이션 수준 부하 측정 도구. 운전자들 JMeter 애플리케이션 자체를 실행하여 스토리지가 실제 사용자가 생성하는 것과 동일한 액세스 패턴(쿼리 계획 및 인덱스 동작 포함)을 확인하도록 합니다. 이러한 동작은 합성 도구로는 재현할 수 없습니다.

Opera시스템 카운터는 전체적인 상황을 파악하는 데 도움이 됩니다. 어떤 도구가 부하를 발생시키든, 스토리지 수치는 프로세서, 메모리 및 네트워크 카운터와 함께 읽어야 합니다. 이를 위해 다음과 같은 여러 스토리지 테스트 기법이 사용됩니다. 벤치마크 테스트 볼륨 테스트결과를 정확하게 해석하려면 전체 스택 관점에 의존해야 합니다.

스토리지 테스트 수행 시 발생하는 실수

잘못된 저장소 결과 대부분 trac다시 말해, 피할 수 있는 오류의 수가 적다는 것입니다.

• 잘못된 서버 성능을 모니터링하고 있으므로, 해당 수치는 테스트 대상이 아닌 시스템의 성능을 나타냅니다.
• 서버 캐시를 먼저 지우지 않고 저장 장치를 비교하면 디스크가 아닌 메모리 용량을 측정하게 됩니다.
• 테스트 중에 프로세서 사용률 모니터링을 소홀히 하면, 저장 장치 부족으로 인한 증상 뒤에 프로세서 병목 현상이 숨겨지게 됩니다.
• 단일 스레드, 캐시 지원, 반복 불가능한 파일 복사 명령을 사용하여 스토리지 성능을 테스트합니다.

자주 묻는 질문