目次


PHPアプリケーションをMySQLからDB2に移行するプロセス

第4部 (アプリケーションの実装)

IBM 社内のイントラネット・アプリケーションの事例に基づく移行について

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: PHPアプリケーションをMySQLからDB2に移行するプロセス

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:PHPアプリケーションをMySQLからDB2に移行するプロセス

このシリーズの続きに乞うご期待。

本シリーズについて

My SQL は、現在 PHP プログラミングで最も多く使用されているデータベース・サーバーですが、DB2 も PHP の機能に対応した汎用度の高いデータベースであり、多くのアプリケーションに最適な機能を提供する点では MySQL を上回る大きなメリットを提供します。

本シリーズでは、PHP アプリケーションを DB2 に移行する際のメリットについて説明したうえで、実際の移行例に基づいて移行の準備方法および実行方法、 メンテナンス方法、発生する恐れのあるリスクへの対応方法について説明します。プロジェクトをスムーズに進めるために有用なコードやコンフィギュレーショ ンのサンプルならびに各種関連情報も提供します。

実際の環境でスムーズに移行を行った例とここから得た教訓を参照することで、明確に記載されたステップに基づいて移行を簡単に実行でき、大きなメリットが得られることを確認できます。

本シリーズは 4 部に分かれています。IBM 社内で ibm.com のコンテンツ製作のために本番システムで使用されるミッション・クリティカルな PHP アプリケーション (グローバルに 4,000 名のユーザーが存在) を MySQL から DB2 にスムーズに移行したプロジェクトから得た教訓について説明 します。

  • 第 1 部では、移行準備について説明します。
  • 第 2 部では、データベース移行について説明します。
  • 第 3 部では、PHP コード変換について説明します。
  • 第 4 部では、アプリケーションの実装とメンテナンスについて説明します。

本記事の説明内容

本資料は、PHP アプリケーションを MySQL から DB2 に移行する際の一般的なステップについて理解を深めることを目的としています。あわせて、参照可能な関連情報について紹介し、IBM のプロジェクト・チームが 2010 年のはじめ実行したプロジェクトについて説明します。

MySQL から DB2 への移行について調べた経験のあるユーザーであれば、製品の説明資料、パフォーマンス・ベンチマーク、DB2 の説明資料に記載されている機能、IBM Redbook の比較資料 (MySQL to DB2 Conversion Guide、参考文献を参照) から DB2 が提供するメリットについて既にご存知かもしれません。

さらに、機能をフルに装備した無償のリレーショナル・データ・サーバー、DB2 Express-C も有益な製品です。本製品は、IBM SmartCloud (本環境は、以前は Development and Test on the IBM Cloud と呼ばれていました) または Amazon EC2 上で簡単にインストールと評価を行えます。本ソリューションに関するリンクも、参考文献に記載しました。

本シリーズは、IBM 社内で頻繁に使用される PHP によるイントラネット・アプリケーション (ibm.com の Web サイトのさまざまなページでコンテンツ管理用に使用) を 2010 年にスムーズに移行した実際の例について説明します。

本記事を読むと、同様の移行プロセスの概要把握、実行すべき項目のタイミングと条件の確認、発生する恐れのあるリスクの認識、各ステップにおけるサポートの受け方について確認することができます。これらの情報を確認すれば、ユーザーの PHP アプリケーションが現在 MySQL で構築されている場合、確信を持って DB2 を選択し最大限に活用できます。

本記事の適用について

本記事は、IBM 社内で実施した MySQL から DB2 への移行のプロセスで得られた教訓と同様の処理に利用可能な関連情報について説明します。本記事は、すべてのシナリオに対応しているわけではなく、移行に関する包括的ガイドではありません。

最適なアプローチを判定するには、“MySQL to DB2 Conversion Guide”をご参照ください。もしくは、ソフトウェア移行プロジェクト事務局 (SMPO) に、無償で移行に関する見積もりを依頼することができます。これらについては、参考文献にてリンクを記載しています。

アプリケーションの実装について

本記事では、本番稼働の準備が整ったアプリケーションとデータベースの実装とメンテナンスを行うための 4 つのステップについて説明します。必要に応じて、本シリーズの第 1 部を参照し、実装を実際に行う前の、移行プロセスの準備について確認してください。

ステップ 1: 新規の本番環境を構築する
  • 本番環境のトポロジーと実装にあたっての戦略を決定する。
  • 本番用のマスター・データ・サーバーとレプリカの DB2 データ・サーバーの設定を行う。
  • 本番用の PHP アプリケーション・サーバーの設定を行う。
ステップ 2: アプリケーションのモニタリング戦略を立てる
  • PHP によるエラー・レポーティング・メカニズムの実装または更新を行う。
  • DB2 の自動管理機能に基づいて適切な値を設定する。
  • データベースのバックアップとレプリケーションの設定を行う。
ステップ 3: 更新済みのアプリケーションを実装する
  • ビジネスへの影響を最小限に抑えられるよう、実装日を決定する。
  • 既存システムと新システムのイメージのバックアップを取る。
  • DB2 データを実装する。
  • PHP コードを実装する。
  • 新システムのモニタリングを行う。
