イベント
コンテナ技術「LXD」で競争力強化！ GMOデジロックが移行体験を語る
第10回 HosCon - GMO Hosting Conferenceレポート
2017年9月13日 06:00
GMOインターネットグループは7日、グループ内のホスティングサービスの技術を紹介する「第10回 HosCon - GMO Hosting Conference」を開催した。
今回は、ホスティングプラットフォームでのコンテナの本番投入がテーマとなり、GMOデジロックの「XREA」「CoreServer」と、GMOペパボの「LOLIPOP! マネージドクラウド」のそれぞれの取り組みが語られた。
LXDコンテナでホスティングサービスの集約率を向上
GMOデジロックでは、ホスティングサービス「XREA」をコンテナ技術「LXD」でリニューアル。すでに移行は完了して実運用中となっており、続いてホスティングサービス「CoreServer」をリニューアル中だという。
LXDはコンテナ技術の一種。Dockerのようなアプリケーション単位のコンテナとは異なり、ハイパーバイザーのように、1つの仮想環境まるごとをコンテナで動かすのが特徴だ。
GMOデジロック株式会社 技術部の藤田伸広氏の発表での言葉によると、同社は社員11名。そのうち、藤田氏と、代表取締役社長の平岩健二氏を含む計3名でLXDを調査したという。なお、発表のときも平岩氏が客席におり、質疑応答への回答に参加していた。
もともと同社は2011年にGMOグループ入りしたタイミングで、物理サーバーをKVMによる仮想化に移行して、400台弱のサーバーが2ラックに収まったという。LXDへの移行も同様の流れにあり、CPU、メモリ、ストレージといったリソースの無駄をなくして集約率を上げるものだ。具体的には「40台あった物理サーバーが、LXDに移って1ラックに収まった」とのことだった。
移行は、2016年夏にコンテナの採用を決めてから本番まで半年。2017年2月に運用をスタートし、5月にすべてリニューアルを完了した。規模は、アカウント数が約30万、データ量が約50TBだという。リニューアルにあたって、ストレージもオールフラッシュにしてRAID10構成とした。ホストOSにはLXDの動作に問題が少なかったUbuntu 16.04 LTSを、ゲストOSには共有サーバーで使い慣れたCentOS 7を選んだ。
構築時や運用時の技術的トラブルもいくつか語られた。例えば、オープンファイル数の上限や、PID数の上限、共有メモリの上限などによりコンテナ数が20台を超えたあたりから不安定になる現象があり、カーネルの設定を変更して対応したという。これについては具体的なカーネルパラメータを挙げて解説がなされた。
また、時間がたつとコンテナのネットワークがつながらなくなるというトラブルについては、1カ月半ほど調査した結果、ネットワーク機器のバグだったことがわかったという。
そのほかCoreServerについて、タグVLAN構成でネットワーク機器のCPU負荷が90％以上になる現象があり、調べたところコンテナのNICを複数作成したときにMACアドレスが重複していたことが原因だったとわかったとのこと。
運用時の苦労についても、プロセスの起動数制限をかけていたが全コンテナでUIDが共通のため全コンテナのプロセス数が対象になってしまった件や、ファイルシステムのZFSがボトルネックになっていたのをチューニングして安定稼働させた件などが紹介された。
移行してみての結果としては、物理サーバー数が少なくなり、集約率が上がったぶん高速なCPUやSSDなどを利用でき、以前より快適に利用できるようになったと報告。「競争力のあるサービスになり、ユーザー数は増加。LXD最高」と藤田氏は結論づけた。
発表の間や後には、参加者からも多くの質問がなされた。LXDの冗長化構成についての質問や、LXD自体のアップデートの問題、Dockerとの違いなど、おそらく現場のエンジニアからと思われる声がいろいろ聞かれた。
オンデマンドでホスティング環境が動くFastContainer
GMOペパボでは、コンテナで動作する新サービス「LOLIPOP! マネージドクラウド」について、仕組みを解説した。LOLIPOP!の一連のレンタルサーバーをリニューアルしており、その一環で作られたサービスだ。現在、招待制のαテストを実施中で、冬ごろに正式リリース予定だという。
GMOペパボ株式会社 ホスティング事業部インフラチームの田中諒介氏の発表によると、LOLIPOP! マネージドクラウドでは、FastContainerアーキテクチャとコンテナエンジンhaconiwaを採用しているのが特徴となっている。どちらも同社の開発による。
一般的なWebホスティングでは、ユーザーのコンテンツやプロセスが特定のサーバーに紐づいている。それに対してFastContainerでは、Webのアクセスがあったときにコンテナが作られて、ユーザーのサービスやコンテンツがその中で動く。コンテナは一定時間で自ら終了する。これを田中氏は「ざっくりいうとFastCGIのコンテナ版のようなイメージ」と説明した。
この機構を元にしたLOLIPOP! マネージドクラウドのセールスポイントとして、コンテナイメージを用意しておけばさまざまなWebアプリをすぐに開始できること、一定時間ごとにコンテナが作り直されるため自動で最新のセキュリティが適用されること、オートスケールすることを挙げた。また、運営側にとっては、アクセスされていないコンテナが停止することでリソースの節約にもなる。
田中氏はLOLIPOP! マネージドクラウドの内部構成についても解説した。コンテナが動く部分「compute」の前段に「WebProxy」があり、それとは別にコンテナを管理する「CMDB」がある。プロジェクトを作るとCMDBにコンテナの情報が登録されるが、この時点ではコンテナは起動しない。リクエストが来たときに、WebProxyから見てコンテナが起動していなければ起動させ、それをCMDBに反映させる。
なお、ユーザーのデータはコンテナ外のdatapoolに置かれて、コンテナからNFSでマウントする。また、WordPressで使うデータベースは、コンテナではない形で動作している。
コンテナには寿命が設定されており、起動して一定時間がたつとhaconiwaから終了させ、CMDBにも反映させる。オートスケールについても、haconiwaが負荷を監視し、CMDBの「予約枠」を変更することで、リクエストのタイミングで新しいコンテナが起動する。スケールインするときも、CMDBの情報を変更し、コンテナが寿命に達することで縮退する。
現在のαテスト段階では、コンテナイメージはWordPressのみ。今後、コンテナの種類も増やしていきたいとのことで、RailsとNode.jsのイメージが調整中でまもなく提供されるという。
この発表についても、参加者からさまざまな質問が出た。課金体系については現在サービス設計中だが、コンテナが停止している間は課金しない方向で考えているとの回答だった。コンテナごとのリソース制限もユーザーが設定できるように検討中という。またαテストに参加している人からは、不安定な状態についての質問も出て、田中氏と議論が交わされた。
