GoogleNext2018に参加してきた
公式ブログ
Google Cloud Japan 公式ブログ
公式サイト
Google Cloud Next ’18 in Tokyo | 9 月 19 ～ 20 日、東京
2018/10/3追記：スライド公開されたっぽい
Google Cloud Platform - Japan | SlideShare
■参加日程
9/19(水) お昼すぎ〜終わりまで
■会場
東京プリンスホテル 及び ザ・プリンスパークタワー東京
■参加目的
現在クラウドでAWSを利用しているが、GCPではどこが違うのか、実際の操作方法やオススメの機能やGCPの強みが知りたくて参加。
■参加したセッション
・詳説！コロプラの大規模クラウドマイグレーション手法の紹介（途中参加）
・Kubernetes を使った継続的デリバリー 〜 GCP におけるベストプラクティス & AbemaTV における取り組み 〜
・GCP データベース移行のためのベストプラクティス（英語セッション）
・Cloud Firestore でスケーラブルなアプリケーションを開発しよう（英語セッション）
※その他デモ体験、ブース周り
詳説！コロプラの大規模クラウドマイグレーション手法の紹介（途中参加）
途中参加ということもあり全てがわからなかったが、AWSからの切り替えというよりはGCPに移行してよかった点などがまとめられていた。
良かった点
・メンテナンスフリー
・Billing
・新アーキテクチャでのゲームリリース
総じて、AWSでもできそうなことであり、大きな違いは感じられなかった。
Kubernetes を使った継続的デリバリー 〜 GCP におけるベストプラクティス & AbemaTV における取り組み 〜
1.多くの課題（ビルドテスト、ビルドの高速化、Githubからのデプロイ方法）を解決したい
→Dockerがコンテナの走りであり、当社ではKubernetesを採用している。
2.GCPのメリット
・高速、安全
→手動プロセスを排除
・フルマネージドサービス
→自動スケール、環境管理不要
・リスク低減
→脆弱性自動検知（自動スキャン）
※ソフトウェアにより脆弱性のあるデプロイはさせないということも可能。
3.利用していて便利なGCPサービスの紹介
・CloudBuild
→フルマネージドなプラットフォーム
コンテナのビルドからデプロイまで管理。
yamlで定義可能。
Github連携可能。
プルリクエストに自動で書き込みして結果がわかる
KMS→セキュリティ強化
・ContainerRegistry
→脆弱性スキャンが自動で走る
脆弱性のDB更新時に勝手にやる
・Spinnaker
→Netflixが開発したもので、現在はGoogleも開発に参加しているデプロイ管理ツール。
・CloudBuild
→Firebaseでデプロイ。コンテナを指定できる
4.AbemaTVの取り組み
ソースコードはGithubで管理し、プルリクエストを送ることが開発の主流。
テストはdrone.ioを利用しているが、スケールアップが難しいという不安要素があるため、CloudBuildに移管したい。
参考：https://drone.io/
ストレージはGCRを利用。特別な設定無しでプライベートリポジトリが使えるメリットがある。
デプロイはchatops、Slackbot利用。Slackにチャット形式で投稿すると自動でデプロイされる。
MonitorはPrometheusを利用。Kurbernetesと相性良い。
まとめ
まだ手動の作業も多いが、GKEを使うとフローが自動化しやすいので、可能な限り自動化していきたい。
GCP データベース移行のためのベストプラクティス（英語セッション）
DBの移行について
→DBの移行はどのアプリケーションにつながっているのかの調査などが必要でとても大変。
移行のタイプ
・Rehost
・Replace
・Refactor
・Revice
・Rebuild
・Redis
Redisへの移行が多い
インメモリキャッシングがよく使われている
例：低遅延を防ぐ、スループット
ユースケース
・セッションマネジメント
・ゲームなら超高速なゲーム体験など
・リアルタイ無の処理
・高速に行うもの
なぜRedisか
・キーバリューストアの機能がある
・カウンタで高速な処理
・永続性
・HAのキャッシュ
・オープンソースであり、移行が楽になる
・Memchacheでは出来ないことができる
※ただしMemcacheが向いている場合もある
新機能
・外部サーバのサポート
・最近東京リージョンも対応
Cloud Firestore でスケーラブルなアプリケーションを開発しよう（英語セッション）
CloudFirestoreのメリット
・小さいチームで大きい成果
・サーバーレス 使ったときだけ課金
・信頼性と可用性
・スケーラブル
・構造化可能、クエリ簡単
新機能
東京もこれからリージョン開始
Datastoreモード：99.9999％可用性
アップグレード：ダウンタイムなし、アクション不要、コード変更不要
NosSQLのDB
ネイティブモード：Backend as a Service バックエンドは気にしたくない人向け
100万アクセスクライアントまでスケールする
事例
ZALORA（東南アジア最大のECサイト）https://worldwide.zalora.com/
→たった3人で1億人にサービス提供している
GTMをいれて分析してCloudFirestoreでレコメンドを出すことも可能。
・スケーリングヒント
→書き込みのスケーリング
→同時接続
