タオバオの技術開発：分散時代のサービス指向

システム開発のプロセスでは、アーキテクトのビジョンが重要です。プログラマーであれば機能を実装するだけでよいのですが、アーキテクトであれば、システムの拡張性や再利用性を考慮する必要があります。この鋭い感覚は、一種のコードクリーンさであると考える人もいます。タオバオの初期の頃、何人かの建築家がこのように感じていました。 Yizhi が開発した Webx は拡張性の高いフレームワークです。Xingdian は、このフレームワークにデータベース配布ルーティング モジュール、セッション フレームワークなどを挿入しました。 Taobao バックエンド システムで作業する際には、これらのモジュールも必要でした。Xingdian は、これらのモジュールを jar パッケージに個別にパッケージ化するように指示してくれました。また、タオバオの航空券や宝くじのシステムを開発していたとき、ページには再利用する必要のあるものがたくさんありました。最も直感的なものはヘッダーとフッターでした。最初は各システムにコピーをコピーしていましたが、不思議なことに、その間にフッターを頻繁に修正する必要がありました。たとえば、「Yahoo China」を「Yahoo China」に変更し、しばらくして「口コミ」を追加し、さらにしばらくして「Yahoo 口コミ」になり、最終的に「Yahoo China」になりました。各システムを修正する必要があり、非常に面倒でした。その後、Velocity テンプレートのこの部分を取り出して、パブリック モジュールにしました。

上記はすべて比較的小さな再利用可能なモジュールです。2006 年に、製品カテゴリ属性を変換し、カテゴリに属性の概念を導入しました。このプロジェクトのコードネームは「泰山」です。その名前が示すように、これは非常に重要なプロジェクトであり、この変更は画期的なイノベーションです。これまでの 3 年間、商品の分類は各レベルのツリー状のノードに基づいていました。商品の数が増えるにつれて、カテゴリはより深く複雑になりました。つまり、購入者は商品を見つけるために各カテゴリ レベルをクリックする必要があり、商品を探す前に商品の分類を理解する必要がありました。タオバオ運営部のカテゴリー担当のウェイターも、深刻な問題を発見しました。例えば、紳士服の中にTシャツがあり、その下にはナイキがあり、純綿のナイキがあります。婦人服の中にもTシャツがあり、その下にはナイキがあり、それでも純綿のナイキがあります。では、まず紳士服と婦人服を分け、次にスタイル、次にブランド、最後に素材で分けるべきでしょうか？それとも、まずブランド、次にスタイル、次に素材、最後に紳士服と婦人服を分けるべきでしょうか？私は気絶してしまいました。このとき、一人の英雄が現れました。それは、イデングです。彼によると、ブランド、スタイル、素材などは「属性」と呼べるそうです。属性はタグに似た概念で、カテゴリと比較すると、より離散的で柔軟性が高く、カテゴリの深さも減ります。このアイデアの提案により、分類の問題が一挙に解決されました。システムの観点から、「属性」と呼ばれるデータ構造を確立しました。カテゴリの子ノードが属性を持つだけでなく、親ノードも属性を持つことができるため、カテゴリ属性も構造化されたデータ オブジェクトになります。これが完了したら、これを catserver (カテゴリ サーバー) と呼ばれるサービスとして分離しました。カテゴリ属性と密接な関係のある商品検索機能は分離され、hesper（Venus）と呼ばれます。Catserverとhesperは、Taobaoのフロントエンドとバックエンドシステムによって呼び出されます。

タオバオの商品カテゴリ属性は現在、世界最大です。タオバオで見つからない商品カテゴリはほとんどありません（禁止されているものを除く）。ただし、カテゴリ属性の初期変換後、特にデジタル製品については、属性データが非常に不足しています。では、このデータはどこから入手したのでしょうか? 私たちは中関村オンラインと協力して、大量のデータを入手しました。当時、多くの商品属性情報の後ろには「中関村オンラインから」と記されていました。カテゴリー属性は、運用を大幅に容易にします。Taobao の運用は主にカテゴリー運用であることがわかっています。どの季節にどの商品を宣伝するかは、購入者が商品を見つけやすくするためにカテゴリー属性を調整する必要があります。例えば、夏には、婦人服の第一階層のカテゴリで、素材がレースか純綿かをユーザーにマークしてもらいたいのですが、冬には、ダウンジャケットを婦人服の第一階層のカテゴリに移動させたいと思います。人気のあるものは何でも、商品を上位の階層のカテゴリに移動します。このように、カテゴリと属性は頻繁に調整する必要があり、カテゴリが調整されるたびに、そのカテゴリの商品の販売者は自分の商品を編集しなければならないという問題が発生します。商品の数が増えるにつれて、販売者の作業負荷が大きくなり、販売者が耐えられなくなることがわかります。 2008年までに、私たちはスーパーマーケットのフロントエンドとバックエンドの商品の分類を研究し、スーパーマーケットのフロントエンド商品の陳列シーンは季節や連想（ビールとおむつの有名な連想など）に応じて調整できるのに対し、バックエンドの倉庫は自然なカテゴリに従って保管する必要があることを発見しました。この2つは密接に関連していますが、互いに分離しています。次に、フロントエンドとバックエンドのカテゴリを分離し、販売者が商品を公開する際に自然なカテゴリと属性を選択できるようにしました。また、Taobao のフロントエンドでは、運用上のニーズに応じて整理された商品のカテゴリと属性が表示されます。変換されたカテゴリ属性は forest という名前になります (これはカテゴリ属性に多少似ています。Catserver は引き続き存在し、販売者の承認、ブランド サービス、キーワード、およびその他の関連サービスを提供します)。カテゴリー属性のサービス指向性は、Taobao のシステムサービス指向性における最初の探求です。

