開催報告: クラウドネイティブ設計コンペバトル! – クラウドネイティブ分科会 第5回 Meetup

はじめに

Jagu’e’r クラウドネイティブ分科会では、各企業のクラウドネイティブ技術の活用促進を目指し、Meetup や チャット上でのコミュニケーションなど様々な企画を検討しております。
2022年4月28日13:00から行われた第5回のイベントではクラウドネイティブ分科会「初」の試みとなる「クラウドネイティブ設計コンペバトル!」を開催しました!

この記事では、コンペバトルの内容について Jagu’e’r クラウドネイティブ分科会 上田 がご紹介致します。

クラウドネイティブ設計コンペバトル!の概要

今回のMeet up は開始時間を普段の18:00ではなく、13:00に前倒しして実施しました。

Google Cloud の Nakさんにお題やファシリテーションをご準備頂き、約二時間、参加者が作ったアーキテクチャを題材にディスカッションを実施しました。

設計コンペバトルは、個人またはチームで参加します。
進め方としては、まずは運営から提示された 3 つのお題の中から 1 つを選びます。
その後、どんなシステムが必要になるのかを “自由に” 想定した上で、システム全体のアーキテクチャを検討しGoogle Slide 上にアーキテクチャ図として落とし込みました。

お題

1つ目のお題は、カレンダーの情報からその会議にかかる人件費を可視化する仕組みです。

2つ目のお題は、自動販売機のディスプレイに顧客に響く広告を表示する仕組みです。

3つ目のお題は、企業や学校など特定のコミュニティ内で利用できる SNS です。

今回、4つの個人・チームが設計に挑みましたが、テーマ選択の結果は下記のようになりました。

  1. カレンダー:2チーム
  2. 自動販売機:1チーム
  3. Twitter:1チーム

ちなみに、運営メンバーも含めた個人単位での希望の結果としては、カレンダーが圧倒的に人気でした。

続いて、アーキテクチャ図の説明・工夫とディスカッション内容について見ていきます。

 

お題1. カレンダー情報から会議の人件費を計算

チームA のアーキテクチャ説明・工夫

  • シンプルかつ、スケーラビリティを持たせ、コスト削減の観点でもライトに!
  • 個人情報をマスクするために Cloud DLP(Data Loss Prevention)を利用
  • 将来的に計測したい機能が増えることを見据えて、Pub / Sub を用いて抽象化し変更を容易に
  • 収集した情報を集計し、Cloud Storage を参照するSPAを作成

チームA のディスカッション

  • 個人情報の削除、マスクの処理を全てCloud DLP に任せてしまうのがいいですね
    • DLP おいてドロップ、マスク、ランダム文字列化に対応しているのは3メガクラウドのうち、Google Cloud 含む2社
    • 各国の機密データに対応している 便利ですよね
    • 中丸という珍しい名字にも対応している!
  • GUIを通じてリアルタイムに柔軟にパラメータを変更し集計するためにこの形を採用
  • BigQuery などデータ分析や可視化のマネージドサービスをもう少し検討してみてもいいかも
    • OSS の Metabase も可視化に使えそう
    • データポータル(海外でのサービス名は Data Studio)は無料です!
    • Looker は柔軟性やアクセスログ、監査の観点でもコンプラ対策でき、ビジネスサイドでのデータ活用・試行錯誤を促進
  • 将来的にレコード数が多くなってくると BigQuery 、各拠点でのトランザクションデータが増えてくると Cloud Spanner の活用もいいよね

 

チームB (チーム旭化成)のアーキテクチャ説明・工夫

  • カレンダーの予定だけでなく、実績を両方集計したいので、AppEngine 上の入力アプリから入力
  • 予定・実績データをEventarc + Cloud Function を用いて BigQuery に投入
  • 会議室単価などの種々のデータをかけ合わせ、データポータルで可視化

チームB (チーム旭化成)のディスカッション

  • スケジューラーという観点では、Eventarc というよりも Cloud Scheduler が担うべきなのかな?
    • Cloud Scheduler にて cron が拾えない、カレンダー側での変更に起因するイベントも拾いたいので Eventarc がいいかなと思った
    • 様々なイベントに対応できるという点で、Eventarc の方が汎用性が高いかな
  • Pub/Sub を使って、キュー、タスク管理をしても良かったかな
  • 会議情報は外に出せないので、セキュリティを担保する仕組みも考えておかないと
  • このアーキテクチャ図を見ているとBigQuery ML を使いたくなっちゃいますよね

お題2. 自動販売機にパーソナルな広告を表示

