Dockerの商用サービスでの利用事例紹介

(1)

1

maebashi@iij.ad.jp

Dockerの商用サービスでの利用事例紹介

(2)

本日の話

前置き

サービス概要

Dockerを商用サービスの基盤に使うに

あたって

実装方法多数のコンテナの管理

コンテナのリソース制限

コンテナ間のネットワーク

その他

(3)

(4)

(5)

IIJ GIO ストレージ& 

アナリシスサービス

+

REST API(AWS S3互換)を持つ

クラウドストレージサービス

Hadoop/Hiveを用いた

データ解析機能(オプション)

(6)

サービス全体図

storage

API

ストレージ

ノード

analysis

API

ユーザー

data

query

IIJ GIO ストレージ&アナリシスサービス

計算

ノード

container

data

(7)

計算ノード

•  Hadoop + Hiveを使用

•  マルチテナント

(8)

計算ノード(図)

analysis

API

query

Hive

NN

RM

DN

NM

metastore

task

storage

API

DN

NM

task

ユーザ毎に用意

NN: Name Node

RM: Resouce Manager

DN: Data Node

NM: Node Manager

ノード

(9)

計算ノード部分要件

•  ユーザ毎に実行環境が隔離されてい

ること

•  公平なリソースの共有

•  ノードはユーザにより増減可能なこ

と

(10)

サービス検討時の候補

•  Hypervisor型仮想マシンによる隔離

– 隔離という面では一番確実

– 起動が遅い、オーバーヘッドがある

•  コンテナによる隔離

•  アプリケーションレベルでの隔離

– Hiveだけ(UDF禁止)等、やれることを限

定すれば可能

(11)

•  コンテナ上で動くアプリケーション

の実行環境を構築・管理

•  オープンソース

•  コンテナとは?

– 複数のLinux標準機能の組み合わせで実

現する隔離環境

•  Namespaces, Cgroups, Capabilities など

(12)

仮想マシン vs コンテナ

Server

Host OS

Hypervisor

Guest OS

Bins/Libs

App A

Guest OS

Bins/Libs

App B

Server

Host OS

Docker Engine

Bins/Libs

App A

Bins/Libs

App B

Hypervisor型仮想マシン

Dockerコンテナ

ゲスト毎に任意のOS使用可

高い隔離性

オーバヘッドが少ない

起動が速い

こちらを採用

Dockerコンテナは、隔

離された単なるプロセス

(13)

実際の本サービスの制限

•  現時点では、ユーザが任意のDocker

イメージを動かすことは出来ない

– 任意のMapReduceプログラムを動かす

こともできない

– 使えるのはHiveQLのみ

•  Dockerの利用は将来への布石

(14)

Dockerを商用サービスの基盤に

(15)

•  単体のホスト上での開発・ビルド・

テスト環境

•  環境のパッケージングと配布

(16)

Dockerの課題

•  複数ホスト上の多数のコンテナの管

理(オーケストレーション)

•  複数ホストをまたいだネットワーク

•  コンテナのログの管理

•  コンテナの監視、モニタリング

(17)

(18)

オーケストレーション

Docker

Container

空き

Docker

Container

Docker

Container

コンテナ

オーケストレーション

ツール

実行したいコンテナ群

(19)

•  例

– Docker Swarm

– Kubernetes

– Apache Mesos

– Fleet

– Nomad

– ...

(20)

doma(docker manager)とは?

•  独自開発

•  多数のDockerコンテナを管理する

– 複数ホストをリソースプールとする

– analysis APIからの要求によりプールか

ら必要数のコンテナを自動確保し起動

(21)

doma 構成図

Docker daemon

Container

slave

構成情報DB

(MySQL MHA)

master

request / response

Docker

Remote API

master

API

docker

ホスト群

使用可能ホスト

リソース空き情報

IPアドレス空き情報

etc

LB(nginx)

HTTP

slave

API

HTTP

over

Unix domain

socket

analysis

API

query

(22)

master

•  多数のコンテナをクラスタ単位で管

理

– クラスタ＝コンテナの集合

•  クラスタ操作

– 予約、アップデート、起動、停止、再

起動、解放(削除)

(23)

クラスタ

•  互いに通信できるコンテナの集合

– 1つのクラスタは1つのユーザに属する

– 別のクラスタとは通信できない

Docker

Container

空き

Docker

Container

Docker

Container

ホスト

クラスタ1

クラスタ2

クラスタ3

(24)

masterが管理するもの

•  ホスト

– dockerが動く物理ホスト

