クラウドとその先へ: データセンターの複数年にわたる移行を計画する
Google Cloud Japan Team
※この投稿は米国時間 2021 年 2 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。
クラウドへのデータセンターの移行はやっかいなビジネス イニシアチブであることが多く、既存のハードウェア、ソフトウェア、ネットワーク、オペレーションを新しい環境へ移行するために何年も要することがあります。Google Cloud の Professional Services Organization の役割として、私たちはお客様と密接に連携して設計を行い、Google Cloud へのデータセンター移行を実現しています。長年にわたり複数の移行作業に関わるなかで、工夫して一般的なアプローチを考案してきました。ここに至るまでに、数多くの複雑な事態に遭遇し、多くの学びを得てきました。今回の投稿では、私たちがおすすめするデータセンター移行プロセスの概要についてご説明します。また今後の投稿では、移行の技術面およびプログラム管理による移行について詳しく説明していく予定です。
移行プロセス
あらゆるデータセンターの移行には、コスト削減やクラウド ネイティブ環境の度合いを高めたいといった理由が背景にあります。そうした理由から、「n か所のデータセンターをこの日までに Google Cloud に移行する」といったビジネス目標が発生します。動機にかかわらず、共通の課題はどのようにしてリスクを効果的に管理しながらデータセンター移行を成功させるかということです。
そのため私たちは、調査、計画、実行、最適化という 4 つのフェーズで構成される、反復可能な移行アプローチを考案しました。多くのデータセンター移行において、この反復可能なフレームワークを利用すると、アセットを簡単に確認し、複数フェーズの移行アプローチを通じてリスクを最小化し、デプロイと構成を行い、完了した状態の最適化を行うことができます。
フェーズ 1: 調査
私たちの移行アプローチの最初のステップは調査フェーズです。ここでは、組織のデータセンター チームと連携し、データセンターのフットプリント全体を把握して文書化します。これには、既存のハードウェア マッピング、ソフトウェア アプリケーション、ストレージ レイヤ（データベース、ファイル共有）、オペレーティング システム、ネットワーク構成、セキュリティ要件、オペレーション モデル（リリース候補、デプロイ方法、エスカレーション管理、システム メンテナンス、パッチ適用、仮想化など）、ライセンスおよびコンプライアンス要件の把握が含まれ、他の該当するアセットも対象になります。
このフェーズは、現在のデータセンター フットプリントの該当するすべてのアセットとリソースの詳細なビューを入手することが目的です。このようなリソースにはリソース グループの分類も含まれ、依存関係のマッピングと移行 Wave の計画のために以降のフェーズで利用されます。たとえば、データセンターのインベントリのリストアップ時に、各種のオペレーティング環境（本番環境と非本番環境）、依存関係（サードパーティ ソフトウェア、ドメイン コントローラなど）、移行の範囲内にあるサードパーティ システムを含む、すべてのアプリケーションのビジネスへの影響を確認する必要があります。
調査フェーズの主要なマイルストーン:
「共有される」データセンター インベントリのフットプリントの作成 - クラウド移行に関わるすべてのチームが、本番運用するアセットとリソースについて認識している必要があります。
初期 GCP 基盤設計の完了 - これには、フォルダ構造、Identity and Access Management モデル、ネットワーク管理モデルなどといった、GCP 組織の統一コンセプトの確認が含まれます。
さらに調査フェーズでは、IT 部門からプログラム管理のための財務部門に至る、他の社内部門との協議を行い、将来のクラウド プロセスをサポートする変化に適応しておくことをおすすめします。物理データセンターの Google Cloud への移行では、データセンター スタッフが Google Cloud 内のシステムとインフラストラクチャの管理をサポートするためのトレーニングを受けているかどうかに注意を払うことが重要になります。また、Google Cloud で使用するサービスのサービスレベル契約（SLA）の再評価と調整が必要になることがあります
フェーズ 2: 計画
第 2 のフェーズは計画です。計画フェーズでは、調査フェーズで収集されたアセットと成果物を利用して、本番環境と非本番環境に順次デプロイする移行 Wave（リソースの論理グループ）を作成します。
経験則としては、非本番環境の移行 Wave を最初に対象とし、その後の Wave をどのように移行する必要があるかを見極めることをおすすめします。以下について検討しておきましょう。
現在のサーバー インベントリを Google Cloud のマシンタイプにマッピング - 現在の各ワークロードは通常、同等の処理能力、メモリ、ディスクを備えるマシンタイプで実行することになります。
タイムライン - いつ何を移行するか。
各グループのワークロード - 何をどのよう移行 Wave にグループ化するか。本番環境アプリケーションと非本番環境アプリケーションでグループ化？機能（データベース、ファイル共有、アプリケーション）でグループ化？
コードリリースのタイミング - 今後のコードリリースを考慮に入れます。すぐに移行するのか、後で移行するのかの決定に影響を与えることがあります。
インフラストラクチャのデプロイとテストのための時間 - Google Cloud へ完全に切り替える前にインフラストラクチャをテストするための適正な時間を考慮に入れます。
アプリケーションの依存関係の数 - 依存関係が最も少ないアプリケーションは、一般的に移行の最初の候補となります。それに対して、複数のデータベースに依存するアプリケーションは、移行を待ったほうがよいでしょう。
移行の複雑さとリスク - 一般的に、移行のシンプルな側面を先に処理すると、移行に成功する可能性が高まります。
移行 Wave については、予測可能性が高くシンプルなワークロードから始めて自信をつけることをおすすめします。たとえば、ここではファイル共有を最初に移行してから、データベース、ドメイン コントローラ、最後にアプリの順で移行することをおすすめします。
IT 組織の将来の状態を設計し始める際や、Google Cloud で主要なワークロードをサポートするため既存のロールをどのように変換するかを議論する際も計画フェーズとみなすことができます。「移行後に Google Cloud をサポートするため既存のスタッフモデルをどのようにマッピングするべきか」というご質問をよく受けます。多くの場合、既存のスタッフをどのようにトレーニングするべきか、また移行後の組織の状態に基づいて、どこに調整が必要になるかを話し合うと効果的です。組織の調整を開始する最適なタイミングは、移行 Wave のデプロイの開始時です。
計画フェーズで検討すべきもう一つの分野は、DevOps および SRE のプラクティスを実装するかどうかです。多くのお客様は、クラウドに移行するタイミングで Infrastructure as Code プラクティスを確立し、継続的インテグレーション / 継続的デリバリー（CI / CD）パイプラインを利用してコードのビルドとリリースを統合して、場合によっては社内サービスレベル指標（SLI）を定義しようと試みます。また Google Cloud サポートが関与するプロセスを含む、インシデント管理とアプリケーション サポート プロセスをアップデートすることもよくあります。これは問題を解決し、インシデントに対応するうえで役立ちます。
フェーズ 3: 実行
第 3 のフェーズは実行で、考案した計画に従い計画を実現します。実行フェーズでは、実際に行う手順と組み立てた構成によく注意する必要があります。通常は、非本番環境の移行 Wave と本番環境の移行 Wave で同じことを繰り返すからです。
実行フェーズでは、インフラストラクチャ コンポーネント（IAM、ネットワーク、ファイアウォール ルール、サービス アカウント）を実装し、それが正しく構成されていることを確認します。また、インフラストラクチャ構成でアプリケーションをテストし、データベース、ファイル共有、ウェブサーバー、ロードバランサ、Active Directory サーバーなどにアクセスできることも確認します。ロギングとモニタリングを使用して、アプリケーションが求められるパフォーマンスで機能し続けることも確認します。
実行フェーズに成功する秘訣は、アプリケーションのデバッグおよびテストを迅速に進めることです。また移行時に生じる可能性がある問題に対処するための、短期計画と長期計画の両方を用意しておくことも重要です。実行フェーズは反復的に行うべきものであり、その目標は新しいインフラストラクチャでアプリケーションを十分にテストすることです。
フェーズ 4: 最適化
大規模なデータセンター移行プロジェクトの最後の段階は最適化です。ワークロードを Google Cloud に移行した後は、最適化のための見直しとプランニングを定期的に行うことをおすすめします。その際は、さまざまな最適化アクティビティを検討することをおすすめします。
マシンタイプとディスクのサイズ調整 - コストの削減か、パフォーマンスの向上か。Active Assist がこの調整の自動化に役立ちます。
Terraform を利用してデプロイの迅速性と予測可能性を向上
自動化を進めて運用のオーバーヘッドを削減
ロギング、モニタリング、アラートを行うツールを使用してより効果的な統合プロセスを実現
マネージド サービスを導入して運用のオーバーヘッドを削減
従来のデータセンター環境からクラウドに移行すると、リソース消費量と使用量が可視化されます。たとえば Compute Engine の場合、Google Cloud によってコストのオブザーバビリティが向上し、CPU コアと RAM の合計コストが表示されることで、費用が発生しているコンピューティング リソースを容易に識別できるようになります。
また Recommender API を使用して、不要となった仮想マシンやサイズを適正化できる仮想マシンを特定し、必要なパフォーマンスに沿うものにすることができます。コンピューティング オペレーションを削減するには、プリエンプティブル VM というオプションもあります。
あるいは Cloud Storage を使用すると、実際のユースケースに基づいてストレージ クラス（Standard、Nearline、Coldline、Archival）を選択し、ライフサイクルと保持ポリシーを適用することができます。
最初の一歩を踏み出す
データセンターの完全移行は大がかりですが、それに見合う価値が見込めます。移行フレームワークを利用すると、プロセスをステージに分割し、既存のデータセンターを効果的に移行することができます。最後に、私たちが得てきた学びをいくつかご紹介します。
常にアジャイルであること - データセンターの移行には多くの変動要素があります。キーパーソンが参加できなくなると、データセンター移行のタイムラインがリスクにさらされます。
容易な部分を最初に対処する - 構成の誤りを簡単に解消し、足りないインフラストラクチャを特定できる、シンプルなアプリケーションを移行することで、構築における自信を深めていきましょう。最初に大規模かつ特に複雑なアプリケーションの移行を試みることはおすすめできません。
早い段階で関係者に連絡する - 多くのデータセンターには、社内の他のユーザーや組織外のユーザーといった「外部ユーザー」がいます。そうしたユーザーに早い段階で移行を通知し、移行が遅れる原因となる、コンプライアンス上の問題がないかを確認しておきましょう。
チームが Google Cloud について学ぶことをサポートする - テスト用のサンドボックス スペースをプロビジョニングしたり、トレーニングの機会に登録したりすることで、GCP 学習プロセスを構築しましょう。
最初の一歩を踏み出す準備ができたら、Google の発見および評価（無料）を通じたサポートをご利用ください。移行のコストとオプションを見積もり、理解するうえで役立ちます。また、今後のブログ投稿にもご注目ください。より迅速な移行方法を実現する技術的な原理や、大規模な移行プログラムを管理するためのプログラム管理プラクティスの確立方法についてご説明していきます。
-Google Cloud 戦略的クラウド エンジニア Garrett Wong
-Google Cloud プロフェッショナル サービス担当責任者 Dillon Do
