[WIP] 運用しているサービスをKubernetes化するかどうか考える / k8s meetup 5th

https://k8sjp.connpass.com/event/56945/ の資料です

Transcript

1. [WIP]
   運⽤しているサービスを
   Kubernetes化するかどうか
   考える
   @r_takaishi / GMO PEPABO inc.
   2017-06-27
   

   View Slide

2. ⽬次
   1. 今⽇のテーマについて
   2. もっとデプロイしたい！
   3. もっとスケールしたい！
   4. まとめ
   

   View Slide

3. ソフトウェアエンジニア
   技術部 インフラグループ
   https://repl.info/
   ⾼⽯諒 @r_takaishi
   

   View Slide

4. カレーがマイブーム
   

   View Slide

5. 今⽇のテーマ
   

   View Slide

6. もっとデプロイしたい
   

   View Slide

7. もっとスケールしたい
   

   View Slide

8. それ でどうなる？
   

   View Slide

9. View Slide

10. minneについて
    • 500万点の作品数
    • 700万DLのアプリ
    • 100台規模のインスタンス
    

    View Slide

11. minneのサービス基盤
    • 今の形になってから約2年ほどたつ
    • クラウド・ネイティブなアーキテクチャ
    • OpenStack上に構築
    • Consulでクラスタリング、Service/TagでLBと紐付け
    • 細かい修正はしているが、⼤きく変わってはいない
    • 結構よくできた仕組みだと思う
    

    View Slide

12. minneのサービス基盤
    api-lb
    www
    www
    www
    www
    web-lb
    www
    www
    www
    www
    Consul Cluster
    Consul Template
    Consul Template
    hakata (CLIπʔϧ)
    ʹΑΔεέʔϧ
    scale count=5
    scale count=N
    TFSWJDFUBHBQJ
    TFSWJDFUBHXFC
    

    View Slide

13. 中⻑期を⾒据えると…
    • アーキテクチャ⾃体の⼤きな課題はない…？
    • 同じアーキテクチャでもいけるかも？
    • このままだと⼤きくなりそうな課題もある
    • 成⻑速度や安定性、信頼性の向上に繋がる策はあるか？
    

    View Slide

14. 「デプロイ」と「スケール」
    • デプロイ：Railsのtarball作成とその配布、プロセス切り替え
    • スケール：インスタンスを追加してLBに繋げる
    • それぞれ、かなり時間がかかっている
    • デプロイ：1回25分
    • スケール：1台10分
    • 現状の仕組みのまま時間短縮できるような対策は実施中
    • 全体の仕組みを変えることで解決できるか？
    

    View Slide

15. Kubernetesに乗せることで実現するか？
    • コンテナ？
    • CIやローカル開発⽤では使っている
    • 実際にコンテナオーケストレーションツールに乗せると？
    • サンプルアプリ等ではなく実際のサービスでうまく使えるか
    • デプロイやスケールの時間や使い勝⼿は？
    

    View Slide

16. 検証環境
    • OpenStack + Rancherで構築
    • OpenStack：Mitaka
    • Rancher
    • コンテナ環境を構築・運⽤するためのプラットフォーム
    • SwarmやKubernetes環境を⽤意できる
    • かっこいいGUI
    

    View Slide

17. 検証環境
    #VJME %PDLFS
    
    3FHJTUSZ
    NJOOF
    3BODIFS 3BODIFS 3BODIFS
    Push
    Pull
    ,VCFSOFUFT
    

    View Slide

18. 検証環境（Rancher）
    

    View Slide

19. もっとデプロイしたい
    

    View Slide

20. デプロイ
    • サービス成⻑のための⾼速かつ頻繁なデプロイ
    • デプロイする⼈：10⼈
    • インスタンス数：100台規模
    • デプロイ：5回/⽇、1回25分
    • ビルド（railsのtarball作成(1GB)、S3へのアップロード）5分
    • 配布（各インスタンスへ転送、プロセス切り替え）：20分
    

    View Slide

21. 時間かかりすぎ
    

    View Slide

22. デプロイ時間を縮めたい！
    • 1⽇のデプロイ可能回数が増える
    • 短時間でいつでもデプロイできて困ることはない
    • 待ち時間が減る => 開発者のリズムを奪わない
    

    View Slide

23. 現在のデプロイの仕組み
    • Capistrano、Consul、Stretcherを使⽤
    • Capistrano：Ruby製のサーバ操作・デプロイ⾃動化ツール
    • Consul：サービスディスカバリ
    • Railsを動かしているインスタンスで任意の処理を実⾏
    • Stretcher：ConsulやSerfと連携してデプロイを⾏うツール
    

    View Slide

