事例から考えるDockerの本番利用に必要なこと

Dockerを取り巻く最新の状況

2016年4月13日にDocker 1.11がリリースされた。PaaS基盤としてのDockerをより便利に利用するために、ネットワークの機能やセキュリティ対策や構成管理ツールの機能が強化されている。さらに2月24日には、クラウドプラットフォーム上でコンテナの統合管理を行うDocker Datacenterもリリースされている。

さらにDocker社は豊富な資金力により、SDN（Software Defined Networking）企業であるSocketPlane社や、ハイパーバイザ型でDockerコマンドとの連携を実現している軽量OSを開発したUnikernel Systems社、DockerコンテナをパブリッククラウドにデプロイするSaaSサービスを提供するtutum社など、多数の企業を買収している。Docker社は各社の製品を統合し、PaaSプラットフォームを構築するツールのみではなく、Dockerをベースとした各種サービスを提供する企業へと成長している。

一方、パブリッククラウド側もDockerに対応するサービスの提供が着々と進められている。たとえばAmazonはAWS/EC2ともにDockerに対応させており、具体例としては、AWS Elastic Beanstalkでアプリケーションをインストール済のDockerコンテナを提供している。さらにAmazon EC2 Container Registryでは、ユーザが作成したDockerコンテナを管理するコンテナレジストリを提供している。

Googleも、Google Compute EngineでのDockerへの対応状況を公開している。OSSのDocker環境のクラスタリングツールのKubernetesが提供されており、さらにDockerコンテナレジストリとしてGoogle Container Engineも提供している。

Microsoftも、Microsoft AzureでCoreOSの仮想マシンイメージを提供しており、利用ガイドも公開している。さらにAzure Marketplaceでも、アプリケーションをインストール済みのDockerコンテナイメージが提供されている。

DockerをPaaS基盤として構築・運用できるOSS製品として、OpenStack Magnum、OpenShift、Apache Mesosなど、多数の製品が次々とリリースされ、Dockerの注目の高さがうかがわれる。利用する側としては、選択に迷うほどである。

Docker社や各ベンダーからの製品やサービスは多数リリースされているが、特に国内での本番業務での利用はなかなか進んでいないように見受けられる。現状では実際の導入事例などの情報が少なく、Dockerの便利さは理解しているが、どのように活用すればいいのか戸惑っている状況なのではないだろうか。

本記事では、Dockerを活用されている企業が公開されている、先進的な事例をご紹介するとともに、本番業務で活用するために必要となる技術やノウハウについて考えていきたい。

なお本記事の内容は筆者の私見であり、所属する企業の見解ではないことをご理解いただきたい。

開発環境の事例

公開されている事例を見ると、やはり開発環境としてITエンジニアが利用しているケースが非常に多く、特にOSS製品を利用する開発ではスタンダードになりつつあると言っても良い状況と思える。これらの事例の中から、Dockerを非常に有効に活用している事例についてご紹介する。

事例１：「Dockerを活用したリクルートグループ開発基盤の構築」

リクルートグループのIT・ネットマーケティングテクノロジーの 開発・提供を行っている株式会社リクルートテクノロジーズの吉田尚弘氏の講演資料から引用している。大規模システム保守の、多面並行開発環境の運用の事例となる。

導入前の状況

ご存じのとおり、リクルート社は非常に多岐に渡る情報提供サービス事業を運営されており、その情報の更新頻度はめまぐるしいものがある。その中の一部であるリクルートポイント（現在はPonta Pointに統合されている）の管理システムでは、ミッションクリティカルなシステムであるにも関わらず、更新頻度が基幹システムでも最低月に1回、サイト向けの開発環境は常に40面以上（＝40件以上の改修が並行で行われている）状態となっている。

この開発環境を維持するために専任のインフラ担当者を置き、次の開発が始まるたびに環境のクリーンアップを手作業で実施していた。そのため運用負荷も高く、環境の利用申請から利用開始まで10日ほどのリードタイムが発生してしまっていた。そこで運用のコストとリードタイム削減のために、Dockerを導入することとなった。

