パブリック クラウドへのエンタープライズ アプリケーションの移行を検討している組織は、データ センタ内でそれらのアプリケーションが依存しているアプリケーション デリバリ サービスも移行する必要があります。またクラウドへの移行は、セキュリティとアクセスを体系化して合理化し、クラウドベースのアプリケーション トラフィックを可視化して堅牢なディザスタ リカバリ プランを設計する機会でもあります。
多くの組織にとって、パブリック クラウドへのエンタープライズ アプリケーションの移行は非常に魅力的な案件です。移行することで大規模なITインフラストラクチャの運用に必要な固定費や資産(世代も保守性のレベルも異なる機器を多数抱えた高コストのデータ センタなど)を処分できます。これらのサーバーは企業を動かしている一方で、電力を消費し、熱を発し、高コストのサポート契約を必要とします。ITインフラストラクチャのライフサイクルや保守、物理的な筐体を管理するには技能や時間、予算が必要であるため、事業を進めるアプリケーションの提供というIT部門全体の使命を損ないかねません。
このような運営上の問題や経済的負担を解消して、代わりに旧式のサーバーやアプリケーションを廃棄してシンプルなAPI呼び出しを使用できる新たな世界を手に入れることは、経済面でも運営面でも理に適っています。ITを運用している基本的なインフラストラクチャを管理する必要がなくなれば、アプリケーションのセキュリティ、パフォーマンス、可用性にもっと注力できるようになります。これがITが企業にもたらす真の価値です。
しかし仮想化されたメンテナンス不要の夢のようなインフラストラクチャを手に入れるには、アプリケーションを新居に移す最善の方法を考え出さなければなりません。アプリケーションをパブリック クラウドに移行するには、いくつかの選択肢があります。アプリケーションをクラウド環境用に完全に作り直せばユーザー エクスペリエンスが洗練され効率化されますが、多くの場合、そのプロセスには多くの時間と労力が必要です。一方、大規模な設計やプラットフォームの変更を行わずに、データ センタで実行しているアプリケーションを選び、パブリック クラウドに配置するだけの方法もあります。
この「リフト アンド シフト」モデルを検討する正当な理由はいくつもあり、まずコストがほぼ10分の1になると見積もられています。1ほとんどの場合に短期間で済み、耐用年数のあるアプリケーションを書き直すのは単純に割に合わない場合もあります。ただし「リフト アンド シフト」モデルの移行を成功させるには、いくつかのルールに従うと同時に1つのルールを無視する必要があります。
まず無視すべきルールからお話しします。「サーバーを家畜のように扱う」という概念はクラウド アーキテクチャの本質を突いているように見えます。サーバー インスタンスが正しく機能していない場合、これを修正するのは時間の無駄である。そのサーバーを停止して再デプロイする。オペレーティング システムやソフトウェアはアップグレードせず、新しいインスタンスをデプロイして古いインスタンスを停止する。これが堅実なアドバイスです。しかしデータ センタで生まれ大切に扱われてきたアプリケーションをパブリック クラウドの冷たく過酷な環境に移行しようとすると、期待外れに終わりかねません。
ほとんどのエンタープライズ アプリケーションはクラウド アーキテクチャとその方法論を念頭に置いて設計されていません。エンタープライズ アプリケーションはローカルにその状態を維持し、基盤となるサーバーが起動してからやっとオンラインになり、突然シャットダウンすればおそらくデータの一貫性が損なわれます。これらのアプリケーションは家畜ではなくかわいいペットのように扱わなければなりません。
クラウド環境に移行したエンタープライズ アプリケーションには、データ センタで受けていたのと同じケア、管理、アプリケーション デリバリ サービス(セキュリティ、可用性、パフォーマンス)が必要です。これらのアプリケーションが必要とする基本的なロード バランシング サービスは、クラウド用に設計されクラウドで生まれたアプリケーションが必要とするものよりも複雑です。これらのアプリケーションをクラウドでもうまく運用するには、その基盤インフラストラクチャも一緒に移行しなければなりません。幸い、大部分のインフラストラクチャ コンポーネントをパブリック クラウドで使用できるようになっています。組織的知識、スキル、さらにはポリシーもクラウドで再利用できます。
ほとんどの企業のITの進化は、配線盤の配線ラックのような経路を辿ります。皆さんもご存じの通りです。最初は美しく整然と配置されて完璧に仕上げられています(素晴らしい構成のいくつかをreddit.com/r/cablepornでご覧ください)。しかし1年も経たないうちに、時間がなく緊急であるためにここでは近道をし、ここでは間違った色のケーブルが使われます(「赤はDMZ用なのに!」)。3年もするとキャビネットはラベルもなく色とりどりのイーサネット ケーブルが絡まったゴルディアスの結び目となり果てます。こうなったらこの結び目を断ち切って再構成しなければなりません。
クラウドへの移行は乱雑な配線盤を一掃し、セキュリティとアクセスを再び管理できる状態に戻す絶好のチャンスです。アプリケーションとともにインフラストラクチャ サービスの一部を移行しなければならない場合、このチャンスを活かしてアプリケーションとネットワークへのアクセスの方法を合理化し、可視化し、構造化してください。
クラウド環境でできる最も重要な管理はおそらく、ユーザーIDの管理です。アプリケーションをクラウドに移行したり、Software as a Service(SaaS)製品を選択してアプリケーションを廃棄したり、アプリケーションを完全に書き換えたりする場合、ユーザーID管理についていくつかの重要な決断を下さなければなりません。
複数のIDサービスを実行することは煩わしく危険で、非効率的であり、排除すべき複雑さを増大させかねません。ID管理は一元化する必要がありますが、必要なすべての場所でアクセス権を連携させなければなりません。IDサービス(通常はMicrosoft Active Directory)と統合し、これをSAML、OAuthといったプロトコルを使用してクラウドとSaaSサービスまで拡張するテクノロジにより、アプリケーションはローカルIDに依存せずに1つのソースでユーザーを認証することができます。
しかしアプリケーションの分散度が増すと、ユーザーの分散度も増します。ユーザーの場所とデバイスを識別するコントロールを追加し、これに二段階認証とワンタイム パスワードのオプションを組み合わせることで、組織の情報セキュリティを脅かすソーシャル エンジニアリングなどの攻撃を防御することができます。
クラウド環境ではインフラストラクチャの多層構造は抽象化され、ユーザーが直接関与することはありません。物理的なインフラストラクチャを運用してサポートする必要がないため、これは良いことです。しかしこのような責任がなくなることは、直接的な管理を手放すことも意味します。
これに対抗するためにすべきことの一つが、アプリケーション パフォーマンスを注意深く監視することです。関連性が高く実用的な情報を提供する優れた監視機能を組み込むことでトラブルシューティングやキャパシティ プランニングが容易になります。
もう一つのメリットは、社内の不安を払拭できることです。クラウドのセキュリティやパフォーマンスについての疑いは、パブリック クラウドのマルチテナントや公開されているサービスへの接続といった面だけでなく、制御性に欠けるという認識からも生まれます。エンタープライズ アプリケーションとその動作をより適切に監視する機能を組み込むことで、クラウドへの移行を促進し、クラウド導入への感情的な障壁を取り除くことができます。
優れたデータ センタ インフラストラクチャとアプリケーション設計の中心はディザスタ リカバリと事業継続性(DR/BC)です。パブリック クラウドを採用しても、アプリケーションを実行して保護する責任から免れるわけではありません。ただしDR/BCサービスを導入する障壁は低くなります。
パブリック クラウド サービスが登場する以前、物理的なディザスタ リカバリの拠点を構築するには多大なコストとリード タイムが必要でした。現在ではさまざまな基盤テクノロジを使用して別の大陸にある別のベンダーのインフラストラクチャにたった数分でアクセスできます。しかしインフラストラクチャが格段に利用しやすくなっても、可用性の高いアプリケーションを構築するにはいまだにかなりの計画と構成が必要です。
ディザスタ リカバリとクラウド インフラストラクチャについては膨大な文書がありますが、DR/BCの計画と設計のための優れた枠組みはいくつかの主な決断と懸念にまとめることができます。
1番目に、リスクと投資収益率(ROI)について考える必要があります。究極のマルチリージョン、マルチベンダー ソリューションに時間と費用を投じる価値はありますか。クラウド サービスの導入コストは抑えられますが、堅牢なDR/BCサービスを維持するための運用コストは依然としてかかります。
2番目に、トランザクション データをどのように保存し、分散させ、その一貫性を保つかについて考える必要があります。これはよく知られた問題ですが、地理的に分散された可用性の高いアプリケーションを構築する上で最も困難な部分かもしれません。多くのソリューションでは、各拠点の間に高帯域幅、低遅延の接続を必要としたり、エンタープライズ アプリケーションでは採用されることの少ない結果整合性モデルなどの難解な設計を必要とします。さまざまなクラウド プロバイダの間に低遅延の接続をで構築することはほとんどの企業の能力では不可能ですが、いくつかのオプションが提供され始めています。
3番目の重要な課題は、アプリケーションへのアクセスを管理することです。アクティブ/アクティブ構成またはアクティブ/DR構成のほとんどはDNSを使用し、可用性、近接性、またはパフォーマンスに基づいてトラフィックを最適なデータ センタに転送することでシンプルさと機能性を両立させています。これは特に、アプリケーションにさまざまなクラウド ベンダーを使用するマルチクラウド モデルを検討する場合に当てはまります。BGPなどのネットワーク プロトコルを使用することも選択肢の一つかもしれませんが、通常は複雑さとリスクが増します。もう一つのオプションは、クラウドの外側か近い場所に配置した機器やサービスを使用して複数のクラウドにわたってネットワーク トラフィックの負荷分散を行うか、切り替えるというシンプルな方法です。そこで最後のルールです。
エンタープライズ アプリケーションのクラウドへの移行を検討している中規模から大規模の組織の多くは、クラウド インフラストラクチャに対する安全なプライベート アクセスを構築しようとしています。公衆インターネットを介したVPNソリューションの運用が適している組織も一部ありますが、多くの組織が使用するのは、もっと直接的な、クラウド プロバイダとの専用接続です。サービス プロバイダが提供するこれらの専用リンクはプライバシーと安定した帯域幅が保証されるだけでなく、公衆インターネット接続と比べて低遅延ですが、コストがかかります。
そして複数のクラウドとの回復力のある接続が必要な場合は、複数のリンクをプロビジョニングする必要があります。また、クラウドをいくつかのインフラストラクチャ コンポーネントに接続しなければならないが、既存のデータ センタがクラウド ネットワークの相互接続点から地理的または論理的に離れている場合はどうでしょうか。
複数のクラウド プロバイダとの高速接続を提供するクラウドで接続された環境(一般にクラウド エクスチェンジと呼ばれている)への機器のコロケーションを検討する組織が増えています。これによってクラウドの仮想インフラストラクチャに非常に近い場所でIT資産をホスティングすることができ、その結果、クラウドで実行されるアプリケーションとインフラストラクチャ コンポーネント(コロケーション センタに配置されているストレージ アプライアンスやセキュリティ アプライアンスなど)との間でプライベートな低遅延の接続が可能になります。また、これによって既存のIT機器を活用してネットワークやセキュリティのコントロールをクラウド インフラストラクチャまで拡張できます。
最後に、クラウド エクスチェンジへのコロケーションでは、企業のデータ センタの中核、クラウド インフラストラクチャ、および公衆インターネットにコントロールを配置できます。ビジネスに必要なセキュリティ ポリシーを拡張または作成し、アプリケーション データ フローの制御性と可視性を高めることで、セキュリティ体制全体を改善してアクセスとセキュリティ サービスを合理化し、標準化することができます。
エンタープライズ アプリケーションをリフト アンド シフト モデルでパブリック クラウドに移行することにより、組織はコストを削減して柔軟性を向上させ、クラウド環境に迅速に移行することができます。ただし移行を成功させるためには、エンタープライズ アプリケーションに周辺のインフラストラクチャが引き続き不可欠であることを理解しなければなりません。
セキュリティ、パフォーマンス、可用性を確保するためにアプリケーションが依存しているサービスをクラウドに配置することで、従来のエンタープライズ アプリケーションを引き続き実行することができ、ユーザーにもメリットをもたらします。監視機能を組み込むことで、問題のある領域に即座に注目することができ、アプリケーション所有者がサービスをクラウドに移行する際に感じる不安を和らげることができます。
またリフト アンド シフトの手法は堅牢な制御を再構築してアクセスを合理化し、事業継続性を改善するきっかけともなり、移行全体のROIも向上します。最後に、複数のパブリック クラウドを利用する場合は、クラウド エクスチェンジでのコロケーションのメリットも検討してください。これによりパフォーマンスが向上し、単一制御点からセキュリティおよびアクセス ポリシーを標準化できます。
1 Knapp、Kristin、『目的達成のための手段』、モダン インフラストラクチャ、2015年7月/8月、http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf.