このテキストは、Salesforce の自動翻訳システムを使用して翻訳されました。アンケートに回答して、このコンテンツに関するフィードバックを提供し、次に何を表示するかをお寄せください。

更新スケジュールについては、こちらを参照してください。

信頼性の高いソリューションは、効果的かつ確実に動作します。可用性と一貫したパフォーマンスを備え、成長するビジネスをサポートする拡張性を備えています。

信頼性の高いシステムは、エラーが発生しにくく、期待どおりに動作し、タイムリーに結果を提供します。逆に、信頼性の低いシステムは動作が遅く、期待どおりに動作しないか、重要なタイミングで失敗します。信頼性の低いシステムは、不正確な情報を提供するため、関係者はビジネス上の意思決定でシステムを Trust できません。

システムの信頼性は一定ではありません。現在の信頼性が高いシステムは、成長に合わせて設計されていないと、信頼性が低下する可能性があります。信頼性の低いシステムでは、コストのかかるメンテナンス、リファクタリング、再実装が必要になり、戦略的プロジェクトから資金が回らなくなる場合があります。

可用性、パフォーマンス、拡張性の 3 つの原則に重点を置き、Salesforce ソリューションの信頼性を向上させます。Salesforce のスケーラビリティ製品スイートは、アーキテクトが信頼性の高い実装を運用できるようにするネイティブ機能を提供します。

可用性は、システムが稼働している時間の割合を表します。Salesforce Platform は、ほとんどのインフラストラクチャレベルの可用性の問題に対応します。ただし、プラットフォームで構築し、顧客が経験するソリューションの可用性は、共通の責任です。Salesforce の高可用性があっても、サービスが中断されるリスクがゼロになることはありません。

アーキテクトは、計画メンテナンスや予期しない状況などの Salesforce サービスの中断に備える必要があります。サービスの中断に加えて、ハイ パフォーマンスを維持し、ビジネスの成長に合わせて拡張する方法を検討します。アーキテクチャの選択肢が狭いと、長期的な可用性の問題が発生する可能性があります。

ソリューションを構築する前の設計フェーズで可用性を検討します。可用性に関する設計を先延ばしにするほど、長期的には可用性の問題の実際のコストは高くなります。潜在的なリスクを軽減するには、テスト環境で Salesforce スケールテストを使用します。この環境では、コードを本番にリリースする前に本番の規模でテストできます。

アーキテクトは、ビジネスの言語を使用して、ビジネスの関係者の技術的な懸念をまとめ、賛同を得て可用性作業に優先順位を付けます。潜在的なリスクを軽減するには、テスト環境で Salesforce スケールテストを使用します。この環境では、コードを本番にリリースする前に本番の規模でテストできます。

リスク管理と障害の軽減を通じて、Salesforce ソリューションの可用性を高めることができます。

Salesforce アーキテクチャのコンテキストでリスクを管理するには、システムの動作、ユーザー (従業員、パートナー、顧客など)、およびビジネスプロセスに対する潜在的な危険を特定します。多くの場合、リスク分析を実施する正式なプロセスは、プロジェクトマネージャーの責任になります。アーキテクトは、リスク分析が技術およびビジネスの関係者の懸念を適切に表すようにします。また、本番ピーク時のホットスポットに基づいてスケールテストする必要があるビジネスクリティカルな使用事例を特定することも、ユーザーの責任です。

リスク管理における最大の落とし穴は、十分な時間と思考を割かなかったことにあります。チームは多くの場合、リスク評価をスキップします。または、データの整合性に対するリスクを軽減する重要な部分であるバックアップとリストアの解決と、包括的なリスク評価および軽減を混同します。

Salesforce ソリューションのリスクを評価するには、次の方法を使用します。

  • リスク評価フレームワーク。一部の大企業では、関連するリスクマトリックスがすでに用意されている場合があります。その場合、それらを使用して、危険の分類方法、収集する情報の種類、修復のために配置する必要がある情報などを決定します。まだリスク評価フレームワークがない場合は、信頼できるソースから見つけて使用します。
  • 顧客の視点から影響の重要度とリスクカテゴリを評価します。Proactive Monitoring and Scale Center では、設定可能なアラートとダッシュボードが提供されます。パフォーマンスと拡張性のリスクを継続的に評価し、手動チェックリストへの依存を減らします。Customer Trust と認識は、すべてのビジネスにとって重要です。ビジネスへの影響の観点から見ると、通常、顧客にリーチした問題のリスクは、リーチしなかった問題のリスクよりも大きくなります。顧客は、内部チームと同じようにリスクについて考えたり認識したりしない可能性があります。顧客がアカウントにログインできない場合、おそらく問題の根本原因に関心はありません。彼らは自分の直近の経験に最も関心があります。
  • リスクに優先順位を付けます。理想的なのは、すべてのリスクが確実な緩和および対応計画にリンクされていることです。実際には、時間の経過と共に解決する必要があるギャップがあります。「早期に価値を提供し、反復する」アプローチを採用することが重要です。あなたと配送およびメンテナンスチームは、一度に多くの作業のみを引き受けることができます。Salesforce では、よく「すべてが重要であれば、何も重要ではありません」と表現します。V2MOM を使用して、会社全体、チーム全体、および各個人に至るまで、作業に優先順位を付けて調整します。(V2MOM の詳細は Trailhead で確認できます)。リスク評価を使用すると、最も重要なリスク管理作業に優先順位を付けて取り組むために関係者と連携できます。スケールテスト - テスト計画の作成を使用して、優先度を設定するリスクを特定し、スケールテストを使用してそれらのリスクを軽減します。

