【WOTD】JD Cloud 鄭永観：JD Cloudの自動運用保守システムの構築

2017年12月1日〜2日、51CTO主催のWOTD 2017グローバルソフトウェア開発技術サミットが深セン南山マリオットホテルで開催されました。 WOTブランドカンファレンスは、技術を重視し、技術者にサービスを提供するというコンセプトを堅持し、2012年以来14回のセッションを成功裏に開催し、多数の技術専門家リソースを蓄積し、大多数のIT実務家と技術愛好家から満場一致で認められ、業界における重要な技術共有・交換プラットフォーム、およびネットワーク拡張プラットフォームとなっています。

カンファレンスは、プログラミング言語とフレームワーク、ビッグデータシステムアーキテクチャ設計、マイクロサービスとコンテナ技術、フロントエンド開発の実践、モノのインターネット（IOT）技術、ソフトウェアパフォーマンスの最適化、ディープラーニングとインテリジェントアプリケーション開発、革新的な運用と保守の探究、技術アーキテクチャとビジネスアーキテクチャの出会い、CTOトレーニングキャンプの10の技術トピックに分かれています。この会議の主催者として、51CTO はイベント全体を通じてライブテキストと画像報道を提供し、この盛大な祝宴のポストプロダクションビデオプレゼンテーションも提供します。

12月1日午前、WOTD2017のメイン会場にて、JD Cloudのシニアアーキテクトである鄭永観氏が「JD Cloudの自動運用保守システムの構築」と題した素晴らしい講演を行いました。以下はスピーチの書き起こしです、ちょっと覗いてみましょう！

JD.com について誰もが知っているのは、JD.com の電子商取引かもしれません。実際、JD.com には、電子商取引、物流、金融、保険という 4 つの主要プラットフォームがあります。 JD には技術設備、ホスト ネットワーク、いくつかのミドルウェアおよび PaaS サービスがありますが、最も重要なのは電子商取引と物流です。

JD Cloud に関して、私たちが最も重視しているのは運用と保守であり、自動化された運用と保守のプラットフォームが必要です。この点に関しては、主にセキュリティ、展開の変更、ネットワーク管理、監視管理など、いくつかの重要な問題があります。自動化された運用と保守を使用して、プラットフォーム アーキテクチャの安定性と人材開発の効率を向上させます。

JD Cloudの自動運用・保守の基本コンポーネント

JD Cloud の運用と保守の課題は何ですか?実際、JD Cloud は PaaS サービスだけでなく、いくつかの SaaS サービスも提供しています。どうすればクライアントのビジネスを安定させることができるでしょうか?それは実は非常に難しい質問です。このプロセスでは、当社の一般的な経験では、まずサービス代理店、スケジュールシステム、顧客管理システムなどの運用および保守技術から始めて、これに基づいてクライアントを構築します。クライアント システムと技術的な概念があってこそ、前述のデプロイメント システム、リリース システム、タスク スケジューリング システム、監視システムなどを構築できます。最終的には、これらの機能を SaaS に変換して、より多くの人がこれらのことを行えるようにサポートし、JD Cloud のお客様により良いサービスを提供したいと考えています。

自動化された運用・保守を実現するためにまず必要なのが構成管理です。サービスツリーで解決したい問題は何ですか? 1 つ目は、サービスの組織構造の問題です。すべてのサービスには依存関係があり、サービスがどこで使用されているか、誰が使用しているか、どのような用途が考えられるかを把握する必要があるためです。 2番目は、当社のすべての技術管理です。大企業やJD.comのような規模の企業の場合、マシンの数は数十万台になります。数十万台のマシンの現在の状態をどうやって知ることができるのでしょうか?使い方は？多くの組織化が必要です。 3 つ目は、ロール管理とロールベースの権限制御です。他にも、モデルや、どのコンピュータ室にあるのか、現在の状態などのビッグデータもあります。最も重要なことは、当社のサービスがシステム内で同期されていることです。サービスがどのマシン上にあるか、どのインスタンスがあるか、どのアプリに属しているか、中間の論理プロセスは何か、外部にサービスを提供するときに、必要な権限と必要な監視の種類を他のユーザーにどのように伝えるかがわかります。私たちが行うすべてのことはサーバー上に構築されています。

