저장 최소단위 프로젝트

와탭 서비스의 모니터링 한 단위는 "프로젝트"라고 합니다. 하나의 프로젝트는 한 단위의 애플리케이션 그룹 일 수도 있고, 한 단위의 서버 그룹 일 수 도 있습니다. 그리고 Kubernetes 는 하나의 NameSapce 가 최소 단위가 됩니다. 대부분은 서버 몇 대, 애플리케이션 몇 개 정도를 한 프로젝트로 구성하고 있습니다.

데이터 저장도 프로젝트가 기준이 됩니다.

저장량 합이 6Tb / 일, 총 프로젝트 수는 10,000 개 정도이므로 프로젝트당 600Mb/일 이 평균 입니다. 새로운 프로젝트가 생성되면 수 십대 저장소 중 가장 여유로운 VM에 자리잡습니다. VM에 할당된 볼륨은 모니터링 데몬이 관리하고 공간 부족이 예상되면 클라우드 프로바이더의 api 를 호출해 볼륨 크기를 증가시킵니다.

어느날 갑자기 대형 고객

나날이 서비스는 번창하고 시스템은 자동화의 힘으로 알아서 잘 굴러가는 평화로운 시절을 보내고 있었습니다.
그러던 어느날 대형 고객사 Kubernetes 모니터링 프로젝트 하나에서 위험 신호를 감지했습니다.
하나의 NameSapce 에서 수 백개의 Pod 이 만들어지더니 하루만에 1Tb 이상 데이터가 쌓이기 시작합니다.

프로젝트 수 가 증가하는 것은 자연스럽게 Scale-Out 되지만 하나의 프로젝트에서 엄청난 데이터를 저장하는 것은 예상 못 한 일입니다.

와탭 모니터링 서비스는 1개월 데이터 보관을 보장해야 합니다. 숙제가 생겼습니다. 이대로 며칠만 있으면 볼륨크기 제한에 도달하기 때문입니다.

응급조치 - LVM

사용량 추이를 며칠 지켜보니 볼륨 크기가 16Tb 넘을것이 확실해졌습니다. 해당 프로젝트만 신규 VM으로 이사를 보냈고 이사 보낸 VM의 볼륨은 LVM 으로 구성해 볼륨 2개를 묶었습니다.

그런데, 쌓여진 데이터를 고객이 열심히 조회할 때가 되니 성능 이슈가 발생했습니다. LVM 자체로는 성능 저하를 유발하지 않지만, 확장을 염두해 두고 Linear 로 구성한 결과 디스크 두 개중 하나만 열심히 쓰는게 문제가 발생했습니다.

Linear vs Stripe

LVM 이후 고민

I/O 성능 저하를 겪으며 LVM 에서 Stripe 를 생각 해 보았습니다.
LVM 의 Stripe 는 raid0 방식이라 단점도 동일합니다. 각 볼륨의 크기도 일치해야 하고 추후에 볼륨 크기 조절도 안됩니다. 이 구성은 LVM의 유연함을 크게 감소시킵니다.
클라우드 환경에서 Disk Fail을 걱정하지는 않지만 설정 변경에 의해 Stripe 정보가 유실되는 경우는 꽤 잦으므로 우려스러웠습니다.
저장소 특성상 Random I/O로 상시 수 천 IOPS 를 사용하며 즉각적인 Latency 를 필요로하기에 HDFS 와 같은 분산파일 시스템, Object Storage 는 애초 고려대상이 되지 않습니다.

그날 밤 늦게까지 고민하던 저는 "LVM 에서 Linear 쓰듯 Stripe 를 구성할 수 있다면 얼마나 좋을까?"하며 소원빌고 잠이 들었습니다

파일시스템 끝판왕 - ZFS

다음날 출근길 "zfs, btrfs 둘 중에 골라보렴" 이라고 구글이 소원에 응답했습니다. 둘 다 들어 본 적 있는 친구들이지만 관심을 가져보거나 실제 적용 해 볼 생각은 하지 않고 있었습니다.

zfs 홈페이지에 나와있는 소개는 엄청났습니다.

• 파일시스템 네이티브 Raid 기능
• Copy-On-Write 트랜젝션
• 데이터 압축 기능
• 데이터 중복 제거 기능
• 지속적인 데이터 무결성 검사 및 자동 복구
• Read / Write Cache
• 최대 크기 16EB

무슨 파일시스템계의 만병통치약입니다. 이게 다 될까? 하고 세부 기능을 들여다 보니 정말 다 될 것 같습니다.

사실인지 확인해 보기로 했습니다.

