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
   

   View Slide

2. 早速ですが
   

   View Slide

3. 今日の勉強会のテーマ覚えてますか？
   

   View Slide

4. Web
   エンジニアが使う
   身近なKubernetes
   

   View Slide

5. ふむ (
   ｀・ω
   ・´)
   

   View Slide

6. と言いつつ難しいんでしょう？
   (/
   ･ω
   ･)/
   汗
   

   View Slide

7. ご安心ください
   今からゆるふわな話だけします
   

   View Slide

8. というか
   先々月からk8s
   触り始めたので
   ゆるふわな話しかできません
   ( ˘ω˘)
   ｽﾔｧ
   

   View Slide

9. ＿人人人人人人人人人人＿
   ＞ 圧倒的な経験不足 ＜
   ￣Y^Y^Y^Y^Y^Y^Y^Y^Y
   ￣
   

   View Slide

10. 優しい世界でお願いします
    

    View Slide

11. ここから本題
    

    View Slide

12. 本番環境でGKE
    を使い始めました！
    （今日）
    

    View Slide

13. 登壇に間に合ってよかった
    登壇駆動開発（TDD
    ）(/
    ･ω
    ･)/
    

    View Slide

14. TL;DR
    既存AWS
    システムをGCP/GKE
    化した（まず一部）
    AI
    チームではGCP/GKE
    化を進めてる
    GCP/GKE
    化の理由
    可用性の向上
    リリースサイクルの高速化
    インフラコストの削減 (
    リソースの共有)
    「GKE
    使うぞ！」という熱い気持ち ← New!
    14
    

    View Slide

15. 自己紹介
    永江悠紀 @yukinagae
    エムスリー株式会社 ソフトウェアエンジニア
    データエンジニア寄り
    元々Java/Scala
    でサーバサイドの開発をやっていた
    最近はGo + Python
    を触ることが多い
    クラウド周りはGCP
    のみを担当 （※AWS
    はよくわ
    かっていない）
    terraform + yaml
    を触る日々
    15
    

    View Slide

16. システム移行の背景
    M3
    では多くのシステムをオンプレ or AWS
    で構築
    AI
    チームではすでに複数の機械学習のサービスを
    開発・リリース（※基本的にAWS
    ）
    ※詳しくはこれを見てね:
    エムスリーにおける 機械学
    習活用事例と開発の効率化 - Speaker Deck
    16
    

    View Slide

17. 多数のマイクロサービス
    短い1
    年半という間に7
    つのサービスがリリース
    現在も増加中
    すごいね！(´∀｀)
    17
    

    View Slide

18. ポイント
    1.
    サービス数（API
    ）が多い
    18
    

    View Slide

19. 今回の移行対象のシステム
    Cantor
    記事などのコンテンツの関連度（類似度）を計
    算するシステム（API
    ）
    ※おまけ: AI
    チームではシステムに数学者の名前をつ
    ける文化があり（中二病！）、実際に Georg Cantor
    というドイツの数学者がいます(
    ｀・ω
    ・´)
    19
    

    View Slide

20. 既存システム構成
    GCP
    BigQuery
    AWS
    ECS
    S3
    DynamoDB
    Lambda
    API Gateway
    20
    

    View Slide

21. 既存システム構成（図）
    21
    

    View Slide

22. ん？ (
    ｀・ω
    ・´)
    22
    

    View Slide

23. 既存システムの課題①
    現状のシステム構成だと、GCP/BigQuery -> AWS
    と
    いうクラウドをまたいだ構成になってしまっている
    23
    

    View Slide

24. ポイント
    2. BigQuery
    とAWS
    の混在
    24
    

    View Slide

25. 既存システムの課題②
    Cantor
    というシステム構成特有の課題:
    Lambda
    でもろもろ問題があった
    15
    分に一度バックエンドのECS
    が停止されてし
    まう（確率的にタイムアウトが発生）
    25
    

    View Slide

26. 既存システムの課題③（※改善点）
    簡単・頻繁にリリースしたい
    すぐリリースしたい（※カナリアリリース etc
    ）
    バグなどの際すぐ以前のバージョンに戻したい
    マイクロサービスが増えているので各環境を用意
    するのは大変
    運用や管理が面倒
    インフラコストがかかる
    26
    

    View Slide

27. ポイント
    3.
    どんどんリリースしたい
    27
    

    View Slide

28. いろいろ選択肢あるよね
    AWS
    なら
    EC2
    ECS
    EKS
    GCP
    なら
    Cloud Run
    GAE
    （ ex
    ）
    GCE
    GKE 28
    

    View Slide

29. 技術選定のポイントいろいろ
    インフラコスト
    運用の手間
    クラウドベンダーのサービスの成熟度やマイルス
    トーン
    ワークロードの特性
    必要なリソース要件
    チーム体制（ex.
    人数 /
    スキル /
    学習コスト）
    29
    

    View Slide