対応

上記の問題を解消するために、以下の対応を実施している。

• 開発で利用するサーバを、Dockerコンテナイメージとして作成しておく
• 開発環境提供時の構築・設定作業は、Dockerfileを利用した自動化を実現
• Dockerコンテナによる開発環境の提供を、利用者が直接実施できるUIを提供
  →UIはClojure開発したオリジナルシステムを提供している

導入効果

その対応で得られた効果は以下のように、驚くべきものである。

• 開発環境の提供期間を10日→10分に短縮
• 開発環境のインフラ運用コストを90%削減

注目点

本事例で注目するポイントは、以下と考えている。

• ビルド環境、テスト実行環境、CI（Continuous Integration：継続的インテグレーション）環境などの開発環境を、自動生成し提供する機能を実現している
• 開発環境を自動提供するUIを、開発者に直接提供している
• Dockerコンテナ化できる部分とできない部分を、適切に分けている

開発環境の自動提供を実現するためには、開発環境を標準化し、利用する環境を最低限のカスタマイズで利用できる状態が実現できている必要がある。おそらくリクルート社では本番環境も含めて、標準化が適切に行われているのだと考えている。

必要な時に、開発者が自らの手で開発環境の構築ができるというのは、開発者のストレス低減に大きく貢献している。DevOpsの求められる形が実現できている。

Dockerコンテナ化する機能と、対象外にする部分の見極めも非常に重要なポイントとなる。Disk I/Oの多いRDBなどの製品や、サーバ間の双方向のネットワーク通信が必要となる分散ストレージなどの製品は、Dockerに不向きとなる場合も多い。さらに商用製品は、ライセンス上の問題からDockerコンテナ上で利用できない場合もあるので、十分な検討が必要である。

事例2：「Docker を使った開発環境構築事例（KLab株式会社）

ソーシャル・携帯ゲームを提供されているKLab株式会社の技術ブログから引用している。多くのサービスの保守開発を行っている環境における、維持管理の効率化を図る事例となっている。

導入前の状況

開発環境としてWebサーバやRDBなどをすべてインストールした仮想マシンを配布する形で開発環境を提供していたが、以下のような問題が発生した。

• 配布したVMを個人好みに育ててしまって、アップデートの心理的障壁となっている
• 追加のミドルウェアを導入したが、環境のアップデートの伝播が行いにくい
• 個人が検証目的などで言語のバージョンを変えたり、追加のエクステンションなどを入れたりしたが、それを元に戻していない

その結果、チーム内メンバー間の環境の違いによるトラブル（テストが通らない等）が発生するという「けしからん」事態になってきたという。

開発案件が保守で長期化するとありがちな問題で、あるあると思われているインフラ管理者も多いだろう。利用者による環境の変更や、アップデートの適用状況などで分散された開発環境の乖離が広がってしまうことはよく発生する。それにより、「開発者の環境では動作するが、結合テストでは動作しない」状態が発生するが、「開発者の環境では不具合が再現されない」という悪循環が起きる。

対応

上記の問題を解消するために、以下の対応を実施している。

• 開発環境の構築を、自動構築スクリプト（Infrastructure as Code）で配布物として管理する
• 個人の好みは配布物に含めず、独自環境を維持できる状態を提供する
• 最終テスト（end-to-end）は、最終テスト用の別環境を構築する
• 環境の自動構築スクリプトはリポジトリに登録し、複数のコマンドを実行するだけで再現できる

導入効果

その対応で得られた効果は以下である。

• 開発環境の腐敗を防ぐことができた
• 構築を自動化させることで、運用者、利用者の作業負荷を軽減できた
• Docker化を行うことで、Windows上でも開発環境を構築できるようになった

開発でありがちな、インフラ起因による解消しにくい問題を抑止できるだけではなく、運用負荷軽減、利便性の向上も実現している

注目点

本事例で注目するポイントは以下と考えている。

