# Google Cloud Next in Tokyo 2日目

# Cloud Code と コンテナツールでKubernetesを使った開発を徹底効率
コンテナはGKE一択ではない。
選択肢はGAE、CloudRun、GKEもあるのでまずはGAEもしくはシンプルに使うならCloud Runもあり。

ローカル開発を効率化について
k8sの課題はデプロイするまでにやることが多い。

## k8sにけるローカル開発の難しさ
* ソースを変更するたびに繰り返し作業が発生
* コンテキストスイッチにより生産性が低下
* k8s関連のツールを覚えるのは学習コストが高い
　* 新規メンバーとか辛いよね

## Cloud code FOR IDE
* 学習コストを削減　→　開発者は開発にフォーカスできるよ
* 選択肢はVS CodeとIntellJがある

## Skaffold
* デプロイをサポートするCLI
* k8sのデプロイではSkaffoldが動いている

## Demo
* VSCodeのコマンドパレットからClusterが作成できる
　* ウィザードが開始される。
　* 認証情報もローカルPCにも自動で展開。contextに反映してるっぽい。
* コマンドパラッとからContinuous Deployをすると、手元のコードに変更があれば自動で自動でデプロイされる。
* 保存をトリガーにしてイメージのビルドが走る。毎回ビルドやポートフォワードしたりしなくて良い。
* 左メニューからログ確認したいpodを右クリックし、Stream Logを押すとIDEの中でコンテナのログを確認可能
* コード上からスケールアウトの検証も可能。
* Get Terminalをクリックすることでコンテナの中にも入ることが可能。
* 既存のアプリケーションに対してもデプロイ設定、デバッグ設定を追加可能。

## まとめ
IDEの中でほとんどの処理を実現可能。
コンテナ上での開発繰り返し作業や学習コストといった課題があるが、Cloud code FOR IDEを使うことで効率的にできるはず。

---

# アサヒビールの挑戦 GKE採用の狙いと移行方法
会社説明とGKEの解説。具体的な技術についてあまり触れなかった。
* ビジネスをデータドリブンでやっているが、既存のオンプレミス環境だと結構つらい。スピード感が求められる。
* 既存ITベンダーから脱却。子会社は使わず、ちゃんと能力があるベンダーを選定。
* SaaSとPaaSのみで構築、インフラ運用がほぼゼロを実現
* マイクロサービス化して追加改修に柔軟に対応可能

## なぜGKEなのか
* なぜコンテナなのか
　* 軽量、ポータブル、効率性
* k8sはデファクト。今後20年のLinuxになる。
* 関心事の分離（開発にフォーカスできる）
* 基盤運用は自動運転（自動で復旧したり、オートスケールしたり、デプロイの仕組みもある）
* k8sのアップデートは頻繁に行われるがアップデートは自動でやってくれる。
* GKE On-Prem もあるよ。オンプレでもGKE動かしたい場合は使ってね。

---

# オブザーバビリティ
オブザーバビリティ(可観測性)
判断に必要な情報が取得できる状態であること。確保することが大事。

Stackdriverは、
* Loginng
* Monitoring
等すべてのあわせた製品郡

障害対応用のダッシュボードもあるよ。AWSも対応している。

## 各運用プロセスに必要なデータ
### 通常運用
全体感のわかる統計データ
SLO違反が発生した場合に備えた対策
使用サービス：StackDriver Monitoring

カスタムメトリクスを使いたい場合：import "go.opencensus.io/stat"
ログベースメトリクス：ログデータ(json)からメトリクスを生成

### 高負荷・調査
プロファイラー：CPU,メモリ、OSスレッド統計情報
分散トレース：マイクロサービス内のボトルネック

* StackDriver Profiler
* アプリケーション内の性能ボトルネックの発見

* StackDriver Trace
* 複数のサービスにまたがったトレース
* 分散トレース環境内で有効化。

### 障害対応
* Stackdriver Error Reporting
* スタックトレースのエラーを種類ごとにグルーピングし頻度を表示
* エラーの発生回数、時刻、詳細情報を確認可能。

* Stackdriver IRM (Incident Respoinse and Management)
* 障害関係のダッシュボード
* 関係する資料のリンク
* コミュニケーションチャンネルの導線
* 通知先の設定(Slack等)
* 障害ごとの役割(role)を設定できる。担当者とか
* 障害関するすべてのことをIRM上で行うことでコミュニケーションも取りやすいし、振り返りもしやすい。

### 振り返り
* Stackdriver LoggingでログをExport　→　Datastadioを使って可視化して調査可能。
* Export先は、Cloud Storage,BigQuery,Cloud Pub/Subが選択できよ。

## まとめ
* プラットフォーマーしか提供できない情報を提供
* SREの実践の共有
* GCP、Googleアカウントとの連携がやりやすい

---

