リクルートにおけるPaaS活用事例

リクルートテクノロジーズ
ビッグデータ部
本村聡
2015年9月1日
リクルートにおけるPaaS活用事例
～BIツールのRedShift移行で得られた3つのメ
リット

自己紹介
2(C) Recruit Technologies Co.,Ltd. All rights reserved.
本村聡 Satoshi Honmura
株式会社リクルートテクノロジーズ
ビッグデータインフラグループ
2014年にリクルートテクノロジーズに中途入社。
職歴はSIer、社内SEを経て現在3社目
これまでは主にオンプレでの開発、運用経験が中心。
現在はビッグデータインフラグループで主にBIツールや
DWHの運用及びサービス企画を行っています。

本日お話させていただきたいこと
1.はじめに～リクルートグループおよびリクルートテクノロジーズ
2.BIツールのクラウド移行プロジェクト事例紹介
・システムの概要
・オンプレからクラウドへ
・クラウド化３つのメリット
３.おわりに

クラウド化による３つのメリット
１．事業が求めるスピードへの対応が可能となる
２．柔軟性、独立性が高い環境が構築できる
３．最適なコストで実現できる
本日お話させていただきたいこと
３つのメリットを享受できる環境としては、
特に情報系システムはクラウドとの相性が非常によい

1.はじめに～リクルートグループおよびリクルートテクノロジーズ

1.はじめに～リクルートとは
【リクルート企業概要】
創立 1960年3月31日「大学新聞広告社」としてスタート
グループ
従業員数
31,841名
連結売上高約1兆2999億円 ※2015年3月末
連結経常利益約1,256億円 ※2015年3月末
関連企業数 162社（国内＋海外）
目指す世界観「あなた」を支える存在でありたい
※2015年3月末

リクルートグループとは
マッチング
カスタマー
（一般ユーザ）
企業
（広告主）
私たちは、新しい価値の創造を通じ、
社会からの期待に応え、
一人ひとりが輝く豊かな世界の実現を目指す。

Life Event
ライフイベント
Life Style
ライフスタイル
将来を考えて選択と意思決定をする
大きな「イベント」
日常の中にある「きょう、何を食
べようか」などといった、小さな
選択と意思決定

9
リクルートキャリア
リクルートジョブズ
リクルートスタッフィング
リクルート住まいカンパニー
リクルートライフスタイル
リクルートマーケティングパートナーズ
スタッフサービス・ホールディングス
リクルートアドミニストレーション
リクルートコミュニケーションズ
事業会社
機能会社インフラ部門
大規模プロジェクト推進部門
UI設計/SEO部門
ビッグデータ機能部門
テクノロジーR&D部門
事業・社内IT推進部門
リクルート
ホールディングス
主要７事業会社＋３機能会社
で構成されるグループ企業群
私が所属する会社は
ビッグデータ機能部門
1.はじめに～リクルートテクノロジーズとは

営業
メディア
プロデュース
事業企画
営業
メディア
プロデュース
事業企画
営業
メディア
プロデュース
事業企画
営業
メディア
プロデュース
事業企画
営業
メディア
プロデュース
事業企画
営業
メディア
プロデュース
事業企画
営業
メディア
プロデュース
事業企画
営業
メディア
プロデュース
事業企画
支
援
支
援
支
援
支
援
支
援
支
援
支
援
支
援
1.はじめに～リクルートテクノロジーズとは
【ビッグデータ機能部門】
ソリューションを軸とした
予測、BI、レコメンド、競合分析
事業案件を軸とした対応
ビックデータ基盤の構築・運用
事業へデータ活用を基とした
各種ソリューションによる支援を行う専門部隊

2.BIツールのクラウド移行プロジェクト

BI環境 Redshift移行PJ概要
12
事業系
データ
ETL
Redshift
会計系
データ
BIツール利用者
（事業）
R-Cloudへ移行
DWH
アプライアンス
BIツール BIツール
リクルート版
クラウド
廃止
DWHアプライアンスサーバーとBIサーバーを
クラウド環境へ移行するプロジェクト

リクルート版クラウド（Rクラウド）とは

【パブリッククラウド利用状況(2010年頃)】
ライバル企業に対する優位性を確立するために
『小さく、軽く』開発できるパブリッククラウドの利用が拡大
サービス立ち上げ期に開発者主体で使える
インフラサービスの需要が発生
パブリッククラウド
Aサービス Zサービス
・・・
Bサービス

【パブリッククラウド利用時の課題】
インフラだけならすぐに作れるが。。。
② 個別に非機能要件の作り込み
→ 作り込みに時間がかかる
① 個別にセキュリティ対応
→ セキュリティ対応に時間がかかる