• 開発環境の管理・維持を、自動構築スクリプト（Infrastructure as Code）で実現している
• 個人環境と開発環境を分離し、開発環境は揮発性のDocker、個人環境はサーバで提供し永続性と自由度を確保している
• 開発環境として利用していなかったWindows端末のローカルでの開発環境の構築を実現している

現状までの個人ごとに提供していた開発環境の利便性を極力低下させずに、開発環境の腐敗の防止を実現できている。DockerfileなどでInfrastructure as Codeに親和性の高いDockerを活用することで、画一化された正しい環境の提供も実現している。さらにDockerのポータビリティを活用し、今まで開発環境として利用されていなかったWindows端末上でも開発環境を再現することができ、開発者の利便性と（主にロケーションの）自由度を高めることも実現している。

事例3：『Dockerの事例紹介』（株式会社ワークスアプリケーションズ）

ERPパッケージ製品の「COMPANY」など、多数のパッケージ製品を提供している株式会社ワークスアプリケーションズの遠藤博樹氏の講演資料を引用している。多数のパッケージ製品の保守を、国内外複数の拠点で開発する事例となっている。

導入前の状況

パッケージ製品を多数提供しているが、その製品保守開発を行うために以下のような問題が存在する。

• 多数のパッケージ製品ごとに対応した開発検証環境が必要となる
• 1つのパッケージ製品に対しても新バージョンの開発に加えて、複数の旧バージョンの保守も行わなければならず、そのバージョンごとの開発検証環境が必要となる
• 国内拠点以外にも上海、シンガポールに開発拠点が存在し、同一製品の保守開発を同時に行っており、複数拠点同時開発であっても製品の品質を担保する必要がある
• 同一製品を複数拠点、メンバーで同時に開発を1面の環境で実施していたが、開発中のバグのあるソースがマージされると、開発検証環境全体が停止してしまう問題が発生した
• 開発検証拠点が1面であったため、東京にDBを構築すると、海外拠点からはAP⇔DB間の通信遅延により動作が遅いとのクレームがあった

開発、CI環境をサーバで提供していたが、アプリケーションのバージョンと利用する実行環境の不整合による問題が発生し、CI中にさまざまなエラーが発生することとなった。仮に動作したとしても、その製品のバージョンが想定している実行環境と異なるため、不具合の原因ともなりかねない状態であった。同一製品の検証環境も1面しかなく、開発中のソースにバグが存在すると、その製品全体の開発が停止してしまい、開発遅延のリスクも発生することとなった。

対応

上記の問題を解消するために以下の対応を実施している。

• 各製品の各バージョンに対応した検証環境およびDBをDockerコンテナで構築し、リポジトリに登録することで、必要が生じた際に環境を構築できる状態を実現した
• Docker化によりリソース消費量が軽減され、開発者個人ごとに検証環境を提供できる状態が実現できた
• 検証サーバ、DBも利用者に近いロケーションに自動構築できる状態を実現した

導入効果

講演資料には効果については残念ながら記載されていなかったが、上記の各問題を解消することで以下の効果が発生していると推察できる。

• 各製品の各バージョンの検証環境が統一され、製品の品質を安定させることができる
• 開発検証環境はDockerリポジトリから提供されるため、開発環境維持コストも低減できる
• 開発者個人ごとに開発検証環境が提供され、開発者の自由度と生産性が向上する
• 開発環境をDockerコンテナ化することで、③を実現しても、サーバリソースへの追加コストが抑止できる

注目点

本事例で注目するポイントは以下と考えている。

• 製品やバージョンごとに開発環境をいつでも再現できる状態を実現している
• 個々の開発者に必要となる環境を、必要となるタイミングで提供が行える状態を実現している
• Dockerを利用することで、サーバリソースへの負荷増大を抑止しながら、環境改善が行える

事例2にもあったが、「開発中の開発者の個人環境」と「最終テストの規定された環境」の分離が行え、さらにいつでも正しい環境が再現できる状態は、開発プロジェクトにとっては理想的であり、生産性と品質の向上に寄与しているのは間違いないだろう。

開発環境の事例から見えること

開発環境にDockerを導入するためには、以下が必要だと考えられる。

