リクルート流SRE インフラ運用がサービスを変える世界

リクルートテクノロジーズ ITエンジニアリング本部サイトリラアビリティエンジニアリング部河村聖悟リクルート流SRE インフラ運用がサービスを変える世界

(C) Recruit Technologies Co.,Ltd. All rights reserved. 2 Recruit Technologies
Site Reliability Engineering リクルートテクノロジーズ紹介

Site Reliability Engineering リクルートグループについてリクルートは2012年10月に分社化、2014年10月に上場しています。創立 1960年3月31日「大学新聞広告社」としてスタートグループ従業員数 45,688名（2017年3月31日時点）連結売上高 18,399億87百万円（2016年4月1日～2017年3月31日）連結経常利益 1,317億18百万円（2016年4月1日～2017年3月31日）グループ関連企業数 357社（連結対象子会社、2017年3月31日時点）目指す世界観「あなた」を支える存在でありたい

Site Reliability Engineering （株）リクルートの事業内容について選択・意思決定を支援する情報サービスを提供し、「まだ、ここにない、出会い。」を実現する。旅行ビジネス支援生活/地域情報グルメ・美容ライフスタイル領域ライフイベント領域進学就職結婚転職住宅購入車購入出産/育児

Site Reliability Engineering リクルートのビジネスモデルについてユーザーとクライアントを新しい接点で結び、「まだ、ここにない、出会い。」の場を創造する。リクルートには、ユーザーとクライアントという2つのお客様が存在します企業と人（B to C）、企業と企業（B to B）、人と人（C to C）、すべての間に立ち、双方にとって最適なマッチングを図る「場」を提供しています

Site Reliability Engineering リクルートグループにおけるリクルートテクノロジーズについてリクルートテクノロジーズは、リクルートグループの IT・ネットマーケティング領域のテクノロジー開発を担う会社ですリクルートホールディングスリクルートキャリアリクルート住まいカンパニーリクルートライフスタイルリクルートジョブズリクルートマーケティングパートナーズリクルートテクノロジーズリクルートスタッフィングスタッフサービス・ホールディングスリクルートコミュニケーションズメディア & ソリューション事業（株）リクルート人材派遣事業 Recruit Global Staffing B.V. HRテクノロジ― 事業 RGF OHR USA, Inc. その他海外派遣グループ会社 Indeed,Inc.

Site Reliability Engineering リクルートテクノロジーズの役割について技術・ソリューションを磨き続け、リクルートの各サービスがもつ価値を最大限に発揮できるようビジネスへ実装。ITの側面からサービスを進化させることを通じて、世の中に新しい価値を提供していきます。

Site Reliability Engineering リクルートテクノロジーズの事業内容について将来のニーズを見据え、新しい技術のR＆D・ソリューションの開拓を実現。検証を続け、いち早く活用できるレベルに引きあげることで、中長期的なビジネス競争優位を構築していきます。

Site Reliability Engineering リクルートテクノロジーズの組織構成についてリクルートテクノロジーズは5つの統括本部で構成されています。各統括本部の下に、さらに部・グループが続きます。企画統括本部 ITマネジメント本部リクルートテクノロジーズ ITマーケティング本部 ITソリューション本部経営企画、広報、経理/人事/総務ほかいわゆるスタッフ部隊事業と一体となり、開発ディレクションやエンハンス、大規模開発プロジェクトの推進を担う UXデザイン、ウェブマーケティング基盤の開発、サービスデザインの検討から実装を担うサービスプロダクトの開発、サービスインフラやAP基盤の開発、運用を担う ITエンジニアリング本部リクルート全社の基幹システムや共通インフラ、セキュリティ等のソリューションを提供する

Site Reliability Engineering SREとは

Site Reliability Engineering そもそもSREとは？ • 「サイト信頼性の向上」を命題におく • 運用オペレーションにソフトウェアの「知識」を持ち込む

Site Reliability Engineering ソフトウェアの「知識」を持ち込む事とは • 自動化実装・OSS導入が全てではない • ソフトウェア開発工程の全てが運用に活きる • 全てをS/W化せずいらないものは捨てる

Site Reliability Engineering 今日の話のポイント

Site Reliability Engineering 今日話したいこと • SREを通じてやってきた事と、それを通じて学んだ事をシェア • 「運用はクリエイティブなもの」 • どんな環境でも運用は改善できる

Site Reliability Engineering 話したいけど細かく話さないので検索を！ • 「リクルート SRE」 • 「RAFTEL Fleet」 • 「リクルートテクノロジーズ kubernetes」 • 「リクルートテクノロジーズ rancher」