24. 現在のデプロイ⽅法
    ։ൃऀ CVJME
    DBQNJOOFEFQMPZ
    XXX
    XXX
    XXX
    4
    $BQJTUSBOP
    UBSCBMM࡞੒
    4΁Ξοϓϩʔυ
    DPOTVMFWFOUͰTUSFUDIFSΛLJDL
    DPOTVMFWFOU
    LJDLTUSFUDIFS
    4USFUDIFS
    4͔Βμ΢ϯϩʔυ
    ల։ɾϓϩηεͷ࠶ىಈ
    

    View Slide

25. Kubernetesにするとデプロイがどうなるか
    • Kubernetes化 = コンテナ化
    • VMにtarballを配布 ＝ コンテナイメージを配布
    • ランタイムや各種依存ライブラリはキャッシュできる
    • リリース毎の差分はコード+precompileしたassetsが主
    

    View Slide

26. Kubernetesにするとデプロイがどうなるか
    ։ൃऀ CVJME
    DBQNJOOFEFQMPZ
    XXX
    XXX
    XXX
    3FHJTUSZ
    $BQJTUSBOP
    3BJMT༻ͷ%PDLFS*NBHF࡞੒
    3FHJTUSZ΁Ξοϓϩʔυ
    LVCFDUMTFUJNBHFͰόʔδϣϯΞοϓ
    ,VCFSOFUFT
    TUSBUFHZʹैͬͯ1PEΛೖΕସ͑
    LT
    LVCFDUMTFUJNBHF
    

    View Slide

27. k8sでminneのデプロイを試した
    • ノード数：20
    • Deploymentを使⽤
    • レプリカ数：20
    • 新しいバージョンのイメージに切り替わるまでの時間を計測
    • 約10分で⼊れ替え完了
    

    View Slide

28. k8sでminneのデプロイを試した
    • 約10分で⼊れ替え完了
    • 現在のインスタンス数とはかなり差があるが、まぁまぁ早いのでは
    • ノード数を増やした時の時間や負荷が気になる所
    

    View Slide

29. もっとスケールしたい
    

    View Slide

30. もっとスケールしたい
    • サービス成⻑や負荷に対応するための⾼速で細かなスケール
    • TV CMなどの対応で20台、30台といった増減
    • 負荷状況に応じてより頻繁にリソースを増減したい
    • もっともっとスケール回数を増やしたい。速くしたい。
    

    View Slide

31. スケール
    • サービス成⻑や負荷に対応するための⾼速で細かなスケール
    • TV CMなどの対応で20台、30台単位での増減
    • 現在、1台起動するのに約8〜10分
    • インスタンス⾃体の起動
    • cloud-initの実⾏
    • tarball（約1GB）の取得・展開
    

    View Slide

32. 時間かかりすぎ
    

    View Slide

33. スケールアウト時間を短くしたい！！！
    • 10台増やすのに10分も20分も待ちたくない
    • 負荷に応じた細かなスケール
    • キャパシティの最適化
    

    View Slide

34. 現在のスケールの仕組み
    • RubyとOpenStack APIを使って専⽤CLIツールを⽤意
    • Compute API(EC2のAPIみたいなもの)を素朴に叩く
    • 複数AZにバランスよく配置
    • あらかじめ必要な台数を指定し、スケールしたことを確認する
    • 結構時間がかかる…
    

    View Slide

35. Kubernetesにするとどうなるか
    • コンテナ化する恩恵が⼤きい
    • VMよりはコンテナの⽅が起動が速い
    • OS起動のオーバーヘッドもない
    • イメージサイズもコンテナの⽅が⼩さい
    • Kubernetesのスケール機能は便利そう
    • 簡単にスケールできる（kubectl, api)
    • ⾃家製CLIツールのコード量も減らせるかも
    

    View Slide

36. k8sのスケールアウトを minne で試した
    • ノード数：20
    • Deploymentを使⽤
    • レプリカ数：1 → 20
    • RunningのPodが20台になるまでの時間を計測
    • 約4分でスケール完了
    

    View Slide

37. k8sのスケールアウトを minne で試した
    • 約4分でスケール完了
    • 1台10秒強。早い！
    • どのくらいPodの数を細かく制御できるのか気になる所
    • Horizontal Pod Autoscaling とか
    

    View Slide

38. まとめ
    • デプロイとスケールについては改善できそう
    • 100台以上の規模になった時どうなるか？
    • デプロイやスケール時の挙動をちゃんと追っておきたい
    • デプロイ・スケール以外の機能はどうか？
    • バッチ
    • OpenStackとの連携
    

    View Slide