Recomendados
Mais conteúdo relacionado
Semelhante a 会計freeeのデプロイを10倍早くした話
Semelhante a 会計freeeのデプロイを10倍早くした話 (20)
会計freeeのデプロイを10倍早くした話
- 5. 数字で見る会計freee 5 40+ 200k+ 1-3 +3k -1.5k Developers Commits Diffs /day Deploy /day
- 9. 会計freeeのデプロイ 9 Old App Old App Old App デタッチ
- 10. 会計freeeのデプロイ 10 Old App Old App Old App Stop
- 20. 会計freeeのデプロイ 20 New App New App New App ● LBから抜く必要があるため、並列にデプロイできない ● 確定申告期など、サーバー台数が多いと50分近くかかることも
- 22. 検討した選択肢 22 ● Elastic Kubernetes Service (EKS) への移行 ● Auto Scaling Groupを用いたBlue/Green ● アプリケーション･サーバーによるホットデプロイ
- 23. Elastic Kubernetes Service (EKS) への移行 23
- 24. Elastic Kubernetes Service (EKS) への移行 24 ● Pros ○ Kubernetes (Docker) ○ 新規マイクロサービスを中心に本番運用実績 ● Cons ○ モノリシックなサービスをKubernetesへ移行した経験がなかった ■ もう少し小さいサービスを先に移行させたい ○ 当時はKubernetesのモニタリング、セキュリティ周りの統一した規格が未整備
- 26. Auto Scaling Groupを用いたBlue/Green 26 Old App New App
- 27. Auto Scaling Groupを用いたBlue/Green 27 Old App New App
- 28. Auto Scaling Groupを用いたBlue/Green 28 Old App New App
- 30. Auto Scaling Groupを用いたBlue/Green 30 ● Pros ○ イミュータブル･インフラストラクチャの実現 ○ 既存の構成に変更を加える必要がない ● Cons ○ AWSがサーバーをプロビジョンする時間がボトルネックになる ○ 常に希望通りのサーバー台数が確保される保証がない
- 35. アプリケーション･サーバーによるホットデプロイ 35 ● Pros ○ 圧倒的に早い ○ Capistranoの資産を再利用できる ● Cons ○ アプリケーション･サーバーの変更による影響範囲が大きい ○ 遠ざかるイミュータブル･インフラストラクチャ
- 36. ホットデプロイを選択 36 ● Unicornによるホットデプロイ ○ デプロイ時間、ロールバック時間 ○ Phusion Passengerと同じマルチプロセス & プリフォーク
- 38. 課題 38 ● ｢会計freeeのアプリケーション･サーバーを安全に入れ替えたい｣ ○ 影響範囲が大きく、事前の完全な検証が困難 ○ 対象ドメイン全体を完全に把握することが困難
- 39. アプローチ 39 ● プランBを確保する ● 変更対象 (ライブラリ等) を深く理解する ● 段階的にリリースする
- 40. アプローチ 40 ● プランBを確保する ● 変更対象 (ライブラリ等) を深く理解する ● 段階的にリリースする
- 42. アプローチ 42 ● プランBを確保する ● 変更対象 (ライブラリ等) を深く理解する ● 段階的にリリースする
- 43. 変更対象を深く理解する 43 ● Unicornのソースコードから3点を把握 ○ 起動からリクエストを捌き始めるまでの流れ ○ ホットデプロイ (USR2) シグナルを受け取った場合の処理 ○ 各パラメーターの使われ方と影響範囲 ● プリフォーク型のアーキテクチャであるため、forkの処理も合わせて抑える ○ ホットデプロイでは環境変数が更新されない ○ PreloadによるFile Descriptorの共有
- 49. PreloadによるFile Descriptorの共有 49 ● Linuxのforkの処理が正しく理解できていれば事象の原因、対策が打てる ○ 親子間でOpen File Tableがコピーされる ○ 同じFile Descriptorへの参照を保持している
- 50. アプローチ 50 ● プランBを確保する ● 変更対象 (ライブラリ等) を深く理解する ● 段階的にリリースする
- 51. 段階的にリリースする 51 ● パフォーマンス劣化やバグを多層でテスト 1. テスト環境での負荷試験 2. 他サービスでのリリース 3. 本番環境でのカナリアリリース
- 52. テスト環境での負荷試験 52 ● Unicorn vs Phusion Passenger、通常時 vs ホットデプロイ時 ● ｢負荷試験コトハジメ｣（https://bit.ly/35Xtncb） ○ インクリメンタルに負荷試験を行う ■ フェーズ1: 単一クライアント、単一API ■ フェーズ2: 複数クライアント、単一API ■ フェーズ3: 複数クライアント、シナリオベース ● 完璧にやろうとしすぎない、次ステージ以降でカバー ホットデプロイ時
- 57. 移行して正直どうだったか? 57 ● 25分 -> 2、3分へ短縮できる効果は大きい 🎉 ○ デプロイ数の増加、ロールバックの安心感 ● 一部本番へ流出した問題があった ○ Redis connection、Releasesの消失 ○ 時間 x 規模が必要な事象は発見しづらい ■ リプレイテストの仕組みなど ● Capistranoの辛さを感じる日々 ○ サーバーの状態変化に起因した問題を引くことが多い
- 58. まとめ 58 ● モノリスへのアプローチ ○ プランBを確保する ○ 変更対象 (ライブラリ等) を深く理解する ○ 段階的にリリースする ● 今後 ○ モノリスがEKSへ移行中 ○ モノリスの分割が進行中 ○ 自動カナリアリリースを準備中