デプロイ再考2024/reconsidering-deploy-in-2024

現在 estie では、デプロイの改善・統一に取り組んでいます。複数プロダクトのそれぞれの技術スタックが大きく違う中、どう考えたら効率的なデプロイを組めるのか。2024年のデプロイの原則について、あらためて考えてみました。

Transcript

1. © 2024 estie Inc. デプロイ再考2024 株式会社estie 杉田毅博 (github:sugitak, X:@sugitak06)
2. © 2024 estie Inc. 「デプロイ再考」で きょう話すこと • デプロイはビルド・デプロイの2ステージだよ • ディスクイメージは全環境で共用したいよ • CI/CDツールにはフローや共通処理だけ書きたいよ
3. © 2024 estie Inc. 杉田 毅博 github:sugitak, x:@sugitak06 • 2022~ 株式会社 estie 「1人目SRE」兼 EM • 2017~ 株式会社Preferred Networksコーポレートエンジニ ア。勝手にEmbedded SREも兼務 • 2015~ freee株式会社にてSREを名乗り始める。デプロイを 60分→7分に短縮・安定化。CSIRT立ち上げリーダー、セ キュリティ開発なども担当。自称デプロイ屋さんになる • 2011~ IIJ にて Ruby PaaS 開発。ユーザコードのデプロイ 部分を一人で担当。自称bundlerの専門家になる 講演等 2017-07 Schoo にて Prometheus 講師 2018-02 Software Design 誌にて9ページ記事執筆
4. © 2024 estie Inc. Confidential © 2022 estie Inc. Our purpose 産業の真価を、さらに拓く。
5. © 2024 estie Inc. estieの事業領域 5 数ある産業の中で、estieが最初に挑む領域は不動産 不動産の中でも商業用不動産領域に注力し、直近はオフィスにフォーカス 資産 タイプ Office オフィス Retail 商業施設・アウトレット等 Industrial 物流施設・データセンター等 Hotel ホテル Residential 住宅 投資 目的資産 自己使用 目的資産 商業用不動産市場 賃貸住宅市場 分譲住宅市場
6. © 2024 estie Inc. Whole Product構想 6 estie独自の不動産基盤データ 分析 認証 権限管理 API セキュリティ ワークフロー 検索 売買事例データ 賃貸事例データ マクロデータ 売買物件 探索 売買物件 管理 物件価値 評価 顧客管理 募集管理 募集情報 提供 売買マーケットプレイス 賃貸マーケットプレイス ポートフォリオマネジメント IR・資金調達 ERP Marketplace SaaS Data as a Service （DaaS） Middleware Data Platform 売買 賃貸 ファイナンス 商業用不動産市場全体を支えるWhole Productを構築し、産業の真価を拓く
7. © 2024 estie Inc. CI/CD に関する現状 • サービスは全て AWS, ECS Fargate 上で稼働 o ecspresso を愛用 • CI/CD には GitHub Actions を利用 • マルチプロダクトを展開。プロダクトごとに技術スタックが違う o 全プロダクトの CI/CD 統一がめっちゃ難しい => 改めてデプロイとは何なのか考えてみる！
8. © 2024 estie Inc. デプロイとは？ • ソフトウェアを実行可能な状態に持っていくこと • "deploy": to move soldiers or equipment to a place where they can be used when they are needed (https://dictionary.cambridge.org/ja/dictionary/english/deploy) o 兵士や兵器を戦闘可能な状態に配備すること
9. 複雑になった デプロイ
10. 原則 ビルド・デプロイの 2フェーズ
11. © 2024 estie Inc. デプロイフェーズ ビルド ソースコー ド準備 ビルド アップロー ド デプロイ migration 展開 リリース デプロイにはフェーズがある。フェーズを意識して組み立てると、考え方が整理しやすい
12. © 2024 estie Inc. デプロイフェーズ ビルド ソースコー ド準備 ビルド アップロー ド デプロイ migration 展開 リリース アプリケーションごとの差 異はこのあたり
13. © 2024 estie Inc. 「デプロイ高速化」 ビルド ソースコー ド準備 ビルド アップロー ド デプロイ migration 展開 リリース ビルドは事前にできる 人間が必要になってから デプロイだけ実行すれば 高速化達成！
14. © 2024 estie Inc. "究極の" デプロイ高速化 ビルド ソースコー ド準備 ビルド アップロー ド デプロイ migration 展開 リリース デプロイ時にここだけ実行す るような仕組みにすると、究 極の高速化ができる
15. © 2024 estie Inc. "究極の" デプロイ高速化のやり方2選 • Blue-Green Deploy o 展開までしておく。デプロイ実行時、 LB や DNS の切り替えだけ実行 • Feature Flag 方式 o 機能単位での出し分け。実質的にデプロイ高速化 • その他 o ファイル転送を事前にしておいて、デプロイ時には symlink 切り替え・ process restart だけするという方 式が一時期流行った o Docker イメージ展開が基本の時代、もう使えない
16. © 2024 estie Inc. estie の選択 • 事前にビルド。「デプロイ」時にはデプロイフェーズのみ実行させる • "究極の" デプロイ高速化はやり過ぎなので手を出さない • Feature Flag は利用中
17. 事前ビルドを考えると、たとえば以下のよう なフローになる build upload migration migration stg deploy tagging migration prd deploy tagging dev deploy dev deploy stg deploy prd deploy tests E2E test → deploy build ←
18. 事前ビルドを考えると、たとえば以下のよう なフローになる build upload migration migration stg deploy tagging migration prd deploy tagging dev deploy dev deploy stg deploy prd deploy tests E2E test → deploy build ← ビルドはここだけ
19. 原則 ディスクイメージは 全環境共用
20. © 2024 estie Inc. ディスクイメージは全環境共用 • ディスクイメージは全環境で同じものを使用するべき！ • 環境による差異は実行時の環境変数で吸収させる o 12 factor app の原則 • 共通のイメージを使えば、本番環境に近い状態でテストできる o ステージング環境と違うイメージを使っていたら、一体何をテストしたの？ということになる • 同じコードを build しても、ディスクイメージが均一であることの保証はできない o 時間差によるパッケージ内容の変化（パッケージ最新版の変化・バージョン取り消し）、外部環境の 影響（npm が落ちたり不安定になったり）、等々、 flaky になる原因はいくらでもある
21. © 2024 estie Inc. estie の選択、実際は…… • できるだけイメージ共用するようにしている、が • Next.js のビルドで静的ファイルの生成をする際の出し分けがうまくできず、環 境ごとのビルドをせざるを得ない……
22. © 2024 estie Inc. 事前ビルドを考えたフロー例（再掲） build upload migration migration stg deploy tagging migration prd deploy tagging dev deploy dev deploy stg deploy prd deploy tests E2E test → deploy build ←
23. これを全て GitHub Actions で書く ……ことはできる、できるのだが、どん どん複雑になってしまう 右図のようなファイルを1,000行管理 するのはきびしい
24. 原則 CI/CDツールは フロー整理中心
25. © 2024 estie Inc. CI/CD ツールの責任範囲を狭める • 多くのツールは "なんでも" できるが、それぞれ得意分野がある • CI/CD ツールはフロー管理だけにし、アプリケーション固有のロジックは別ファイルに移す • 責任分界点の整理のためでもある o build, test の論理はローカルや開発環境、 devcontainers 等でも再利用できるべき o 処理の編集による影響範囲を最小化。「フロー全体を壊しそうで怖い」にしない o 人は「誰でもソースコードを触れる」では触らない。個人の責任感はファイル単位で発生する
26. © 2024 estie Inc. フロー全体は Actions で管理 .github/workflows 以下 ほとんど変更しない。SRE 管理 処理の中身はスクリプト /scripts/ 以下 SWE が頻繁に更新する build upload E2E test
27. © 2024 estie Inc. 事前ビルドを考えたフロー例（再再掲） build upload migration migration stg deploy tagging migration prd deploy tagging dev deploy dev deploy stg deploy prd deploy tests E2E test → deploy build ←
28. © 2024 estie Inc. estie の選択 • 鋭意対応中！ • ビルドのロジックは Makefile とシェルスクリプトに逃がす • GitHub Actions はフロー整理に使用。社内共通 action も活用
29. © 2024 estie Inc. まとめ • デプロイの原則はこの10年、あまり大きく変わっていない • 原則を意識すると、よりデプロイを整理しやすい • 最初から意識して作るのは困難なので、皆で改善してやっていきましょう • きょう紹介した3つの原則 o デプロイはビルド・デプロイの2ステージだよ o CI/CDツールにはフローや共通処理だけ書きたいよ o ディスクイメージは全環境で共用したいよ