①開発環境の標準化が行えていること

開発環境で使用するサーバをすべてDockerコンテナ化するためには、再作成が行えることが必須となる。また再作成を容易にするためには、開発環境の標準化を行い、定型化することが必要となる。定型化により、作成・再作成の手順も定型化される。

②開発環境構築の自動化が行えていること

開発環境の標準化、作成・再作成の手順が定型化されるため、開発環境の構築手順をInfrastructure as Codeの技術で実装することが可能となる。インフラ構築がプログラムにより実装されるため、開発環境が高速かつ冪等性（べきとうせい）が保証される状態で構築できる状態が実現される。

③開発者自らインフラ運用を行えるインターフェースを提供していること

開発環境構築の自動化の実現により、通常の環境構築はインフラ運用者の専門知識や作業が不要となる。さらに開発者向けにUIを提供することで、開発者が自ら開発環境を必要な時点で構築し利用することができる状態が実現される。

ただ、各事例から感じられるのは、この状態を実現するためには「アプリケーション開発、インフラ構築、運用のすべてを理解したフルスタックエンジニア」が設計・構築を行うことが必須条件であるということだ。数少ないフルスタックエンジニアを、開発環境改善という投資にアサインできるのかがカギとなるだろう。

本番環境での事例

本番環境でのDocker活用事例は、開発環境の事例に比べると多くないが、先進的な事例が公開されつつある。その中でも将来のDockerの本番環境への利用の参考となりそうな事例を紹介する。

事例１：「Dockerの商用サービスでの利用事例紹介」（株式会社インターネットイニシアティブ）

インターネットプロバイダ、クラウド事業も手掛ける株式会社インターネットイニシアティブの前橋孝広氏の講演資料から引用している。IIJ GIOストレージサービスとHadoop/Hiveを利用したデータアナリシスサービスをDockerで実装した事例となる。

導入の経緯

新規事業としてIIJ GIOストレージサービス上でHadoop/Hiveを利用したデータアナリシスサービスを提供することとなったが、本機能を実装させるために多くのHadoopのData Nodeを起動させる必要が発生する。マルチテナントでサービスを提供するため、Data Node起動に対してオーバーヘッドをより少なくすることが必要となった。そのため、オーバーヘッドが少なく、起動も高速なDockerコンテナを採用することとなった。Dockerの採用は、今後のDocker活用への試金石という意味もある。

本サービスでは利用者はシステムに対してHiveQLでのみアクセスを行え、Dockerコンテナの起動もMapReduceプログラムも動作させることができない仕様となっている。サービスプラットフォームは、利用者からは隠ぺいされている状態となる。そのため、Dockerコンテナに対して、クラウド上の仮想マシンのようなセキュリティを実装する必要は軽減されている。

対応

上記を実現するために以下の対応を実施している。

• 多数のコンテナを管理するツールとしてdoma（Docker manager）を独自開発し、コンテナの自動配置とクラスタリングを実現
• コンテナのCPU、ディスク使用量の制限も独自で実装（memoryの制限はDocker標準で実装されている）
• コンテナへのネットワークもLinux bridgeを利用した独自実装とし、domaから制御を行う
• コンテナ間のネットワーク分離はLinuxのfirewallであるiptablesを利用
• コンテナイメージもCentOS 6をベースに自作し、Dockerfileで必要プロダクトをインストールする
• ログ収集、監視、コンテナのリソース使用状況のモニタリングも独自で実装

足りない部分は全て独自実装するというIIJ社ならではの高い技術レベルの対応となっている。ただ、本サービス開始時点のDockerのバージョンでは実装が不十分な機能も存在したため、やむを得ない点もあったのだろう。最後のまとめ部分で、現状であれば実現できる製品の対応表も記載されている。

導入効果

導入効果については残念ながら記載されていないが、Hadoopのように多くのサービスを並列で稼働させるために、オーバーヘッドが少なく構築も速いDockerを採用していることは、利用者に対して構築待ち時間の削減やコストの低減など多くのメリットを発生させていると考えられる。さらに、マルチテナントのサービスとして事業化を実現していることは大変素晴らしいと言える。

