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
1.1k
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 における Datadog Browser Test の活用事例 / Datadog Browser Test at Reckoner
nomadblacky
0
480
Reckoner の Scala プロジェクトにおける オブザーバビリティの取り組み / Observability Initiatives in Reckoner's Scala Project
nomadblacky
0
2.3k
AWS CDK on Scala ~ Scalaでインフラ管理してみたはなし / Manage infrastructure with AWS CDK on Scala
nomadblacky
0
4.7k
Slinky で Scala.js 製 React Webアプリケーションを つくったはなし / How to build a Scala.js React web application in Slinky
nomadblacky
1
5.2k
面倒なことはScalaスクリプトにやらせよう / let scala scripts do the troublesome things
nomadblacky
0
1.1k
Other Decks in Programming
See All in Programming
Swift Concurrency - 状態監視の罠
objectiveaudio
2
530
Go言語はstack overflowの夢を見るか?
logica0419
0
350
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
380
あなたとKaigi on Rails / Kaigi on Rails + You
shimoju
0
160
Claude CodeによるAI駆動開発の実践 〜そこから見えてきたこれからのプログラミング〜
iriikeita
0
270
「ちょっと古いから」って避けてた技術書、今だからこそ読もう
mottyzzz
11
6.8k
Introducing ReActionView: A new ActionView-Compatible ERB Engine @ Kaigi on Rails 2025, Tokyo, Japan
marcoroth
3
1k
Leading Effective Engineering Teams in the AI Era
addyosmani
6
450
私はどうやって技術力を上げたのか
yusukebe
43
19k
いま中途半端なSwift 6対応をするより、Default ActorやApproachable Concurrencyを有効にしてからでいいんじゃない?
yimajo
2
430
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
170
What's new in Spring Modulith?
olivergierke
1
150
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Side Projects
sachag
455
43k
Producing Creativity
orderedlist
PRO
347
40k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3k
Done Done
chrislema
185
16k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
31
2.7k
Building Applications with DynamoDB
mza
96
6.7k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
How to train your dragon (web standard)
notwaldorf
97
6.3k
KATA
mclloyd
32
15k
Context Engineering - Making Every Token Count
addyosmani
6
260
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