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
Scala アプリケーションのビルドを改善してデプロイ時間を 1/4 にした話 | ...
Search
KADOWAKI Takumi
September 06, 2024
Programming
1
450
Scala アプリケーションのビルドを改善してデプロイ時間を 1/4 にした話 | How I improved the build of my Scala application and reduced deployment time by 4x
2024/09/06 Scalaわいわい勉強会 #3
https://scala-tokyo.connpass.com/event/325327/
KADOWAKI Takumi
September 06, 2024
Tweet
Share
More Decks by KADOWAKI Takumi
See All by KADOWAKI Takumi
Reckoner の Scala プロジェクトにおける オブザーバビリティの取り組み / Observability Initiatives in Reckoner's Scala Project
nomadblacky
0
1.3k
AWS CDK on Scala ~ Scalaでインフラ管理してみたはなし / Manage infrastructure with AWS CDK on Scala
nomadblacky
0
4.5k
Slinky で Scala.js 製 React Webアプリケーションを つくったはなし / How to build a Scala.js React web application in Slinky
nomadblacky
1
5k
面倒なことはScalaスクリプトにやらせよう / let scala scripts do the troublesome things
nomadblacky
0
930
Other Decks in Programming
See All in Programming
C#および.NETに対する誤解をひも解く
ymd65536
0
220
タイミーにおけるデータの利用シーンと データ基盤の挑戦
marufeuille
4
3.1k
Cloud Adoption Frameworkにみる組織とクラウド導入戦略(縮小版)
tomokusaba
1
160
ポケモンで考えるコミュニケーション / Communication Lessons from Pokémon
mackey0225
4
140
pytest プラグインを開発して DRY に自動テストを書こう
inuatsu
2
240
DjangoNinjaで高速なAPI開発を実現する
masaya00
0
420
上手に付き合うコンポーネントテスト
quramy
3
1.2k
複数プロダクトの技術改善・クラウド移行に向き合うチームのフレキシブルなペア・モブプログラミングの実践 / Flexible Pair Programming And Mob Programming
honyanya
0
140
"Swarming" をコンセプトに掲げるアジャイルチームのベストプラクティス
boykush
1
160
CSC509 Lecture 03
javiergs
PRO
0
130
Quarto Clean Theme
nicetak
0
220
Kotlin Multiplatform at Stable and Beyond (Kotlin Vienna, October 2024)
zsmb
2
320
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
19
2.9k
Designing on Purpose - Digital PM Summit 2013
jponch
114
6.9k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Fireside Chat
paigeccino
32
2.9k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
30
2.6k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.4k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Code Reviewing Like a Champion
maltzj
519
39k
Bash Introduction
62gerente
608
210k
Designing for Performance
lara
604
68k
Transcript
Scala アプリケーションのビルドを改善して デプロイ時間を 1/4 にした話 2024/09/06 Scalaわいわい勉強会 #3 Copyright ©
3-shake, Inc. All Rights Reserved.
自己紹介 門脇 拓巳 (KADOWAKI Takumi) 株式会社スリーシェイク Incubation 事業部 Reckoner 開発チーム
データ処理系 Scala 製アプリケーションの 開発を行いつつ、インフラ業務などを担当 X (Twitter): @nomadblacky GitHub: NomadBlacky
Reckoner というデータ連携サービスを開発してます https://reckoner.io/ 裏側のデータ処理部分が Scala アプリケーションです
アジェンダ デプロイ、快適ですか? つらい😭😭😭 これをなんとかしました、というお話です
前提 - デプロイには Cloud Build を使用 - デプロイ時間には Scala アプリ以外のビルドも
含まれる - が、大半は Scala アプリのビルド - Scala アプリのビルド手順 - Scala ビルド用コンテナイメージのビルド - アプリケーションのコンパイル - docker build - docker push (to: Artifact Registry) - sbt-native-packager を使用 - コンテナイメージを 100種類以上 (!) 作成 Scala ビルド部分 約 40 分
改善したこと - ビルド用のコンテナイメージを事前に作成しておく - ライブラリ依存のキャッシュを使う - sbt のリモートキャッシュを使う - Cloud
Build の実行リージョンを asia-northeast1 にする - gsutil をやめて gcloud storage を使う - docker build/push の並列化
ビルド用のコンテナイメージを事前に作成しておく Dockerfile が更新されたら GitHub Actions で イメージをビルドするよう設定
ビルド用のコンテナイメージを事前に作成しておく ビルド済みのイメージを使用して 毎回実行されないように
ライブラリ依存のキャッシュを使う ci.yml deploy.yml CI で作成したライブラリ依存の キャッシュをデプロイに利用
sbt のリモートキャッシュを使う CI 時にあらかじめ pushRemoteCache で コンパイルキャッシュを保存 ライブラリ依存とともにアーカイブ
sbt のリモートキャッシュを使う デプロイ実行時に pullRemoteCache で コンパイルキャッシュを展開
Cloud Build の実行リージョンを asia-northeast1 にする キャッシュや Artifact Registry は asia-northeast1
にあるので リージョンを合わせる global だとどのリージョンでビルドが実行されるかわからない 実行リージョンによっては無駄なネットワーク転送が発生していた
gsutil をやめて gcloud storage を使う https://cloud.google.com/blog/ja/products/storage-data-transfer/new-gcloud-storage-enables-super-fast-data-transfers
gsutil をやめて gcloud storage を使う イメージとコマンドを置き換えるだけでOK (gsutil のすべての機能が使えるわけではない点には注意)
docker build/push の並列化 docker build 対象の サブプロジェクトがあまりにも多い …
docker build/push の並列化 native-packager の publishLocal で docker build すべてのサブプロジェクトに対して
並列で docker push コマンドを実行 before
docker build/push の並列化 https://docs.docker.com/reference/cli/dockerd/ --max-concurrent-uploads int Set the max concurrent
uploads (default 5) docker daemon はデフォルトでレイヤーのアップロードは 5並列 に制限されている Cloud Build のジョブはひとつのインスタンス上で実行されるため、 単に docker push コマンドを並列で実行してもこの制約に引っかかる 並列で docker push できていると思っていたが …
docker build/push の並列化 native-packager の stage で Dockerfile を出力 after
1. Dockerfile の生成 2. docker build/push を別インスタンスで実行 という2つの手順に修正
docker build/push の並列化 Dockerfile を転送して新しい Cloud Build ジョブとして docker build/push
する gcloud builds submit コマンドを使用 after build_rdap2_process_images.sh サブプロジェクトの数だけ並列で実行
結果 デプロイ時間が 1/4 になった!! 💪🥳
まとめ - 一見当たり前の設定がちゃんとできてないことがあるので確認しよう - デプロイにもキャッシュを使おう - docker build/push はホスト単位で並列化しよう -
そもそもコンテナイメージを大量に作らなくて済むほうがいいかも - 細かい最適化でも積み上げていくと大きな改善になるよ 少しでも参考になったら嬉しいです 良いデプロイライフを!
最後に Reckoner では Scala エンジニアを募集しています! - https://jobs-3-shake.com/ - https://hrmos.co/pages/threeshake/jobs/E_0220