SRE_20220312_TrackB_Recruit

2022/3/12 開催 6社合同SRE勉強会におけるリクルートの小林および甲谷による講演資料になります。

Transcript

1. 株式会社リクルート SRE部 小林直樹 / 甲谷 悠 2022年3月12日 歴史あるサービスでのリクエストの増加に向き合うSRE (C) Recruit Co., Ltd. All rights reserved.
2. 2 アジェンダ • リクルート/SRE 紹介 • 住まいのSRE活動 • 旅行・飲食・ビューティーのSRE活動
3. 3 リクルートSRE 紹介
4. 4 (株)リクルート 創立 従業員数 メディア＆ソリューション事業 売上収益 目指す世界観 果たす役割 1960年3月31日 「大手新聞広告社」としてスタート 15,807人 (2021年4月1日現在 / アルバイト・パート含) 6,720億円 (2020年4月1日～2021年3月31日） Follow Your Heart まだ、ここにない、出会い。 より速く、シンプルに、もっと近くに。 引用元：https://recruit-holdings.com/ja/about/profile/
5. 5 リクルートホールディングス 引用元：https://speakerdeck.com/recruitengineers/aws-conference?slide=5
6. 6 リクルートの主要事業 選択・意思決定を支援する情報サービスを提供し 「まだ、ここにない、出会い。より速く、シンプルに、もっと近くに。」を実現する 引用元：https://speakerdeck.com/recruitengineers/aws-conference?slide=5
7. 7 リクルートのビジネスモデル 個人ユーザと企業クライアントが出会う場を作り出し、より多くの最適なマッチングを実現 引用元：https://recruit-holdings.com/ja/about/business/
8. 8 SRE部 リクルートSREのなかで、SRE部が担うのは商用インフラに関わるSRE業務 インフラソリューションユニット SRE部 ITSM部 DP部
9. 9 SRE部 SRE部 縦と横 SRE部には縦軸と横軸のSRE機能が存在します。今日は縦軸SREのお話。 事業領域A 事業領域B 事業領域C 横断プラットフォームサービス 安定運用の提供と継続的な改善 事業領域A SRE 事業領域B SRE 事業領域C SRE 担当領域(縦軸)でのサービスの安定提供に向けた継続的な改善
10. 10 今日お話しすること 生まれ淘汰され続けてきた歴史の中で、長年その存在を保ってきた古参サービス。 このサービスの信頼性を維持し、新たな可能性を広げるためにSREがやってきたこと。 攻めと守りを組み合わせながら取り組んできた歴史の一部をご紹介します。
11. 11 住まい 住まいのSRE活動
12. 12 自己紹介 小林直樹 株式会社リクルート インフラソリューションユニット SRE部 住まい領域SREグループ グループマネージャー ▪ 経歴 ▪ 2003～ SIer リクルートWebサービス支援 ▪ 2016～ 飲食、スポーツ業界 EC/APPサービス開発推進 ▪ 2020～ リクルート入社 ▪ 2021～ 住まい領域SREグループ GM着任 ▪ 趣味 ▪ トレイルランニング、言語習得（喋るほう）
13. 13 住まい事業の歴史 1976 「住宅情報」首都圏版創刊 1996 住宅情報 On The Net 2009 SUUMOブランド統一 2010 SUUMO SPサイト SUUMOスマホアプリ • 日本の住環境向上を目指して「住宅情報」月刊紙を創刊。業界に先駆け、ネットサービス展開。 • 複数の住まいサービスを集約し、『SUUMOブランド』として統一。 • ネットサービスの変遷とともに歩み続け、そして四半世紀。
14. 14 住まいビジネスモデル • SUUMOのユーザは、住宅や賃貸物件を探す個人（カスタマー）と、工務店や賃貸事業者などの住宅関連 事業者（クライアント）。 • 広告課金と成果課金モデルの組み合わせ。 • クライアント提供情報を正しく確実にカスタマへ提供し、反響（資料請求、訪問予約など）を獲得する ことが最大目的。
15. 15 住まいの開発機能・体制 ものづくり ビジネス検討 / 要件定義 / 設計 / PG / テスト サービス運用 モニタリング / 障害対応 / 資源計画 / 運用改善・・ 分析～ビジネス戦略立案 企画 エンジニアリング 戦略 サービスマネジメント （SRE） • 住まい事業におけるSREは、サービスマネジメントの一機能としての役割。 • その責務は機会毀損回避。
16. 16 システム構成 みなさんに見えてるところ ※ごく一部 • 改廃を繰り返した結果、関連システムは社内だけで約130。 • 個々のシステム特性に合わせ、プラットフォームはオンプレとパブリッククラウドのハイブリッド。 • 外部脅威からシステムを守るには独自の工夫が不可欠。 • 安定運用と毀損回避を実現するために、SREが注力すること。
17. 17 今日お伝えしたいこと 機会毀損を防ぐためSREが重視すること モニタリング環境整備とアクションのサイクル 解くべき課題にフォーカス 今日はコチラ
18. 18 モニタリング環境整備とアクションのサイクル データの可視化と定期分析 予測と制御 • ビジネス視点でモニタリング項目を定義（リソースから反響、掲載物件数まで） • ヒートマップやグラフを利用し、常時10以上の指標を分析 • モニタリングチームの定期分析を通じて短期課題や傾向課題を明確化 • 【傾向対策】独自分析モデルからピーク時期とアクセス数を予測、適正なリソースを事前に確保 • 【突発対策】アクセス急増や不正アクセスに対し独自フィルタリングを設置し自動制御
19. 19 モニタリング環境整備とアクション -事例①【傾向対策】- ①賃貸領域 常態的アクセスピークへの対応 • 『SUUMO』全体PVの50%を占める賃貸領域。繁忙期1月はアクセス数前月比30%up。 • モニタリングデータとアクセス傾向分析から、繁忙期のアクセスPVを予測。 • 安全に繁忙期を乗り切るために必要なリソース（API、検索、DB、Web・・）を見立て事前に環境を整える。 • 実績データを蓄積、振り返りを経て次期繁忙期の参考データとし、年々予測と対応の精度を上げる。 繁忙期 モニタリング データ解析 ビジネス合意 リソース整備
20. 20 モニタリング環境整備とアクション -事例②【突発対策】- ②突発アクセスや不正アクセスへの対応 • メディア露出による短時間ピークアクセスへの対応（〇〇砲）。 • botなどによる不正アクセス、DoS。 • 独自フィルタリング機能を複数設置。 • 特定条件を整備、完全自動でフィルタしリソース保護する。 • アプリケーション連動させ、フィルタ条件は柔軟に変更可能。 モニタリング アクション 解析 分析データの取得と可視化 • アクセスパターンの解析 • 受けるか、拒否するか • 予期可能か、突発的か • 共通項を見つけ出す！ • 計画的な増強 • API異常検知制御（ストップフラグ） • 複数の特定条件フィルタ • 不正アクセス検知と制御 メディア露出で前週比60%増！ 進化し続けるフィルタ実装
21. 21 住まいのまとめ • 安定運用と改善のタネは日々の地道なモニタリングの中から拾う。 • モニタリングはデータ取得だけでなく分析とアクションのサイクル。 • 蓄積データを次のアクションのための布石とする。 少しの遠回りが継続の近道
22. 22 旅行・飲食・ビューティー 旅行・飲食・ビューティーのSRE活動
23. 23 自己紹介 • 名前: 甲谷 悠(カブトヤ ユウ) • プロダクティビティエンジニアリンググループ GM 兼 • 旅行・飲食・ビューティー SREグループ GM • 略歴： • ~ 2014/10 某コンサルファームでアーキテクト • ~ 2017/01 サービスマネジメントとしてRJB所属 • ~ 2018/10 ~ 旧RLS HotpepperBeautyにて運用改善&基盤T所属 • ~ 2020/04 ~ 旧RLS テックリード任用 • 2020/04 ~ 現職 • 座右の銘: • 崖から飛び降りながら飛行機を組み立てる
24. 24 旅行・飲食・ビューティーのサービス(抜粋) • 代表的なサービスとして「ホットペーペッパーグルメ(飲食領域)」「ホットペッパービューティ(美容領 域)」「じゃらん(旅行領域)」の3つがある。 • これらのサービスは紙媒体からWebへの移行を経験している歴史あるサービスあり、扱う領域としては 日常消費の中で利用されるサービスである。 • また、それぞれのサービスは多くのユーザに利用していただいており、経済を活性化させるための社会 基盤という自負を持ってサービス運営を行っている。 (C) Recruit Co., Ltd. All rights reserved. 各領域で、ユーザに対して いつでも"利用いただける 状態"を維持することを 心がけている 飲食領域 旅行領域 美容領域
25. 25 旅行・飲食・ビューティーの(ざっくりとした)システム構成の概念 • 我々が扱う領域はリクルートの「リボンモデル」に基づいてサービスが構築されているものが多い。 • このモデルに基づいたサービスをシステムとして構築する場合、トランザクションの整合性を安全/ シンプルに担保する構成を採用している事が多い。 • そのため、永続化層(≒DB)の負荷がスループットの最大のボトルネックとなるケースが多くなる。 (C) Recruit Co., Ltd. All rights reserved. Action (Recruit) Customer Client カスタマ提供価値 クライアント提供価値 社会提供価値 カスタマの多種多様なニーズを満た したり、新たな気付きを与えること クライアントのサービスをカスタマ に適切に届けること カスタマとクライアントのベスト マッチングを最大化すること データストア 入稿/登録 検索
26. 26 消費マインドの変化に対するサービス影響 • (当然のことながら)消費したいユーザーが増えることで消費財を提供する企業/店舗が活性化する。 • 日常消費の領域ではユーザーの行動心理に影響を与える変数が多くあり、企業が出すキャンペーン だけでなく、国の施策や、テレビ放映などでもサービスへのアクセス量が大きく変化する。 (C) Recruit Co., Ltd. All rights reserved. コロナ禍、まんえん防止/緊急事態にて日常消費は大きく落ち込んだ ※ただし美容領域は飲食/旅行に比べて、例えば「髪が伸びたら切る必 要がある」といった消費マインドとの相関は相対的に低い。 マイナス要素 (アクセス減) プラス要素 (アクセス増) 他要素 (アクセス不安定) Go To トラベルやGo To Eatといった国の消費喚起施策によって 一時的だが急激かつ予測しづらい消費行動が発生した。 定期的に発生するbotアクセスによるアクセス(検索エンジンによる クローラーだけでなく、悪意のあるbot含む)が不定期に発生し アクセススパイクが発生 ここからはSREの取り組みの中でも「急激なアクセス増加が発生しても利用 し続けられる状態」を維持するために行った取り組みを紹介していきます。 コロナにて消費が落ち込む中でGoTo関連は 特に消費傾向を下げてはならないという使命感
27. 27 変化に対するSREの取り組み • SREの行う業務は様々あるが、アクセス増加に向き合うために行っている「(SLOに基づく)モニタリング サイクル」を紹介する。 • モニタリングにおいてはサービスレベルオブジェクト(目標)の定義から必要となるモニタリング要素 (SLI)を要素分解し、各SLIに基づいたモニタリングのためのツールを選定(時には実装)を行っている。 (C) Recruit Co., Ltd. All rights reserved. 次項から、国の施策や需要の変化をベースに、直近起こった“変化への対応” の事例を紹介します。 業務 概要 アーキテクチャ 設計/構築 ✓ 信頼性、可用性、保守性etcを担保するためのシステム構成の 設計と実装 キャパプラ/ 性能改善 ✓ サービスレベルの目標値を定義しサービスレベルの遵守 ✓ システム性能/品質分析 ✓ 品質とコストのコントロール 開発プロセス 改善 ✓ システム運用分析 ✓ 開発基盤、運用プロセス設計と構築 1. インディケーター(SLI)の 剪定 2. ツールによるモニタ/分析 3. 問題点の改善 実施サイクル
28. 28 事例1:国の施策(Go To Eat)による急激なアクセス増加 • 前述の通りコロナの蔓延により緊急事態宣言が発令。消費の減少に伴いアクセス数が落ち込んだ。 • その後、一時期のコロナの落ち着き時に国の施策としてGo To Eatが打ち出された。 • これにより需要喚起が発生しマシンリソースが急激に逼迫、その中で一部のユーザにてログイン状態が 不安定になる事象が発生した。 (C) Recruit Co., Ltd. All rights reserved. • Go To Eatの開始当日のピーク時間帯からアクセス 数が急増(その後継続)。 • それに伴って各マシンリソースの使用量も増加した。 • その中でユーザがログインできない状態が顕在化。 • 調査をしていくとセッション利用しているRedisにて evict key(メモリ溢れによるキー削除)が増加してい ることが判明。 $ /app/XX/redis/rtssesXX/bin/redis-cli info | grep evicted_keys evicted_keys:3901958 Go To Eat前 インスタンス数 PV数(月間) 約30台 ***PV Go To Eat後 インスタンス数 PV数(月間) 約30台 4倍のPVに インスタンス数の増減を極力 抑えてアクセス増を乗り切る アクセス増に伴い、各種マシンリソースの 利用状況も跳ね上がった
29. 29 事例1:国の施策(Go To Eat)による急激なアクセス増加とその対応 • RedisのEviction(データ溢れ)が発生する原因としてデータ件数、サイズ、TTLの設定値をベースにキャッシ ュアウトのタイミングをモデル化、特定のデータ構造が(サイズは小さいものの)データを肥大化させる構造 であることが判明した。 • さらに、分析したところTTL値は正常だが利用されないデータとなり、それが消されることなくキャッシュ される実装であることが判明した。 (C) Recruit Co., Ltd. All rights reserved. セッション名 有効期間 1分あたりの発行数 memory 30分 850 token 2日 1765 permanentdb 30日 22 info 30日 2637 • 格納されるデータとTTLの再整理 • Redisのコードに基づくexpire keyの削除 アルゴリズムの把握 データ増加量のモデル化 明らかに想定メモリ量を超え ているため以下を実施。 • RedisDBのTTL単位での 分離 • 参照されない有効データ の定期削除(Lua)
30. 30 事例2:需要の変化によるアクセス傾向の変化 • 旅行領域でもコロナ感染者の増減に需要が左右される構造。その中で消費対象にも変化が発生した。 • Go To トラベルという国の施策により国内需要が大きくなったことと、近場での旅行にあらためて注目 が集まったことを一因に今まで安定していた機能にてスローダウンが発生した。 (C) Recruit Co., Ltd. All rights reserved. • 機能単位でシステムを分けてサービスを運営。 • 今まで注視していなかった機能にてスローダウンが発生する ようになった。 (定期的にサチュレーションが発生するようになった。) • 他のマシンリソースに対してはスパイクがみられず、 アクセスPathからも特定機能にたいする偏り等もない。 • 暫定的にスケールアウトを増やしサービス全体のスロー ダウンリスクを低減させつつ、該当時間のProfileを実施。 Go To トラベル前(複数プロダクト計) インスタンス数 PV数(月間) 約130台 ***PV Go To トラベル後(複数プロダクト計) インスタンス数 PV数(月間) 約140台 2倍のPVに プロダクト毎に乗り切り方を設計 国内旅行 遊び/観光 海外旅行 … 需要高 (想定外) 需要高 (想定) 需要低 (想定)
31. 31 事例2:国の施策(Go To トラベル)によるアクセス傾向の変化とその対応 • 該当機能はJavaにて構築されており、そのプロファイリングを行うためにCloudProfilerを導入。 • JVM側の処理のCPU Timeが高かったため、CPUスパイク時にperfを実施する監視機能を作成した。 • perfによる詳細分析の結果、code cacheの不足によりリコンパイルが多発しCPU負荷が上昇する原因と なっていた。 (C) Recruit Co., Ltd. All rights reserved. • libjvm.soのCPU Timeが多くperfにて詳細確認。 • compiler_thread_loopの処理が大部分を占めて おりコードの再コンパイルが多数発生していた。 • そのことからcode cacheの枯渇が発生している と推測し、設定値の見直しを実施。 • 実際にcode cacheを含むnon_heap領域が頭打ちの 状態からCPUスパイクのタイミングで解放→増加が 発生していた。 (code cacheのメトリックは取得していなかった。) code cacheのデフォルト値が 240MBのため倍に指定。 -XX:ReservedCodeCacheSize480m
32. 32 旅行・飲食・ビューティー領域まとめ • 今回は旅行・飲食・ビューティー領域のうち、旅行と飲食でのSREの取り組み を紹介しました。 • あまり目立つ仕事ではありませんが、サイトの信頼性を守る上でとても重要な 業務を担っていると自負しています。 • 今回は紹介していませんが、SRE業務は他にも様々存在しておりリクルートの システムに非連続な変化をもたらす取り組みも行っています。 • リクルートのSRE活動について興味を持ってもらえたら幸いです。 以上 (C) Recruit Co., Ltd. All rights reserved.