見出し画像

ドクターメイトがプロダクションコードにRustを選んだワケ

もつお

はじめに

ドクターメイトでは7/8（月）から「夏のnote祭り2024」を開催しています。ドクターメイト株式会社でプロダクト開発の執行役員をしています榎本が担当します。昨日の山ちゃんに続いての投稿です。

さてさて、私はいわゆる1人目エンジニアでして、2021/10からドクターメイトに関わる様になって以来、様々な技術選定を行ってきました。
最近では、カジュアル面談などで「Rustをプロダクションコードで使われている企業って珍しいですよね！なぜ、Rustを選定したのですか？」と聞いて頂くことも非常に多くなってきたので、この記事では日中医療相談及び夜間オンコール代行のAPI開発で採用されているRustに焦点を当てていきたいと思います。

「なぜ私たちはRustを選定したのか？」「実際使ってどうだったのか？」、を選定に至るまでの経緯と共にお伝えすることで、少しでもRustや弊社に興味を持つ方が増えると嬉しいです。

現在の技術スタックについて

現状、私たちが社内外に提供しているソフトウェアの多くの構成はざっくりと下記のようになっています。
(弊社のさらに詳しい技術スタックについては→What we useをご覧ください)

  • フロントエンド (ネイティブアプリ)

    • React Native (TypeScript)

  • フロントエンド (Web)

    • Next.js (TypeScript)

  • バックエンド

    • NestJS (TypeScript)

    • axum (Rust) → 今回のメインテーマ

  • インフラ

    • Google Cloud Platformの各種サービス

採用までの経緯

2021/10 1人目正社員エンジニア (私)がジョイン！原初の構造を作る

この時点では「何を作りたいか」がかなりふわっとしている中で、弊社が提供している「医療相談」から自社プロダクト化しよう！という流れに。
この時にご協力いただいた業務委託の方は数名いたものの、フルコミットではなく私が中心になってコードを書いていくことに。
非常に限られたリソースの中で

  • ネイティブアプリ開発をキャッチアップしながら一生懸命バックエンド書きたくない！

  • インフラにコストもかけたくない！(固定費コワイ)

  • でも動くものは作りたい！

ということでReact Native + Firebase(Auth,Firestore,Cloud Storage)を中心とした技術スタックが採用されていきました。

2023/4くらい〜 導入施設増加により後方互換性に課題が発生

ここまで限られた施設様に使っていただいていたアプリケーションなのですが、品質の安定と契約数の増加に伴い、利用施設が一気に増えていきました。これによって、モバイルアプリ特有のアップデートが一気に課題化してきます。
介護施設さんが保有している端末やネットワーク環境次第で古いバージョンのアプリが使われてしまう制約がある一方で、前述の構成だとフロントエンドにバックエンドとなるFirestore(永続化層)がベッタリと依存してしまっており、常にエンジニアは後方互換性を気にしながらの開発を余儀なくされてしまうことに…

2023/6〜 BFF (API) 化の動きについて検討を開始。APIで使用する言語についての検討が始まる

アプリから Firestore を直接読み書きしているのを、 Web API 経由に変更することで、今後の改修や機能追加を容易にする方針をチームで策定。
この時にメンバーが保有している技術スタックを加味してAPIをTypeScriptで作るかRustで作るかの検討が始まりました。

↓当時のメモがこちら

2023/8〜 検討を重ねRustの採用を決定

採用したい理由・したくない理由それぞれの意見を交換。
エンジニアからでた意見を一部取り上げると…下記が挙げられていました。

Rustを採用したい理由

  • develperが選ぶ好きな言語ランキングで一位なのでどんなものかと思っている

  • 実行時の性能が高い

  • 最大限安全になるよう考慮されている

  • 低レイヤーから高レイヤーまで幅広い環境に一本で対応できる

    • Webアプリケーションなど軽量言語が中心の領域でも十分に使える

    • WASMなどにも適用

Rustを採用したくない理由

  • Firestoreを扱う上での公式sdkがない

  • サードパーティ製のライブラリに不安がある

  • 「顧客価値」の観点での直接的なメリットがあるか不明

  • キャッチアップすべき技術が増える

考えるべきポイントは多くありましたがが、最終的には開発が大切にするカルチャーに則って
「迷った時には、一番「ワクワクする」選択を」
という観点からRust採用を決定します。

↓こちらはドクターメイトのカルチャーについての記事

結果、採用してどうだったか

技術的なキャッチアップの困難さはありましたが、総合的に見ると「よかった！」と思っています。簡単なPros/Consをまとめていくと

Pros

Cons

  • 公式SDKが無いのはそれなりに辛い (が自力で乗り切るというProsにも繋がった)

  • キャッチアップコストをそれなりに支払う必要はある。

    • この部分については下記に詳述していきます。

ドクターメイトが技術的なキャッチアップをどう進めていったか

  • ごく基本的な部分についてはAt Coderを日々解く

毎日の活動記録

  • 比較的要件が単純なバックログをモブプロを通じて対応して共通知を作る

これは一部のメンバーだけなのですが、Rust製のOSSを書きながら、スペシャリストのPRを受け続ける、というのもありました。

Tech LeadからPRをお納めされる図

現在では、各メンバーのキャッチアップや基盤の整備が進み、特に言語特有のつらみを感じることなく開発を推進できていると思います。

まとめ

ここまでRust選定に至るまでの経緯やPros/Consなどをまとめてきましたが、おおまかにまとめるとこんな方や組織にオススメかと思います。

  • 厳格な型付けにより安全な開発をしたい

  • 実行時の性能が良いものを選びたい

  • エコシステムは発展途上なところもあるので「なければ作る！」ができる

We're Hiring!!

Rustを使った開発をしてみたい！興味ある！プロダクションコードでどう使ってるの？などありましたら、お気軽にお話ししましょう！
持続可能な介護の仕組みを一緒に創る仲間を募集中です！

(おまけ)技術選定を語った動画コンテンツもあります！

当社の技術選定の経緯＋αをLAPRAS様のエンジニアトークで喋ってますので、こちらもぜひぜひご覧ください！

いいなと思ったら応援しよう！