[検証！マイグレーション先としてのAWS]

2017年7月3日(月)石田 知也（アイレット cloudpack事業部ソリューションアーキテクト）

リスト

　オンプレミスでシステムを運用していれば、少なくとも5年に1度はシステム更新を求める知らせがベンダーから怒涛のように届くはずだ。この通知の山に、うんざりしないIT部門の担当者はいないだろう。

　この“リプレース地獄”から逃れるために、AWSをはじめとするパブリッククラウドへのマイグレーションを検討する企業が年々増えてきた。事実ここ1、2年では、AWSへの移行が格段に進んでいる。システムはオンプレミスのままで運用し、バックアップ環境だけをクラウドに切り替えるというハイブリッド環境を選ぶ企業が少なくなかったころと比べると隔世の感を禁じ得ない。

クラウドへの移行で“リプレース地獄”からの解放

　AWSに移行したことによって、IT 部門の担当者から「ビジネスへの意識が大きく変わった」という声を聞く機会も非常に多い。クラウドへの移行で得られる最大のメリットに挙がるのが、冒頭で触れた「リプレース地獄からの解放」である（図1）。

図1：クラウドへの移行でIT部門は“リプレース地獄”から解放される
拡大画像表示

　例えば、筆者らが担当した事例の1つに近畿大学のシステム移行がある。同校のIT部門担当者からは「保守切れに悩まされなくて良いということが、これほど楽なんて!」とのコメントを頂戴した。5年先を見越したハードウェア調達という負荷からの解放感は、実際に体験してみると想像のはるかに上を行くレベルなのだ。同校は今後、保守切れを迎えるハードウェアは順次、AWSクラウドに移行していく方針だという。

　しかし「ハードウェアのリプレースから解放されたとしても、クラウドでは動かないアプリケーションが、まだ多いのではないか」「業務アプリケーションを滞りなく稼働させるためには、アプリケーションに最適化したハードウェアが必要ではないか」という疑問の声も止まない。だが、AWSへの移行案件を多数手がけてきた筆者らとしては、「一般的な業務アプリケーションであれば、AWSで動かせないものはほとんどない」と断言できる。少なく見積もっても、世の中にある9割以上の業務アプリケーションはAWS上で動作するだろう。

　もちろんAWSでは動かせないアプリケーションは存在する。例えばAWSのスペックでは、どうしてもパフォーマンスが出なかったり、極端に短いレイテンシーが要求されたりするアプリケーションである。もっとも、このレベルになると、ハードウェアだけでなく、ネットワークやファシリティに相当特殊なスペックが要求される。クラウドかオンプレミスかといった選択に悩む問題とは別次元の課題かもしれない。

　さらに、「運用が楽になる」という評判を信じてクラウドに移行したものの「思ったほどの効果を感じられない」という声を聞くこともある。特にAWSでは、移行事例の数が多いこともあり、「思っていたのと違う」という違和感を訴えるユーザーは少なくない。この背景には、「AWSに移行する」ということの意味を十分に理解しないままに移行に踏み切った企業の認識不足があると言える。

「責任共有モデル」が示す利用企業の責任範囲

　クラウドと既存のオンプレミスの最大の違いとして挙げられるのが「責任共有モデル」である。クラウドへの移行を検討している企業のIT担当者であれば、この言葉は何度も聞いたことがあるだろう。要約すると次のようになる。

　ユーザー企業が利用するITリソースのうち、クラウドベンダー（本稿ではAWS）はハードウェアやネットワーク、仮想環境といったレイヤーを責任をもって担保する。ユーザー企業は、その上位レイヤー、つまりアプリケーションやデータなど、ビジネスにより近い部分に関して自社で責任をもつ必要がある。

　すなわち、ベンダーとユーザー企業のそれぞれが責任を担保する範囲が明確に分かれているのである（図2）。ここで注意が必要なのは、例えばユーザー企業がセキュリティ的に脆弱なOSやミドルウェアを選択してAWSのコンピュートサービス「Amazon EC2」上に実装していたり、セキュリティパッチを当てる作業を怠り外部から攻撃を受けたりしたとしても、それはAWSの責任ではなく、ユーザー企業自身の責任になる。

