1. はじめに 本記事では、Oracle WebLogic Server（以下、WebLogic）からApache Tomcat（以下、Tomcat）への移行検証を紹介します。 「次のシステム更改で、WebLogicをTomcatに移行するから。よろしく。」 と上司から言われて、さて困りました。 とはいえ、最初からものすごく難しく考えていたわけではありません。 Oracle WebLogic Server Proxy Plug-In（以下、WebLogic Proxy Plug-In）をApplication Request Routing（以下、ARR）に置き換えて、Tomcatま

こんにちは、基幹システム本部リプレイス推進部の ssssota です。 ZOZOでは、Classic ASP (VBScript) で長年運用してきた基幹システムを、新しい技術へリプレイスする取り組みを進めています。 本記事では、このリプレイスを推進するために、AIを活用してClassic ASPのエミュレータを作った事例を紹介します。 目次 目次 基幹システムの構成 リプレイスにおける構成由来の課題 エミュレーションによる課題の解消 AIを活用したコンパイラの作成 Classic ASP、IISへの拡張 副産物 まとめ おわりに 基幹システムの構成 ZOZOの基幹システムは、長年Classic ASPやVBScriptといった技術を用いて構築、運用されてきました。 Classic ASPは、Windows Server上のIIS (Internet Information Services) で動作し、サーバ上で動的にHTMLを生成する技術です。ロジックはVBScriptで記述します。 しかし、Microsoftは VBScriptの廃止を発表 しており、今後の運用保守は困難になると予想されます。そのため、基幹システムのリプレイスが急務となっています。 さらに、基幹システムはClassic ASPの上にサードパーティ製のクローズドなフレームワークを載せ、その上に構築されています。 リプレイスにおける構成由来の課題 リプレイスにおいては、規模はもちろんですが、システムの技術構成に由来する課題が多く存在します。 1つ目の課題は、テストが非常に困難な点です。システムは主にWebページとして提供されるので、PlaywrightといったE2Eテストツールを用いることは可能です。しかし、ページ数が多いうえにページ間の依存関係が複雑に絡み合っており、大量のテストデータも必要です。そのため、E2Eテストだけで網羅性を担保するのは困難です。 ユニットテストにも難しさがあります。Classic ASPおよびVBScriptにはモジュールシステムがなく、ファイルを分割しても、C言語の #include ディレクティブと同様、単純に結合されるだけです。そのため、モジュール単位でのユニットテストも困難です。ファイル単位でテストしようとしても、他ファイルのグローバル変数などに依存しているケースがあります。 2つ目の課題は、Classic ASPおよびVBScriptがWindows上でしか実行できない点です。そのため開発者が手元で実行するにはWindows端末を用意するか、仮想環境を構築する必要があります。 エミュレーションによる課題の解消 以上の課題を解消するため、VBScriptのエミュレータを作成することにしました。 パーサやインタプリタは既存のOSSなども調査しましたが、いずれも精度が十分ではなく、私たちが求めることを実現できないと判断しました。そこで自作を前提に、VBScriptの構文を解析して実行するインタプリタをRustで作成することを検討しました。しかし、インタプリタを作る場合、それに対応するテストフレームワークやサーバ統合、実用的なパフォーマンスチューニングなど、作るべき対象が膨大で、相応のコストを要します。 最終的に選んだのは、VBScriptをJavaScriptに変換するコンパイラです。JavaScriptに変換すれば、既存のテストフレームワークを利用でき、サーバなどへの統合も比較的容易に実装できると考えました。また、自前のインタプリタより高度に最適化されたJavaScriptエンジンで実行できるため、実行速度の面でも優位性があることを期待しました。私自身がJavaScriptを得意としていることも選択の理由の1つです。 AIを活用したコンパイラの作成 VBScriptをJavaScriptに変換するには、VBScriptの仕様を深く理解する必要があります。しかし、VBScriptには細部の挙動まで網羅したドキュメントがありません。そこで、次の手順でAIにコンパイラを作成させました。 AIが、挙動を確かめるためのVBScriptコードを大量に生成する 生成したコードをWindows上で実行し、実際の出力を記録する 記録した出力を正解として、それを満たすようにAIがコンパイラを実装する 人間が担当したのは、macOS上に構築したWindowsの仮想環境での実行のみです。それ以外のステップは、ほぼすべてAIに任せられました。Windowsの実挙動を正とする方針を最初に示してから、それらしく動くようになるまで、1週間とかかりませんでした。細部の調整は地道で、実際のコードを動かすなどして、穴をたまたま見つけては修正する作業を繰り返しています。 JavaScriptへ変換できるようにしたことで、ブラウザ上でもVBScriptを実行でき、変換結果や動作を手軽に確認できるようになりました。 スクリーンショットのとおり、変換後のJavaScriptはVBScriptと1対1に対応しておらず、可読性が低く、人間による保守は困難です。理想としては、コードが1対1で対応するように出力したいところですが、現実は甘くありません。これはVBScriptの言語特性によるもので、エラーや引数の扱いを再現するには避けられませんでした。現代的な言語からは考えづらいVBScriptの挙動をいくつか紹介します。 1つ目は、単純なtry/catchでは再現できないエラー処理です。 On Error Resume Next を宣言すると、エラーが発生しても処理が止まらず、次の行から実行を続けます。 On Error Resume Next ' エラーが発生しても無視して次の行へ進む宣言 Dim x ' 変数xを宣言 x = 1 / 0 ' ゼロ除算エラーが発生するが、継続 WScript.Echo "continue" ' 実行される（WScript.Echoは標準出力関数） 2つ目は、引数の渡し方です。引数はデフォルトで参照渡しですが、引数を括弧で囲んで式として評価させると値渡しに変わります。 Call の括弧は引数リストの区切りなので、値渡しにはなりません。 Sub Increment(value) ' 引数valueをインクリメントするSubプロシージャ value = value + 1 End Sub Dim number ' 変数numberを宣言 number = 1 ' 初期値1 Increment number ' デフォルトは参照渡し WScript.Echo number ' 2 Increment (number) ' 括弧付きは値渡し WScript.Echo number ' 2 Call Increment(number) ' Callでは括弧が必須で、括弧付きでも参照渡し WScript.Echo number ' 3 Call Increment((number)) ' 二重括弧では値渡し WScript.Echo number ' 3 3つ目は、自作クラスより組み込みクラスが優先される挙動です。組み込みクラスと同じ名前のクラスを定義しても、 New で生成されるのは組み込みクラスのインスタンスです。 Class RegExp Public Function Kind() Kind = "script" End Function End Class Dim regex Set regex = New RegExp ' VBScript組み込みのRegExpクラスが優先されるため、上で定義したRegExpクラスは無視される WScript.Echo regex.Kind() ' エラー（組み込みのRegExpクラスにはKindメソッドが存在しないため） このような挙動チェックをするVBScriptのコードサンプルは1,000件を超えました。コンパイラの出力はすべてのサンプルで正しく動作していますが、仕様が網羅されているわけではありません。コンパイラのコードは人間が理解できる分量を優に超えましたが、本番環境で利用する目的ではないため目をつぶっています。 コンパイルから実行までの流れは次のとおりです。 #include で結合したVBScriptをコンパイラがJavaScriptへ変換します。実行時は、ランタイムとあわせて読み込んだエントリーポイント（ main.js など）から、Node.jsやブラウザで実行します。 Classic ASP、IISへの拡張 Classic ASPは、HTMLにVBScriptを埋め込んでページ単位で実行する方式です。 <?php ?> でHTMLにコードを書いていた頃のPHPのように、リクエストごとにサーバがそのページを実行してHTMLを返します。コンパイラは、基本的にVBScriptと同じ変換処理を使い回せました。Classic ASPでは Response.Write などの組み込みオブジェクトを利用できます。これらもVBScriptのときと同様に、呼び出し側からJavaScriptの関数として提供します。 ここまでで、Classic ASPのページにリクエストの情報を渡し、レスポンスを生成できるようになりました。これを任意のHTTPサーバと接続すれば、IISのように振る舞えます。IIS固有の挙動も、実際のIISでのレスポンスを記録し、それを正解としてテストが通るように実装しました。 前述のとおり、基幹システムはClassic ASP上でサードパーティ製のクローズドなフレームワークを利用しています。このフレームワークは内部実装に立ち入らずブラックボックスとして扱いました。ASPと同様に実際の環境へリクエストを送って挙動を記録し、それを正解としてテストが通るように実装しました。これにより、Classic ASPのページへのリクエストに対し、IISと同様の挙動でレスポンスを返せるようになりました。 副産物 ASPやVBScriptをJavaScriptに変換し、さらに実行可能にしたことで、いくつかの副産物が生まれました。特に大きいのは依存関係の追跡・可視化です。ASPやVBScriptを高い精度でパースできるため、関数などのシンボルを正確に検出できます。さらに、サードパーティフレームワーク独自のテンプレートエンジンが持つシンボルも検出できるようになり、依存関係を静的に追跡できるようになりました。裏を返せば、これまでは依存関係の解析すらままならない状態でした。 また、リプレイス後のシステムと同じJavaScriptランタイム上で旧ページを動かせるようになりました。これにより、新旧の動作を同じ環境で比べたり、新システムからまだリプレイスしていない旧ページへ遷移したりできます。 まとめ VBScriptやClassic ASPで動く古いシステムをリプレイスするにはテストが必要ですが、その構成上テスト自体が困難でした。そこで、AIを用いてVBScriptやClassic ASPをJavaScriptに変換するコンパイラを作成しました。これによりテストが可能になり、ポータビリティも向上しました。もちろんエミュレータの精度は完璧からほど遠いものの、そもそも本番環境で使うことは想定していません。 言語の実行環境を作るというのは、2年前には実現できなかったでしょう。しかしAIに任せることで、力技で解決できるようになりました。そんな選択肢がすぐ近くにあることを感じていただければ幸いです。 おわりに ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに こんにちは。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