低コストで高速なコンテナ化イメージの展開: コンテナ環境での Xiaohongshu の CD 実践

コンテナは発売以来、ソフトウェア開発に非常に伝染性の高い興奮と革新をもたらし、大企業からスタートアップ、研究開発からさまざまな IT 担当者まで、あらゆる業界や分野から多大な支持を受けています。

有名な越境電子商取引プラットフォームである Xiaohongshu の事業が拡大するにつれて、オンライン展開ユニットの数が飛躍的に増加し、Jenkins を使用してスクリプトを呼び出してファイルをプッシュする展開モードでは、ニーズを満たすことができなくなりました。

[[207473]]

この記事では、Xiaohongshu が最小限の投資と開発労力でコンテナ化されたイメージの展開を迅速に実装する方法と、その結果得られるメリットを紹介します。

[[207474]]

図1

Xiaohongshu はコミュニティとして始まった越境電子商取引プラットフォームです。現在、ユーザー数は5,000万人に達し、eコマースプラットフォームのSKUは10万に達しています。ユーザーは、私たちのプラットフォーム上で生活、フィットネス、ショッピング体験、旅行などに関する投稿を好んでおり、毎日 1 億件の投稿が公開されています。

コミュニティ内のユーザーが作成したメモから関連するタグを生成し、関連する製品を関連付け、製品ページには製品に関連するコミュニティ内のユーザーメモも表示されます。

Xiaohong はまだ立ち上げ段階にあり、技術チームも大きくありません。もちろん、運用・保守自体も少人数のチームで行っています。チームは小規模ですが、運用と保守に関するすべての技術的側面に関与する必要があります。

中小企業はリソースが限られています。理由の一つは人材が限られていること、もう一つは推進すべき事業がたくさんあることです。 CI/CD をうまく実行し、実践的に実装する方法に関しては、オープンソースを優先するのが当社の戦略です。当社ではオープンソース製品を優先し、ニーズが満たされない場合はオープンソースをベースに自社で開発します。

小紅書オンライン申請手続き

図2

図 2 は、アプリケーションを起動するプロセスを示しています。開発者は運用保守部門に要件を提出し、必要なサーバーの数を尋ねます。運用保守部門は要件に基づいてアプリケーションを初期化し、その情報を開発者に提供します。

現在、運用・保守プラットフォームが整備されており、すべてのサーバーの展開はこのプラットフォームで完了します。プラットフォームは Tencent Cloud API を呼び出してサーバーを生成し、環境を初期化し、監視とアラームを構成し、最終的に標準化されたサーバーを開発者に提供します。

図3

開発者がサーバーを取得し、オンライン リリースの準備をするとき、Jenkins を使用してスクリプトをトリガーします。Jenkins スクリプトを使用してテストを実行し、コード プッシュを実行します。

新しいサーバーを追加したり、サーバーをオフラインにしたりする必要がある場合は、リリース スクリプトを変更する必要があります。リリースのプロセスは、大まかに次のようになります。まず Jenkins スクリプトがベータ環境にリリースされ、開発者がベータ環境でセルフテストを行い、セルフテスト環境で問題がなければ完全リリースが行われます。

開発者自身がテストしてオンラインでリリースしたところ、問題がなかったという状況に何度も遭遇しました。全巻をオンラインで送信しましたが、失敗しました。

ロールバックするときは何をすべきでしょうか?プロセス全体は 1 回だけ実行できます。開発者は古いコードをロールバックし、Jenkins スクリプトを再度実行します。全体のプロセスには最大 10 分かかります。このプロセス中はオンライン障害が常に発生するため、効率が非常に低くなります。

上記の慣行は、実際にはほとんどの企業の現状ですが、私たちはもはやそれに適応することができません。現在、私たちの技術全体が変化を遂げており、環境はますます複雑になっています。

既存のコードローンチモデルを維持したままだと、当然制御不能になるリスクがあり、そのようなインフラをベースとした自動キャパシティ管理などを行うことは困難になります。

技術チームの問題とニーズ

まず、当社の技術チーム全体の人数が増加しており、テクノロジースタックが変化しています。以前は、技術環境は純粋な Python でしたが、現在はさまざまなチームが Java、Go、Node を試しています。

