オンプレミスの基幹データベースを、AWSへの移行を成功させるポイントとは？

自社のシステムをクラウドへ移行する企業が増加する中、移行作業の効率化やクラウド上での可用性の確保を求める声が高まっています。

伊藤忠テクノソリューションズ株式会社（以下CTC）は、オンプレミス環境からアマゾン ウェブ サービス（以下AWS）へのデータベース移行と冗長化を支援すべく、「データベース移行ソリューション for AWS」と「データベース冗長化ソリューション for AWS」を提供しています。

今回は、同社流通・EPビジネス企画室 クラウドインテグレーションビジネス推進部 エンタープライズクラウド技術課課長の髙橋達矢氏、同主任の古川英一氏に、「データベース移行ソリューション for AWS」と「データベース冗長化ソリューション for AWS」の特長と優位性についてお話をうかがいました。

―　まず、お二人の所属部門とミッションについてご紹介ください。

髙橋氏：
　流通・EPビジネス企画室では、流通・EP事業グループで推進するさまざまなサービスの売り方や売りモノを企画・整備しています。クラウド、セキュリティ、アジャイルといった最近のトレンドを中心に、Salesforceやその他の製品を取り扱っていますが、その中でエンタープライズクラウド技術課はAWSなどのクラウドインテグレーションの技術推進、部内にて取り扱っている製品の支援を行っています。今回お話させていただくソリューションは、クラウドの技術推進の一環として実施しました。そのソリューションの企画・立ち上げをメインで担当したのが、古川となります。

古川氏：
　私は主として、クラウドインテグレーションのプリセールス支援と、お客様に訴求できるような新しいソリューションの企画・立ち上げを担当しています。

クラウドがエンタープライズシステムの基盤になることを見据えた新ソリューション

―　今年の3月29日にプレスリリースで発表された、「データベース移行ソリューション for AWS」と「データベース冗長化ソリューション for AWS」に関して、サービスの概要をご紹介いただけますか。

古川氏：
　まず背景状況をご説明しますと、今までLOB（事業部門）のデジタルマーケティングなどに使われるのが一般的だったAWSが、最近では、社内システムや業務システムなど、エンタープライズシステムの移行へと拡張してきています。現状ではまだまだ一部の用途に限定されていますが、今後クラウドが全社的な基盤として利用されることも、視野に入ってきていると考えます。

　実際、その走りとして増えているのが、現在オンプレミスで動いているシステムのハードウェアの保守切れや交換のタイミングで、クラウドの利用を考えるお客様です。その移行のご支援を行うのが、この「データベース移行ソリューション for AWS」と、「データベース冗長化ソリューション for AWS」で、このソリューションの目的は、今お持ちのオンプレミス環境を、なるべくそのままクラウド化することです。

　なぜなら、こういったお客様では「クラウド上でそのまま現システムを動かしたい」というご要望が多いのですが、その際にデータベースの部分が非常に大きな課題になるからです。これに対しては、まずはデータベースを極力そのままの形でクラウドへ移行し、その後クラウドネイティブ対応をしていくという流れが考えられます。また、今動いているアプリケーションをそのままクラウドに持っていく場合も多少の改修コストはかかるので、いずれの場合でも、その最適化の部分で私たちがお手伝いすることが可能です。

―　クラウド移行を検討する際、いきなりクラウドネイティブに行くのではなく、リフト＆シフトと呼ばれる手法で第一段階の移行を行う。コアコンポーネントであるデータベースをいかにうまくAWSに持っていくかが支援のポイント、ということですね。元々使用していたデータベースエンジン（DBMS）もそのまま使うのが基本的な考え方になるのでしょうか。

髙橋氏：
　DBMSを変えると多少なりともアプリケーションにも影響を与えるので、第一段階の移行ではオンプレミスで動いているDBMSも含めて、そのままクラウドに移行するのが適していると思います。

オンプレミスからAWSにシステム移行する際、考慮したい２つのポイント

―　「データベース冗長化ソリューション for AWS」でデータベース基盤を考えた場合、オンプレミスとの相違点、AWSならではの技術的な考慮点などはありますか。

古川氏：
　大きく分けて2つあると思います。まず1つめは、AWSでは共有ディスクを使った、一般的なデータベースの冗長化手法がとれないという課題です。それを解決するために、サイオステクノロジーのLifeKeeper、DataKeeperを使用して、共有ディスクがなくともデータをリアルタイムで同期して、冗長化を図るというソリューションを企画しました。

