Salesforceデータアーカイブ戦略：パフォーマンスとストレージを最適化するためのアーキテクト向けガイド

日付:

背景と適用シナリオ

Salesforceアーキテクトとして、我々の重要な責務の一つは、プラットフォームの長期的な健全性、スケーラビリティ、そしてコスト効率を確保することです。組織が成長し、ビジネスが拡大するにつれて、Salesforceに蓄積されるデータ量は指数関数的に増加します。このデータの増加は、最初は成功の証と見なされますが、やがて看過できない技術的負債へと変わる可能性があります。

データ量の増大は、具体的に以下のような課題を引き起こします。

パフォーマンスの低下

数百万、数千万件のレコードを抱えるオブジェクトは、レポートの実行、リストビューの表示、SOQLクエリの応答時間を著しく悪化させます。特に、親子関係が複雑なオブジェクトで発生する Data Skew (データスキュー：特定の親レコードに大量の子レコードが紐づく状態) は、ロック競合を引き起こし、システムの応答性を全体的に低下させる原因となります。ユーザーエクスペリエンスの低下は、最終的にSalesforceの利用率や業務効率の低下に直結します。

ストレージコストの増大

Salesforceのデータストレージは有限であり、決して安価ではありません。契約上のストレージ上限を超過すると、追加のストレージを購入する必要が生じ、Total Cost of Ownership (TCO) (総所有コスト) を押し上げます。戦略的なデータ管理なしには、ストレージコストは際限なく増加し続けます。

ガバナンスとコンプライアンス要件

GDPR (EU一般データ保護規則) やCCPA (カリフォルニア州消費者プライバシー法) といったデータ保護規制は、企業に対して厳格なデータ保持ポリシーの策定と遵守を求めています。不要になったデータを無期限に保持し続けることは、コンプライアンス上のリスクを高める行為です。データアーカイブは、定められた保持期間を過ぎたデータを安全に隔離・管理するための重要なプロセスです。

俊敏性の低下

肥大化したデータは、Sandboxの作成や更新にかかる時間を増大させ、開発やテストのサイクルを遅延させます。また、データモデルの変更や大規模なデータ移行プロジェクトを計画する際にも、その複雑性とリスクを増大させる要因となります。

これらの課題に対処するため、効果的な「データアーカイブ戦略」の設計と実装は、Salesforceアーキテクトにとって避けては通れない重要なテーマなのです。本稿では、その戦略立案の考え方、主要な技術パターン、そして実装における注意点について詳説します。

原理説明

データアーカイブとは、アクティブな業務では利用されなくなったが、コンプライアンスや将来の分析のために保持する必要があるデータを、プライマリストレージ（Salesforceの標準・カスタムオブジェクト）から、より低コストなセカンダリストレージへ移動させるプロセスを指します。これは、単なるバックアップ（災害復旧目的のデータコピー）とは目的が異なります。

優れたアーカイブ戦略は、以下の要素で構成されます。

  1. 識別 (Identification): どのデータを「非アクティブ」と見なすかの基準を定義します。（例：「完了してから5年以上経過したケース」）
  2. 抽出 (Extraction): 対象データをSalesforceから安全かつ効率的に抽出します。
  3. 保管 (Storage): 抽出したデータを適切なセカンダリストレージに保管します。
  4. 削除 (Deletion): プライマリストレージから抽出済みデータを安全に削除します。
  5. アクセスと復元 (Access and Restoration): 必要に応じて、アーカイブされたデータにアクセスまたは復元する手段を確保します。

アーカイブソリューションの主要パターン

アーキテクチャの観点から、ソリューションは大きく「On-Platform」と「Off-Platform」の2つのパターンに分類されます。

1. On-Platform アーカイブ: Big Objects

Big Objects (ビッグオブジェクト) は、Salesforceプラットフォーム上で数十億件規模のレコードを格納・管理するために設計された特殊なオブジェクトです。非同期SOQL (Async SOQL) を用いてクエリを実行し、大量のデータを扱うことができます。

  • 利点:
    • データがSalesforceエコシステム内に留まるため、セキュリティとガバナンスの管理が比較的容易。
    • Salesforceの標準的な認証・認可モデルを利用できる。
    • 外部システムとの連携が不要なため、アーキテクチャがシンプル。
  • 欠点:
    • 標準UI（レコード詳細ページやリストビュー）が存在しない。データアクセスにはカスタムUI (Lightning Web Componentsなど) の開発が必須。
    • 標準レポートやダッシュボードで直接利用できない。
    • リレーショナルデータベースではないため、複雑なJOIN操作には不向き。

