テストはうまくいったのに……クラウド移行・運用の落とし穴

IT導入において、クラウドはいまや "当たり前の選択肢" のひとつとなっている。もちろん、クラウドにもメリット・デメリットはある。ITのアジリティは向上したものの日々の運用に想定以上の手間がかかる、そんな反省を耳にすることも少なくない。そうした背景があってか、「クラウド移行の正しい期待値」と題してマイナビニュースが2020年3月3日にオンライン配信したウェビナーは、100名以上の方が聴講した。本稿では同ウェビナーより、クラウドへの実移行・実運用に潜む落とし穴をテーマに講演した、ヴィーム・ソフトウェア(以下、Veeam)のセッションの模様をお届けする。

クラウドはネイティブな機能が充実! しかしそこに落とし穴が

Veeamは、ヨーロッパではNo.1のシェアを誇るバックアップソフトウェアベンダーだ。顧客ロイヤリティを示すネットプロモータースコアでは業界平均を3.5倍上回る73に到達しており、ガートナー社の代表的なリサーチ「マジック・クアドラント」でもリーダーポジションに選ばれるなど、同社製品は市場から高い評価を得ている。

Veeamと聞くとバックアップをイメージする方が多いと思うが、同社は近年、自らを「クラウド・データマネジメント・カンパニー」と標榜。クラウド時代のアベイラビリティ(システムの耐久性)を支える存在として、ビジネス領域を拡大している。

そんなVeeamのセッションには、同社 システムズエンジニア本部 システムズエンジニアの卯花 渉 氏が登場。「クラウド移行の悩み、運営の悩み、解決します!」と題して講演を行った。

卯花 氏はセミナーのはじめ、主要クラウドサービスはその多くが、システム移行や運用をラクにする様々なネイティブ機能を提供していると言及。しかし、そこには "実移行、実運用を行ってはじめて気づく落とし穴" が存在しているとし、このように述べる。

「AWSでいえば、オンプレにある仮想化環境をEC2へ移行するツールとしてAWS Server Migration Service(以下、SMS)を提供しています。運用にしても、ブロックストレージであるAmazon Elastic Block Store (以下、EBS)は、スナップショットをとるAmazon EBS snapshotを備えています。こうしたネイティブ機能は大変便利ですが、一方で、事前テストで見落としがちな落とし穴もあります。詳しくは後述しますが、ここでの問題は "事前テストで見落としがち" なことです。『クラウド移行って思ったより簡単』そう判断して少ないリソースのまま移行や運用を進めた結果、残業時間やクレーム件数が膨れ上がってしまった。そんなケースもあるかもしれません。」(卯花 氏)

実移行の落とし穴:オンプレ環境の性能を長時間引き落としてしまう

同氏が述べた落とし穴について、具体例を1つ紹介しよう。

上のスライドは、SMSを利用したシステム移行のプロセスだ。IAMロールとは、通常AWS上のリソースへアクセスできないユーザーやアプリケーション、サービスにアクセス権を委任する仕組みであり、まずはSMS用のIAMを作成し、SMSがAWSにあるリソースへアクセスできるようにする。次にSMSの備えるServer Migration Connectorを利用し、移行対象となるオンプレの仮想化環境とSMSとを紐づける。その後、SMSを利用してレプリケーションジョブを作成。同ジョブを実行すると移行対象であるオンプレの環境が、EC2上にAmazonマシンイメージ（以下、AMI）として作られる。あとはこれをもとにインスタンスをデプロイすれば、システム移行は完了だ。

卯花 氏はここまでのフローについてデモを交えて説明し、「工程は非常にシンプルです。事前にテストを行っても、きっとつまずくことはないでしょう。」と語る。しかし、実移行にあたっては問題が発生しがちだとし、こう続ける。

「レプリケーションジョブとデプロイ実行時に移行元であるオンプレ環境の性能が著しく低下してしまうことが、第一の問題としてあります。SMSによるレプリケーション中はVMwareのスナップショットが保持された状態となるため、どうしても性能に悪影響を引き起こしてしまうのです。移行にかかる時間が短ければ、性能ダウンは大きな問題にならないでしょう。しかし、残念ながらこれらの作業には多くの時間を要します。具体的にわれわれの検証では、わずか10GBほどの環境であっても、レプリケーションに2時間、インスタンスのデプロイに5分を要しました。」(卯花 氏)

