TOP
＞
業務システム
＞ 移行を決断するまでの経緯
勝ち組に学ぶシステム導入事例
第２回：大手ブログ検索サイトがPostgreSQLからOracleへ移行を決断した理由（前編）
著者：
ミラクル・リナックス 高橋 強
2006/4/5
前のページ
1
2
3
次のページ
移行を決断するまでの経緯
ところが6,000万件を超える辺りから、インスタンスを増設しても改善されず、以下のような性能劣化が発生しました。
システム負荷が高い（CPUロードアベレージが常時20以上）
定期的に行っていたオンラインVACUUM（注1）が数日かけても終了せず、ディスク容量を圧迫しはじめた
表1：発生した問題点
※注1：
VACUUMについては、連載「徹底比較!! Oracle & PostgreSQL 第３回：アーキテクチャ比較 ファイル構造の違い」を参照
http://www.thinkit.co.jp/cert/compare/1/3/3.htm
さらにアプリケーション側からの検索処理は可能でも、蓄積したデータから統計情報を収集する際にSQLの反応が戻ってこない、データの登録処理が遅くなるなどの影響もでていました。
こうした状況から、データ増加速度に対して今後もPostgreSQLでの運用やスケーラビリティに限界を感じ、他のデータベースへの移行の必要性を痛感していた折、タイミングよく日本オラクルによるOSSデータベースからの移行セミナーが開催されました。
そこで、大容量のデータを自動的に分割・管理し、性能も維持できる「パーティショニング機能」を知り、「Oracleを採用すればすべての問題がクリアになる」と感じたそうです。
同社ではすぐに評価版を入手し、さっそく検証を開始しました。そして実際に約500万件のサブセットデータをOracle Databaseにインポートすることで既存データを移行できると判断。またアクセスが集中した状態を想定するため、データベースへの同時書き込みの多重度を40〜50程度に上げた状態でCPUへの負荷テストを実施し、パフォーマンスを測定したところ問題なく動作することを確認しました（ロードアベレージは1以下）。
このテストにより移行前のデータベースサーバ2台、PostgreSQLのインスタンス5つという状態（図1でいう左下のデータベースサーバ2台で稼働）から、サーバ1台でインスタンス1つという理想的な構成での運用が可能と判断したのです。
図2：移行前後のデータベースサーバ構成
PostgreSQLでの運用開始からたった半年で、データ量が1億件に到達する事が確実となったこともあり、これ以上PostgreSQLでのデータ分割では対処できないと判断しました。
移行方法の決定まで
Oracle Databaseへの移行を固めつつある頃、別件で弊社とのやり取りがあった関係もあって、筆者は移行作業の技術的なコンサルティングを担当することになりました。
この時点で作業上の要件は以下のようなものでした。
PostgreSQL V8.0.3 → Oracle10gR2 (OSはMIRACLE LINUX V4.0 x86-64)
移行対象表の最大データ数は1億件以上
停止可能期間は仮に最大2日間
表2：移行作業の要件
データ件数とシステムの停止可能期間を考えると、かなり難しい作業となることが予想されました。そこで移行を実施する上でまず最初に提案したのは、ハードウェアを新たに準備してもらい、新旧環境の平行稼働が可能な環境を構築することでした。
これは下記の目的を狙ってのことでした。
目的：バックアップ採取、復元のリスクを排除
なぜかというと、もし何かトラブルが発生した場合はPostgreSQL環境へ速やかに戻し、継続して稼働できることが必須の条件と考えたためです。そして結果的には下記にあげる副次的な効果をもたらしました。
副次的効果：平行稼働可能な環境を構築することで柔軟な移行スケジュールをたてられる
これにより、平行稼働でなければ移行作業そのものが難しい状況をカバーすることとなりました。
前のページ
1
2
3
次のページ
著者プロフィール
ミラクル・リナックス株式会社 高橋 強
1993年某SIベンダへ入社後、Oracle、DB関連のコンサルティング、チューニング、社内案件の技術支援などを10年ほど担当。2004年ミラクル・リナックス株式会社へ入社。
INDEX
第2回：大手ブログ検索サイトがPostgreSQLからOracleへ移行を決断した理由（前編）
オープンソースからの移行を考える
移行を決断するまでの経緯
移行の際のポイント
