この記事は、Microsoft Azure Tech Advent Calendar 2019のための記事となります。
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
はじめに
Northwind Traders 買収される！
2019年の Microsoft Ignite における重大発表は、どんな最新サービスのアナウンスよりも__この衝撃的なニュース__を超えるものは無いと個人的には思います。しかも、ちゃんとしたプレスリリースなどでのアナウンスなどなくセッションの概要にさらっと下記の一文がありました。
Tailwind Traders has acquired Northwind, a large subsidiary company
寝耳に水の出来事です。__Contso__や Fablikan, Adventure Works, World Wide Importers__の将来もこのような可能性があるかもしれないご時世なので__うかうかしていられません。
ご存知ない方のために捕捉をしておくと、Northwind Traders といえば Access や SQL Server をはじめとしたデータベースのサンプルデータベースの教材として広く知られている架空の企業です。
Northwind といえば、Access ですよねー？
2017年のアドベントカレンダーに投稿した Access から SQL Database に移行する手順をまとめた記事ですが、今でも細々と検索エンジン経由での訪問があるようだったのでいい機会なので__2019年っぽいやり方__で移行してみましょう。ちなみに、作業時の Access のバージョンは Microsoft Access for Office 365 MSO (16.0.12228.20322)の64ビット版を使っていますが、__ノースウィンド2007__というサンプルDBはなんとか健在でした！既に Tailwind Traders とかになってたらショックだったけど、どうやら現場で使われているツール類にまでこの余波が来るのはまだまだ先ということでしょうか。いずれにしてもよかったよかった。
現場の Access にあるデータを移行する理由
現場の Access にあるデータを移行する理由は無数に考えられますが、一番よく挙げられるポイントとしては次のものがあります。ちょっと読み物的な観点で挙げておきますね。
-
会社全体のガバナンス強化
- 現場の Access （というか通常の Office で作成されたドキュメントファイル類）って個々の担当者のPCに入っていることも多く__バックアップすら取られていない__こともよくあります。バックアップ対象とするとか OneDrive や共有ファイルサーバーに配置するとか転ばぬ先の対策をするということを考えておきましょう。そう。__疲れててうっかりPCにコーヒー飲ませたりケーキを食べさせたりすること__って人には稀にあるんですよ。（いずれも私の経験談）その時に笑っていられるかどうかっていうのは重要なカギです。
-
利便性とデータ活用性の向上
- AIとかデータとかキーワードはいくつも出てきていて、思わず夢見ちゃいますよね。賢いAI（イメージはスターウォーズのドロイド群）がなんだかよくわからないデータをよしなに解析して、ビジネスに役立つふわっとしたいい感じの解析結果をもとにした予測データで仕事を助けてくれるとかくれないとか。でもどんなデータも解析するためのデータソースにしないことにはその分析・解析はおろか機械学習をもとにした予測データの作成すらままならないことは容易に想像がつくでしょう。__手元のPCにあるデータをデータソース化する__ということは第一歩だったりします。
- とはいえ、運用管理っていうなんだか難しいことはやりたくない。となると、クラウドサービスを使って今のデータをデータソースとして置かせてもらって冗長性や可用性、バックアップやセキュリティといった__面倒な運用管理のほとんどをクラウド側におまかせしちゃっておいしいところだけ使おう__というのが一番賢いやりかたにです。
これらを踏まえて移行先を検討します。
移行先をどうしましょうか？
Microsoft Azure にはたくさんのデーターベースサービスがありますが、移行先の選択肢にはリレーショナルなデーターベースサービスからはリレーショナルなものが Access を含めたツール類が活用できるためユーザー側への対応負荷を減らすことができることでしょう。簡単に Microsoft Azure で利用可能なリレーショナルな各データーベースサービスについてまとめておきます。
| サービス名 | 特徴 | 備考 |
|---|---|---|
| Azure SQL Database | SQL Server をもとにした PaaS サービスです。様々な機能を使用することができます。 | SQL Database には大容量対応の Hyperscale, SQL Server との互換性を高めた Managed Instance など個性派な仲間もたくさんいます。SQL Server との機能差についてはこちらに明記されています。 |
| SQL Server on Virtual Machines | SQL Server をインストールした仮想マシンワークロードです。 | オンプレミスの SQL Server インストール済みの仮想マシンをマイグレーションしたイメージに対しても、Resource Provider 登録することで最初から SQL Server イメージが入っている仮想マシンをデプロイしたときと同様に Azure Portal から色々な機能を使用することが可能です。 |
| Azure Database for MySQL | コミュニティ版の MySQL をもとにした PaaS サービスです。 | |
| Azure Database for PostgreSQL | コミュニティ版の PostgreSQL をもとにした PaaS サービスです。 | 大規模な分析基盤ではマルチノードのCitusベースのものも利用することが可能です。 |
| Azure Database for MariaDB | MariaDB をもとにした PaaS サービスです。 | |
| Azure Synapse Analytics (以前の名称：SQL Datawarehouse）もリレーショナルなPaaSサービスといえなくもないのですが、分散コンピューティング＆分析基盤なので、Accessのスケール先としてはとても大きなものになるためこの表には含めていません。 |
Azure の PaaS の DB の特徴としては、標準で冗長化（いわゆるクラスター構成）が実装済みであることが挙げられます。たとえば、SQL Database であれば、高可用性と Microsoft Azure SQL Databaseというドキュメントに明記されていますがどのサービスでも冗長化構成がとられています。まずは__手始めに SQL Database に移行__しちゃいましょう。
移行の下準備
移行先の準備
移行先の SQL Database を立てておきます。
SQL Database のプロビジョニングについては Microsoft Learn のコンテンツ アプリケーション データを格納する Azure SQL データベースをプロビジョニングする を参考にしてくださいね。
今回の移行ツールはテーブルの自動作成は行わないので、Northwind サンプルのテーブル定義をもとにテーブル作成しておきます。
移行につかうツールの準備
今回の移行には Database Migration Service を使うことはできません。2017年の記事で書いたように SQL Server インポート及びエクスポートウィザードを使うこともできるのですが、ここは Microsoft Azure のデータ統合サービスであるData Factoryを使ってコーディング無しで移行してみることにします。
Data Factory の作成については Microsoft Learn のコンテンツ Azure Data Factory におけるデータ インジェスト を参考にしてくださいね。
今回は移行テストだけできればいいので、gitでの管理を外しています。というのは Azure Data Factory はそのデータ操作内容（ETL的なデータ加工のパイプラインや元先のデータソースの定義など）を json ファイルとして任意の git サービスで管理することができます。例えば、MSDN の特典としても利用可能な Azure DevOps と組み合わせると定義内容を git でバージョン管理や整合性の管理をしつつバックアップも取れて一石二鳥という環境も簡単につくることができます。
移行元の準備
今回は、Azure Data Factory の Self Hosted Integration runtime を使った構成で行います。移行元（Access がインストールされた場所）と Azure の接続性の確保及び、 Microsoft Access 2013 Runtimeのインストールを行っておきます。
ODBCドライバにシステムDSNの設定を行います。（ここからはスクリーンショットを参考にペタペタ貼っておきます。）
通常のシステムDSNの設定なので、あまり目新しいことは無いのですが、注意ポイントとしては 64 bit OSの場合は64 bit 版の ODBC 設定画面から設定しましょう。（32 bit 版の設定画面には注意メッセージが表示されました。）
Azure Data Factory の Data Source の設定
移行元のデータソース定義
（ここからはスクリーンショットを参考にペタペタ貼っておきます。）
最初に__Connections__をクリックし、__Integration runtimes__タブをクリックし、__＋New__で追加します。
Access からデータを移行するためには Integration runtime の設定をする必要があります。これは、異なるネットワーク（オンプレミスとAzure）の間でデータ統合機能を使用するために必要な設定です。
インストール後に、Integration RuntimeがRunning状態になっていることを確認しておきます。
今度は Linked Service タブに Access の定義をつくっておきます。
Note:セキュリティ上よろしくないのですが、今回は移行テストのみなため、Anonymous(Everyoneにファイル共有＆読み取り・書き込み権限付与）にして、KeyVaultを使用せずに構築しています。
本番環境や企業内で実施する場合はきちんと Credential の管理を KeyVault 等で隠ぺいできる仕組みを考えましょう。
なお、Key1,Key2ともに再生成しているのでこちらのスクリーンショットを手入力しても使えませんのであしからず。
移行先のデータソース
先ほど同様Linked Service で今度はSQL Database を選択してデータソースを定義しておきます。
Note:SQL Database でユーザー・パスワードが合ってるのにテスト接続に失敗する場合は、SQL Database のファイアウォールの設定がされているかどうかを確認してください。うっかりミスポイントです。
移行作業の定義作成
Azure Portal の Azure Data Factory の概要ページの 作成と監視 をクリックし、Azure Data Factory Webポータルを開きます。メニューの Copy data をクリックします。
（ここからはスクリーンショットを参考にペタペタ貼っておきます。）
テーブルを選択してコピーすることも、特定のクエリで選択した結果をコピーすることも可能です。
以上で設定は終わりです。感覚的な操作でコーディング無しで移行の定義をつくるところまでできました。
テーブル定義（特にカラムのデータ型など）が一致していないと失敗しますので注意してください。
まとめ
Access のデータ移行先と移行方法はいくつかありますが、__Azure Data Factory を使用する方法はAccessだけではなく色々なデータソースに対応__しているので、統合データウェアハウスやデータレイクをコーディングレスで実装するのにはとてもやりやすいツールです。
ただ、Azure Data Factory そのものは Create Table を自動で行わないことや Integration Runtime の設定を途中で読み込むことが難しいため事前にデータの移行先についてきちんと整備しておく必要がある等の下準備をしておくことがポイントになります。
これらのツールを使うことで Northwind 社のように急な買収によってシステム統合が必要となった場合のクラウドへのデータソース移行のハードルを少しでも低くすることができますので、ぜひ一度お試しください。
参考資料
- List of fictional Microsoft companies
- Migrating to Windows Server 2019
- データストアの選択基準 （いろんなデータストアを触ってみる前に...)
- データベース
- Azure SQL Database の機能
- 高可用性と Microsoft Azure SQL Database
- アプリケーション データを格納する Azure SQL データベースをプロビジョニングする
- Azure Database Migration Guide
- Azure Database Migration Service のドキュメント
- Data Factory
- Azure Data Factory におけるデータ インジェスト
- Azure Data Factory の統合ランタイム
- Azure Data Factory を使用して Microsoft Access データ ストアをコピー元またはコピー先としてデータをコピーする
- Microsoft Access 2013 Runtime