Qunar.com は Mesos と Docker をベースにしたプライベートクラウドサービスを構築

この記事では、Qunar.com が Mesos と Docker を使用してプライベートクラウドサービスを構築するプロセス全体を詳しく説明し、ステートレスアプリケーションからステートフルアプリケーションへの段階的な移行の経験と洞察を共有します。

プラットフォームの概要

2014 年後半頃、Qunar はプライベートクラウドサービスの構築に関する技術調査を完了し、最終的に Docker/Mesos ソリューションを選択しました。下の図 1 は、Qunar のデータプラットフォームの全体的なアーキテクチャを示しています。

図1: Qunarデータプラットフォームの全体的なアーキテクチャ

現在、プラットフォームには次の機能が実装されています。

毎日約 340 億/25 TB のデータを処理します。
データの 90% は 100 ミリ秒以内に処理されます。
最大3時間/24時間のデータ再生。
プライベート Elasticsearch クラウド。
自動監視とアラーム。

Docker/Mesosを選ぶ理由

今のところ、このデータプラットフォームは、プライベートElasticsearch Cloudや監視アラームなどのデータを含む同社のストリーミングデータ全体の主な入口と出口であると言えます。では、なぜ Docker/Mesos なのでしょうか?

Docker を選択する主な理由は 2 つあります。 1つ目はパッケージングです。業務をパッケージ化した後の運用・保守において、日々直面するのは、マシンにスクリプトを配布する際に生じるさまざまな問題です。ビジネスパッケージは比較的高度なトピックなので、ここでは詳しく説明しません。ここで言う「パッケージング」とは、ソフトウェアのランタイム層を指します。 Docker のパッケージングメカニズムを使用して、問題が発生しやすいランタイムをイメージにパッケージ化してレジストリに配置し、必要なときに取り出すと、プラットフォーム全体で最大 1 つのリモートスクリプトを実行するだけで済みます。これはチームが最も楽観視している機能です。 2 つ目は運用と保守です。Docker は依存関係の制限を削除します。仮想環境またはランタイムイメージを構築すれば、それをサーバーに直接プルして、対応するプログラムを起動できます。また、Docker はクリーンアップが比較的簡単で、環境のクリーンでないアンインストールなどの問題を心配する必要がありません。

一般的なコンピューティングフレームワークに関しては、それらは本質的に、その上で実行されるジョブのランタイムに属します。上記に基づいて、チームはランタイム用にパッケージ化することを選択しました。

Mesos が選ばれたのは、シンプルで十分に安定しており、成熟したスケジューリングフレームワークを備えているためです。 Mesos のシンプルさは、そのすべての機能が Kubernetes の機能より劣っているという事実に反映されています。サービス自体をサポートしていないことが判明する場合もあります。ユーザーは、ネットワーク層を含む実際の要件を満たすために二次開発を行う必要があります。しかし、これがこの製品の強みでもあるのです。 Mesos 自体は多くの SDN インターフェースを提供し、またはモジュール読み込みメカニズムを備えており、カスタマイズや変更が可能で、プラットフォームのカスタマイズ機能が比較的強力です。したがって、Mesos ソリューションを使用する場合は、チームが開発プロセス全体を管理できるかどうかを考慮する必要があります。

フレームワークの観点から見ると、Marathon は長時間実行されるサービスをサポートできますが、Chronos はスケジュールされたタスク/バッチ処理に重点を置いています。

下の図 2 は Mesos の簡単な構造図です。

図2: Mesosアーキテクチャ

データプラットフォームの最終的な目標アーキテクチャを以下の図 3 に示します。

図3: プラットフォームターゲット

コンポーネントのコンテナ化と展開

コンポーネントのコンテナ化は、JVM コンテナ化と Mesos コンテナ化に分けられます。 JVM コンテナ化を使用する場合は、次の点に注意する必要があります。

潜在的なファイル作成の構成に注意してください

java.io.tmpdir  
 -XX:ヒープダンプパス 
 -Xloggc

