強制的な技術変革: Ele.me のハイブリッド クラウド アーキテクチャの探求

多くの場合、いわゆるアーキテクチャの進化には先見性があまりなく、そのほとんどは強制的に排除されます。

技術的負債を返済するタイミング、変更するタイミング、トレンドに追随するタイミングについては、多くの企業がビジネスに基づいて判断しますが、私たちはそれを 3 つの段階に分けます。

• 煙
• 小さな火事
• 火

私たちにできることは、スモーク段階で可能な限り技術的な変更を加えることです。小さな火事が発生したときに技術的な改革を行うと、少し手遅れになります。もし大火事になったら、他に選択肢がない状況に追い込まれるようなことになるでしょう。

同じ業界であっても、会社によって多少の違いはあります。私は Meituan についてある程度理解していますが、技術面ではまだ若干の違いがあります。

本日の私のシェアは次の 4 つの部分に分かれています。

• チャレンジ。私たちがこれまで使用してきた TiDB や Office などのソフトウェアなど、一部のテクノロジは普遍的で一般的ですが、私たちは誰に対してもソリューションを販売しているわけではありません。

ヨーロッパとアメリカの友人たちが私のところに来て、そちらのセットをコピーすればうまくいくかどうか尋ねてきました。これは非現実的です。今私たちにとって価値があるのはコードではなく、ビジネスを理解し、ビジネスを運営できる人々の集団なので、私たちと一般的なテクノロジーとの違いはかなり大きいです。

• 建築。どの家庭にも共通する建築の絵があり、どれも似たり寄ったりです。しかし、なぜ 3 年前ではなく今日このような写真になったのでしょうか?なぜなら、ここには多くの実際的な困難があるからです。
• トポロジーとデータ。説明といくつかのデータを含むトポロジが表示されます。実際、データに関しては大変なことがたくさんあり、障害も多々ありました。オンラインビジネスが最も恐れているのはダウンタイムです。
• 現在行われていることと、将来に向けて計画されていること（実行と計画）。ここではちょっとした精神的な探求が進行中で、私たちは現在喫煙段階にあります。

Ele.meの技術的課題

上図のように、時間の経過に伴う注文量の変化を示す曲線チャートです。これがフードデリバリー業界の特徴です。緑色の部分は何らかの異常を示しています。両者の間で変換が行われるため、フロントエンドのトラフィックが大きくなります。

中国でこのような曲線を持つ唯一の電子商取引業界は食品配達業界であり、当社の 2 社 (Ele.me と Meituan) も同様です。

ビジネスにおいて「山を減らし、谷を埋める」というのは非常に難しいことです。なぜなら、私たちはそのような習慣を身につけるために長年努力してきたからです。しかし、技術的な方法を見つけなければなりません。

この図を見ると、自社がクラウド コンピューティングに取り組まなければ、マシンが大量に無駄になると思われるかもしれません。

これは非常に重大な無駄だと言いたいのですが、他に方法はないのです。私が現在行っているキャパシティプランニングはピークに基づいています。

会社のコストも節約したいです。 IT 部門は多額の投資を行っており、会社は予算を削減するつもりはありません。コスト面については今非常に懸念しておりますので、会社側の負担をいかに軽減するかを検討しております。

今日は主に、クラウドとバックエンドの影響、「ピークを減らして谷を埋める」ために何をする必要があるか、そしてハイブリッド クラウドを構築する必要がある理由についてお話します。

プログラマーとして、私が最も気に入っているのはシンプルさです。お金を投じるだけで済むのであれば、大勢の人にそれを任せる必要はないでしょう。しかし現在、ハイブリッド クラウドはますます複雑になっており、スケジューラ間で多くの適応を行う必要があります。

たとえば、YARN は ZStack や Mesos にどのように適応するのでしょうか?私たちは Mesos のヘビーユーザーであり、二次開発を数多く行ってきたため、適応は非常に面倒です。