　2つめは、オンプレミスでは1つのデータセンターに閉じた環境で冗長化構成を組むことが主流でしたが、AWSだと、複数のデータセンターにまたがって冗長化構成を組むことが可能になる点です。複数のデータセンターにまたがる構成で、一番注意しないといけないのがネットワークのレイテンシーです。この点に関して、サイオスさんのソリューションを使った場合にデータベースにどのような影響を与えるかという点が、今回の検証のポイントでした。

―　AWS上で冗長化を図ろうとした場合に最大のネックとなるのが、共有ストレージが使えないという点だと思いますが、それ以外にAWSならではの課題はありますか。

古川氏：
　たとえば、IPアドレスの設定という点でも、AWS独自の方法があります。ひとつのデータセンターのひとつのネットワークセグメントであればバーチャルIPを簡単に持てたのが、複数のアベイラビリティゾーンに分かれてしまうとバーチャルIPアドレスのようなものを普通は持てなくなるので、そこをどうするかといった点が、オンプレと比較するとAWSならではの課題ですね。
そこに関してはサイオスさんが事前にナレッジを蓄えられてホワイトペーパーなども作成されているので、今回参考にして検証をスムーズに進めることができました。

クラウド移行すれば、冗長化ソリューションが不要になるという誤解

―　今回、「データベース冗長化ソリューション for AWS」で弊社のLifeKeeper、DataKeeperをお使いいただきましたが、世の中ではまだまだ、クラウドに移行すれば冗長化ソリューションは必要ないだろうと考えている人は多いと思います。クラウドには元々HA機能が備わっているし、仮想化基盤であれば従来のHAクラスターソフトウェアは不要ではないかという考えです。
そういった中で、御社では当社のLifeKeeper、DataKeeperの価値をどのように捉えていただいているのでしょうか。

古川氏：
　まずはコスト面ですね。御社のライセンス体系が、お客様にとって魅力的な点です。あとは、いち早くAWSに対応する取り組みを開始された点は高く評価できると思いますし、オンプレミス環境での長年の冗長化の実績やナレッジをお持ちです。今回のソリューションでは、オンプレミスからAWSにマイグレーションするお客様をターゲットにしていますが、オンプレミスとAWSを両方理解したうえで製品を開発しているサイオスさんと協業させていただき、競争優位性が確保できたことは弊社にとっても非常に魅力的でした。

―　専用のHAクラスターソフトウェアでなくとも、AWSのAuto Recovery、VMwareのvSphere HAのように、障害時に他の物理サーバ上で立ち上げて自動復旧してくれる機能は存在しています。でも、ある程度の規模の企業であれば、それをさらに補完するような、本格的な高可用性に対する要件が存在するとお考えでしょうか。

古川氏：
　はい、そういった要件は確かに存在します。できるだけフェールオーバー時間を短くしたい、データを直近の状態まで戻したい、かつ障害監視もOSレイヤーではなく、ミドルウェアやアプリケーションレイヤーで実施したいといったニーズに対応するには、御社のHAクラスターソフトウェアが一番適していると思います。

「データベース移行ソリューション for AWS」と「データベース冗長化ソリューション for AWS」の検証結果

―　今回のソリューションの検証内容についてうかがいます。データベース基盤としてAWSを考えた時に、インスタンスやストレージの選定では、どのような点を考慮する必要がありましたか。または推奨できるポイントなどがあれば教えてください。

古川氏：
　検証するにあたり、どうすればお客様にリファレンスを提供できるかということに気を使いました。現在オンプレミスで使用しているシステムをAWSに持っていく際、判断基準になるような情報をインプットできないと、検証の意味合いが薄れてしまいます。今回は性能面での検証に力を入れましたが、その際のベンチマークの仕方も、お客様目線でどのようなベンチマークをするのが一番適切なのかという点を見極めるのに一番苦心しましたね。

　実際には、ベンチマークの手法も複数種類採用し、よりお客様に参考となる情報を提供できるよう準備しました。またAWSで利用するディスクはIOPS（I/O per Second）が優れているものなどいくつかのパターンがありますが、どのディスクを選定してどのようなベンチマーク手法で計測するのが一番参考になるかという観点で、複数のパターンから絞り込みました。検証パターンを絞り込むと最終的に10パターン程度あり、それを地道に実施していくのは苦労しました。ただ、やった分だけお客様に提供できる参考情報が過不足のないものになったので、有意義だったと思います。