Proactive Monitoring を使用して、可用性リスクを早期に検出します。API リクエスト制限の急増、行ロック エラー、同時 Apex 障害などの異常を明らかにし、問題がサービスの中断にエスカレーションする前にアクション可能なインサイトを提供します。

可用性パターンとアンチパターンは、Salesforce ソリューション内のリスク管理が適切かどうかを示します。このパターンを使用して、構築前に設計を検証したり、システムのリファクタリング領域を特定したりします。

リスク管理に関連する Salesforce ツールについての詳細は、「Salesforce Tools For Reliability (信頼性のための Salesforce ツール)」を参照してください。

障害ポイントとは、システムが信頼性を失う脆弱性です。優れた障害軽減とは、すべての潜在的な障害ポイントを特定することではありません。メンテナンスチームとサポートチームが効果的に対応できるように、障害ポイントをすばやく分類して優先順位を付けます。「インシデント応答」を参照してください。

より適切な障害軽減戦略を作成する

  • **人、プロセス、テクノロジーの観点から障害ポイントのトリガーを分類します。**人、プロセス、テクノロジーの観点でリスクを分類するのと同じように、優先度の高い障害ポイントがトリガーされる方法にも同じ考え方を適用します。このアプローチは、潜在的な障害トリガーを特定し、その障害トリガーへの対応策を作成して整理するのに役立ちます。トリガーの分類方法に基づいて、同様の軽減アプローチで一見不一致に見える障害トリガーを軽減できます。
トリガー分類/種別 軽減
人 ポリシー
プロセス プレイブック、継続性計画
テクノロジー 重複
  • 基本、中間、および成熟した緩和の外観を識別します。緩和戦略の構築には時間がかかります。軽減レベルを定義して、すぐに制御できる場所と、経時的な取り組みの焦点を自分とチームが確認できるようにします。可能な限り早い段階で、緩和アプローチで自動化を使用する機会を常に探します。このアプローチが実際にどのようなものかを説明するために、この例では、人指向のトリガーと、ポリシーベースの緩和が基本レベル、中間レベル、成熟レベルでどのようなものかを示しています。
トリガー 軽減 基本 中級 成熟
新規または退職する従業員のユーザーアクセス権の変更 ユーザーをプロビジョニングまたはプロビジョニング解除するためのサービスレベル契約 (SLA) と要件 手動変更の SLA に従って、ユーザーを手動でプロビジョニングおよびプロビジョニング解除します。 スケジュール済み変更の SLA に従って、スケジュール済みジョブでユーザーの変更を処理します。 SSO/IDM ソリューションを使用して、ユーザーのプロビジョニングとプロビジョニング解除を自動化します。

アーキテクチャ プレイブックと継続性計画に加えて、Proactive Monitoring を使用します。Proactive Monitoring では、ログイン失敗、CPU タイムアウト例外、同時 API 要求エラーなどの障害トリガーに対するリアルタイム アラートを設定できます。このアラートのアプローチにより、テクニカル関係者とビジネス関係者の両方に障害の影響を軽減するタイミングを知らせることで、障害の軽減を強化します。

可用性パターンとアンチパターンは、Salesforce ソリューションでの障害軽減の適切さと劣悪さを示します。これを使用して、構築前に設計を検証したり、システム内のリファクタリングする場所を特定したりできます。

障害軽減のための Salesforce ツールについての詳細は、「Tools Relevant to Reliable (信頼性に関連するツール)」を参照してください。

次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。

✨ パターン & アンチパターンエクスプローラーで、使用可能なパターンをさらに確認できます。

パターン アンチパターン
リスク管理 ビジネス:
確立されたリスク評価フレームワークが使用されている。
リスクは、人、プロセス、テクノロジーの領域に分類されます。		 ビジネス:
- Salesforce のリスク評価フレームワークはアドホックです。
リスクが明確ではない。
ドキュメント:
- リスクの重要度は、顧客への影響に基づいて分類および評価されます。
- リスク軽減および対応計画に優先順位を付けます。		 ドキュメント:
- リスクの重要度やカテゴリを評価するときに、顧客の視点は考慮されません。
- リスク軽減および対応計画は、考えられるすべてのリスクを把握しようとします。
障害の軽減 組織内：
- 障害点トリガーとそれに対応する緩和計画は、人、プロセス、テクノロジー別に分類されます。
- 緩和コントロールがすぐに導入され、経時的に成熟し、できるだけ早く自動化が組み込まれます。
- 最適な拡張性を確保するために、変更が本番にリリースされる前に包括的なテストと最適化を完了します。
- ビジネスクリティカルなイベントの前に、SLA に従ってスケールテストと最適化が実行されます。 		組織内：
- 失敗点トリガーは分類されません。緩和方法が存在しないか、その場しのぎでのみ使用されます。
- 緩和措置が再検討または改善されていない。
- 軽減措置では自動化は使用されません。
監視とオブザーバビリティ 組織内：
-チェックと異常検出では、Proactive Monitoring が有効になっています。
-継続的な可視性のために、Proactive MonitoringアラートはScale Centerと統合されています。 		組織内：
- 状態チェックは手動でのみ実行され、継続的な監視は行われません。