同時実行性の高さやフラッシュセールの影響はそれほど悪くありませんが、最大の問題はコストです。ユニット操作の効率をどのように向上させるかということです。企業が最後まで戦うとき、生き残るための鍵は、誰がより多くのお金を持っているかではなく、効率性です。すべては効率性を中心に展開しており、この出発点に基づいていくつかのアーキテクチャの変更を加えました。

以前は災害復旧を行っていましたが、これは比較的簡単でしたが、その後はできなくなりました。これは単なる消去法ではありません。これまでに遭遇した落とし穴は、次の選択をする際に役立ちます。

Ele.me のアーキテクチャの進化

5年前にはこの写真はありませんでした。まだ手動での操作とメンテナンスの段階でした。当時はDevOps（ソフトウェア開発（Dev）とソフトウェア運用（Ops）の統合を目指すソフトウェアエンジニアリングの文化と実践）と呼ばれていました。

なぜ？当社のエンジニアはオペレーションを担当しているため、専任のオペレーションチームはありません。 3 年前に入社したとき、チームにフルタイムの DBA (データベース管理) が 1 名とオペレーションが 1 名しかいないことに驚きました。

後になって、それは不可能だと分かったので、人を雇わなければなりませんでした。私が雇った人数はあなたの想像を超えていました。ビジネスロジックを書くために何人かの人を雇いました。ビジネスロジックはインテリジェントにはならず、Liu Qi氏やその同僚のような中国のトッププログラマー3人を雇っても解決する方法はありません。

ビジネス ロジックの状況は、抽象化されているものの、まだ機能していないということです。ビジネスロジックは AI では解決できません。その後、私たちは人材の採用がうまくいっていないこと、取り組んでいたプロジェクトが混乱していること、システムがクラッシュし続けていることに気づきました。

私はPythonについて不満を言っているのではありません。私たちは最近、数億人民元を節約できる大きな計画を立てました。それは、Python から Go に切り替えることです。トラフィックのほとんどは Python によって実行されるため、クラスターの圧力もかなり高くなります。 Go では、およそ 5 で割られます。

今日は IDC (インターネット データ センター) + クラウドについてお話します。当社には独自の IDC があるため、それを廃止することはできないですよね?

機械は 3 年かけて減価償却されますが、毎年少しずつ追加され、大規模な運用および保守チームも存在します。

この時点で、クラウドは再び複雑になりました。私たちは基本的に、中国で 4 つの主要なクラウド プラットフォームをすべて使用してきました。当社はかつて Tencent Cloud と Baidu Cloud の最大のユーザーでした。 Alibaba Cloud はおそらくトップ 3 に入るか、1 位には入っており、次に Qiniu Cloud があります。つまり、当社には 4 つの主要なクラウド プラットフォームがすべて揃っています。

当初は災害復旧をしたいと思っていましたが、災害復旧には大きな問題がありました。実際に災害が発生したときに、あえ​​て切り替えることができないのです。

当時の災害復旧は順調に進んでいませんでした。最大の費用は導入ではなくテストにかかりました。これは、災害復旧には本番トラフィックがなく、検証が難しいためです。

ビジネス ロジックは問題ありません。たとえば、インターフェイスが 1 つ増え、アプリケーションが 1 つ減り、非同期から同期に変更されますが、非常にイライラすることもあります。

これらすべてのことが原因となり、最終的にプロジェクトは中断されました。このプロジェクト（災害復旧）を開始したのも私であり、それを止めたのも私です。これはギャンブルだ。 Google と TiDB が 100% の信頼性を保証することは不可能です。常に一定の確率が存在します。それはほんの数個の9の問題です。

私たちの（マルチアクティブアーキテクチャ）コーディング、展開、テストには合計でわずか 3 か月しかかからず、事前の準備には 9 か月かかりました。多くのチームは、複数のタスクを異なる場所で実行するのは簡単で、3 か月で完了できると考えていますが、実際はそうではありません。

