Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
モンスターストライクの信頼性を支えるSREの組織化について / Internet Week 2017
Search
Isao Shimizu
November 29, 2017
Technology
0
2.1k
モンスターストライクの信頼性を支える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
Notion x ポストモーテムで広げる組織の学び / Notion x Postmortem
isaoshimizu
1
280
New Relicを活用したSREの最初のステップ / NRUG OKINAWA VOL.3
isaoshimizu
3
1k
「家族アルバム みてね」における運用管理・ オブザーバビリティの全貌 / Overview of Operation Management and Observability in FamilyAlbum
isaoshimizu
5
2.1k
約10年間MIXIのインフラを 支えてきたPagerDutyの活用事例 / PagerDuty on Tour 2024
isaoshimizu
6
1.2k
家族アルバム みてねにおけるGrafana活用術 / Grafana Meetup Japan Vol.1 LT
isaoshimizu
2
1.8k
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
isaoshimizu
18
9.1k
今年1年のEKS運用振り返り/3-shake SRE Tech Talk
isaoshimizu
2
390
ポストモーテムの基礎知識と最新事例 / Fundamentals of Postmortem
isaoshimizu
12
3.2k
全世界1,800万人が利用する「家族アルバム みてね」におけるNew Relic活用法 / FutureStack Tokyo 2023
isaoshimizu
1
590
Other Decks in Technology
See All in Technology
o11yで育てる、強い内製開発組織
_awache
3
120
VCC 2025 Write-up
bata_24
0
180
AIツールでどこまでデザインを忠実に実装できるのか
oikon48
5
2.4k
『OCI で学ぶクラウドネイティブ 実践 × 理論ガイド』 書籍概要
oracle4engineer
PRO
2
140
KMP の Swift export
kokihirokawa
0
340
いまさら聞けない ABテスト入門
skmr2348
1
220
社内お問い合わせBotの仕組みと学び
nish01
1
490
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
290
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi
shift_evolve
PRO
4
340
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
1
510
Large Vision Language Modelを用いた 文書画像データ化作業自動化の検証、運用 / shibuya_AI
sansan_randd
0
120
動画データのポテンシャルを引き出す! Databricks と AI活用への奮闘記(現在進行形)
databricksjapan
0
160
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
The Cult of Friendly URLs
andyhume
79
6.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
GraphQLとの向き合い方2022年版
quramy
49
14k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
610
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Six Lessons from altMBA
skipperchong
28
4k
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