こんにちは。エンジニアのkitagawaです。
こちらはトレタアドベントカレンダー2021 21日目の記事です。
今年は新規サービスのトレタO/Xに心血注いだ一年でした。 振り返りを込めて、トレタO/Xのバックエンドとしてマイクロサービスを導入したことについて紹介します。
新規サービス「トレタO/X」
www.toreta-ox.com トレタO/Xは飲食店向けのモバイルオーダーアプリです。飲食店の来店者はテーブルごとに渡されるQRコードが印字された紙を自身のスマートフォンで読み込んで、トレタO/Xアプリを開きます。 トレタO/Xから料理の注文が行えて、オンライン決済でスムーズに退店することができます。
トレタO/Xの特徴としては、そのお店ごとの雰囲気を表現したリッチなUIです。 そのためシステム構成は、メニューブックを柔軟に表現できるように各社ごとにフロントエンドのアプリをそれぞれ作っています。 一方でバックエンドは共通の機能を提供するSaaSモデルを提供しています。 そうすることで、各社ごとに異なったUIを提供しつつ、共通のバックエンドで機能エンハンスを行えるようにしています。
マイクロサービスを導入した背景
トレタO/Xの開発が本格的に始動したのは約2年前です。 コロナ渦で飲食店が厳しい状況を強いられている中、トレタも大きな打撃を受けました。 そこで今まで予約台帳サービスをはじめとする飲食店の「予約」事業の会社から、「飲食店支援」の会社へ変わろうと新しい事業の模索が行われました。 いくつかの新規サービスが立ち上がり、その中で注力事業として置いたのがトレタO/Xです。
トレタO/XはプロトタイプでのPoC期間を経て、次はシステムをスケールさせるために製品版としてバックエンドのリニューアルを行いました。 その際にシステム構成を検討する上で主軸とした考えが、システムの再利用性です。
「強くてニューゲーム」ができる開発組織
トレタO/Xを予約事業の次の事業の柱にする意気込みでバックエンドの設計検討を行いましたが、 その先を見据えるとトレタが次は単に「オーダーアプリ」の会社になるのではなく、「飲食店支援」の会社として今後も次々と新規サービスを出していく会社になる必要があると考えました。
そこでトレタO/Xのシステムはその足がかりとなるように、トレタO/Xで作ったシステムの一部が他の新規サービスでも再利用できるような構成を理想の姿としました。 そうすることで、今後の新規サービスを立ち上げる際には毎回0からのスクラッチではなく、資産を流用することで開発期間が短縮された「強くてニューゲーム」が行える組織になると考えました。
そのため、「O/Xのバックエンド」ではなく「トレタの共通基盤システム」として、特定のコンテキストで区切られたシステムを組み合わせて構成するマイクロサービスを自然と選ぶことになりました。
トレタO/Xのシステム構成
トレタO/Xのシステムは大まかに以下のマイクロサービスで構成されています。
- 認証サービス
- Auth0をベースにし、各種サービスごとの権限やロールなどを管理するサービス
- 注文サービス
- トレタO/Xのメインとなる注文データやユーザーのセッション情報を扱うサービス
- 変更履歴が全て保存されるDatomicをDBとして、Clojureで書かれたGraphQLサーバー
- 決済サービス
- 決済や返金なでの決済処理や決済データを管理するサービス
- Stripeなどの決済プラットフォームをラップし抽象化する
- 印刷サービス
- 注文データやQRコードをキッチンプリンタへ印刷するサービス
- 印刷ジョブを管理し、ネットワークプリンタから定期的に送られてくる印刷ジョブチェックのリクエストを捌く
- APIサーバー
- クライアントアプリと各種マイクロサービスとの間をかけもつファサード層
- 外部公開用のAPIを提供する
ご覧の通り使用している言語がバラバラでも成立するのがマイクロサービスの一つの利点かと思います。 技術選定は在籍エンジニアの技術スタックであったり、システム要件としてデータベースにあわせた言語や連携先サービスのSDKの提供状況などを加味しています。
マイクロサービスにしてみて
「マイクロサービスは銀の弾丸ではない」とはよく言われるもので覚悟はしていましたが、やはりいろいろと地雷は踏みました。
分散トランザクションによる問題
- タイムアウトなどにで一部にだけデータが入りロールバックできず不整合
- リトライや冪等性、到達保証など考慮する点が多い
- トラッキングIDを入れないと調査に一苦労
- 結局は分散トランザクションが生じている時点でドメイン境界が正しく切れていない
インフラコストの問題
- それぞれのコンテナ実行環境構築と管理するためのインフラエンジニアが不足
- デプロイさせるシステムの順番を間違えると事故が起きる可能性もある
徐々にマイクロサービス化するという幻想
苦労する部分は多いですがやってみて良かったと思うことの一つに、最初からマイクロサービスを前提にしていたからこそ正しく正規化や抽象化されたデータ構造に近づけたという点です。
「初期の段階からマイクロサービスにするな」というのもよく言われる話です。 ただ、モノリスをつくってから徐々に切り出していく、というのもそう簡単ではありまえせん。 トレタでも予約台帳のサーバーは約8年越しの巨大なモノリスとなっており、部分的に切り崩そうとしてもデータが依存しあったりコードが絡みあっていたりで、話があがるたびには消えていました。 そもそもリプレイスや大規模リファクタリングは事業フェーズのタイミングとリソース(人、金)が揃わないとなかなか行うことができません。
今回のようにPoCでコンテキストの境界を検証したり仕様を概ね出し切っておき、プロトタイプを脱する時点でマイクロサービスを検討するのは良いタイミングだったかと思います。
さいごに
マイクロサービスにするとやはりエンジニアの頭数がどうしても必要になってきます。 トレタではエンジニアの採用を現在全方面オープンしています。 飲食店のDX化が急速に進んでいる昨今で、一緒に未来の飲食業界を作っていく仲間をお待ちしてます！