Site Reliability Engineering やってきた事を説明する前に、背景

Site Reliability Engineering そもそもなんで改善施策を行おうとしたのか？ • 贔屓目にみてもうまくいってなかった • どう見ても大人数で全員サッカー • コミュニケーション大変そう • 何営業日もかかる • その作業、手動でやる必要あるのか？ • トリプルチェック

Site Reliability Engineering リクルートだから改善やりやすいとかは特にない • リクルート流といいつつ他の会社と特に変わった背景はない • エンタープライズ環境あるある • だれしもが先進的かというとそうでもない • 古い技術・慣れた仕組みはそれで大事

Site Reliability Engineering リクルートのシステムは新旧入り混じっている • 大規模サイトは変わらずオンプレミス上 • 仮想化はVMWare、一部NSX導入してS/W化 • 基幹インフラは物理一曲集中 • ゲストOSはRedhat、まれにUbuntu • クラウド利用は増加傾向 • AWS/GCP/Azure • k8s + dockerなんて構成もある

Site Reliability Engineering やりやすさも他の会社と同じ • はじまりは一人から • 常に準備して機会を狙う • 唯一のリクルートらしさは「なぜやるの？」を聞かれる

Site Reliability Engineering ここからの話は • 遠い世界の出来事ではない • やろうと思えばできる話も多数あります！

Site Reliability Engineering リクルートのSREはどんな事をやってきたか

Site Reliability Engineering 現状を知る • まずは現状を知りつくす • 自分の担当範囲を越えて知ろうとする

Site Reliability Engineering 仕組み化を考える • 情報が揃ったら、仕組み化（フロー化）を考える • できるだけシンプル化する • その過程で、現フローの無駄や課題を見つける

Site Reliability Engineering 仕組み化の前に考えた事 • システムの運用やメンテナンスを見据えて自動化する • 無理な自動化は負荷を生む（メンテナンスコストもかかる）

Site Reliability Engineering 自動化は「時間を作り出せるか？」で考える • なんでもかんでも自動化で解決するわけではない • ポイントは「その自動化が（他に使える）時間を作り出すか」 • 自動化が余計な仕事を作り出していないか？ • ひとりよがり（俺すごい）はよくない

Site Reliability Engineering 自動化が効果的でない例部分的な自動化は作業を作り出したり、トータル時間が変わらなかったりする手作業A レビュー手作業B レビュー引き継ぎ記録自動化 A レビュー自動化 B レビュー引き継ぎ記録結果の変換実施結果の調査 time time 自動化で短縮自動化Bに渡すため変換作業が増加自動化実施した結果を目視で転記トータルでかかる時間は同じ

Site Reliability Engineering 自動化で時間を作り出す例手作業A レビュー手作業B レビュー引き継ぎ記録 time 自動化 A 自動化 B time 自動記録自動化で短縮次の自動化にそのまま連携ルールにそって値をバリデーション記録できるツールに API連携で書き込み「時間を作り出した」と言える

Site Reliability Engineering どんな自動化を実施したかの例 • どんな自動化かに取り組んだか、は本題ではないので飛ばす • サーバ構築のAnsible化 • ドキュメントのGoogle Spread Sheet化 • 申請自動化 • Excel申請のJira化による集計自動化 • Confluence記載フォームからのJiraチケット作成 • WebGUI経由の自動化（独自実装） • ストレージサイズ拡縮自動化 • DNS申請自動化 • FW設定棚卸し • WebGUI経由の構築フル自動化（Fleet） • サーバ構築・NW構築・FW設定迄含めた自動化・払い出し • NW仮想化：VMWare NSX + F5 VA • Rancher + Dockerによるマイクロシステム化された部分実装可能なオーケストレータ • Slackボット（議事ページ自動作成・空調・Mac/Win CIFS変換・PDF印刷）

Site Reliability Engineering 抵抗にあらがう • 改善・改革は、なにかしらの抵抗にあうが、とにかく話に行く • 運用は「変えない事」で短期的には安定する • 運用は減点方式で採点されることが多いので、余計な事はしたくない • ネゴが大変だったら実行してしまう • 運用フローのInとOutを変えずに、中身だけ入替える • 便利（高速・手間いらず）になってれば人は後からついてくる

Site Reliability Engineering あきらめずにしっかり説明する • 中長期でみると「変えない事」により品質が下がる • システムが変わらなくても、人は変わってしまう • 自動化より手動のほうが安心というのは都市伝説

