Google Cloud 移行を簡単に
Google Cloud Japan Team
※この投稿は米国時間 2020 年 9 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Cloud では、パブリック クラウドの機能を効率的に統合することが企業のデジタル変革に向けた取り組みにおいて不可欠であると考えます。適切に設計されたデジタル変革戦略を採用することで、競争力を維持できるだけでなく、IT スタッフを価値の低い労働集約的な作業から解放し、イノベーションと影響の大きいプロジェクトに集中させることができ、卓越したサービスを提供する企業としての地位を確立できます。
多くの場合、クラウドへの移行は、迅速かつシンプルな手段でコストを削減し柔軟性を向上させることができるということから、デジタル変革への第一歩となります。この記事では、オンプレミスまたはパブリック クラウドでホストされたインフラストラクチャの Google Cloud への移行について焦点をあてます。
実際のところ、デジタル変革を開始して、対応する移行戦略を計画する際に唯一の正解というものはありません。すべての変革にはそれぞれ微妙な違いや固有の考慮事項があります。各オプションの長所と短所を把握したうえで、決定が行われています。
どこから始めるか
出発点を理解することは、アプリケーション移行戦略の計画と実施を成功させるためには不可欠です。技術要件だけでなく、ビジネス上の目標（現在と将来）の検討、重要なタイムライン、独自の内部機能を含めた包括的なアプローチを取る必要があります。状況によって、価値創出までの時間にも関わるということから、以下のようなカテゴリが当てはまる可能性があります。移行のすべての状況に対応できるアプローチはありませんが、重要なのはどの手段を選んでも、構築を重ねていく方法は常に存在し、追加的にクラウドの利点を活用し続けることができるということです。
Google Cloud へ移行する場合
お客様のアプリケーションをクラウドに移行できるか、また移行するべきかについて判断するには、次の質問に回答することから始めてください。
1.自社のアプリケーション スタックのコンポーネントは仮想化されていますか（または仮想化可能ですか）。
2.自社のアプリケーション スタックは、ライセンス、セキュリティ、プライバシー、コンプライアンスの各要件を満たした状態で、クラウド環境で運用できますか。
3.すべてのアプリケーション依存関係（サードパーティ製の言語、フレームワーク、ライブラリなど）はクラウドでサポートできますか。
上記の質問のいずれかで答えが「いいえ」であった場合、それらのアプリケーション コンポーネントをクラウドでのサービスと置き換えることが実行可能かどうか評価することをおすすめします。実行可能でない場合は、デジタル変革の初期のフェーズで、それらのコンポーネントをオンプレミスに保持して、他のアプリケーション コンポーネントの移行に焦点を合わせることをおすすめします。
オンプレミスでの保持が実行不可能になった場合（データセンターを完全に閉鎖する必要がある場合など）、またはクラウド リソースへの近接性を高める必要がある場合は、Google Cloud の Bare Metal Solution を活用するか、適切なクラウド リージョンに隣接するコロケーション施設に移行することが推奨される代替的な方法です。
最適な移行パスの決定
変革の取り組みを開始したら、Google Cloud への移行の 5 つの重要なタイプを検討することをおすすめします。
1.Google Cloud マネージド サービスへの移行
2.Google Kubernetes Engine（GKE）または Anthos 上のコンテナへの移行
3.GCE（Google Compute Engine）上の VM（「リフト＆シフト」）への移行
4.Google Cloud VMware Engine への移行
5.Google Cloud Bare Metal Solution への移行
次のようなシナリオの例があります。
積極的なタイムラインに取り組んでいる場合は、クラウドへのリロケーションによりインフラストラクチャのモダナイゼーションを迅速に実施できる「リフト＆シフト」が適切な選択肢になる可能性があります。これは、後で追加のモダナイゼーションでフォローアップできます。
クラウドへの移行を直ちに活用する必要があるが、時間とスキルが制限されている場合、「リフト＆最適化」が最適です。クラウドでコンピューティング仮想マシンや VMware Engine を使用するときは、同様の使い慣れている仮想化された環境でも、クラウドの柔軟性や規模の利点を活用できます。
クラウドの利点（柔軟性、規模、マネージド サービスなど）を直ちにフル活用する必要がある場合、移行と組み合わせてさらに積極的にモダナイズする（コンテナ テクノロジーの採用など）ことが最も効率的です。この状況では、「移行して改良」と「リファクタリング」が最適ですが、現在のアプリをコンテナに適応させたりサーバーレスにしたりするのに必要な変更作業のため、この方策の実施には多少長い時間がかかります。
以下のディシジョン ツリーを利用して、お客様のアプリケーションに適したパスを選ぶことができます。
一般的なユースケース
ユースケース 1: ハイブリッド クラウドのバースト
Cloud Interconnect を使用して、オンプレミスとクラウド間の接続を設定します。
Cloud ランディング ゾーンを作成します。これには、Google Compute Engine（GCE）、Google Kubernetes Engine（GKE）、Google Cloud VMware Engine（GCVE）、Anthos などのプロジェクトとリソースの作成が含まれます。
次に、適切なリソースでオンプレミスからクラウドへの「リフト＆シフト」または「リフト＆最適化」を実施します。
これで、トラフィック バーストや過剰なトラフィックを Google Cloud に送信して、既存のデータセンターへの負荷を低減する準備が整います。
ユースケース 2: Anthos によるモダナイズ
Cloud Interconnect を使用して、GCP へのネットワーク接続を確立します。
クラウド ランディング ゾーンを作成します。
次に、ワークロードをリフト＆シフトし、オンプレミスの容量を解放します。
Anthos オンプレミス ランディング ゾーンを構築します。
次に、オンプレミスとクラウドの両方でアプリをモダナイズします。
ユースケース 3: ランディング、拡張、使用停止
Cloud Interconnect を使用して、GCP へのネットワーク接続を確立します。
クラウド ランディング ゾーンを作成します。
次に、すべてのワークロードを移行します。
最後に、完了後にデータセンターを使用停止します。必要に応じて、ハードウェアの使用停止を反復処理します。
ユースケース 4: DR サイトの昇格
Cloud Interconnect を使用して、GCP へのネットワーク接続を確立します。
クラウド ランディング ゾーンを作成します。
これで、Cloud 内のすべてのワークロードを複製する準備が整います。
次に、Cloud へのユーザー接続を PRIMARY に切り換えます。
最後に、コロケーションをすべて一度に使用停止します。
まとめ
デジタル変革の取り組みを開始したばかりでもその途中段階でも、Google Cloud はお客様がどこにいてもサポートし、より柔軟でアジャイルなインフラストラクチャへの移行を容易にします。ご紹介したステップがお客様の取り組みの出発点となり、デジタル変革をより簡単に推進できることを願います。
クラウドへの移行を始める方法についてのチュートリアルとなる動画シリーズをご覧ください。
移行のご購入手続きの詳細については、こちらのホワイトペーパーと、こちらのソリューション ガイドをご覧ください。
#GCPSketchnote や同様の Cloud コンテンツの詳細については、Twitter @pvergadia をフォローしていただき、thecloudgirl.dev をご確認ください。
-デベロッパー アドボケイト Priyanka Vergadia
