第11回 HosCon - GMO Hosting Conference - @大阪 に参加したので、そのメモです。
会場
グランフロントタワー B の 梅田・GMO Yours での開催でした。 前に何かの勉強会で一度来たことがあるような気がするのですが、何だったか思い出せませんでした。
タワー B 自体は最近 Rails Developers Meetup #4 大阪会場 で来ていました。
その他
ハッシュタグは #hoscon でしたが、ツイートはあまりありませんでした。
https://twitter.com/rzl5/status/908276901914882049 に写真がありますが、 ConoHa カードをもらったので、使ってみたいと思いました。
コンテナ基盤であるLXC/LXDを本番環境で運用する話
- 2011年に物理からKVMによる完全仮想化へ
- 完全仮想化はリソースに無駄があるということで準仮想化、コンテナ化へ
- なぜLXDか?
- 他に検討した選択肢は Docker, KVM, OpenVZ, (VMware は高いので選択肢に入らず)
- 質問: Linux だけで Windows や BSD はなかった? カーネルモジュールなども問題なかった? → Linux で、カスタマイズはしていたが共通の kernel だったので問題なく集約できた。
- 質問: OpenVZ が遅かった? → 一般的には遅くないかもしれないが、試した環境ではコンテナより遅かった。
- LXDは2017年2月から運用開始
- ホストOSは Ubuntu 16.04 LTS
- ゲストOSは使い慣れたCentOS
- なぜZFSか? → 公式がオススメしているのとベンチマークの結果がよかった
- 今も苦労している部分はある
- fio で計測
- ZFS を採用した理由: 機能性、柔軟性, 比較対象: lvm, dir
- ホストシステム構築時のトラブル
- オープンファイル数の上限など色々な上限に引っかかった
- ネットワーク編
- NIC の MAC アドレスがかぶっていた
- LXD 運用編
- Apache RLimitNPROC にひっかかった
- ホストのロードアベレージが急激に上昇 → ZFS がボトルネックだったのでチューニングを実施 (ZFS ARC?)
- 2ラック (KVM) → 1ラック (LXD)
- 質問タイム
- LXD で新しくサービスできるようになったことはある? → 新たなサービスはないが、快適なディスクIOを提供できている
- まだリリースできていないが、準専有の基盤ができた
- ZFS はメモリをたくさん使って残りがユーザーの領域? → ご想像にお任せします
- どのようなところで運用負荷の軽減? 運用でカバーしているところ? → 物理が減ったので楽になった。リソースの制限の自動化を目標に手動でやっている。物理より柔軟にできるのが良い。
- ライブマイグレーションをしているかどうか? → やっていない。今後対応していく。
- 内製でコントロールパネルのようなものを作っている? → ない。全部コマンドで。
- CentOS? → 既存のノウハウをいかすために選んだ。
- OS のアップデートはどうしている? → カーネル以外は通常のアップデート
- ホスト側のリソース監視はしていると思うが、コンテナ側はどうしている? → 緩めの limit を設定してる
- PHP などのバージョン違い? → 問い合わせで個別に対応することもある
- サポートが終了したものはなるべく引き継がない
- CentOS 6? 7? → 7
休憩
20:16 まで
ロリポップ！マネージドクラウド FastContainerの裏側
- ロリポップ！マネージドクラウドは FastContainer アーキテクチャを採用していて、コンテナエンジンに haconiwa
- 質問: 価格? → 価格についてはまだ未定
- オートスケール
- 質問: 何をもってマネージド? → コンテナの起動の仕方が特殊 (FastContainer) で、完全に root 権限があるわけではないなど
- 質問: データベース? → データベースはコンテナで動いていないので、オートスケールではない
- 質問: オートスケールは php だけ? → apache + php
- 質問: データベースがオートスケールではないのなら、ユーザーごとのリソース制御? → まだ未確定
- 質問: 具体的にアクセスが増えると、とは? → 実際は CPU のスロットルタイムをみているので、CPU の負荷が高くなれば。
- 逆に負荷が下がればコンテナを減らす。
- 質問: ユーザーごとのリソースの分割? 他のユーザーの影響は受けるのか? → 基本的には影響は受けない。リソースは分離している。ホスト自体が重くなっても負荷分散できるアーキテクチャになっている。
- FastContainer とは?
- FastCGI のコンテナ版といったイメージ
- リクエスト契機で Web アプリのコンテナが起動
-
一度起動したコンテナはその後しばらく使い回して、一定時間が経過したら終了
- 利点
- オートスケール
- リクエストがないと停止するのでリソースの節約
- いろんなコンテナで色々なアプリを提供
- 常に最新
-
他のマシンへの載せ替えも楽
- マネージドクラウドの構成
- CMDB というところでコンテナの情報を管理
- 質問: 構成が速度に影響があるか? → ある。今は動くものを優先。 nfs が重いというのは多方面から突っ込まれている
- 質問: 起動していない時と起動している時のパフォーマンスの差? → 確かにたちがっていない状態のアクセスは時間がかかる。調整中
- 質問: どこが大きくなっていく? compute? → 今のところ compute と datapool が増えるのを想定している。
- パフォーマンスは調整していく段階なので、今後機会があれば。
- ngx_mruby
- haconiwa
- コンテナ
- 基本は1コンテナに1プロセス
- ssh も sshd コンテナ経由
- FastContainer リクエスト制御フロー
- 質問 → 今はチューニングがすんでいないので初回は 2,3 秒ぐらいかかる
- 質問 → ユーザーが予約枠を設定していて、そこまでしか上がらないようにしている
-
予約枠は金額で設定できるようにしたい
- コンテナの死
- コンテナの寿命: lifetime が設定されていて一定時間経過で自動停止
- なぜ寿命?
- リソースの節約
- 新しくなるタイミングでライブラリなども更新されてセキュア
- 別ホストに移行したい時も CMDB をいじるだけ
- compute のメンテも簡単
-
質問: リクエストが有る限り死なない? → lifetime で死ぬ
- オートスケール
- haconiwa が cgroup から各コンテナの CPU, I/O 負荷を計測・監視
- ユーザーはコンテナの予約枠を設定可能
- スケールインは CMDB の変更だけで停止は自動停止任せ
-
予約枠を取るだけでオートスケール
-
コンテナの種類も増やしていきたい
- 質問タイム
- 予約枠? パケット量をみる? → 設計中。基本的には使ったぶんだけ課金する予定?
- コンテナのサーバー自体が高負荷になったり物理的な障害が起きても自動でフェイルオーバー? → 自動ではできていない。手動でのせかえることはできる。自動化は可能ではある。
- SSL 証明書? Symantec のような台数分の場合とか → あとで
- オートスケールをする監視をしている間隔? → 暫定で1秒
- オートスケールの課金の指標は? ニュースで取り上げられる予定だから、とか。 → 設計中
- 聞き逃し
- WAN の IP は共有? → 共有
- コンテナはドメインでみている
- IP アドレス単位で他のユーザーの影響は受ける可能性がある
- 現状 CMDB はデータベースのフェイルオーバー任せなので、そこが止まると止まる可能性はある
- のせるアプリの開発環境? → 将来的には用意したい
- 聞き逃し → コンテナ単位でどのくらいパフォーマンスが出ているかだそうとか色々話はある
懇親会
5分休憩の後で懇親会でした。
感想
LXD を採用したという話自体は以前に別の勉強会で聞いたことがあったので、それと重複した話もありましたが、もっと技術的につっこんだ話も聞けておもしろかったです。
LXD は他では使っているという話を聞いたことがないので、使っている人はもっと情報を出してくれればいいのに、という気がしています。 個人的には、情報がなくて探しても何もわからないよりは、Docker のように情報がたくさんあって玉石混交で、自分で見極めないといけない、という状態の方が望ましいです。
マネージドクラウドの話は haconiwa って作ってみたというようなものじゃなくて、ちゃんと実用的に使うためのものだったのかというのが驚きました。 FastContainer は用途があえば良さそうな感じなので、機会があれば使ってみたいと思いました。