はじめに
GCPだけまだ触れてなかったので、今回は私がプロダクションで運用して感じた、GCP固有の優位性に関して述べていきたいと思います。
なお、留意点として初めに述べておくと、2022年に「Google Cloud Platform」は「Google Cloud」に名称が変更されています。
それに伴って、「GCP」という名称は旧名称となり、現時点での正式名称ではなくなっている点に注意してください。
このシリーズ中で「GCP」と呼んでいるのは、このシリーズ開始時点ではGoogle検索でGoogle Cloudのサービスの調べ物をするときに「GCP」の旧名称を利用したほうが欲しい結果が返ってきていたことが理由です。
2023年11月時点でも学習データの関係上、ChatGPTを用いてなにか確認するときにも「GCP」という旧名称を利用したほうが欲しい結果が得られるはずです。
公式ドキュメント上は反映されているものの、世間的にまだこの名称変更があまり浸透していない印象ですね。
この記事執筆時点では、パートナー企業さんのドキュメントでも新旧の呼び名が混在しています。
なお、呼称に関して、「Google Cloud Platform」 から 「Google Cloud」になったので、呼称も「GCP」 → 「GC」になりそうではありますが、「Google Cloud」のことを「GC」と呼んでいる方を見たことがありません。
私も「GC」と言われたらガーベッジコレクションを先に連想します。
各種公式資料を見る限り、正式名称「Google Cloud」、略称は無しというのが現在の公式見解みたいです。
とはいえシリーズでGCPという名称を最初に利用している関係上、統一性の観点からこの記事でもGCPという旧名称で述べていきます。
GCP固有の優位性
GCPは、基本的にAlphabet(Google)社が自社サービスを提供するうえで利用している技術やインフラを、サービスとして社外の組織や個人にも開放してくれているものです。
そして、Google社はGoogle検索やGmail等の多くのサービスを提供する過程で、AIや大規模分散処理アーキテクチャの開発/運用等の分野で多くの実績を残しており、GAFAMの一社としてテクノロジー業界で非常に大きな影響力を持っています。
GCP固有の優位性に関しては、Googleが提供しているサービスとの連携性と、これまでGoogle社が培ってきた各種領域での知見が大きく影響している印象です。
私が感じているGCP固有の優位性に関しては以下の5つです。
- Google Workspaceとの連携性
- BigQueryを始めとしたAI/データサイエンス系サービスの強さ
- Kubernetesを利用したインフラ構築の(相対的な)容易さ
- Flutter + Firebaseでのアプリ作成の容易さ
- Cloud Runの優秀さ
これらに関して、以下個別に詳細を述べていきます。
1. Google Workspaceとの連携性
10年以上前はオフィススイートといえば「Microsoft Office」が圧倒的シェアを誇っていましたが、近年中小企業を中心にGoogle Workspaceがオフィススイートとしてのシェアを伸ばしてきています。
Google WorkspaceにバンドルされているGmailやGoogle スプレッドシートなどのサービスはGoogleの個人アカウントでも利用できるので、最近だと学生時代から利用されている方も多いかと思います。
GCPはGoogle Workspaceとの非常に連携性が高く、以下のようなBIツールとしての使い方が簡単にできます。
- コネクテッドシートを利用してBigQueryに格納してある大量のデータに対して集計/可視化を行う
- Google Workspace上の各種データをBigQueryに流し、Looker Studioでダッシュボード/レポートとして可視化する
そもそもGoogle Workspaceの情報に外部からアクセスするためには、GCPを経由することが必須なんですよね。
Google Workspaceに対して以下のような操作を行うときにもGCPの利用が必須となります。
- 各種ファイルの共有状況や操作履歴をサードパーティのSIEM、CASBなどのセキュリティソリューションに流す
- Google Workspace上のユーザーアカウントを外部SaaSと連携する
2. BigQueryを始めとしたAI/データサイエンス系サービスの強さ
Google社は従前からAI/データサイエンス領域に積極的に投資を行い続けており、これらの領域でトップランナーとして君臨し続けてきました。
そして、GCPのBigQueryはAI/データサイエンスの領域でデータウェアハウス(DWH)のデファクトスタンダートと言えるレベルで利用されています。
この領域は大量のデータの保存と加工、抽出が必要になってくるのですが、BigQueryを利用した場合、非常に安価かつ高速にこのタスクをこなせることが人気の主な理由かなと思います。
サンプルコードなどでもBigQueryが利用されていることが多く、KaggleのLearningコース中でもBigQueryの利用を前提としています。
GCPの活用が進んでいる企業だと機械学習モデルの開発〜分析〜運用〜改善までの一連の流れ(ML Ops)をVertex AIを利用して実現しているところもあります。
AI/データサイエンス領域の強さから、メインインフラとしてAWSやAzureを利用していても、AI/データサイエンスの領域だけ別途GCPを利用するという使い方をしている企業も結構あるはずです。
もっとも、AI/データサイエンス領域に関しては、Microsoft社がここ数年多額の投資を行って、Azure OpenAI ServiceやAzure AI Studio、Microsoft Fabric等の競争力の高いサービスを提供してきています。
長年Google社はAI/データサイエンス領域に関してトップランナーであり続けたものの、OpenAI社を含むMicrosoft連合の台頭によってやや雲行きが怪しくなって来ましたね。
数年前にGoogle社の研究者によって、現在のLLM発展の基礎となっているTransformerやBERTモデルが生み出されたときには、こんなことになるとは想像もしていませんでした。
3. Kubernetesを利用したインフラ構築の(相対的な)容易さ
最近だとマイクロサービスを構築する際に、Kubernetes(K8s)をコンテナ基盤として選定することは割と無難な選択肢になってきたかなと思います。
(AWSだと運用負荷の低さから移植性を犠牲にしてECS on Fargateを選ぶことも結構あります。)
Kubernetes(K8s)はデプロイやスケーリングを自動化したり、コンテナ化されたアプリケーションを管理したりするための、オープンソースのシステムです。
今はK8sはオープンソース化されているとはいえ、元々Google社が設計/開発したものなので、さすがにK8sはGoogle Kubernetes Engine(GKE)で動かすのが初期構成まで一番簡単ですね。
ダッシュボードも標準装備されてますし、Cluster Autoscalarの設定もダッシュボードから数回のクリックで簡単に行えます。
メガベンチャーでのGKEの採用例も多い関係上、GCP上でKubernetesの運用経験があるSRE/インフラエンジニアに絞った場合であれば、AWSに匹敵する人材層の厚さがある印象です。
書籍やインターネット上の情報もGKEを前提に書かれていることが多く、その情報をなぞるだけでプロダクションレベルのCI/CDパイプラインを構築できたりします。
AWSのElastic Kubernetes Service(EKS)は比較的初期構成の難易度が高いです。
そもそもデータプレーンをEC2にするのかFargateにするのかでも考える必要がありますし、ダッシュボードやCluster Autoscalarは公式を見て自前での対応が必要になります。
AzureのAzure Kubernetes Service(AKS)やAzure Container Apps(ACA)は参考にできる情報が少なすぎて、Microsoft Learnを頼りに手探りで構築する形になります。
そして、AKS、ACAの構築経験のあるSRE/インフラエンジニアは日本の採用市場には皆無といっていいレベルでいません。
そのあたりを鑑みるとGCPはK8sのインフラ構築という面ではわりと優位性があるかなと思います。
Kubernetesを利用したインフラ構築の容易さ : GCP > AWS >>> Azure
4. Flutter + Firebaseでのアプリ作成の容易さ
FlutterはGoogle社が開発したマルチプラットフォームの開発フレームワークです。
Dartというプログラミング言語を使って、シングルコードベースでiOS、Android、Web、およびデスクトップアプリケーションを開発できます。
Flutterもオープンソース化されているとはいえ、Google社のエンジニアが開発に参加していることもあって、GCPとは非常に高い連携性を誇ります。
Firebaseと組み合わせれば、バックエンドサーバーを構築することなく、認証の実装（Firebase Authentication）や複数端末での同一データの操作(Firebase Realtime Database)などが実現できます。
バックエンドをBaaSに寄せることによってDartでのアプリケーション側の開発に集中できるため、これはシード期のベンチャーなど、エンジニアリソースが少ない組織にとっては非常に強い味方となります。
モバイルアプリに対する開発効率の高さから有名企業でもFlutterの利用例が増えています。
Flutterを使うデメリットは、Flutterでの開発経験があるエンジニアを確保する難易度が非常に高いことと、純粋なネイティブアプリよりも基本的には動作パフォーマンスが劣るところですかね。
パフォーマンス問題に関しては、Flutterが悪いというよりはマルチプラットフォームの宿命みたいなものです。
Flutterを利用してネイティブアプリと同等のパフォーマンスを出すこともできますが、それにはFlutterのレンダリングの仕組みとウィジェットの組み合わせへの高い理解が必要になり、結構技術力が要求される印象です。
5. Cloud Runの優秀さ
Cloud Runはコンテナ化されたアプリケーションを簡単にGCP上でデプロイ/実行できるコンピューティングプラットフォームです。
単なるコンテナの実行環境であれば、他のクラウドにも同様のものがあるのですが、Cloud Runは以下の5点を実現しているところが素晴らしいですね。
- プラットフォームによる利用可能言語の制限が無い
- コールドスタート(最小インスタンス数 0)の設定が可能なうえに起動速度も早い
(Startup CPU Boostによりさらなる高速化も可能) - オートスケールが可能なうえにスケーリング速度が非常に早い(約数秒)
- 移植性が高く、後でGKEや他の実行環境に移すことが容易
- デプロイまでの設定が容易
記事執筆時点では、他のクラウドサービスでこれらの要素を4つ以上同時に実現できているものは無い認識です。
トラフィックの上下動が激しいサービスや、月数回の起動時に大量のマシンリソースを消費するバッチ処理などでCloud Runは活躍します。
より高い自由度が必要になればGKEやGCEに移植することも容易です。
最後に
Google社は基本的に自社の技術的な結晶をオープンソース化したり、技術的な知見を論文や書籍で公開してくれる傾向があります。
それらのテクノロジー業界に対する影響や貢献は非常に大きく、私もSREやAI等の多くの分野でGoogle社の公開情報に助けられてきました。
ただその一方で、TransformerやKubernetes等、その公開情報やオープンソース化が競争相手の強化に繋がってしまっているケースがあるのも事実です。
TransformerがOpenAI社のGPTの登場に繋がっていますし、今やGCPのGKE上で動作しているKubernetes Clusterよりも、AWSのEKS上で動作しているKubernetes Clusterの数のほうが多いんじゃないかというレベルでAWS上で利用されています。
GCPを見ていると、公益性と自社の競争優位性を天秤にかけたときに、自社の知見をどれだけオープンに公開していくべきなのかは結構考えさせられる問題だなと思いますね。
私がGCPをプロダクションで実運用して感じた、GCP固有の優位性に関しては以上となります。
バックナンバー