マイクロサービス変革にも取り組んでいます。これまでのモノリシックなアプリケーションは、さまざまなマイクロサービスに急速に分割されており、アプリケーションの数も大幅に増加しています。

マイクロサービスを分割した後、チームはさらに細分化されました。同時に、フロントエンドとバックエンドも分割しています。もともと、多くの APP ページはバックエンドでレンダリングされていましたが、現在はフロントエンドとバックエンドを分割しています。バックエンドプログラムは API であり、フロントエンドは表示ページです。さまざまなアプリケーション間の依存関係もますます高まっています。

電子商取引企業が毎年実施する大規模なプロモーションと相まって、現在のモデルでは生産能力の拡大にも時間と労力がかかります。したがって、現在のモデルを維持することは困難です。

私たちのチームは、2、3か月前にこれらの問題を解決し、オンライン環境とコードリリースを改善する方法について考え始めました。次のことを行う必要があります。

• コードからリリースまでのプロセスを再構築します。
• きめ細かなトラフィック管理を実現するための Canary リリース戦略をサポートします。
• すぐに巻き戻すことができます。
• 自動テストを実践するには、自動テストを実行できる環境が必要です。
• サーバーなどのリソースの透過的な管理を要求し、開発者がアプリケーションがどのサーバー上で実行されるかを心配しないようにします。これは開発者にとって意味がなく、開発者は開発のことだけを心配すればよいのです。
• 容量を便利に拡張および縮小できる必要があります。

コンテナ化されたイメージの展開を迅速に実現する方法

当社は当初からコンテナ化を考慮し、コンテナ管理に Kubernetes フレームワークを使用しました。

なぜコンテナ化なのか?コンテナとマイクロサービスは「良き友人」のペアであり、開発環境からオンライン環境まで基本的に一貫性を保つことができるからです。

Kubernetes を使用する理由は何ですか?これは、動作環境と展開環境に関係します。当社は Tencent Cloud を頻繁に使用しており、Tencent Cloud は Kubernetes に対して非常に優れたネイティブ サポートを提供しています。

いわゆるネイティブ サポートとは、次のような実装の側面があることを意味します。

• ネットワーク レベルでは、ベア メタル環境の Kubernetes は、Tencent Cloud 環境にオーバーレイ ネットワーク、つまり SDN ネットワーク環境を実装する必要があります。それ自体がソフトウェア定義ネットワークであり、ネットワーク上での実装は、パフォーマンスを犠牲にすることなく、コンテナ環境のネイティブ ネットワークと同じくらい高速になります。
• Tencent Cloud 環境では、Kubernetes 内のロードバランサーとサービスをバンドルすることができ、Kubernetes サービスを作成することでクラウド サービスの L4 ロードバランサーを保守することができます。
• Tencent Cloud のネットワークディスクは Kubernetes で管理でき、PVC などを実装できます。もちろん、Kubernetes 自体が提供する機能でもニーズを満たすのに十分です。

図4

スタートアップとして、私たちはオープンソースを主に扱っており、Jenkins、GitLab、Prometheus、Spinnaker などのオープンソース テクノロジーを新しい環境に適用しています (図 4)。誰もが Jenkins と GitLab について聞いたことがあり、使用していると思います。 Prometheus と Docker も現在主流のオープンソース製品です。

ここでは、比較的新しい、現在非常に人気のある 2 つのオープン ソース テクノロジに焦点を当てます。

• Spinnaker は、私が個人的に優れていると思うオープンソースのリリース システムです。これは昨年 Netflix によってオープンソース化され、Netflix が社内で使用してきたリリース システムに基づいています。これはCDにおけるNetflixのベストプラクティスと言えるでしょう。コミュニティ全体が非常に活発で、Kubernetes 環境を非常によくサポートしています。
• Traefik は、私たちの環境内の Nginx リバース プロキシを置き換えるために使用されます。 Traefik は、Go で書かれたリバース プロキシ サービス ソフトウェアです。

01. スピネーカー

Spinnaker には次の機能があります。

