「強い意志」も大切――マイクロサービスの実運用で感じた5つの課題：リクルートのプロダクト開発例に学ぶ、マイクロサービス活用の勘所（終）

リクルートの新規事業におけるマイクロサービスアーキテクチャの活用を全3回にわたって紹介する本連載。最終回は、実運用を通じて見えてきた5つの課題と対策に向けた取り組みを紹介します。

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

はじめに

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

　全3回にわたってリクルートの新規事業である、セルフオーダーにおけるマイクロサービスアーキテクチャの取り組みを紹介する本連載第3回は、マイクロサービスの実運用で感じた課題、工夫した点と今後の展望を紹介します。

現在のアーキテクチャとそこに至るまでに感じた課題

　第2回で、セルフオーダーのアーキテクチャが簡易構成から始まり、モノリスを経て図1のようなマイクロサービスへ進化してきた過程を紹介しました。

図1: 2022年6月現在のアーキテクチャ

　マイクロサービス化して運用する中で感じた5つの課題をそれぞれ紹介します。

• サービス間の依存関係が複雑になる恐れがある
• モニタリングの項目が多くなる傾向がある
• 開発環境の各サービスにどのアプリバージョンがデプロイされているか分かりにくい
• インフラがどんな構成になっているか分かりにくい
• 複数のサービスに依存するトランザクションの整合性を保つことが難しい

サービス間の依存関係が複雑になる恐れがある

　依存関係の複雑さに初めて直面したのは、商品の画像を登録する機能を開発するタイミングでした。メニュー取得のサービスではひも付けられた商品と画像IDのデータを保持していますが、画像のURLなどを含む画像情報は別の画像サービスが保持していました。そのため、メニュー取得サービスから画像サービスに画像情報を取得する処理が必要になりました。サービス間で通信し、依存関係を持つことは、サービス同士をなるべく疎結合にしておきたいという方針に反して、大きな課題となったのです。

　この課題に対してはカスタマー側のGatewayにAggregatorの役割を持たせることで回避しました。カスタマー側のGatewayでメニュー情報と画像情報を取得してひも付けてからフロントエンドに返却することでメニュー取得サービスと画像サービスが通信することを回避しています。図2にAggregator導入前後のアーキテクチャの比較を示しています。

図2: Aggregator導入前後のアーキテクチャの比較

　しかし、GatewayにAggregatorの責務を持たせることも課題を感じています。すでにGatewayの責務に加えて認証の責務も持っているため、責務が肥大化しているように感じるからです。現在はAggregatorとしての役割はまだ小さく、別のサービスとして切り出すコストの方が大きいと判断したためGatewayに集約していますが、今後GatewayにBFF（Backends For Frontends）のような役割をさらに追加することになった場合、BFFの責務を別のサービスとして切り出す余地はあると考えています。

モニタリングの項目が多くなる傾向がある

　モニタリングの項目が多い課題はサービスの数が増えてきたときに実感しました。マイクロサービスではサービスごとにCPU使用率やメモリ使用量などのメトリクスや、アプリケーションのログなどをモニタリングする必要があります。サービスの数が増えたことで全てのサービスのメトリクスやログをモニタリングすることに大きな課題を感じました。モニタリング項目が抜け漏れたり、メトリクスやログを一つ一つ理解するのが難しかったりする状況です。

　そこで、モニタリング項目をなるべく絞り、かつモニタリングをする場所を集約するというアプローチを採ることにしました。メトリクスに関してはスループットを計測するための秒間リクエスト数、リクエストのエラー率、リクエストのレイテンシの3項目を最重要項目としてモニタリングしています。基本的にはこれらの3項目でシステムの異常や劣化に気付くことができています。もちろん、サービスごとのCPU使用率やメモリ使用量などの詳細なメトリクスに関してもダッシュボードを作成しており、いつでも見ることができるようにしています。最重要項目で異常があった際は、さらに調査してどのサービスに異常があるのかを調べるためです。しかし基本的には最重要項目のモニタリングで十分だと感じており、実際に多くのメンバーが各項目の意味を理解し、無理のないモニタリングが可能になってきました。

　さらに、メトリクスやログはDatadogを利用して集約、可視化しています。これによりモニタリング項目の抜け漏れを起こりにくくし、複数のサービス間に及ぶ調査などを容易にしていると考えています。

開発環境の各サービスにどのアプリバージョンがデプロイされているか分かりにくい

　サービスの数が増えると、各サービスにどのバージョンのアプリケーションがデプロイされているか把握することも難しくなります。セルフオーダーでは複数の開発環境を用意し、アプリケーションエンジニアが自由にデプロイして開発中の機能の動作確認をしています。そのため開発環境とサービスの数だけデプロイの状態が増えてしまい、把握が困難となります。実際にどのサービスがどんな状態になっているか分かりにくいため、デプロイのたびに担当者同士で確認するコミュニケーションが発生するなどの課題がありました。

　そのため図3のように、Hubotで構築したSlack上のbotが特定の環境の各サービスにデプロイされているDockerイメージを一覧で表示してくれるツールを作成しました。特定のサービスへイメージを反映するのもチャットbot経由で行えるようにしました。これによりエンジニアがスムーズに開発環境へデプロイして動作確認できるようになっています。