Site Reliability Engineering 属人性を剥がす • 属人性は品質を下げる • 仕組み化を考える「過程」は、属人性はがしに有効に働く • 背水の陣（多少つらくても配置を変えてしまう） • さじ加減大切

Site Reliability Engineering いらないアラートを潰す • アラートを潰す • メンバが考えてくれた、べたでもっとも有効な運用効率化 • 障害発生してもほっといてもいいシステムなら記録だけ残す

Site Reliability Engineering コミュニケーションをオープンに • インフラだけに閉じず、広く関係者に話す • インフラ（OPS）に対してフランクに相談できる環境を作る • 閉鎖的なコミュニケーションのコストは尋常じゃない • チームにとじたツールは全廃する

Site Reliability Engineering 部署をわけてもっとサービスに寄せた • サービスに寄り添って会話できる組織体制をつくった • 温度感とかすごく伝わるので距離（ロケーション）は重要 • ただ反省として役割定義は明確にしておく必要がある

Site Reliability Engineering 「インフラ作業申請」の形を変える • （インフラ部署が開発部隊と別れている人向けの話） • 申請内容の人間のチェックとか大半は不要 • 複雑な暗黙ルール（フリーフォーマット）を減らす • ロケーションを近くして、会話して、記録を残す

Site Reliability Engineering 監視・モニタリングを変える • （監視用コールセンター利用中の方向け） • ログを目視確認して人手で電話という状況は全体障害に弱い • 監視はASPで自動化（Datadog / Pagerduty） • メトリクスはあらかじめ絞り込まず最初は全部とってから絞る

Site Reliability Engineering 組織として振り返る • 失敗したら減点、失敗した人を怒る風土をやめる • 失敗のカバーは「その作業をやらなくていい仕組み」で • 振り返る・個人ではなくチームでどう立ち向かうか？ • 前向きに振り返る

Site Reliability Engineering 技術的な物差しを世の中にあわせる • 自社独自の世界観だけに詳しいのはアンチパターン • 技術の物差しを世の中にあわせる（古くても良い） • 対外活動を積極的に推奨する • 外部エンジニアが当たり前に持っている環境を与える • macbook / GitHub / Container Repository / slack / hubot / jira / confluence ...

Site Reliability Engineering リクルートのインフラ運用はどう変わったか

Site Reliability Engineering 結果、リクルートの運用は、どのぐらい変わったか？ • 定常運用人数は１年で５０人減 • オンプレミスの運用サーバ数は右肩あがり • 対応チケット数は２年前の約３倍 • 内部・外部への発信回数・連載記事も１年前の数倍に

Site Reliability Engineering 得た気づきを共有します

Site Reliability Engineering べたな改善の積み重ねで運用は変えられる！ • 自動化は本質ではなく、べたな改善の積み重ねが重要 • 「作業フロー」のほうが実は改善しどころ • アイデア次第で改善はどうとでもなる • 本当に解決したかった事は何か？ • 自動化をやるなら、バランス感覚が大切

Site Reliability Engineering 自動化をすすめてわかった事 • 部分的な自動化は、全体でみると実はあまり手間が減らない • 自動処理よりも「今の設定を表示する見える化」が効果的 • ルール判定の自動化は人の判断よりも正確でミスがない • メンテナンスコストかかるが手動作業失敗時より手間は少ない

Site Reliability Engineering トイル（不要な雑用）を見抜いて変える • 作業はとりあえず全部把握する • 改善する作業の全量・頻度をただしく把握する • 自動化＝トイル撲滅ではない、要は無くせばいい • 冷静に見抜く

Site Reliability Engineering 運用改善をやるには王道なし • リソースを何も変えずに改善するのは「無理」人定常作業改善人定常作業改善人定常作業人定常作業改善増員仕事量通常ダメ難易度高い良い人を増やして改善施策定常作業を減らして改善施策改善施策をそのまま押し込む

Site Reliability Engineering 疑う • 本当にその作業、必要？ • 今いらないものは勇気をもって捨てる • なんとなく納得して実行し続けてることは山ほどある • いるかいらないかは広い視野で捉える

Site Reliability Engineering 運用で守るべきものをもう一度考える • インフラ機材を全部正常に動かすことが運用ではない • インフラ機材だけが動いてたってあまり意味がない • 障害時に捨てられる設計がとれるか？ • サービスレベルにあわせたリスクマネジメント • 24/365の全員サッカーにならないようにする

