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
740
AWSを使ったカンファレンスの 配信アーキテクチャ - 吉祥寺.pm37
takaishi
2
520
どうやればインシデント対応能力を鍛えられるのか? / SRE Kaigi 2025
takaishi
12
11k
Podcastを3年半続ける技術と得た物 / ya8-2024
takaishi
5
1.9k
入門!ClusterAPI 〜 k8s クラスターも k8s API で管理したい 〜 / k8s_meetup_31
takaishi
3
4.6k
CloudNativeへの道 リーダーシップとフォロワーシップ / 201911-cndjp13
takaishi
2
940
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
ヘブンバーンズレッドにおける、世界観を活かしたミニゲーム企画の作り方
gree_tech
PRO
0
580
生成AI時代のデータ基盤
shibuiwilliam
6
3.8k
【Grafana Meetup Japan #6】Grafanaをリバプロ配下で動かすときにやること ~ Grafana Liveってなんだ ~
yoshitake945
0
380
Codeful Serverless / 一人運用でもやり抜く力
_kensh
6
330
Grafana MCPサーバーによるAIエージェント経由でのGrafanaダッシュボード動的生成
hamadakoji
1
1.4k
AI エージェントとはそもそも何か? - 技術背景から Amazon Bedrock AgentCore での実装まで- / AI Agent Unicorn Day 2025
hariby
4
1.2k
Vault を基盤として整備し、 みんなに使ってもらえるようになるまで
takahiko
1
110
まだ間に合う! StrandsとBedrock AgentCoreでAIエージェント構築に入門しよう
minorun365
PRO
11
1.1k
大「個人開発サービス」時代に僕たちはどう生きるか
sotarok
19
9.4k
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.4k
研究開発と製品開発、両利きのロボティクス
youtalk
1
490
フィンテック養成勉強会#56
finengine
0
130
Featured
See All Featured
Facilitating Awesome Meetings
lara
55
6.5k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Balancing Empowerment & Direction
lara
3
610
Unsuck your backbone
ammeep
671
58k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Embracing the Ebb and Flow
colly
87
4.8k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Producing Creativity
orderedlist
PRO
347
40k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
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との連携