https://k8sjp.connpass.com/event/56945/ の資料です
[WIP]運⽤しているサービスをKubernetes化するかどうか考える@r_takaishi / GMO PEPABO inc.2017-06-27
View Slide
⽬次1. 今⽇のテーマについて2. もっとデプロイしたい!3. もっとスケールしたい!4. まとめ
ソフトウェアエンジニア技術部 インフラグループhttps://repl.info/⾼⽯諒 @r_takaishi
カレーがマイブーム
今⽇のテーマ
もっとデプロイしたい
もっとスケールしたい
それ でどうなる?
minneについて• 500万点の作品数• 700万DLのアプリ• 100台規模のインスタンス
minneのサービス基盤• 今の形になってから約2年ほどたつ• クラウド・ネイティブなアーキテクチャ• OpenStack上に構築• Consulでクラスタリング、Service/TagでLBと紐付け• 細かい修正はしているが、⼤きく変わってはいない• 結構よくできた仕組みだと思う
minneのサービス基盤api-lbwwwwwwwwwwwwweb-lbwwwwwwwwwwwwConsul ClusterConsul TemplateConsul Templatehakata (CLIπʔϧ)ʹΑΔεέʔϧscale count=5scale count=NTFSWJDFUBHBQJTFSWJDFUBHXFC
中⻑期を⾒据えると…• アーキテクチャ⾃体の⼤きな課題はない…?• 同じアーキテクチャでもいけるかも?• このままだと⼤きくなりそうな課題もある• 成⻑速度や安定性、信頼性の向上に繋がる策はあるか?
「デプロイ」と「スケール」• デプロイ:Railsのtarball作成とその配布、プロセス切り替え• スケール:インスタンスを追加してLBに繋げる• それぞれ、かなり時間がかかっている• デプロイ:1回25分• スケール:1台10分• 現状の仕組みのまま時間短縮できるような対策は実施中• 全体の仕組みを変えることで解決できるか?
Kubernetesに乗せることで実現するか?• コンテナ?• CIやローカル開発⽤では使っている• 実際にコンテナオーケストレーションツールに乗せると?• サンプルアプリ等ではなく実際のサービスでうまく使えるか• デプロイやスケールの時間や使い勝⼿は?
検証環境• OpenStack + Rancherで構築• OpenStack:Mitaka• Rancher• コンテナ環境を構築・運⽤するためのプラットフォーム• SwarmやKubernetes環境を⽤意できる• かっこいいGUI
検証環境#VJME %PDLFS3FHJTUSZNJOOF3BODIFS 3BODIFS 3BODIFSPushPull,VCFSOFUFT
検証環境(Rancher)
デプロイ• サービス成⻑のための⾼速かつ頻繁なデプロイ• デプロイする⼈:10⼈• インスタンス数:100台規模• デプロイ:5回/⽇、1回25分• ビルド(railsのtarball作成(1GB)、S3へのアップロード)5分• 配布(各インスタンスへ転送、プロセス切り替え):20分
時間かかりすぎ
デプロイ時間を縮めたい!• 1⽇のデプロイ可能回数が増える• 短時間でいつでもデプロイできて困ることはない• 待ち時間が減る => 開発者のリズムを奪わない
現在のデプロイの仕組み• Capistrano、Consul、Stretcherを使⽤• Capistrano:Ruby製のサーバ操作・デプロイ⾃動化ツール• Consul:サービスディスカバリ• Railsを動かしているインスタンスで任意の処理を実⾏• Stretcher:ConsulやSerfと連携してデプロイを⾏うツール
現在のデプロイ⽅法։ൃऀ CVJMEDBQNJOOFEFQMPZXXXXXXXXX4$BQJTUSBOPUBSCBMM࡞4ΞοϓϩʔυDPOTVMFWFOUͰTUSFUDIFSΛLJDLDPOTVMFWFOULJDLTUSFUDIFS4USFUDIFS4͔Βμϯϩʔυల։ɾϓϩηεͷ࠶ىಈ
Kubernetesにするとデプロイがどうなるか• Kubernetes化 = コンテナ化• VMにtarballを配布 = コンテナイメージを配布• ランタイムや各種依存ライブラリはキャッシュできる• リリース毎の差分はコード+precompileしたassetsが主
Kubernetesにするとデプロイがどうなるか։ൃऀ CVJMEDBQNJOOFEFQMPZXXXXXXXXX3FHJTUSZ$BQJTUSBOP3BJMT༻ͷ%PDLFS*NBHF࡞3FHJTUSZΞοϓϩʔυLVCFDUMTFUJNBHFͰόʔδϣϯΞοϓ,VCFSOFUFTTUSBUFHZʹैͬͯ1PEΛೖΕସ͑LTLVCFDUMTFUJNBHF
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との連携