Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
[WIP] 運用しているサービスをKubernetes化するかどうか考える / k8s meetup 5th
Search
Ryo Takaishi
June 27, 2017
Technology
2
3.1k
[WIP] 運用しているサービスをKubernetes化するかどうか考える / k8s meetup 5th
https://k8sjp.connpass.com/event/56945/
の資料です
Ryo Takaishi
June 27, 2017
Tweet
Share
More Decks by Ryo Takaishi
See All by Ryo Takaishi
Podcastを3年半続ける技術と得た物 / ya8-2024
takaishi
5
1.3k
入門!ClusterAPI 〜 k8s クラスターも k8s API で管理したい 〜 / k8s_meetup_31
takaishi
3
4.3k
CloudNativeへの道 リーダーシップとフォロワーシップ / 201911-cndjp13
takaishi
2
840
ClusterAPI v1alpha1 → v1alpha2 / k8s_meetup_23
takaishi
1
1.4k
実録!CloudNativeを 目指した230日 / cloud-native-days-tokyo-2019
takaishi
2
2.4k
Consul Connect and Kubernetes Integration / cloud native meetup tokyo 7
takaishi
2
2.2k
ソフトウェアエンジニア の楽しみ / 2018-pepaboudon
takaishi
0
190
Ansible、Terraform、Packerで作るSelf-Hosted Kubernetes / JKD1812
takaishi
5
3.9k
Knative Serving 入門 / kubernetes meetup 13
takaishi
2
1.2k
Other Decks in Technology
See All in Technology
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
13
3.6k
楽しくGoを学び合う、LayerXの勉強会文化 / LayerX's study culture of having fun and learning Go together
ar_tama
2
350
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
[NIKKEI Tech Talk]Bias for Action!! 実践から学ぶための仕組とコミュニティ / Community for Practice and Learning
kanamasa
0
280
ゆめみのアクセシビリティの現在地と今後
ryokatsuse
3
290
スレットハンティングについて知っておきたいこと
hacket
0
130
コンテナ・K8s研修 - 前半 コンテナ基礎・ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
Git 研修 Basic【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
310
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
130
テストケースの自動生成に生成AIの導入を試みた話と生成AIによる今後の期待
shift_evolve
0
190
成長期に歩みを止めないための創業期の開発文化形成
mayah
6
420
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
380
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
The Power of CSS Pseudo Elements
geoffreycrofte
64
5.2k
Fashionably flexible responsive web design (full day workshop)
malarkey
399
65k
Documentation Writing (for coders)
carmenintech
63
4.2k
Facilitating Awesome Meetings
lara
46
5.8k
Code Reviewing Like a Champion
maltzj
517
39k
What's new in Ruby 2.0
geeforr
338
31k
Practical Orchestrator
shlominoach
185
10k
Agile that works and the tools we love
rasmusluckow
325
20k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.4k
Happy Clients
brianwarren
94
6.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
248
20k
Transcript
[WIP] 運⽤しているサービスを Kubernetes化するかどうか 考える @r_takaishi / GMO PEPABO inc. 2017-06-27
⽬次 1. 今⽇のテーマについて 2. もっとデプロイしたい! 3. もっとスケールしたい! 4. まとめ
ソフトウェアエンジニア 技術部 インフラグループ https://repl.info/ ⾼⽯諒 @r_takaishi
カレーがマイブーム
今⽇のテーマ
もっとデプロイしたい
もっとスケールしたい
それ でどうなる?
None
minneについて • 500万点の作品数 • 700万DLのアプリ • 100台規模のインスタンス
minneのサービス基盤 • 今の形になってから約2年ほどたつ • クラウド・ネイティブなアーキテクチャ • OpenStack上に構築 • Consulでクラスタリング、Service/TagでLBと紐付け •
細かい修正はしているが、⼤きく変わってはいない • 結構よくできた仕組みだと思う
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
中⻑期を⾒据えると… • アーキテクチャ⾃体の⼤きな課題はない…? • 同じアーキテクチャでもいけるかも? • このままだと⼤きくなりそうな課題もある • 成⻑速度や安定性、信頼性の向上に繋がる策はあるか?
「デプロイ」と「スケール」 • デプロイ:Railsのtarball作成とその配布、プロセス切り替え • スケール:インスタンスを追加してLBに繋げる • それぞれ、かなり時間がかかっている • デプロイ:1回25分 •
スケール:1台10分 • 現状の仕組みのまま時間短縮できるような対策は実施中 • 全体の仕組みを変えることで解決できるか?
Kubernetesに乗せることで実現するか? • コンテナ? • CIやローカル開発⽤では使っている • 実際にコンテナオーケストレーションツールに乗せると? • サンプルアプリ等ではなく実際のサービスでうまく使えるか •
デプロイやスケールの時間や使い勝⼿は?
検証環境 • OpenStack + Rancherで構築 • OpenStack:Mitaka • Rancher •
コンテナ環境を構築・運⽤するためのプラットフォーム • SwarmやKubernetes環境を⽤意できる • かっこいいGUI
検証環境 #VJME %PDLFS 3FHJTUSZ NJOOF 3BODIFS 3BODIFS 3BODIFS Push Pull
,VCFSOFUFT
検証環境(Rancher)
もっとデプロイしたい
デプロイ • サービス成⻑のための⾼速かつ頻繁なデプロイ • デプロイする⼈:10⼈ • インスタンス数:100台規模 • デプロイ:5回/⽇、1回25分 •
ビルド(railsのtarball作成(1GB)、S3へのアップロード)5分 • 配布(各インスタンスへ転送、プロセス切り替え):20分
時間かかりすぎ
デプロイ時間を縮めたい! • 1⽇のデプロイ可能回数が増える • 短時間でいつでもデプロイできて困ることはない • 待ち時間が減る => 開発者のリズムを奪わない
現在のデプロイの仕組み • Capistrano、Consul、Stretcherを使⽤ • Capistrano:Ruby製のサーバ操作・デプロイ⾃動化ツール • Consul:サービスディスカバリ • Railsを動かしているインスタンスで任意の処理を実⾏ •
Stretcher:ConsulやSerfと連携してデプロイを⾏うツール
現在のデプロイ⽅法 ։ൃऀ CVJME DBQNJOOFEFQMPZ XXX XXX XXX 4 $BQJTUSBOP UBSCBMM࡞
4Ξοϓϩʔυ DPOTVMFWFOUͰTUSFUDIFSΛLJDL DPOTVMFWFOU LJDLTUSFUDIFS 4USFUDIFS 4͔Βμϯϩʔυ ల։ɾϓϩηεͷ࠶ىಈ
Kubernetesにするとデプロイがどうなるか • Kubernetes化 = コンテナ化 • VMにtarballを配布 = コンテナイメージを配布 •
ランタイムや各種依存ライブラリはキャッシュできる • リリース毎の差分はコード+precompileしたassetsが主
Kubernetesにするとデプロイがどうなるか ։ൃऀ CVJME DBQNJOOFEFQMPZ XXX XXX XXX 3FHJTUSZ $BQJTUSBOP 3BJMT༻ͷ%PDLFS*NBHF࡞
3FHJTUSZΞοϓϩʔυ LVCFDUMTFUJNBHFͰόʔδϣϯΞοϓ ,VCFSOFUFT TUSBUFHZʹैͬͯ1PEΛೖΕସ͑ LT LVCFDUMTFUJNBHF
k8sでminneのデプロイを試した • ノード数:20 • Deploymentを使⽤ • レプリカ数:20 • 新しいバージョンのイメージに切り替わるまでの時間を計測 •
約10分で⼊れ替え完了
k8sでminneのデプロイを試した • 約10分で⼊れ替え完了 • 現在のインスタンス数とはかなり差があるが、まぁまぁ早いのでは • ノード数を増やした時の時間や負荷が気になる所
もっとスケールしたい
もっとスケールしたい • サービス成⻑や負荷に対応するための⾼速で細かなスケール • TV CMなどの対応で20台、30台といった増減 • 負荷状況に応じてより頻繁にリソースを増減したい • もっともっとスケール回数を増やしたい。速くしたい。
スケール • サービス成⻑や負荷に対応するための⾼速で細かなスケール • TV CMなどの対応で20台、30台単位での増減 • 現在、1台起動するのに約8〜10分 • インスタンス⾃体の起動
• cloud-initの実⾏ • tarball(約1GB)の取得・展開
時間かかりすぎ
スケールアウト時間を短くしたい!!! • 10台増やすのに10分も20分も待ちたくない • 負荷に応じた細かなスケール • キャパシティの最適化
現在のスケールの仕組み • RubyとOpenStack APIを使って専⽤CLIツールを⽤意 • Compute API(EC2のAPIみたいなもの)を素朴に叩く • 複数AZにバランスよく配置 •
あらかじめ必要な台数を指定し、スケールしたことを確認する • 結構時間がかかる…
Kubernetesにするとどうなるか • コンテナ化する恩恵が⼤きい • VMよりはコンテナの⽅が起動が速い • OS起動のオーバーヘッドもない • イメージサイズもコンテナの⽅が⼩さい •
Kubernetesのスケール機能は便利そう • 簡単にスケールできる(kubectl, api) • ⾃家製CLIツールのコード量も減らせるかも
k8sのスケールアウトを minne で試した • ノード数:20 • Deploymentを使⽤ • レプリカ数:1 →
20 • RunningのPodが20台になるまでの時間を計測 • 約4分でスケール完了
k8sのスケールアウトを minne で試した • 約4分でスケール完了 • 1台10秒強。早い! • どのくらいPodの数を細かく制御できるのか気になる所 •
Horizontal Pod Autoscaling とか
まとめ • デプロイとスケールについては改善できそう • 100台以上の規模になった時どうなるか? • デプロイやスケール時の挙動をちゃんと追っておきたい • デプロイ・スケール以外の機能はどうか? •
バッチ • OpenStackとの連携