基本的なプラクティス

SRE

Shell Path

Linux（Unix 系 OS）ではルート（/）配下の各ディレクトリにコマンドやスクリプト、プログラム等のバイナリファイルが置かれる

基本コマンド

/bin
- シングルユーザモードでも利用できるコマンドが置かれる
- /usr/bin や /usr/local/bin に置かれているコマンド等はシングルユーザモードで利用できない（その端末で共有されたコマンドが置かれる）
- シングルユーザモードは、基本的に OS が壊れて正常に起動できない等の非常時に利用するもの
- ごく基本的かつ非常時に利用するコマンドが置かれる
/usr/bin
- 「シングルユーザモードで利用しない」かつ「RPM や deb 等のパッケージ管理システムによって、システムに管理されるコマンドやプログラム」が置かれる
- 非常時に利用するものではないが、システムを構成する重要なコマンドやプログラムはここに置かれる
/usr/local/bin
- 「シングルユーザモードで利用しない」かつ「RPM や deb 等のパッケージ管理システムによってシステムに管理されないコマンドやプログラム」が置かれる
- 自作のスクリプト等は /usr/local/bin 配下に置くことが一般的
- Linux ディストリビューションをインストールしたばかりのときは、このディレクトリが空であることも多い

カーネルコマンド

/sbin, /usr/sbin, /usr/local/sbin のディレクトリも基本的に同じ関係性
/bin とは異なり、/sbin はシステム管理用のコマンドやプログラムが置かれる

Google Authentication の仕組み

テスト戦略

A/B テスト（Blue/Green デプロイメント）
- 旧バージョンと新バージョンの効果やパフォーマンスの比較を行う
- 以前のバージョンを保持するため、即座なロールバックが可能
- 一時的に必要なリソースが倍増する
- 異なるラベルを付与しておき、ASM の VirtualService を作成して転送ルールを設ける
カナリアテスト（カナリアリリリース）
- 即座なロールバックが求められるデプロイ戦略には向かない
- 全環境での負荷テストは避けながら、できるだけ早く新機能をデプロイしたい場合等に利用
- 一部のユーザに対して新機能をテストしたい場合に向いている
  - Cloud Run のトラフィック分割機能や Anthos のトラフィック制御機能を用いる
シャドーテスト
- ライブトラフィックを使用して新しいアプリケーションと既存のアプリケーションの両方のパフォーマンスメトリックを収集したい
- 起動前に完全な実稼働負荷に対してテストする
- （トラフィックミラーリングによる A/B 検証にも利用可能）
スモークテスト
- 開発・修正したソフトウェアを実行可能な状態に組み立て、起動するかどうかや基本的な機能が動作するかなどをざっと確認する
- 新機能を即座に全ユーザに公開される

ローリングアップデート戦略

maxSurge：最大追加数
- 余分に作成可能な Pod の数
- 絶対値（整数）または相対値（％）で指定できる
maxUnavailable：最大停止数
- サービスについて使えなくなって良い（削除可能な）Pod の最大数
- 絶対値（整数）または相対値（％）で指定できる

HTTP ステータスコード

4xx 系

401 Unauthorized：認証エラー（アカウントキーの設定ミス）
403 Permission Denied：権限に関するエラー（IAM ロールの不足）
404 Not Found：指定された URL パスが見つからない
406 Not Acceptable：リクエストの Accept ヘッダにサーバで受理できない内容が含まれている

5xx 系

502 Bad Gateway：サーバサイドエラー

Cloud Storage クラス

Nearline ストレージ：月に 1 回程度しか行わないデータを管理
Coldline ストレージ：四半期に 1 回程度しか読み取りや変更を行わないデータを管理
Archive ストレージ：1 年間に 1 回未満しかアクセスしないデータを管理

Cloud SQL

レプリケーション

Cloud Armor

DDoS, XSS, SQLi 等のアプリケーション攻撃をはじめ、さまざまなタイプの脅威からリソースを保護する（境界型防衛）
認証や脆弱性スキャンを行うためのものでは無いので要注意
- 試験では IAP や Web Security Scanner（SCC）の選択肢と一緒に登場することが多いイメージ

