Google Cloud の概要

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

あなたがインターネットにアクセス可能なアプリケーションである foo.com の Google Cloud アーキテクトであると想像してみてください。Google Cloud 上でこのようなアプリケーションを構築するには、さまざまな方法があり、どの方法が正しいとか間違っているということはありません。ユーザーがブラウザを開き、アドレスバーに foo.com と入力したときの一般的なリクエスト フローの観点から、ある一つのアプローチについて考えてみます。

ドメイン ネーム システム（DNS） 

このリクエストは DNS サーバーに送られ、IP アドレスで返信されます。Cloud DNS は、Google が提供する大容量の権威 DNS サービスのためのインフラストラクチャで、100% の SLA を提供します（つまり、絶対にダウンしないことを意味します）。Google のグローバル ネットワークであるエニーキャスト ネームサーバーを使って、世界中の冗長な場所から DNS ゾーンを提供し、高可用性と低レイテンシをユーザーに提供します。

ウェブサーバーとアプリケーション サーバー 

ウェブサーバーとアプリケーション サーバーについては、Cloud Run、App Engine、GKE、Compute Engine の中から複数のオプションを選択できます。詳しくは、こちらのブログ投稿をご覧ください。

• サーバーレス: デベロッパーのチームがいますが、インフラストラクチャやスケーリング タスクを気にすることなく、コーディングに集中させたいと考えます。そうすると Cloud Run や App Engine が最適な選択になります。どちらもサーバーレスで、低トラフィックから高トラフィックまで必要に応じてスケーリングできます。ウェブやイベント ドリブンのマイクロサービス アーキテクチャを提供するサーバーレス コンテナを実行したい場合は、Cloud Run がおすすめです。Cloud Run はほとんどのユースケースに対応できます。静的ファイル ホスティングを組み込んだウェブサイトを開発する場合は、App Engine をチェックしてください。

• Google Kubernetes Engine（GKE）: より多くの構成オプションと柔軟性でコンテナ化されたアプリケーションを実行したい場合は、GKE を使用できます。Kubernetes を使用してコンテナ化されたアプリケーションを簡単にデプロイでき、ノードの構成を制御できます。  また、スケーリングも簡単で、トラフィックの増加に合わせてスケールするノード数を定義できます。GKE では、柔軟性と制御性を必要としながらも、オペレーションやエンジニアリングのサポートが限られている場合に、Autopilot を利用できます。

• Compute Engine: もう一つの最大制御のオプションは Compute Engine です。ストレートな仮想マシン（VM）なので、必要なメモリや CPU の量に応じて、マシンの構成を正確に定義できます。しかし、このレベルの制御は、必要に応じて VM を拡張、管理、パッチ適用、保守する責任がより大きくなることを意味します。Compute Engine は、特定のニーズを持つ以前のアプリケーションや、本当に完全な制御が必要な状況に適しています。

データベース 

当然ながら、foo.com は情報を保存するために 1 つ以上のデータベースを必要とします。データの種類やユースケースに応じて、リレーショナル データベースや非リレーショナル データベースを使用できます。（ユースケースに適したデータベースの選択に関するより詳細なガイダンスは、Google Cloud のデータベース オプションについての説明）をご覧ください。

Google Cloud のリレーショナル データベースには、Cloud SQL と Cloud Spanner があり、いずれもマネージド型です。

• Cloud SQL は、MySQL、PostgreSQL、SQL サーバーなど、一般的な SQL のニーズに最適です。

• Spanner は、水平方向のスケーラビリティを必要とする大規模なリレーショナル データベースに最適です。（ここでいう大規模とは、ACID トランザクションをサポートしながら、1 秒間に数千回の書き込みと数万回の読み取りを行うことを意味します。）

非リレーショナル データベースの場合、Google Cloud には Firestore、Bigtable、Memorystore という 3 つの主要なオプションがあります。

