Professional Cloud Developer 認定試験範囲の解説
こんにちは。クラウドエース株式会社で Google Cloud 認定トレーナーをしている廣瀬 隆博です。
最近は業務がメチャクチャ多忙でヘヴィメタル成分を摂取できておらず、動画で最低限の栄養を摂取して生きています。
やはりリアルタイムに生演奏の爆音を浴びてこそのヘヴィメタルなので、栄養が枯渇するまでに何とか時間を確保したいところです。
さて、今回は Professional Cloud Developer 認定試験の解説記事となります。
モダンなアプリケーション開発では、昨今は開発スピードの向上が求められがちですね。
生演奏に負けないくらいのスピード感を持ってリアルタイムにアプリケーションをリリースできる仕組みを紹介しているので、是非とも栄養を摂取していってください。
本記事を読み始める前に
本記事は Professional Cloud Developer の認定試験範囲について解説するものであり、システム開発に対してある程度の知識・経験を保有している方に向けた内容となっています。具体的には、Google Cloud における初級の認定試験である Cloud Digital Leader や、中級の認定試験である Associate Cloud Engineer の合格者、もしくは同等の知識・経験をお持ちの方を想定しています。どなたにも理解いただけるように、なるべく平易な表現を心がけておりますが、あらかじめご了承ください。
試験範囲の概要
解説を始める前に、そもそもどんな試験なんだ？ ということに少し触れておきましょう。
試験ガイドによると、スケーラブルで可用性が高く、信頼性のあるクラウド ネイティブ アプリケーションを構築、テスト、デプロイ、管理する能力が問われるようですね。
具体的には、サーバーにミドルウェアを導入してプログラム実行環境を導入する旧来の方式ではなく、コンテナ技術を活用した問題が多く出題されます。
私なりにざっくり表現すると、マネージド サービスを活用して運用負荷を低減し、アプリケーションの開発に注力するための技術が問われる といったところでしょうか。
私のようなインフラ エンジニアは Professional Cloud Architect が理解しやすく Google Cloud の入門に最適でしたが、アプリケーション開発が得意なエンジニアは本試験が入門に向いているのかもしれません。
試験範囲の解説
さて、本題の解説に入りましょう。最近流行のアプリケーション開発といえばコンテナ！
と言える気がしており、解説もコンテナを中心に始めていきます。
コンテナとは
コンテナとは、アプリケーションとその依存関係（ライブラリ、設定ファイルなど）をひとまとめにし、隔離された環境で実行するための技術です。サーバー仮想化と比較してみましょう。
-
仮想マシン
- Operating System（以下、OS） 全体とアプリケーションをパッケージングします。そのため、起動が遅く、リソース消費も大きくなりがちです。各 VM は独立した OS を持つため、OS レベルでの隔離が可能です。
-
コンテナ
- ホスト OS のカーネルを共有し、アプリケーションとその依存関係のみをパッケージングします。そのため、軽量で高速に起動し、リソース効率が良いのが特徴です。プロセスレベルで隔離されます。
ざっくりいえば、仮想マシンが「家を丸ごと提供する」のに対し、コンテナは「家の中の独立した部屋を提供する」ようなイメージですね。 コンテナは OS を含んでいないため、ディスク使用量が少なく、数秒で起動するという大きなメリットがあります。
コンテナ管理基盤
Google Cloud でコンテナを動かすための代表的なプロダクトが Google Kubernetes Engine（GKE） と Cloud Run です。順に解説していきましょう。
GKE
GKE は文字通り Google が提供する Kubernetes です。本試験のツートップと言っても過言ではありません。後述する Kubernetes をマネージド サービスとして提供してくれるので、簡単に使い始めることができます。
Kubernetes とは
GKE の前に、そもそも Kubernetes とは何かを見ていきましょう。
コンテナ化したアプリケーションを動作させるための管理基盤であり、オープンソースとして広く使われています。サーバー仮想化における VMware と似たようなものといえば、インフラに強いエンジニアには伝わるかもしれません。
オープンソースなので個人的に導入することも可能です。
Kubernetes に詳しくなりたい場合、一度個人環境に導入してみると良いですね。
なお、k8s と略されることが多いので、この表記も覚えておくと技術ブログなどを読む際の助けとなるでしょう。
クラスタ
まずは GKE クラスタについて覚えましょう。公式ドキュメントから画像を引用してきました。
色々と複雑に見えますね。まずは左側の コントロール プレーン と、真ん中の ノード を理解しましょう。
コントロール プレーン
GKE クラスタ全体を管理するのが コントロール プレーン です。様々な管理機能が動作しているのですが、ひとまず GKE が動作するために必須の機能群だと覚えておけば大丈夫でしょう。
ノード
ユーザーがデプロイしたコンテナが動作する場所が ノード です。実態は Compute Engine で動作する仮想マシンですね。ノードの管理機能として Standard と Autopilot があります。
Standard
ノードの構成を自身で管理し、実態の仮想マシンを SSH で操作可能なのが Standard クラスタです。管理の手間はかかりますが、多くの仕組みを自ら制御することが可能です。
Autopilot
ノードの構成や管理を GKE に任せてしまうのが Autopilot です。細かい制御が不要な場合はおススメですね。実態の仮想マシンは Compute Engine の画面に表示されませんので、SSH での操作もできません。そんな管理は GKE に任せましょう。
Pod
ノード上で実際にコンテナが動作する最小単位が Pod です。1 つの Pod には 1 つ以上のコンテナが配置される仕組みであり、関連する複数のコンテナを 1 つの Pod にまとめることが可能です。
ReplicaSet
ReplicaSet は、常に指定された数の Pod のレプリカが実行されていることを保証する役割を担います。もし Pod が何らかの理由で停止したり削除されたりした場合、ReplicaSet は自動的に新しい Pod を起動して、定義されたレプリカ数を維持しようとします。逆に、レプリカ数が定義よりも多い場合は、余分な Pod を停止します。後述する Deployment 内で使われることがほとんどですね。
Deployment
最も一般的に使用されるワークロードで、アプリケーションのデプロイやローリングアップデート、ロールバックなどを管理するのが Deployment です。ステートレスなアプリケーション（状態を持たないアプリケーション）に適しています。Deployment は、ローリングアップデートなどの機能を提供しつつ、内部で ReplicaSet を使って Pod の数を管理します。よく使うので覚えておきましょう。
StatefulSet
データベースのように、状態を持つ（ステートフルな）アプリケーションを管理するためのワークロードが StatefulSet です。Pod ごとに永続的なストレージと固定のネットワーク識別子（ホスト名など）を提供します。後述する Cloud Run はステートフルなコンテナを動作させるのには向いていないので、GKE を採用する理由にもなりますね。
DaemonSet
クラスタ内の全てのノード（または特定の条件に一致するノード）で、必ず 1 つの Pod が実行されることを保証するワークロードの一種が DaemonSet です。ログ収集エージェントやモニタリングエージェントなど、各ノードで動作する必要があるコンポーネントに適しています。
Job / CronJob
バッチ処理や定期的なタスクを実行するためのワークロードが Job / CronJob です。Job は一度実行されて完了するタスクに使われ、CronJob スケジュールに基づいて定期的に Job を実行します。名前から役割を想像しやすくて良いですね。
Service
Pod へのアクセスを負荷分散を制御するための仕組みが Service です。パラメータに応じた Cloud Load Balancing がデプロイされる仕組みですね。Cloud Load Balancing については後述します。
ちょっとややこしいので、公式ドキュメントから画像を引用してきました。
Namespace
クラスタ内でリソースを論理的に分割するための仕組みが Namespace です。
同じクラスタ内で本番・検証・開発といった環境を分割するために使用するような感じですね。
公式ドキュメントに良さげな資料が無かったのですが、以下のブログが参考になりそうです。
Cloud Run
長々と GKE が続きましたが、ここからはもう一つのコンテナ管理基盤である Cloud Run の解説に入ります。
GKE と違って基盤のことを意識せずに済むので、とても手軽で使いやすいプロダクトですね。
Cloud Run Services
ウェブサイトやウェブ アプリケーションに向いているのが Cloud Run Service です。
*.run.app ドメインの HTTPS エンドポイントが提供されるため、コンテナをデプロイして同ドメインへアクセスすれば、それだけでウェブブラウザからアクセスしてサイトを表示することが可能です。
トラフィック管理
GKE の Deployment で実現するトラフィック管理について、Cloud Run では GUI で簡単に設定可能です。もちろん定義ファイルを書いて設定することも可能なので、柔軟で便利ですね。後述するデプロイ戦略の項目でもう少し触れていきます。
ゼロスケール
コンテナは高速で起動するというメリットを活かす仕組みが ゼロスケール です。ユーザーからのアクセスが無い場合、全てのインスタンスを停止して課金を抑えることができます。
リクエストがあれば数秒程度で起動するため、ユーザーには「ちょっと遅いかな？」と思われる程度の待ち時間でコンテンツを提供できるようになっており、うまく使えばコストが抑えられて嬉しいですね。
ステートレス
Cloud Run は ステートレス であり、インスタンスは使い捨てです。そのため、情報を保持したい場合、後述する方法でデータを外部に保管しましょう。
Cloud Run Jobs
プログラムの実行が終わったらインスタンスが停止するという特徴を持つのが Cloud Run Jobs です。
バッチ処理に向いていますね。
Cloud Run Functions
旧来、Cloud Functions という名称で提供されていたプロダクトが Cloud Run Functions という名称に変わりました。
こちらは厳密にはコンテナ管理基盤ではないのですが、名称の都合で本項目に記載してあります。
コンテナを意識する必要がなく、プログラムさえ書けば動作する仕組みであり、名前の通り関数として使用するのに向いていますね。
Cloud Run Jobs より手軽に、コンテナイメージを意識せず使えるものだと思えば良いと思います。
認証
さて、ここからはコンテナ以外も学んでいきましょう。まずは認証から進めていきます。
Cloud Identity
組織が Google アカウントを管理したい場合、Cloud Identity を用います。ちょっとややこしい話ですが、Google Workspace でも同じことが可能です。
本試験の範囲から外れるので詳細は避けますが、これらのプロダクトを使うことで組織のドメイン（*.com など）の Google アカウントを発行できます。
管理者側でアカウントを無効にしたり、二要素認証のようなセキュリティ要素を強制することが可能です。
gmail.com では実現できない一元管理の機能なので、Google Cloud を本格的に活用する場合は是非検討してみましょう。
IAM
Google Cloud の認証といえば Identity and Access Management（以下、IAM） です。
ユーザーやサービスに付与する権限を管理するサービスですね。
本試験ではそれほど突っ込んだ内容は出題されないので、簡単に見ていきましょう。
最小権限の原則
最小権限の原則 といった考え方があります。これは Google Cloud に限らず、システムを構築するうえで重要な考え方です。不要な権限を持っていなければセキュリティは強固になりますので、特に本番環境の権限は、必要最小限なものだけ付与しましょう。
アカウント種別
Google Cloud では、大きく分けて 2 つのアカウントがあります。
- ユーザー アカウント
- 人が操作する際に用いるアカウントです
- アカウント名は
@gmail.comが代表的ですが、組織が管理している場合は@<ドメイン名>となります
- サービス アカウント
- 人ではなく、サービスに付与するアカウントです
- 例えば Cloud Run に
roles/storage.objectCreatorを付与すると、Cloud Run のインスタンスから Cloud Storage に対してオブジェクトを作成することができるようになります - 例外はありますが、基本的に
@<プロジェクト名>.iam.gserviceaccount.comといったアカウント名になります
ロールのタイプ
IAM には、次の 3 種類の ロール があります。
- 基本ロール
- Google Cloud リソースへの幅広いアクセス権を付与します
- 簡単・お手軽ですが、付与される権限が非常に多いので、あまりおススメではありません
- Google Cloud リソースへの幅広いアクセス権を付与します
- 事前定義ロール
- 特定のプロダクトへのアクセスを細かく制御できます
- 特に問題なければ事前定義ロールを中心に使用しましょう
- 特定のプロダクトへのアクセスを細かく制御できます
- カスタムロール
- 権限を個別にロール化して付与できるので、最も最小限にすることができます
- ユーザーが管理する必要があるので、事前定義ロールだけでは権限が過剰、もしくは不足した場合に使用するのがおススメです
- 権限を個別にロール化して付与できるので、最も最小限にすることができます
IAM Conditions
IAM を付与する際に条件を設けるのが IAM Conditions です。
例えば、Compute Engine 全体に対して最小の権限を付与するが、インスタンス名が「dev-」で始まるものについては更にオーナー権限を付与するようなことが可能です。
サービス アカウント キー
サービス アカウントはサービスに付与するものであり、外部のサービスに使わせることも可能です。
その際には サービス アカウント キー を用いることで、外部サービスに認証情報を持たせることができます。
以前に私が執筆したブログでは、Veeam という製品が Google Cloud へアクセスするためにサービス アカウント キーを使用したりしています。
Workload Identity Federation
前述のサービス アカウント キーには運用上のリスクがあります。キーが漏洩すれば、外部から不正なアクセスを受ける可能性がある点ですね。
これを回避するために用いるのが Workload Identity Federation です。
セキュリティの試験ではないので詳細は省きますが、Google Cloud 外の ID プロバイダー（IdP）と連携することで、サービスは鍵を持たずに認証させることが可能となっています。
理解の助けになるかと思い、公式ブログの画像を引用してきました。
OAuth 2.0
OAuth 2.0 は、あるサービスに対して、ユーザーの認証情報（パスワードなど）を直接渡すことなく、限定的なアクセス権限（何をしてよいか）を与えるための仕組みです。
こちらも詳細は省きますが、サービス アカウントに付与した権限を用いて Google Cloud 上のリソースへのアクセスが可能となる過程には Oauth 2.0 が動作していると考えれば理解しやすいかもしれません。
JWT
JSON Web Token（以下、JWT） とは、認証情報の交換に利用されるチケットのようなものです。JWT はデジタル署名されているため、改ざんされていないことを検証することができます。前述のサービス アカウントでの認証において、JWT が使用されています。
Identity-Aware Proxy
簡単に Google アカウントの認証を実現する仕組みが Identity-Aware Proxy（以下、IAP） です。Google Cloud 上の仮想サーバーを操作する際にサーバー一覧の画面から押す SSH ボタンについても、内部では IAP が動作しています
これを用いることで、開発したアプリケーションに Google アカウント認証を実装することが可能です。
Secret Manager
ここまでに記載した仕組みを使うことで、プログラムやサービスに認証情報を持たせない事もある程度可能です。
とはいえ、どうしてもユーザー名とパスワードのような情報を保持することが必要な場合もあります。
そういった場面では Secret Manager が便利です。
認証情報を直接プログラムやサービスに持たせるのではなく、Secret Manager に登録することが可能です。
プログラムやサービスは認証情報が必要となるたびに Secret Manager へアクセスし、最新の情報を取得します。
うまく権限を設計することで、開発者は直接パスワードを知ることなくアプリケーションには使わせることも可能です。
Kubernetes Secret
Secret Manager と同じような機能が Kubernetes Secret といった名称で提供されています。呼んで字のごとく Kubernetes の機能であり、Pod から参照するためのものです。
注意点として、標準では Kubernetes Secret に格納したデータは暗号化されません。別途設定することで暗号化は可能なのですが、設計次第では Secret Manager と連携させたほうが良いかもしれません。
Secret Manager と似た用途の機能ですが、Kubernetes Secret 文字通り Kubernetes が提供している機能のため、役割が重複しているように感じるわけですね。
API 管理
開発したアプリケーションを Application Programming Interface（以下、API）として公開する際に、その管理・運用を助けるためのプロダクトが提供されています。
API Gateway
主にサーバーレスなバックエンドに用いる API 管理プロダクトが API Gateway です。
弊社の廣瀬（私ではない）が API Gateway に関する技術ブログを公開しているので、こちらを参照いただくと理解の助けとなるでしょう。
Cloud Endpoints
Extensible Service Proxy（以下、ESP）というプロキシを使って API を管理するのが Cloud Endpoints です。
その性質から Compute Engine や GKE などに用いることが多いですが、ESPv2 であれば、Cloud Run も管理対象とすることができます。
公式ドキュメントの画像が参考になるので引用してきました。
Apigee
Google Cloud が提供する API 管理プロダクトとして最も大規模で強力なものが Apigee です。
API 管理プラットフォームと呼んでも差し支えないほど多機能であり、多数の API を統合管理することができます。
高機能という事は、必然的に利用料が高額になりがちです。前述のプロダクトでは機能が不足する場合に導入を検討してみると良いでしょう。
データ
アプリケーションが用いるデータは、どこかに保存しなくてはなりません。
特にコンテナはステートレスであったほうが嬉しいので、Google Cloud 上のプロダクトにデータを保存することを検討しましょう。
データベース
Google Cloudが提供する主要なデータベース プロダクトを紹介します。
| 種類 | 特徴 | 主な用途 | SLA（※） |
|---|---|---|---|
| Cloud SQL | MySQL、PostgreSQL および SQL Server を動作させることができるマネージド リレーショナル データベース | - Web アプリケーションのデータベース - トランザクション処理 |
>= 99.99% |
| Spanner | 分散型 SQL データベースであり、大規模なアプリケーションのトランザクションとスケーラビリティに対応できる | - グローバル アプリケーションのデータベース - トランザクション処理 |
>= 99.999% |
| Bigtable | カラム指向の NoSQL データベースであり、高スループットに期待できる | - IoTデータ - クリックストリーム |
>= 99.999% |
| Firestore | ドキュメント指向の NoSQL データベースであり、一時的にオフラインとなるような通信環境でも使用可能 | - モバイル アプリケーション | >= 99.999% |
| Bare Metal Solution for Oracle | オンプレミスの Oracle Database をクラウドに移行するためのハードウェア | - Oracle Database | No SLA |
※ SLA は構成によって異なり、表には最大値を記入している
なお、上記の表以外に AlloyDB も存在しています。
本試験の範囲に入りそうなものですが、本記事執筆時点の試験ガイドに名前が出ていないため、解説は割愛いたします。
詳細を知りたい方は、以下のリンクから公式ページをご確認ください。
Redis (Memorystore for Redis)
Redis とは、インメモリな NoSQL データベースです。
インメモリとは、データをハードディスクや SSD ではなくメモリ上に保持する仕組みであり、高速なアクセスが可能となります。
その特性を活かし、キャッシュやセッション管理に用いられることが多いものです。
なお、Redis 自体はオープンソースですが、これを Google Cloud でフルマネージドなサービスとして提供しているのが Memorystore for Redis ですね。
Cloud Storage
Google Cloud で最も基本的なストレージ サービスの一つが Cloud Storage です。
オブジェクト ストレージと呼ばれるタイプのサービスで、画像、動画、バックアップ データ、ログファイルなど、あらゆる種類のデータを保存することができます。
使いどころの多いサービスなので、細かく見ていきましょう。
静的ウェブサイト ホスティング
Cloud Storage は、静的ウェブサイトを公開する機能を持っています。ここでの「静的」とは HTML や画像、動画のような「必ず同じデータを提供すればよい」ものと思ってください。
署名付き URL
通常、Cloud Storage のオブジェクトは IAM 権限に基づいてアクセスが制御されます。しかし、Google アカウントを持っていないユーザーにアクセスさせたい場合もあります。
例えば「免許証で身分を証明する」システムを作る場合、ユーザーから免許証の画像をアップロードしてもらう必要がありそうです。その際に 署名付き URL を用いることで、一時的にアクセスを許可することができます。
ストレージ クラス
ストレージ クラスとは、Cloud Storage のコストを最適化するための機能です。アクセス頻度や保存期間から最適なクラスを選択することで、コストの削減が可能となります。
クラスは以下の種類があるのと、これらを自動的に制御してくれるオートクラスという便利な機能があることを覚えておきましょう。
| ストレージ クラス | 最小保存期間 | 一般的な月間可用性 |
|---|---|---|
| Standard ストレージ | なし | マルチ リージョンとデュアル リージョンでは 99.99% を超える リージョンでは 99.99% |
| Nearline ストレージ | 30 日 | マルチ リージョンとデュアル リージョンでは 99.95% リージョンでは 99.9% |
| Coldline ストレージ | 90 日 | マルチ リージョンとデュアル リージョンでは 99.95% リージョンでは 99.9% |
| Archive ストレージ | 365 日 | マルチ リージョンとデュアル リージョンでは 99.95% リージョンでは 99.9% |
ライフサイクル
前述のストレージ クラスを最適に使いたいと考えると、保存日数の経過に応じて段階的にクラスを長期保管用のものへ変更したいと思いませんか。
そこで役に立つのが ライフサイクル です。
定義したルールにしたがってオブジェクトのクラスを変更したり、オブジェクト自体を削除することが可能です。
クラス変更以外の例として、「監査に必要なデータなので 7 年保持する」といった要件がある場合、7 年経過後に自動削除するライフサイクルを設定しておくことでコストが最適化されますね。
ネットワーク
単独で稼働するアプリケーションもありますが、多くは何かと連携して動作します。例えば、前述したステートレスなコンテナの場合、何かしらデータを格納するサービスと連携することが多いですね。
また、アプリケーションは開発して満足するものではなく、公開して利用者に使ってもらうためのものですよね。そこで、アプリケーション開発者として知っておくべきネットワークについて紹介していきます。
Cloud Load Balancing
アプリケーション公開といえば、まず思いつくのがロードバランサーですね。Google Cloud では、Cloud Load Balancing が該当します。
Web アプリケーションなら HTTP(s) が一般的な公開方法ですが、それ以外の TCP/UDP 通信も対象とすることが可能です。
どのタイプでどういったアプリケーションが公開可能か、公式ドキュメントに分かりやすい図があったので引用してきました。
暗記する必要はないですが、ざっと見ておくと試験対策に良いかもしれません。
Virtual Private Cloud
Virtual Private Cloud（以下、VPC） とは、Google Cloud 内にプライベートなネットワークを構築するサービスです。
Compute Engine VM や、GKE クラスタなどは、この VPC ネットワーク内に配置され、相互に通信します。
プライベート サービス アクセス
実は、Cloud SQL や Memorystore for Redis といった Google Cloud のマネージドサービスは、Google が管理するネットワーク上で実行されています。自分で管理する VPC では動作しないんですよね。
そういったサービスと Google Cloud の内部で通信する際に用いるのが プライベート サービスアクセス です。
Pub/Sub
少し説明が難しい 非同期メッセージング サービス が Pub/Sub です。連携したいコンテナやサービス同士を直接接続させるのではなく、Pub/Sub に中継させることで得られるメリットがあります。
例えば、顧客からアップロードされた画像を分析してテキスト化するサービスがあったとしましょう。
直接連携させると分析が終わるまで待たなくてはいけませんが、Pub/Sub を用いた非同期での連携にすることで、分析完了を待たずとも「分析を開始しました」と応答を返すことが可能です。
しばらく経過してから結果を確認しにいくと「分析が完了しました」というステータスに変化しており、結果を確認することができるような感じですね。
このように、サービス同士を疎結合にして非同期に処理させることが可能となります。
マイクロサービスを開発したい場合には、是非活用しましょう。
セキュリティ
アプリケーションを狙った攻撃は日々増加する一方であり、開発者として対策は必須ですね。様々なセキュリティ要素を覚えておきましょう。
SSL 証明書
HTTP 通信 を暗号化して HTTPS にするために用いるのが SSL 証明書です。
今どきは HTTP 通信だと Web ブラウザが警告を発することもあるので、是非とも SSL 証明書で通信を暗号化しましょう。
Google Cloud では無料で SSL 証明書を利用することが可能なので、とてもありがたいですね。
Cloud Armor
Cloud Load Balancing と連動し、様々な攻撃を防ぐサービスが Cloud Armor です。
IP アドレスでのアクセス制御、Web Application Firewall（WAF）、DDoS 保護といった Web アプリケーションを守るための機能が数多く実装されています。
Cloud Data Loss Prevention
Cloud Data Loss Prevention とは、データから機密情報を検出して情報漏洩の対策をするためのサービスです。
アプリケーションが扱うデータに機密情報が含まれていないことを確認したり、機密情報をマスキングしたりすることができます。
個人情報を扱う場合には活用したいですね。
Cloud Key Management Service
データの暗号化に用いるのが Cloud Key Management Service（以下、Cloud KMS） です。
Google Cloud の多くのサービスでは、保存データはデフォルトで暗号化されています。
これは Google 管理の鍵で暗号化されているのですが、鍵を変更したい場合には Cloud KMS を使います。
デプロイ戦略
アプリケーションは開発したら終わりではなく、機能追加や不具合対応によって改修し、稼働中の環境へのデプロイが発生することも多くあります。
昨今は開発速度の向上も求められており、それを実現するためのデプロイ戦略が重要になります。
様々なデプロイ戦略
代表的なデプロイ戦略は以下の通りです。
詳細は私が別途執筆している Professional Cloud DevOps Engineer 試験対策記事をご参照ください。
| 戦略名 | 概要 | メリット | デメリット |
|---|---|---|---|
| インプレイス アップデート | 既存の環境上で、古いバージョンのアプリケーションを新しいバージョンに直接上書きして置き換える。 | 構成がシンプルで、追加のリソースが不要。 | デプロイ中にダウンタイムが発生する可能性。問題発生時の切り戻しが複雑になることがある。 |
| ローリング アップデート | 複数のインスタンスがある環境で、一度に全てのインスタンスを更新するのではなく、一部分ずつ順番に新しいバージョンに置き換える。 | ダウンタイムを最小限に抑えられる。問題発生時の影響範囲を限定できる。 | デプロイ中に新旧バージョンが混在する期間がある。切り戻しに時間がかかる場合がある。 |
| ブルーグリーン デプロイ | 現在稼働中の環境（ブルー）とは別に、新しいバージョンの環境（グリーン）を用意する。テスト完了後、ロードバランサーなどを利用してトラフィックをグリーン環境に一気に切り替える。 | ダウンタイムがほぼゼロ。問題発生時に即座にブルー環境に切り戻せる。 | 常に 2 つの環境を維持する必要があるため、リソースコストが 2 倍かかる。データベースのスキーマ変更などに注意が必要。 |
| カナリアテスト | 新しいバージョンをまずごく一部のユーザー（カナリアユーザー）にのみ公開し、問題がないことを確認しながら段階的に公開範囲を広げていく。「炭鉱のカナリア」が名前の由来。 | リスクを最小限に抑えながら新機能をリリースできる。実際のユーザー環境でテストできる。 | 全ユーザーに展開するまでに時間がかかる。一部ユーザーに問題が発生する可能性がある。 |
自動テスト・自動デプロイ（CI/CD）
例えばコンテナ化されたアプリケーションの場合、新しいコンテナをデプロイするためには、コンテナのビルドと本番環境での入れ替えが必要です。
また、新しいコンテナをデプロイした後はテストも必要でしょう。
そういった作業を手動でしていると、いずれミスが起こりかねません。
そんな手間は自動化しましょう。
継続的インテグレーション / 継続的デリバリー（以下、CI/CD） と表記されることも多いので、この言葉も覚えておきましょう。
Cloud Build
Cloud Build は、Google Cloud 上でソースコードのビルド、テスト、デプロイを自動化するためのサービスです。
cloudbuild.yaml という設定ファイルにビルドステップを定義することで、様々な処理を実行することができます。
Artifact Registry
開発したアプリケーションのビルド成果物（アーティファクト）を保存・管理するためのサービスが Artifact Registry です。
コンテナだけではなく、Java や Go など、様々な形式をサポートしています。
Binary Authorization
Binary Authorization は、信頼されたコンテナ イメージのみがデプロイされることを保証するセキュリティ機能です。
組織が定義したポリシーに基づき、デジタル署名や構成証明（Attestation）によって検証されたイメージのみ実行を許可します。
コンテナ イメージを不正に入れ替えるような悪さを防ぐ機能ですが、ちょっと運用が大変なのでご利用は計画的に。
運用
アプリケーションに問題が発生したことを素早く発見することで安定稼働に繋がります。
「あのサービス止まってるよ」って SNS で発信される前に解決できるような仕組みを実装しておきましょう。
Cloud Monitoring
Cloud Monitoring は、Google Cloud サービスやアプリケーションのパフォーマンス指標（メトリクス）を収集、可視化し、アラートを設定できるサービスです。
後述する各サービスと連携し、システム全体の状態把握や異常検知の起点となるため、是非とも活用しましょう。
Cloud Logging
Cloud Logging は、アプリケーションや Google Cloud サービスから出力されるログデータを一元的に収集、検索、分析、監視するサービスです。
アプリケーションのエラーログを起因にアラートを通知することも可能であり、安定稼働には必須と言えるでしょう。
Cloud Profiler
Cloud Profiler は、アプリケーションの CPU やメモリ割り当てを継続的に分析し、パフォーマンスのボトルネックとなっているコード箇所を特定するのに役立ちます。
ソースコードに Cloud Profiler の記述を追加する必要があることを覚えておきましょう。
Cloud Trace
Cloud Trace は、アプリケーションへのリクエストのレイテンシを追跡・分析するためのサービスです。リクエストがどのサービスでどれだけ時間を要したかを把握できるため、デバッグに有効です。
こちらもソースコードへの記述が必要なので注意しましょう。
Error Reporting
Error Reporting は、実行中のアプリケーションで発生したクラッシュやエラーを集計し、リアルタイムで表示するサービスです。
集計結果を視覚化してくれるのが嬉しいですね。
開発支援
Google Cloud の開発において、生産性を向上させるためのツールも提供されています。
ローカル開発
クラウドのサービスと連携するアプリケーションを開発する場合、気になるのは利用料ですね。
一部のサービスでは、ローカル環境で動作するエミュレータが提供されているので、うまく活用してコストを削減すると共に、開発を効率化しましょう。
| エミュレータ | 説明 |
|---|---|
| Cloud Firestore エミュレータ | Cloud Firestore の動作をローカルでシミュレートします。 https://cloud.google.com/firestore/docs/emulator?hl=ja |
| Pub/Sub エミュレータ | Pub/Sub のトピックやサブスクリプションの動作をローカルでエミュレートします。 https://cloud.google.com/pubsub/docs/emulator?hl=ja |
| Bigtable エミュレータ | Bigtable の動作をローカルでエミュレートします。 https://cloud.google.com/bigtable/docs/emulator?hl=ja |
| Datastore エミュレータ | Datastore (旧) の動作をローカルでエミュレートします。 https://cloud.google.com/datastore/docs/tools/datastore-emulator?hl=ja |
Cloud Code
Cloud Code は、GKE や Cloud Run などの多くの Google Cloud サービスを Integrated Development Environment（以下、IDE） から直接使用できるようにする拡張機能です。
普段使っている IDE を Google Cloud に対応させて、便利に使うためのものという感じですね。
まとめ
Professional Cloud Developer の試験ガイドを元に、試験範囲の概要を説明してきました。
内容は多岐にわたるのですが、一貫してアプリケーション開発者に求められる知見が問われる内容となっています。
Google Cloud 未経験の開発者が手始めに勉強する内容としても適切ですので、是非とも多くの方にチャレンジいただければと思います。
クラウドエース株式会社 Google Cloud 認定トレーナーの廣瀬 隆博がお届けしました。また次の記事でお会いしましょう。
Discussion