信頼性

Salesforce は、自動フェールオーバーとインフラストラクチャレベルの耐障害性により、複数の地域で耐障害性の高いインフラストラクチャを運用します。このプラットフォームは、データセンターの冗長性、ネットワークの可用性、インフラストラクチャのパッチ適用を処理します。プラットフォームの可用性状況は Trust.salesforce.com でリアルタイムに確認できます。

ガバナ制限内で拡張するデータモデル、障害を予測して復旧するトランザクション、ソリューションの可用性目標からの逸脱を検出する監視、障害発生時に業務を復元するディザスターリカバリー手順など、このインフラストラクチャで実行されるすべてのものの信頼性を設計します。

Salesforce SLA はプラットフォームを対象としますが、インフラストラクチャレイヤーより上位のすべてに対する信頼性は各自で管理します。ビジネスに必要な信頼性目標である独自のサービスレベル目標 (SLO) を定義して達成する責任があります。プラットフォームの SLA 階層に関係なく、アプリケーション層の信頼性は各自の責任です。可用性を保証する同じプラットフォームでも制限があります。ガバナ制限では、1 つのテナントが他のテナントのプラットフォームを劣化させることがないように、各テナントのリソース消費量を制限します。したがって、ソリューションは、単に容量の追加を要求するのではなく、これらの制限の範囲内で適切に拡張する必要があります。

ソリューションの信頼性が低いと、ビジネスに連鎖的な影響が生じる可能性があります。コマースプラットフォームが使用できないと、収益フローが遅くなります。ワークフローの途中で内部ツールが失敗すると、生産性が低下します。Trust は、データが破損したり、レコードが失われたりすると失われます。これらの問題は、回避策が蓄積され、技術的な負債が膨らむにつれて、時間の経過とともに複雑になります。

信頼性とは、すべての失敗を防ぐことではありません。障害は分散システムで発生します。信頼性とは、障害を予測し、爆発半径を抑え、サービスを自動的に復元するシステムを設計することです。信頼性要件は、ビジネスへの影響によって異なります。たとえば、99.9% の可用性を必要とする顧客向け Experience Cloud ポータルでは、時折の遅延を許容する内部一括報告プロセスとは根本的にアーキテクチャの選択肢が異なります。

信頼性とオペレーショナル エクセレンスは密接に結びついています。アドレス監視、インシデント対応、システム可用性の両方。この重複は意図的なものであり、偶然ではありません。違いは*、設計時と実行時*にあります。

信頼性とは、実行前にシステムに組み込むものです。これには次のものが含まれます。

• ガバナ制限内で拡張する前述のデータモデル
• 障害を予測して復旧するトランザクション
• ブラスト半径を含む冗長性と回路ブレーカー
• 障害発生時のシステムの動作を決定する目標 (目標復旧時間 (RTO) と目標復旧時点 (RPO))。

信頼性は、ソリューションの構造的な特性です。

Operational Excellence は、実行後にシステムを運用、改善、維持する方法です。これには以下が含まれます。

• 変更リスクを軽減する導入方法
• インシデント発生時にチームを誘導するランブックとエスカレーションパス
• シグナルを表面化する観測可能性パイプライン
• 経時的にシステムを改善するフィードバックループ。

Operational Excellence を実践するのは、ソリューションを取り巻く人間とプロセスの規律です。

2 つの柱の共通基盤は監視および観測可能性レイヤーです。監視は、信頼性の問題として設計されています。観測可能なシステムを構築する必要があります。これは、オペレーショナルエクセレンスの懸念事項として実践されています。チームは、これらのシステムからの指示に基づいて行動します。信頼性は、アラートしきい値や状態ダッシュボードなど、組み込みのアーキテクチャパターンを対象とします。Operational Excellence では、ランブックやオンコール応答などのシグナルにチームが応答する方法がカバーされます。

「このシステムは存続しますか?」という信頼性の違いを考慮してください。Operational Excellence は「チームは運用できますか?」に対応します。ランブック、一貫したリリース、フィードバックループのないチームによって運営される完全に信頼性の高いシステムは、実際には失敗する可能性があります。脆弱で設計が不十分なシステムを管理する優れた運用チームは、防止できないインシデントに圧倒されます。両方の柱が必要であり、どちらも他方の柱の代わりにはなりません。

信頼性は単独では機能しません。前のセクションで説明したように、Operational Excellence は最も近いパートナーです。この 2 つの柱は可観測性レイヤーを共有しており、信頼性はシステムに組み込む内容を定義し、オペレーショナルエクセレンスはチームの運用方法を定義します。Trustには、攻撃に耐え、データの整合性を維持するインフラストラクチャも必要です。つまり、システムが侵害される可能性がある場合、そのシステムは信頼性を失います。リソースの最適化により、ガバナ制限の枯渇が回避され、プラットフォームの信頼性が大規模でも維持されます。コストの最適化では、信頼性への投資とビジネス価値のバランスを取ります。可用性目標は、その達成に必要なアーキテクチャの複雑さを正当化します。1本の柱が単独で適切に設計されたソリューションを生み出すことはありません。信頼性は、他の柱に依存して補強する構造的基盤となります。

次の原則を使用して、プラットフォームの信頼性に関するアーキテクチャ上の意思決定をガイドします。

• **一括処理によって作業負荷を分散します。**レコード単位の連続操作に依存するのではなく、1 つのトランザクションで複数のレコードを処理します。一括処理では、1 つのトランザクションで処理されるバッチ間でガバナ制限が共有され、スループットが最大化されます。コレクション・ベースのApex処理、範囲が構成可能な一括処理ジョブ、一括消費されるプラットフォーム・イベントはすべて、この原則を体現しています。適切に一括化されたソリューションでは、順次処理で同じ数の SOQL および DML ステートメントを含む 200 件のレコードを 1 件のレコードとして処理します。分散ワークロードパターンでは、1 つのレコード障害がバッチ全体の処理に影響しないため、復元力が提供されます。
• **すべて失敗したとします。**ガバナ制限、プラットフォームメンテナンス期間、インテグレーション連動関係により、Salesforce マルチテナントアーキテクチャに関連する障害モードが作成されます。これらのプラットフォーム固有の障害に対して最初から設計します。SOQL クエリがデータスキューの行制限を超えている。Apex CPU時間は、複雑な計算中に期限切れになる可能性があります。コールアウトタイムアウトは、外部サービスが低速になると発生する可能性があります。同時トランザクションが競合すると、DML 行のロックに失敗します。ファイルのアップロードが予期せず急増すると、ストレージ制限に失敗する可能性があります。これらの障害を計画するアーキテクトは、手動操作なしで信頼性の高いソリューションを構築します。これらの信頼性の高いシステムは、近づいているガバナ制限を検出し、エラー処理によって爆風半径を抑制し、再試行フレームワークとプラットフォームイベントによって自動的に回復します。
• **自己復旧システムを構築します。**人の介入なしで障害を検出して自動的に復旧するソリューションを設計します。プラットフォームイベントにより、カスタム再試行パターンが有効になります。登録者への配信は EventBus.RetryableException で再試行できますが、元のトランザクションの再生にはカスタムアーキテクチャが必要です。フローエラー処理では、例外が復旧フローに転送されます。Apex一括処理ジョブでは、チャンク障害が分離されます。失敗したチャンクによって他のチャンクの処理が妨げられることはなく、部分的なジョブの完了と対象を絞った再試行が可能になります。一時的な障害回復のために AsyncApexJob でエラー追跡を使用して明示的な再試行ロジックを実装します。一時的な失敗を処理する場合は、次の再試行パターンに指数バックオフを適用します。自動復旧システムは、人間の対応者が対応できない業務時間外のインシデントでも対応可能状況目標を維持し、運用負荷を軽減しながら平均復旧時間を短縮します。
• **最初にビジネス要件に合わせて設計します。**テクニカルソリューションを選択する前に、実際のビジネスへの影響に基づいてサービスレベル目標を定義します。すべてのコンポーネントで99.9999%の可用性が求められるわけではありません。信頼性への投資をビジネスの重要度と照合し、サポート機能の正常な劣化を設計します。現実的な目標により、アーキテクチャを適切に選択し、過剰な設計や不十分な提供を回避できます。
• **ドリルでリカバリを検証します。**バックアップの復元、フェールオーバー手順、インシデント対応プレイブックをテストするディザスターリカバリー訓練をスケジュールします。本番バックアップから Full Copy Sandbox を復元して、リカバリプロセスを検証します。Sandbox 環境に意図的な障害を導入して、監視で問題が検出され、自動復旧が正しく実行されることを確認します。実際のインシデントで明らかになる前に、ドリルで手順、ツール、ランブックのギャップを明らかにします。ドリル結果を文書化し、検出されたギャップの修復を追跡します。定期的なテストにより、ソリューションが進化し、チームメンバーが変更された場合でも、リカバリ機能が最新の状態が維持されることを確認します。

