エンタープライズ アプリをクラウドへ移行: 従うべき 5 つのルール (そして破るべき 1 つのルール)

エンタープライズapplicationsをパブリック クラウドに移行することを検討している組織は、applicationsが依存するデータ センター内のapplication配信サービスも移行する必要があります。 さらに、クラウドへの移行により、セキュリティとアクセスを整理して合理化し、クラウドベースのapplicationトラフィックを可視化し、強力な災害復旧計画を設計する機会が生まれます。

導入

多くの組織にとって、エンタープライズapplicationsをパブリック クラウドに移行することは非常に魅力的な提案です。 これにより、さまざまな世代やサポート レベルの機器が詰め込まれた高価なデータ センターなど、大規模な IT インフラストラクチャの運用にかかる固定費と資産を削減できます。 これらのサーバーは企業を稼働させていますが、同時に電力を消費し、熱を発生し、高価なサポート契約を要求します。 IT インフラストラクチャのライフサイクル、メンテナンス、および物理的なハウジングの管理には、スキル、時間、および予算が必要であり、ビジネスを運営するapplicationsの提供という IT 組織の全体的な使命を損なう可能性があります。

この運用上の悩みや経済的負担をなくし、古いサーバーやapplicationを単純な API 呼び出しで廃止できる新しい世界を手に入れることは、多くの場合、経済的にも運用的にも理にかなっています。 IT を実行する基本的なインフラストラクチャを管理する必要がなくなれば、IT が企業にもたらす真の価値を表すapplicationsのセキュリティ、パフォーマンス、可用性にさらに重点を置くことができます。

しかし、仮想化されたメンテナンス不要のインフラストラクチャの理想に到達する前に、applicationsを新しい場所に移動するための最善の方法を考え出す必要があります。 applicationをパブリック クラウドに移行するには、いくつかの選択が必要です。 applicationをクラウド環境向けに完全に再設計することで、洗練された合理化されたユーザー エクスペリエンスを実現できますが、多くの場合、時間と労力がかかるプロセスになります。 あるいは、データセンターで実行されているapplicationsを選択して、設計やプラットフォームの大幅な変更を加えずにパブリック クラウドにドロップすることもできます。

この「リフト アンド シフト」モデルを検討する理由は数多くあります。 約10分の1ほど安くなると推定されています。1ほとんどの場合、はるかに高速であり、場合によっては、寿命が限られているapplicationを書き直す価値がないこともあります。 しかし、「リフト アンド シフト」移行を成功させるには、従うべきルールがいくつかあり、また、破る必要のあるルールも 1 つあります。

ルール 1: サーバーをペットではなく牛のように扱う

まずは壊すものから始めましょう。 サーバーを牛のように扱うという概念は、クラウド アーキテクチャに固有のものであるとよく考えられています。 サーバー インスタンスが正しく機能していない場合は、修正に時間を無駄にせず、インスタンスを強制終了して再デプロイしてください。 オペレーティング システムやソフトウェアをアップグレードせず、新しいインスタンスを展開し、古いインスタンスを終了するだけです。 これは確かなアドバイスです。 しかし、データ センターの贅沢な環境で生まれ育ったapplicationを、冷たく厳しいパブリック クラウドの世界に移行しようとすると、逆効果になる可能性があります。

ほとんどのエンタープライズapplicationsは、クラウド アーキテクチャと方法論を考慮して設計されていません。 これらは状態をローカルに保持し、基盤となるサーバーの起動後にオンラインになるまでに時間がかかり、突然のシャットダウンによりデータの不整合が発生する可能性があります。 彼らを牛のようにではなく、甘やかされたペットとして扱う必要があります。

クラウド環境に移植されたエンタープライズapplicationsには、データ センターで受けるのとほぼ同じケア、管理、application配信サービス (セキュリティ、可用性、パフォーマンス) が必要です。 これらのapplicationsに必要な基本的な負荷分散サービスでさえ、クラウドで設計され作成されたapplicationに必要なサービスよりも複雑になります。 applicationをクラウドで稼働させたい場合は、それをサポートするインフラストラクチャも一緒に移行する必要があります。 幸いなことに、ほとんどのインフラストラクチャ コンポーネントは現在、任意のパブリック クラウドで利用できるようになり、組織の知識、スキル、さらにはポリシーをクラウドで再利用できます。

ルール 2: 混乱ではなくapplicationを移動

ほとんどのエンタープライズ IT の進化は、パッチ パネル配線ラックに似た経路をたどります。 ご存知ですよね。 始まりは美しく、デザインも良く、完璧に実行されています。 (本当に感動的な構成については、 reddit.com/r/ cableporn をご覧ください。) しかし、1年も経たないうちに、時間と緊急性の必要性から、ここでは近道が取られ、あそこでは間違った色が使われてしまった(「赤はDMZだ、ちくしょう!」)。 わずか 3 年で、キャビネットはラベルのない多色の Ethernet ケーブルのゴルディアスの結び目と化し、引き抜いて再構成する必要がある状態になりました。

