Zhihu クラウドネイティブアーキテクチャプラクティス

著者 |王 陸

編集者 |王瑞平

この記事は、Zhihu のクラウド ネイティブ アーキテクチャの責任者である Wang Lu 氏の WOT2023 カンファレンスでの基調講演からまとめたものです。さらにエキサイティングなコンテンツやライブPPTについては、51CTO Technology Stack公式アカウントをフォローし、[WOT2023PPT]にメッセージを送信して直接受け取ってください。

最近、51CTOが主催したWOTグローバルテクノロジーイノベーションカンファレンスで、王陸は「Zhihuクラウドネイティブアーキテクチャの実践」と題した基調講演を行い、一般の人々に新たな視点を提示しました。

クラウド ネイティブは、高度にスケーラブルで信頼性が高く、持続可能なアプリケーションの展開と管理を実現することを目的とした、新しいソフトウェア アーキテクチャおよび開発モデルです。その中核となるコンセプトは、クラウド コンピューティング環境で実行できるマイクロサービスとしてアプリケーションを設計し、コンテナ化、自動管理、弾力的なスケーリングなどの技術的手段を使用して、アプリケーションの開発、配信、運用、保守のプロセスを最適化することです。主な機能には、コンテナ化、マイクロサービス アーキテクチャ、自動化された運用と保守、継続的な配信、柔軟なスケーリングなどがあります。

この記事は、WOTでの王陸氏の講演の素晴らしい内容から抜粋したもので、主にZhihuのクラウドネイティブアーキテクチャの進化プロセスとクラウドネイティブアーキテクチャの実践について説明しています。

クラウド ネイティブの登場により、ソフトウェア開発者はクラウド コンピューティング、コンテナー テクノロジー、自動運用と保守などの高度なテクノロジーをより有効に活用して、効率的で信頼性が高く、スケーラブルなアプリケーションを構築できるようになりました。企業により柔軟で効率的なアプリケーション配信および管理方法を提供し、クラウド コンピューティングとマイクロサービス アーキテクチャの開発も促進します。

同時に、クラウド ネイティブは一連の課題と変化ももたらし、組織と開発チームはクラウド ネイティブ時代の開発ニーズに適応するために、対応する技術変革と組織変更を実行する必要があります。

Wang Lu 氏は 2016 年に Zhihu に入社し、現在は同社の社内クラウド ネイティブ チームの責任者を務めています。彼は、Zhihu の内部オンライン インフラストラクチャのネイティブ アーキテクチャの構築を担当しており、Zhihu のクラウド ネイティブ アーキテクチャの進化と実践の全プロセスを個人的に経験しています。

1. クラウドネイティブの再理解：アーキテクチャの進化

クラウドネイティブは、何でも入れられるバスケットのようなものですが、クラウドネイティブとは何かを説明するのは難しいです。 Wang Lu 氏は、クラウド ネイティブ アーキテクチャの進化を出発点として、クラウド ネイティブの概念を再解釈しました。それでは、クラウド ネイティブ アーキテクチャの進化について簡単に見てみましょう。

写真

図に示すように、ビジネスはモノリシック アーキテクチャから SOA アーキテクチャ、そしてマイクロサービス アーキテクチャへと進化してきました。インフラストラクチャは、物理マシンから仮想マシン、そしてコンテナへと進化しました。ついに2つの剣が合体し、クラウドネイティブ時代が到来しました！

クラウド ネイティブの出現により、ビジネス アーキテクチャとインフラストラクチャの接続はこれまで以上に密接になりました。具体的には、インフラストラクチャによってビジネス上の問題をより詳細に解決し、インフラストラクチャの問題ではなくビジネスの問題点に真に焦点を当てることができます。

写真

Cloud Native Computing Foundation によるクラウド ネイティブ テクノロジー スタックの公式定義には、次の部分が含まれます。1. コンテナー。 2. 不変のインフラストラクチャ。 3. 宣言型 API 4. サービス メッシュ、最後はマイクロサービスです。

このうち、マイクロサービスはビジネス アーキテクチャに属し、他の 4 つはインフラストラクチャに属します。実際には、マイクロサービスのデプロイメント、スケジューリング、オーケストレーションなど、マイクロサービスに関するさまざまなテクノロジを複数の方向に分割する必要があります。

もう 1 つの重要な方向性は、サービス メッシュとメッセージ キューの両方を含むマイクロサービスのトラフィック管理機能です。さらに、サービス メッシュは東西のトラフィック管理の問題のみを処理しますが、南北のトラフィック管理の問題もあります。

これらの指示は、最終的にはビジネスに実装するか、ビジネスがクラウドネイティブ インフラストラクチャのメリットを享受できるようにする必要があります。このため、企業がクラウドネイティブ アーキテクチャのメリットを享受できるように、DevOps プラットフォームを提供する必要があります。