Cloud Pub/Sub

概要・要点

Pull サブスクリプション
- トピックを順次処理する（Pub/Sub の利用方法としてはほぼこの使い方）
Push サブスクリプション
- 負荷が高い場合に、サブスクライバが処理しきれなくなる懸念がある
- 大量のメッセージの処理に向かない

Pull サブスクリプション

使用例
- メッセージが多い場合（1 秒間に GB）
- メッセージ処理の効率とスループットが重要な場合
- 非自己署名 SSL 証明書を持つパブリック HTTPS エンドポイントを設定できない環境
エンドポイント
- 承認済みの認証情報を持つインターネット上のデバイスが Pub/Sub API を呼び出すことができる
ロードバランシング
- 複数のサブスクライバが、同じ「共有」サブスクリプションへの pull 呼び出しを作成できる
- サブスクライバ毎にメッセージのサブセットを受信する
構成
- 構成不要
フロー制御
- サブスクライバクライアントは配信レートを制御
- サブスクライバは確認応答期限を動的に変更し、メッセージ処理期間を必要に応じて長くすることができる
効率とスループット
- バッチでの配信、確認応答、超並列消費を可能にすることで、低い CPU と帯域幅で高いスループットを実現
- 積極的なポーリングを使用してメッセージ配信時間を最小限に抑える場合には効率的でない場合がある

Push サブスクリプション

使用例
- 同じ Webhook で処理する必要がある複数のトピック
- App Engine スタンダードおよび Cloud Functions のサブスクライバ
- Google Cloud の依存関係（認証情報やクライアントライブラリ）が設定できない環境
エンドポイント
- 非自己署名証明書を持つ HTTPS サーバは、パブリックウェブ上でアクセス可能
- 受信エンドポイントは、Pub/Sub サブスクリプションから切り離すせるため、複数のサブスクリプションからのメッセージが単一のエンドポイントに送信される
ロードバランシング
- ロードバランサを指定できる
構成
- サブスクライバと同じプロジェクトでは、App Engine アプリへの設定が不要
- Google Cloud コンソールでは、push エンドポイントの確認は必要無い
- エンドポイントには DNS 名を使用して到達可能で、SSL 証明書がインストールされている必要がある
フロー制御
- Pub/Sub サーバはフロー制御を自動的に実装する
- クライアント側でメッセージフローを処理する必要は無い
- HTTP エラーを戻すことで、クライアントが現在のメッセージ読み込みを処理できないことを示せる
効率とスループット
- リクエスト毎に 1 つのメッセージを配信し、未処理メッセージの最大数を制限する

Export サブスクリプション

使用例
- 毎秒数百万回のメッセージまでスケールアップできる大量のメッセージ
- メッセージは、追加の処理を行うことなく Google Cloud リソースに直接送信される
エンドポイント
- BigQuery サブスクリプションの BigQuery データセットとテーブル
- Cloud Storage サブスクリプションの Cloud Storage バケット
ロードバランシング
- Pub/Sub サービスは負荷を自動的に分散する
構成
- BigQuery のデータセットとデーブルは、適切な権限で構成された BigQuery サブスクリプション用に存在している必要がある
- Cloud Storage バケットは、適切な権限で構成された Cloud Storage サブスクリプション用に存在している必要がある
フロー制御
- Pub/Sub サーバは、Google Cloud リソースへのメッセージ書き込みを最適化するためのフロー制御を自動的に実装する
効率とスループット
- スケーラビリティは、Pub/Sub サーバによって動的に処理される

アプリケーションモダナイゼーション

マイクロサービス

メリット

アプリケーションをマイクロサービスに分割すると次のような利点がある。
多くはマイクロサービスが疎結合であることに起因する。

