【技術特集】選ばれた技術、その理由と裏側～①～USEN-ALMEX ITエンジニアキャリア採用サイト

藤森

このチームでは、飲食店で導入されている出前サービスと業務システムをつないでいるバックエンドの開発に取り組んでいて、本日はその技術選定(APIとGoogle Cloud)についての打ち合わせが行われるとお聞きしています。技術選定の作業には正解がなく、多くのエンジニアが悩む部分かと思いますが、バックエンドグループではチーム内でどのように決定していくのでしょうか。打ち合わせ後にこちらからいくつか質問もできればと思いますので、本日はよろしくお願いします。

佐藤さん

はい、まずは画面共有して、今回の注文一元管理サービスのプロジェクトの背景や要件の説明をしますね。今回、飲食店Aで取り扱いのある業務システム製品に対して、既存のデリバリーサービスを利用している店舗が一部あります。その店舗は各デリバリーサービスと契約していて、そこから入ってきた注文情報が業務システムに流れて、売上の管理がされています。また注文伝票は、今は手書きしている現状があり、それを今回、複数のデリバリーサービスに対応するために、注文一元管理サービスと業務システム間を自動で連携するためのバックエンドサービスの開発を行い、注文が入ったら自動的に注文伝票出力まで行うというのが今回のプロジェクトの背景です。
ここまでで質問ありますか？大丈夫でしょうか？

興野さん

大丈夫です。

佐藤さん

こちらに企画部からの要件書がありまして、今回この注文一元管理サービスって、デリバリーサービスから注文が入るとWebhookと呼ばれるものが飛んできて、それをトリガーにしてバックエンドから注文一元管理サービスに注文情報の詳細を取得しにいって、注文情報が連携される、といった仕組みになっています。
要件概要は(スライドを見せながら)こんな感じで、主に関係してくるところは、件数的なところですね。今デリバリーサービスを導入している店舗で1店舗当たり1ヶ月の注文数が約2000件、導入される想定の店舗が最大160店舗なので合計1ヶ月あたりの注文は32万件発生します。今回の要件だと、月32万件で、注文情報のデータを3ヶ月くらい保持しておきたいということで×3で96万件マックスデータ量として保持する必要があります。これがデータ数のお話になります。注文一元管理サービスから取得した注文情報を今回業務システムに自動的に連携するか、業務システムから取りに来てもらうかっていうところはこの後議論していきたいところなんですけど、業務システムから取りに来てもらうというところであれば、取りに来てもらう間隔とかは別途計算して方向性を考える必要があります。というところがざっとした要件になりますが、ここまでで質問ありますか？

興野さん

大丈夫です。

佐藤さん

続いてはAPIの話に行きたいと思います。今回注文一元管理サービスから取得した注文情報を、業務システムに自動的に連携するか、業務システムから取りに来てもらうか、といったところがあるのですが、Push型で我々が業務システムへデータを送信するのがいいか、Pull型で業務システム側からデータを取得してもらうか、どちらが適しているかを検討したいと思います。

興野さん

Push型であれば、外部APIから取得したデータを即座に業務システムにわたす事が可能ですね。しかし、その場合は取得した注文情報の送り先っていうのをこちらで管理する必要が出てくるため、導入店舗が増えるたびにこちらで導入のための設定作業が必要になるため、運用が煩雑になりそうな感じはします。
一方で、Pull型であれば業務システム側から定期的に取得要求を送ってもらう形になるので、リアルタイム性には欠けますが、導入店舗が増えても我々側で新たな設定は必要ありません。そう言った点で考えると、運用がシンプルになるという点でPull型がいいと思いますが、いかがでしょうか？

佐藤さん

今回は秒単位のリアルタイム性をそこまで求められているわけではないので、取得してくる間隔などを検証して決めれば、Pull型の方が、今後店舗数が増えたときに長期的に見ても効率良さそうですね。Pull型で進めましょうか。

興野さん

また、要件として、注文が入った場合には外部からWebhookが飛んでくる仕組みがあり、Webhookの内容を元に情報を取得します。もし情報取得が失敗した場合、リトライ処理を行う必要がありますが、この部分も検討が必要ですね。
Webhookに対するレスポンス返却とリトライ処理を同期的に行った場合、リトライ処理中はレスポンスが返せないため、処理時間が長くなった場合には、再度Webhookが飛んでくる可能性があります。この解決策として、Pub/Subを使用してWebhookの内容確認と注文情報の取得処理を非同期で行うのはどうでしょうか？そうすることにより、Webhookからリクエストが来た場合、即座にWebhookの内容確認をしてレスポンスを返却することができますし、注文情報のリトライ処理が別軸で動くことになると思うので、いくらリトライ処理が続いたとしても、Webhook側の処理には影響がないと思うのですが、どうでしょう。

佐藤さん

その案いいと思います。技術検証を行って、もし実現可能であればその方法で進めましょう。これで事前に抑えておくべき点は、カバーできたかと思います。他になにかありますか？

興野さん

実は、以前Postmanの勉強会に参加した際、運用や単体テスト・内部結合テストに役立ちそうな機能がいくつかあったので、それを活用できればと思いますが、よろしいでしょうか？

佐藤さん

Postmanを使うと、どういったメリットがあるのでしょうか？

興野さん

Postman導入のメリットは、2点あります。1つ目はコレクションと呼ばれるリクエストの一括管理がありまして、そのコレクションを利用してテスト実行と確認が簡単にできることです。2つ目は、モックサーバーをPostman側で簡単に構築ができるので、内部結合テストの際、作業効率が向上します。今回、試しに導入するのはどうかなと思っております。

佐藤さん

なるほど。テストが誰でも行いやすい点やモックサーバーを簡単に導入できるのはいいですね！ぜひ導入しましょう。ただ、Postmanを使用した経験が少ない方が多いと思うので、簡単なPostmanの使用方法のドキュメントと、今回のプロジェクトにおけるテスト実施の手順書の作成をお願いできますでしょうか？

興野さん

承知いたしました。ドキュメントと手順書も合わせて準備します。

佐藤さん

APIの構成についてはこんなところでしょうか。ほかに何かありますか？

興野さん

特にありません。

ーーーーー

ここまでの打ち合わせで、バックエンドの方たちがプロジェクトの目的を整理して、APIの構成までを決めていく様子をお伝え出来たと思います。次の記事では、Google Cloudの構成についての話し合いと、打ち合わせ後のインタビューについて紹介していきます。

【技術特集】選ばれた技術、その理由と裏側～②～に続きます。