会計freeeのデプロイを10倍早くした話

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のデプロイ  15 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  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を確保する  • 変更対象 (ライブラリ等) を深く理解する  • 段階的にリリースする 

プランBを確保する  41 • 不確実性の低い選択肢をプランBとして確保  • 影響範囲の小さいBlue/GreenがプランB  不確実性高  不確実性低  効果高  効果低 
EKS  Unicorn  Blue/Green 

変更対象を深く理解する  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 

Process 

Process  File  Descriptor  File  Descriptor 

PreloadによるFile Descriptorの共有  49 • Linuxのforkの処理が正しく理解できていれば事象の原因、対策が打てる  ◦ 親子間でOpen File Tableがコピーされる  ◦
同じFile Descriptorへの参照を保持している 

段階的にリリースする  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へ移行中  ◦ モノリスの分割が進行中  ◦ 自動カナリアリリースを準備中 

スモールビジネスを、  世界の主役に。 

会計freeeのデプロイを10倍早くした話

会計freeeのデプロイを10倍早くした話

More Decks by freee

Other Decks in Technology

Featured

Transcript