サーバサイドのOS環境にはdockerなどの標準的なコンテナ技術を積極的に採用していく方針をとっています。
コンテナを活用することで異種環境を混在させることなく共存させられるため、長期的にはJavaやRuby、PHPといった異なる技術スタックのうえに構築されたアプリケーションを手軽に利用していきたいと考えています。
まず手はじめとして現状の施策としては、ローカルマシン上の開発環境でdockerを利用し、簡易的なWebサーバーを構築するところから着手しています。
ローカルのWebコンテナを動かすことで、主に以下の3点のメリットが得られます。
- 短期間の作業でパブリッククラウドにシームレスに移行できる
- 当初からマルチホスト構成で検証を進められる
- kubernetesなどのオーケストレーション環境への移行パスがある
パブリッククラウドへのシームレスな移行
RailsやFuelPHPといったWebアプリケーションフレームワークを利用して開発したサービスでは、アプリケーションそのもののコード開発と別に、一定のOS環境依存が発生します。
実験的に立ち上げるサービスが運営途中でアクセスが増えて来た場合、ホスト環境の移行がつきものになってきます。
このようなケースでもdockerでコンテナイメージやその構築手順を確立しておけば移行がスムーズになります。
パブリッククラウドの事業者はdockerのサポートを拡大しており、またクラウドサービス側のdockerサポートが弱かったとしてもCentOSやUbuntuなど広く使われているOSの標準構成に取り込まれているため、開発環境のイメージはクラウドに移行しやすくなりつつあります。
パブリッククラウドは仮想VMの選択肢が多いため、性能面でもスケールしやすく、またネットワークレイヤのセキュリティ強化施策も追加導入しやすくなります。
マルチホスト構成の獲得
dockerでは1コンテナ＝1サービスという構成を指向していることもあり、たとえばApache+PHPとMySQLの2コンテナ構成をとることが多くなります。
1台の開発機（たとえばノートPC）で複数のOSを立ち上げることは従来のVMでは無駄が多かったのですが、コンテナではオーバーヘッドが少ないため特に問題なく複数のOS環境を構築できます。
本番環境でも開発機上のWebサーバーとDBMSの接続設定をある程度活用できるため、ネットワーク構成上は処理容量の上限を相当かせぐことが可能になります。
このようにdockerでひとまずアプリケーションが動作する環境を作っておけば、先々アクセスが増えて環境を移行するケースが発生しても短期間で構築しやすいというメリットを得られます。
Railsの環境構築については、「 dockerでRailsの開発環境を手軽に準備」で具体的に解説しています。
kubernetesなどへの移行パス
dockerベースのシステムを運用してみて分かったことは、dockerを本番環境で直接実行するのはやや難がある、ということです。
せっかくパッケージ化した実行環境なので、無数のコンテナを管理できるオーケストレーションツールを活用して運用するところまでセットアップした方が大きなメリットを得られます。
dockerのオーケストレーションツールとしては、 kubernetesが有望と考えられます。Googleが Container Engine(GKE)を提供しているため、クラスタ環境についてはミドルウェアのセットアップ不要で利用できます。
また、kubernetesはdockerのコンテナ間link機能（–linkオプションと環境変数）と互換性を持たせるように設計されているため、うまく構築すればローカルのdockerコンテナイメージ群をそのまま本番のkubernetes環境に配備できます（Volumeに依存しないイメージを作る必要があるなど、多少の制約はあります）。
アプリケーション層については、Google Container Engineに載せるだけでいきなり負荷分散とインスタンスの稼働維持が両立します。Google Compute Engineはライブマイグレーションが完備していることもあり、サーバーの物理障害をほとんど考える必要がなくなります。
さらに、サービスの成長に合わせてGCEのインスタンスから必要な環境を選択して簡単に移行できるようになります。
Chuma Takahiro
関連記事
