アプリをクラウドに移行しますか? まずこれを読んでください。

クラウド コンピューティング環境は現在、IT 環境の主要な特徴となっており、組織は従来のオンプレミスapplicationsをクラウドに移行する頻度がますます高まっています。 しかし、applicationをクラウドに移行するには、applicationをクラウド プロバイダの仮想マシンに移動する以上のことが必要です。 クラウド移行の動機は組織によって異なりますが、すべての組織が考慮すべき重要な要素があり、クラウド移行の取り組みを成功させるのに役立つベスト プラクティスも確かに存在します。 クラウド移行から最大限のメリットを得るには、applicationアーキテクチャとオンプレミスからクラウドへの移行の両方を事前に計画する必要があります。

クラウド環境はオンプレミス環境とは異なる動作をします。 2 つの環境の違いのいくつかは明らかです。たとえば、コンピューティング リソースは社内で所有および管理されるのではなく、別の企業によって所有および管理されるという点です。 しかし、最も重要な違いのいくつかは、テクノロジーの機能ではありません。 一般的に、クラウド プロバイダから利用できるテクノロジーはすべてオンプレミスでも利用できます。 クラウドが提供するのは代替テクノロジーではなく、代替消費モデルです。 言い換えれば、クラウド プロバイダに移行する利点は、コンピューティング リソース自体ではなく、コンピューティング リソースがどのように消費されるかにあります。

クラウド プロバイダーは、オンプレミス ハードウェア用に設計されたデータ監査コンプライアンス ポリシーなど、すべてのオンプレミス機能を必ずしも複製できるわけではありません。 クラウド コンポーネントは地理的に分散しているため、クラウド展開では一般にレイテンシが悪化します。 クラウドプロバイダーは他の制限にも直面しています。 プロバイダーはクライアント間で標準に準拠しているため、コンピューティング環境のカスタマイズには実際の制限が存在します。 たとえば、希少で特殊なコンピューティング機器を提供するクラウド プロバイダーはほとんどありません。

しかし、企業がそれらの制限内で運営できる場合、クラウド プロバイダはほとんどの企業が手に負えない消費機能を提供できます。 クラウド プロバイダは世界中にデータ センターを運営し、組織にコンピューティング リソースを配置するデータ センターの選択肢を提供します。 クラウド プロバイダは固定費も吸収できるため、企業は実際に使用したリソースに対してのみ支払うことができます。 クラウド プロバイダは、ほとんどの企業に匹敵する規模の経済性を備えているため、展開を管理および自動化するためのシステムに多額の投資を行うことができます。 これらの利点はいずれも技術的な性質のものではなく、むしろ、クラウド プロバイダの利点は、消費者が利用できる選択肢とコスト構造にあることに注意してください。

クラウド プロバイダの制限を緩和し、その利点を活用するには、IT 部門はapplicationsの展開方法を変更し、ワークフローを変更してクラウド プロバイダの相対的な強みを最大限に活用すると同時に、レイテンシなど、クラウド環境が不利になる属性への依存を回避する必要があります。

クラウドに移行する主な動機としてコスト削減がよく挙げられますが、本当の理由はより微妙な傾向があります。 ほとんどの動機は、確実性、生産性、俊敏性の 3 つのカテゴリに分類されます。

パブリック クラウド プロバイダーは、テクノロジーをパッケージ化して使いやすくすることで確実性を高め、そうすることで IT 運用上のリスクの一部を吸収します。 プロバイダーがインフラストラクチャを維持し、責任を負うため、組織はこれらの懸念を無視できます。 同様に、クラウド プロバイダーは通常、IT 運用に関する洞察を得るためのツールを提供し、可視性を高めます。 パブリック クラウドのコストは一般的に消費量に応じて決まるため、組織はapplicationのメリット (収益など) をそのapplicationの運用コストとより密接に結び付けることができます。 applicationの使用が増えるにつれてコストは増加しますが、メリットも増加します。 経費を資本から運用に移すことで、購入の決定において将来の成長に備える必要性が低くなります。 これらの不確実性をクラウド プロバイダレベルで管理すると、測定可能なメリットが得られます。

パブリック クラウドを導入するもう 1 つの理由は、生産性の向上です。 プロバイダーが提供するコラボレーションおよび自動化ツールは、市場で入手可能な最も先進的なものの 1 つです。 さらに、インフラストラクチャを管理する必要がないため、IT スタッフはビジネス戦略的な取り組みに集中できるようになり、どこからでも管理できる合理化された運用により IT スタッフの生産性が向上します。

