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
recruiting@caddi.jp
April 28, 2022
Technology
0
910
Kotlin製のWebアプリケーションをRustでリプレイス_220428
recruiting@caddi.jp
April 28, 2022
Tweet
Share
More Decks by recruiting@caddi.jp
See All by recruiting@caddi.jp
【CADDI VIETNAM】Company Deck for Engineers
caddi_eng
0
320
CADDi Company Deck_Global.pdf
caddi_eng
0
210
[ English ] Company Overview for Engineers
caddi_eng
0
2.4k
エンジニア向け会社紹介資料
caddi_eng
16
380k
CADDi 会社紹介・採用説明資料
caddi_eng
11
920k
機械学習チームのモノレポ移行
caddi_eng
0
570
BtoB SaaS を支える 認証認可基盤の設計
caddi_eng
0
1.2k
2023.01_CADDi Thailand Company Overview
caddi_eng
0
15k
20220826_Company Briefing Online Event
caddi_eng
0
560
Other Decks in Technology
See All in Technology
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
130
Ruby on Railsで持続可能な開発を行うために取り組んでいること
am1157154
3
160
設計を積み重ねてシステムを刷新する
sansantech
PRO
0
170
いまからでも遅くない!コンテナでWebアプリを動かしてみよう!コンテナハンズオン編
nomu
0
160
AWSを活用したIoTにおけるセキュリティ対策のご紹介
kwskyk
0
380
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
5
910
MIMEと文字コードの闇
hirachan
2
1.4k
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
400
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
310
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
12
3.9k
日経のデータベース事業とElasticsearch
hinatades
PRO
0
240
NFV基盤のOpenStack更新 ~9世代バージョンアップへの挑戦~
vtj
0
360
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
74
9.2k
Designing for Performance
lara
604
68k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Thoughts on Productivity
jonyablonski
69
4.5k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
It's Worth the Effort
3n
184
28k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Making Projects Easy
brettharned
116
6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Raft: Consensus for Rubyists
vanstee
137
6.8k
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に • 同時並行のリプレイスは意思決定のスピードや手戻りと の付き合い方が大事そう