ホスト管理について話す

2020 年にマシンをオンラインにするには、8 つのサービス間を行ったり来たりする必要がありますが、プロセス全体が手動で行われます。 Didi のビジネスが拡大し、クラウドに移行すると、弾力性のあるクラウドに多数の物理マシンが追加され、オンライン操作は少なくとも 100 倍必要になりました。これにより、問題が明らかになりました。この速度でマシンをオンラインにするには、マシンの設置に大量の人手を投入する必要があります。したがって、Elastic Cloud では、ホストのオンラインおよびオフライン操作を管理するためのプラットフォームが緊急に必要です。

写真

無から有へ

DevOps、標準第一

DevOps の実践では、標準化は非常に重要な部分です。エラスティック クラウド内のすべてのマシンは、サービス ツリーを中心に管理されます。以前は手動で管理されていたため、サービスツリー上のエラスティッククラウドマシンのマウント状況は非常に混乱していました。そのため、マシン管理をより標準化するために、Elastic Cloud ではまずサービス ツリー ノードの標準と仕様を定義し、ホストのライフサイクルをサービス ツリー ノードに関連付けます。具体的には：

• マシンがオンライン: マシンは初期化のためにバックアップ ノードから kube-node-init ノードにマウントされ、その後、アラームの関連付けのためにオンラインの kube-node ノードにマウントされます。
• マシンのメンテナンス: オンライン マシンはメンテナンスのためにメンテナンス ノードにマウントされます。メンテナンスが完了すると、kube-node-init ノードにマウントされ、オンラインになります。
• マシンがオフライン: コンテナがドリフトした後、オンライン マシンはシャットダウンと置き換えのために pre-offline.backup ノードにマウントされます。

写真

プロセスの分解と需要分析

標準が定義された後、プラットフォームの要件が分析されます。まず、次の図に示すように、ホストのオンライン、オフライン、およびメンテナンスのプロセスを分解します。

写真

分解したプロセスを分析した結果、マシン管理プラットフォームには少なくとも以下の機能が必要であるという結論に達しました。

• プロセス全体には長い時間がかかり、ストリーミング タスクであるため、タスクは非同期で実行する必要があります。
• プラットフォームは多くのサードパーティ サービスに依存しており、下流の異常なシナリオに柔軟に対応するために、スキップ、再試行、一時停止などの機能をサポートする必要があります。
• 各プロセス間には繰り返しのステップがあり、プログラムの柔軟性を向上させるにはステップを自由に組み合わせることができる必要があります。
• 二重チェックの原則に従って、タスクは作業指示書の形式で提示する必要があります。

アーキテクチャ設計、コード開発

ソフトウェア開発において、プログラムの階層化は、ソフトウェア システムをよりモジュール化、拡張可能、かつ保守しやすいものにできる一般的なソフトウェア アーキテクチャ パターンです。要件が明確になったら、開発プロセスに入ることができます。プラットフォームの製品形態の観点から見ると、プラットフォームの将来の使用プロセスは次のようになります。ユーザーが作業指示書を作成し、ユーザーが承認後に作業指示書を実行し、プログラムが実行アクションを感知してタスクを実行し、プログラムがタスクの進行状況に関するリアルタイムのフィードバックを提供し、タスクが異常な場合にユーザーに通知し、ユーザーが介入して問題を処理します。タスクが完了すると、作業指示書は終了します。したがって、プラットフォームは 4 つのレイヤーに分けられます。

• アクセス層: ユーザー アクセス制御、マシン アクセス制御。
• 制御層: 作業指示書の制御、作業指示書の作成、実行、終了など。
• スケジューリング レイヤー: タスクのスケジュールと配布。
• 実行レイヤー: ステップを結合し、タスクを実行し、フィードバック ステータスを提供します。

グループサービスのほとんどは Go 言語で開発されているため、今回の開発にも Go 言語が選択されました。アドミッション レイヤーとコントロール レイヤーでは一般的な Web フレームワークを使用できますが、スケジューリング レイヤーと実行レイヤーでは非同期タスク スケジューリング フレームワークが必要です。

