最終更新日: 2024 年 10 月 3 日
サイト切り替えとは?
各 Salesforce インスタンスは 2 つの地理的に異なる場所に構築され、維持されています。インスタンスは一方の場所 (有効サイト) から有効に提供され、ほぼリアルタイムで、もう一方の完全に冗長な場所 (予備サイト) でトランザクションが複製されます。サイト切り替えとは、インスタンスの有効サイトと予備サイトの場所を入れ替えて、予備サイトを新しい有効サイト、有効サイトを新しい予備サイトにすることです。インスタンス名は変更されません。このインフラストラクチャモデルを使用することで、メンテナンス、コンプライアンス、障害回復のために有効サイトの場所を切り替えることができます。
重要な作業
A.サイト切り替えが実施された場合に通知を受け取れるように Trust Notifications に登録してください。
B.Salesforce インフラストラクチャのベストプラクティスに従って、アクセス先を Salesforce の IP 範囲や Government Cloud の IP 範囲に制限せず、ハードコード化された参照を削除し、DNS タイムアウト値を 5 分間 (デフォルト設定) に設定します。
C.Live Agent/SOS カスタムクライアントを使用している場合は、これらのクライアントが新しい有効サイトへのリダイレクトを適切に処理できることを確認する必要があります。適切に処理できないと、Live Agent サービスが機能しなくなる場合があります。これらの問題を回避する最適な方法は、SwitchServer 応答を処理し、この応答の要求と後続のすべての要求で「newUrl」プロパティを使用します。 詳細は、質問 8 を参照して下さい。
D.サイト切り替えの後にメールログを表示する必要がある場合、メンテナンス実施時間の前にメールログを要求します。詳細は、質問 11 を参照してください。
E.クライアントエンドポイント (例: PC) とインターネットサービスプロバイダ (ISP) の両方でDNS キャッシュを更新することが重要です。場合によっては、Salesforce に起因しない潜在的なログインの問題を緩和するために、DNS テーブルの更新を ISP に依頼する必要があります。
よくある質問
1. サイト切り替えは、どのような方法で通知されますか?
サイト切り替えの予定は、Trust サイトのメンテナンスカレンダー (status.salesforce.com) に掲載されます。インシデント発生中にインスタンスをオンラインに戻すためにサイト切り替えを実行する必要があった場合、status.salesforce.com のインシデント記録が更新されてその情報が反映されます。ご利用のインスタンスに関する Trust Notification にサインアップすると、メンテナンス通知メール (リマインダー、開始、更新、完了) およびインシデント通知メール (新規、更新、解決、根本原因) を受信できます。これらのメールにサインアップする方法についての詳細は、「Trust Notification User Guide (Trust Notification ユーザガイド)」を参照してください。
2. サイト切り替えにはどの程度の時間を要しますか?
現在、サイト切り替えの完了までには約 20 分かかります。計画サイト切り替えについては、サイト切り替え作業の予想所要時間を Trust に掲載しています。
3. サイト切り替えから除外されるように指定することはできますか?
個別の組織をサイト切り替えから除外することはできません。Salesforce のインフラストラクチャではマルチテナントアーキテクチャを採用しているため、インスタンス上のすべての組織に対して同時にサイト切り替えを行う必要があります。
計画サイト切り替えは、優先システムメンテナンス実施時間内にのみスケジュールされます。お客様の Salesforce 組織のメンテナンス作業 (ソフトウェアのアップグレード、インテグレーションの変更など) は、優先システムメンテナンス実施時間以外にスケジュールしていただきますようお願い申し上げます。
4.サイト切り替え中に組織にアクセスできますか?
計画サイト切り替えの作業中は、お客様の組織はご利用いただけなくなります。サイト切り替えは約 20 分で完了するようになりました。サイト切り替え中はインスタンスを使用不可とみなすことをお勧めします。
5.サイト切り替えの準備に必要な作業は何ですか?
インフラストラクチャのベストプラクティスに従って、アクセス先を Salesforce の IP 範囲に制限せずに、DNS タイムアウト値を 5 分間 (デフォルト設定) に設定している場合は、サイト切り替えはユーザに対してシームレスに行われます。
アクセス先を特定の IP 範囲またはデータセンターに制限している場合は、サイト切り替え後に意図しないサービス中断を避けるために Salesforce の IP 範囲の完全なリストが含まれるようにネットワーク設定を更新してください。また、DNS タイムアウト値セットを制御している場合は、メンテナンス後に DNS キャッシュを更新し、すべてのインテグレーションを再起動することが必要になる場合があります。
6. サイト切り替えによって、以前からスケジュールされていたアクティビティ (ウィークリーエクスポート、Apex ジョブなど) と Apex コールアウトはどのような影響を受けますか?
継続中のアクティビティは、サイト切り替え前に一時停止され、サイト切り替え後に再開されます。サイト切り替え中にスケジュールされたアクティビティは、サイト切り替え後に開始されます。
サイト切り替え前に開始された Apex、Batch Apex、REST API、SOAP API、および Bulk API ジョブの一部は、メンテナンス期間後にエラーになる可能性があります。以前にスケジュールされていたジョブがメンテナンス期間後にエラーになった場合は、ジョブを再起動すれば正常な結果に戻ります。業務をシームレスに進めるために、サイト切り替えが完了してから、大きなジョブや長時間実行ジョブのスケジュールを変更することをお勧めします。
メンテナンス期間中は、外部サービスへの Apex コールアウトは実行されません。メンテナンス期間中は、このようなコールアウトが実行されないようにすることをお勧めします。このようなコールアウトが実行されないようにする方法についての詳細は、「Callout Limits and Limitations (コールアウトの制限と制限事項)」を参照してください。
7.サイト切り替えによって、Web-to-リード、Web-to-ケース、メール-to-ケースのアクティビティはどのような影響を受けますか?
サイト切り替え中に発生したメール-to-ケースはキューに入れられ、サイト切り替えの完了後に処理されます。Web-to-リードおよび Web-to-ケースは一時停止され、メンテナンス完了後に再開されます。
8.サイト切り替えは Live Agent に影響しますか?
はい。サイトの切り替え中は、組織の有効サイトが予備サイトの場所に、予備サイトの場所が有効サイトの場所に切り替わります。この処理が行われると、Live Agent/SOS へのアクセスに使用される URL が変わります。Salesforce から提供されるチャットクライアントとリリースコードは、この変更に対応して HTTP 要求を新しいエンドポイントに適切に転送しますが、一部のサードパーティまたはカスタムアプリケーション (Live Agent カスタム REST クライアントなど) はそのように動作しない可能性があります。これらのカスタムアプリケーションは、以前のインスタンスでアカウントを見つけることができず、失敗する可能性が高くなります。
Live Agent/SOS 実装への影響を最小限に抑えるには、ベストプラクティスに従って、組織の移動を伴うメンテナンスの後に Live Agent カスタム REST クライアントが Live Agent サービスの新しいインスタンスに要求を適切にリダイレクトできるようにします。カスタムクライアントでこれらの問題 (要求が自動的に適切なエンドポイントに転送されない) を回避する最適な方法は、SwitchServer 応答を処理し、この応答の要求と後続のすべての要求で「newUrl」プロパティを使用します。カスタムクライアントの更新とテストについての詳細は、ナレッジ記事「組織インスタンスの変更時に Live Agent カスタムクライアントを更新する方法」を参照してください。これにより、カスタムクライアントでサイト切り替え後に問題が発生しなくなり、実行開始時から使用されるエンドポイントを後で更新するために十分な時間を確保できます。
Live Agent エンドポイントについての詳細、およびハードコード化された Live Agent 参照の意味については、記事「Live Agent サーバ (エンドポイント URL) が変更された後、Live Agent チャットが機能しない」を参照してください。
9.サイト切り替えによって、継続中の Sandbox の更新はどのような影響を受けますか?
サイト切り替え前に完了していない Sandbox の更新は停止します。サイト切り替え後に Sandbox の更新が (再開ではなく) 再起動されます。また、お客様はサイト切り替え中に Sandbox の更新を開始できません。
10.サイト切り替えによって、メール送信 (モバイル通信業者や Office 365 への送信など) は影響を受けますか?
サイト切り替え後、メールは以前とは異なる IP を持つメール転送エージェント (MTA) から送信されます。これらの MTA は評価が確立されており、メール配信は影響を受けませんが、アクセス制御リスト (ACL) や許可リストによるメールリレーを使用している場合は例外です。このような場合は、記事「Salesforce IP Addresses and Domains to Allow (許可する Salesforce の IP アドレスとドメイン)」を参照して、必要に応じてメールリレー用の IP を ACL や許可リストに登録してください。メールリレーを使用しているかどうかを Salesforce で確認するには、[設定] に移動し、「メールリレーの有効化」を検索します。[有効] のチェックボックスが選択されていれば、メールは設定内に記述されているホストにメールリレーを使用して配信されています。
11.サイト切り替えの後にメールログを表示する予定がある場合、メンテナンスの前にメールログを要求しておく必要がありますか?
サイト切り替えの後にメールログを表示する必要がある場合、メンテナンス実施時間の前にメールログを要求しておく必要がありますメールログを要求するには、記事「Request an Email Log (メールログの要求)」の手順に従ってください。メールログが要求されると、メールログはデータベースに保存され、サイト切り替えメンテナンス時に移行されます。以前のデータセンターからのメールログは、サイト切り替え後には抽出できなくなります。
メンテナンス後の短期間 (最大 30 日間)、メールログにはメールが送信済みと表示されていても、メールの最終的な宛先が含まれないことがあります。これは、新しい有効サイトの IP が、大量のトラフィックを送信する前に、インターネットでの評価を確立する必要があるためです。
12.Salesforce の継続的サイト切り替えプログラムとは何ですか?
継続的サイト切り替えプログラムについての詳細は、記事「継続的サイト切り替え」を参照してください。
13. サイト切り替えはプラットフォームイベントおよびデータキャプチャにどのように影響しますか?
サイト切り替えは、Pub/Sub API、ストリーミング API、EMPApi Lightning コンポーネント、Apex トリガー、イベントリレー、フローなど、購読者が保持するイベントのストリームには影響しません。ただし、並列購読として使用される Apex トリガーが遅れていて、サイト切り替えが発生したときにすべてのイベントの処理が完了していない場合は、影響を受けます。この場合、Apexトリガーはサイト切り替え前に処理が完了していない処理を続行できません。サイト切り替え後、新しく公開されたイベントから並列購読が再開されます。
000387541

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.