AWSからGCP/GKEに移行してみた / From AWS to GKE on GCP

Slides for Webエンジニアが使う身近な Kubernetes 2019/09
https://m3-engineer.connpass.com/event/143295/

Transcript

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