システムアーキテクチャのパフォーマンスは、システムの処理量 (スループット) と応答速度 (レイテンシ) の指標です。通常、本番環境でのテストと監視を通じてシステムのパフォーマンスを把握します。

パフォーマンスの高いシステムは、予測されるすべての需要レベルでタイムリーにプロセスを完了します。

パフォーマンスが低いと、レイテンシーやスループットが低下し、生産性が低下してユーザーのストレスが高まります。パフォーマンスの問題の解決は急務です。これは、顧客の Trust が失われ、財務上の損失が生じる可能性があるためです。

スループットと遅延を最適化することで、ソリューションのパフォーマンスを向上させることができます。

注意:スループットと遅延の最適化は、システムの処理と応答性の向上に不可欠な側面です。ただし、全体的なシステム パフォーマンスは、拡張性を考慮した設計の程度にも左右されることに注意してください。設計では両方のディメンションを考慮する必要があります。

Salesforce アーキテクチャのコンテキストでは、スループットとは、システムが特定の時間内に完了できる同時要求の数です。スループットを考慮して設計および最適化されたお客様の Salesforce ソリューションは、Salesforce Platform に組み込まれたLEGATO の制限内で適切に動作します。

Salesforce のスループットを最適化するには、まずシステムの作業負荷を正確に計算し、その増加を計画します。システムに対して行われる要求の正確な予測がなければ、システムのスループット機能で潜在的な問題を特定できません。

ワークロードについて考えるときは、次の 3 つのディメンションを考慮してください。

  • 特定の時間内にシステムで処理する必要のあるトランザクション数
  • システムに同時にアクセスする必要があるユーザーの数
  • システムのトランザクションロジックの全体的な複雑さ

パフォーマンスについて考える場合、チームはコンピューティングと最大 CPU 時間の制約に焦点を絞りすぎることがあります。これはプラットフォームのガバナ制限です。CPU 時間に焦点を絞ったチームは、スループットを最適化する他の方法を見落とします。対象を拡大してこれらの方法を適用すると、Salesforce アーキテクチャの全体的なスループットと効率が向上します。これらの改善により、遅延が短縮され、システム全体のパフォーマンスが向上します。ApexGuru は、ループ内の SOQL、ループ内の DML、非効率的な GGD コール、コストのかかるメソッドなど、スループット制限アンチパターンを積極的に検出します。これらのインサイトは、チームがスループットの上限となるガバナ制限のリスクを排除するのに役立ちます。

システムのスループットを最適化する

  • 非同期処理を推奨。Salesforce Platform では、トランザクションコンテキストを使用してデータの整合性を制御し、暴走コードを制限します。「アーキテクチャの基本」の「アーキテクチャの基本」の「トランザクション」を参照してください。このため、可能な場合は非同期 (async) 処理を使用することで、同期実行コンテキストの潜在的なボトルネックを最小限に抑えることができます。「データ処理」を参照してください。非同期コンピューティングの使用は、あらゆる種類のパフォーマンスの問題を解決できるわけではなく、非同期プロセスを組み込むときには遅延を考慮する必要があります。キュー可能 Apex などの特定のプラットフォーム機能では、キューでのメッセージの待機時間が長くなるため、トラフィック急増時に遅延が増加する可能性があります。使用事例によっては、スループットを維持または改善するために、応答性の低下を許容する必要がある場合があります。場合によっては、遅延の増加を許容できないと判断できます。スケールテストでは、Full Sandbox でトラフィックの急増をシミュレーションすることで、これらのトレードオフを検証できます。そこで、ジョブがスループットと遅延にどのように影響するかを測定できます。
  • 常に一括処理を使用します。一括処理の概要は、コレクションに対して操作を実行することを意味します。多くの場合、Salesforce ソリューションの一括処理について話し合うチームは、コレクションに対するデータ操作の合理化に焦点を当てています。「運用ロジック」を参照してください。ただし、システムレベルでの一括処理には、データ操作以外にも関連があります。また、コールアウトや複雑な計算などの特定のタスクを一括処理の候補にすることを検討します。適切な一括処理により、オーバーヘッドが軽減されます。操作ごとに 1 つの要求ではなく、1 つの要求で複数の操作を実行します。ApexGuru では、DML や SOQL などの膨張防止パターンがループ内に表示され、本番に拡張する前に修正できます。「Bulk Operations」を参照してください。
  • **検索に SOSL を使用し、SOQL をデータ操作のように扱います。**複雑すぎる SOQL ステートメントを使用すると、システムがレコードを取得する時間が長くなることは明白に思えるかもしれません。SOQL は、基礎となるリレーショナル データベースにオーバーヘッドを追加し、処理速度を低下させます。テキスト条件またはワイルドカード条件を使用する場合、SOSL のパフォーマンスが高くなります。SOSL は、全文検索用インデックスとユニバーサル検索用に最適化されたプラットフォームの検索エンジンを使用します。レコード取得パターンを最適化するには、設計標準で SOSL を使用してシステム内のデータを検索するタイミングが指定されていることを確認してください。また、効率的なデータ操作のために SOQL の使用方法を指定していることを確認します。「運用ロジック」を参照)。
  • プラットフォームキャッシュと Apexgur。Lightning Platform Cacheレイヤーにより、Salesforce セッションおよび組織のデータをキャッシュするときのパフォーマンスと信頼性が向上します。プラットフォームキャッシュは、キャッシュスペースを分散することでパフォーマンスを向上させ、一部のアプリケーションや操作が他のアプリケーションや操作から容量を奪うことを防ぎます。ApexGuru は、繰り返されるクエリ (Platform Cache for SOQL 結果など) をキャッシュする機会の欠落を検出し、大規模な環境でのスループットを向上させます。

