K8をゼロから始める| etcdパフォーマンス最適化プラクティス
https：// www.kubernetes.org.cn/6295.html
著者| Chen Xingyu（Yumu）Alibaba Cloud Basic Technology Central Taiwan Technical Expert
この記事は、「CNCF x Alibaba Cloud Native Technology Open Course」の第 17 講義から編集されました。
はじめに：etcdは、主要なメタ情報を格納するためにコンテナークラウドプラットフォームで使用されるコンポーネントです。Alibabaは3年間etcdを使用しており、今年もダブル11プロセスで主要な役割を果たし、ダブル11のプレッシャーによってテストされています。etcdのパフォーマンスの背景から始めて、この記事の作成者は、etcdサーバーのパフォーマンスの最適化とetcdクライアントの使用のベストプラクティスを理解し、すべての人が安定して効率的なetcdクラスターを実行できるように支援することを望んでいました。
1. etcdの簡単な紹介
etcdはCoreOsで生まれ、Golangで開発され、分散型KeyValueストレージエンジンです。etcdを分散システムメタデータのストレージデータベースとして使用し、システムに重要なメタデータを格納できます。etcdは、大手企業でも広く使用されています。
次の図は、etcdの基本的なアーキテクチャを示しています
上記のように、クラスターには3つのノード（リーダーと2つのフォロワー）があります。各ノードは、Raftアルゴリズムを通じてデータを同期し、boltdbを通じてデータを格納します。1つのノードがハングすると、別のノードが自動的にリーダーを選出して、クラスター全体の高可用性特性を維持します。クライアントは、任意のノードに接続することでリクエストを完了できます。
次に、etcdのパフォーマンスを理解する
最初に写真を見てみましょう：
上の図は、標準のetcdクラスターアーキテクチャの簡略図です。etcdクラスターは、たとえば、青いRaftレイヤーと赤いストレージレイヤーなど、いくつかのコアパーツに分割できます。ストレージレイヤーはさらに、treeIndexレイヤーと、boltdbボトム永続ストレージキー/値レイヤーに分割されます。それらの各層は、etcdパフォーマンスの損失を引き起こす可能性があります。
Raftレイヤーを最初に確認します。Raftはネットワークを介してデータを同期する必要があります。ネットワークIOノード間のRTTおよび/または帯域幅は、etcdのパフォーマンスに影響します。さらに、WALはディスクIO書き込み速度の影響も受けます。
ストレージレイヤーを見ると、ディスクIO fdatasyncの遅延がetcdのパフォーマンスに影響し、インデックスレイヤーロックのブロックもetcdのパフォーマンスに影響します。さらに、boltdb Txのロックとboltdb自体のパフォーマンスもetcdのパフォーマンスに大きく影響します。
他の観点からは、etcdが配置されているホストのカーネルパラメーターとgrpc apiレイヤーの遅延もetcdのパフォーマンスに影響します。
3、etcdパフォーマンス最適化-サーバー側
以下は、etcdサーバーのパフォーマンス最適化の詳細な紹介です。
etcdサーバーのパフォーマンス最適化-ハードウェアの導入
サーバー側では、etcdの動作を保証するために、ハードウェアに十分なCPUとメモリが必要です。次に、ディスクIOに大きく依存するデータベースプログラムとして、etcdはIOレイテンシとスループットが非常に優れたssdハードディスクを必要とします。etcdは分散キー/値ストレージシステムであり、ネットワーク条件も重要です。最後に、展開では、ホストマシン上の他のプログラムがetcdのパフォーマンスに干渉しないように、できる限り独立して展開する必要があります。
添付ファイル：etcd公式推奨構成要件情報。
etcdサーバーパフォーマンス最適化ソフトウェア
etcdソフトウェアは多くの層に分かれています。以下は、さまざまな層によるパフォーマンス最適化の簡単な紹介です。詳細を知りたい学生は、次のGitHub prにアクセスして、特定の変更されたコードを取得できます。
- 1つ目は、etcdのメモリインデックスレイヤーの最適化です。内部ロックの使用を最適化して待機時間を短縮します。元の実装は、BTreeが使用する内部ロックをトラバースすることです。内部ロックの粒度は比較的粗いです。このロックはetcdのパフォーマンスに大きく影響します。新しい最適化により、この部分の影響が軽減され、遅延が減少します。
詳細については、以下のリンクを参照してください。
- 以下のためのリーススケールの使用を最適化するには、次の最適化アルゴリズムおよびリースリボークは、時間複雑性O（n）の下からO（LOGN）に元のリストを横断する障害を満了し、リースの大規模な使用の問題を解決します。
詳細については、以下のリンクを参照してください。
- 最後に、それはバックエンドのboltdbの 使用のために最適化されています：バックエンドのバッチサイズの制限/間隔を調整して、さまざまなハードウェアとワークロードに応じて動的に構成できるようにします。これらのパラメーターは以前は控えめな値でした。
- もう1つのポイントは、Googleエンジニアによって最適化された完全な同時読み取り機能です。読み取りパフォーマンスを向上させるためのboltdb tx読み取りおよび書き込みロックの最適化された使用。
分離されたハッシュマップに基づくetcd内部ストレージのフリーリストを配布およびリサイクルするための新しいアルゴリズム
他にも多くのパフォーマンス最適化がありますが、ここではAlibabaによるパフォーマンス最適化に焦点を当てています。このパフォーマンス最適化により、etcdの内部ストレージのパフォーマンスが大幅に向上します。その名前は、分離されたハッシュマップに基づくetcd内部ストレージのフリーリストの配布とリサイクルのための新しいアルゴリズムです。
上の図はetcdのシングルノードアーキテクチャです。Boltdbはすべてのキー/値の永続的なストレージとして内部的に使用されるため、boltdbのパフォーマンスはetcdのパフォーマンスにとって非常に重要です。Alibaba内では、内部ストレージメタデータとしてetcdを幅広く使用していますが、使用プロセス中に、boltdbのパフォーマンスの問題を発見しました。
上の図は、etcdの内部ストレージの割り当てとリカバリのコアアルゴリズムです。ここに背景知識をいくつか示します。まず、etceはデフォルトのページサイズ4KBを使用してデータを格納します。図に示すように、数字はページID、赤はページが使用中であること、白は使用されていないことを示します。
ユーザーがデータを削除する場合、etcdはこのストレージスペースをすぐにシステムに返さず、最初に内部的に予約し、ページのプールを維持して次の使用のパフォーマンスを向上させます。このページプールはフリーリストと呼ばれ、図に示すように、フリーリストのページID 43、45、46、50、53が使用され、ページID 42、44、47、48、49、51、52はアイドル状態です。
新しいデータストレージが3の連続ページの構成を必要とする場合、古いアルゴリズムはフリーリストヘッダーからスキャンを開始し、最後にページ開始IDを47に返す必要があるため、通常のetcd線形スキャン内部フリーリストアルゴリズムを確認できます。データ量が多い場合、または内部の断片化が激しい場合、パフォーマンスは急速に低下します。
この問題に対応して、分離されたハッシュマップに基づく新しいフリーリスト配布リサイクルアルゴリズムを設計および実装しました。アルゴリズムは連続ページサイズをハッシュマップのキーとして使用し、値は開始IDの構成セットです。新しいページストレージが必要な場合、このハッシュマップ値をクエリしてページの開始IDをすばやく取得するには、O（1）時間の複雑さだけが必要です。
上記の例をもう一度見てみると、サイズ3の連続するページが必要な場合、このハッシュマップをクエリすることで、開始ページIDの47をすばやく見つけることができます。
また、ページを解放するときに、最適化のためにハッシュマップも使用しました。たとえば、上の図でページID 45と46が解放されると、前後にマージして大きな連続ページ、つまり開始ページIDが44でサイズが6の連続ページを形成できます。
要約すると、新しいアルゴリズムは、O（n）からO（1）への割り当ての時間の複雑さを最適化し、O（nlogn）からO（1）への回復など、etcd内部ストレージはその読み取りおよび書き込みパフォーマンスを制限しなくなりました実際のシナリオでは、そのパフォーマンスは数十回最適化されています。1つのクラスターから推奨ストレージ2GBを100GBに拡張できます。現在、最適化はアリババで内部的に使用されており、オープンソースコミュニティにエクスポートされています。
ここで別のポイントですが、今回言及した複数のソフトウェアの最適化は、新しいバージョンのetcdでリリースされる予定です。
4番目、etcdパフォーマンス最適化-クライアント側
etceクライアントのパフォーマンス使用のベストプラクティスを紹介しましょう。
最初に、etcdサーバーがクライアントに提供するいくつかのAPI（Put、Get、Watch、Transactions、Leases、およびその他の多くの操作）を確認しましょう。
上記のクライアント操作について、いくつかのベストプラクティスコールを要約しました。
- Put操作では、大きな値を使用しないでください。K8でのcrdなど、合理化してから合理化してください。
- 次に、etcd自体が適用され、まれに変更されるいくつかのキー/値のメタデータ情報を保存します。したがって、クライアントは頻繁に変更されるキー/値を作成しないようにする必要があります。この時点、たとえば、K8の下の新しいノードノードのハートビートデータのアップロードは、このプラクティスに従います。
- 最後に、多くのリースを作成することを避け、再利用を選択する必要があります。たとえば、K8sでは、イベントデータ管理：TTL有効期限が同じイベントでも、新しいリースを作成する代わりに、同様のリースを多重化に選択します。
最後に、1つのことを覚えておいてください。クライアントがベストプラクティスを使用できるようにすることで、etcdクラスターが安定して効率的に実行されるようになります。
このセクションの要約
このセクションはここにあります。ここに皆のための要約があります：
- まず、etcdのパフォーマンスの背景を理解し、背後にある原理から潜在的なパフォーマンスのボトルネックを理解します。
- etcdサーバーのパフォーマンス最適化を分析し、ハードウェア/展開/内部コアソフトウェアアルゴリズムの側面から最適化します。
- etcdクライアントのベストプラクティスを理解する。
最後に、この記事を読んだ後、何かを得て、安定した効率的なetcdクラスターを実行するための支援を提供できるようになることを願っています。