As a SW/Ops/DB Engineer

riywo’s technology memo

Private PaaS

作りたいなーと漠然と思ってるアイデア。自分用メモなので色々省略してますので、興味ある人がいれば詳しく話します。

  • 基本コンセプト
    • Herokuライクなデプロイ
    • 壊れにくい
    • 開発が運用コスト管理
  • 技術トピック
    • 12factor
    • Docker
    • Mesos

基本コンセプト

よくある話で、開発者が自由にサーバを足し引きできたら楽だよね、という発想をもうちょっと現実的に意味のあるものにしてみた。単にgit pushでアプリ起動、くらいだったらdokkuとかDeisとか使えばなんもせんでもできる。けどそれだけだと、じゃあそのサーバの面倒は?とかリソースの割り当ては?とか、本質的に面倒な問題は片付かない。

ので、自由に計算機資源を使える代わりに、使う分のお金は自分で払ってね、というアイデアを考えた。普通にPaaS使うなら当たり前なんだけど、社内とかになると、余ってるサーバ使おう、共有部門の負担で、運用は誰かよろしく、みたいな感じになりがち。そうじゃなくて、自分達が使う分をちゃんとお金負担して使えば、チューニングも自分達でやらなきゃって思うし、コスト感覚が強くなると思う。

開発と運用を分けることで、確実に開発スピードは落ちる。落ちるから安定するとも言える。開発スピードを落とさず、お金かければある程度はスケールさせて逃げられるような共通基盤、あったらいいなぁ、ということで考えた結果、インフラ屋さんほとんど要らない感じにしたいなと思った。

Herokuライクなデプロイ

まぁこれは言うまでもなく。upstartとかdaemontoolsのrunスクリプトなんて、毎度書くのはDRYじゃない。デプロイしてアプリ起動までは共通的に自動化すべき。そうでなきゃ、結局サーバの管理コストが果てしなくなる。

壊れにくい

環境の構築が必要な時点で、壊れる可能性が非常に上がる。各種パッケージマネージャでバージョン固定しないと、とか。だったら、Dockerで稼働環境を丸っと固めて置くのがよい。デプロイもimageをダウンロードして起動するだけでシンプル。

開発が運用コスト管理

キャパシティプランニングも開発チームがやろう。でも、例えば開発チームが複数のサービスを1つのサーバクラスタで動かしたいとしたら、プランニングがとても面倒。だからといって、1サービス1クラスタとかにすると無駄が多くなりそう。Mesos使ってリソース管理すると、一段抽象化できるので計算しやすそうだし、足し引き簡単そう。

技術トピック

12factor

そもそもアプリの作りが12factor的な感じになってないと色々やりづらそう。特にconfigはオレオレにあのファイルやこのファイル読んで、とかなじゃくて、全部環境変数にしてしまう。

Docker

Docker imageはサービスごとに違っても、なんか共通の使っても、どっちでもいい。いつ誰がどこで起動しても同じ環境になるのがうれしい。その環境自体の記述はDockerfileで工夫する感じかな。ソースコードはbind mountすれば良さそう。

これやると開発環境と本番環境の差異が無くなるので多分うれしい人が多い。他には、新入社員の環境構築も一瞬、CIとかも環境構築に時間使わない、最初はEC2で大きくなったらオンプレでというのが超簡単、などなど。

デプロイはアプリケーションのリビジョンとそれが使うDocker imageのリビジョンをセットにする。ローカルのファイルシステムは使ってもいいけど、いつか消えるのでそういう用途に使わない(Herokuと同じ)。

もう一つ利点は、人気無くなったサービスとかを引き取る人が、何も調べずとも環境作れるので、とりあえず何の更新もせずに動かしておくだけのサービスの障害とかに時間使うことがほとんど無くなる。

Mesos

チームとかの単位でMesosクラスタ持つ。そのクラスタの料金を負担する。高負荷やバグをクラスタ増強でしのぎたければお金を積むか他から借りる。インフラ屋さんは全社のMesosクラスタ用のサーバの余剰を管理するだけでよし(ネットワーク資源除く)。開発側はMesosクラスタさえ持ってれば、あとはその資源の尽きない限りにおいて、自由に計算機資源を使えるので、インフラ屋さんにお伺いをたてる必要なくなる。EC2使うなら何も気にする必要ない、お金さえあれば。

動きはMesosがDockerを起動する感じMesosphereの人がそういうの作るって言ってたので待ってる。Marathon使えばdaemonも管理できそう。Chronos使えばcron駆逐できそう。

あとインフラ屋さんもDocker使って好きな監視エージェントとかをばらまける。こちらもイチイチ開発側にお伺いたてる必要ないので楽。共通的に使えるツールの開発と適応の速度上げられそう。

課題

データベースは要検討。Mesosにしてもいいのかもしれないし、そこはRDSとかみたいな外部サービスを使うかインフラ屋さんが同じようなインタフェースを作って責任持つのがいいのかもしれない。

ログ収集や監視は共通的に同じの入れてもいいかもだけど、そうすると今度はそれの更新スピードが落ちるので、Mesosで簡単に入れられるような基盤整備するだけがいいのかも。面倒くさがりは用意されたまま使えばいいし、手を入れたければ自分のところで勝手に変えてしまえばいい。

チューニングとかをインフラ屋さんが担ってたとしたら、そういう人を各サービスで抱えるか、もしくはそういう専門部隊として再編成すると良さそう。ナレッジとライブラリ・ツールの共有ができるようにすることが大事。

まとめ

お金で解決できるところはお金で解決して、なるべく時間の無駄を無くして開発スピードを上げるにはどうしたらいいかなということで考えた結果、開発側が運用コスト負担すればいいのではという結論になった。どうしても運用コストだけを見てる人と開発スピードだけを見てる人の価値観は合わないので、同じ人がやるべきかなと。

ただ、これやるぐらいなら各チームが勝手にHeroku使えばいいのでは?という気もするので、実装する気力は全然起きてない。誰かが作ってくれるのを待ってる。

Comments