注目点

現時点で注目すべきポイントは、以下と考えている。

• Dockerを、サービス実装のために有効であることを評価して利用している
• Dockerをマルチテナントのサービスとして提供するために必要な要素技術が網羅されている
  →オーケストレーション、クラスタリング、リソース制御、ネットワーク制御、ロギング、監視 etc…
• Dockerを活用できる部分と活用できない部分を明確に分け、機能の不足があれば、独自開発以外にもLinux標準の機能も活用している

ありがちなことだが、手段（この場合はDockerを採用すること）が目的となってしまう案件も見られる。本事例では、サービス上十分なメリットがあることを判断したうえでDockerを採用しているのだと考えられる。

マルチテナントのクラウドサービスであるため、既存のクラウドサービス同様のサービスや制限、セキュリティも実装する必要がある。Docker環境で、それらをどのような実装するのかに非常に参考になる点が多い。特にマルチテナントの悩みどころであるネットワークを、KVMやXenでも利用され実績のあるLinux標準機能であるLinux bridgeとiptablesを利用して実装している。独自開発部分は保守を行うための作業負荷も大きいが、Linux標準の機能を活用するのであれば、そのリスクを軽減することが可能である。

事例2：「Docker を利用した Web アプリケーションのデプロイ」（クックパッド株式会社）

レシピ検索サイトとして有名なcookpadを提供するクックパッド株式会社の開発者ブログから引用している。クックパットの一部で、Dockerがアプリケーションサーバとして利用されていることを紹介する事例となる。

導入の経緯

Dockerのポータビリティを活かして、アプリケーションサーバのデプロイ業務を改善することを目的としているようだ。

対応

上記を実現するために以下の対応を実施している。

• Docker本体および周辺製品の更新が頻繁なため、当初はDocker標準コマンドのみで実装している
• WebアプリケーションおよびWebサーバをデプロイする単位でDockerコンテナ化する
• コンテナ内のアプリケーションへの接続は、上位のnginxで行う
• アプリケーションの更新をコンテナ単位で行い、nginxを変更することで、アプリケーションの切り替えを実施する
• nginxとコンテナおよびコンテナ間の通信は、UNIXドメインソケットまたはDockerのbridge networkingを利用する
• コンテナの自動構築にはCapistranoを利用し、コンテナ側に不要なファイルシステムへのアクセス権限を与えない

導入効果

その対応で得られた効果は以下である。

• コンテナのデプロイおよびアプリケーションの切り替えの自動化を実現できた
• コンテナをどのサーバに配置するかは、運用者が手動で設定している
• コンテナのデプロイ数によるオートスケールはまだ実現できていない

注目点

本事例で注目するポイントは以下と考えている。

• 1つのシステムを複数のコンテナの組み合わせで実装している
• Webアプリケーションをデプロイする単位でDockerコンテナ化している
• 更新した機能（＝コンテナ）をデプロイする場合、更新したコンテナ以外と統合するnginxのみに変更が発生する

Webアプリケーションは、おそらく単体でも動作する状態でコンテナ化されていると考えられる。これはシステムの各機能のカプセル化と考えて良いだろう。各機能単体でテストが行え、テスト済みのコンテナを変更することなく本番環境にデプロイすることができる。これにより、本番リリース時に構築作業の不備などによって発生する障害を大きく削減することができる。

この１つのシステムを機能ごとに分割し、コンテナでカプセル化してデプロイの管理を行う仕組みは、今後のDockerの本番活用の基本パターンになると考えている。

事例3：「Docker at Shopify: How we built containers that power over 100,000 online shops」

次は海外の大規模導入事例となる。SaaS型のeコマースサイトサービスを提供するカナダShopify Inc.の技術ブログから引用している。10万件を超えるテナントが利用するコマースサイトを、Docker環境で運用している事例となっている。このブログは連載記事となっており、前回記事（Building an Internal Cloud with Docker and CoreOS）も公開されているので、こちらも合わせて読まれることをお勧めする。

