Cloud Run と Cloud Spanner を利用したモダンなサーバー構成

こんにちは。クラウドエースの松本です。
サーバーの運用には、どうしても予定にない突発的なトラブルやメンテナンスなどの工数が発生してしまうことが多いものです。

複数環境の構築作業
複雑なデプロイ
セキュリティパッチ当てによる夜間メンテ
スパイクによる緊急対応
データベース最適化

などなど。

しかし、現場ではこういった作業に専属のエンジニアを配置できないケースを多く目にします。
なんとか2~3名程度のバックエンドエンジニアをの工数を工面し解決に当たっても、通常業務と並行で行う上、慣れていない作業に想定以上の工数が発生することが度々あります。

そんな問題を Cloud Run や Cloud Spanner を利用することでどのように解決することが出来るのか、みていきましょう。

Cloud Run とは

Cloud Runはコンテナ化されたアプリケーションをデプロイ・スケーリング可能なサーバレスコンピューティングプロダクトです。
様々なメリットがありますが、特筆すべき点は以下になります。

デプロイされたサービスは Google 管理となり、リージョン単位で複数ゾーンに複製されるので、冗長性を担保できる。
100ミリ秒単位の課金でトラフィックに応じてゼロから1000まで自動的にスケールし、トラフィックが少なければ無料枠におさまる。

Cloud Run はコンテナ単位で制御が行える Container as a Service (CaaS) に分類されますが、
CaaS と PaaS の両方の側面を併せ持つインフラサービスだと筆者は考えています。

※CaaS と PaaS の違いについては下記記事をご覧くださいCaaSとは. 意味や主要サービスを5分でわかりやすく解説

Google Kubernetes Engine (GKE) などの CaaS はユーザーが自前で DockerFile を用意し、コンテナイメージ化する作業が必要であるため、 Docker に慣れていないユーザーにとっては、少し難易度が高いものでした。

Google App Engine (GAE) などの PaaS はソースコードを用意するだけで、アプリケーションを簡単に公開・運用できますが、サードパーティやライブラリの制限など、自由度が低く融通が利かない面があります。

Cloud Run ではソースコードからのデプロイ機能により、DockerFile を用意せずともデプロイが可能となります。

「コンテナの拡張性」「デプロイの用意さ」を兼ね備えた Cloud Run は、CaaS と PaaS のハイブリッドな位置付けのプロダクトと言えるでしょう。

ソースコードからコンテナを作成

Cloud Run はデプロイコマンドに –source オプションを指定するだけで、
ソースコードからプログラミング言語を検出し、コンテナイメージ化したものを
Artifact Registry と呼ばれるコンテナレジストリへと Push してくれます。

# ソースコードディレクトリ
$ cd path/to/your/app

# 「myapp」というサービス名と --source オプションを指定し、ワンライナーでデプロイ
$ gcloud run deploy myapp --source=.

https://myapp-<PROJECT_ID_HASH>-an.a.run.app

デプロイが完了すると、上記のような一意の URL が発行されアクセスが可能になります。

ここまでの手順で Dockerfile は作成していませんし、PaaSの特徴である「ソースコードを用意するだけで、アプリケーションを簡単に公開」ができました。

これが、CaaS と PaaS のハイブリットと言える所以です。

Cloud Spanner とは

一言で表現すると MySQL などの「RDB構造」と、非 RDB の NoSQL が持つ「水平方向のスケーラビリティ」両方の特性と良さを持つデータベースです

Google Cloud のデータベース群では RDB に位置付けされます。
テーブルスキーマ、ACID トランザクション、SQL（ANSI 2011）をサポートしており、
MySQ L等の DB エンジンを触ったことがある方であれば、見慣れた構文になります。

また、業界最高水準の SLA を提供しており、
リージョナル 99.99% / マルチリージョン 99.999% となっています。

従来のデータベースは、セキュリティパッチ当てや最適化のために夜間メンテナンスを定期的に行う必要があり、運用中にデータが肥大化していくとデータベースを分割（シャーディング）して負荷を軽減するという対応が必要になることがありましたが、Cloud Spanner はフルマネージドサービスのため、それらの作業は必要ありません。また、ダウンタイムが発生することもありません。

	従来データベース	Cloud Spanner
メンテナンス	✕ 夜間作業等でメンテナンスによる停止	◯ Google管理のため不要
高負荷時の対応（スパイク対応等）	✕ スケールアップによる停止	◯ 無停止のスケールアウト
データベース最適化（インデックス再構築等）	✕ 手動実施	◯ 自動最適化
データベース分割（シャーディング）	✕ アプリ改修やスキーマ再設計	◯ 自動シャーディング
学習コスト	◯ 開発経験やナレッジが豊富	△ 基本はリレーショナルモデルだが、キー設計などSpannerの特性を理解して設計する必要がある

開発環境料金

開発中はアクセスが少ない為、ほとんどの場合 Cloud Run の無料枠内でご利用頂けます。
Cloud Spanner は最小インスタンスで1万円前後となります。

さらに費用を抑えたい場合は、Cloud Spanner エミュレータを使用しても良いでしょう。

Google Cloud を活用した WordPress らくらくパッケージ

ここまで Cloud Run と Cloud Spanner を紹介してきましたが、弊社クラウドエースでは、Wordpress をご利用予定のお客様向けに『Google Cloud を活用した WordPress らくらくパッケージ』 をご用意しております。

本パッケージは WordPress に特化した内容であるため、低価格かつスピーディーな提供が可能となっております。

パッケージに含まれるもの

現行インフラの TCO の可視化

現在のインフラから移行する際の費用対効果を明確にします。

基本設計書 IAM 設計書 / 物理構成図のドキュメント作成

作成されず、引き継ぎがスムーズにいかないことが多いです。
新規参画メンバーのためにも Cloud Ace がキッチリ作成します。

プロダクトトレーニング

運用自動化に向けて、Cloud Run / Spanner に特化した、
勘所や注意点を含めたハイレベルトレーニングを実施します。

Terraform コードの提供

module 化された Terraform コードのサンプルを提供します。

技術アドバイザー / 開発協力

実装上の問題にお答えします。一緒に悩みます。
またご要望によっては準委任契約による開発協力も視野に入れています。

Cloud Storageとは
Google Cloud のオブジェクトストレージである Google Cloud Storage (以降 GCS)のことを指します。
GCSは、保存できるデータ量に制限はなく、必要に応じてデータを取得でき、高いセキュリティと冗長性を誇り、ユーザーは API によって柔軟な拡張を行うことが可能です。

SendGridとは
Twilio 社が提供するクラウドメール配信サービスです。
独自ドメイン利用やエンゲージメントの最適化、Activety 機能など様々な機能を備えています。
またドキュメントも多く、SMTP や API 経由で気軽な実装が可能です。

まとめ

Google Cloud のフルマネージドサービスをフル活用することで、誰かがやらなければならなかった面倒な問題に悩まされることなく、サービスの開発に集中することができます。まとめると下記のようなメリットが教授できます。

Before	After
複数環境の構築作業	Terraform による複数環境の安定高速構築
複雑なデプロイ	クラウドコンソールまたはコマンドラインから簡単デプロイ
セキュリティパッチ当てによる夜間メンテ	フルマネージドサービスにより管理不要
スパイクによる緊急対応	自動スケーリングによりスパイク回避
データベース最適化	Spannerの機能により自動最適化