リクルートのWebサービスを支える「RAFTEL」

リクルートテクノロジーズインフラソリューション部

北岡史也

2015年7月28日

リクルートのWebサービスを支える「RAFTEL」〜堅牢性と機動性を両立した運用基盤とは〜

自己紹介

2 (C) Recruit Technologies Co.,Ltd. All rights reserved.

北岡史也 Fumiya Kitaoka

株式会社リクルートテクノロジーズインフラソリューション部インフラソリューション３G グループマネージャー前職はSIerでDBA。2011年にリクルートに中途入社。入社後はプライベートクラウドの運用、設計、構築を担当し、現在はパブリッククラウドも担当しております。

本日お話させていただきたいこと


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

2.プライベートクラウド”RAFTEL”の進化の軌跡

3.パブリッククラウド”Rクラウド”の進化の軌跡

4.まとめ〜プライベート／パブリッククラウドの運用から

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


1.はじめに〜リクルートとは


【リクルート企業概要】

創立 1960年3月31日「大学新聞広告社」としてスタート

グループ従業員数

31,841名

連結売上高約1兆2999億円 ※2015年3月末

連結経常利益約1,256億円 ※2015年3月末

関連企業数 162社（国内＋海外）

目指す世界観「あなた」を支える存在でありたい

※2015年3月末



【リクルートのビジネスモデル】

マッチング

カスタマー（一般ユーザー）

クライアント（サービス提供企業）

世界中の生活者と産業界に「まだ、ここにない、出会い。」を提供します




カスタマーマッチングクライアント




※リボンモデルについてはyoutube上に「ribbon model」で説明があります

カスタマーマッチングクライアント

○○な結婚式がしたいけどどの結婚式場にすれば・・・

○○な結婚式をあげられる式場なんだけどな・・・

○○なヘアースタイルにしてくれるところないかな・・・

こういうヘアースタイルにすることができるんだけど・・・



ライフイベント領域

進学

就職

結婚

転職

住宅購入

車購入

出産/育児

旅行

トレンド

生活/地域情報

グルメ・美容

ライフスタイル領域

選択・意思決定を支援する情報サービスの提供「まだ、ここにない、出会い。」を実現する

【リクルートの事業領域】

1.はじめに〜リクルートテクノロジーズとは


リクルートキャリア

リクルートジョブズ

リクルートスタッフィング

リクルート住まいカンパニー

リクルートライフスタイル

リクルートマーケティングパートナーズ

スタッフサービス・ホールディングス

リクルートアドミニストレーション

リクルートコミュニケーションズ

事業会社

機能会社

インフラソリューション

大規模プロジェクト推進

UXD/SEO

ビッグデータ機能

テクノロジーR&D

事業・社内IT推進

リクルートホールディングス

リクルートとは、主要７事業会社＋３機能会社で構成されるグループ企業群

私が所属する会社はリクルートテクノロジーズ

セキュリティ AP基盤・オフショア開発

1.はじめに〜リクルートテクノロジーズとは


【リクルートテクノロジーズのミッション】リクルートグループ各社の現在・将来のニーズを見据えて競合優位性の高いIT、ネットマーケティング基盤を開拓・ビジネス実装することによりリクルートグループの競争優位を構築していく。

IT・ネットマーケティング領域の専門部隊。リクルートグループをITで牽引する企業です



ライフイベント領域

進学

就職

結婚

転職

住宅購入

車購入

出産/育児

旅行

トレンド

生活/地域情報

グルメ・美容

ライフスタイル領域

【リクルートのインフラ】

プライベートクラウド（RAFTEL）

パブリッククラウド（Rクラウド）





【インフラ統合前(2006〜2007年頃)】

データセンタ1

サイト数サーバ数 NW機器

専用1 109 65

データセンタ2


専用1 129 57

主サイト数サーバ数 NW機器

8 526 287

データセンタ4


32 574 298

データセンタ3

HOPE

Ima/MARCO

Arorua

Gemini

Kassul FROLIDA

4箇所のデータセンター、 1400台のサーバで構成エンジニアも各サービスごとに配置



【インフラ統合前(2006〜2007年頃)】

データセンタ1


専用1 109 65

データセンタ2


専用1 129 57


8 526 287

データセンタ4


32 574 298

データセンタ3

HOPE

Ima/MARCO

Arorua

Gemini

Kassul FROLIDA

億ＰＶ

年度

ビジネススピードは加速し、アクセス数も急増しインフラ負荷も急激に上がっていた

4箇所のデータセンター、 1400台のサーバで構成エンジニアも各サービスごとに配置



【インフラ統合前(2006〜2007年頃)の課題】

② 頻発する新規サイトの立ち上げ、環境の増改築 → 人件費の増加

③ ビジネススピードの加速 → インフラのサービス提供が追いつかない

① インフラを個別最適で拡張 → 無駄の発生



【インフラ統合前(2006〜2007年頃)の課題】

② 頻発する新規サイトの立ち上げ、環境の増改築 → 人件費の増加

