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
2k
モンスターストライクの信頼性を支える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
「家族アルバム みてね」における運用管理・ オブザーバビリティの全貌 / Overview of Operation Management and Observability in FamilyAlbum
isaoshimizu
4
160
約10年間MIXIのインフラを 支えてきたPagerDutyの活用事例 / PagerDuty on Tour 2024
isaoshimizu
6
860
家族アルバム みてねにおけるGrafana活用術 / Grafana Meetup Japan Vol.1 LT
isaoshimizu
1
1.5k
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
isaoshimizu
18
8.7k
今年1年のEKS運用振り返り/3-shake SRE Tech Talk
isaoshimizu
2
280
ポストモーテムの基礎知識と最新事例 / Fundamentals of Postmortem
isaoshimizu
11
2.5k
全世界1,800万人が利用する「家族アルバム みてね」におけるNew Relic活用法 / FutureStack Tokyo 2023
isaoshimizu
1
410
『家族アルバム みてね』で計測しているSLIの事例 / SLI as measured in FamilyAlbum
isaoshimizu
3
710
4年間の取り組みで実現したコンテナ技術を活用したスケーラブルなインフラ構築とコスト削減 / Container Summit 2023
isaoshimizu
1
200
Other Decks in Technology
See All in Technology
可視化により内部品質をあげるAIドキュメントリバース/20240910 Hiromitsu Akiba
shift_evolve
0
200
なにもしてないのにNew Relicのデータ転送量が増えていたときに確認したこと
tk3fftk
2
210
LLVM/ASMを使った有限体の高速実装
herumi
0
120
効果的なオンコール対応と障害対応
ryuichi1208
5
2.8k
ついに出た!OpenAIの最新モデル「o1」って何がすごいの?
minorun365
PRO
2
540
Creative UIs with Compose: DroidKaigi 2024
chrishorner
1
440
AIで変わるテスト自動化:最新ツールの多様なアプローチ/ 20240910 Takahiro Kaneyama
shift_evolve
0
210
AWS SAW を広めたい @四国クラウドお遍路
kazzpapa3
0
230
あなたの知らないiOS開発の世界
recruitengineers
PRO
3
150
Next.js のページ遷移を全力で止める
ypresto
0
120
Fediverse Discovery Providers overview
andypiper
0
160
SORACOMで実現するIoTのマルチクラウド対応 - IoTでのクリーンアーキテクチャの実現 -
kenichirokimura
0
380
Featured
See All Featured
Robots, Beer and Maslow
schacon
PRO
157
8.2k
Git: the NoSQL Database
bkeepers
PRO
425
64k
Imperfection Machines: The Place of Print at Facebook
scottboms
263
13k
GraphQLとの向き合い方2022年版
quramy
43
13k
Building Adaptive Systems
keathley
36
2.1k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
3k
Designing for Performance
lara
604
68k
Making the Leap to Tech Lead
cromwellryan
128
8.8k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Design by the Numbers
sachag
277
19k
Intergalactic Javascript Robots from Outer Space
tanoku
268
26k
Web Components: a chance to create the future
zenorocha
308
42k
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