2. Off-Platform アーカイブ: 外部システム連携

Salesforce外のデータベースやストレージサービスを利用するアプローチです。選択肢は多岐にわたり、要件に応じて最適なものを選択します。

  • Heroku (Heroku Connect & Heroku Postgres): Heroku Connectを使用してSalesforceのデータをHeroku Postgresデータベースに同期します。アーカイブ対象データをPostgresに移動させ、Salesforce側から削除します。Salesforce Connect を利用して、アーカイブデータを外部オブジェクトとしてSalesforce UI上に表示することも可能です。
  • データウェアハウス (Snowflake, Google BigQuery, Amazon Redshift): MuleSoftやInformaticaなどのETL/iPaaSツールを利用して、データを抽出し、データウェアハウスに格納します。このパターンは、アーカイブデータを他の業務データと統合して高度な分析を行いたい場合に特に有効です。
  • クラウドストレージ (Amazon S3, Azure Blob Storage): 最もコスト効率が高い選択肢です。Bulk API 2.0でデータをCSV形式などで抽出し、クラウドストレージにファイルとして保管します。データへのアクセス性は低下するため、コンプライアンス目的の「コールドストレージ」として利用されることが多いです。

どのパターンを選択するかは、コスト、データのアクセス頻度、セキュリティ要件、既存の技術スタックなどを総合的に評価して決定する必要があります。

サンプルコード

Off-Platform アーカイブ戦略の「抽出」フェーズで最も一般的に使用されるのが Bulk API 2.0 です。ここでは、Bulk API 2.0を使用して「完了してから5年以上経過したケース」を抽出するジョブを作成するcURLコマンドの例を示します。これは、自動化スクリプトやETLジョブの基礎となるものです。

この例は、Salesforce REST API を使用して、指定した SOQL クエリを実行するクエリジョブを作成する方法を示しています。 

# 1. cURLコマンドの準備
# MyDomainName: 組織の[私のドメイン]名に置き換えてください
# 44.0: 使用するAPIバージョン
# YOUR_ACCESS_TOKEN: OAuth 2.0フローで取得したアクセストークン
# このコマンドは、Bulk API 2.0のクエリジョブを作成エンドポイントにPOSTリクエストを送信します。

curl https://MyDomainName.my.salesforce.com/services/data/v44.0/jobs/query -X POST -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -H "Content-Type: application/json; charset=UTF-8" -H "Accept: application/json" -d '{
  "operation" : "query",
  "query" : "SELECT Id, CaseNumber, Status, IsClosed, ClosedDate, CreatedDate FROM Case WHERE IsClosed = true AND ClosedDate < LAST_N_YEARS:5"
}'

# 2. JSONペイロードの詳細
# {
#   "operation" : "query",
#   // operation: 実行する操作を指定します。ここでは 'query' を指定します。
#
#   "query" : "SELECT Id, CaseNumber, Status, IsClosed, ClosedDate, CreatedDate FROM Case WHERE IsClosed = true AND ClosedDate < LAST_N_YEARS:5"
#   // query: 実行するSOQLクエリです。
#   // このクエリは、クローズ済み(IsClosed = true)で、かつ最終クローズ日(ClosedDate)が
#   // 5年以上前のケースレコードをすべて選択します。
#   // LAST_N_YEARS:5 のような日付リテラルを使用することで、動的な日付指定が可能です。
#   // アーカイブ対象のレコードを正確に特定することが、このプロセスの第一歩です。
# }

# 3. 成功した場合のレスポンス (例)
# レスポンスとして、作成されたジョブに関する情報がJSON形式で返されます。
# このID (id) を使用して、後続の処理でジョブの状態を確認したり、結果を取得したりします。
# {
#   "id" : "750R0000000zLLhIAM",
#   "operation" : "query",
#   "object" : "Case",
#   "createdById" : "005R0000000cw8OIAQ",
#   "createdDate" : "2018-12-07T19:59:11.000+0000",
#   "systemModstamp" : "2018-12-07T19:59:11.000+0000",
#   "state" : "UploadComplete",
#   "concurrencyMode" : "Parallel",
#   "contentType" : "CSV",
#   "apiVersion" : 44.0,
#   "jobType" : "V2Query"
# }