사실인지 확인해 보기로 했습니다.

서비스 데이터 일부를 미러링 해 운영 저장소 2배 이상의 프로젝트를 수용하도록 혹독한 환경을 만들었습니다.

Canaria 환경은 이렇습니다, 이름은 "까나리" 입니다.

• AWS - m5.xlarge, gp2 2Tb, ubuntu linux 18.04
• 평균 CPU 사용량 70%
• 동시 오픈 파일 개수 12000 개
• 평균 5000 IOPS
• Write - 90MBps

첫번째 - btrfs 와 zfs 무엇을 선택 할 것인가?

Linux 환경에서 관리와 모니터링은 btrfs가 장점이 많았지만 간단한 파일럿 결과로 저희 서비스에는 zfs가 더 적합한 것으로 결론 내렸습니다.

발전 가능성을 보면 단연 btrfs 이지만 현재는 아쉬운 점이 좀 있습니다. 추후 btrfs는 일반 zstd 대비 5배 이상 압축률의 zstd dictionary, 가장 빠른 속도인 lz4 지원이 예정되어 있네요. 예정대로만 된다면 2~3년 뒤 zfs 를 btrfs 로 바꾸는 작업도 할 수 있겠습니다.

그리고 lz4 압축 지원이 컸습니다. zfs의 lz4는 brfs 의 lzo, zstd 와 비교했을때 Random I/O 속도 차이가 "아주" 컸습니다.
다만, 저희 처럼 즉각적인 Latency 가 절실하지 않다면 btrfs + zstd 조합도 훌륭한 선택이 될 것 같습니다.

gzip vs lzo vs lz4 vs zstd

두번째 - zfs 는 ext4 대비 괜찮은 성능을 보이는가?

일반적인 환경에서는 파일시스템 특성에 따른 성능 차이를 체감하기 어렵지만 저희 저장소는 극한의 I/O를 자랑합니다.

저희 저장소 특성입니다.

• 수 만 개의 파일을 동시 오픈한 상태에서 각각 파일에 불규칙한 수 Kb 단위로 저장이 발생한다.
• 저장 중 또는 저장과 동시에 상시 조회가 발생한다.

까나리 환경 테스트 결과는 다음과 같습니다.

• 큰 볼륨 하나(AWS GP2 5Tb - 250Mb / 16000 IOPS)로 구성한 경우 ext4 보다 훨씬 느립니다.
  이는 저널링 방식이 아닌 CoW(Copy on Write)에서 유발 된 것으로 보입니다.
• 4Tb 를 500Gb * 8 개로 잘게 묶은 경우 엄청난 성능이 나왔습니다.
  IOPS 보다 Latency 값이 체감 성능과 밀접한 것으로 판단합니다.
• 압축 옵션을 적용했을때 I/O 성능이 더 향상됩니다.
  압축 알고리즘으로 lz4를 선택 했을때 가장 성능향상이 두드러졌습니다.

놀라운 까나리 테스트 결과

결과에 많이 놀랐습니다. zfs를 쓰지 않을 이유가 "전혀","Never" 없습니다. 특히 볼륨압축을 적용했을때 I/O 성능이 더 향상되는 사실은 아주 고무적이었습니다.

ext4 를 zfs 로 변경한다면 다음과 같은 장점이 기대되었습니다.

편해진 볼륨 관리

• 전체 볼륨 크기가 1/3 수준으로 작아지므로 상대적으로 관리가 쉬워진다.
• 논리 볼륨관리자를 파일시스템 레벨에서 사용 할 수 있다.
• 온라인 마운트 상태에서 파일시스템을 축소 할 수 있다.

성능

• stripe를 적용해 Disk 수 만큼 선형적으로 성능을 향상 할 수 있다.
• lz4 압축 적용시 ext4 대비

비용 감소

• 압축 적용으로 용량이 1/3로 감소 했습니다. 따라서 볼륨 비용도 1/3 이 됩니다.

일부 단점도 있지만 장점이 모든 것을 뛰어 넘습니다.
약간의 메모리와 CPU 사용량이 증가하는데 이를 Trade Off 해도 성능과 비용감소 이점이 워낙 크기에 10번 양보해도 남는 장사 입니다.

단점

• 압축 적용시 CPU 사용량이 다소 높아진다. +10% 수준 증가
• 메모리 사용량이 다소 증가 한다.
• 기능이 많고 옵션이 세세한 만큼 학습이 필요하다.

Production 적용

