Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

3adaa5e19f64345a0fbdb2e5d00be571?s=47 freee
January 21, 2020

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

3adaa5e19f64345a0fbdb2e5d00be571?s=128

freee

January 21, 2020
Tweet

Transcript

  1. freee 株式会社
 会計freeeのデプロイを10倍早くした話
 2020.01.21

  2. プロフィール
 HR系企業を経て2016年11月freee入社。申告freeeのリリースに携わった後、 認証基盤チームへ異動。ログインやセッション管理の改修、二段階認証の開 発等を担当しました。2019年4月よりSRE所属。
 @shuheiktgw Shuhei Kitagwa


  3. お話すること
 3  04 振り返り ・ まとめ
  03 モノリスへのアプローチ
  02 検討した選択肢
  01 会計freeeのデプロイ


  4. 4 会計freeeのデプロイ
 01 Section

  5. 数字で見る会計freee
 5 40+
 200k+
 1-3
 +3k
 -1.5k
 Developers
 Commits
 Diffs


    /day
 Deploy
 /day

  6. 6 会計freeeの構成
 Nginx
 Phusion
 Passenger
 Ruby on Rails
 ELB
 EC2s


  7. 会計freeeのデプロイ
 7 Capistrano
 New Code New Assets New Code New

    Assets EC2s

  8. 会計freeeのデプロイ
 8 Old App Old App Old App

  9. 会計freeeのデプロイ
 9 Old App Old App Old App デタッチ


  10. 会計freeeのデプロイ
 10 Old App Old App Old App Stop


  11. 会計freeeのデプロイ
 11 Old App Old App Start


  12. 会計freeeのデプロイ
 12 New App Old App Old App

  13. 会計freeeのデプロイ
 13 New App Old App Old App

  14. 会計freeeのデプロイ
 14 New App Old App Old App

  15. 会計freeeのデプロイ
 15 New App Old App New App

  16. 会計freeeのデプロイ
 16 New App Old App New App

  17. 会計freeeのデプロイ
 17 New App Old App New App

  18. 会計freeeのデプロイ
 18 New App New App New App

  19. 会計freeeのデプロイ
 19 New App New App New App

  20. 会計freeeのデプロイ
 20 New App New App New App • LBから抜く必要があるため、並列にデプロイできない


    • 確定申告期など、サーバー台数が多いと50分近くかかることも

  21. 21 検討した選択肢
 02 Section

  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のモニタリング、セキュリティ周りの統一した規格が未整備

  25. Auto Scaling Groupを用いたBlue/Green
 25 Old App

  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

  29. Auto Scaling Groupを用いたBlue/Green
 29 New App

  30. Auto Scaling Groupを用いたBlue/Green
 30 • Pros
 ◦ イミュータブル・インフラストラクチャの実現
 ◦ 既存の構成に変更を加える必要がない


    • Cons
 ◦ AWSがサーバーをプロビジョンする時間がボトルネックになる
 ◦ 常に希望通りのサーバー台数が確保される保証がない

  31. アプリケーション・サーバーによるホットデプロイ
 31 App Server Old App

  32. アプリケーション・サーバーによるホットデプロイ
 32 App Server Old App New App

  33. アプリケーション・サーバーによるホットデプロイ
 33 App Server Old App New App

  34. アプリケーション・サーバーによるホットデプロイ
 34 App Server New App

  35. アプリケーション・サーバーによるホットデプロイ
 35 • Pros
 ◦ 圧倒的に早い
 ◦ Capistranoの資産を再利用できる
 • Cons


    ◦ アプリケーション・サーバーの変更による影響範囲が大きい
 ◦ 遠ざかるイミュータブル・インフラストラクチャ

  36. ホットデプロイを選択
 36 • Unicornによるホットデプロイ
 ◦ デプロイ時間、ロールバック時間
 ◦ Phusion Passengerと同じマルチプロセス &

    プリフォーク
 

  37. 37 モノリスへのアプローチ
 03 Section

  38. 課題
 38 • 「会計freeeのアプリケーション・サーバーを安全に入れ替えたい」
 ◦ 影響範囲が大きく、事前の完全な検証が困難
 ◦ 対象ドメイン全体を完全に把握することが困難


  39. アプローチ
 39 • プランBを確保する
 • 変更対象 (ライブラリ等) を深く理解する
 • 段階的にリリースする


  40. アプローチ
 40 • プランBを確保する
 • 変更対象 (ライブラリ等) を深く理解する
 • 段階的にリリースする


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


    EKS
 Unicorn
 Blue/Green

  42. アプローチ
 42 • プランBを確保する
 • 変更対象 (ライブラリ等) を深く理解する
 • 段階的にリリースする


  43. 変更対象を深く理解する
 43 • Unicornのソースコードから3点を把握
 ◦ 起動からリクエストを捌き始めるまでの流れ
 ◦ ホットデプロイ (USR2) シグナルを受け取った場合の処理


    ◦ 各パラメーターの使われ方と影響範囲
 • プリフォーク型のアーキテクチャであるため、forkの処理も合わせて抑える
 ◦ ホットデプロイでは環境変数が更新されない
 ◦ PreloadによるFile Descriptorの共有

  44. PreloadによるFile Descriptorの共有
 44 Master
 Process
 File
 Descriptor
 Connection
 Redis


  45. PreloadによるFile Descriptorの共有
 45 Master
 Process
 File
 Descriptor
 Worker
 Process
 Worker


    Process

  46. PreloadによるFile Descriptorの共有
 46 Master
 Process
 File
 Descriptor
 Worker
 Process
 Worker


    Process

  47. PreloadによるFile Descriptorの共有
 47 Master
 Process
 File
 Descriptor
 Worker
 Process
 Worker


    Process

  48. PreloadによるFile Descriptorの共有
 48 Master
 Process
 File
 Descriptor
 Worker
 Process
 Worker


    Process
 File
 Descriptor
 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: 複数クライアント、シナリオベース
 • 完璧にやろうとしすぎない、次ステージ以降でカバー
 ホットデプロイ時

  53. 他サービスでの先行リリース
 53 • 規模の小さいサービスで先行リリース
 ◦ 運用を通じた各種パラメーター、モニタリング等の調整
 ◦ 複数回リリースの経験


  54. 本番環境でのカナリアリリース
 54 • 本番リクエストを2%程度
 • Nginxログからレスポンスタイムを集計
 Uncorn
 98%
 2%


  55. 55 振り返り ・ まとめ
 04 Section

  56. Unicornへ移行した結果
 56 移行
 分


  57. 移行して正直どうだったか?
 57 • 25分 -> 2、3分へ短縮できる効果は大きい 
 ◦ デプロイ数の増加、ロールバックの安心感
 •

    一部本番へ流出した問題があった
 ◦ Redis connection、Releasesの消失
 ◦ 時間 x 規模が必要な事象は発見しづらい
 ▪ リプレイテストの仕組みなど
 • Capistranoの辛さを感じる日々
 ◦ サーバーの状態変化に起因した問題を引くことが多い

  58. まとめ
 58 • モノリスへのアプローチ
 ◦ プランBを確保する
 ◦ 変更対象 (ライブラリ等) を深く理解する


    ◦ 段階的にリリースする
 
 • 今後
 ◦ モノリスがEKSへ移行中
 ◦ モノリスの分割が進行中
 ◦ 自動カナリアリリースを準備中

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