대형 포트는 애플리케이션, 스토리지, 프로세서, 네트워크 경로 및 수신자가 이를 사용할 수 있을 때만 가치가 있습니다. 작업 세트와 동시성을 계획하고, 각 제한 단계를 벤치마크하며, 운영 경계를 정의하십시오. 40, 100 및 200 Gbps 카탈로그 라벨은 포트 등급이며 보편적인 전송 또는 가용성 보장이 아닙니다.
포트를 데이터 규모로 변환하십시오
10진 단위에서 40, 100 및 200 Gbps는 초당 5, 12.5 및 25 GB의 회선 속도 산술에 해당합니다. 이는 프로토콜 및 구현 효과 이전의 참조 변환입니다. 주변 설계의 규모를 설명하며 측정된 속도나 오리진이 해당 양의 애플리케이션 콘텐츠를 전달할 것이라는 약속이 아닙니다.
배포 프로젝트의 경우 동시 요청, 오브젝트 크기 및 작업 세트를 추정하십시오. 인기 있는 작은 세트를 반복적으로 제공하는 서비스는 캐시되지 않은 아카이브를 스트리밍하는 서비스와 다릅니다. 가정을 명시적으로 만드십시오. 이러한 가정 없이 구매한 대형 포트는 프로젝트의 반복 비용을 증가시키면서 스토리지, 애플리케이션 또는 수신자 한계를 그대로 둘 수 있습니다.
| 나열된 포트 등급 | 원시 10진 변환 | 계획 시사점 |
|---|---|---|
| 40 Gbps | 오버헤드 전 5 GB/s | 콘텐츠 및 애플리케이션 경로를 측정하십시오 |
| 100 Gbps | 오버헤드 전 12.5 GB/s | 스토리지, 동시성 및 처리를 조사하십시오 |
| 200 Gbps | 오버헤드 전 25 GB/s | 모든 단계와 수신 용량을 검증하십시오 |
작업 세트와 캐시 동작을 모델링하십시오
자주 요청되는 콘텐츠와 필요 시 스토리지에서 읽어야 하는 콘텐츠를 식별하십시오. 따뜻한 캐시는 콜드 스타트가 유지할 수 없는 결과를 생성할 수 있습니다. 프로젝트에 중요할 때 두 조건을 모두 테스트하십시오. 측정이 실제로 해결해야 하는 질문에 답할 수 있을 만큼 데이터 세트를 크고 현실적으로 유지하십시오.
인기 릴리스와 오래된 아카이브가 있는 합법적인 소프트웨어 다운로드 오리진을 상상해 보십시오. 바쁜 릴리스 기간과 일반 아카이브 액세스를 비교하십시오. 해당 작업이 겹치는 경우 게시, 체크섬 생성 및 백업 트래픽을 위한 용량을 확보하십시오. 이 원래 시나리오는 계획 프레임워크를 제공하며 특정 하드웨어나 캐싱 서비스가 SwissOctet에 포함된다고 확립하지 않습니다.
스토리지를 독립적으로 측정하십시오
애플리케이션이 수행하는 스토리지 작업을 측정하는 것으로 시작하십시오. 대용량 파일의 순차 읽기와 많은 작은 임의 읽기는 서로 다른 한계를 노출할 수 있습니다. fio 문서는 이러한 패턴을 나타낼 수 있는 워크로드 매개변수를 설명합니다. 시스템에 맞는 제어된 테스트 파일과 설정을 사용하고 프로덕션 데이터에 대한 파괴적인 테스트를 피하십시오.
스토리지 레이아웃, 데이터 세트 크기 및 테스트 조건을 기록하십시오. 캐시된 데이터를 포함하는 벤치마크는 기본 장치에서의 지속적인 읽기와 동등하지 않습니다. 이후 애플리케이션의 실제 콘텐츠 경로로 반복하십시오. 용량이 많다고 자동으로 전달 속도가 증가하지 않으며, 여러 드라이브를 선택한다고 특정 어레이 레이아웃이나 측정된 처리량이 확립되지 않습니다.
프로세서 및 큐 한계를 관찰하십시오
높은 전송 속도에서는 애플리케이션 CPU 사용과 함께 처리 및 인터럽트 처리가 중요할 수 있습니다. Linux은 네트워크 작업을 큐와 프로세서에 분산하기 위한 수신 측 스케일링 및 관련 메커니즘을 문서화합니다. 그 존재와 동작은 하드웨어와 구성에 따라 다릅니다. 모든 서버에 일반적인 튜닝 레시피를 적용하지 말고 해당 문서를 사용하여 측정을 해석하십시오.
전체 시스템보다 하나의 CPU, 작업자 또는 수신 큐가 먼저 바빠지는지 관찰하십시오. 프로덕션 서비스가 암호화, 압축 및 요청 처리를 사용하는 경우 테스트에 포함하십시오. 유휴 평균 CPU 숫자는 포화된 구성 요소를 숨길 수 있습니다. 한 번에 하나의 요인을 변경하고 기준선을 유지하여 효과를 이해할 수 있도록 하십시오.
서비스 애플리케이션을 검증하십시오
서버는 네트워크 벤치마크를 통해 바이트를 이동하는 것 이상을 수행해야 합니다. 의도한 소프트웨어로 연결, 요청 구문 분석, 권한 부여, 콘텐츠 읽기 및 응답 완료를 검증하십시오. Nginx는 자체 구현에 대한 파일 전송 및 연결 제어를 문서화합니다. 다른 소프트웨어는 다른 설정을 가집니다. 운영할 실제 버전의 문서를 읽으십시오.
현실적인 동시성을 테스트하고 집계 출력뿐만 아니라 꼬리 완료 시간을 관찰하십시오. 큰 집계 숫자는 시간 초과되는 개별 요청과 공존할 수 있습니다. 서비스가 여전히 수용 가능하게 동작하는 한계를 설정한 다음, 하루 종일 모든 구성 요소를 이론적 최대치로 실행하는 것을 목표로 하지 말고 운영 여유를 남기십시오.
실제 Transit 사양을 비교하십시오
SwissOctet의 Transit 제품군은 다양한 프로세서, 메모리 및 스토리지 기반을 나열하면서 국가를 스위스로 유지합니다. 정확한 요금제를 읽으십시오: Transit 100은 SSD 스토리지를 나열하고, 다른 Transit 기본 사양은 NVMe를 나열합니다. 추가 디스크 옵션에는 자체 라벨이 있습니다. 포트 등급이 나머지 구성을 검토하는 것을 대체하게 하지 마십시오.
또한 실제 서비스와 함께 가용성, 트래픽 조건, 관리 책임 및 복구 프로세스를 확인하십시오. 무제한 트래픽은 트래픽 모델을 설명하며 임의 활동에 대한 허가나 가동 시간 약속이 아닙니다. 대용량 워크로드는 소규모 워크로드와 마찬가지로 명확한 운영 조건과 콘텐츠 배포 권한이 필요합니다.
트래픽을 열기 전에 운영을 준비하십시오
누가 콘텐츠를 게시하고, 구성을 변경하고, 오리진을 관리할 수 있는지 정의하십시오. 해당 인터페이스를 보호하고, 유용한 운영 측정을 수집하며, 과부하에 대한 임계값을 설정하십시오. 애플리케이션이 예상치 않게 동작할 경우 트래픽을 줄이거나 릴리스를 롤백할 방법을 유지하십시오. 큰 인터페이스는 일반적인 소프트웨어 또는 액세스 실수의 결과를 증폭시킬 수 있습니다.
승인된 수신자와 합의된 한계를 사용하여 단계적 연습을 실행한 다음 계획된 워크로드로 증가시키십시오. 결과, 미해결 질문 및 리소스 여유를 배포 기록에 유지하십시오. 이 증거가 뒷받침할 때만 더 큰 포트를 선택하십시오. 완전하고 측정된 설계가 카탈로그에서 사용 가능한 가장 큰 숫자보다 더 유용합니다.
실용 체크리스트.
- 포트 등급을 페이로드 전달로 취급하지 말고 변환하십시오.
- 캐시 적중, 콜드 읽기 및 동시 요청을 모델링하십시오.
- 무해한 테스트 데이터로 스토리지를 벤치마크하십시오.
- CPU, 작업자 및 네트워크 큐를 관찰하십시오.
- 서비스 애플리케이션과 수신자 용량을 테스트하십시오.
- 트래픽을 단계적으로 적용하고 롤백 절차를 유지하십시오.
중요한 세부 사항.
가장 큰 포트가 항상 가장 안전한 선택인가요?+
아니요. 측정된 수요와 전체 시스템의 한계에서 선택하십시오. 더 큰 포트는 불충분한 스토리지, 프로세서 또는 애플리케이션 용량을 해결하지 않습니다.
모든 Transit 제품군이 NVMe를 사용하나요?+
아니요. 실제 요금제를 읽으십시오. Transit 100의 기본 사양은 SSD를 나열하고, 다른 기본 요금제와 추가 드라이브 옵션에는 자체 설명이 있습니다.
캐시된 데이터와 콜드 데이터로 모두 테스트하는 이유는 무엇인가요?+
서로 다른 운영 조건을 노출합니다. 릴리스, 재시작 또는 작업 세트 변경은 따뜻한 캐시 벤치마크가 피하는 스토리지 활동을 생성할 수 있습니다.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- Linux 커널: 네트워킹 스택의 스케일링 docs.kernel.org
- fio: 워크로드 및 측정 문서 fio.readthedocs.io
- Nginx: HTTP 코어 모듈 nginx.org
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.