Ceph Blog(https://ceph.io/en/news/blog/)를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://ceph.io/en/news/blog/2025/benchmarking-object-part3/
이전에, 우리의 성과 블로그 게시물 시리즈의 2부에서
IBM Storage Ceph RGW가 노드 수에 따라 어떻게 확장되는지 살펴보았고, 4개, 8개, 12개 노드에서 PUT 및 GET 작업 모두에 대해 거의 선형적인 처리량 향상을 확인했습니다. 또한, 클러스터 크기에 따라 리소스 사용 추세가 어떻게 변화하는지 살펴보았고, 이를 통해 리소스를 많이 사용하는 삭제 코딩된 워크로드에서도 확장을 통해 효율성이 향상됨을 확인했습니다. 아직 확인하지 않으셨다면 2부 링크를 참조하세요 .
TLS 종료 성능: 전송 중 S3 엔드포인트 암호화¶
TLS가 Ceph Object Gateway(RGW) S3 엔드포인트 성능에 미치는 영향을 평가하기 위해 세 가지 일반적인 배포 전략, 즉 종단 간 암호화(RGW에서의 SSL), cephadm으로 배포된 인그레스 서비스(HAProxy)에서의 SSL 종료, 그리고 암호화되지 않은 베이스라인을 비교했습니다. HAproxy 서비스는 Ceph Object Gateway(RGW) 서비스와 함께 실행됩니다. 노드별로 가상 IP 주소(VIP)가 구성되어 있으며, 벤치마크 클라이언트는 구성된 모든 VIP에 걸쳐 요청을 분산합니다. 이 테스트는 EC 8+3을 사용하는 12노드 클러스터에서 중대형(4MiB) 및 소형(64KiB) 객체 워크로드를 모두 사용하여 수행되었습니다.
중형/대형 개체 워크로드(4MiB)
이 섹션에서는 중대형 객체 크기의 대표적인 사례인 4MiB 객체 크기 결과에 중점을 둡니다. 더 큰 객체의 경우에도, 바이트당 오버헤드가 낮고 전송 효율이 높아져 여기에서 관찰된 추세가 일반적으로 유지되거나 더욱 개선됩니다.
Ceph Object Gateway(RGW)의 SSL은 SSL 미적용 구성과 거의 동일한 처리량을 제공했습니다. GET 요청의 경우 그 차이는 0.4%에 불과했지만, PUT 처리량은 4.2%로 약간 더 크게 감소했습니다. 클러스터가 네트워크 바인딩되어 있었기 때문에 이러한 작은 차이는 예상된 결과입니다. 테스트 중 Ceph Object Gateway(RGW)의 평균 CPU 사용량은 GET의 경우 40%, PUT의 경우 71% 증가했지만, Ceph 호스트당 최대 CPU 사용률은 약 83%에 달했습니다. 이러한 추가 부하가 성능에 미치는 실질적인 영향은 없었습니다. 이는 RGW의 SSL이 기본적으로 안전한 옵션이며, 대용량 객체 워크로드에서 성능 저하가 미미함을 확인시켜 줍니다.
| 미터법 | SSL 없음(기준선) | RGW의 SSL | % 변경(SSL 없음 대비) |
|---|---|---|---|
| GET 처리량(MiB/s) | 96,351 | 95,965 | -0.4% |
| PUT 처리량(MiB/s) | 58,086 | 55,651 | -4.2% |
| GET 대기 시간(ms) | 42 | 42 | 0% |
| PUT 대기 시간(ms) | 64 | 70 | +9.4% |
| RGW CPU(GET) | 3.19 코어 | 4.46코어 | +40% |
| RGW CPU(PUT) | 3.62코어 | 6.19 코어 | +71% |
반면, 인그레스 서비스(HAProxy)에서 SSL을 종료하면 더 눈에 띄는 효과가 나타났습니다. 처리량은 GET의 경우 약 27%, PUT의 경우 19% 감소했고, 그에 따라 지연 시간도 증가했습니다. 이러한 감소는 SSL 오버헤드 자체가 아니라 암호화 워크로드가 HAProxy 계층으로 이동했기 때문입니다. 워크로드가 많을 경우, 객체 크기가 64KiB에서 1GiB로 증가함에 따라 각 HAProxy 데몬은 평균 3~6개의 vCPU를 사용했습니다. Ceph 호스트의 최대 CPU 사용률은 최대 90%에 달했으며, 이는 CPU 병목 현상을 방지하기 위해 적절한 HAProxy 튜닝 및 확장의 필요성을 시사했습니다.
소규모 객체 워크로드(64KiB)
소규모 객체의 경우, 처리량이 네트워크 바운드에서 CPU 바운드로 자연스럽게 전환되어 암호화 오버헤드가 더욱 두드러집니다. 그럼에도 불구하고 Ceph Object Gateway(RGW)에서 SSL을 활성화한 영향은 관리 가능한 수준이었습니다. SSL을 사용하지 않은 기준 대비 GET IOPS는 5.2%, PUT IOPS는 10.7% 감소했습니다. Ceph Object Gateway(RGW)의 CPU 사용량은 GET의 경우 4.2%, PUT의 경우 11.3% 증가하여 암호화 작업이 클러스터 전체에 걸쳐 잘 분산되었음을 나타냅니다. 소규모 객체 워크로드가 CPU 사용량에 더 민감하게 반응함에도 불구하고, 엔드투엔드 SSL은 여전히 실용적이며, 대부분의 경우 성능 저하가 한 자릿수 백분율 이내로 유지되었습니다.
| 미터법 | SSL 없음(기준선) | RGW의 SSL | % 변경(SSL 없음 대비) |
|---|---|---|---|
| IOPS 얻기 | 137,226 | 130,089 | -5.2% |
| IOPS를 넣으세요 | 75,074 | 67,013 | -10.7% |
| GET 대기 시간(ms) | 3.05 | 3.25 | +6.6% |
| PUT 대기 시간(ms) | 9.75 | 10.00 | +2.5% |
| RGW CPU(GET) | 6.11 코어 | 6.37코어 | +4.2% |
| RGW CPU(PUT) | 2.20 코어 | 2.45 코어 | +11.3% |
Ingress 종료 SSL은 다시 더 큰 성능 격차를 초래했습니다. SSL을 사용하지 않은 경우와 비교했을 때 GET IOPS는 약 18%, PUT IOPS는 8% 감소했습니다. 이로 인해 Ingress CPU 사용량이 증가하고 요청 지연 시간이 약간 증가했습니다. 수치상으로는 성능 차이가 더 크게 나타나지만, Ingress 확장이 동시성 및 처리량 목표에 맞춰 조정된다면 보안 정책에 따라 TLS 오프로드가 요구되는 프로덕션 환경에서도 이러한 설정은 여전히 유효합니다.
결론 – SSL/TLS S3 엔드포인트 보안
요약하자면, Ceph Object Gateway(RGW)의 SSL/TLS는 대부분의 객체 워크로드에서 보안과 성능 간의 탁월한 균형을 제공합니다. 대용량 객체의 경우 거의 기본 수준의 처리량을 제공하고, 소규모 객체의 경우 약간의 성능 저하를 보이는 동시에 종단 간 암호화를 유지합니다.
클러스터 서비스 전송 중 암호화: 대규모 내부 트래픽 보호
보안 표준이 지속적으로 발전함에 따라, 특히 규제된 환경에서 Ceph 데몬 간의 내부 통신 보안은 프로덕션 배포의 모범 사례로 자리 잡고 있습니다. Ceph에서는 이러한 내부 암호화가 Messenger v2 보안 모드를 통해 활성화되는데, 이는 클러스터 네트워크 암호화 또는 전송 중 내부 암호화라고도 합니다. 외부 클라이언트와 S3 Ceph Object Gateway(RGW) 엔드포인트 간의 트래픽을 보호하는 TLS와 달리, Messenger v2는 RGW-OSD, OSD-Monitor, Manager 간 통신을 포함한 모든 데몬 간 트래픽이 암호화되고 인증되도록 보장합니다.
이 섹션에서는 Ceph Object Gateway(RGW) SSL 지원 기준선에 Messenger v2 보안 모드를 활성화할 때의 성능 영향을 살펴봅니다. 보안 모드 사용 여부에 관계없이 두 구성 모두 클라이언트 측 암호화를 위해 RGW에서 SSL을 사용했습니다. 테스트는 중대형 객체 크기(1MiB~256MiB)의 8+3 이레이저 코딩을 사용하는 12노드 클러스터에서 수행되었습니다.
개요: 더 강력한 보안을 위한 최소한의 오버헤드
Messenger v2 보안이 활성화된 구성과 활성화되지 않은 구성에서 GET 및 PUT 작업의 처리량과 지연 시간을 평가했습니다. 아래 그래프와 표에서 볼 수 있듯이, 읽기 및 쓰기 작업 모두에서 성능 차이가 미미했으며, 이는 전송 중 내부 암호화가 고처리량 객체 스토리지 사용 사례와 호환됨을 보여줍니다.
다음은 참조 4MiB 객체 크기를 사용하여 구성 간에 측정된 백분율 변화를 완전히 비교한 표입니다.
| 미터법 | 암호화 없음 | 보안 메신저 v2 | % 변화 |
|---|---|---|---|
| GET 처리량 | 95,965MiB/초 | 95,671MiB/초 | -0.3% |
| PUT 처리량 | 55,651MiB/초 | 52,994 MiB/s | -4.8% |
| GET 대기 시간 | 42밀리초 | 42밀리초 | 0% |
| PUT 대기 시간 | 70밀리초 | 71밀리초 | +1.4% |
| RGW CPU(GET) | 4.46코어 | 4.38코어 | -1.8% |
| RGW CPU(PUT) | 6.19 코어 | 6.55 코어 | +5.8% |
| RGW 메모리(GET) | 313미비 | 336마이크로비 | +7.3% |
| RGW 메모리(PUT) | 308마이크로비 | 329마이비 | +6.8% |
분석
- 처리량 영향: 테스트된 모든 객체 크기(1MiB~256MiB)에서 GET 처리량은 Messenger v2 보안 모드를 활성화한 후에도 사실상 변화가 없었습니다. PUT 처리량은 소폭 감소했는데, 특히 1MiB 객체에서(-3.1%) 두드러졌고, 더 큰 크기에서는 영향이 거의 없는 수준으로 감소했습니다(예: 64MiB 및 256MiB에서 -0.4%). 이러한 추세는 예상과 일치합니다. 객체 크기가 작을수록 조정 및 암호화 오버헤드가 커지는 반면, 객체 크기가 클수록 처리량에 더 큰 영향을 받고 비용 상각이 발생하기 때문입니다.
- 지연 시간 영향: GET 및 PUT 지연 시간은 전반적으로 안정적으로 유지되었습니다. 관찰된 변동은 미미했으며(일반적으로 ±1ms), Messenger v2 보안 모드를 활성화해도 높은 동시성 및 다양한 객체 크기에서도 유의미한 대기열 또는 처리 지연이 발생하지 않음을 확인했습니다.
- 리소스 사용률: RGW 수준의 CPU 사용량은 PUT 작업의 경우 약간 증가했지만(객체 크기에 따라 약 2~6%), GET CPU 사용량은 거의 변동이 없었습니다. 메모리 사용량도 비슷하게 완만한 변화(약 5~7% 이내)를 보였으며, 리소스 고갈이나 포화 상태는 나타나지 않았습니다.
결론 – 내부 암호화를 위한 Messenger v2
Messenger v2 보안 모드를 활성화하면 내부 Ceph 데몬 통신에 암호화 보호 기능이 추가되지만 성능에는 거의 영향을 미치지 않습니다. 테스트 결과 모든 객체 크기에 걸쳐 안정적인 처리량과 지연 시간이 나타났으며, RGW 메모리 및 CPU 사용량은 주로 PUT 작업에서 소폭 증가했습니다. Messenger v2는 최소한의 절충으로 강력한 보안을 보장하도록 설계되어 높은 처리량을 요구하는 엔터프라이즈급 객체 스토리지 구축 환경과 높은 호환성을 제공합니다.
최종 권장 사항 – 보안 설계: TLS + Messenger v2
클라이언트로 전송되는 데이터와 클러스터 서비스 간 내부에서 강력한 데이터 보호가 필요한 환경에서는 S3 엔드포인트의 TLS와 내부 암호화를 위한 Messenger v2를 결합하면 성능에 미치는 영향을 최소화하면서 강력한 보안을 제공할 수 있습니다.
AI 파이프라인, 분석 플랫폼 또는 멀티 테넌트 개체 스토리지 서비스를 보호하는 경우 Ceph RGW는 처리량, 지연 시간 또는 확장성을 손상시키지 않고 풀스택 암호화를 자신 있게 배포할 수 있음을 보여줍니다.
저장 시 암호화(SSE-S3): 컨텍스트 및 4MiB 결과
왜 SSE-S3인가요?
저장 시 암호화(Encryption at Rest)는 객체 데이터가 저장되기 전에 암호화되고, 액세스가 필요할 때만 복호화되도록 보장합니다. Ceph RGW에서 SSE-S3는 봉투 암호화(Envelope Encryption)를 사용합니다. 객체별 데이터 키는 페이로드를 암호화하고, 해당 데이터 키는 KMS에 저장 및 보호됩니다. 벤치마크 과정에서 토큰 관리 및 인증 오프로드를 위해 Vault Agents를 통한 Vault Transit을 사용했습니다. 이러한 설계는 강력한 보안 보장과 중앙 집중식 키 제어를 제공합니다.
이러한 상충 관계는 예측 가능합니다. 모든 객체의 PUT/GET은 암호화 작업과 (KMS로 보호되는 키의 경우) 키 언래핑 단계를 추가합니다. 객체가 작을수록 고정된 객체당 비용이 더 크게 발생합니다. 객체 크기가 작을수록 예상되는 패턴을 관찰했습니다. 객체가 작을수록 객체당 키 작업과 암호화로 인한 상대적인 오버헤드가 커집니다.
측정 내용(12노드, EC 8+3, 512개 클라이언트 스레드, 4MiB 객체)
구성:
- 기준선: RGW + TLS + msgr_v2(SSE 없음)
- SSE @ RGW: 기준선 + SSE-S3(RGW에서 종료된 TLS)
- Ingress의 SSE: HAProxy에서 TLS 오프로드가 포함된 SSE-S3(msgr_v2)
SSE와 기준 성능의 처리량 및 지연 시간 비교:
| 미터법 | 기준선(SSE 없음) | SSE @ RGW | Δ 대 기준선 | SSE @ 인그레스 | Δ 대 기준선 |
|---|---|---|---|---|---|
| PUT 처리량(MiB/s) | 44,121 | 39,643 | -10.1% | 33,922 | -23.1% |
| PUT 대기 시간(ms) | 44 | 50 | +13.6% | 57 | +29.5% |
| GET 처리량(MiB/s) | 85,951 | 46,815 | -45.5% | 63,574 | -26.0% |
| GET 대기 시간(ms) | 23 | 25 | +8.7% | 32 | +39.1% |
읽는 방법:
- 4MiB에서 RGW의 SSE는 적당한 지연 시간 증가와 함께 PUT 처리량의 약 90%를 유지합니다. 이는 대용량 객체와 쓰기 작업이 많은 파이프라인에 좋은 소식입니다.
- GET 경로는 각 읽기 작업 시 객체의 데이터 키(KMS 왕복 + 복호화)를 언래핑해야 하므로 민감도가 더 높으며, 이는 동시성이 높을수록 페이싱 요인이 됩니다. TLS를 인그레스로 오프로드하면 RGW의 CPU 사용량이 줄어들고 GET 갭의 일부가 복구되지만, KMS/키 언래핑 비용이 여전히 가장 큰 비중을 차지합니다.
결론 – 휴면 암호화(SSE-S3)
SSE-S3는 예측 가능한 오버헤드로 강력한 암호화를 제공합니다. 대용량 객체에 효율적이며(PUT은 기준선에 가깝게 유지됨) 소규모의 채팅 작업 부하에는 KMS에 민감합니다. 이는 객체 크기 조정, KMS 확장 및 RGW/수신 용량 계획을 통해 완화할 수 있는 균형입니다.
다음은 무엇인가
우리의 미래 벤치마킹 목표
- 소형 객체 EC 성능을 위한 Fast EC 개선 사항(Ceph 9.x)을 살펴보세요.
- 현재 NIC 상한선을 넘어서기 위해 200/400GbE로 대형 객체 테스트를 다시 실행합니다.
- SSL 종료 시 Ingress 서비스에 대한 더 나은 기본 튜닝 가능 사항을 연구합니다.
결론
이 3부작 시리즈를 통해 보안을 활성화한 상태에서 예측 가능한 확장성을 보여주었습니다. 12노드 클러스터는 GET 속도 약 111GiB/s, PUT 속도 약 66GiB/s를 기록했으며, 4→8→12노드에서 거의 선형적인 성능 향상을 보였으며 지연 시간은 더 짧거나 안정적이었습니다. 또한 64KB에서 최대 391K/86K IOPS를 달성했습니다. RGW의 TLS는 거의 기준선에 가까운 성능을 유지했고, Messenger v2는 무시할 수 있는 수준의 오버헤드를 발생시켰으며, SSE-S3는 크기에 따라 조정 가능한 비용을 보여주었습니다. 이러한 결과는 IBM Storage Ceph Object가 대규모 고처리량 및 저지연 워크로드에 대한 준비성을 잘 보여준다는 것을 보여줍니다.
저자는 이 게시물을 작성하는 데 시간을 할애하여 커뮤니티를 지원해 준 IBM에 감사드리고 싶습니다.
