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/DevOps の実践 / SRE and DevOps Pra...
Search
mom0tomo
August 28, 2023
Programming
720
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
クラウド移行を通じた SRE/DevOps の実践 / SRE and DevOps Practice in Cloud Migration
ゆるSRE勉強会第一回発表資料です。マッハバイトのクラウド移行を通じた、SRE/DevOpsを実践する取り組みについて具体的に話します。
mom0tomo
August 28, 2023
More Decks by mom0tomo
See All by mom0tomo
生成AI時代にこそ効くGo | Why Go Works in the Age of Generative AI
mom0tomo
8
3.4k
10年続くコミュニティ運営のコツ
mom0tomo
0
83
「名前のない仕事」にチームで取り組む–WOLとトラッキングツールの活用- / The SRE team's approach to unnamed work
mom0tomo
3
750
golang tokyo go tools
mom0tomo
3
1.3k
最初の言語としてGoを学んだ人から見た Ruby on Rails
mom0tomo
2
680
はじめてみんなで作ったGoのツールの話
mom0tomo
0
190
人材業界 中の人が語る 若手エンジニアの転職活動
mom0tomo
0
560
Go-ビギナーズ - よくある3つの質問
mom0tomo
2
150
Go徒然日記
mom0tomo
0
1.5k
Other Decks in Programming
See All in Programming
Strategic Design in the Frontend: Moduliths & Micro Frontends @DDDEurope
manfredsteyer
PRO
0
140
Hunting Vulnerabilities in Symfony with LLMs
vinceamstoutz
0
570
コンテキストの使い捨てをやめる — ビジネスルール駆動開発と miko —
ioki
0
270
OS アップデート対応の取り組み方がもっと共有されてほしい
andpad
0
110
jQueryをバージョンアップする前に使いたいjQuery Migrate
matsuo_atsushi
0
640
Spec Driven Development | AI Summit Lisbon
danielsogl
PRO
0
230
コーディングルールの鮮度を保ちたい for SRE NEXT 2026 / keep-fresh-go-internal-conventions-sre-next-2026
handlename
0
110
分散システム、なんですぐ死んでしまうん?耐障害性を高めたいあなたのためのレジリエンスパターン入門
mshibuya
7
3.1k
例外の正しい扱い方 そのエラー try-catchして大丈夫?
jinwatanabe
0
330
Signal Forms: Details & Live Coding @enterJS 2026 in Mannheim
manfredsteyer
PRO
0
220
エンジニアにデザインハーネスを 〜デザインプロセスを規定するためのハーネス〜 / Design harness from an engineer's perspective
rkaga
2
730
気圧・高度・GPSを記録&可視化するアプリ「Koudo」を作った話
hjmkth
1
340
Featured
See All Featured
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
410
A Tale of Four Properties
chriscoyier
163
24k
Testing 201, or: Great Expectations
jmmastey
46
8.2k
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.5k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
150
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
460
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
180
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.5k
A designer walks into a library…
pauljervisheath
211
24k
Transcript
クラウド移行を通じた SRE/DevOps の実践
バックエンドエンジニア → インフラエンジニア、 SREs 現在はマッハバイト インフラ担当。 趣味: 限界まで安い手段で海外旅行に行くこと mom0tomo 渡辺もも
テクノロジカルマーケティング部 インフラストラクチャーグループ Copyright © Livesense Inc.
About Livesense Invent The Next Common. Copyright © Livesense Inc.
Livesenseの事業 Copyright © Livesense Inc.
Copyright © Livesense Inc. • 社員数 ◦ 正社員 214名(2023年6月30日現在) •
エンジニア社員数 ◦ 全体 63名 正社員 40名 ◦ 正社員だけで見るとエンジニア職が1/5を 占める 社員数・組織規模
インフラグループ Copyright © Livesense Inc. • 事業部に属さない全社横断組織 • 6人+兼務2人 •
各事業部に対し、1-2人が窓口担当になる (DevOps/SRE的な動きもする) • リブセンス全体で利用する基盤・プラット フォームも管轄する
本日話すこと 1 クラウド移行の背景 2 移行前の課題 3 移行で改善できたこと 4 今後の課題 Copyright
© Livesense Inc.
クラウド移行の背景 Copyright © Livesense Inc.
クラウド移行の背景 フルリモートワーク化からのオフィス移転 • 創業期から契約しているデータセンターがある ◦ 創業当時からのサービスであるマッハバイト(旧ジョブセンス)では、ほとんどのシステムがオンプ レで運用されてきた • 新しい事業はクラウドで運用されているものも多い ◦
knew(マッチングサービス)、 batonn(面接最適化サービス)、 IESHIL(不動産事業)などは最初か らクラウド上で運用されている ◦ 転職会議・転職ドラフトもほぼオンプレから AWSに移行済み • コロナ禍で全社フルリモートワーク化し、オフィスを WeWorkに移転した ◦ オフィス内のサーバールームで運用してきた開発環境を急遽クラウドに移行した ◦ これを契機にクラウド移行の機運が加速した • 2023年末をもってクラウド移行が完了する予定 Copyright © Livesense Inc.
クラウド移行の背景 Copyright © Livesense Inc. https://made.livesense.co.jp/entry/2022/12/21/083000
移行前の課題 Copyright © Livesense Inc.
• 開発(アプリケーションエンジニア)と運用(インフラエンジニア)の間に壁があった • 権限の壁 ◦ オンプレミスのサーバーの設定変更はインフラチームに作業依頼が必要 ▪ sudo権限がないとインフラの設定変更ができない ▪ VM構築(サーバー準備)はインフラの担当
etc.. ◦ アプリケーション側の変更はアプリケーション開発チームに作業依頼が必要 ▪ リポジトリがたくさんあってデプロイ方法も統一されておらず複雑 ▪ 一部システムは監査対応のための特別な承認フローがある etc… • コミュニケーションの壁 ◦ プロジェクト・チームごとに Slackチャンネルが分かれていて気軽に声をかけづらい ◦ 隔週の定例が正式なコミュニケーションの場だが、シャンシャンと終わりがち 移行前の課題 「開発」と「運用」の分断 Copyright © Livesense Inc.
• サービスの信頼性への責任が曖昧になる ◦ 共用インフラ基盤の調査はインフラエンジニアが担当する ▪ 開発エンジニアが直接 L7LBのログを見られない etc. ◦ 監視・モニタリングサービスの導入はインフラチームが担当する
▪ 何かアラートがなったとき、設定した人(インフラチーム)が対応しがち • 作業待ちが発生してデリバリーに時間がかかる ◦ 「インフラチームがVM構築終わったらデプロイができる」(開発エンジニアは自分でサーバー構築 できない)etc. • アプリケーションの本質的な改善が進まない ◦ アプリケーションのコードを直せば解決する問題でも、リソースを増やすなどインフラ側でなんとか してしまい、保守性が下がる 移行前の課題 分断による悪影響 Copyright © Livesense Inc.
移行で改善できたこと Copyright © Livesense Inc.
• 権限を見直す ◦ インフラエンジニアしかサーバの rootを取れない→AWSのIAMグループを利用して適切な権限を 付与する • コミュニケーションチャネルを見直す ◦ Slackチャンネルを整理、統合してコミュニケーションの活性化を図る
◦ Work Out Loudの文化を伝える ▪ インフラチームEMの方がマッハバイトの EMを兼務してくれたことでスムーズに導入された • 信頼性向上に取り組むための土台を作る ◦ 共同で勉強会を開催してインフラ・モニタリングに関する知識を伝達する ▪ AWS勉強会、Datadog勉強会 移行で改善できたこと SRE/DevOpsの実践 Copyright © Livesense Inc.
• 複雑なリリースフローを改善する ◦ GitHub Actionsを利用してPRベースのデプロイワークフローを組む ◦ GitHubのリリース機能を利用し、リリースフローを省略する • IaCを徹底する ◦
インフラ構成のコードをリポジトリにまとめ、開発エンジニアも contributeできるようにする ▪ 開発エンジニアもレビューを受けて自由にインフラの構成変更ができる • モブプロでクラウド移行を加速する ◦ 協働してCI/CDワークフローを整備する ◦ 移行で邪魔になるデッドコードの削除、アーキテクチャの変更などその場で話し合って素早い意思 決定を行う 移行で改善できたこと SRE/DevOpsの実践 Copyright © Livesense Inc.
→ “越境文化”はSREっぽい! https://recruit.livesense.co.jp/lp/engineer/overview Copyright © Livesense Inc.
今後の課題 Copyright © Livesense Inc.
今後の課題 これからやりたいこと • サービスレベル(SLI/SLO)の策定と実践 ◦ 足元の整備中 ▪ Datadogを活用する ▪ エラーバジェットを定義する
• 誰でも障害対応できる体制づくり ◦ メトリクス・モニター・ダッシュボードのノウハウを共有する ◦ 障害対応を振り返り、ベテランの動きを学ぶ ◦ 詳しくないシステムで障害が起こったときに「シャドー」になる Copyright © Livesense Inc.
Copyright © Livesense Inc. • エンジニアブログ ◦ https://made.livesense.co.jp/ • Livesense
Engineering Handbook ◦ https://livesense-inc.gitbook.io/livesense-e ngineering-handbook/ エンジニアによる発信の ご紹介
クラウド移行の取り組みも発信中 https://made.livesense.co.jp/entry/2023/06/27/080000 https://made.livesense.co.jp/entry/2023/06/14/080000 https://made.livesense.co.jp/entry/2023/08/25/083000 Copyright © Livesense Inc.
None