SRE in UZABAS

Transcript

1. hbstudy #82 SRE 大全 UZABASE SRE
2. 自己紹介 羽山雄偉 株式会社ユーザベース　SREチーム インフラエンジニア 前職も某ゲーム会社でソーシャルゲームのインフラエンジニア 4年前にユーザベースにジョイン 主にSPEEDAと社内インフラを担当 ・SPEEDAではネットワークやサーバ構築を実施 ・社内インフラでは引越時のインフラ構築や上場時のIT統制などを実施
3. • UZABASEについて • UZABASEのSREについて • SPEEDAにおけるSREについて • SPEEDAの環境 • 開発チームとの連携 • SREの取り組み事例 Table of Contents
4. UZABASEについて
5. Mission 経済情報で、世界をかえる Business Intelligence to Change Your World 私たちは、世界中で愛される経済情報インフラをつくります。 あらゆる経済情報を人とテクノロジーの力で整理・分析・創出し、 ビジネスパーソンの生産性を高め、創造性を解放します。 私たちは経済情報を通じて世界中の意思決定を支え、世界をかえます。
6. Our Services B2Bマーケティングエンジン ソーシャル経済ニュース 企業・業界情報プラットフォーム 日本最大級のベンチャーデータベース 2009年 2008年 創業 2014年 2016年 2017年
7. • 各サービスごとに1テックチーム ◦ SPEEDA/NewsPicks/entrepedia/FORCAS • Tech Culture ◦ 技術的にも挑戦する文化（k8s,micro services, micro frontend） ◦ 社内ハッカソン (http://tech.uzabase.com/entry/2018/02/22/141810) ◦ 社内ISUCON Tech Team in UZABASE
8. UZABASEのSRE
9. SREについて • 昨年10月にSPEEDAテックチームにSREを設立 • 前身は開発チームの運用メンバーとインフラチーム • テックチームは全体で30名 ◦ 開発チーム20名 ◦ SREチーム10名 • ソフトウェアエンジニア5名、インフラエンジニア5名で構成
10. SREの活動 • 技術力向上の推進 ◦ チーム内でk8s合宿を実施 （http://tech.uzabase.com/entry/2018/02/01/1614 ） • 情報共有の推進 ◦ SRE Loungeで情報・取り組みを共有 (http://tech.uzabase.com/entry/2018/01/26/200021 ) ◦ Tech Blogを使った技術発信 (http://tech.uzabase.com )
11. • SPEEDA ◦ インフラ＋ソフトウェアで新機能開発以外を担当 ▪ インフラの構築運用 ▪ サービス・ジョブの運用 ▪ プロダクト改善、本番バグ対応、社内ツール開発 • 社内 ◦ オフィスネットワーク構築運用 ◦ 社内システム・PC・各種アカウント管理 ◦ コーポレートサイト、各サービスのLPサイトの構築運用 SREの業務範囲
12. SPEEDAにおけるSREについて
13. • 安定稼働のために出来ることはすべてやる • ユーザが快適に利用できる状態にするために出来ることはすべてやる 基本的な方針
14. • オペレーション ◦ ジョブ・システム監視 ◦ 各チームからの問い合わせ対応 • インフラ基盤管理 ◦ リソース管理、負荷対策、CDN ◦ セキュリティ対策 • ソフトウェア開発業務 ◦ SPEEDAのバグ対応、高速化 ◦ 周辺ツール開発 SPEEDAにおけるSREの業務内容
15. SPEEDAにおけるSREの業務範囲 インフラ構築 バグ対応 サービス運用 新規開発 インフラ運用 社内ツール作成 問い合わせ対応 開発チーム SREチーム サービス改善
16. SPEEDAの環境
17. • ビジネスパーソンの情報収集・分析における課 題を解決する最先端のプラットフォーム • 世界中の企業情報、業界レポート、市場デー タ、ニュース、統計、M&Aなどあらゆるビジネ ス情報をカバー https://www.ub-speeda.com SPEEDAとは？
18. • アプリケーションサーバ ◦ JVMメモリ60GB • ジョブ ◦ 総数4000件 ◦ 24x365での稼働 • 総データ量 ◦ データベース: 約3T ◦ 検索インデックス：約3T ◦ ファイルデータ：約3T システムの特徴
19. • オンプレミス環境 • ネットワークから仮想サーバまでを管理 • DBはioDriveを搭載した物理サーバ • 3つの仮想基盤から構成されている • ラック内で適切な電力使用量になるようなサーバ配置 • ハードウェアトラブルは自動検知 SPEEDAを支えるインフラ基盤
20. 仮想基盤 v1 • 単体のアプリケーション • XenServer • ゴールデンテンプレートでの仮想 サーバ構築
21. 仮想基盤 v2 • マイクロサービス化 • XenServerクラスタ • Ansibleでの仮想サーバ構成管 理
22. 仮想基盤 v3 • マイクロサービス化 • Kubernetes on Rancher 基盤 • cloud-initでの構成管理 • Dockerコンテナでのアプリケー ション管理
23. 開発チームとの連携
24. • 開発速度を早くするために出来ることはすべてやる 基本的な方針
25. • Face to Faceでの会話が基本 • リモートのやりとりはSlackを利用 • テックミーティングで週1回情報共有 • ハッカソンなどで開発メンバーと共同開発 コミュニケーション
26. • 開発環境は開発チームが管理・運用している • 開発サーバの異常はSlackに発報される • 本番のデータが必要になるケースはジョブ化 開発環境
27. SREの取り組み事例
28. 差し込み業務への取り組み
29. • 外部要因で差し込み業務が発生し、進めているプロジェクトに集中できないこと がよくある • 一方で、差し込み業務への対応も安定稼働を支えるSREの重要な業務である • 差し込み業務の種類 ◦ 障害 ▪ システム障害 ▪ バッチ障害 ◦ 問い合わせ ▪ データ異常 ▪ バグ 運用チームでありがちなこと
30. 差し込み業務とプロジェクトを両立するためにやっていること • 業務のシフト化（負荷軽減・属人性の排除） • 問い合わせ対応時間の固定化（時間の二極化） ◦ 緊急度の高いもの以外はこの時間で対応する ◦ 緊急案件についてはCSの判断で直接連絡をもらう ▪ 緊急度の認識をCSとすり合わせておくことが重要 • 差し込み業務の削減（根本対応） ◦ 差し込み頻度の高いもの、差し込み負荷の高いものは原因の解決と自動 化を行う 差し込み業務への取り組み
31. 自動化への取り組み
32. • 定常業務の自動化 • リリースの自動化 ◦ Slackを使ったChatOps ◦ Jenkinsを使ったCI/CD • 状況はSlackに通知 自動化への取り組み
33. まとめ
34. • UZABASEにおけるSREは新機能開発以外を担当 • 安定稼働、ユーザ体験向上のために出来ることはすべてやる • 開発速度を早くするために出来ることはすべてやる • 開発環境は開発チームで運用し、SREはサービスを運用する • 差し込み業務を対応しつつ、プロジェクトを進めるため試行錯誤の日々 • 自動化、効率化を進め、必要に応じて社内ツールの開発も行う まとめ
35. ありがとうございました
36. Any questions? Thank you for listening！