2. 早く変更すればコストは下がる：Zhihuのクラウドネイティブアーキテクチャの進化

Zhihu は早い段階からクラウド ネイティブへの変革を開始し、2014 年と 2015 年にマイクロサービス変革とコンテナ化をビジネスに導入し始めました。進化のプロセスは、おおまかに次の段階に分けられます。

2016年、Zhihuは全事業のコンテナ化を完了しました。当時、知乎のトラフィックと規模は比較的小さく、変革コストも比較的低かった。

写真

2016年、ZhihuはMesosと自社開発のフレームワークを組み合わせて、すべての事業のコンテナ化を完了しました。登録センター HAproxy は、サービスの検出、登録、および通信に使用されます。

この段階の後、次の段階に移行します。 2018年から2019年にかけて、MesosはKubernetesに置き換えられ、ミドルウェアは主にHAProxyとKafkaがコンテナ化されました。

次の段階は2021年です。最大の変更点は、Service Meshの導入であり、これにより、従来の登録センター+ HAProxyサービスの検出と登録方法が部分的に置き換えられます。もう 1 つの大きな変更点は、主に TIDB と Redis のデータベースがコンテナ化されたことです。

現在、Zhihu は主にプライベート クラウドになっており、クラウドの構築は主に自社で行われています。ただし、この機能はパブリック クラウドに移行されており、リソースの弾力性が向上しています。もう一つの大きな変化は、段階的に進歩を遂げてきたオフラインとオンラインのハイブリッド展開です。

上記は、Zhihu のクラウドネイティブ アーキテクチャの全体的な進化プロセスです。

3. 基本アーキテクチャ: スケジューリングとKubernetesトラフィック管理

上の図は、比較的シンプルなクラウドネイティブ アーキテクチャ図です。下から上に向かって、主に物理マシンと仮想化層があり、その上にスケジューリングとオーケストレーション層があり、その上にKubernetesのコアとなる基本サービスも構築されています。

写真

たとえば、トラフィック管理には主にサービス メッシュ、サービス ゲートウェイ、メッセージ キューが関係しますが、対応するサービス メッシュは東西トラフィック管理です。

マイクロサービス ゲートウェイは南北トラフィック管理を担当し、メッセージ キューは非同期トラフィック管理を担当します。一部のミドルウェアはトラフィック管理と重複しています。たとえば、Kafka と Pulsar は、トラフィック管理機能とメッセージ キュー機能を備えている場合があります。 TIDB と Redis も Kubernetes 上で実行されます。

重点は、スケジューリングおよびオーケストレーション層、Kubernetes、トラフィック管理、可観測性、およびデプロイメント プラットフォーム、サービス メッシュ プラットフォーム、ゲートウェイ プラットフォーム、可観測性プラットフォームなどのインフラストラクチャ上に構築されたプラットフォーム アプリケーションにあります。

4. Zhihu クラウドネイティブアーキテクチャプラクティス: Kubernetes のスケジューリングとオーケストレーション

Zhihu は、クラウド ネイティブの実践中に Kubernetes をスケジュールおよびオーケストレーションする上でどのような実践経験を持っていますか?

写真

上の写真はZhihuの事業のすべてを網羅しています。このアーキテクチャに問題が発生した場合、Zhihu のビジネス全体に影響が及ぶことになります。 Kubernetes はこのアーキテクチャ図の中で接続の位置を占めており、クラウドネイティブ アーキテクチャ全体の基礎となります。

Kubernetes に問題が発生した場合、その影響は壊滅的なものになる可能性があるため、安定性が重要です。

次に、Kubernetes の安定性を構築するための 2 つのコア エクスペリエンスを示します。1 つ目はクラスターのサイズを制御することです。 2 つ目は API サーバーを保護することです。

まず、Kubernetes クラスター管理においてクラスター サイズを制御する主な方向性は 2 つあります。1 つ目は超大規模クラスターです。もう1つは複数の小規模なクラスターです。

Zhihu の観点から見ると、超大規模クラスターを維持するには、運用・保守コストなど莫大なコストがかかります。大規模クラスターではパフォーマンスの問題がより多く発生するため、比較的小規模なクラスター 3 つを運用し、大規模なクラスターを維持するための運用および保守コストは比較的低くなります。 2つ目は研究開発費です。 10,000 ノードまたは 5,000 ノードを超えるノードを運用および保守する場合は、研究開発コストを支払ってネイティブ コンポーネントを変換する必要がある場合があります。

もう一つの重要なポイントは、失敗の影響です。業務全体を大規模なクラスター内に配置した場合、障害発生時の爆発半径は極めて大きくなります。ただし、複数のクラスターに分散されている場合、1 つのクラスターが完全に故障しても、その影響は壊滅的ではなく最小限に抑えられます。

