オンラインコミュニケーション開発ツール「 SkyWay」 を支える技術 〜AlloyDB 活用例〜 / Technology behind the online communication development tool "SkyWay" -Utilization example of AlloyDB-

2023 年 5 月 24 日のGoogle Cloud Day ’23 Tour in TOKYOで発表した「オンラインコミュニケーション開発ツール「 SkyWay」 を支える技術 〜AlloyDB 活用例〜」の資料です。
2023 年 1 月にリリースした新しい SkyWay は、可用性向上のためリリース 1 ヶ月前に利用する DB を AlloyDB に変更するという決断を行いました。
本セッションでは、なぜ AlloyDB の利用を決めたのか、それによってどのような課題が解決されたのかを実例とともに紹介します。
加えて、毎日 40 万回以上のビデオ・音声通話を支える、Firestore や Cloud Armor を活用したインフラ構成についても説明します。

講演詳細についてはこちらをご覧くださいhttps://cloudonair.withgoogle.com/events/google-cloud-day-23/watch?talk=tok-d2-db02

Transcript

1. オンラインコミュニケーション開発ツー ル「SkyWay」 を支える技術 〜AlloyDB 活用例〜 門下 佳樹 NTT コミュニケーションズ株式会社 プラットフォームサービス本部 SkyWay 推進室 ソフトウェアエンジニア 池田 裕介 NTT コミュニケーションズ株式会社 プラットフォームサービス本部 SkyWay 推進室 ソフトウェアエンジニア
2. スピーカー自己紹介 2021 年に新卒で入社 リアルタイム コミュニケーション プラットフォーム 「SkyWay」の開発・運用に従事 バックエンド・フロントエンドの開発に加え、 インフラの構築・運用まで幅広く担当 門下 佳樹 NTT コミュニケーションズ株式会社 プラットフォームサービス本部 SkyWay 推進室 ソフトウェアエンジニア
3. SkyWay の紹介
4. SkyWay とは • 映像・音声・データ通信機能をアプリケーションに簡単に 実装できる SDK & API • 端末間の通信を仲介するサーバーと、 それを利用するための SDK を提供 • SkyWay のシステムは、ほぼ全て Google Cloud 上で構築
5. SkyWay のこれまで • 2013 年　提供開始 • 2017 年　商用提供開始 • 2022 年 2 月　新しい SkyWay β 版提供開始 • 2023 年 1 月 31 日　新しい SkyWay 提供開始 ※1　2021 年度実績 万回/日 映像・音声通話回 数 % 稼働率 ※1 年以上 運用実績 99.96 10 40
6. Virtual Private Cloud AlloyDB Cluster Virtual Private Cloud 本セッションで説明する範囲 Firestore アカウント管理サー バー Compute Engine Internal Load Balancer Cloud Load Balancing 認証サーバー Compute Engine シグナリングサー バー Compute Engine HTTP WebSocket Cloud Load Balancing Cloud Armor Cloud Load Balancing Cloud Armor AlloyDB の活用例 スケールする リアルタイム双方向通信 Primary AlloyDB Read Pool AlloyDB 利用量集計バッチ Cloud Functions コネクタ Compute Engine マネージドサービスを用いたセ キュアなサービス提供 Identity-Aware Proxy SSH
7. Virtual Private Cloud AlloyDB Cluster Virtual Private Cloud 本セッションで説明する範囲 Firestore アカウント管理サー バー Compute Engine Internal Load Balancer Cloud Load Balancing 認証サーバー Compute Engine シグナリングサー バー Compute Engine HTTP WebSocket Cloud Load Balancing Cloud Armor Cloud Load Balancing Cloud Armor AlloyDB の活用例 スケールする リアルタイム双方向通信 Primary AlloyDB Read Pool AlloyDB 利用量集計バッチ Cloud Functions コネクタ Compute Engine マネージドサービスを用いたセ キュアなサービス提供 Identity-Aware Proxy SSH
8. Virtual Private Cloud AlloyDB Cluster Virtual Private Cloud 本セッションで説明する範囲 Firestore アカウント管理サー バー Compute Engine Internal Load Balancer Cloud Load Balancing 認証サーバー Compute Engine シグナリングサー バー Compute Engine HTTP WebSocket Cloud Load Balancing Cloud Armor Cloud Load Balancing Cloud Armor AlloyDB の活用例 スケールする リアルタイム双方向通信 Primary AlloyDB Read Pool AlloyDB 利用量集計バッチ Cloud Functions コネクタ Compute Engine マネージドサービスを用いたセ キュアなサービス提供 Identity-Aware Proxy SSH
9. SkyWay における AlloyDB の 活用例
10. AlloyDB とは • PostgreSQL との完全な互換性を持ったマ ネージド データベース サービス • 高いパフォーマンスと可用性が特徴 • 2022 年 12 月に一般提供開始
11. SkyWay における AlloyDB の利用用途 • アカウント情報の管理 ◦ プロジェクト ◦ アプリ ◦ アカウント etc… Project Application Account Account Project Project Application Application Application Application
12. SkyWay における AlloyDB の利用用途 • アカウント情報の管理 • ユーザーの端末接続時の認証処理 Virtual Private Cloud AlloyDB Cluster Virtual Private Cloud Internal Load Balancer Cloud Load Balancing 認証サーバー Compute Engine シグナリングサー バー Compute Engine アカウント管理系 リアルタイム通信系 Read Pool AlloyDB
13. SkyWay における AlloyDB の利用用途 • アカウント情報の管理 • ユーザーの端末接続時の認証処理 • 利用状況の可視化・分析 Virtual Private Cloud AlloyDB Cluster アカウント管理系 Primary AlloyDB Read Pool AlloyDB 利用量集計バッチ Cloud Functions コネクタ Compute Engine BI ツール Compute Engine BigQuery
14. なぜリリース 1 ヶ月前に AlloyDB に移行したのか 2023 / 01 / 31 新しい SkyWay リリース 2019 〜 従来の SkyWay では Cloud SQL を利用 2023 / 01 AlloyDB 移行作業開始 2022 / 12 AlloyDB 一般提供開始 2022 / 05 アカウント管理系開発スタート 当初は Cloud SQL を利用 • 開発スタート時点で AlloyDB はプレビュー段階 • リリース後の移行はダウンタイム・並行運用が必要 • アプリケーション側のコードの変更は不要 • 　「移行するならリリース前の今しかない」
15. なぜ Cloud SQL から AlloyDB に移行したのか • 可用性向上のため ◦ オンライン診療や手話通訳など、重要度の高いサービスでも 利用されており、可用性が非常に重要 ◦ Cloud SQL では、SLA 対象外のダウンタイムを伴う メンテナンスが定期的に発生 ※1 AlloyDB Cloud SQL SLA 99.99 % 99.95 % ※2 メンテナンスによるダウンタイム 〜 10 秒 平均 30 秒未満 ※1　メンテナンス拒否期間の設定により影響を軽減可能 ※2　定期メンテナンスに伴うダウンタイムは対象外
16. なぜ Cloud SQL から AlloyDB に移行したのか • 従来の SkyWay では、メインのインスタンスと、メンテナンス時のみ 利用するバックアップのインスタンスを準備 ◦ データ同期や接続先切り替えが必要となり、複雑になっていた メイン Cloud SQL バックアップ Cloud SQL Compute Engine 通常時（従来） 同期 メイン Cloud SQL バックアップ Cloud SQL Compute Engine メンテナンス時（従来） 切断を検知して 接続先を切り替え
17. 移行時の作業 • VPC の構成変更 ◦ AlloyDB にはプライベート サービ ス アクセスを利用して接続 ◦ 制限により別の VPC からは 接続できない ◦ AlloyDB に接続する必要がある サーバーは同一 VPC 内に配置 Virtual Private Cloud Virtual Private Cloud Compute Engine AlloyDB Virtual Private Cloud Compute Engine VPC Network Peering VPC Network Peering
18. AlloyDB のメリットと今後に期待すること • メリット ◦ 容易に高い可用性を実現できる点 ▪ 移行時にアプリケーション側のコード変更が不要 ▪ PostgreSQL に対応しているツール・ライブラリをそのまま使える • 今後に期待すること ◦ VPC 外から AlloyDB Auth Proxy を用いて接続ができると嬉しい
19. スピーカー自己紹介 2017 年入社 入社後はソフトウェアエンジニアとして WebRTC PaaS である SkyWay の様々な開発を担当 JavaScript SDK や バックエンド、インフラ構築の 開発・設計などに広く携わる 池田 裕介 NTT コミュニケーションズ株式会社 プラットフォームサービス本部 SkyWay 推進室 ソフトウェアエンジニア
20. Firestore によるスケールするリ アルタイム双方向通信の 構成
21. SkyWay がスケールするのに必要なこと • SkyWay は 1 日 40 万回以上の利用数 • SkyWay でコミュニケーションするには 事前にクライアント間の情報交換を実施 • 円滑な利用のためリアルタイム通信のスケーラビリティが必要 • スケールアウトには複数サーバー間での状態管理が必須
22. 状態管理してますか? • 一時的な Key-Value を持ちたいことは多い ◦ 特に小さいデータの場合を想定 ◦ 比較的書き込み比率が高い場合を想定 • サーバーがステートフルだと大変 • ステートを外で管理するのが一般的 ◦ Redis, memcached など • マネージドなサービスも選択肢
23. SkyWay で選定した Key-Value ストア 〜 Firestore 〜 • マネージドサービス • 自動スケーリング • SLA 99.99 % + 計画的ダウンタイム無しで高可用性 • TTL ポリシーによる自動削除機能
24. Firestore と他のプロダクトとの比較 Firestore Memorystore Cloud SQL Cloud Spanner • NoSQL DB • 自動スケーリング • SLA 99.99 % • 計画的ダウンタイム無 • 自動削除有 • 安価※ • インメモリ DB • 手動スケーリング • SLA 99.9 % • 計画的ダウンタイム有 • 自動削除可能 • 安価 • リレーショナル DB • 手動スケーリング • SLA 99.95 % • 計画的ダウンタイム有 • 自動削除無 • Firestore の 15 倍 (今回のユースケースの 場合) • リレーショナル DB • 自動スケーリング • SLA 99.99 % • 計画的ダウンタイム無 • 自動削除有 • Firestore の 10 倍 (今回のユースケースの 場合) ※: 費用は SkyWay でのユースケースを用いて試算
25. Virtual Private Cloud AlloyDB Cluster Virtual Private Cloud Firestore の利用例 Identity-Aware Proxy Firestore アカウント管理サー バー Compute Engine Internal Load Balancer Cloud Load Balancing 認証サーバー Compute Engine シグナリングサー バー Compute Engine HTTP WebSocket SSH Cloud Load Balancing Cloud Armor Cloud Load Balancing Cloud Armor リアルタイム通信系 Primary AlloyDB Read Pool AlloyDB 利用量集計バッチ Cloud Functions コネクタ Compute Engine
26. シグナリング サーバーとは • クライアント間で直接通信するには データ送信前に情報交換が必要 ◦ クライアント間で IP アドレスなどを交換 • サーバープッシュ対応が必要 ◦ WebSocket が必要 • リアルタイム双方向メッセージはスケールしづらい ◦ SkyWay は WebSocket + Firestore で解決
27. Instance Group WebSocket 接続の構成 • クライアントが接続中の サーバー情報を Firestore で一元管理 • クライアントはサーバーを 経由してメッセージを送信 ◦ サーバー間では HTTP で メッセージを転送 Cloud Load Balancing Firestore シグナリング サーバー Compute Engine メッセージの流れ 管理用データの流れ シグナリング サーバー Compute Engine 1 1 2 3 4
28. Firestore を採用したメリット 〜 TTL ポリシー機能 〜 • 一時的な値を入れる用途のため 値の削除が必要 ◦ 選定段階には無かったので 実装方法を検討中だった ◦ 2022/10 に機能追加 • GUI から 2 クリックで設定可能 ◦ 実装や設計のコストを削減
29. Firestore で考慮したポイント 〜 ホットスポット対策 〜 • ホットスポットとは ◦ 狭い Key の範囲に書き込みが集中 ◦ 書き込み性能が低下 • SkyWay では UUID を接頭辞とした文字列を ハッシュ化した値をキーにして利用 ◦ UUID の先頭の文字は 16 種類のため ハッシュ化した値をキーにして分散 ▪ 例: 11764d0c-a66d-41f5-947b-f858fe6a8b28 => ZTU5YWE5ZjAxNDNlNmMzMjQ3OTY3OTBiYmZiNz ZjNGY1YWI5YzdlYw== 11764d0c-a66d-41f5-947b-f8 58fe6a8b28 11764d0c-a66d-41f5-947b-f8 58fe6a8b28/foo 11764d0c-a66d-41f5-947b-f8 58fe6a8b28/bar 7c039f8b-d7b6-441a-9118-6 2f11bf1e3f8 7b4f63e9-2c7e-4268-804c-4 e677d8253ee e2f95cb3-b279-498a-b0f1-f0f 9213f42d8
30. SkyWay で選定した Key-Value ストア 〜 Firestore 〜 • Key-Value ストアとして便利 ◦ TTL ポリシーで古い情報を自動削除 ◦ ホットスポットには注意 • 自動スケーリングで簡単 • SLA 99.99 % + 計画的ダウンタイム無しで高可用性 • Cloud SQL や Cloud Spanner より安価
31. マネージドサービスを用いたセ キュアなサービス提供の 実現
32. SkyWay で必要な セキュアなアクセス • サーバーに SSH が 必要な場合がある • 社内のみに公開したい ウェブツールも存在 ◦ これらのアクセスを セキュアに行いたい ▪ ユーザ認証が必要 Instance Group シグナリング サーバー Compute Engine シグナリング サーバー Compute Engine 踏み台サーバー Compute Engine 社内向けツール Compute Engine 踏み台サーバー Compute Engine SSH HTTP
33. 従来の SkyWay の方式 • プライベートなアクセスは 踏み台サーバー経由 • 踏み台での アカウント管理が必要 • 設定忘れ・漏れが発生 ◦ 特に新規メンバー Instance Group シグナリング サーバー Compute Engine シグナリング サーバー Compute Engine 踏み台サーバー Compute Engine 社内向けツール Compute Engine 踏み台サーバー Compute Engine SSH HTTP
34. 新しい SkyWay で 採用した方法 • Identity-Aware Proxy (IAP) 経由で プライベートなアクセス ◦ SSH, HTTP 両対応 ◦ サーバーに Public IP は不要 • Google アカウントで管理 Instance Group シグナリング サーバー Compute Engine シグナリング サーバー Compute Engine 社内向けツール Compute Engine Identity-Aware Proxy Identity-Aware Proxy Cloud Load Balancing SSH HTTP
35. Cloud Armor による攻撃対策 • アプリケーションを保護するためのサービス ◦ DDoS 対策や WAF 機能 • 新しい脅威にも対応 ◦ 2021 年の Log4Shell では 一週間ほどでルールが追加 • POST リクエストで JSON が送られてくる場合、 JSON 解析の有効化が必要
36. まとめ • AlloyDB で高い可用性を実現 • Firestore でスケール可能な Key-Value ストアを安価に使用開始 • Identity-Aware Proxy で 踏み台サーバーにお別れ • Cloud Armor で脅威を軽減
37. Thank you.