個別にテストしてデプロイ可能
- デプロイ単位が小さいほどデプロイが容易となる
異なる言語やフレームワークで実装可能
- マイクロサービス毎に、ユースケースに最適なテクノロジを自由に選択できる
異なるチームで管理可能
- マイクロサービス間の境界により、1 つのチームが 1 つまたは複数のマイクロサービスを簡単に管理できる
チーム間の依存関係の緩和
- 各チームは依存しているマイクロサービスの API のみを考慮し、マイクロサービスの実装方法やリリースサイクルについて考える必要は無い
障害に対する設計が容易
- サービス間に明確な境界があるため、サービスが停止した場合の対処方法を決定しやすくなる

デメリット

複雑さの増大
- マイクロサービスベースのアプリを構成するサービスの相互関係が明確でない場合が多くシステム全体の複雑さは増大する傾向にある
セキュリティリスク
- モノリシックなシステムの内部と異なり、マイクロサービスはネットワークを介して通信を行うため、セキュリティ上の問題が発生することがある
- 例えば、この問題を解決するため、Istio はマイクロサービス間のトラフィックを自動的に暗号化している
レイテンシの増加
- サービス間のレイテンシのため、モノリシックアプローチと同じレベルのパフォーマンスを実現するのが困難な場合がある
可観測性の低下
- システムの動作は、単一のサービスに起因するのではなく、多くのシステムとシステム間のやり取りによって引き起こされる
- 本番環境でのシステムの動作を把握することが難しくなる
- Istio はマイクロサービス環境下においてオブザーバビリティを実現するためにいくつかの便利な機能を提供している

分散トレーシング

分散トレーシングでは、Trace ID と処理中の Span の ID を子オペレーションに渡す
Span ID
- 子オペレーションの固有識別子
- 同じオペレーションが複数回実行された場合、そのオペレーションには複数のスパンがあり、それぞれに固有識別子がある
Trace ID
- この特定のオペレーション全体が行われたエンドツーエンドのオペレーションの固有識別子
- Trace ID は親から提供される
Parent Span ID
- 親のスパンの固有識別子
- こ Parent Span ID は親から提供される
- ルートスパンの場合は null となる
X-Cloud-Trace-Context フィールドにこれらの情報を含めることができる
- X-Cloud-Trace-Context: TRACE_ID/SPAN_ID;o=OPTIONS
- TRACE_ID：128 ビットの番号を表す 32 文字の 16 進数
- SPAN_ID：符号無し Span ID の 64 ビット 10 進数
- OPTIONS：0（親がサンプリングされない）と 1（親がサンプリングされた）をサポート

Istio

概要

統一された方法でマイクロサービスの接続、管理、保護を実現する OSS 版サービスメッシュソリューション
マイクロサービスコードを変更することなく、サービス間のトラフィックフローの管理、アクセスポリシの適用、テレメトリデータの集計を行うことができる

利点

HTTP / gRPC / WebSocket / MongoDB / TCP トラフィックの自動負荷分散
高度なルーティングルール、再試行、フェイルオーバ、フォールトインジェクションによるトラフィックの動作のきめ細かい制御
アクセス制御、レート上限、割り当てをサポートする構成可能なポリシレイヤと API
上りと下りを含む、クラスタ内のすべてのトラフィックのメトリクス、ログ、トレースの自動作成
ID ベースの認証と承認を使用した、クラスタ内の安全なサービス間通信

Fault Injection

堅牢な障害復旧機能があったとしてもメッシュの復元性のテストは必要である
フォールトインジェクションは、一定の条件に一致するリクエストに遅延フォールト（障害）や中断フォールトを挿入するように構成する
障害の対象となるリクエストの割合も制限できる

Anthos

概要

ハイブリッド/マルチクラウド環境で動作するアプリケーションのモダナイズを実現するためのプラットフォーム
GKE をベースに様々な機能を有することで、よりユーザのニーズに沿ったフレキシブルなアプリケーション開発環境を実現

種類

Anthos Cluster（Anthos GKE）
Anthos GKE on-Prem
Anthos GKE on AWS
Anthos Config Management
Anthos Service Mesh
その他
- Cloud Run for Anthos
  - コンテナ環境をサーバレス環境として利用できる機能
