こんにちは、CE課（コーポレートエンジニアリング課）の江利です。
この記事ではSalesforceエンジニア歴12年の筆者が2023年に初めて実際に目にした、こんなエラーあったんだーまあ確かに必要だよねーという感じのエラーを起きた状況や対応策を交えて紹介したいと思います。
- サインインエラー: 「ログイン数超過」（LOGIN_RATE_EXCEEDED）
- 削除処理対象が多すぎます（DELETE_OPERATION_TOO_LARGE）
- データのエクスポートに関する FAQ
- まとめ
サインインエラー: 「ログイン数超過」（LOGIN_RATE_EXCEEDED）
https://help.salesforce.com/s/articleView?id=000381578&type=1
こちらはとあるAppExchangeを導入した際にアプリベンダーさんにてデータインポートを実施いただいたタイミングで発生しました。 インポートツールがガバナ制限を考慮された作りになっておらず、1レコード挿入ごとにログイン処理を行っていたことに起因するものではないかと想像されます。
API処理全般を担うユーザーで実行していたため他システムとの連携に影響がありました。
解決策としては下記のことを実施しました。
- アプリベンダーさんに連絡し、インポート処理を一旦停止してもらった
- 新たに対象AppExchange専用ユーザーを作成した
事前にsandbox組織にてインポートのテストを実行していただくべきだったと反省しています。
本エラーはユーザあたり 3,600 回/時を超えるログイン要求はブロックされる（1秒につき1回ログインすると1時間あたり3,600）という制限によるため人間がこのエラーを発生させることはまず考えにくいです。
1 時間待ってから再度ログインを試みる。
と公式Helpに記載されていますが、実際は1時間あたりの制限となるため毎時0分になると一旦リセットされます。
2023年3月14日より使用可能になったSalesforceインテグレーションユーザーライセンスが無償で5ライセンス提供されているので、複数の外部システムと連携している場合はシステムごとにユーザーを分けることをおすすめします。
https://help.salesforce.com/s/articleView?id=sf.security_platform_integration_user.htm&type=5
この制限がなければ、悪意を持ったユーザーが無限にログインするスクリプトでサーバーの負荷を上げ放題なので、まあ確かに必要だよねーということです。
削除処理対象が多すぎます（DELETE_OPERATION_TOO_LARGE）
https://help.salesforce.com/s/articleView?id=000382586&type=1
こちらは日次のバッチ処理にてカスタムオブジェクトの洗い替えを行っている際に発生しました。
洗い替え対象のオブジェクトは主従関係の親オブジェクトで、Bulk APIの削除処理によって子オブジェクトもカスケード削除されています。
本エラーは1トランザクション内でのカスケード削除が親子合算で100,000レコードまでという制限により発生します。
実はサーバーワークスでは以前にもこのエラーが同じ処理にて発生したことがあったそうです。その際には親オブジェクト削除時のチャンク数を少し減らすという応急処置を行ったそうです。
今回も一次対応としてさらにチャンク数を少し減らす応急処置を行いました。その後に改めて、根本改善を行うためにチャンク数を固定値ではなく親子の数を100,000レコードの制限ギリギリまで動的に取得するような実装を行い回避する対策を取りました。
1件の親レコードに大量の子レコードが紐付いている場合に発生する可能性があるためデータローダーやリストビューからの一括削除時にも同様のエラーが発生する恐れがありますが、その場合はバッチサイズを小さくしたりリストビューでの選択レコード件数を減らすなどの方法で対処できると思います。あまりないとは思いますがそもそも子レコード自体が100,000レコードあるような場合は先に子レコードをどうにかしろという話ですね。
この制限がなければ、想像もしないような大量の子レコードを持つ親レコードの削除に伴うカスケード削除時にサーバーに恐ろしく負荷がかかりそうなので、まあ確かに必要だよねーということです。
データのエクスポートに関する FAQ
こちらはエラーではないのですが、意外と知らなかったことだったので取り上げてみました。
バックアップ目的でウィークリーエクスポートを利用している方も多いと思います。サーバーワークスでも毎週ウィークリーエクスポートを利用してバックアップを取得しています。
先日サーバーワークスのSalesforce組織ではインスタンス変更が実施されたのですが、インスタンス変更後最初のウィークリーエクスポート実行時に通常であれば完了通知が届く時間帯にも完了通知が届かないばかりか翌日になっても完了通知が届かないということがありました。（完了までに1週間以上を要しました）
Salesforce社に問い合わせところデータエクスポートに関するSLAはないという回答がありました。*1
なお、Salesforce社にて時間がかかった原因を調査いただいたところ、ごみ箱内の物理削除待ちレコードが多いことによるとの指摘がありました。こちらは前述の洗い替えによる影響であることは明白だったため一次対応として実行ユーザーでログインしごみ箱を空にしました。また、恒久対策としてバッチ処理時の削除を物理削除に変更しました。
こちらも確かに追加容量マシマシの組織でレコード数爆増オブジェクトがあった場合などのエクスポートに対してのSLA担保できるわけないかーということですね。
まとめ
今回紹介した内容は、いずれも考えてみれば確かにそうだよなというものばかりでした。普段何気なく使っているとそれほど頻繁に発生するようなエラーではありませんが、実際に発生した際にエラーコードで検索しても公式Helpくらいしか情報がなかったので、この記事がどなたかの障害対応の一助となればと思います。それでは良きSalesforceライフを！
*1:確かに公式Helpにも明記されていました https://help.salesforce.com/s/articleView?id=000383962&type=1 の6
江利 義陽(記事一覧)
CE部CE課でSalesforceエンジニアをやっています。Salesforce歴は12年目くらいなのでチョットだけわかります。
記事への質問やフィードバックは yoshiaki.eri@serverworks.co.jp までお願いいたします。
Trailblazer プロファイル
