Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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との連携