1 © PKSHA Workplace All rights reserved. マルチクラウド・マルチプロダクト で実運用中のプロダクトのアーキテ クチャと IaC の話 株式会社 PKSHA Workplace 成定 怜士 2023年7月13日

2 © PKSHA Workplace All rights reserved. プロフィール 成定 怜士 （なりさだ れいし） ソフトウェアエンジニアとして複数の経験を積んだ後、 2022年に株式会社 PKSHA Workplace に入社。 AI ヘルプデスクのテックリードとしてインフラからフロントエン ドまで幅広く関わりながら、開発と運用を担当。 株式会社 PKSHA Workplace テックリード @_ri_sa_da

3 © PKSHA Workplace All rights reserved. 3 1. PKSHA AI ヘルプデスク for Microsoft Teams の紹介 2. マルチクラウドの経験談 3. Azure OpenAI 導入によるアーキテクチャの変化ついて 4. Azure リソースの IaC について 目次

4 © PKSHA Workplace All rights reserved. 4 PKSHA AI ヘルプデスク for Microsoft Teams の紹介

5 © PKSHA Workplace All rights reserved. PKSHA グループのビジネスの全体像

6 © PKSHA Workplace All rights reserved. PKSHA AI ヘルプデスク for Microsoft Teams の紹介 使えば使うほど賢くなる Teams で実現するAI ヘルプデスク 社内ヘルプデスク環境を Microsoft Teams 上で実現。 社内問合せに対応するバックオフィス部門、 商品および技術情報の問合せに対応する各サポート部門の 各種問合せ業務をサポートし、生産性を向上させる。 [機能一覧] - 社内問合せ管理・有人チャット - FAQ 管理/運用・FAQ 自動生成 - AI チャットボット 等 [導入企業 (一部)]

7 © PKSHA Workplace All rights reserved. PKSHA AI ヘルプデスク for Microsoft Teams の紹介 Microsoft Teams 上に簡単に導入可能なシステム ・質問者と回答者それぞれの運用コストを大きく軽減 ・使うほど自己解決・有人対応それぞれの回答精度や品質を向上

8 © PKSHA Workplace All rights reserved. PKSHA AI ヘルプデスク for Microsoft Teams の紹介 • 有人チャット終了後、すぐに対話ログから Q&A を自動生成 • そのまま Chatbot に登録することで、次回 からは自動応答で返答可能になり、利用者 の利便性向上と問い合わせ対応者の工数削 減につながる 従業員の問い合わせデータログから Q&A を作成

9 © PKSHA Workplace All rights reserved. 9 マルチクラウドの経験談

10 © PKSHA Workplace All rights reserved. マルチクラウドの経験談 AI ヘルプデスク のインフラとして Azure を使用した感想 ・エンタープライズ企業自身のインフラも Azure になっていることが多く、セキュリティ観点で顧客の納得を得やすいため、 　導入のハードルを下げることができた ・Azure App Service を利用すると Web アプリケーションに必要な要素が全てマネージドな形で素早く構築できたため、 　数日で MVP を作成し、顧客に提供することができたり、本質的なプロダクト探索に集中することができた ・環境を複数アカウント作成することなく、リソースグループ単位で分離できるので管理コストを下げることができた AI ヘルプデスクに Azure Bot Service を採用した背景 ・素早く Teams アプリケーションを立ち上げるため ・UX を Teams と揃えるため AI ヘルプデスク のマルチクラウド部分の紹介 ・AI ヘルプデスクは Azure 上で稼働 ・AI ヘルプデスクは AWS 上で稼働する PKSHA Chatbot と連動 ・全社でのドメイン管理は Amazon Route53 で実施 ドメイン管理 PKSHA Chatbot 稼働 AI ヘルプデスク 稼働

11 © PKSHA Workplace All rights reserved. マルチクラウドの経験談 単独クラウド利用時よりも検証に時間がかかる ・ドメイン関連の設定など、各種設定時には AWS と Azure の両方を操作する必要があった ・Web 上の情報は少ないことなどから調査などに時間がかかる想定でプロジェクト管理・検証を行った 単独クラウド利用時よりもログやトレースを追いづらくなる ・リクエスト開始からレスポンス完了までを一貫して追うことが難しかった ・ログなどを一箇所に集約してモニタリングを行うようにした

12 © PKSHA Workplace All rights reserved. 12 Azure OpenAI 導入によるアーキテクチャの変化について

13 © PKSHA Workplace All rights reserved. アーキテクチャの変更 Python モジュールを追加 ・AI ヘルプデスクは Go と Typescript を採用していた ・データ処理や自然言語処理をする部分向けに Python を追加採用 キューやキャッシュ使用箇所の増加 ・応答時間がかかり同期的な処理が難しいこと、料金が高くなりがちなことから、キューやキャッシュを追加 ・Azure App Service で複数サービスを運用中であり、更に App Service とキューなどの追加で管理が複雑になる状況 ⇨ なるべく複雑にならず、シンプルな実装ができる、何か適切なサービスはないだろうか？...

