はじめに

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

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

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

前回までの記事はこちら：

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

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

 

概要

焦点を当てる内容としては赤枠箇所の以下となります。

  • フロントエンド
    ・Cloud Run
  • バックエンド
    ・Cloud SQL
    ・MemoryStore
  • バッチ
    ・Cloud Functions

各コンポーネント詳細

【Cloud Run】

コンテナサービスの場合、インフラチームと開発チームの作業分解点が難しいところですが、当該案件の場合、Cloud Runのサービス周りはインフラチーム、Cloud Run上で動作するコンテナは開発チームが担当しております。
Cloud Runのサービス作成にあたっての特徴的なポイントを3点記載します。

シークレットの利用

Cloud SQLへの接続を行うことから、接続に必要な機密情報をシークレットに暗号化して保存し、そのシークレットをCloud Runにマウントすることで、安全に機密情報を扱っております。
参考URL：https://cloud.google.com/run/docs/configuring/secrets?hl=ja

コンテナ数

Cloud Runは迅速にコンテナが起動できるため、常時起動はせず、少数であればリクエストがあった際に起動し捌くことが可能です。
しかし、リクエスト時にコンテナの異常によりエラーが発生した場合、アクセスを受け付けられるコンテナがなくなり、応答ができなくなる可能性があることを確認しました。
スケール速度は十分であるものの、お客様サービスの観点から、会員カードアプリ側は最低コンテナ数を2とし、常に冗長化する構成とし、想定されるリクエストエラーを回避いたしました。

Ingress制御

今回Cloud Load Balancerの配下にターゲットとして設定しており、カスタムドメイン設定や静的コンテンツへのパスルーティング設定しておりますのので、外部からのCloud Runのサービス作成時に払い出されるURLへのアクセスは不可とし、Cloud Load Balancerを通過した通信を許可するよう設定しております。

【Cloud SQL】

マネージドサービスであるため、パッチ適用やOS周り等の運用は基本的にGoogleに任せることで、運用負荷を軽減しています。
当該DBはアプリ利用及びネットスーパーの新DBとしての役割があり、冗長構成は必要条件でしたので、HA構成とし、障害時は待機しているインスタンスへフェイルオーバーするような構成としております。
ネットワーク編でも記載しておりますが、インスタンスにプライベートIPアドレスを設定し、Cloud Serverless VPC Access connector 経由でVPCを通って接続する構成としています。

【MemoryStore】

マネージドサービスであるため、パッチ適用やOS周り等の運用は基本的にGoogleに任せることで、運用負荷を軽減しています。
アプリ利用の観点で、冗長構成は必要条件でしたので、HA構成とし、障害時は待機しているインスタンスへフェイルオーバーするような構成としております。
当該コンポーネントの主な用途としては揮発性情報を保存し、リクエストに対する応答速度に貢献しています。
また、ネットワーク編でも記載しておりますが、インスタンスにプライベートIPアドレスを設定し、Cloud RunからServerless VPC Access connector 経由でVPCを通って接続する構成としています。

【Cloud Functions】

主に以下の種類の方法で起動しており、アプリに必要なレコメンド情報、店舗情報、購入履歴など多岐に渡る内容を外部システムと連携しており、それぞれの目的に応じた適切な起動方法で実行しています。

  • ネットスーパーシステムに対してのAPI提供
  • Cloud Storageへのファイル保存をトリガーにした起動
  • Cloud Scheduler(とPub/Sub)により定期実行をトリガーにした起動
  • アプリリリースに伴う会員データ移行時の手動起動

考慮点及びコメント

考慮点

機密情報を扱ううえではシークレットの利用などは必須になってくるかと思いますが、各コンポーネントでのセキュリティ面や可用性を意識した内容が考慮点の中心となりました。

コメント

Cloud Runにおいて、負荷試験を行ったうえで、記載したようなCloud Runの挙動を理解し、コンテナ数、リソース割当を決定することができました。
Cloud Runが良いコンポーネントであることは前提ではありますが、それを理解したことで、より良い運用を行える形にできたと考えています。

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