Salesforce の動作を理解することで、制御する内容の信頼性設計作業に集中できます。このプラットフォームは、従来の IT 環境では専任チームが必要となる次のようなインフラストラクチャの懸念事項に対応します。

• マルチリージョンインフラストラクチャとフェイルオーバー: Salesforce Hyperforceは、内部サービスのフェイルオーバを自動化して地域のデータセンターに提供します。また、リージョン内に複数の可用性ゾーンを提供し、インフラストラクチャ レイヤーでデータ レプリケーションを行います。このプラットフォームでは、リージョン内の冗長性と可用性ゾーンの配布が透過的に処理されます。
• プラットフォーム SLA コミットメント: 契約上の救済措置を含む可用性レベルの保証は、顧客ごとに交渉されます。Trust.salesforce.com では、プラットフォームの状況とアップタイム履歴がリアルタイムで公開されますが、特定の可用性保証とその救済策は、交渉済みの契約に基づきます。契約と最新のSalesforce Trust and Complianceのドキュメントで、組織に適用されるコミットメントを確認します。
• インフラストラクチャの冗長性: プラットフォームは、冗長なサーバ、ネットワークパス、データベースインフラストラクチャ、およびストレージシステムを維持します。インフラストラクチャレベルのフェイルオーバは、ハードウェア障害時にお客様によるアクションなしで自動的に実行されます。プラットフォームのバックアップは、インフラストラクチャレベルのデータ損失から保護します。
• プラットフォームのメンテナンスおよび更新: プラットフォームのメジャーリリースでは、Salesforce が管理する下位互換性のある機能とセキュリティパッチが提供されます。プラットフォームのメンテナンス期間は、Trust.salesforce.com でスケジュールおよび通知されます。インフラストラクチャのパッチ適用は、お客様の介入なしで透過的に行われます。
• コアプラットフォーム状態監視: Salesforce は、データベースの応答時間、ネットワークレイテンシ、API ゲートウェイの状態、ストレージシステムのパフォーマンスなど、インフラストラクチャのパフォーマンスを監視します。プラットフォームの稼働状態ステータスは Trust.salesforce.com に表示され、インシデントのリアルタイム更新が含まれます。インスタンス固有の状況は、Status API を介して使用できます。

これらのプラットフォーム操作は、構築の基礎となります。データセンターの管理、サーバーのプロビジョニング、インフラストラクチャのディザスタリカバリの設計は行いません。代わりに、この基盤上で設計および設定を行うのはユーザーです。

共有責任モデルでは、Salesforce で作成するすべてのものの信頼性を所有することを指定します。プラットフォームの信頼性は作業を可能にしますが、置き換えるものではありません。信頼性に対する責任は、6 つの相互接続領域にまたがっています。

サービスレベル目標 (SLO) は、信頼性要件を測定可能な言葉で定量化します。SLO は、ビジネス要件と技術アーキテクチャを橋渡しします。テクノロジーの選択やデータモデルの設計を行う前に、重要なユーザーフローごとに成功を定義する SLO を設定します。

SLO は通常、次の項目を測定します。

• Availability (可用性) - システムが稼働中でアクセス可能な時間の割合
• レイテンシ - 操作の完了に必要な時間 (パーセント単位) (p50、p95、p99)
• スループット - 単位時間あたりに正常に完了した操作の量
• Error rate - 失敗した要求またはエラーが返された要求の割合
• 復旧時間 - インシデント後にサービスをリストアするために必要な期間

技術コンポーネントごとではなく、ビジネス能力ごとに SLO を定義します。ユーザー向け機能には、管理プロセスや一括処理よりも厳しい SLO が必要です。各 SLO は、使用可能な計装を使用して客観的に測定する必要があります。

サービスレベル契約 (SLA) は、契約上のコミットメントであり、失敗という結果をもたらします。保証された可用性レベルと契約上の救済措置は、顧客ごとに交渉されます。組織に適用されるコミットメントに関する契約と最新のSalesforce Trust and Complianceドキュメントを確認します。

ソリューションの SLO は、エラーの予算を維持するためにプラットフォームの SLA よりも厳しくする必要があります。プラットフォーム SLA とソリューション SLO の両方が 99.9% を目標としている場合、重大なプラットフォームダウンタイムが発生すると、エラー予算が直接消費され、同じ測定期間内のアプリケーションレイヤーの障害、インテグレーションの問題、または計画メンテナンスのバッファがなくなります。SLO が正式に違反となるのは、累積ダウンタイムで測定期間の誤差予算がすべて使い果たされた場合のみです。SLA と SLO が同じ目標に設定されている場合、1 つのプラットフォームインシデントでその予算を完全に使い果たす可能性があります。たとえば、プラットフォームが 99.9% を提供する場合、ソリューション SLO を 99.5 % に設定して、アプリケーションのバグ、インテグレーションの失敗、リリース期間など、対処する必要がある問題に対して有意義なバッファを維持します。

サービスレベルインジケーター (SLI) は、SLO の達成を評価するために使用されるメジャメントです。SLI は、客観的に測定でき、一貫して収集でき、ユーザーエクスペリエンスに直接関連付けられている必要があります。

Salesforce ソリューションの場合、SLI には以下が含まれます。

• Trust.salesforce.comによるプラットフォームのアップタイム
• Experience Cloud 分析によるページの読み込み時間
• イベント監視による API 応答時間 (Event Monitoring アドオンまたは Salesforce Shield が必要)
• カスタムアプリケーションログによるトランザクション成功率
• AsyncApexJob 監視による一括処理ジョブの完了

可用性目標を高くすると、複雑さとコストが急増します。目標にコミットする前に、アーキテクチャへの影響を理解します。

