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

by Ryo Takaishi

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

カレーがマイブーム

Slide 5

Slide 5 text

今⽇のテーマ

Slide 6

Slide 6 text

もっとデプロイしたい

Slide 7

Slide 7 text

もっとスケールしたい

Slide 8

Slide 8 text

それでどうなる？

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

検証環境（Rancher）

Slide 19

Slide 19 text

もっとデプロイしたい

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

時間かかりすぎ

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

もっとスケールしたい

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

時間かかりすぎ

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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