Netflix のオープンソース プロジェクト。 Netflix のオープンソース プロジェクトは、コミュニティ内で常に高い評価を得ています。

オープン性と統合機能を備えています。 Jenkins と GitLab の統合をネイティブにサポートでき、Webhook もサポートします。つまり、ある環境において、あるリソースの制御コンポーネント自体が API である場合、それを Spinnaker に簡単に統合することができます。

強力なパイプライン表現能力を有する。パイプラインは非常に複雑になる可能性があり、パイプラインは相互にリンクされる可能性があります。

強力な表現機能を備えています。式を使用して、任意のリンク内の静的パラメータと値を置き換えることができます。パイプラインの開始時に、生成されたプロセス変数はパイプラインの各ステージによって呼び出すことができます。

たとえば、パイプラインがいつ開始されたか、トリガーされたときのパラメータは何だったか、特定のステップが成功したか失敗したか、今回デプロイされるイメージは何だったか、現在オンラインになっているバージョンは何だったかなど、これらすべてに変数を通じてアクセスできます。

インターフェースは使いやすく、複数のクラウド プラットフォームをサポートしています。現在、Kubernetes、OpenStack、Amazon のコンテナ クラウド プラットフォームをサポートしています。

図5

図 5 は、ユーザー インターフェイス Deck、API ゲートウェイ Gate などを含むマイクロサービス アーキテクチャである Spinnaker のアーキテクチャを示しています。

API ゲートウェイは外部に公開することができ、これを使用して他のツールとの緊密な統合を行うことができます。 Rosco はイメージ構築のためのコンポーネントですが、Rosco を使用せずにイメージ構築を行うこともできます。 Orca はその中核となるプロセス エンジンです。

Echo は通知システムであり、Igor は Jenkins などの CI システムを統合するために使用されるコンポーネントです。 Front52 はストレージ マネージャーであり、クラウド ドライバーはさまざまなクラウド プラットフォームに適応するために使用されます。たとえば、Kubernetes には専用のクラウド ドライバーがあり、Amazon Container Cloud 用のクラウド ドライバーもあります。 Fiat はその認証コンポーネントです。

図6

図6はSpinnakerのインターフェースです。インターフェースは一見乱雑に見えますが、実際には優れたロジックを備えています。

ここでの各ブロックには、Kubernetes 環境内のインスタンスの現在のステータスを表す 3 つの色があります。緑はライブインスタンスを表します。右側には、インスタンスの YML 構成、インスタンスが配置されているクラスター、インスタンスのステータス、関連イベントなどのインスタンス情報が表示されます。

図7

図 7 はパイプライン インターフェイスです。まず第一に、インターフェースが素晴らしくてわかりやすいと思います。 2 番目に、パイプラインは非常に柔軟に作成できます。前のステップを実行した後、またはすべてのステップが完了した後に、特定のステップを実行できます。

このステップでは、ユーザーが承認を行い、3 つのステップのいずれかを実行してから、特定のリンクを実行します。リリースまたはロールバックすることもできます。リリースはリリース プロセスに従うことであり、ロールバックはロールバック プロセスに従うことです。

つまり、期待されるすべてのパイプライン関数をここで提供できます。それでもうまくいかない場合は、外部システムと簡単に統合できる Webhook モードもあります。

図8

図 8 はパイプライン ステップの種類を示しています。左上の前提条件をチェックします。前提条件が満たされた場合にのみステップが実行されます。

たとえば、特定のステップは、前回の最初のリリースのすべてのインスタンスがアクティブな場合にのみ実行されます。または、前のステップが特定の状態に達したら、次のステップを実行します。

デプロイは、Kubernetes 環境で生成されるレプリケーション セットです。デプロイでは、サーバー グループを更新したり、クラスターを無効にしたり、クラスターの容量を減らしたり増やしたりすることができます。

コンテナ内でスクリプトを実行することもできます。たとえば、Java は起動後すぐにトラフィックにアクセスできない場合があります。トラフィックの受け入れを開始する前に、データベースからデータをロードし、初期化作業を行うために Java でジョブを実行する必要がある場合があります。

図9

