中国のEコマース最大手アリババは最近、1日で30億ドル相当の商品を販売した。InfoQはTmallとTaobaoのアーキテクトであるZhuang Zhuoran氏とYoutan氏に、負荷対策の難しさと対処方法について話を聞いた。
中国最大のB2CのEコマースサイトであるTmallとC2CオンラインショッピングプラットフォームであるTaobaoはアリババグループの傘下であり、合わせて5億人以上のユーザが登録している。今年のTaobaoの“Double Sticks Promotion”は4年連続の開催になり、総流通総額は191億人民元(おおよそ30億ドル)に達し、1億4700万人のユーザが訪問した。
"中国規模"のEコマースサイトを運営する難しさについて、
2012年11月11日(Double Sticks Promotionの当日)、TmallとTaobaoには1億4700万人のユーザが訪れ、3000万人が買い物をし、1億の支払いが発生しました。0:00には、1000万人のユーザが同時にオンラインにいました。技術チームはいくつかの大きな困難に直面しました。Double Sticksのさまざまな機能的要請を満たすにはどうすればいいか、準備段階でシステムに対する完璧で正確な評価をするにはどうしたらいいか、効率的に最適化を実装する方法、デザスタリカバリの計画、緊急事態時の正しい意思決定方法、高負荷状態での安定性、性能、ユーザエクスペリエンスを保証する方法などです。
Tmallの取引システムの処理のピークは最初の1時間に来ました。システムが秒間13,000の処理要求を正常に処理できたときです。システムのピークは40,000 QPSで平均応答時間は200ミリ秒でした。Tmallの商品詳細ページには16億の訪問があり、ピーク時のスループットは秒当たり69,000訪問でしたが、応答時間は12ミリ秒を保つことができました。ページビューは5億9000万まで上がり、ピーク時のスループットは14,000訪問/秒に達しました。
Zhuang氏の説明では、アプリケーションレベルでは、TmallとTaobaoは自前で開発したサービス指向のアーキテクチャで実装されており、MVCフレームワークとSpringと共に利用されている。アプリケーションは分散ファイルシステム、分散キャッシング、メッセージングミドルウエア、CDNネットワーク帯域幅に支えられている。中心となるデータベースは独自開発したデータアクセスミドルウエア経由でアクセスされる。データベースを水平分割とデータ転送の仕組みはアプリケーションからは完全に透過的だ。
拡張性のあるシステムで構築されているTmallとTaobaoは柔軟にマシンを追加してプロモーション活動によって発生するトラフィックの圧力に対処できる。
キャパシティを計算するのに多くの時間を費やします。ウェブサイトを構成するアプリケーション間の依存関係やトラフィックの分散具合、アプリケーションの呼び出し関係を深く分析して、初期段階でさまざまなマシンで負荷テストを行い、QPSを正確に評価します。こうすることでクラスタの処理能力を客観的に判断することができます。しかし、この作業はとても難しいのです。というのは、TmallとTaobaoは本質的には弱く結合しているシステムではなく、単一のシステムに対する負荷テストではシステムのボトルネックは特定できないからです。負荷テストのための環境を構築するために本番の環境と構成をそのまま完全にコピーすることはできませんが、システムの欠点をあぶりだすために負荷テストはもっと活用されるべきです。
最後にサイトの自然成長と過去のDouble Sticksのデータに基づいて予想される販売ターゲットを推定します。そして、その推定から各システムをどのくらい拡張すればいいか正確に計算します。
単に水平方向に拡張すると販売のピークを過ぎたらマシンの利用が減ってしまい、運用で柔軟に確保できるキャパシティへの依存が増大します。メンテナンスを行う個人に対しても依存してしまいます。それゆえ、今年はcloud.tmall.comのようなアプリケーションには伸縮自在なコンピューティングフレームワークを利用しようとしました。これで異なるアプリケーションの異なる商店がひとつのクラスタのシステムリソースを共有します。2012年11月11日の帯域幅やVM、ストレージリソースは柔軟に拡張しました。多くの内部アプリケーションにも同様の仕組みを適用しましたが、これが準備期間での技術的なブレークスルーになったのです。
TaobaoとTmallのチームはキャッシュヒット率、SQL、データベースのコネクション、アプリケーションサーバのパラメータ、JVMのパラメータの最適化を行い、コードレビューとインスペクションを実施した。さらに、さらに、大量のソリッドステートドライブ(SSD)を使ってデータベースストレージ全体の性能を向上させた。
また、負荷が想定内に収まらない場合を考えて、重要でないシステムの運用を停止するために、ビジネス上のダウングレードとトラフィック制限の計画を建てた。
ビジネス上のダウングレードとは、重要な機能を安定的に動かすために重要でない機能を制限することです。このダウングレードをきれいに行うために、私たちは機能を比較的独立している単位に別けて、優先順位を基に分離し、バックグラウンドで制御することで、重要でない機能をダウングレードしなければなりません。こうすることで、システムの依存性を下げ、性能の劣化を防ぎ、クラスタ全体のスループットを向上させます。
ダウングレードが不十分な場合、トラフィック全体を制限する必要があります。まず、フロントエンドでウェブアプリケーションをキューイングして、アプリに対するトラフィックを制御します。具体的には、ウェブサーバのカスタムモジュールを使い、QPSの制限機能を有効にして、ウェブサーバが耐えられる負荷の最大値に基づいてQPSを制御します。この制限が行われるとユーザには「お待ちくださいページ」が表示されます。また、フロントエンドのウェブアプリへのトラフィックの急増で、バックエンドサービスへ処理できないくらいのトラフィックが流れ込まないようにするために、バックエンドサービスの重要ではない処理のトラフィックを制限します。こうすることで、異なる経路から負荷がかかることでバックエンドサービスがつぶれてしまわないようにして、重要な処理へのアクセスを保証します。
TmallとTaobaoで、2012年のDouble Sticks Promotion向けに、合計で400以上のシステムダウングレード計画を作成しました。
ダウングレードと帯域制限を失敗することなく実施するため、何度か練習をしました。このような緊急の計画を発動する必要がなければいいのですが、計画を正しく実施できることを確認する必要があります。
緊急事態での意思決定プロセスについては、
11月11日は400人以上のエンジニアが発生する事態にスムーズに対応するために働いていました。すぐに意思決定できるようにするため、顧客からのフィードバックを収集し整理し、重複したフィードバックや無意味なフィードバックを除外する部隊を現場に作りました。技術チームへ行く情報に重複がないようにするためです。
さらに、現場に本部を置いていましたが、緊急事態の意思決定の責任は現場の開発エンジニアに持たせました。すべてのエンジニアの役割と責任は明確に定義されています。各アプリケーションには1人から2人のオーナを割り当て、オーナがシステムの各指標に基づいて意思決定を行うことで、緊急事態にタイムリーに対応します。緊急事態の意思決定は、ビジネスに大きな影響を与える場合とユーザエクスペリエンスに大きなダメージを与える場合のみ、本部に上申されます。
TaobaoとTmallはオープンソース戦略を効果的に利用している。code.taobao.orgでは多くのソースコードが公開されている。リモート通信フレームワークであるHSF、メッセージングミドルウエアのNotify、データアクセスミドルウエアのTDDLなどが公開されている。