株式会社東レシステムセンター｜DMSによる“双方向連携”を活用し224の業務アプリをわずか15カ月間で移行完了させ、ExadataからAWS RDSへの大規模移行を実現

東レは、高騰するOracle Exadataの保守費用からの脱却と、機器老朽化への対応のため、AWS RDS for Oracleへの大規模なクラウドシフトを決断した。最大の課題は、Exadata特有の機能に頼らず、基幹システムを含む224のアプリケーションの性能を維持すること。この難題に対し、同社はインサイトテクノロジーに支援を要請した。
Insight SQL Testingを用いた綿密な性能アセスメントと、データ連携の複雑な設計を含む、AWS移行のための総合的なコンサルティングサービスを活用。性能劣化を事前に数値化して予測し、不安を払拭することができた。その上でAWS DMSによる「双方向連携」という前例のない方法を採用し、タイトなスケジュールと技術的な障壁を無事に乗り越え、大規模移行を成功に導いた。

まずは東レグループにおける東レシステムセンターの役割、そして今回の大規模なクラウド移行の背景と、Exadataからの移行を決断した理由をお聞かせください。

塙氏　東レシステムセンターは、東レグループの事業を支える情報システム会社として、情報インフラの企画から運用までを担っています。今回、2022年度下期から2024年度にかけて、システムセンター内のデータセンター機能を収束させる大規模な「クラウドシフトプロジェクト」を実施しました。

田中氏　このプロジェクトは、元々、東レの滋賀システムセンターというデータセンターにあるホストコンピュータの外部への移設、それと合わせて620台ほどある仮想サーバーをAWSに移行するものでした。移行対象のサーバーの中に、基幹システムを支えてきたOracle Exadata環境もあり、そのアプリケーションとデータベースをAWSへ移行することとなりました。滋賀システムセンターのデータセンター機能を収束させることが、大きな目的でした。

塙氏　Oracle Exadata移行の主な背景は、機器の老朽化、煩雑なOracleのライセンス管理、そして高騰するソフトウェア・ハードウェアの保守費用からの脱却です。特に、運用負荷を軽減するために管理を自社からクラウドベンダーに任せたいとの意向が強く、さらにコスト削減を最大限に図るために、高額なEnterprise EditionからOracle Standard Edition(SE)への移行を目指し、AWS RDS for Oracleを選択しました。
当初は脱OracleでPostgreSQLへの移行も視野に入れましたが、更改の期限が迫る中でデータベース移行に伴うアプリケーションの改修期間が取れないと判断し、最終的にRDS for Oracleの採用となりました。

移行プロジェクトにおける主要な要件は何でしたか?

田中氏　最も大きな制約は、スケジュールでした。オンプレミスのOracle Exadataの保守期限が2024年12月頃に迫っていたため、そこまでに移行を完了させる必要がありました。
また、移行の対象となるWebアプリケーションは260を超えていました。それを精査し減らしたものの、移行対象になるWebアプリケーションは224にものぼりました。多くがホストと連携するもので、その他にも業務アプリケーションがありました。特にホストと連携するアプリケーションは重要な業務を担っており、停止が極めて困難なものでした。平日の日中帯には停止が難しく、そのため移行に伴う停止を最小限にし、高い可用性が求められました。さらに性能面では、Exadataで動いていた時と同等以上を維持することが最低限の要件でした。

塙氏　基幹システムなので、止められる日時には制約がありました。224のアプリケーションはそれぞれ管理者も違えば担当者も異なったので、一度に全てを止めて移行することができませんでした。個別にダウンタイムを調整する必要があり、さらにアプリケーション間でのデータ参照があったので、1つのアプリケーションを移行する際に参照元のデータがExadataに残っている場合は同期をとる必要がありました。複雑なデータ参照依存がある中で業務を止めないように調整する。そのために双方のアプリケーション間でレプリケーションをしながらの移行となり、その調整はかなり大変でした。

インサイトテクノロジーにプロジェクトの支援を依頼した背景と、決め手となったポイントは何ですか?

塙氏　クラウドシフトプロジェクトの中で、もっとも懸念があったのがOracle Exadataの移行でした。既存のExadataのデータ容量は5テラバイトを超え、テーブル数も約5万と極めて大規模なデータベースでした。これをクラウドへ移行する際に最も懸念されたのが、パフォーマンスの維持でした。高性能化のためのさまざまな機能が
あるExadataからStandard Edition(SE)ベースのRDSへの移行で、性能を維持できるという確証が必要でした。
当初、他社ツールを用いてExadataのワークロードを再現し、性能評価を行うことを検討しました。しかし、ライセンスの問題や既存ベンダーの知見不足で、それは断念せざるを得ませんでした。この性能評価の模索中に、データベースに関する豊富な知見があり、レプリケーションツール(Qlik Replicate)などで以前から認知していた
インサイトテクノロジーの存在を改めて認識することになります。
そして、インサイトテクノロジーの「Insight SQL Testing」というツールを使えば、ExadataのSQLを抽出してRDS上で再現し性能差を客観的に評価できると知り、性能検証を含めた支援をインサイトテクノロジーに依頼するに至りました。