恣意的な目標は避けてください 「何事にもファイブ・ナイン」代わりに、機能ごとのダウンタイムのビジネスへの影響を評価し、それに応じて目標を設定します。1 か月あたり 7 時間のダウンタイムを許容する内部バッチレポートでは、サブ時間のリカバリを必要とする収益に不可欠な注文処理とは根本的に異なるアーキテクチャが必要です。

技術的な総計値のみではなく、ユーザーの観点から信頼性を定義します。システムが 99.9% のアップタイムを報告しているがタイムアウトが頻繁に発生すると、ユーザーエクスペリエンスベースの信頼性が低下します。ユーザーは、個々の API アップタイムよりもワークフローを正常に完了することを重視します。

個々の API コールではなく、ユーザージャーニーを反映する SLO を設計します。複数ステップの Checkout フローでは、許容時間内にすべてのステップを正常に完了する必要があります。主要な信頼性インジケーターとして、エンドツーエンドのユーザーフローの完了率を測定します。コンポーネントの可用性は必要だが、ユーザーエクスペリエンスの信頼性を確保するには不十分。

Salesforce Hyperforceは、地理的な分散を可能にする地域データセンターを提供します。このプラットフォームは、複数の可用性ゾーン、内部サービスの自動フェールオーバー、インフラストラクチャレイヤーでのデータレプリケーションなど、リージョン内のインフラストラクチャの冗長性を処理します。プラットフォーム SLA には、このインフラストラクチャの冗長性が反映されます。

ほとんどのソリューションでは、プラットフォームで管理される冗長性を備えた単一リージョンのリリースで十分な可用性が提供されます。Trust Salesforceインフラストラクチャによる基本的な可用性を実現し、フォールト トレラントなインテグレーション パターン、グレースフル デグラデーション、自動リカバリなど、アプリケーション レイヤーの信頼性に重点を置いたソリューション アーキテクチャを実現します。

可用性ゾーン間のリージョン内フェールオーバーは自動的に行われ、標準のプラットフォーム SLA コミットメントに含まれます。Salesforce は、これをインフラストラクチャレイヤーで透過的に管理します。地域間 (地域外) ディザスターリカバリーは個別の有料サービスであり、どの標準エディションにもデフォルトで含まれていません。ビジネス継続性要件で地域間のフェールオーバーが必要な場合は、ディザスターリカバリー計画でこの依存関係を明示的に文書化して、含まれるプラットフォームの耐障害性と購入した地域間の DR 機能の違いを関係者が理解できるようにします。

複数組織アーキテクチャでは、最も強力な分離と地理的冗長性が提供されますが、データ同期、ユーザープロビジョニング、導入の調整、ライセンスコストなど、運用の複雑さが増します。ビジネス要件によってその複雑さが明らかに正当化されるシナリオに備えて、複数組織のパターンを確保します。たとえば、次のシナリオの複数組織のパターンについて考えてみます。

• ビジネスには、プラットフォーム機能を超える保証された RPO/RTO が必要
• 規制要件により地理的データが分離され、ビジネス継続性計画では 1 つの地域から完全に独立している必要がある
• ビジネスユニットの自律性の要件のため、組織の統合は実行できません。

アクティブ-パッシブ パターン: - プライマリ組織は、通常の条件下ですべてのトラフィックを処理します。異なるリージョンのセカンダリ組織は同期済みですがアイドル状態のままです。フェールオーバーは、プライマリリージョンの停止中に発生します。このソリューションでは、最もシンプルな複数組織のパターンが提供されますが、セカンダリ容量は未使用のままになります。DNS ルーティングまたはユーザー認証レイヤーによって、ユーザーは有効な組織に転送されます。

Active-Active パターン: - 両方の組織が継続的に本番トラフィックを提供します。ユーザーは、地域、ビジネスユニット、または作業負荷種別ごとに割り当てられます。アクティブ-アクティブは業務量を最大化しますが、高度なデータ同期とユーザールーティングが必要です。両方の組織で同じレコードが変更される場合、競合の解決が不可欠です。

RPO 要件に適したデータ同期を設計します。プラットフォームイベントでは、重要なデータの変更に対してほぼリアルタイムのイベントストリーミングが提供されます。変更データキャプチャでは、最小限の開発で選択したオブジェクトの変更を自動的に追跡できます。Bulk API 2.0 を使用した固定間隔でのスケジュール済み API レプリケーションは、時間的制約の少ない参照データに適しています。

データ、アプリケーション、インテグレーションレイヤーで冗長性を適用して、単一障害点を回避します。階層化された冗長性により、単一レイヤーで障害が発生してもシステム全体の可用性が損なわれません。

• データの冗長性: プラットフォームは、インフラストラクチャのバックアップによってデータの冗長性を提供します。プラットフォームの復元手順よりも迅速なリカバリがビジネスで必要な場合は、アプリケーションレベルのレプリケーションでこの冗長性を補完します。変更データキャプチャまたはプラットフォームイベントを使用して、重要なデータをセカンダリストレージまたは外部システムに継続的にレプリケートします。これにより、インフラストラクチャのバックアップでは対処できない論理的な破損や構成エラーからの復旧が可能になります。
• アプリケーションの冗長性: 任意のアプリケーションサーバーで任意の要求を処理できるように、ステートレスなアプリケーションロジックを設計します。水平スケールを妨げるサーバー側の状態は避けてください。すべてのアプリケーションサーバーですぐに使用できる必要がある設定には、カスタムメタデータ型とカスタム設定を使用します。ステートレス設計により、アプリケーションサーバーは特定のサーバーの状態に依存することなく要求を処理できます。
• インテグレーションの冗長性: 一時的な外部システムの使用不可を許容するインテグレーションを設計します。失敗したインテグレーションを検出する回路ブレーカーパターンを実装します。外部システムが停止しているときに、ユーザー操作をブロックするのではなく、プラットフォームイベントを介して要求をキューに入れます。これにより、外部システム障害がユーザー対応機能から分離されます。

Trust.salesforce.comとインスタンス固有の状況APIを使用して、Salesforceプラットフォームの健全性を監視します。インスタンスの状況通知を登録して、インシデント、メンテナンス期間、パフォーマンスへの影響に関するアラートを受信します。プラットフォームの状態シグナルにより、事後対応のトラブルシューティングではなく、プロアクティブな対応が可能になります。

プラットフォームの健全性状況に対応するソリューションを設計します。プラットフォームのパフォーマンスが低下した場合は、重要でないバッチ処理の負荷を軽減します。スケジュール済みジョブ監視を使用して、メンテナンス期間中にバックグラウンドジョブを延期します。インシデント中の重要なユーザー向け操作を保護するために、必須ではないインテグレーションを無効にします。この動的な負荷制限により、負荷がかかっても重要な機能の信頼性が維持されます。

スケールセンターを使用して、プラットフォームリソースに偏りのある実行時間の長いトランザクションと操作を特定します。Scale Center はトランザクションレベルの可視性を提供し、アーキテクトがユーザー向けのインシデントになる前に信頼性リスクを検出できるようにします。週次スケールセンターレビューにより、アーキテクチャの修正が必要なパターンが明らかになります。

複数のレベルで障害検出を実装し、完全な停止に連鎖する前に問題を検出します。階層型検出では、検出されなかった障害に対する詳細な防御が提供されます。