Go 言語には優れた Web フレームワークが多数ありますが、スケジューリング フレームワークはほとんどありません。いくつかのフレームワークを比較した後、最終的に最も多くの星を獲得した非同期タスク フレームワーク マシンを選択しました。しかし、使用していくうちに、機械はタスクフローやタスク再試行などの機能をサポートしているものの、タスク一時停止やスキップなどの機能のサポートが不足しており、さらにいくつかの機能をカプセル化する必要があることがわかりました。しばらく試してみたところ、コードを読むのは書くよりもはるかに難しいことがわかりました。さらに、Go の並行性と非同期性のネイティブ サポートは優れているため、最終的にスケジューリング レイヤーを自分で実装することにしました。最終的な開発サイクルは長くなりますが、プログラムの保守性と拡張性は向上します。このようにして、ホストライフサイクル管理サービス (mmachine) の最初のバージョンが 2 か月後にリリースされました。

写真

ホストはメンテナンスのためオフラインです

ホストライフサイクル管理の最初のバージョンでは、マシンオンライン機能のみがリリースされ、基本的にはマシンオンラインを手動から無人に移行できるようになりましたが、マシンオフラインとメンテナンスには依然として手動によるサポートが必要でした。

歴史的な理由により、Elastic Cloud の一部のサービスはコンテナ IP を介して通信するため、一部のコンテナは IP ドリフトを変更できず、マシンがオフラインになったときにマシン上のコンテナを空にすることが困難になります。手動でオフラインにすると、フローティング コンテナーは移動され、非フローティング コンテナーはサービス移行のためにビジネス側で接続されます。経験上、ビジネス サービスの移行を手動でプッシュするには長い時間がかかります。プログラムを通じてプッシュした場合、効果は手動の場合とそれほど変わりません。

では、オンライン ビジネスに影響を与えずにオフラインとみなされるには、マシンはどのような状態に到達する必要がありますか?そこで私たちは、1、2、10 原則という新しい基準を定義しました。マシンがオフラインになったら、クラスターでドリフトしていないコンテナを確認します。

• マシンに 5 個未満のレプリカと 1 個を超える実行されていないコンテナーを含むクラスターがある場合、マシンをオフラインにすることはできません。
• マシンに、レプリカ数が 5 より大きく 20 より小さいクラスターがあり、実行されていないコンテナの数が 2 より大きい場合、マシンをオフラインにすることはできません。
• マシンに 20 を超えるレプリカがあり、クラスター内の実行されていないコンテナの数がレプリカの総数の 10% を超える場合、マシンをオフラインにすることはできません。

マシンがオフラインになると、まずマシン上のコンテナが移動され、マシンが正式にオフラインになる前にマシンの徹底的な検査が実行されます。 1、2、10 の原則に違反しないという前提で、Elastic Cloud はマシンをシャットダウンします。

スケジューラ設計の柔軟性により、オフライン マシンとオンライン マシンの手順がマシン メンテナンス プロセス (オフライン - 修復 - オンライン) に統合されます。また、機械メンテナンス時に操作が必要な機械が比較的明確なため、自動化の度合いが比較的高く、人手による介入がほとんど必要ありません。具体的な戦略は以下のとおりです。

• 修理報告: 各コンピュータ ルームは、月曜日から金曜日まで 1 台のマシンの修理を報告できます。
• オンライン: 毎週月曜日、水曜日、金曜日にマシンをスキャンして修復し、オンラインにします。

効率性の向上

最初のフェーズでは、Elastic Cloud によってホストライフサイクル管理サービス (mmachine) の構築が 0 から 1 に完了し、マシンをオンラインにするために必要な時間が数日から数時間に短縮されました。しかし、サービスの使用中に、最適化できる領域がまだ多くあることがわかりました。

オンラインプロセス最適化

