Edited at

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化?

アクセスコントロールは有効だよ

キーワード検索とファセット検索の両方