早期発見と偽陽性のバランスを取るアラートしきい値を設計します。エラー率がしきい値を超えた場合、または持続的な劣化が発生した場合にアラートを表示します。障害が分離された場合はアラートを表示しません。単一エラーは分散システムでは正常です。エラーのパターンは、注意が必要な信頼性の問題を示します。

Salesforce ガバナでは、マルチテナントプラットフォームでの各テナントのリソース消費の上限が制限されるため、1 つのテナントが他のテナントのパフォーマンスを低下させることはありません。これらは恣意的な制限ではなく、ソリューション設計を形成するアーキテクチャの境界です。信頼性の高いアーキテクチャを設計する前に、ガバナ制限を理解します。通常の負荷でガバナ制限に頻繁に近づいているソリューションは、ストレスで失敗する可能性があります。

アーキテクチャの決定に影響する重要なガバナ制限:

ピーク負荷下でも制限内で適切に完了するトランザクションを設計します。通常の条件下でガバナ制限の 70% を上限としてマージンを確保し、予期しない急増に備えて 30% を確保します。このバッファは一時的な負荷の増加に対応し、通常はハードリミットに達しません。

一括処理は、Salesforce の基本的なスケーラビリティパターンです。個々のレコード操作ではなく、1 つのトランザクションで複数のレコードを処理します。一括処理により、スループットを向上させながらガバナ制限の消費を削減できます。すべての Salesforce アーキテクトは、すべての拡張可能なソリューションの基盤となっている一括処理パターンを習得する必要があります。

レコード・コレクションを効率的に処理するように、すべてのApexトリガー、バッチ・クラス、インテグレーションを設計します。最初にレコード識別子を収集してから、単一クエリステートメントと DML ステートメントを使用してすべてのレコードを処理します。個々のクエリを含むネストされたループではなく、マップとセットを使用して効率的にルックアップします。コレクションベースの処理では、レコード単位のアプローチに比べて効率が大幅に向上します。

プラットフォームは最大 200 件のレコードのバッチで実行をトリガーするため、レコードトリガー自動化ではトリガー呼び出しごとに 200 件のレコードを処理する必要があります。Lightning Data Service 操作バッチは自動的に実行されますが、カスタム コンポーネントは DML 操作を実行するときに一括パターンを明示的に実装する必要があります。

非同期処理では、1 つのトランザクションのガバナ制限内で即座に完了しようとするのではなく、作業を時間全体に分散します。非同期パターンは、操作が同期ガバナ制限を超える大量のデータを処理している場合、応答時間が変動する外部システムに依存している場合、完了の遅延を許容できる場合、または同期 CPU 制限を超える実行時間の延長が必要な場合に使用します。

Salesforce の非同期機能とアーキテクチャの適合性:

• Apex 一括処理: 実行メソッドごとに最大 2,000 件のレコードのチャンクで大量のレコードを処理します。バッチでは、チャンクごとの専用のガバナ制限と障害の分離が提供されます。チャンクが失敗しても、他のチャンクの完了は妨げられません。これにより、部分的な成功と対象を絞った再試行が可能になります。AsyncApexJob オブジェクトで失敗したチャンク範囲を追跡し、対象を絞った一括処理ジョブを再度キューに入れることで、一時的な失敗に対するカスタム再試行ロジックを実装します。一括処理は、データ移行、スケジュールされた一括更新、大規模なデータ処理に使用します。組織ごとに最大 5 つの一括処理ジョブが同時に実行中または待機中です。追加のジョブは Apex Flex キュー ([保留中] 状況の最大 100 個のジョブ) にキューイングされ、スロットが開くと自動的に実行されます。
• キュー可能 Apex: チェーン機能を使用して非同期ジョブを実行し、複数ステップのワークフローと複雑なオブジェクトパラメーターを有効にします。Queueable Apex は、24 時間あたり 25 万件の実行という組織全体の DailyAsyncApexExecutions の制限を、キュー可能固有の専用割り当てを保持するのではなく、他のすべての非同期 Apex (バッチ、将来、スケジュール済み Apex) と共有します。Queuable Apexは、@futureメソッドよりも優れた監視機能を備えた順次処理が必要な複数ステップのオーケストレーションおよびインテグレーション ワークフローに使用します。
• プラットフォームイベント: プラットフォームイベントは、パブリッシャーを登録者から分離する公開-登録イベントアーキテクチャで使用されます。イベントは 72 時間 (3 日) の保持期間から再生されます。72時間を超える拡張保存は有料アドオンとして使用できます。拡張リプレイに依存するSLAの義務を果たす前に、最新のSalesforce Platform Eventsドキュメントで現在の最大制限とGA状況を確認します。イベント駆動型の自動化、システム間インテグレーション、リアルタイムデータストリーミングには、プラットフォームイベントを使用します。プラットフォームイベントでは、トランザクションフェーズ間の自然な非同期境界が提供されます。
• スケジュール済み Apex: System.schedule() を介して CRON 式を使用して、固定のスケジュールでジョブを実行する。ジョブは、最大 1 時間に 1 回実行するようにスケジュールできます。CRON seconds 項目と minutes 項目では、範囲ではなく固定値を使用する必要があります。同様の操作を 1 つのスケジュール可能なクラスに統合することで、組織あたりのスケジュール済み Apex ジョブの最大数を 100 以内に抑えることができます。

一括処理や非同期パターンを使用してもデータ量が実用的な処理制限を超える場合は、データを論理境界間で分割して並列処理を有効にします。データパーティショニングでは、大きな順次操作が小さな並列操作に変換され、より迅速に完了してガバナ制限内に収められます。

• 日付ベースのパーティショニング: 今月のトランザクションまたは前四半期のケースを含む期間でデータを処理します。履歴データを Big Object または外部ストレージにアーカイブして、作業セットを管理しやすくします。ほとんどのトランザクションクエリは、時間ベースのパーティショニングを自然に効率的にするために最近のデータに焦点を絞ります。
• レコードタイプのパーティショニング: パートナーケースと顧客のケース、エンタープライズ取引先とSMB取引先など、さまざまなレコードタイプを個別に処理します。種別ごとに個別の一括処理ジョブを使用すると、並列化が可能になります。多くの場合、レコードタイプは、独立した処理を正当化する個別のビジネスプロセスと相関します。
• 所有者ベースパーティショニング: 各営業地域の商談を個別に処理するなど、レコード所有者ごとに処理を配分します。所有者ベースのパーティション分割は、既存のメカニズムを使用してセキュリティが適用されるため、共有モデルと組み合わせると特に効果的です。所有者ベースのパーティショニングにより、処理負荷を地理的に分散できます。

枯渇を制限するのではなく、ビジネスの成長に基づいて将来の業務量要件を予測します。プロアクティブな業務量計画により、プラットフォームリソースの不足に起因する信頼性インシデントを回避します。

• ユーザーライセンス - 人員の増加により、ユーザーあたりのAPIコールの割り当てとストレージエンタイトルメントが増加します。
• データ ストレージ - ストレージ消費を促進するトランザクション量と保持ポリシー(名目上、年間10~20%以上の増加を計画)
• APIコール - インテグレーション数と頻度による24時間のAPI割り当て(新しいインテグレーションパターンごとに定期的な消費が追加されます)
• 処理能力 - 非同期処理キューと同時実行制限の原因となる一括処理ジョブ数と複雑さ

