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
780
AWSを使ったカンファレンスの 配信アーキテクチャ - 吉祥寺.pm37
takaishi
2
530
どうやればインシデント対応能力を鍛えられるのか? / SRE Kaigi 2025
takaishi
13
11k
Podcastを3年半続ける技術と得た物 / ya8-2024
takaishi
5
1.9k
入門!ClusterAPI 〜 k8s クラスターも k8s API で管理したい 〜 / k8s_meetup_31
takaishi
3
4.7k
CloudNativeへの道 リーダーシップとフォロワーシップ / 201911-cndjp13
takaishi
2
950
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
OCIjp_Oracle AI World_Recap
shinpy
1
120
Dylib Hijacking on macOS: Dead or Alive?
patrickwardle
0
420
「魔法少女まどか☆マギカ Magia Exedra」の多様なバトルの開発を柔軟かつ効率的に実現するためのPure C#とUnityの分離について
gree_tech
PRO
0
140
Azureコストと向き合った、4年半のリアル / Four and a half years of dealing with Azure costs
aeonpeople
1
230
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
43k
CNCFの視点で捉えるPlatform Engineering - 最新動向と展望 / Platform Engineering from the CNCF Perspective
hhiroshell
0
110
NLPコロキウム20251022_超効率化への挑戦: LLM 1bit量子化のロードマップ
yumaichikawa
1
120
GoでもGUIアプリを作りたい!
kworkdev
PRO
0
160
難しいセキュリティ用語をわかりやすくしてみた
yuta3110
0
340
Oracle Autonomous AI Database:サービス概要のご紹介
oracle4engineer
PRO
2
15k
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
2.8k
ハノーファーメッセ2025で見た生成AI活用ユースケース.pdf
hamadakoji
0
170
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
2.8k
A better future with KSS
kneath
239
18k
Rails Girls Zürich Keynote
gr2m
95
14k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
10
880
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Building Adaptive Systems
keathley
44
2.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Embracing the Ebb and Flow
colly
88
4.9k
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との連携