Databricksへの移行を支援するツールを試してみた 1. はじめに NTTデータの丹羽です。Databricks Championとしても活動しています。 近年、既存のデータウェアハウス（DWH）からDatabricksへのマイグレーションを検討する機会が増えています。 Databricksでは、Teradataなどの既存DWHからDatabricksへの移行を支援するツールとして、Lakebridgeが提供されています。 本記事では、Databricks CLIおよびLakebridgeをセットアップし、TeradataのソースコードをDatabricks向けに変換するま

Weekly Google Cloud アップデート情報 - 2026年10月6日 皆さま、こんにちは。先週 (2026/09/25 - 2026/10/01) の主な Google Cloud（旧GCP）のアップデート情報を紹介します。 ※本記事の引用元:Google Cloud リリースノート 注目のアップデート Gemini Enterprise: アプリとデータストアのきめ細かなアクセス制御の構成 管理者は、Google Cloud コンソール、Google Cloud CLI、または REST API を使用して、特定の Gemini Enterprise アプリや

はじめに こんにちは。EC基盤開発本部 SRE部 カート決済SREの遠藤です。 普段はカート決済に関連する機能のリプレイスや保守運用をメインに、ZOZOTOWNのDBREとして活動しています。 近年、ランサムウェア攻撃が世界中で猛威を振るっており、企業のデータ保護は喫緊の課題となっています。特にデータベースは企業活動の根幹を支える重要な資産であり、万が一の攻撃に備えた対策が不可欠です。 本記事では、Everpure社（旧Pure Storage社）のストレージ製品「FlashArray」を活用したランサムウェア対策をご紹介します。対象はZOZOTOWNの基幹データベースであるMicrosoft SQL Serverです。 はじめに 概要 前提：Everpure FlashArrayとSafeMode FlashArrayの主な特徴 主な特徴・機能 スナップショットの容量効率と多世代保持 SafeModeによる不変スナップショット SafeModeのランサムウェア対策の仕組み 課題：FlashArray標準スナップショットによる運用上の問題 解決策：VSS連携によるSQL Serverスナップショットの取得 VSS連携の仕組み VSS連携の流れ VSSの3つのコンポーネント 検証：I/Oフリーズによるサービス影響 検証方法 検証結果 実装：スナップショット取得バッチの作成 全体構成 事前設定 クレデンシャルの登録 バックアップジョブの登録 バッチ実装 スナップショットの実行 運用：構成とモニタリング Protection Group と Snapshot Schedule の設計 実行タイミングの最適化 日常運用とモニタリング 展望：T-SQLスナップショットへの移行 各方式の比較 SQL Server 2022：VSSに依存しないスナップショットバックアップ SQL Server 2025：T-SQLで完結したスナップショットバックアップ まとめ 本取り組みのポイント 今後の展望 最後に 概要 本取り組みでは以下を行いました。 Everpure FlashArrayの「SafeMode」機能を利用した不変スナップショット運用の導入 データベースの整合性を担保したスナップショット取得の設計実装 今後のSQL Serverのバージョンアップに伴うFlashArrayとの連携強化の調査と検証 これらの取り組みにより、万が一ランサムウェア攻撃を受けた場合にデータを復旧できる体制を強化しました。 前提：Everpure FlashArrayとSafeMode FlashArrayは、ストレージベンダーであるEverpure社が提供するオールフラッシュストレージです。 ZOZOTOWNの基幹データベースは、オンプレミス環境のWindows Server上で稼働するMicrosoft SQL Serverです。そのデータを保存するストレージとして、Everpure FlashArrayを採用しています。 Everpure社は、2026年2月にPure Storage社からの社名変更を発表しました。本記事ではSDKなど一部の名前に「Pure Storage」という名前が残っていることをご了承ください。 www.everpuredata.com FlashArrayの主な特徴 主な特徴・機能 FlashArrayは、データベース運用において有用な特徴や特性を備えています。 機能・特性 説明 データベース運用上のメリット 重複排除・データ圧縮 同一ブロックの集約とリアルタイム圧縮 ストレージ容量を効率化し、多世代スナップショットを低コストで保持できる 高速なスナップショット ボリュームの瞬間的なコピーを作成 高速なバックアップ・復元が可能 SafeMode機能 データやスナップショットの物理削除を不可能にする ランサムウェア対策に有効 スナップショットの容量効率と多世代保持 FlashArrayのスナップショットは元データの参照情報を記録した軽量データです。スナップショット作成時にはデータの物理的なコピーは行わず、その後書き換えられたデータの旧版のみが容量を消費します。保持されるデータにも重複排除と圧縮が適用されます（弊社環境のアレイ全体では平均5:1程度のデータ削減率を実現しています）。 管理画面上では最新以外のスナップショットは数GB程度と小さく表示される一方、最新のスナップショットだけが数百GB規模で表示される場合があります。これは複数世代で共有しているデータが最新のスナップショットにまとめて計上されるためで、実際の消費量はスナップショット全体の合計で見る必要があります。この合計容量は、データの増加量ではなく既存データの書き換え量で決まります。追記中心のDBでは小さく収まりますが、インデックスの再構築や大量の更新・削除、集計テーブルの洗い替えなど、既存ページを広く書き換える処理があると大きくなります。 いずれの場合も、世代ごとに全量のコピーを持つわけではないため、ストレージ内に多世代のスナップショットを容量効率良く保持し続けられます。 SafeModeによる不変スナップショット FlashArrayによってランサムウェア対策を実現するためには、SafeMode機能 *1 の有効化が必要です。 SafeModeが有効なスナップショットは、事前に設定された保持期間の間は削除・変更できなくなります。前述の容量効率の高さにより、この不変スナップショットも多世代にわたって保持できるため、ランサムウェア被害時に確実に復旧できます。 SafeModeのランサムウェア対策の仕組み 昨今のランサムウェア攻撃はデータを暗号化するだけでなく、バックアップやスナップショットを削除して復旧手段を奪おうとするケースが増えています。通常のストレージであれば、管理者の認証情報まで取られた場合、攻撃者はスナップショットを削除できます。 しかし、SafeModeで保護されたスナップショットは、管理者権限でも物理削除できないため、攻撃前の正常なデータを確実に保持し続けます。仮に攻撃者がホストサーバー（Windows Server等）の管理者権限を取得し、FlashArrayのボリューム上のデータを暗号化したとしても、スナップショット自体は守られます。 万が一、SafeModeの無効化や設定変更を行いたい場合は、事前に登録された複数の管理者がEverpureのサポートと連絡を取り本人確認する必要があります。この多要素・多人数の認証により、内部犯行や認証情報の漏洩があった場合でも、攻撃者が単独でSafeModeを無効化できないようになっています。 以下の図は、ランサムウェア攻撃に対してSafeModeがどのように機能するかを示しています。 攻撃を受けた場合は、FlashArrayの管理画面やREST APIから攻撃前の正常なSafeModeスナップショットを特定し、ボリュームをリストアすることで復旧できます。 課題：FlashArray標準スナップショットによる運用上の問題 ここからは、FlashArrayのSafeModeによる不変スナップショットを導入するにあたり判明した課題と解決へのアプローチを紹介します。 ZOZOTOWNの基幹データベースでは、以前からFlashArrayを採用していました。 FlashArray導入時からSafeModeも有効化しスナップショットを取得していました。しかし、ランサムウェア対策の運用を見直す中で、FlashArrayの標準設定ではSQL Serverの運用に適したスナップショットが取得できていないことが判明しました。 FlashArrayをはじめとするストレージ製品の標準的なスナップショットは、「クラッシュ整合性」と呼ばれる整合性レベルのスナップショットです。 SQL Serverなどのトランザクションを持つデータベースでは、書き込みI/Oを一時停止して静止点を確保し、復元可能な状態を保証する「アプリケーション整合性」レベルのスナップショットが求められます。 それぞれの整合性の違いは下記の通りです。 比較項目 クラッシュ整合性 アプリケーション整合性 データ状態 突然の電源断と同じ状態。メモリ上のバッファキャッシュや未コミットのログはディスクに書き込まれていない。 書き込みI/Oが停止された状態。書き込み中断によるページ破損のリスクがなく、復元可能な状態が保証されている。 復旧プロセス 起動時にクラッシュリカバリが走る。不整合な箇所を自動修復する。 リカバリ処理は不要。バックアップ時点の状態ですぐに起動・利用可能。 復旧時間 (RTO) 時間がかかる。未処理のログ量が多いほど、起動時のロールフォワード/ロールバックに時間を要する。 極めて短い。修復プロセスをスキップできるため、即座にサービスを再開できる。 データ破損リスク 稀にページ破損（Partial Write）が起きるリスクがある。 リスクは極めて低い。 実現方法 ストレージやハイパーバイザのスナップショット機能のみで実行。 DBのI/Oを一時的に凍結し、静止点を作れる機能と連携して実行 本番への影響 負荷が無い。DB側での処理が不要なため、スナップショット作成時のパフォーマンス低下はない。 一時的な負荷あり。メモリのフラッシュやI/Oの一時凍結（フリーズ）により、レスポンスの瞬断や遅延が発生する場合がある。 クラッシュ整合性スナップショットから復元するとクラッシュリカバリが必ず走ります。ログ量や実行中のトランザクションの状況によって復旧にかかる時間は大きく変動するため、RTOを見通せないことが問題となります。 また、MicrosoftはSQL Serverのスナップショットバックアップの取得方法としてVSSとの連携を案内しており *2 、ストレージ単独でのスナップショット取得は推奨されていません。 解決策：VSS連携によるSQL Serverスナップショットの取得 この課題を解決するための方法として、Windows VSS *3 （Volume Shadow Copy Service、以下VSS）と連携しスナップショットを取得する必要があります。 しかし、過去に別のバックアップソリューションでVSSと連携したスナップショットを取得した際、深刻な障害へと発展した経験がありました。 VSS連携時にはディスクに対して瞬間的にI/Oフリーズを発生させる必要がありますが、このI/Oフリーズが長時間続いた場合、クエリタイムアウトが発生し、大量のエラーを引き起こすことにつながります。 この経験から、VSSの利用は慎重なアプローチが必要でした。 VSS連携の仕組み ここでFlashArrayとVSSの連携方法を解説します。VSSはある瞬間の整合性が取れたデータスナップショットを取得するためのサービスで、Windows OSに組み込まれている機能です。 VSS連携の流れ 以下がVSSによるFlashArrayの不変スナップショットの全体フローです。 VSSの3つのコンポーネント VSSを使ったスナップショットは、以下の3つのコンポーネントを連携することで実現します。 （1） VSS Requester VSSによるボリュームのスナップショットを取得するためにはVSS Requesterによる実行指示が必要です。 Backup SDKによってインストールされるPure Storage Requesterがこれに該当します。PowerShellのスクリプトを定期実行し、SDKの Invoke-PfaBackupJob コマンドによりPure Storage Requesterに対してスナップショット取得を要求します。 （2） VSS Writer SQL Serverなどのアプリケーション側と連携するためのコンポーネントです。今回はSQL Server VSS Writerがこれに該当し、SQL Server構築時に自動でインストールされています。VSSからの指示を受けて、静止点が取れる状態に準備します。その後データベースへの書き込みI/Oの一時停止（Freeze）と再開（Thaw）をします。 （3） VSS Hardware Provider ストレージ側と連携するためのコンポーネントです。今回はPure Storage VSS Hardware Providerがこれに該当します。VSSからの指示を受けて、FlashArrayのREST APIを呼び出し、スナップショットを作成します。 検証：I/Oフリーズによるサービス影響 前述の通り、過去にVSSのI/Oフリーズを原因とした障害を経験しており、今回のVSS連携も慎重に検討する必要がありました。 検証方法 以下の2つの検証を実施しました。 STG環境で過去に障害となったバックアップツールを起動し、VSSによるI/Oフリーズの発生時間を確認 商用環境でI/Oフリーズを再現し、段階的にフリーズ時間を延長してサービス影響が出ないか確認 検証2では以下のクエリをSQL Serverに実行しI/Oフリーズを再現しました。 DBCC FREEZE_IO ( ' DB名 ' ) WAITFOR DELAY ' 00:00:00.100 ' ; --（例）100msの間I/Oフリーズを発生させる DBCC THAW_IO ( ' DB名 ' ) DBCC FREEZE_IOコマンドはMicrosoft公式サポート対象外（Undocumented）です。本来は本番環境での利用は推奨されませんが、問題がないことを確認した上で利用しています。 検証結果 2つの検証を通じて、VSSのI/Oフリーズの与えるサービス影響が許容範囲であることを確認し、VSS連携によるSafeMode導入は問題ないと判断しました。 また、検証のなかで、VSSによるI/Oフリーズ発生時の具体的な影響範囲も判明しました。 Insert/Update/Deleteは全て影響を受ける Selectについてはメモリにデータが載っていないときだけ影響を受ける メモリに余裕がある場合Select句で影響を受ける可能性は少なくなる 実装：スナップショット取得バッチの作成 全体構成 今回は、VSSと連携してスナップショットを取得するために、Pure Storage Backup SDKを利用したバッチスクリプトを実装しました。このSDKはPowerShellモジュールのため、バッチもPowerShellで実装しています。 バッチから呼び出される各機能の関連は下記の通りです。 このうち、SQL Server VSS WriterとVSSはSQL Server構築時とWindows OSに標準で含まれているため、追加インストールは不要です。Pure Storage Requesterについても、初回のバックアップジョブ実行時にBackup SDKが自動でインストールしてくれました。手動でのインストールが必要なのは、バッチ実行サーバーのSSMS Extension（Backup SDKが同梱されています）と、DBサーバーのVSS Hardware Providerの2つです。 FlashArrayへのREST API接続は2経路あります。1つはVSS Hardware Providerからのもので、VSSからの指示を受けてスナップショットを作成します。もう1つはBackup SDKからのもので、こちらはスナップショット取得そのものではなく、バックアップ構成と取得履歴の管理に使われます。 なお、DBサーバーとFlashArrayの間はFC Switch経由のFC接続で、SQL Serverのデータファイル・ログファイルはFlashArray上のボリュームに配置されています。 事前設定 設定にはPure Storage Backup SDKのPowerShellモジュールに含まれるコマンドレットを使用します。 クレデンシャルの登録 バッチ実行サーバーから、SQL ServerとFlashArrayのREST APIに接続するためのCredentialを登録します。 # SQL Serverへの接続情報（Windows認証） Add-PfaBackupCred -CredentialName "<任意の名前>" ` -Address "<SQL Server IP>" ` -CredentialType "Windows" ` -Credential ( Get-Credential ) # FlashArrayへの接続情報 Add-PfaBackupCred -CredentialName "<任意の名前>" ` -Address "<FlashArray IP>" ` -CredentialType "FlashArray" ` -Credential ( Get-Credential ) バックアップジョブの登録 同様に、バッチ実行サーバーからスナップショット取得先の設定を登録します。 Add-PfaBackupJob -ConfigName "<設定名>" ` -Component "<インスタンス名>\<データベース名>" ` -ComputerName "<SQL Server名>" ` -FAName "<FlashArrayクレデンシャル名>" ` -VolumeType "Physical" ` -MetadataDir "<メタデータ保存先>" ` -CopyOnly SQL Serverのバックアップ運用と併用する場合は -CopyOnly を指定します。未指定の場合、スナップショットが差分バックアップの基点としてリセットされ、既存のフルバックアップ＋差分バックアップの復元手順に影響が出てしまいます。 バッチ実装 スナップショットの実行 バッチから Invoke-PfaBackupJob コマンドを実行しスナップショットを取得できます。ConfigNameには Add-PfaBackupJob コマンドで事前に設定したジョブ設定名を指定します。 $result = Invoke-PfaBackupJob -ConfigName "<設定名>" if ( $result [ "Status" ] -ne "Succeeded" ) { throw "スナップショット取得に失敗しました" } 運用：構成とモニタリング VSS連携によるスナップショット運用を安定して回すため、Protection Groupの設計、実行タイミング、日常的なモニタリングの観点で運用ルールを整理しました。 Protection Group と Snapshot Schedule の設計 Protection Groupは、FlashArrayにおけるスナップショットの管理単位です。複数のボリュームをグループ化し、まとめてスナップショットを取得・管理できます。 同じProtection Group内にある複数ボリュームのスナップショット取得や復元は、まとめて処理されます。しかし、VSS連携をした今回のスナップショットは指定したボリュームのみに適用されます。また、SafeModeを有効化するためには、Protection GroupにSnapshot ScheduleというFlashArray標準のスナップショットも有効化する必要があります。 この仕様を理解し、以下のようにProtection Groupの設計を見直しました。 SystemDBとUserDBをそれぞれ独立してリストアできるよう、Protection GroupとVSS連携をDBごとに分ける Protection GroupのSnapshot Scheduleは必ず有効化する（SafeMode有効化の前提条件） 弊社環境での具体的なProtection Group構成は以下の通りです。 ProtectionGroupA ：DBではないその他の複数ボリューム ProtectionGroupB ：SQL ServerのSystemDBが存在する単一ボリューム。VSS連携によるスナップショット対象 ProtectionGroupC ：SQL ServerのUserDBが存在する単一ボリューム。VSS連携によるスナップショット対象 ProtectionGroupD ：SQL ServerのTempDBが存在する単一ボリューム（SQL Server起動時に自動再作成されるため、VSS連携の対象外） 実行タイミングの最適化 他の処理との競合を避けるため、実行タイミングを慎重に設計しました。考慮事項としては以下が挙げられます。 他の処理のピーク時間帯を避ける 通常のSQL Serverバックアップ（BACKUP DATABASE）とVSSスナップショットを同時に実行すると、ロック競合を起こす可能性があるため起動時間をずらす 同一のFlashArray内で複数のデータベースが稼働している場合はそれらの起動時間が被らないようにずらす 日常運用とモニタリング 日常的なモニタリング項目としては以下が挙げられます。 I/Oフリーズ時間の監視 スナップショットストレージ容量の推移監視 I/Oフリーズは負荷やDBの特性によって変化が大きく、数十msから1500ms程度かかるDBも存在しました。データの更新量やキャッシュ容量の大きいDBではスナップショットの所要時間が伸びる傾向にあります。許容できるフリーズ時間をあらかじめ見積もり、フリーズ時間が徐々に延びていないかを監視する必要があります。 また、FlashArrayのスナップショットは、重複排除の仕組みにより非常に小さいサイズで済みます。しかし、データの更新量や重複率によってサイズが大きく変わるため、正確な見積もりは困難です。そのためスナップショットを含めたFlashArrayの容量監視は重要です。 なお、万が一ランサムウェアに感染しデータを改ざんされた場合、重複排除が効かなくなりデータ容量の肥大化を起こすと考えられます。その際の早期発見としても容量推移のモニタリングは有効です。 展望：T-SQLスナップショットへの移行 ここからは、今後のバージョンアップに備えて調査・検証した最新の連携方法を整理します。 今回導入したVSS方式は安定して運用できていますが、SQL Server外部のWindows VSSがI/Oフリーズを制御する仕組みです。そのため、VSS WriterやVSS Hardware Provider、Backup SDKなどの依存コンポーネントが多い構成となっています。また、VSS方式のスナップショットはLSN情報を持たないため、スナップショット復元後に既存のトランザクションログバックアップを適用したポイントインタイムリストア（PITR）ができないという制約もあります。ランサムウェア被害時はサーバー上のデータが信用できないためSafeModeスナップショットから復元しますが、VSS方式ではその後のPITRに対応できません。 SQL Server 2022で追加された「T-SQLスナップショットバックアップ」はSQL Server自身が静止点を制御する方式で、VSSへの依存がない構成です。加えて、 .bkm メタデータファイルによってスナップショット後のログバックアップを適用したPITRも可能になります。さらにSQL Server 2025ではFlashArrayのAPI呼び出しまでT-SQLで行えるようになり、外部スクリプトを排した運用が可能になりそうです。 各方式の比較 項目 VSS連携方式 T-SQL方式 (2022) T-SQL方式 (2025) SQL Serverバージョン 2016以降 2022以降 2025以降 I/Oフリーズの制御 VSS（Windows OS側） SQL Server自身 SQL Server自身 ストレージ呼び出し VSS Hardware Provider PowerShell + Backup SDK T-SQLから直接（REST API） 外部スクリプト 必要（PowerShell等） 必要（PowerShell等） 不要 ポイントインタイム復旧 困難 可能（.bkmファイル） 可能（.bkmファイル） 各方式の構成は以下のようになります。バージョンが上がるにつれて依存コンポーネントが段階的に削減されます。 SQL Server 2022：VSSに依存しないスナップショットバックアップ SQL Server 2022では、VSSを介さずSQL Server自身がI/Oフリーズを直接制御します *4 。 VSS WriterやVSS Hardware Providerへの依存がなくなり、構成がシンプルになります。 スナップショット取得後に出力される .bkm メタデータファイルにはLSN（Log Sequence Number）情報が記録されます。これにより、スナップショットから復元後にトランザクションログバックアップを適用したポイントインタイム復旧が可能になります。VSS方式では実現が難しかった任意時点への復旧が、標準的な手順で行えるようになる点が大きな改善です。 なお、FlashArrayのREST API呼び出しはPowerShell *5 で行う必要があります。 SQL Server 2025：T-SQLで完結したスナップショットバックアップ SQL Server 2025では、T-SQLからFlashArrayのREST APIを直接呼び出せるようになります（ sp_invoke_external_rest_endpoint ） *6 。 これにより外部PowerShellスクリプトが不要になり、認証情報の管理を含めたスナップショット運用をSQL Server内部に完全に閉じることができます。スナップショットへのタグ付けやカタログ機能も提供され、T-SQLのみでバックアップ運用を完結できます。 このように、今後SQL ServerとFlashArrayの連携が強化され、よりシンプルな運用が可能になる予定です。 まとめ 本取り組みのポイント 本記事では、Everpure FlashArrayのSafeModeとVSS連携を組み合わせ、SQL Serverの確実なリストア体制を整えた取り組みを紹介しました。 FlashArray SafeModeによる不変性の確保 ：導入当初から有効化し、攻撃者による削除・改ざんを防止 VSS連携の導入（今回の対応） ：Microsoftが推奨するVSS連携を導入し、クラッシュリカバリなしに確実に復旧できる体制を整えた 重複排除による容量効率 ：多世代のスナップショットを効率的に保持 段階的な導入 ：過去のVSS障害の教訓を活かし、影響を最小限に抑えながら展開 今後の展望 今後も様々な改善を検討中です。 SQL Server 2022環境でVSSに依存しない方式への移行 SQL Server 2025でのT-SQLで完結したスナップショットへの移行 異なる環境へのスナップショットの転送。多層防御化 定期的な復旧訓練の実施 最後に ランサムウェア対策は単一の施策で完結するものではありません。多層的な防御を構築し、継続的に改善していくことが重要です。本記事が同様の課題を抱える方々の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com *1 : https://www.everpuredata.com/jp/solutions/cyber-resilience/ransomware/safemode.html *2 : https://learn.microsoft.com/ja-jp/sql/relational-databases/backup-restore/create-a-transact-sql-snapshot-backup *3 : https://learn.microsoft.com/ja-jp/windows-server/storage/file-server/volume-shadow-copy-service *4 : https://learn.microsoft.com/ja-jp/sql/relational-databases/backup-restore/create-a-transact-sql-snapshot-backup *5 : https://github.com/PureStorage-Connect/PowerShellSDK2 *6 : https://techcommunity.microsoft.com/blog/sqlserver/reimagining-data-excellence-sql-server-2025-accelerated-by-pure-storage/4470810