パフォーマンスのパターンとアンチパターンは、Salesforce 組織でのスループットの適切と劣悪を示します。これらを使用して、構築前に設計を検証したり、さらなる最適化の機会を特定したりできます。

スループットを最適化するための Salesforce ツールについての詳細は、「Salesforce Tools For Reliability (信頼性のための Salesforce ツール)」を参照してください。

レイテンシは、システムが実行パスを完了する速度の指標です。システムのスループットを最適化すると、遅延の改善に寄与します。レイテンシのもう 1 つのディメンションは、知覚されるパフォーマンス、つまりユーザーが感じるシステムの応答性です。

ユーザーは、ページの読み込みやプロセスの終了を待ちたくありません。リストビュー、レコードページ、レポートなどを操作するときに読み込み時間が頻繁に長くなると、システムのユーザーはストレスを感じるでしょう。この場合、顧客やパートナーは、パフォーマンスの低いシステムに対処するのではなく、他の場所にビジネスを移すことができます。内部では、従業員が設計どおりにシステムを使用しないように回避策を作成することがあります。これにより、セキュリティとデータの整合性の下流で問題が発生する可能性があります。

知覚されるパフォーマンスは診断が難しい場合があります。ユーザーからパフォーマンスの低下が報告されると、サポートチームは問題を再現できない可能性があります。遅延の増加は、多くの場合、小さな問題が積み重なって発生するため、知覚されるパフォーマンスの問題の正確な原因を診断することが困難になる可能性があります。

Salesforce システムで遅延を減らし、応答性を改善する

  • レポートを最適化します。各レポートが 1 つの特定の目的を果たすようにします。システムのすべてのレポートの対象ユーザーと目的を明確に特定します。レポートには、利用者メンバーが意思決定を行うために必要な最小限のデータのみを含めます。レポートの目的と一致しない列を削除すると、取得および表示する必要があるデータの量が減るため、レポートのパフォーマンスが向上します。
  • フィルタを最適化します。有効な検索条件を使用すると、データベースから取得される行数の範囲を正確に設定できるため、レポートおよびリストビューのパフォーマンスが向上します。原則として、検索条件ロジックを具体的にすればするほど、データに対する基礎となるクエリの効率が向上します。検索条件を最適化する方法は次のとおりです。
    • 「次の文字列を含む」および「次の文字列を含まない」の代わりに「次の文字列と等しい」および「次の文字列と等しくない」を使用
    • 数式項目による絞り込みの回避
  • 共有モデルを簡素化します。共有モデルが複雑すぎると、ユーザーが表示または処理するデータにアクセスできるかどうかを判断するために共有および表示モデルを確認する必要があるため、さまざまなプロセスが遅くなる可能性があります。複雑な共有の計算では、ユーザーのコンテキストで実行されるレポート、リストビュー、自動化の遅延が増加する可能性があります。「共有と表示」を参照してください。
  • カスタム UI コンポーネントを最適化。カスタムのユーザーインターフェース (UI) コンポーネントを使用すると、遅延が増加する可能性があります。カスタム UI コンポーネントのパフォーマンスを最適化するには、次のことを検討してください。
    • Lightning Web コンポーネント (LWC)。LWC フレームワークは、最新の Web 標準に密接に対応しています。LWC で記述されたカスタムコンポーネントは Web ブラウザーでより効率的に表示され、開発者はよりパフォーマンスの高い JavaScript メソッドを使用できます。Aura や Visualforce などの古い UI テクノロジーではなく、LWC を使用することを常に目指してください。
    • Lightning データ サービス。Lightning Data Service は、コンポーネント間の安全でパフォーマンスの高い共有キャッシュの作成とメンテナンスを処理します。これを使用して、データのためにサーバーを不必要に往復することを回避し、全体的なアプリケーションの応答性を向上させます。
    • **リストデータのクライアント側の並び替えと絞り込み。**LWC (推奨) コンポーネントと Aura コンポーネント (それ以外の場合) の両方で、開発者は標準の JavaScript 配列機能を使用してクライアント側で値の並び替え、絞り込み、選択を行い、サーバーへの移動回数を減らすことができます。

パターンとアンチパターンは、Salesforce 組織での適切な遅延と低い遅延を示します。これらを使用して、構築前に設計を検証したり、さらなる最適化の機会を特定したりできます。

レイテンシ最適化のための Salesforce ツールについての詳細は、「Salesforce Tools For Reliability(信頼性のための Salesforce ツール)」を参照してください。

次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。

✨ パターン & アンチパターンエクスプローラーでパフォーマンスに関するより多くのパターンを検出します。

