音声系サービスにおけるサーバーレスアーキテクチャの活用について

NTT Tech Conference 2022（2022年3月23日開催）
「音声系サービスにおける サーバーレスアーキテクチャの 活用について」
(講演者：西谷 智広[NTTコミュニケーションズ株式会社])の講演スライドです。

GCPのサーバーレスアーキテクチャを使ってNTTコミュニケーションズ株式会社の音声サービス（COTOHA Call Center\COTOHA Voice DX Basic)を内製開発した時の工夫点、注意点を解説しています。

解説している主なGCPサービスは、Google App Engine,Firestore,Spannerとなります。

NTT Tech Conference 2022の詳細は下記をご覧ください。
https://ntt-techconf.connpass.com/event/241061/

Transcript

1. Ⓒ NTT Communications Corporation All Rights Reserved. 音声系サービスにおける サーバーレスアーキテクチャの 活用について NTTコミュニケーションズ株式会社 アプリケーションサービス部開発オペレーション部門 2022年3月23日 NTT Tech Conference 2022 西谷 智広 tomohiro.nishitani@ntt.com
2. Ⓒ NTT Communications Corporation All Rights Reserved. 自己紹介 西谷 智広（NTTコミュニケーションズ株式会社） ◆P2P,NAT越え ・キャリアグレードNAT国際標準化 ・050 plusの方式/開発リーダー ・P2P教科書（インプレス） ・15-10年前は社外でいろいろな勉強会の立ち上げ/運営 ◆VoIPの内製開発チームの立ち上げ ・COTOHA VoiceDX Basic ・COTOHA Call Center (NeWorkはアドバイザーとして参加） NTT関係技術士の会幹事 Professional Cloud Architecture(GCP)を取得 趣味 ・楽器演奏 -パイプオルガン、バイオリン、フルート、ピアノ 過去には吹奏楽も 2
3. Ⓒ NTT Communications Corporation All Rights Reserved. COTOHA VoiceDX Basicについて 3 電話の自動応答を提供。完全従量課金で、イニシャルコストを抑えて導入可能。 電話番号はWEB上から即時購入可能。  着信タイプ GUIでシナリオが設定できるIVR。(Interactive Voice Response） 電話着信時の応答を自動化。結果をメール送信やWEBで確認。 用途：ワクチン受付、作業報告、時間外受付 等  発信タイプ Slackをつかって、電話を一斉発信、順次発信。 発信時の応答結果はSlackに通知。 用途：故障呼び出し、安否確認、予約リマインド 等
4. Ⓒ NTT Communications Corporation All Rights Reserved. COTOHA VoiceDX Basicについて 4
5. Ⓒ NTT Communications Corporation All Rights Reserved. COTOHA VoiceDX Basicについて 5
6. Ⓒ NTT Communications Corporation All Rights Reserved. COTOHA VoiceDX Basicについて 6
7. Ⓒ NTT Communications Corporation All Rights Reserved. COTOHA Call Centerについて 7 中小企業向けのコールセンターサービス。ブラウザで発着信できる。 フリーダイヤル、ナビダイヤルとも連携できる。 ・グループ着信、保留、転送 ・時間外ガイダンス、時間外転送、携帯への転送 ・IVRシナリオ設定（GUI） ・電話帳、メモ機能 ・通話録音機能 ・COTOHA VoiceDX Basicと連携して、自動応答も可能。 ※ブラウザでの通話実現でWebRTCを利用
8. Ⓒ NTT Communications Corporation All Rights Reserved. COTOHA Call Centerについて 8
9. Ⓒ NTT Communications Corporation All Rights Reserved. チームの目標と課題 【目標】  電話の新しいサービスを、内製開発によってスピード重視でリリースする。  PoCによってトライアンドエラーで検討する。 【課題】 開発経験の少ないメンバで商用の電話系サービスが開発せざるを得ない。 【対策】 1.サーバーレスアーキテクチャを採用（本講演の説明対象） 2.開発言語をJavascript/Node.jsに統一 (Vue.jsを採用） 3.担当者を機能ごとに分ける（フロントエンド/バックエンドで分けない）
10. Ⓒ NTT Communications Corporation All Rights Reserved. 【デメリット】 Google Cloud の仕様に依存する 仕様追加 / 変更があるので定期的に 情報収集が必要 サーバーレスアーキテクチャの特徴 10 【メリット】 ➢ 開発スピード向上 OS 設定や各種パッケージの インストール作業が不要 ➢ プログラム開発に集中できる モニタリング ツールなど保守機能の 開発が不要。 Google Cloud 側でフルマネジメント。 耐障害性設計や冗長設定が不要。 ➢ リソース監視が簡素化 オートスケール対応。 リソースの変更作業および トラフィックの増大対応が簡素化。 内製開発するにあたり、コード量 / 検証を極力減らしたい ⇒GCPのサーバーレス アーキテクチャを採用
11. Ⓒ NTT Communications Corporation All Rights Reserved. 11 COTOHA Call Centerのアーキテクチャ(概要） bas オペレーター Google App Engine (PaaS) Cloud Load Balacing (LB) Cloud Armor (WAF機能) Firestore (NoSQL DB) Cloud Spanner (RDBM) 音声合成API 通話者 読み込みが メインなデータ 複雑なクエリ、 書き込みが多いデータ MemoryStore for redis 基本機能は ここで実現 Cloud function 電話 基盤 Security Command Center(SIEM)
12. Ⓒ NTT Communications Corporation All Rights Reserved. Google App Engine (Standard) 項目 内容 機能 プログラムをアップロードするだけで、プログラムを実行できる PaaS *以降GAEと略記 主な特徴 ・サーバーの構築が不要 ・対応言語：Node.js, Java, Python, Go など ・バージョンアップ時のお客様影響なし ・バージョン切り戻しが GUI で可能 制約事項 ・リクエスト受信後の動作時間に制約有り（Basic scaling だと制約が緩和） ・単一プログラム言語のプログラムしかアップロードできない オートスケール 可能（Automatic scaling 等を設定している場合） 12
13. Ⓒ NTT Communications Corporation All Rights Reserved. Google App Engine(Standard) 項目 内容 ポイント ・min_instances で最低起動インスタンス 数を設定する ->インスタンス数が 0 だと 50X エラーがでる場合がある ・GAE のレスポンス 時間を 10 秒を超えないようにする ->10 秒を超えると 50X エラーがでる ->トレース を使ってレスポンス時間を定期的にチェック ・長期安定試験でメモリリーク がないか確認する ＜テクニック＞ ・長時間のバッチ処理は、Basic Scaling を選択する ・Memorystore for redis と接続できる ・cron.yaml により定期実行が可能 ・dispatch.yamlによりURLによってサービスを分けることができる 選定理由： トラフィックの変動に応じて、すばやくインスタンス数を自動的に増減 マイナー リビジョン ランタイムの自動更新（ランタイムのセキュリティパッチ自動更新） フルマネージドなので運用や障害時の対応を簡素化できる 13
14. Ⓒ NTT Communications Corporation All Rights Reserved. Google App Engine(Standard) GAEを直接インターネット公開することもできるが、 ロードバランサーを導入することで ・cloud armorによってWAF相当の機能を実現できる （アクセスについてIPアドレス制限、ヘッダー情報による制限、地域制限も可能) ・自分が取得しているドメインに対する電子証明書を無料で作成・設定できる（＊自動更新） （ただしサブドメインに対するワイルドカードは使えない） ・サーバーレス ネットワーク エンドポイント グループを使ってロードバランサーとGAEを接続する Cloud Load Balacing (LB) Cloud Armor (WAF機能) Google App Engine (PaaS) インターネット
15. Ⓒ NTT Communications Corporation All Rights Reserved. Google App Engine(Standard) vs Cloud Run コンテナのフルマネージドサービス → Cloud Run GAEからCloud runに移行している企業もいる。 GAE:ソースコードをそのままデプロイ →単一言語に限られる Cloud Run: コンテナをデプロイ →様々なミドルウェアが利用できる GAEだとNode.jsのマイナーバージョンアップを自動的に行うので、その点は便利 (脆弱性対応） また、Cloud Runだと実行できる時間が短時間なので、処理時間が長いバッチ処理は GAE(Basic Scaling）が向いている。 ＊ GAE(Basic Scaling）だと１時間処理が継続できることは確認済み。
16. Ⓒ NTT Communications Corporation All Rights Reserved. Firestore 項目 内容 機能 サーバーレスの NoSQL ドキュメントデータベース 主な特徴 ・テーブル相当（コレクション） をワンクリックで作成できる ・クラスタリングの設定不要 ・GUI でデータベース の内容を編集できる ・非常に安価、読み込み速度が速く、スケーラビリティが高い ・メンテナンス時間がない 制約事項 ・同一ドキュメントに対する単位時間あたりの書き込みの回数制限あり →セッション管理、流量制限等の管理は、Memorystore for redisの 利用が一般的 ・バックアップ、一定期間後のデータ削除は cloud functions などで実施 ・NoSQL なので複雑なクエリはできない ・ホットスポットを避けるため、ドキュメント ID の値をなるべく分散できるようにする オートスケール 可能 16
17. Ⓒ NTT Communications Corporation All Rights Reserved. Firestore 項目 内容 ポイント ・読み込みが多い処理に向いている ・リレーショナル データベースと違い、柔軟にデータ構造を変更可能 →スキーマ―という概念が存在しない ・複数の処理を連続して行う場合、トランザクション 、バッチ処理を推奨 ＜テクニック＞ ・複数のコレクションから特定のドキュメントを探す APIがリリースされた。 ・一定期間以上の古いドキュメントを削除するには、Firestoreの機能では実現 できない。ドキュメントにタイムスタンプを付与してCloud functionsによって 削除する必要がある。 ・クエリー結果を並び替え可能。あいうえお順も可能だか、正式サポート外。 （前方一致検索しかできない） 選定理由： スケーラビリティが非常に高く、安価 高可用性フルマネージドなので運用や障害時の対応を簡素化できる 17
18. Ⓒ NTT Communications Corporation All Rights Reserved. Cloud Spanner 項目 内容 機能 可用性と拡張性に優れたフルマネージド リレーショナル DB 主な特徴 ・DB の構築が不要 ・クラスタリングの設定不要 →リージョン内の各ゾーンにデータ複製 ・メンテナンス時間がない (Cloud SQL はメンテナンス時間あり） ・GUI でデータベースの内容を編集可能 ・SQL が利用できるため複雑なクエリに対応できる ・GUI でノード数を変更できる 制約事項 ・ホットスポット を避けるため、主キー の値をなるべく分散できるようにする ＊例：キーとしてUUIDを使う ・主キーをauto incrementができない オートスケール しない (スケールを制御するオープンソースはある) 18
19. Ⓒ NTT Communications Corporation All Rights Reserved. Cloud Spanner 項目 内容 ポイント ・DB のメンテナンス時間 / 稼働を極力減らす必要がある場合に選択 ・中～大規模な処理では、Cloud SQL よりも安価な場合がある、とのデータあり ・今までノード単位でしか設定できなかったが、1 ノードまでは 1/10 ノード単位で設定 可能。小規模の場合、今までよりもコストを抑制 ＜テクニック＞ ・一定期間経ったレコードを自動的に削除できるようになった ・利用期間確約で、利用料を下げることができる（１年以上の利用が前提） ・CPU使用率などのリソースを監視しておく 選定理由： Google Cloud のリレーショナル DB のサービスで Google 側のメンテナンスによる 停止時間が唯一０ フルマネージドなので運用や障害時の対応を簡素化できる 19
20. Ⓒ NTT Communications Corporation All Rights Reserved. 監視について 項目 内容 ポイント ・定期的なEnd-End監視がメイン（ユーザの操作を疑似的に行い、障害がないか確認） ・障害かな？と思ったらGoogle Cloud Status Dashboardをみる https://status.cloud.google.com/ （RSSもある） ・あとは障害がなおるまで待つだけ。 ・Security Command Center (GCPによるSIEM)を導入し、脅威や脆弱性の検知もしている。 （サーバレスなので、EDRを導入できないため） ※Security Command Center組織単位での導入になる ※例えばlog4jの攻撃の検知ができる 障害発生頻度（体験談、使い方によって違いがあるかも） GAE:半年～１年に1回程度、数10分程度影響 Firestore/Spanner：サービスに影響した障害は経験したことがない 20
21. Ⓒ NTT Communications Corporation All Rights Reserved. 項目 内容 ポイント ・E2E試験でPuppeteerを導入 ・WEBRTCの負荷試験・長安試験として、Puppeteer+ Puppeteer Cluster(npm)を利用 →Puppeteer clusterを使うと、同じシナリオを同時実行可能 →WEBRTCでPuppeteerを使うには、マイク許可のポップアップのdisable, 疑似的に音声を流す等のPuppeteerの設定が必要 21 E2E(End-to-End)試験について
22. Ⓒ NTT Communications Corporation All Rights Reserved. ・開発量を大幅に減らすために、サーバーレス ソリューションの活用は非常に有効 ・ただしサーバーレス ソリューションの仕様を熟知している必要がある =>長期安定試験や負荷試験でサーバーレス ソリューションが適用できるか、見定めが必要 まとめ 22
23. Ⓒ NTT Communications Corporation All Rights Reserved.