クラウドに移行すると、混乱したパッチ パネルを取り除き、セキュリティとアクセス管理の制御を取り戻すチャンスが得られます。 applicationとともにインフラストラクチャ サービスの一部を移行する必要がありますが、この機会を利用して、applicationとネットワーク アクセスの戦略を合理化し、視覚化し、整理する必要があります。

戦略的なコントロールポイント
図1: クラウド展開に戦略的な制御ポイントを追加します。
ルール 3: 自分のアイデンティティを守りましょう

おそらく導入できる最も重要な制御は、クラウド環境でのユーザー ID の管理です。 一部のapplicationsをクラウドに移行したり、一部のapplicationsを廃止して Software as a Service (SaaS) サービスに移行したり、一部のapplicationsを完全に書き直したりするときには、ユーザー ID 管理に関するいくつかの重要な決定を行う必要があります。

複数の ID サービスを実行すると、面倒でリスクが高く、非効率的になる可能性があり、排除すべき複雑さが再び生じる可能性があります。 ID 管理は集中化する必要がありますが、アクセスは必要なすべての場所にフェデレーションする必要があります。 ID サービス (通常は Microsoft Active Directory) と統合し、SAML や OAuth などのプロトコルを使用してクラウドおよび SaaS サービスに拡張するテクノロジにより、applicationsはローカル ID に依存せずに単一のソースでユーザーを認証できるようになります。

しかし、applicationsが分散するにつれて、ユーザーも分散するようになりました。 ユーザーの場所とデバイスを識別するコントロールを追加し、2 要素認証とワンタイム パスワードのオプションを組み合わせることで、ソーシャル エンジニアリングや組織の情報セキュリティを侵害しようとする同様の試みに対する防御を提供できます。

IDをクラウドに連携
図2: アイデンティティをクラウドに統合します。
ルール 4: 「クラウド不安」を解消するための監視

クラウド環境では、複数のインフラストラクチャ レイヤーが抽象化され、ユーザーの直接的な関心事から切り離されます。 これは良いことです。なぜなら、物理的なインフラストラクチャのサービスとサポートを行う必要がなくなるからです。 しかし、この責任のアウトソーシングには、直接的な管理権の譲渡も伴います。

これに対抗するために必要なことの 1 つは、applicationのパフォーマンスをより注意深く監視することです。 関連性のある実用的な情報を提供するより優れた監視機能を追加すると、トラブルシューティングと容量計画が容易になります。

もう一つの利点は、ビジネス内のいくつかの懸念が取り除かれることです。 クラウドのセキュリティとパフォーマンスに関する疑問は、パブリック クラウドのマルチテナントとパブリック接続の側面から部分的に生じていますが、制御の喪失が認識されることからも生じています。 エンタープライズapplicationsと動作の監視を強化することで、この移行の促進に大きく貢献し、クラウド導入に対する感情的な障壁を取り除くことができます。

ルール 5: DR/BC 戦略に重点を置く

災害復旧と事業継続性 (DR/BC) は、優れたデータ センター インフラストラクチャとapplication設計の柱です。 パブリック クラウドを使用しても、applicationsを稼働させ、安全に保つ責任がなくなるわけではありません。 ただし、DR/BC サービスの参入障壁は低くなります。

パブリック クラウド サービスが利用可能になる前は、物理的な災害復旧場所を構築するには多大なコストとリードタイムが必要でした。 今では、異なる基盤テクノロジーを使用する別のベンダーから、別の大陸にあるインフラストラクチャにわずか数分でアクセスできるようになりました。 しかし、インフラストラクチャははるかに容易に利用可能になるかもしれませんが、可用性の高いapplicationを作成するには、依然としてかなりの計画と構成が必要です。

災害復旧とクラウド インフラストラクチャに関するトピックに特化した広範なドキュメントがありますが、DR/BC の計画と設計のための適切なフレームワークは、いくつかの重要な決定と懸念事項に絞り込むことができます。

まず、リスクと投資収益率 (ROI) について考える必要があります。 究極のマルチリージョン、マルチベンダー ソリューションを採用することは、時間と費用に見合う価値があるでしょうか? クラウド サービスによって取得コストは削減できますが、堅牢な DR/BC サービスを維持するための運用コストは依然として発生します。

次に、トランザクション データをどのように保存および配布し、一貫性を保つかを検討する必要があります。 これはよく理解されている問題ですが、地理的に分散した高可用性applicationsを構築する上でおそらく最も難しい部分です。 多くのソリューションでは、場所間の高帯域幅、低遅延の接続、またはエンタープライズapplicationsではほとんど採用されない最終的な一貫性モデルなどのより難解な設計が必要です。 異なるクラウド プロバイダー間で低遅延の接続を構築することは、ほとんどの企業の能力の範囲外ですが、いくつかのオプションが利用可能になりつつあります。