ネーミング サービスは、サービス間の分離関係やサービス関連付け関係、およびサービスが外部に提供するウィンドウを解決するために使用されます。右の図はサービスツリーと名前サービス図を示しています。最上位層は、アプリケーションとインスタンスの関係の分離を示しており、これにはクライアントのニーズも含まれます。最も重要なファイルはタスクのスケジュールです。共同で操作を行う、オンラインにする、展開する、ファイルを配布するなど、何を行う場合でも、これらのシステムでは、ターゲット マシンが対応する操作を実行するようにスケジュールする必要があります。つまり、指定された戦略に従って、指定されたマシンで指定されたコマンドを実行する必要があります。このプロセスには、実際には比較的大きな課題が伴います。これはリアルタイムで大規模であり、同時に存在するため、より優れたシステム サポートが必要であり、バッチで使用することもできます。戦略もあります。どのような同時実行性が必要か、たとえば、100 台のマシンが必要ですが、そのすべてが同時に実行されるとは限りません。最も簡単なのは、それらをオンラインにすることです。 100 台のマシンすべてをオンラインにするつもりはありませんが、おそらくバッチでオンラインにするでしょう。これは並行性であり、それぞれの並行性がどのように実行されるかを示します。ローンチやタスクのスケジュール作成に取り組んでいるときは、その時点でいくつかの作業を行う必要があります。それは成功するでしょうか、それとも失敗するでしょうか?成功または失敗した場合、以下のロジックは何ですか?そして、どのレベルでビジネスは成功、あるいはタイムアウトと見なされるのでしょうか?多くのビジネスはこの基盤となるアーキテクチャ上に構築されているため、そのスケジューリング ロジックは同じです。

同時に、すべての実行は追跡可能である必要があります。つまり、誰が何をいつ実行したかを知る必要があり、これはセキュリティや標準化にとって非常に重要です。では、1 台のマシンの出力はどの程度でしょうか?どのような問題を見つける必要がありますか?障害が発生した場合、これはタスク スケジューリング システムであり、これに基づいて多くのことを行うことができます。スケジューリング ロジックは、サービス ツリーとネーミング サービスに基づいています。

3 つ目は監視です。これは、データの収集からデータの集約、保存、処理までのプロセスに他なりません。ここで非常に重要な概念は、監視データ層です。これは通常見られるものとは異なり、時系列です。これには時系列ストレージの構築が必要です。つまり、収集された監視ポイントが保存され、そのたびに多数のデータ ポイントをクエリする必要があります。また、非常に重要なのは、「読み取りを少なくし、書き込みを多くする」というプロセスであり、その「書き込み」（データの書き込み）は比較的バランスが取れているのに対し、「読み取り」（データの読み取り）はバースト的です。たとえば、いつでもモニターやモニターのステータスを確認できます。書き込みは、10 秒、1 秒、または 1 分ごとにデータを収集するプロセスです。書くことは頻繁に行われるプロセスですが、読むことは突然行われるプロセスであるため、読むことと書くことは切り離す必要があります。

