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.2k
[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
AWSを使ったカンファレンスの 配信アーキテクチャ - 吉祥寺.pm37
takaishi
2
440
どうやればインシデント対応能力を鍛えられるのか? / SRE Kaigi 2025
takaishi
11
9.6k
Podcastを3年半続ける技術と得た物 / ya8-2024
takaishi
5
1.7k
入門!ClusterAPI 〜 k8s クラスターも k8s API で管理したい 〜 / k8s_meetup_31
takaishi
3
4.5k
CloudNativeへの道 リーダーシップとフォロワーシップ / 201911-cndjp13
takaishi
2
900
ClusterAPI v1alpha1 → v1alpha2 / k8s_meetup_23
takaishi
1
1.5k
実録!CloudNativeを 目指した230日 / cloud-native-days-tokyo-2019
takaishi
2
2.5k
Consul Connect and Kubernetes Integration / cloud native meetup tokyo 7
takaishi
2
2.3k
ソフトウェアエンジニア の楽しみ / 2018-pepaboudon
takaishi
0
230
Other Decks in Technology
See All in Technology
DevOps文化を育むQA 〜カルチャーバブルを生み出す戦略〜 / 20250317 Atsushi Funahashi
shift_evolve
1
110
LINEギフトのLINEミニアプリアクセシビリティ改善事例
lycorptech_jp
PRO
0
240
お問い合わせ対応の改善取り組みとその進め方
masartz
1
360
ウェブアクセシビリティとは
lycorptech_jp
PRO
0
260
日本MySQLユーザ会ができるまで / making MyNA
tmtms
1
360
製造業の会計システムをDDDで開発した話
caddi_eng
3
950
Proxmox VE超入門 〜 無料で作れるご自宅仮想化プラットフォームブックマークする
devops_vtj
0
120
30代エンジニアが考える、エンジニア生存戦略~~セキュリティを添えて~~
masakiokuda
4
2k
SaaSプロダクト開発におけるバグの早期検出のためのAcceptance testの取り組み
kworkdev
PRO
0
430
バクラクでのSystem Risk Records導入による変化と改善の取り組み/Changes and Improvement Initiatives Resulting from the Implementation of System Risk Records
taddy_919
0
220
Go製のマイグレーションツールの git-schemalex の紹介と運用方法
shinnosuke_kishida
1
400
AIエージェントキャッチアップと論文リサーチ
os1ma
6
1.2k
Featured
See All Featured
Done Done
chrislema
183
16k
Code Reviewing Like a Champion
maltzj
522
39k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Into the Great Unknown - MozCon
thekraken
36
1.7k
The Invisible Side of Design
smashingmag
299
50k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Building an army of robots
kneath
304
45k
How GitHub (no longer) Works
holman
314
140k
How to train your dragon (web standard)
notwaldorf
91
5.9k
RailsConf 2023
tenderlove
29
1k
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との連携