- Ingress for Anthos
  - クラスタ間の負荷分散機能
- Anthos clusters on VMware
  - VMware 上で動作する Kubernetes クラスタを管理するための機能
  - オンプレミスのデータセンターにホストされているクラスタでイメージを実行します
- Binary Authorization
  - クラスタイメージのセキュリティ管理機能

比較

特徴	Anthos Service Mesh（ASM）	Anthos Config Management（ACM）
主な機能	サービス間の通信およびセキュリティの管理	Kubernetes クラスタの構成とポリシの管理
トラフィック管理	詳細なトラフィックの制御、ルーティング、負荷分散	該当なし
セキュリティ	サービス間通信の暗号化と認証（mTLS）	クラスタ設定やポリシの一貫した適用
ポリシ管理	サービス間のリクエスト管理や通信ポリシ	クラスタ全体のポリシガバナンス管理
自動化	トラフィック観測とセキュリティの自動管理	クラスタの構成とポリシの自動同期と修復
使用状況	マイクロサービス間通信の監視や管理に特化	マルチクラスタの構成とガバナンス管理に特化

Anthos Service Mesh（ASM）

概要

マイクロサービス間の通信を制御し、セキュリティやトラフィックの管理、可視化を提供するツール
Google Cloud が提供するマイクロサービスのためのネットワーキングおよびサービス管理ソリューション
特にコンテナあるいは Kubernetes 環境で稼働するサービスの通信管理を最適化するために使用される
Istio をベースに、Google がサポートと管理機能を強化している

主要機能

トラフィック管理
- コンテナやマイクロサービス間のトラフィックの制御が可能
- リクエストのルーティングや負荷分散、フェイルオーバー等を柔軟に設定可能
- これにより、ブルー/グリーンデプロイメントやカナリアリリースといった進行中のリリース戦略の実施が容易となる
サービスの可視化とトレーシング
- 分散トレーシング（リクエストがサービスを経由していくプロセスを追跡）や、サービス間の通信状況やパフォーマンスメトリクスをリアルタイムでモニタリングできるダッシュボードが提供されている
- この可視化により、システムのボトルネックの特定やトラブルシューティングが効率的に行える
セキュリティ
- ASM では、サービス間の通信が自動で暗号化され、互いの通信を認証するための TLS 通信が適用される
- プロキシインジェクションによる通信のセキュリティポリシが設定でき、サービス単位でアクセス制御が簡単に構成できる（mTLS：相互認証 TLS 等）
ポリシ管理とレート制限
- サービス間でどのようなリクエストを許可するのか、あるいは一定のリクエスト数以上を制限するためのポリシも管理できる
- これにより、不正アクセスや高負荷の回避が可能

利点

自動化された観測
- トラフィック、エラー率、レイテンシ等の情報を自動的に収集し、モニタリングを行う
耐障害性
- サーキットブレイカーのような耐障害性を高めるメカニズムが完備されており、不安定なサービスの影響を緩和できる
セキュリティの簡素化
- 通信が暗号化され、認証の仕組みが統一されているため、セキュリティの管理が容易となる

Anthos Config Management (ACM)

概要

Kubernetes クラスタ全体で構成やポリシを管理し、GitOps による宣言的な管理方法を提供するツール
ACM は Kubernetes クラスタの構成管理とポリシ管理を自動化するためのソリューション
特に、マルチクラスタ環境における設定の一元管理が可能になる

主要機能