私たちは ES に基づいて TSPD を作成しました。これは 2 つのことをカプセル化します。 1 つはホット データ、より重要なデータ、または Redis に保存されるリアルタイム データ用であり、もう 1 つは履歴データ用です。履歴データは ES によってカプセル化され、いわゆる読み取りと書き込みの分離が実現されます。当社のデータは、高いデータ可用性を確保するために二重の順序で書き込まれます。自動サンプリングとデータ監視には別の機能があります。クエリは頻繁に実行される場合もありますが、収集するデータ ポイントは 10 秒、1 秒、または 1 分であるため、クエリの範囲は 1 年間や 1 か月間など、非常に長くなります。 1 か月、1 年、あるいはそれ以上の期間にわたって確認しても、すべてのデータ ポイントが見つかるとは限りません。すべてチェックすると、クエリデータの量が大きくなりすぎて実装が難しくなります。そのため、書き込み時に自動的にサンプリングが行われました。 15 日間以上のデータをチェックし、これらのデータ ポイントを 1 分ごとまたは 1 時間ごとに集計して入力しました。その後、1 か月間のデータをチェックしました。アダプティブルーティングにより、1時間分のデータを確認できます。この方法では、検出が制限され、データベースまたはビジネス システムが高速化されます。 2つ目はリアルタイムのデータ処理です​​。ここでより重要な機能は、JNS スケジューリング プロセスに基づくマルチレベル展開であり、これを多次元リアルタイム コンピューティングと呼びます。

上記の技術コンポーネントにもクライアントが存在し、すべてのビジネスにはクライアントが必要です。 JD のような規模の企業では、監視や初期化などはすべてネットワーク全体に展開されています。数十万台のマシンがロードされた展開を想像してみてください。すべてのアップグレードやすべての起動に、これら数十万台のマシンの操作が必要になるとしたら、これはまったく想像もできません。もう一つ問題があります。数十万台のマシンのエージェントを保守している場合、環境は複雑で、複数の IP アドレスがあり、発生する問題に対処する方法がありません。単一の次元で処理すると、このことは実行できません。エージェントに関して非常に重要なことの 1 つは、リソースの過負荷です。たとえば、監視エージェントはいくつかの計算を実行し、現在の計算を終了します。ただし、監視はサービス外のものです。現時点では、監視によりサービス自体の安定性に影響が出る可能性がございます。エージェントの役割は、まず第一に、すべてのエージェントの展開とアップグレードを担当することです。 2 つ目は、これらのエージェントの生存を維持することです。電話が切れると、エージェントがどのマシンにいるのか、いつ電話が切れたのか、そして電話を再開するためにどのような操作を行えばよいのかがわかります。 3つ目はリソース制限保護です。 4つ目は段階的なリリースです。その実装についてお話ししましょう。テクノロジーをインストールするときに、エージェントをインストールします。マシンがサービスに入ると、管理エージェントはサーバーに登録し、マシンが現在特定のブランチ ルームにあることと、特定のエージェントのバージョンが何であるかを伝えます。この方法では、サービスに参加すると、どのコンピュータ ルームとサービスに属しているかが自然にわかり、エージェントが期待するバージョンが通知されます。この時点で、彼は当然パッケージをダウンロードし、エージェントは *** のバージョンを認識し、プロセスを実行できるようになります。これは別のクライアント システムです。

これらのクライアント システムまたはコンポーネントを構築すると、展開およびリリース タスクの構築が容易になります。当社のアプリケーション展開システムについて簡単に紹介させていただきます。アプリケーション展開システムは、アプリケーションを展開するだけでなく、一部のサービス保守やリソース管理も実行し、アクセス プロセスも備えています。私たちはいくつかのことを行いました。まず、コンパイルとビルドを行い、次にブラウジングとアクセスを行いました。このエージェントには、クロスプラットフォームである必要があるという中心的な要求があります。 JD.com が直面している環境は比較的複雑です。仮想マシン、Docker、物理マシンがあるため、スケジュールではいわゆる物理マシン、仮想マシン、Docker をサポートする必要があります。 2 つ目は、前述の操作の多くを統合する必要があり、同時にフォールト トレランスを実現できなければならないことです。 1 台または 1 台のマシンが故障してサービス障害が発生することは許可されません。同時に、これらのサービスに問題がある場合は、サービス側が自らそれを発見することになります。さらに、JD.com にとって非常に重要なシナリオは、Double Eleven などのプロモーションです。トラフィックの急増や減少に対応するために、容量を迅速に拡張できます。

