スケールに影響を及ぼす要因について学ぶ
学習の目的
この単元を完了すると、次のことができるようになります。
- スケーリングに悪影響を及ぼす課題について説明する。
- 一括処理が適切に行われていない状況を改善する 3 つの方法を再確認する。
- 不適切な共有モデルの影響を認識する。
- スケーリングを評価するために必要な 4 つの決定事項を検討する。
ソリューションを設計するときは、長期的な視野に立つことが大切です。1 人のお客様をサポートできるのであれば、何百万ものお客様をサポートすることを想定します。「細心の注意を払う」とは、細かいところまで気を配るということです。組織をスケールしてパフォーマンスを最大化するような場合には、その細部に意識を向ける必要があります。組織の一括処理やガバナンスが適切に行われていない場合や、ロックの問題が生じている場合、負荷の高い Apex 後処理が実行されている場合には、効果的なスケーリングに直接的な悪影響を及ぼします。その結果、お客様の成功が大きく左右されます。大量のデータを受信できなければ、将来的にお客様の商品が役に立たなくなる可能性があるためです。
では、こうした落とし穴を確認し、各自のアーキテクチャをより適切にサポートするための対処法を考えてみましょう。
適切な一括処理の欠如
トランザクションを一括処理すれば、応答時間やリソース消費が改善され、制限への到達を回避できます。その一方で、特にトリガーコードで適切な一括処理が行われていなければ、スケーリングが阻害されます。そのため、次のような優秀な開発者をチームに配置することが不可欠です。
- トリガーコードの最適化を習慣にしている。
- Apex のベストプラクティスに従う。
- Bulk V1 を使用する場合は、最適なバッチサイズを使用して一括処理を改善する。
複合 API を使用して、複数の API コールを 1 回のコールに集約します。Bulk API を使用するときは、制限による再試行やタイムアウトの上限を回避するためにバッチサイズを最適化します。一括処理ジョブが失敗する主な原因の 1 つはバッチサイズです。バッチサイズが大きすぎると、システムで割り当てられた 10 分以内に処理できず、一括処理が中断されてしまいます。
Salesforce では、実行時間が 10 分を超えると一括処理がタイムアウトします。組織で Bulk API 2.0 を使用している場合は、バッチサイズの問題が自動的に解決されます。他方、V1 を使用しているお客様は概して、大きめのバッチサイズ (10,000) から始め、タイムアウトが発生したらサイズを小さくしていきます。
Bulk V1 を実行している場合は、タイムアウトにならないように、バッチサイズを 7,000、5,000 と段階的に減らしていくことが適切な処理です。バッチサイズを小さくすると、スループットが低下しますが、ロックの発生を防ぎ、再試行回数を最小限に抑えることができます。タイムアウトが継続的に発生する場合は、Bulk API 2.0 に移行してください。
ガバナンスの欠如
ガバナンスについては、スケーラビリティに影響を及ぼす要因として、次の 2 点が挙げられます。
- 競合する複数のインテグレーションの実行
- 不適切なデータ/共有モデル
競合する複数のインテグレーションの並列実行は回避する必要があります。たとえば、あるインテグレーションで取引先 1 のケースが挿入され、同時に別のインテグレーションで取引先 1 の取引先責任者が挿入されるような場合です。このようにインテグレーションが競合すると、ロックの原因になります。こうしたガバナンスの欠如は、同じアプリケーションで作業する複数の機能チームや技術チームが、そのアプリケーションを構成するインテグレーションの全体像を把握していない場合によく見られます。
また、共有モデルが不適切な場合もスケーラビリティに影響します。データ/共有モデルはアプリケーションの基盤です。その設計に不備があれば、インテグレーション、レポート、シングルサインオン (SSO) など、ほかのすべての要素も失敗に終わります。
お客様と継続的に対話していれば、現在と将来のあらゆるニーズを把握することができます。データトランザクションをリアルタイムで行う必要があるのか、ほぼリアルタイムでよいのかを判断することが、ガバナ制限を回避する鍵になります。この点を把握していれば、大量のクエリ、更新、挿入に伴う負荷を将来に分散させることができます。この場合には、インテグレーションの選択プロセスも簡素化されます。データがプラットフォーム上に存在する必要がない場合は、Salesforce Connect のような手法を用いることが実際的な選択肢になります。
ロック
お客様が、データを更新するほかのシステムとのインテグレーションを維持したまま、大量のデータをアップロードすることがよくあります。複数のインテグレーションが同時に同じレコードを更新しようとすると、レコードのロックが生じるおそれがあります。
データベースのレコードレベルのロックは、更新中のデータの整合性を維持するために設けられています。このロックは、組織のほかのロックのようなパフォーマンス上のリスクはありませんが、更新の失敗の原因になることがあります。お客様が異なるスレッドで同じレコードに競合する更新を実行しないようにすることが重要です。
次の例を見てみましょう。カスタムシューズの製造企業である Cloud Kicks では、新しいスニーカーブランドのリリースに向けたマーケティングキャンペーンで、15 万件の取引先責任者が生成されました。ただし、これらの取引先責任者はいずれの法人取引先にも関連付けられていません。取引先責任者は取引先に関連付ける必要があります。親取引先が存在しないため、新しい取引先責任者をすべてダミーの取引先に割り当てれば簡単なのではないかと思うかもしれません。そうすると、ユーザーが取引先に関連付けられているのではなく、それ自体が取引先であるユーザーになってしまいます。1 件の親取引先に対する子レコードの最適な数は 1 万件です。Cloud Kicks が 15 万件の取引先責任者を 1 件の取引先に割り当てれば、メンテナンス時にパフォーマンスの問題が生じます。
負荷の高い Apex 後処理
実行順序がいかに重要かは周知のとおりです。開発者が同じオブジェクトに 12 ～ 15 のトリガーを記述しているのを目にしたことがあるかもしれません。その結果、過度の再帰が発生し、設計の不備だけが原因でデータインテグレーションに時間がかかるようになります。
さまざまなパターンを試してみたが、思うようなスループットが得られなかったということはありませんか? この原因として真っ先に思い浮かぶのは、選択したパターンに何か問題があるのではないかということです。実際には、Apex 後処理が原因でスループットに影響が及んでいる可能性があります。ここで少し時間を取り、Apex 後処理、プロセスフロー、トリガーを見直して、最適な状態であることを確認します。
Apex 後処理が最小限に抑えられていることを確認します。Bulk API を使用する場合、この点は重要な要因です。お客様がリソースを大量に消費していないか見極める優れた方法の 1 つは、一括処理ごとにどのくらい時間がかかっているか調べることです。一括読み込みを行っているのに、その処理時間が通常より一貫して長くなっている場合は、Apex 後処理の負荷が高いためにレイテンシーが大幅に増加しているということです。
必要なインテグレーションを調査する
スケール方法を正確に評価するためには、次の 4 つの事項を決定する必要があります。こうした決定事項は、サービスレベル契約 (SLA) を定める際にも役立ちます。
複製元と複製先
何が複製元で、何が複製先かを定義することが大切です。要件の作成を進める際、どのシステムでインテグレーションが開始され、どのシステムで複製元と統合されるのかを把握しておく必要があります。
種別
使用するインテグレーションの種別に着目します。統合が、プレゼンテーション、ビジネスプロセス、データのどのレイヤーで行われるのか判断します。
データ量
システム全体で想定されるデータ量とトランザクション数はどのくらいですか? データ量を検討するときは、データの行数だけでなく、 データサイズも考慮します。処理可能なスループット量を把握する必要があるためです。
タイミング
タイミングも同様に重要です。選択するパターンが左右されるためです。同期タイミングにして、複製元がリアルタイムの応答を待機するようにしますか? それとも、非同期タイミングのように、複製元が要求を開始した後に処理を続行しますか?
このモジュールは、4 つの決定事項を念頭に置いて取り組みます。続いて、時間をかけて次の点を自問します。
- データを移動する必要があるか?
- 参照のみの要件か?
- データをどのくらいの頻度で移動する必要があるか?
- どのオブジェクトを使用するか?
- 1 時間あたりのデータ量とピーク時のデータ量はどのくらいか?
- 予想される合計量はどのくらいか?
複製元と複製先、統合の種別、データ量、タイミングを把握すれば、開発者またはアーキテクトとして今後の進め方を理解しやすくなります。
次のステップ
スケーリングの鍵は、ユーザーよりはるか前にボトルネックを見つけることです。その原因が、API の構成方法、さらにはデータの後処理であることが少なくありません。また、API のパフォーマンスを最大化するための細かな点にも注意を払うことで、カスタマーサクセスに向けて適切な方向に進むことができます。
後続の単元では、将来に向けて組織をスケールする際に影響を及ぼす上記の要素を盛り込んだ 2 つのシナリオを見ていきます。シナリオを読み進める際に重要なことは、ビジネス上の問題に特定の計画を適用する前に、概念を十分に理解しておくことです。
リソース
- Salesforce Developer ドキュメント: データ読み込みに関する一般的なガイドライン
- Salesforce 開発者ドキュメント: Apex 開発者ガイド
- Salesforce Developer ドキュメント: Bulk API 2.0 と Bulk API の概要
- Trailhead: 360 プラットフォーム API の基本