ストレージ速度はetcdに適していますか？ フィオに聞く

フィオとetcdについての短い物語

etcdクラスターのパフォーマンスは、ストレージのパフォーマンスに大きく依存します。 etcdは、いくつかのメトリックをPrometheusにエクスポートして、ストレージパフォーマンスに関する必要な情報を提供します。 たとえば、メトリックwal_fsync_duration_seconds。 etcdのドキュメントには、ストレージが十分に高速であると見なされるには、このメトリックの99パーセンタイルが10ミリ秒未満である必要があります。 Linuxマシンでetcdクラスターを実行する予定で、ストレージが（SSDなどの）十分に高速かどうかを評価する場合は、I / O操作をテストするための一般的なツールであるfioを使用できます。 次のコマンドを実行します。test-dataは、ストレージマウントポイントの下のディレクトリです。

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果を見て、 fdatasync期間の99パーセンタイルが10ミリ秒未満であることを確認するだけです。 はいの場合、かなり高速のストレージがあります。 結果の例を次に示します。

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70 sync percentiles (usec): | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627], | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549], | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278], | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795], | 99.99th=[15795]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注釈

• 特定のシナリオ用に--sizeおよび--bsオプションを構成しました。 fioから有用な結果を得るには、値を入力します。 どこで入手できますか？ fioの設定方法を学んだ方法をお読みください。
• テスト中、I / O負荷全体はfioから発生します。 実際のシナリオでは、wal_fsync_duration_secondsに関連するものを除き、他の書き込み要求がリポジトリに届く可能性があります。 追加の負荷により、wal_fsync_duration_secondsの値が増加します。 したがって、99パーセンタイルがほぼ10ミリ秒に達した場合、ストレージの速度は十分ではありません。
• 3.5以上のfioバージョンを使用します（以前のバージョンではfdatasync期間のパーセンタイルが表示されません）。
• 上記では、fioの結果のスニペットのみが示されています。

フィオとetcdについての長い話

etcdのWALとは

データベースは通常、 先行書き込みログを使用します。 etcdもそれを使用します。 ここでは、先行書き込みログ（WAL）ログの詳細については説明しません。 知っておく必要があるのは、etcdクラスターの各メンバーが永続ストレージにそれを維持していることだけです。 etcdは、各キーと値のペアの操作（更新など）をWALに書き込んでから、リポジトリに適用します。 スナップショット間でストレージメンバーの1つがクラッシュして再起動すると、WALコンテンツを使用して最後のスナップショットからトランザクションをローカルで回復できます。

クライアントがキーと値のペアのストアにキーを追加したり、既存のキーの値を更新したりすると、etcdはこの操作を永続ストレージの通常のファイルであるWALに記録します。 続行する前に、etcdはWALへの書き込みが実際に行われたことを完全に確認する必要があります。 Linuxでは、実際の物理ストレージへの書き込みが遅延する可能性があるため、単一の書き込みシステムコールではこれには不十分です。 たとえば、Linuxはカーネルメモリ内のキャッシュ（ページキャッシュなど）にWALレコードを保存する場合があります。 また、データを永続ストレージに正確に書き込むには、書き込み後にfdatasyncシステムコールが必要です。etcdはそれを使用するだけです（ straceの結果からわかるように、8はWALファイル記述子です）。

 21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012> 21:23:09.894911 write(8, ".\0\0\0\0\0\0\202\10\2\20\361\223\255\266\6\32$\10\0\20\10\30\26\"\34\"\r\n\3fo"..., 2296) = 2296 <0.000130> 21:23:09.895041 fdatasync(8) = 0 <0.008314>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、永続ストレージへの書き込みはすぐに失敗します。 fdatasync呼び出しが遅い場合、etcdシステムのパフォーマンスが低下します。 etcdのドキュメントでは、fdatasync呼び出しの99パーセンタイルでWALファイルに書き込むのに10ミリ秒もかからない場合、リポジトリは十分に高速であると見なされています。 ストレージには他にも便利なメトリックがありますが、この投稿ではこのメトリックについてのみ説明します。

fioでストレージを評価する

リポジトリがetcdに適しているかどうかを評価する必要がある場合は、非常に人気のあるI / O負荷テストツールであるfioを使用します。 ディスク操作は非常に異なる場合があることに注意してください：同期と非同期、多くのクラスのシステムコールなど。その結果、fioの使用は非常に困難です。 これには多くのパラメーターがあり、それらの値の異なる組み合わせにより、まったく異なるI / Oワークロードが生成されます。 etcdの適切な数値を取得するには、fioからのテスト記録の負荷が、WALファイルを書き込むときのetcdからの実際の負荷にできるだけ近いことを確認する必要があります。