3 番目の重要な課題は、applicationsへのアクセスを管理することです。 ほとんどのアクティブ/アクティブまたはアクティブ/DR 設計では、可用性、近接性、またはパフォーマンスに基づいて DNS を使用してトラフィックを最適なデータセンターに送信することが、シンプルさと機能性の最適なバランスを実現します。 これは、applicationsに異なるクラウド ベンダーを使用するマルチクラウド モデルを検討している場合に特に当てはまります。 BGP などのネットワーク プロトコルを使用することもできますが、通常は複雑さが増し、リスクも生じます。 もう 1 つの選択肢としては、クラウドの外側にあるがクラウドに近い場所に配置された機器やサービスを使用して、クラウド間でネットワーク トラフィックの負荷を単純に分散または切り替えるというものがあります。これが最終的なルールです。

ルール 6: クラウドに近づく

エンタープライズapplicationsをクラウドに移行する中規模から大規模の組織のほとんどは、クラウド インフラストラクチャに安全なプライベート アクセスを構築したいと考えています。 パブリック インターネット経由で VPN ソリューションを実行することが適切な場合もありますが、多くの組織では、クラウド プロバイダへのより直接的な専用接続を使用します。 サービス プロバイダーによって提供されるこれらの専用リンクは、プライバシー、保証された帯域幅、およびパブリック インターネット接続よりも低いレイテンシを提供しますが、それにはコストがかかります。

また、複数のクラウドへの耐障害性のある接続が必要な場合は、複数のリンクをプロビジョニングする必要があります。 あるいは、クラウドをいくつかのインフラストラクチャ コンポーネントに接続する必要があるが、既存のデータ センターがクラウド ネットワーク ピアリング ポイントから地理的または論理的に遠すぎる場合はどうでしょうか。

複数のクラウド プロバイダーへの高速接続を提供するクラウド接続環境 (一般にクラウド エクスチェンジと呼ばれる) に機器をコロケーションすることを検討する組織が増えています。 これにより、IT 資産の一部をクラウド仮想インフラストラクチャの非常に近くにホストできるようになり、クラウドで実行されているapplicationsと、コロケーション センターに設置されたストレージやセキュリティ アプライアンスなどのインフラストラクチャ コンポーネントとの間で、プライベートで低遅延の接続を実現できます。 さらに、この構成により、既存の IT 機器を活用し、ネットワークとセキュリティの制御をクラウド インフラストラクチャに拡張できるようになります。

最後に、クラウド エクスチェンジにコロケーションすると、企業のデータ センター、クラウド インフラストラクチャ、パブリック インターネットの結節点に制御を配置できます。 ビジネスに必要なセキュリティ ポリシーを拡張または作成し、applicationデータ フローの制御と可視性を向上させることで、全体的なセキュリティ体制を改善し、アクセスおよびセキュリティ サービスの合理化と標準化を図ることができます。

クラウドエクスチェンジのコロケーション
図3: クラウド エクスチェンジでのコロケーション。
結論

エンタープライズapplicationsをパブリック クラウドにリフト アンド シフトすることで、組織はコストを節約し、柔軟性を高め、クラウド環境に迅速に移行できるようになります。 ただし、エンタープライズapplicationsには依然として周囲のインフラストラクチャが必要であることを認識することが、移行を成功させる上で重要です。

applicationsがセキュリティ、パフォーマンス、可用性のために依存しているサービスがクラウドに存在することを確認することで、従来のエンタープライズapplicationsの実行が継続され、ユーザーの満足度が向上します。 監視を組み込むことで、問題のある領域を迅速に特定し、サービスをクラウドに移行する際にapplication所有者が感じる不安を軽減することができます。

リフト アンド シフトの行為は、堅牢な制御を再確立し、アクセスを合理化し、ビジネスの継続性を向上させる触媒としても機能し、移行の全体的な ROI を向上させます。 最後に、複数のパブリック クラウドを活用している場合は、クラウド エクスチェンジにコロケーションするメリットを検討してください。これにより、パフォーマンスが向上し、単一の制御ポイントからセキュリティとアクセス ポリシーを標準化できるようになります。

Knapp, Kristin、「The Means to the End」、Modern Infrastructure、2015 年 7 月/8 月、 http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf

2016 年 11 月 29 日公開
  • Facebookでシェア
  • Xに共有
  • LinkedInにシェア
  • メールで共有
  • AddThisで共有

F5とつながる

F5 ラボ

最新のアプリケーション脅威インテリジェンス。

デベロッパーセントラル

ディスカッション フォーラムと専門家による記事のための F5 コミュニティ。

F5 ニュースルーム

ニュース、F5 ブログなど。