一部のアーキテクトはコードのクリーンさにこだわっていますが、Taobao のフロントエンド システムのビジネス量とコード量は急速に増加しています。ビジネス側からは常に催促があり、開発者が足りないときはどんどん人を採用します。採用した人たちは、もともとのビジネスをまったく理解していないので、手探りで「適切なコード」を「適切な場所」に追加して、動くかどうか確認し、ネットに公開するしかありません。このような悪循環に陥ると、システムはどんどん肥大化し、業務の結合度はどんどん高まり、開発効率はどんどん低下していきます。当時の流行語を借りると、「コードを書いてコンパイルすると、30 分が経過しますが、コンパイルに失敗すると半日が経過します。」 この場合、システムエラーの可能性は徐々に高まります。 多くの場合、製品に関連するコードの一部を変更して、トランザクションに問題があることがわかります。 フォーラムでコードの一部を変更しただけで、Wangwang に問題が発生することもあります。これにより、開発者は惨めな思いをし、ビジネス側も開発者の作業がどんどん遅くなっていると考えます。

2007 年末頃、シリコンバレーの上級幹部である孔文師匠が R&D 部門に派遣されました。孔文は優しい長老です。彼は、すべては安定を中心に据えるべきであり、システムの安定性に影響を与えるすべての要因を解決しなければならないと私たちに語りました。たとえば、ルーチンの変更が行われるたびに、システム全体を回帰テストする必要があります。1 つのバージョンに複数のルーチンの変更が含まれている場合、1 つの機能がテストに失敗すると、システム全体をリリースすることはできません。これを「列車モデル」と呼んでいますが、乗客が乗車するまで列車は出発できません。その最も直接的な結果は、電車がいつも遅れ、新機能のリリースがさらに遅くなることです。ビジネス側の不満ははっきりと感じられ、孔文は大きなプレッシャーを感じているに違いありません。当時、私は、安定性のために開発のスピードを犠牲にするこの画一的なアプローチを理解できませんでした。これは、ある政党の「安定性がすべてに優先する」という考え方とどう違うのでしょうか?

しかし、今振り返ってみると、私たちはその背後にある考え方を実際には理解していませんでした。この要件の下で、回帰テストを毎日のルーチンにしたり、システム全体の回帰を毎晩実行したりするなど、いくつかの変更を開始する必要がありました。さらに、この要件の下では、この非常に複雑なシステムを解体して再構築する必要がありました。最も再利用可能なモジュールであるユーザー情報モジュールが分割され始めました。私たちはそれをUIC（ユーザー情報センター）と呼びました。 UIC では、getUserById、getUserByName などの最も基本的なユーザー情報操作のみを処理します。

一方、システムの基本機能の分割を必要とする新たなビジネスが 2 つあります。当時、私たちはタオバオ旅行（trip.taobao.com）とタオバオ宝くじ（caipiao.taobao.com）という2つの新しい事業を立ち上げました。この2つの新しい事業は、商品の表示や取引プロセスの面でメインサイトの事業とは異なっていました。航空券はフライト情報に応じて表示され、宝くじは2色のボール、数字、サッカーのスケジュールに応じて表示されました。しかし、使用しているメンバーシップ機能やトランザクション機能はメインサイトと似ています。やっているときにとても葛藤しました。メインサイトでやると、メインサイトとは関係のないものがほとんどになってしまう。ゼロからやると、重複する部分が多くなってしまう。最終的に、メインサイトに余分なものを追加しないことに決め、ゼロから始めて 2 つの新しいビジネス システムを構築しました。製品の問い合わせから、製品の購入、評価とフィードバックの提供、注文の確認までのプロセス全体が書き直されました。現在、「My Taobao」の取引記録を確認すると、航空券と宝くじが「購入商品」に別々にリストされており、通常の注文には追加されていないことがわかります。メンバーシップ、トランザクション、製品、評価の各モジュールが当時分離されていたら、すべてをやり直す必要はなかったでしょう。

