Rust製の業務WebアプリケーションをRustでリプレイス_220428

Transcript

1. A B O U T Rust製の業務Webアプリケーションを Rustでリプレイス
2. Yoshiki Matsuda 2 • バックエンドエンジニア @CADDi • キャディでは受発注業務アプリケーションをRust で開発 • 前職ではGoでバックエンド開発 • 開発環境 ◦ Neovim ◦ wezterm ◦ Arch Linux
3. 3 今日お話しするプロダクト サプライチェーンの 可視化 発注先パートナーの選定 ※　リプレイス前の画面です
4. なぜリプレイスするのか？ 4 • 「多品種少量・受注生産」のみならず「中量産・見込 み生産」へとビジネスが拡張 BOM （部品表） 製品 製品 製品 製品 見積 受注 発注 発注 案件 製品 製品 製品 発注 発注 案件 製品 製品 製品 発注 発注
5. 既存コードベースの拡張ではダメだった？ 5 • 既存コードベースの拡張でも、対応できなくはなかった ◦ Entity間の関係性を全面的に見直す必要がある • 工数を考えると、リプレイスしたほうが得と判断 ◦ 互換性確保のために工数を割く必要がない ◦ 現在のビジネスモデルを前提に最適な設計ができる ◦ ついでに技術的負債も返済できる • 社外ユーザー様が関わる部分のみ互換性を確保
6. 6 リプレイスの全体像
7. リプレイスの方針 7 • YAGNI(You Ain’t Gonna Need It)を重視 ◦ 早すぎる抽象化・最適化を避ける • 学習コストの削減 ◦ 一貫性のある規約によってコードベースを構築 ◦ ドメインロジックに集中できる状態 • テスタビリティの向上 ◦ 外部I/Oはすべてモック化可能な設計に ◦ 結合テストも自動化する
8. 全体アーキテクチャ 8 マイクロサービスはコンテキスト単位で分割 - BOM（部品表） - 見積 - 受注 - 発注 - サプライチェーン設計 - 取引先情報 - ユーザ情報 - etc… DBは将来的に分割できるよう マイクロサービスごとに スキーマを分けて運用 マイクロサービス群の外側の他サービスとは Cloud Pub/Subで連携 （gRPCを同期的に叩いているケースもあり） マイクロサービス間はgRPC APIで 同期的に通信 コンポーネント横断での開発を促進す るため、リプレイス対象のマイクロ サービス群の開発言語はRustに統一
9. なぜRust? 9 • 型の表現力の高さと堅牢性 ◦ Option / Result ◦ パターンマッチ ◦ trait • キャディでは最も利用経験者の多い言語 ◦ 現状もRustなので当たり前ではあるのですが…… ◦ チーム間の人員流動性を確保できる • 社内に蓄積された知見を利用できる
10. Rustへの懸念 10 • 新規メンバーの学習コストが大きいのでは？ ◦ 他の言語でも、言語未経験の新規メンバーに一定の学習コストが発生 するのは同じ ◦ これまでに入社したRust未経験メンバーも無事にキャッチアップでき ている • 外部SDKが提供されない等で困るケースが発生する のでは？ ◦ これまでの経験上、大きな問題は生じていない ◦ 仮にそのようなケースが発生した場合、外部SDKに依存するマイクロ サービスのみ別の言語で開発する選択肢もある
11. 11 リプレイスのポイント
12. Monorepo 12 • UI / BFF / Microservices を単一のGitHub Repositoryに共存 させるモノレポ構成を導入 ◦ Repository間の移動によるコンテキストスイッチを軽減 ◦ path-filteringにより、変更されたファイルのパスに応じてCIを制御 • マイクロサービスの雛形を自動生成するスクリプトを用意 ◦ 自動生成→CIに組み込むだけで開発環境にサーバーが立ち上がる ディレクトリ構成 ./ - .circleci - proto - rust - common - service-a - service-b - service-c - typescript - apps - ui - bff
13. Clean Architecture 13 • ドメインロジックはDomain層に集約 • Infra層に対してはtraitを経由して依存する Domain Usecase Infra Repository Trait Repository Impl ディレクトリ構成 service-a - app - domain - usecase - infra - db_dto - repository_impl - grpc - grpc_handler - grpc_convert - common - external_libs - error
14. ドメイン駆動設計 14 • 境界付けられたコンテキストの内側に集約を定義 ◦ 集約は1つまたは複数のエンティティから構成される • データの更新は必ず集約単位で行う ◦ それぞれの集約は、集約内部のデータの不変条件を担保 BOM（部品表）コンテキスト 集約 集約 見積コンテキスト 集約 集約 受注コンテキスト 集約 集約 発注コンテキスト 集約 集約
15. crateを細分化 15 • crateは他の言語でいうパッケージやモジュールに相当 • 1つのマイクロサービスの内部を多数の小さなcrateに分割 ◦ ビルド時間短縮による開発者体験の向上 ◦ リプレイス前は一部のcrateが肥大化し、ビルド時間のボトルネッ クとなっていた Domain Usecase A Usecase B gRPC Handler A Repository A Repository B App (Entrypoint) gRPC Handler B
16. テスタビリティ向上 16 • mockallクレートでRepositoryのtraitをモック化し て単体テスト ◦ リプレイス前は、データベースI/Oに独自の社内ライブラリを利用 していた関係で、Usecase層のテストが書きづらかった • 結合テストのコードもRustで書いている ◦ gRPCリクエストを飛ばすテストコード専用のcrateを定義 ◦ cargo testで走らせる
17. 苦労していること 17 • ドメインモデリング ◦ 事業規模拡大により、案件担当者、検品拠点スタッフ、会計担当者 など、ユーザーごとのニーズの多様性が増大 ◦ 見込み発注、在庫引当、装置一式組立…… • マイクロサービス ◦ サービス間通信、分散トレーシング、サービスメッシュ…… • テスト・QA ◦ Rustの型の厳しさの代償として、テストコードを書くコストが重い ◦ UIまで含めたe2eテストも自動化したいが、まだ手つかず
18. 18 おわりに
19. We are hiring! 19 • 以下のような方、一緒に開発しませんか？ ◦ 複雑な業務ドメインのモデリングが好きな方 ◦ 高速で変化するビジネスモデルに対応できる柔軟なソフトウェア アーキテクチャを探求したい方 ◦ モダンな技術をフル活用して事業価値を実現したい方 • ぜひカジュアルにお話ししましょう ◦ ご応募はこちらから： https://corp.caddi.jp/recruit/eng