ステップ 4: 継続的なメンテナンスを行う
  • パフォーマンス上の問題に対応し、プロアクティブな対応を取る。
  • データのサイズとワークフローの変化に基づいて、システムのコンフィギュレーションを変更する。

本事例で取り上げる既存の PTT システムのトポロジーについて

本記事で事例として取り上げる実装トポロジーであるプロジェクト・トラッキング・ツール (PTT) の本番システムは、Apache の Web サーバー (動的モジュールとして mod_php 拡張機能の構築とロードを行ったソースに基づいてコンパイル済み) を起動する 1 台の Linux マシン、MySQL のマスター・データベースを起動する 1 台の Linux マシン、およびアナリティクスとアドホックなクエリーのために MySQL のレプリケーション・データベースを起動する 1 台の Linux マシンで構成されていました。

本 PTT アプリケーションは IBM の Web サイトで提供される情報のワークフローを管理する様々な機能に使用されています。世界中の 4,000 名を越えるユーザーが PHP の Web フロント・エンド経由で MySQL データベースにアクセスし、修正を行っています。ある一時点では、数百名の同時アクセス・ユーザーが存在しています。

トポロジーの概要は、図 1 のとおりです。

図 1. 既存システムのサーバーとソフトウェアのトポロジー
End user inputs to Apache web server with PHP on Linux, which inputs to MySQL data servers on Linux, which connects to a replica. Report user is connected to replica.
End user inputs to Apache web server with PHP on Linux, which inputs to MySQL data servers on Linux, which connects to a replica. Report user is connected to replica.

大多数のユーザーは、Apache と PHP のフロント・エンド・システム経由でマスター・データベースにアクセスしています。一部のユーザーがレプリケーション・データベースに直接アクセスすることにより、アドホックな SQL クエリーを実行し、Hyperion Brio を使用してレポートを発行しています。

本事例のシステムでは 3 台のサーバーで引き続きシステムが構成され、MySQL のマスター・システムとレプリカ・システムを DB2 のインスタンスで置き換えました。Apache と PHP のコンフィギュレーションに基づいてコンパイルしたソースは、Apache と PHP (DB2 の拡張機能を実装した Zend Server) のバイナリー・パッケージ版で置き換えました。

本記事は、PHP と DB2 のトポロジーを構築する際に、コードをできるだけスムーズに本番環境に移行するために必要な考慮ポイントについて説明します。また、システム実装後に安定した状態を保つためのメンテナンス方法についても説明します。

実装に必要なコンポーネントを準備する

更新済みアプリケーションの実装準備にあたっては、安定した機能を提供するデータベースとコードのコピーが本番システムで使用可能な状態になるよう準備する必要があります。このような準備を行うためには、本シリーズの記事の第 2 部と第 3 部 (参考文献を参照) の移行プロセスと変換プロセスを繰り返し実行する必要があります。このコピーが安定した機能を提供することを確認するだけでなく、ステークホルダーの代表者がアプリケーション全体の機能について承認を行う必要があります。

安定した機能を提供する、移行対象の DB2 のデータベース構造とデータのコピー (ステーホルダーによる承認済みのもの)

本番環境が開発環境と同じプラットフォームかどうか (両環境において 64 ビットの Linux システムが実装されている場合など) によって、データを本番システムに移行するにあたり以下のいずれかのアプローチを取ることができます。同じプラットフォームである場合は、開発システムのデータベースのバックアップを取り、本番用のデータベースの新規のコピーとしてリストアすれば済みます。異なるプラットフォームが使用されている場合は、データベース構造を作成するための一連のデータ定義言語 (DDL) スクリプト (キーや値の制約のようなオブジェクト、インデックス、コンフィギュレーションの設定を含む) を本コピーに含める必要があります。さらに、移行対象のデータを新規の DB2 システムに移行するためのインポート・スクリプトも本コピーに含める必要があります。

安定した機能を提供する、変換済みの PHP コードとその他の静的ファイルのコピー (ステーホルダーによる承認済みのもの)

本コピーには、変換済みの PHP コードとその他の Web アップリケーションを構成するために必要な JavaScript ファイル、CSS ファイル、イメージ・ファイルが含まれます。定期的な通知やメンテナンス (データ管理ルールに基づく夜間のメンテナンス処理の実行など) を処理するための cron ジョブによって定期的に起動可能なシェル・スクリプトも含まれます。

本シリーズの記事で既に説明したコンフィギュレーションの考慮ポイントや教訓を参照して、実装を行う時点で本番システムに適切なコンフィギュレーションが設定されていることを確認する必要があります。実装を行う前の重要なマイルストーンにおいて、既存のシステムと新規のシステム両方のスナップショットを仮想マシン・イメージとして保存することでバックアップ・データとして活用し、今後コードの改善を行う際、比較のためのベースライン資料として利用することができます。

