可用性とパフォーマンスのパターン


Well-Architected Reliability (適切に設計された信頼性) → High Availability Architecture (高可用性アーキテクチャ) の詳細

パターン

参照すべき場所外観
ビジネスインパクト分析✅ 技術コンポーネントごとではなく、ビジネス能力ごとに定義された SLO (例: 「商談成立フロー: 99.9% の可用性、p95 の遅延は 2 秒未満」)
ユーザーフロードキュメント✅ 各重要なユーザーフローには、実際のユーザーエクスペリエンスに関連付けられた可用性、レイテンシ、スループット、エラー率、復旧時間をカバーする測定可能なSLOがあります。
アーキテクチャ決定レコード✅ ビジネスダウンタイムの影響分析に基づく対応可能状況目標、および文書化した根拠 (例: 内部バッチレポート 99% と収益に不可欠な注文処理 99.95%)
SLO の仕様✅ アーキテクチャの複雑さを考慮した現実的な目標(99% = 標準プラットフォーム機能、99.5 % = 基本的な冗長性とアクティブ監視、99.9% = 複数リージョン対応と自動フェールオーバー、99.95% = アクティブ-アクティブパターンとカオステスト、99.99% = 複数組織アーキテクチャ)
プラットフォームドキュメント✅ プラットフォームSLAよりも厳格ではないソリューションSLO(例:プラットフォーム99.9%のSLA → ソリューション99.5パーセントのSLO)により、アプリケーションレイヤーの障害に対するエラー予算を提供
監視設定✅ SLI(サービス レベル インジケーター)は、プラットフォーム計測を介して客観的に測定できます。Trust.salesforce.comのアップタイム、Experience Cloudの分析、イベント モニタリングAPIのレスポンス タイム、AsyncApexJobの完了
ユーザーエクスペリエンス総計値✅ SLO には、個々の API アップタイムではなく、完全なユーザージャーニー (「ケース登録フロー: p95 ユーザーは 5 ステップすべてが 8 秒以内に完了」など) が反映されます。

アンチパターン

参照すべき場所どんな悪い感じか
アーキテクチャドキュメント⚠️ 「システムは高速で信頼性がある必要がある 」 ( 測定不能、アーキテクチャの決定に影響しない)
SLO の仕様⚠️ 「99.999% のアップタイムが必要」 (収益業務と内部管理ツールのビジネス重要度の違いを無視した不当なコスト)
監視戦略⚠️ プライマリ SLI としてのインフラストラクチャ CPU 監視 (プラットフォーム評価指標アーキテクトは対応できず、ユーザー対応エクスペリエンスを反映していない)
プラットフォーム業務量計画⚠️ ソリューション SLO はプラットフォーム SLA に 99.9% で正確に一致 (アプリケーション層の問題、インテグレーションの失敗、計画メンテナンスのエラー予算なし)
SLO ドキュメント⚠️ ユーザー対応ビジネス能力ではなく技術コンポーネントごとに定義された SLO (コンポーネントの可用性は必要だが、ユーザーエクスペリエンスの信頼性のためには不十分)

パターン

参照すべき場所外観
地域展開戦略✅ プラットフォームで管理されるHyperforce冗長性を使用した単一リージョンの導入(複数の可用性ゾーン、自動インフラストラクチャ フェールオーバー)により、ほとんどのソリューションで99.9%のSLOを実現
複数組織アーキテクチャ✅ プラットフォーム機能を超えたRPO/RTOの保証、規制対象の地理的データの分離、または地域の完全な独立性(データ同期によるアクティブ-パッシブまたはアクティブ-アクティブ)がビジネスで必要な場合のみ、マルチ組織パターン
データレプリケーション✅ 重要データの変更データキャプチャ (ほぼリアルタイムの RPO、分)、ほぼリアルタイムのビジネスイベント用のプラットフォームイベント、参照データ用のスケジュール済み Bulk API 2.0 抽出 (24 時間 RPO)
プラットフォームの状態監視✅ Trust.salesforce.com状況通知とインスタンス固有の状況APIへの登録により、インシデント、メンテナンス期間、パフォーマンスへの影響へのプロアクティブな対応が可能
動的負荷管理✅ ソリューションは、劣化時の重要でないバッチ処理を減らし、メンテナンス期間中のバックグラウンドジョブを延期することで、プラットフォームの健全性に対応します。
スケールセンターの使用✅ 週次スケール センター レビューにより、リソースに偏りがある実行時間の長いトランザクションと運用を特定し、ユーザーへの影響が生じる前にアーキテクチャを修正できます。
障害検出レイヤー✅ マルチレベルの検出:ステータスAPIによるプラットフォーム障害、タイムアウト監視によるインテグレーション障害、例外ログによるアプリケーション障害、レイテンシ パーセンタイルによるパフォーマンス低下、Proactive Monitoringによる容量警告
アラートしきい値✅ アラートはエラー率パターン (60 秒で API タイムアウトが 5 回など) または持続的な低下でトリガーされ、分散システムで通常発生する分離された障害ではありません。

