リテール導入で発生した問題、改善するためにシステムの強化へ
今回登壇したのは、出前館のプロダクト本部 マーチャント部 マーチャント連携開発グループに所属する三木一馬氏。出前館と加盟店間のAPI連携機能の開発や運用、AWSのインフラ構築などを担当している。
出前館のサイトやアプリにおけるリテール対応と聞くと、ユーザー向けのtoC部分がイメージされるが、実は加盟店ドメインなどBtoBの領域も多い。実際に出前館で注文した後、ユーザーに配達するまでの流れを表したのが、以下の図である。そこには大きく分けて3つのドメインが存在する。
主にユーザーとのやり取りを行う出前館の「サイト・アプリ」、飲食店などの加盟店とのやり取りを行う「加盟店」、商品を届ける配達員とのやり取りを行う「デリバリー」ドメインである。
現在、出前館ではフード加盟店に加えて、リテール加盟店の導入も進んでいる。リテール加盟店とは、食料品や日用品を扱うコンビニエンスストアやスーパーマーケット、医薬品を扱うドラッグストアなどである。三木氏いわく、「従来のフード加盟店とは異なる部分が多く、さまざまな課題が発生していた」という。
当初のリテール店舗における運用フローは、出前館ユーザーが商品を注文すると、出前館で注文の受付処理が行われ、その後小売り店舗にあるタブレットアプリに注文情報が連携される。店舗のスタッフがその商品をピックし、配達員が店舗でピックされた商品を受け取り、ユーザーのもとへ届ける流れであった。
商品の欠品があった場合は、店舗スタッフが出前館のタブレットアプリに該当商品の品切れを設定する。出前館サイト上では品切れ表示となり、その商品を含む注文はできなくなる。
だが、リテール店舗では取り扱う商品数も多く、品切れや解除の設定を一つひとつ手動で行うのは店舗スタッフの業務負荷が高くなる。さらには、品切れ対応の遅れや漏れは、カスタマーセンターの対応コストやUXにも悪い影響を及ぼす。
そこで三木氏ら開発チームは、加盟店側にある在庫データをもとに出前館の品切れを設定できるAPIを作成し、システム化を行った。品切れ設定や参照用のAPIを新たに開発し、加盟店側の在庫データをもとに、定期的に品切れ設定APIを呼び出す仕組みである。システム化によって品切れ設定業務が自動化され、業務負荷を軽減することができた。
だが、品切れの設定を反映する在庫連携バッチは数分間に1回起動する仕様だったため、その間にユーザーが注文することができてしまい、注文後に実は欠品だったという事象も発生してしまう。そのため、在庫が少なくなってきた段階で、出前館上で品切れ設定にする必要があった。そこで、店舗で在庫をゼロまで売り切ることができないという課題が出てきたのである。
この課題に対しては、注文時に在庫の存在をAPIで問い合わせる機能を追加することで、欠品商品の注文を防ぎ、加盟店としては在庫が最後まで確実に売り切れるように対策した。
まず、決済画面遷移時に店舗側システムに対して、APIでリクエストを行い、販売可否APIが加盟店側の在庫が存在していることを担保する。注文確定時に店舗がシステムに対して再度APIリクエストを行い、在庫引当APIで加盟店側の在庫数を担保した上で、在庫販売した分だけマイナスさせる仕組みだ。
さらに、ユーザーが参照するUI上の品切れ設定の反映ラグと決済エラーを繰り返す状況にも改善を加え、ユーザーの決済時販売可否APIのレスポンスが在庫なしの場合、その商品を即座に品切れの状態にするような処理を追加した。このようにさまざまな課題を解消して、最終的に完成した処理の流れが以下の図である。
モダン技術を活用したリアルタイム在庫連携システムのアーキテクチャとは
完成したシステムのアーキテクチャも紹介された。環境はAWS上に作成し、出前館でのナレッジがあるFargateを採用。その中でSpring BootでAPIを起動させている。
「今回作成した販売可否、在庫引当APIについては、出前館のサイトやアプリ側のシステムからリクエストを受け取るため、内部用のAPI環境であるInternal APIで動作させており、リクエストの受け取りと加盟店側のAPIを呼び出します」（三木氏）
品切れAPIについては、加盟店から直接リクエストを受け取るため、パブリックなAPIとして新たに構築。以下の図の赤枠部分である。
「新たに構築した理由としては、今後品切れのようなマスターを汎用的に操作できるAPIを構築していく計画があること。そして、既存のAPIと新たに作るAPIとの可用性を考慮し、既存のAPIと同じ環境とならない設計としました」（三木氏）
CI/CDにはGithub Actions、APIではBlue/Green Deploymentも採用している。
「日々の運用や調査ではNew Relicを活用しており、障害時の解析およびサービスレベルの監視などに役立てています。何か障害があった際のアラートに関しては、Slackも利用しています」（三木氏）
完成したシステムを稼働して改善された3つのポイント
三木氏は今回の取り組みを通して、良かったことがいろいろあったと振り返る。まず1点目として、店舗の課題を全て解決できた点を語っている。
「品切れ設定における業務負荷については品切れ設定を自動化し、店舗の業務負荷を減らすことができました。在庫を最後まで販売したいという課題に対しては、在庫を確実にゼロまで販売できた。出前館ユーザーのUXの改善および、出前館のカスタマーセンターでの欠品対応コストも減らせたと考えています」（三木氏）
定量的な効果としては、従来1店舗で1日あたり100分程度かかっていた品切れ業務負荷がゼロになったことが挙げられた。
良かったことの2点目は、エンジニアの悩みごとを解決できた点だ。旧来のシステムではJavaのバージョンが古く、TLSバージョン1.2が非対応という問題があった。今回は古いシステムに改修を加えるのではなく、新しく構築したシステムで開発を進めたことで、この問題が解決したのだ。
その他にもエンジニア視点でモダンな技術を取り入れることができたことや、現在のシステムの状況が不明確だった課題にも向き合うことができた点が挙げられた。正確なモニタリングがないことで、加盟店やカスタマーセンターなどの業務側からの問い合わせベースで課題に気づくこともあったが、現在はモニタリングの強化を進めている。
「Amazon CloudWatchを用いたメトリクスの監視やログのアラート、New Relicによるサービスレベルの測定など、モニタリングの強化を進めています」（三木氏）
そして3点目が、ビジネスの将来性を考慮できた点だ。今回の仕組みで、新たな加盟店とアプリケーションの改修を加えることなく連携が行えるようになり、ビジネスの成長性に対応できるようになったことが大きな利点となった。
「リテールなどの店舗ではどの店舗でも同じような課題を抱えていると考え、出前館として、特定の加盟店に依存しないような設計にしました」（三木氏）
また、将来的にさまざまな加盟店のリクエストに耐えられるようにAPIの性能も意識し、ボトルネックとなっていたSQLのチューニングを実施している。
「結果としてAPIが遅延なくレスポンスを返せる限界値が、秒間70リクエストだったのが、秒間150リクエストまで上がり、パフォーマンスへの考慮ができました」（三木氏）
三木氏は最後に、現在エンジニアを積極採用中である事にも触れ、以下のようにメッセージを送り、セッションをまとめた。
「出前館では、多様性のあるエンジニアが日々切磋琢磨しています。エンジニアが主体となってさまざまな課題に挑戦できたり、積極的にモダンな技術を活用したり、技術面においてもチャレンジできる環境です。その取り組みはエンジニアブログでも紹介しているので、興味のある方はぜひご覧ください」（三木氏）
