우리는 물리 서버 뿐만 아니라 클라우드 서버에서도 DB 시스템을 운영하고 있습니다. DB 시스템에서 전체 성능에 가장 큰 영향을 미치는 요인은 스토리지의 I/O 성능인 경우가 많습니다. 클라우드 서버는 스토리지 자원을 공유하므로 IOPS 제한을 설정하게 됩니다. 따라서 클라우드 서버에서 물리 서버와 비슷한 성능을 확보하기 위해서는 IOPS 제한의 적정 수치를 파악할 필요가 있습니다.
비교를 위해 DB 시스템의 하드웨어 스펙을 아래와 같이 정하였습니다. 10,000 rpm SAS 하드 디스크는 150 IOPS 정도의 성능을 내는 것으로 알려져 있으므로, 8개의 디스크를 사용하는 장비는 최대 150 x 8 = 1200 IOPS 정도의 성능을 기대할 수 있습니다.
표 1. 물리 서버 하드웨어 사양
테스트 장비 사양
프라이빗 클라우드와 Amazon RDS를 테스트 대상으로 선정했습니다. 테스트 장비의 하드웨어 사양은 가능한 물리 서버와 동일하게 구성하였고, Micorosoft SQL Server(이하 MS-SQL)를 세팅 하였습니다.
표 2. 부하 테스트 장비 사양
RDS는 인스턴스 클래스 ‘db.m4.4xlarge’를 사용했기 때문에 64 GB 메모리지만, MS-SQL의 최대 사용 메모리를 다른 장비와 동일하게 26,214MB로 설정하여 메모리 용량의 차이로 인한 성능 차이를 제한했습니다.
테스트 환경 구축
부하를 주는 어플리케이션 서버와 부하를 받는 DB 서버 각 1대를 이용하여 테스트 환경을 구축하였습니다. 어플리케이션 서버에는 MS-SQL의 스트레스 툴인 ‘OStress’를 사용하기 위하여, Microsoft 사에서 제공하는 RML Tool을 설치하였고, DB 서버에는 MS-SQL을 설치하고 더미의 데이터를 이용하여 부하 테스트 DB 환경을 구축하였습니다. 또한, 현재 서비스 중인 서버들에 영향을 끼치지 않고 네트워크의 영향을 최소화 하고자 어플리케이션 서버와 DB 서버 사이에 네트워크를 직접 연결하였습니다.
테스트 방법
먼저 물리 서버 기반의 DB 시스템을 대상으로 어플리케이션 서버에서 ‘Ostress’를 이용하여 연결(connection) 수를 증가 시키면서 테스트를 수행했는데, 연결 수를 1,500으로 했을 때 평균 QPS 값이 최대가 되는 것을 확인하였습니다. 다음으로 프라이빗 클라우드와 RDS 서버에서 동일한 연결 수를 기준으로 IOPS 수치를 조정하여 물리 서버와 비슷한 평균 QPS를 낼 수 있도록 하였습니다.
테스트에 사용 된 쿼리는 실제 게임 서비스와 유사한 쿼리로 제작하였습니다. 또한, 물리 서버와 프라이빗 클라우드는 6시간씩 테스트를 진행하했으나, RDS는 서비스 특성으로 인해 6시간 동안 테스트 상태를 유지할 수 없어 3시간만 진행했습니다.
테스트 결과
1. 배치 요청(Batch Request, QPS)
그림 1. 배치 요청(QPS)
프라이빗 클라우드와 RDS는 IOPS 제한을 3,000으로 세팅하였을 때, 물리 서버의 평균 QPS와 근접한 결과를 내는 것을 알 수 있었습니다. RDS는 배치 요청 건수의 편차가 큰 것에 비해, 프라이빗 클라우드는 상대적으로 그 편차가 크지 않은 것을 볼 수 있었습니다.
2. 프로세서 타임(Processor Time)
그림 2. 프로세서 타임
프로세서 타임은 쉽게 말해 CPU 사용량입니다. 평균 CPU 사용량을 봤을 때, CPU 사용량이 가장 높은 서버는 RDS였습니다. 프라이빗 클라우드는 DB에서 매 시간마다 로그 백업을 진행 할 때, 더 많은 CPU 자원을 사용했기 때문에 프로세서 타임 최대 값이 상대적으로 커졌습니다. 평균 CPU 사용량은 평균 배치 요청 건수와 비례하였습니다.
3. 평균 쓰기 시간(Avg. Disk sec/Write)
그림 3. 평균 쓰기 시간(초)
평균 쓰기 시간은 디스크에 대한 쓰기 작업에 걸리는 평균 시간(초)을 의미합니다. Microsoft에서 제시하는 적정 수치는 0.02 미만으로, 테스트 상황에서 DB 시스템은 I/O 지연이 발생하는 상태였던 것으로 볼 수 있습니다.
4. 평균 읽기 시간(Avg. Disk sec/Read)
그림 4. 평균 읽기 시간(초)
평균 읽기 시간은 디스크에서 읽기 작업에 걸리는 평균 시간(초)을 표시합니다. 마찬가지로 Microsoft에서 제시하는 적정 수치는 0.02 미만으로, I/O 지연이 발생한 상태였습니다.
5. 디스크 쓰기 속도(Disk Writes/sec)
그림 5. 디스크 쓰기 속도(bytes)
디스크 쓰기 속도는 초당 쓰기 작업을 한 바이트 수를 의미합니다. RDS는 SSD 기반 스토리지로 그 만큼 더 높은 성능을 보이는 것은 일반적인 것으로 보입니다. RDS와 다른 장비 간의 성능을 비교하면 평균 쓰기 시간의 차이에 비해 디스크 쓰기 속도는 크지 않은 것을 볼 수 있습니다. 따라서 물리 서버와 프라이빗 클라우드는 RDS와 비교할 때 디스크 성능 외에 지연의 요인이 있을 것으로 예상됩니다.
6. 디스크 읽기 속도(Disk Reads/sec)
그림 6. 디스크 읽기속도(bytes)
디스크 읽기 속도는 초당 읽기 작업을 한 바이트 수를 의미합니다. RDS의 디스크 읽기 속도는 다른 지표에 비해 상당히 낮은 결과를 보입니다.
결론
이번 테스트 결과에서 프라이빗 클라우드와 RDS에서 디스크 IOPS를 3,000으로 세팅해야 물리 서버와 비슷한 성능을 낼 수 있는 것을 확인 할 수 있었습니다. 서로 다른 장비가 비슷한 배치 요청 건수(QPS)를 처리할 수 있더라도, 디스크에서 서로 다른 성능을 가지고 있는 것을 볼 수 있었습니다. 실제로 물리 서버로 운용하고 있는 DB는 자신이 갖고 있는 디스크의 최대 성능을 보여줬지만, 프라이빗 클라우드와 RDS의 디스크 성능은 미지의 범위가 있습니다.
다만, 디스크 쓰기 속도와 디스크 읽기 속도를 합산하여 IOPS를 측정할 수 있었는데, 물리 서버의 경우에는 약 2,881 IOPS 정도로 확인되고, 클라우드 환경에서는 IOPS를 3,000으로 제한하였지만 실제로는 조금 더 높은 수치의 성능을 보였습니다.
가장 낮은 부하를 보이는 RDS 같은 경우에는 물리 서버, 프라이빗 클라우드와는 달리 SSD를 사용합니다. 실제 Amazon EBS를 통해 제공받은 gp2는 더 나은 성능을 제공할 수 있음에도 사용할 수 있는 IOPS 제한을 했기 때문에, 측정된 디스크 부하 수치가 낮게 나왔을 수 있겠다는 생각도 들었습니다.
노트: RDS의 IOPS를 3,000으로 맞추기 위해서는 Provisioned IOPS를 사용하여 IOPS를 3,000으로 맞추거나, gp2 디스크의 용량을 1TB로 맞추면 사용 가능합니다. RDS에서 스토리지는 Amazon EBS(Elastic Block Store)를 사용합니다.
총 2가지 타입의 스토리지를 제공하고 있으며, 그 두 가지 스토리지 타입은 범용 SSD(gp2)와 ‘Provisioned IOPS SSD’(io1)로 나누어집니다.
IOPS를 10,000 ~ 20,000로 세팅하여 사용해야 할 경우에는 ‘Provisioned IOPS SSD’를 사용해야 하고, 10,000 IOPS 이하는 범용 SSD인 gp2를 사용해도 무방합니다.범용 SSD(gp2)는 1GB당 3 IOPS를 보장하며, 1TB를 사용했을 때 3,000 IOPS를 보장합니다.
마찬가지로 2TB를 사용했을 때에는 6,000 IOPS를 보장합니다. 반면 ‘Provisioned IOPS SSD’의 경우에는 1GB당 10 IOPS를 보장해줍니다. 또한, 범용 SSD(gp2)는 3,000 IOPS 미만(1 TB 미만)일 경우에는 ‘Burst Bucket’를 지원하여 최대 IOPS를 3,000으로 높여줍니다.
이와 같은 기능은 예상치 못한 부하가 발생하였을 때 사용하게 되고, 계속 3000 IOPS를 유지하지 못하고 I/O크래딧이 전부 소진되면 원상태로 돌아가게 됩니다. 반면 io2는 세팅해준 IOPS를 계속 유지합니다.
