Google Cloud Next 19 Tokyoのメモ

適当にメモしたので、内容には保証はありません。

### Cloud Runについて
サーバレスとは
- no infra management
- full managed security
- pay only for usage

Cloud Runの必要性
- 言語ライブラリに依存
- 特定ベンダーへのロックイン
- GPU等にアクセスできない

Knative
- k8sにFaaS/PaaSを構築
- k8s + Isito
- Build/Serving/Events

特徴
- 高速デプロイ
- サーバレス・ネイティブ
- ポータビリティ

Cloud Run
  - 使った分だけ課金
  - TLS
  - memoryのみ管理
  - public
  - not yes
Cloud Run on GKE
  - GKE上で動作
  - Memory / CPU /GPU
  - self TLS
  - VPC アクセス

将来
- カナリヤデプロイとかのためのRevision

運用
- Stackdriverと統合
- 認証済みコンテナのみのアクセス
- Autoscale

使い分けo
- イベントドリブン Function
- ナレッジの多さ: App Engine
- 値段とか: RUN 


### Data pipeline on GCP

蓄積されたデータに価値が出るよ
リアルタイムのデータも多くなるよ
- 生成も消滅も早い
- リアルタイムに処理したい

アーキテクチャ
- モバイル
- 取り込み: pubsub/kafka
- 変換: Apache beam/Dataflow/ApacheFlink/Spark
- 分析: Bigquery/BigTable/AI Platform
- 可視化: ...

Dataflow
- Managed Apache Beam
- Integrated Streaming & Batch
- portability

Apache Beam
- 使い慣れた言語で集計SDK実行できるようにしたい
- 後処理とへの流し込みをうまくやりたい

便利になったよ
- Autoscale
- python3
- モニタリング/Logging

Dataflow Streaming
- Autoscale
- 少リソース
- Tokyoでも使えるよ
- かんたんであればGUIでもOK
- 指標をStackdriverでアラート通知できるよ

Beam SQLってのがあるよ
- Pub/Subスキーマに対応

Beam-on-FlinkランナーやBeam-on-Sparkランナー
- Streaming AI作れるかも？


### 製造業の検査工程自動化
- センサーデータと観測されうる事象をを記録
- 故障は機械学習で判定
- 記録されたデータと突き合わせ


### GKEのコンテナセキュリティについて
- コンテナ化によって他のサーバへの侵入は難しくなった

k8sでの課題
- k8sアクセス、FW、ACL等が課題になるよ

コンテナ化によるメリット
- モニタリングの統一
- イメージを個別にスキャン
- イメージの署名
- サービスメッシュ

Google Infra Security
- Infra側はGoogleにおまかせすればいいよ
- 開発者はワークロードとNodeのセキュリティを考えるべし

ライフサイクルでセキュリティを考える
- コンテナイメージの変更性
- 脆弱性
- 不正侵入
- 権限の正しさ、不正アクセス

Docker Image
- プライベートなレジストリ
- 自動ビルド
- 脆弱性スキャン

デプロイ Binary Authorization
- コンテナリリース業務の標準化
- イメージの同一性検証
- レジストリの信用性

運用GKE Sandbox
- Podに防御を追加
- 攻撃を限定する
- gVisorを利用している


### Anthos
- サービスメッシュで通信元先を限定
- 他にもいろいろできる
- Istioつかってサービス間をトンネリング

Event Threat Detection
- 驚異検知
- Stackdriverログから

ユーザー・権限管理
- GKEでもIAM

何かあったら : Cloud Security Command center
- 通知してくれるよ
- Dashboard

### コスト管理について
組織リソース
- 組織
- フォルダ(プロジェクトの具グルーピング)
- プロジェクト
- ラベル(リソースのアノテーション)
- 請求先アカウント

課題
- アクセス権消失
- 請求書識別
- 請求の誤り
- 支払い遅れ
- サービス停止

権限
- フォルダに継承関係があるよ

ドメイン / 組織
- ドメイン 1-1 組織
- Google Admin Console使ってなくてもOK
- Cloud Identity使えばGSuiteつかえるよ
- 特権管理者(メンバーの管理)
- 組織管理者(GCPの管理者)
- 複数人に割り振るべきだよ
- 2factorAuth

請求先アカウント
- 組織管理者と別に設定可能
- 単一通貨の支払い
- 請求先アカウント管理者: 請求に関する全権限
- 請求先アカウントアカウントユーザー: 閲覧権限のみ
- 会計を分ける等の場合は請求先アカウントを分けるべき

プロジェクト/フォルダ/ラベル
- プロジェクト作成者: プロジェクトのオーナー
- プロジェクト編集者: コストとGCPリソースの閲覧、ラベルの追加
- 本番環境と開発環境を分離する
- 環境ごとにコストを把握
- フォルダ作成は組織構造に合わせると継承がうまく行くよ

コスト管理
- コストの可視化
  - 請求レポート
- 説明責任
  - レポート見せる、BigQueryで分析
- 予測
  - Dashboardでできるよ
- インテリジェンス
  - BigQueryにExport
  - フォルダ単位で分けることもできるよ
  - GCEだけみたい場合にLabel が役に立つよ
  - 自動的にラベル付与されてるのを使うもよし


### GKE運用
アプリケーションをクラウドネイティブにする
- クラウドネイティブ目指すならスケーラビリティを最初から考えよう
- 障害が発生することを前提にする 

GKEのメリット
- Workflowの標準化、手順の最適化の強要

Configration as Codeのメリット
- Codeレビュー可能なインフラ
- Stagingを簡単に手に入れられる
- CDできる
- Version管理
- Readiness/Liveness
- Min/Max Resource
- Autoscale


### ハイブリッドマルチクラウドでのk8s
ハイブリッドマルチクラウド
- 統合されたAPIが必要
kubenetesである理由
- 環境による差異の最小化
- 環境をあとから変更可能
- 機能差の最小化
課題
- クラスタ間のオペレーション互換
  - 管理レイヤを作って統一させるよ
- ネットワークの接続
- ストレージ
  - ステートフルなサービスが特に環境依存が多い

ステート
- DBとか
- コンテナに状態が残る必要があるもの
- アプリケーションから生成されるデータ
- Secret
- kubenetesではなるべく扱うべきではない

Storage
- storage in kubernetes
  - クラスタ上にデータを永続
- storage for kubernetes
  - kubernetesクラスタのためにストレージを準備
  - external dynamic provisioner
  - container storage interface

ステートフルワークロード
- PodからStorageを切り離す

etcd
- 必ず保護、バックアップ
- 3rd partytoolがあるよ heptio velero

secret
- hashicorpに製品あるよ


### Anthosでハイブリッドクラウド
Anthos
- ハイブリッドマルチクラウド
- フルマネージド
- オープン

ハイブリッドマルチクラウド
- 既存リソースの有効利用
- 社内ポリシーへの対応
- マルチクラウド 

フルマネージド
- 開発に集中
- Googleによるテスト
- オープン性の担保

オープン
- Google発のオープンソース
- オープンソースエコシステムを破壊しない

Anthosの目指すもの
- 柔軟性
- 競争力を享受できる
- Onpremissとクラウドを統合する


### BigQueryについて
updateが色々あるよ
メモしてないので、要確認


### Data Catalog
フルマネージド/スケーラブルなデータ検出・メタデータ管理
メタデータ: Table Column nameとか、キーとか、
対象GCPのデータをSpannerに突っ込んで、Index化？
アクセスコントロールは有効だよ
キーワード検索とファセット検索の両方