-Xloggc は指定されたファイルに GC 情報を記録します。現在、XLoggc が直接構成に使用されることはほとんどありません (MXBean に置き換えられました)。 -Xloggc 経由で GC ログを出力する古いプログラムがある場合は、コンテナーに追加のボリュームをマウントする必要があります。

タイムゾーンとエンコーディング

–env TZ=アジア/上海 
 –ボリューム /etc/localtime:/etc/localtime:ro  
 –env JAVA_TOOL_OPTIONS=”-Dfile.encoding=UTF-8 -Duser.timezone=PRC

タイムゾーンも考慮すべき点です。上記の 3 つの異なる方法はすべて目的を達成できます。 1 番目/3 番目は Dockerfile に書き込むことも、docker 実行時に –env を介して渡すこともできます。 2 番目の方法は、docker の実行時にボリュームを通じてのみマウントされます。また、3 番目の方法では、文字セットのエンコーディングも追加で設定されるため、この方法が推奨されます。

ヒープをアクティブに設定する

人間工学によるメモリの誤算を防ぐ

これは Docker の内部実装の問題です。 Docker 用のメモリを設定しても、コンテナ内の free コマンドで見えるメモリはホストマシンのメモリと同じです。使いやすさを考慮して、JVM はデフォルトでヒューマンマシン関数を設定し、現在のマシンのメモリに基づいてヒープサイズを計算します。 JVM ヒープメモリを積極的に設定しないと、Memory Cgroup 制限を超えるメモリが計算され、起動時にクラッシュする可能性が非常に高いため、起動時のメモリ設定には注意が必要です。

CMSコレクターは並列処理を調整する必要がある

-XX:ParallelGCThreads=CPU パラレルGCスレッド数 
 -XX:ConcGCThreads=CPU/2

CMS は共通コレクターです。マシン上のコアの数を使用して並列度を計算します。コンテナに 2 つの CPU が割り当てられている場合でも、JVM はホストマシンのコア数に応じてスレッド数を初期化するため、GC 回復効率が低下します。この問題を回避する方法は 2 つあります。 1 つ目は、Lxcfs などの偽の Proc ファイルシステムをマウントすることです。 2 つ目は、Hyper のようなハイパーバイザーベースのコンテナーを使用することです。

Mesos コンテナ化では、構成パラメータと実行パラメータという 2 種類のパラメータに注意する必要があります。

注意が必要な設定パラメータ

MESOS_systemd_enable_サポート 
 MESOS_docker_mesos_イメージ 
 MESOS_docker_ソケット 
 GLOG_最大ログサイズ 
 GLOG_stop_logging_if_full_disk

Mesos には最も多くの構成パラメータがあります。物理マシンでは、Mesos はデフォルトでシステムの Systemd 管理タスクを使用します。 Mesos が Docker run を通じて起動される場合、Mesos Slave がコンテナのランタイムデータを取得して混乱を招かないように、ユーザーは systemd_Enable_support をオフにする必要があります。

2番目はDocker_Mesos_Imageです。この構成は、Mesos Slave が現在コンテナ内で実行中であることを伝えます。物理マシン環境では、Mesos スレーブプロセスがクラッシュして再起動すると、実行プロセス/コンテナの名前に基づいて回復アクションが実行されます。ただし、コンテナ内では、クラッシュ後にすべてのエグゼキュータがリサイクルされます。コンテナが再起動されると、スレーブはそれを新しい環境と見なし、上書きアクションをスキップしてタスクを自動的に送信するため、タスクが重複する可能性があります。

Docker_Socket は、Docker によって指定されたリモートアドレスまたはローカルファイルがデフォルトで Mesos コンテナにマウントされていることを Mesos に伝えます。ユーザーがファイルを直接実行すると、ファイルエラーが発生し、メッセージの取得に失敗します。このとき、現在の物理マシンのディレクトリをコンテナにマウントし、個別に名前を付けるという簡単な方法が推奨されます。これは、コンテナ内の物理マシン全体のパスに直接アクセスし、そのアドレスを再指定することと同じです。このようにして、変更があるたびに、Mesos はそれを検出し、独自の指示を実行できます。

