こんにちは、佐藤です。第２回はオンプレミスのアプリケーションサーバをクラウドへ移行する際のファイルサーバ、データベースなどのデータストアの移行におけるポイントをご紹介します。
データストアのクラウド移行とは
オンプレミスからクラウドへ移行する際の代表的なデータストアの例を示します。
・社員がActive Directoryで認証して利用しているファイルサーバ
・アプリケーションサーバからNFS/SMBでマウントしているファイルサーバ
・アプリケーションサーバから接続されるSQL Server、Oracle Database、MySQL、PostgreSQL、等のデータベース
・バックアップデータ用のiSCSIで構成されたSAN（Storage Area Network）
それぞれのデータストアについて、クラウドへ並行する際どのようなステップで検討し、移行すればよいのかを順番に説明していきます。
クラウドにシステムを移行することで、従来行っていた仕組みが不要となることがあります。例えばアプリケーションサーバのイメージバックアップや基本的な監視などです。Azure上にアプリケーションサーバを移行し、Azure Backupによるバックアップを行うことで、オンプレミスで利用していたバックアップ用のSANは不要となり移行対象から外すことができるかもしれません。
もちろんSANがバックアップ用のデータが保存されている場合は、そのデータの取扱や移行先を考える必要があります。バックアップ対象を減らすことで移行作業を最適化しコストも効率化することができますので、データストアのクラウド移行を行う際、まずはデータ移行が必要？不要を整理すると良いでしょう。
移行対象先の検討とコスト見積
移行対象となるデータストアが明確になったら、今度は各データストアの移行先のサービスを検討します。先述のデータストアの例では、下記のような移行先が考えられます。
・社員がActive Directoryで認証して利用しているファイルサーバ
今回のテーマからは外れますがAzureにはAzure Active Directory Domain Services (Azure AD DS)というマネージドサービスのドメインコントローラが利用できます。移行対象として最適か？は要件、コスト試算の結果によりますが、ドメインコントローラもマネージドサービス化することでサーバ管理が不要となります。
データストアはAzure Filesというマネージドサービスが有効です。1GBあたりのストレージ単価は仮想マシンのストレージ（Managed Disk）よりは高くなりますが、実際に保存されたデータ量分しか課金されない（Managed Diskは確保したストレージ容量に課金される）、ストレージ容量は最大で5PiB（GPv2 ストレージ アカウント Standardの場合）まで利用できるため、ディスク容量が枯渇し増設対応する必要もほぼなくなります。
Azure Filesの課金は実際に保存されているデータ容量、バックアップデータ量、読み込み書き込みなどのトランザクション量の足し算で課金されます。Azure Filesには要件にあわせてPremium（高スループット、高I/Oを提供するSSDベースのストレージ）、トランザクション最適（トランザクションが多いデータストア用）、ホット（汎用的な用途）、クール（アーカイブ用）のレベルがあり、レベルによって課金される単価が変わりますので、実際にコスト試算する際は「料金計算ツール」で試算するようにしましょう。
図：料金計算ツール
・アプリケーションサーバからNFS/SMBでマウントしているファイルサーバ
この例もAzure Filesがデータストア移行先としては有効です。Azure FilesのStandardレベルはSMBのみサポートしていますが、PremiumレベルはSMB及びNFSをサポートしておりLinuxサーバからのファイル共有も可能です。
高いI/Oが求められず、NFSでの接続が要件だった場合、Blobをデータストアの移行先として選択するのも有効です。現在BlobはNFS3.0での接続をサポートしているため、Linuxサーバからマウントされていたファイルサーバの移行として検討してみると良いでしょう。メリットはAzure Filesよりもコストが安い、デメリットはI/Oは高くない点です。
・アプリケーションサーバから接続されるSQL Server、Oracle Database、MySQL、PostgreSQL、等のデータベース
Oracle DatabaseなどAzure上でマネージドサービスとして提供されていないデータベースエンジン以外はPaaSファースト（クラウドでのシステム構築・移行を考えるとき、PaaSサービスの採用を第一に考えること）で移行先のサービスを選定することをおすすめします。主な理由は下記のとおりです。
・既定でバックアップが取得されている安心感とサービスレベル品質の担保
・既定で冗長化されているため不慮の障害時も短いサービス停止に影響をおさえられる
・既定で基本的な監視が行われているためリソース、性能を定量的に把握することが簡単にできる
・スケールアップ/ダウン時のサービス停止時間が仮想マシンベースのデータベースと比較し格段に短い
・仮想マシンの管理をする必要がない
SQL DatabaseはSQL ServerのEnterprise Editionでの機能が一部利用できつつコストがEnterprise Editionよりも大幅に安いことに加え、スケールアップ/ダウン時のサービス停止時間が数秒など他のクラウドサービスにはない強力な特徴があります。
また、OSS（Open Source Software）のMySQL、PostgreSQL、MariaDBといったデータベースエンジンのPaaSもAzure上で提供されています。現在は新しい世代のFlexible Server（プレビュー中）が利用でき、初代のサービスで課題でしたパッチ適用によるサーバ再起動のタイミングがユーザ側でコントロールできるため、パフォーマンスが改善しています。
出典：概要 - Azure Database for PostgreSQL - フレキシブル サーバ
https://docs.microsoft.com/ja-jp/azure/postgresql/flexible-server/overview
Azureのマネージドデータベースサービスは既定で冗長化されているため、比較対象も冗長化されている構成とのコスト比較をするよう注意してください。例えばVMベースであれば、複数台のVMでのクラスタ構成との比較、AWSとの比較であればMulti AZ構成でのRDS/Auroraとの比較になります。
Oracle Database、DB2などマネージドサービスとして提供されていないデータベースエンジンは仮想マシン上で動作させる必要があります。Oracle DatabaseについてはOCI（Oracle Cloud Infrastructure）とAzureで簡単に専用線接続が安価、かつ双方の管理ポータルからの操作だけ接続できるため、Oracle DatabaseはOCIに移行しアプリケーションサーバはAzureに配置するという構成も可能です。
Azure上でOracle Databaseを動作させるには仮想マシン上にデプロイする必要がありますがコストが安いとは言えません。同じスペックであればOCIのOracle Databaseのサービスを利用した方が安いため、回線費用ともあわせてコストメリットがあるようであればこの構成も有効です。
出典：Microsoft Azureを使用したOracle Cloudの接続について
https://docs.oracle.com/ja/solutions/learn-azure-oci-interconnect/index.html#GUID-A3BCA684-47C4-4644-90E8-99A7E3E0A6FE
・バックアップデータ用のiSCSIで構成されたSAN（Storage Area Network）
前述の通りこれまでのバックアップがAzure Backupｄで代替えできるのであれば移行不要となります。
変更部分の精査
移行先のデータストアが決定できたあとはアプリケーションサーバの変更部分の必要箇所を精査します。
Active Directoryと連携しているファイルサーバはAzure上で新規に構築されたドメインコントローラとの連携部分が肝になります。そのため、早期に基本的なテストを行っておくことを推奨します。
基本的な動作確認ができれば、ユーザ影響を精査します。例えばユーザが利用しているPCから新しいファイルサーバへの接続はユーザにやってもらうことが多いためその手順を大まかにでも早期に把握しておくことが重要です。また、管理者側ので運用が変わる部分もおさえておく必要があります。
Azure Filesを利用する場合、これまでのサーバの管理やバックアップなどは楽になりますが、クラウドならではの管理が必要となることがあります。例えば想定以上にデータ量が増えてコストが急増しないようデータ容量を監視しておく、アクセスが低いデータはコストパフォーマンスが高いクールレベルに移動するよう利用状況を見ながら設定変更するなどです。詳細については次回の記事でご紹介します。
データベースであれば接続先の情報を変更するだけ良いかもしれませんが、一般的にクラウド移行時にデータベースのVersion Upも同時に行われることがあるためこれまでのアプリケーションサーバの設定、コードで動作するかは事前に精査しておくと良いでしょう。
不要ファイルのクレンジング
実際に移行するデータの中身も精査して必要なデータだけを移行することをおすすめします。特にファイルサーバは長年蓄積されたアクセスがほぼ無いデータや同じファイルが複数箇所に保存されているなど無駄にデータ量が増えていることも多いかと思います。移行のような大イベントがないとこういったところに手を入れるのは難しいため、利用部門の担当者や各ユーザに協力してもらい精査し、必要なデータだけを移行しましょう。
Azure FilesにもBlobにもアーカイブ用の安価に利用できるレベルのストレージも用意されているため、「削除はできないけどあまりアクセスがないデータ」についてはこういった領域に保存するとよいでしょう。
移行方法
具体的にデータストア内のデータを移行する方法をご紹介します。
・社員がActive Directoryで認証して利用しているファイルサーバ
旧環境と新環境のファイルサーバの並行運用期間を一定期間設け、利用部門の担当者、各ユーザにデータをコピーしてもらうのがよいでしょう。もちろんIT部門で旧環境のデータを機械的にコピーして移行する方法もありますが、不要なデータもそのまま新環境に持ってきてしまう可能性も高くなってしまいます。
・アプリケーションサーバからNFS/SMBでマウントしているファイルサーバ
rsyncやrobocopyのような従来からのツールを利用してデータを権限含め同期させ、本番移行時に旧環境のデータ更新を完全に停止、新旧環境で完全にデータが同期されたらアプリケーションサーバの接続先を新環境に切り替えるという方法が多いかと思います。従来からのツールを利用することでオンプレミスのエンジニアも従来の経験を活用して安心してデータを移行できるというメリットもあります。Windows Serverのファイルサーバからの移行であればAzure File Syncという移行ツールも活用できます。
・アプリケーションサーバから接続されるSQL Server、Oracle Database、MySQL、PostgreSQL、等のデータベース
データベースの移行はファイルサーバのように事前にデータを同期させておく方法と移行当日にデータのエクスポート・インポートで行う方法の大きく２つがあります。いずれの場合もDMS（Azure Database Migration Service）が活用できます。今回は詳細は活用しますが事前に検証を行った上で要件に合う移行ができる場合にはこちらを利用することをおすすめします。
移行当日にエクスポート・インポートを行う方法は、明確に静止点を設けてデータをエクスポートし、新環境にインポートします。この方法は従来からある方法でオンプレミスのエンジニアも馴染みのある方法であるということと、移行におけるトラブル時の原因解析や対応がシンプルであるというメリットがあります。デメリットは移行当日に必要となるサービス停止時間が事前同期の方法と比較し多くなるという点です。
データのエスポートにかかる時間（サーバのスペック、データ量に依存）、データを新環境にコピーする時間（データ量、回線速度に依存）、データをインポートする時間（サーバのスペック、データ量に依存）の総和＋予備時間になりますので、環境によっては数時間この作業だけに必要となります。この時間を正確に見積もるために早期にテストをしておくとよいでしょう。
確認
正しくデータが新環境に移行できたかどうかが最後の正念場になります。そのため、事前に確認方法を確立し、手順を極力コード化して移行当日は焦らず確認できるようにしておきましょう。
・ファイルサーバでの確認項目例
- 移行前後データサイズ、データ数の比較
・データベースの確認項目例
- エスポートデータファイルとインポートデータファイルのデータサイズとチェックサム
- データベース毎、テーブル毎のデータサイズ、データ数の比較
・アプリケーションサーバからの確認項目例
- アプリケーションから確認できるデータをサンプルでいくつか最新データになっているか確認。例えば購買履歴、ログイン履歴、チャット履歴などの頻繁に更新されやすいデータがよいでしょう。
まとめ
今回はオンプレミスからのデータストアのクラウド移行について検討のポイントを説明しました。初回のアプリケーションサーバの移行と同じく要件から机上で移行方針を検討し、早い段階で検証・テストを行い、方針を決定するのが非常に重要です。
特にデータは企業、サービスの大きな資産ですし、データの欠損はビジネスへの影響が大きいため慎重に進める必要があります。
この作業をプレッシャーに負けず、高いモチベーションで高品質、高効率ですすめるために、余裕を持って事前検証期間をスケジュールし、積極的にPaaS、移行ツールの活用することをおすすめします。新しい技術、サービスの活用はエンジニアにとってもスキルアップの良い機会になります！
次回は「オンプレミスでは必要なかった運用のポイント」についてご紹介していきます。
・関連情報ページ