マシンオンボーディングプロセスの最初のバージョンでは、すべてのマシンが 1 つの作業指示書に含まれていました。ただし、1 台のマシンがオンラインにならないと、作業指示全体の進行に影響します。たとえば、100 台のマシンがオンラインのときに 1 台のマシンの再インストールに失敗した場合、他の 99 台のマシンは、障害が発生したマシンが修復されるまでオンライン状態を続行できません。これは、マシンがオンラインになる効率に重大な影響を及ぼします。実際、マシンの起動間には相互依存性がないため、起動プロセスをシリアルから並列に変更して、単一のマシンの起動時間を大幅に短縮できます。そのため、機械間のやり取りによって発生する時間消費を削減するために、オンライン作業指示書を再設計しました。

ただし、起動プロセスが並列に変更された場合は、下流のサービスも並列処理をサポートする必要があります。しかし、再構築のプロセス中に、並行して処理できない 2 つの重要なポイントがあることがわかりました。

• マシンはオンラインになる前に再インストールする必要があり、注文を決済する前にすべてのマシンで再インストール操作を完了する必要があります。
• オンラインにするには、スクリプトを初期化するデプロイメント システムが必要ですが、デプロイメント システムは単一モジュールの同時操作をサポートしていません。

そこで、システム部門と連携して各マシンの再インストール状況を公開し、デプロイメントシステムからZeus実行への初期化スクリプトを変更することで、下流の並列処理の問題を解決しました。また、オンライン プロセスをホストごとに 1 つのタスク フローにアップグレードし、各タスク フローは互いに独立しました。最適化後、Elastic Cloud ホストの起動に必要な時間が数時間から数分に短縮されました。

バックアップマシン管理

機械の立ち上げプロセスは大幅に短縮されましたが、実際の機械の納品プロセスでは、機械の立ち上げは納品プロセス全体の 1 つのステップにすぎません。リソース不足の検出からマシンをオンラインにするまでの完全なプロセスには、次の手順が含まれます: 「リソース不足 -> マシンの申請 -> マシンの配送 -> マシンの再インストール -> オンラインにする -> コンテナのスケジュール設定」。オンライン トラフィックが突然増加した場合、このプロセスを通じてマシンを追加することは、近くの火を遠くの水で消すようなものです。しかし、エラスティッククラウドの観点から見ると、配信プロセスは「リソース不足 -> リソースの追加 -> コンテナのスケジュール設定」に簡素化できます。 「リソースの追加」ステップを事前に完了しておけば、数分でリソースの配信を実現できます。

分析の結果、システム部門には日常的なリソース配信に使用されるバックアップ マシンがいくつかあることがわかりました。同時に、エラスティック クラウドのオフライン クラスター コンピューティング リソースは比較的不足しています。オフライン クラスターは、エラスティック クラウド内の分離されたクラスターであり、分離されたクラスターとパブリック クラスターの性質は Kubernetes の taint 機能によって制御されます。スタンバイ マシンがオフラインの分離されたクラスターで実行されている場合、オンライン リソースが不足しているときは、スタンバイ マシンの汚染を削除してパブリック クラスターに追加するだけで、分単位のリソース配信を実現できます。また、オフラインコンテナは高い安定性を必要としないため、非弾性クラウド業務ラインの配信にバックアップマシンを使用する必要がある場合にも、すぐに返却することができます。そこで、Elastic Cloud はシステム部門と協力して、次のような具体的な機能を備えたバックアップ マシン管理モジュールを開発しました。

• 自動オンボーディング: バックアップ マシンがエラスティック クラウド バックアップ プールに配信されると、オフライン リソース プールに自動的にオンボーディングされます。オフライン サービスは、アイドル容量があることを検出し、自動的にサービスを拡張します。
• 簡単な補足: オンライン リソースが不足している場合、スタンバイ マシン管理モジュールは、テイントを変更してマシンをエラスティック クラウドのパブリック リソース プールに転送します。
• 迅速な返却: システム部門でバックアップ マシンが必要な場合、オフライン サービスを迅速に縮小してマシンを返却できます。

これにより、エラスティッククラウドの容量が保証され、会社のバックアップマシンプールが十分に活用され、バックアップマシンの利用率も向上します。

クラウド管理

