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
Kotlin製のWebアプリケーションをRustでリプレイス_220428
Search
[email protected]
April 28, 2022
Technology
0
1k
Kotlin製のWebアプリケーションをRustでリプレイス_220428
[email protected]
April 28, 2022
Tweet
Share
More Decks by
[email protected]
See All by
[email protected]
キャディでのApache Iceberg, Trino採用事例 -Apache Iceberg and Trino Usecase in CADDi--
caddi_eng
0
420
製造業の会計システムをDDDで開発した話
caddi_eng
3
1.9k
【CADDI VIETNAM】Company Deck for Engineers
caddi_eng
0
1.6k
CADDi Company Deck_Global.pdf
caddi_eng
1
490
[ English ] Company Overview for Engineers
caddi_eng
1
8.9k
エンジニア向け会社紹介資料
caddi_eng
17
580k
キャディ株式会社 会社紹介・採用説明資料
caddi_eng
12
1.2M
機械学習チームのモノレポ移行
caddi_eng
0
690
BtoB SaaS を支える 認証認可基盤の設計
caddi_eng
0
1.5k
Other Decks in Technology
See All in Technology
20251014_Pythonを実務で徹底的に使いこなした話
ippei0923
0
200
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
やる気のない自分との向き合い方/How to Deal with Your Unmotivated Self
sanogemaru
0
510
RDS の負荷が高い場合に AWS で取りうる具体策 N 連発/a-series-of-specific-countermeasures-available-on-aws-when-rds-is-under-high-load
emiki
3
2.3k
GoでもGUIアプリを作りたい!
kworkdev
PRO
0
150
ガバメントクラウドの概要と自治体事例(名古屋市)
techniczna
3
240
プレーリーカードを活用しよう❗❗デジタル名刺交換からはじまるイベント会場交流のススメ
tsukaman
0
170
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
8.8k
20251010_HCCJP_AdaptiveCloudUpdates
sdosamut
0
130
防災デジタル分野での官民共創の取り組み (2)DIT/CCとD-CERTについて
ditccsugii
0
300
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
6
1.6k
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
930
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
20
1.2k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
Six Lessons from altMBA
skipperchong
29
4k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
The Invisible Side of Design
smashingmag
302
51k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Mobile First: as difficult as doing things right
swwweet
224
10k
GitHub's CSS Performance
jonrohan
1032
470k
Why Our Code Smells
bkeepers
PRO
340
57k
Transcript
A B O U T Kotlin製の業務Webアプリケーションを Rustでリプレイス
Takumi Karibe 2 • 2021/09 入社 • Backend Engineer @CADDi
• 受発注システム/パートナー連携システムのTL • 今まではiOSアプリ作ったり経路探索エンジン作ったり ブロックチェーン関連のサービス作ったり • 明日はひつまぶしを食べる
3 受発注管理プロダクト(Klein) サプライチェーンの 可視化 発注先パートナーの選定 ※ リプレイス前の画面です
4 製造パートナー連携プロダクト(SPP) キャディから受注済の案件一覧 キャディからの見積依頼を一括処理
5 構成 SPP-API Kubernetes Klein Kubernetes PostgreSQL Cloud SQL
6 構成 SPP-API Kubernetes Klein Kubernetes PostgreSQL Cloud SQL 今回はここの話
なぜリプレイスするのか? 7 • 組織的問題 ◦ チーム内に初期設計者やKotlinに慣れた人いない ◦ 新規の機能開発や運用の効率が悪い • 技術的負債
◦ ステータスを重複して管理しているため分散トランザクション を行っており、バグの温床となっている ◦ 新Kleinではドメインモデルが変更されるため、既存モデルと同 居させるとバグが埋め込みやすいコードになってしまう • タイミング ◦ Kleinのリプレイスのために工数を確保している今しかタイミン グがないだろうと考えた
リプレイスの要件 8 • 納期遵守 ◦ Kleinのリプレイスが本目的なので、その計画を破綻させてはい けない • 既存機能を変更しない ◦
UIはリプレイスしないため、バックエンドが変更されても既存 の機能が使えるようにする必要がある • Kleinのリプレイスと同時並行して開発 ◦ 納期はKleinのリプレイスと同じであるため、同時並行で開発す る必要がある
9 現在の構成(リプレイス中) SPP-API Kubernetes 新Klein Kubernetes PostgreSQL Cloud SQL 新SPP-API
Kubernetes Klein Kubernetes
10 今後の構成(リプレイス後) SPP-API Kubernetes 新Klein Kubernetes PostgreSQL Cloud SQL 新SPP-API
Kubernetes Klein Kubernetes
KotlinからRustへの変更 11 • 社内での開発実績や慣れている人が多く知見がある • コンパイラが堅牢なので短納期な状況では品質担保の手 間が減って嬉しい • リリース後に体制変更があっても新Kleinと新SPP-APIで 言語は変わらないため新規参入者の学習コストは総体的
に減る • リプレイス後の機能開発や運用効率を高めたい ◦ 負債の返済ではなく複利の効く資産形成として攻めのリプレイス
利用ライブラリ 12 • GraphQL ◦ https://github.com/async-graphql/async-graphql • WAF ◦ https://github.com/tokio-rs/axum
• ORM ◦ https://github.com/diesel-rs/diesel • gRPC ◦ https://github.com/hyperium/tonic
ベストプラクティスに倣いつつシンプルな設計 13 • Clean Architectureの採用
ベストプラクティスに倣いつつシンプルな設計 14 • 外部接続を抽象化した存在をおかない ◦ UseCaseはinfra層への個別の接続を明示的に呼び出す ◦ データの所在がわかりやすくなるため、実装を追いやすく、レ ビューコストも下がる ◦
Traitでinfra接続への依存関係を表現しているため、意図しない 接続は呼び出せない
設計・開発の考慮② 15 • データの置き場所を整理 ◦ 分散トランザクションを上手く行うのではなく、分散トランザク ションを避けるように設計 • 可逆的な変更の意思決定は後回しにする ◦
不可逆な変更や他の選択肢に選び直すコストが高い場合を除い て、意思決定の速度を優先 ◦ Unknown * Unknown にならないように他の選択肢のpros/consの整 理と選択を変える場合の手段は考えておく
設計・開発の考慮③ 16 • 依存先の開発状況を意識しない開発 ◦ 新Kleinも現在進行形で開発が進んでいる ◦ infra層で仕様を隠蔽する ▪ 新Kleinのドメインモデルとの変換を集約
◦ 手戻りを許容し仮でも良いので実装を進める • PRで議論ではなく、細かい同期的なレビューで開発着手 からマージまでのリードタイムを短縮 ◦ どれだけ書いてもmainブランチにマージされなければ価値はゼロ ◦ より良い書き方があったとしてもマージを優先 ▪ コメントルールを整備して後で取り組めるように
まとめ 17 • 開発効率向上のためにKotlinからRustに • 同時並行のリプレイスは意思決定のスピードや手戻りと の付き合い方が大事そう