パターン アンチパターン
スループット 設計基準では、次のようになります。
- プラットフォームキャッシュの使用方法に関するガイダンスは、プラットフォームキャッシュベストプラクティスに準拠しています。 		設計基準では、次のようになります。
- プラットフォームキャッシュの利用状況に関する指針がある場合、明確ではない、またはベストプラクティスに準拠していない。
組織内：
- 一括処理は、データとシステム操作に使用されます。
- DML またはデータベースメソッドは、常に Apex のコレクションに対して動作します。
- DML 中にデータベースで経過時間が短くなるために使用する項目が制限されます。
- SOSL ではすべてのワイルドカード条件が使用されます。
- SOQL ステートメントは選択的です。
-- LIKE 比較や部分テキスト比較は使用しません。
-- 比較演算子では、主ロジックまたは唯一のロジックとして肯定的なロジック (つまり INCLUDES または IN) が使用されます。
--= NULL と != NULL が使用されるのは、常に肯定的な比較演算子の後にある場合のみです。
– データ負荷を最小限に抑えてパフォーマンスを最大化するために、SOQL クエリで必要な項目のみが取得されます。
-- LIMIT 1 ステートメントは使用されません。
-- ALL ROWS キーワードは使用されません。
- 可能な場合は非同期処理が優先されます。
プラットフォームキャッシュパーティションが設定されている。 		組織内：
- DML ステートメントは一括処理されません。
- Apex の 1 つのレコードに対して DML またはデータベースメソッドが動作します。
- SOSL がワイルドカード選択条件で使用されることはほとんどありません。
- SOQL ステートメントは非選択的です。
-- LIKE およびワイルドカード検索条件が含まれます。
-- !=、NOT、または NOT IN 条件を使用した比較は、主または唯一の比較演算子として使用されます。
-- = NULL 条件と != NULL 条件を主または唯一の比較演算子として使用します。
-- LIMIT 1 ステートメントが使用されます。
-- ALL ROWS キーワードが使用されます。
- SOQL がループ内に表示されます。
- 同期プロセスが好まれます。
遅延 組織内：
- レポートは 1 つの特定の目的を果たし、意思決定に必要な最小限の行数と列数が含まれます。
-検索条件で「次の文字列と一致する」と「次の文字列と一致しない」が使用されている。
- 検索条件に数式項目が含まれていない。
・共有モデルは可能な限り簡略化。
カスタムUIコンポーネントでは、LWC(Lightning Webコンポーネント)を使用します。
- LWC はデータ操作に Lightning Data Service を使用します。
- リストデータの並び替えと絞り込みは、JavaScript でクライアント側で処理されます。
- Salesforce Edge が有効になっている。 		組織内：
- レポートには複数の目的がある場合や、意思決定に不要な行や列が含まれている場合があります。
-検索条件で「含む」と「含まない」が使用されている。
- 検索条件には数式項目が含まれます。
共有モデルは複雑です。
-カスタムUIコンポーネントではフレームワークが使用されているため、LWCよりもレンダリング効率が低い場合があります(AuraやVisualforceなど)。
- LWC はデータ操作に Apex を使用します。
- リストデータの並び替えと絞り込みは、Apex を使用してサーバー側で処理されます。
- Salesforce Edge が有効になっていない。

拡張性とは、システムが進化および成長しても一貫して実行できる機能です。拡張性の高いシステムでは、トランザクション量や同時アクセスの大幅な増加を、根本的な変更なしで処理できます。Salesforce のプラットフォームサービスは、アプリケーションの拡張性をサポートするように設計されています。「内部プラットフォーム処理」を参照してください。そうは言っても、組織が成長し、製品やサービスの需要が増加すると、効果的かつ期待どおりに機能するシステムを作成する責任があります。最初から拡張性を考慮して設計することで、新しい機能をより迅速に提供し、ユーザートラフィックが増加してもサービスの中断を減らすことができます。新機能を本番にリリースする前の設計フェーズの早い段階で、スケールテストを使用して予測されるワークロードをシミュレーションし、アーキテクチャがそれらをサポートするために拡張できることを確認します。

拡張性を重視して設計されていないシステムでは、トラブルシューティング、再設計、リファクタリングに絶えずコストがかかります。拡張性の問題は時間と共に複雑になり、システム全体のパフォーマンスが低下します。ビジネスによっては、開発およびメンテナンスリソースの大半を、価値を生み出す新機能ではなく拡張性の問題への対応に費やしている場合があります。

ビジネスが臨界点に達することがあります。システムの元の設計ではビジネスの成長に対応できず、予期しないイベントによってシステムが不安定になります。Scale Centerからのインサイトを使用して、拡張性の転換点を早期に特定します。Scale Center では、例外のホットスポット、実行時間の長いトランザクション、経時的に悪化するキューのボトルネックが表示されます。

データモデルの最適化とデータ量管理に焦点を当てることで、拡張性を備えた設計が可能になります。

注:ここでは説明しませんが、拡張性のテストは、アプリケーションアーキテクチャの検証に不可欠です。指針については、「テスト戦略」を参照してください。

データモデリングでは、組織内のオブジェクトを構造化し、ユーザーと自動化プロセスが必要なデータをできるだけ早く取得できるように相互に関連付けます。スループットを向上する手段を講じることで多くのパフォーマンス問題に対処できますが、最適化されたデータモデルがなければ、取り組みの効果は高まりません。

不適切に設計されたデータモデルの悪影響はすぐには現れません。データ量、プロセス、ユーザー、インテグレーションの面でシステムが大きくなるにつれて、その弱点が露呈します。適切に設計されたデータモデルを使用すると、要件の追加や拡張に応じてアプリケーションを継続的にリファクタリングしやすくなります。ApexGuruは、非選択的な SOQL、未使用のフィールド、スキーマの非効率性など、データモデルの拡張性に直接影響するデータアクセスのアンチパターンを明らかにします。