物理マシンのコンフィギュレーション・イメージを保存したい場合は、無償の VMware vCenter Converter を利用できます。 もしくは、クラウドを活用して、システム環境を柔軟に変更することができます。Amazon EC2 上で DB2 AMI を利用したり、IBM SmartCloud (本環境は、以前は IBM Development and Test on the IBM Cloud と呼ばれていました) を契約することも可能です。仮想化環境を活用することで、最初の段階でサーバー・ハードウェアの調達とオペレーティング・システムと DB2 のインストールの必要がなくなり、実装スピードを改善し、移行プロセスのスピードアップを図ることができます。さらに、自信を持ってニーズに最適なコンフィギュレーションを試すことができます。これらのソリューションに関するリンクは、参考文献にあります。

ステップ 1: 新規の本番環境を構築する

本シリーズの第 2 部と第 3 部 (参考文献を参照) に基づいてデータとコードを移行した時点で、アプリケーションが本番環境で必要とするリソースのコンフィギュレーションに関しては、既に検証が完了したことになります。アプリケーションのテストと検証が完了したら、次に本番で使用する環境について確認を行う必要があります。

本事例では、本番環境で実装するアプリケーションは、図 1で既に説明した MySQL ベースのシステムをホストする既存のサーバー上に実装するのではなく、新規の物理サーバー上に実装します (ただし、仮想マシンを使用することも可能) 。本ステップを実行するには、以下のサブ・ステップの実行が必要です。

本番環境の戦略を立てる

この事例では、新規に構築する DB2 データベースとそのレプリカのインストールを行い、データ―を 2 台の 64 ビットの Linux サーバーに移行します。既存の MySQL のマスター・サーバーとレプリカ・サーバーは、それぞれ 4 プロセッサー・コア (3.0 GHz) と 8 GB の RAM を搭載していました。新規の 2 台の DB2 サーバーは、8 プロセッサー・コア (2.5 GHz) と 16 GB の RAM を搭載しています。サーバーの仕様を強化したのは、DB2 を使用するにあたってハードウェアの仕様を強化する必要があったということではありません。既存のマシンが古かったためです。適切なワークロードに対して適切なシステム・リソースを割り当てるには、本シリーズにおいて既に実施した移行プロセス、変換プロセス、およびテスト・プロセス (参考文献を参照) をご参照ください。

既存の本番環境の修正を行うのか、それとも新規のマシンを実装するのかを決定する
本シリーズの記事の第 2 部と第 3 部 (参考文献を参照) のアプリケーションのテストとパフォーマンス特性に関する記載で説明したとおり、既存の MySQL のマスターとレプリカで使用しているハードウェア (または同様のハードウェア) で、新規の DB2 システムをサポートできることが分かりました。

しかし、既存のシステムは実装後 3 年以上が経過していたため、本事例では、より処理能力と効率の高いハードウェアの新規導入を行うこととしました。移行と変換のプロセスにおいて発生したボトルネックを見極めることによって、アプリケーションとデータベースのワークロードがマッチしているかどうかを判断する必要があります。その結果、新規のハードウェアを調達すべきか、既存のシステムをアップグレードすべきかの意思決定を行うことができます。

本番システムを全て置き換えるか、それとも段階に分けてアップグレードを行うかを決定する
実装プロセスでさらに考慮すべきポイントとして、現在の本番サーバーとは全く別の新規サーバーを実装するのか、既存の物理サーバーまたは仮想サーバー上でソフトウェアのみを置き換えるべきかというポイントがあります。この見極めにあたっては、新規システム全体を同時にカットオーバーさせるべきか、それとも一部のコンポーネントを個別に置き換えるべきかを決定する必要があります。

本事例においては、MySQL を DB2 に移行する前の段階で、Apache と PHP のカスタム・ビルドをパッケージ版のビルドで置き換えることも可能でした。最終的には、数段階にわたってシステム・インフラに変更を加えるのではなく、テスト済みのコンポーネントを全て同時に移行することにしました。

DB2 に基づいて構築された新規システムのトポロジーは、既存の MySQL システムのトポロジーを踏襲しましたが、新規システムは既存のステージング・システムや本番システムとは別に構築したものです。新規のシステムへの移行が完了した時点で、トラフィックを新規のフロン・エンドの Web サーバーに移行しました。このため、トラフィックの移行先を元に戻すことによって、システム環境を既存の環境に戻すことも可能でした。

本移行プロジェクトの当初は、MySQL のインスタンスを DB2 のインスタンスで置き換えることのみを考えていましたが、本事例では、移行プロセスに基づいて Apache と PHP のカスタム・ビルドをメンテナンスの容易なパッケージ版のビルドで置き換えることもしました。

DB2 のマスター・データ・サーバーとレプリカ・データ・サーバーを設定する

2 台の全く同じ仕様の 64 ビットの Red Hat Enterprise Linux サーバーに DB2 Enterprise 9.7.2 をインストールします。本記事のメモでも説明されているとおり、developerWorks の 2 種類の記事 ("DB2 for Linux, UNIX, and Windows database administration"および"Leveraging MySQL skills to learn DB2 Express: DB2 versus MySQL administration and basic tasks") を参照して、インストールとコンフィギュレーションのプロセスで必要となる重要なタスクを確認できます。これらの記事へのリンクは、参考文献にあります。

