Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
モンスターストライクの信頼性を支えるSREの組織化について / Internet Week 2017
Isao Shimizu
November 29, 2017
Technology
0
1.8k
モンスターストライクの信頼性を支えるSREの組織化について / Internet Week 2017
Internet Week 2017
S15 高信頼性運用を実現するSREという新潮流
2017年11月30日(木) 16:15 ~ 18:45
Isao Shimizu
November 29, 2017
Tweet
Share
More Decks by Isao Shimizu
See All by Isao Shimizu
海外ユーザーのレスポンスタイム を可視化して改善した話 / Improved response times for users worldwide
isaoshimizu
1
66
約6年間運用したシステムをKubernetesに完全移行するまで/Kubernetes Novice Tokyo
isaoshimizu
6
1.4k
1,000万人以上が利用する「家族アルバム みてね」のSRE組織は4年間でどのように作られてきたのか/SRE NEXT 2022
isaoshimizu
7
9.6k
SREグループのマネージャーという立場になって真っ先にやったこと
isaoshimizu
5
1.7k
開発者とSREの役割、責任/SRE Lounge 13 LT
isaoshimizu
6
2.4k
世界中のユーザーが快適に利用できるクラウドネイティブなシステムを目指して/#CNDT2021
isaoshimizu
1
400
Ruby on Rails x Kubernetes におけるObservability / Rails x Kubernetes Observability
isaoshimizu
2
1.3k
利用者数800万人突破の「家族アルバム みてね」に学ぶ クラウドセキュリティの勘所/Cloud Security Tips
isaoshimizu
6
2.3k
「家族アルバム みてね」におけるAmazon EKSへの移行の取り組み / CNBF 202001
isaoshimizu
5
1.4k
Other Decks in Technology
See All in Technology
💰年度末予算消化祭💰 Large Memory Instance で 画像分類してみた
__allllllllez__
0
110
Dockerに疲れた人のためのLXDではじめるシステムコンテナ入門
devops_vtj
0
120
OCI技術資料 : ロード・バランサー 詳細 / Load Balancer 200
ocise
2
7.2k
創業1年目のスタートアップでAWSコストを抑えるために取り組んでいること / How to Keep AWS Costs Down at a Startup
yuj1osm
3
2.2k
CSS Variable をもっと活用する / Kyoto.js 18
spring_raining
2
1k
目指せCoverage100%! AutoScale環境におけるSavings Plans購入戦略 / JAWS-UG_SRE_Coverage
taishin
0
520
開発者と協働できるメトリクスダッシュボードを作ろう!/SRE Lounge 2023
lmi
3
530
Exploring MapStore Release 2022.02: improved 3DTiles support and more
simboss
PRO
0
390
ユーザーテストガイドライン VERSION 2.0
kouzoukaikaku
0
1.5k
API連携に伴う規制と対応 / Regulations and responses to API linkage
moneyforward
0
160
Hatena Engineer Seminar #23 「チームとプロダクトを育てる Mackerel 開発合宿」
arthur1
0
610
OVN-Kubernetes-Introduction-ja-2023-01-27.pdf
orimanabu
1
450
Featured
See All Featured
Three Pipe Problems
jasonvnalue
89
8.9k
A better future with KSS
kneath
230
16k
Building a Modern Day E-commerce SEO Strategy
aleyda
6
4.5k
Automating Front-end Workflow
addyosmani
1351
200k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
217
21k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
101
6.2k
No one is an island. Learnings from fostering a developers community.
thoeni
12
1.5k
Practical Orchestrator
shlominoach
178
8.9k
The Brand Is Dead. Long Live the Brand.
mthomps
48
2.9k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
31
20k
The Illustrated Children's Guide to Kubernetes
chrisshort
22
43k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
22
1.7k
Transcript
モンスターストライクの信頼性 を⽀えるSREの組織化について 株式会社ミクシィ XFLAG スタジオ ゲーム開発室 SREグループ 清⽔ 勲 Internet
Week 2017 S15 ⾼信頼性運⽤を実現するSREという新潮流
2 ⾃⼰紹介 清⽔ 勲 / Isao SHIMIZU @isaoshimizu 株式会社ミクシィ XFLAG
事業本部 ゲーム開発室 SREグループ 所属 経歴 • SIerで受託開発、⾃社プロダクト開発、運⽤を約8年 • 株式会社ミクシィ • 2011.8〜 運⽤部 アプリ運⽤グループ所属、SNSの運⽤ • 2014.4〜 モンスターストライクの運⽤にジョイン • 2015.8〜 XFLAG スタジオが創設される • 2016.7〜 XFLAG スタジオにSRE グループ創設
3 ミクシィグループ 2017年11⽉8⽇ 2018年3⽉期 第2四半期 決算説明会資料より抜粋
4 XFLAG スタジオ • スマートフォン向けゲーム • モンスターストライク(2013.10〜) • モンストスタジアム(2015.4〜) •
ファイトリーグ(2017.6〜) • 動画 • モンストアニメYouTube配信(2017.6.14に世界累計再⽣回数2億回突破) • 昨年末には劇場版も公開 • XFLAG STORE SHIBUYA(常設店舗) • XFLAG STORE(オンラインストア) • その他
5 SRE という組織ができるまでの 変遷についてお話します
6 モンスターストライク以前
7 モンスターストライク以前 • かつては運⽤部という組織で、SNS「mixi」の運⽤に取り組んでいた • インフラ、アプリ運⽤という2つのグループ • インフラ • サーバー調達、ネットワーク設計・構築などがメイン
• インフラエンジニアと呼ばれたり • アプリ運⽤ • サーバー構築、負荷対策、デプロイ、チューニングなどがメイン • 運⽤エンジニアと呼ばれたり • 運⽤部と連携する「たんぽぽグループ」
8 たんぽぽグループ • 2008年頃、「刺⾝の上にタンポポをのせる仕事」 のような単純作業の仕事 から社内開発者を解放しよう、というミッションのもと設⽴ • 「開発者のための開発」をおこなう組織 • サービスがどうあるべきかという⼤局的な視点に⽴って、すべてのシステム
に横断的に関わる組織 • コアアーキテクチャの検討、開発⼯程の改善、改善のためのツールの導⼊検 討、パフォーマンスチューニング、アルゴリズム改善、海外向けサービスプ ロジェクトのサポートなど • 開発・運⽤がスムーズに進むように • 現在においてもXFLAG スタジオ内で同様の取り組みをおこなっている
9 当時のシステム・インフラ • 〜2013年くらいの話 • SNSのシステム • サーバー • 1つのDCにオンプレミス(数千台)
※いまはAWSに移⾏済み • OS • Fedora 8から17へ ※いまはCentOS 7.1 • プログラム⾔語 • Perl 5.8系から5.14系へ • ミドルウェア • Apache 2.2系(mod_perl, mod_proxy)、Percona Server 5.1、Memcached 1.4.5 • ソースコード管理 • SubversionからGitへ(Gitolite → GitHub Enterprise) • コミュニケーションツールはIRCがメインだった
10 当時の課題 • 主に負荷対策、効率化、コスト削減 • 課題、取り組んできたことの⼀例 • MySQLの負荷対策、ioDriveでの集約化 • 古いOS、古いミドルウェア、Perlのアップデート
• OpenStack導⼊ • systemd対応 • デプロイ、プロビジョニングの改善 • コンテナ化 • その他いろいろ • JIRAで課題管理、アサイン、作業の実施 • Confluenceでドキュメント作成
11 モンスターストライクの登場 2013年10⽉
12 「モンスターストライク」利⽤者数推移 2017年11⽉8⽇ 2018年3⽉期 第2四半期 決算説明会資料より抜粋
13 モンスターストライクリリース後 • 2014年前半からは、新機能の開発と平⾏して負荷対策に注⼒していた • スケールアップ • ⾼負荷のマシンはAWSからオンプレへ(⾃社インフラの活⽤) • AWSも併⽤する。Direct
Connect(専⽤線)フル活⽤。 • SSDやioDrive(PCIe SSD)の活⽤ • スケールアウト • DB分割(テーブル分割、シャーディング) • DBチューニング • ソースコードの改善 • クエリ改善 • キャッシュの活⽤(Memcached) • コミュニケーションはIRC → HipChat → Slackへ • ソースコード管理はGitHubに統⼀
14 SRE グループ設⽴ 2016年7⽉
15 SRE について • Site Reliability Engineering • Googleが提唱し、Facebook、Dropbox、メルカリ、クックパッド、サイボウズなど、 最近では多くの企業が取り⼊れてきた(組織として存在する)
• システム運⽤、可⽤性向上、⼈⼿で⾏ってきたことの効率化・⾃動化など • 運⽤業務よりもソフトウェアエンジニアリングに割く時間の割合が多め • 書籍「SRE サイトリライアビリティエンジニアリング――Googleの信頼性を⽀えるエ ンジニアリングチーム」 • https://www.oreilly.co.jp/books/9784873117911/ • Googleのサイトでは英語版が無料で読める http://landing.google.com/sre/book.html • 最近では、SREに関するイベントや勉強会も増えてきている
16 XFLAG スタジオにおけるSRE グループについて • 求められること • サービスに何が起きていて、何をすべきか理解すること • 当たり前のことを優先度付けして能動的にやれること
• 視野を広くして俯瞰して⾒られること • ソフトウェア・エンジニアリングによって徹底的に信頼性を向上させること • 変わったこと • 社内&社外からもわかりやすい組織体制 • ゲームに関わる機能開発からの分離 • 負荷対策、効率化、⾃動化などに注⼒ • 従来と変わらないこと • メンバーの得意不得意を相互に補完 • 運⽤業務
17 XFLAG スタジオにおけるSRE の業務内容 • モンスターストライクの負荷対策 • クエリ改善、キャッシュ利⽤の効率化、DB分割、チューニングなど • リソース⾒積もり、ベンチマーキング
• 可⽤性向上(壊れにくいハードウェア選定、ミドルウェア構成) • データのバックアップ • リリースエンジニアリング(デプロイ、プロビジョニング) • 物理マシン、クラウドのリソース設計と最適化 • ⾃動化、ツール開発 • 監視、モニタリング改善 • 各種Webサイト構築 • 新規案件相談、モック開発 • セキュリティ対策 • 障害対応(オンコール対応) • その他
18 オンコール対応 • 定時外、休⽇の緊急時に⼀次対応するための制度(当番制) • 2007年頃から制度化 • 2名体制、1週間でローテーション • 対応例
• ハードウェア故障対応(メモリ、電源、SAS、SSDなど) • 負荷増への対応 • クラウド障害対応 • いまではPagerDutyフル活⽤ • 以前はNagiosからのメール受信のみだった • 様々な通知(電話、メール、プッシュなど) • 当番が通知に気づかなかった場合、当番外へ⾃動エスカレーション
19 仕事の進め⽅ • それぞれが能動的に⾏動し、今やるべき仕事は⾃分で⾒つける • マネージャーからはチームの⽅向性の調整のみ • 使いたい技術はメンバーの合意を得て積極的に導⼊する • 例えば、プログラム⾔語、クラウド、ミドルウェア、ツールなど
• Slackのチャンネルで議論 • ダイレクトメッセージではなくチームのチャンネルでおこなう • GitHub上でのコードレビュー必須 • Pull Request、Issue上で⼤半の課題は解決する • テストとレビューが通り、masterにマージされたらデプロイする • SREに限らず、XFLAG スタジオで統⼀されたやり⽅
20 SRE の評価ポイント • 何にどのくらい時間をかけて、何に対して貢献したのか • 与えられた仕事だけしても評価はされない • 技術 •
技術によってどんな課題を解決できたのか • 今その技術を選ぶ必要があったのかどうか • アウトプット • 何を作ったのか、そのモノの価値はどうなのか • ⽣産性は⾼かったのか • 事業貢献 • 事業、プロダクト・サービスへどの程度貢献できたのか • なぜそれに貢献したのか • グループ貢献 • グループに与えた影響はどんなものだったのか • メンバーに対してどんな⾏動をして、何が変わったのか
21 現在のシステム・インフラ
22 現在のシステム・インフラ概要 • モンスターストライク(⽇本版)のシステムの例 • サーバー(現在1,100台くらい) • オンプレミス(2つのDC) • DC単位での冗⻑構成(⽚⽅のDCが死んでもサービス継続できるように)
• マルチクラウド(AWS, GMO, GCP) • レイテンシ(RTT) 1ms以下を⽬指したい • 適材適所、その時に最適なものを使う • OS • Ubuntu Server • プログラム⾔語 • Ruby • ミドルウェア • unicorn、nginx、MariaDB、Memcached、Redis • ソースコード管理 • GitHub
23 現在のシステム・インフラ概略図 A10 Load Balancer Unicorn Fluentd Redis MariaDB Memcached
Batch Worker Cron APIアクセス モンスターストライク(⽇本版)のシステム
24 現在の課題 • 負荷対策はずっと続いていく • さらなる⾼負荷が想定される企画、事業に応えていく • 古いものを捨てて新しいものを使う • ハードウェア、ソフトウェア、アーキテクチャ
• ⼊れ替えしやすい環境作り • ⼈間の⼿による作業を減らす • ミスを減らす、作業時間を減らす • 例えばクラウドのコンソール画⾯をポチポチする作業 • APIを使ったツールの開発 • ハードウェアのパワーに頼りすぎない • ソフトウェアで解決できることを探す • 耐障害性向上、コスト削減につながる
25 まとめ
26 まとめ XFLAG スタジオにおけるSRE(Site Reliability Engineer) • いままでの運⽤業務もやりながら、ソフトウェアを作る、使うことで課題 を解決していく •
能動的に、広い視点で、最適な技術を使って、いまやるべきことにおいて 価値を⽣み出す • 新しいものを取り⼊れ、新しいことに挑戦し、事業に貢献していく
None