社内のクラウドネイティブの発展に伴い、柔軟なクラウドマシン管理にも新たな課題が生じています。 IDC では、一度にオンラインになる物理マシンの数は通常数百台を超えませんが、クラウドでの弾力的なスケーリングには、毎日何千もの仮想マシンのスケールアップとスケールダウンが必要です。 IDC の物理マシンの周波数と数はクラウド上のものとは大きく異なり、コアリンク上のトラフィックを運ぶためにクラウドリソースが使用されるため、拡張効率も高速化する必要があります。クラウド上のマシンの数が増えるにつれて、問題が徐々に明らかになってきます。

• フルプロセス サービスには 8 つのダウンストリーム サービスがあり、ダウンストリーム サービスごとにレート制限戦略が異なります。
• マシンの初期化時間が長すぎて、1 回の初期化に 5 分以上かかります。
• 一度に 1,000 台を超えるマシンがオンラインになると、作業指示が停止する可能性があります。

速度制限の問題を解決するために、さまざまな速度制限戦略に応じて、プロセス全体を可能な限り互換性のあるものにしました。たとえば、搭載されているマシンの数が 200 台を超える場合、プロセス全体ではマシンを 200 台ずつグループにまとめて搭載し、コンテナ検査の頻度がマシン 1 台あたり 10 ミリ秒を超えないようにします。

時間がかかる問題を解決するには、クラウド上のミラーリング機能を使用して、展開する必要があるサービスを事前にミラーに埋め込むことができます。この方法では、仮想マシンがオンラインのときにマシンを初期化する必要がないため、マシンをオンラインにするまでの時間が大幅に短縮されます。ただし、この場合のマシンのオンボーディング プロセスは以前とはまったく異なります。スケジューラのオリジナル設計の利便性により、クラウド上の仮想マシンの起動用に別のタスクフローを追加し、起動プロセスを 23 ステップから 10 ステップに合理化し、マシンの起動にかかる時間を大幅に短縮しました。

写真

調査の結果、作業指示書の滞留のボトルネックは主にetcdとMySQLで発生していることがわかりました。スケジューラが最初に設計されたとき、ステップ実行の継続性を確保するために、スケジューラは閉じられていない MySQL タスクを継続的に取得し、etcd のロックを取得しようとしました。ロックを取得したプロセスはタスクを実行し、ロックを取得していないタスクはロックの取得を試行し続けます。同時実行性が高い状況では、このモードではロックが失われる可能性があります。そのため、タスクについては、タスクがすでに実行中かどうかを判断するために、データベースに新しい isRunning フィールドを追加しました。実行中のタスクの場合、スケジューラはタスク リストを取得しなくなり、ロックを取得しようとしなくなりました。さらに、タスククエリにかかる時間を短縮するために、主要なデータベース フィールドにインデックスを追加しました。これを行うと、一部のタスク実行の継続性が失われますが、安定性が大幅に向上します。一連の最適化措置により、クラウド仮想マシンのオンライン効率は 1,000 台あたり 1.5 分に向上し、毎日の弾力的なスケーリングのニーズを満たしています。

コスト最適化

エラスティック クラウドのコストは、主にサーバー コスト、価格設定サービス コスト、人件費の 3 つの部分で構成されます。その中でも、サーバー料金は毎月の総費用の大部分を占めます。コストを削減するために、エラスティック クラウドでは、コンテナ管理やホスト スケーリングなどの対策を講じて、サーバー価格の支出を削減し、エラスティック クラウド プラットフォーム サーバーへの投資を削減できます。弾性クラウドマシンのリソースは、実際に使用されるオンライン リソース、オンライン バッファ リソース、低負荷 (アイドル) リソースの 3 つのカテゴリに分類できます。これらのリソースを最適化することで、弾力性のあるクラウド マシンのコストが効果的に削減されます。

写真

マシンオフライン加速