PHP のアプリケーション・サーバーを設定する

次に、Apache と Zend Server をアプリケーション・サーバーにインストールします。本サーバーは、他の 2 台のデータベース・サーバーと同様の仕様を取ることができます。既存の本番サーバーでは、Apache はソースから構築し、PHP は動的共有モジュールとして稼働するよう構築されていました。

新規の本番システムでは、Zend Server を使用し、オペレーティング・システムのパッケージ管理ユーティリティーを使用して、Apache (http) パッケージの管理とアップグレードを行います。この方法を採用した理由は以下のとおりです。

  • Zend Server は、Apache の Web サーバーのコンフィギュレーションを自動的に行える PHP のバイナリー・ディストリビューションです。さらに、Zend Server はエンタープライズ・レベルの Linux システム上で稼働できることが実証されています。パッケージ形式になっているためインストールとメンテナンスが簡単で、Red Hat Linux 上で稼働するyumツールで簡単に管理できます。
  • Zend Server には DB2 ドライバーが含まれ、拡張機能を設定するために必要な GUI インターフェースを提供します。
  • Zend Server が提供するモニタリング機能、ログ機能、アラート機能によって、システムの実行環境に関するより詳細な分析を行うことができます。

Daniel Krook による developerWorks の記事 ("Create a PHP development environment on the cloud") では、Zend Server とともに DB2 のインストールとコンフィギュレーションを行う方法について説明しています (参考文献を参照) 。本記事でも、非常によく似たプロセスについて説明しています。

図 2 は、MySQL を DB2 で置き換え、Zend Server にアップグレードした後のシステムを示しています。最後に行うべきプロセスは、IBM Cognos Business Intelligence ソフトウェアのインストールです。本ソフトウェアは既存の Hyperion Brio のデスクトップ・ツールを置き換え、新規の DB2 データベースに基づいてアナリティクスを実行します。参考文献で、Cognos のインストールについて詳細情報を確認できます。

図 2. 新規システムのサーバーとソフトウェアのトポロジー
End user connects to Apache web server, connected to DB2 data servers on Linux, which outputs to replica. Report user connects to replicat through Cognos system.
End user connects to Apache web server, connected to DB2 data servers on Linux, which outputs to replica. Report user connects to replicat through Cognos system.

ステップ 2: アプリケーションのモニタリング戦略を立てる

成熟した本番システムから移行を行う場合は、エラー・レポーティング・メカニズムが既に存在している場合あります。本事例の場合、PHP において PDO データベース抽象化レイヤーが使用されているため、コードで問題が発生した場合は、既存のシステムを使用して管理者へ問題の通知もできました。データベース・レベルでは、DB2 Health Monitor を使用して、基準値が制限値に近づいたり、制限値を超えた場合にアラートを提供していました。本ステップには、以下のサブ・ステップが含まれます。

独自に構築したエラー・レポーティングのためのコードから得られる分析結果に加えて、本事例では Zend Server に移行することによって精密なモニタリングと分析ができる環境が実現しました。

PHP のエラー・レポーティング・メカニズムを設定する

どれだけ注意深く開発とテストを行った場合でも、本番システムで予期しないエラーが発生することがあります。本アプリケーションには、既に効果的かつ自動的にデバッギングを行う機能が組み込まれています。Web アプリケーションでエラーが発生した場合は、エラーのコンテキストに関するあらゆる情報を収集し、開発担当者に電子メールを送信します。その結果、担当者は迅速に問題を見極め、問題の解決を図ることができます。本機能は、特に DB2 に移行したばかりのアプリケーションに対して役立ちます。開発者がデバッギングを行うために役立つ DB2 の SQL の状態とエラーに関するコードをアプリケーションに含めることができます。

本事例は図 2 で既に説明したアプリケーションによるエラー・レポーティング・メカニズムを活用し、データベースに基準値を設定することによって、データベースごとに設定したアラートの通知ができます。これらの基準値を超えた値が検出されると、DB2 Health Monitor から問題が発生した可能性があることを通知する電子メールが送信されます。

タイムリーにエラーとパフォーマンスに関する情報が得られることは非常に重要です。これを実現するために、本アプリケーションでは PHP コードに基づいて以下の 2 種類のメール通知を行うよう設定されています。

  • SQL エラーが発生した際には、メンテナンス・チームにメールを送信する
  • あらゆるページの実行時間が 60 秒を超えた際には、メンテナンス・チームにメールを送信する

SQL エラーを検出するために、データベース・アクセス・クラスを実装しました。これはあらゆるアプリケーションのクエリーを実行するための一連の手法を規定します。全ての SQL 文は、データベース・アクセス・クラスと本クラスに関連する手法に基づいて try/catch ブロック内で実行されます。エラーが発生すると、本クラスが包括的なトレース情報を収集し、メンテナンス・チームに本情報を送信します。通知メールには、エラー・コードと DB2 からのメッセージ、実行された SQL 文、PHP スタックトレース、処理を実行したエンドユーザーのアカウント情報などの情報が含まれます。本情報を活用して、メンテナンス・チームはエラーを特定し、問題に対処できるようになります。