ポリシ・ガバナンス
- セキュリティ設定やリソースの配信ポリシを集中管理し、それを自動的にクラスタ全体に配布できる
- これにより、例えば「特定の名前空間には特定のリソースしかデプロイできない」といったポリシを統制できる
GitOps による宣言的管理
- ACM は、Git リポジトリで構成ファイルを管理し、それをもとにクラスタの構成を宣言的に管理する
- 構成が変更されると、ACM がリアルタイムで検出し、その内容を各クラスタに適用する
- これにより、コードベースで設定が一元管理され、環境ごとに異なる設定ミスや人為的ミスを減らすことができる
複数クラスタの一元管理
- 1 つのリポジトリから複数の Kubernetes クラスタを一括管理できるため、クラスタが増加しても管理作業が煩雑になりにくい
- GKE だけでなく、オンプレミスやハイブリッドクラウド環境の Kubernetes クラスタも管理可能
自動同期と自動修復
- Git リポジトリに保存された構成が、リアルタイムでクラスタに適用され続ける
- 万が一クラスタの設定が手動で変更されたとしても、ACM が自動でリポジトリの設定に戻す
- この仕組みによって、設定の一貫性が常に保たれる

利点

一貫した設定管理
- ポリシやアクセス権限等の設定を一元的に管理でき、すべてのクラスタに即時に適用されるため、設定の不整合や手作業によるミスが防げる
コーディング時点でのポリシチェック
- GitOps のモデルを活用して運用をシフトレフト（開発段階でポリシ順守やエラーを検出）することで、本番環境に影響を及ぼすポリシミスを未然に防ぐことができる
スケーラブルなマルチクラスタ運用
- 例え数百のクラスタがあっても、各クラスタの設定を簡便に一括管理できるため、スケーラビリティを確保できる

アクセス制御

Cloud IAM

概要

Cloud IAM：Google Cloud Identity and Access Management
ID から Google Cloud API を呼び出す場合、その ID にはリソースを使用するための適切な権限が必要となる
Cloud IAM には高度に自動化され、少ない手間でリソースの権限を管理するための適切なツールが用意されている
ユーザに権限を直接付与する代わりに、権限を組み合わせたロールを割り当てる
- 権限を付与するには、ユーザ、グループ、またはサービスアカウントにロールを付与する
これにより、社内の職務権限をグループやロールにマッピングできる
ユーザは自分の業務の遂行に必要なアクセス権のみを付与され、管理者はユーザグループ全体に対してデフォルトの権限を簡単に付与できる

ロールの種類

（基本ロール）
- Cloud IAM の導入前に存在していたオーナー、編集者、閲覧者のロールが含まれる
事前定義されたロール
- Google によって作成、管理される
- 特定のサービスへのアクセスを細かく制御する
- 権限は Google Cloud に新しい機能やサービスが追加された場合等、必要に応じて自動的に更新される
カスタムロール
- ユーザ定義であり、特定のニーズに合わせて 1 つ以上のサポートされている権限を制御できる
  - カスタムロールは、使用可能な Cloud IAM 権限を組み合わせて作成する
- Google Cloud は一切管理しない（新しい権限、機能、サービスを追加しても、カスタムロールは自動的に更新されない）

サービスアカウント

概要

GSA：Google Service Account
サービスアカウントは、個々のエンドユーザではなく、アプリケーションや仮想マシン（VM）に属している特別な Google アカウント
サービスアカウントはアカウント固有のメールアドレスで識別される
アプリケーションはサービスアカウントを使用して、サービスの Google API を呼び出す（ユーザが関与する必要は無い）
サービスアカウントはサービスの ID となり、サービスアカウントの権限によって、そのサービスがアクセスできるリソースが制御される
例：
- あるサービスアカウントで Compute Engine VM が実行される場合、必要なリソースへのアクセス権をそのアカウントに付与できる

IAM ロールの付与

サービスアカウントにロールを付与すると、Google Cloud プロジェクトのリソースに対して特定の操作を行う権限が付与される
- 例：storage.admin のロール（role/storage.admin）が付与されたサービスアカウントでは、Cloud Storage のオブジェクトやバケットを管理できる

作成したサービスアカウントにロールを付与するには iam-policy-binding を実行する

$ gcloud projects add-iam-policy-binding $DEVSHELL_PROJECT_ID \
    --member serviceAccount:my-sa-123@$DEVSHELL_PROJECT_ID.iam.gserviceaccount.com --role roles/editor

