特徴 †
- Cloud Shell
- OS バージョンは Debian 8,9 ($ cat /etc/debian_version)
- docker バージョンは 17.05.0-ce
- Cloud SQL
- GCE -> Cloud SQL (第2世代) 接続する際は Cloud SQL Proxy を介して暗号化 (TLS) 通信を実施
- GCE 側の MySQL Client は GCE 内の Proxy と接続し Cloud SQL 側の Proxy と Proxy 間で API 通信を実施
- Proxy on GCE <-> Proxy on SQL の通信は tcp/3307 (デフォルトの 3306 ではない) で実施
- 事前に GCE インスタンスに Cloud SQL API を許可する必要あり
- Cloud Datastore
- 各エンティティ (データ, 行) を特定する Key として 'ID' と 'Parent' というプロパティ (列) が存在
- 'ID' と 'Parent' の組み合せが Kind 内でユニークになれば良いので 'Parent' が異なれば 'ID' の重複はOK
- 多数の Kind をまたがってエンティティをグループ化するエンティティグループという概念あり
- 例) Organization, User, Mail という Kind が存在した場合に任意のユーザーの組織・ユーザー・メールを Kind をまたいでグループ化可能
- エンティティグループ (Ancestor パス) は Parent プロパティにて定義
- GAE 環境では NDB クライアントライブラリの使用が推奨
- NDB では OR マッピング機能を提供
- GAE 環境では Memcache 機能が提供されており NDB は Memcache を用いて Datastore にアクセス
- Memcache の利用は透過的に行われるためユーザーは意識する必要はない
- Datastore では全ての検索処理がインデックステーブルを参照して行われるため事前にインデックス作成が必要
- SELECT 文で単一のプロパティを WHERE 句の条件に指定する場合はインデックスを作成する必要はない
- WHERE 句に複数のプロパティを含む条件指定する場合は事前に index.yaml にてインデックスを定義する必要あり
- Datastore の仕様上、複数の不等号条件のプロパティを指定した検索は不可
- App Engine
- cron ジョブ、タスクキュー、セキュリティスキャンなどの機能あり
- セキュリティスキャン: 外部からのアクセスをエミュレーションしてセキュリティチェックをする機能 (手動実行 or 定期的に自動実行)
- 1つのプロジェクトに対して1つの Web アプリケーションが対応
- 1つの Web アプリケーションを複数の「サービス」に分割してマイクロサービス型の設計を行うことは可能
- Web アプリケーションの URL はデフォルトで https://<プロジェクトID>.appspot.com が割当て
- サービスの URL は https://<サービス名>.<プロジェクトID>.appspot.com が割当
- 各サービスのバージョン管理が可能
- gcloud app deploy で Web アプリをデプロイすると自動的に新規バージョンが作成される
- デフォルトでは gcloud app deploy 時に新バージョンがアクティブに切り替わる
- 事前に gcloud config set app/promote_by_default false と設定変更すれば自動的にはアクティブなバージョンが切り替わらない
- アクティブなバージョンを切り替えるにはトラフィック分割を行う
- 各バージョンに流すトラフィック割合を100%にすると完全に切り替わる
- IPアドレス、Cookie、ランダムな基準によりトラフィック分割が可能
- バージョン名を指定してデプロイが可能 (gcloud app deploy -v version_name)
- バージョン名を例えば dev001, dev002, stg001, prd001 等とすれば DEV / STG / PRD 環境を管理することが可能
- Machine Learning Engine
- TensorFlow コードの最適な実行環境
- 学習処理の間のみ計算ノードが割当てられ課金対象となる
- オプションで GPU が利用可能
- MLE で学習を行う際には Cloud Storage を介してデータ (スクリプト一式, 学習データ) のやり取りを行う
- 学習処理が終わった段階でモデルの構造と最適化されたパラメータ値を含むバイナリが GCS 上に出力される
AWS との違い †
- アカウント
- GCP: 課金アカウント <-- 紐付け --> プロジェクト >> ユーザー, IAM, VPC 等の各リソース
- AWS: アカウント (カード情報と1対1) >> ルート >> ユーザー, IAM, VPC 等の各リソース
- "プロジェクト" の概念が AWS には無い (プロジェクト単位でアクセスコントロールや API 認証が可)
- IAM
- AWS の IAM エンティティ: グループ / ユーザー / ロール (アカウント毎)
- GCP の IAM エンティティ: グループ / ユーザー / ドメイン / サービスアカウント (プロジェクト毎)
- 各 IAM エンティティに対して "役割" という形で権限を付与
- 基本の役割としては "オーナー (roles/owner)" "編集者 (roles/editor)" "閲覧者 (roles/viewer)" が存在
- AWS の IAM ロールの代わりに GCP では サービスアカウントの概念
- サービスアカウントは各リソースオブジェクト毎に自動生成
- Cloud Shell
- Cloud Shell の使い勝手が非常に良いため Terminal クライアントソフト不要
- Chrome ブラウザでほとんどの作業が完結
- キーペアの管理等が煩雑にならずに非常に楽 (鍵管理がほぼ不要)
- セキュリティ観点で保護するべきは鍵ではなく Google アカウント
- gcloud, gsutil, kubectl 等の CLI を実行可能
- AWS CLI は GUI 操作の代替手段の印象だが GCP では Cloud Shell の存在により CLI が気軽に実行できるため GUI 操作の補完的役割を担っている印象
- Compute Engine
- 内部 DNS が自動的に割り当てられるがプライベート IP に依存しない
- スナップショットからの復旧等でインスタンスが変更になった場合もホスト依存処理や制御に影響しない
- EC2 の内部 DNS はプライベート IP アドレスに基づいた名称が付与される
- Cloud Storage
- ストレージクラスとして "Regional" に加えて "Multi-Regional" も選択可
- S3 は "Regional" のみ (リージョンサービス)
- ファイアーウォール (パケットフィルタリング) の方法
- AWS は "セキュリティグループ"
- GCP は "ファイアーウォールルール" と "タグ" により実現
- GCP の "ファイアーウォールルール" では "許可" に加えて "拒否" も指定可
- VPC ネットワーク
- ゾーンを跨いだ単一のサブネットを構成可能 (Subnet Network)
- リージョンを跨いだ単一サブネットも構成可能 (Legacy Network) * gcloud コマンドでのみ設定可
- 恐らく AWS では仮想ネットワークの "コントロールプレーン" がリージョン単位なのに対して GCP ではグローバルで一元的に管理
- グローバルで仮想的な単一ネットワーク構成が可能なため他サービスコンポーネントも AWS と比較してゾーン・リージョン非依存が多い印象
- 共有 VPC の概念:共有 VPC ホストプロジェクト >> 共有 VPC サービスプロジェクト
- スナップショット / イメージ
- AWS: Snapshot -> AMI
- GCP Snapshot -> Disk -> Image -> Instance Template -> Instance Group
- Instance Template は Image にファイアーウォールのタグ付や SSH 認証鍵、API 認証設定等の起動時設定をプロビジョニングしたもの
- Instance Group は Instance Template を元にインスタンスをゾーン配置 (シングル or マルチ) 、インスタンス数、自動スケーリング設定等を行いインスタンスを作成するオプション
- Instance Group の作成を行うと自動的に VM (インスタンス) が起動する
- Instance Group 内のインスタンスに対して Rolling Update が可能
- Managed Instance Group 内の VM を個別に停止 / 削除してもインスタンスは自動的に再起動 / 再作成される
- Load Balancer
- UDP 負荷分散にも対応 (Azure Load Balancer も UDP 負荷分散に対応)
- 1つの固定 IP で世界中のリージョンに負荷分散可 (Global Load Balancing)
- AWS の Network Load Balancing (NLB) では各 VPC サブネット毎に単一の固定 IP が保有可能
- Cloud Datastore
- Global Query は Eventual Consistency (結果整合性) が適用
- Ancestor Query は Strong Consistency が適用
- Global Query はある Kind に含まれる全てのエンティティを対象に検索する
- Ancestor Query は検索範囲を特定のエンティティグループ内に限定する
- Amazon DynamoDB は Eventual Consistency (結果整合性)
- スキーマ名称比較 (Datastore : DynamoDB): Kind ≒ Table / Entity ≒ Item / Property ≒ Attribute
- Stackdriver
- GCP だけでなく AWS のリソースに対するモニタリングも可能
- エージェントイストールすることで OS の syslog も収集・ダッシュボード上で確認可能
- 監視項目は???
- 相当サービスなし
- ElastiCache (GAE 環境向けの Datastore では Memcache 機能提供)
- CodeDeploy (代替手段として Jenkins on GCE を利用)
|