まず第一に、マルチサイトでの活動は技術的な仕事ではありません。ビジネスにそれが必要かどうかを明確に考える必要があります。災害復旧が適切に実施されていなかったため、ビジネス上、これを実行せざるを得ませんでした。災害復旧の実施は確かに難しいと感じています。そのため、ビジネス志向の企業でテクノロジーに取り組むのは非常に面倒です。

ここでグローバルゾーンについてお話ししましょう。取引には注文と配送の 2 種類があります。

ほとんどの取引は 1 つのコンピュータ ルームで完了できますが、避けられないものもあり、グローバル ゾンの使用が必要になります。

Baidu は、「同一都市マルチアクティブ」と呼ばれるマルチアクティブ機能も実装しました。厳密に言えば、マルチアクティブ機能ではありません。 「同じ都市」はグローバルゾーンに似ています。

北京と上海だけで満足であれば、BGP がどこに配置されていても問題ありません。しかし、3 級都市や 4 級都市の 200 の都市をターゲットにしたい場合、それを実現する方法はありません。

私たちはクラウドではなく IDC なので、クラウドがどこにあるかは問題ではありません。弊社のマルチサイト アクティブ アクティブは強制されており、Baidu の「同一都市の疑似マルチサイト アクティブ アクティブ」が大変気に入っています。

Baidu Takeout が使用する Baidu Cloud は広州に 2 つのデータセンターを持ち、レイテンシは約 2 ミリ秒です。マスターがいる場所は 1 か所だけであり、トラフィックは均等に分散されます。トラフィックがマスターの DB と同じ場所にない場合は、同じ都市内の専用回線を通過します。これは、グローバル ゾーンに相当します。

上の写真の通り、これは典型的な南北線ですが、南北線ではありません。交通の流れに応じて分割されます。

上記のように、スケジューラが 4 つあるため、非常に面倒です。 ZStackについてお話しましょう。 Docker がリリースされる前は、基本的にすべてが ZStack、つまり仮想マシン上で行われ、物理マシンに対する特別なスケジュールはありませんでした。

当社では約 20% のノードが Docker でデプロイされており、多くの企業がすでに 100% Docker を採用していますが、現時点ではいくつかの実際的な問題によりそれを実現することはできません。

Docker化もちょっと面倒です。 ElasticSearch などのステートフル サービスなど、一部のクラスターは Docker に移行できません。当社では独自の分散ストレージ システムの開発も開始しており、EMC から人材を引き抜いて開発に携わらせていますが、まだ開発段階にあります。

ビッグデータのTP（トランザクション処理）とAP（分析処理）についてお話します。

私たちの AP は基本的にすべて YARN 上にありました。現在の状況では、なぜ Kubernetes ではないのかと疑問に思うかもしれません。

これも強制でした。当初はKubernetesではなくMesosを使用する予定でした。多くの場合、それはあなたのチームに関係しています。チームは長い間 Mesos を使用しており、ビジネスは比較的安定していますが、Kubernetes は複雑すぎて使い始めるのが困難です。

Google 製品を使用したいので、現在 Kubernetes を使用しています。現在、Spark だけでなく機械学習も備えた機械学習プラットフォームが存在します。しかし、特に Python と Tenserflow に慣れている学生はまだいます。現在、私たちは elearn (Kubernetes 上の自社開発 AI) を使用しています。

TP に Kubernetes をデプロイしていないことに、誰もが驚くかもしれません。 TP では主に Mesos と ZStack を使用します。

このとき、クラウドはさらに厄介です。現在、Ele.me は主に Alibaba Cloud をベースにしており、Baidu Takeout は主に Baidu Cloud をベースにしています。

Baidu Cloud にも非常に厄介な問題がいくつかあります。数日前に彼らと話をしましたが、それもとても辛かったです。私たちのチームは物理マシンの使用を主張しました。 Tencent Cloud を利用していた当時、私たちはすでに独自の物理マシンを持っていたので、それを Tencent Cloud のコンピューター ルームに移動しました。

しかし現在、Alibaba Cloud では独自のマシンを移行することができません。どうすればいいですか？今年の Yunqi カンファレンスで言及され、私たちはそれを最初に使用した企業の 1 つでした。物理マシンの使用を主張する必要があります。そうしないと、IO 集約型のタスクはまったく実行されません。