• Firestore は、強整合性を提供し、ACID トランザクションをサポートし、複雑なクエリに対して高速な結果を提供するサーバーレス文書データベースです。また、オフライン データや同期にも対応しており、ウェブ、IoT、ゲームと並んでモバイルのユースケースに最適なプロダクトとなっています。

• Bigtable は、極めて低いレイテンシで重い読み書きをサポートするワイドカラム型 NoSQL データベースです。そのため、イベント、IoT デバイスからの時系列データ、クリック ストリーム データ、広告イベント、不正検出、最適化案、その他パーソナライゼーション関連のユースケースに最適なプロダクトとなっています。

• Memorystore は、Redis と Memcached のためのフルマネージド インメモリ データストア サービスです。一時ストアやデータベース キャッシュに最適です。

ロード バランシングとスケーリング

トラフィックが増加すると、それに合わせてウェブサーバーやアプリケーション サーバーをスケーリングする必要があります。また、サーバーの台数が増えてくると、ウェブサーバーやアプリケーション サーバーへのトラフィックをルーティングするためのロードバランサが必要になります。Cloud Load Balancing は、エニーキャスト IP アドレスに基づく完全分散型のソフトウェア定義システムで、単一の IP アドレスでフロントエンドを設定できます。また、グローバルにデプロイしているため、ユーザーのできるだけ近くにコンテンツを提供でき、100 万以上の秒間クエリ数に対応できます。  HTTP ヘッダーや一意のリソース識別子などの属性に基づいて、コンテンツベースのルーティング判定を設定できます。また、社内のアプリケーション サーバーのロード バランシング機能も備えており、必要に応じてサーバー間のトラフィックをルーティングできます。

コンテンツ配信ネットワーク（CDN）

静的ファイルは頻繁に変更されないので、CDN を使用してこれらのファイルをキャッシュに保存し、ユーザーに最も近いロケーションから提供することで、レイテンシを低減できます。ロードバランサでは、Cloud CDN を有効にして、頻繁にリクエストされるメディアやウェブ コンテンツをユーザーに最も近いエッジ ロケーションにキャッシュするオプションも用意されています。これにより、レイテンシを低減し、ラスト ワンマイル パフォーマンスを最適化できます。また、バックエンドで処理する必要がないため、エッジでリクエストを処理することでコストを削減できます。   

オブジェクト ストア 

メディア ファイルやイメージ、CSS や JavaScript など、foo.com のすべての静的ファイルをオブジェクト ストアに格納できます。Google Cloud では、Cloud Storage が長期および短期のストレージ ニーズに対応するオブジェクト ストアとなります。

サーバーレス機能 

例えば、foo.com はモバイル デバイスでも利用可能で、モバイル デバイスではより小さなフォーマットでレンダリングされた画像が必要とされるとします。このような機能をウェブサーバーから切り離し、Cloud Functions で Functions as a Service として利用できます。この方法により、画像サイズ変更ロジックを他のアプリケーションにも適用できます。Cloud Storage にファイルが追加されると同時にサーバーレス機能を起動し、ファイルを複数のフォーマットに変換してストレージに格納し、ウェブサーバーで使用できます。また、アドレス検索やチャットボット、機械学習など、他のユースケースでもサーバーレス機能を利用できます。

イベント

ある状況下では、foo.com はさまざまなマイクロサービス間でメッセージ、ユーザーへの通知、またはイベントを送信する必要があるかもしれません。そこで、Cloud Pub / Sub のような非同期メッセージ サービスを使って、トピックに通知を push し、他のサービスがトピックを登録してそれに対して適切なアクションを非同期で行うことができます。

データ分析

