クラウドのためのアーキテクチャを考える6つのステップ

ITアーキテクチャは複雑である――この現実から目をそらすことはできません。クラウドへの移行を検討しているのであれば、アーキテクチャ、そして組織で必要となる多くの変更について懸念するのは当然のことです。

しかしながら、ほとんどの企業は既に同様のことを繰り返し経験しています。貴社でも、3~5年に1度のペースで、コアアーキテクチャのオーバーホール点検を実施していることでしょう。アプリケーションの配信について調整を行い、パフォーマンスの向上、セキュリティの強化、コストの削減を目指し、懸命に努力しているのではないでしょうか。

ただ、クラウドは、さらに複雑です。かならずしもサービスをコントロールできるとはかぎりません。接続のハードコーディングが行えず、昔からのやり方を変更せざるを得ない可能性もあります。

苦労も伴いますが、昔からいわれているように、「苦なくして得るものなし」です。

スタートを切るための6つのステップを、以下に紹介します。

ユーザの行動、接続、適切な帯域幅について計画を立てることが必要

1. 保有しているアプリの評価

貴社のアプリケーションの現状はどうでしょう? いくつのアプリを保有しており、それらのビジネスでの重要度はどの程度のものでしょう? アプリではどのようなデータが保持されていますか? そして、もっとも重要なこととして、データ間の依存関係はどのようになっていますか?

まずは、アプリのカテゴリについて考えてみましょう。選択肢は以下の3つです。

  1. SaaSの採用
  2. クラウドへの移行
  3. 現状維持

2. SaaSへのアウトソーシングが可能なアプリを選別

まずは簡単なところから始めましょう。バーチャル・コモディティであるアプリを選別します。おそらく多数見つかるでしょう。専用のExchangeサーバ、時代遅れのHRシステム、自家製の販売自動化ツールなどのサポートは、本当に必要ですか? 社員の手を煩わせ、OpExを費やすだけの価値があることですか? もしそうでなければ、販売、HR、生産性などに関する適切なソリューションの利用契約を結ぶことで、多くの手間を省くことができます。サードパーティを検討しましょう。SaaSは、ただちに明らかな成果をもたらしてくれるでしょう。

3. その他のアプリの分析と見極め

次に、その他のアプリを評価し、クラウドに移行するものと、現状を維持するものとを見極めます。

次のポイントを自問してみてください。アプリXをクラウドに移したら、どの程度の混乱が生じることになるのか? データの保存場所はどこで、それらの依存関係はどうなっているのか? どのようなネットワークサービスが使用されているのか? 標準のプロシージャとプロトコルが使えない場合の次善の策が必要なアプリはどれか?

ほとんどのアプリに対し、これらの質問の答えを導き出せるはずです。実際に移行に踏み切るまでわからないという場合もあるかもしれません。混乱のリスクが高く、複雑化が見込まれ、依存関係についてよくわからない場合は、アプリを現状のまま留めておいたほうがいいということです。

データ間の依存関係をチェックする際は、文書化が必要です。たとえ少数のアプリのみをクラウドに移すことになった場合であっても、資料は役立ちます。

4. 標準化

次に、アプリ配信に関する自社のポリシーを精査し、標準化を検討します。アプリごとに手作業で設定を調整するのではなく、標準のロードバランシング・ポリシーをいくつか(10個程度)定めておくことをお勧めします。標準のストレージ層とネットワークサービスを定義したうえで、標準化のメリットについて開発者に説明し、コミットメントを得るようにします。開発者がすばやく簡単に導入を行えるよう、テンプレートを作成するようにしましょう。

5. アクセスの簡素化と保護

誰がどこからアプリにアクセスしようとしているのかを、個別に見極めます。ユーザの行動、接続、適切な帯域幅について計画を立てることが必要です。プライベートとパブリックのどちらであれ、クラウドへの移行を検討しているのであれば、あらゆる場所からのアクセスが必要なアプリであることが考えられます。これらをクラウドに移行することで、インフラストラクチャの負担が軽減されることになります。

さらには、自動化とセキュリティの問題もあります。これまで、ほとんどの企業が、アプリをコントロールするのではなく、ネットワーク利用によりそのアクセスの決断を下してきました。パブリッククラウドでは、新しいアクセス技術 - かつてなかった方法でアクセスを決定するゲートウェイ - が必要になることが考えられます。

6. アーキテクチャのプランニング

クラウドに移行するとなると、構成が静的ではないため、アーキテクチャはそれまでと異なるものになります。データベースに代表されるモノリシックなアプリケーションの場合、それまでIPアドレスなど普遍の要素と関連付けられていたメカニズムは、クラウドでは機能しません。絶えず変化する環境で一貫性を保つためのロードバランサやプロキシの追加が必要になる可能性があります。制御ポイントを追加することで、中断を伴うことなく、誰もが常にアプリにアクセスできるようになります。

「リフト&シフト」の移行は容易ではない

冒頭でも述べたように、ITアーキテクチャは複雑です。

クラウドへの移行は決して容易ではありません。しかし、コスト(OpExとCapEx)の削減と拡張性のメリットだけを見ても、挑戦する価値は十分にあります。クラウド移行に向けた準備を整えただけで、コストを大きく削減できたというケースも存在します。既存のアプリ評価と依存関係の分析を行い、文書化し、可能なかぎり標準化と簡素化に努めることで、何を移行し何を残すのかを決断するための態勢を整えることができます。