Proactive Monitoring を使用して、組織業務量の使用状況を継続的に評価します。Proactive Monitoringでは、APIの使用による要求制限の急増、ストレージの制限の近さ、バッチ ジョブ キューの深さが持続可能なレベルを超えて増大するなど、業務量に関するリスクが明らかになります。毎週の業務量レビューにより、ビジネスへの影響が発生する前に追加のライセンスや制限の調達リードタイムを短縮できます。

本番リリース前の負荷テストで拡張性の前提条件を検証します。負荷テストでは、少量開発テストでは見えなかったガバナ制限の問題、インテグレーションのボトルネック、業務量の制約を明らかにします。本番規模のデータ量と同時実行でテストし、現実的な条件下での信頼性を検証します。

• データ量テスト: Full Copy Sandbox で本番規模のデータ量を入力して、実際のデータスキュー、リレーション深度、レコード件数でクエリパフォーマンスを検証します。生産量がこの規模に達すると、1,000 万件以上のレコードでテストできます。データ量が増加すると、クエリオプティマイザーの動作が大きく変わり、小スケールテスト結果が誤解を招く可能性があります。
• 同時ユーザーテスト: ピーク時の同時ユーザー負荷をシミュレーションして、トランザクションスループットと競合を検証します。対象組織で使用できるスケールテストを使用して、リリース前に Sandbox 環境で本番ワークロードをシミュレーションします。同時実行により、シングルユーザーテストでは見えないロックの問題が明らかになります。
• API 負荷テスト: ピーク API 量を生成して、インテグレーションの拡張性、レート制限の処理、および負荷が持続した場合の回路ブレーカーの動作を検証します。API 負荷テストでは、ストレス状態で再試行ロジックとエラー処理が正常に動作するかどうかを明らかにします。
• スケールテスト: スケールテストは、本番業務量に合わせて拡張されたFull Copy Sandbox環境に対して本番ワークロードをシミュレートするために使用されるSalesforce製品です。スケールテストはHyperforce上のFull Copy Sandboxに対して実行されます。Hyperforce 上になくても、本番インスタンスを使用できます。本番組織でテスト計画を作成し、テストは Sandbox に対して実行します。スケールテストを使用して、大規模な導入前のピーク負荷条件下でのガバナ制限のヘッドルーム、非同期処理スループット、インテグレーション応答の動作を検証します。

グレースフル デグラデーションでは、重要でないコンポーネントに障害が発生してもコア機能が維持されます。障害発生時にサポート機能よりも重要なユーザーフローを優先するようにシステムを設計します。すべての機能に同じビジネス上の重要度があるわけではなく、アーキテクチャにはこれらの優先度が反映されている必要があります。

機能重要度階層を定義します。

この階層により、アーキテクトは部分的なシステム障害が発生してもビジネス継続性を維持する機能低下ポリシーを設計できます。ユーザーは、完全な対応不可状態よりも機能の低下を好みます。

Circuit Breaker (回路ブレーカー) パターンにより、インテグレーションが使用できなくなった場合に障害が連鎖することを防ぎます。トランザクション時間とガバナ制限を消費するタイムアウトを累積するのではなく、失敗パターンを検出して、失敗したシステムのコールを停止します。サーキットブレーカーは、低速の障害ではなく高速の障害を提供します。

Circuit Breaker State:

• 完了 - 通常動作。要求は設計どおりに外部システムにフローされます。
• オープン - 失敗しきい値を超えました。要求は外部コールを試行せずにすぐに失敗し、リソースを節約します。
• ハーフオープン - リカバリテスト期間、制限された要求で外部システムを調査し、回路を完全に閉じる前にリカバリを検出する

プラットフォームキャッシュを使用して回路ブレーカーを実装し、すべてのトランザクションでアクセスできる回路の状態を保存します。プラットフォームイベントを使用して、組織全体で状態の変更をブロードキャストします。Circuit Breaker ロジックは、外部コールを試行する前に状態をチェックし、既知の障害が発生したシステムでの無駄なコールアウト制限を回避します。

一時的な障害は、分散システムでは正常な状態です。多くの場合、ネットワークの中断、一時的なサービス不能、レート制限応答は数秒で解決されます。すぐに失敗するのではなく、順次遅延後に失敗した操作を繰り返す再試行ロジックを実装します。

指数関数的なバックオフにより、システムのリカバリに負担をかける再試行ストームを回避できます。1 回目の再試行は 1 秒後に、2 回目の再試行は 2 秒後に、3 回目の再試行は 4 秒後に、4 回目の再試行は 8 秒後に行われます。指数関数的増加に関係なく、最大遅延を 30 ～ 60 秒で制限します。このバックオフパターンにより、障害が発生したシステムの復旧に時間をかけると同時に、再試行の合計回数を制限できます。

再試行戦略を失敗種別と照合します。

• ネットワークタイムアウト: 短いバックオフで再試行します (操作がサーバに到達していない可能性があります)。
• レート制限エラー （429）： Retry-After ヘッダー値またはレート制限のリセット時間後の再試行
• サーバ エラー (5xx): サーバが一時的に過負荷になっている可能性があるため、指数バックオフで再試行します。
• クライアントエラー (429 を除く 4xx): 再試行しないでください。エラーで無効な入力が示されたため、要求を修正してください。
• **ガバナ制限エラー:**同じトランザクションで再試行しないでください。たとえば、非同期登録者が新しいトランザクション制限の下でバックオフで再処理する失敗イベントを公開して、専用の制限がある非同期操作として再キューします。

フォールバック戦略では、プライマリメソッドが失敗した場合の代替アプローチを定義し、パフォーマンスが低下している条件下での運用を継続できるようにします。

• 代替データソース: プラットフォームキャッシュセッションから、またはリアルタイム API が使用できない場合は組織パーティションからデータを取得します。正常な操作中にキャッシュに事前入力します。キャッシュでは、古いが使用可能なデータが提供されます。これは、多くの使用事例で完全な障害が発生するよりも優れています。
• デフォルト動作: Personalization または強化サービスが使用できないときに標準ビジネスルールを適用します。デフォルト値を使用して処理し、サービスが回復したときに強化のフラグを設定します。デフォルト動作では、精度が低下する代わりにスループットが維持されます。
• 手動プロセス: 自動化に失敗したときに手動操作を完了できるようにします。行き詰まったトランザクションを完了するための管理インターフェースを提供します。手動フォールバックにより、自動化が損なわれてもデータの損失を回避し、ビジネス継続性を維持できます。
• 再試行キュー: 外部システムが復旧したときに処理できるように、プラットフォームイベントまたはカスタムキューオブジェクトに操作を保存します。標準で 72 時間保持されるプラットフォームイベントリプレイにより、一時的な障害後に登録者がデータを損失することなく復旧できます。

すべてのインテグレーションコールアウトに適切なタイムアウトを設定します。Salesforce では、トランザクションごとに合計で最大 120 秒のコールアウト時間が適用されます。ハングした接続でトランザクション時間が消費されないように、この時間を 1 つのトランザクション内のすべてのコールアウトに配分します。

タイムアウトの設計に関する考慮事項:

• ユーザー向け同期コールアウト: 応答性の高い UI を維持するには、最大 5 ～ 10 秒を使用します。これは、ユーザーの待ち時間が長くなる傾向があるためです。
• バックグラウンド非同期コールアウト: 30 ～ 60 秒を使用して、ユーザーを待たせずに外部パフォーマンスを調整します。
• 一括処理コールアウト: 応答を待機しているユーザーがいない場合は、許容される最大の 120 秒を使用します。
• Multiple callouts per transaction: すべてのコールアウトの予算合計時間。たとえば、10 秒で 3 つのコールアウトを行い、それぞれ 120 秒の予算の 30 秒を消費します。

