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

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

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

はじめに

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

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

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

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

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

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

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

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

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