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 mee...
Search
Ryo Takaishi
June 27, 2017
Technology
2
3.3k
[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
スロークエリとの戦いの軌跡2024 / ゆるSRE勉強会 #10
takaishi
1
710
AWSを使ったカンファレンスの 配信アーキテクチャ - 吉祥寺.pm37
takaishi
2
490
どうやればインシデント対応能力を鍛えられるのか? / SRE Kaigi 2025
takaishi
11
11k
Podcastを3年半続ける技術と得た物 / ya8-2024
takaishi
5
1.8k
入門!ClusterAPI 〜 k8s クラスターも k8s API で管理したい 〜 / k8s_meetup_31
takaishi
3
4.6k
CloudNativeへの道 リーダーシップとフォロワーシップ / 201911-cndjp13
takaishi
2
930
ClusterAPI v1alpha1 → v1alpha2 / k8s_meetup_23
takaishi
1
1.6k
実録!CloudNativeを 目指した230日 / cloud-native-days-tokyo-2019
takaishi
2
2.6k
Consul Connect and Kubernetes Integration / cloud native meetup tokyo 7
takaishi
2
2.3k
Other Decks in Technology
See All in Technology
地図と生成AI
nakasho
0
710
メモ整理が苦手な者による頑張らないObsidian活用術
optim
0
120
The Madness of Multiple Gemini CLIs Developing Simultaneously with Jujutsu
gunta
1
2.6k
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
160
複数のGemini CLIが同時開発する狂気 - Jujutsuが実現するAIエージェント協調の新世界
gunta
12
3.3k
少人数でも回る! DevinとPlaybookで支える運用改善
ishikawa_pro
1
460
Ktor + Google Cloud Tasks/PubSub におけるOTel Messaging計装の実践
sansantech
PRO
1
280
Shadow DOM & Security - Exploring the boundary between light and shadow
masatokinugawa
0
660
株式会社島津製作所_研究開発(集団協業と知的生産)の現場を支える、OSS知識基盤システムの導入
akahane92
1
1.2k
TypeScript 上達の道
ysknsid25
10
1.2k
M365アカウント侵害時の初動対応
lhazy
7
4.6k
AI駆動開発 with MixLeap Study【大阪支部 #3】
lycorptech_jp
PRO
0
210
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
21
1.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
282
13k
Scaling GitHub
holman
461
140k
The Cost Of JavaScript in 2023
addyosmani
51
8.6k
Producing Creativity
orderedlist
PRO
346
40k
Code Review Best Practice
trishagee
69
19k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
A Tale of Four Properties
chriscoyier
160
23k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
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との連携