はじめに

初めてクラウド移行を検討する際、移行計画として何をどう進めていくのか悩むことがあるかと思います。 本連載では、移行を検討中、これから検討するという皆様に向けて、システムのクラウド化のうち、特に移行で注意が必要であるデータ移行（データベース部分）について、シリーズを通して解説を行います。

システムをクラウドに移行することには多くのメリットがあります。しかし、その反面注意すべき事項も多くあり、これらを理解することで移行におけるリスクを抑えることができます。そこで、データベース移行について考えるシリーズの第2回である今回は、AWS環境を例に過去実績などから移行する際のハマりがちなポイントについてピックアップしたのでご紹介を致します。

既に検討済みであればよし。もし検討できていないものがあれば、ぜひこれらの内容について考えてみてください。

当社取り組みの関連記事はこちら。

• ・AWS連載
• ・シリーズ第1回 移行先によるコストの比較

移行時のハマがちなポイント

過去の経験上、比較的ハマりやすいポイントとして、以下の6点についてご紹介します。

未サポートのサードパーティ製品の存在

Amazon RDSやAmazon Auroraの場合、pg_dbms_stats、pg_statsinfo等の一部の追加モジュールを使用できません。

もちろん、AWS社にリクエストすることで追加される可能性もありますが、現時点で利用できないサードパーティ製品は存在します。もし、移行先に必要としている拡張モジュールが存在しない場合は代替手段の検討が必要になる点、ご注意ください。

マネージドサービスを利用することはいろいろな管理をクラウドベンダに任せられる反面、ユーザの自由度が下がります。オンプレミス環境のときは簡単に実現できたこともクラウド環境ではできないことが存在します。

もしシステムで必須の拡張機能があった場合、移行先のマネージドサービスで利用できるかどうかを事前に確認しておくことが移行時のトラブルを防ぐことにつながり重要です。

トラブル時の解析ツールのノウハウ不足

解析の内容自体に変わりはないが、マネージドサービスを使用する場合、一部実施可能な手段が変わるため、解析のためのノウハウ拡充が必要となります。

クラウド環境では全ての情報がユーザに開示されているわけではないため、基盤側のトラブルでFO発生した場合、原因を必ず確認できるわけではない点も理解しておく必要があります。ベンダに確認することである程度情報はもらえる可能性はありますが、全ての情報は開示されるわけではありません。（運用上必須ではないですが、）

利用するサービスによってユーザの責任範囲が変わるのもクラウドの特徴なのでその点を理解し、どういったトラブルへの対処をしなければいけないかを把握し対策を用意しておく必要があります。

移行作業が想定よりも長引いてしまった

移行の本番の段階で、移行元からのデータの転送速度が想定よりも遅く、移行に時間が掛かってしまい、後続の作業の着手が遅れてしまうことが挙げられます。

こういった問題を未然に防ぐには本番の環境を擬似した環境を作成し、移行検証として事前に調査しておくことが望ましいです。 データ転送時のボトルネックを解析し、規定の時間に収まるようにチューニングを施すことで対処が可能です。 過去に対応した移行案件では、転送先のPostgreSQLでのWAL書き込みがネックとなり、移行時間が長時間化しているケースがありました。そのときは、移行実施日に一時的にスケールアップをすることでIO性能引き上げ、処理時間の短縮を行いました。

ただし、過剰な移行検証の実施はその作業自体の工数が移行コストに積まれるため、どこまでやるかの見極めも重要となります。

運用コストが想定よりも高くなってしまった

運用コストで注意が必要要素として、インスタンスの数やインスタンスタイプは意識しやすいですが、ディスクの使用量という部分にも注意が必要です。 特に分析用のデータを格納する際にAmazon RDS等でAmazon EBSで大量のデータを保持するとそのコストは無視できないほど大きなものとなります。

分析として複雑なSQLを実行したいときにAmazon RDSにTBオーダーのデータを全て格納してしまうとランニングコストは非常に高額なものとなります。 こういうケースでおすすめなのは、ホットなデータのみを中間データとしてAmazon RDS上に展開してストレージの使用量を抑える運用です。直近の分析で使用しないデータはS3等の比較的安価に使用できる場所に格納しておくような運用設計を行うことでコストを大幅に下げることができます。

分析する内容次第では、全てのデータはS3に格納しておき、分析用のサービス（Amazon Redshift、Amazon Athena、Amazon EMR等）で直接S3のデータにアクセスする方法も考えられます。 実現したいことに対して、アプローチは複数考えることができます。このように設計には適切なクラウドサービスの選定も重要となるということはご留意ください。

オンプレミスでの運用方針が流用できず、設計の見直しが必要

バックアップ/リカバリ方式についてはマネージドサービスを利用する場合、オンプレミスとは大きく異なるため、再整理が必須となります。マネージドサービスでのバックアップは自動バックアップ機能等、スナップショットを使用した方式になります。

次にサーバサイドユーティリティを前提とした運用手順が使えないことも注意が必要なポイントになります。サーバサイドユーティリティとは、具体的にはpg_ugradeやpg_rewind等のデータベースサーバ上で実行する機能になります。マネージドサービスでは、ホストマシンに直接アクセスすることはできないため、これらの機能の利用を前提とした運用がある場合は見直しが必要となります。

最後にパラメータ設定がそのまま使用することができないについても意識しておく必要があります。Amazon RDSやAmazon Auroraなどでは、そもそもパラメータの設定がユーザに開放されていないものがあるため、オンプレミス環境で使用していたパラメータとの差分が発生します。特にAurora PostgreSQLはそもそもアーキテクチャが異なっている部分もあるため、パラメータチューニングしている部分も再検討が必要となることにも見落としがちなポイントになります。

オンプレミスと同等のサービスレベルを達成できない

Amazon RDS、Amazon Auroraを使用する場合、バックアップからの復旧ではデータを最新状態への復旧することはできず、最も新しくて5分前の状態への復旧となります。（参考：特定の時点への DB instanceの復元） これはマニュアルにも記載のあるとおり、Amazon RDSがトランザクションログを5分ごとに Amazon S3 にアップロードする動作であることに起因します。 そのため、もしシステムのリカバリ要件として、バックアップからの復旧で障害発生の直前に戻すことが必要な場合はAmazon RDS、Amazon Auroraでは満たせないことを理解しておく必要があります。

ただし、Amazon RDSやAmazon Auroraを使用していれば、データの冗長化等によりデータの全損が発生する可能性は低く、バックアップからのリストアが必要になるのはユーザによるデータの論理破壊等の限られた場面でしか発生しないと考えられます。何を意図した要件であるか確認することで、調整の余地はあるため、できるできないだけでなく、サービスレベルをどういった形で達成するのかも含めて検討することが重要となります。 　

まとめ

クラウドを利用することで多くのメリットを得られますが、注意すべきポイントは少なからず存在します。 今回上げたハマりがちなポイントは、データベースに特化したものだけではありませんがデータベースを含め、システムのクラウド移行を検討する際はこれらの要素について意識して進めていただけると失敗の無い移行が実現できると思います。

移行をこれから検討する方、既に検討されている方で今回気になったものがあれば、ぜひ弊社にお声掛けください。 適切なサービスの選定できる知識と多くの移行ノウハウを持つNTTテクノクロスがAWSへの移行をサポート致します。