リスト 1 の PHP データベース・アクセス・クラスのスニペットは、PDO トランザクション内で SQL 文を実行し、PDOException によって問題をキャプチャーできる例を示しています。

リスト 1. PDOException を使用してデータベース・エラーをキャプチャーおよび報告するための PHP コードのサンプル
<?php
// Database query or update specified by the application.
// $query = ...
Database::beginTransaction();

try {                     
	$res = Database::getRawResource()->prepare($query);
	Database::$affectedRows = 0;
	foreach ($data as $itemData) {
		Database::$queryCount++;
		if (!$res->execute($itemData)) {
			throw new PDOException("Could not execute query: $query");
		}
		Database::$affectedRows += $res->rowCount();
		$res->closeCursor();
	}
	
} catch (PDOException $e) {  
	Database::rollback();
	$error = new error("Database error: " . $e->getMessage(), 0, $query);
	if (true == Config::get('DB', 'DIE')) {
		// Captures full trace error info and sends notification.
		$error->nicedie(); 
		return $error;	
	}	
}

Database::commit();

パフォーマンス上の問題があるコードとクエリーの場合は、本スクリプトによって各ページの実行時間をキャプチャーできます。本スクリプトはメインのビジネス・ロジックを実行する前の開始時間を記録し、メインのコンテンツが表示された後の終了時間を取得し、その後トランザクション全体の処理時間を検証します。処理時間が 60 秒を超える場合は、PHP スタックトレース、HTTP リクエストともに送信されたパラメーター、ブラウザー情報、処理を実行したエンドユーザー情報を含んだ電子メールによる通知が送信されます。

リスト 2 は、設定された基準値 (60 秒) に基づいて、指定された管理者の電子メール・アドレスに通知を送信する PHP スクリプトを示しています。

リスト 2. スクリプトの実行時間を把握するためのサンプルの PHP コード
<?php
// This static function returns the current UNIX timestamp as microseconds.
function getmicrotime() {
	list($usec, $sec) = explode(" ", microtime());
	return ((float) $usec + (float) $sec);
}

$starttime = getmicrotime();

// Main PHP code for current page executes here.
// ......

$endtime = getmicrotime();

if(($starttime - $endtime) >= $CONFIG['DEBUG']['EXECUTION_THRESHOLD']) {
	$message = "Execution time > ".$CONFIG['DEBUG']['EXECUTION_THRESHOLD'].":\n\n";
	$message .= Error::createReport();
	Mailer::textmail(
		$CONFIG['DEBUG']['EXECUTION_MAIL'], 
		'Execution time greater than '. $CONFIG['DEBUG']['EXECUTION_THRESHOLD'] . 
		' seconds', $message
	);   
}

DB2 のメンテナンス・パラメーターを設定する

データベースの設定を行う際には、DB2 のメンテナンス・パラメーターがユーザーのニーズに合致していることを確認する必要があります。表 1 は、サンプルのコンフィギュレーションを示しています。これらの設定によって、頻繁に実行される DB2 の自動管理機能をバランスよく実行し、バックアップとレプリケーションをより適切に制御することができます。

表 1. DB2 のメンテナンス・パラメーターの設定
内容パラメーター設定値
自動メンテナンスAUTO_MAINTOn
データベースの自動バックアップAUTO_DB_BACKUPOff
テーブルの自動メンテナンスAUTO_TBL_MAINTOn
統計情報の自動収集AUTO_RUNSTATSOn
ステートメントの統計情報の自動収集AUTO_STMT_STATSOn
統計情報の自動プロファイリングAUTO_STATS_PROFOff
プロファイルの自動アップデートAUTO_STATS_PROFOff
自動再編成AUTO_STATS_PROFOn

DB2 のバックアップ設定とレプリケーション設定を確認する

既存の MySQL のシステムが提供する cron ベースのバックアップ・スクリプトを再利用し、カスタムのデータ管理ポリシーに準拠するアーカイブ・システムを再利用するために、表 1 の記載のとおり、DB2 の自動データベース・バックアップ機能を無効化することができます。

第 2 部で既に説明したとおり、SQL Replication を使用してマスター・データベースとレプリカ・データベースのデータを常に同期することができます。この手法を採用したうえで、ログに基づいた SQL 文を再実行して、レプリカ・データベースにマスター・データベースのデータをロードしました。

“MySQL to DB2 Conversion Guide” (参考文献を参照) の第 9 章は、バックアップ、リストア、レプリケーションの手法に関するより詳細な情報について説明しています。本資料を参照することで、適切なソリューションを確認できます。

ステップ 3: 更新済みのアプリケーションを実装する

