超簡易版Facemashを作ってみた

はじめに

• 作ったもの
  • Linkedinの顔写真データを用いて、その顔写真が好ましいかどうかを判定するアプリケーション
• 動機
  • gcpを自由に使える環境があったので、サクッと何かを作ってみたかった
  • 顔写真の評価データを保持しておけば、将来的に何かに使えるのでは？

インフラ構成の判断軸などをメモしておくための備忘録

構成

全体構成図

まずはざっくり全体の構成図を。

Cloud Storage ➔ CloudSQL(画像URLの保存およびCSVデータの読み込み)
ユーザ ⇄ Firebase Hosting（フロントエンド）
Firebase Authenticationで認証し、トークン管理
フロントエンドから比較APIサーバ(Cloud Run)へリクエスト
Cloud Run（APIサーバー） ⇄ CloudSQL（データ管理）

処理の流れ

• Cloud StorageでCSVファイルをアップロードし、画像のid, group_id, URLデータをcloud sqlにインポート
• Firestoreにユーザ情報を保存し、各ユーザが行った評価結果をcloud sqlに保持
• Firebase Hostingでフロントエンドアプリをホスティングし、Firebase Authenticationを用いた認証と連携
• Cloud RunにバックエンドAPIをデプロイし、画像の評価結果保存

ログイン方法

Firebase Authentication

データ保持方法

ユーザ情報や顔写真評価結果のデータを保存するため、以下のデータベースを使用。

• Google Cloud SQL
  • ユーザのログイン情報や、ユーザがその画像をgood/badどちらを選んだか、を保持しておく
• Cloud Storage
  • CSVファイルを管理するために使用。linkedinから取得したcsvを設置し、cloud sqlにインポート
• BigQuery
  • 将来的にsqlに保存された評価データをもとに画像の評価を学習させる際に用いる

アプリケーションの配信方法

• フロントエンド
  • ユーザインターフェースはWebベースのシングルページアプリケーション（SPA）として開発し、Firebase Hostingでホスティング
• バックエンド
  • 評価ロジックやデータ管理のためにバックエンドAPIを構築し、Cloud Runでコンテナ化してデプロイ

その他の選択肢

• フロントエンド
  • Cloud Storage + Cloud CDN
    • 静的ファイルの配信には適しているが、アプリケーションには向かなそう
  • App Engine
    • SSRが必要な場合に適しているが、今回はそこまで複雑なアプリケーションではない
• バックエンド -> どれも重すぎる
  • App Engine
    • コンテナを使わずに動的アプリケーションをデプロイできるPaaS
  • Compute Engine
    • VMインスタンス上でアプリを実行するIaaS
  • Google Kubernetes Engine (GKE)
    • Kubernetesクラスターを用いて複数のコンテナをオーケストレーションするためのプラットフォーム