新規プロダクトにマイクロサービスを選ぶ理由、注意しておきたいポイント：リクルートのプロダクト開発例に学ぶ、マイクロサービス活用の勘所（1）

リクルートの新規事業におけるマイクロサービスアーキテクチャの活用を全3回にわたって紹介する本連載。初回は、現場目線でどのようなメリットがあると考えマイクロサービスを採用し、どのような構成になっているのか紹介します。

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

　リクルートで「Airレジ オーダー セルフオーダー」（以下、セルフオーダー）の開発を担当している早川です。リクルートの新規事業であるセルフオーダーにおけるマイクロサービスアーキテクチャの取り組みを全3回にわたって紹介します。

　本連載ではセルフオーダーがマイクロサービスアーキテクチャを採用した背景、大規模システムにおける課題、事業のフェーズに並走するアーキテクチャの進化と見えてきた課題、今後の展望をお伝えできればと考えています。

「Airレジ オーダー セルフオーダー」とは

　私たちが開発しているセルフオーダーは、飲食店でお客さまがQRコードを読み込むことで自分のスマートフォンから料理を注文できるWebアプリケーションです。お客さまが店員さんを待つことなく好きなタイミングで注文できることや、飲食店における業務負荷の削減および客単価の向上を提供価値としています。飲食店でニーズが高まる感染症対策をいち早く支援するためリリースを前倒しし、2020年7月にサービスを提供開始しました。

　セルフオーダーチームでは2つのアプリケーションを開発しています。1つ目はお客さまがメニューを閲覧して注文できるスマートフォン向けのWebアプリケーションです。2つ目は飲食店の店舗スタッフがメニューを設定できるPC、タブレット向けのWebアプリケーションです。

セルフオーダーの関連プロダクト

　セルフオーダーの関連プロダクトとその責務も紹介します。セルフオーダーを利用するためには同じくリクルートのプロダクトである「Airレジ」「レストランボード」「Airレジ オーダー ハンディ」の利用がセットになります。AirレジはPOSレジアプリ、レストランボードは飲食店での予約台帳アプリ、Airレジ オーダー ハンディは飲食店向けオーダーシステムです。

　セルフオーダーから見たそれぞれのプロダクトの責務は、Airレジが商品管理、レストランボードが席管理、Airレジ オーダー ハンディが注文管理です。これらの3つのプロダクトがそろうことで「任意の商品を任意の席に注文する」ことが可能です。厳密には予約や伝票の概念もありますがここでは割愛します。

　セルフオーダーの責務はお客さまがする注文の管理です。これまで店舗スタッフ向けであった注文機能をお客さまに公開する必要があるためです。さらにセルフオーダーにはお客さまに公開するための商品データを管理する責務もあります。店舗スタッフには「HB」という略称でどの商品か分かっても、利用者には「ハイボール」と正確な商品名でないと伝わらないケースがあります。セルフオーダーでお客さま向けの商品名を設定する必要があります。

　Airレジ、レストランボード、Airレジ オーダーおよびセルフオーダーはそれぞれ別のチームが開発しており、プロダクト間は主にWebAPIを用いて連携させています。

　さらに最近ではセルフオーダーに「オンライン決済 by Airペイ」を用いた決済機能が実装されました。このオンライン決済 by Airペイの開発もまた別のチームが担当しています。このようにそれぞれ大きなプロダクトが複雑に連携していることが大きな特徴です。各プロダクトの責務とその連携を以下の図1に示します。

図1 セルフオーダーから見た各プロダクトの責務とその連携

大規模プロダクトの開発、運用における課題

　プロダクトが大規模化、複雑化すると影響範囲が大きくなります。調査、開発、テストのコストも非常に高くなるでしょう。Airレジから認証、顧客管理およびレストランボードを分離するという大規模プロジェクトに参画したり、大きなプロダクトを開発したりした経験から、以下のような課題があると考えています。

• 1回のデプロイの影響が大きいため、システム障害リスクが高くなる。結果としてリリースの頻度が少なくなり、1回のリリースの規模も大きくなる。さらなるリスクを招く。また、リリース頻度が少ないことは事業面での競合優位性の低下となり得る
• 1つの機能がボトルネックとなってシステム全体に影響を及ぼし、その他の機能のシステム障害につながる場合がある
• フレームワークやライブラリなどの新しい技術を導入したいと思っても影響範囲が大きいため試しづらく、技術の陳腐化が発生する。技術の陳腐化は開発生産性や品質、エンジニアのモチベーションの低下を招く可能性がある

　セルフオーダーの開発に当たってマイクロサービスアーキテクチャに注目したのは、先行する大規模プロダクトにおける上記のような課題を解決できるのではないかという考えがあったためです。

マイクロサービスアーキテクチャとは？　マイクロサービスの定義

　マイクロサービスは、複数の小さなアプリケーションを組み合わせることで1つのプロダクトとして機能させるシステムアーキテクチャです。プロダクトを構成する小さなアプリケーションのことを「サービス」と呼びます。サービス間の連携はそれぞれのサービスが公開するAPI経由で行います。このことからマイクロサービスは分散システムへの取り組みであるともいえます。サービスの粒度に関してはさまざまな考え方がありますが、主にはビジネスドメインに基づいたサービス分割が好ましいと考えています。