Architecting with Google Cloud Platform
期間限定で無料になったので無料の間に全部やる
Google Platformの紹介
製品の紹介の前にクラウドコンピューティングそのものや歴史的経緯の説明
Cloud computing
On-demand self-service
Broad network access
Resource pooling
Rapid elasticity
Measured service
歴史的経緯
Physical/Colo -> Virtualized -> Serverless
GCP computing architectures
https://gyazo.com/43b9bf16a58660173fd58fe2cb900339 https://gyazo.com/43b9bf16a58660173fd58fe2cb900339
GCPのリージョンとゾーン
ゾーン
GCPリソースのデプロイ領域
リージョンという個々の地域にグループ化されている
リージョン選択
リージョン内の単一障害点ドメイン
GCPでのfault tolerantなアプリ構築手段
リソースのリージョン内の複数ソーンに分散
一部のサービスではリソースのマルチリージョン配置が可能
環境に対する責任
試験
https://gyazo.com/ac82da4b076a6f7e6a568aa0edebad90
Googleが採用・進めている多層セキュリティ
Google Cloud Platform リソース階層
ボトムアップに見ていくのがおすすめらしい
プロジェクトとフォルダの関係
プロジェクト
VM
Cloud Storage
Table
BigQuery
フォルダ
プロジェクト1
プロジェクト2
プロジェクト3
フォルダ2
プロジェクト3
プロジェクト4
組織ノードの下で全フォルダとプロジェクトがまとめられる
ポリシー
組織ノード、フォルダ、プロジェクトにまたがるポリシー
一部のGCPリソースでは個別のポリシー定義ができる
プロジェクト
GCPサービス使用の際の基本単位
設定項目
APIの管理
課金
共同編集者の追加と削除
プロジェクトごとに異なるオーナーとユーザーを作成して個別に管理できる
独立した区画
リソースは一つの区画にのみ属する
Identity attributes
Project ID
Globally unique
Chosen by you
immutable
should be human readable
Project name
Need not be unique
Chosen by you
mutable
Project number
Globally unique
Assigned by GCP
Immutable
フォルダ
flexible management
e.g.
Folders group projects under an organization
Folders can contain project, other folders, or both
Use folders to assign policies
フォルダ内のリソースはフォルダのポリシーを継承する
フォルダ作成には組織ノードが必要
組織ノード
リソースの使用状況の確認とポリシーの適用を一元的に行う
ポリシー管理者の指定
プロジェクト作成者のアサイン
G Suite
ある場合は自動的に組織ノードに属する
ない場合はGoogle Cloud Identityを使用して作成
ドメイン内の全員がプロジェクトと請求先アカウントを作成できる。
ノード作成後はこれらの操作を許可するメンバーを設定する
組織レベルで定義したポリシーは継承される
上位階層で定義されたポリシーは下位階層で付与されたアクセス権限を削除することはできない
より制限の緩いポリシーが適用される
Google Platformの操作
GCPの操作方法
API Explorer
インタラクティブにAPIを調べられる。試せる
Cloud Shell and Cloud SDK
Cloud Console Mobile App
ダッシュボードから確認
REST-based API
IAM
ユーザーへの特定のリソースへの操作権限付与
誰が
Google アカウント、グループ、サービスアカウント, G Suite、Cloud Identityドメイン
何を
IAM role
権限の集合
Primitive
プロジェクトに適用するとプロジェクトの全リソースに適用される
Owner
Editor
Viewer
Billing administrator
Predefined
Primitiveに加えて細かい権限管理を行うために使用される
Custom
Predefinedでもまかなえない用途における権限管理
どのリソースに
対して行えるかを定義
GCPにソフトウェアパッケージをデプロイするためのツール
自動設定
software
VM instance
storage
network
手動で変更可能
料金
リソースの通常料金のみ
一部Cloud Laouncherイメージは例外
起動前の月額利用見積もり表示
問題・脆弱性修正のためのソフトウェアのベースイメージ更新が入ることに注意
デプロイ後のソフトウェアは更新されないので自分で保守
Qwiklabsでのアクティビティ
https://gyazo.com/12be7b3f71af4ca530e5e75ae5965ec1
シークレットタブを開いて以降の手順もきちんと紹介されている。終わったら自動でチェックマークがついている。
Virtual Machine
最初のプロジェクトに独自のVPCを定義するかデフォルトのVPCを選んで使い始める
VPCネットワーク
GCPリソースの相互接続とインターネットとの接続を可能にする
ネットワークのセグメント化
ファイアウォールルールでアクセス制限
static route を作成してトラフィックを特定の宛先に転送できる
グローバルスコープを持つ
どのGCPリージョンにもサブネットを持てる
リージョン内の複数ゾーンをまたぐことも可能
VMインスタンスの作成にはgloudコマンドラインツールを使う
イメージはGoogleから提供されているものとカスタマイズバージョンがある
物理サーバーからイメージをインポートすることも可能
ストレージの選択
標準
SSD
ローカルSSD
一時的な領域が必要な場合に使う
Vm終了時に消去されるので
ブートイメージ
Linux
Windows
独自イメージ
常に特定の構成で起動する場合
スナップショット
バックアップ
別のリージョンへの移行時に使用
他でリソースが必要になった場合にCompute Engineがそれを終了できる
停止と再開が可能なジョブに使用するべき
オートスケーリング
負荷の指標に基づいてアプリのVM数を増減できる
仕組みの一環として着信トラフィックの負荷がVM間で分散される
Google VPCは何種類かの負荷分散をサポートしている
Google VPCの重要な機能
同じネットワーク内のインスタンス間でトラフィックを転送するためにルーティングテーブルを使用する
物理ネットワークと同じ
サブネット間やGCPゾーン間でも外部IPアドレスを使用せずに転送できる
プロビジョニング、管理不要
ファイアウォールインスタンスのプロビジョニングと管理も不要
VPCのグローバルな分散型ファイアウォールを使用してインスタンスへの送受信トラフィックを制限できる
ファイアウォールルール
インスタンスのメタデータタグを使用できる
すべてのウェブサーバにwebというタグを付ける例
ファイアウォールルールでポート80または443での受信トラフィックをwebタグが付いたVMに許可する
VPCはGCPプロジェクトに属する。
複数のGCPプロジェクトがあり、VPC間に通信が必要な場合の対処
VPC Peeringを使用
IAMで別のプロジェクトのVPCに対して誰が何の操作を行えるか制御する場合
Shared VPCを使用
VMのオートスケーリングでアプリが提供するVMの数が変わる場合
Cloud Load Blancing
完全分離
管理対象のVMで実行されない
一つのany cast IPが世界中のリージョンのバックエンドインスタンスのフロントエンドになる
負荷はリージョン間で分散される
Automatic multi region fail over
バックエンドが不調の時、トラフィックを分割して移動する
需要の急増にも自動対応
HTTPS負荷分散
Global TCP proxy load balancer
Cloud Load Balancingはインターネットから送信されるトラフィックが対象
内部ロードバランサ
プロジェクト内での負荷分散
プロジェクト内部での受信トラフィックの負荷をCompute Engine VM間に分散
Cloud DNS
Cloud Router
Direct Peering
オブジェクトストレージ
☓ フォルダの階層としてデータを管理するファイルストレージ
☓ OSがデータをディスクの塊として管理するブロックストレージ
○ データを保管するとその一連のバイトがオブジェクトとして扱われ固有のキーでデータをアドレス指定できるストレージ
キーはURL形式
Scalable
バケットで構成される
バケットを作成して構成、そこにオブジェクトを格納する
Global に一意な命名
バケットとそのコンテンツを保管する地理的ロケーションを指定し、デフォルトのストレージクラスを選択する Multi-regional
Regional
Nearline
Coldline
使ったことが有るのでこれのドキュメントは読んだことあった
ストレージオブジェクトはImuutable
編集ではなく新しいバージョンを作成する
必要に応じてバージョニングを有効にできる
バージョニングによるゴミの整理はライフサイクル管理ポリシーを使用する
e.g.
一定期間経過後に削除
指定した期間以前に作成されたものを削除
直近の3バージョンのみ残す
暗号化。追加料金なし
他のGCPサービスに移動できる
オブジェクトとバケットへのユーザーアクセス制御はCloud IAM。他にもあるが基本はそれ
roleの細かい制御を行いたい場合はACL（アクセス制御リスト）を作成する
バケットとオブジェクトにアクセスできるユーザーとユーザーのアクセスレベル
ACLの構成要素
Scope
指定の操作を実行できるユーザーの定義
Permission
実行できる操作の定義
データ取り込み方法
Cloud SDKに含まれるCloud Storageコマンド
ChromeでのGCP Consoleでドラッグ・アンド・ドロップ
TB ~ PB規模のデータの転送にはStorage Transfer Service、Offline Transfer Appliance
Transfer Appliance
ラックマウント型のストレージサーバーでGoogle Cloudからリースできる
他のリソースと密接に結合されているので他のプロダクトから利用することも多い
ビッグデータ用のNoSQLデータベースサービス
NoSQLなので、データベースエンジン自体に適用される単一のデータベーススキーマによる整合性チェックが不要なデータの格納に適している。 フルマネージド
構成や調整は不要
永遠ハッチテーブルってなんのことかと思った。英語のままの方が理解しやすいと思う
persistent hash table
この講座にはいくつかそういう部分がある
HBaseという同じOpen Source APIを通じて提供される HBaseはApache Hadoopプロジェクトのネイティブデータベース
移植ができることを意味する
Apache HBaseインストール環境ではなくBigTableを選択するメリット
スケーラビリティ
管理タスクの透過的な処理
保存時及び処理中の暗号化
IAMを使用したユーザー制御
GCPエコシステムの一部である恩恵
他のGCPサービスやサードパーティクライアントとの連携
NoSQLに対するRDBの利点
スキーマによるデータの一貫性と正確性
トランザクション
Cloud SQLはRDBの設定、保守、管理の手間をうまくやってくれる
Cloud SQLのMySQLとPostgreSQLはβ版なのか……
大抵はCompute Engine VM内で独自のデータベースサーバーを実行している
Cloud SQLのこれに対する利点
複数のレプリカサービスの提供
データのバックアップ
垂直スケーリング
マシンタイプの変更
水平スケーリング
リードレプリカ
セキュリティ
Cloud SQLインスタンスのネットワークファイアウォール
暗号化
他のGCPサービスとの連携
Cloud SQLで対応できない場合に検討すべきなのがCloud Spanner
ユースケース
リレーショナルデータベースの容量を超えた場合
高スループットを得るためにシャーディングする場合
トランザクションの整合性、グローバルデータ、強整合性が必要な場合など
tanabe.icon使うことなさそう
GCP NoSQLデータベースの一つ
App Engineアプリの構造化データの格納が主な用途
App Engine とCompute Engine をまたぐソリューション構築の際の統合ポイント
フルマネージド
Cloud Bigtableと異なる点
複数のデータベース行を対象としたトランザクション
SQL likeなクエリ
無料割当
小規模オペレーションに向く
インフラの面倒な作業を省ける点でIaaSと似ている
developerのニーズを念頭に構築されているという点でPaasにも似ている
コンテナ
Paasのようなワークロードの独立した環境によるスケーラビリティとIaas環境のようなOSとハードウェアの抽象化層を提するもの
コードとその依存関係が存在する見えないボックス
ファイルシステムとハードウェアの独自のパーティションにのみアクセスできる
新しいプロセスとして起動する。OSインスタンスの起動にかかる時間よりずっと早い
基本的にはハードウェアでなくOSの仮想化
micro servicesのアーキテクチャに則って構成されたコンテナが具体例として紹介
各コンテナ内のコードの通信方法
ネットワークファブリック
Container orchestrator
API
許可されたユーザーのみが複数のユーティリティを使ってオペレーションの制御ができる
e.g.
kubectl コマンド
クラスタ
一連のノード
ノードはコンピューティングインスタンス。
Google CloudではCompute Engine内で実行されるVM
マスターコンポーネントのセット
システム全体とコンテナを実行する一連のノードをコントロールする
コンテナをデプロイする
ポッド
抽象化層
この中にコンテナや一連の関連コンテナをデプロイする
Kubernatesの最小デプロイ単位
クラスタで実行中のプロセスようなもの
自動的にネットワークを共有し共通のディスクストレージボリュームを使用できる
固有のIPアドレスとポートが割り当てられる
ポッド内のコンテナ同士はローカルホストネットワークインターフェースで通信
デプロされているノードは認識されない
Deployment
同じポッドのレプリカのグループ
ノードのいずれかに障害が起こってもポッドの実行状態を保つことができる
Deploymentにはアプリの一部、または全体を含められる
Deployment内のポッドを一般公開にはロードバランサに接続する
KubernatesがServiceを作成。そこに固定のIPアドレスを設定
Service
Kubernatesで負荷分散を表す表記手法
Kubernatesに対してPublic IP Addressで外部ロードバランサをServiceに接続するように指定してクラスタの外部からアクセスできるようにする
GKEではネットワークロードバランサとして作成される
Compute EngineがVMに提供するマネージド負荷分散サービスの一つ
厳密には、一連のポッドグループ化して安定したエンドポイントを提供するもの
構成ファイルを使うのがベター
コマンドでも可能
Update strategy
ローリングアップデート
新しいバージョンの各ポッドを作成し使用可能になるのを待ってから古いバージョンのポッドを破棄するkubectl get services
クラウド内のフルマネージドサービスとしてのKubernates
コンテナ化アプリを簡単に実行できるがクラスタが取得する方法がない。
保守が必要
ハードウェア上で自分で作成
VMを提供する環境
GCP ConsoleでKubernatesクラスタを作成できる
保守不要
GCPのAPI管理ツール
Cloud Endpoints
デプロイが容易なプロキシを使用して必要な機能を実装
APIコンソールによる管理
GCPで実行されるアプリをサポート
Apigee Edge
APIプロキシを開発・管理するためのプラットフォーム
レート制限、割当、分析などに重点を置く
GCP外部のバックエンドサービスにも対応する
レガシーアプリの分解に使われる
Gitインスタンスの保守の手間を省く
コードの公開をGCPプロジェクトに制限する
いつも使ってるのでメモすること特に無し
環境設定
目的とする環境の仕様に対してテンプレートを用意する
Declarative
テンプレートファイルを作成してYAML、Pythonを使用して必要なコンポーネントを記述する
Cloud Source Repositoriesでバージョン管理
モニタリング、ロギング、診断
シグナルにアクセス
infrastructure platform, VM, container, middleware, application layer, log, etc
チェック対象
サービスのエンドポイント
ログのエクスポート
Error Reporting
Trace
URLごとの統計レポートの作成
デバッグに役立てる
アプリ内にログステートメントを記述するのではなく本番環境データをソースコードに関連付けて本番環境の任意のコード位置でアプリの状態を調べられるようにする
tanabe.icon簡単に言ってるけどどうやってるのか気になる
Cloud Source Repositoriesなどに保管してソースコードが使用できる場合に行えるらしい
Google Cloudが提供するビッグデータソリューション
統合サーバーレスプラットフォーム
ジョブを実行するインスタンスのプロビジョニングが不要
ユースケース
データセットのサイズが明らかな場合
クラスタサイズを自分で管理する場合
汎用ETLツール
ユースケース
リアルタイムデータやデータのサイズとレートが予測できない場合
作成したデータパイプラインをバッチデータとストリーミングデータの両方に適用できる
リソース管理の自動化
クラスタの起動、インスタンスのサイズ変更は不要
ユースケース
Dynamic pipelineではなく膨大なデータを探索してデータを実行したい場合に膨大なデータセットに対するアドホックなSQLクエリが必要
フルマネージドのanalytics dataware house
従量課金モデルを利用できる
データ取り込みが容易
Cloud Storage 、Cloud Datastore
ストリーミング
Cloud Dataflow、Hadoop、Sparkを使ったデータの読み書き
毎月の無料割当がある
クエリとデータストレージの料金が別
構築した個別のアプリ間でメッセージを送受信できる
アプリがメッセージをPublishすると一つ以上のSubscriberが受信する
機械学習に関して提供されているAPI
Cloud Vision API
Cloud Speech API
Cloud Translation API
Cloud Video Intelligence API