JD Cloudの自動運用・保守導入の紹介

デプロイメントには 2 つのタイプがあります。1 つはいわゆる Docker ベースのイメージ出力であり、もう 1 つは従来の物理マシンまたは仮想マシンに基づくパッケージ出力です。コンパイルや構築から、自分で作る製品ライブラリまで、コード パッケージやコード アイテムがあり、構築したばかりのスケジューリング システム上のデプロイメント サービスやデプロイ サービスを通じてリリースされ、物理マシンやコンテナー上で実行できます。展開後は、システムを実行および保守することになります。特に、画像ログを収集・分析する必要があり、ログサービスが提供されています。トラフィックアクセスはフロントエンドで行われ、中間に LB ネットワークが構築されます。最も重要な点は、このデプロイメントが 2 つのタイプに分かれており、サービスのニーズに応じてアップグレードできることです。ここでのすべてのサービスはサービスに基づいています。実際、現在のサービス プロセスやそのプロセスの実装方法については気にする必要はありません。必要なのは、現在何が必要で、その容量はどれくらいか、そしてお客様にどのようなリソースを割り当てているかだけだからです。

JDクラウド自動運用保守監視システム

展開について話した後、監視システムについて話しましょう。監視に関して最も重要なことは誰もが理解しています。先ほどの例では、誰もが緊急に必要としているのは復旧です。いつ復旧するのでしょうか?まず最初にやるべきことは、いつ問題が発生するかを知ること、つまり、できるだけ早く問題を発見できるようにすることです。これは、回復のための非常に重要なステップです。 2 つ目は、問題をすばやく見つけて、その場所を知る方法です。 3 番目のステップでは、事前に準備されたいくつかの計画を自動的にスケジュールしたり、以前に承認されたいくつかのアルゴリズムを自動的に準備したりして、障害の回復を自動的にスケジュールしたり、いくつかの計画を手動ですばやく作成したりできます。彼が直面している環境もおそらく同じだろう。仮想マシンと Docker を必要とする比較的複雑な環境です。最も重要なのは、展開の連携の必要性です。オンラインプロセスでは、段階的にリリースされるものもあり、段階的なリリースプロセス中はサービスを停止することはできません。

実際、これらの失敗自体がイベントです。他の人が意思決定を行うための基礎を提供するために、このイベントをどのように保存し、簡単に照会できるようにするのでしょうか?前のイベントは次のステップに影響し、下流で障害が発生したときに上流に知らせる優れたイベント ライブラリがあるため、監視に非常に役立ちます。次に、オフライン処理を実行してより良いソリューションを取得し、計算とアラームのフィードバックを提供します。

どのようなデータを表示できますか?トレンド チャート、ダッシュボード、またはダッシュボードが必要になる場合があります。これが私たちが勉強する必要があるものです。これらのイベント、アラーム、またはオンライン レポートを外部に表示するためのより優れた方法を持つことも非常に重要です。エージェントからカスタマイズされたログ、外部ログ、および全国の CDN ポイントでの外部ネットワーク検出までのデータを収集します。これらの方法により、上位レベルで多くの監視モードを構築することが決定されます。

これを基に、JD Cloud 監視システムを構築しました。監視は 4 つのレベル、つまり 4 つのタイプに分けられています。1 つ目は基本監視で、CPU、メモリ、ディスクなどを含むマシン レベルと呼んでいます。これは比較的単純で、ユーザーによる構成は必要ありません。データは自動的に収集されます。機械に関しては、機械が良好な状態であれば、サービス監視の問題を解決できます。この解決策はより一般的であり、より頻繁に実行されます。 2つ目は、サービス監視の問題をどのように解決するかです。プロセスやポートの監視、セマンティック監視などの生存監視が必要です。