パイプライン式は非常に強力であり、その式は Grovvy を使用して作成されます。 Grovvy は動的言語です。 Grovvy で使用できる構文は、文字列がある場所ならどこでも使用できます。

したがって、これらのステップでは、ステップ パラメーターは式から取得されると言えます。条件付き実行があり、環境が生成された場合にそのようなことが行われるとも言えます。前提条件が存在する場合もあり、この条件が満たされると、プロセスとステージを続行できます。

図10

図10に示すように、さまざまなタイプの表現があります。これからは基本的に様々なニーズにお応えできるようになります。

図11

パイプラインは自動的にトリガーできます (図 11)。毎日、毎週、毎月、毎年、または特定の日にトリガーして自動リリースなどを行うことができます。パイプラインを使用して、新しいタグがイメージ リポジトリにプッシュされたときにイメージをリリースすることもできます。

02. SpinnakerとKubernetesの関係

図12

Spinnaker と Kubernetes の関係は何ですか? 1対1の概念はたくさんあります。 Spinnaker にはアカウントと呼ばれるものがあり、アカウントは Kubernetes Cluster に対応します。

現在、私たちの環境には、それぞれ開発、テスト、本番に対応する 3 つの Kubernetes クラスターがあります。これらは 3 つの Spinnaker アカウントにも対応しています。インスタンスは Kubernetes の Pod に相当し、Pod は実行単位です。

レプリカ セットまたはディポジションに対応するサーバー グループもあります。次に負荷分散があります。 Spinnaker でロードバランスと呼ばれるものは、Kubernetes ではサービスです。

03.トラエフィク

図13

Traefik のハイライトをいくつか紹介します。

• 再起動せずに構成をホットリロードします。リバースプロキシとして Nginx ではなく Traefik を使用するのはなぜですか?まず、Traefik はホットロード構成です。 Nginx を使用する場合、ルーティング ルールを更新し、バックエンド サーバーをオンラインおよびオフラインでリロードする必要がありますが、Traefik では必要ありません。
• ヒューズ機能内蔵。 Traefik には独自のサーキットブレーカー機能があり、たとえばバックエンドインスタンスのエラー率が 50% を超えるとアクティブに融合され、リクエストが送信されなくなるように定義できます。

traefik.backend.circuitbreaker:ネットワークエラー率() > 0.5

• 動的に重み付けされたラウンドロビン戦略。 5 秒以内のリクエストに対するすべてのバックエンド インスタンスの応答時間または接続数を記録します。バックエンド インスタンスの応答が特に遅い場合、このバックエンドの重みは、通常のパフォーマンスに戻るまで 5 秒間削減されます。このプロセスは絶えず調整されており、これが私たちが必要とする機能です。

traefik.backend.loadbalancer.method:drr

コンテナを使用した後、アプリケーションのすべてのインスタンスが同じ処理能力を持つノードにデプロイされていることを確認するのは困難です。クラウド サービス プロバイダーもサーバーを一括購入しますが、各一括購入が完全に一貫しているわけではないため、すべてのノードのパフォーマンスが一貫していることを保証することは困難です。

図14

図 14 は Traefik に付属するインターフェースです。定義したルールとバックエンド インスタンスのステータスをリアルタイムで表示できます。

04.Kubernetes環境でTraefikを選んだ理由は何ですか?

Traefik と Kubernetes の関係は何ですか? Kubernetes 環境で Traefik を選択する理由は何ですか?以下の点をまとめます。

• Kubernetes クラスター内の Ingress コントローラー。 Traefik は Kubernetes 内で Ingress コントローラーとして存在します。ご存知のとおり、Ingress の概念は Kubernetes 1.4 以降に導入されました。

Kubernetes には元々、サービス検出と負荷分散を実装するサービスが 1 つしかありませんでした。このサービスは 4 層の負荷分散サービスであり、ルールベースの転送を実行できませんでした。

