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
会計freeeのデプロイを10倍早くした話
Search
freee
January 21, 2020
Technology
0
5.3k
会計freeeのデプロイを10倍早くした話
freee
January 21, 2020
Tweet
Share
More Decks by freee
See All by freee
巨大なテーブルのテーブル定義を無停止で安全に誰でも変更できるようにする / Table-definitions-for-huge-tables-can-be-modified-by-anyone-safely-and-non-disruptively
freee
1
810
合理的配慮を知るワークショップ/Understanding Reasonable Accommodations (Workshop)
freee
1
1.4k
10分でわかるfreeeのQA
freee
0
740
10分でわかるfreeeのPdM
freee
9
12k
freee + Product Design FY24 Q3
freee
3
7.4k
freeeAPI × Postman APIコラボレーションで スモールビジネスを世界の主役に! / FreeeAPI x Postman API collaboration to make small business the world's leading actor!
freee
0
3.1k
モバイルチームについて
freee
0
1.2k
GitHub Copilot 導入時に考えたセキュリティのあれこれ / Security-considerations-when-introducing-GitHub-Copilot
freee
3
6.3k
課金基盤開発エンジニアについて
freee
0
410
Other Decks in Technology
See All in Technology
MapLibreとAmazon Location Service
dayjournal
1
160
チームでロジカルシンキングに改めて向き合っている話 〜学習環境と実践⽅法〜
sansantech
PRO
3
2.7k
GraphQL 成熟度モデルの紹介と、プロダクトに当てはめた事例 / GraphQL maturity model
mh4gf
7
1.4k
Python と Snowflake はズッ友だょ!~ Snowflake の Python 関連機能をふりかえる ~
__allllllllez__
1
120
Postman v10リリース後を振り返る / Looking back at Postman v10 after release
yokawasa
1
160
いつか使うかも貯金してたらめちゃめちゃ機能が増えてた話
riyaamemiya
0
350
ServiceNow Knowledge 24の歩き方 EYストラテジー・アンド・コンサルティング
manarobot
0
200
私が trocco を推す理由
__allllllllez__
1
260
LLM開発・活用の舞台裏@2024.04.25
yushin_n
1
370
現代CSSフレームワークの内部実装とその仕組み
poteboy
7
3.6k
障害対応をちょっとずつよくしていくための 演習の作りかた
heleeen
0
240
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
3
570
Featured
See All Featured
Building an army of robots
kneath
300
41k
Fantastic passwords and where to find them - at NoRuKo
philnash
37
2.5k
Documentation Writing (for coders)
carmenintech
60
3.9k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.6k
What's new in Ruby 2.0
geeforr
337
31k
Adopting Sorbet at Scale
ufuk
68
8.6k
Visualization
eitanlees
136
14k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
322
20k
Infographics Made Easy
chrislema
238
18k
The Art of Programming - Codeland 2020
erikaheidi
42
12k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
20
1.9k
KATA
mclloyd
15
12k
Transcript
freee 株式会社 会計freeeのデプロイを10倍早くした話 2020.01.21
プロフィール HR系企業を経て2016年11月freee入社。申告freeeのリリースに携わった後、 認証基盤チームへ異動。ログインやセッション管理の改修、二段階認証の開 発等を担当しました。2019年4月よりSRE所属。 @shuheiktgw Shuhei Kitagwa
お話すること 3 04 振り返り ・ まとめ 03 モノリスへのアプローチ 02 検討した選択肢 01 会計freeeのデプロイ
4 会計freeeのデプロイ 01 Section
数字で見る会計freee 5 40+ 200k+ 1-3 +3k -1.5k Developers Commits Diffs
/day Deploy /day
6 会計freeeの構成 Nginx Phusion Passenger Ruby on Rails ELB EC2s
会計freeeのデプロイ 7 Capistrano New Code New Assets New Code New
Assets EC2s
会計freeeのデプロイ 8 Old App Old App Old App
会計freeeのデプロイ 9 Old App Old App Old App デタッチ
会計freeeのデプロイ 10 Old App Old App Old App Stop
会計freeeのデプロイ 11 Old App Old App Start
会計freeeのデプロイ 12 New App Old App Old App
会計freeeのデプロイ 13 New App Old App Old App
会計freeeのデプロイ 14 New App Old App Old App
会計freeeのデプロイ 15 New App Old App New App
会計freeeのデプロイ 16 New App Old App New App
会計freeeのデプロイ 17 New App Old App New App
会計freeeのデプロイ 18 New App New App New App
会計freeeのデプロイ 19 New App New App New App
会計freeeのデプロイ 20 New App New App New App • LBから抜く必要があるため、並列にデプロイできない
• 確定申告期など、サーバー台数が多いと50分近くかかることも
21 検討した選択肢 02 Section
検討した選択肢 22 • Elastic Kubernetes Service (EKS) への移行 • Auto
Scaling Groupを用いたBlue/Green • アプリケーション・サーバーによるホットデプロイ
Elastic Kubernetes Service (EKS) への移行 23
Elastic Kubernetes Service (EKS) への移行 24 • Pros ◦ Kubernetes
(Docker) ◦ 新規マイクロサービスを中心に本番運用実績 • Cons ◦ モノリシックなサービスをKubernetesへ移行した経験がなかった ▪ もう少し小さいサービスを先に移行させたい ◦ 当時はKubernetesのモニタリング、セキュリティ周りの統一した規格が未整備
Auto Scaling Groupを用いたBlue/Green 25 Old App
Auto Scaling Groupを用いたBlue/Green 26 Old App New App
Auto Scaling Groupを用いたBlue/Green 27 Old App New App
Auto Scaling Groupを用いたBlue/Green 28 Old App New App
Auto Scaling Groupを用いたBlue/Green 29 New App
Auto Scaling Groupを用いたBlue/Green 30 • Pros ◦ イミュータブル・インフラストラクチャの実現 ◦ 既存の構成に変更を加える必要がない
• Cons ◦ AWSがサーバーをプロビジョンする時間がボトルネックになる ◦ 常に希望通りのサーバー台数が確保される保証がない
アプリケーション・サーバーによるホットデプロイ 31 App Server Old App
アプリケーション・サーバーによるホットデプロイ 32 App Server Old App New App
アプリケーション・サーバーによるホットデプロイ 33 App Server Old App New App
アプリケーション・サーバーによるホットデプロイ 34 App Server New App
アプリケーション・サーバーによるホットデプロイ 35 • Pros ◦ 圧倒的に早い ◦ Capistranoの資産を再利用できる • Cons
◦ アプリケーション・サーバーの変更による影響範囲が大きい ◦ 遠ざかるイミュータブル・インフラストラクチャ
ホットデプロイを選択 36 • Unicornによるホットデプロイ ◦ デプロイ時間、ロールバック時間 ◦ Phusion Passengerと同じマルチプロセス &
プリフォーク
37 モノリスへのアプローチ 03 Section
課題 38 • 「会計freeeのアプリケーション・サーバーを安全に入れ替えたい」 ◦ 影響範囲が大きく、事前の完全な検証が困難 ◦ 対象ドメイン全体を完全に把握することが困難
アプローチ 39 • プランBを確保する • 変更対象 (ライブラリ等) を深く理解する • 段階的にリリースする
アプローチ 40 • プランBを確保する • 変更対象 (ライブラリ等) を深く理解する • 段階的にリリースする
プランBを確保する 41 • 不確実性の低い選択肢をプランBとして確保 • 影響範囲の小さいBlue/GreenがプランB 不確実性高 不確実性低 効果高 効果低
EKS Unicorn Blue/Green
アプローチ 42 • プランBを確保する • 変更対象 (ライブラリ等) を深く理解する • 段階的にリリースする
変更対象を深く理解する 43 • Unicornのソースコードから3点を把握 ◦ 起動からリクエストを捌き始めるまでの流れ ◦ ホットデプロイ (USR2) シグナルを受け取った場合の処理
◦ 各パラメーターの使われ方と影響範囲 • プリフォーク型のアーキテクチャであるため、forkの処理も合わせて抑える ◦ ホットデプロイでは環境変数が更新されない ◦ PreloadによるFile Descriptorの共有
PreloadによるFile Descriptorの共有 44 Master Process File Descriptor Connection Redis
PreloadによるFile Descriptorの共有 45 Master Process File Descriptor Worker Process Worker
Process
PreloadによるFile Descriptorの共有 46 Master Process File Descriptor Worker Process Worker
Process
PreloadによるFile Descriptorの共有 47 Master Process File Descriptor Worker Process Worker
Process
PreloadによるFile Descriptorの共有 48 Master Process File Descriptor Worker Process Worker
Process File Descriptor File Descriptor
PreloadによるFile Descriptorの共有 49 • Linuxのforkの処理が正しく理解できていれば事象の原因、対策が打てる ◦ 親子間でOpen File Tableがコピーされる ◦
同じFile Descriptorへの参照を保持している
アプローチ 50 • プランBを確保する • 変更対象 (ライブラリ等) を深く理解する • 段階的にリリースする
段階的にリリースする 51 • パフォーマンス劣化やバグを多層でテスト 1. テスト環境での負荷試験 2. 他サービスでのリリース 3. 本番環境でのカナリアリリース
テスト環境での負荷試験 52 • Unicorn vs Phusion Passenger、通常時 vs ホットデプロイ時 •
「負荷試験コトハジメ」(https://bit.ly/35Xtncb) ◦ インクリメンタルに負荷試験を行う ▪ フェーズ1: 単一クライアント、単一API ▪ フェーズ2: 複数クライアント、単一API ▪ フェーズ3: 複数クライアント、シナリオベース • 完璧にやろうとしすぎない、次ステージ以降でカバー ホットデプロイ時
他サービスでの先行リリース 53 • 規模の小さいサービスで先行リリース ◦ 運用を通じた各種パラメーター、モニタリング等の調整 ◦ 複数回リリースの経験
本番環境でのカナリアリリース 54 • 本番リクエストを2%程度 • Nginxログからレスポンスタイムを集計 Uncorn 98% 2%
55 振り返り ・ まとめ 04 Section
Unicornへ移行した結果 56 移行 分
移行して正直どうだったか? 57 • 25分 -> 2、3分へ短縮できる効果は大きい ◦ デプロイ数の増加、ロールバックの安心感 •
一部本番へ流出した問題があった ◦ Redis connection、Releasesの消失 ◦ 時間 x 規模が必要な事象は発見しづらい ▪ リプレイテストの仕組みなど • Capistranoの辛さを感じる日々 ◦ サーバーの状態変化に起因した問題を引くことが多い
まとめ 58 • モノリスへのアプローチ ◦ プランBを確保する ◦ 変更対象 (ライブラリ等) を深く理解する
◦ 段階的にリリースする • 今後 ◦ モノリスがEKSへ移行中 ◦ モノリスの分割が進行中 ◦ 自動カナリアリリースを準備中
スモールビジネスを、 世界の主役に。