タイムアウトを短くすると失敗が早くなり、フォールバック戦略をより迅速に開始できます。タイムアウトを長くすると、低速だが機能する外部システムの成功率が高くなります。バランスに関する考慮事項は、ユーザーが応答を待機しているかどうか、および代替戦略が使用可能かどうかに基づきます。

障害をクラッシュから管理された劣化に変換する包括的なエラー処理を設計します。

• Fail fast: エントリポイントで入力と前提条件を検証します。コストのかかる操作の前にガバナ制限消費量を確認します。無効な状態を複数の処理レイヤーに伝達するのではなく、障害をすぐに検出します。早期検出により、ブラスト半径が減少し、デバッグが容易になります。
• 正常な障害: 操作が部分的に失敗した場合でもユーザー機能を維持します。バッチの 200 件のレコードのうち 3 件が検証に失敗した場合、バッチ全体を失敗させるのではなく、成功した 197 件のレコードを処理し、3 件の失敗を報告します。一括処理では、部分的な成功の方が全体的な失敗よりも優れています。
• Fail informatively: トランザクション ID、ユーザーコンテキスト、入力パラメーター、スタック追跡を使用してエラーを記録します。迅速なインシデント解決の主な障害は、エラーコンテキストの不足です。すべてのエラーログにより、応答者は失敗した内容、理由、再現方法を理解できます。
• 安全に障害発生: 障害によってデータの整合性やセキュリティが損なわれないようにします。データを矛盾した状態にせずに、部分的なトランザクションをロールバックします。スタック追跡によって攻撃者に役立つ実装の詳細が明らかになるため、内部エラーの詳細はエンドユーザーに公開しないでください。

RTO (目標復旧時間) では、災害発生後の許容可能なダウンタイムの最大値を定義します。RTO は、フェールオーバーの自動化、バックアップ頻度、リカバリテストへの投資に関するアーキテクチャ上の意思決定を促進します。ビジネス能力が異なると、RTO 投資も異なります。RTOはユーザーが直接体験するダウンタイムであるため、目標が達成されなかった場合、システムの停止が長期化し、Customer Trustが損なわれます。

RTO はビジネス能力によって異なります。

災害復旧アーキテクチャを設計する前に、機能ごとの RTO を定義します。RTO は、テクノロジーの選択、自動化への投資、テストのケイデンスを形成します。より積極的な RTO 目標には、自動化と冗長性への投資が必要です。

RPO(目標復旧時点)では、許容される最大データ消失期間を定義します。RPOによって、バックアップ頻度、レプリケーション戦略、同期パターンが決まります。RPO（目標復旧時点）の厳格化に伴い、データ・レプリケーションの頻度が高まり、複雑さとコストが増大します。RPO (目標復旧時点) はビジネスが吸収するデータ損失であるため、目標が達成されなかった場合、トランザクションが失われ、レコードに復元できないギャップが生じる可能性があります。

RPO 要件とコストおよび複雑さのバランスを取ります。RPO (目標復旧時点) をほぼゼロにするには、インフラストラクチャに多大な投資をしながら継続的なデータレプリケーションを行う必要があります。日次バックアップでは、複雑さを最小限に抑えながら 24 時間の RPO が提供されます。ほとんどの組織では、非財務データのデータ損失を許容できます。

プラットフォームインフラストラクチャの冗長性により、インフラストラクチャの障害から保護されますが、ほとんどのデータ損失の原因となるユーザーエラー、欠陥のあるリリース、インテグレーションの欠陥の結果が複製されます。バックアップは、これらのアプリケーションレイヤーの障害から復旧するために存在し、プラットフォームの信頼性を補うものではありません。データ、メタデータ、ファイルそれぞれに異なるバックアップ方法が必要であるため、バックアップ戦略を実装します。

• データバックアップ: データとメタデータの両方に対応する包括的なバックアップ戦略を実施します。ネイティブのデータエクスポートサービスを使用して、重要なオブジェクトデータをエクスポートします。Enterprise Edition、Performance Edition、および Unlimited Edition では 7 日ごと、Professional Edition 以前では 29 日ごとです。エクスポート ファイルは、通知メールの送信後、週末を除き、自動削除されるまで 48 時間使用できます。ファイルが完全に失われないように自動ダウンロードプロセスを設定します。メタデータ API と Salesforce CLI (sf project retrieve) を使用して、Git などのソース制御システムで組織構成、カスタムコード、宣言型自動化のバージョン管理を行います。メタデータのバックアップを標準の CI/CD パイプラインの一部として扱います。ポイント・イン・タイムのリストア、詳細なレコード・レベルのリカバリ、ネイティブ・エクスポートの頻度を超えた保持のためのOwnなどの専用のバックアップ/リカバリ・サービスでデータ・バックアップを補完します。ネイティブデータエクスポートでは、ポイントインタイムのリストアはサポートされていません。また、RTO/RPO で詳細なリカバリ期間が必要な場合、サードパーティツールが必要です。復元手順は定期的にテストしてください。復元されていないバックアップは、テストされていない前提です。
• **メタデータ バックアップ:**バージョンは、GitリポジトリのSalesforce DXソース形式を使用してすべてのメタデータを制御します。メタデータバージョン管理により、破損や意図しない変更の後でも迅速に設定を復元できます。すべてのリリースはソース制御から再現できる必要があります。Git のメタデータでは、設定のポイントインタイムリカバリが提供されます。
• ファイルバックアップ: ContentVersion レコード、添付ファイル、ドキュメントを外部ストレージにエクスポートします。Salesforce は、長期間のファイルアーカイブではなく、規制で保持される外部ストレージにファイルをエクスポートする有効なデータに最適です。プラットフォームの機能を超える規制保持要件に対応する自動ファイルエクスポートを実装します。
• 検証: スクラッチ組織または Developer Sandbox にバックアップを定期的にリストアし、手順とバックアップの整合性を検証します。テストされていないバックアップは、バックアップ範囲が不完全であったり、アーカイブが破損したりして、必要なときに失敗することがよくあります。四半期ごとのリストア検証をスケジュールして、災害が発生する前に問題を検出します。リストアの検証に加えて、バックアップの更新を監視します。最後に成功したバックアップが想定されたケイデンスよりも古い場合 (毎週のエクスポートが 8 日以上完了していない場合など) にアラートを表示します。この検証により、サイレントで失敗したバックアップジョブが、次のドリルではなくすぐに表示されます。

RPOおよび複数組織の要件に適したレプリケーションを設計します。

