適当にメモしたので、内容には保証はありません。
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化?
アクセスコントロールは有効だよ
キーワード検索とファセット検索の両方