これまでの最適化により、弾力性のあるクラウド マシンをオンラインにするのにかかる時間は、基本的に予想どおりになりました。機械のオフラインは各業務の安定性に関わるため、オフライン操作に費やされる時間は依然として比較的高いレベルにあります。 Elastic Cloud は、さまざまなコスト最適化プロジェクトの実施により、2023 年に大量のマシンを返却できると見込んでいます。ただし、過去の経験からすると、これらのマシンを完全に返却するには約 2 年かかる可能性があり、この速度では需要を満たすことができないのは明らかです。マシンがオフラインになるまでに長い時間がかかる主な理由は 2 つあります。

• マシンがオフラインになると、コンテナはマシンごとに順番にドリフトされる必要があります。コンテナをドリフトするにはホストマシンごとに約 10 分かかり、1 日にドリフトできるマシンは最大 50 台です。
• エラスティック クラウドでは、一部のコンテナーはドリフトできず、孤立したコンテナーも多数存在します。マシンがオフラインになると、これらの孤立したコンテナを処理する人は誰もいなくなり、その影響範囲が不明であるため、これらのマシンを簡単にシャットダウンすることはできません。

コンテナの移動速度を上げるために、オフラインプロセスを最適化しました。ドリフトモードを「マシンによるシリアルドリフト」から「クラスターによるパラレルドリフト」に変更し、1、2、10の原則を崩さずにコンテナを可能な限りドリフトします。安定性を確保しながら、コンテナのドリフト速度を1日あたり50個から1時間あたり100個に増加しました。私たちは SRE やさまざまな事業部門の同僚と協力して、孤立したコンテナをクリーンアップし、長期間放置されたコンテナをオフラインにするための標準を設定しました。

• 担当者に毎日通知が送信されます。通知が 3 回連続して行われると、バックアップ戦略に準拠していないクラスター リーダーにグループ通知が送信されます。
• グループ通知後、1日間観察します。処理されていないクラスターについては、対応するホストをシャットダウンし、3 日間観察します。
• 3日以内にユーザーから異常の報告があった場合、1時間以内にコンテナを復旧します。 3日経ってもフィードバックがない場合は、機械は返却されます。

新しいドリフトプロセスとオフライン標準により、弾性クラウドマシンのオフラインホストを効果的に改善できると同時に、さまざまな最適化プロジェクトの安定した進行も保証されます。

写真

低負荷リソース管理

2022 年には、エラスティック クラウド内に 10 日を超える低負荷時間のマシンが多数存在します。低負荷マシンの数を最適化すると、エラスティック クラウドのコストがいくらか削減されます。エラスティック クラウド内の低負荷リソースは、次の 2 つのカテゴリに分けられます。

• 低負荷が予想される：新計算機室がまだ運用開始されておらず、操縦翼面機の稼働率が低い等。
• 予期しない低負荷: 納品後にオンラインにするのを忘れたり、テスト後に返却し忘れたりしたなどの理由により、マシンがアイドル状態になっています。一部のマシンは、保証期間が経過した後や修理後に交換または返却されずにオンラインにできなくなります。

アイドル状態のマシンをオペレーターに自動的に通知する、プロセス全体を対象としたアイドル リソース管理および制御モジュールが開発されました。指定されたユーザーは、負荷が低いと予想されるマシンを免除することができますが、長期間免除されていないマシンは自動的に返却されます。これにより、最終的には在庫内の予想外に負荷が低いマシンが吸収され、新規追加が削減されます。

要約する

エラスティッククラウドの開発では、ホストのライフサイクル管理が重要な課題です。当初、マシンの起動は手動で行われていたため、起動に時間がかかりました。

この問題を解決するために、Elastic Cloud はホストライフサイクル管理プラットフォーム (mmachine) を開発しました。 mmachine は継続的な最適化と改善を通じて、オフライン標準と同時ドリフトをカスタマイズすることで、マシンをオンラインにする時間を短縮し、効率を向上させ、マシンのオフライン サイクルを短縮しました。安定性を確保しながら、エラスティックスケーリングやマシン交換などのプロジェクトで節約したリソースの回収を加速しました。 mmachine は、自動修復レポートや低負荷管理などのモジュールを通じて、リソースを最大限に活用し、エラスティック クラウド プラットフォームの全体的なリソース使用率を向上させ、エラスティック クラウド サーバーのコストを削減します。