3.パブリッククラウド”Rクラウド”の進化の軌跡
【パブリッククラウド利用時の課題】
インフラだけならすぐに作れるが。。。
② 個別に非機能要件の作り込み
→ 作り込みに時間がかかる
① 個別にセキュリティ対応
→ セキュリティ対応に時間がかかる
これらの課題解決のため
・・・
(Rクラウド)
・・・
共通機能
（セキュリティ、非機能対応）
2011年からリクルート版パブリッククラウド(Rクラウ
ド)を構築し、順次共通機能の提供を開始！

移行対象のシステム

【本日の主役のシステム】
2013年より提供開始
BIツールを利用した事業向け営業支援ツール
【サマリーレポート】
営業が業績の概要を把握する。
前週までの主要KPIを表示する。
BIサービスの導入により、現状分析～打ち手実行まで
を可視化し、営業活動のスピードアップを可能にする。

DWHのアプライアンス製品を利用
複数サービスでの共同利用を想定
【初期導入時の想定】
リクルート各事業のデータを集約し、複数事業でBIツールやア
ドホック分析で利用
ETL
（事業）
DWH
BIツール
事業系
データ
会計系
データ
WEB
サーバー
アドホック分析者
事業系
データ事業系
データ事業系
データ

課題は？

【課題】
１．事業への提供コストが高い
⇒インフラコストと人的なコストが高い状態
２．安定的な性能を提供できない
⇒ＢＩツールのレポート表示に性能的問題があった。
サービス提供にあたって
コスト、性能に問題があった

初期導入時にある程度将来的な拡大利用も含めて
環境構成やサイジングをする必要があった。
【導入時の想定】
リクルート各事業のデータを集約し、BIツールやアドホック
分析でRグループの複数事業で利用する予定
ETL
（事業）
DWH
BIツール
事業系
データ
会計系
データ
WEB
サーバー
アドホック分析者
事業系
データ事業系
データ事業系
データ

しかし、事業への展開には時間がかかる

【課題１：事業への提供コストが高い】
～物に関するコスト～
・本番、ステージング、開発環境などを保持する必要がある。
・ピーク時を想定したサイジングとなる。
・サイジングの変更（拡張、縮小）コストが高い。
オンプレの場合はオーバースペック傾向な見立てとなる
ので、高コスト構造となっていた
DWH DWH
BI
WEB
BI
WEB
BI
WEB

【課題１：事業への提供コストが高い】
～人に関するコスト～
・ＤＷＨアプライアンスの運用は専門性が高い
・バージョンアップやパッチ対応の運用工数大
・機能拡張時にPOCから導入までの工数が大きい
運用保守作業に多くの工数を要していた
Ex)

【課題２：安定的な性能を提供できない】
・資産の効率利用を考え、同一環境上で複数サービスやバッチ実
行などの共同利用を行っていたため、相互影響が発生していた状
態。
環境の共同利用により性能問題が発生
DWH
BI
今日はたくさん
分析しよう！なんか
遅いな

クラウドで解消できるか考えてみました

～物に関するコスト～
・本番、ステージング、開発環境などを保持する必要がある。
・ピーク時を想定したサイジングとなる。
・サイジングの変更（拡張、縮小）コストが高い。
クラウドで解決できそう
⇒ フルタイム使うわけではないので、必要に応じて立ち上げる。
⇒ BIサービスの現在の利用状況に合わせてサイジング可能。
⇒ 拡張する時に必要なリソース分のみ拡張すればよい。

～人に関するコスト～
・バージョンアップやパッチ対応の運用工数大
・ＤＷＨアプライアンスの運用は専門性が高い
・機能拡張時にPOCから導入までの工数が大きい
⇒ マネージドサービスなので対応工数削減できる
⇒ Redshiftもマネージドサービスのため、チューニングなど
できることに制約はあるが専門性は高くない。
⇒ 設定一つで新機能の利用ができる。

性能問題
・資産の効率利用を考え、同一環境上でサービスやバッチ実行な
どの複数サービスの共同利用を行っていたため、相互影響が発生
していた状態。
⇒BIサービス単体の環境とすることで独立性を確保

結論：クラウドへの移行で解決できそう！

最初からクラウドにしていれば良かったのでは？

2012年頃のDWH状況
・当時は高性能なDWH製品はアプライアンス製品が中心。
（Redshiftが登場したのは2013年）
・セキュリティの観点でクラウド上に企業情報を置くことの
ハードルが高かった。
当時の状況としては、
オンプレ環境しか選択できなかった。