導入の経緯

Shopify Inc.は非常に多数の利用者を抱えており、利用者に快適なサービスを提供するためにDockerを利用することで、以下を実現している。

• サービスの起動を高速で行える。サービス開始までの待ち時間が少なく利用者の作業を妨げない
• リソース使用量が少なく、高密度でハードウェアの利用が可能で利用コストの削減につながる。
• 各インスタンスが必ず同一の状態で起動する一貫性が担保される
• 高負荷時は、コンテナ数を増やすことで処理能力を向上させることができる

対応

• コンテナ内部から不要な機能を排除し、よりシンプルなコンテナとした
• コンテナの構築をすべてDockerfileで行えるように実装した
• アプリケーションに対して、Dockerコンテナで動作させることを前提とするContainerizingを施した
• アプリケーションを1つのコンテナで完結するように実装した
• 効率を高めるため、統計情報やログ情報はアプリケーション側から直接送信するようにした
• Dockerのコンテナとinitプロセスを分離するため、PID=3のppidshimプロセスから生成されるようにした
• コンテナで利用するホスト名でワークロードを管理できるように、命名則を設けた
• Dockerレジストリを複数構成し、nginx proxyで負荷分散とキャッシュをすることで、大量のコンテナのデプロイ要求に対応した

導入効果

上記に対応により導入の経緯となった目的はほぼ実現できていると考えらえる。現在は20万件を超えるテナントの運用を実現している

注目点

本事例で注目するポイントは以下と考えている。

• Docker上で稼働させることを前提に、アプリケーションを開発している
• Dockerで稼働させるために、安定度と効率を最優先にしている
• 不要なサービスやアクセス権をコンテナに付与しないことで、コンテナを密閉している
• Dockerの実行環境をベースOSから分離させるセキュリティ対策を行っている

サービスが定型化されているため、コンテナ内のプロダクトを最低限にするとともに、アプリケーション側でも作りこみの対応を行っている。それによりシステムの安定化とリソース利用の効率化を実現している。

Docker自体はサービスとして起動するため、Dockerサーバプロセス経由であれば、OSの管理者と同じ特権で処理が行え、重大なセキュリティホールとなりうる。そのためコンテナに不要なサービスやアクセス権を付与しないことで、コンテナを密閉し、よりセキュリティの強化を実現している。

ブログ内ではオートスケールを実現しているような記述はみられるのだが、どのように実装しているのかは残念なが見つけることができなかった。

本番環境の事例から考えるDocker環境

あくまで私見ではあるが、前述の事例を基に、本番環境でDockerを活用するイメージを筆者なりに考えてみた。

本番環境に実現すべき機能

Dockerを本番環境で利用するためには、以下が必要であると考えている。

①Docker前提でのアプリケーション開発

Dockerで動作させることを前提とするためには、以下の実現が必要となる。

1. 完結した1つの機能を１つのコンテナに集約する
2. メンテナンス時は、コンテナの入れ替えで更新を行えるようにする
3. 多数のコンテナを集約し、１つのシステムして稼働させる管理機能を実装する

複数のコンテナを組み合わせて、大きなシステムを実現する場合、セッション情報や処理ステータスやデータなどコンテナ間で共有される情報も多い。分離された実行環境であるコンテナを組み合わせて、１つのシステムとして運用するのであれば、アプリケーションレベルからDockerに対応して開発することが必須となる。

②クラスタリング・オートスケールの実現

Dockerコンテナの最大のメリットは、軽量であるコンテナの作成・削除が容易である点である。そのメリットを最大限に活用するためには、「コンテナを必要な時に必要なだけ稼働させる」ことが必要となる。これが実現されると、クラスタリングもオートスケールも非常にシンプルに「コンテナを必要な時に必要なだけ稼働させる」形で実装される。コンテナはシステム状況に応じて自由に生成・削除をされるため、以下の機能の実装が必須となる。

1. コンテナの増減にシームレスに対応できるロードバランサ機能
2. 再生成されたコンテナで処理を継続できるクラスタリング機能
3. 消失が許されないセッション情報やデータのコンテナ外の保持とコンテナ間で継承する機能

