OpenZFS로 성능과 비용, 두 마리 토끼 잡기
온라인 결제 서비스를 운영하는 토스페이먼츠에서는 매일 방대한 양의 로그 데이터가 만들어져요. 만들어진 대부분의 로그 데이터는 Elasticsearch에 보관하면서 분석과 시각화에 사용하고요.
Elasticsearch에서 많은 양의 로그 데이터를 다루기 위해 여러 개의 노드를 하나로 묶는 클러스터 방식을 사용하고 있어요. 이렇게 하면 많은 데이터를 더 빠르게 처리할 수 있고, 노드 하나에 문제가 생겨도 전체 시스템이 멈추지 않는다는 장점이 있어요.
효율적인 데이터 관리를 위한 존 분류
먼저 Elasticsearch에서 클러스터 데이터를 더 효율적으로 처리하는 ‘존(zone)’에 대해 설명할게요. 데이터 종류에 따라 'Hot', 'Warm', 'Cold'라는 세 가지 존이 있어요. Hot 존에는 자주 사용되고, 최근에 수집된 데이터가 저장돼요. 최근 데이터는 자주, 많은 사람들이 사용하기 때문에 가장 빠른 스토리지를 사용해요. Warm 존에는 Hot 존 데이터만큼 자주 사용하지는 않지만 여전히 중요한 데이터가 저장돼요. 마지막 Cold 존에는 거의 사용하지 않는 오래된 데이터가 저장돼요. 그래서 상대적으로 비용이 저렴한 스토리지를 사용하죠.
이렇게 존을 나눠두면 데이터를 보다 효율적으로 관리할 수 있고, 존 사이의 데이터 이동을 자동으로 관리할 수 있어요. 예를 들어, 데이터가 처음 생성될 때는 Hot 존에 저장되었다가 시간이 지나면서 Warm 존, 그리고 Cold 존으로 자동으로 옮겨져요. 이렇게 하면 데이터를 저장하는 비용을 줄이면서 필요할 때 빠르게 접근할 수 있어요.
문제: Warm 존에서 발생한 성능 저하
토스페이먼츠도 Elasticsearch 클러스터를 직접 구성해서 사용하고 있는데요. 빠른 속도가 필요한 Hot 존에는 고성능의 gp3 볼륨을 스토리지로 사용하고, Warm 존에는 gp3 볼륨보다 50% 정도 저렴한 st1 볼륨을 스토리지로 사용하고 있었습니다. 그런데 어느 날 로그 데이터를 분석하는 과정에서 성능 문제가 감지됐어요. Warm 존 데이터의 평균 조회 시간이 Hot 존 데이터 보다 두세 배나 더 많은 시간이 걸리고 있었어요.
문제의 원인을 파악하기 위해 fio를 사용해서 gp3(8TB, ext4)와 st1(8TB, ext4) 볼륨의 랜덤 I/O 성능을 데이터 블럭 사이즈 별로 비교하는 실험을 해봤어요. 실험 결과는 다음 그래프에 잘 나와있는데요. 가로 축은 블록 사이즈를 나타내고, 세로 축은 메가바이트/초(MB/sec) 단위로 성능을 나타냅니다. 처리하는 데이터의 크기가 커질 수록 st1 볼륨의 처리 속도가 느려지고 있었죠.
즉 Warm 존의 느린 조회 시간의 주된 원인은 st1 볼륨을 사용하고 있기 때문이었어요. 하지만 비용이 50%나 저렴한 st1 볼륨을 포기할 수도 없었죠. 그래서 비용을 유지하면서도 스토리지 성능을 향상할 수 있는 방법을 찾아봤어요.
성능 최적화 과정
1. AWS EBS 볼륨 유형과 OpenZFS 이해하기
성능 향상 과정을 설명하기 전에 데이터 저장에 사용되는 두 가지 기술인 AWS EBS(Elastic Block Store) 볼륨 유형과 OpenZFS에 대해서 간단하게 설명할게요. 한 마디로 AWS EBS는 클라우드 기반의 가상 스토리지 서비스이고, OpenZFS는 이런 스토리지 위에서 데이터를 관리하는 고급 파일 시스템이에요.
AWS EBS 볼륨
AWS에서 제공하는 스토리지 볼륨 서비스인 EBS는 크게 네 가지 유형의 스토리지 볼륨 유형으로 나뉘는데요. 각 볼륨 유형의 주요 특징은 다음과 같아요.
gp2와 gp3는 SSD를 사용하고 일반적으로 데이터베이스나 자주 접근하는 데이터 저장에 적합해요. 성능은 gp3가 gp2보다 가성비가 좋아요. st1과 sc1은 큰 데이터를 저렴한 비용으로 저장하는 데 적합해요. st1은 더 빠른 속도를 제공하고, sc1은 더 저렴합니다. 토스페이먼츠 팀은 Hot 존 노드에 gp3를, Warm 존 노드에 st1을 사용하고 있어요.
OpenZFS
OpenZFS는 파일 시스템의 한 종류로, 데이터를 효율적으로 관리하는 데 많은 기능을 제공합니다. 선마이크로시스템즈가 오픈 소스로 공개한 128비트 파일 시스템인데요. RAID, LVM과 같은 파일 시스템의 특징을 모두 가지고 있고 데이터 중복 제거, 압축 기능, 페타바이트 용량 제공, 스냅샷 등의 다양한 추가 기능을 제공하죠.
특히 Linux에 기본 포함된 LVM과 비교해서 보면, LVM이 앞쪽 부터 채워가면서 사용하기 때문에(Linear) 특정 파일에 대한 성능에 제약을 받지만 OpenZFS는 하나의 파일을 저장해도 모든 디바이스에 분산 저장(Striped)을 합니다. 덕분에 최대 성능으로 스토리지를 사용할 수 있게 되죠.
또, OpenZFS는 효율적인 파일 시스템 압축 기능도 지원하는데요. 그중에서 LZ4 압축 알고리즘은 CPU를 적게 사용하면서 매우 높은 압축율을 제공해요. 다음 표는 LZ4 GitHub에 공개된 싱글 쓰레드 환경에서의 벤치마크 자료중 일부입니다.
이 벤치마크 결과가 맞는지, 실제로 LZ4 압축으로 인한 성능 저하가 있는지 fio 툴을 이용해서 블럭 사이즈 별로 테스트를 해봤어요. 다음 그래프에서 알 수 있듯 압축을 사용했을 때와 사용하지 않았을 때(그래프에서 off로 표현)의 읽기와 쓰기 속도에 큰 차이가 없다는 것을 확인할 수 있었어요. 이전 그래프와 마찬가지로 가로 축은 블록 사이즈, 세로 축은 성능을 나타냅니다.
fio는 zip 파일 처럼 추가적인 압축이 거의 안되는 데이터를 테스트 파일로 사용해요. 이 테스트를 통해 LZ4 압축이 스토리지의 읽기/쓰기 성능에 미치지는 영향이 크지 않다는 것을 알 수 있어요.
위 테스트로 LZ4 압축 기능을 사용하면 OpenZFS 저장하는 데이터 형태를 몰라도 성능 저하 없이 데이터 형태에 따른 최적의 압축 성능을 제공해주는 것을 확인했어요.
2. Elasticsearch 스토리지 최적화를 위한 리서치 및 실험
다음으로 스토리지 구성 변경을 위해 토스페이먼츠의 Elasticsearch의 스토리지 이용 패턴을 확인하고 성능 테스트를 진행했어요.
다음 그래프들은 토스페이먼츠 Elasticsearch 클러스터의 Hot 존 노드(위쪽)와 Warm 존 노드(아래쪽)에서 발생하는 평균 읽기/쓰기 블럭 사이즈에요. Hot 존 노드는 읽기는 대략 100k, 쓰기는 20k 정도, Warm 존 노드는 읽기가 128k, 쓰기가 256k 정도로 나타났어요. Hot 존에 비해 Warm 존이 더 큰 읽기/쓰기 작업을 처리하는 경향을 알 수 있죠.
이 데이터를 바탕으로 Elasticsearch의 평균 읽기/쓰기 블럭 크기에 최적화된 OpenZFS의 recordsize 설정을 찾을 수 있었어요.
3. OpenZFS 설정 최적화 테스트
더 큰 작업을 처리하는 Warm 존은 더 큰 recordsize를 설정할 수 있다는 것을 앞의 테스트로 알게 됐어요. 그래서 recordsize 32k, 64k, 128k 각각의 설정에 대한 테스트를 진행했어요. st1과 OpenZFS의 최상의 성능을 낼수 있는 구성을 찾는 테스트를 진행하고, 테스트 결과로 찾은 구성과 기존 st1과 EXT4 파일 시스템을 비교해봤어요. 다음은 자세한 테스트 구성이에요.
- 스토리지
다양한 스토리지 설정 중 어떤 구성이 가장 빠른지 확인해 봤어요. 예를 들어, 하나의 큰 스토리지를 사용하는 것과 여러 개의 작은 스토리지를 나눠 쓰는 것 중 어떤 것이 더 나은 지와 같은 거죠. 다음과 같이 st1이라는 유형의 스토리지와 OpenZFS라는 파일 시스템을 다양한 방식으로 조합해 봤어요.
EBS 볼륨 유형용량개수파일시스템비고구성1st18TB1OpenZFS구성2st14TB2OpenZFS구성3st12TB4OpenZFS구성4st11TB8OpenZFS구성5st18TB1EXT4기존 환경 비교용 - 서버
성능 테스트를 위한 서버는 AWS에서 제공하는 EC2를 사용했는데요. 24시간당 30분동안 제공되는 EC2의 스토리지 네트워크 가속 기능으로 인한 측정 오류를 줄이기 위해 실제 Warm 노드에서 사용하는 서버보다 높은 사양의 EC2를 사용했어요.
AWS EC2 사양별 스토리지 대역폭
EC2 사양CPU 코어 개수대역폭 (MB/sec, 128KB I/O)비고r7g.xlarge4156Cold/Warmr7g.2xlarge8312Warm/Hotr7g.4xlarge16625Hot - OpenZFS
OpenZFS는 가장 최신 안정 버전인 2.2.2 버전을 사용했어요. 압축 기능을 사용할 것인지가 고민이었는데요. 테스트 결과 압축으로 인한 성능 저하가 없다고 판단했어요. 압축 알고리즘은 LZ4 GitHub 페이지에 공개된 자료를 감안해서 LZ4를 사용했어요. recordsize는 ElasticSearch의 평균 읽기/쓰기에 주는 영향도를 확인하기 위해 32k, 64k, 128k로 진행했어요.
- 성능 측정 도구
성능 측정을 위한 도구로는 앞서 사용했던 fio를 다시 사용했어요. fio 옵션은 메모리 캐싱 효과 최소화와 실제와 비슷한 I/O 패턴과 비슷하게 하기 위해 다음과 같이 설정했어요.
# fio --directory=/test --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=$BS --iodepth=64 --size=10G --readwrite=randrw --rwmixread=75 --numjobs=16 --time_based --runtime=600 --group_reporting10GB 파일 16개의 테스트 파일과 16개의 동시 프로세서와 랜덤 읽기 75%와 랜덤 쓰기 25% 비율을 사용했어요. 블럭사이즈(
--bs옵션) 16k, 32k, 64k, 128k, 256k, 512k에 대해 각각 10분동안 측정한 뒤 평균 값을 사용했어요. ST1은 크레딧 방식의 버스트 기능을 제공하는데 1분정도로 짧게 측정을 하면 테스트 시점에 따른 측정결과의 차이가 컸어요. 하지만 10분정도를 하면 여러번 테스트를 해도 거의 비슷한 값을 보여주었어요.
4. 성능 테스트 결과와 스토리지 구성
성능에 영향을 줄 수 있는 st1 스토리지 개수 4가지, OpenZFS recordsize 3종류, fio 블럭 사이즈 6종류, 총 72가지 구성에 대한 성능 테스트를 진행했어요. 다음 그래프에서 결과를 볼 수 있어요.
이 테스트 결과를 바탕으로 Warm 존 노드 OpenZFS 설정에 recordsize는 기본값으로 128k를 사용하기로 했어요. 만약 Hot 존 노드에 OpenZFS 적용을 고려한다면 32k나 64k도 고려해볼수 있을거 같아요.
st1 스토리지 개수가 많을 수록 성능도 좋아지지만, 4개 이상에서는 성능 향상이 많이 둔화됐어요. 그래서 구성과 운영의 편의성을 위해서 2TB 4개로 구성하기로 결정했습니다.
OpenZFS 적용 후 2.7배 향상된 스토리지 성능
이제 기존 8TB 1개 ext4 파일시스템 사용 구성과 새로운 2TB 4개 OpenZFS 구성의 성능을 비교해 봤어요. 성능이 약 2.7배 개선된 것을 알 수 있습니다. 같은 비용을 유지하면서도 스토리지 성능을 높이는데 성공했어요!
OpenZFS를 이용해 성능을 향상시키면서 AWS는 EC2와 EBS의 사양에 따라 스토리지 성능이 다르고 버스트 기능 동작 방식도 다르다는 것을 알게됐어요. 이 차이만 잘 이해하고 있어도 몇 가지 설정으로 스토리지 성능을 향상시키거나 불필요한 스토리지 비용 낭비를 줄일 수 있어요.
이번 글에서는 다루지는 않았지만 Cold 존에 사용 중인 sc1도 OpenZFS를 적용해서 성능 향상을 할 수 있는지, 향상 된다면 어느 정도 일지에 테스트를 준비 중이에요. 새로운 인사이트를 발견하면 또 공유드릴게요!
참고 자료
Write 박명순 Review 박세원, 박수연 Edit 한주연 Graphic 이나눔, 이은호
