58.com の高可用性 Docker コンテナ クラウド プラットフォームの技術的進化

58 プライベート クラウド プラットフォームは、58 Tongcheng Architecture Line がコンテナ テクノロジに基づいて社内サービス向けに開発したビジネス インスタンス管理プラットフォームです。

ビジネス インスタンスのオンデマンド拡張と数秒でのスケーリングをサポートします。このプラットフォームは、ユーザーフレンドリーなインタラクション プロセスと標準化されたテストおよびオンライン プロセスを提供し、開発者とテスターを基本環境の構成と管理から解放して、自社のビジネスに集中できるようにすることを目的としています。

[[207200]]

この記事では、主に次の 3 つの部分から、プライベート クラウド プラットフォームの実装に関連するコンテナー テクノロジのプラクティスを紹介します。

• 背景:現在どのような問題が存在し、なぜコンテナ テクノロジが使用されるのか。
• 全体的なアーキテクチャ:コンテナ テクノロジー全体のアーキテクチャ ソリューション。
• コア モジュールの設計計画:いくつかのコア モジュールの選択決定とソリューション。

コンテナ技術を使用する理由は何ですか?

コンテナ化技術を使用する前は、次のような問題がありました。

01リソース利用の問題

ビジネス シナリオによって、CPU 集約型、メモリ集約型、ネットワーク集約型など、リソースに対する要件が異なります。これにより、リソースの使用が不当になる可能性があります。たとえば、マシンに展開されているすべてのサービスがネットワークを集中的に使用する場合は、CPU リソースとメモリ リソースが無駄になります。

一部の企業では、サービス自体にのみ重点を置き、マシン リソースの使用率の問題を無視する場合があります。

02 ハイブリッド展開の相互影響

オンライン サービスの場合、1 台のマシンに複数のサービスが展開されていると、サービスが相互に影響を与える可能性があります。

たとえば、何らかの理由でサービスで突然ネットワーク トラフィックが急増した場合、マシン全体の帯域幅が完全に使用され、他のサービスに影響が及ぶ可能性があります。

03膨張・収縮効率が低い

ビジネス ノードの容量を拡張または縮小する必要がある場合、マシンのオフラインからアプリケーションの展開およびテストまでのサイクルは長くなります。企業が突然のトラフィックのピークに遭遇した場合、マシンを導入した後にはトラフィックのピークは過ぎている可能性があります。

04複数環境のコードの不整合

過去の非標準的な社内開発プロセスにより、いくつかの問題が発生しています。企業がテスト用に提出したコードは、テスト環境でテストされた後、パッケージ化されてオンラインになる前にサンドボックスで変更および調整される場合があります。

これにより、テスト コードとオンラインで実行されるコードの間に不整合が生じ、サービスの開始リスクが高まり、オンライン サービスの障害のトラブルシューティングが困難になります。

05安定したオフラインテスト環境の欠如

テスト プロセス中に、サービスが依存する他のダウンストリーム サービスが安定したテスト環境を提供しないという問題が発生する可能性があります。

これにより、テスト環境でオンライン プロセス全体をシミュレートしてテストを行うことが不可能になるため、多くのテスターはテストにオンライン サービスを使用することになりますが、これには高い潜在的リスクが伴います。

上記の問題を解決するために、Architecture Line Cloud チームは技術的な選定とデモンストレーションを繰り返し、最終的に Docker コンテナ技術を採用することを決定しました。

58 プライベートクラウドの全体アーキテクチャ

58 プライベート クラウドの全体的なアーキテクチャは次のとおりです。

01インフラ

プライベート クラウド プラットフォーム全体が、サーバー、ストレージ、ネットワーク、その他のリソースを含むすべてのインフラストラクチャを引き継ぎます。

02コンテナレイヤー

コンテナ初期化レイヤー全体は、Kubernetes、エージェント、IPAM を含むインフラストラクチャの上に提供されます。 Kubernetes は、Docker のスケジュールおよび管理コンポーネントです。

エージェントはホスト マシンに展開され、監視と収集、ログ収集、コンテナーの速度制限など、システム リソースと基盤となるインフラストラクチャを管理するために使用されます。 IPAM は Docker のネットワーク管理モジュールであり、ネットワーク システム全体の IP リソースを管理するために使用されます。

03リソース管理

コンテナ層の上にはリソース管理層があり、コンテナ管理、スケーリング、ロールバックとダウングレード、オンラインリリース、クォータ管理、リソースプール管理などのモジュールが含まれています。

04アプリケーション層

ユーザーが送信したビジネス インスタンスを任意のプログラミング言語で実行します。

05基本コンポーネント

プライベート クラウド プラットフォームは、サービス検出、イメージ センター、ログ センター、監視センターなど、コンテナ運用環境に必要な基本コンポーネントを提供します。

06サービス検出

クラウド プラットフォームに接続されたサービスは、クラウド プラットフォームへのビジネス アクセスを容易にする統合サービス検出メカニズムを提供します。

07ミラーセンター

ストレージビジネスイメージ、分散ストレージ、柔軟な拡張。

08ログセンター

