クロスユースプラットフォーム～ 秒間10万リクエスト・レスポンスタイム100ms以下を実現するシステム について ～ / YJTC19 in Shibuya A-4 #yjtc

クロスユースプラットフォーム ~秒間10万リクエスト・レスポンスタイム100ms以下 を実現するシステムについて~ コマースカンパニー 事業推進室 コマースマーケティング本部 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 大島 圭貴

大島 圭貴 コマースカンパニー事業推進室 2012年度入社 8年目 知恵袋・ショッピングなどのサービスの開発 クロスユースプラットフォームは開発初期から参画 現在は開発業務のかたわら、ディレクションも行う Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

アジェンダ 1. クロスユースプラットフォーム 2. システム構成 3. スループットとレイテンシー 4. 四つの課題とその対策 5. まとめ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

アジェンダ 1. クロスユースプラットフォーム 2. システム構成 3. スループットとレイテンシー 4. 四つの課題とその対策 5. まとめ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

クロスユースプラットフォーム ヤフーのサービスと言えば？ クロスユースプラットフォーム、入ってます Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

クロスユースプラットフォーム クロスユースプラットフォーム（クロスユースPF） ユーザーにヤフーのコンテンツを紹介するためのプラットフォーム COUPON CAMPAIGN POINT CONTENT ヤフーをもっと知って・便利に使っていただくことが目的 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

クロスユースプラットフォーム もう一つの共通点 セ ク ア 数 ス 多 が ！ い クロスユースPFを利用しているページ全体で最大 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 100,000 アクセス/s

クロスユースプラットフォーム 他にもこんな要件が HURRY UP! ヤフーとしてユーザーを 「おまたせしない」ための要件 100ms 以内 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. ページ クロスユースPF

クロスユースプラットフォーム ここまでのまとめ クロスユース プラットフォームとは どこで使われているのか どんな要件があるのか Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. ユーザーにヤフーのコンテンツを 紹介するためのプラットフォーム 主要なヤフーページ 100,000 リクエスト/s レスポンスタイム 100ms

アジェンダ 1. クロスユースプラットフォーム 2. システム構成 3. スループットとレイテンシー 4. 四つの課題とその対策 5. まとめ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

システム構成 クロスユースプラットフォームのアーキテクチャ クロスユースプラットフォーム（XPF） Cassandraノード サーバーアプリ Cassandraノード Cassandraノード サーバーアプリ サーバーアプリ インターネット 読 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 書 ⁝ 配信管理ツール 書 ⁝ 全社PaaS基盤 (Pivotal Cloud Foundry) ページID ルール コンテンツ 専用Cassandra クラスタ ユーザ属性データ

システム構成 データの関係性 ユーザー属性 コンテンツ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. ルール … ルール ページID

システム構成 データ構造（ユーザー属性） ユーザー情報とヤフービックデータをもとにしてユーザー属性データを生成 ユーザーID 00X2SA2 00X2SA2 00X2SA3 00X2SA3 ⁝ ユーザー情報 ユーザー属性 ヤフービックデータ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 属性キー isPrem haveCoupon isPrem haveCoupon ⁝ 値 1 1 0 0 ⁝

システム構成 データ構造（ページID・ルール・コンテンツ） ページIDごとに、ユーザ属性に応じてコンテンツを選択するルールを定義 ルール コンテンツ ログインユーザー？ ユーザー属性 No コンテンツA Yes ユーザ属性A？ No Yes ページID ユーザ属性B？ Yes ⁝ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. コンテンツB No コンテンツC ⁝

アジェンダ 1. クロスユースプラットフォーム 2. システム構成 3. スループットとレイテンシー 4. 四つの課題とその対策 5. まとめ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

スループットとレイテンシー 要件の移り変わり（スループット） 実際のリクエスト数 スループット要件 100,000rps 33倍 3,000rps (開発β) サービス開始(2年前) Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 現在