IAM のロールを付与する際には、サービスアカウントをリソースまたは ID として扱うことができる
アプリケーションでは Google Cloud サービスに対する認証のためにサービスアカウントを ID として使用する
例：
- Compute Engine 仮想マシン（VM）をサービスアカウントとして実行している場合は、プロジェクト（リソース）のサービスアカウント（ID）に編集者ロール（role/editor）を付与できる
- サービスアカウント（リソース）に対する serviceAccountUser のロール（roles/iam.serviceAccountUser）をユーザ（ID）に付与することで誰が VM を起動できるかを制御することもできる

Kubernetes

ヘルスチェック Probe

項目	Liveness Probe	Readiness Probe
目的	コンテナが"生きている"ことを確認し、異常なら再起動する	コンテナがトラフィックを受け付ける準備ができたかを確認
適用タイミング	コンテナに異常が発生した場合、再起動が必要なとき	起動直後または一時的にリクエストを受けられないとき
結果	失敗時にコンテナが再起動される	失敗時にエンドポイントから外される
例	フリーズやデッドロック状態の検出	起動中や一時的な過負荷状態の検出
失敗した場合の動作	Kubernetes がコンテナを再起動	Kubernetes がトラフィックをその Pod に送らない

Liveness Probe
- コンテナをいつ再起動するかを認識する
- バグがある Pod を再起動することでアプリケーションの可用性を高める
Readiness Probe
- コンテナがトラフィックを受け入れられる状態であるかを認識する
- トラフィックが受け入れられない Pod を Service のロードバランシングから切り離す
Startup Probe
- コンテナアプリケーションの起動が完了したかを認識する
- Startup Probe が成功するまでは、Liveness Probe によるチェックを無効する

制御パラメータ

initialDelaySeconds
- kubelet が最初の Probe を実行する前の待機時間を指定
periodSeconds
- kubelet が Liveness Probe を実行する間隔

セキュリティ関連

Binary Authorization

概要

コンテナベースのアプリケーションにソフトウェアサプライチェーンのセキュリティを提供する Google Cloud のサービス
構成したポリシに基づいてイメージのデプロイを許可またはブロックする
- 例：
  - 信頼できるコンテナのみが GKE にデプロイされるように構成できる
  - 脆弱性スキャン結果に基づく証明書を要求するルールがあるポリシを適用できる
  - 承認されたイメージのみを有効にする
  - イメージが開発環境からテスト環境、本番環境クラスタに進むマルチステージデプロイパイプラインでは、証明者を使用して、ソフトウェアが次のステージに移行する前にすべての必要なプロセスが完了したことを確認できる
ソフトウェアが内部のベストプラクティスと標準に従い、構築、テスト、リリース、デプロイされるようにすることを目的としたツール

サポートされるプラットフォーム

Google Kubernetes Engine（GKE）：Google Cloud でホストされているクラスタでイメージを実行
Cloud Run（プレビュー）：フルマネージドのサーバーレスプラットフォーム上でコンテナ化されたアプリケーションを実行
Anthos Service Mesh（プレビュー）：オンプレミスまたは Google Cloud で信頼性の高いサービスメッシュを管理
Anthos clusters on VMware：オンプレミスのデータセンターにホストされているクラスタでイメージを実行

デプロイアーキテクチャ

Binary Authorization は、次の関連プロダクトを含むデプロイアーキテクチャの一部となっている

Artifact Registry（GAR）/ Container Registry（GCR）：デプロイするイメージを格納するレジストリ
Container Analysis
- デプロイを制御するために Binary Authorization で使用できる脆弱性情報を提供
- 認証プロセスで使用される信頼できるメタデータを保存
セキュリティモニタリング：相互に関連する Google Cloud プロダクト全体のアプリケーションセキュリティを評価できるダッシュボード
Cloud Deploy：継続的デリバリを実現するマネージドサービスで、定義した順序で一連のターゲット環境へのアプリケーションの配信を自動化する