アプリをクラウドへ移行する前に、まずはこちらをご覧ください
はじめに
クラウドコンピューティング環境は今やIT環境の主流となり、レガシーなオンプレミスアプリケーションをクラウドへ移行する組織がますます増えています。しかし、アプリケーションのクラウド移行は、単にクラウドプロバイダーの仮想マシンへ移すだけでは実現できません。クラウドへ移行する動機は組織によって異なりますが、どの組織も検討すべき重要な要素があり、移行を成功に導くためのベストプラクティスも存在します。クラウド移行のメリットを最大限に引き出すには、アプリケーションアーキテクチャとオンプレミスからクラウドへの移行プロセスの両面で、事前に計画を立てることが重要です。
概要
クラウドとオンプレミスの主な違い
クラウド環境は、オンプレミス環境とは異なる動作をします。両者の違いには、コンピューティングリソースを社内で所有・管理するのではなく、別の企業が所有・管理するといった明白なものもあります。しかし、特に重要な違いのいくつかは、テクノロジーそのものによるものではありません。一般に、クラウドプロバイダーから利用できるテクノロジーは、オンプレミスでも利用できます。クラウドが提供するのは、別のテクノロジーではなく、別の利用モデルです。言い換えると、クラウドプロバイダーへ移行するメリットは、コンピューティングリソースそのものではなく、その利用方法にあります。
クラウドプロバイダーは、オンプレミスのハードウェア向けに設計されたデータ監査のコンプライアンスポリシーなど、オンプレミスのすべての機能を再現できるわけではありません。クラウドのコンポーネントは地理的に分散しているため、一般にクラウド環境ではレイテンシーが大きくなります。クラウドプロバイダーには、ほかにも制約があります。複数の顧客に共通する標準に準拠しているため、コンピューティング環境のカスタマイズには実質的な限界があります。たとえば、希少で特殊なコンピューティング機器を提供するクラウドプロバイダーはほとんどありません。
しかし、企業がこうした制約の範囲内で運用できるのであれば、クラウドプロバイダーは、ほとんどの企業が自力では実現できない従量利用の仕組みを提供できます。クラウドプロバイダーは世界各地でデータセンターを運用し、組織がコンピューティングリソースを配置するデータセンターを選択できるようにしている場合があります。また、固定費を負担することで、企業が実際に使用したリソースの分だけ支払えるようにすることもできます。クラウドプロバイダーは、ほとんどの企業にはない規模の経済を活かし、デプロイの管理と自動化を行うシステムに多額の投資が可能です。これらのメリットはいずれも技術的なものではありません。クラウドプロバイダーの利点は、利用者が選択できる幅と、利用可能なコスト構造にあります。
クラウドプロバイダーの制約を緩和し、その利点を活用するには、IT部門はアプリケーションのデプロイ方法を変更する必要があります。クラウドプロバイダーの相対的な強みを最大限に活かせるようワークフローを見直す一方で、レイテンシーなど、クラウド環境が不利となる特性への依存を避けることが重要です。
クラウド移行の動機
クラウド移行の主な推進要因としてコスト削減がよく挙げられますが、実際の理由はより複雑です。移行の動機は、確実性、生産性、アジリティの3つに大別されます。
パブリッククラウドプロバイダーは、テクノロジーを利用しやすい形で提供することで確実性を高めるとともに、IT運用上のリスクの一部を引き受けます。プロバイダーがインフラストラクチャを保守し、その責任を負うため、組織はこうした懸念に対処する必要がありません。同様に、クラウドプロバイダーは通常、IT運用の状況を把握するためのツールを提供し、可視性を高めます。パブリッククラウドのコストは一般に利用量に応じて決まるため、組織はアプリケーションがもたらす収益などのメリットと、そのアプリケーションの運用コストをより密接に関連付けることができます。アプリケーションの利用が増えるとコストも増加しますが、得られるメリットも増加します。支出を設備投資から運用費へ移行することで、購入時の意思決定において将来の成長を見越した余裕を確保する必要性が低下します。こうした不確実性をクラウドプロバイダー側で管理することで、測定可能なメリットが得られます。
パブリッククラウドを導入するもう1つの理由は、生産性の向上です。プロバイダーが提供するコラボレーションツールや自動化ツールは、市場で利用できるものの中でも特に先進的です。さらに、インフラストラクチャを管理する必要がなくなるため、ITスタッフはビジネス戦略に関わる取り組みに注力できます。また、どこからでも管理できる効率化された運用により、ITスタッフの生産性も向上します。
パブリッククラウドを導入する最後の理由は、おそらく最も説得力のある「俊敏性」です。クラウドプロバイダーは、いつでも無限のリソースを利用できるかのような環境を提供するため、ビジネス施策のスピードや方向性がITプロビジョニングの制約に左右されなくなります。リソースは数秒から数分でデプロイできます。プロジェクトでは、終了時のハードウェア廃棄を気にすることなく、複雑なコンピューティング環境を短期間利用できます。ハードウェア資産を意識せずに、アプリケーションを迅速にデプロイ、スケーリング、削除できます。
クラウド移行の障壁
クラウド移行には多くのメリットがある一方で、移行の取り組みにはいくつかの課題も伴います。障壁とリスクは、移行前、移行中、移行後のどの段階で生じるかによって異なります。こうした障壁とリスクに事前に対処することで、移行が成功する可能性が高まります。
移行前の計画は、移行プロセスにおいて最も重要な要素と言えるでしょう。クラウドの機能を活用できるようにアプリケーションを再設計しなければ、移行に失敗する可能性があります。この段階は、アプリケーションの複雑さを把握し、その管理に着手する良い機会でもあります。また、ITトレーニングも取り組みの開始時に実施する必要があります。クラウド導入では、実行体制のサイロ化やツールの乱立が生じやすいため、早期段階で計画を立てることで、移行プロセスを円滑に進めやすくなります。
アプリケーションのクラウド移行は、当初の計画よりも時間がかかり、複雑になる傾向があります。問題を最小限に抑えるため、まずは小規模で比較的独立したアプリケーションから着手し、発生した問題の影響を最小限にとどめます。小規模なアプリケーションの初回移行で得た知見は、今後の移行に活用できます。
移行に伴う長期的な問題は、移行完了後に明らかになります。クラウド環境ではセキュリティ境界の定義が難しくなることが多いため、セキュリティやコンプライアンスに関する懸念が生じる可能性があります。新旧のシステムが異なる環境にあるだけでなく、異なる文化のもとで開発されている場合、レガシーシステムのサポートがさらに難しくなることがあります。特にコンテナの普及に伴い、クラウドへのロックインを懸念する組織もあります。また、変動するクラウドコストは四半期ごとの予測が難しいため、予算上の問題が生じる可能性もあります。
移行するアプリの選び方
アプリケーションを評価する手法の1つに、成熟度と配置場所のマトリックスがあります。アプリケーションを精査し、どの程度の成熟度が必要かを判断します。競争上の差別化につながるアプリケーションやニッチなアプリケーションには、オンプレミスが最適な場合があります。一方、低コストまたはコストリーダーシップを重視するアプリケーション（特に変更コストを重視する場合）は、多くの場合、クラウド環境に適しています。ほかにも、スケーラビリティなどを考慮する必要があります。たとえば、新しいアプリケーションをデプロイし、最終的に現在の100倍の負荷まで拡張する可能性があるとします。オンプレミス環境での需要増加に先回りして対応するには、インフラストラクチャを大幅に過剰プロビジョニングする必要があり、使用されないリソースに余分な設備投資が発生します。しかし、同じアプリケーションをクラウド環境にデプロイすれば、成長に応じてコストも増加するため、過剰なプロビジョニングは不要です。
クラウド環境に移行するアプリケーションを決定する際には、ネットワーク上の問題も判断材料となります。広範な販売店ネットワークなど、分散した場所にいるユーザーの割合が高いアプリケーションや、リモートでメールを利用するユーザーが多数いるアプリケーションをオンプレミスに導入すると、そのトラフィックはすべてデータセンターに集中します。トラフィックはすでにインターネットを経由しているため、こうしたアプリケーションはレイテンシーの影響を受けにくいという特性があります。このようなアプリケーションをクラウド環境に配置してもネットワークレイテンシーは変わりませんが、分散した場所にいるユーザーによって消費されていたオンプレミスデータセンターの帯域幅を解放できます。
一方で、一部のアプリをオンプレミスに残すべき理由もあります。残りの利用期間が短いアプリケーションは、移行に伴うリスクやコストに見合わない可能性があります。また、ネットワークの低遅延やストレージ速度に依存するアプリは、クラウド環境ではパフォーマンスが大幅に低下するおそれがあります。コンプライアンスやセキュリティ上の懸念も、アプリをオンプレミスに残す理由としてよく挙げられます。監査手順によっては、データを検証するためにシステムやデータへ物理的にアクセスすることを前提としている場合があります。また、アプリケーションとオペレーティングシステムをベアメタル上で稼働させること、つまり仮想マシン上では実行しないことを求める場合もあります。いずれコンプライアンス手順もクラウド環境に対応していくと考えられますが、現時点では未対応のケースが少なくありません。アプリケーションをクラウドに移行してコンプライアンス監査に不合格となるリスクを負うよりも、当面はこうした機密性の高いアプリをオンプレミスに残す方が合理的な場合があります。レガシーシステムやプロセスをサポートする必要があり、クラウドで稼働できるように再設計することが現実的ではないアプリもあります。こうしたアプリも、オンプレミスに残す候補となり得ます。以上の理由から、一部のアプリについては、クラウド環境との適合性が高いアプリよりも移行の優先度を下げるべきです。
オンプレミスに残す方が適したアプリケーション
- 短期間で利用を終了する予定のアプリ
- 低レイテンシが求められるアプリ
- コンプライアンス上の懸念があるアプリ
- レガシーシステムをサポートするアプリ
移行時の考慮事項
多くの組織は、移行プロセスでさまざまな課題を克服する必要があります。特に重要なのは、実際の切り替えをどのように行うかという点です。1つの方法は、クラウドアプリケーションの十分なテストが完了するまではDNSでオンプレミスのアプリケーションに名前解決し、その後DNSレコードを変更してクラウドアプリケーションに名前解決することです。DNSにはTime to Live（TTL）値があり、クライアントは一定期間DNS応答をキャッシュできます。切り替え後にクライアントが新しいアプリケーションへ速やかに名前解決できるよう、移行前にTTLを数秒程度まで短く設定することが適切な場合があります。ただし、この方法にはリスクも伴います。TTLを短くすると、DNSトラフィックとサーバーの負荷が大幅に増加する可能性があります。また、組織によってはTTLを無視し、指定された期間よりも長くキャッシュする場合があるため、切り替え後も一部のユーザーが長時間にわたってオンプレミスのアプリケーションに名前解決される可能性があります。この方法を使用する前に、DNSインフラストラクチャの堅牢性をテストすることを検討してください。
移行プロセスでは、テストで見つからなかった新しいアプリケーションの問題が明らかになることもあります。アプリケーションに問題が発生した場合に備える方法の1つは、処理をオンプレミスのアプリケーションに戻せるフォールバック計画を用意することです。ただし、双方向の移行ではデータ同期が複雑になるため、事前により綿密な計画とテストが必要です。より高度なアプローチとして、カナリアテストと呼ばれる部分移行があります。これは、一部のユーザーをクラウドアプリケーションに移行し、その稼働状況を監視する方法です。アプリケーションへの信頼性が高まるにつれて移行対象を増やし、最終的にはすべてのユーザーを移行できます。反対に、問題が発生した場合は、移行済みのユーザーをオンプレミスのアプリケーションに戻すことができます。カナリアテストは、プログラム可能なApplication Delivery Controller（ADC）でF5® iRules®を使用して実施できます。これにより、リスクを最小限に抑えながら、移行期間中に運用チームが選択できる対応策を増やせます。
推奨事項
クラウド向けにアプリの構築方法を変える
アプリケーションの移行時に組織が犯す大きな過ちの1つは、クラウド向けに再設計しないことです。クラウド環境の特性を活かせるよう、時間をかけてアプリケーションの構造を変更することで、大きなメリットが得られる可能性があります。
たとえば、クラウド環境でのスケーリングは、オンプレミスでのスケーリングに比べて容易です。最悪の負荷を想定してアプリケーションを設計・テストするのではなく、軽量でありながら拡張可能な設計にします。アプリケーションの利用規模が大きく変動する場合でも、大規模な構成に伴うオーバーヘッドを常時維持する必要はありません。まずは小規模に構築し、必要に応じてスケールできるようにします。同様に、クラウド環境では停電などの特定の障害が発生する可能性が低いため、それらを想定した設計の必要性も低くなります。
一方、クラウド環境には、オンプレミスでは通常生じない新たな制約があります。クラウドアーキテクトは、通常の処理の一環として、どのVMインスタンスもいつでも障害が発生し得ることを想定して設計する必要があると指摘しています。クラウド環境では、ストレージも異なります。オンプレミスの設計では、一般にローカルブロックストレージを使用します。同じ選択肢はクラウド環境でも利用できますが、共有はできません。共有されないローカルの状態とインスタンス障害が重なると、深刻な問題につながる可能性があります。ほかにも、オブジェクトベースのストレージやキーバリューストレージサービスなどのストレージ方式があります。アプリケーションを再設計することで、クラウド環境の制約に備えることができます。
オンプレミスに残すものを検討する
一部のアプリケーションや制御システムは、オンプレミスに維持するのが合理的です。多くの組織では、Active Directoryをオンプレミスに維持しながら、フェデレーションを利用してクラウド環境へアイデンティティを拡張します。同様に、ADCは、ファイアウォール、Webアプリケーションファイアウォール、DDoS対策、SSL/TLSインターセプト、サービスチェイニングなど、アプリケーションデリバリを支える多様なセキュリティサービスを提供します。また、高度なトラフィック管理、プログラム可能なプロキシ、アイデンティティおよびアクセス管理も提供します。
組織は従来、これらのアプリケーションサービスをアプリケーションの外部に集約してきました。これらのサービスはビジネスロジックの一部ではなく、運用上の要件に関わるためです。多くの企業では、アプリケーションのリリーススケジュールに左右されずに運用を変更できるよう、ADCを戦略的な制御ポイントとして活用し、すべてのアプリケーションに適用可能な専門知識を集約しています。しかし、クラウド環境ではこのモデルが変わります。
クラウド環境におけるアプリケーションデリバリへの初期のアプローチは、各クラウド環境のネイティブツールを使用してADCサービスを再現するというものでした。しかし、クラウドプロバイダーが提供するネイティブ機能の水準は同一ではないことがすぐに明らかになり、組織は、クラウド環境とオンプレミス環境で異なるアプリケーションデリバリ標準を維持するか、すべてのアプリケーションを最小公分母に合わせて再設計するかの選択を迫られました。
企業が複数のクラウド環境へと展開するにつれ、どちらの選択肢も魅力を失っていきました。たとえば、3社のクラウドプロバイダーを利用しながら、オンプレミスのデータセンターも維持している組織を考えてみましょう。この場合、SSL/TLSやDDoSなどについて、それぞれ4つの環境に対応する専門知識を維持するか、まとまりを欠き、しかも限定的になっていく基本サービス群に標準を統一する必要がありました。さらに別のクラウド環境に新しいアプリケーションを1つ導入するだけでも、新たな専門家チームを確保するか、既存のすべてのアプリケーションに適用する新たな標準を策定する必要があり、多額の追加コストが発生しました。
しかし、すべての環境で一貫したサービスを提供するための第3の選択肢があります。F5 Application Connectorを使用すると、アプリケーションがどこに存在していても、1つの専門家チームですべてのアプリケーションを管理できます。既存のBIG-IP®ハードウェアまたはソフトウェアアプライアンスを使用することで、組織は場所を問わず、あらゆるアプリケーションの前段に高度なアプリケーションサービス一式を導入できます。これにより、すべてのアプリケーションに戦略的な制御ポイントを設け、1つの専門家チームで管理できます。さらに、Application Connectorは、外部から見えるパブリックIPアドレスをすべて排除して攻撃対象領域を縮小することで、セキュリティを強化します。暗号化キーをクラウドインスタンスではなく一元的に保管するため、重要な暗号情報の機密性を維持できます。さらに、Application Connectorでは、プロキシインスタンスが新しいワークロードノードを自動検出できるため、クラウド導入の効率が向上します。
ストレージを慎重に検討する
オンプレミスアプリケーションとクラウドアプリケーションの大きな違いの1つは、アプリケーションの状態を保存するストレージです。オンプレミスの設計では、ほとんどの場合、ハードディスクやソリッドステートドライブなどのローカルブロックストレージを使用します。クラウドアプリケーションでもブロックストレージを使用できますが、そのストレージはインスタンスにローカル接続されているため、インスタンスの障害を想定して設計する必要があります。アプリケーションをクラウドに移行する際、アプリケーション設計のほかの部分を変更しない場合でも、状態の処理方法は変更する必要があります。
一般的なクラウドストレージの種類の1つにオブジェクトストレージがあります。各オブジェクトは実質的にはファイルですが、名前を使ってアクセスします。通常、このストレージの階層は最大でも1レベル（フォルダーまたはディレクトリ）であるため、従来のファイルシステムをオブジェクトにマッピングすると問題が生じる可能性があります。オブジェクトは編集できず、作成、読み取り、削除のみが可能です。そのため、オブジェクトストレージは画像などの静的コンテンツには適していますが、状態の保存には適していません。多くのアプリケーションはファイルを変更できることを前提としているため、オブジェクトでは動作しません。
その他のストレージの選択肢には、キーバリューストアや従来型のトランザクションデータベースがあります。これらはファイルシステムのようなストレージではありませんが、データを保存する機能を備え、追加サービスとして提供されます。適切に設計すれば、状態をキーバリューストアやデータベースサービスに保存できます。
要点：移行前の準備が重要
クラウドコンピューティング環境のメリットを得るには、クラウドの制約による影響を軽減しながら、その機能を活用できるように主要なアプリケーションを再設計する必要があります。クラウド環境では、オンプレミスとは障害の発生パターンが異なり、ネットワーク遅延が増大することも少なくありません。一方で、迅速なスケーリングが可能で、世界各地のデータセンターから選択できます。クラウドへの移行にあたっては、移行するアプリケーションとオンプレミスに残すアプリケーションを見極める必要があります。
移行プロセス自体についても慎重に検討して計画を立て、クラウドアプリケーションが想定どおりに動作しない場合に備えて、切り戻し計画を用意する必要があります。計画の一環として、ホスティング先を問わず、すべてのアプリケーションを管理する戦略的な制御ポイントとして、オンプレミスにADCを維持する組織もあります。さらに、クラウドアプリケーションでデータと状態をどのように保存するかを慎重に計画してください。アプリケーション、そしてビジネスをどのような方法でクラウドへ移行する場合でも、経験豊富なクラウドパートナーの支援を受けることをご検討ください。
2017年8月16日公開