관련링크

こんにちは、WhaTap Labs DevOpsチームリーダーのソンジェジンです。

DevOpsチームは、WhaTapサービスインフラ管理からCI / CD、課題処理、顧客応対、技術文書の作成まで、幅広い作業を行います。

技術業務のうち、サービス開発を除く残りのすべてを行っていると言えます。

WhaTap Monitoringサービスは、世界中の数万台のサーバーと毎秒100万件以上のトランザクションをリアルタイムでモニタリングするのに十分な量のデータを収集します。

収集サーバーDiskに保存される量は6Tb /日レベルで、保存量は毎日増加しています。

WhaTapサービスの核となるデータ、このデータ保存方式の効率化のため、コードではなくインフラの観点から悩んだ話をしたいと思います。 😄

保存最小単位プロジェクト

WhaTapサービスのモニタリングの単位は、**「プロジェクト」**と呼ばれます。1つのプロジェクトは、1ユニットのアプリケーショングループでも、1ユニットのサーバーグループでもかまいません。そして Kubernetes は 1 つの NameSapce が最小単位になります。ほとんどはサーバー数台、アプリケーション数個程度を1つのプロジェクトで構成しています。

データ保存もプロジェクトが基準となります。

保存量合計が6Tb/日、総プロジェクト数は10,000個程度なので、プロジェクトあたり600Mb/日が平均です。新しいプロジェクトが作成されると、何十代ものリポジトリの中で最もリラックスしたVMになります。VMに割り当てられたボリュームはモニタリングデーモンによって管理され、スペースが不足すると予想される場合はクラウドプロバイダのapiを呼び出してボリュームサイズを増やします。

ある日突然に、大型顧客

日々、このサービスは繁栄し、システムは自動化の力で知り、よく転がっていく平和な時代を過ごしていました。

そんなある日、大規模な顧客会社Kubernetesモニタリングプロジェクト1つで危険信号を検出しました。

1 つの NameSapce で数百のポッドが作成されると、1 日で 1 Tb 以上のデータが蓄積し始めます。

プロジェクト数の増加は自然にスケールアウトされますが、1つのプロジェクトで膨大なデータを保存することは予期しないことです。

WhaTap Monitoringサービスは、1ヶ月間のデータ保管を保証する必要があります。宿題ができました。このままだと数日でボリュームサイズ制限に達するからです。

緊急処置 - LVM

使用量の推移を数日見てみると、ボリュームサイズが16Tbを超えることが確実になりました。そのプロジェクトだけが新しいVMに移動し、移動したVMのボリュームはLVMで構成され、2つのボリュームをまとめました。

ところで、積み重ねられたデータを顧客が一生懸命照会するときになるため、パフォーマンス問題が発生しました。LVM自体ではパフォーマンスの低下を引き起こすことはありませんが、拡張を念頭に置いてLinearで構成した結果、ディスクの2つのうちの1つだけを懸命に書き込むことが問題になりました。

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 二人の中から選んでみなさい" とGoogleが願いに答えました。どちらも聞いたことのあるやつらですが、関心を持ってみたり、実際に適用してみるつもりはありませんでした。

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に変える作業もできると思います。

btrfs.wiki.kernel.org/index.php

そして、lz4圧縮サポートが大きかったです。zfsのlz4はbrfsのlzo、zstdと比較したとき、Random I/O 速度差が "非常に" 大きかったです。

ただし、私たちのように即時のラテンシーが切実でなければ、btrfs + zstdの組み合わせも素晴らしい選択だと思います。

gzip vs lzo vs lz4 vs zstd

| アルゴリズム | 圧縮率 | 圧縮性能 | 解凍性能 | | ---------- | ------- | -------- | --------- | | gzip | 2.743x | 90 MB/s | 400 MB/s | | lzo | 2.106x | 690 MB/s | 820 MB/s | | lz4 | 2.101x | 740 MB/s | 4530 MB/s | | zstd | 2.884x | 500 MB/s | 1660 MB/s |

出典**:** https://facebook.github.io/zstd/

第二 - zfsはext4と比べてまともなパフォーマンスを示しているのか？

一般的な環境では、ファイルシステムの特性によるパフォーマンスの違いを体感することは困難ですが、リポジトリは極端なI / Oを誇ります。

我が社のリポジトリの特性です。

• 数万個のファイルを同時オープンした状態で、それぞれファイルに不規則な数Kb単位で保存が発生する。
• 保存中または保存と同時に常時照会が発生する。

カナリ環境テストの結果は次のとおりです。

• 1つの大きなボリューム(AWS GP2 5Tb - 250Mb / 16000 IOPS)で設定した場合、ext4よりはるかに遅く、ジャーナリングではなくCoW(Copy on Write)によって引き起こされたようです。
• 4Tbを500Gb * 8個で細かく束ねた場合、膨大な性能が出ました。IOPSよりLatency値が体感性能と密接であると判断します。
• 圧縮オプションを適用するとI/O性能がさらに向上します。

驚きのカナリテスト結果

結果にとても驚きました。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バージョンを使ってください。違いがとても大きいです。

https://zfsonlinux.org/

   #Ubuntuなら、
sudo add-apt-repository ppa:jonathonf/zfs
sudo apt-get install -y zfs-dkms

   

2. 用途に合わせてオプション調整する必要があります。

デフォルトは無難ですが、わずかなオプション調整が加わるとパフォーマンスが大幅に向上します。ただし、すべての場合に通用される万能薬はないし、順序 vs Randomなどの特性に合わせて適切に調整する必要があります。

たとえば、recordsize を大きくとると圧縮率、順次保存性能が向上しますが、Random性能は低くなる式のTrade Offがあります。

ガイドは親切に出ています。

https://openzfs.github.io/openzfs-docs/Performance and Tuning/Workload Tuning.html

   #ワタップ収集サーバーに適用されるオプション
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で測定したのとあまり変わりません。

https://silashansen.medium.com/looking-into-the-new-ebs-gp3-volumes-8eaaa8aff33e

AzureリージョンはプレミアムSSDを標準SSDに変更しました。

Azureの標準SSDは非常に低いパフォーマンスを持っていますが、実際にはHDDよりも少し優れています。

Wow!! 変えても十分です。

特に、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ボトルネック地獄からあなたを救います。

十分なテストはWhaTapでよくモニタリングしてください。