データモデルを最適化する

  • Salesforce の事前作成済みデータモデル。Salesforce では、営業、サービス、さまざまな業種向けに事前作成済みデータモデルを提供しています。Salesforce が提供するデータモデルを使用することで、システムの機能が 1 回のみ定義され、冗長性とサイロ化が解消され、システム全体の情報源が一元化されます。この 1 つのソースでは Salesforce の事前作成済みデータモデルを使用していたため、分析を使用してアプリケーションデータを理解し、Salesforce の事前作成済み人工知能サービスを使用する方が簡単です。また、サポートする必要があるカスタマイズを減らすことで、メンテナンスコストと技術的負債を削減できます。
  • 適切なデータ型。Salesforce でサポートされるさまざまな項目の種別とその制限について説明します。レポートと暗号化の要件を考慮して、将来、種別間でデータを変換する必要がないようにします。
  • 適切なリレーション。Salesforce では、オブジェクト間の主従関係と参照関係の 2 種類がサポートされています。主従関係には 2 つの主な利点があります。1 つは、子レコードの詳細を数えて集計する組み込みの積み上げ集計機能です。もう 1 つは組み込みのカスケード削除機能で、親レコードを削除すると、子レコードも削除されます。ただし、主従関係の使用を決定する前に、主従関係の共有とデータスキューの影響を理解していることを確認してください。
  • **スケールに合わせて非正規化します。**正規化とは、データの冗長性を減らしてデータの整合性を向上させるためにデータモデルを構造化するプロセスです。残念ながら、正規化によってスケーリングの問題が発生することがあります。非正規化されたテーブルは規模に応じてパフォーマンスが向上しますが、データの整合性と冗長性を考慮してください。

パターンとアンチパターンは、Salesforce 組織でのデータモデルの最適化の適切さと劣悪さを示します。これらを使用して、構築前に設計を検証したり、さらなる最適化の機会を特定したりできます。

データモデル最適化用の Salesforce ツールについての詳細は、「Salesforce Tools For Reliability (信頼性のための Salesforce ツール)」を参照してください。

データ量は、レコード件数とサイズに基づく、システム内に保存されているデータ量の指標です。組織に数万人のユーザー、数千万件のレコード、または合計数百ギガバイトのレコードストレージがある場合、データ量が多くなります。組織のデータ量とオブジェクト間のリレーションは拡張性に影響し、レコード数のみよりも拡張性に大きく影響する可能性があります。

データ量が多い組織の拡張性を向上させる

  • 子レコードを配布します。親に多数の子レコードが含まれないようにすることで、親子データの歪みを回避します。一般的な推奨事項は、親レコードが 10,000 件を超えないようにすることです。たとえば、取引先責任者が多数あり、取引先を使用しないリリースでは、複数の取引先レコードを設定し、関連する取引先責任者レコードをそれらの取引先責任者レコードに分散することを検討します。
  • レコードの所有権を分配する。1 人のユーザーまたはキューが 10,000 件を超える同じオブジェクトのレコードを所有しないようにしたり、1 つのロールまたは公開グループのすべてのメンバーがそのレコードを所有しないようにしたりすることで、所有権の偏りを回避します。「ダミーユーザー」によるデータの「保留」は、所有権の偏見につながることがよくあります。この問題が発生した場合は、共有計算への影響に注意してください。所有権のスキューを解消するためにレコードを再配布できない場合は、データ所有者ユーザーをロールに割り当てないようにします。組織の共有モデルでロールの割り当てが必要な場合は、データ所有者のユーザーを共有階層の最上位の個別のロールに配置します。変更を行うと、共有の再適用によってパフォーマンスに大きな影響を与えるため、そのユーザーのロールで頻繁に変更したり、予定外の変更を行ったりしないでください。共有ルールで参照される可能性のある公開グループからユーザーを除外します。
  • Salesforce のレコードデータ量を削減します。Salesforce は、企業が顧客を 1 つのビューで表示できるように設計されています。Salesforce でデータを制限することがベストプラクティスであることは直観に反すると思われるかもしれません。ただし、単一ビューの威力は、ビジネスユーザーが顧客データをどの程度理解してアクションを実行できるかにあります。データ量が増加するにつれて、最新ではないデータや、日常的なプロセスや分析に関連しないデータによって、いくつかの問題が発生します。これらの問題には、アプリケーションのパフォーマンスの低下、データセキュリティリスクの増大、検索、レポート、分析への悪影響などがあります。この問題を回避するには、データモデルのすべてのオブジェクトのデータライフサイクルを定義し、古くなり、即座にビジネス上の価値が失われた場合のデータのタイムラインと分類を設定します。データライフサイクルに従って、次の手順を実装し、経時的なデータを管理します。
    • データアーカイブおよび消去 - データ量をできるだけ少なくするには、ビジネスで不要なレコードを削除してデータ量をできるだけ少なくします。Bulk API 2.0 の物理削除機能を使用して、大量のデータを削除します。
    • データ集計 - 主要な履歴トレンドやサマリー データをレポートと互換性のある形式で集計する集計カスタム オブジェクトを作成します。バッチ Apex を使用してカスタムオブジェクトに入力します。その後、ユーザーは集計されたオブジェクトレコードに基づいてレポートを実行できます。
    • データ階層化。Salesforce レポートや日常業務で不要な大規模なデータセットは、別のアプリケーションで管理します。必要に応じて、マッシュアップ、コールアウト、外部オブジェクトを使用して Salesforce でデータを使用できるようにします。