本ステップでは最終の実装プロセスを実行し、新規のシステムをユーザーに提供します。データとコードの移行が完了後、新規システムの提供開始日を検討することになります。本事例の場合は、当初のプロジェクト・プランに基づいて、プロジェクトの開始後およそ 3 カ月で新規システムの提供開始が行われました。この新規システムの提供により起こりうる、世界中に存在するユーザーへのインパクトを最小限に抑えられるよう、ビジネス部門のニーズを勘案して実装完了までに行うべきこと決定しました。本プロセスには、以下のサブ・プロセスが含まれます。

実装日を決定する

スムーズな実装を行うには、ユーザーとサポート・スタッフ双方に最適な日を選択します。ユーザーへの影響を最小限に抑えるために、1 年のうちで重要な業務 (四半期末の締めの処理や主要製品の発売など) が発生しないと思われる週末に実装を行います。本事例では、アーキテクト、開発者、データベース管理者、およびその他の主要なステークホルダーの都合がよい週末に実装を行いました。実装に数時間しかかからないと思われる場合でも、問題に対応できるように十分な時間を割く必要があります。

本事例では、実装プロセスはアメリカ時間で営業時間終了後の金曜の夜に開始しました。この時間帯は、開発チームが存在する中国では朝に当たります。一部の問題については対応にある程度の時間が必要となったため、このスケジュールは好都合でした。問題はデータベースやコードの移行によって発生したものではなく、ファイアウォールのルールやオペレーティング・システムのパーミッションのようなシステムの他の要素に関係するものでした。システム環境の変化によってこのような要素にインパクトが発生するとは考えていなかったため、これらについてはあまり考慮していませんでした。

既存システムと新システムのイメージを保存する

本シリーズの他の記事 (参考文献を参照) で既に説明したとおり、既存のインフラの仮想マシンのイメージやバックアップを適切に保存し、実装予定の仮想マシンやバックアップ・データのコピーを作っておくことは非常に重要です。これにより、問題が発生した際にシステムのバックアップのプロセスが簡単にでき、将来開発を行う際のベースライン・システムとしての本番用コードを含んだ新規システムのコピーを作成することができます。

DB2 データを実装する

安定した機能を提供する開発用サーバーのデータベースのバックアップを作成し、本データベースを新規の本番用データベースにリストアすることによって、更新済みのデータをマスター・データ・サーバーにまずインストールします。その際 BACKUP コマンドを使用して、開発システムからデータベースを抽出します。リスト 3 は、データを移行するために必要なアーカイブを作成する方法について説明しています。

リスト 3. 本番システムにデータを移行するために、データベースのバックアップを作成する
db2 BACKUP DATABASE PTT

リスト 4 は、本番用の DB2 のマスター・サーバー上で空のデータベースを作成する方法を説明しています。本シリーズの第 2 部を参照して、このようなコンフィギュレーション・オプションを採用した理由について再確認できます。

リスト 4. 本番サーバー上に DB2 データベースを作成する
db2 "CREATE DATABASE PTT
USING CODESET UTF-8
TERRITORY US
COLLATE USING UCA500R1_S1
PAGESIZE 4096"

既に説明したとおり、異なるプラットフォーム間でデータベースの移行を行う場合は、このようにバックアップとリストアのプロセスを実行することはできません。その場合は、DDL を使用してデータベース構造とデータベース・オブジェクトのロードを行い、データは別途インポートする必要があります。データのロードに関するより詳細な情報については、本シリーズの第 2 部をご参照ください。

アプリケーションのインストールを行い、アプリケーションの機能を検証した後で、レプリケーションの設定を行うためにデータのキャプチャーとロードのジョブを起動します。レプリケーションの設定に関するより詳細な情報については、本シリーズの第 2 部をご参照ください。

リスト 5 は、RESTORE コマンドを使用してデータを本番用の DB2 のマスター・サーバーに移行する方法について説明しています。

リスト 5. データベースを本番環境にリストアする
db2 RESTORE DB PTT TAKEN AT 20100101090000 INTO PTT REPLACE EXISTING

この時点で、包括的な機能を提供するデータベースが完成したことになります。“MySQL to DB2 Conversion Guide” (参考文献を参照) の第 10 章に記載されるチェック作業を行うことによって、データが正確であることを確認します。

PHP コードを実装する

ここで実装の重要な局面を迎えます。本事例と同様に、新規システムを既存システムとは別に構築した場合、実装のプロセスにおいてトラフィックの移行先をあるシステムから別のシステムに変更し、アプリケーション・サーバーとデータ・サーバー間のコミュニケーションが正確に行われ、適切なパフォーマンスが実現していることを確認する必要があります。

新システムのモニタリングを行う

実装を行ってからの数時間および数日は、非常に重要なタイミングです。この時点でデータベースに影響を与えるアクティビティーをモニタリングする必要があります。他のデータベース・システムと同様に、何らかのロジック・エラーによって不適切なデータを作成したり、既存のデータの修正が不正確に実行されると、時間の経過とともにシームレスに修正を行うことが困難になります。バグを含むコードがさらに問題を生むことのないようシステムをオフラインにしたり、修正を行うためのスクリプトをいくつか起動することによって、不適切に変更されたデータを修正する必要がある場合があります。