図3: Slack上のbotが各サービスにデプロイされているDockerイメージを表示している様子（セキュリティ上サービス名は伏せ、サービスの数も省略しています）

インフラがどのような構成になっているか分かりにくい

　サービスが増えてくるとインフラの観点でもサービスの全体像が分かりにくかったり、サービス間の依存関係やサービスとインフラリソースとの依存関係を把握したりすることが難しくなりました。この課題に対しては大きく分けて2つの対策をしています。

　1つ目はInfrastructure as Code（IaC）の取り組みです。コンテナのオーケストレーションにKubernetesを用いているため、全てのサービスの構成管理はYAML形式のマニフェストで表現されます。その他のインフラ構成もTerraformを用いて構成管理をしています。マニフェストやテンプレートファイルを追うことで各サービスのインフラの状態や依存関係を把握しやすくできました。

　2つ目は図1でも紹介したようなアーキテクチャの図を継続的にメンテナンスし続ける取り組みです。これにインフラリソースや他プロダクトとの依存関係などを加えた詳細な図をメンテナンスし続けています。図やドキュメントを継続的にメンテナンスし続けることは課題になりがちです。コードから読み取ることが難しい情報は、強い意志を持って図やドキュメントでメンテナンスし続けています。サービスの全体像を俯瞰（ふかん）できる図がないと、新しいサービスを追加する際のアーキテクチャ設計で困ったり、好ましくない依存関係を追加したりしてしまいそうになった経験から、この取り組みが重要だと感じています。

複数のサービスに依存するトランザクションの整合性を保つことが難しい

　この課題も画像機能を実装する際に直面したものでした。画像を扱うサービスを、すでに存在していたメニュー設定のサービスとは別に画像サービスとして構築することにしました。ただし画像のIDだけはメニュー設定サービス内の商品データにひも付けておく必要があります。そのため、画像を商品に登録する際は、以下の2つの処理を行う必要があります。図4にシーケンス図としても示します。

1.画像サービスへの画像の登録する

2.1で発行された画像IDをメニュー設定サービスで商品へひも付ける

図4: 画像を商品に登録する際のシーケンス図

　この2つの処理は同一トランザクションで行うことが好ましい処理です。なぜなら2のひも付けが失敗した場合、1の処理をロールバックしなければ不要な画像データが残ってしまうためです。これは1つのアプリケーション内の実装であればDB（データベース）のトランザクション機能を用いることで容易に実現できます。しかしマイクロサービスでは2つの処理がどちらともWebAPIで行われるため、2の処理が失敗した時にはすでに1の処理が完了しており、ロールバックすることが困難です。

　この課題へのアプローチとしては結果整合性を保つ方法があります。具体的な手段としてはTCCパターンやSagaパターンと呼ばれるものがあります。これらの紹介は割愛しますが、複雑な実装が必要になります。今回のケースでは不要な画像データは必ずしも即座に削除する必要がないと判断できたため、複雑な実装を避けるためにも不要な画像データを残すことを許容した上で定期的なパージを行うことを検討中です。

今後の展望

　第3回ではマイクロサービスの課題を紹介しましたが、これらをしっかり対策することで、第1回で紹介したマイクロサービスのメリットがデメリットを上回っている状態だと考えています。

　今後もセルフオーダーではさらなる機能追加などによりプロダクトの改善や拡張をしていく予定です。さらに第1回でも紹介した通り、マイクロサービスにしたことによりサービスの統合、分離の検討が容易になり、アーキテクチャを変えた恩恵が実感できています。

　今後の改善や拡張によっては別の新しいサービスを構築したり、プロダクトが持つ責務を見直したりして、サービスを分離、統合する可能性あると考えています。マイクロサービスの恩恵をさらに強く享受できるよう、引き続き磨き込みを進めていく予定です。

最後に

　全3回にわたり「Airレジ オーダー セルフオーダー」でのマイクロサービスアーキテクチャの取り組みを紹介しました。今回紹介したような課題もある中で強い意志を持ってマイクロサービスにチャレンジしている根底には、エンジニアリングで最大限事業を進化させたいという思いがあります。そうすることでセルフオーダーを使っていただくユーザーの皆さまや飲食店の皆さまに少しでも良い飲食体験をしていただけると信じているためです。

　今後もプロダクトを成長させながら、実現したいことに柔軟に対応できるアーキテクチャに進化させることで、開発スピードや品質などの観点で事業の進化を加速させることができると考えています。より良い飲食体験の実現に向けて、マイクロサービスのメリットを生かしながら高いアジリティを持って貢献していきます。

筆者紹介

早川浩平

リクルート プロダクト統括本部 飲食プロダクト開発G

2016年、リクルートに新卒で入社。海外向け新規サービスのiOSアプリ開発を担当。その後、Airレジ オーダーのサーバサイドとフロントエンドの開発を経て、2019年からAirレジ オーダー セルフオーダーの開発の立ち上げと推進に従事。