このコードは、Salesforce Bulk API 2.0 and Bulk API Developer Guide に記載されている公式な手法に基づいています。このAPIコールを起点として、ジョブの完了をポーリングし、完了後に結果セットをダウンロード、そして最後にSalesforceから対象レコードを削除する、という一連の自動化プロセスを構築します。

注意事項

データアーカイブ戦略を実装する際には、アーキテクトとして以下の点に細心の注意を払う必要があります。

データ整合性とリレーションの維持

Salesforceのデータは、オブジェクト間で複雑な親子関係や参照関係を持っています。例えば、取引先(Account)をアーカイブする際に、関連する商談(Opportunity)やケース(Case)を考慮しないと、データ間の整合性が失われ、孤立したレコードが残ってしまいます。アーカイブおよび削除の順序（通常は子オブジェクトから親オブジェクトの順）を慎重に設計する必要があります。

権限とセキュリティ

データ抽出を行うAPIユーザーには、対象オブジェクトに対する適切なCRUD権限と「APIの有効化」権限が必要です。また、アーカイブデータを保管する外部システムのセキュリティも同様に重要です。誰がそのデータにアクセスできるのか、暗号化はされているかなど、Salesforceと同等レベルのセキュリティポリシーを適用する必要があります。

APIガバナ制限 (API Governor Limits)

Salesforceには、24時間あたりのAPIコール数やBulk APIのジョブ数に上限が設けられています。大規模なアーカイブ処理を計画する場合、これらの API Governor Limits (APIガバナ制限) に抵触しないよう、ジョブの実行タイミングやデータ量を調整する設計が不可欠です。

エラーハンドリングと監査

アーカイブはクリティカルなプロセスです。抽出、保管、削除の各ステップでエラーが発生した場合の再試行ロジックや、失敗時に管理者に通知する仕組みを必ず実装してください。また、どのレコードがいつ、誰によってアーカイブされたのかを追跡するための監査ログを保持することも、ガバナンスの観点から非常に重要です。

データへのアクセス方法の確保

「アーカイブはしたが、誰もデータを見ることができない」という状況は避けなければなりません。アーカイブ後のデータにビジネスユーザーがどのようにアクセスするか、その要件を事前に定義し、実装する必要があります。Salesforce Connectによる外部オブジェクトとしての表示、外部システム上のレポートへのリンク提供、あるいは特定の要求に応じてデータを復元するプロセスなど、具体的なアクセス手段を設計に含めるべきです。

まとめとベストプラクティス

効果的なデータアーカイブ戦略は、単なる技術的な課題解決に留まらず、Salesforceプラットフォームの持続的な価値を最大化するための経営課題です。アーキテクトとして、以下のベストプラクティスを念頭に置いて戦略を推進することが成功の鍵となります。

  1. データライフサイクルポリシーの策定から始める: 技術的な実装に着手する前に、まずビジネス部門のステークホルダーを巻き込み、全社的なデータ保持・アーカイブポリシーを定義します。どのデータを、いつ、どこへ、どのようにアーカイブし、誰がアクセスできるのかを明確に文書化します。
  2. 適切なツールを適切な目的で選択する: すべての要件を満たす万能なソリューションはありません。プラットフォーム内で完結させたい場合はBig Objects、高度な分析が主目的ならデータウェアハウス、低コストな長期保管が目的ならクラウドストレージ、といったように、要件に最適なアーキテクチャパターンを選択します。
  3. 徹底的なテスト: Full Sandbox環境で、アーカイブプロセス全体（抽出、保管、削除、アクセス、復元）のエンドツーエンドテストを必ず実施します。特に、リレーションの整合性が保たれているか、削除処理が意図しないデータを消していないかなどを入念に検証します。
  4. 自動化と監視: アーカイブプロセスは手動で行うべきではありません。スケジュール化されたバッチ処理として自動化し、その実行状況を監視する仕組みを構築します。エラー発生時には即座に対応できる体制を整えます。
  5. 小さく始めてスケールさせる: 最初からすべてのオブジェクトを対象にするのではなく、影響範囲が比較的小さく、ビジネスインパクトが明確なオブジェクト（例：活動履歴(Task/Event)など）をパイロットプロジェクトとして選定し、そこで得られた知見を基に全社展開を図るのが賢明なアプローチです。

データアーカイブは、一度実装して終わりではありません。ビジネスの変化に応じてポリシーを見直し、継続的に改善していくプロセスです。戦略的な視点を持ってこの課題に取り組むことで、Salesforceは将来にわたって俊敏で高性能なプラットフォームであり続けることができるでしょう。

コメント

コメントを投稿