アンチパターン

参照すべき場所どんな悪い感じか
複数組織設計⚠️ データ同期、ユーザープロビジョニング、リリース調整の運用の複雑さを正当化するビジネス要件が文書化されていない「念のため」実装されたマルチ組織アーキテクチャ
プラットフォームの状態監視⚠️ Trust.salesforce.comの状況通知を無視し、ユーザーから障害の報告を受けたときにメンテナンス ウィンドウを検出する(プロアクティブな対応ではなくリアクティブな対応)
障害検出⚠️ レートに関係なく個々のエラーごとにアラートを表示 (アラートの疲労度が重要なシグナルを非表示)、シングル API タイムアウトでページアウトをトリガー (通常の分散システムの動作に過剰反応)
データレプリケーション⚠️ インテグレーション固有の監視はなく、ユーザーがブロックされた操作を報告したときにのみインテグレーション障害を検出します (外部システムの正常性を確認できません)
冗長性戦略⚠️ タイムアウトやフォールバックのない外部強化サービスへの同期コールアウト (外部サービスが低速または対応できない場合にユーザーがブロックされる)

パターン

参照すべき場所外観
リアルユーザー監視 (rum)✅ Experience Cloud 分析またはカスタム計測で測定された実際のユーザー遅延 (実際のネットワーク状況、デバイスパフォーマンス、地理的分布を反映)
合成監視✅ ユーザーが問題を報告する前に、複数のロケーションから対応可能状況とパフォーマンスを検証する自動トランザクション (例: 3 つのリージョンから 15 分ごとに注文を送信)
トランザクション追跡✅ ボトルネックを特定するステップごとのタイミングを使用して計測される複数ステップの操作 (例: ステップ 3 アドレス検証コールアウトが合計レイテンシの 70% を占める)
クエリの最適化✅ インデックス付き検索条件を使用した選択的なクエリ、往復を削減するリレーションクエリ、本番規模のデータ量に関するクエリオプティマイザーの考慮事項 (1000 万件以上のレコードで動作が劇的に変化)
プラットフォームキャッシュの使用状況✅ 頻繁にアクセスされる参照データを提供するセッションまたは組織のキャッシュパーティション。操作が成功すると自動的に入力され、リアルタイム API が使用できない場合に古いが使用可能なデータが提供されます。
タイムアウト設定✅ ユーザー向けの同期コールアウトは 5 ～ 10 秒 (応答型 UI)、バックグラウンド非同期コールアウトは 30 ～ 60 秒 (外部パフォーマンスは可変)、一括処理は 120 秒 (ユーザーは待機なし)、トランザクションあたりの複数のコールアウトの予算合計
インテグレーション遅延の監視✅ エンドポイントごとのSLOとのインテグレーションあたりのp50/p95/p99のレイテンシーパーセント。レイテンシーの異常(レスポンスタイムが上昇)は、完全な障害が発生する前の業務量の飽和を示します。

アンチパターン

参照すべき場所どんな悪い感じか
監視戦略⚠️ ユーザー向けフローメジャメントを使用せずにインフラストラクチャメジャメント (サーバー CPU、ネットワーク帯域幅) のみを監視する (メジャメントは実際のユーザーエクスペリエンスを反映しない)
キャッシュ戦略⚠️ 頻繁にアクセスされる参照データでプラットフォームキャッシュが使用されていない (同じデータに対してクエリを繰り返すと、遅延が増大し、SOQL 制限が消費される)
タイムアウト設定⚠️ 120 秒のタイムアウトがある同期フローコールアウトにより、ユーザーは読み込み中のスピナーを 2 分間見つめます (代替で 5 ～ 10 秒のタイムアウトを使用する必要があります)。
パフォーマンステスト⚠️ 最小限のデータ量での小規模なテスト (1000 万件以上のレコードでクエリオプティマイザーの動作が劇的に変化し、小規模な結果が誤解を招く)
インテグレーション設計⚠️ 複数ステップのワークフローのトランザクションレベルの追跡なし (集計指標ではボトルネックステップは非表示)