• 変更データキャプチャ (CDC): 追跡オブジェクトの変更イベントを登録します。CDC は、項目値が変更された作成、更新、削除、および復元イベントを提供します。標準オブジェクトとカスタムオブジェクトを含め、サポートされるオブジェクトの開発作業を最小限に抑えながら、ほぼリアルタイムのレプリケーションを実現します。エディションに基づく日次配送割り当ての対象になります。
• プラットフォームイベント: ビジネスイベントと状態の変更を複製するためのカスタムイベントアーキテクチャ。CDC よりも柔軟性が高く、カスタムペイロードや複雑なイベント構造をサポートしていますが、トリガーまたはプロセスで明示的な公開ロジックが必要です。72 時間リプレイ期間標準では、一時的な登録者障害からの回復が可能です。
• スケジュール済み API レプリケーション: スケジュール済み API レプリケーションは、固定されたスケジュールに従って Bulk API 2.0 を介してバッチを抽出します。これは、RPO が抽出頻度に等しい最もシンプルな実装です。スケジュール済み API レプリケーションは、参照データや履歴分析など、ほぼリアルタイムの実行が不要な重要でないデータに適しています。
• MuleSoft オーケストレーションレプリケーション: MuleSoft Anypoint Platform は、複雑なマルチシステムレプリケーショントポロジ向けにオーケストレーション、変換、監視を提供します。この用途は、高度なルーティングと変換ロジックを必要とする Salesforce および複数の外部システム間でのレプリケーションに適しています。

人、プロセス、テクノロジーをまとめて検証するスケジュール済み訓練を使用して、災害復旧をテストします。

• 机上課題: チームは災害シナリオに沿って、実際のフェイルオーバなしで役割と意思決定のポイントについて話し合います。この活動は低コストで、手順のギャップやコミュニケーションの内訳を明らかにします。机上演習を定期的に実施して、人事異動時のチームの準備を整えます。
• 部分フェイルオーバ: - ソース制御からのメタデータの復元、バックアップサービスからのデータの復元、Sandbox の更新など、特定の復旧手順をテストします。これにより、ビジネスへの影響が限定的である技術的な手順が検証されます。すべてのリカバリ機能を毎年カバーするようにテストする手順を循環しながら、定期的に実施します。
• 完全フェールオーバー訓練: 完全フェールオーバーとは、本番トラフィックカットオーバーを使用してディザスタリカバリ環境に完全フェールオーバーすることです。最高の信頼性を提供しますが、ビジネスの調整とユーザーとのコミュニケーションが必要です。この訓練は、重要なシステムに対して毎年実施します。完全フェールオーバードリルでは、カットオーバー手順やユーザーとのコミュニケーションなど、リカバリ機能全体が検証されます。

各ドリル後に得られた教訓を文書化します。調査結果に基づいてランブックを更新します。チームの変化やソリューションの進化に伴い、リカバリ機能が低下する可能性があります。DR ドキュメントは、1 回限りの成果物ではなく、定期的なメンテナンスが必要な生きた成果物として扱います。

ビジネス継続性は、技術的なリカバリだけでなく、人、プロセス、ベンダーの依存関係にまで及びます。

• チームの対応可能状況: 重要なロールのエスカレーション手順とバックアップ担当者を文書化します。Operation Knowledgeに単一障害点が存在しないことを確認します。災害発生中はプライマリ レスポンダーが対応できない場合があるため、バックアップ スタッフの割り当てが重要になります。
• コミュニケーション手順: インシデントをユーザー、顧客、エグゼクティブに伝達する方法を定義します。Salesforce 自体を含む主要なツール (外部状況ページや SMS 通知システムなど) が使用できないときに機能するコミュニケーションチャネルを確立します。
• ベンダー連動関係: ソリューションの運用に不可欠な外部ベンダー連動関係を対応付けます。Salesforce、インテグレーションパートナー、ISV パッケージプロバイダーなど、重要なベンダーごとにエスカレーションパスと契約 SLA を文書化します。たとえば、24 時間 365 日対応のサポートを提供しているベンダーや、リカバリのタイミングに影響する営業時間のみのサポートを提供しているベンダーを把握します。
• 規制義務: 長期間の停止によってトリガーされる通知要件を特定します。多くの場合、金融サービス、医療、および政府との契約では、特定の期間内のインシデント通知が要求されます。コンプライアンス違反によって規制リスクと法的リスクが発生し、どちらも災害に影響を及ぼします。

複数のシグナルをシステム全体の健全性状況に集約する健全性モデルを定義します。健康モデルでは、詳細な評価指標を分析することなく、運用状況を一目で確認できます。次に例を示します。

稼働状況をすぐに表示する健全性ダッシュボードを設計します。稼働状況により、緑の状況では通常の業務、黄色の状況では監視の強化、赤の状況では有効なインシデント対応などの業務対応がガイドされます。

プラットフォーム状況シグナル (「プラットフォーム状態の監視」の前半で説明) では、Salesforce インフラストラクチャのパフォーマンスが低下したときは表示されますが、独自のソリューションのパフォーマンスは表示されません。

ソリューション固有のオブザーバビリティでこれらのシグナルを強化します。

• イベント監視: イベント監視には、API コール、ページビュー、レポートエクスポート、ログインアクティビティ、Apex 実行を取得する詳細なログが含まれます。EventLogFile オブジェクトは、24 時間 (毎日) または 1 時間の頻度でログを提供します。1 時間ごとの配信には Event Monitoring アドオンまたは Salesforce Shield が必要です。保存期間は[設定]から最大365日まで設定できますが、保存期間を延長するにはSalesforce ShieldまたはEvent Monitoringアドオンが必要です。アドオンがない場合、ログ ファイルは1日間保持されます。イベントを外部のセキュリティ情報およびイベント管理 (SIEM) システムまたはログ集計プラットフォームに転送し、ネイティブの制限を超えた関連付け、アラート、保持を行います。イベント監視を使用して、異常なAPI消費パターンの検出、Apexプロセスの暴走の特定、規制された環境でのデータ・アクセスの監査を行います。
• Scale Center: Scale Centerは、実行時間の長い操作、行ロックの競合、リソースを大量に消費するトランザクションをトランザクションレベルで可視化します。Scale Center を使用すると、アーキテクトは特定のトランザクションパターンから信頼性リスクを特定して、ユーザーが直面するインシデントを未然に防ぐことができます。週次レビューでは、最適化の機会を明らかにすることができます。
• Proactive Monitoring: Proactive Monitoring は、組織の健全性を継続的に評価し、パフォーマンスと拡張性のリスクを明らかにします。Proactive Monitoringでは、API要求制限の急増、Apex同時実行の失敗、SOQL行制限の問題、ストレージ消費トレンドに関するアラートが提供されます。Signature Success (旧 Signature Support) エンタイトルメントを持つお客様が使用できます。これは、Standard Edition に含まれるセルフサービス機能ではありません。

インフラストラクチャではなくユーザーの観点からアプリケーションのパフォーマンスを監視します。

• **Real User Monitoring (**rum): Experience Cloud 分析またはカスタム計測を使用して実際のユーザーエクスペリエンスを測定します。実際のネットワーク状況、デバイスのパフォーマンス、地理的分布を反映して、実際の遅延を取得します。合成監視では、この変動を複製できません。
• 統合監視: 複数の場所から定期的に自動トランザクションを実行して、可用性とパフォーマンスを検証します。統合監視では、ユーザーが問題を報告する前に問題が検出されます。スケジュール済み Apex を使用して統合監視を実装し、プラットフォームイベントを使用して重要な操作を実行し、結果をレポートします。
• トランザクション追跡: 複雑な複数ステップの操作を測定し、ステップごとのタイミングを取得します。次に、5 ステップのワークフローのどのステップで遅延が発生するかを特定します。フロー全体をブラックボックスとして処理しないでください。ステップレベルのタイミングにより、集計指標では見えない最適化商談が表示されます。