Zhihu の実践的な経験に基づくと、大規模な超大規模クラスターよりも、複数の小規模 Kubernetes クラスターの方が実用的です。

写真

ただし、複数のクラスターを使用する場合は、次の問題に対処する必要がある場合があります。1 つ目は、複数のクラスターをどのように分割するかです。 2 つ目は、複数のクラスター間でリソースをスケジュールする方法です。 3 つ目は、複数のクラスター間でサービス検出と通信を実行する方法です。

API サーバーの安定性を維持するという点において。 Zhihu は関連する失敗を何度か経験しています。たとえば、異常なトラフィックの「ハング」は、直接的に「出血」につながります。このとき、内部ゲートウェイ機能を再利用し、7 層の電流制限を実行して異常なトラフィックを制限し、主要コンポーネントのトラフィックを保護し、Apiserver が迅速に回復できるようにする必要があります。

5. トラフィック管理の実践: サービスメッシュ、メッセージキュー、ゲートウェイ

トラフィック管理には、主にサービス グリッド、メッセージ キュー、ゲートウェイの 3 つのコンポーネントが含まれます。

まず、次の重要な質問について説明しましょう。交通管理のプロセスにおいて、東西交通管理、非同期交通管理、南北交通管理を組み合わせる必要があるのはなぜでしょうか。

まず、ビジネスが発展するにつれて、マイクロサービス間の通信はますます複雑になります。このため、電流制限や回路遮断機能の自動構成など、多くのガバナンス機能要件が提唱されています。

2 番目に、既存のソリューションの変換は、実際には HAProxy + 登録センター方式です。理論的には、HA に基づいてガバナンス機能全体を改善できますが、研究開発コストが高くなります。

3 番目に、サービス メッシュ ソリューション istio は、豊富な標準化されたトラフィック管理機能を提供します。これは、インフラストラクチャ機能に対するビジネス ニーズまたはビジネス要件を満たすことと同じです。

写真

アーキテクチャの観点から見ると、パフォーマンスの最適化またはパフォーマンス上の最大の課題は、プッシュ パフォーマンスです。 Istiod はすべての構成を Sidecar にプッシュする必要があります。これには、構成の最適化とアーキテクチャの最適化の両方が必要です。

現在、Zhihu は、グローバル電流制限機能を含むローカル電流制限機能を提供する電流制限コンポーネントの完全なセットを開発し、負荷分散の問題にも対処しています。

実践により、集中型の負荷分散の方が効果的であることが証明されています。ただし、メッシュ モードまたはサイドカー モードに切り替えると、各サイドカーと各クライアントにグローバル負荷情報が欠落し、一部のビジネス面では負荷効果が極端に悪くなります。

Zhihu はこれらの面でもいくつかの改善を行いました。グローバル情報が欠落している場合は、サイドカーを起動し、インスタンスのグループを個別の負荷分散クラスターとして扱い、よりバランスの取れた効果を実現する必要があります。このソリューションと以前の HAProxy の最大の違いは、既存の istiod のガバナンス機能を完全に取得できることです。

6. 観察可能なプラクティス: メトリクス、ログ、トレース

可観測性の実践に関しては、Zhihu の基盤レイヤーはストレージ システムとして Victorian Metrics を統一的に使用し、上位レイヤーは Promesql 形式で保存され、ネイティブの Promesql 形式のクエリと独自開発のコンポーネントの両方を提供します。

図: 観測可能な指標システム

観測可能性は比較的単純です。 Filebeat は収集側であり、ストレージは自社開発であり、検索はストレージに依存し、完全なログは Flink を通じて HDFS に着陸します。

トレースでは、Open Telemetry コレクション エンドが均一に使用されます。 ClickHouse はストレージとクエリに使用されます。パフォーマンスは比較的ニーズを満たすことができます。

7. 最後に: 常にビジネスニーズと安定性に注意を払う

インフラストラクチャは、ビジネス アーキテクチャのニーズに常に注意を払う必要があります。アーキテクチャのアップグレードは、単なるアップグレードではなく、ビジネスに役立つものでなければなりません。アーキテクチャのアップグレードがビジネスにメリットをもたらすのか、あるいはアーキテクチャのアップグレードによってビジネス開発の効率や安定性が向上するのかを検討する必要があります。もう 1 つのポイントは、アーキテクチャのアップグレードのタイミングが適切である必要があることです。

さらに、安定性が常に最優先されます。安定性が保証されなければ、すべてのアーキテクチャのアップグレードは空中楼閣になってしまいます。

今後、Zhihuはマルチクラウド、マルチアクティブ、オフラインとオンラインのハイブリッド展開にさらに重点を置き、フルタイムのオフラインとオンラインのハイブリッド展開への投資を継続し、フルタイムのハイブリッド展開を実現します。サーバーレスも将来の開発方向です。