受講前に
たくさん出てくるので知っておくべき用語
プロビジョニング: 必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと
レイテンシ： 遅延
GCPのリージョンとゾーン
Compute Engineを使ってGCPでVMを起動するとVMは指定したゾーンで稼働する。
ゾーンはGCPデータセンターのように 思われているが、正確にはそうではない。 （ゾーンは１つの建物と 対応するわけではないから）
ただしそのように見ても構わない
環境に対する責任
2007年以来 Googleは100％カーボンニュートラル。近いうちにデータセンターの電力は100％再生可能エネルギーになる。
GCPのリソース階層
組織レベルで設定したポリシーは自動的にすべての子プロジェクトに継承される。
プロジェクト内のすべてのリソースがポリシーを継承する。
階層の上位で実装されたポリシーがそれより下位で付与されたアクセス権限を削除することができない。
ex)
プロジェクトでCloud Storageバケットの変更権限が付与されているとします
しかし組織レベルのポリシーで許可されているがバケットの変更ではなく表示の場合、より制限の緩いポリシーが適用される
VPCネットワーク
VPCネットワークが グローバルスコープを持つ
ネットワークはグローバルリソース、サブネットはリージョンリソース
Compute Engine
永続ストレージは標準とSSDの2種類から選択できる。
プリエンプティブルVM
通常の Compute Engine VMと違い、他でリソースが必要になった場合にCompute Engineがそれを終了できる。プリエンプティブルVMでは費用を大幅に節約できる。停止と再開が可能なジョブに適している。
VPCの重要な機能
ウェブアプリの負荷をリージョン間で分散する場合はHTTPS負荷分散を使用。
HTTP以外のSSLトラフィックはグローバルSSLプロキシロードバランサ
SSLを使用しないTCPトラフィックはグローバルTCPプロキシロードバランサ
多層アプリケーションの一部を構成する複数のバックエンドVMにトラフィックの負荷を分散させたい場合はリージョン内部ロードバランサ
オンプレ環境とインターネットをしようしない通信をしたい場合
ダイレクトリアリングが候補。ただしSLA対象外
高い稼働率が必要な場合はDedicated Interconnectを使用。SLA 99.99%
Cloud Storage
AWSでいうS3
高パフォーマンス
- Multi-Regional
- 地理的冗長性が高くなる
- 可用性 99.95%
- Regional
- 安価。
- だが冗長性は低い
- 可用性 99.9%
バックアップとアーカイブ用
- Nearline
- 可用性 99%
- データアクセスに費用がかかる。
- Coldline
- 可用性 99%
- 年に１度程度しかアクセスしないデータの保管に最適
- 90日の最小保存期間あり
- データアクセスに費用がかかる。Nearlineより高い
- １オペレーションあたりの費用も高め
Google Cloud Bigtable
NoSQL
HBaseと同じオープンソースAPIを介して提供
同じAPIを使っているのでHBaseとBigtableの間でアプリの移植が可能
Bigtableではマシンの数を増やすだけでスケールできる。ダウンタイム必要なし
Bigtableはアップグレードや再起動などの管理タスクを透過的に処理する
Bigtableが適しているのは単一の参照キーを持つデータ
読み書きの多い分析データの格納に最適
Google Cloud SQL と Google Cloud Spanner
リレーショナルデータベース
Cloud Spannerを検討するのは
- リレーショナルデータベースの容量を超えた場合
- 高スループットを得るために シャーディングする場合
- トランザクションの整合性、グローバルデータ、強整合性が必要な場合
- データベースを強化する場合
金融アプリや在庫管理アプリなどのユースケースに適している
Google Cloud Datastore
高可用性と耐久性を兼ね備えているため自動でスケールして負荷に対処
Cloud Bigtableとは異なり複数のデータベース行を対象としたトランザクションも実行可能
SQLのようなクエリも可能
半構造化データの格納に最適。GAEアプリとの組み合わせがGOOD
AWSのDynamoDBに近い？
Kubernetes と GKE の概要
クラスタ・ノード・ポッド
Deployment内のポッドを一般公開するにはロードバランサを接続する
GKEではこうしたロードバランサは ネットワークロードバランサとして作成される
Serviceは安定したエンドポイントを提供する
Kubernetesの真の強みは宣言型。コマンドを実行する代わりに 構成ファイルを使用
Hybrid and Multi-Cloud Computing (Anthos) の概要
ハイブリッド/ マルチクラウドアーキテクチャ
システムインフラの一部オンプレミスに維持したまま他の部分をクラウドに移行できる
オンプレミス、クラウド、複数のクラウドでも ネットワーク全体で整合性を維持できる
ネットワーク内のクラスタはオンプレミスでもクラウドでもコンテナ化アプリの同じリポジトリにアクセス可能
Stackdriverで１つのダッシュボードですべての環境をモニタリングできる
Google App Engine スタンダード環境
スタンダード環境ではコードの制限があり 「サンドボックス」でコードが実行される
これはハードウェア、OS、物理的なサーバーの場所に依存しないソフトウェア構成概念です
サンドボックスの制限
- ローカルファイルシステムに書き込めない
- アプリが受信するすべてのリクエストは60秒でタイムアウトする
GAEは複数アプリ動作可能
https://qiita.com/spica88/items/28e643f124e3772f8a20
Google App Engine フレキシブル環境
App Engineを実行するコンテナを指定
アプリはCompute EngineのVM上のDockerコンテナ内で実行される
App Engineが Compute Engine VMを管理する
App Engineフレキシブル環境は GAEスタンダード環境とGKEの中間に位置するもの
App Engine環境ではコンテナを目的を達成する手段として扱う
Kubernetes Engineでは コンテナは構築の基盤になる
Google Cloud Endpoints と Apigee Edge
APIを管理するもの
Google Cloud Endpoints
- APIコンソールの使いやすい インターフェースで機能を管理
- GCPで実行される アプリをサポート
Apigee Edge
- レート制限、割り当て、分析などの ビジネス的な問題に重点を置いている
デプロイメント: コードとしてのインフラストラクチャ
Deployment Manager
YAMLマークアップ言語またはPythonを使用して環境に必要なコンポーネントを記述する
AWSの CloudFormation に相当する
Cloud Dataproc
データセットのサイズが明らかな場合や クラスタサイズを自分で管理する場合に役立つ
Cloud Dataflow
リアルタイムのデータや データのサイズとレートが予測できない場合に役立つ
リソース管理を 完全に自動化
BigQuery
膨大なデータを探索してデータを実行したい場合に有効
膨大なデータセットに対する アドホックSQLクエリが可能
Cloud Pub/Sub と Cloud Datalab
Cloud Pub/Sub
リアルタイムのイベントを扱うメッセージングサービス
ストリーミングデータを分析する場合 Cloud DataflowとPub/Subを 組み合わせて使用するといい感じ
Cloud Datalab
Datalabを起動すると すぐに使える インタラクティブなPython環境が提供される
管理作業もしなくていい
その他
- Cloud Shellでは環境変数「$DEVSHELL_PROJECT_ID」に常にプロジェクトIDが格納される