宮地　じつは以前に、今回のExadataをクラウドに持って行けないかとの相談があり、その際にQlik Replicateの前身であるAttunity Replicateを使い、PoCの環境構築などのお手伝いをしたことがありました。それでインサイトテクノロジーのことは知っていただいていたのかと思います。

森田氏　そのPoCを担当したのは私でした。5年ほど前のことで、御社のことはとても印象に残っていました。

インサイトテクノロジーによる支援内容の詳細について教えてください。

塙氏　インサイトテクノロジーには、移行実現のために必要な包括的な支援をお願いしました。御社に依頼する前には、AWSに依頼して移行で必要となるRDSのスペックを分析してもらっています。その結果、かなり大きなインスタンスのRDSが必要となり、それだとかなりのコスト高になると感じていました。そこでコスト削減に向け詳細な性能アセスメントをお願いしました。

宮地　最初の1カ月ほどで、AWSのレポートにあったクエリーのリストから遅いもの、コストの高いものを特定し、その改善方法のアドバイスをさせてもらいました。

大橋　その後、RDSのインスタンスを縮小するために既存のExadataのSQLを収集し、それを用いてRDSでのレスポンスタイムを比較しました。処理時間が5秒以上遅延するSQLを特定して、チューニング対象を絞り込むなどを行っています。
この検証を通じて、スマートキャッシュなどのExadata特有の機能がOLTP業務ではほとんど利用されていないことが確認できました。データウェアハウス系のクエリーではスマートキャッシュを使っていたので、そのままだと遅くなるため、適宜チューニングするといったアドバイスさせていただきました。

田中氏　ExadataからRDSに移行して何パーセント性能が劣化するのか、それがインサイトテクノロジーの協力の下、Insight SQL Testingを使って具体的に把握できたからこそ、Exadataを辞める判断ができました。

塙氏　また、データ移行にはAWS Database Migration Service(DMS)を利用しましたが、業務間の依存関係を解消するために、RDSに移行した業務データをExadata側へ一時的に逆向きに連携させる「双方向連携」という特殊な設計を行いました。これにより、業務単位で順次移行を進めつつも、未移行のシステムが必要とする最新データを参照できるようになり、ダウンタイムを最小限に抑えられました。

大橋　今回の移行では、移行元となるデータベースインスタンスが4つあり、単なる移行にとどまらず、RDSのデータをDMSで逆向きにExadataにも連携するという、少し特殊な構成でした。そのため、移行用と双方向連携用にDMSのインスタンスを分け、移行のタイミングだけ移行用インスタンスを起動し、完了後は停止するという運用を提案しました。これにより、DMSの利用コストの最適化と、ランニングコストの抑制にもつなげています。

塙氏　また、DMSによるレプリケーションでは通信品質とセキュリティの観点から専用線を利用する必要がありましたが、どの程度の帯域が必要か、サービスに影響が出ないかを事前に把握することが重要でした。ネットワーク設計時には、Exadata→DMS→RDS間のトラフィック量を検証いただき、トラフィックが多いレプリケーションタスクでは240Mbpsの帯域が必要であることが判明しました。
その結果、サービス用の専用線とは別に移行用の専用線を確保する必要があることがわかり、ネットワーク面でのトラブルを未然に防ぐことができました。

大橋　他には、既存のExadata環境でOracle Enterprise Manager(EM)を用いて実施していた監視・運用を、RDS環境でも実現するようにしています。EMが内部でどういうSQLを発行していたかはインサイトテクノロジーで把握していました。ですので、AWS標準の監視では取得できないOracle Database内部の情報(表領域の使用量など)を取得するスクリプトを開発して情報を集約し、移行後の監視と運用の一元管理体制を構築しました。

塙氏　詳細をお話しすると、AWSの標準RDSインスタンスの監視に加えて、Oracleデータベースの内部情報を取得するためにスクリプトを開発し、データを集約しています。こうした仕組みを使って、両方の監視をZabbixで一元的に管理しています。

移行プロジェクトで最も苦労した点と、それをどのような工夫で乗り越えたかを教えていただけますか?

塙氏　たとえば、プライマリーキーを持たないテーブルに対してアプリケーション側で大量の削除・変更処理が発生した際、DMSの仕組み上で同期遅延が生じ、一時的に業務に影響が出たことがありました。
平均で3~7秒、負荷が高い処理中でも十数秒に抑えることはできていたのですが、5分を超える遅延が発生した場合には、原因特定と解消のためのトラブルシュート、アプリケーション部門への影響確認を迅速に実施いただきました。
また、移行リハーサルの初期段階では、双方向連携の切替手順ミスが原因で、移行元・移行先双方のデータがゼロになるという予期せぬ障害も発生しましたが、リカバリと再発防止策を即座に講じることができました。
これらの課題の解決には、インサイトテクノロジーの迅速かつ的確な技術支援が大きく寄与してくれました。
例えば、DMSの知見に基づき、プライマリーキーがないテーブルに対する大量処理が必要な場合には、レプリケーションタスクを分離し、他のタスクへの影響を最小限に抑える工夫を施しました。
さらに、監視体制の強化により、トラブルシューティングからアプリケーション担当への連絡まで、迅速な対応を可能としてくれました。

