「Google スプレッドシート＋手作業」からマイクロサービスに進化――新規事業におけるアーキテクト選定の考え方：リクルートのプロダクト開発例に学ぶ、マイクロサービス活用の勘所（2）

リクルートの新規事業におけるマイクロサービスアーキテクチャの活用を全3回にわたって紹介する本連載。第2回は、簡易構成からモノリス、マイクロサービスへとアーキテクチャを進化させていった過程を紹介します。

» 2022年06月07日 05時00分公開

[早川浩平，リクルート]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　リクルートで「Airレジオーダーセルフオーダー」（以後、セルフオーダー）の開発を担当している早川です。セルフオーダーは飲食店でお客さまがQRコードを読み込むことでスマートフォンから料理を注文できるWebアプリケーションです。

　全3回にわたってリクルートの新規事業である、セルフオーダーにおけるマイクロサービスアーキテクチャの取り組みを紹介する本連載第2回は、新規事業の進展に応じてサーバレスと人手を組み合わせた簡易構成からモノリス、マイクロサービスへとアーキテクチャを進化させていった過程を紹介します。

ビジネスの進展とともに変化するシステム要件

　連載第1回で「Airレジ」などの先行する大規模プロダクトにおける課題を解決するための手段として、新規事業であるセルフオーダーにマイクロサービスを適用した背景を紹介しました。

　しかし、開発当初からマイクロサービスで構築していたわけではありません。新規事業のリリースまでのフェーズをプロトタイプ、MVP（Minimum Viable Product、実用最小限の製品）、製品版の3つとした際に、各フェーズでアーキテクチャを変化させてきました。

　各フェーズにおけるビジネス側での取り組みは、セルフオーダーのプロダクトマネジャーの川崎が「プロダクトマネージャーカンファレンス2020」で発表した「業務と消費者の体験を同時にデザインするリクルートの価値検証のリアル ― 「Airレジハンディ」セルフオーダーのブレない「価値」の確かめ方 ―」の内容をご覧ください。

　簡単にプロトタイプ、MVP、製品版それぞれのフェーズの特徴を紹介します。

　まずプロトタイプではセルフオーダーの最もコアな価値となる「お客さまのスマホでQRコードを読み込み、注文する」ことが受け入れられるのかを確かめることが目的でした。検証は1店舗ずつ夜の営業時間のみ実施する内容で、スピード感を持って価値検証することが最優先でした。

　次にMVPでは店舗でセルフオーダーを運用し続けられるかどうかを検証しました。検証は数店舗で数カ月間、最小限の機能で実運用するというものでした。スピードと品質のバランスを取ることが重要でした。

　そして製品版は、製品としてサービス提供することが目的です。システムの安定性に加え、今後の機能追加に対応できる拡張性も重要となりました。それぞれの特徴をまとめたものが表1です。


フェーズ	目的	運用方法	システムに求められること
プロトタイプ	コアバリューの検証	1店舗ずつ夜の営業時間のみ	スピード感を持った価値検証の実施
MVP	実運用の検証	数店舗が数カ月間	スピードと品質のバランス
製品版	製品としてサービス提供	常時安定稼働	安定性と拡張性
表1 各フェーズの特徴

プロトタイプフェーズにおけるアーキテクチャ

　プロトタイプのフェーズではサーバレスと人手を組み合わせた簡易構成で運用しました。

　フロントエンドからリクエストされた注文が「Google スプレッドシート」に入力され、セルフオーダーのチームメンバーが注文内容を目視で確認し、人手により「Airレジオーダー」から注文するという構成です。以下の図1のような構成です。

図1 プロトタイプのアーキテクチャ

　このような構成にした理由は以下の通りです。

「Airレジオーダー」は検証店舗に導入済みであり、店舗スタッフが「Airレジオーダー」から注文を取る業務は確立されていました。そのためセルフオーダーのチームメンバーが店舗スタッフの代わりに注文を取ることはセルフオーダーのコアバリューを試すのには十分であり、店舗業務での検証も容易でした
プロトタイプはあくまで検証用であり、本開発が行われるとしても使い回さない前提がありました。プロトタイプは捨ててしまうことが決まっており、コストをかけるよりはスピード重視で開発したかったため、バックエンドアプリケーションの開発はしないという選択をしました
プロトタイプによるビジネス検証は社内食堂や協力してくださる数店舗で短期検証でした。1日に1店舗ずつ夜の営業時間のみシステムを利用する検証だったため、チームメンバーが4人程度いれば人力でも十分業務を回せると判断しました

MVPフェーズにおけるアーキテクチャ