RDS (リレーショナル データベース サービス) も試しましたが、テスト目的のみでした。当社のすべてのプログラマーと QA (品質保証) は、RDS を使用して Alibaba Cloud 上の環境を使用しています。

もちろん、もう 1 つの重要な理由があります。それは、RDS が高価すぎるということです。再開発された Mesos をクラウド上に展開します。

Ele.me アーキテクチャ トポロジとビッグデータ

上の写真にあるように、黄色いボックスは基本的に IDC やクラウドなどのコンピューター ルームです。最も厄介なのは北京と上海です。

上海の新しいデータセンターが稼働する前は、ビッグデータ用の AP と TP が混在して展開されていましたが、この混在展開は分離されており、1 つのノードに実際に混在してはいませんでした。

これらは、Alibaba Cloud East China と Alibaba Cloud North China です。 Tencent Cloudはほぼ完成しました。専用回線もいくつかあり、支払い方法は2種類（WeChatとAlipay）あります。

当初、この2つの支払いは専用回線を使用していませんでしたが、後に公衆回線の使用が耐えられないことが判明しました。ピーク時には、わずかな揺れでも耐えられず、1 秒間に 10,000 件の注文が失われることもあり得ます。

支払い段階で顧客を失うことが最も大きな損害となります。最初にアプリを開くことができない場合は、それを承認します。しかし、すべての手続きを経ても結局支払いが失敗してしまうと、非常に面倒なことになります。

専用回線が多数あり、各回線はループになっています。広州の百度では、百度クラウドは大規模な IDC アーキテクチャではなく、完全なシステムです。上海の 2 つのコンピューター室を接続するには 2 本の専用回線が必要であり、それぞれがループになっているため、非常に複雑です。

社内で最大の頭痛の種となっているのは IDC ではなく、さまざまな専用回線です。非常に複雑だからです。オフィス内にも POP ポイントが必要です。

そんなに複雑にしたくありません。北京のIDCを廃止すれば十分だと言う人もいるかもしれないが、それはそれほど単純ではない。なぜなら、異なる場所であっても同じ都市であっても、複数のことを行うことが前提となっているからです。

現在、北京チームと上海チームには合計約 25,000 個のノードがあります。 Docker 率は 20% 未満であり、特にミドルウェアに関してはできないことも多く、Docker を使用するのは費用対効果が良くないため、50%~60% を目標としています。

私たちはビッグデータの分野ですべてのTPアプリケーションを排除することを決意しました。しかし現在、コンピューター ルームは主にビッグ データに基づいているにもかかわらず、同じ都市で AP と TP を統合する必要があることがわかりました。これらは非常に困難な状況で分離され、現在では再び統合されなければなりません。

ビッグデータ コンピュータ ルームにかかるプレッシャーは現在かなり高くなっています。弊社のビジネスは120TB増加しました。ビッグデータに加えて、当社には約 400 TB に及ぶ独自のシステム ログとトレースも存在します。毎日3PBのデータを処理する必要があり、合計ストレージは12PBと非常に大きなデータ量です。

現在のシステム、特に一般的なソフトウェアの供給元では、いかなる問題も発生せず、停止することもできません。

この顧客がフラッシュセールをしているか、通常のビジネスを行っているかに関係なく、彼は間違いなくそれに耐えることができないだろう。自社事業のみのサービスですので、損失は若干小さくなります。

しかし、Qiniu CloudやTiDBなどの公共施設の場合、一時停止するとすべてのユーザーに迷惑がかかるため、私たちは比較的プレッシャーを感じていません。

私たちのビジネスでは、1日350回リリースするしかありません。今は新規事業も多く、一日に何回もリリースしているので、それ以上になるかもしれません。

私たちのビッグデータは非常に高価です。最も高価な 3 つのクラスターは、MySQL、Hadoop+Spark、Redis です。