― ベンチマークの方法を複数採用されたということですが、これは複数のベンチマークツールをお使いになったのでしょうか。

古川氏：
　そうですね。ひとつは自社で作成しましたが、弊社の内製ツールだとお客様が比較しづらい部分もありますので、自社ツールと汎用性の高いベンチマークツールの２種類を使用しました。汎用性の高いツールであれば、お客様がオンプレミスの自社環境に実装して計測し、今回私たちがAWSで計測した結果と比較して、実際にAWSに移行できるかどうかの判断がしやすいと考えました。

　またAWSで冗長化構成を組む際、ひとつのデータセンターに閉じた環境（シングルAZ）の中で冗長化構成を組む方法と、データセンターをまたがってマルチAZで組む方法と、大きく2つのやり方があります。やり方が違う中で、データベースの性能にどう影響を与えるのか、LifeKeeperやDataKeeperにどう影響を与えるのかという点の検証には、弊社の内製ツールを使用しました。

―　検証の結果、AWSは基幹データベースのプラットフォームとして、十分に実運用に耐えられるものだという結論に達しましたか。

古川氏：
　はい、そうですね。

オンプレミスと比較して、AWSのパフォーマンスは？

―　一般のオンプレの環境と比較した場合でも、パフォーマンスの観点から十分な値が出せましたか。

古川氏：
　はい、汎用性の高いベンチマークツールでは、オンプレミスとの比較で、AWSでもある程度性能が出ることは示せたと思います。また、シングルAZで冗長化構成を組む場合および、マルチAZで冗長化構成を組む場合に、LifeKeeper、DataKeeperにどう影響を与えるか、そしてデータベースの性能劣化という面でどのように影響を与えるかということについては、ある程度指針となる結果が得られました。お客様に参考情報としてお伝えし、有効活用していただきたいと思います。

―　実際にシングルAZとマルチAZを比較した場合、差は出ましたか？マルチAZと言っても東京と大阪ほど離れているわけではなく、せいぜい首都圏内だと思いますが。

古川氏：
　シングルAZとマルチAZを比較した場合、マルチAZのほうがレイテンシーは大きかったです。マルチのほうがシングルに比べてマイナス3パーセント前後、データベースの性能に影響があることがわかりました。また、シングルAZでクラスターを組む場合と、普通のシングル構成のデータベース、つまり、冗長化したものとしていないものを比較すると、マイナス6パーセント前後という結果が得られました。

―　レプリケーションの処理が入る分パフォーマンスが低下するといえども、それでも1ケタ台のマイナスでとどまったということですね。今回、性能面以外で検証された項目などはありますか。

古川氏：
　オンプレミスの環境と比較検討していただくために、汎用的なベンチマークツールでTPCスコアを算出したので、オンプレミスから移行する場合にはどうかといった判断基準をお客様に提供できるようになったことは大きいと思います。

―　運用面から考えると、オンプレと比べた場合のAWSのメリットは何かありますか。

古川氏：
　今回の冗長化ソリューションは、AWSのクラウドと御社のLifeKeeper、DataKeeperを組み合わせて、高可用性のシステムを構築するというものです。オンプレミスの場合はお客様が一からサーバ、ネットワーク、ストレージなどを組み立てる必要がありますが、AWSのクラウドでは仮想マシンを簡単にプロビジョニングできるので、お客様の構築や運用を効率化できます。

― 最後に、今後の展開について教えてください。

髙橋氏：
　今回はデータベースの冗長化ソリューションを発表しましたが、そのスコープだけではなく、お客様のクラウドへの移行や最適な利用を、全般的にサポートしていきたいと考えています。例えば、クラウド化のコンサルや、開発、運用といった部分です。データベースだけでなく、全般的なクラウド化の流れの中で必要な、もしくは最適だと思われるソリューションやサービスを企画・提供していきたいと思います。今回のソリューションは、その第一弾の位置づけです。

―　第一弾の屋台骨を支えているのが我々の製品であるのならば、大変光栄です。本日は貴重なお話をありがとうございました。