Google の IT チームが Google Cloud サービスを採用

※この投稿は米国時間 2024 年 8 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

Google のエンタープライズ IT チームは、Google を支えるインフラストラクチャの構築とメンテナンスを行っています。当チームの使命は、Google 社員が最高の仕事ができるよう、社員が必要とする、信頼性が高く安全でスケーラブルなインフラストラクチャを提供することです。そしてそのビジョンは、世界をリードする、企業向けテクノロジー ソリューションのプロバイダになることです。

Google 社員のニーズに最大限に応えるには、Google 自身のクラウド インフラストラクチャの規模と運用基準を活用する必要があることはわかっており、そしてこの変革が功を奏しました。移行によって、低価値で低レベルの骨折り作業がなくなり、チームのスキルが向上し、最終的には、より有効なツールを使用してユーザーに付加価値機能を提供できるようになったのは明らかです。

リフト＆シフト（100 を超えるベンダー提供サービスを含む）とそれに続くクラウド モダナイゼーションの取り組みが完了したので、ここまでの道のり、得られたメリット、その過程で明らかになった関連するリスクについて共有したいと思います。

振り返り - クラウドの有効化とリフト＆シフト（2016～2019 年）

チームが Google Cloud に慣れるように簡単な調査とプロトタイピングを行った後、既存の企業インフラストラクチャと企業ワークロードの詳細な評価を手始めに、クラウドへの移行を本格的に始動しました。このとき、他のコンピューティング ランタイムはまだ未熟であったため、このフェーズではリフト＆シフトに重点が置かれました。

当時、Migrate for Compute Engine などの多くのリフト＆シフト ツールはまだ存在しておらず、カタログ化はほぼ手作業で行われました。主な作業は、データソースの検出 / クリーニング / 結合、自社製のスキャン ユーティリティの作成、20 年以上におよぶ仲間内の知識を整理するためのインタビューの実施などで、企業の遺物の整理に尽力しました。

このカタログ化の作業を大規模に実施するために、信頼できる一元的な情報源を維持しながら、サービスチームとインフラストラクチャ チーム間で作業を分担しました。

サービスについては、ユーザー ジャーニーをキュレートしてその主要な特徴とユーザー グループを特定して優先順位を付けるようサービス オーナーに依頼しました。同様に、インフラストラクチャ チームには、テクノロジーに依存しない機能やパフォーマンス仕様の観点からコンポーネントについて説明するよう依頼しました。次に、優先順位を付けたサービスのユーザー ジャーニーを、基盤となるインフラストラクチャ機能にマッピングし、簡単に移行できたサービスと、対応する機能が Google Cloud に存在しないために移行が妨げられたサービスをすばやく特定できるようにしました。

移行の阻害要因については、さらなる調査のために、Google Cloud 組織内の同僚と共有しました。こうした対話に基づいて、特定のシナリオに合わせてアプローチを調整してモダナイズするか、またはプラットフォームに新機能を追加してもらいました。これまでに、このような対話から生まれた新しいエンタープライズ対応機能は 110 を超えています。その一部を挙げると、Identity Aware Proxy、Cloud SQL、NFS ボリューム、IAM 拒否ポリシー、階層型ファイアウォール、Packet Mirroring の作成などがあります。

阻害要因のないサービスから、複雑さの異なる 3 つのサービスを選択してカナリアベースの移行を実施しました。この際、Google Cloud の開発者、カスタマー エンジニア、Google のコーポレート エンジニアリング チームを招待して、実世界のアプリケーションの移行を実際に経験してもらいました。

次に、これらのデプロイの骨の折れる作業部分をすべて評価し、クラウド デプロイを自動化および標準化するためのツールを開発しました。これには、次の大規模なバケットのツールが含まれます。

