データの読み込みの失敗を軽減する
学習の目的
この単元を完了すると、次のことができるようになります。
- テストのパフォーマンス計画を使用して、エンタープライズのスケールを最大化する。
- レコードのロックエラーを回避する。
シナリオ 1: 大規模なバッチサイズへの対応
創業 100 年を迎える大手の小売企業は、大勢のロイヤルカスタマーを抱えています。この企業は、日々の同期プロセスで 1,200 万件近くのレコードを Salesforce に更新/挿入しています。このプロセスでは、取引先 (100 万～ 400 万件) と金融口座 (600 万～ 1,000 万件) のデータの変更と、その他の数種のオブジェクトを同期します。お客様の金融口座の読み込みには Bulk API、取引先の読み込みには SOAP API を使用しています。SOAP API を使用して、データを複数のファイルに分けて取得することで、ビジネスの小規模な読み込みに対応しています。取引先については、1 回の読み込みで各種のシステムから取り込んだ 100 万件前後のレコードが処理されます。
この企業では、取引先の後処理を行うために、いくつかの Apex 一括処理ジョブがほぼ同時に開始されます。お客様は、すべてのジョブを 3 時間以内 (EST の午前 5 時～ 8 時の間) に完了させることを要件にしています。米国東海岸の最初のビジネスユーザーがログインする前に更新を完了させる必要があるため、この時間制限は極めて重要です。
1 か月前にコードのリリースを行い、ホーム画面に新しい Lightning コンポーネントを 2 つ追加しました。また、取引先の最新機能に対応するトリガーもいくつか追加しました。今回は小規模な更新であったため、リリース前に大規模なパフォーマンステストは実施していません。その後、時として日々のジョブの完了に 5 ～ 8 時間もかかっていることに気づき始めました。この遅延により、3 時間という SLA が守れなくなり、ビジネスユーザーがそのことに不満を抱いています。また、数人のユーザーがデータを編集しようとしたところ、ロックエラーが発生しました。一部のユーザーから、ホーム画面にアクセスしたときの動作が遅いという苦情も寄せられるようになっています。
では、このシナリオの詳細を整理して、問題の根本原因を特定してみましょう。
シナリオの重要な詳細情報
- 「日々の同期プロセスで 1,200 万件近くのレコードを Salesforce に更新/挿入しています。このプロセスでは、取引先 (100 万～ 400 万件) と金融口座 (600 万～ 1,000 万件) のデータの変更 … を同期します。」
- 「金融口座の読み込みには Bulk API、取引先の読み込みには SOAP API を使用しています。」
- 「お客様は、すべてのジョブを 3 時間以内 (EST の午前 5 時～ 8 時の間) に完了させることを要件にしています。」
- 「日々のジョブの完了に 5 ～ 8 時間もかかっています。」
注意点
このシナリオには、注意すべき点が 2 つあります。データの読み込み方法と Lightning コンポーネントの設定方法が、この企業に影響を与えている遅延だけでなく、そのスケール方法にも大きな影響を及ぼしています。上記のシナリオに基づいて、次の質問を検討し、パフォーマンスを向上させるためにはどのように対処すべきか考えてみてください。
データの読み込み
- 一括処理の実行時間はどのくらいか? 10 分という制限時間に近づいているか、制限時間に達して再試行が行われているか?
- データの読み込み中にエラーが発生しているか?
- ロックの原因となる可能性がある並列処理が行われているか?
- 新しいトリガーコードや追加された入力規則に非効率な点はないか?
- SOAP API ジョブを一括処理ジョブとして実行できるか?
Lightning コンポーネント
- ホームページの EPT (体験ページ時間) とネットワーク遅延はどのくらいか?
- 基盤となる Lightning コンポーネントに非効率な点はないか?
- ホームページ内のボタンをクリックしたときに Lightning コンポーネントが読み込まれるようにすることは可能か?
- 最新のブラウザーの使用、十分な帯域幅がある VPN の利用、バッテリー残量が十分なノートパソコンの使用といったベストプラクティスにすべて従っているか?
アンチパターン
シナリオを検討する際、開発者やアーキテクトは通常、問題の解決に使用できるパターンを考えます。このモジュールでは異なるアプローチをとり、お客様が Salesforce を実装する際に実施する一般的なアンチパターンについて解説します。アンチパターンとは、一般的ながら効果のない解決策のことです。一見すると適切な解決策のように思えますが、実際にはデメリットがメリットを上回ります。
では、このシナリオのアンチパターンと、代替となるベストプラクティスを見ていきましょう。
アンチパターン: 一括処理の読み込み時間を判断するための事前評価が Sandbox で行われていない。
ベストプラクティス: Bulk API を使用する前に、Full Copy Sandbox 内で試行して、パターン、読み込みのシーケンス、発生する可能性があるロックの問題を特定します。
アンチパターン: 50 万件を超える夜間読み込みに SOAP API を使用している。
ベストプラクティス: 50 万件以上の大量のレコードを Salesforce に読み込む場合は、Bulk API を使用します。小規模なデータセットには SOAP を使用します。外部システムから Salesforce にデータを同期する場合は、ビジネスユースケースを満たすために必要なデータのみを同期します。仮想化手法を使用して外部システムのデータを「参照」すれば、重要でない大量のデータを同期する必要がありません。上記のシナリオで、お客様は 100 万～ 400 万件の取引先データの読み込みに SOAP API を使用していました。読み込みが小さな単位に分割されていたものの、各読み込みのレコード数が 100 万件になっていました。SOAP API と Bulk API のどちらを選択するかは、データセットのサイズで判断します。
アンチパターン: データ読み込みと並行して一括処理 Apex を実行する。
ベストプラクティス: このシナリオの Apex コードの実行方法を見ると、Salesforce のロックメカニズムや、それが一括データの読み込みに及ぼす影響についての理解が不足しています。Salesforce でデータ移行をコーディングする際、レコードのロックエラーはよくある問題です。事前に子レコードを親 ID 順に並べ替えておくと、並列読み込みの一括処理間での親レコードのロック競合の可能性を減らすことができます。こうすれば、同じ取引先に属する取引先責任者がすべて同じ一括処理に含まれる可能性が高くなり、ロックが生じる可能性が大幅に低下します。
アンチパターン: 非同期操作に対して厳密な SLA を想定する。
ベストプラクティス: 非同期操作では、一括処理ジョブに時間のかかることがよくあります。そのため、キューに配置されたジョブがいつ完了するかについての保証や SLA は存在しません。Bulk API を選択した場合、サーバーはリソースが確保できた段階でレコードを処理します。ほかの一括処理ジョブが処理中かどうかによって、リソースの確保に数分かかることがあります。同期タスクは常に非同期タスクより優先されます。即時処理の必要がない場合は、非同期操作を使用します。
アンチパターン: カスタム Lightning コンポーネントのリリース前にパフォーマンス評価を実施していない。
ベストプラクティス: アプリケーションにカスタム機能が搭載されている場合は、本番にリリースする前にパフォーマンステスト計画を定めることが重要です。プロセスの早い段階で、ユースケースと計画、使用するツールやアクター、実行すべきテストの種別を決定して文書化します。ただし、Salesforce の標準機能にパフォーマンス評価やストレステストを行う必要はありません。
カスタム機能をテストする前に、どのようなテストを計画しているか Salesforce に知らせるケースを作成する必要があります。
お客様が実施する一般的なパフォーマンステストに、単一ユーザーテストがあります。ユーザーを 1 人作成し、エンドツーエンドで操作して、ボトルネックを見つけ出します。単一ユーザーテストは、ガバナ制限に達する可能性があるかどうかを把握するために実施します。このシナリオでは、Full Copy Sandbox 内でパフォーマンステストを実施する必要がありました。Full Copy Sandbox でテストを行えば、本番環境に予想されるデータ量に基づいて合成データを読み込むことができます。Full Copy Sandbox でテストすることが重要だとお伝えしましたよね? 念のための確認です。テスト環境は、データの量や構成の面で、本番とよく似た環境にしておくことが重要です。こうすれば、アプリケーションの実際のパフォーマンスをとらえることができます。
取引先と商談の間に所有権がある場合は、同じ比率とデータプロファイルを維持します。
パフォーマンスのテストを行うときは、ユースケースを常に最優先事項にします。テストすべきシナリオが複数ある場合は、エンドツーエンドでテストします。エンタープライズのダウンストリームで統合する必要があるバックエンドシステムもこの対象です。UI から開始し、Lightning コンソールの設定、ページのパフォーマンスの確認、バックエンドシステムへのインテグレーションのテスト、コールアウト時間の確認、カスタムコードのパフォーマンスの確認を行います。
パフォーマンスログをエンドツーエンドで表示できるツールが用意されています。こうしたツールを使用すると、どのレイヤーでパフォーマンスが低下しているかを可視化できます。インテグレーションについては、仮想ユーザー数を本番で想定される人数の 50% で再現することをお勧めします。たとえば、アプリケーションにログインするユーザーが 1,000 人いる場合は、最大 50% または Sandbox 内で許容される最大数で再現します。この種のテストは、オフピークの時間帯に実施することをお勧めします。Salesforce はマルチテナントプラットフォームであるため、日中にほかのテナントがピークトラフィックを実行していない時間にテストすると効果的です。
まとめ
このお客様には、かなりのアンチパターンがあり、深刻な障害を引き起こしていました。調査を終えた今、テストの活用方法、レコードのロックエラーの回避方法、一括処理データの読み込みのスケール方法について理解が深まったのではないでしょうか。次の単元では、エンタープライズ内での検索やレポートの問題を解決する方法を見ていきます。
リソース