• ルーティング ルールを更新するために Ingress を動的に読み込みます。 Kubernetes では、Ingress はレイヤー 7 HTTP の実装です。もちろん、Kubernetes 自体はレイヤー 7 の負荷分散を実行しません。これは Ingress Controller を通じて実装されます。 Traefik は Kubernetes の Ingress コントローラーです。
• サービス定義に従ってバックエンド Pod を動的に更新します。 Kubernetes の Ingress によって定義されたルーティング ルールを動的に読み込むことができます。 Ingress はルーティング ルールに対応するサービスも定義し、そのサービスは特定の Pod に関連付けられます。
• Pod の Liveness チェック結果に基づいて、利用可能な Pod を動的に調整します。 Pod リストは、Pod の Liveness および Readiness ステータスに基づいて動的に調整されます。
• リクエストはポッドに直接送信されます。 Traefik はこれを使用して、サービスによって管理される iptables を介してリクエストを転送せずに、ターゲット Pod に直接リクエストを送信できます。

図15

図 15 は、新しいリリース プロセスまたは開発プロセスです。次の 3 つのリンクがあります。

• 開発フェーズ。
• 統合テスト。
• オンライン。

開発フェーズでは、開発者はイテレーションの開始時に Feature ブランチを生成し、その後の更新ごとにこの Feature ブランチを GitLab にプッシュします。

GitLab で設定された Webhook は Jenkins ジョブをトリガーし、ユニット テストとイメージの構築を実行し、Feature ブランチのイメージを構築し、イメージに特定のタグを付けます。新しいイメージが生成されると、Spinnaker のデプロイメントがトリガーされます。この展開は開発環境のみで行われます。

開発者は、デプロイされたばかりの開発環境にどのようにアクセスするのでしょうか?これが HTTP アプリケーションで、アプリケーションの名前が APP1、ブランチ名が A であるとすると、開発者は APP1-A.dev.xiaohongshu.com を通じて機能 A のコードにアクセスできます。

サイクル全体を通じて継続的な反復を行うことができ、最終的に開発者が機能が完了したと感じたら、リリースにプッシュできます。コードがリリースにプッシュされると、別のビルドがトリガーされます。これは基本的に前のプロセスと同じです。

最後に、自動テストがあります。これは基本的に、テスト チームによって提供される自動テスト ツールです。 Spinnaker を使用して呼び出し、結果を確認します。

今日自信がつき、本番環境にリリースすることに決めた場合は、Git でタグを生成できます。たとえば、このタグが 0.1.1 で、バージョン 0.1.1 を今日リリースしたい場合、イメージのビルドもトリガーされます。

これら 3 つの異なる段階で構築されるイメージ タグは異なります。新しいタグが生成されるたびに、Spinnaker はタグの命名規則に従って異なるパイプラインをトリガーし、異なる環境にデプロイします。

05.カナリア

最も重要なことは、カナリアリリースプロセスがあることです。 Spinnaker をベースにした Canary メカニズムを開発しました。

Canary は Beta に似ていますが、Canary では実際のトラフィックが導入されます。オンライン ユーザーを 2 つのグループに分けます。

• トラフィックユーザーの安定バージョン。
• Canary ユーザー。

彼らは新しいバージョンを最初に使用することになります。私たちの具体的な戦略は、まずそれを会社と私たちのオフィスの人々に提供することです。グレースケールに問題がなく、ユーザーフィードバックもOK、モニタリングデータにも問題がなければ、オンラインユーザーを1%-10%-20%-50%-100%の段階でランダムに選択し、グレースケールを継続します。

プロセス全体を通じて監視データが利用可能であり、いつでも例外が発生した場合は、Spinnaker を通じてロールバックできます。

図16

これはCanaryの概略図です。オンラインユーザーは 2 つのグループに分けられます。ほとんどのユーザーは古いバージョンにアクセスし、特定のユーザーは負荷分散によって特定のバージョンに転送されます。 2 つのバージョン間の違いを比較しやすくするために、バックグラウンドで監視データがあります。

図17

これは、コンテナ環境に実装した Canary アーキテクチャです (図 17)。ユーザーリクエストは正面から入ってきて、最初にTraefikにヒットします。 Canary プロセスがない場合、Traefik はグループ インスタンスにリクエストを直接送信します。

新しいバージョンをリリースする場合は、プロジェクト サービスを制御し、どのような種類のトラフィックがこのバージョンにアクセスできるのかを決定する HTTP API があります。

