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
10分でわかるfreeeのPdM
freee
0
7.4k
freee + Product Design FY24 Q3
freee
3
7.1k
freeeAPI × Postman APIコラボレーションで スモールビジネスを世界の主役に! / FreeeAPI x Postman API collaboration to make small business the world's leading actor!
freee
0
2.4k
モバイルチームについて
freee
0
1.1k
GitHub Copilot 導入時に考えたセキュリティのあれこれ / Security-considerations-when-introducing-GitHub-Copilot
freee
3
5.4k
課金基盤開発エンジニアについて
freee
0
280
「Engineerサクセス」という組織を 作って感じた開発組織作りのポイント / Key-Points-for-Creating-a-Development-Organization
freee
1
130
人事とエンジニアで協業しながら進める組織作り / Creating an organization in which HR and engineers collaborate with each other
freee
0
200
セキュリティ組織のマネジメントとアップデート / Management-and-updating-of-security-organisations
freee
0
4.5k
Other Decks in Technology
See All in Technology
AWSアカウント74件をバックアップした方法と課題
chiharutsuboi
0
110
20240314-AboutStorageAntivirusMeasures
takano0131
1
100
技育祭2024春 LT Finatextホールディングス
kevinrobot34
1
120
The Twelve-Factor App とクラウドアプリケーションのコスト
ny7760
3
260
SSMエージェントはIAMロールの夢を見るか/ Do SSM Agents Dream Of IAM Roles?
yukihirochiba
0
1.4k
【OpsJAWS】EC2 のセキュリティの運用と監視について考えてみた件
hssh2_bin
4
600
Uniting Rust Servers and Clients through OpenAPI
ahl
0
430
Server-Side Kotlin + Spring Boot + Exposedでやったこと
ikefukurou777
0
110
小さく始めるAnsible
stopendy
0
210
自己完結な開発者組織を支える プラットフォーム作り
recruitengineers
PRO
2
230
App Runnerでパラメーターストアの値を使ってみた
miura55
0
230
OCI Data Science Service 製品概要
oracle4engineer
PRO
0
110
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
7
2.3k
Imperfection Machines: The Place of Print at Facebook
scottboms
257
12k
Art, The Web, and Tiny UX
lynnandtonic
288
19k
Fireside Chat
paigeccino
19
2.5k
Agile that works and the tools we love
rasmusluckow
323
20k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
14
1.3k
Build The Right Thing And Hit Your Dates
maggiecrowley
23
1.9k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
219
21k
Raft: Consensus for Rubyists
vanstee
130
6.2k
Build your cross-platform service in a week with App Engine
jlugia
223
17k
Building a Scalable Design System with Sketch
lauravandoore
455
32k
Six Lessons from altMBA
skipperchong
19
2.9k
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へ移行中 ◦ モノリスの分割が進行中 ◦ 自動カナリアリリースを準備中
スモールビジネスを、 世界の主役に。