Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

[email protected]

May 02, 2022
Tweet

Other Decks in Technology

Transcript

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

    View full-size slide

  2. Yoshiki Matsuda
    2
    ● バックエンドエンジニア @CADDi
    ● キャディでは受発注業務アプリケーションをRust
    で開発
    ● 前職ではGoでバックエンド開発
    ● 開発環境
    ○ Neovim
    ○ wezterm
    ○ Arch Linux

    View full-size slide

  3. 3
    今日お話しするプロダクト
    サプライチェーンの
    可視化
    発注先パートナーの選定
    ※ リプレイス前の画面です

    View full-size slide

  4. なぜリプレイスするのか?
    4
    ● 「多品種少量・受注生産」のみならず「中量産・見込
    み生産」へとビジネスが拡張
    BOM
    (部品表)
    製品
    製品
    製品
    製品
    見積
    受注
    発注
    発注
    案件
    製品
    製品
    製品
    発注
    発注
    案件
    製品
    製品
    製品
    発注
    発注

    View full-size slide

  5. 既存コードベースの拡張ではダメだった?
    5
    ● 既存コードベースの拡張でも、対応できなくはなかった
    ○ Entity間の関係性を全面的に見直す必要がある
    ● 工数を考えると、リプレイスしたほうが得と判断
    ○ 互換性確保のために工数を割く必要がない
    ○ 現在のビジネスモデルを前提に最適な設計ができる
    ○ ついでに技術的負債も返済できる
    ● 社外ユーザー様が関わる部分のみ互換性を確保

    View full-size slide

  6. 6
    リプレイスの全体像

    View full-size slide

  7. リプレイスの方針
    7
    ● YAGNI(You Ain’t Gonna Need It)を重視
    ○ 早すぎる抽象化・最適化を避ける
    ● 学習コストの削減
    ○ 一貫性のある規約によってコードベースを構築
    ○ ドメインロジックに集中できる状態
    ● テスタビリティの向上
    ○ 外部I/Oはすべてモック化可能な設計に
    ○ 結合テストも自動化する

    View full-size slide

  8. 全体アーキテクチャ
    8
    マイクロサービスはコンテキスト単位で分割
    - BOM(部品表)
    - 見積
    - 受注
    - 発注
    - サプライチェーン設計
    - 取引先情報
    - ユーザ情報
    - etc…
    DBは将来的に分割できるよう
    マイクロサービスごとに
    スキーマを分けて運用
    マイクロサービス群の外側の他サービスとは
    Cloud Pub/Subで連携
    (gRPCを同期的に叩いているケースもあり)
    マイクロサービス間はgRPC APIで
    同期的に通信
    コンポーネント横断での開発を促進す
    るため、リプレイス対象のマイクロ
    サービス群の開発言語はRustに統一

    View full-size slide

  9. なぜRust?
    9
    ● 型の表現力の高さと堅牢性
    ○ Option / Result
    ○ パターンマッチ
    ○ trait
    ● キャディでは最も利用経験者の多い言語
    ○ 現状もRustなので当たり前ではあるのですが……
    ○ チーム間の人員流動性を確保できる
    ● 社内に蓄積された知見を利用できる

    View full-size slide

  10. Rustへの懸念
    10
    ● 新規メンバーの学習コストが大きいのでは?
    ○ 他の言語でも、言語未経験の新規メンバーに一定の学習コストが発生
    するのは同じ
    ○ これまでに入社したRust未経験メンバーも無事にキャッチアップでき
    ている
    ● 外部SDKが提供されない等で困るケースが発生する
    のでは?
    ○ これまでの経験上、大きな問題は生じていない
    ○ 仮にそのようなケースが発生した場合、外部SDKに依存するマイクロ
    サービスのみ別の言語で開発する選択肢もある

    View full-size slide

  11. 11
    リプレイスのポイント

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  14. ドメイン駆動設計
    14
    ● 境界付けられたコンテキストの内側に集約を定義
    ○ 集約は1つまたは複数のエンティティから構成される
    ● データの更新は必ず集約単位で行う
    ○ それぞれの集約は、集約内部のデータの不変条件を担保
    BOM(部品表)コンテキスト
    集約 集約
    見積コンテキスト
    集約 集約
    受注コンテキスト
    集約 集約
    発注コンテキスト
    集約 集約

    View full-size slide

  15. crateを細分化
    15
    ● crateは他の言語でいうパッケージやモジュールに相当
    ● 1つのマイクロサービスの内部を多数の小さなcrateに分割
    ○ ビルド時間短縮による開発者体験の向上
    ○ リプレイス前は一部のcrateが肥大化し、ビルド時間のボトルネッ
    クとなっていた
    Domain
    Usecase A Usecase B
    gRPC Handler A Repository A Repository B
    App (Entrypoint)
    gRPC Handler B

    View full-size slide

  16. テスタビリティ向上
    16
    ● mockallクレートでRepositoryのtraitをモック化し
    て単体テスト
    ○ リプレイス前は、データベースI/Oに独自の社内ライブラリを利用
    していた関係で、Usecase層のテストが書きづらかった
    ● 結合テストのコードもRustで書いている
    ○ gRPCリクエストを飛ばすテストコード専用のcrateを定義
    ○ cargo testで走らせる

    View full-size slide

  17. 苦労していること
    17
    ● ドメインモデリング
    ○ 事業規模拡大により、案件担当者、検品拠点スタッフ、会計担当者
    など、ユーザーごとのニーズの多様性が増大
    ○ 見込み発注、在庫引当、装置一式組立……
    ● マイクロサービス
    ○ サービス間通信、分散トレーシング、サービスメッシュ……
    ● テスト・QA
    ○ Rustの型の厳しさの代償として、テストコードを書くコストが重い
    ○ UIまで含めたe2eテストも自動化したいが、まだ手つかず

    View full-size slide

  18. 18
    おわりに

    View full-size slide

  19. We are hiring!
    19
    ● 以下のような方、一緒に開発しませんか?
    ○ 複雑な業務ドメインのモデリングが好きな方
    ○ 高速で変化するビジネスモデルに対応できる柔軟なソフトウェア
    アーキテクチャを探求したい方
    ○ モダンな技術をフル活用して事業価値を実現したい方
    ● ぜひカジュアルにお話ししましょう
    ○ ご応募はこちらから: https://corp.caddi.jp/recruit/eng

    View full-size slide