　MVPでのアーキテクチャはモノリス（厳密にはモジュラモノリス）です。フロントエンドはカスタマー（お客さま）向けとクライアント（店舗）向けの2つのアプリケーションを構築しており、それぞれに対応する形でバックエンドを構築しています。カスタマー側のバックエンドの責務はメニュー取得、注文と認証です。クライアント側のバックエンドの責務はメニュー設定と認証です。バックエンドのリポジトリは1つですがその中でモジュールを分割する形で実現していました。ビルドツールには「Gradle」を用いていたので、1つのプロジェクト配下に2つのサブプロジェクトを持つ構成にしていました。2つのモジュールは同じデータベース（DB）を参照しています。

図2 MVPのアーキテクチャ

　プロトタイプからの差分は2つあります。1つ目はクライアント向けのアプリケーションが増えた点です。2つ目はバックエンドを人力ではなくアプリケーションとして構築した点です。このような構成にした理由は以下の通りです。

MVPは昼夜含めた数カ月に及ぶ実運用の検証が目的でした。そのため、店舗スタッフが自分でメニューを設定するためのクライアント側のアプリケーションを構築し、注文業務も人力ではなくシステムで自動化しています
製品化のめどが立っていたこともあり、検証が終わった後もMVPのシステムを改修することで製品版にアップデートさせる計画でした。多少コストがかかったとしても後から直すことが難しい部分は作り込むと判断し、カスタマー側のサービスとクライアントサイドのモジュールを分割しました。製品版ではマイクロサービスアーキテクチャを採用してサービスを分割していきたい、実際にマイクロサービスアーキテクチャの効果を検証したいという観点でも、2つのモジュールを運用して知見を得たいと考えました

　MVPは最小限の機能で検証するアプリケーションとなるため、機能をサービスとして分割せずに、モジュラモノリスを採用しました。とはいえ、製品版でマイクロサービス化するための準備もしていました。2つのモジュールを運用するためにマイクロサービスで欠かせないインフラを整えたり学習したりするというコストを払いながら、着実にチームのマイクロサービスに対する技術力が高くなっていった時期だったと考えています。スピードと品質のバランスを取りつつ、製品版に向けて準備するという点で非常に難しいフェーズでした。しかし振り返ってみると、この期間にしっかりと準備ができたため、製品版でのマイクロサービス移行はスムーズでした。

製品版におけるアーキテクチャ

　製品版は、MVPを拡張する形でマイクロサービスの形（図3）になってきています。

図3 製品版（2022年4月現在）のアーキテクチャ

　図2のMVPのアーキテクチャに対して最初に加えたのは図3の画像にあるバックエンドのサービスとクライアントサイドの認証とGatewayのサービスです。クライアントサイドの認証とGatewayのサービスが持つ認証の責務は、MVPにおけるメニュー設定と認証のバックエンドが持つ認証の責務を移管した形になります。

　認証サービスを別のサービスとして切り出す検討もしましたが、管理するサービスの増加に伴うコストのリスクを踏まえ見送りました。これら2つを新たに加えた理由は、店舗スタッフが商品の画像をアップロードし、お客さまがその画像を閲覧できる機能を実現するためでした。画像リソースはカスタマーサイドとクライアントサイドの両方に必要なリソースのため、第3のサービスとして切り出しました。

　クライアントのフロントエンドから画像サービスにアクセスするためには認証が必要となるため、クライアントサイドの認証とGatewayのサービスを新しく構築しました。直近だと決済のサービスが加わり、図3の構成となりました。

　MVPの名残からメニュー取得と注文のサービスとメニュー設定のサービスは同じDBを参照していますが、決済と画像のサービスはそれぞれ別のDBを参照しています。また、クライアントサイドの認証のサービスとカスタマーサイドの認証もそれぞれ別のRedisのDBを参照しています。

　製品版になっても新しい機能が頻繁に追加される中で、既存サービスへの影響を少なく開発できるアーキテクチャになってきました。複数の機能を並行開発することも多くなってきているため、拡張性の高いマイクロサービスアーキテクチャのメリットを大きく享受できていると考えています。

　例として挙げたいのが、決済機能の追加です。工期も長く、難易度の高いプロジェクトでしたが、新しいサービスとして開発することで、既存サービスに対する他の機能追加には全く影響を及ぼすことなく開発を完遂できています。

おわりに

　新規事業の進展に応じてサーバレス、モノリス、マイクロサービスとアーキテクチャを進化させていった過程を紹介しました。各フェーズで一貫して大切にしていたのは、事業の特性やフェーズに最適な技術を採用したいという思いです。エンジニアとしてアプリケーションの開発スピードや品質などの観点から、最大限事業を成長させたいと思っています。今後もアーキテクチャは進化させていく計画です。

　今回はマイクロサービスの長所に焦点を当てた内容でしたが、運用を進める中で直面した課題、工夫した点もあります。次回はマイクロサービスの実運用で感じた長所、短所と今後の展望を紹介します。