したがって、fioは少なくともファイルへの一連の順次書き込み操作の形式でロードを作成する必要があり、各レコードは書き込みシステムコールとそれに続くfdatasyncシステムコールで構成されます。 順次書き込み操作の場合、fioには--rw =書き込みオプションが必要です。 fioが記録時にpwriteではなくwriteシステムコールを使用するには、-ioengine = syncパラメーターを指定する価値があります。 最後に、各レコードの後に​​fdatasyncを呼び出すには、-fdatasync = 1パラメーターを追加する必要があります。 この例の他の2つのオプション（--sizeおよび--bs）はシナリオ固有です。 次のセクションでは、それらの設定方法を示します。

なぜFIOであり、どのように設定するかを学んだ方法

この投稿では、実際のケースについて説明します。 Probertheusを使用して監視したKubernetes v1.13クラスターがありました。 etcd v3.2.24はSSDでホストされていました。 Etcdメトリックスは、クラスターが何も実行していない場合でも、fdatasyncの待機時間が長すぎることを示しました。 メトリックは奇妙で、私たちはそれらが何を意味するのか本当に知りませんでした。 クラスターは仮想マシンで構成されていたため、物理SSDまたは仮想化レイヤーの問題を理解する必要がありました。 さらに、ハードウェアとソフトウェアの構成を頻繁に変更し、その結果を評価する方法が必要でした。 各構成でetcdを実行し、Prometheusメトリックを確認できますが、これは面倒です。 特定の構成を評価するためのかなり簡単な方法を探していました。 etcdのPrometheusメトリックを正しく理解しているかどうかを確認したかったのです。

しかし、このためには2つの問題を解決する必要がありました。 まず、WALへの書き込み時にetcdが作成するI / Oロードはどのように見えますか？ どのシステムコールが使用されていますか？ レコードのサイズは？ 次に、これらの質問に答える場合、fioで同様のワークロードをどのように再現すればよいですか？ fioは多くのオプションを備えた非常に柔軟なツールであることを忘れないでください。 lsofコマンドとstraceコマンドを使用して、1つのアプローチで両方の問題を解決しました。 lsofは、プロセスとその関連ファイルで使用されるすべてのファイル記述子を表示します。 straceを使用すると、すでに実行中のプロセスを調査したり、プロセスを開始して調査したりできます。 straceは、調査中のプロセス（およびその子プロセス）からのすべてのシステムコールを表示します。 etcdは同様のアプローチをとるだけなので、後者は非常に重要です。

まず、straceを使用して、クラスターに負荷がかかっていないときにKubernetesのetcdサーバーを学習しました。 ほぼすべてのWALレコードがほぼ同じサイズ（2200〜2400バイト）であることがわかりました。 したがって、投稿の最初のコマンドで、パラメーター--bs = 2300を指定しました（bsは各fioエントリのサイズをバイト単位で意味します）。 etcdレコードのサイズはetcdのバージョン、配信、パラメーター値などに依存し、fdatasyncの期間に影響することに注意してください。 同様のシナリオがある場合は、straceを使用してetcdプロセスを調べ、正確な数を見つけてください。

次に、etcdファイルシステムのアクションを理解するために、straceと-ffttTオプションを使用して開始しました。 そのため、子プロセスを調査し、それぞれの出力を個別のファイルに書き込み、各システムコールの開始と継続時間に関する詳細なレポートを取得しようとしました。 lsofを使用してstrace出力の分析を確認し、どのファイル記述子がどの目的に使用されたかを確認しました。 straceを使用すると、上記の結果が得られました。 同期時間の統計により、etcdからの指数wal_fsync_duration_secondsがWALファイル記述子を使用したfdatasync呼び出しに対応していることが確認されました。

fioがetcdと同様の負荷を生成するように、fioのドキュメントを調査し、スクリプトのオプションを選択しました。 etcdと同様に、straceからfioを実行して、システムコールとその継続時間もチェックしました。

--sizeパラメーターの値を慎重に選択しました。これは、fioからのI / O負荷全体を表します。 私たちの場合、これはストレージに書き込まれたバイトの総数です。 書き込み（およびfdatasync）システムコールの数に直接比例することが判明しました。 特定のbs値の場合、fdatasyncの呼び出し回数=サイズ/ bs。 パーセンタイルに興味があったので、信頼性のために十分なサンプルが必要だったはずであり、10 ^ 4で十分であると計算しました（22メビバイトが得られます）。 --sizeが小さい場合、外れ値が発生する可能性があります（たとえば、いくつかのfdatasync呼び出しが通常よりも長く機能し、99パーセンタイルに影響します）。

自分で試してみてください

fioの使用方法を示し、ストレージのパフォーマンスが十分であるかどうかなどを確認しました。 IBM Cloudの SSDストレージを備えた仮想マシンなどを使用して、実際に試してみてください。