パターン

参照すべき場所外観
横方向のスケールパターン✅ ワークロードが複数のリソースに分散される: 一括処理ではトランザクションごとに複数のレコードを処理し、非同期処理では作業の経時的な分散を行い、データパーティショニングでは境界を越えて負荷を分散します。
一括処理設定✅ スループットとガバナ制限のバランスを取る最適なバッチ サイズ(バッチApex実行あたり2,000レコード、トリガー呼び出しあたり200レコード、複合APIコールあたり25要求)
API レート管理✅ インテグレーションのバッチ処理とキャッシュにより API 消費を削減し、エディションごとに 24 時間の API 割り当てを監視します。業務量計画は、ライセンスを追加するか、枯渇する前に増加を制限します。
同時実行✅ パーティション分割されたデータの並列一括処理ジョブ (5 つの地域積み上げ集計バッチを同時に実行)、プラットフォームイベント登録者によるストリームの同時処理
キュー深度の監視✅ 非同期インテグレーションの場合、キュー深度のトレンドは、処理が生産レートに遅れをとっていることを示し、容量の増加やスループットの最適化が必要
ボリューム異常検出✅ トランザクション量が想定パターンを大幅に上回る/下回る場合、調査と調整が必要なプロセスが暴走する可能性があります。

アンチパターン

参照すべき場所どんな悪い感じか
一括処理⚠️ データ量でパーティション分割された並列実行が必要な場合、すべてのレコードを順次処理する (日付ベース、レコードタイプベース、または所有者ベースのパーティション分割で同時処理が可能)
API 消費⚠️ インテグレーションパターンでは、業務量計画なしで API 消費が 25% 追加されます (「API 制限を超えました」という突然のエラーはユーザーに影響します)。
キュー監視⚠️ 非同期インテグレーションキュー深度の監視なし (処理が可視化されていない生産レートに後れを取る)
ガバナ制限管理⚠️ ヒープサイズまたは CPU 時間制限に達する大量の処理を処理する同期操作 (専用の制限がある非同期処理に移行すべき)

パターン

参照すべき場所外観
機能重要度階層✅ 定義されたランク: 重要 (収益/コンプライアンス、低下なし)、重要 (コアワークフロー、重大インシデント時のみ低下)、サポート (エクスペリエンスの向上、インテグレーション失敗時に無効化)、省略可能 (必須、高負荷時に無効化)
Circuit Breaker の実装✅ 回線状態 (Closed = 正常、Open = しきい値の直後に失敗、Half-open = 回復プローブ)、プラットフォームキャッシュの保存状態、プラットフォームイベントブロードキャストの変更、連続失敗 (例: 10 失敗) 後に開く
再試行ロジック✅ 一時的な失敗の指数バックオフ (1s、2s、4s、8s、30-60s での上限)、バックオフによるネットワークタイムアウトと 5xx エラーの再試行、Retry-After ヘッダー後の 429 レート制限の再試行、同じトランザクションでのクライアント 4xx エラーまたはガバナ制限エラーの再試行なし
代替戦略✅ 代替データソース (リアルタイム API が使用できない場合のプラットフォームキャッシュ)、デフォルト動作 (パーソナライズサービスが停止している場合の標準ルール)、手動プロセス (停滞しているトランザクションの管理インターフェース)、再試行キュー (72 時間再生のプラットフォームイベント)
エラー処理アーキテクチャ✅ 迅速な失敗 (入力時に入力を検証)、正常な失敗 (3 回の検証失敗で 200 件のレコードのうち 197 件を処理)、情報に基づいた失敗 (トランザクション ID、ユーザーコンテキスト、スタック追跡を含むログを記録)、安全な失敗 (部分的なトランザクションをロールバックし、内部をユーザーに公開しない)
リカバリの自動化✅ プラットフォーム監視によって自動復旧がトリガーされる: 非同期再試行メカニズム、失敗した処理のデッドレターキュー、手動操作なしで迅速な復旧を可能にする自動復旧ワークフロー

アンチパターン