実際には、問題が発生したときに拡張性の問題の根本原因にすぐに対処できるとは限りません。このため、Salesforce には当面の課題を軽減するオプションが用意されています。大量のデータを処理するには、組織でこれらの機能を有効にすることが現実的で長期的なアーキテクチャ戦略ではないことを知っておくことが重要です。これらの短期的なその場しのぎの回避策は、不十分なデータアーキテクチャに悩まされているシステムの遅延を減らすのに役立ちますが、組織に技術的な負債を追加する可能性もあります。

規模の問題の短期的な回避策は次のとおりです。

  • カスタムインデックスインデックスは、プラットフォームのクエリオプティマイザーがデータアクセス操作を高速化するために使用する特殊な内部テーブルに保存されます。「マルチテナントインデックス」を参照)。プラットフォームでは、デフォルトで特定の種別の項目に自動的にインデックスが付けられます。パフォーマンスの低いクエリを高速化するには、Salesforce カスタマーサポートに連絡して追加のカスタムインデックスを要求できます。クエリプランツールを使用して、カスタムインデックスによってクエリのパフォーマンスが向上するかどうかを判断します。
  • Skinny テーブル。100 万件を超えるレコードがあるオブジェクトの一般的な項目セットのクエリをさらに最適化する必要がある場合は、スキニーテーブルが役立ちます。Skinny テーブルでは、レポートまたはオートメーションで同じオブジェクトのカスタム項目と標準項目を使用する場合に発生するバックグラウンド結合が排除されます。スキニーテーブルを使用するには、Salesforce カスタマーサポートが組織でスキニーテーブルを有効にする必要があります。

拡張性に関するパターンとアンチパターンは、Salesforce 組織でのデータボリューム管理の適切さと劣悪さを示します。これらを使用して、構築前に設計を検証したり、さらなる最適化の機会を特定したりできます。

データ量を管理するための Salesforce ツールについての詳細は、「Salesforce Tools For Reliability (信頼性のための Salesforce ツール)」を参照してください。

組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンの選択内容が表示されます。

✨ パターン & アンチパターンエクスプローラーで拡張性に関するより多くのパターンを見つけます。

