オーケーアプリ事例に関する技術解説（構成について）

はじめに

2023/1/13にオーケー株式会社様における会員カードアプリの導入事例が公開されました。

cloudpackの導入事例｜オーケー株式会社様のクラウドを活用した導入事例

2,500社を超える導入実績を持つcloudpack。導入事例としてオーケー株式会社様のクラウドを活用した導入事例、cloudpackのプランやサービスを合わせてご紹介いたします。具体的なイメージにご活用ください。

cloudpack（クラウドパック） 2,500社を超える導入...

アイレットはデザインから開発、そしてインフラ構築・運用までをご支援させていただきました。
今回はインフラ構築の裏側について解説する記事となります。
複数回に分けて公開させていただいており、当該記事では構成部分について解説します。

解説記事の一覧はこちら：

オーケーアプリ事例に関する技術解説（構成について）

オーケーアプリ事例に関する技術解説（ネットワーク編）

オーケーアプリ事例に関する技術解説（フロント・バックエンド・バッチ編）

オーケーアプリ事例に関する技術解説（データ分析、開発編）

オーケーアプリ事例に関する技術解説（監視運用、ログ保管編）

概要

構成では、インフラ、開発ツール、分析環境まですべてがGoogleで完結しております。Googleのサービスの豊かさと、BigQuery に代表されるデータ分析に関わる分野においては、Google Analyticsデータ連携をはじめとした強みを出せていますが、それにプラスしてWebサービス提供におけるフロント面を始めとしたインフラ面においても、Google Cloud の強みを発揮できており、他クラウドを使わずにGoogle Cloudのみで構成できている点がポイントとなります。
構成を検討するにあたって、インフラ、開発両面において、クラウドであることを活かし、運用負荷を軽減するためにも、極力マネージドサービスを選定しております。後続に構成図、構成の詳細を記載します。

構成図

構成の詳細

【インフラ】

構成は大きく、カード会員アプリと管理サイトの2つに分かれます。

フロントエンド

両方のフロント部分はCI/CDの仕組みを容易に組み込めることやスケールスピード、構築を行う上での容易性からCloud Runを選定し、また静的コンテンツについてはCloud Storage へ配置しました。

バックエンド

方針に従いデータベースはマネージドデータベースのCloud SQLを選定しました。また処理の高速化のために、MemoryStoreを利用し、揮発性情報を保存し、高速化する構成としました。

外部連携

既存のネットスーパーと連携するうえでセキュリティ及び要件上の観点からDBを外部に公開せずに、外部公開するAPIをCloud Functionsで設け、Cloud Functions経由で連携する設定としました。

バッチ処理

バッチサーバを設けずに、Cloud Functuonsを作成し、CloudScheduler、Pub/Subと連携してのスケジュール実行や、イベントドリブン可能な構成とし、サーバの管理なく、処理種別に応じて柔軟に対応できるコンポーネントを選定しました。

認証、ID管理

Cloud Identity にてアプリ上のユーザ及びネットスーパーのID、認証情報を管理し、認証機能自体も提供する構成としております。

セキュリティツール

Cloud Armorを利用し、WAF機能を提供し、こちらもマネージドルールを利用しております。

【開発】

開発ツール

Firebaseにてアプリのプッシュ通知、DataAnalyticsとBigQueryへの連携、アプリの検証環境の配信をアプリで行うなど、開発に関わるツール群を一元管理する構成としました。

データ分析

各種情報を上述した、BigQueryへ連携する仕組みを設けることで、Lookerを利用し容易にデータ分析連携可能な構成としました。

考慮点及び構成に対するコメント

考慮点

前提に従い、構成自体にはそれほど時間をかけずに決めることができました。
インフラ部分での選択肢が多かったものとしては、フロントエンドはGCE、App Engine、Cloud Runが検討にはあがりましたが、前提条件を満たそうとすると、GCEはまず検討から外れました。
今回、サーバーレス、マネージドでありながら、コンテナでの構築の有識者も参画していることから、Cloud Runを選定しました。
Cloud Run はコンテナを自身で組めることと、Google側の仕組みでも可能ですが必要に応じたインフラ面でコントロールできること(例えば想定される負荷に応じてコンテナ数を調整できることなど)、Googleのサービスとしても成長中であり、選定時点でも充分ですが、スケールスピードのさらなる上昇や他サービスとの連携強化など今後のアップデートにも期待できることが決め手となりました。
上記以外は、Google Cloudの筆頭サービスで即決可能な部分が多い状況であり時間がかかりませんでした。
例えば、、、以下のような形です。

• アプリの開発に必要なPush通知(Firebase Cloud Messaging)、イベント情報の集積(Firebase Event)、Firebase AnalyticsのBig Queryへの連携設定、テストアプリリリース(Firebase Distribution)、をそれぞれFirebaseが機能を有しており、Firebaseを選定
• バッチ処理については、定期実行、イベントドリブンなど状況を選ばず実行でき、柔軟であることから Cloud Functions を選定

構成についてのコメント

考慮点にも記載しておりますが、実現したいものとマッチするサービスがGoogle側で準備されていたものが多く、お客様の要望を満たす上でも、Google Cloud を選定したことのメリットを多く享受できました。中でも今回利用したサービスからBigQueryへのデータ連携がスムースにできることで、すでにお客様にてBigQueryをご利用になられていることもあり、データ分析の統合管理において、大きなメリットとなりました。

当該記事はインフラ担当した亀田、齋藤(寛隆)にて記載しております。