システムのマイグレーションにおいて、データベース（以下DB）に関する変更を行う場合があります。DBはシステムの根幹を担う存在であり、この際にはさまざまな懸念点があります。たとえばスキーマ変更やデータ移行に伴うダウンタイムのリスクがあり、その解決手段としてDBテストが欠かせません。
本記事ではDBテストにおける課題と解決策について解説いたします。
マイグレーションにおけるDBテストとは
マイグレーション時におけるDBに関する変更としては、以下が挙げられます。
– DBの変更
– DBのバージョンアップ
– スキーマ変更
– データ移行
いずれの場合においても、移行した後にテストを実施してDBの正常性を確認しなければなりません。主なテストとしては、以下が挙げられます。
スキーマの整合性テスト
スキーマはDBの設計図であり、根幹です。これがマイグレーション前後で正しい状態であることを確認します。開発環境と本番環境でカラムの並び順が異なってエラーになる、張られているべき外部キーやインデックスがないといった問題を発見できます。
データの整合性テスト
カラムの種類を変えたり、DBを変更したりすると、データの整合性が損なわれる場合があります。開発環境のDBは個人情報などがマスクされているため、移行前後の本番環境のデータを利用してテストを行います。
パフォーマンス・負荷テスト
DBをバージョンアップ、または別なDBに載せ替えた場合には、パフォーマンステストや負荷テストが必須です。クエリの実行速度やDBの応答時間を測定し、必要に応じて最適化を行います。
バックアップ・リストアテスト
本番環境のデータが正しくバックアップされており、かつリストアも問題ないことを確認するテストです。バックアップされているはず、と思い込んだ結果、万一の際にデータが消失するケースは少なくありません。バックアップのタイミング含め、正しく動作していることをテストします。
マイグレーションにおける課題
DBはシステムのボトルネックになりやすいと言われます。理由は、アプリケーションサーバーは増やせても、DBをスケールさせるのは難しいためです。そのため、DBテストを適切に行い、常に最良のパフォーマンスを出せるように準備が必要です。
複雑性
DBはアプリケーションから利用するのが基本です。DB自体の複雑さに加えて、そうした利用する外部システムとの互換性も考慮しなければなりません。クライアントのドライバーがDBと適合していないと、レスポンスが文字化けしてしまう、対応していない文字コードを送信してDBに障害が発生することもあります。
また、DBには固有の方言、固有の機能があります。SQL以外のトリガー周りはDB依存性が高く、マイグレーション時の足かせになることが多々あります。扱えるデータ型についても、DB毎に異なるので注意が必要です。
ダウンタイム
マイグレーション時には一定のダウンタイムが発生するのは致し方ないでしょう。ビジネスへの影響を最小限にする必要があります。Amazon Aurora PostgreSQLやGoogle Cloud SQL for PostgreSQLなどのマネージメントサービスではダウンタイムが（ほぼ）ゼロでのパッチ処理などをサポートしています。こうしたサービスを利用するのも一つの解決策です。
テスト
DBのテストを適切に設計するのは困難です。DBはアプリケーションと密接に関連していたり、トリガーなどの独自処理も追加できます。そのため、単体テストでデータベースに関連する処理をカバーするのは難しいでしょう。結合テストなどで、ワークフローを通じてDB周りもカバーする形になります。ただしアプリケーションからすべてのデータに触れるよう設計するのも大変・スクリプトが膨大になってしまうので、テストの範囲をどこまで広げるかが難しい判断になります。
テスト環境を用意する際にも、本番環境と同等の環境を作るのは多大なリソースが必要です。また、大量のデータを用いた負荷テストを行う場合、テストデータの作成やテストの実行に時間がかかるため、効率的なテストの実施が難しい点も挙げられます。
マイグレーションDBテストの解決策
では、このようなマイグレーションDBテストの課題をどのように解決すればよいのでしょうか？以下にいくつかの解決策を紹介します。
計画立案
マイグレーションを円滑に成功させるためには、まず詳細な計画立案が不可欠です。DBの停止はビジネスへの影響が確実にありますので、利用者への告知も十分に行わなければなりません。そして、最小限の時間で済むように設計します。
マイグレーション時に何らかの問題が発生した場合に備えて、バックアップや社内での通知体制を整えましょう。移行が完了した後もモニタリングを続け、問題が発生した際に素早く対応できるようにしておきます。
テスト環境の構築
実運用環境と同じDB環境を構築し、テストを十分に行います。ただし、クラウド環境などではOSがすでにバージョンアップしているなど、ライブラリまで含めてまったく同じ環境を作るのは難しいかも知れません。
テスト環境ではスキーマ変更やデータ移行をシミュレーションし、なるべく手作業なしで行えるように準備を整えます。テスト環境で潜在的な問題を発見し、移行後のトラブルを防ぎましょう。
テスト自動化ツールの活用
DBのテストは複数のステップを経て行われるので、自動化ツールの活用も検討したいところです。自動化ツールを利用することで、同じ手順を繰り返し検証できます。また、自動化ツールを利用すれば作業漏れ、検証漏れを防げます。
適切な計画立案を行い、それに沿ってテストスクリプトを作成しましょう。
マイグレーション品質向上支援サービスのご紹介
バルテスでは長期・大規模・高難度のマイグレーションプロジェクトを支援する「マイグレーション品質向上支援」を提供しています。当サービスでは、マイグレーション経験者を中心とした品質管理支援担当（QMO）が御社プロジェクトに参画し、品質活動を推進します。
マイグレーションプロジェクトで起こりがちな「現行システムの仕様がわからない」という課題に対して、システムマイニングのツールを活用して現行システムフローを可視化します。
また、マイグレーションで発生するリグレッションテストについては、当社のテスト自動化ツール「T-DASH」を利用して省力化を図ります。さらに、テスト管理ツール「QualityTracker」を活用して、ボリュームの高いテストを一元管理します。
まとめ
DBはシステムの根幹を担う存在であり、マイグレーションの失敗はビジネスの致命的な問題になりかねません。それを防ぐためには、綿密な計画、テスト環境そしてテスト自動化ツールの活用が肝要です。
バルテスでは、マイグレーション品質向上支援サービスを提供しています。マイグレーションプロジェクトにおける品質活動を支援し、成功を後押しします。マイグレーションプロジェクトにおいて課題を感じていましたら、ぜひバルテスにお問い合わせください。
当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。
