本記事では、アリババの大規模データセンターのパフォーマンス監視・分析の課題と実践を紹介します。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
独身の日、ショッピングフェスティバル
アリババの代表的なデータクランチイベントは、毎年中国の独身者の日を記念してプラットフォーム全体でセールを行う「11.11グローバルショッピングフェスティバル」です。
下図は2017年時点のデータを使用しています。イベントの規模がわかるように、左上のグラフは売上高の数字を示しています：約253億米ドルで、これは同年のアメリカの感謝祭、ブラックフライデー、サイバーマンデーを合わせた売上高を上回っています。
技術専門家は右のグラフをより重視します。2017年、アリババのクラウドプラットフォームでは、1秒間に325,000件のトランザクションと256,000件の支払いというピークボリュームを可能にしました。
このような高いピークパフォーマンスは、アリババにとって何を意味するのでしょうか？それはコストを意味します! パフォーマンスにこだわる理由は、絶え間ない技術革新によってパフォーマンスを継続的に向上させながら、コスト削減を目指しているからです。
アリババのインフラ
上記のピーク時のパフォーマンスの数字の裏には、それを支える大規模なソフトウェアとハードウェアのインフラがあります。
上図のように、アリババのインフラには、電子商取引アプリの淘宝（タオバオ）やTmall、物流ネットワークのCainiao、ビジネスメッセージングアプリのDingTalk、決済プラットフォームのAlipay、Alibaba Cloudなど、最上位層に多様なアプリケーションが存在しています。このようなビジネスシナリオの多様性は、アリババ経済の特徴です。
最下層には、数百万台のマシンに接続された大規模なデータセンターがあります。
中間層は、アリババでは「イネーブル・プラットフォーム」と呼んでいます。上位層のアプリケーションに最も近いものは、データベース、ストレージ、ミドルウェア、コンピューティング・プラットフォームです。その間には、リソーススケジューリング、クラスタ管理、コンテナがあります。最下層には、オペレーティングシステム、JVM、仮想化などのシステムソフトウェアがあります。
パフォーマンス分析
ベンチマークテストは、パフォーマンスを測定するためのシンプルで再現性の高い方法が必要なために有用です。しかし、ベンチマークテストには限界があります。なぜなら、各テストはハードウェアとソフトウェアの設定とともに、独自に定義された動作環境に左右されるからです。これらの設定は、パフォーマンスに大きな影響を与える可能性があります。さらに、ハードウェアとソフトウェアの構成が実際にビジネス要件を満たしているかどうか、ひいては代表的な結果が得られるかどうかという問題もあります。
ベンチマークテストで観察された効果は、実際の複雑な本番環境にまで拡大することができますか？
アリババのデータセンターには何万ものビジネスアプリケーションがあり、何百万ものサーバーが世界中に分散しています。そのため、データセンターでソフトウェアやハードウェアのアップグレードを検討する際には、小規模なベンチマーク・テストで観察された効果が、データセンター内の複雑な本番環境に実際に適用できるかどうかが重要な問題となります。
例えば、異なるJavaアプリケーションではJVM機能が異なるパフォーマンスに影響を与え、異なるハードウェアでは同じアプリケーションのパフォーマンスが異なる結果を観測することがあります。このようなケースは、決して珍しいことではありません。すべてのアプリケーションやハードウェアごとにテストを実行することは不可能なので、さまざまなアプリケーションやハードウェアに対する新機能の全体的なパフォーマンスの影響を推定するための体系的なアプローチが必要です。
データセンターでは、ソフトウェアやハードウェアのアップグレードによる全体的なパフォーマンスへの影響を評価することが重要です。当社の11.11グローバル・ショッピング・フェスティバルを例に考えてみましょう。私たちは、売上と取引のピーク時のビジネス指標を非常に注意深く監視しています。しかし、ビジネス指標が2倍になったらどうなるでしょうか？それは、すべてのマシンの台数を2倍にしなければならないということでしょうか？その答えを出すためには、技術力を評価しつつ、技術がビジネスに与える影響を示す評価手段が必要です。これまで多くの技術革新を提案し、パフォーマンスの最適化の機会を多く見つけてきましたが、ビジネス価値も実証しなければなりません。
SPEEDプラットフォーム
上記のような問題点を解決するために、システム性能推定・評価・決定（SPEED）プラットフォームを開発しました。
まず第一に、SPEEDはデータセンターで現在何が起きているかを推定します。グローバルな監視を通じてデータを収集し、そのデータを分析して、最適化の可能性を検出します。
次に、SPEEDは、本番環境でのソフトウェアやハードウェアのアップグレードについて、オンラインで評価を行います。例えば、新しいハードウェア製品を導入する前に、ハードウェアベンダーは通常、性能向上を示す独自の性能テストを実施します。しかし、性能向上はベンダーのテストシナリオに特有のものです。私たちが知る必要があるのは、そのハードウェアが私たちの特定のユースケースにどれだけ適しているかということです。
これは、答えを出すのは簡単ではありません。明白な理由から、ユーザーはハードウェア・ベンダーに自分のビジネス環境でのパフォーマンスをテストさせることはできません。その代わり、新しいハードウェアのカナリーリリースをユーザー自身で行う必要があります。もちろん、カナリーリリースの規模が大きければ大きいほど、評価はより正確になりますが、本番環境はビジネスに直接関係するため、最初のうちはあまり大規模にすることはできません。リスクを最小限に抑えるために、ユーザーは通常、一握りのマシンから数十台のマシンの間でカナリアリリースを行い、その後、徐々に数百台、数千台へとスケールアップしていきます。
したがって、SPEEDの重要な貢献は、小規模なカナリアリリースであっても、合理的な推定値が得られることで、コストを節約し、長期的にはリスクを軽減することができます。カナリーリリースの規模が大きくなるにつれて、SPEEDはパフォーマンス分析の質を向上させ続け、ユーザーが重要な意思決定を行う際の手助けとなります。
意思決定の目的は、与えられたハードウェアやソフトウェアのアップグレードを実施するかどうかを決定することだけでなく、ソフトウェアとハードウェアのスタックのパフォーマンスの性質を総合的に理解することです。対象とするアプリケーションのシナリオにどのようなハードウェアとソフトウェアのアーキテクチャがより適しているかを理解することで、ソフトウェアとハードウェアのカスタマイズの方向性を検討することができるようになります。
パフォーマンス・メトリクスを理解することは容易でない
データセンターでよく使われているパフォーマンス指標の一つに、CPUの利用率があります。しかし、これを考えてみてください。データセンター内のマシン1台あたりの平均CPU使用率が50%で、アプリケーションの需要がもはや増加しておらず、ソフトウェアの断片がお互いに干渉しないと仮定した場合、データセンター内の既存のマシンの数を半分にすることができるでしょうか？おそらく無理でしょう。
多数の異なるワークロードと大量のハードウェアが存在するため、データセンターにおける包括的なパフォーマンス分析の主要な課題は、異なるワークロードとハードウェアのパフォーマンスをまとめるための全体的なパフォーマンス指標を見出すことです。私たちの知る限りでは、現在のところ統一された基準はありません。SPEEDでは、私たちは、単位作業あたりのリソース利用率を測定するために、Resource Usage Effectiveness (RUE)と呼ばれる指標を提案しました。
ここで、Resource Usageとは、CPU、メモリ、ストレージ、ネットワークなどのリソース使用率のことであり、Work Doneとは、電子商取引アプリケーションのクエリやビッグデータ処理のタスクのことです。
RUEの考え方は、パフォーマンスを多面的に総合的に評価する方法を提供しています。例えば、ビジネス側から「あるマシン上のアプリケーションの応答速度が速くなった」と言われたら、技術側も「確かにシステムの負荷やCPUの使用率が上がっている」と考察します。このような場合、当然の反応としては、新機能のせいで障害が発生したのではないかと心配になります。しかし、より良い対応として、クエリ毎秒のスループット指標（QPS）も見てみると良いでしょう。もし QPS が増加しているのであれば、新機能のリリース後、より多くの作業を完了するためにより多くのリソースが使用されているという事実を指し示しているかもしれません。
このように、パフォーマンスは多面的に総合的に測定する必要があります。そうでなければ、不合理な結論が導き出され、パフォーマンスの最適化のための真の機会を逃すことになりかねません。
収集したデータが必ずしも正しいとは限らない
パフォーマンス分析にはデータの収集が必要ですが、収集したデータが正しいことをどうやって知るのでしょうか？
インテルの技術であるハイパースレッディングの例を考えてみましょう。最近のノートPCは一般的にデュアルコア、つまり2つのハードウェアコアを持っています。ハイパースレッディングを有効にすると、デュアルコアのマシンは4つのハードウェアスレッド（論理CPU）を持つマシンになります。
下の図では、上のグラフは、ハードウェアコアが2つあり、ハイパースレッディングが無効になっているマシンを示しています。両方のコアのCPUリソースを使い切っているので、タスクマネージャはマシンの平均CPU使用率が100%であることを報告しています。
左下隅のグラフは、同じく2つのハードウェアコアを持つが、ハイパースレッディングが有効になっているマシンを示しています。各物理コアのハードウェアスレッドのうち1つを使い切っているため、マシンの平均CPU使用率は50%となっています。一方、右下のグラフは、同じく2つのハードウェアコアを持つマシンで、ハイパースレッディングが有効になっており、1つのコア上の2つのハードウェアスレッドが使い切られていることを示しています。つまり、このマシンの平均CPU利用率も50%となっています。
ここに問題があります。実際には、左下のグラフに示されているCPU使用率と右下のグラフに示されているCPU使用率は全く異なるが、マシン全体の平均的なCPU使用率だけを集めれば、全く同じであることが分かります。
このように、性能データの分析を行う際には、データの処理やアルゴリズムだけを考えている余裕はありません。データがどのように収集されているかも考慮しなければなりません。
異種ハードウェア
ハードウェアの異質性は、データセンターにおける性能解析の大きな課題となっていますが、同時に性能最適化の方向性を示すものでもあります。
例えば下の図では、左のBroadwellアーキテクチャは、ここ数年のIntelサーバーCPUの主流アーキテクチャを表しています。
2つのアーキテクチャには大きな違いがあります。たとえば、Broadwellでは、メモリアクセスは長年使われてきたデュアルリングモードで行われるのに対し、Skylakeではメモリアクセス方式がメッシュモードに変更されています。さらに、SkylakeではL2キャッシュが4倍に拡張されています。
これらの違いにはそれぞれ長所と短所があります。これらの違いが全体のパフォーマンスに与える影響を測定し、コストを考慮してデータセンターのサーバをSkylakeにアップグレードするかどうかを検討する必要があります。
ハードウェアの違いは、ハードウェア上で実行されるすべてのアプリケーションに影響を与えるため、ハードウェアの違いを理解することが重要です。使用するハードウェアは、カスタマイズや最適化の方向性に大きく影響します。
複雑なソフトウェアアーキテクチャ
現代のインターネットサービスのソフトウェアアーキテクチャは非常に複雑で、アリババのeコマースアーキテクチャがその代表例です。このような複雑なソフトウェアアーキテクチャは、データセンターでのパフォーマンス分析にも大きな課題を投げかけています。
簡単な例を挙げると、下の図の右側がクーポンアプリケーション、左上が大規模なプロモーションの会場用アプリケーション、左下がショッピングカートアプリケーションです。これらはEコマースにおける典型的なビジネスシナリオです。
Java開発の観点から見ると、それぞれのビジネスシナリオはアプリケーションです。eコマースの顧客は、プロモーション会場からクーポンを選択するか、ショッピングカートからクーポンを選択するか、好みに応じて選択することができます。ソフトウェアアーキテクチャの観点から見ると、会場とショッピングカートは2つの主要なアプリケーションであり、それぞれがクーポンアプリケーションのためのポータルです。ポータルごとにクーポンアプリケーションの呼び出し経路が異なり、それぞれがパフォーマンスに与える影響が異なります。
そのため、クーポン・アプリケーションの全体的なパフォーマンスを分析する際には、eコマース・アーキテクチャ全体の様々な複雑なアプリケーション関連付けと呼び出しパスを考慮する必要があります。このような多様なビジネスシナリオや複雑な呼び出しパスは、ベンチマークテストで完全に再現することが難しく、本番環境でパフォーマンス評価を行う必要があります。
シンプソンのパラドックス：注意事項
下の図は、実データ解析でよく知られているシンプソンのパラドックスを示しています。
前述の例の続きとして、図に示すアプリがクーポンアプリであるとします。プロモーション中に新機能Sが登場し、カナリア解放に使用されているマシンが全体の1%を占めているとします。RUEメトリクスによると、機能Sは8%のパフォーマンスを向上させます。しかし、ここでは、クーポンアプリケーションには3つの異なるグループがあり、グループは上で議論したように、異なるポータルを持つアプリケーションに関連しているので、各グループの観点からは、機能はアプリケーションのパフォーマンスを低下させます。
同じデータセットと同じ評価基準で、全体的な集計分析によって得られる結果は、各部分の個別分析によって得られる結果と正反対の結果となります。これがシンプソンのパラドックスです。
全体の評価結果を見ることもあれば、構成要素ごとの結果を見ることもあるということを意識しなければなりません。この例では、それぞれのグループを見て、機能Sは実際には性能を低下させ、さらなる修正と最適化が必要だと結論付けるのが正しいアプローチです。
シンプソンのパラドックスは、パフォーマンス分析において、さまざまな潜在的な落とし穴に注意を払うことが不可欠である理由を思い出させてくれます。思慮に欠けたメトリクスや代表的でないデータに基づいた意思決定や、ハードウェアやソフトウェアのアーキテクチャを考慮に入れない意思決定は、ビジネスにとって非常に大きなコストになる可能性があります。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