これらの機能を実現するためには、コンテナの外部で以下の機能を実装する必要がある。

1. ユーザのセッション情報や処理中の一時データを保持する機能
2. リクエストごとに処理を実行するコンテナを実行する機能
3. 処理が中断された場合は、再実する機能
4. 固定データや永続化するデータを保存、管理する機能

上記の4.は、既存のデータベースやファイルサーバなどで実現できるが、1.～3.を実現するためにはDocker環境に特化したロードバランサ製品が必要となると考えられる。

③マルチテナントでのセキュリティの担保

本番環境ではマルチテナントで利用することが前提となるため、以下の対策が必須となる。

1. 各テナントが接続できるネットワークは必ず分離して、他のテナントにアクセスできないこと
2. 利用者による悪意の攻撃（高負荷はセキュリティホールへの攻撃）を遮断できること
3. 各テナントが利用できるリソース（CPU・メモリ・ディスクI/O・ネットワークI/O）が確保されていること

Docker標準の機能では上記への対応は実装されつつあるが、現状では物理サーバや、仮想サーバのOSレベルの分離ほど完全ではない。もし、現状のDockerを利用してマルチテナントでのセキュリティを担保するのであれば、物理サーバや仮想サーバで実現する形を取らざるを得ないだろう。

オンライン処理の実現イメージ

上記を実現したオンライン処理の構成のイメージは以下となる。

1. アプリケーションを1つの機能単位でコンテナ化し、コンテナの入れ替えでメンテナンスを行う
2. 処理リクエストの負荷に応じて、必要な台数のコンテナを起動させる
3. コンテナの入れ替えや台数の増減は、上位のWebサーバやロードバランサで制御する
4. コンテンツの内容もコンテナの入れ替えに動的に対応できるようにする

上記が実現できれば、複数のコンテンツやサービスを1つの画面上で自由にカスタマイズして利用できる状態が実現できるのではないかと考えている。Yahoo Japanがエンドユーザー向けに提供しているのMy Yahooのように、ポータルサイトの各コンテンツがコンテナで実装されている形がイメージに近いかもしれない。

バッチ処理の実現イメージ

バッチ処理に適用するには、このようなパターンも考えられる。現状、OSや使用する言語ごとに分離しているサーバを、Dockerを利用して統合するのは、既存の技術で問題なく実現できるだろう。

Dockerの最大のメリットであるポータビリティを活かし、バッチ処理のオートスケールに活用する形が有効である。オートスケールにより並行稼働を行う場合、以下の配慮が必要となるだろう。

• 各コンテナへの処理の分散と処理順序の制御
• 異常発生時に再実行の制御

最後に

冒頭にも記載したとおり、Docker社も上記の実現は必要と認識しており、Docker本体のみならず周辺の運用管理ツールなども機能強化が行われている。Docker社以外のベンダーも続々と製品のバージョンアップを行っており、「クラスタリング・オートスケールの実現」と「マルチテナントでのセキュリティの担保」は、既存の技術の応用に近い部分が多いためか、すでに実現されつつある。

ただ残念なことに「Docker前提でのアプリケーション開発」については、現状との乖離が大きいためか、なかなか進展が見られていないように感じられる。実現のためには、アプリケーションやプラットフォームを含めた新たなフレームワーク製品の開発も必須となるだろう。

DockerはDevOps実現のカギとなるプラットフォームであり、開発者、インフラ運用者で協力し合い、安全で効率のよいサービスプラットフォームを提供することが今後の課題となる。この課題を乗り越えるには、個人や一企業の力ではなく、組織や企業や業界の壁を越えてDockerのより良い使い方を考えていくコミュニティ活動をもっと活発にしていく必要があるのかもしれない。つたない内容ではあるが、本記事がその検討の一助にでもなれば幸いである。

最後に、本記事の執筆にあたり、非常に有用な事例を公開いただいた各社様に心から感謝の気持ちと御礼を申し上げたい。