スループットとレイテンシー スケーラビリティ PaaSクラスタとアプリ数(インスタンス数)でスケーリング ノード数でスケーリング Cassandraノード サーバーアプリ サーバーアプリ サーバーアプリ ⁝ ⁝ クラスタ Cassandraノード ⁝ サーバーアプリ Cassandraノード ⁝ クラスタ PaaS Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. Cassandra

スループットとレイテンシー スケーリングの移り変わり サーバーアプリ(クラスタ1) サーバーアプリ(クラスタ3) Cassandra(クラスタ1) キャパシティ要件 サーバーアプリ(クラスタ2) サーバーアプリ(クラスタ4) Cassandra(クラスタ2) 実際のリクエスト数 2クラスタ 計200ノード サーバーアプリ 4クラスタ 計80インスタンス 17倍 40倍 1クラスタ 計2インスタンス 1クラスタ 計12ノード (開発β) サービス開始(2年前) Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 現在

スループットとレイテンシー 要件の移り変わり（レイテンシー） 実際のレイテンシー レイテンシー要件 第一の課題 200ms 第二の課題 第三の課題 (開発β) サービス開始(2年前) Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 50% 第四の課題 100ms 現在

アジェンダ 1. クロスユースプラットフォーム 2. システム構成 3. キャパシティとレイテンシー 4. 四つの課題とその対策 5. まとめ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

四つの課題とその対策 第一の課題 実際のレイテンシー レイテンシー要件 200ms 第一の課題 サービス開始時のレイテンシー要件を 満たすため 50% 100ms (開発β) サービス開始(2年前) Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 現在

四つの課題とその対策 第一の課題（原因） 原因 複数のデータを個別に取得しており、ボトルネックとなっていた ルール ページID ボトル ネック 複数回 必要 複数 必要 サーバーアプリ コンテンツ Cassandra Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

四つの課題とその対策 第一の課題（対策） 対策 ルールとそれに紐づくコンテンツを1つのデータに結合して保持し、 一回でデータを取得 クロスユースPF サーバーアプリ ルール結合 データ 一回で 取得 ページID ルールに紐付く コンテンツ Cassandra Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. ルールと コンテンツを 一つのレコード に保持

四つの課題とその対策 第二の課題 実際のレイテンシー レイテンシー要件 200ms 第二の課題 50% 100ms要件への対応 100ms (開発β) サービス開始(2年前) Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 現在

四つの課題とその対策 第二の課題（原因・対策） ルール結合データのデータサイズが大きく、 原因 Cassandraからの取得に時間がかかっていた 対策 XPFサーバー内でルール結合データをキャッシュ ※以下の要件を踏まえてキャッシュの持ち方とリフレッシュに工夫が必要 ページID ルール 1 2 3 1つのページIDに複数ルールが紐づく Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 各ルールが有効期限（開始/終了）を持つ

四つの課題とその対策 第二の課題（対策・キャッシュ方式） 初期キャッシュ仕様 クロスユースPFサーバーアプリ ルール解析 エンジン キャッシュコントローラ Key ページ1 キャッシュ レコード ページ1 ページ2 ⁝ 定期的に 更新 Value ルール1 ルール2 ルール3 ルール4 ⁝ • キャッシュ更新時間 以内の「未来のルール」 を含む • 一つでも有効期間が 終了した場合 レコード全体を無効化 有効期間 切れの場合 即時更新 • 「未来のルール」を含むため、データ取出し時に都度フィルタリングが必要 • 毎日24時に複数ルールの有効期間切れが重なり、スパイク的な負荷上昇が発生 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

四つの課題とその対策 第二の課題（対策・キャッシュ方式） 現行キャッシュ仕様 クロスユースPFサーバーアプリ ルール解析 エンジン キャッシュコントローラ L 1 L1キャッシュレコード ページ1 ルール1 ルール2 L2キャッシュレコード ページ1 L 2 ページ1 ルール1 ルール2 ルール3 フィルタリング が不要に • 現在有効なルールのみを保持 • 一つでも有効期間が終了した場合または L2キャッシュ内の次の「未来のルール」 が有効になる場合キャッシュが更新される 現在有効な ルールだけを L1に格納 • 定期時間内の「未来のルール」を含む • 有効期間が終了したルールのみ レコードのスライスから消去 スパイク 負荷上昇を回避 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 定期的に 更新