図2：「責任共有モデル」では、ベンダーとユーザー企業が責任を担保する範囲が明確に分かれる
拡大画像表示

　OSやミドルウェアの運用までを外部に委任したいなら、クラウドの専門知識を有するパートナー企業に任せるという手段もある。その場合の責任共有モデルは図3のように変わる。

図3：マネージドサービスを利用した際の「責任共有モデル」の境界
拡大画像表示

　いずれにせよ、責任共有モデルを理解するためには、「当社は、どこからどこまでのレイヤーに対し責任をもち、AWSあるいはパートナー企業には、どこまで担保してもらうのか」といったラインを明確にしておくのが基本である。クラウドが普及したことで責任共有モデルについての理解も、かなり拡がったように思える。だが実態は、この理解を疎かにしている企業が未だに少なくない。そもそも、責任共有モデルという言葉に置き換わってはいるが、「誰が、何を、どうやって守るのか」という基本原則の重要性は、クラウドでもオンプレミスでも変わらない。

　もし、読者の会社がシステムをオンプレミスで運用していて、ファシリティやハードウェアから業務アプリケーションに至るまでをすべて、自社の責任と監視の下に実施していれば、AWSクラウドに移行すれば、その責任範囲はぐっと狭くなるのは間違いない。しかし、オンプレミスにあるシステムのすべてをITベンダーに丸投げしている企業にとっては、責任範囲の変化は感じにくいかもしれない。IT担当者として感じているべき「責任」を理解できていなければ、責任共有モデルはあまり意味をなさないだろう。

クラウド移行でIT部門は“稼ぐIT ”に貢献する部署に

　AWSはIT部門をリプレース地獄から解放する。これが意味するのは、つまり「IT部門の仕事がリプレース中心だった」という時代が終わるということである。すなわち、IT 部門の仕事の中身が変わってしまうということだ。オンプレミス全盛時代は日本に限らず、世界中でシステムの保守・運用がIT担当者にとって最も重要な業務だった。それを大きく変えるのがAWSというクラウドである。

　AWSに移行した企業のIT担当者は、リプレースやシステム運用の負荷が減っていく。代わりに“稼ぐIT”への貢献を求められるようになる。米国を中心とするクラウド導入企業において、開発部門と運用部門が密に連携する“DevOps”的な内製化アプローチが普及しているのも、そうした背景がある。ここで誤解を恐れずに言えば、IT担当者は5年ごとのシステム更改に悩まされなくなる代わりに、クラウドの進化をデイリーでキャッチアップしていく必要がある。

　本来、企業のIT部門は「経営に資するIT」を目指すべき部署だ。リプレースに追い立てられてきたIT 部門が、ビジネスの課題をITで解決する、つまり「経営に資するIT」を実現できる部門へと生まれ変わるためには、ITの進化をキャッチアップしていく姿勢が不可欠である。とりわけ、AWSは数あるパブリッククラウドの中でもイノベーティブであり、日本を含む世界中に最新のクラウド事例を誕生させてきた実績がある。この進化の速いプラットフォームを常に追いかけ、自社のビジネスにいかに活かしていくかを考えることこそが、クラウド時代の新しいIT部門のあり方ではないだろうか。

　やや厳しい言い方をすれば、クラウドの変化についていく覚悟がないのなら、クラウドへの移行は控えたほうがいい。そう考えれば、クラウドにおける責任共有モデルの採用は、自らに課した責任を果たしぬく覚悟の表明と言えるかもしれない。

　AWSクラウドに移行する究極の意義は、ハードウェアのリプレースではなく、IT部門のそのものを再構築することにある。AWSへの移行を検討しているなら、このことを是非とも頭の中に入れて臨んでほしい。この覚悟だけは、AWSやシステムインテグレーターが、どれだけ頑張っても用意することはできないのだから。

　次回は、移行前のアセスメントについて解説する。