パブリック クラウドを採用する最後の理由は、おそらく最も説得力のある「俊敏性」です。 クラウド プロバイダは、いつでも無限のリソースが利用可能であるという幻想を作り出すため、ビジネス活動のスピードと方向性は、IT プロビジョニングの制約に縛られなくなります。 リソースは数秒または数分で展開できます。 プロジェクトでは、プロジェクトの終了時にハードウェアを廃止する必要なく、短期間で複雑なコンピューティング環境を利用できます。 ハードウェア資産を気にすることなく、applicationsを迅速に展開、拡張、削除できます。

クラウド移行には多くの利点がありますが、移行作業にはいくつかの課題が伴います。 障壁とリスクは、移行プロセスのどこで発生するか（移行前、移行中、移行後）によって異なります。 これらの障壁とリスクに事前に対処することで、移行作業が成功する可能性が高まります。

移行前の計画は、おそらく移行プロセスの中で最も重要な部分です。 クラウド機能を活用するためにapplicationを再設計できなかったために、移行作業が失敗する可能性があります。 これは、アプリケーションの複雑さを評価し、管理を開始するのに適した時期でもあります。 IT トレーニングも取り組みの開始時に実施する必要があります。 クラウドの導入では、サイロ化された実行とツールの急増が起こりがちであり、初期段階で計画を立てることで移行プロセスをスムーズに進めることができます。

applicationsをクラウドに移行すると、当初の計画よりも時間がかかり、複雑になる傾向があります。 問題を最小限に抑えるには、発生した問題の影響が最小限になるように、小さく比較的独立したapplicationから始めます。 小規模なapplicationの最初の移行から得られた教訓は、将来の移行に適用できます。

移行に伴う長期的な問題は、移行が完了した後に明らかになります。 クラウド環境ではセキュリティ境界を定義するのがより困難になるため、セキュリティとコンプライアンスに関する懸念が生じることがあります。 古いシステムと新しいシステムが異なる環境にあるだけでなく、異なる文化で開発されている場合、レガシー システムのサポートはより困難になる可能性があります。 一部の組織では、特にコンテナの増加に伴い、クラウド ロックインに対する懸念が生じています。 最後に、変動するクラウド コストを四半期ごとに予測することが難しいため、予算に関する懸念が問題になる可能性があります。

applicationsを評価する 1 つの手法は、成熟度と場所のマトリックスです。 applicationsを調べて、どの程度の成熟度が必要かを判断します。 競争上の差別化を実現するapplicationsやニッチなアプリケーションは、オンプレミスで提供するのが最適です。 一方、低コストまたはコストリーダーシップのapplications（特に変更コスト）は、クラウド環境に適合することがよくあります。 考慮すべきその他の要素には、スケーラビリティが含まれます。 新しいapplicationがデプロイされ、最終的には現在の負荷の 100 倍に拡張される可能性があるとします。 オンプレミス展開の成長に遅れを取らないためには、インフラストラクチャを大幅に過剰にプロビジョニングする必要があり、アイドル状態のリソースに追加の資本コストがかかります。 ただし、同じapplicationをクラウド環境に導入すると、コストは成長に合わせて拡大し、過剰なプロビジョニングの必要がなくなります。

ネットワークの問題は、どのapplicationsをクラウド環境に移行するかを決定する際にも影響することがあります。 大規模なディーラー ネットワークや、多数のリモート メール ユーザーなど、applicationに分散ユーザーの割合が大きい場合、オンプレミス展開では、そのトラフィックのすべてをデータ センターに集めます。 トラフィックはすでにインターネットを通過しているため、applicationsは遅延の影響を受けません。 このようなapplicationsをクラウド環境に配置すると、ネットワークのレイテンシは変わりませんが、分散したユーザーが消費していたオンプレミスのデータセンターの帯域幅が解放されます。

同時に、一部のアプリをオンプレミスで維持する理由もあります。 寿命が短いapplicationsの場合、移行作業のリスクとコストに見合わない可能性があります。 一部のアプリは低いネットワーク遅延とストレージ速度に依存しており、クラウド環境ではパフォーマンスが大幅に低下する可能性があります。 アプリをオンプレミスで維持する理由として、コンプライアンスとセキュリティに関する懸念がよく発生します。 一部の監査手順では、データを検証するためにシステムとデータへの物理的なアクセスを前提としていますが、他の監査手順では、applicationとオペレーティング システムがベアメタル上で実行されることが必要です (つまり、仮想マシン上で実行することはできません)。 時間の経過とともに、コンプライアンス手順はクラウド環境に適合するようになりますが、多くの場合、まだそうなっていません。 クラウド内のapplicationsでコンプライアンス監査に失敗するリスクを負うのではなく、今のところは機密性の高いアプリケーションをオンプレミスに保持する方が理にかなっている可能性があります。 一部のアプリはレガシー システムとプロセスをサポートする必要があるため、クラウドで動作するように再設計することは現実的ではありません。 これらのアプリもオンプレミスに残しておく候補になる可能性があります。 これらの理由から、一部のアプリは、クラウド環境に適したアプリよりも移行の優先順位を低くする必要があります。