ビジネス インスタンス ログを集中的に収集し、統一されたビジュアル エントリを提供して、ユーザーの分析とクエリを容易にします。

09 監視センター

すべてのホストおよびコンテナの監視情報を要約し、監視を視覚化し、アラームをカスタマイズして、インテリジェントなスケジューリングの基礎を提供します。

10統合ポータル

ビジュアル UI ポータル ページは、ビジネス プロセス全体を標準化し、ユーザー プロセスを簡素化し、クラウド環境全体のすべてのリソースを動的に管理できます。

新しいアーキテクチャにより、ビジネス フローに新しい方法がもたらされます。

プラットフォームは 4 つの基本環境を定義します。

• テスト環境:テスターは機能テストを実施し、オフライン環境に接続します。
• サンドボックス環境:オンライン環境に接続するプログラムのプレリリース環境。
• オンライン環境:サービスが提供されるオンライン環境。
• 安定した環境:オフライン環境で実行され、他のアップストリーム サービスに安定したテスト環境インスタンスを提供するインスタンス。

業務では、SVN で送信されたコードに基づいてイメージを構築し、イメージのライフサイクル全体が 4 つの環境で流れます。インスタンスは同じイメージに基づいて作成されるため、テストに合格したプログラムはオンラインで実行されているプログラムとまったく同じであることが保証されます。

コアモジュール設計

58 プライベート クラウド プラットフォームを開発する際には、考慮すべき詳細事項が多数あります。ここでは主に 5 つのコア モジュールを紹介します。

• コンテナ管理。
• ネットワークモデル。
• ミラーリポジトリ。
• ログ収集。
• アラームを監視します。

これらのコアモジュールにより、プラットフォームは基本的なフレームワークを備え、運用できるようになります。

01コンテナ管理

私たちは、Swarm、Mesos、Kubernetes という 3 つの主要な Docker ベースの管理プラットフォームを調査しました。比較した結果、最終的にKubernetesを選択しました。

Swarm は機能が単純すぎるため、当初は採用されませんでした。 Mesos + Marathon は成熟したソリューションですが、コミュニティが十分にアクティブではなく、使用するには 2 つのフレームワークに精通している必要があります。

Kubernetes は、コンテナ テクノロジー専用のスケジューリングおよび管理プラットフォームです。より専門化されており、非常に活発なコミュニティを持ち、多くのサポートコンポーネントとソリューションを備えており、ますます多くの企業で使用されています。いくつかの企業とのコミュニケーションを通じて、Docker アプリケーションを Mesos から Kubernetes に徐々に移行しています。

次の表は、私たちのチームの重点分野の比較を示しています。

02ネットワークモデル

ネットワーク モデルは、ネットワーク規模が拡大するとさまざまな問題が発生するため、あらゆるクラウド環境が直面しなければならない問題です。ネットワークの選択に関しては、Docker と Kubernetes の特性に基づいて、以下の 6 つのネットワーク方式を比較します。

クラウド チームは、Calico を除く各ネットワーク モデルについて対応するパフォーマンス テストを実施しました。これは、同社が使用しているコンピュータ ルームが BGP プロトコルの有効化をサポートしていなかったため、テストは実行されなかったためです。

iPerf によるネットワーク帯域幅のテストの結果は次のとおりです。

Qperf による TCP レイテンシのテストの結果は次のとおりです。

Qperf テスト UDP レイテンシの結果は次のとおりです。

テスト結果によると、ホスト モードとブリッジ モードのパフォーマンスはホスト マシンに最も近いですが、他のネットワーク モードとの間にはまだ若干のギャップがあり、これはオーバーレイの原理に関連しています。

プライベート クラウド プラットフォームは、次の理由により、最終的にブリッジ + VLAN ネットワーク モードを選択しました。

• 優れたパフォーマンス、シンプルなネットワークを備え、既存のネットワークにシームレスに接続できます。コンテナとコンテナ間、コンテナとホスト間の相互通信を適切に実現できます。
• 障害はデバッグが容易で、従来の SA で解決できます。あらゆる物理デバイスに適応でき、大規模に拡張できます。
• 社内のすべてのサービスは RPC プロトコルに基づいており、独自のサービス検出メカニズムを備えているため、優れた互換性が実現されています。既存の内部フレームワークへの変更は最小限です。

VLAN は最大 4096 個あるため、VLAN の数には制限があり、そのために VLAN が存在します。

現在のクラウド プラットフォームのネットワーク計画では、VLAN で十分です。今後、利用規模の拡大や技術の発展に合わせて、より適切なネットワーク構築方法についても深く研究してまいります。

一部の学生は、Calico の IPIP モードのネットワーク パフォーマンスも非常に高いとオンラインで報告しました。しかし、Calico には現在多くの落とし穴があることを考えると、それをサポートするには専用のネットワーク グループが必要ですが、クラウド チームにはそれが不足しているため、詳細な調査は行われませんでした。

ここで別の問題があります。デフォルトのブリッジ モードでは、各ホスト マシンに異なるネットワーク セグメントのアドレスが構成されます。これにより、異なるホスト上のコンテナに割り当てられた IP アドレスが競合することがなくなりますが、大量の IP が無駄になる可能性もあります。