"까나리" 환경에서 훌륭한 결과를 보여줬기에 바로 Production 환경 적용을 시작했습니다. 총 150Tb 이상의 파일시스템 마이그레이션은 3개월에 걸쳐 순차적으로 진행되었고 무난한 과정이지만 몇몇 시행착오가 있어 정리해 놓습니다.

시행 착오 Note

1. 어떤 ZFS 버전을 선택 할 것인가?

ZFS 버전이 다양하고 모듈 제공 방식도 여러가지가 있습니다. 배포판에 기본 제공되는 ZFS 보다 OpenZFS 2.0x 버전 + dkms 로 배포되는 모듈이 성능/안정성 면에서 탁월했습니다. 고민하지 말고 이 버전 쓰세요.

꼭! 2.0.x 버전 쓰세요. 차이가 매우 큽니다.

#우분투라면
sudo add-apt-repository ppa:jonathonf/zfs
sudo apt-get install -y zfs-dkms

2. 용도에 맞추어 옵션 조정필요 합니다.

기본값은 무난하지만 약간의 옵션 조정이 더해진다면 성능이 크게 증가 합니다. 단, 모든 경우에 통용되는 만병통치약은 없으며 순차 vs Random 등 특성에 맞추어 적절한 조정은 필요합니다.

예를 들어, recordsize 를 크게 잡으면 압축률, 순차저장 성능이 향상되지만 Random 성능은 낮아지는 식의 Trade Off가 있습니다.

가이드는 친절하게 나와 있어요.

#와탭 수집서버에 적용된 옵션
sudo zpool set ashift=12 yardbase

sudo zfs set compression=lz4 yardbase
sudo zfs set atime=off yardbase
sudo zfs set sync=disabled yardbase
sudo zfs set dnodesize=auto yardbase
sudo zfs set redundant_metadata=most yardbase
sudo zfs set xattr=sa yardbase
sudo zfs set recordsize=128k yardbase

좀 더 과감한 시도

Production 환경에서 별 탈 없이 적용되어 잘 사용될때 쯤 Disk Spec 을 낮추는 시도를 했습니다.

AWS 리전은 gp2 를 gp3 로 변경 했습니다. gp2 대비 gp3는 latency 가 다소 낮고 대역폭이 절반이지만 비용이 20% 가까이 저렴합니다. 성능 차이는 아래 blog 를 따왔는데 저희가 기존에 ext4에서 측정한 바도 크게 다르지 않습니다.

Azure 리전은 프리미엄 SSD 를 표준 SSD 로 변경 했습니다.

Azure 의 표준 SSD 는 매우 낮은 성능을 가지는데 사실상 HDD 보다 좀 더 나은 정도입니다.

와!! 바꿔도 충분합니다.

특히 Azure의 표준 SSD에서 잘 동작할 것이라고는 예상하지 못했습니다.

ZFS의 raidz stripe 가 Disk 수 만큼 성능이 선형적으로 증가하니 낮은 Spec Disk도 전혀 무리 없었습니다.

결과

유연한 볼륨관리와 성능 개선 목적으로 ZFS 를 적용했는데 가장 큰 성과는 "비용" 이었습니다.

ZFS를 전체 적용하고 총 볼륨 크기를 100Tb 이상 줄였습니다. 100Tb 의 볼륨 비용을 절감하게 되었습니다. 더불어 나머지 Disk 는 Downgrade 로 20% 이상 비용을 절감했습니다.

ZFS 도입으로 얻은것

ZFS 도입으로 원하는 결과 모두 다 얻었습니다.

• lz4 압축 적용으로 비용 1/3 감소
• Disk Spec Down 으로 다시 비용 20% 감소
• 관리 편의성 향상
• IO 성능 향상

데이터 보관주기 1년!

절감한 디스크비용은 다시 고객을 위해 투자하기로 결정했습니다.

I/O 특성상 저희 서비스에서 Disk 가 차지하는 관리비용이 가장 컸는데요 이 부분이 해결되면서 큰 결정을 하게 되었습니다.

관리가 수월해지고, IO성능이 개선되고, 저장 용량이 줄어들게 되어 "통계 데이터 보관 주기를 1개월에서 1년으로 변경" 하게 되었습니다.

마무리

Disk 관리와 Disk I/O 성능 문제로 고민한다면 ZFS 를 검토 해 보세요. 장점이 아주 많습니다.
충분한 테스트와 옵션조정이 동반 된다면 ZFS는 반드시 I/O 병목 지옥에서 여러분을 탈출시켜 줄 것입니다.

충분한 테스트는 와탭으로 잘 모니터링 해 주세요.