③ ビジネススピードの加速 → インフラのサービス提供が追いけない

① インフラを個別最適で拡張 → 無駄の発生

④ スモールスタート型の新規ビジネスの増加 → 柔軟なインフラ拡張が求められるように

これらの課題解決のため

2009年にDCを統合し、プライベートクラウド (RAFTEL)を構築することに！

データセンタ 1







サイトA用サイトB用サイトC用サイトD用サイトE用サイトF用サイトG用サイトH用

課題① インフラを個別最適で拡張、無駄の発生

DC3

サーバ X社ネットワーク Y社ストレージ Z社

DC4 DC2

サーバ U社ネットワーク V社ストレージ W社

サーバ R社ネットワーク S社ストレージ T社

サーバ O社ネットワーク P社ストレージ Q社

DC1

各サイトの専用のサーバ、NW、ストレージ

リソースが足りない時にはサイトごとにリソース追加

各リソースに余剰があってもサイト間でリソースは共有できない

DCごとに異なるHWベンダ



サイトA用サイトB用サイトC用サイトD用サイトE用サイトF用サイトG用サイトH用

課題① インフラを個別最適で拡張、無駄の発生

DC3

サーバ X社ネットワーク Y社ストレージ Z社

DC4 DC2

サーバ U社ネットワーク V社ストレージ W社

サーバ R社ネットワーク S社ストレージ T社

サーバ O社ネットワーク P社ストレージ Q社

DC1

各サイトの専用のサーバ、NW、ストレージ

リソースが足りない時にはサイトごとにリソース追加

各リソースに余剰があってもサイト間でリソースは共有できない

DCにごとに異なるHWベンダ

個別最適化（分割）による無駄を減らすことが重要！



打ち手① DC統合とリソースの標準化、プール化

サーバの標準化

ネットワークスイッチの標準化

ストレージの標準化

単一ベンダで 2スペックのサーバ

(DBサーバ、Webサーバ)

単一ベンダで単一スペックのエッジスイッチ

単一ベンダで単一スペックの

NASヘッド



サイトA用論理Vol.

サーバプールサイトA用サーバ

サイトB用サーバ

サイトC用サーバ

打ち手① DC統合とリソースの標準化、プール化

ネットワークプール (統合ネットワーク)

ストレージプール (統合ストレージ)

…

…

…

…

…

…

標準サーバ、標準NWスイッチ、標準ストレージによるリソースプールを形成

必要に応じてサイトに対してリソースプールから

サーバ、ネットワーク、ストレージリソースを割り当て

DCを統合することで、ネットワーク、ストレージを統合

サイトA用論理NW

サイトB用論理Vol.

サイトB用論理NW

サイトC用論理Vol.

サイトC用論理NW

統合ネットワーク

統合ストレージ



既存サイトのリプレース

新サービス立ち上げ

アクセス数インフラ費用

インフラコストの約5割はサイト構築＋定常運用の人件費

課題② 新サービス立ち上げ、エンハンス対応人件費の増加

新サービスの構築、既存サイトのエンハンス

個別に検討・設計を実施

構築/運用人件費が増加し続けている

増加傾向にある構築・エンハンスの人件費をどう抑えていくかが重要！



次世代IT統合基盤

インフラ増改築作業、維持運用作業自動化のために…

・自動化プラットフォームの導入

・インフラ構成情報のデータベース化

運用自動化の対象要素既存インフラ

ネットワーク

ハードウェア

OS

言語

フレームワーク

ミドルウェア

基本構築テンプレート手

作業（一部効率化）

個別設定作業

基本構築作業（ﾃﾞｨｽｸｺﾋﾟｰ等）

自動化システム

構成管理DB

運用作業テンプレート

打ち手② エンジニア作業・構成管理の自動化



構成管理機能

構成管理DB

MA

構成管理自動化作業

サーバ基本設定

• RAID設定

•OSインストール

•NFSマウント設定

NW基本設定

•SWポート開放

•ACL設定

•DNS設定

•監視設定

MW設定

• Apacheインストール

• Tomcatインストール

• Sophosインストール

• JP1監視インストール

通信設定

• LB設定

• FW設定

サーバプール

Webサービス

Batchサービス

打ち手② エンジニア作業・構成管理の自動化



新規サイト計画／既存サイトの増改築

調達、設計、構築の各工程で時間がかかっている

（余裕を見越したサイジングの原因）

必要なときにすぐに増設ができないビジネスのスピード感に合わない

ビジネス機会の損失性能問題への対応が遅れる

課題③ ビジネススピードにインフラ提供が追いつかない

発注～納品 (Unixやストレージの場合数ヶ月のことも…)

ラッキング

（サービスイン）

ＬＢ開始

ケーブリング

ＳＷ設定

ＯＳインストール

ＭＷ設定

監視設定

ＬＢ登録

ＦＷ登録

テスト

監視テスト

設計


ラッキング


ＬＢ開始

ケーブリング

ＳＷ設定


ＭＷ設定