チームC のアーキテクチャ説明・工夫

  • 飲み物を販売する自動販売機において、購入者のSNSのアカウント情報を元に商品をレコメンド
    • 例:直近にアップロードされた写真が、酢豚、ラーメン、中華丼  であれば 烏龍茶
  • 事前にレコメンド情報をバッチ処理により生成し、Cloud Bigtableに格納しておく
  • 予測・レコメンドの際はCloud Run 経由でBigTableにアクセスし、低レイテンシで飲み物をレコメンド

チームC のディスカッション

  • 自動販売機にSNSアカウントを入力させるのは無理がないか?
    • その通り!変化球の設定をしてみました!
  • 実際の広告ではサイネージにビーコンを組み込み、アプリと通信を行い広告の出し分けを行う例などあり
  • Firebase を活用して、スマホ側にPush通知するなどの連携しても面白そう
  • CN 分科会で、いつか Firebase を扱いたいですね!
    • オフライン同期
    • ABテスト
    • Firebase ML
  • Cloud Run のメモリ上限が32GB まで上がりました!
  • Cloud Composer は Apache Airflow ベースのワークフロー オーケストレーション サービス
    • Cloud Composer は 依存関係のある処理同士をつなぎこんだ DAG (有向非巡回グラフ)をサポートしている
    • タスクの繋がり・順序性をもとに、一番効率の良いフローを計算する
    • Cloud Workflows と違い、Cloud Composer DAG をサポートしていることが大きな違い
  • BigQuery ではなく、BigTable を利用した理由は?
    • 低レイテンシを重視!
  • (その後、Cloud Run Jobs がGoogle I/Oで発表されました)

お題3. Twitter がほしいです

チームD のアーキテクチャ説明・工夫

  • 社内システムなので、LBの前にCloud IAPを置いてコミュニティドメインに属する特定のGoogle アカウントからのアクセスのみ許可
  • Cloud Run を用いてシンプルな形に
  • 投稿する内容はPub/Sub、Natural Languate API を経由し問題がある投稿をブロックし、 Cloud SQL にテキストデータを保存
  • 画像はCloud Storageに保存

チームD のディスカッション

  • Pub/Sub を利用する目的の一つとして、同時接続 1,000ユーザでも快適に使えることがある
    •  全投稿について3〜4秒かかるとレスポンスに長時間を要する
    • ところが、Pub/Sub を用いることでイベントドリブン・疎結合にでき、フロントのサーバーは短時間でレスポンスを返すことができるようになる
  • Pub/Sub を利用すると、後ろのSubscriber をNatural Languate API 以外にも簡単に増やすことができるので機能追加が楽になる
  • Cloud CDN を使うのはどうでしょう?静的ファイルはキャッシュさせてもいいかも
  • 高頻度な時系列データはBigtableもあり得るが、 後からクエリを投げることを考えると今回は素直にRDBの方が良さそう
  • Eventarc を用いて、画像のFormatting も良さそう
  • Cloud Run の Native な IAP 対応は Preview
  • IAPを使うためにLB のNEG設定を行うのは煩雑ですよね
  • Pub / Sub のPush notification を使うためにIAPを活用したことがある
  • 不適切な画像を検出するためには、AutoML Vison を導入して検出・除外が良さそう
  • GCS の Storage Notification を用いてBucket にファイルがアップロードされたら通知
  • Web Risk API を活用するのもいいですね!

その他ディスカッション

  • アーキテクチャに沢山アイコンがあると、シンプルさには欠けますが、満足感が出ますよね〜
  • 制限時間として、20分は短かったですね

まとめ

設計コンペバトルと銘打ち、お題に対するアーキテクチャを検討しディスカッションをする初めての試みでした。
設計の背後にある思想を聞いてなるほどと感じる面白さや、サービスの使い所をより深く理解する意味でも非常に有意義な時間だったと思います。

今後も設計コンペバトルを開催していきたいと思いますのでぜひ奮ってご参加頂き、熱くディスカッションさせてください!

最後に

Jagu’e’r では会員を募集しております。
Japan Google Cloud Usergroup for Enterprise(Jagu’e’r) 会員登録申込みフォーム http://goo.gle/Jaguer

上記の登録に加え、下記フォームにお申し込みいただくことで 分科会のSlackグループに参加することができるようになり、本セッションの資料をダウンロードすることが出来ます。
Jagu’e’r 「クラウドネイティブ分科会」 会員登録申込みフォーム https://forms.gle/dmGfuUzK1qh9roch8

長文になりましたが最後までお読みいただきましてありがとうございました。
それでは、次回のクラウドネイティブ分科会 Meetup でお会いしましょう!

Jagu’e’r クラウドネイティブ分科会

Yoshinori Ueda