Slide 1
Slide 1 text
AWS
からGCP/GKE
に移行してみた
Web
エンジニアが使う身近な Kubernetes - 2019/09
@yukinagae
Slide 2
Slide 2 text
早速ですが
Slide 3
Slide 3 text
今日の勉強会のテーマ覚えてますか？
Slide 4
Slide 4 text
Web
エンジニアが使う
身近なKubernetes
Slide 5
Slide 5 text
ふむ (
｀・ω
・´)
Slide 6
Slide 6 text
と言いつつ難しいんでしょう？
(/
･ω
･)/
汗
Slide 7
Slide 7 text
ご安心ください
今からゆるふわな話だけします
Slide 8
Slide 8 text
というか
先々月からk8s
触り始めたので
ゆるふわな話しかできません
( ˘ω˘)
ｽﾔｧ
Slide 9
Slide 9 text
＿人人人人人人人人人人＿
＞ 圧倒的な経験不足 ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y
￣
Slide 10
Slide 10 text
優しい世界でお願いします
Slide 11
Slide 11 text
ここから本題
Slide 12
Slide 12 text
本番環境でGKE
を使い始めました！
（今日）
Slide 13
Slide 13 text
登壇に間に合ってよかった
登壇駆動開発（TDD
）(/
･ω
･)/
Slide 14
Slide 14 text
TL;DR
既存AWS
システムをGCP/GKE
化した（まず一部）
AI
チームではGCP/GKE
化を進めてる
GCP/GKE
化の理由
可用性の向上
リリースサイクルの高速化
インフラコストの削減 (
リソースの共有)
「GKE
使うぞ！」という熱い気持ち ← New!
14
Slide 15
Slide 15 text
自己紹介
永江悠紀 @yukinagae
エムスリー株式会社 ソフトウェアエンジニア
データエンジニア寄り
元々Java/Scala
でサーバサイドの開発をやっていた
最近はGo + Python
を触ることが多い
クラウド周りはGCP
のみを担当 （※AWS
はよくわ
かっていない）
terraform + yaml
を触る日々
15
Slide 16
Slide 16 text
システム移行の背景
M3
では多くのシステムをオンプレ or AWS
で構築
AI
チームではすでに複数の機械学習のサービスを
開発・リリース（※基本的にAWS
）
※詳しくはこれを見てね:
エムスリーにおける 機械学
習活用事例と開発の効率化 - Speaker Deck
16
Slide 17
Slide 17 text
多数のマイクロサービス
短い1
年半という間に7
つのサービスがリリース
現在も増加中
すごいね！(´∀｀)
17
Slide 18
Slide 18 text
ポイント
1.
サービス数（API
）が多い
18
Slide 19
Slide 19 text
今回の移行対象のシステム
Cantor
記事などのコンテンツの関連度（類似度）を計
算するシステム（API
）
※おまけ: AI
チームではシステムに数学者の名前をつ
ける文化があり（中二病！）、実際に Georg Cantor
というドイツの数学者がいます(
｀・ω
・´)
19
Slide 20
Slide 20 text
既存システム構成
GCP
BigQuery
AWS
ECS
S3
DynamoDB
Lambda
API Gateway
20
Slide 21
Slide 21 text
既存システム構成（図）
21
Slide 22
Slide 22 text
ん？ (
｀・ω
・´)
22
Slide 23
Slide 23 text
既存システムの課題①
現状のシステム構成だと、GCP/BigQuery -> AWS
と
いうクラウドをまたいだ構成になってしまっている
23
Slide 24
Slide 24 text
ポイント
2. BigQuery
とAWS
の混在
24
Slide 25
Slide 25 text
既存システムの課題②
Cantor
というシステム構成特有の課題:
Lambda
でもろもろ問題があった
15
分に一度バックエンドのECS
が停止されてし
まう（確率的にタイムアウトが発生）
25
Slide 26
Slide 26 text
既存システムの課題③（※改善点）
簡単・頻繁にリリースしたい
すぐリリースしたい（※カナリアリリース etc
）
バグなどの際すぐ以前のバージョンに戻したい
マイクロサービスが増えているので各環境を用意
するのは大変
運用や管理が面倒
インフラコストがかかる
26
Slide 27
Slide 27 text
ポイント
3.
どんどんリリースしたい
27
Slide 28
Slide 28 text
いろいろ選択肢あるよね
AWS
なら
EC2
ECS
EKS
GCP
なら
Cloud Run
GAE
（ ex
）
GCE
GKE 28
Slide 29
Slide 29 text
技術選定のポイントいろいろ
インフラコスト
運用の手間
クラウドベンダーのサービスの成熟度やマイルス
トーン
ワークロードの特性
必要なリソース要件
チーム体制（ex.
人数 /
スキル /
学習コスト）
29
Slide 30
Slide 30 text
ポイントを振り返る
1.
サービス数（API
）が多い
2. BigQuery
とAWS
の混在
3.
どんどんリリースしたい
30
Slide 31
Slide 31 text
もろもろありましたが
結局、、、
31
Slide 32
Slide 32 text
解決案: AWS/ECS → GCP/GKE
32
Slide 33
Slide 33 text
GKE
でいい感じに作れるのでは？
(
｀・ω
・´)
33
Slide 34
Slide 34 text
想定するメリット
コスト削減
複数サービスをGKE
で構築しリソース最適化
メンテナンスコストも削減（されるはず）
リリースの高速化
オーダーメイドから量産体制へ
terraform
k8s
可用性も向上
全部GCP
にできてBigQuery
もにっこり(´∀｀) 34
Slide 35
Slide 35 text
それでは早速やっていきましょう
35
Slide 36
Slide 36 text
移行方針:
どうやって移行する？
1.
まずはAPI
部分（システムの一部）からの移行
2.
段階的にすべてを移行していく
まずはAPI
部分からの移行を実施
影響範囲を小さくしたい
API
だけなら最悪どうにでもなる
もともとのAWS
ヘの切り戻しも容易
機械学習部分をいきなり移行してデグレったら
嫌だよね(/
･ω
･)/
汗
36
Slide 37
Slide 37 text
移行後の構成（API
部分のみ）
ここまでリリースできた
37
Slide 38
Slide 38 text
移行後の理想（全部GCP/GKE
化）
38
Slide 39
Slide 39 text
今後の移行方針
既存サービスのGCP/GKE
化
まずは今回のプロジェクトで導入実績を作り、
運用経験を積む
他サービスも徐々に移行していく（※移行すれ
ばするほど、インフラ・運用コストを削減でき
る）
新規サービスは最初からGCP/GKE
で構築
現在 @katio2
が開発中、年内にリリース予定
39
Slide 40
Slide 40 text
移行してみての感想
40
Slide 41
Slide 41 text
k8s
難しいよ
k8s/GKE
のノウハウが少ない（※特に運用面）
そもそもk8s
自体の学習コストが高い
ある日のtwitter
のつぶやき
41
Slide 42
Slide 42 text
つまり
Slide 43
Slide 43 text
Web engineer should be k8s itself!
Slide 44
Slide 44 text
まとめ
良かったこと
terraform + yaml
でk8s
環境構築・リリースは楽
とりあえず本番リリースはできた
悪かったこと
ノウハウや経験がないので手探り
k8s
の公式ドキュメントそのままだと動かない
GKE
はだいたいβ
版
本番運用でいろいろ問題起きると思うので怖い
（ガクブル）
44
Slide 45
Slide 45 text
ありがとうございました！
(´∀｀)
45
Slide 46
Slide 46 text
F.Y.I.
おまけ
既存のAWS
システムではdatadog
をdashboard
で使
ってたが、GCP
で使うのは辛い
PubSub
経由でdatadog
にpush
する仕組みを毎回
作らないといけない
GCP
プロジェクト毎に認証をしないといけない
の大変
datadog APM
の導入はめちゃくちゃ楽
しかし、もちろんcontainer
周りの指標しか取得
できない
46
Slide 47
Slide 47 text
stackdriver monitoring
使う理由
datadog
用に追加のintegration
作業が不要
複数プロジェクトを一つのworkspace
にまとめれ
ば、GKE
やCloud SQL
のプロジェクトが別でも1
つ
のdashboard
で監視できる
alert policy
やuptime check
もそのまま作れる
47
Slide 48
Slide 48 text
現状の運用・監視方法
GCP
の場合にはStackdriver
使うことにした
Stackdriver monitoring
での監視
alert policy
の作成 + slack
通知
dashboard
の作成
Stackdriver trace
でのパフォーマンスチェック
opencensus
入れた
Stackdriver for python
はα
版。。。(
｀・ω
・´)
汗
48
Slide 49
Slide 49 text
参考資料
GCP
Google Kubernetes Engine
Stackdriver Monitoring
OpenCensus
OpenCensus
GitHub - census-instrumentation/opencensus-
python
49
Slide 50
Slide 50 text
Special Thanks! ( ˘ω˘)
ｽﾔｧ
@kaito2
@saiya_moebius
@SassaHero
@yokomotod
@chidakiyo
50