したがって、夜間に実装を行うよう設定した場合は、実装後に十分な時間を割いて、サポート・チームが発生する可能性がある問題に対応できるようにする必要があります。メジャー・アップデートを実装し、実装がスムーズに完了したと早合点した後で、朝の 3 時に電話で対応を依頼されたり、複数のユーザーから問題の発生を知らせる電子メールを受け取ることになり、不測のシステム停止や大幅なシステム修正を迫られることほど最悪なことはないでしょう。

ステップ 4: 継続的なメンテナンスを行う

スムーズに実装が完了して数時間および数日が経過し、システムが安定稼働に入った時点でも、注意してシステムのモニタリングを行う必要があります。本ステップには、以下のサブ・ステップが含まれます。

トラブルシューティングとシステム診断の手法については、“MySQL to DB2 Conversion Guide” (参考文献を参照) の第 10 章をご参照ください。

パフォーマンス上の問題に対応し、プロアクティブな対応を取る

既に説明したとおり、システムが提供するアラートやトラブルに対応することは、ログの分析によるプロアクティブな問題やトレンドの検出と同様に重要です。本事例では、アメリカの東部標準時間の午前 8 時から午前 10 時の間に毎日ユーザー数が増大し、世界の他の地域でも業務開始後の同じ時間帯でユーザー数が増大することが分かっていました。スクリプトの起動時間とロックのエスカレーションを詳細にモニタリングすることで、ワークロードを迅速かつ正確に処理できるようにしました。

例えば、分析を行うことにより、ある非常にスピードが遅いクエリーについては、それほど多くのデータベース・テーブルの結合処理を行う必要がないことが判明しました。別の分析では、同時実行を行う際の分離レベルの条件が厳しすぎることが分かりました。クエリーの実行によってファントム・リードやその他の不整合が発生するケースから問題を検出できる場合があります。ユーザーと継続的にコミュニケーションを持つことによって、ユーザーが問題と思われる事象を適切なタイミングと方法で報告できる環境を構築する必要があります。さらに、本シリーズの第 3 部で使用した手法を活用することで、システムの最適化を行うことができます。

データのサイズとワークフローの変化に基づいて、システムのコンフィギュレーションを変更する

あらゆるアプリケーションには、同じライフサイクルがあります。実装とメンテナンスが行われ、最終的にはサービス提供が終了します。このライフサイクルを通じて、アプリケーションには限りない数の機能拡張が適用されます。同様に、全てのユーザーのアプリケーションに関しても、モニタリングと機能拡張を行う必要があります。

DB2 は、メンテナンス作業に役立つ多くのツールを提供します。このようなツールについて知識を深め、実際に使用し、問題が発生した場合に誰にサポートを求めるべきか確認しておく必要があります。通常、他の DB2 ユーザーも同様の状況を経験していることがよくあります。勿論、IBM からも必要に応じてユーザーにサポートを提供します。

本事例の開発者は、参考文献の「議論するために」に記載される Web サイトやフォーラムの情報をフォローしました。こうすることで、DB2 のセキュリティー・アップデートやフィックス・パックの最新情報を把握し、現在のニーズに合致する新規機能について理解を深めることができました。

移行によって実現した結果

本事例では、アプリケーションの実装後すぐに、予定していたメリットの多くが実現したことを確認できました。特に、ビジネス・プロセスの改善効果を確認することができました。本データベース・システムはビジネスの意思決定に役立つ重要な評価指標を正確に提供できるため、この点に関する効果が期待されていました。また、本事例では、将来データが増大した時点で、パフォーマンスと拡張性に大きな影響を及ぼす DB2 の先進データベース機能 (拡張性を最大限に高める機能、精緻なセキュリティー管理機能、ネイティブ XML のストレージ機能、データ圧縮機能など) を活用することもできます。

Cognos Business Intelligence の実装によるメリット

DB2 に移行することで、レポーティングのために Cognos を使用できるようになりました。この結果、Web 上でレポートを発行し、どのユーザーが当該レポートを参照できるのかを制御できるようになりました。以前はレポーティングのプロセスを毎週 1 回行っていましたが、今では、クエリーの実行、データの加工とビジュアル化、重要な分析結果の提供までのプロセスがほぼ 16 時間で完了できるようになりました。レポーティングのプロセスは以前は手作業でエラーが発生することが多かったため、経営陣に正確な情報を提供することが困難だったものも、新システムによって変動するビジネス環境により迅速かつ俊敏に対応できるようになりました。

新システムではビジネス・アナリストが正確なレポートを 6 時間以内に発行できるようになり、レポートの発行にあたって専任の技術担当者は不要になりました。さらに、アクセス制御機能の改善によって、ユーザーが自分のニーズに合致する情報を参照し、情報に基づいて行動を起こせるようになったため、より効果的にビジネス上の目標を達成できるようになりました。

