リクルートでのSREの取り組み

2018/11/30 第15回 itSMF Japanコンファレンスでの、宮川の講演資料になります

Transcript

1. 2018年11月30日 リクルートテクノロジーズ 宮川 典久 リクルートでのSREの取り組み
2. 2 自己紹介 宮川 典久 株式会社リクルートテクノロジーズ 執行役員 ITエンジニアリング本部 ▪経歴 SIer（2004/04〜2012/10）  アーキテクト兼プログラマー リクルートテクノロジーズ（2012/11〜）  グループマネージャー（2014/04〜）  シニアマネージャー（2016/04〜）  執行役員（2017/04〜） ▪主な役割 • 内製開発 • AP基盤 • ネットインフラ • データ活用
3. 3 はじめに
4. 4 リクルートグループについて リクルートは2012年10月に分社化、2014年10月に上場しています。 創立 1960年3月31日 「大学新聞広告社」としてスタート グループ 従業員数 40,152 名 連結売上高 21,733億円 連結経常利益 1,917億円 グループ 関連企業数 361社 目指す世界観 果たす役割 （2018年3月31日時点） （連結対象子会社、2018年3月31日時点） （2017年4月1日〜2018年3月31日） （2017年4月1日〜2018年3月31日） 「あなた」を支える存在でありたい
5. 5 リクルートの主な事業 リボンモデルを活用したビジネスを展開
6. 6 リクルートの主な事業 ライフイベント領域 進学 就職 結婚 転職 住宅購入 車購入 出産/育児 旅行 ビジネス支援 生活/地域情報 グルメ・美容 ライフスタイル領域
7. 7 リクルートテクノロジーズとは リクルート HD リクルートキャリア リクルート住まいカンパニー リクルートライフスタイル リクルートジョブズ リクルートマーケティングパートナーズ リクルートテクノロジーズ リクルートコミュニケーションズ メディア＆ ソリューション Staffing HR Technology SBU Company Holding Company and more... (Strategic Business Unit)
8. 8 リクルートテクノロジーズとは リクルートテクノロジーズ 企画統括本部 ITエンジニアリング本部 ITマネジメント本部 ITソリューション本部 ITマーケティング本部 経営企画、広報、経理、人事、総務など いわゆるスタッフ部門 事業と一体となり、開発ディレクションやエンハン ス、大規模プロジェクトの推進を担う 内製でのプロダクトの開発やネットインフラ・AP基 盤の構築／運用、データ活用などの機能を担う リクルート全社の基幹システムや共通インフラ、セ キュリティ等のソリューションを提供する UXデザイン、ウェブマーケティング、サービスデ ザインの検討から実装を担う
9. 9 リクルートのインフラ
10. 10 データセンターの統合 2009年6月：４つの主要DCを統合 • 徹底的な標準化による、全面的コスト削減
11. 11 サーバ仮想化の実施 2013年6月：DCの全面リプレースを実施 • 仮想化技術の全面採用と、仮想化ベースのアーキテクチャによって、サーバ 台数の劇的削減とコスト削減を実施 • 仮想化技術の全面採用（物理と論理の分離）によって、基本的に、サーバ関 連作業において、アプリ・サービス影響がなくなった
12. 12 クラウド活用の促進 クラウドも積極的に活用中 AWS GCP 主に新規の中小規模サイトや開発環境として 活用している。 大規模サイトを高速エンハンスするために切 り出して、部分的な機能拡張を行う用途でも 活用している。 GCPは現状主にBigQuery等、データ分析用 途での活用がメイン。 また、データを活用したデータプロダクトの インフラ環境としても活用し始めている状 況。 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 6月 7月 8月 55期 56期 57期 58期 AWS月次利用料
13. 13 リクルートの主なインフラ オ ン プ レ ミ ス • 大規模サイト向けインフラ環境 RAFTEL改 RAFTEL Lite ELIXIR Rクラウド AWS Rクラウド GCP ク ラ ウ ド • 小規模サイト向けインフラ環境 • セキュアサイト向けインフラ環境 • 現状はリクルートポイント専用の環境 • 中小サイトや、開発環境、大規模サイトの機能切り出 し等に活用している環境 • データ分析やデータプロダクト用の環境 名称 概要 約30 サイト数 約100 1 約100 - 独自AWS • Rクラウド以外で、独自契約したAWS環境 5〜10
14. 14 インフラに求められる運用の変化
15. 15 ポイント サイト毎に異なるサービスレベル 求められるリードタイムの削減 標準化の限界
16. 16 ポイント サイト毎に異なるサービスレベル 求められるリードタイムの削減 標準化の限界
17. 17 サービスレベル 複数のビジネスドメインが存在している 各領域とも規模が大きく、成長もしている
18. 18 サービスレベル 開発プロセス アジャイル開発中心 ウォーターフォール開発中心 ハイブリッド型 開発/運用体制 SIer委託中心 内製開発中心 ハイブリッド型 サービス特性 極端なスパイクアクセス 24/365レベルでのリアルタイム性 繁忙シーズン サイト毎に開発プロセスや開発/運用体制、サービス特性が異なる
19. 19 サービスレベル ビジネス領域の拡大が進んでいる IR資料：「メディア＆ソリューション事業のご紹介」より抜粋
20. 20 サービスレベル 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 サービスの成長／拡大に伴い、求められるSLAが向上している 3月
21. 21 ポイント サイト毎に異なるサービスレベル 求められるリードタイムの削減 標準化の限界
22. 22 リードタイム リボンモデルをベースとしたビジネス ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー
23. 23 リードタイム ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー 2種類の開発が求められる • 営業が売るための商品開発 • カスタマー／クライアントの継続利用に向けたサイト改善 CVR 向 上 業 務 効 率 向 上 商品開発 営業
24. 24 リードタイム 案件によって開発に求められるQCDが大きく異なる 案件タイプ 規模（コスト） 納期の重要度 品質の重要度 （例） 営業商品 大 高 高 詳細ページに動画広 告を入れたい サイト 改善 カスタマー 小 低 中 ボタンを四角から丸 に変えたい クライアン ト 中 低 高 入力バリデーション を追加したい
25. 25 リードタイム サイトの成長が進む中で、大規模な商品開発だけでなく、定常的なサイト改善の 重要度が高まってきた 案件タイプ 規模（コスト） 納期の重要度 品質の重要度 （例） 営業商品 大 高 高 詳細ページに動画広 告を入れたい サイト 改善 カスタマー 小 低 中 ボタンを四角から丸 に変えたい クライアン ト 中 低 高 入力バリデーション を追加したい インフラ構築のリードタイム が10日程度かかっても誤差 可能な限り短いスパンでリリー スを行いたいため、インフラの リードタイムも極力短くしたい
26. 26 ポイント サイト毎に異なるサービスレベル 求められるリードタイムの削減 標準化の限界
27. 27 オンプレミス（RAFTEL） 標準化の限界 リボンモデルに特化した標準化 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー ハイパーバイザー 各種ハードウェア
28. 28 標準化の限界 ビジネスの多様化が進む IR資料：「メディア＆ソリューション事業のご紹介」より抜粋
29. 29 標準化の限界 ビジネスの多様化に伴い、個別最適化を行っていく必要性が増えてきている サイトB サイトC サイトA サイトB サイトC サイトA 過去 現在 リボンモデルをベースにした似たサイト構成 開発/運用ノウハウが各サイトに無かった サイトの構成も個別に進化 サイトにエンジニアが増え、開発のレベルが向上 標準化の価値が大きかった 個別最適化のニーズが増えてきた Webサーバ APサーバ フレームワーク 開発言語 検索エンジン DB Webサーバ APサーバ フレームワーク 開発言語 検索エンジン DB キャッシュ キャッシュ Apache Tomcat R2FW Java Solr Oracle OSキャッシュ Apache Nginx Tomcat UNICOR N R2FW Spring Boot RoR Java Ruby Solr Elasticsearch Oracle MySQL OSキャッシュ Redis  全ての構成を統一することで、一定レベルのシステムを 構築できるようサイトのレベルを引き上げていた  ビジネスも多様化してきており、共通の構成だけでは対 応することが困難になりつつ有る
30. 30 SREへの取り組み
31. 31 インフラの置かれた状況 サイト毎に異なるサービスレベル 求められるリードタイムの削減 標準化の限界
32. 32 課題への対応 サイト毎に異なる サービスレベル 求められるリード タイムの削減 個別最適のニーズ SRE組織の構築 自動化と無駄の削減 監視モニタリングの 進化
33. 33 SREへの取り組み SRE組織の構築 自動化と無駄の削減 監視モニタリングの進化
34. 34 SREへの取り組み SRE組織の構築 自動化と無駄の削減 監視モニタリングの進化
35. 35 これまでの運用体制 標準化を進めた結果、インフラに関する運用・変更については横断インフラ組織 と開発組織が分断してしまった状態 カ ス タ マ ー ク ラ イ ア ン ト フレームワーク フレームワーク インフラ フレームワーク カ ス タ マ ー ク ラ イ ア ン ト カ ス タ マ Web ク ラ イ ア ン ト 横断インフラ組織 開発体制 開発体制 開発体制 依頼 依頼 依頼
36. 36 これまでの運用体制 機能毎に細分化した組織構成 ネットワーク班 構 築 チ ー ム サーバ班 ストレージ班 DB班 ミドルウェア班 運用チーム サービスデスク 統括班 サイトA サイトD サイトB サイトC 運用担当 運用担当 運用担当 運用担当 構築申請 横断インフラ組織 開発担当 開発担当 開発担当 開発担当
37. 37 SREとは • サイトの信頼性向上を命題に置く • 運用オペレーションにソフトウェ アの知識を持ち込む
38. 38 目指した姿 SRE組織 各サイトにインフラ全体を担当出来るチームを配置し、それぞれの中でDevOps 的な開発/運用を行える状態 サイトA サイトD サイトB サイトC 基盤チーム 開発担当 SREチーム 開発担当 SREチーム 開発担当 SREチーム 開発担当 SREチーム 定常運用 インフラ作業 事業調整 運用改善 定常運用 インフラ作業 事業調整 運用改善 定常運用 インフラ作業 事業調整 運用改善 定常運用 インフラ作業 事業調整 運用改善
39. 39 SRE組織を作るための進め方 いきなり全部を変えるのではなく、小さく実績を作り、その後に横展開を実施 ネットワーク班 構 築 チ ー ム サーバ班 ストレージ班 DB班 ミドルウェア班 運用チーム サービスデスク 統括班 サイトD 開発担当 SREチーム サイトA サイトB サイトC 運用担当 運用担当 運用担当 開発担当 開発担当 開発担当 横断インフラ組織 定常運用 インフラ作業 事業調整 運用改善
40. 40 SRE組織を目指す中で見えてきたこと • リリースの改善 • インフラ担当がソースコードリポジトリやCI/CDまで含めて把握していくことで、 リリースまで含めた改善を進めることが出来た • 監視・モニタリングの進化 • 監視を改善するにはツールよりもまず、アラートを減らしていくことが重要 開発と連携して進めていくことでアラート削減が進んだ • モニタリング観点はサービス特性によって異なるので、サイト毎に特化したモニ タリングが進んだ 上手くいった点 • 属人性の排除 • 各チームに分散していた権限を小さいチームに集約することで、チーム内でのノ ウハウ共有が進み、属人性削減が進んだ • リードタイムの向上 • チームが小さくなることで、これまで起きていたチーム間のコミュニケーション が減り、大幅にリードタイムが改善 • 開発と一体となって動くことにより、インフラ構築に必要な情報を事前に把握出 来ているため、結果としてリードタイム削減に繋がった 開 発 と の 連 携 サ イ ト 別 チ ー ム
41. 41 SRE組織を目指す中で見えてきたこと 上手くいかなかった点 ス ケ ー ル マ イ ン ド 個 別 対 応 • サイト数の多さ • 大規模サイトだけでも30を超えるサイト数があり、それぞれに特化したチームを 作る事が困難 • チーム/リーダーの育成 • 個々に多くのスキルを求めるため、チーム/リーダーの育成に時間がかかる • 失敗を恐れる • これまでの運用では可能な限り失敗を行わないようにしてきたことも有り、なか なか改善に踏み込むことが出来なかった • 受け身になりがち • 依頼されたことをやるだけのチームも生まれてしまっていた • 横断としての改善要望 • サイト個別の要望が次々と上がる中で、インフラ全体として改善を行うべきテー マも多く有り、統制が必要となってきた • 開発プロセス、開発/運用体制の違い • 求められる運用の範疇がサイトによって大幅に異なる
42. 42 行った対応 スケール マインドセット → いきなり大きくするのではなく、少しずつ範囲を広げていく 全て個別にするのではなく、必要な範囲を整理 → 組織として失敗をフォローする雰囲気の醸成が重要 現場の失敗に対しても上位レイヤでもコミュニケーションを行う 個別対応 → 様々な要望が出る中で、横断での改善も行える体制を構築 開発のプロセスや状況に合わせた体制を目指す
43. 43 現在の組織構造 横断的なSREチームを作り、サイト状況に合わせた体制を構築 サイト サイト サイト サイトA サイトA サイト 基盤チーム SREチーム 開発担当 横断SRE 横断運用改善 インフラ作業 定常運用 インフラ作業 事業調整 運用改善 サイト サイト サイト 運用チーム 事業調整 運用改善 運用チーム 事業調整 運用チーム 事業調整 定常運用 定常運用 開発担当 開発担当 開発担当
44. 44 現在の組織構造 横断的なSREチームを作り、サイト状況に合わせた体制を構築 サイト サイト サイト サイトA サイトA サイト 基盤チーム SREチーム 開発担当 横断SRE 横断運用改善 インフラ作業 定常運用 インフラ作業 事業調整 運用改善 サイト サイト サイト 運用チーム 事業調整 運用改善 運用チーム 事業調整 運用チーム 事業調整 定常運用 定常運用 開発担当 開発担当 開発担当 これで完成ではなく、 状況に合わせて組織自体も 進化を続けていく
45. 45 SREへの取り組み SRE組織の構築 自動化と無駄の削減 監視モニタリングの進化
46. 46 運用フロー全体を考慮した自動化 障害対応 障害検知 ブランチ運用 手順作成 案 件 推 進 作 業 非 定 型 作 業 CS インフラ 障害調査 アプリ 障害調査 ブランチ 作成 緊急 リリース 運用 運用 基盤 障害対応 CL 入稿ﾊﾞｯﾁ CS CL 入稿ﾊﾞｯﾁ CS CL 入稿ﾊﾞｯﾁ基盤 内容確認 CS CL 入稿ﾊﾞｯﾁ 問合せ (システム) 問合せ 依頼 CS Oracleサ ポートetc Job 調査etc 運用 基盤 CL 入稿 ﾊﾞｯﾁ ﾘｸﾎﾟﾝ 問合せ (ユーザー) 行動調査依 頼 CL Web 操作履歴 調査 運用 CS Web HD ﾏﾈｼﾞ サポデ 調査 調査 依頼 CS ｱｸｾｽ量 性能etc ログ取得 運用業務 運用 基盤 CL 入稿 ﾊﾞｯﾁ 案件検討・ 設計 CS CL 入稿ﾊﾞｯﾁ ブランチ作成 ブランチ管理(マージ) 仕様確認 CS CL 入稿 ﾊﾞｯﾁ 運用 運用 単体テスト 環境構築 運用 インフラ要 件確認 基盤 アカウント作成 新規メン バー参画 CS アカウント 作成 基盤 CL 入稿ﾊﾞｯﾁ ﾌｰｼｬ ｾﾝﾄ 開発環境変更 (FSHA) モニタリング 基盤変更 開発面切替 (RAFTEL) 開発面切替 (MINKE) 高負荷面切替 (RAFTEL) 開発 CS CL 入稿ﾊﾞｯﾁ テスト (AT・ST) CS CL 入稿ﾊﾞｯﾁ リリース 確認 CS CL 入稿ﾊﾞｯﾁ 開発環境変更 (RAFTEL) 開発環境変更 (MINKE) 高負荷環境変 更(RAFTEL) 本番環境変更 (RAFTEL) リリースリハ 基盤 運用 基盤 テスト (性能) CS CL 入稿ﾊﾞｯﾁ 運用 基盤 基盤 リリース 基盤 テスト (検品) CS CL 入稿 ﾊﾞｯﾁ 本番環境変更 (FSHA) 本番環境変更 (SENTO) 検品環境変更 (RAFTEL) 検品環境変更 (FSHA) 検品環境変更 (SENTO) 開発環境変更 (SENTO) 基盤 ﾊﾞｯﾁ 入稿 高負荷環境変更 (FSHA) 高負荷環境変更 (SENTO) ﾊﾞｯﾁ 入稿 基盤 基盤 運用 基盤 運用 基盤 運用 基盤 環境切替 環境整備 ﾊﾞｯﾁ 入稿 基盤 基盤 ﾊﾞｯﾁ 基盤 入稿 基盤 リ リ ー ス ﾗﾌﾃﾙ ﾗﾌﾃﾙ ﾗﾌﾃﾙ ﾗﾌﾃﾙ ﾗﾌﾃﾙ QAT
47. 47 運用フロー全体を考慮した自動化 部分的に自動化を行ったとしてもトータル時間が早くなるとは限らない DB変更 手順作成 DB変更 アプリ 手順作成 バッチ リリース アプリ リリース リリース 内容確認 バッチ 手順作成 MW変更 手順作成 作業 内容確認 MW リリース リリース作業 自動化
48. 48 運用フロー全体を考慮した自動化 全体像を把握した上で、必要な箇所を自動化する 過去(資源管理バラバラ) 自動化後(資源管理方法の統一と分掌の分離) ディレクトリ マスタデータ (DML) DDL ジョブ定義 アプリ 資源 JIRAチケ JIRAチケ OB ER 検品環境 GhE 管理対象 管理方法 Conf 各環境 (一部GhE) Ansible CSV (liquibase) liquibase Java/Shell 管理内容 Conf (Ansible) GhE 管理方法 Excel (手順書) CSV sql ジョブ フロー Java/Shell 管理内容 Conf ファイル サイト個別のインフラ資源を コードとして構成管理。 各環境への適用時に属人性を 排除する。 DBスキーマ情報をDSLとして 構成管理。マスタ情報の環境 適用も透過的に実施可能とす る。 リリース単位での差分情報管 理を行う。 GhEで構成管理を一元化し、「デプロイ」と 「変更内容確認」の効率化を実現する。 ジョブ フロー
49. 49 運用フロー全体を考慮した自動化 トータル時間をいかに削減するかを意識する DB変更 手順作成 DB変更 アプリ 手順作成 バッチ リリース アプリ リリース リリース 内容確認 バッチ 手順作成 MW変更 手順作成 作業 内容確認 MW リリース リリース作業 新リリース作業 リリース 内容確認
50. 50 運用の無駄を削除 サービス担当者 調整担当 実作業担当 申請用 ページ 開発用 JIRA インフラ用 JIRA slack ①相談・質問 ②コメントでやりとり （記録のためのツール） ③excelのヒアリング シートを作成し、 申請用ページで作業申請 sack ⑤不明点質問 ④依頼内容確認 ⑥作業実施・進捗更新 ⑦作業完了報告 ➇作業完了報告 設定 対象 機器 作業 A 作業 B 作業 C ・・・ ① ② ③ ④ ⑤ ⑥ ⑦ 時間 ➇ 各タスクの時間イメージ フローのイメージ SREチーム
51. 51 運用の無駄を削除 サービス担当者 調整担当 実作業担当 申請用 ページ 開発用 JIRA インフラ用 JIRA slack ①相談・質問 ②コメントでやりとり （記録のためのツール） ③excelのヒアリング シートを作成し、 申請用ページで作業申請 sack ⑤不明点質問 ④依頼内容確認 ⑥作業実施・進捗更新 ⑦作業完了報告 ➇作業完了報告 設定 対象 機器 作業 A 作業 B 作業 C ・・・ ① ② ③ ④ ⑥ 時間 ➇ 各タスクの時間イメージ フローのイメージ SREチーム 中身を、SREチームで対応 するフローに変え、無駄を 捨てる（⑤・⑦捨て） これまで実作業のみ実施してき たメンバーが作業の背景も含め 理解することで依頼内容の確認 などもスムーズに（④短縮） SREチーム化によっ て、申請用ページで 申請する必要がなく なった（③短縮） 削減時間
52. 52 SREへの取り組み SRE組織の構築 自動化と無駄の削減 監視モニタリングの進化
53. 53 監視・モニタリングの進化 システムが個別進化を続けていく中で、監視やモニタリングもシステムごとに分 散してしまった Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon CloudSearch オンプレミス AWS Amazon CloudWatch
54. 54 監視・モニタリングの進化 オンプレミス/クラウド含めて統一的に活用できる監視モニタリング基盤を整備 Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon CloudSearch オンプレミス AWS 監視モニタリング基盤
55. 55 監視・モニタリングの進化 監視・モニタリングについてはASPを活用 PagerDuty • クラウドとオンプレミスで同じツールで監視で きる世界観を目指し、ASPへの置き換えを実施 • メトリクスの監視には拡張性が高く、機能も豊 富なDataDogを選定 • 電話での通知はやはり必要であるため、電話通 知も行えるPagerDutyを選定 DataDog
56. 56 監視・モニタリングの進化 DataDogを中心に、監視・モニタリングの基準を明確化 アラート チケット ロギング 監視システム サービス障害など リソース使用量が 警戒閾値を超過など 詳細ログなど 計画的に対応 分析・追跡の際に利用 即対応 電話などでの通知 メールなどで通知 SRE組織
57. 57 監視・モニタリングの進化 サーバ情報 1月 2月 3月 全体 台数 xx xx xx CPU数 xx xx xx WEB/AP 台数 xx xx xx CPU数 xx xx xx DB 台数 xx xx xx CPU数 xx xx xx その他 台数 xx xx xx CPU数 xx xx xx 作業 1月〜3月 通常 xx 件 緊急 xx 件 夜間休日 xx 件 障害 1月〜3月 サービス影響なし xx 件 サービス影響あり xx 件 PV数（WEBの分析データ） 1月〜3月 PV数合計 xxxxxxxxxxx PV HTTP status code 100系 x % 200系 xx % 300系 x % 400系 x % 500系 x % 時間を要しているDB query（DBの分析データ） 延べ実行時間 実行回数 1回あたりの 実行時間 query xx 秒 xx 回 xx.xx ミリ秒 select xxxx xx 秒 xx 回 xx.xx ミリ秒 select xxxx xx 秒 xx 回 xx.xx ミリ秒 select xxxx ・・・ インフラ観点で気になっていること • HTTP 500系が前回の結果より増えている状況です • DBの「select xxx」が時間がかかっているため改善で きると効果が高いです インフラ観点での定期的な棚卸しを実施し、改善ポイントを見つける
58. 58 まとめ
59. 59 まとめ SRE組織の構築 自動化と無駄の 削減 監視モニタリン グの進化 • 全てのサイトに対して最適化を行うのが困難な中、より変 化が多いサイトや、求められるサービスレベルの高いサイ トに対して、サイトに特化したSREチームを配置 • 同時に横断的なSREチームを作ることで、全体的なサイト の信頼性向上を実施 • 部分的な自動化は効果が薄く、運用フロー全体を把握した 上での自動化が重要 • 自動化を行うよりも無駄な作業の削減や、役割の変更によ る運用フローの改善のほうがトータル時間を削減できる場 合が多い • 使う技術要素が多様化していく中で、監視やモニタリング のように統一化するポイントを用意する事は重要 • 自前主義にはならず、ASPやクラウドは積極的に活用して いくことで運用負荷は大幅に減らすことが出来る
60. 60 まとめ 挑戦出来る風土を作る きちんと振り返る ユーザーを意識する
61. 61 一緒にSRE活動を行ってくれる仲間を募集中です！ リクルートテクノロジーズ 検索
62. ご清聴ありがとうございました