パターン アンチパターン
データモデリング 設計基準では、次のようになります。
- カスタムオブジェクトが存在することをビジネス上の正当性が保証する基準と指針。 		設計基準では、次のようになります。
- カスタムオブジェクトを作成するための標準はありません。
データモデルの場合:
可能な場合は標準オブジェクトが使用されます。
- ApexGuru によるアンチパターンチェックにより、SOQL クエリが選択され、スキーマの非効率的な使用が回避されることを確認します。
- テーブルはスケールに対して非正規化されます。 		データモデルの場合:
- 複製された標準オブジェクトがある。
- テーブルは冗長性を避けるために正規化されます。
ビジネス内：
- ローコードビルダーは、Salesforce でサポートされるさまざまなデータ型を理解し、レポートと暗号化の要件を評価してから、データ型を選択します。
- オブジェクト間の主従関係を確立する前に、その関係の共有とデータスキューの影響を評価します。 		ビジネス内：
- ローコードビルダーは、下流のレポートと暗号化の要件を評価することなくデータ型を選択します。
- オブジェクト間の主従関係を確立することを決定する前に、その関係の共有とデータスキューの影響を評価しません。
データ量 データ内：
10,000 件を超える子レコードを持つ親レコードはありません。
- 10,000 件を超える同じオブジェクト種別のレコードにユーザーが割り当てられていない。
- 同じレコードを参照する参照項目を持つ 10,000 件を超えるレコードが含まれるインスタンスはありません。
- 一括データ読み込みは、ParentId 項目値に従ってバッチに並び替えられます。
-バッチ戦略が同時実行で破綻しないように、スケールテストを使用して本番規模で一括読み込みパターンを検証します。
- 本番へのデータの一括読み込みは、ピーク営業時間中に行われません。
- 一括データ読み込みには、ビジネス上の意思決定に必要な最小限のデータのみが含まれます。 		データ内：
10,000 件を超える子レコードが存在する。
- ユーザーが同じ種別の 10,000 件を超えるレコードに割り当てられている。
10,000 件を超えるレコードに同じレコードを参照する参照項目があるインスタンスが存在する。
- 一括データ読み込みは、ParentId 項目値に従ってバッチに並び替えられません。
- 本番環境へのデータの一括読み込みは、営業時間のピーク時に行われます。
- 一括データの読み込みは、ビジネス上の意思決定に必要な最小限のデータに制限されません。
フローおよび Apex の場合 ―
- データの歪みが問題になるシナリオで、子レコードの数を複数の親レコードに分散するロジックが存在します。
-インテグレーションを使用してレコードをインポートまたは複製すると、ロジックによって適切なユーザーに割り当てられます。
- Apex コレクション (リストやセットなど) の場合、クエリを最小限に抑えてデータ処理を最適化するために複数のレコードを処理するロジックが存在します。
- 拡張性の高いコードの標準とベスト プラクティスに準拠する効率的なApexコードが記述され、リリースされます。 		フローおよび Apex の場合 ―
- 子レコードは、すでに割り当てられている子レコードの数に関係なく、親レコードに任意に割り当てられます。
データ読み込みまたはインテグレーションで作成されたレコードは、一般的な「インテグレーションユーザー」に割り当てられます。
- 同じオブジェクトからの複数の再帰的な SOQL クエリが同期トランザクションにあり、ヒープ使用量が多い。
-開発者がApexコードを作成すると、非効率性とパフォーマンスのアンチパターンが発生します。
ビジネス内：
- データのアーカイブおよび消去戦略を文書化して実装している 		ビジネス内：
-データアーカイブおよび消去戦略がないか、戦略が文書化されているが実装されていない
ツール説明可用性Performance拡張性
Big Object プラットフォームで大量のデータを保存および管理します。 X
コードスキャナー Apex コードをスキャンしてパフォーマンスの問題がないか確認します。 X
カスタムインデックス カスタムインデックスを使用してクエリのパフォーマンスを向上させます。 X
データの削除 不要なデータを削除してパフォーマンスを向上させます。 X X
ディビジョン データをパーティション分割して、クエリとレポートのレコード数を制限します。 X
スケールテスト システムのパフォーマンスをテストし、結果を解釈します。本番にリリースする前に、拡張性とパフォーマンスを検証するために、Playwright または JMeter スクリプトを使用して大規模な UI および API ワークロードをシミュレーションします。 X X
Scale Center システムパフォーマンスに関するセルフサービスとリアルタイムのインサイトを取得します。実行時間の長いトランザクション、例外のホットスポット、スループットのボトルネックを見つけます。開発サイクルの早い段階で拡張性の問題を診断します。 X X
ApexGuru Scale CenterのこのGenAIベースの機能を使用して、実行時にApex、SOQL、テスト クラスのアンチパターンを検出します。ApexGuru と Salesforce Code Analyzer のインテグレーションにより、開発ワークフローで AI を駆使したおすすめとインライン修正を利用できます。これらの推奨事項と修正を使用して、ホットスポットを解決し、クエリの選択性、一括処理、キャッシュ使用量、テスト品質を向上させます。 X X
Salesforce Code Analyzer IDE、CLI、または CI/CD を使用してコードをスキャンし、ベストプラクティスに準拠していることを確認します。Salesforce Code Analyzer と ApexGuru の統合により、開発者ワークフローでパフォーマンスのアンチパターンに関するインサイトを直接取得できます。 X
Salesforce Edge ネットワーク Salesforce Edgeネットワークを介して[私のドメイン]をルーティングすることで、ダウンロード時間とユーザーエクスペリエンスを改善します。 X
スキニーテーブル 頻繁に使用する項目があるテーブルでの結合は避けてください。 X
プロアクティブな監視 レコードの増加、所有権のスキュー、パフォーマンスの低下の異常を継続的に監視します。重大になる前に、規模に関するアラートを表示します。 X X
リソース説明可用性Performance拡張性
拡張性の課題 - ビジネスを将来にわたって維持する方法 拡張性の実装が、持続可能な成長と長期的な成功にどのようにつながるかを説明します。 X X
Scale Center を使用したスケーラブルなアプリケーションの構築とリリース Salesforce 実装のパフォーマンスの問題を積極的に評価して解決する方法について説明します。
複雑なSalesforceアプリケーションでのパフォーマンスの分析とホットスポットの拡張 組織のパフォーマンスと拡張性の問題に対処します。 X X
ラッシュ時のトラフィックでアプリケーションがパニックになるべきではない - 準備方法 スケールテストを成功させるための 4 つの主要なステップについて説明します。
ApexGuru AIエンジンの説明 ApexGuru がカスタムトレーニングされたモデル、実際の組織のテレメトリ、インテリジェントなフィルタリングを使用して、正確でコンテキストに沿ったアクション可能なインサイトを提供する方法について説明します。 X X
ApexGuruを使用したアプリケーションおよびAgentforce向けApexの最適化 SOQL、DML、デバッグ、非効率性のテストなど、ApexGuruが開発者のパフォーマンス アンチパターンの検出と修正にどのように役立つかについて説明します。また、ApexGuruを、アプリケーションの拡張性の高い開発とAgentforceの実装のためのAI搭載コーチとして使用します。 X X
ApexGuru Antipatterns Salesforce のメジャーリリースのたびに更新される ApexGuru で検出されたアンチパターンの公式ライブラリについて説明します。 X X
大量のデータを使用するリリースのベストプラクティス 大量のデータのプロセスへの影響を理解します。 X
Salesforce Edge ネットワークに関する考慮事項 Salesforce Edge ネットワークを使用するために組織を準備する方法を確認します。 X
設計標準テンプレート 組織の設計標準を作成します。 X X X
データモデル設計に関する考慮事項 拡張性とメンテナンスのためにデータモデルを最適化します。 X X
企業の規模に応じたレコードアクセス権の作成 設定によってアクセス制御のパフォーマンスを最適化します。 X
大量のデータを処理するシステムのインフラストラクチャ 大量のデータを使用するリリースのシステムパフォーマンスをサポートする機能について説明します。 X
一括管理の学習リソース 一括管理について説明します。 X X
Lightning Experience パフォーマンスの最適化 組織のLightning Experienceを改善して、ユーザーの作業時間を短縮します。 X
Salesforce でのルックアップスキューの管理によるレコードロック例外の回避 ルックアップスキューの影響を最小限に抑える方法を理解します。 X X
SOQL および SOSL のベストプラクティス 大量のデータを使用するリリースの場合は、SOQL および SOSL のベストプラクティスに従ってください。 X X
大規模な再配置のためのツール 再配置を効果的に計画および実行します。 X
マッシュアップの使用 大きなデータセットを別のアプリケーションで管理します。 X X

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくためのアンケートにご協力ください。また、今後の展望についてもお聞かせください。