さらに、古いシステムでは、エンドユーザーはサイズの大きなレポート・ファイルをダウンロードする必要があり、各レポートのダウンロードに 10 分の時間がかかっていました。しかも、レポートのデータはレポートを起動した時点での最新データを提供していました。新システムでは、ユーザーは Web ブラウザーを使って迅速にレポートにアクセスできるようになりました。一部のレポートはある特定の時点のスナップショットのデータを提供しますが、ほとんどのレポートはリアルタイム・データを提供しています。そのため、ユーザーはいつでも最新の情報を参照できるようになりました。

データ品質の向上

新システムは CHECK 制約とキーに基づくリレーションシップによってデータベースにおけるビジネス・ルールを実行するため、データの整合性の問題によるデータベースでの問題発生を防止できるようになりました。このため、データの品質を改善できるようになりました。以前はデータの不整合を毎週手作業で修正することがよくありました。今では、月次のトラブル・レポートも発行されなくなり、実装後の最初の 3 カ月で以前は月次で 12 件発生していたトラブルも 0 件になったため、開発者が毎月数時間かけて行っていた作業もなくなり、エンドユーザーがより安心して本システムを活用できるようになりました。

ユーザー・エクスペリエンスへの影響を最小限に抑えることに成功

移行を実施した最初の週末にはシステムは使えなくなったものの、それ以降はユーザーに大きな影響は出ませんでした。今回の事前計画に基づくシステム停止は、新規アプリケーションの提供や、通常のシステムのメンテナンスやアップグレードの際の事前通知に基づいて実施するシステム停止と何ら変わることがありませんでした。したがって、エンドユーザーの観点からも、何のデメリットも発生させることなく、よりよいシステムを実現することができました。

パフォーマンスとモニタリングを改善

DB2 に含まれる幅広い自動管理機能と一連のツールを活用することで、MySQL ベースのシステムに比べて、より迅速にアプリケーションに関する問題を見極め、解決できるようになりました。DB2 の自動システム・チューニング機能を活用できるようになり、基準値に達する前にアラートを受領できるようになりました。

メンテナンスの簡略化

本事例では、以前はデータベース管理者が手作業で毎月 1 回インデックスを追加する必要があったものが、新システムへの移行後は、パフォーマンス向上のためのパッチを四半期に 1 度かそれ以下の頻度で実装すればよくなりました。

IBM ソリューションを活用するための様々なオプションが存在

DB2 に移行することで Cognos Business Intelligence を活用できるようになったことに加えて、PHP から WebSphere ベースの Java EE ソリューションに将来的に移行する計画も立案されることとなりました。また、様々な IBM ソフトウェア・スタックや IBM のクラウド・コンピューティング基盤やプラットフォーム・サービスとよりシンプルな連携を実現することも、将来的な計画として検討されています。

結論

本資料の目的は、PHP アプリケーションを MySQL から DB2 に移行する際に通常必要となるプロセスを理解し、利用可能な参照資料を把握し、実際にスムーズに移行を行った事例について確認することにあります。

本シリーズの第 1 部では、以下の情報を確認しました。

  • IBM によるアプリケーションの移行事例の目的、リスク、およびメリットについて確認する。
  • 本事例で発生した内容を確認することによって、DB2 の機能を説明した様々な資料を参照し、MySQL の移行に必要なプロセスを理解する。
  • 移行を実行するにあたって役立つツールについて確認する。
  • 様々なツールやリソースを組み合わせて使用することで、プロジェクトの各フェーズのプロセスをスムーズに実行できることを確認する。

本シリーズの第 2 部では、以下の情報を確認しました。

  • 変換対象の移行元の MySQL データベースについて確認する。
  • DB2 用にデータベース構造を変換する方法について確認する。
  • データを DB2 に移行する方法について確認する。
  • データベースの管理機能の設定方法について確認する。

本シリーズの第 3 部では、以下の情報を確認しました。

  • 変換の対象となる移行元の PHP コードについて理解する。
  • DB2 用にアプリケーションをアップデートする方法について確認する。
  • 変換を行った後で、コードのテストとチューニングを行う方法について確認する。

本シリーズの第 4 部では、以下の情報を確認しました。

  • DB2 ベースのトポロジーに基づいてアプリケーションの準備と実装を行う方法について確認する。
  • 新規のシステムで発生する問題をトラッキングすることを目的として、継続的なメンテナンスを行う方法について確認する。
  • 本移行プロジェクトを実行することによって得られたメリットについて理解する。

本シリーズの記事を参照することで、MySQL から DB2 への移行を行うにあたっての計画を立てることができ、実際の移行事例から得られた教訓に基づいて、各ステップで必要となる情報を確認できます。

各ユーザーにとって最適な手法を決定するにあたっては、“MySQL to DB2 Conversion Guide” (参考文献にリンクがあります) をご参照ください。もしくは、ソフトウェア移行プロジェクト事務局 (SMPO) に無償で移行に関する見積もりを依頼できます。これらについては、参考文献にてリンクが提供されています。

謝辞

本記事の内容を確認し、コメントを提供してくれた Leons Petrazickis と Ambrish Bhargava に感謝します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management, Open source
ArticleID=845096
ArticleTitle=PHPアプリケーションをMySQLからDB2に移行するプロセス: 第4部 (アプリケーションの実装)
publish-date=11302012