エラー率、遅延の割合、スループットを使用して、すべての外部インテグレーションを監視します。インテグレーションの失敗は、信頼性インシデントの主な原因です。

• エラー率 - エラーを返す通話の割合 (対象: 正常なインテグレーションの場合は <1%)
• レイテンシ - p50、p95、p99で測定された応答時間(タイムアウト予算に基づいてインテグレーションごとのSLOを設定)
• タイムアウト率 - 設定されたタイムアウト (目標: <0.1%) を超過する割合
• 回路ブレーカー状態 - Open 状態は、すぐに対応が必要な障害が継続していることを示します。
• キューの深さ - 非同期インテグレーションの場合、キューの増加は、処理が生産レートを下回っていることを示します。

要求 ID、エンドポイント、応答コード、期間を使用して、すべてのインテグレーションコールを記録します。このデータにより、インテグレーションの失敗が信頼性に影響する場合に根本原因を迅速に分析できます。インテグレーションログで集計とトレンド分析を有効にする必要があります。

ユーザーが影響を受ける前に問題に対するアラートを設計し、プロアクティブな対応を可能にします。

• アクション可能アラート: すべてのアラートには、定義済みの応答アクションと割り当てられた応答者があります。明確な応答がないアラートは、疲労感を引き起こし、重要なシグナルを不明瞭にします。アラートの設計では、応答するユーザー、チェックする内容、および修正方法を対象とする必要があります。
• 適切な緊急性: ユーザーに影響する障害について、オンコール担当者をページ送りします。パフォーマンスが低下するとメールを送信します。トレンドに関する問題を日次ダイジェストに含めます。緊急度が一致しないと、過剰なエスカレーションによるアラートの疲労や、エスカレーション不足によるインシデントの見逃しが発生します。
• 状況に応じた通知: 超過したしきい値、現在の値、最近のトレンド、関連するダッシュボードまたは Runbook へのリンクを含めます。回答者がコンテキストを収集することなく、すぐに診断を開始できるようにします。各アラートには、追加のクエリなしで優先順位を付けるのに十分な情報が含まれている必要があります。
• ストーム抑制: 複数のシステムで同時に障害が発生した場合、冗長なアラートを抑制します。インテグレーションプラットフォームの障害を示す 1 つのアラートは、根本原因が不明瞭な個々のインテグレーション障害アラートの 50 件よりもアクション可能です。

異常検知では、異常なパターンが識別され、静的しきい値アラートでは見えない新しい問題を示すことができます。

• ボリュームの異常: トランザクション量が、予想される日次パターンを大幅に上回るか下回る場合、プロセスの暴走やユーザーアクセスの問題を示している可能性があります。
• エラー率の異常: 先週の同時期のベースラインと比較して増加したエラー率は、しきい値を超える前に徐々に低下します。
• レイテンシの異常: 複数日にわたって上昇している応答時間は、業務量の飽和またはパフォーマンスの低下を示します。
• 動作の異常: 異常なログインパターン、予期しないAPI使用率の急増、スケジュールされた時間枠外での一括処理ジョブの実行は、疑わしい使用を示している可能性があります。

Signature Success エンタイトルメントを持つお客様には、Proactive Monitoring で追加の設定なしでプラットフォームレベルの異常を検出できます。外部分析プラットフォームにエクスポートされたカスタム SLI のアプリケーション固有の異常検出で補完します。異常検知はしきい値アラートよりも偽陽性率が高いため、異常シグナルを使用して、すぐにエスカレーションをトリガーするのではなく調査をガイドします。

このチェックリストは、アーキテクチャのレビュー時、本番リリース前、および継続的な信頼性評価のために定期的に使用します。

信頼性目標と SLO

• 設計を開始する前にすべての重要なユーザーフローの SLO を定義する
• インフラストラクチャ総計値だけでなく、ユーザーエクスペリエンスに関連付けられた測定可能な SLI を確立する
• 恣意的な目標ではなく、ビジネスへの影響分析に基づいて現実的な可用性目標を設定する
• ソリューションの SLO がプラットフォームの SLA よりも厳格でないことを確認し、エラーの予算を提供する
• アーキテクチャ決定レコードでの可用性目標と根拠の文書化

高可用性アーキテクチャ

• データ、アプリケーション、インテグレーションレイヤーでの冗長性の設計
• Trust.salesforce.comおよびインスタンス ステータスAPIを使用してプラットフォームの正常性を監視する
• プラットフォームの状況に依存しないアプリケーション状態チェックの実装
• ビジネス要件が複雑さを明らかに妥当な場合にのみ、マルチ組織アーキテクチャを考慮する
• 複数組織パターンのテスト済みランブックを使用した自動フェールオーバーの設計

拡張性と業務量計画

• 通常の負荷でガバナ制限の 70% 以内に完了するトランザクションを設計する
• すべてのApexトリガー、バッチ クラス、インテグレーションに一括処理パターンを実装
• 同期制限を超える操作に非同期処理を使用
• 個々のレコードコールではなく、すべての API インテグレーションを一括処理
• リリース前に本番規模のデータ量で負荷テストを実施
• OrgLimits APIまたはカスタムApexを使用して容量使用率を監視し、使用量が70%の運用上限に近づいているときにアラートを表示
• 12 か月の成長予測に基づくプロジェクト業務量の要件
• 大規模データを日付、レコードタイプ、所有者別にパーティション分割し、ボリュームが順次制限を超えた場合に並列処理を有効化

フォールト トレランスと耐障害性

• 定義された機能重要度階層を使用したグレースフルデグラデーションの設計
• すべての外部システムインテグレーションにサーキットブレーカーを実装する
• 一時的な失敗に対する指数バックオフを使用した再試行ロジックの適用
• 操作種別に適したタイムアウトの設定 (5 ～ 10 秒のユーザー向け、30 ～ 60 秒の非同期)
• プラットフォームキャッシュとキューベースのパターンを使用した代替戦略の設計
• 十分な診断コンテキストを使用した構造化エラー処理の実装

災害復旧とビジネス継続性

• 設計前にビジネス能力ごとの RTO と RPO を定義する
• データ、メタデータ (ソース制御)、ファイルの自動バックアップの実装
• 本番以外の環境でバックアップのリストア手順を四半期ごとに検証
• バックアップの更新を監視し、スケジュール済みバックアップの期限を過ぎたときにアラートを表示
• RPO 要件に一致するデータレプリケーション戦略を設計する
• ディザスタリカバリテストを毎年実施 (机上の表は四半期ごと)
• ベンダーのエスカレーションパスを含むビジネス継続性手順の文書化

監視とオブザーバビリティ

• サービス、インテグレーション、データ、業務量シグナルを集計する健康モデルを定義する
• Salesforce インスタンスのプラットフォーム状況通知の登録
• 重要な Experience Cloud フローの実際のユーザー監視の実装
• エラー率、遅延、回路ブレーカーの状態によるインテグレーションの健全性の監視
• 定義済みの対応手順と所有権を使用したアクション可能なアラートの設計
• イベント監視データを外部プラットフォームに転送して長期保存および分析
• Proactive Monitoring and Scale Centerを使用して継続的な信頼性リスク評価を行う
• 量、エラー率、遅延パターンの異常検出を適用して、静的しきい値で見逃される劣化をキャッチ

適切に構築されたフレームワークに関するフィードバックを共有する。