Slide 1

Slide 1 text

A B O U T Kotlin製の業務Webアプリケーションを Rustでリプレイス

Slide 2

Slide 2 text

Takumi Karibe 2 ● 2021/09 入社 ● Backend Engineer @CADDi ● 受発注システム/パートナー連携システムのTL ● 今まではiOSアプリ作ったり経路探索エンジン作ったり ブロックチェーン関連のサービス作ったり ● 明日はひつまぶしを食べる

Slide 3

Slide 3 text

3 受発注管理プロダクト(Klein) サプライチェーンの 可視化 発注先パートナーの選定 ※ リプレイス前の画面です

Slide 4

Slide 4 text

4 製造パートナー連携プロダクト(SPP) キャディから受注済の案件一覧 キャディからの見積依頼を一括処理

Slide 5

Slide 5 text

5 構成 SPP-API Kubernetes Klein Kubernetes PostgreSQL Cloud SQL

Slide 6

Slide 6 text

6 構成 SPP-API Kubernetes Klein Kubernetes PostgreSQL Cloud SQL 今回はここの話

Slide 7

Slide 7 text

なぜリプレイスするのか? 7 ● 組織的問題 ○ チーム内に初期設計者やKotlinに慣れた人いない ○ 新規の機能開発や運用の効率が悪い ● 技術的負債 ○ ステータスを重複して管理しているため分散トランザクション を行っており、バグの温床となっている ○ 新Kleinではドメインモデルが変更されるため、既存モデルと同 居させるとバグが埋め込みやすいコードになってしまう ● タイミング ○ Kleinのリプレイスのために工数を確保している今しかタイミン グがないだろうと考えた

Slide 8

Slide 8 text

リプレイスの要件 8 ● 納期遵守 ○ Kleinのリプレイスが本目的なので、その計画を破綻させてはい けない ● 既存機能を変更しない ○ UIはリプレイスしないため、バックエンドが変更されても既存 の機能が使えるようにする必要がある ● Kleinのリプレイスと同時並行して開発 ○ 納期はKleinのリプレイスと同じであるため、同時並行で開発す る必要がある

Slide 9

Slide 9 text

9 現在の構成(リプレイス中) SPP-API Kubernetes 新Klein Kubernetes PostgreSQL Cloud SQL 新SPP-API Kubernetes Klein Kubernetes

Slide 10

Slide 10 text

10 今後の構成(リプレイス後) SPP-API Kubernetes 新Klein Kubernetes PostgreSQL Cloud SQL 新SPP-API Kubernetes Klein Kubernetes

Slide 11

Slide 11 text

KotlinからRustへの変更 11 ● 社内での開発実績や慣れている人が多く知見がある ● コンパイラが堅牢なので短納期な状況では品質担保の手 間が減って嬉しい ● リリース後に体制変更があっても新Kleinと新SPP-APIで 言語は変わらないため新規参入者の学習コストは総体的 に減る ● リプレイス後の機能開発や運用効率を高めたい ○ 負債の返済ではなく複利の効く資産形成として攻めのリプレイス

Slide 12

Slide 12 text

利用ライブラリ 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

Slide 13

Slide 13 text

ベストプラクティスに倣いつつシンプルな設計 13 ● Clean Architectureの採用

Slide 14

Slide 14 text

ベストプラクティスに倣いつつシンプルな設計 14 ● 外部接続を抽象化した存在をおかない ○ UseCaseはinfra層への個別の接続を明示的に呼び出す ○ データの所在がわかりやすくなるため、実装を追いやすく、レ ビューコストも下がる ○ Traitでinfra接続への依存関係を表現しているため、意図しない 接続は呼び出せない

Slide 15

Slide 15 text

設計・開発の考慮② 15 ● データの置き場所を整理 ○ 分散トランザクションを上手く行うのではなく、分散トランザク ションを避けるように設計 ● 可逆的な変更の意思決定は後回しにする ○ 不可逆な変更や他の選択肢に選び直すコストが高い場合を除い て、意思決定の速度を優先 ○ Unknown * Unknown にならないように他の選択肢のpros/consの整 理と選択を変える場合の手段は考えておく

Slide 16

Slide 16 text

設計・開発の考慮③ 16 ● 依存先の開発状況を意識しない開発 ○ 新Kleinも現在進行形で開発が進んでいる ○ infra層で仕様を隠蔽する ■ 新Kleinのドメインモデルとの変換を集約 ○ 手戻りを許容し仮でも良いので実装を進める ● PRで議論ではなく、細かい同期的なレビューで開発着手 からマージまでのリードタイムを短縮 ○ どれだけ書いてもmainブランチにマージされなければ価値はゼロ ○ より良い書き方があったとしてもマージを優先 ■ コメントルールを整備して後で取り組めるように

Slide 17

Slide 17 text

まとめ 17 ● 開発効率向上のためにKotlinからRustに ● 同時並行のリプレイスは意思決定のスピードや手戻りと の付き合い方が大事そう