applicationsはオンプレミスで残した方がよい

• 寿命が短いアプリ
• 低遅延を必要とするアプリ
• コンプライアンス上の懸念があるアプリ
• レガシーシステムをサポートするアプリ

多くの組織は、移行プロセス中に課題を克服する必要があります。 答えなければならない大きな疑問は、実際の切り替えをどのように実行するかということです。 1 つの方法は、クラウドapplicationが徹底的にテストされるまで DNS を使用してオンプレミスapplicationに解決し、その後、DNS レコードを変更してクラウドapplicationに解決することです。 DNS には、クライアントが一定期間 DNS 応答をキャッシュできるようにする有効期間 (TTL) 値が含まれています。 移行前に、TTL を数秒程度低く設定して、切り替え後にクライアントが新しいapplicationsにすばやく解決できるようにすることが賢明です。 ただし、このアプローチにはいくつかのリスクがあります。 TTL を下げると、DNS トラフィックが大幅に増加し、サーバーの負荷も増加する可能性があります。 組織は TTL を無視し、指定された期間よりも長い期間キャッシュする可能性があり、カットオーバーが行われた後も、一部のユーザーがオンプレミスapplicationに解決されたままになる可能性があります。 このアプローチを使用する前に、DNS インフラストラクチャの堅牢性をテストすることを検討してください。

移行プロセスでは、テストでは発見されなかった新しいapplicationの問題が明らかになることもあります。 問題のあるapplicationを回避する方法としては、問題が発生した場合にオンプレミスのapplicationに処理を戻すことができるフォールバック プランがあります。 残念ながら、双方向の移行ではデータの同期が複雑になるため、事前にさらに多くの計画とテストが必要になります。 より洗練されたアプローチでは、カナリア テストと呼ばれる部分的な移行を使用します。これは、監視中に一部のユーザーをクラウドapplicationに移行します。 applicationに対する信頼が高まるにつれて、より多くの、そして最終的にはすべてのユーザーを移行できるようになります。 逆に、問題が発生した場合、移行したユーザーはオンプレミスapplicationの使用に戻ることができます。 カナリア テストは、F5® iRules® を介してプログラム可能なapplication配信コントローラ (ADC) によって実行できるため、移行期間中に運用チームが利用できるオプションの数を増やしながらリスクを最小限に抑えることができます。

組織がapplicationsを移行する際に犯す最大の間違いの 1 つは、アプリケーションをクラウド用に再設計しないことです。 クラウド環境の違いを活用できるようにapplicationの構造を変更する時間を割り当てると、大きなメリットが得られます。

たとえば、クラウド環境でのスケーリングは、オンプレミスでのスケーリングに比べると簡単です。 applicationを設計して最悪の負荷をテストするのではなく、スリムでありながらスケーラブルなapplicationを設計します。 applicationの使用範囲が広範囲にわたる場合、大きなフットプリントのオーバーヘッドを維持する必要はありません。 代わりに、小さく構築して、拡張できるように準備しておいてください。 同様に、クラウド環境では停電などの特定の障害が発生する可能性が低いため、それらを考慮して設計する必要も少なくなります。

一方、クラウド環境では、オンプレミスでは通常発生しない新たな制限が発生します。 クラウド アーキテクトは、設計では通常の処理の一環として、いつでも VM インスタンスの障害に備える必要があることに留意しています。 クラウド環境ではストレージも異なります。 オンプレミス設計では、ローカル ブロック ストレージが定期的に使用されます。 同じオプションはクラウド環境で使用できますが、共有することはできません。 ローカルの非共有状態とインスタンス障害の組み合わせは、災害の原因となる可能性があります。 オブジェクトベースのストレージやキー値ストレージ サービスなど、他のストレージ パラダイムも存在します。 クラウド環境の制限に対するヘッジは、applicationを再設計することによって行うことができます。

一部のapplicationsや制御システムは、オンプレミスで維持することが合理的です。 多くの組織では、フェデレーションを使用して ID をクラウド環境に拡張しながら、オンプレミスの Active Directory を維持します。 同様に、ADC は、ファイアウォール、Webapplicationファイアウォール、DDoS 保護、SSL/TLS インターセプト、サービス チェーンなど、application配信をサポートする多くのセキュリティ サービスを提供します。 ADC は、高度なトラフィック管理、プログラム可能なプロキシ、および ID とアクセス管理も提供します。

これらのアプリケーション サービスはビジネス ロジックの一部ではなく、運用上の懸念事項であるため、組織では通常、これらのapplicationサービスをapplicationの外部に統合しています。 applicationのリリース スケジュールに関係なく運用上の変更を可能にするために、多くの企業は、ADC を戦略的な制御ポイントとして使用して、すべてのapplicationsに適用できるドメインの専門知識を集中させます。 しかし、クラウド環境はこのモデルを変えます。

