こんにちは。TeamSpirit開発チームの畠山です。
今回は今年の9月に開催されたDreamforce 2021にて発表されたPartner Intelligence Starter Packについてご紹介いたします。
当セッションは以下のSalesforce+のURLより見ることができます。弊社テクニカルサポートの手島も登壇しておりますので是非ご覧ください。
Partner Intelligence Starter Packとは
2021年9月3日にリリースされたAppExchangeで提供されているLabAppの1つで、同じくAppExchangeで公開したSalesforceアプリケーションの利用ログをAWSと組み合わせて簡単に取得できるようになるアプリケーションです。 TeamSpiritではリリース以前よりパイロットとして本アプリケーションの利用を開始し、ログ取得の仕組みを大幅に改善することができました。本記事では導入に至った経緯、具体的な仕組み、従来方法と比べて改善された点、実際のセットアップについてご紹介します。
Salesforceアプリケーションのログ取得の問題点
まず、Salesforceでは通常どのようにログを取得するのかご説明します。 ログ取得までのデータフローは以下のとおりです。
ここで問題はAppAnalyticsQueryRequestの部分です。ログの取得には都度ログ取得リスクエストをSalesforceに行う必要があり、リクエストにはクエリが15分以内に完了しなければならない且つ24時間に取得するログの容量20GBまで、さらに取得できるのは過去1ヶ月までという制限があります。
リクエストはAppExchangeで提供されているApp AnalyticsアプリケーションにてAppAnalyticsQueryRequetsオブジェクトにレコードを追加するか、APIを直接呼び出して行います。そうすると数分後にログのダウンロードリンクが取得できるためそこからログを取得する形になります。
このリクエストとダウンロード手動で毎日行うのは手間がかかります。さらに、ログを取得しようとしているアプリケーションに大規模な登録者基盤がある場合1日のログ容量は20GB(※)を超えます。実際にTeamSpiritでは1回のリクエストが15分以内に完了するためには1日のうち30分程度のレンジに絞る必要があり、必要なリクエスト数は非常に多くなっていました。そこで以下のような仕組みを作成してログの取得を行っていました。
具体的にはログ取得状況を管理するカスタムオブジェクトを作り、これに従ってEC2に作成したバッチが日次で動作して必要なデータを抽出した上で自組織のカスタムオブジェクトへ書き戻してレポートで閲覧する仕組みがありました。
ここで蓄積されたデータは弊社のカスタマーサクセスで活用され十分に有効性が確認されていました。そこで開発チームでも利用をはじめようとしたところで新たにいくつかの問題が上がりました。 それは大容量のため取得時間も長いことや、取得の失敗が起こるたびにリトライが追いつかなくなる事態があること、また当初はカスタマサービス向けの情報が目的であったため完全なログが残らず後から別の情報を取り出すことが出来ませんでした。
これらの改善に乗り出したのが今年の7月頃で、ちょうどその頃TeamSpiritではSalesforceと協同でAnalyticsの有効活用に向けて話し合いが行われていました。そこで上記の問題を相談したところ、Salesforceのエンジニアの方を紹介していただき提案されたのがPartner Intelligence Starter Packのパイロット版であり、先行で利用させていただく事になりました。
Partner Intelligence Starter Packを導入
実際に導入してみるとPartner Intelligence Starter Pack(以下、PI App)はTeaｍSpiritが構築したようなログ取得の仕組みを簡単にセットアップでき、且つ効率化された方法で上記の問題点を解決してくれるものでした。具体的な構成は以下のとおりです。
このうち、QuickSightを除くAWSの部分は提供されるCloudFormation設定によって全自動で構築されます。組織にインストールしたPartner Intelligence Starter Pack本体と合わせて動作し、毎日のログ取得からマニュアルでの期間を指定したリクエスト、リトライまでSalesforce側で制御することができるようになります。取得したログはS3に蓄積され、Athena、QuickSight、TablaueCRM等のデータソースに利用できます。
改善ポイントその1 : バッチ処理のサーバーレス化
まずEC2で行っていたバッチ処理はEventBredgeから起動されるStepFunctionsで処理されます。サーバーレス化されたことによりコストが大幅に低下した上、実行ごとにコンソールからビジュアルで動作ログを追うことができるようになりメンテナンス性も向上しました。
改善ポイントその2 : ログの容量低下
App Analyticsのログ形式はSummer'21までcsv形式しかありませんでした。しかしSummer'21からはParquet形式に対応し、大幅に容量が削減された状態でダウンロードできるようになり、TeamSpiritの場合csv形式で30GBほどあったサイズがParquet形式では2GB 弱ほどまで抑えられています。もちろんPI Appはこれに対応しており低コストでログを保存できるようなり、取得にかかる時間も非常に短くなりました。しかしParquet形式のファイルはそのままでは読み込むことが出来ないため、後述するAthenaを利用して解析を行います。
改善ポイントその3 : データ分析の基盤ができる
S3に蓄積されたParquet形式のログファイルは列指向データのためそのままの状態では分析が難しいですが、AthenaというAWSのクエリサービスを用いて馴染みあるテーブルデータとして扱うことが出来ます。これはQuickSightやTablaue等の分析基盤のデータソースにすることができます。
Partner Intelligence Starter Packのセットアップ手順
ここからは実際にPI Appを導入する手順を解説していきます。 所要時間は1時間弱程で完了することが出来ます。尚、本記事のセットアップ手順は2021/12時点のものとなっております。オリジナルの記事はこちらです。
まず、Salesforce側の設定です。
まずSaleforce LabsよりPI Appをインストールします。 Partner Intelligence Starter Pack [Old Version] - Salesforce Labs - AppExchange インストールするとPI LabAppアプリケーションにてLogPullConfig、Log Pull Activityオブジェクトを確認できます。
PBO組織にてユーザ(PILabappにアクセスするユーザとAWSからAppAnalyticsRequest APIを呼び出すAPIユーザ。同一でもOK)を用意し、権限セット「PILabappConfigPSL」を割り当てます。このとき、APIユーザでセキュリティトークンを発行しておきます。
PI LabAppアプリケーションに移動し、LogPullConfigタブを開き、以下のようにレコードを作成します。
新規LogPullConfig画面
・AppName - 任意のアプリ名
・AppPackageId - AppExchangeリストに関連付けられているパッケージIDの15文字。18文字のパッケージIDから最後の3文字を削除します。
・Packages - AppPackageIdと同じ。複数パッケージのログを取得する場合はコンマ(,)区切りで入力します。
・ExpectedVolume - 予想されるログの量に応じて選択。HIGHのほうがリクエストが細かく分割されるようになります。
ここからはAWS側の設定です。
- CloudFormationスタックをインストールします。「新しいリソースを使用（標準）」を選択し、「前提条件 - テンプレートの準備」は「テンプレートの準備完了」、「テンプレートの指定」はS3URLにリージョンによって以下を指定します。
- us-east-1 : https://pi-public-template-bucket.s3.amazonaws.com/PiappjscdkStack.template.json
ap-northeast-1 : https://pi-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/PiappjscdkStack.template.json スタックに任意の名前を付け、残りはすべてデフォルトで作成します。
PBOログイン情報をSecretManagerに登録します。TemplatedSecret..ではじまるシークレットを見つけてPBO組織のAPIユーザ名とパスワードを更新します。
Secrets Manager更新画面
・ password - 上記ユーザのパスワード(セキュリティトークン付き)
以上で設定は完了です。
最後に
今回はPartner Intelligence Starter Packを使用したTeamSpiritログ取得の改善活動の内容をお届けしました。TeamSpiritでは本アプリを利用することでカスタマーサクセスにおけるDXや、機能開発の意思決定の迅速化を実現しました。是非利用してみてはいかがでしょうか？
