Dockerの商用サービスでの利用事例紹介 [email protected] 株式会社インターネットイニシアティブ 1 本日の話 前置き サービス概要 Dockerを商用サービスの基盤に使うに あたって 実装方法 多数のコンテナの管理 コンテナのリソース制限 コンテナ間のネットワーク その他 © 2015 Internet Initiative Japan Inc. 2 サービス概要 http://www.iij.ad.jp/biz/storage/ © 2015 Internet Initiative Japan Inc. 4 IIJ GIO ストレージ& アナリシスサービス REST API(AWS S3互換)を持つ クラウドストレージサービス + Hadoop/Hiveを用いた データ解析機能(オプション) © 2015 Internet Initiative Japan Inc. 5 サービス全体図 ユーザー data query IIJ GIO ストレージ&アナリシスサービス storage API analysis API data data data container © 2015 Internet Initiative Japan Inc. ストレージ ノード 計算 ノード 6 計算ノード • Hadoop + Hiveを使用 • マルチテナント © 2015 Internet Initiative Japan Inc. 7 計算ノード(図) ユーザ毎に用意 ノード DN query analysis API ノード NM NN task storage API RM Hive DN NM task metastore ノード © 2015 Internet Initiative Japan Inc. NN: Name Node RM: Resouce Manager DN: Data Node NM: Node Manager 8 計算ノード部分 要件 • ユーザ毎に実行環境が隔離されてい ること • 公平なリソースの共有 • ノードはユーザにより増減可能なこ と © 2015 Internet Initiative Japan Inc. 9 サービス検討時の候補 • Hypervisor型仮想マシンによる隔離 – 隔離という面では一番確実 – 起動が遅い、オーバーヘッドがある • コンテナによる隔離 • アプリケーションレベルでの隔離 – Hiveだけ(UDF禁止)等、やれることを限 定すれば可能 © 2015 Internet Initiative Japan Inc. 10 Dockerとは? • コンテナ上で動くアプリケーション の実行環境を構築・管理 • オープンソース • コンテナとは? – 複数のLinux標準機能の組み合わせで実 現する隔離環境 • Namespaces, Cgroups, Capabilities など © 2015 Internet Initiative Japan Inc. 11 仮想マシン vs コンテナ Dockerコンテナは、隔 離された単なるプロセス App A App B Bins/Libs Bins/Libs Guest OS Guest OS App A App B Bins/Libs Bins/Libs Hypervisor Docker Engine Host OS Host OS Server Server Hypervisor型仮想マシン Dockerコンテナ ゲスト毎に任意のOS使用可 高い隔離性 オーバヘッドが少ない 起動が速い こちらを採用 © 2015 Internet Initiative Japan Inc. 12 実際の本サービスの制限 • 現時点では、ユーザが任意のDocker イメージを動かすことは出来ない – 任意のMapReduceプログラムを動かす こともできない – 使えるのはHiveQLのみ • Dockerの利用は将来への布石 © 2015 Internet Initiative Japan Inc. 13 Dockerを商用サービスの基盤に 使うにあたって Dockerが向いていること • 単体のホスト上での開発・ビルド・ テスト環境 • 環境のパッケージングと配布 © 2015 Internet Initiative Japan Inc. 15 Dockerの課題 • 複数ホスト上の多数のコンテナの管 理(オーケストレーション) • 複数ホストをまたいだネットワーク • コンテナのログの管理 • コンテナの監視、モニタリング © 2015 Internet Initiative Japan Inc. 16 多数のコンテナの管理 オーケストレーション Container Container Container 実行したいコンテナ群 コンテナ オーケストレーション ツール ホスト Docker Docker Docker Container Container Container Container Container Container 空き Container Container © 2015 Internet Initiative Japan Inc. 18 オーケストレーションツール • 例 – Docker Swarm – Kubernetes – Apache Mesos – Fleet – Nomad – ... © 2015 Internet Initiative Japan Inc. 19 doma(docker manager)とは? • 独自開発 • 多数のDockerコンテナを管理する – 複数ホストをリソースプールとする – analysis APIからの要求によりプールか ら必要数のコンテナを自動確保し起動 © 2015 Internet Initiative Japan Inc. 20 doma 構成図 request / response analysis API HTTP master API LB(nginx) master HTTP 使用可能ホスト リソース空き情報 構成情報DB IPアドレス空き情報 (MySQL MHA) etc slave API slave HTTP over Unix domain socket Docker Remote API Docker daemon Container query docker ホスト群 © 2015 Internet Initiative Japan Inc. 21 master • 多数のコンテナをクラスタ単位で管 理 – クラスタ ＝ コンテナの集合 • クラスタ操作 – 予約、アップデート、起動、停止、再 起動、解放(削除) • Ruby + Rack + EventMachine © 2015 Internet Initiative Japan Inc. 22 クラスタ • 互いに通信できるコンテナの集合 – 1つのクラスタは1つのユーザに属する – 別のクラスタとは通信できない クラスタ1 クラスタ2 クラスタ3 ホスト Docker Docker Docker Container Container Container Container Container Container 空き Container Container © 2015 Internet Initiative Japan Inc. 23 masterが管理するもの • ホスト – dockerが動く物理ホスト – CPU、メモリ割当て状況 • IPアドレス – コンテナは1個ずつ(プライベート)IPア ドレスを持つ © 2015 Internet Initiative Japan Inc. 24 コンテナの種類 • グレード – 性能を決める(CPUコア数、メモリ量) • タイプ – dockerイメージ名に対応 – アプリケーション毎に複数用意されて いる © 2015 Internet Initiative Japan Inc. 25 slave • Docker daemonのwrapper – masterからは、ほぼDocker daemonに 見える – いくつかAPIを拡張 slave API • Goで記述 master slave HTTP over Unix domain socket Docker Remote API Docker daemon © 2015 Internet Initiative Japan Inc. 26 Docker Remote API • HTTP、REST、JSONベース • dockerコマンドはすべてこのAPIを経 由している Docker Remote API Docker client docker pull docker run docker ... Host Docker daemon HTTP over Unix domain socket または TCP © 2015 Internet Initiative Japan Inc. container container container 27 slave追加機能 • コンテナ起動関連 – サイズ制限されたディスク領域提供 – ネットワーク設定 – iptablesチェイン設定 • コンテナのメトリクス取得 • コンテナ内にファイルを送り込む • コンテナ非同期削除 © 2015 Internet Initiative Japan Inc. 28 コンテナのリソース制限 リソース制限概略 • 主にcgroupを使う • CPU – cpuset • メモリ – memory • ディスク使用量 – cgroupではできない © 2015 Internet Initiative Japan Inc. 30 CPU制限 • (Docker Remote API経由で)cgroupの cpuset.cpusを使う – コンテナのプロセスが実行されるCPU コアの番号を指定 – 例: "CpusetCpus":"0-2,7" • 各コンテナおよびシステムプロセス それぞれが使うCPUコアを分離 © 2015 Internet Initiative Japan Inc. 31 ディスク使用量制限 • 特定サイズのloopbackデバイス用 ファイルを作って、それをmount – あらかじめmkfs済sparseイメージ入り tarファイルを用意 – コンテナ起動時にそれを展開して mount(0.1∼0.2秒くらい) – コンテナ解放時はファイルを1個削除す るだけ © 2015 Internet Initiative Japan Inc. 32 コンテナ間のネットワーク 通常のDockerのネットワーク container network namespace host network namespace コンテナA コンテナB eth0 eth0 vethA vethB 仮想ネットワーク インターフェース (veth) 仮想ブリッジ docker0 IPマスカレード NIC ホスト © 2015 Internet Initiative Japan Inc. 34 通常のDockerのネットワーク コンテナA コンテナB コンテナC コンテナD eth0 eth0 eth0 eth0 vethA vethB vethA vethB docker0 docker0 IPマスカレード NIC ホスト1 IPマスカレード NIC ホスト2 ホストをまたいだコンテナ間通信は困難 (ポートが固定されていればEXPOSEでできるが Hadoopと相性が悪い) © 2015 Internet Initiative Japan Inc. 35 解決策 • 例 – pipework – weave – flannel – libnetwork overlay driver – ... こちらを採用 • または独自に頑張る © 2015 Internet Initiative Japan Inc. 36 本サービスのネットワーク • dockerのネットワーク設定は使用せ ず – ("NetworkDisabled": true) • 代わりにslaveがコンテナ起動時に ネットワーク設定をする © 2015 Internet Initiative Japan Inc. 37 本サービスのネットワーク 本サービスの ネットワーク 通常のdockerの ネットワーク コンテナA コンテナB eth0 eth0 vethA vethB container network namespace コンテナA コンテナB eth0 eth0 vethA vethB docker0 host network IPマスカレード IPマスカレード namespace NIC ホスト bridge0 host-veth IPマスカレード NIC © 2015 Internet Initiative Japan Inc. ホスト ホスト host-geth 38 論理的にはこんな感じ コンテナA コンテナB eth0 eth0 ホスト1 host-geth コンテナC コンテナD eth0 eth0 ホスト2 host-geth • コンテナはホストと同じネットワークに直接つながる • コンテナのIPアドレスはmasterが決定しslaveが設定する © 2015 Internet Initiative Japan Inc. 39 ネットワークの隔離 • クラスタ間はiptablesで隔離 – コンテナはCAP_NET_RAWを禁止 © 2015 Internet Initiative Japan Inc. 40 その他 Dockerイメージ • Docker HUBのイメージは使用せず – 同じrepository名:tag名でも内容が変 わっていることがある – (docker 1.6〜はContent Addressable Image Identifiersにより一意に指定可) • 独自にOSイメージ作成 – febootstrap で CentOS 6ベースで作成 • そのOSイメージからJDK, Hive, Hadoop入りなどをDockerfileで生成 © 2015 Internet Initiative Japan Inc. 42 ログの管理 • コンテナ内の各種ログは、コンテナ 内の特定ディレクトリに一時保存 • ホスト上(コンテナ外)のfluentdで外に 飛ばす • 本サービスのストレージ部分(管理用) に保存 (今ならDockerのlog driverを使えば良いと思う) © 2015 Internet Initiative Japan Inc. 43 監視 • ホストが障害を起こしたらdomaはコ ンテナ割り当て対象から除外 – 障害コンテナを別ホストに自動移動し たり再起動はしない • コンテナのアプリケーションレイヤ の監視はanalysis APIが行っている © 2015 Internet Initiative Japan Inc. 44 コンテナのモニタリング • slaveに、コンテナ単位のメトリクス を返す機能追加 • cgroupの統計情報と、コンテナ内の /proc/net/dev 等からメトリクスを得 る (今なら cAdvisor を使えば良いと思う) © 2015 Internet Initiative Japan Inc. 45 コンテナのモニタリング ↓CPU Accounting ↓Network traffic Memory→ 46 ホストOSについて • CentOS 6を使用中 – だがDocker 1.8以降、CentOS 6は対象 外 – Red Hat は、DockerをRHEL 6で動かす ことを推奨していない • コンテナ用OS – CoreOS, Project Atomic, Snappy, RancherOS © 2015 Internet Initiative Japan Inc. 47 まとめ • Hadoop/Hiveをマルチテナントで動か すためにDockerを採用 • Dockerは多数のコンテナを扱うには 課題がある – 解決のためいくつかのツール類を開発 – 今ならもっと楽な別のやり方があるは ず © 2015 Internet Initiative Japan Inc. 48 別のやり方 項目 本サービス 別のやり方(例) コンテナオーケ ストレーション 独自 doma(docker manager) Kubernetes, Swarm, Mesosな ど ネットワーク 独自 libnetwork, flannel, weave など ロギング 外付けfluentd docker log driver モニタリング 独自 cAdvisor OS CentOS 6 CoreOS, Atomic Hostなど © 2015 Internet Initiative Japan Inc. 49
© Copyright 2024 ExpyDoc
