SYNに転職してChompyの運営に参加しました
2020年12月22日
Chompyは現在渋谷を中心としたエリアで展開するフードデリバリーサービスです。 フードデリバリーサービスは一般的なウェブサービスと比べた場合に、1つのサービスでありながら、3種類のアプリがあるという特徴があります。 1つめは飲食店などのパートナー用のアプリ、2つめは料理を配達するクルー用のアプリ、3つめは料理を注文するユーザー向けのアプリです。 私はこれら3つのアプリを束ねるバックエンドアプリケーションのエンジニアとして参加しました。
技術スタック
詳しくはCTO 八木のNoteに書いてありますが、バックエンドの技術スタックとしては、Go+gRPC(-Gateway)+GCPがメインです。 アプリケーションは前職から引き続きGo+gRPCで書いていますが、GCPで使っているサービスは結構別のもになっています。 前職では、ランタイム環境はGKE、データベースはMySQL/Cloud Datastore/Cloud Spanner、メッセージングはCloud Pub/Subがメインでした。 Chompyでは、ランタイム環境はGAE/Cloud Function/Cloud Run、データベースはCloud Firestore、メッセージングはCloud Tasksを使っています。 比較すると、基本的にはサービスの規模に応じて選ぶクラウドサービスが変わるということが見えて面白いですね。 規模が大きいと、求められるのは大量のリクエストを安定して処理する能力になるので、パフォーマンスが高いCloud SpannerやCloud Pub/Subが選ばれます。 規模が小さいと、求められるのはいかに少ない工数でサービスを伸ばしていけるかということになるので、更新トリガーがあるCloud Firestoreや遅延キューがあるCloud Tasksなど、利便性の高いクラウドサービスが選ばれます。 パフォーマンスと利便性はトレードオフになっている場合が多いので、規模が小さい間は利便性を取り、規模が大きくなった後でパフォーマンスが高いものに移行するのがよさそうです。
フードデリバリーサービスの難しさ
フードデリバリーサービスを一般的なウェブサービスと比べたときの難しさとして、リアルタイム性と不確実性の高さがあります。 例えば普通のECサイトであれば、ユーザーが注文した商品が届くのは翌日以降です。 さらに、配達も大手の物流網に乗せられるため、比較的安定して予定時間に届けることができます。 ところが、フードデリバリーでは、ユーザーの注文から配達完了までが、ほとんどの場合1時間以内に完結します。 加えて、毎回異なる配達ルート、天気、気温、交通状況、配達クルーの人数、飲食店の調理状況など、様々な要因によって配達環境がリアルタイムに変化します。 そんな不安定な配達環境の上で、予定時間内に配達を完了できるように、配達クルーに仕事を依頼するのがフードデリバリーサービスの難しさです。 今までやっていたマイクロサービスなどの技術的な難しさとは違った性質の難しさなので、技術だけでなく、オペレーションなども含めた改善をしなくてはいけないところが、やりがいのある部分です。
おわりに
まだ働き始めたばかりですが、私が関わった新機能が既にリリースされていたりして、早いスピード感で仕事ができるのは楽しいです。 スタートアップというと、スピードだけを重視して技術的なクオリティは低いというイメージが多そうな気がしますが、私はこれらの2つは同時に達成できると思っているので、これからは最高のChompyを最高のスピードと最高の技術クオリティで作り上げていこうと思っています。 まだまだやるべき事は多く、様々なスキルセットを持ったメンバーに集まってもらいたいと思っているので、ちょっと普通のウェブサービスとは違うことをやってみたいという方は、私のTwitterのDMかSYNの採用ページからご連絡ください。