生存監視の基礎は、サービス レベルが外部で何を実行するかです。当社の 4 つのコア指標は、サービス パフォーマンスや異常を解決し、いわゆる境界問題を特定します。ここでは、パフォーマンス監視はログを通じて解決されます。ブラックボックスと同様に、ユーザー側からサービスを見て問題点を見つけます。ユーザーの視点から見ると、サービスは良いと思うのに、外部的にはサービスのパフォーマンスが良くないことがよくあります。非常に単純な例としては、すべてのサービスインジケーターは正常であるが、Web サイトにアクセスできないというものがあります。これは問題であり、JD.comにとって非常に深刻です。この時点で、トラフィックが減少したり、注文が減少したりしていることに気付くでしょう。これもまた非常に深刻な問題です。つまり、ビジネス観点とユーザーレベルの両方からブラックボックス検出を実行します。テクノロジーによって監視されるマシンの場合、収集から計算、アラーム、マシンの接続まですべてが自動化されます。ユーザーはこれらのものを収集するために何もする必要はありません。これらのアラームはいくつかのデフォルトを提供します。たとえば、マシンの cpu.idle が 10% 未満であることがわかった場合、それがどのサービスに属しているかがわかります。サービスから、誰がそれを保守しているかがわかります。それを維持する者は誰に警告すべきか知っているだろう。その人に警告した後、どのようなデータを収集する必要があるかがわかります。私たちはこのリンクを実行します。オンラインプロセス中に、このマシンのアラームに対してどのような評価を行う必要がありますか?これは技術的な問題です。生存監視では、主に基本ログが生存しているかどうか、および現在の技術的消費量がどうなっているかをチェックします。次に、ポートが正常かどうかを確認します。

パフォーマンス監視に関しては、主にサービスの外部指標に重点を置いています。これらの指標はどこから来るのでしょうか?通常は丸太です。この形式は比較的統一されています。いわゆるログ形式を定義、標準化、または合意します。この時点で、これらの値を分離するのは簡単です。実際、それは多次元です。 JD のトラフィックは安定したプロセスであることがわかりますが、その裏ではより不安定である可能性があります。全体的なトラフィックはバランスが取れているように見えるかもしれませんが、たとえば、特定の期間に山東聯通のトラフィックが正常ではない場合があります。多次元集約を通じて、いわゆる微妙な問題が見つかるかもしれません。この収集方法は、ログからキャプチャするものです。もう 1 つの方法は、それを保持したり、ユーザー自身がそれを公開したりして、何らかの方法でこれらの値を出力することです。

ビジネス監視は、ユーザー側からサービスが正常かどうかを確認します。ユーザー側が最も重要です。全国各地のユーザーが訪問し、オペレーター以外のアクセスや支店のアクセスを検出するシミュレーションを行うことができます。これは、外部ネットワークまたはカスタマイズされた方法を使用して行われます。さまざまな方法を使用して、クラウド操作をシミュレートし、クラウドを監視します。監視クラウド Web サイトにユーザーがログインし、ホストを購入してイメージを展開し、リリースを行うというシミュレーションを行います。これらのプロセスはすべて正常です。監視層が正常であれば、理論的にはユーザーも正常です。ユーザーの視点から見ると、いくつかの問題が発見される可能性があります。ユーザーより先に問題を発見することが重要です。事前に発見できれば、事前に対処することができます。これは失敗ではなく、単なる小さなケースです。

まとめると、私たちはJD.com向けの監視自動化プラットフォームを開発しました。次のステップは、テクノロジーをサービスに変換し、ライフサイクル全体に DevOps を実装することです。特に、当社には多数の SaaS 顧客がいらっしゃるため、効率性の確保、コストの削減、ソリューションの提供、ユーザーの問題解決の支援をお手伝いします。

ありがとう！

————————

上記は、51CTO.com の記者が最前線からお届けする素晴らしいレポートです。今後もさらに興味深い独占レポートをお届けする予定ですので、どうぞお楽しみに。