リクルートの新規事業におけるマイクロサービスアーキテクチャの活用を全3回にわたって紹介する本連載。初回は、現場目線でどのようなメリットがあると考えマイクロサービスを採用し、どのような構成になっているのか紹介します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
リクルートで「Airレジ オーダー セルフオーダー」(以下、セルフオーダー)の開発を担当している早川です。リクルートの新規事業であるセルフオーダーにおけるマイクロサービスアーキテクチャの取り組みを全3回にわたって紹介します。
本連載ではセルフオーダーがマイクロサービスアーキテクチャを採用した背景、大規模システムにおける課題、事業のフェーズに並走するアーキテクチャの進化と見えてきた課題、今後の展望をお伝えできればと考えています。
私たちが開発しているセルフオーダーは、飲食店でお客さまが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に示します。
プロダクトが大規模化、複雑化すると影響範囲が大きくなります。調査、開発、テストのコストも非常に高くなるでしょう。Airレジから認証、顧客管理およびレストランボードを分離するという大規模プロジェクトに参画したり、大きなプロダクトを開発したりした経験から、以下のような課題があると考えています。
セルフオーダーの開発に当たってマイクロサービスアーキテクチャに注目したのは、先行する大規模プロダクトにおける上記のような課題を解決できるのではないかという考えがあったためです。
マイクロサービスは、複数の小さなアプリケーションを組み合わせることで1つのプロダクトとして機能させるシステムアーキテクチャです。プロダクトを構成する小さなアプリケーションのことを「サービス」と呼びます。サービス間の連携はそれぞれのサービスが公開するAPI経由で行います。このことからマイクロサービスは分散システムへの取り組みであるともいえます。サービスの粒度に関してはさまざまな考え方がありますが、主にはビジネスドメインに基づいたサービス分割が好ましいと考えています。
マイクロサービスと比較する形で語られるアーキテクチャがモノリスです。モノリスは1つの大きなアプリケーションにより1つのプロダクトとして機能させるシステムアーキテクチャです。モノリスそしてマイクロサービスにもそれぞれ長所と短所があるため、理解した上で事業、組織およびシステムの特性やフェーズで使い分けることが重要だと考えています。
一般的にマイクロサービスの利点とされている特徴を、個人的な意見も交えて紹介します。
障害点を分離しやすい構造にできる
プロダクトの特定機能の不具合によりメモリリークしたケースを考えます。単一のインスタンスやコンテナで運用されている場合、プロダクトの全停止につながる恐れがあります。複数のコンテナで運用されているマイクロサービスの場合、原因となったサービスは停止しますがその他のサービスは停止せず、残りの機能でプロダクトの提供を継続できます。
しかし、サービス間の依存関係次第で前述した動作が期待できなくなるため、サービス同士はなるべく疎結合にすることが好ましいです。
リリースの粒度を細かくする取り組みを実施しやすい
それぞれのサービス同士が疎結合なら、サービスごとのリリースが可能になります。つまり、1回のリリースの粒度を細かくでき、その結果リリースの頻度を高めることもできます。リリースの粒度が細かいことはシステム障害のリスクを低減できますし、仮に障害が発生した場合も切り戻しが容易です。リリースの頻度が高いことはビジネス上での競合優位性につながると考えることもできます。
サービスごとに異なる技術を利用できる
サービスの特性に応じた技術を採用することでシステム全体のパフォーマンスを上げたり、新しい技術を試したりすることが容易になります。もちろん複数の技術を採用することはデメリットにもなります。同じチームで複数のアプリケーションを開発、運用している場合は学習コストやスイッチングコストなどのオーバーヘッドが発生するためです。
チームの生産性を高めやすくなる
マイクロサービスはサービスごとにチームの分割が可能になるため、小さいチームの高い生産性というメリットを享受しやすい構造です。1つの大きなプロダクトを1つの大きなチームが運用することは非常に難易度が高い印象です。仕様が複雑かつ膨大となり全体を把握することが困難で、コミュニケーションや管理のコストも大きくなってきます。
一方、チーム分割のデメリットとして組織のサイロ化が挙げられます。近年急速に導入が進んだリモートワークも相まって、チーム間の連携不足による品質低下を避けるために対策をしなければいけません。
スケール時にインフラを最適化しやすい
マイクロサービスは、ボトルネックのあるサービスのみをスケールさせることができるためインフラコストやリソース効率を最適化しやすい構造です。近年ではオートスケールの手法も一般的になってきましたが、オートスケール時も小さなサービスは起動速度が速いですし、必要なインフラリソースも少なくて済む点がメリットとなります。
ただしサービスごとにキャパシティープランニングをする必要があるため、大きな労力を必要とする点はデメリットだと考えています。
前提条件を補足すると、今回紹介するマイクロサービスのスコープは、冒頭に紹介した関連プロダクト含めた全体ではなく、セルフオーダーに閉じた範囲となります。
セルフオーダーがマイクロサービスを採用した大きな目的は、将来的にセルフオーダーの責務を分離しやすくするためです。セルフオーダーの責務はお客さまによる注文の管理とお客さま向け商品データ管理の2つですが、後者に関してはセルフオーダー立ち上げ時にさまざまな選択肢がありました。「商品のデータだからAirレジに持たせるべき」「Airレジの商品管理の責務を分離して店舗向けかつお客さま向けの商品データ管理基盤を立ち上げるべき」などの意見も上がりました。
しかし大規模プロダクトであるAirレジに手を加えることは、セルフオーダーの成長スピードを鈍化させるリスクがありました。当時のセルフオーダーの将来性が不確実という懸念もあり、なるべくセルフオーダーで完結させることを目的として現在の責務分割となりました。
とはいえ課題もあります。システム負荷とパフォーマンスの観点でAirレジの商品データをセルフオーダーにキャッシュする必要があるため、データのライフサイクルが複雑になります。また店舗スタッフがAirレジとセルフオーダーの双方で商品データを編集しなければならないという課題も発生します。次の新規事業でお客さま向けの商品データを参照したくなった場合(例えばフードデリバリーもセルフオーダーに似た構成だと考えています)はより複雑な依存関係となってしまいます。
以上のような課題から、将来的にはお客さま向け商品データの管理の責務はセルフオーダーから分離することが好ましいと考えています。そのため初めから責務を分離しやすいアーキテクチャにとどめておくため、マイクロサービスを採用しました。
責務の分離のしやすさに加えて、先に挙げた大規模プロダクトの課題への対策もマイクロサービスを採用した理由です。システム障害リスクの増大とリリース頻度の低下に対しては、障害点を分離できる構造とリリースの粒度を細かくするアプローチが有効です。サービスごとに異なる技術を用いることができるため、技術の陳腐化に対する打ち手にもなりました。
以上の理由でセルフオーダーにマイクロサービスを採用し、現在では図2のような構成になっています。
しかし、開発当初からマイクロサービスにしていたわけではありません。新規事業の進展に応じてサーバレス、モノリス、マイクロサービスとアーキテクチャを進化させていきました。次回は、アーキテクチャ変遷の過程を紹介していきます。
Copyright © ITmedia, Inc. All Rights Reserved.