クラウドで複数のサービスを展開する際に用いるべきプロビジョニングツールとは

質問したいこと

なんでもかんでもDockerを使うべきなのか？
といったところが主題です。

CIツールなどを使ってみて、ふと抱いた疑問です。いろんな意見が聞ければと思います。
大規模サービスの経験がないので、そもそもが違っていたらすみません。

前提

変な仮定ですが、本体は同じサービスだけど、
顧客ごとにバージョンが違うような運営がされてるサービスがあるとします。

/var/www/html
             --[顧客A ver.Oxygen]
             --[顧客B ver.Luna]
             --[顧客C ver.Kelper]
             --[顧客D ver.Luna]

これがapacheないしはnginxによって、
virtualHost機能などで顧客A.example.comとか、
example.com/顧客Aとかで配信されてるとします。

また、ミドルウェアとしてMySQLなどのDBがあって、
一つのDBサーバー上でdatabaseが分かれており、
内部的には区切られた運用がされているとします。

各バージョンごとのhotfixはそこそこ頻繁にされていて、
masterへと統合され次第、各バージョンに対してパッチしていたとします。

これを従来では手作業で新規契約ごとにデプロイしていて、
修正があるたびに各バージョンに対してパッチしていたのを、
一斉にプロビジョニングツールに置換しようという機運が高まったとします。

本題

このとき手法として、大きく

Chef, Ansible, Gitで冪等性を保てるように手作業していた部分を置換
Webサーバー、ミドルウェアの部分は従来通り共通
Docker(+private registryサーバー), CIツール, Gitを用いて、
masterがpushされ次第、ExampleImage/Oxygen:latestのようなイメージを作成し、
docker-composeを用いてdown/pull/upするようにする。
Dockerイメージはソフトウェア、ミドルウェア、Webサーバーなんかをひとかたまりにしていて、
アクセスはnginx-proxyとかでコンテナ内部にリバースプロキシする。
よってWebやミドルは分割される。

の２つがあると思うのですが、
これをクラウドで動かす時、どちらの手法がメリットが大きいんでしょうか？

つまり、Dockerはいろんなリソースをひとかたまりにしている以上
顧客数が100などのオーダーであった場合、メモリの面で費用が嵩むような気がします。
その代わりDockerによって細やかな設定の手間は省くことができます。

対してAnsible,Chefでは運用の実態としては従来通りだが
修正だったり新規契約だったり毎に発生する作業を簡略化できます。
しかしながら都度軽いRecipeの修正が必要になってくるでしょう。

もちろんコンテナ内で動くプロセスの持つ負荷によりますし、
クラウドのコストというのも、Recipe修正で動く人の単価やサーバー単価によって変わってきますが、
この二者において、サービスがかなりスケールした時に、
明らかにどちらかの方が優れている、と言えることはあるのでしょうか。

付記

たとえばDockerを使うことでapacheのC10K問題のようなメモリ不足が
100ユーザーくらいできてしまうと目も当てられないですし、
Ansible+Chefで運用するにしても、たとえばnginx+PHPだと
(詳しいことは知りませんが)PHPはシングルスレッドなので、動作の低速化が懸念されるような気がいたします。
(=パフォーマンスが落ちる)

DBが分かれていることで不具合が起きた時に対処しやすそうなのはDockerですし、
でもDockerで--memoryを使うってなんか違う気がしますし、、
一部の顧客が高負荷になったときにAnsible+Chefでは共倒れしてしまいそうですが、
dockerならうまくバランスが取れそうです。
とはいえdockerを使うとベースのメモリ消費量が高いから、
そもそもスケールした時点でコストがものすごくかさんでしまいそうです。

クラウドで負荷に応じてAuto-Scalingできるとはいえ、
Dockerによってベース負荷がそもそもものすごく膨らんでいるのであれば、
同じAuto-Scalingであれば初期構成がAnsible+Chefであるほうが
夜中などのサービスが落ち着いた時間は全然コストがかからないなど、
軍配が上がりそうな気がしています。
とはいえ先ほど申し上げたように一つのWebクライアントに集約的な運用だと
落ちた時の信頼の損失とか、そういったコストが大きくなりそう....

そんなところで、全体のアクセスが集中しても1万くらい/顧客件数が100件程度であればAnsible+Chef,
それより高い負荷がやってくる/顧客数を持ったのであればDockerなのかな、なんて思うに至りましたが、
皆さんどうでしょうか。ぜひご意見お聞かせください！

行動規範の内容に同意します

回答1件

よく調査されている印象を受けました。
ただ、質問者さんはDockerをほとんど触った事がないのでは？
ちょっと軌道修正すれば良い感じの結論が出せるでしょう。

知っておいて欲しいのは、そもそもDockerはLinuxの1プロセスとして動作する仮想マシン風アプリなのでそんなにオーバーヘッドはありません。
またDockerを使ったからといって全てが全自動になるわけでもありません。

実際Dockerのコンテナを動かす為のオプションやdocker-compose.ymlファイルは依然Ansible等のプロビジョニングツールを使う事になるでしょう。

ぶっちゃけてしまうと質問文の大半はどうでもよくって、