次の 2 つは Mesos Logging 構成であり、ログファイルの生成の動作を調整します。

注意が必要な実行パラメータ

--pid=ホスト
–特権
–net=ホスト (オプション)
ルートユーザー

スレーブコンテナーを起動するときには、Pid Namespace を追加しないことをお勧めします。コンテナー内の Pid=1 のプロセスは通常、アプリケーションであるため、子プロセスをリサイクルできない可能性があります。または、同じ目的を達成するために tini などのプロセスを使用してアプリケーションを起動しないでください。 –privileged および root ユーザーは主に Mesos の永続ボリューム機能用であり、それ以外の場合はコンテナにマウントできません。 –net=host はネットワーク効率を考慮します。結局のところ、ネイティブブリッジモードは比較的非効率的です。

図4: Qunarデータプラットフォームの展開フローチャート

上の図 4 は、Qunar データプラットフォームの展開のフローチャートです。

マラソンに基づくストリーミングスケジュール

Mesos 上の Spark の記録を見ると、Spark に基づく Marathon スケジューリングでも、ユーザーはフレームワークを開発する必要があります。本番環境に移行するには大量のコードが必要です。チームは以前、マスターで Spark が実行される問題を具体的に解決するために、約 1,000 行のコードを追加しました。ただし、ソフトウェアの 1 つがマスターに対して実行されることが多く、フレームワークごとに繰り返しコードが記述されます。さらに、内部ロジックの再利用は困難です。そのため、チームは上位レベルのすべてを統一されたフレームワークで実行することを検討しました。例えば、その後の運用・保守や容量拡張もすべてこのフレームワークひとつで行うことができます。チームは最終的に Marathon を選択し、Spark を Marathon タスクとして送信し、Spark を Marathon 内で配布しました。

ディメンションの標準化と自動化を提供することに加えて、Spark ベースの Marathon は Mesos-Dispatcher のいくつかの問題も解決できます。

構成を正しく同期できません。この部分の更新頻度は特に遅く、デフォルトの速度も非常に遅いため、自分でバージョンを維持する必要があります。最初の構成を正しく同期できません。いくつかのパラメータ情報、Spark コアの数、内部損失を設定する必要があります。ここでは、構成の一部のみを選択的に抽出して送信します。
属性に基づくフィルタリング機能がありません。現在の環境では、属性フィルタリング設定機能が明らかに欠落しています。マシンが専用であるか、特別な構成であるかに関係なく、すぐに送られると ES マシンがいっぱいになりやすくなります。
ロール/プリンシパルで Mesos にアクセスします。異なるビジネスラインにリソースを割り当てる場合、異なるロールの Mesos にアクセスすることはできません。
再登録できません。フレームワーク自体は再登録できません。フレームワークが実行中にクラッシュした場合、再起動後に以前のタスクは無視され、フレームワークを手動で強制終了する必要があります。
実行者は動的に拡張できません。最後に、動的に拡張または調整することはできず、一時的な変更が必要な場合は、タスクを再送信することしかできません。

全体のプロセスは、下の図 5 に示すように、比較的簡単です。

図5: 代替Spark Mesosディスパッチャ

しかし、まだいくつか問題があります:

チェックポイントとブロック

動的予約と永続ボリューム
ジャーを設定する
無効なボリュームをクリーンアップする

チェックポイントとブロックに関しては、動的予約機能を使用して、このタスクをこのマシンに直接「固定」することができます。ハングした場合は、元のマシンで直接再起動し、ボリュームをマウントして作業を続行できます。予約されていない場合は、データブロックが見つからない他のマシンにスケジュールされる可能性があり、その結果、データが失われたり、処理が重複したりします。

永続ボリュームは Mesos によって提供される機能です。データの永続性を考慮する必要があります。 Mesos は、ローカルディスクをディレクトリにアップグレードし、それを Docker に転送するというソリューションを提供します。データがローカルに書き込まれるたびに、永続ボリュームを通じて直接メンテナンスできるため、手動メンテナンスのコストが削減されます。しかし、現在問題があります。タスクがリサイクルされた場合、その永続ボリューム内のデータは自動的に削除されません。定期的に巡回して適宜削除するスクリプトを作成する必要があります。