Site Reliability Engineering サービスは良くなったのかを考える • 大事なのは、サイトが快適に動作し続けられるかどうか • サイトリライアビリティというからにはサイト信頼性重要 • 今やろうとしてる改善、工夫は、誰にとってよくなる事か？ • 安定的にかつ、サイトを効率的に保てるかの視点を持ち続ける

Site Reliability Engineering やってみる • その改善は慎重に対応しなといけない事か？ • 守るところと攻めるところをはっきりする • 守る：本番インフラ環境で「とりあえずやってみる」なんて愚策 • 攻める：単に作業フローを変える事を「慎重に検討」してたらもったいない！ • 検討だけだと全部白紙撤回しがち（進まない） • 攻めるポイントでは、「やってみる」を積み上げる

Site Reliability Engineering 満点を目指さない • インフラ運用は減点方式なので満点から始まりたい人が多い • 改善できるなら、やってみられることはやってみる • １００点とれないからやらないなら、何も変えられない • ただ、何かあった時に「元に戻せるか？」は考えておく

Site Reliability Engineering 挑戦できる土壌を作る • 個人の失敗を責めない • 失敗を振り返り、前をむける部署は、改善を提案しやすい • 減点方式にしない • 挑戦しないでミスするようなら考え直したほうがいい • 変えないからこそ、問題がおきやすいという考え方は大事

Site Reliability Engineering ちゃんと振り返る • 失敗/障害は振り返りのミーティングに時間をかける • ひたすら事象や構造を振り返り、仕組みをなんとかする • チームとして今後どうしたら防げるのか？もっとよくなるのか • 運用改善の芽が見つかる重要な行動 • 次に活かす（その分だけ改善は進む）

Site Reliability Engineering リクルートのSREはこれから何をやっていくのか？

Site Reliability Engineering サービスを構成する機能要件と非機能要件 • サービスは機能要件と非機能要件から成り立つ • 機能要件： WEBアプリの機能 • 非機能要件：性能・速度・快適さ • ユーザがサービス利用する時、２側面のどちらも大切

Site Reliability Engineering リクルートは「機能要件」でビジネスがなりたっている機能を追加、効果をBIツールでチェックし改善を測るサイクルサービスクライアント・カスタマ横断インフラ（オンプレ・クラウド）事業・開発＆事業インフラ（M/W以上） BI モニタリング機能分析機能開発

Site Reliability Engineering リクルートSREがこれからやりたいこと「非機能要件」から状態を見える化して改善サイクルを作るサービスクライアント・カスタマ横断インフラ（オンプレ・クラウド）事業・開発＆事業インフラ（M/W以上）非機能モニタリング非機能性能改善・非機能性能分析・基盤インフラ改善・SRE機能

Site Reliability Engineering 一旦全部見える化した先には • おかしなところは全部見えるようにしてから「気づく」 • 最初から予想とか勘で、問題点を絞ってしまわない • 意外なところにあるボトルネックを見つけて解消していく

Site Reliability Engineering 非機能要件の見える化によって見つかる簡単な問題の例 • 多段にリダイレクトがかかり表示が遅くなっていたが機能は動作していた • 特定のページのリンクから大量に４０４リクエスト • 大量に５xxが起きているマイナな機能があった • 一見問題なくうごいているが定期的にサーバエラーが増える時間があった • 特定の曜日の特定の時間にグラフでならされると気づかない突発のスパイクが発生していた • 軽いからといって見過ごしていたSQLクエリが想定以上に大量に発行されていて重い • time_waitが溢れていた • 無駄なリクエストがリクエストのトップ１０に入っていた • 専用線の通信が特定の時間に限界を迎えパケットロスしていた • いずれも使い手から見ると「サービス」の快適さに影響するもの

Site Reliability Engineering これからなにをやろうとしているか？ • 運用から非機能の状態を徹底的に見える化 • インフラからサービス全体をみた改善サイクルを作り出す • インフラ運用がサービスを変えるというクリエイティブな世界

Site Reliability Engineering 終わりに

Site Reliability Engineering 終わりに • 運用はアイデアで変えられる「クリエイティブなもの」です • 技術を取り入れるも良し、フローを変えるも良し、選択肢は多い • インフラがサービスを変えていく世界が目の前にあります • どんな環境にも変えていくチャンスはあります

リクルート流SRE インフラ運用がサービスを変える世界

リクルート流SRE インフラ運用がサービスを変える世界

More Decks by Recruit Technologies

Other Decks in Technology

Featured

Transcript