• ランディング ゾーンの自動化 - Terraform を使用して、カスタマイズ可能で繰り返し可能な、デフォルトでセキュリティ保護されたランディング ゾーンのセットを作成しました。
• 構成マネージャー - ランディング ゾーンのセキュリティ ポスチャーと全般構成の整合性を長期にわたって維持するために、ドリフトの検出と修正のためのツールを作成しました。
• ブリッジ システム - 移行が完了するまでは、企業インフラストラクチャへのブリッジ（企業の DHCP、DNS、認証システム、マシンのインベントリ システムへの接続など）と、まだ移行していないサービスへの接続が必要でした。

阻害要因のないすべてのサービスについては、まず先行ユーザーに行き届いた移行支援を提供することで移行を拡大しました。そして機運を高めてから、セルフサービスに向けてツールやアプローチを整えました。

阻害要因のある移行については、サポート機能がリリースされるとすぐにサービス オーナーに通知して試してもらいました。その後、サービス オーナーは移行を試みて、その過程で Google Cloud に直接フィードバックを提供しました。

2 年間にわたって数十のアプリケーションが Google Cloud に移行されました。その中で最も複雑だったのは、Oracle バックエンドから「SAP on Google Cloud」への移行で、これをきっかけに生まれたのが現在の標準のデプロイ戦略です。

最後に、当初は（ロールの冗長化やクラウド環境でのカスタマイズ性の低下に関する懸念により）移行に対して文化的な抵抗があるのではと心配していましたが、それは杞憂に終わりました。

現状: クラウドのモダナイゼーション（2019～2024 年）

Google Compute Engine エコシステムの成熟とクラウド フットプリントの拡大に伴い、規模の拡大に対応できる手段を探し始めました。

この時点で、他の大企業と同様に、Google のクラウドへの移行は、イネーブルメントからモダナイゼーションへと成熟を遂げていました。つまり、リフト＆シフトの取り組みから、効率性を高めながら機能を追加することに重点を置いた取り組みへと進化していました。

この変化を具体化するために、一歩戻って、エンタープライズ サービスのエンドツーエンドの要件を定義する作業を行いました。

こうして、概して、エンタープライズ ワークロードでは、フロントエンド / UX、接続性、コンピューティング、その他の統合という共通のアーキテクチャ構成要素セットを共有する傾向があることがわかりました。

これは予想外のことではありませんでしたが、興味深いことでした。というのも、何年もの間、Google は他のどの企業も求めていないソリューションや機能を必要とする特別な存在であるという誤った認識が社内に広まっていたからです。

今では、すべての企業は雪の結晶のように特別な存在であると認識するようになりました。つまり、遠くからはすべて同じように見えますが、十分に近づいてみるとそれぞれが異なる固有なものであることがわかります。

それを念頭に置いて、いくつかの要件は、主に Google がクラウドの消費者であると同時にそのプロバイダでもあるという理由から、確かに固有のものであることを認識する必要がありました。

当チームが選択した新しいクラウド プラットフォーム、Google Kubernetes Engine（GKE）により、迅速なスケーラビリティ、反復性、管理性が実現し、Google のエンタープライズ IT 向けの最新型のクラウド エコシステムが構築されました。

次のステップは、上述の構成要素を Google Cloud サービスにマッピングし、Filestore、Cloud SQL、その他の新しいアーキテクチャ要素への依存度を高めることでした。

このプロセスでもやはり、次のような新たな課題が生じました。

• マルチ環境エンタープライズ: GKE が明らかに最適なソリューションとなるワークロード（ほとんどの既製のソフトウェア、ベアメタル VM など）もあれば、GCE が依然として優れたソリューションとなるワークロード（Docker イメージのないワークロードなど）もあります。また、従来のデータセンター フットプリントは依然として必要で、他のユースケースにも使用されています。
  つまり、ボリュームと需要プールが絶えず変化するマルチ環境エンタープライズを運営していることになります。