一時ファイル

java.io.tmpdir=/mnt/mesos/sandbox
spark.local.dir=/mnt/mesos/sandbox

永続ボリュームを使用する場合は、これら 2 つの設定を変更し、シャッフルファイルなどの一時ファイルを書き込む必要があります。永続ボリュームが構成されている場合、ユーザーは永続ボリュームへのパスを書き込むこともできます。

粗粒度

Spark には、細粒度と粗粒度の 2 つのリソーススケジューリングモードがあります。現在、きめ細かなモードは推奨されていません。細粒度モードでは可能な限りすべてのリソースを占有することを考慮すると、Mesos リソースが枯渇する可能性が高くなります。したがって、この時点では粗粒度モードを選択する傾向があります。

図6: マラソンの嵐

上の図 6 は Storm に基づく Marathon のスケジュールを示しており、Flink の場合も同様です。オンライン操作と保守およびデバッグと組み合わせて、次の点に注意する必要があります。

ネイティブ Web コンソール

ランダムポート
ワイルドカードドメイン名を使用した OpenResty
デフォルトのソース Web コンソール、フロントエンド構成転送、固定ドメイン名への直接アクセス。

ファイルビート + カフカ + ELK

マルチバージョントレース
日常的なトラブルシューティング
異常な監視

WebUI に表示される内容のほとんどは、現在の内部データ処理ステータスであり、ELK を通じて情報を照会できます。タスクが異なるバージョンの Spark で実行された場合、日次および問題の監視を含む複数のバージョンのログを追跡し、直接使用することができます。

メトリクス

3番目に注目するのはインジケーターです。たとえば、Spark では、データソースを出力するために Metrics のみを使用する必要があります。

Mesos の ELK

現在、プラットフォームには約 50 のクラスター、約 100 TB 以上のビジネスデータ、ピーク時の 1.2k QPS、約 110 のノードがあります。 Elasticsearch の需要は徐々に増加しています。

図7: Mesos上のELK

上の図 7 は Mesos 上の ELK の構造図であり、これもチームの無力な選択です。 Mesos はまだマルチロールフレームワーク機能をサポートしていないため、この妥協的なアプローチが選択されました。マラソンでは、ビジネスラインに応じてクォータを設定した後、ビジネスラインを使用して新しいマラソンを起動し、それに接続します。マルチテナントの場合、後続のリソース管理とリソース適用に Kubernetes を使用できます。

ES をデプロイした後、サービス検出に関する問題が発生します。コールバックを登録すると、Marathon は情報を返し、マスター/スレーブプロセスが配置されているマシンとポートを解析し、Haproxy を変更して転送レイヤーを実行します。これは、バックエンドの TCP 接続全体をチャネルにするのと同じです。 ES は Spark とまったく同じではありません。 Spark 送信自体のトラフィックは比較的大きく、ES は起動時にマスターアドレスにアクティブに接続し、マスターを介して対応するクラスターを取得してから P2P を実行する必要があります。トラフィックは比較的少なく、リンクも長くありません。

監視と操作

この部分には、ストリーミング監視インジケーターとアラーム、およびコンテナ監視インジケーターとアラームの 2 つの側面が含まれます。

ストリーミング監視インジケーターとアラーム

ストリーミング監視には、トポロジ監視とビジネス監視が含まれます。
ストリーミングトポロジー監視

ビジネスモニタリング

Kafka トピックラグ
処理遅延平均90/上限90
Spark スケジューラの遅延/プロセスの遅延
検索数/メッセージ数
拒否/例外
仮想マシン

トポロジ監視には、データソースとトポロジプロセス全体が含まれており、これらはユーザーが整理して構築する必要があります。更新すると、これが誰に依存しているか、オンラインサービスに依存しているかどうかがわかります。途中で止まると機械の故障の原因になります。ビジネスモニタリングの場合、最初のものはトピックラグです。トピックラグの変動はそれぞれ異なります。このように監視すると、頻繁にアラームが発生します。中央値の 90% は 80 ～ 100 ミリ秒の範囲内にあるため、範囲全体を監視できます。