foo.com のようなアプリケーションでは、リアルタイム データ（クリックストリーム データ）とバッチデータ（ログ）が生成されます。このデータを取り込み、処理し、データ ウェアハウスでダウンストリーム システムのために準備する必要があります。そこから、データ アナリスト、データ サイエンティスト、ML エンジニアがさらに分析し、分析情報を得て予測を立てることができます。Cloud Storage や BigQuery からのバッチデータ、Pub / Sub を使ったアプリケーションからのリアルタイム データの取り込みが可能で、1 秒あたり数百万のイベントの取り込みまでスケールアップが可能です。オープンソースの Apache Beam をベースとした Dataflow を使って、バッチデータやストリーミング データを処理し、拡充できます。Hadoop のエコシステムを利用している場合、Dataproc を使って処理できます。マネージド Hadoop と Spark プラットフォームで、Hadoop クラスタの管理や立ち上げを気にすることなく、分析に集中できます。

処理したデータを保存するには、データ ウェアハウスが必要です。BigQuery は、SQL クエリをサポートし、ペタバイト級のストレージにスケーリング可能なサーバーレス データ ウェアハウスです。また、Cloud Storage とともに、長期保存やデータレイクとしての役割も果たすことができます。BigQuery のデータを使って、Looker やデータポータルでダッシュボードを作成できます。BigQuery ML では、標準的な SQL クエリを使用して ML モデルを作成し、予測を行うことができます。

機械学習

ML / AI プロジェクトでは、BigQuery のデータを使って Vertex AI でモデルを学習させることができます。Cloud Storage からメディア、イメージ、その他の静的ファイルのデータセットを直接 Vertex AI にインポートできます。独自のカスタムモデルを作成することも、事前に学習させたモデルを使用することも可能です。まずは学習済みのモデルから始めて、自分に合うかどうかを確認するのが賢明です。ほとんどの一般的なユースケースをカバーしています（画像、テキスト、動画、表形式データが含まれます）。事前に学習させたモデルが用途に合わない場合は、Vertex AI の AutoML モデルを使って、ご自身のデータセットでカスタムモデルを学習させてください。AutoML は、一般的なユースケースをすべてサポートしており、コードは必要ありません。ML やデータ サイエンスに関する専門知識をたくさん持っている場合は、選択したフレームワークで独自のカスタムモデル コードを書くこともできます。これについては、次回の投稿で詳しく説明します。

運用

foo.com は、サーバーやアーキテクチャのあらゆる部分が健全であることを確認するために、全体的なモニタリングが必要です。Google Cloud のオペレーション スイートは、アプリケーションやインフラストラクチャのロギング、モニタリング、デバッグ、トラブルシューティングに必要なすべてのツールを提供します。

DevOps 

また、foo.com の開発チームと運用チームが、アプリケーションを構築してデプロイするために、適切なアクセスと適切なツールを備えていることを確認する必要があります。デベロッパーはアプリのコードを書くと、IDE 内の Cloud Code を使って Cloud Build にコードを push できます。Cloud Build はコードをパッケージ化してテストし、コードに対して脆弱性スキャンを実行し、Binary Authorization を呼び出して信頼できるコンテナ イメージをチェックし、テストを追加した後で、パッケージをステージングにデプロイします。そこから、レビューや本番環境へのプロモーションのプロセスを作成できます。コンテナ イメージは Artifact Registry に保存され、ここから GKE や Cloud Run にデプロイできます。Compute Engine イメージは、プロジェクトに保存されます。

セキュリティ

foo.com は、データ、アプリケーション、ユーザー / ID、インフラストラクチャ、そしてコンプライアンスの各レベルでセキュリティを確保する必要があります。このトピックは、次回の投稿で詳しく紹介します。

まとめ 

foo.com のようなウェブ アプリケーションを Google Cloud 上に構築する 1 つの方法をご紹介しました。スタート地点に立ったわけですから、ここからの可能性は無限大です。Google Cloud を利用したウェブサイトの構築を始めてみませんか？以下のリソースをご確認ください。#GCPSketchnote や同様の Cloud コンテンツの詳細については、Twitter で @pvergadia をフォローしてください。thecloudgirl.dev もぜひご覧ください。