• 事前準備で大きな問題が発生しなくとも、実移行と同等規模でのテストを行わないことで予期せぬ問題を発生させてしまうという。

• レプリケーションジョブの作成・実行および、AMIからインスタンスをデプロイする際に発生する問題。

システム移行において、メンテナンスなどの "ユーザーがシステムを利用できない時間" が生まれるのは致し方ないことだ。ただ、それが半日、1日と長期化する場合、話は変わってくる。ミッションクリティカルであるほど、リードタイムがビジネスに引き起こす悪影響が大きくなるからだ。

運用の落とし穴:データが消失した場合の責任はユーザーにある

落とし穴はほかにもある。

AWSの話が続くが、前出したEBS snapshotsではEBSの特定時点のスナップショットをAmazon S3へ保存することができる。二次バックアップや長期バックアップなどで非常に役立つ機能だが、論理障害以外の問題に対しては復旧アプローチがなく、万が一リージョンごと落ちてしまった場合にはバックアップ自体の意味を成さなくなる。

「クラウドには責任共有モデルという特有のルールが敷かれています。ハイパーバイザーより上位レイヤーについてはユーザー側の責任範囲になり、データ保護の観点ではこの点に注意が必要です。事業者の提供する機能、サービスを使っていて何らかの障害が発生する、これによりデータがロストする、……そうした場合の責任は、事業者ではなくユーザーが持つこととなるのです。事業者が提供しているからと安心するのではなく、そこに何か問題が生じた場合にも対処できるようにしておかなければ、万が一の場合に大きな損失を被ってしまいます。」(卯花 氏)

• 責任共有モデルを念頭に置いた仕組みづくりが、クラウド活用にあたっては重要となる。

アベイラビリティを確保するVeeamのソリューション

ここまで触れてきた落とし穴は、ユーザーが不自由なくシステムを使い続ける上でのアベイラビリティを脅かす存在だ。ここに対してVeeamは、どのようなソリューションを提供するのか。

「移行の例で言えば、当社はVeeam Backup & Replicationという製品を提供しています。これは基本的にはデータ保護を行うソリューションですが、AWSやAzure、オンプレなどマルチクラウド/ハイブリッドクラウドへのリストアにも対応したソリューションです。同システムをオンプレに用意するだけで、これを介してオンプレや各種クラウドにあるシステムを柔軟かつ容易にリストアすることが可能です。ローカルでバックアップを行うためレプリケーションジョブの実行時間は短縮され、スナップショットの負荷はストレージへオフロードする機能もありますので性能減も回避できます。」(卯花 氏)

• Veeam Backup & Replicationは、AWSとAzureといった主要クラウドのどちらにも対応している。

Veeamのソリューションは運用にあたっても効果を発揮する。Veeam Backup for AWSを使ってEBSをバックアップする、そして同環境を別リージョンやオンプレと同期する、これにより、データセンター単位で物理障害が発生した場合にも環境を復元することが可能となる。また、Veeam Backup for AWSはファイル単位、構成ファイルベースの復元が可能なため、これまで以上にきめ細やかな運用ができる。

• 2020年4月現在はAWSのみの提供だが、近日中にAzureでも、Veeam Backupとして同ソリューションが提供される予定だ。

ハイブリッドクラウド/マルチクラウド時代においてもアベイラビリティを確保し続けるために

こうしたVeeamのソリューションは、ハイブリッドクラウド/マルチクラウドに対応しているという点が大きなポイントだ。

クラウド化は確かに加速している。しかし、冒頭に触れたように、クラウドへ移行したものの結果としてそれは最適な選択ではなかったという場合がある。最近ではクラウドからオンプレへ環境を移す、または他のクラウドへ移すケースが増えており、それぞれのプラットフォームの利点を理解し、アプリケーションの要件を踏まえて適材適所でインフラを選ぶという考え方が浸透し始めてきている。

「インフラを流動的に変えながらもシステムのアベイラビリティは堅持し続けられる。そんなプラットフォームを持つことが、これから先、企業には求められるでしょう。こうした場合に、Veeamのソリューションは必ずお役立てできます。クラウドの利用を考えるのならば、ぜひ当社にお声がけ頂きたいですね。」卯花 氏はこう語り、講演を締めくくった。

[PR]提供：ヴィーム・ソフトウェア