Ansibleで接続してsudo service nginx startを実行
Ansibleで接続してdocker run タグ名 optionを実行

このどちらかになるくらいの違いしか無いわけですね。

Dockerを使うことでapacheのC10K問題のようなメモリ不足が

100ユーザーくらいできてしまうと目も当てられないですし、

いや、そもそもこれメモリの問題じゃないんで…
Apache2.2が10Kの同時アクセスを捌けず、慌ててCPUやメモリを追加しても性能が伸び悩む現象を指しています。

これは単にApache2.2の作りが悪くて多数のアクセスを捌けないだけの問題です。
ただし、我々普通のエンジニアがWebサーバアプリを自作するとなった時に、普通に設計して実装したら同じ問題出ちゃうよね〜ということで騒がれただけの話です。

その後NginxやApache2.4が登場しC10K問題は過去の話になりました。
Dockerとは違う話なんで一緒にしないようにしてくださいね。

ここからどの様に調査していけばいいかをざっくり解説します。
そもそもApacheとNginxを使った時にPHPとどういう関係で動かしているかよくわかってないんじゃないかと思いますのでそこから

Apacheはディレクトリとサーバのパスを1:1で紐付ける事が大前提の静的ファイルを配信するWebサーバです。
PHPを動かしたいという人の為にmod_phpというモジュールが別途用意されており、これを組み込んだApacheは(設定ファイルを確認しながら)PHPのプロセスを4つほど立ち上げます。
PHPファイルへのアクセスが来た場合、空いているPHPのプロセスへファイルを読み込ませて実行、出力結果をクライアントへ返し、PHPプロセスは即刻再起動する作りになっています。

Nginxはmod_phpのようなモジュールは提供されていません。
PHP-FPMという高速に動作するサーバを別途立ち上げてそこに接続を受け流しています。
参考サイト: nginx と PHP-FPM の仕組みをちゃんと理解しながら PHP の実行環境を構築する

PHP-FPMはApacheのmod_phpと似たような挙動で、空のPHPプロセスを4つほど立ち上げて、処理が終わったらプロセスは削除しないで変数等を初期化して使い回すちょっと賢い設計だったかと記憶しています。

まぁ要するにmod_phpもPHP-FPMも空のPHPプロセスを複数立ち上げてるだけで、
アクセスが来ない限りそんなにメモリを食わないよって所が重要です。

Dockerでやる場合、大まかに2つの手法があります。

PHPファイルを含めたイメージを生成し、本番環境ではpull後にrunするだけ
PHP-FPM等の必須ライブラリだけ突っ込んで、PHPファイルはrun時に-vオプションで注入

質問文で想定しているのは前者で、マイクロサービスの理想はそちらにあるでしょう。
ビジネスロジックをDockerHubのパブリックで配信するわけにはいかないでしょうから、
DockerHubのそこそこお高い月額料金を支払ってプライベートリポジトリを起動するか、
自分でDockerイメージのホスティングサーバを立ち上げて管理するかの二択になるでしょう。

しかし後者のような使い方もありますが、こちらは本番環境でgit pull等を利用して変更後のPHPファイルを受け取る手間が発生します。
ここで登場するのがCIツールやAnsible等ですが、この場合はやってる事は従来通りの手法なので普通にサーバ立ち上げた後のコマンドが変わるだけです。
Dockerなんで別にファイルを外から注入してもそんなにパフォーマンスは落ちません。
質問文のケースは大量のWebサービスを1つのマシンで運用したいとのことなので、
後者の方が良いんじゃないかな？感はありますね。

投稿2018/08/26 05:19

miyabi-sun

総合スコア21158

yokatone

2018/08/26 13:03 編集

ありがとうございます。これまで、Dockerでいろんなサービスのパッケージ(Redmineとか、GitLabとか...)を1つのマシンで立ち上げて複数動かしてると、動作が重くなってしまったり、Dockerがハングしてしまったことがあって Dockerってリソースたくさん食うのかな？たくさんコンテナを立ち上げすぎると不安定になるのかな？っていう疑問がありました。 (もちろんこの不安定には配布イメージの構成だったりがあるんだと思います。 GitLabはDockerであろうが、サーバー設置であろうが、メモリ設定を適切にしないと動作が安定しませんし....）なので、そこを出発点として、なんというか....サーバーとWebサーバーソフトウェアが1対1である場合と、 Dockerによって1対多になる構成の場合(Dockerとサーバーが1対1)とで、もしパフォーマンスに差異があるのなら、いろんなリスクを考えてもどっちの方が利便性だったり動作として良いのかなってところでした。結局Dockerの消費するリソースっていうのは大きく考えなくてよくて (OSを内包してるからといって、そんなにオーバーヘッドはない) 究極ソフトウェアはメモリとCPUがあれば処理はいくらでも捌けるものであり、 C10Kなど、諸般の問題っていうのは結局作りの問題に過ぎなくて、 Dockerが安定していて、nginx+FPMという優れた仕組みがある以上、サーバーとWebが1対1であろうが、1対多であろうが、どっちでもいいって感じなんですね。いろいろ勉強になりました。ありがとうございました :D

行動規範の内容に同意します