K8s のアップグレードにより Didi が 12 時間停止したのですか?

みなさんこんにちは。ジュン兄です。

少し前に起きた Didi の障害については、皆さんご存知だと思います。 P0 障害を 12 時間のサービス中断として分類することは不公平ではありません。

写真

障害レビュー

運用保守担当者がk8sをアップグレードした際、当初はバージョン1.12から1.20にアップグレードする予定だったが、操作ミスで間違ったバージョンを選択してしまい、クラスターを下位バージョンにダウングレードしてしまったという噂がネット上で流れている。

Didi のアップグレード計画については、以下のDidi Technologyブログでもご覧いただけます。

写真

アップグレードコストを削減するために、Didi はその場でアップグレードすることを選択しました。まずマスターをアップグレードし、次にノードをアップグレードします。 k8s の公式アーキテクチャを見てみましょう。

写真

マスター ノード (公式 Web サイトの図では CONTROL PLANE と呼ばれています) は、3 つの重要なコンポーネントで構成されています。

• cloud-controller-manager: コンテナオーケストレーションを担当します。
• kube-api-server: Node ノードの API 登録サービスを提供します。
• スケジューラ: タスクのスケジュールを担当します。

ポッドは、ノードが kube-api-server に正常に登録された後にのみ実行できます。 Didi のブログからは、インプレース アップグレード方式が採用されていることがわかります。マスターをアップグレードした後、ノードは徐々にアップグレードされます。ノードには再登録プロセスがあります。ただし、このソリューションを選択する場合、運用および保守担当者はそれを繰り返し練習する必要があります。再登録にかかる時間は非常に短く、ユーザーはそれに気付かないでしょう。

ただし、マスターが間違ったバージョンを選択してダウングレードすると、kube-api-server が汚染され、ノードはマスターへの登録に失敗し、すぐにロールバックできなくなります。このようにして、ノードはクラスターによって不健全なノードとみなされ、上のポッドは強制終了され、サービスは停止します。

クラスター隔離

写真

この停止中に議論されたもう一つのホットな話題は、k8s クラスターの分離でした。これは、タクシー配車サービスや自転車サービスなど、複数のサービスが同時にダウンしたことから、それらはすべて同じクラスター上に存在し、分離のために別のクラスターが構築されていなかったことが示されました。これは、ブログで「最大クラスター サイズがコミュニティが推奨する上限の 5,000 ノードを大幅に超えている」と述べられている理由でもあるかもしれません。

もちろん、ビジネスが急成長していたときに、すぐにオンライン化してビジネスを立ち上げるために、1 つのクラスター上に複数のビジネスを構築した可能性もあります。その後、分割するという案もあったようですが、事業成長の余地が少なく、既存のクラスターを維持できることが判明したため、見送られました。

複数のクラスターに分割することによる利点は明らかで、ビジネスの分離、障害の分離、信頼性の向上などが挙げられます。このアップグレードを例に挙げてみましょう。まず、パイロットとして、ビジネス ボリュームが小さい、重要度の低いクラスターをアップグレードしました。アップグレードが成功したら、他のクラスターを 1 つずつアップグレードしました。

しかし、欠点も明らかです。運用と保守の複雑さが増し、コストが増加します。

アップグレードプラン

これまでの数年間、私は大規模なプラットフォーム再構築に何度か参加してきましたが、インプレースアップグレードには関わったことがありません。主な理由は、アーキテクトがインプレース アップグレード ソリューションを選択することにあまり積極的ではないことです。これらは主に以下の考慮事項に基づいています。

• ビジネスシステムを現地で再構築してアップグレードすることは、それを打倒して再構築するほど徹底的ではありません。
• ビジネスへの影響を最小限に抑えるために、通常はグレースケールリリースを通じてトラフィックを段階的に新しいバージョンに切り替えます。
• 交換およびアップグレード計画により、チームの成果をよりよく示すことができます。

Didiのような大企業であれば、運用・保守チームには有名人が揃っていると思います。どのような解決策を採用する場合でも、繰り返し検証されている必要があります。おそらく間違ったバージョンを選択しなければ、その場でアップグレードしても問題はないでしょう。

コストを削減し、効率を高める

滴滴出行のWeiboでの謝罪コメント欄を読んだ後、多くの人が今回の事故の原因はコスト削減と効率化によるもので、コストの高い最前線の運行・保守要員を解雇し、コストの低い新人を維持したためではないかと推測した。

データから判断すると、Didiは確かにコスト削減と効率化を目的として過去2年間に人員削減を行ってきたが、これが事故の直接的な原因であるとは考えていない。

急速な成長段階では、システムを構築するために多くの技術者が必要になります。しかし、国内のインターネットの規模は基本的にピークに達しています。長年事業を運営していると、爆発的な成長はなくなり、システムは非常に安定します。このような状況では、会社にはそれほど多くの技術者は必要なく、メンテナンスのために何人かの人員を残しておけば十分です。

したがって、どの企業であっても、コスト削減や効率化は事業が安定した後に必ず経験しなければならない段階です。 Didi の 12 時間にわたる停止によって引き起こされた損失について考えてみましょう。技術者 1,000 人を雇用するコストよりも高くなる可能性はありますか?

私たち研究開発担当者は、急成長中の企業に入社する機会があれば、そのチャンスをつかんでもっと稼いで、解雇されたらのんびりするべきです。定年まで会社で働くのは難しすぎる。同時に、私たちが会社にもたらす価値も認識する必要があり、優れた技術力を持っているという理由だけで、私たちがその PPT エンジニアよりも価値があると考えてはいけません。

要約する

本稿では、ネット上で広まっている滴滴出行の失敗原因を踏まえ、アップグレード計画やコスト削減、効率化について分析する。いよいよ今年も終わりが近づいてきました。皆様がシステムをしっかりと維持し、年末の評価に影響するような重大な障害を回避できることを願っています。