2008年初頭にはメインサイトシステム全体（航空券や抽選システムが追加された後、元のシステムはメインサイトと呼ばれていました）の容量がボトルネックになり、商品数は1億を超え、PVは2億5000万を超え、会員数は5000万人を超えました。現時点では、Oracle 接続プールの数が足りず、データベース容量が限界に達しており、上位システムはマシンを追加することで拡張し続けることができません。基盤となる基本サービスを分割し、下から容量を拡張し続けることしかできません。そうして初めて、上位層を拡張して、今後 3 ～ 5 年間の成長に対応できるようになります。

そこでその年、私たちはより大きなプロジェクトを立ち上げ、取引のコアビジネスモジュールを分割しました。元々の Taobao 取引は、商品管理と連動していただけでなく、Alipay と Taobao の間を行き来し、Alipay と連動していました。システムが複雑で、ユーザー エクスペリエンスが悪かったのです。トランザクションの基盤業務を分離し、トレーディングセンター TC (トレードセンター) と呼びます。基盤業務とは、注文の作成、在庫の削減、注文ステータスの変更などのアトミック操作であり、トランザクションの上位レベルの業務はトランザクション管理 TM (トレードマネージャー) と呼ばれます。たとえば、通常の商品を入札する場合は、注文、在庫、物流を操作する必要がありますが、仮想商品を入札する場合は、物流を操作する必要はありません。これらは TM で完結します。このプロジェクトには、「千島湖」という非常に創造性に欠ける名前が付けられました。開発者は、開発が完了したら千島湖を観光する目的でこの名前を選びました。その後、彼らの願いは叶いました。当時、タオバオモールという別のプロジェクトが開発中でした。以前に分割されていた基本サービスは、モールの急速な建設のための良い基盤を提供しました。

カテゴリ属性、ユーザーセンター、トランザクションセンター、これらのモジュールが徐々に分割され、サービスに変換されるにつれて、システムアーキテクチャに関する多くの経験も蓄積されてきました。 2008 年末までに、私たちは Taobao のすべてのビジネスをモジュール化するという、より大規模なプロジェクトに着手しました。これは、2004 年の LAMP アーキテクチャから Java アーキテクチャへの移行に続く 2 度目の大きな変革でした。このプロジェクトには、「五色石」（女媧が天を修復するために使用した石）という非常に威圧的な名前が付けられています。このシステムを再構築する作業は非常にスリリングなもので、「高速航空機のエンジンを交換する」と評する人もいました。

五彩石プロジェクトが発表された後、エンジニアたちは数日間三亜へ行きました。彼らは Taobao システムを次のアーキテクチャに分割しました。

前述のように、UIC と Forest はそれぞれ TC、IC、SC です。これらのセンターレベルのサービスは、ID による製品検索、トランザクションの作成、在庫の削減などのアトミックレベルのビジネス ロジックのみを提供します。次のレベルは、ビジネスシステム TM (Trade Manager 取引ビジネス)、IM (Item Manager 商品ビジネス)、SM (Shop Manager、響きが悪いので後に SS: Shop System に改名、店舗ビジネス)、Detail (商品詳細) です。

分割後、次の図に示すように、システム間の相互作用は非常に複雑になります。

このようにシステムを分割すると、メリットは明らかです。分割後は、各システムを個別に展開できるため、業務がシンプルになり、拡張が便利になります。再利用可能なモジュールが多数あるため、新規業務の開発が容易になります。また、専任の人材と専任のタスクを配置できるため、技術者が特定の分野にさらに集中できるようになります。解決すべき問題も明らかです。分割後も、システムは相互にやり取りする必要があります。システムのレベルが低いほど、それを呼び出すクライアントの数が多くなります。このため、基盤となるシステムは超大容量と非常に高い可用性を備えている必要があります。さらに、分割されたシステムはどのように通信するのでしょうか。ここでは 2 つのミドルウェア システムが必要です。1 つはリアルタイム呼び出しミドルウェア (Taobao の HSF、High Performance Service Framework) で、もう 1 つは非同期メッセージ通知ミドルウェア (Taobao の Notice) です。解決する必要があるもう 1 つの問題は、ユーザーがシステム A にログインした場合、システム B に移動するときにユーザーのログイン情報がどのように保存されるかということです。これもまた、セッション フレームワークに関係します。さらに、ソフトウェア エンジニアリングの問題として、非常に多くのレイヤーを持つシステムをどのようにテストするかという問題があります。

タオバオの技術開発レビュー（VI）：Java時代：技術の創造 - Tair

タオバオの技術発展レビュー（V）Java時代：堅固な岩のように

タオバオの技術発展レビュー（IV）：Java時代の復活

タオバオの技術開発レビュー（第3部）：Oracle/Alipay/Wangwang

タオバオの技術発展レビュー（I）：「独身の日」のカーニバル

タオバオの技術発展の回顧（II）：個人ウェブサイト時代[推し絵]

原題: 淘宝網の技術開発: 分散時代のサービス指向

キーワード: 淘宝網、技術開発、展開時間、サービス、システム開発、プロセス、建築家、ビジョン、重要性、ウェブマスター、ウェブサイト、ウェブサイトのプロモーション、収益化