– CPU、メモリ割当て状況

•  IPアドレス

– コンテナは1個ずつ(プライベート)IPア

ドレスを持つ

(25)

コンテナの種類

•  グレード

– 性能を決める(CPUコア数、メモリ量)

•  タイプ

– dockerイメージ名に対応

– アプリケーション毎に複数用意されて

いる

(26)

slave

•  Docker daemonのwrapper

– masterからは、ほぼDocker daemonに

見える

– いくつかAPIを拡張

•  Goで記述

Docker daemon

slave

Docker

Remote API

HTTP

over

Unix domain

socket

master

slave

API

(27)

Docker Remote API

•  HTTP、REST、JSONベース

•  dockerコマンドはすべてこのAPIを経

由している

Host

Docker daemon

docker pull

docker run

docker ...

container

Docker client

HTTP over

Unix domain socket

または

TCP

Docker

(28)

slave追加機能

•  コンテナ起動関連

– サイズ制限されたディスク領域提供

– ネットワーク設定

– iptablesチェイン設定

•  コンテナのメトリクス取得

•  コンテナ内にファイルを送り込む

•  コンテナ非同期削除

(29)

(30)

リソース制限概略

•  主にcgroupを使う

•  CPU

– cpuset

•  メモリ

– memory

•  ディスク使用量

– cgroupではできない

(31)

CPU制限

•  (Docker Remote API経由で)cgroupの

cpuset.cpusを使う

– コンテナのプロセスが実行されるCPU

コアの番号を指定

– 例: "CpusetCpus":"0-2,7"

•  各コンテナおよびシステムプロセス

それぞれが使うCPUコアを分離

(32)

ディスク使用量制限

•  特定サイズのloopbackデバイス用

ファイルを作って、それをmount

– あらかじめmkfs済sparseイメージ入り

tarファイルを用意

– コンテナ起動時にそれを展開して

mount(0.1∼0.2秒くらい)

– コンテナ解放時はファイルを1個削除す

るだけ

(33)

(34)

通常のDockerのネットワーク

IPマスカレード

仮想ネットワーク

インターフェース

(veth)

container

network

namespace

コンテナA

コンテナB

host

network

namespace

ホスト

仮想ブリッジ

docker0

NIC

eth0

vethA

eth0

vethB

(35)

通常のDockerのネットワーク

ホストをまたいだコンテナ間通信は困難

(ポートが固定されていればEXPOSEでできるが

Hadoopと相性が悪い)

IPマスカレード

コンテナA

コンテナB

ホスト1

docker0

NIC

eth0

vethA

eth0

vethB

IPマスカレード

コンテナC

コンテナD

ホスト2

docker0

NIC

eth0

vethA

eth0

vethB

(36)

解決策

•  例

– pipework

– weave

– flannel

– libnetwork overlay driver

– ...

•  または独自に頑張る

(37)

本サービスのネットワーク

•  dockerのネットワーク設定は使用せ

ず

– ("NetworkDisabled": true)

•  代わりにslaveがコンテナ起動時に

ネットワーク設定をする

(38)

本サービスのネットワーク

IPマスカレード

通常のdockerの

ネットワーク

container

network

namespace

本サービスの

ネットワーク

host

network

namespace

ホスト

IPマスカレード

コンテナA

コンテナB

ホスト

docker0

NIC

eth0

vethA

eth0

vethB

IPマスカレード

ホスト

コンテナA

コンテナB

NIC

eth0

vethA

eth0

vethB

host-veth

ホスト

host-geth

bridge0

(39)

論理的にはこんな感じ

eth0

コンテナA

eth0

コンテナB

host-geth

ホスト1

eth0

コンテナC

eth0

コンテナD

host-geth

ホスト2

•  コンテナはホストと同じネットワークに直接つながる

•  コンテナのIPアドレスはmasterが決定しslaveが設定する

(40)

ネットワークの隔離

•  クラスタ間はiptablesで隔離

(41)

(42)

Dockerイメージ

•  Docker HUBのイメージは使用せず

– 同じrepository名:tag名でも内容が変

わっていることがある

–  (docker 1.6〜はContent Addressable Image Identifiersにより一意に指定可)

•  独自にOSイメージ作成

– febootstrap で CentOS 6ベースで作成

•  そのOSイメージからJDK, Hive,

(43)

ログの管理

•  コンテナ内の各種ログは、コンテナ

内の特定ディレクトリに一時保存

•  ホスト上(コンテナ外)のfluentdで外に

飛ばす

•  本サービスのストレージ部分(管理用)

