Embed Size (px)
Citation preview
田中諒介 / GMO Pepabo, Inc.
2017.09.07 GMO HosCon 10
ロリポップ！マネージドクラウドFastContainerの裏側
エンジニア
田中諒介 @ry_023
ホスティング事業部インフラチー
ム
2016年3月熊本大学大学院情報電気電子工学専攻修了
同年4月 GMOペパボに新卒エンジニアとして入社
2017年1月からインフラチーム配属
目次
• 1. ロリポップ！マネージドクラウドについて
• 2. FastContainerとは？
• 3. マネクラの構成を通して解説
•リクエスト制御フロー、コンテナ停止、オートスケール
• 4. 統括・FastContainerの良さふりかえり
ペパボのホスティングサービス
ロリポップ！の新プラン
αテスト実施中！
一般的なWebホスティング
•ユーザのコンテンツ・プロセスが特定のサーバに紐づく
•負荷分散の難しさ…
•急なアクセス増へのスケールの難しさ…
•他サーバへの移行の難しさ…
ロリポップ！マネージドクラウド
•ロリポのプランの一つだが、バックエンド・フロントエンド共に一新
•コンテナ型ホスティングサービス
• FastContainerアーキテクチャを採用
•コンテナエンジンにhaconiwa
ロリポップ！マネージドクラウド
オートスケールで
急なアクセスにも対応
自動で最新の
セキュリティ
様々なWebアプリを
すぐに開始
使いたいアプリ選んで プロジェクト名入力するだけ できる！
すぐにWebアプリを提供！
すぐにWebアプリを提供！
オートスケール
アクセスが増えると
複数台のコンテナでアクセスを受ける
オートスケールを有効に
今日はロリポ！マネクラがどういうように動いているか
というお話を
FastContainer
FastContainerとは？ ざっくり概要
• FastCGIのコンテナ版といったイメージ
• CGIのプロセスを終了せずに使い回す
•リクエスト契機でWebアプリのコンテナが起動
•一度起動したコンテナはその後使い回す
•一定時間経過すると自ら停止する
FastContainerの良さ
•オートスケール
•リクエストがないとコンテナは停止するのでリソースの節約
•色んなコンテナを用意することで色々なアプリを提供
•生まれ代わり続けるので常に最新
•他ホストへのコンテナ載せ替えも簡単
•負荷が少ないホストにコンテナを起動させるようにする等も
• compute母艦の無停止メンテもできそう
ロリポの構成を通してFastContainerを見ていきます
マネージドクラウド全体構成
compute1
CMDBCoreAPI
LBClient
datapool
container1
compute2
nfs
nfscontainer2
container1 status:
enabled
host: compute1
container2 status:
enabled
host: compute2
コンテナの情報
Webproxy
実際コンテナが起動するホスト
コンテナの情報を管理→
FastContainer関連の構成
ユーザの
コンテンツ(/var/www/ 配下)
ngx_mruby
•弊社@matsumotory開発 nginx拡張 (mod_mrubyもあります)
• Nginxの各イベントにhookしてmrubyを実行できる
•ロリポ！マネージドクラウドではプロキシ時にCoreAPIに問い合わせ
たり、haconiwaを実行したりするのに活用
location / {
...
mruby_set $backend /var/lib/mruby/hook.rb cache; # script実行
proxy_pass http://$backend:80;
}
haconiwa
•弊社@udzura開発コンテナエンジン
• mrubyのDSLで設定(hacofile)を記述可能
•コンテナのリソース制限も(cgroupによる制限)
Haconiwa.define do |config|
config.chroot_to Pathname.new("/var/lib/haconiwa/rootfs/php")
...
config.cgroup["cpu.cfs_period_us"] = 1000000 # cpu使用率を制限(20%)
config.cgroup["cpu.cfs_quota_us"] = 200000 #
config.cgroup["pids.max"] = 128 # プロセス数を制限
end
マネクラのコンテナ
• haconiwaにより起動, hacofileで設定
•コンテナ種別毎に母艦(compute)上にrootfsを用意してsymlink
• container:/ → compute:/var/lib/haconiwa/rootfs/php/
• /var/www などのユーザ領域はdatapoolをmount
• initプロセスにミドルウェアを指定して起動
•アプリ種別ごとにhacofileを用意することで色んなコンテナ作れる
なんでもコンテナ
•基本は1コンテナに1プロセス
• apacheコンテナ
• sshdコンテナ
• postfixコンテナ？
FastContainerリクエスト制御のフロー
compute1
CMDBCoreAPI
LBClient
datapool
compute2
nfs
nfs
container1 status:
ready
host: compute1
コンテナの情報
Webproxy
プロジェクト開始直後
ready=待機中
compute1 datapool
compute2
nfs
nfs
コンテナの情報
プロジェクト開始直後
container1 status:
booting
host: compute1
CoreAPI
LBClient Webproxy
CMDB
プロキシ可能な
コンテナ情報を取得
クライアントから
リクエスト
compute1
CMDBCoreAPI
LBClient
datapool
compute2
nfs
nfs
container1 status:
booting
host: compute1
コンテナの情報
プロジェクト開始直後
クライアントから
リクエスト
コンテナのIP等を
ヘッダに負荷しプロキシ
Webproxy
compute1
CMDBCoreAPI
LBClient
datapool
compute2
nfs
nfs
container1 status:
booting
host: compute1
コンテナの情報
Webproxy
プロジェクト開始直後
クライアントから
リクエスト
コンテナのIP等を
ヘッダに負荷しプロキシ
目的のコンテナのIP:80が
LISTENしてない
compute1
CMDBCoreAPI
LBClient
datapool
compute2
nfs
nfs
コンテナの情報
Webproxy
プロジェクト開始直後
クライアントから
リクエスト
container1
コンテナ起動！！
container1 status:
enabled
host: compute1
enabled=稼働中
container1 status:
enabled
host: compute1
compute1
CMDBCoreAPI
LBClient
datapool
compute2
nfs
nfs
コンテナの情報
Webproxy
プロジェクト開始直後
クライアントから
リクエスト
container1
コンテナ起動！！
enabled=稼働中
compute1
CMDBCoreAPI
LBClient
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
Webproxy
プロジェクト開始直後
container1
2回目以降のリクエストは
コンテナ起動済みなので高速
コンテナの死
コンテナの寿命
•コンテナにはLifetimeが設定されており、一定時間経過で自動停止
• haconiwa のhookでコンテナのプロセスをKILL
•利用中のコンテナが停止する際はコンテナを待機中として登録し直す
•次のリクエストでまた新しいコンテナが起動する
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
コンテナの寿命
＼寿命きた／
container1
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container2 status:
ready
host: compute1
コンテナの情報
コンテナの寿命
待機中(ready)
コンテナを再登録
HALT
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container2 status:
enabled
host: compute1
コンテナの情報
コンテナの寿命
LBClient Webproxy
リクエスト契機で
新しいコンテナ起動
container2
コンテナに寿命があることで…
•リクエストがないコンテナは勝手に停止し、リソースを食わずエコ！
•定期的にコンテナが新しく生まれ変わる
•新しくなるタイミングでライブラリ等も更新されセキュア
•コンテナを別ホストに移行したい時もCMDBをいじるだけでOK
•コンテナは明示的に停止させずとも勝手に死ぬ
• compute(コンテナの母艦)のメンテしたい時も簡単
オートスケール
オートスケール
•コンテナの負荷に応じて、コンテナ数を増減
• haconiwa がcgroupから各コンテナのcpu・i/o負荷を計測・監視
•ユーザはコンテナの予約枠を設定可能
•コンテナが何台まで起動するか、それぞれのコンテナでリソースを
どれぐらい使うかなど事前に決定しておく
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
スケールアウト
container1
container2 status:
disabled
host: compute1
予約枠を登録
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
スケールアウト
container1
container2 status:
disabled
host: compute1
予約枠を登録
＼負荷やばい／
コンテナ増やして！
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
スケールアウト
container1
待機コンテナに
変更container2
status: ready
host: compute1
LBClient Webproxy
リクエスト契機で
新しいコンテナ起動
container2
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
スケールイン
container1
container2
status: ready
host: compute1
container2
＼さほどでもない／
コンテナ減らして！
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
スケールイン
container1
container2
＼さほどでもない／
コンテナ減らして！
container2 status:
disabled
host: compute1
再びdisabledへ
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
スケールイン
container1
container2
container2 status:
disabled
host: compute1
LBClient Webproxy
container2には
ルーティングされない
compute1
CMDBCoreAPI
datapool
compute2
nfs
nfs
container1 status:
enabled
host: compute1
コンテナの情報
スケールイン
container1
container2
container2 status:
disabled
host: compute1
LBClient Webproxy
container2には
ルーティングされない
これは放っておけば
勝手に停止する
予約枠をとるだけでオートスケール
FastContainerの良さ
•オートスケール
•リクエストがないとコンテナは停止するのでリソースの節約
•色んなコンテナを用意することで色々なアプリを提供
•生まれ代わり続けるので常に最新
•他ホストへのコンテナ載せ替えも簡単
•負荷が少ないホストにコンテナを起動させるようにする等も
• compute母艦の無停止メンテもできそう
コンテナの種類も増やしていきたい
アプリの調整など進捗
αで提供中！
調整中! 間もなく
その他続々……？
ロリポ！マネージドクラウドをよろしくお願いします！
君もペパボで働かないか？
最新の採用情報をチェック→ @pb_recruit