• 新たなギャップ: GKE に焦点を移すにつれて、新たなギャップが見つかりました。これらのギャップの一部は、成熟した GCE プラットフォームではすでに解決されており、新興のプラットフォームに合わせて再調整する必要がありました。
• 先行ユーザー: 多くの場合、Google はカスタマー ゼロ、つまり新しい機能セットやプロダクトを使用する最初の企業でした。そのため、初期段階の問題があり、パフォーマンスは最適ではありませんでしたが、Google Cloud を優れたエンタープライズ プラットフォームにする最終プロダクトの形成に貢献できることにもなりました。

今後の展望: スケーリング、ガバナンス、最適化

クラウド移行のゴールとはどのようなものでしょうか。既存のアプリケーションをリフト＆シフトしてリプラットフォームするだけで十分でしょうか。最後のオンプレミス アプリケーションをクラウドに移行すれば満足かもしれませんが、それは移行の始まりに過ぎません。クラウド テクノロジーによって、IT インフラストラクチャの継続的な改善ループを可能にして改善を加速することをおすすめします。経験に基づいてクラウドへのベースラインを再設定することで、次の項目にわたって革新を続けることができました。

• 構成管理
• ガバナンス、チェンジ マネジメント、ポリシー
• セキュリティ
• 運用
• チェンジ マネジメント

この変革により、エコシステムがモダナイズされ、Google のクラウド エコシステムのスケール メリットを享受できるようになりましたが、同時に、次のような新たな企業の課題、リスク、緩和戦略がもたらされました。

企業のガバナンス:

新しいテクノロジーの導入は最初のステップにすぎません。企業は、ユーザーがテクノロジーを安全かつ効率的に使用できるようにする必要があります。この目標を達成するには、（少なくともアジャイルな組織では）テクノロジー主導のガードレールと文化的なシフトの両方が必要になり、一筋縄ではいきません。

また、文化的な問題も浮上します。ユーザーによるテクノロジーの使用について妥協せずに、組織内で主体性を維持するにはどうすればよいでしょうか。

私たちが学んだことの一つは、命令は機能しないということです。人は、なぜそうすべきかを理解していないのに、すべきことを指示されるのは嫌がるものです。つまり、独断的なガードレールはどのような種類であっても、ユーザーに真のメリットをもたらす必要があります。私たちは、セキュリティ事前承認済み使用パターンの形でこれを実現しました。これにより、ユーザーは、長くかかるセキュリティ審査プロセスを経ることなく、事前に定義されたアーキテクチャ ブループリントに従ってワークロードを立ち上げることができます。共生できる十分に明るい経路を構築することで、誰もが利益を得られます。ユーザーは新しいワークロードへの道のりが楽になり、組織はトイルやリスクを軽減できます。

マルチ フットプリントの最適化の問題

新しいテクノロジーの阻害要因を排除すると、「成功による障害」を生み出すリスクも高まります。つまり、新しいテクノロジー、特に新しいプラットフォームを取り入れると、費用とトイルが増加します。これは最適化の問題に直結します。プラットフォームを完全に管理したい場合、管理するプラットフォームが管理不能になるまでに、いくつの異なる要素を含めることができるでしょうか。この技術面に関して続く論争では、技術的収束が重要な要素になります。（前述した技術的ガバナンスとともに）最小限のプラットフォーム セットに収束すると、短期から中期的には費用がかさみますが、長期的には最小限のトイルで済む無駄のない技術スタックになります。

ここまでとてもワクワクする道のりでしたが、今後も Google Cloud の強力な機能を活用して、引き続きエンタープライズ IT に革命を起こしていきたいと考えています。Google のエンタープライズ IT チームが Google で情報技術（IT）をどのように運用しているか、またどのように規模を拡大し、未来の働き方に適応させているかについて詳しくは、コーポレート エンジニアリングの分析情報ページをご覧ください。

ー テクニカル プログラム管理担当ディレクター Philippe-Joseph Arida

ー エンジニアリング リード Lior Tishbi