監視設定

ＬＢ登録

ＦＷ登録

テスト

監視テスト

設計

各工程の時間をいかに短縮できるかが重要！



打ち手③ プール化と自動化による機動力向上

1w 2w 3w 4w 5w 6w


ラッキング


ＬＢ開始

ケーブリング

ＳＷ設定


ＭＷ設定

監視設定

ＬＢ登録

ＦＷ登録

テスト

監視テスト

標準化されたサーバがサーバプールに存在

5w 1w 6w 4w 3w 2w


ＬＢ開始

ラッキング


ＬＢ開始

ケーブリング

ＳＷ設定


ＭＷ設定

監視設定

ＬＢ登録

ＦＷ登録

テスト

監視テスト

設計

設計

自動化ツールで構築作業を

短縮

Webサーバ増設にかかる時間の比較

機器の発注からサービスインまで最短で6週間

発注のリードタイムが不要のため最短2週間で構築

RAFTEL導入後

RAFTEL導入前



打ち手③ プール化と自動化による機動力向上

1w 2w 3w 4w 5w 6w


ラッキング


ＬＢ開始

ケーブリング

ＳＷ設定


ＭＷ設定

監視設定

ＬＢ登録

ＦＷ登録

テスト

監視テスト

標準化されたサーバがサーバプールに存在

5w 1w 6w 4w 3w 2w


ＬＢ開始

ラッキング


ＬＢ開始

ケーブリング

ＳＷ設定


ＭＷ設定

監視設定

ＬＢ登録

ＦＷ登録

テスト

監視テスト

設計

設計

自動化ツールで構築作業を

短縮

Webサーバ増設にかかる時間の比較

機器の発注からサービスインまで最短で6週間

発注のリードタイムが不要のため最短2週間で構築

RAFTEL導入後

RAFTEL導入前



② 新規立ち上げ、増改築の頻発で増加した人件費

③ ビジネススピードに追随できない構築スピード

① 個別最適の拡張で発生していた無駄

「RAFTEL」で採用した打ち手と成果

サーバ構成/配置の統一。余剰リソースの利用効率向上 N/W、ストレージの統合/仮想化。論理的に個別利用

エンジニア作業、構成管理を自動化。機動性up＆省力化サーバ、ストレージ、ネットワークリソースのプール化





【パブリッククラウド利用状況(2010年頃)】

ライバル企業に対する優位性を確立するために『小さく、軽く』開発できるパブリッククラウドの利用が拡大

サービス立ち上げ期に開発者主体で使えるインフラサービスの需要が発生

パブリッククラウド

Aサービス Zサービス・・・

Bサービス



【パブリッククラウド利用時の課題】インフラだけならすぐに作れるが。。。

② 個別に非機能要件の作り込み → 作り込みに時間がかかる

① 個別にセキュリティ対応 → セキュリティ対応に時間がかかる



【パブリッククラウド利用時の課題】インフラだけならすぐに作れるが。。。

② 個別に非機能要件の作り込み → 作り込みに時間がかかる

① 個別にセキュリティ対応 → セキュリティ対応に時間がかかる

これらの課題解決のため

パブリッククラウド


パブリッククラウド (Rクラウド)


共通機能（セキュリティ、非機能対応）

2011年からプライベートクラウド(Rクラウド)を構築し、順次共通機能の提供を開始！



【プライベートクラウド⇄パブリッククラウド】パブリッククラウドに対して専用線経由でアクセスすることでセキュアかつ高品質なアクセス経路が確保され、様々な連携が可能に



専用線






専用線

ログ取得用踏み台サーバ

ログイン認証サーバ

・操作ログを取得

既存業務フローを最大限活用し、パブリッククラウドに対しても監査機能の有効化






専用線

ログ取得用 FTP サーバ


・ログイン履歴を取得

ファイルアップロードも既存運用を変えることなくセキュリティ運用を担保

・ウィルスチェック






専用線

ログ取得用 FTP サーバ


Zabbixを用いて監視を実施しています



【プライベートクラウド⇄パブリッククラウド】



専用線

監視サーバ CIサーバ

モニタリングサーバ

Gitサーバ

Webサーバ

4.まとめ〜プライベート／パブリッククラウドの運用から


4.プライベート／パブリッククラウドの運用から


【まとめ】

プライベートクラウドでもパブリッククラウドでも共通化、自動化はコスト、効率、スピードアップ

にとても有効。ただし、作り上げたものを維持する必要があり、逆にネックになる場合も

共通化、自動化を過剰に行うのではなく、ビジネスの状況を見て、場合によっては部分最適

も良しとする、そのバランスが非常に重要

4.プライベート／パブリッククラウドの運用から


とはいえ。。。

ビジネススピードが以前と比べて格段にあがっている中、どこでバランスとればいいの？という疑問が当然あると思っております。是非、情報交換させて頂ければと思っておりますので、気軽にお声掛けください

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

リクルートテクノロジーズ

Technology

リクルートのWebサービスを支える「RAFTEL」