移行を進めるにあたって、事前に課題もあり
・BIツールのドライバがRedshiftに対応していない。
・性能面が従来のDWHアプライアンス製品と同等レベルでるか。
・サーバーコストが本当に下がるか
事前検証期間として1か月検証期間を設ける

事前検証の結果

・BIツールのドライバがRedshiftに対応していない。
⇒レポートパターン分類し動作確認。修正ポイントも把握。
・性能面が従来のDWHアプライアンス製品と同等レベルか。
⇒同等レベルの性能を出すためのサイジング判明
（当初想定の１.５倍程度必要）
・サーバーコストが本当に下がるか
⇒当初想定より削減効果は下がったが、一定の効果あり。
（約４０％程度削減）
事前に検証の結果、正式に移行が決定

【事前検証方法の違い】
オンプレ型事前検証
・本番同等の環境は用意できない（または時間がかかる）
⇒机上や多くの制約条件の中で実施。
クラウド型事前検証
・本番同等の環境が用意できる
⇒本番に近い環境のため、事前にリスクの洗い出しが可能。
一か月で事前検証ができるのはクラウド効果

移行方針
・クラウドはRクラウド（ＡＷＳ）を利用
・ＤＷＨ部分はRedshift、BIツール部分は、EC2上への移植
・ETLツールは廃止
・移行期間は3か月
移行期間３か月でのAWS（Rクラウド）への
ほぼ単純移植を決定
事業系
データ
Redshift
会計系
データ
（事業）
BIツール
リクルート版
クラウド

プロジェクト実施中の課題

バッチ連携処理の性能問題が発生
⇒HDを磁気ディスクからSSDへ切り替え
処理時間4時間⇒3時間（２５％の処理改善）
オンプレでは実現不可能な構成変更が短期間に可能
設計発注
キッティ
ング輸送
ラッキ
ング
初期設
定
データ
移行
設計
設定変
更再構成
数週間～数か月必要
約5時間で切り替え
オンプレの場合
今回のパターン

リリース結果

コスト
モノのコスト・・・SSDへの切り替えなど、開発中に
見直しが入ったがほぼ想定通りの結果
であった。
人のコスト・・・BIサービスの運用は少数体制へ
１０人⇒５人体制に
性能面
BIサービス単体の環境となったため、複数システムによる
相互影響はなくなり、性能問題も解消。
ほぼ当初期待通りの結果となった

得られた３つのメリット

・トライアルや検証が圧倒的にやりやすい
・構築フェーズでも環境構成変更が容易
・類似的な環境であれば横展開が簡単
・ドキュメント作成工数が削減

・利用者の拡大や縮小に合わせて、環境を柔軟に変更できる。
・相互影響を与えない独立した環境を構築できること。

・オンプレと同じやり方を踏襲していては減らない。
・設定変更や改修に関する事前調査工数を削減。
・監視やバックアップなど自動化ができる部分は自動化に。
・実現が難しいことはあきらめる。対応されるのを待つ。
・ドキュメントを必要以上に作らない

得られた注意点

・チューニングできる範囲は少ない。
・検証・開発期間中のAWSコストが読みづらい
・あまりに簡単に設定変更ができすぎる。

リリース後のRedshift状況

稼働後4か月経過
・Redshiftの停止は深夜2回、時間にして約10分発生
（定期メンテナンス時間を除く）
RedshiftはRDSと比較して可用性は下げると思われがちだが、
99％以上の稼働率。いずれも自動復旧している。
安定性は高いが、再起動など予期せぬ
動作もあるので要注意。

クラウド化3つのメリット
情報系の特徴
・思い立ったらすぐに使いたい。データ活用は鮮度が重要。
・データ量の変化が読めない。
・ユーザー利用方法が読めない。
・SLAがそれほど高くない。
情報系システムと相性がよい
今後も情報系システムを中心に利用促進を予定

３.おわりに
まだまだ我々のクラウドへの取り組みはこれからという状態です。
クラウド系のDWHやBIへの取り組みなど、ぜひ情報交換させて
ください。
また、リクルートテクノロジーズは一緒に働く仲間も募集してい
ます。
よろしくお願いします。

ご清聴ありがとうございました

リクルートにおけるPaaS活用事例

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (19)

Similar a リクルートにおけるPaaS活用事例

Similar a リクルートにおけるPaaS活用事例 (20)

Más de Recruit Technologies

Más de Recruit Technologies (14)

Último

Último (9)

リクルートにおけるPaaS活用事例