Redis を使用すると、コストを節約できる余地がまだたくさんあります。経済的/効率的な観点から言えば、これをそこに置いておくのは無駄です。

ビッグデータのバックアップもあり、ビッグデータは私たちの生命線です。ウェブサイトが 1 日ダウンした場合、謝罪するだけで、アクセスするはずだったユーザーは翌日にまたアクセスするでしょう。

しかし、ビッグデータに問題が発生すると、第一に、データが非公開であること、第二に、データが失われたり乱れたりすることになり、さらに厄介なことになります。

毎日大量のバックアップを作成していましたが、後になってこれらのバックアップが冷たすぎることが判明しました。費用対効果は高いですか?賭けることはできませんが、コストが大きすぎます。ハイブリッド クラウド アーキテクチャは私に強制されたもので、私が望んでいたものではありませんでした。

Ele.me の現状と今後の計画

ハイブリッドクラウドアーキテクチャ

マルチアクティブ展開の難しさは、主に異なる場所でのマルチアクティブ展開にあります。同じ都市内での疑似マルチアクティブ展開は比較的簡単で、これがグローバル ゾーン アプローチです。しかし、実際の同じ都市でのマルチアクティブ展開は、異なる場所での展開と同様であり、主な問題はレイテンシです。

MySQL レベル、Zookeeper レベル、Reids レベルを含む DRC (データ レプリケーション センター) を自分で構築する必要があります。

サービスを使用する場合、主にレイテンシと一貫性の理由で、IDC 間をまたがることを望みますが、これら 2 つの問題を調整するのは困難です。

Go言語と同様に、トレンドであるクラウドネイティブもあります。煙が出始めたら始めます。時代を先取りしすぎないでください。結局のところ、まずはビジネスを構築しなければなりません。

しかし、小さな火事になるとさらに危険です。小さな火事のときも借金返済に努めました。借金を返済するのは比較的容易でした。小さな火事になると、消火に人力に頼るほうが面倒です。

クラウドは間違いなく検討されます。ハイブリッドクラウドは流行っているように聞こえますが、慎重に進めていきます。これは、RDS などの運用保守チームにとっても課題となります。

当社の内部データベースも、MySQL や MongoDB など多岐にわたります。コマンドラインの入力やスクリプトの作成に慣れている運用および保守担当者をプログラマーに変え、社内ではこれを OpsDev と呼んでいます。これは DevOps よりもはるかに困難です。社内の全員がプログラマーであることを願っていますが、これはかなりの難題です。

当社のサーバーレスシステムはオンラインシステムですが、比較的シンプルです。次に、SMS プッシュとモバイル プッシュを検討します。この場合は、Redis をセットアップしてオンにするだけで、直接送信できるためです。

当社にとって、クラウド インフラストラクチャを完全に使用しない限り、サーバーレスは複雑なビジネスには実現可能ではありません。

より多くのアクティビティが完了した後、より柔軟になり、必要なだけトラフィックを削減できるため、自動スケーリングを実装する予定です。

取引の 95% は同じゾーン内で完了します。これを行わなければ、Alibaba Cloud を拡張することはできません。 Alibaba Cloud では Auto Scaling を実行できるようになりましたが、コストが非常に高くなります。

一般的に、クラウド コンピューティングのコストは IDC よりも高いので、ピーク トラフィックに対処するために 4 時間プルアップしてからプルダウンすることは費用対効果が高いでしょうか。

いくつか計算してみたところ、必ずしもそうではないことがわかりました。ピークシェービングとバレーフィリングが効果的に行われると、Auto Scaling によるコスト削減効果は薄れてしまいます。

私たちはSina Weiboとは違います。突然の出来事を予測することはできないので、要求に応じて行動することしかできません。谷間には大きな差がありますが、それは予測可能です。

数日前、チームから「爆弾」が投げかけられました。現在、マシンの稼働率が非常に低いのです。私たちは Docker を使用しており、1 つのことを行っています。それは、過剰販売です。