コンピュータ室のイントラネット環境の IP リソースは限られており、この方法でネットワークを構成する方法はないため、グローバル IP 管理を実行するための IPAM モジュールを開発することしかできません。

IPAM モジュールの実装は、オープン ソース プロジェクト Shrike の実装を参照します。割り当て可能なネットワーク セグメントは etcd に書き込まれます。 Docker インスタンスが起動されると、IPAM モジュールを介して etcd から使用可能な IP アドレスが取得されます。インスタンスがシャットダウンされると、IP アドレスが返されます。全体的なアーキテクチャは次のとおりです。

また、Kubernetes では CNM の使用がサポートされていないため、Kubernetes ソースコードに変更を加えました。ネットワークに関して考慮すべきもう 1 つのポイントは、ネットワーク速度の制限です。

03ミラーリポジトリ

Docker のイメージ リポジトリは公式のイメージ リポジトリを使用しますが、バックエンドによって提供されるストレージ システムを選択します。デフォルトのローカル ディスク方式はオンライン システムには適用できません。具体的な選択は次のとおりです。

比較すると、Ceph が最も適していることがわかりますが、最終的にクラウド チームは、次の理由により、イメージ ウェアハウスのバックエンド ストレージとして HDFS を使用することを選択しました。

• Swift は公式にデフォルトでサポートされているストレージ タイプですが、Swift システムを構築し、安定した動作を確保するには、専任の担当者による徹底的な調査が必要です。人員が限られているため、まだ使用されていません。 Ceph も同じ理由で選択されませんでした。
• HDFS システム企業には、それを管理および保守するための専用のデータ プラットフォーム部門があります。彼らはより専門的であり、クラウド チームは HDFS 上で Docker イメージを安全にホストできます。

ただし、HDFS 自体にもいくつか問題があります。たとえば、圧力が高い場合、NameNode は時間内に応答できません。今後は、バックエンドストレージをアーキテクチャライン部門が開発したオブジェクトストレージへ移行し、安定的かつ効率的なサービス提供を検討してまいります。

04ログシステム

従来のサービスをコンテナ環境に移行すると、ログ記録が大きな問題になります。コンテナは使用後に販売されるため、コンテナが閉じられるとコンテナのストレージは削除されます。

コンテナ内のログはホストマシン上の指定された場所にエクスポートできますが、コンテナがドリフトすることがよくあります。トラブルシューティングを行う際には、特定のコンテナが履歴の特定の時点でどのホスト マシン上で実行されていたかも知る必要があります。また、ユーザーにはホストマシンへのログイン権限がないため、ログを適切に取得できません。

コンテナ環境では、新しいトラブルシューティング方法が必要です。ここでの一般的な解決策は、集中型ログ ソリューションを採用して、散在するログを統一的に収集して保存し、柔軟なクエリ方法を提供することです。

プライベート クラウド プラットフォームで採用されているソリューションは次のとおりです。

ユーザーは、管理ポータルで収集するログを構成します。プライベート クラウド プラットフォームは、環境変数を通じてそれらをコンテナーにマッピングします。ホストにデプロイされたエージェントは、環境変数に基づいて収集するログを取得し、収集のために Flume を起動します。

Flume はログを統一された方法で Kafka にアップロードし、Kafka にアップロードされたログは厳密な順序であることが保証されます。

Kafka には 2 つのサブスクライバーがあり、1 つは管理ポータルによるクエリのために検索サービスにログをアップロードします。もう 1 つは、履歴ログを照会およびダウンロードするためにログを HDFS にアップロードします。ユーザーは、指定したログを分析するために独自の Hadoop プログラムを作成することもできます。

05監視アラーム

リソースの監視とアラームもクラウド プラットフォームの重要な部分です。コンテナ監視には、成熟したオープンソース ソフトウェア オプションが数多くあります。 58 には内部に専用の監視コンポーネントもあります。クラウド チームも、監視を改善する方法について適切な選択を行いました。

最後に、クラウド チームは、WMonitor 自体が物理マシンとアラーム ロジックを統合するため、コンテナーの監視コンポーネントとして WMonitor を使用することを選択しました。対応する開発を行う必要はありません。コンテナ監視部分のコンポーネントを開発するだけで、内部監視のニーズに合わせて適切にカスタマイズできます。

Heapster + InfluxDB + Grafana は、Kubernetes が公式に提供する監視コンポーネントです。小規模な場合は問題なく使用できますが、全ノードの監視情報を取得するためにポーリングを行うため、大規模で使用する場合には問題が発生する可能性があります。

追記

上記の内容は、58.com のアーキテクチャ ラインがコンテナー テクノロジーをどのように実装できるかを調査したものです。多くの技術選択は、その長所と短所とは無関係であり、58 の関連するアプリケーション シナリオに適したものだけが選択されます。クラウドプラットフォーム全体で解決すべき技術的なポイントは数多くあります。ここで、いくつかの重要なポイントを取り上げ、皆さんにシェアしたいと思います。