コンテナ監視インジケーターとアラーム

コンテナ監視は、次の 3 つの側面に重点を置いています。

Google cAdvisorは十分に効果的

rootfs をマウントするとコンテナの削除に失敗する可能性があります #771
--docker_only
–docker_env_metadata_whitelist

統計 + ウォッチャー

Graphiteベースの数千万の指標監視プラットフォーム

ナギオス

コンテナ部分は比較的シンプルです。 Docker を使用して Mesos と連携し、Marathon ID を取得するだけです。練習中に問題を発見しました。 Statsd Watcher は問題が発生しやすいです。 Docker を直接使用すると、いくつかのエラーが報告されます。この問題は、Statsd Watcher がパスをハングさせることです。私たちのプラットフォームでは、この問題に一度遭遇しており、コミュニティの一部の人々もこれを暴露しましたが、再発率は比較的低いです。使用中にこの問題が見つかった場合は、Statsd Watcher を停止してください。インジケーターとしては、各マシンに statsd を配置してバックグラウンドワーカーを送信し、アラームプラットフォームもこれです。

実際、Docker 監視にはまだいくつかの問題があります。

基本的な監視圧力

データインフレ
ゴミ指標の増加
ワイルドカードの数が多いとデータベースの負荷が高くなります

単一タスクのコンテナライフサイクル

リリース
スケーリング
突然辞める

まず第一に、監視システムは大きな圧力にさらされています。もともと、仮想マシンを監視する場合は、仮想マシンごとに監視していました。仮想マシンが削除されない限り、長期レポートが実行され、インジケーター名が固定されます。しかし、コンテナ内では、このものは常に変化しています。このシステムでは、インジケーターが使用され、ローカルディレクトリの外部にディレクトリが作成され、そこにファイルが保存されます。したがって、このストレージメカニズムにコンテナーインジケーターを保存することは適切ではありません。主な問題は、データの拡張が非常に深刻であることです。コンテナに名前が付けられ、複数回名前が付けられた後、Graphite 側に対応するインジケーターが 10 個以上存在する場合があります。これらはすべて事前に生成された監視ファイルです。たとえば、1 秒ごとにデータポイントを定義し、それを 1 年間保存する場合、1 年あたりの秒数に基づいて RRD ファイルが生成され、そこに保存されます。これらの指標を既存の基準に従って計算すると、コンテナのライフサイクルは数日しかない可能性があり、このメカニズムは適用できません。同じ量のメトリックをテストしたところ、同社のストレージ方法は Graphite よりも比較的優れています。 Graphite はファイルシステムに基づいているため、最初に行うべきことはインジケーター名を最適化することです。インデックスの高速化とクエリのために、ディレクトリをデータベースに転送する必要があります。ただし、コンテナ側にはワイルドカードが比較的多いため、具体的な対応IDを直接取得することはできません。集計にはワイルドカードクエリのみを使用できます。長期ワイルドカードは文字列インデックスで依然として簡単に使用できるため、一般的に使用されるクエリ結果とディレクトリをそこに入れるという妥協案が採用されるようになりました。

もう 1 つはコンテナのライフサイクルです。監査やバージョン変更を行ったり、Mesos レベルで Marathon に基づいて監視したり、問題が見つかったときにその状態をマークしたり、どのコンテナーまたはタスクに問題があるか、それに応じて容量を拡張して記録したりすることができます。 Docker 自体にも問題があるため、後でレコード全体を作成すると、比較的完全な TASK-ID が得られます。

著者について: Xu Lei は、Qunar.com プラットフォーム部門の運用保守開発エンジニアです。 2015年にQunar.comに入社し、リアルタイムログの開発と運用・保守を担当しています。彼は通信およびクラウドコンピューティング業界で長年の経験を持ち、Red Hat China で勤務していました。

<<: 「9つの言葉、1つの手、専用のクラウド」、Youfu Networkのクラウドへの道

>>: クラウドコンピューティングは「星を見上げる」ことから「地に足をつけた」ものへと進化しました