私たちの戦略としては、IP でオフィス ユーザーに電話をかけたり、オンラインの Android ユーザー、またはオンラインの Android ユーザーの 1% に電話をかけたりすることが考えられます。これらはすべて定義可能です。

図18

図 18 は実際のオンライン展開プロセスを示しています。最初に行うことは、カナリア戦略を設定することです。カナリア戦略では、完全にランダムにするか、ユーザーの特定のソースに基づいてするかを指定できます。

たとえば、オフィスのユーザーや上海の全ユーザーなどが考えられます。次に、パラメータを上海ユーザーの 1% または上海ユーザー全員に調整します。

次に、サービスのデプロイを開始し、Canary インスタンスを拡張します。トラフィックが流入する前に、インスタンス容量を準備する必要があります。

トラフィックは、到着後、バックエンド Pod に直接送信されるのではなく、Canary プロキシ サービスに送信されるようリダイレクトされます。その後、Canary プロキシ サービスは、戦略とユーザー ソースに基づいてトラフィックをさらに分散します。

プロセス全体は継続的に繰り返され、オンライン ユーザーの 1% が徐々に 100% に到達し始めます。 100% に達すると、赤黒戦略を使用してすべての古いバージョンを置き換えます。最初にすべての新しいバージョンのインスタンスを生成し、すべての新しいバージョンがヘルス チェックに合格してオンラインになるまで待機し、その後、古いバージョンを一括してオフラインにして、グレースケールを完成させます。

途中で問題が見つかり続行できなくなった場合は、すぐにロールバックできます。いわゆるロールバックとは、トラフィックをオンライン バージョンに戻すことを意味します。

図19

上の図 (図 19) は、当社のカナリア戦略です。これは私たち自身が実装したもののセットです。画像の例は、指定されたネットワーク セグメントの半分の iPhone ユーザーに対して Canary を実行することです。

ユーザー グループ化ディメンションには他のルールが存在する場合があります。現在、完全にランダム/特定の IP/特定のデバイス タイプをサポートしており、これらのルールを組み合わせることができます。

当社のユーザー グループの一貫性は保証されています。ユーザーがグループ化されると、現在のグレースケール期間中はユーザーのグループ化は変更されません。変更されると、ユーザー エクスペリエンスに影響します。

今後の展開

次に、次の 2 つのことを行う予定です。

• 自動グレースケール解析は ACA と呼ばれます。 AIOps の概念は現在非常に人気があります。自動グレースケール解析は、AIOps の具体的な実装と言えます。

グレースケール処理中に、人間が新しいバージョンが正常かどうかを判断します。ログ収集が十分に完了していれば、この判断は機械で行うことができます。マシンはすべてのデータに基づいて新しいバージョンにスコアを付け、その後、パブリッシング システムはスコアの結果に基づいて自動的にパブリッシングを続行するか、リリースを終了してロールバックします。

• さらに、Kubernetes をベースに自動容量管理を行って、コンピューティング リソースをより有効に活用することもできます。

要約すると、優れた CD システムはリリースによってもたらされるリスクを制御できる必要があります。人的資源が限られている場合、問題を解決するためにオープンソースの方法を使用する傾向があります。オープンソースが満足できない場合は、何らかの適応機能を開発します。

[[207478]]

孫国清

小紅書運用保守チーム長

彼は浙江大学のコンピュータサイエンス学部を卒業し、長年にわたり伝統的な企業の IT 部門で勤務しました。近年はインターネット業界の技術・技術経営にも携わる。彼は Ctrip Infrastructure で勤務し、Linux システムの標準化と分散ストレージの研究と実装を担当しました。彼は現在、Xiaohongshu の運用保守チームを率いており、ビジネス アプリケーション、インフラストラクチャ、IT サポートを担当しています。私は幅広い技術に触れており、開発から運用・保守までさまざまな分野に興味を持っています。私は Scala 言語のファンであり、「The Neophyte's Guide to Scala」を翻訳しました。この本は何千人もの Scala 開発者に役立っています。 Xiaohongshuに入社してからは、DevOpsの体系的な実装と運用・保守の効率化を担当するようになりました。