Google Cloudによるハイブリッド/マルチクラウド構築の課題とチャンス
Google Cloudを活用したハイブリッド/マルチクラウドを採用する企業が増えています。スタートアップは顧客のいる環境に合わせてサービスを届けることで顧客基盤を広げ、大企業は課題解決に最適なツールの選定、高可用性の実現、ベンダー分散によるリスク低減を目的に導入を進めています。ハイブリッド/マルチクラウドの構築（多くの場合、より大きなアプリケーションモダナイゼーションの一環として行われます）に着手する前に、想定される課題とチャンスを押さえておくことが重要です。
本記事では、こうした論点を掘り下げ、どのような企業が向いているのか、押さえておくべき課題、利用できるソリューション、そして（少なくとも当面は）この選択肢を避けたほうがよいケースについて解説します。
用語の定義
まずは用語の定義から始めましょう。
- パブリッククラウド – オンデマンドのコンピューティングサービスとインフラをサードパーティのプロバイダーが管理し、パブリックインターネット経由で複数の組織が共有して利用する形態
- プライベートクラウド – 単一の利用組織専用に構築されたインフラ。自社データセンターまたはサードパーティのコロケーション施設にホスティングされる
- ハイブリッドクラウド – オンプレミス、プライベートクラウド、サードパーティのパブリッククラウドを組み合わせ、各プラットフォームを横断してオーケストレーションする形態
- マルチクラウド – 複数のクラウドコンピューティング/ストレージサービスを単一の異種アーキテクチャに組み合わせる形態。クラウド資産、ソフトウェア、アプリケーションなどを複数のクラウドホスティング環境に分散配置することも含む
- レガシーアプリケーション – 古い技術をベースとしている可能性があるものの、日々の業務に欠かせない情報システム。多くは3層構造のモノリシックアプリケーションで、脆弱で保守やアップグレードが難しいもの
- モダンアプリケーション – 一般に、N層アーキテクチャ上のマイクロサービスで構成されるアプリを指す。必要十分な信頼性を備え、本番環境に影響を与えずに1日に何度でもアップグレードできるもの（より広い定義はThe Twelve Factor appを参照）。
ユースケース
すべてを網羅したリストではありませんが、代表的なものを紹介します。
- クラウド移行の難易度がそれほど高くないITインフラを段階的に移行するケース：例えば、オンプレミスに大量のサーバー（多くはLinuxまたはWindows）を保有する顧客が、VPNやインターコネクトで接続を確立し、（アプリケーションのworkload境界に応じて分けた）VMグループを順次クラウドへ移行します。すべてのworkloadsがパブリッククラウドへ移行されるまでの間、一部のアプリケーションをオンプレミスで、残りをクラウドで稼働させるハイブリッドクラウドで顧客にサービスを提供します（ハイブリッドクラウド）。
- ソリューションをモダナイズしたいが、クラウド移行が極めて困難なアプリケーションやデータベースを抱えているケース：例えば、プライベートクラウド環境にメインフレームやOracle DB（最近は以前ほど難しくはありません）を持つ顧客が、アプリケーションをKubernetesのようなモダンなアーキテクチャへ移行したい場合（ハイブリッドクラウド）。
- 規制要件への対応：例えばデータの所在地に関する規制により、特定の情報を国外に持ち出せないケースなどがあります。
- クラウドバースティング：オンプレミス環境が逼迫した際に、追加のキャパシティをクラウドへ自動的にプロビジョニングしてスケールアウトします。小売業のブラックフライデー/サイバーマンデーのような場面で活用されます（ハイブリッドクラウド）。
- 高可用性とディザスターリカバリ（ハイブリッドクラウドおよびマルチクラウド）
- 用途ごとに最適なクラウドを使い分ける：例えば、Kubernetesやデータ分析の基盤はGoogle Cloud Platform（GCP）に、Microsoft系のアプリケーションはAzureに置くといった構成です。
- ベンダーロックインの回避
技術スタックと求められるケイパビリティ
続いて、用意あるいは構築すべき技術スタックとケイパビリティ、そしてそれが各フェーズの企業に突きつける課題を見ていきましょう。
コンピュート：
- プライベートクラウド環境の理解 – VMやハイパーバイザーレベルのさまざまな技術：現在プライベートクラウドを利用している企業であれば、これは当然問題になりません。一方、デジタルネイティブ企業で、プライベートクラウドにクラウドソリューションを導入する際の技術スタックや社内調整を経験したことがない場合、これは大きなハードルとなり得ます。
- パブリッククラウド環境の理解：デジタルネイティブ企業には問題になりませんが、現在オンプレミスで運用している企業にとっては、セキュリティや社内調整の面で大きな課題となり得ます。VM管理やオートスケーリングなど、新しいスタックと運用の作法を学ぶ必要があります。
データベースとストレージ：
- 現在プライベートクラウドを使っている企業にとっての課題は、適切なクラウドネイティブのデータベースを選定し、習得することです。マネージドのSQL Server/PostgreSQL/MySQLへの移行は手軽な選択肢ですが、ビジネス上・技術上の目標によってはSpanner、BigTable、BigQueryのような技術へ移行したい/する必要があるケースもあり、この場合は難易度が上がります。
- 2つの技術スタックを並行運用するのは大変です：オンプレミスのOracleデータベースを使うアプリケーションをPostgreSQL Databaseへ移したい企業には、複雑性と利用中の機能に応じて2つの選択肢があります。1つ目は、まずベアメタル環境へリフト＆シフトしてからモダナイズする方法。もう1つは、オンプレミスに残したままプライベートクラウド上でモダナイズし、その後クラウドへ移行する方法です。いずれの場合も、モダナイズが完了して片方のDBを停止できるようになるまで、企業は2種類のDBを同時に運用しなければなりません。
ネットワーキング：
- パブリッククラウドとプライベートクラウドではネットワーキングに大きな違いがあり、クラウド間でも仕様は異なります。例えばGoogle CloudのGlobal VPCは、ネットワーク構成を大きくシンプルにできる強力な仕組みです。プライベートクラウド出身の多くの企業は、こうした仕組みを学ぶ必要があります。また、プライベートクラウドのやり方をパブリッククラウドにそのまま持ち込まないと意識的に判断するのも、なかなか難しいものです。
- VPN、パートナーインターコネクト、インターコネクトのセットアップは、ケースによっては簡単ですが、顧客のプライベートクラウドの所在地次第で数週間から数か月かかることもあります。
セキュリティ：
- ハイブリッド/マルチクラウド環境全体で、本番運用に耐える統一されたセキュリティ対策を実装するのは一筋縄ではいきません。クラウドベンダーごとにセキュリティの仕組みも実装方法も異なるためです。デプロイ時にソフトウェアを展開し、脆弱性をテストする方法を整備するだけでも、ひとつのプロジェクトになり得ます。
- 複数クラウドにまたがるセキュリティ監視システムの構築も難所のひとつです。
CI/CD：
- インフラ（IAC – TerraformやPulumiなど）とアプリケーションの両方を、複数の環境に対してビルド・テスト・セキュリティ確認・デプロイできる継続的インテグレーション/継続的デプロイメント（CI/CD）パイプラインを安定して構築することは、非常に大きな挑戦です。高度なエンジニアリングチームと洗練されたツールチェーンが欠かせません。
モダナイゼーション：
- アプリケーションやDBを「何を」「どう」モダナイズするか決めるのは簡単ではなく、相応のアセスメントと計画フェーズが必要です。プライベートクラウド出身の顧客がK8sと最適な運用手法を習得するには、数か月から数年、さらには大規模な組織変革マネジメントが伴うこともあります。
認証：
- SSOフェデレーションやADフェデレーションなどを、複数プラットフォームにまたがって単一の信頼できる情報源で扱うことが課題となります。
チーム：
- 複数プラットフォームに精通したEngineers/アーキテクトを採用するのは難しいため、チームの育成への投資が欠かせません。
- もう一つの道は、変化の速いクラウドの世界で複数環境のキャッチアップを続けながら、異なるスキルセットを持つチームを別々に編成し、それらが効率よく連携するための業務プロセスを設計することです。
コスト：
- マルチリージョン・高可用性（HA）構成の構築と同様に、マルチクラウドやハイブリッドクラウドの構築コストは最大で10倍になることもあります。単にVMやデータベースをもう1セット用意して追加料金を払うという話ではなく、オーケストレーション、レプリケーション、ネットワーク下り（egress）コスト、それらを支える人やプロセスのサポートまで含めたDay 2運用が積み重なるためです。
- FinOpsの観点から、各チームが自分たちのクラウドコストを管理し、誰もがクラウド利用にオーナーシップを持ち、中央のベストプラクティスチームが支援を提供し、ハイブリッド/マルチクラウドのコストを360°で可視化できる文化を育てることが求められます。
ソリューションを描く
ここまで読むと、マルチクラウドやハイブリッドクラウドはやはり難しいと感じるかもしれません。それでも業界全体がこの方向に進んでいる以上、解を見つける必要があります。
こうしたプロジェクトには時間がかかると理解した上で、次の進め方で取り組むのがおすすめです。
- 自社の企業文化、DevOpsプラクティス、技術スタックなどをアセスメントする。
- 自社のビジネスおよび技術上の目標とアセスメント結果に基づいて計画を立てる。システムへの変更には、社内・顧客の双方に大きな学習曲線が伴うことを念頭に置きましょう。時間がかかる前提で、新しい働き方や技術に人々が適応できる余裕を確保する必要があります。
- 移行/リファクタリング：小さく、ゆっくり始めましょう。早めに失敗し、そこから学んで改善できる余地を残します。ゆっくり始めれば、スピードは段階的に上がっていきます。プラットフォームやコードベースを変更しながら同時に最適化まで狙わないことが肝心です。
- 初期の変更が完了し、新しいシステムが稼働し始めてから最適化に取り組みます。パフォーマンスとコストの両面から最適化を進めましょう。
最適なハイブリッド技術スタックを組み立てる
市場にあるどの技術ソリューションも、単独ですべてを解決してくれるわけではありません。自社のスタックを評価し、複数のソリューションを組み合わせて、完成度の高いハイブリッド技術スタックを作り上げる必要があります。
アプリケーション層：
GCP Anthosは、ソリューションのコード/アプリケーション層の運用に必要な要素を幅広くカバーする強力な選択肢です。以下の各レイヤーが用意されており、GCP、AWS、Azure、プライベートクラウド、ベアメタル上でKubernetesクラスターやVM（プライベートプレビュー段階）をオーケストレーションして実行できます。
Google Cloud Anthos アプリケーション層
スタックの最下層に位置するマネージドKubernetes層であるAnthos clustersは、自前でオープンソースのKubernetesクラスターを運用する場合に比べ、Day 2運用を大幅に楽にしてくれます。
Anthos Ingressは、GKEクラスター向けのクラウドホスト型マルチクラスターIngressコントローラーです。
Anthos Service Meshは、オンプレミスまたはGoogle Cloud上で信頼性の高いサービスメッシュを監視・管理するためのツール群です。
Anthos Config Managementは、Policy Controller、Config Sync、Config Controllerの3つのコンポーネントを組み合わせた構成・ポリシー管理サービスです。これらが連携することで、Google CloudおよびKubernetesリソースを継続的に保護・構成できます。
Anthos fleets（旧称：environs）は、クラスターやその他のリソースを論理的にまとめるためのGoogle Cloudの概念で、マルチクラスター機能を活用・管理し、システム全体に一貫したポリシーを適用できるようにします。
制約事項：このサービスで制御・監視できるのは、Anthos環境内で稼働している部分に限られる点に注意が必要です。
データベース・ストレージ層：
- クラスターの外側で独自にストレージやDB層を運用する場合は、CloudSQLやRDSのようなマネージドDBサービスを活用できる可能性があります。
- Kubernetesクラスター内でDB（mySQLやMongoDBなど）を運用する場合、クラウドプロバイダーのマネージド版を使う場合と比べて運用上のオーバーヘッドが大きくなります。
セキュリティ＋監視：
- SIEM＋監視：Splunk、Datadog、PagerDutyなど、マルチクラウド/ハイブリッドクラウドに対応したツールを選びましょう。
- セキュリティ＆シークレット管理：HashiCorp VaultやAWS Secrets Managerが代表例です。
CI/CD：
- 市場にあるGitlabやJenkinsなどのソリューションは、複数の環境にまたがって動作し、コンテナとVMの両方をビルド・デプロイできます。
VMのビルドとデプロイが不要であれば、spinnakerも選択肢になります。
インフラのプロビジョニング：
- HashiCorp Terraform、Red Hat Ansible、Pulumiなどが選択肢として挙げられます。
まとめ：
- ハイブリッド/マルチクラウドの構築は、人とプロセスの面でも技術の面でも、非常に難しくコストも高くつきます。
- GCP Anthosのような技術はマルチクラウドを支えてくれますが、エンドツーエンドで完結するソリューションは存在しません。アーキテクチャ設計時にはこの点を踏まえる必要があります。
- すでに本番環境でKubernetesを大規模に運用している企業（オンプレミスかクラウドかを問わず）にとっては、このプロセスは比較的進めやすくなります。
- 逆に、最も難航しがちなのは以下のケースです：
オンプレミスでレガシーなモノリシックアプリケーションを運用している企業。ハイブリッド構成の構築と、それに伴う業務プロセス、人材育成、技術スタックの変革には、変化の複雑さや規模に応じて2年から10年程度かかることもあります。
市場はこの方向へ進んでおり、このプロセスを完遂した企業は大きなROIを得ています。とはいえ、こうした取り組みに踏み出す際は、課題の大きさを踏まえて期待値を現実的に調整しておくべきです。
少人数チームのスタートアップ：Kubernetesは魅力的で、あらゆる環境のすべての顧客にサービスを届けたくなりますが、リソースには限りがあり、運用とコストのオーバーヘッドを最小限に抑えながら、しっかり動くプロダクトを作る必要があります。こうした制約を踏まえると、まずは（workloadのポータビリティを意識しつつ）フルマネージドサービスを最大限活用し、単一クラウド上で実用的なプロダクトと顧客基盤を確立することに集中するのが得策です。チームが十分な規模になり、ソリューションが安定してから、マルチクラウドへのリファクタリングと運用を検討しましょう。
このテーマをさらに深く知りたい方、Anthosがマルチクラウド環境でどのように動くかのデモをご覧になりたい方は、2022年2月22日午後1時（GMT）開催のイベントにぜひお申し込みください。
ご質問やハイブリッド/マルチクラウド環境におけるモダンアプリケーションへの取り組みについてのご相談は、お気軽にお問い合わせください。