売られ過ぎとは何ですか?以前は 1 つのコアを 1 つのコアとして使用していましたが、現在は 1 つのコアを 2 つのコアとして使用しています。後でそれが悪くないことが分かりました。 Docker を使っている人は、何の変化も感じません。

過剰販売を続け、1 つのコアを 3 つのコアとして使用しました。ピーク値に基づいて計算したところ、通常のピーク使用率はそれほど高くないことがわかりました。

コロケーションを試す

自動スケーリングを実行するかどうか、またはビジネスのピークを平滑化し谷を埋めるかどうかに関係なく、コロケーションを実行する必要があります。

コロケーションに関しては、Baidu の方が早くからスタートしました。彼らは数年前にシステムを構築しました。目的はコロケーションを実現することではなく、この機能を実現するための良い副作用を生み出すことでした。

ビジネス自体に戻ると、共同配置は実際には非常に困難です。彼らと話したとき、私は、検索のようなビジネスでは、各グリッドが独自に計算して収束するグリッド コンピューティングを採用できると言いました。

スワップ（データ交換）が大量にありますが、機械学習やスワップなどの機能を Spark に実行させると、10G ネットワーク カードでもすぐに帯域幅がいっぱいになってしまいます。

今日の機械学習は、分割して征服できる検索やクローラー技術とは異なります。これを分散型と呼び、スワップが大量に発生します。また、各ノードで独立して計算でき、大量のスワップを必要としないタスクを配置しようとしています。

コロケーションはどのような問題を解決しますか?当社のビジネスはピーク時が非常に忙しく、谷間時にはこれらのマシンはアイドル状態になります。それで、それらを使用していくつかのジョブを実行できますか?

このジョブは TP を参照しません。 TP にもいくつかのジョブがありますが、CPU をあまり消費しません。これは費用対効果が良くありません。ただ遊ぶためだけにテクノロジーで遊ぶことはできません。多数のシナリオを解決する必要があります。

特に機械学習のプレッシャーが比較的高い現在では、考えられるのは Hadoop と Spark です。でも、雑談するのは難しいです。まず、私たちは別々の場所にいることはできませんし、次に、同じ都市にいる場合も困難です。

非常に厄介な課題もあります。それは、当社のビッグデータ チームが使用するモデルがカスタマイズされており、チームのメンバーはこのモデル テンプレートに慣れているということです。

TP テンプレートは数多くあり、数百から数十に減りましたが、API、ビジネス ロジック、Redis などを含めると、まだ数は多いです。ビッグデータや機械学習のタスクをさまざまなマシンモデルにどのように適応させるかが問題です。

私たちの業界ではプロモーションが頻繁に行われます。イベント中に雲がかかっても、費用はかかります。したがって、イベント中はビッグデータタスクを凍結して、大規模なプロモーションのためにマシンリソースを解放することができます。

ほとんどのタスクでは、3 ～ 4 時間の遅延は許容されます。両者は協力して、まずリソースの分離とスケジューラの問題を解決します。 YARN では TP をスケジュールするのが難しく、Mesos や Kubernetes でも​​ AP をスケジュールするのは困難です。

私たちが研究している問題は、YARN、Mesos、ZStack をどのように適応させるかということであり、これはまだ解決されていません。

コロケーションの問題は長い間存在していましたが、私にとっては経済的プレッシャーはそれほど大きくなく、怒り狂うほどではありません。 Ele.me が将来 Ele.me Cloud を提供しても驚かないでください。

パブリッククラウドを構築するわけではありませんが、PaaS（Platform-as-a-Service）とSaaS（Software-as-a-Service）の中間に位置する物流クラウドを検討しています。

現在、Ele.me 以外からの配送も多数あり、Double 11 の配送もお手伝いしています。 1人で1品を配達し、短時間で配達できる「フラッシュデリバリー」というサービスもありますが、料金は比較的高めです。

荷物を直接配達する人たちは、たいていは電気自動車のバイクに乗っているのを見ました。多くの場合、ビジネスが発展するにつれて、そのような問題の解決に役立ちます。