Google Cloud Next 2019 聴講メモ
こんにちは。
先日、Google Nextに行ってきて、何個かセッションを見たので、それらの聴講メモです。
それなりに自分でも理解できた点が多くて、割と嬉しかったのが今回です。
Cloud CodeとコンテナツールでK8sを使った開発を徹底効率化
- 岩成祐樹
- Google Cloud
- カスタマーエンジニア
container or k8s
コンテナを用いた選択肢
- GAE(source base)
- Cloud Run (container base& serverless)
- GKE(container base)
k8sを使ってローカル開発を効率化
- 開発者はコードにフォーカスしたいがやることがたくさんある
- インフラ管理
- OS
- middle ware
- monitoring
- etc...
- インフラ管理
k8sを用いた開発の難しさ
- painful deployment cycle
- ソースの修正のたびに繰り返し作業が発生
- context switch
- ブラウザ、IDE等の移動で生産性↓
- high learning cost
- 全部は把握しきれない(k8s自体の開発がかなり早い)
- チームとして把握していることが望ましいがなかなか難しい
Cloud Code
- コードにフォーカスしてできる
- IDEで一元管理
- deploy
- debug
- Pod管理
- etc
- IDEで一元管理
特徴
- k8sの開発サイクル
- バックエンドではskaffold
- デバッグ
- クラスター管理
- podの状況
- YAMLの修正の可視化
- 反映させなくてもわかるようになっている
- テンプレートと編集支援
- deployment, debugが用意されたテンプレートから作成できる
- エコシステムとの統合
- 新規のプロダクトに対してのキャッチアップの時間を削りたい...!
- GCPとの統合
- 自動で認証情報を登録される(./kube/config)
- deployの選択肢
- ワンショットのデプロイ
- 継続的デプロイ(ソースの変更を検知してデプロイ)
- GKEだけじゃなくて、EKSやAKSも操作できる！
skaffold
個人的ToDo
- skaffold
Cloud Run ~Knativeを使った新しいサーバーレス
そもそもserverlessって?(Googleの定義)
- no infra management
- インフラの管理はユーザーでは行わない
- fully managed security
- Google側でセキュリティ問題が完結している
- pay only for usage
- 従量課金制
googleのサーバーレスコンピュート
- Functions
- App engine
- Cloud Run
why Cloud Run?
- Cloud Run以外で起こる問題点
- 使用できる言語、ライブラリに制約
- ベンダーロックイン
- GPU/TPUなど特定のハードへのアクセスができない
- 解決のために
特徴
- 高速なデプロイ
- ステートレスなコンテナ
- 高速に0から無限にスケール
- 数秒でデプロイ
- サーバーレスネイティブ
- コードに集中できる
- ランタイムの制約がなくなる
- コードに集中できる
- 高いポータビリティ
- コンテナベースのため
- Knativeベースであれば他ベンダーでも使える
2つのCloud Run
２つの対比としてはこちらがよくわかりやすい(らしい)
リソースモデル
- Service
- Cloud Runの主リソース
- Service毎にエンドポイントを提供
- Revision
- デプロイする毎に生成される
- デプロイされるとリクエストが割り振られる
- Container Instance
ユースケース
- 外部サービス公開
- IAMをつかってプライベートにアクセス
- 非同期タスク
- Cloud Schedulerを使って定期的に呼び出す
- DB接続
なぜ高速にデプロイできるのか
- gVisorを使っている
- システムコールを阻害
- concurrencyを使ったリソース消費とコストの最適化
- Stackdriverとの連携
- Monitoring
- logging
- error reporting
どうサーバーレスを使い分ける？
- Functions
- ソースベース
- イベントドリブン
- App Engine
- ソースベース
- １プロジェクトにつき１リージョンの制約
- Cloud Run
- コンテナベース
- ランタイム制約・ロックインなし
まとめ
- Cloud Runはコンテナをサーバーレスに使える
- 様々な制約がない(言語、ランタイム)
個人的に調べたいToDo
- gVisor
- Cloud RunとCloud Run on GKEの対比
AIと量子コンピューターで開く、新たなビジネスの可能性 (ML+量子コンピュータ 実用化が進む世界)
- 最首英裕
- Groovenauts CEO
- 世界で唯一商用ベースで量子コンピューターを使っている会社
Goovenautsのプロダクト ~MAGELLAN BLOCKS~
- 機械学習の予備知識なしで高度なデータ分析や予測をできるようにしてきた
- やりたいことがあれば簡単に機械学習を利用できる
- 応用例
- コールセンターにかかってくるコール数の予測
- コンビニの地域による売り上げ予測
- これから建てるコンビニがどれくらい売り上げられるか
- etc...
機械学習を進めると...
- 機械学習をやればやるだけ、最適化が必要になることがわかってくる
- 事例が溜まってきて機械学習の応用例がたくさんある
- 解決した課題の先の課題に業を煮やすことが増えてきた
- コールセンターのリソース管理までは考えられない
Beyond AI
AI x 量子コンピューター
量子アニーリングタイプのコンピューター
課題解決のために
- 世の中の課題をエネルギー式に変換する
- 微妙なニュアンスを式で変更することができる
- 条件を追加したり、除去の追加がしやすい
子どもに繋げる
- 運営しているTech Parkの子どもたちに簡単にAIを体験してもらえる仕組み
- scratchにAIの拡張とか入れてより遊べるようにしている
- 発想がすごい(らしい)
- scratchにAIの拡張とか入れてより遊べるようにしている
GKEによるコンテナセキュリティの道
- Ian Lewis
- Developer advocate
アプリ運用今昔
コンテナを導入する前
- 特定のサーバーにデプロイ
- 言語別のパッケージング
- ファイルコピーしてアプリを再起動
- ほとんどが手動
- セキュリティ
- ファイアウォールで守っていたとしても、超えられたら基本的には丸見え状態
コンテナの構成
- どのサーバーにどのコンテナをデプロイするかk8sに任せる感じ
- 仮に1コンテナを攻撃されても他のコンテナに移られにくい
コンテナ導入のメリット
- 仮に1コンテナを攻撃されても他のコンテナに移られにくい
- コンテナの中身関係なくリリース方法が一緒
- ステップが少ないので自動運用しやすい
コンテナ導入によるセキュリティの課題
- k8sへのアクセス権限の管理
- ファイアウォール
- セキュリティの新しい可能性
- 統一したモニタリング
- イメージスキャン
- イメージ署名
- サービスメッシュ
Googleのインフラセキュリティ
- 責任共有モデルに示されるように、各サービスに責任分界点がある
- サーバー自体は物理的に防いだり、一部の社員しかデータセンターに入れないようになっている
- ユーザーのアカウントは、原則Google社員でもさわれないようになっている(ユーザー側の許可が必要)
アプリのライフサイクルをセキュアに
CI/CD・ビルド
Google Container Registry
- Dockerコンテナイメージを保存・管理・保護する
- 安全なプライベートリポジトリである
デプロイ
Binary Authorization
- 信頼できるコンテナのみをGKEにデプロイ
- コンテナのリリース業務標準化
- 予防的なセキュリティ対策
- 脆弱性があるものについてはそもそもデプロイできないようにする
- Docker Hubのイメージも使えないようにすることができる
アプリ運用
GKE Sandbox
Anthos
- アプリの最新化(モダナイゼーション)
- ポリシーとセキュリティを大規模に自動化する
- 一貫性のある体験
- オンプレでもクラウドでも環境に整合性を持たせることができる
- サービスメッシュ
Event Threat Detection
- GCP環境に存在するセキュリティの脅威を検出
- クラウドベースの脅威を迅速に検出
- 業界トップの脅威インテリジェンスを搭載
ユーザー・アクセス管理
Cloud IAM
- ユーザーが何をできるかを細かく指定できる
- 企業のID管理を簡素化
- 適切な役割
- きめ細かいリソース制御
Cloud Security Command Center
- GCP用の包括的なセキュリティ管理とデータリスクプラットフォーム
- クラウドデータやサービスの可視化と制御により脅威を防止
個人的ToDo
- Envoy
- gVisor
- Istio
