Google Cloud Platform Fundamentals: Core Infrastructure 日本語版 受講まとめ



# 受講前に

たくさん出てくるので知っておくべき用語

プロビジョニング: 必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと
レイテンシ： 遅延

# 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 の概要

クラスタ・ノード・ポッド

![IMG_0031.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/630149/ee1772c1-2fb3-25a3-02c2-b25e6843789a.jpeg)

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が格納される