14 © PKSHA Workplace All rights reserved. Azure Container Apps の導入 Azure Container Apps ・AWS でいうと Fargate がイメージとしては近い ・2022 年 5 月に GA ・Container Apps environment に複数のサービスをまとめることで環境内で直接通信が可能 ・Dapr というサイドカーコンテナを利用した各種 Azure のサービスとの連携 https://learn.microsoft.com/en-us/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml

15 © PKSHA Workplace All rights reserved. Azure Container Apps の導入 環境の構築や運用してみての感想 ・複数モジュールを Dapr 経由でやりとりさせることができるので一度設定してしまえば Dapr Client を 　各モジュールでライブラリ経由で使うのみなのでシンプル ・複数の App Service で構成する場合各 App Service に通信相手のドメイン情報などを環境変数などで 　持つ必要があるが、Dapr で行うと全て localhost で通信可能 ・キューなどの実装も Dapr でない場合はそれぞれのサービスのクライアントを実装する必要があるが、 　Dapr では Dapr クライアントに統一可能 ・Redis や Service Bus、Azure Storage Queue などと簡単に接続可能 ・ローカル環境も Dapr コンテナを用意するとクラウド環境に合わせることができる ・多少 Kubernetes の知識が必要だが、ほとんど Kubernetes を意識せずに使用できる 今後の期待 ・Azure Container Apps Jobs ・現在はプレビュー版 ・ジョブコンテナを簡単に実行できる https://techcommunity.microsoft.com/t5/apps-on-azure-blog/introducing-jobs-for-azure-container-apps/ba-p/3826677

16 © PKSHA Workplace All rights reserved. 16 Azureリソースの IaC について

17 © PKSHA Workplace All rights reserved. Azureリソースの IaC について AI ヘルプデスクの IaC ・Terraform で管理 ・Azure provider を基本的には使用するが、場合によっては AzAPI Provider も使用する必要がある ・GA されたばかりのリソースなどは Azure Provider の更新が間に合わないこともあるので 　Azure Resource Manager の上に薄くラップされた AzAPI Provider を使用することで対応できるケースがある ・リソースの命名規則などは Microsoft の公式ドキュメントを参考に行っている https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations ・（参考）各種リソースの短縮名称について

18 © PKSHA Workplace All rights reserved. Azure OpenAI リソースの IaC について リソース管理で気をつけていること ・開発環境と本番環境で Azure OpenAI のリージョンを分ける ・現在はリージョンごとのクォータが存在するため ・クォータにかかってしまう場合は冗長構成も取り入れる ・特定のリージョンのモデルに大きな変化がないか定期的にチェックする ・レガシーモデルは再作成できないことに注意する https://learn.microsoft.com/en-us/azure/cognitive-services/openai/concepts/legacy-models

19 © PKSHA Workplace All rights reserved. Azure OpenAI リソースの IaC について リソース管理で気をつけていること ・キャパシティの設定を IaC で行う ・設定せずにデプロイするとデフォルト値で設定される ・Azure Portal で設定値を更新しても再デプロイ時に戻るため https://learn.microsoft.com/en-us/azure/cognitive-services/openai/how-to/quota

20 © PKSHA Workplace All rights reserved. Azure OpenAI リソースの IaC について 過去の経験から気をつけていること ・アプリケーションの実装側で IaC によって作成されるリソースのモデル名を環境変数から参照しない ・モデルが変わると API のインターフェースが変わるケースが過去にあった ・必須プロパティだったものが新モデルでは存在するとエラーになる ・モデルを追加する（IaC のデプロイ）→ アプリケーションの実装と、使用する 　モデル名変更（アプリケーションのデプロイ）ができるようにしている

21 © PKSHA Workplace All rights reserved. まとめ ・マルチクラウドで発生する課題に対してプロジェクト管理やモニタリングを見直した ・Azure OpenAI 導入によるアーキテクチャ変更を容易に管理するため Azure Container Apps を取り入れた ・Azure OpenAI のクォータやリージョンごとに使用できるモデルの違いに注意し、IaC で の管理を見直した

22 © PKSHA Workplace All rights reserved. 宣伝 PKSHA AI ヘルプデスク for Microsoft Teams では Azure Container Apps や Azure OpenAI など新しいサービスをビジネスインパクトを考慮して導入し、提供価値を最大化していき ます PKSHA では GPT のみならず様々なアルゴリズムをプロダクト開発に取り込んで価値提供 することができます ご興味がある方、ぜひお話させてください!! 採用ページ: https://www.pkshatech.com/recruitment/