# コンテナセキュリティの道
* コンテナ化することイメージを統一できる。
* イメージスキャンして、イメージの署名も可能。
* Userはアプリケーションのセキュリティを考えて。それ以外はGoogleが考えるよ。
* アプリケーションのライフサイクルをセキュアにしよう。
* コンテナイメージは変更されてないか
* 脆弱性がないか
* 不正侵入されてないか
* ユーザ権限が正しいか、不正アクセスがないか

## CI/CD・ビルド
* GCRで脆弱性のスキャン
* 検出した脆弱性の内容と重大度を表示
* Binary Authorization
* 信頼できるコンテナのみをデプロイ
* 証明書を作成して、デプロイ時に証明書をチェックできる

## デプロイ
* Binary Authorization
* コンテナポリシーを作成可能。デプロイ可能なイメージを鼓膜指定できる。

## アプリケーションの運用
* GKE Sandbox
* ポッド イヤに防御用の第 2 レイヤを追加する？
* https://cloud.google.com/kubernetes-engine/sandbox/?hl=ja
* Anthos
* GKE on premises と GCPをAnthosで管理できる
* サービスメッシュ構成の場合、アプリケーション間通信の認証をしたり
* Event Threat Detection
* Stackdriverのログを見て脅威を迅速に検出
* 脅威インテリジェンスを搭載

## ユーザー・アクセス管理
* IAMしっかりやろう
* Cloud Security Command Cneter
* すべてのプロジェクトのアラートや状況をセキュリティのダッシュボードで見える
* 例えば、Thread Detectionで検知したアラートをCommand Centerで表示したりできる。

# Google Cloud Next in Tokyo 3日目
# SRE入門
## SREとはなにか
ソフトウェアは設計や構築に重点が置かれる。しかし問題はリリース後に問題する。
開発者(アジリティ) - 運用者(安定性)という対立
SREのアプローチ
* 自動化
* ソフトウェアで実行
* 信頼性高いソフトウェアを設計

### SREチームは何をするのか
* ソリューションの開発
* スケーラビリティ、信頼性、効率性の高いソリューションを開発
* 哲学と考え方
* SREはより良い本番システムの運用を目的としたエンジニアリングアプローと
* エンジニアリングの実践とツール
* ソフトウェア開発とシステムエンジニアリングが交わるところで運用を行うことでアークテクチャを進化させる

## SREの重要な原則
### エラーバジェット
信頼性をどのように測定するのか
お客様にどのように機能しているのかを考えなければならない。
リスクを避けるのではなく、リスクをいかに管理するか。
可用性を設定する→ダウンタイムがそのままエラーバジェット。

SLOの定義と指針
目的は
* 開発の業務上の優先順位と制限を設定
* ユーザを期待を設定(ユーザをハッピーにしているのかどうか）

前提として
* 可用率100%は無理

## SREの実践
### 指標とモニタリング
* モニタリングの自動化
* アラートは、緊急呼び出しもしくは、チケットか対応する
* 人間が関与するのは、SLOの達成が危うくなったときだけ

### 需要予測とキャパシティプランニング
* 信頼性目標を達成するために十分な予備キャパシティを確保していきましょう。

### 変更管理
* 段階的なロールアウトをしましょう
* 問題があればロールバックしましょう
* 自動化によってヒューマンエラーをなくしましょう

### 変更スピーの最大化を追求
* エラーバジェットを使って開発スピードをあげていきましょう
* 目標は障害ゼロではなく、エラーバジェット内に収めること

### 緊急対応
* ものは必ず壊れる
* まずはパニックになってはいけません
* 事前にトレーニング大事。
* 手に負えないと思ったら加勢を頼みましょう

### インシデント管理
* 閾値を前もってきちんと定義しておきましょう。

### ポストモーテムの哲学
* ポストモーテム作成は罰ではない
* 文書化することで根本原因を理解し再発の可能性や影響を減らす効果的な防止策を講じる
* 犯人探しをしない。エラーはシステムの問題です。人は修正できないが、システムは修正できる。
* 犯人探しが横行すると、人々は罰を恐れて問題は表面化されない。

### チームのスキル
* ソフトウェアエンジニアとシステムエンジニアの両方を採用
* 必ずしも1人で何でもこなせる訳ではない

### SREチームへの権限付与
* エラーバジェットを行使する権限が必要あります

### まとめ

---

# Istio,k8sのカナリアデプロイ
いろんなデプロイがある
* ローリングアップデート
* ブルーグリーン
* カナリアロールアウト

カナリアロールアウトは、baseline用のpodとcandidate用のpodを設置し、
両者に同じトラフィックを流していくことで事前検証したりすることが可能。

## TEKTON
CI/CDのパイプラインをくむことができる。k8sのCI/CDプラットフォーム
TEKTONのパイプラインを使って、カナリアロールアウトが可能。
https://cloud.google.com/tekton/
徐々にcandidate用のpodへのトラフィックを増やしくいくようなmafifestを書いてパイプラインでつないでいくイメージ。
Spinnakerでも代用可能