四つの課題とその対策 第三の課題 実際のレイテンシー レイテンシー要件 200ms 第三の課題 50% リクエストは増えていないのに 運用が進むにつれてレイテンシー悪化 (開発β) サービス開始(2年前) Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 100ms 現在

四つの課題とその対策 第三の課題（原因） 原因 運用の中でルールが複雑化 ルールが肥大化 データ取得・解析時間が悪化 ルール ログインユーザー？ ユーザ属性A？ ユーザ属性B？ ユーザ属性D？ ユーザ属性E？ ユーザ属性C？ ユーザ属性F？ ⁝ ⁝ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. ユーザ属性G？ ⁝ どんどん 肥大化

四つの課題とその対策 第三の課題（対策） ユーザーをクラスタリングすることで複数属性を一つの属性で表現 対策 （クラスタリングは自動で実施） ルール ルール ログインユーザー？ ユーザ属性A？ Yes Yes ユーザ属性B？ Yes A ログインユーザー？ B ¬C ユーザ属性C？ No ユーザ属性D？ Yes ？ D なユーザー ってどんな人？ を属性化 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. ユーザクラスタA Yes ？

四つの課題とその対策 第四の課題 実際のレイテンシー レイテンシー要件 200ms 50% 100ms 第四の課題 リクエスト増（ページ増）にともない レイテンシー悪化 (開発β) サービス開始(2年前) Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 現在

四つの課題とその対策 第四の課題（原因） 原因 CassandraのPartition KeyをページIDとしていたが ページIDごとに、データ数・サイズに偏りがあったため、 特定のCassandraノードにRead負荷が集中していた ページA データ数：多 データサイズ：大 ページB データ数：多 データサイズ：小 ページC データ数：少 データサイズ：小 A B Cassandraによる データ配置 （レプリケーション: 3） C Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. A,B Cassandraノード B,C Cassandraノード B,C Cassandraノード A,C A B 高負荷 Cassandraノード 高負荷 Cassandraノード 高負荷 Cassandraノード ⁝ x200 Cassandra

四つの課題とその対策 第四の課題（対策） 対策 ランダムIDをルールに付与しつつ複製し、 ページIDと合わせて複合Partition Keyとする 20個に コピー A A A random̲id=0 最大60ノードに データ配置 random̲id=1 ⁝x20 A ランダム ID 付与 random̲id=19 Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved. 80インスタンス A0,A1 Cassandraノード A3,A19 Cassandraノード A1,A2 Cassandraノード A5,A8 Cassandraノード A7,A11 Cassandraノード A12,A18 Cassandraノード ⁝ x200 Cassandra 読 サーバーアプリ random̲idを、都度 ランダム付与して読込 ページID:A アクセス 負荷が分散される

四つの課題とその対策 四つの課題から得た学び 1. データストアへのアクセス回数は出来るだけ少なくする 2. 使用頻度の高いデータは効率的にキャッシュする 3. データが肥大化したときは、スケーリングする前に、 工夫で小さくできないか考える 4. データストアの特性を理解してデータ構造を作る （特にNoSQLは注意が必要） Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

アジェンダ 1. クロスユースプラットフォーム 2. システム構成 3. キャパシティとレイテンシー 4. 4つの課題とその対策 5. まとめ Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

まとめ 全体のまとめ クロスユースプラットフォーム 秒間10万リクエスト・レスポンスタイム100ms以下を実現 スループットとレイテンシーを両立する上で重要な要素 • インフラからデータストアまで全体がスケーリングする仕組み • データストアとシステムの特性を考慮した設計 • 環境の変化とシステムの劣化を継続的に確認し、 打ち手を考え続けること Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.

Copyright© 2019 Yahoo Japan Corporation. All Rights Reserved.