クラウド環境でのapplication配信に対する初期のアプローチは、各クラウド環境でネイティブ ツールを使用して ADC サービスを複製することでした。 すぐに、クラウド プロバイダーが同じレベルのネイティブ機能を提供していないことが明らかになり、組織には、クラウド環境とオンプレミス環境間で異機種application配信標準を維持するか、すべてのapplicationsを最低限の共通基準に合わせて再設計するかという選択が求められました。

企業が複数のクラウド環境に拡大するにつれて、どちらのオプションも受け入れにくくなりました。 ある組織が 3 つのクラウド プロバイダーを活用し、オンプレミスのデータ センターも維持しているとします。 組織は、SSL/TLS の専門知識を 4 セット、DDoS の専門知識を 4 セットなど維持するか、ますます断片化 (および制限) される基本サービスのセットを標準化する必要がありました。 追加のクラウド環境に 1 つの新しいapplicationを導入するだけでも、別のドメイン エキスパート グループ、または既存のすべてのapplicationsに適用する新しい標準セットのいずれかに多大な限界コストがかかります。

しかし、すべての環境で一貫したサービスを提供するための 3 番目の選択肢があります。 F5applicationコネクタを使用すると、applicationsがどこに存在するかに関係なく、1 組のドメイン エキスパートがすべてのapplicationsを管理できます。 既存の BIG-IP® ハードウェアまたはソフトウェア アプライアンスを使用することで、組織は、どこにあってもあらゆるapplicationの前に完全な高度なapplicationサービスを挿入し、すべてのapplicationsに単一のドメイン エキスパート セットによって管理される戦略的な制御ポイントを提供できます。 さらに、 Application Connector は、目に見えるすべてのパブリック IP アドレスを排除することでセキュリティを強化し、攻撃対象領域を減らします。 暗号化キーをクラウド インスタンスではなく集中的に保存することで、組織は重要な暗号化情報が非公開のままであることを確信できます。 最後に、 Application Connector は、プロキシ インスタンスによって新しいワークロード ノードが自動的に検出されるようにすることで、クラウド展開の効率を高めます。

オンプレミスapplicationsとクラウドapplicationsの最大の違いの 1 つは、application状態の保存です。 オンプレミスの設計では、ほとんどの場合、ハード ディスクやソリッド ステート ドライブなどのローカル ブロック ストレージが使用されます。 クラウドapplicationでもブロック ストレージを使用できますが、ストレージはインスタンスに対してローカルであり、設計ではインスタンスの障害を想定する必要があります。 組織がアプリをクラウドに移行するときにapplication設計の他の部分を変更する必要がない場合は、状態の処理方法を変更する必要があります。

一般的なクラウド ストレージの種類はオブジェクト ストレージです。オブジェクト ストレージでは、各オブジェクトは基本的にファイルですが、名前を使用してアドレス指定されます。 通常、ストレージには最大 1 つの階層レベル (フォルダーまたはディレクトリ) があるため、従来のファイル システムをオブジェクトにマッピングすると問題が発生する可能性があります。 オブジェクトは編集できず、作成、読み取り、削除のみ可能であるため、オブジェクト ストレージは画像などの静的コンテンツには適していますが、状態には適していません。 多くのapplicationsは、ファイルが変更可能であることを前提としているため、applicationsでは動作しません。

その他のストレージの選択肢としては、キー値ストアや従来のトランザクション データベースなどがあります。 これらはファイルシステムのようなストレージではありませんが、データを保存し、追加サービスとして提供されます。 効果的な設計により、状態をキー値またはデータベース サービスに保存できます。

クラウド コンピューティング環境はメリットをもたらしますが、それはクラウドの制限の影響を軽減しながらクラウド機能を活用するように主要applicationsが再設計された場合に限られます。 クラウド環境では障害シナリオが異なり、ネットワーク遅延が増加することがよくありますが、迅速なスケーリングと世界中のデータセンターの選択が可能になります。 クラウド移行の考慮事項には、どのapplicationsを移行し、どのアプリケーションをオンプレミスに保持するかを決定することが含まれます。

移行プロセス自体についても、クラウドapplicationが期待どおりに動作しない場合に備えてバックアウト プランを慎重に検討して計画する必要があります。 計画プロセスの一環として、ホストされている場所に関係なく、すべてのapplicationsの戦略的な制御ポイントとしてオンプレミスに ADC を維持する組織もあります。 最後に、クラウドapplicationがデータと状態を保存する方法を慎重に計画します。 applicationsとビジネスをクラウドに移行する方法を選択する場合は、経験豊富なクラウド パートナーの協力を得ることを検討してください。