30. ポイントを振り返る
    1.
    サービス数（API
    ）が多い
    2. BigQuery
    とAWS
    の混在
    3.
    どんどんリリースしたい
    30
    

    View Slide

31. もろもろありましたが
    結局、、、
    31
    

    View Slide

32. 解決案: AWS/ECS → GCP/GKE
    32
    

    View Slide

33. GKE
    でいい感じに作れるのでは？
    (
    ｀・ω
    ・´)
    33
    

    View Slide

34. 想定するメリット
    コスト削減
    複数サービスをGKE
    で構築しリソース最適化
    メンテナンスコストも削減（されるはず）
    リリースの高速化
    オーダーメイドから量産体制へ
    terraform
    k8s
    可用性も向上
    全部GCP
    にできてBigQuery
    もにっこり(´∀｀) 34
    

    View Slide

35. それでは早速やっていきましょう
    35
    

    View Slide

36. 移行方針:
    どうやって移行する？
    1.
    まずはAPI
    部分（システムの一部）からの移行
    2.
    段階的にすべてを移行していく
    まずはAPI
    部分からの移行を実施
    影響範囲を小さくしたい
    API
    だけなら最悪どうにでもなる
    もともとのAWS
    ヘの切り戻しも容易
    機械学習部分をいきなり移行してデグレったら
    嫌だよね(/
    ･ω
    ･)/
    汗
    36
    

    View Slide

37. 移行後の構成（API
    部分のみ）
    ここまでリリースできた
    37
    

    View Slide

38. 移行後の理想（全部GCP/GKE
    化）
    38
    

    View Slide

39. 今後の移行方針
    既存サービスのGCP/GKE
    化
    まずは今回のプロジェクトで導入実績を作り、
    運用経験を積む
    他サービスも徐々に移行していく（※移行すれ
    ばするほど、インフラ・運用コストを削減でき
    る）
    新規サービスは最初からGCP/GKE
    で構築
    現在 @katio2
    が開発中、年内にリリース予定
    39
    

    View Slide

40. 移行してみての感想
    40
    

    View Slide

41. k8s
    難しいよ
    k8s/GKE
    のノウハウが少ない（※特に運用面）
    そもそもk8s
    自体の学習コストが高い
    ある日のtwitter
    のつぶやき
    41
    

    View Slide

42. つまり
    

    View Slide

43. Web engineer should be k8s itself!
    

    View Slide

44. まとめ
    良かったこと
    terraform + yaml
    でk8s
    環境構築・リリースは楽
    とりあえず本番リリースはできた
    悪かったこと
    ノウハウや経験がないので手探り
    k8s
    の公式ドキュメントそのままだと動かない
    GKE
    はだいたいβ
    版
    本番運用でいろいろ問題起きると思うので怖い
    （ガクブル）
    44
    

    View Slide

45. ありがとうございました！
    (´∀｀)
    45
    

    View Slide

46. F.Y.I.
    おまけ
    既存のAWS
    システムではdatadog
    をdashboard
    で使
    ってたが、GCP
    で使うのは辛い
    PubSub
    経由でdatadog
    にpush
    する仕組みを毎回
    作らないといけない
    GCP
    プロジェクト毎に認証をしないといけない
    の大変
    datadog APM
    の導入はめちゃくちゃ楽
    しかし、もちろんcontainer
    周りの指標しか取得
    できない
    46
    

    View Slide

47. stackdriver monitoring
    使う理由
    datadog
    用に追加のintegration
    作業が不要
    複数プロジェクトを一つのworkspace
    にまとめれ
    ば、GKE
    やCloud SQL
    のプロジェクトが別でも1
    つ
    のdashboard
    で監視できる
    alert policy
    やuptime check
    もそのまま作れる
    47
    

    View Slide

48. 現状の運用・監視方法
    GCP
    の場合にはStackdriver
    使うことにした
    Stackdriver monitoring
    での監視
    alert policy
    の作成 + slack
    通知
    dashboard
    の作成
    Stackdriver trace
    でのパフォーマンスチェック
    opencensus
    入れた
    Stackdriver for python
    はα
    版。。。(
    ｀・ω
    ・´)
    汗
    48
    

    View Slide

49. 参考資料
    GCP
    Google Kubernetes Engine
    Stackdriver Monitoring
    OpenCensus
    OpenCensus
    GitHub - census-instrumentation/opencensus-
    python
    49
    

    View Slide

50. Special Thanks! ( ˘ω˘)
    ｽﾔｧ
    @kaito2
    @saiya_moebius
    @SassaHero
    @yokomotod
    @chidakiyo
    50
    

    View Slide