🙌

Camelのアーキテクチャ・技術選定の背景を説明します!

2024/01/31に公開

株式会社tacomsでCTOをしている井上(@masa1934yg)と申します!
tacomsには創業期からジョインし、開発業務から組織作り、お客様やパートナー企業との折衝まで、事業グロースに関わる業務はなんでも幅広く担当しています。
趣味はバッティングセンターに行ったり、野球観戦行くことで小学生時代から変わらず巨人推しです!
お気に入りだった大塚のバッセンが昨年無くなってしまったので凹んでますmm

現在tacomsでは絶賛エンジニア採用強化中ということで、エンジニアの方向けにサービスの技術構成などを解説した、「株式会社tacoms エンジニアチーム Entrance Book」を先日リリースしました!

https://speakerdeck.com/tacoms/zhu-shi-hui-she-tacoms-enziniatimu-entrance-book

今回は、こちらのEntranceBookのご紹介と併せて、tacomsでの技術選定の背景や、開発観点でtacomsのプロダクトの面白い点などをご紹介していきたいと思います!

Camelとは 〜プロダクトの紹介〜

tacomsは、飲食業界向けに「Camel(https://www.camel-delivery.com/) 」というVertical SaaSを提供しているスタートアップです。

私たちが現在提供しているCamelというサービスは、様々なデリバリー・テイクアウト・モバイルオーダーサービスとAPIを通じて連携することで、

  • デリバリーやテイクアウトといった、イートイン以外の店外の注文や売上は、全て1台のタブレットで一元管理できる
  • 既に厨房内に設置してある、POSレジシステムやキッチンプリンターなどと連携することで、イートインと店外の売上・注文データを統合管理できる

といったことを実現するサービスです。
これにより、店舗ではイートインのオペレーションを崩すことなく、簡単にデリバリーやテイクアウトといった店外の売上獲得に向き合うことができるようになります。

※より詳細のプロダクトの説明については、会社紹介資料をぜひご覧ください!!
https://speakerdeck.com/tacoms/zhu-shi-hui-she-tacoms-hui-she-shao-jie-zi-liao

どのようにオペレーションを一元管理している?

Camelでは国内のデリバリー・テイクアウトサービスとAPI連携することで弊社の端末1つで店舗のオペレーションが完結するような機能を提供しています。
例えば、注文者が書くデリバリーサービスから注文をしてから、Camelを利用して店舗スタッフさんが店舗で注文を確認するまでの流れは以下の図のような形になっています。

まず、注文者が各サービス上で注文を完了すると、各サービスからwebhookという形でイベントが通知されます。そのイベントの中に店舗IDや注文IDなどの識別情報が送信されてくるため、それらのIDを使って、弊社側で注文の詳細情報を取得し、返却されたデータを弊社のDBに登録、注文情報を店舗のタブレット端末に表示するという流れです。
※連携している全企業が上記のような連携ではなく、あくまで一般的な例です。

Camelの技術構成・選定について

Camelのインフラ全体像は以下のようになっています。

特徴としては、

  • 基本的に全てAWSのサービスを利用
  • フロントエンドはどちらもSPAの基本的な構成、バックエンドAPIサーバーは1つのモノレポで管理しており、サーバーとしてもモノリスで構成
  • DBにはAurora(MySQL)とDocumentDBを採用しており、メインのDBはAuroraで一部特殊な要件を持ったデータを永続化する際はDocumentDBという棲み分けになっている
  • コアのバックエンドAPIサーバーとは別でいくつかのサブシステムが動いており、プロダクトの重要な部分である連携部分や非同期処理を行っている
  • 社内ツールにはRetool(https://retool.com/)という社内の管理画面が簡単に構築できるサービスを使用しており、社内のオペレーション自動化を実現

などとなっています。

React/TypeScript/Go/AWSという技術選定の背景について

Camelのプロダクトでは、フロントエンドはReact+TypeScript、バックエンドはGo、インフラにAWSという技術選定になっています。

プロダクト開発当初、技術選定にあたっては「PMFまでのスピードを最優先とした上で、中長期で見ても開発速度が落ちないようするにはどうしたら良いか」という点を重視して選定を進めました。
プロダクトがないスタートアップにとって、採用力などの視点は一旦後回しに考え、とにかく素早くPMFさせるためにどうすれば良いかを検討した結果、主に以下3つの視点から意思決定しました。

  • 作り上げるプロダクトとその機能を最も容易に実現できる言語
  • 認識齟齬や危険なメソッドを生じづらくするため静的型付け機能を保持する言語
  • 初期のメンバーが最も慣れている言語

技術選定の背景などは、特に初期のスタートアップでの技術選定の参考になるのではと思いますので、また後日noteなどで詳細をお話しできればと思います。

エンジニア視点から見たCamelというプロダクトの面白い点

「一元管理」と言うワードで想像がつく方もいらっしゃるかもしれませんが、Camelというサービスにおいては、飲食店のあらゆる注文を受注するハブとなるプロダクトであるため、高い可用性が要求されます(Camelが1時間止まると、店舗では1時間のデリバリー売上の損失に繋がってしまう)。

また、コアの機能は外部サービスとのAPI連携によって実現しているため、外部サービスとの共存が重要なサービスとなっています。

このような特徴を踏まえ、tacomsのプロダクト開発における面白さをエンジニア視点から紹介したいなと思います。

①多種多様なwebAPIを使用することでwebAPIへの知見が深まる

2023年現在、Camelでは20社以上の外部サービス事業者の方々とAPIで連携しています。 連携を行う中で各社の様々なwebAPIを利用させていただく機会があり、感動するほど綺麗に設計されたAPIもたくさん見てきました(その逆も。。。😇)。

様々なAPIを利用する中で何が正しいのか確認するため、IETFやW3Cなどの標準仕様を調べる機会も増えてエンジニアとしては良い経験になっていると思います。
2022年にはCamelとして外部向けの公開API(Camel Public API)もリリースしましたが、Camel Public APIの設計時にもかなり参考になりました。

例えば、以下のポイントなどは、Camelというプロダクトの開発を通じて参考になったなと感じています。

  • Content-type, Accept-EncodingなどRequest headerの正しい使い方
  • PUTと冪等性
  • API責務に対しての適切なHTTPメソッド
  • API責務に対しての適切なリソース名
  • APIのバージョン管理
  • ページネーションの設計
  • OpenAPIにおけるリクエスト制限の設計・実装
  • OAuth2.0のクライアント・クレデンシャルズフローや認可コードフロー等

②複数の似通ったモデルの関心事を分離して、可読性・保守性の高いコードを設計する必要がある

Camelという一元管理サービスの特性上、とにかく同じような処理やクラス(構造体)が頻発してきます。
例えば、デリバリーサービスAのOrderモデルとのデリバリーサービスBのStoreモデルが似たような構造であったり、複数サービス間でAPIを叩くタイミングが類似していたり、といったことが多いです。 これはつまり、このデリバリーサービスのJSONをデコードする構造体はこのデリバリーサービスでも流用できるのでは?とか、このユースケースほぼ一緒だから分岐で書いてしまえ!ということも出来るわけです。

しかし弊社では各デリバリー・テイクアウトサービスに関わる処理に関してはDRY原則を意識的に使わないようにしています。
その理由はサービスごとの仕様変更に対する拡張性が損なわれるからです。

ある時点ではデリバリーサービスAとデリバリーサービスBの注文確定ユースケースがほぼ同じ処理だとしてもそれが未来永劫同じことは保証出来ませんし、実際APIのパラメータに変更が加わることは頻繁にあります。その際、もし同じユースケースで2つのデリバリーサービスを扱っていたら、一方のデリバリーサービスの変更をするだけなのに変更のない方にも気を配らなければなりません。これは単一責任の原則に反しますし拡張性のあるコードとは言い難いと思います。

もちろん、DRY原則が悪いとは全く考えておらず、tacomsでも将来外部要因で変更される可能性が少ない処理については積極的にDRYの原則を使っていく方針です。重複した処理は記述量が増えますし、コピペミスによる予期せぬミスが発生する可能性も孕んでいるためDRYに出来るところはしたほうが良いだろうなと考えています。

エンジニアチームの雰囲気について

tacomsのエンジニアチームは、平均年齢はだいたい30歳くらい、明るい雰囲気なメンバーが多く、MTGなども和気あいあいとした雰囲気で進むことが多いです!
新卒からずっとエンジニアというメンバーと転職してエンジニアになったメンバーが半分半分というチーム構成で多様なバックグラウンドを持ったチームであることも1つの特徴だったりします👏

MTGのファシリテーションやCSチームからの問い合わせ対応などもエンジニアチーム全員が対応するようになっており、開発以外のことにも比較的積極的に取り組むメンバーが多いチームです!

最後に

エンジニアチームの各ポジションで絶賛採用中ですので、少しでもtacomsに興味を持っていただけた方は、ぜひ会社HPから、ご連絡いただけると嬉しいです!カジュアルにお話ししましょう!

tacomsテックブログ

Discussion