Cloud Foundry Advent Calendar 2017の13日目。
最近どうぶつを高く積み上げていくe-sportsを始めてみたのですが、あれよあれよと時間を吸われます。やばい。
さてみなさん。コロケ芸という言葉をご存じでしょうか。
もし知っているという人は、おそらく某所関係者かと思われますので多分この記事読まなくても大丈夫です。
CFの必要リソースでかいねん問題
Cloud Foundryの構築はBOSHを用いますが、BOSHはVMを用いてデプロイを行う仕組みなので、コンポーネントが増えれば増えるほどVMの数がすごいことになります。Cloud Foundryは数多くのコンポーネントから成りますので、デプロイするだけでものすごいVM数になります・・・というのは、CFに関わる人であればご存じでしょう。
きちんと理由があってコンポーネントが分けられているので、BOSHで管理する以上VM数が増えてしまうのは仕方ない・・・と言いたいところですが、とはいってもやっぱりコンパクトな環境でフル機能CFを使いたい。 BOSH-lite でAll in oneを構築してしまう手はありますが、そうではなく・・・と。
「なんとかしてリソースを節約しつつもプロダクションレディなCFクラスタを構築したい」
そういう考えから、VMに多くのコンポーネントを同居させつつも運用性は失わない、コロケーションのノウハウ、すなわちコロケ芸が、都内某所で脈々と受け継がれているという噂があります。
コロケ芸の広まり？
そんな門外不出のコロケ芸ですが、やはり同じことを考える人は多いようで。
Pivotal Cloud Foundryを提供するPivotalが、9月にリリースしたバージョン1.12で"Small Footprint Runtime (SRTと略す)"というリソース削減版を公開しました。これはまさに、コロケ芸そのものだったりします。
SRTの仕組み
Pivotalのドキュメントを見ると、以下のようなことが書いてあります。
The Small Footprint Runtime is a repackaging of the Elastic Runtime components into a smaller and more efficient deployment. A standard Elastic Runtime deployment must have at least 24 virtual machines (VMs), but the Small Footprint Runtime requires only 14.
24必要だったVMが14になる！とのこと。・・・うーん、確かに大きく減りましたがびっくりするほどの削減ではないですね･･･。 ですが、よく見てみましょう。
よく見ると、必要と言われているVMのうち多くをErrandが占めていることがわかります。ErrandはBOSHでrun-errandを行ったときに必要になってくるVMであり、常に立ち上がっているVMではありません。そのため、本当の意味で必要なVMはより限られることになります。
この図の中で、CF自体の動作に必要なVMは以下の4つのみです。
- Control
- Compute
- Router
- Database
つまり、HAを考えないのならば4VMでいける、というわけです。
コロケの実現方法
さてこのコロケ芸、どうやって実現しているんでしょうか。Pivotal Cloud Foundryも内部的にはBOSHなので、OSS CF でも同じことは出来るはずです。
cf-deploymentのUAAの記述をみてみましょう
https://github.com/cloudfoundry/cf-deployment/blob/master/cf-deployment.yml#L367-L577
インスタンス数、VMの種類の指定が続いたあと、jobs: にてどのjobをどういう設定で構築するか記述されていることが分かるでしょう。 もしUAAとCloud Controllerを同居させたい場合は、両方のJobを動かせるだけのインスタンスを指定し、jobs: の項目をマージしてやればいけそうです。
･･･というと簡単そうに聞こえますが、実際にはなかなかムズかしかったりします。そもそもマージさせていく作業が超絶地味だったり、jobの中でも重複する項目があったりと。
もしVM数を削減してみたいという方は、是非一度チャレンジしてみてはどうでしょうか
PCFを買ってSRTでセットアップすれば一瞬ですが
どういう単位でコロケするか
どのJobをどうコロケーションさせていくのがいいか。これは知恵の出しどころかなと思います。 たとえばコロケさせたうち特定のJobだけ過負荷でスケールアウトさせないと・・・という場合、コロケの仕方によっては不要なJobまで増やしてしまい、リソース削減のために行ったコロケが逆効果なんてことも起きえます。
先ほども紹介した、PCFのSRTはその分け方の参考になるかもしれません。
- Control
- Compute
- Router
- Database
の4VMが必須と書きましたが、そのうちComputeはdiego-cellそのものです。他のものは同居していません。 また、Routerに関してもGorouterそのものです。
つまり、CFを使う上で一番負荷がかかりやすいであろう、Gorouterとcellだけは他と同居させず、そのままというわけです。
CFの主要なコンポーネントの多くは、Controlに集約されています
また、Consul, NATS, MySQLに関してはDatabaseに集約されます
Consulは仕組み上、クラスタを組むのであれば3台, 5台といった奇数にする必要があります。つまり、HAで組む場合Databaseは3台必要ということになりますね。
ControlやRouter, Computeは2台以上あればHA構成になります