参照すべき場所どんな悪い感じか
インテグレーション連動関係⚠️ 外部住所検証サービスがダウンすると、注文の送信が完全に失敗する (重要なフローがサポート機能でブロックされているため、手動レビューで適切に機能しない)
Circuit Breaker 戦略⚠️ 外部コールアウトでサーキットブレーカーが発生しないため、外部システムがダウンしたときにすべてのトランザクションがタイムアウトするまで 120 秒待機する (すべてのユーザーは 1 つのインテグレーションの失敗の影響を受ける)
再試行ロジック⚠️ Retry Apex CPU limit exceeded immediately in the same transaction context （同じトランザクション コンテキストで Apex CPU 制限をすぐに再試行してください。） エラー （再度失敗します。専用の制限のある非同期操作として再キューする必要があります）
再試行ロジック⚠️ 成功するまで無期限に再試行する (無限ループのリスク、トランザクションは完了しません。最大再試行回数の上限を設定する必要があります)
エラー処理⚠️ Try-catch ブロックは、ログのない例外を飲み込みます (診断と修正を妨げているオペレーターには見えない失敗)
エラー処理⚠️ Lightningページでエンドユーザーへのスタック トレースを表示(実装の詳細を明らかにするセキュリティ リスク、ユーザー エクスペリエンスの低下)
フォールバック戦略⚠️ 税金計算サービスですべての注文送信のブロックに失敗する (フォールバックのない重要な機能。手動処理のキューに入れるか、デフォルトのレートを使用)

パターン

参照すべき場所外観
健康モデリング✅ 稼働状況の集計: サービスの稼働状況 (トランザクションの成功率が緑で 99.5 % 、 黄色で 98 ～ 99.5 % 、 赤色で 98% 未満)、インテグレーションの稼働状況 (すべて応答が緑、黄色が劣化、サーキットブレーカーが赤でオープン)、データの稼働状況 (同期電流が緑、黄色が背景、古い/失敗した赤)、業務量の稼働状況 (緑で 70%、黄色で 70 ～ 85%、赤色で 85% 未満)
イベントモニタリング✅ 24時間/1時間の配信で外部SIEMにルーティングされ、ネイティブの保存制限を超えて保持されるEventLogFileオブジェクト。APIコール、ページ ビュー、レポートのエクスポート、ログイン アクティビティ、Apex実行をキャプチャ
Proactive Monitoringアラート✅ APIリクエスト制限の急増(75%のしきい値に達すると調査がトリガーされる)、Apex同時実行の失敗、SOQL行制限の問題、ストレージ消費トレンドを継続的に評価
Integration Health (インテグレーション状態) ダッシュボード✅ インテグレーションごとの評価指標: エラー率 (1% 未満目標)、SLO を使用した遅延 p50/p95/p99、タイムアウト率 (0.1% 未満目標)、サーキットブレーカーの状態、非同期キュー深度、要求 ID、エンドポイント、応答コード、期間を含む構造化ログ
アクション可能なアラート設計✅ すべてのアラートで、対応するユーザー、チェックする内容、修正方法を定義します。しきい値の超過、現在の値、最近のトレンド、ダッシュボードリンク、ランブックリンク、緊急度に応じた重要度が含まれます (ユーザーへの影響に関する重要なオンコールページ、トレンドの懸念に関する警告メール)。
異常検知✅ ボリューム異常 (標準負荷の 300%)、エラー率異常 (しきい値 5% 未満でも標準 2% 対 0.5%)、レイテンシドリフト (徐々に上昇トレンド)、行動異常 (異常なログインパターン、スケジュール外の一括処理ジョブ)。調査のガイドとして使用し、即時エスカレーションをトリガーしない

アンチパターン

参照すべき場所どんな悪い感じか
イベントモニタリング⚠️ イベントモニタリングが有効になっているがエクスポートされていない (トレンド分析にネイティブ保持が不十分、履歴データが失われている)
アラート設計⚠️ コンテキスト、しきい値、応答アクションのないアラートメッセージ「エラーが発生しました」 (アラート疲労が生成され、オペレーターは効果的にトリアージできません)
アラートの重要度⚠️ すべての異常を重要なアラートとして処理する (偽陽性率が高いとアラートの疲労感が生じ、重要なアラートが見落とされる)
状態監視⚠️ 集計健康モデルがなく、個々の技術評価指標でオペレーターが圧倒され、クロスシステムパターンがない
インテグレーション監視⚠️ インテグレーション固有のエラー率、遅延、回路ブレーカーの状態追跡がない (インテグレーション障害がユーザーレポートによって事後的に検出される)
業務量監視⚠️ Proactive MonitoringまたはScale Centerのレビューなし(リソースを大量に消費するトランザクションの信頼性リスクは本番環境に影響するまで検出されません)

インラインの例と詳細なガイダンスについては、信頼性の柱を参照するか、パターンとアンチパターンのエクスプローラーを参照してください。