$30 off During Our Annual Pro Sale. View Details »

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

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

Ryo Takaishi

June 27, 2017
Tweet

More Decks by Ryo Takaishi

Other Decks in Technology

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