メルカリが Cloud Profiler でリクエスト レイテンシを 15% 短縮した方法
Google Cloud Japan Team
※この投稿は米国時間 2020 年 11 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。
編集者注: 小売業者にとって、消費者の欲求と需要を予測することは至上の目標と言えます。小売業 IT の目標は、e コマース アプリケーションのパフォーマンスを把握することです。この記事では、日本のオンライン小売業者である Mercari, Inc. が、Cloud Profiler と Trace を使用して、Google Cloud で実行されている複雑なマイクロサービスベースのアプリケーションを理解し、商品需要の変化の中でも厳格な SLO 遵守を達成した事例についてご紹介します。
この 2020 年に起こった出来事は、e コマースを加速させ、オンライン マーケットプレイスの需要とトラフィックを増加させました。アナリストである eMarketer は、2020 年の米国における小売総売上高が全体で 10.5% 減少するのとは対照的に、e コマース売上高は 18% の成長を遂げると予測しています。同様に、私達が所属する企業、日本に本社を置く消費者向けマーケットプレイスである Mercari, Inc. も、急速に成長しています。米国だけでも、月間平均利用者数は前年比 74% 増の 340 万人となっています。当社の成功の大きな要因は、強固な決済 / 入金システムと AI を利用した不正監視システムです。これによって売り手は購入アイテムを出品し、買い手は安全に取引を完了できます。
メルカリはモノリシック アプリケーションとしてスタートしましたが、複雑さが増すにつれ、マイクロサービス アーキテクチャに移行することにしました。そして、移行の過程全体を通じて、Cloud Profiler や Cloud Trace などのツールがコード内のパフォーマンスの問題を追跡するのに役立ち、レイテンシを大幅に改善することができました。
マイクロサービスのメナジェリー
現在、当社では Go、Python、JavaScript、Java などの言語を組み合わせて 80 以上のマイクロサービスを Google Cloud で運用しています。この新しいアーキテクチャを実現するために、間もなく移行予定のモノリシック サービスから Google Cloud のマイクロサービスにトラフィックを転送するための、ゲートウェイ的なマイクロサービスを作成し、さまざまな機能を提供しました。
いくつかのマイクロサービスを作成した後、共通の要件を特定し、開発を加速させるためのテンプレートを作成しました。これらの共通要件には以下が含まれます。
Prometheus への指標のエクスポート
gRPC サーバーとインターセプタ
Error Reporting、Cloud Trace、Cloud Profiler。Error Reporting は、実行中のクラウド サービスのクラッシュをカウント、分析、集計します。Cloud Trace はマイクロサービス内でやり取りされるリクエストのビューを提供し、Cloud Profiler はマイクロサービスの CPU、メモリ、スレッドの消費状況を示します。
その後、当社は Python を使って機械学習サービスのテンプレートを作成し、新しいマイクロサービスの作成も迅速化しました。これにより、新たな要件に対応するために使用するマイクロサービスの数を増やすことができました。しかし、マイクロサービスの数が増えるにつれ、それぞれのパフォーマンスを効率的にモニタリングし、把握する必要がありました。
SLO を維持するという課題
特に、99.95% のリクエスト成功率およびリクエストの 95% で 350 ミリ秒以内のレイテンシを維持できるよう、新しいバージョンが本番環境に与える影響と本番環境の運用の効率性をモニタリングする必要がありました。
また、当社のエンジニアリング チームは、カナリア デプロイを使用して、主要なサービスの新しいバージョンの問題を検出しています。しかしながら、これらの施策を実施したにもかかわらず、事業が予想を上回るスピードで成長を遂げた場合や、予想外の需要の急増時には、SLO を維持することが非常に困難であることを実感しました。問題によっては、明らかなものもあれば、簡単に検出できるものもあります。たとえば、あるサービスで高い CPU 使用率が発生している場合は、水平 Pod オートスケーラー（HPA）の配置や微調整で問題を解決できます。しかし、他の問題はそれほど明白ではない場合があります。たとえば、パフォーマンスの低下は、特定のリリースに直接結びついているわけではなく、予期せぬリクエストが原因であったり、1 つのコードリリースで複数の関数に加えられた変更が原因であったりします。
Cloud Profiler と Cloud Trace を使用してパフォーマンスの問題を最小限に抑える
特に、ユーザーがメッセージに返信するスピードや、売り手がどれだけ早く確実に商品を発送するかを追跡する、当社のビジネスに不可欠な UserStats サービスのパフォーマンスが最近になって低下し始めました。
新たな機能要件により、売り手が注文をキャンセルする頻度を追跡し、統計情報を提供することを求められました。しかし、この新機能を追加したものの、この変更により他の関数がリファクタリングされたため、パフォーマンスが低下している関数を特定できませんでした。当社のサービスのほとんどが Cloud Profiler と Cloud Trace で有効になっているため、これらのプロダクトに目を向け、根本原因の調査と特定を行いました。
変更前:
変更後:
これら 2 つの Cloud Profiler ビューは、コールスタックの CPU 時間が 457 ミリ秒から 904 ミリ秒に増加しており、デルタの大部分は _UserStats_SellerCancelStats_Handler 関数に起因していることを示しています。しかし、他の関数でも CPU 消費量にばらつきがあったり、呼び出しが並行して発生したりすることがあるため、レイテンシ増加の原因を特定することが難しいことがわかりました。この関数呼び出しが必要であったという事実は、関数全体を削除することができないことを意味していました。
Cloud Trace を確認したところ、以下のように一部のリクエストで関数呼び出しが全体的なレイテンシを増加させていることがわかりました。
Cloud Profiler でサービスを分析し、CPU 消費時間の増加の要因となっているホットスポットを特定しました。これらのホットスポットとなっていた関数を最適化し、新しいコードをデプロイした後、Cloud Profiler を使用してこの変更が CPU 時間の短縮に望ましい効果をもたらすことを検証しました。こうすることで、レイテンシを 10%～15% 改善することができました。
DevOps エクスペリエンスの簡素化
Cloud Profiler を採用する以前は、デバッグフラグを使用した再コンパイル、本番環境へのデプロイ、プロファイルを収集して分析を実行するための異なるツールの使用など、本番サービスのプロファイリングは手作業で行う煩雑な仕事でした。コンテナ化はこの複雑性を高めるだけで、開発者の生産性をさらに低下させました。
Cloud Profiler を使用することで、小規模な簡単なコード変更で本番環境を継続的にプロファイリングすることができ、パフォーマンス解析のための環境設定に必要だった従来の面倒な作業は不要になります。Cloud Profiler を使用したオーバーヘッドが少ない継続的なプロファイリングにより、問題の根本原因を突き止め、問題を迅速に解決することで、サービス パフォーマンスの変化に迅速に対応できます。
さらに、Cloud Trace や Cloud Profiler などのツールは、セットアップに必要な労力が最小限に抑えられており、サービス オーナーに一貫した DevOps エクスペリエンスを提供します。これは、米国やその他の国での成長を期待するうえで特に重要となります。Google Cloud がなければ、言語、テクノロジー スタック、フレームワーク、コンテナが混在する本番環境でのモニタリング、デバッグ、プロファイリングは、非常に困難で時間のかかる作業になってしまいます。Cloud Profiler などのツールの新機能やエクスペリエンスがリリースされ、Google Cloud を当社のプライマリ クラウド プラットフォームとして選択できたことを嬉しく思います。今後も新機能を活用し、Google Cloud にフィードバックを提供することで、Google Cloud のユーザーへのより良いサービスの継続的な提供に貢献していきたいと思います。
Cloud Profiler と Cloud Trace について詳しくは、Google Cloud ウェブサイトをご覧ください。
- Mercari, Inc. ソフトウェア エンジニア（マイクロサービス プラットフォーム）Bill Chung 氏
- Mercari, Inc.ソフトウェア エンジニア（マイクロサービス プラットフォーム）Sho Ogihara 氏