に保存

(今ならDockerのlog driverを使えば良いと思う)

(44)

監視

•  ホストが障害を起こしたらdomaはコ

ンテナ割り当て対象から除外

– 障害コンテナを別ホストに自動移動し

たり再起動はしない

•  コンテナのアプリケーションレイヤ

の監視はanalysis APIが行っている

(45)

コンテナのモニタリング

•  slaveに、コンテナ単位のメトリクス

を返す機能追加

•  cgroupの統計情報と、コンテナ内の 

/proc/net/dev 等からメトリクスを得

る

(今なら cAdvisor を使えば良いと思う)

(46)

46 ↓CPU Accounting

Memory→

↓Network traffic

(47)

•  CentOS 6を使用中

– だがDocker 1.8以降、CentOS 6は対象

外

– Red Hat は、DockerをRHEL 6で動かす

ことを推奨していない

•  コンテナ用OS

– CoreOS, Project Atomic, Snappy,

RancherOS

(48)

まとめ

•  Hadoop/Hiveをマルチテナントで動か

すためにDockerを採用

•  Dockerは多数のコンテナを扱うには

課題がある

– 解決のためいくつかのツール類を開発

– 今ならもっと楽な別のやり方があるは

ず

(49)

別のやり方

項目

本サービス

別のやり方(例)

コンテナオーケ

ストレーション

独自 doma(docker

manager)

Kubernetes,

Swarm, Mesosな

ど

ネットワーク

独自

_{libnetwork, flannel,}

weave など

ロギング

_{外付けfluentd}

_{docker log driver}

モニタリング

独自

_cAdvisor

OS

_{CentOS 6}

_{CoreOS, Atomic}

Hostなど

Dockerの商用サービスでの利用事例紹介

maebashi@iij.ad.jp

Dockerの商用サービスでの利用事例紹介

本日の話

前置き

サービス概要

Dockerを商用サービスの基盤に使うに

あたって

実装方法 多数のコンテナの管理

コンテナのリソース制限

コンテナ間のネットワーク

その他

IIJ GIO ストレージ&

アナリシスサービス

+

REST API(AWS S3互換)を持つ

クラウドストレージサービス

Hadoop/Hiveを用いた

データ解析機能(オプション)

サービス全体図

storage

API

ストレージ

ノード

analysis

API

ユーザー

data

query

IIJ GIO ストレージ&アナリシスサービス

計算

ノード

container

data

data

data

計算ノード

• Hadoop + Hiveを使用

• マルチテナント

計算ノード(図)

analysis

API

query

Hive

NN

RM

DN

NM

metastore

task

storage

API

DN

NM

task

ユーザ毎に用意

NN: Name Node

RM: Resouce Manager

DN: Data Node

NM: Node Manager

ノード

ノード

ノード

計算ノード部分 要件

• ユーザ毎に実行環境が隔離されてい

ること

• 公平なリソースの共有

• ノードはユーザにより増減可能なこ

と

サービス検討時の候補

• Hypervisor型仮想マシンによる隔離

– 隔離という面では一番確実

– 起動が遅い、オーバーヘッドがある

• コンテナによる隔離

• アプリケーションレベルでの隔離

– Hiveだけ(UDF禁止)等、やれることを限

定すれば可能

• コンテナ上で動くアプリケーション

の実行環境を構築・管理

• オープンソース

実装方法多数のコンテナの管理

IIJ GIO ストレージ& 

•  Hadoop + Hiveを使用

•  マルチテナント

計算ノード部分要件

•  ユーザ毎に実行環境が隔離されてい

•  公平なリソースの共有

•  ノードはユーザにより増減可能なこ

•  Hypervisor型仮想マシンによる隔離

– 隔離という面では一番確実

– 起動が遅い、オーバーヘッドがある

•  コンテナによる隔離

•  アプリケーションレベルでの隔離

– Hiveだけ(UDF禁止)等、やれることを限

•  コンテナ上で動くアプリケーション

•  オープンソース

•  コンテナとは?

– 複数のLinux標準機能の組み合わせで実

•  Namespaces, Cgroups, Capabilities など

•  現時点では、ユーザが任意のDocker

– 任意のMapReduceプログラムを動かす

– 使えるのはHiveQLのみ

•  Dockerの利用は将来への布石

•  単体のホスト上での開発・ビルド・

•  環境のパッケージングと配布

•  複数ホスト上の多数のコンテナの管

•  複数ホストをまたいだネットワーク

•  コンテナのログの管理

•  コンテナの監視、モニタリング