大橋　今回、224業務だと20回くらいは移行を実施しています。リハーサルを合わせると、40回以上の作業をしています。それを1年ちょっとの期間でやる必要があり、毎週何らか移行作業をしているような状況でした。その間に業務側の都合で、リハーサルと本番のタイミングを変更しなければならない状況も発生しました。双方向連携を行う都合上、リハーサルと双方向連携の順番は同じにする必要があり、その辺りの調整を東レ様側で行ってもらうのはかなり大変だったと思います。結果的に、移行に伴う大きな業務影響はなかったのかなと思います。

今若氏　移行順序に関する調整も大きな課題でした。インサイトから、連携を考慮するとリハーサルと本番移行の順番を厳密に守る必要があるとの指摘があり、アプリケーション部隊も尽力して複雑な移行順序を調整しきったことも、プロジェクト成功の大きな要因となりました。これだけ無理なスケジュールの調整に、インサイトテクノ
ロジーはとことん付き合ってくれて、本当に助かりました。

田中氏　最も困難をきわめたのは、AWS DMSを使ったデータ連携と双方向連携の設計・運用でした。前例のないDMSを使った双方向連携における同期遅延をいかに短くするか。これが最も重要な課題でした。技術面だけでなくコミュニケーションも含めてインサイトテクノロジーの協力でそれを乗り越えられました。

移行プロジェクト全体の評価と、インサイトテクノロジーへの期待を教えてください。

塙氏　プロジェクトは成功裏に完了し、Exadataを継続しなければならないのではとの不安を完全に払拭できたことが最大の成果です。特に、Insight SQL Testingを活用して、RDSに移行した際にどのくらい性能が劣化するかを事前に数値化し、どのSQLのチューニングが必要かを明確にできたことで、アプリケーション担当者も安心して移行を進められた点は高く評価しています。

増田氏　もしこのSQL Testingの事前検証の結果が得られていなければ、不安からExadata継続との判断もあったかもしれません。移行後の環境は非常に安定しており、Exadata時代に発生していたような、SQL暴走による手動介入が必要な事態なども起きておらず、運用負荷は大幅に軽減されています。この大規模移行の成功は社内でも高く評価され、プロジェクトは東レシステムセンターの社長賞を受賞することができました。

大橋　SQL Testingの操作自体は、今回インサイトテクノロジー側で実施しており、その結果を適宜提示するようにしていました。

森田氏　裏ではかなり苦労していたのではと思います。そういったところからも、インサイトテクノロジーの技術力の高さを評価しています。また、タイトなスケジュールの中でも、プロジェクトをけん引する強力なリーダーシップと柔軟な対応にも大変満足しています。

今若氏　Oracle Golden Gateなども使っていたので、データベースのデータ連携については分かっているつもりでした。とはいえ、DMSのエラーについてはよく分からないことが多かったです。それに対し大橋さんからはかなり迅速に返答があり、すごいなと思っていました。あとは、我々でも無理だと思っていたスケジュールに最後まで付き合ってくれて、本当に助かりました。

大橋　ピーク時には、コンサルチームの7割ほどのメンバーがこのプロジェクトに携わったかもしれません。期間も短かったので、振り返ってみるとその点は確かに大変でした。

宮地　東レさん側でしっかり調整してくれたことも、大きかったと思います。

森田氏　他のベンダーさんから聞いたのですが、200を超えるアプリケーションの移行を、戻しなしにやりきったとの話は聞いたことがないとのこと。この話を聞いたことは自分の中にも響いていて、やっぱりこのプロジェクトをやりきったのはすごいことだったのだなと思っています。

塙氏　トラブル発生時、特にDMSのエラーなど、我々では原因の特定が難しい部分でも、エラーメッセージを見ただけで、AWSからの回答よりも早く解決策を提示してもらえました。これは、データベースはもちろん、レプリケーションツールに関する豊富な経験と知見のたまものだと感じています。大規模なプロジェクトでデータベースを扱うようなプロジェクトでは、また是非協力していただきたいなと思っています。

増田氏　移行プロジェクトは大変だったのですが、移行後はびっくりするぐらい問題なく稼働しています。今後は、アプリケーションのモダナイゼーション(モノリシックからAPI参照への切り替えなど)や、新規開発におけるRDS PostgreSQLの採用検討も進めます。
一部、古い仕組みがOracle Databaseとして残っているため、新旧システムをどう扱っていくかが今後の課題です。データベースに関わる課題は今後も出てくると思われますので、引き続きインサイトテクノロジーの知見と支援には大いに期待しています。