クラウドへの移行で知っておくべきこと（およびその関連ドキュメント）
Google Cloud Japan Team
※この投稿は米国時間 2020 年 9 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。
長年ワークロードをオンプレミスで実行してきた企業にとって、クラウドへの移行は非常に困難なものになることがあります。移行を成功させるためにはまず、計画の段階で、人、プロセス、テクノロジーなどを多角的に考慮する必要があります。また、設計にあたっては、役立つガイダンスやベスト プラクティスが必要になります。
Google はソリューション アーキテクトとしての経験に基づき、Google Cloud への移行の計画、設計、実装を行う IT 担当者向けのドキュメントを包括的にまとめました。Google Cloud への移行のページには、移行を適切に計画し、実行するうえで役立つ幅広い技術情報とアドバイスが掲載されています。このブログ投稿では、移行をスムーズに開始できるよう、プロセス全体を概説するとともに、より詳しい情報が得られる関連ドキュメントへのリンクをまとめています。
移行を開始する
移行を開始する前に、Google Cloud、お客様の環境、さまざまな移行アプローチに関する基本を理解する必要があります。
Google Cloud と現在の環境の違いを理解します。移行元の環境がオンプレミス環境や非公開のホスティング環境だとすると、このような環境は、物理的セキュリティ、ネットワーキング、電源、ハードウェア、仮想化といった点で、パブリック クラウドとは異なる運用モデルを持っています。
移行が必要なワークロードのタイプを特定します。移行を開始する際、ワークロードをレガシーとクラウドネイティブの 2 つに分類することから始めることをおすすめします。レガシー ワークロードはクラウド環境を考慮せずに開発されており、ディスク リソースやコンピューティング リソースなどのスケーリングのサポートには制限があります。そのためレガシー ワークロードでは、変更を加えるのが難しかったり、実行やメンテナンスで多額の費用がかかったりすることがあります。ベスト プラクティスに従って設計されたクラウドネイティブのワークロードは、ネイティブにスケーラブルで、移植可能であり、可用性があり、安全です。そのため、クラウドネイティブのワークロードの場合、デベロッパーの生産性とアジリティが改善される傾向があります。デベロッパーが開発環境やランタイム環境の管理に悩まされることなく実際のワークロードに集中できるためです。
クラウド テクノロジーに対する組織の成熟度を決定します。早期に特定することで、自習、トレーニング、ピア メンタリングなどを通じ、移行プロセスを進めていくなかで不足スキルを補うことができます。クラウド導入に関する組織の成熟度は、Google Cloud のクラウド導入フレームワークで評価できます。
さまざまなタイプの移行アプローチとそのメリット、デメリットについてよく理解します。ワークロードごとに異なる移行アプローチが必要になる場合もあります。Google は、移行を以下の 3 つのタイプで定義しています。
1. リフト＆シフト。最小限の変更を適用してワークロードを移行します。
2. 改善して移行。移行の一環として、ワークロードの一部を変更してクラウドネイティブ アプローチを採用します。
3. 削除して置き換え。既存のワークロードを削除して新しいワークロードを作成し、クラウドネイティブ アプローチを採用します。
移行タイプの詳細については、移行ガイドの移行のタイプのセクションをご覧ください。
移行の 4 つのフェーズ
移行はおおまかに、評価、計画、デプロイ、最適化の 4 段階のプロセスで構成されます。並べると一見シンプルですが、このように単純にことが運ぶケースはほとんどありません。これらのフェーズが複数の異なるワークロードで同時進行することが一般的です。
フェーズ 1: 移行するワークロードを評価する
このフェーズは、それまでに行った事前作業に基づいたものです。移行するワークロードと、そのワークロードの依存関係を調べることに重点が置かれます。考慮すべき事項としては、ハードウェアとパフォーマンスの要件、ユーザー、ライセンス、コンプライアンス要件、ワークロードの依存関係などが挙げられます。次に、この情報をアプリカタログにマッピングします。このカタログで、いくつかの重要な質問に関わる情報がまとめられます。以下はその例です。
ワークロードに依存関係があるかどうか、また、ワークロードが他のワークロードの依存関係であるかどうか
各ワークロードはビジネスにとってどの程度重要か
移行の難易度はどの程度か
アプリカタログを通じて、すべてのワークロードを移行するためにかかる労力をおおむね把握できます。また、StratoZone などの自動ツールを使用して既存のワークロードをスキャンし、収集したデータに基づく情報を確認することもできます。また、StratoZone ではこの検出機能に加えて、インスタンスを一致する Google Compute Engine インスタンスにマッピングすることも可能です。StratoZone の概要については、こちらのブログ投稿をご覧ください。検出の実行方法に関する詳細は、アプリを分類するセクションでも確認できます。
リスクや労力の程度をより正確に把握するには、複雑なワークロードに着目し、ワークロードのさまざまなユースケースと要件をテストする概念実証（POC）を実施する必要があります。概念実証を行うと、より詳細な情報が早期に得られ、不明な点を限定することができます。
また、このフェーズで総所有コスト（TCO）の計算を実行して、クラウドに関連する支出が移行後にどのようになるかを可視化し、既存の環境と比較する必要があります。オンプレミスからクラウド環境に移行するときに、従来のデータセンターにかかる費用を計算するときには見逃されていた隠れた支出が見つかることはよくあります。TCO を計算する際に考慮すべき主な点は、Google のガイドの総所有コストを計算するセクションに記載されています。コストモデルの変化や獲得できる付加的な利点について経営陣の理解を得ることは、移行を成功させるために非常に重要です。
最後に、どのワークロードを最初に移行するかを決定する必要があります。これには、ワークロードのビジネス価値、移行の複雑さ、ワークロードの可用性と要件など、数多くの要素が関係します。議論の対象となる分野に詳しい、それぞれのワークロードのエキスパートを招集して会議を開き、意見の一致が見られた要素を 1 つずつよく調べ、決定の助けにすることをおすすめします。最初のワークロードの移行を成功させられるかが、移行全体の成功の鍵を握ります。初期の成功は信頼と信用につながりますが、初期に難題を抱えてしまうと、移行プロジェクト全体を狂わせる結果につながりかねません。
フェーズ 2: 基本的要素を計画する
次のフェーズは、新しいクラウド環境の基本的要素を計画することです。以下のような工程が含まれますが、これらに限定されません。
1. ユーザーとサービスの ID を確立します。ユーザーとサービス アカウントをどのように作成し管理すればよいでしょうか。G Suite ドメインと Cloud Identity ドメインのいずれかを選択できます。オプションで既存の ID プロバイダ（IdP）との統合も可能です。詳細については、Identity and Access Management セクションをご覧ください。
2. リソースの組織階層を設計します。異なる Google Cloud リソースをどのように階層的に構造化できるでしょうか。組織ノード、フォルダ、プロジェクトは、リソースの組織階層を構成する要素になります。リソースの組織を適切に設計すれば、アクセス制御と支払い管理を簡素化することができます。例として、以下のような形で設計できます。
- 環境指向の階層 - この設計では、本番環境、品質保証環境、開発環境が分離されます。
- 機能指向の階層 - この設計では、異なるビジネス機能を上位の独自フォルダに分割し、その下に環境指向の階層を実装します。
- 詳細指向の階層 - この設計では、最上位にビジネス ユニット組織が追加されることで、機能指向の階層の上に構築されます。
このトピックに関する詳細は、リソース階層セクションで確認できます。
3. リソース アクセスのグループとロールを定義します。クラウド環境にアクセスするユーザーのロールにはどのようなものがあるでしょうか。そして、それらのロールにはどのような権限が必要でしょうか。組織管理者、ネットワーク管理者、セキュリティ管理者などのマネージャーのロールを作成し、クラウド リソースを管理する必要があります。また、デベロッパー、テスター、サイト信頼性エンジニア（SRE）など、クラウド環境を使用するさまざまなクラスのユーザー向けに専用のロールを作成することも推奨しています。これらのロールには、タスクの実行に必要な最小限の権限セットが関連付けられます。このトピックについて詳しくは、企業組織のベスト プラクティスのドキュメントをご覧ください。
4. ネットワーク トポロジと接続を設計します。アプリケーションをデプロイするリージョンはどれでしょうか。移行元の環境に戻るための接続はあるでしょうか。個別に設定が必要なネットワークはいくつありますか。こうした問いを吟味することで、Google Cloud 内のプライベート ネットワークである Virtual Private Cloud（VPC）をどのように設計するかを決定できます。1 つの VPC は、お客様のクラウド環境内にある 1 つのスタンドアロン ネットワークにマッピングされます。VPC には、物理ネットワークの特徴を模倣できるサブネット、ファイアウォール ルール、ルートが備わっています。セキュリティのベスト プラクティスを確実に適用することも重要です。これらの詳細については、セキュリティ セクション、およびエンタープライズ組織のベスト プラクティス ガイドのアプリとデータを保護するセクションで確認できます。また、ダイレクト インターコネクト、ピアリング、VPN などのオプションを使用して、移行元の環境に戻る接続を確立することもできます。詳細については、接続性とネットワーキング セクションをご覧ください。
フェーズ 3: ワークロードをデプロイする
移行の基盤を整えた後の次のステップは、ワークロードをクラウド環境にデプロイする最適なアプローチを決定することです。すべてのワークロードに対して同じアプローチをとる必要はありませんが、プロセスが標準化されているほど、チーム間学習とデプロイ プロセスにおける改善の機会を増やせます。デプロイ アプローチの例として以下のようなものがあります。
1. 完全な手動デプロイ。このアプローチは、ワークロードを稼働させるための最もシンプルで迅速な方法であり、Cloud Console または Cloud SDK から直接実行できます。手動デプロイで一部の実験を行うのは問題ありませんが、エラーが発生しやすいうえ、再現性がなく、文書化も不十分になる傾向があるため、本番環境ワークロードのデプロイにはおすすめしません。現在手動デプロイを使用している場合は、手動デプロイから、自動かつコンテナ化されたデプロイへの移行セクションがプロセスの改善に有用です。
本番環境では、現在の環境にある既存のワークロードを自動的に複製して GCP に導入できるサービスを使用することをおすすめします。Google Cloud は、そのようなサービスをいくつか提供しています。
- Migrate for Compute Engine - VM ベースのアプリケーションを既存の環境（VMware、Azure、AWS など）から GCP に最小限のダウンタイムとリスクで移行できます。
- Migrate for Anthos - VM をそのまま移行する代わりに、VM で実行されているワークロードをインテリジェントに変換して GKE のコンテナに移行できます。多くの場合、これによりコストと管理を削減することができます。
- データベース移行ソリューション - Striim のようなサードパーティや、Google Cloud SQL のネイティブ レプリケーション サポートを利用するなど、Google Cloud にデータを取り込む手法はたくさんあります。
- VMware Engine - Google Cloud VMware Engine に直接変更を加えることなく、既存の VMware ベースのワークロードをオンプレミスのインフラストラクチャから移行することができます。これにより、既存の VMware デプロイツールを再利用して、移行をすぐに開始でき、Google Cloud 内の VMware フレームワークを使用して新しいワークロードを簡単に追加できます。
2. 構成管理ツールを使用したデプロイ。Ansible、Chef、Puppet のような構成管理（CM）ツールを使用すると、再現性があり、自動化され、制御された方法でデプロイを実行できます。ただし、これらのツールの最適な用途はプロビジョニングと構成であり、ワークロードのデプロイにはそれほど適していません。これらのツールには、ダウンタイムなしのデプロイ、Blue/Green デプロイ、ローリング アップデートなどを処理するために独自のデプロイ ロジックが必要であり、長期的な管理とメンテナンスが難しくなるためです。
3. コンテナ オーケストレーション ツールを使用したデプロイ。 ワークロードがコンテナ化されている場合は、Google Kubernetes Engine（GKE）を使用してデプロイ プロセスを処理できます。Kubernetes のオーケストレーターは、ダウンタイムなしのデプロイや事前に構築されたローリング アップデートなど、さまざまなタイプのデプロイ ロジックをサポートしています。ワークロードがまだ GCE を実行している VM 上にある場合は、Azure または AWS Migrate for Anthos を使用して、VM を自動的にコンテナに変換できます。これには、すばやくコンテナ上で実行できるという利点があります。
4. 自動デプロイ。 自動デプロイ プロセスは、ワークロードの変更につながるアクションに基づいてトリガーされ、スクリプト化できる任意のオーケストレーション ツール上に構築できます。デプロイの自動化により、デプロイ プロセスを合理化、標準化できるため、人的エラーの抑制になります。
Jenkins、SonarQube、Cloud Build、Spinnaker などのツールを使用して、既存のオーケストレーション ツール上にエンドツーエンドの自動デプロイ パイプラインを構築できます。自動デプロイ プロセスの主な手順は次のとおりです。
- コードのレビュー。コードベースのすべての変更は、コードベースにマージする前に、変更の品質を確認するためにピアレビューを実施する必要があります。
- 継続的インテグレーション（CI）。マージされると、CI ツールはコードベースの新しいバージョンに対して既存のすべてのテストを実行し、テストが失敗しないことを確認します。そうして初めて、ビルドが成功としてマークされます。
- アーティファクトの生成。ビルドが成功するたびに、アーティファクトが生成されます。コンテナはアーティファクトの一例です。また、Serverspec などのツールを使用してテストを実行し、アーティファクトが正常に動作しているかも確認できます。
- 継続的デプロイ（CD）。成功したアーティファクトは、開発または品質保証のクラウド環境にデプロイされます。その後、デプロイに対して別の一連の機能テストを実行して、正常に動作するかどうかを確認できます。これらのテストで問題がなければ、自動的に、またはオペレーターが手動でトリガーして本番環境にデプロイすることができます。
- インフラストラクチャをコードパターンとして適用してデプロイ。コードとしてのインフラストラクチャの背後にある考え方は、ワークロードのソースコードを扱うのと同じように、クラウド リソースの構成とプロビジョニングを扱うということです。一連の自動化された手順とテストを経て新しいバージョンのワークロードがデプロイされるのと同様に、インフラストラクチャの構成に対する変更も、テストを含む一連の手順を通過して初めて目標のクラウド環境にデプロイされます。Google が提案するこのベスト プラクティスは、デプロイ全体を高速化できる再現性とトレーサビリティを獲得するのに有効です。このプロセスを実施するには、Terraform などのツールと Deployment Manager などのマネージド サービスを使用します。
フェーズ 4: 環境を最適化する
新しい Google Cloud 環境でワークロードの基本的なデプロイが実行され、テストされたら、次はその基盤の改善に着手します。これには、ライブ トラフィックを切り替える前に完了しておくべき重要なステップが含まれます。たとえば、新しいクラウド運用戦略についてチームをトレーニングすることや、ワークロードのロギング、モニタリング、アラートを確実に実施できるようにすることなどです。
ワークロードが本番環境のトラフィックを処理するようになると、次のような点を最適化することができます。
- 自動スケーリングによるコストの最適化
- マネージド ワークロードへの移行による運用オーバーヘッドの削減
- デプロイ プロセスの自動化
適切な手法については、環境の最適化セクションをご確認ください。
クラウドへの移行を成功させるために
大規模な移行は、チームが非常に野心的であったとしても難しいプロジェクトとなるかもしれません。しかし、計画、テスト、そしてデプロイという適切なアプローチをとることで、問題をより小さく、管理しやすいステップに分割できます。Google Cloud への移行ソリューション ガイドでは、この点について詳しく説明し、「サポート」セクションなど、ワークロードのクラウドへの移行を開始する際に役立つ付加的なリソースも提供しています。
移行を成功に導いた実績を持つプロフェッショナルからさらなるサポートを希望する場合は、Google Cloud Professional Services Organization の利用をおすすめします。Google チームから、または幅広い専門知識を持つ多数のパートナーからコンサルティング サービスを受けることができます。ご連絡いただければ、いつでも移行のサポートをさせていただきます。
