さくらのdockerコンテナホスティング-arukasの解説とインフラを支える技術（july...

さくらのDockerホスティング Arukasの解説とインフラを支える技術

ShujiYamada(山田修司)@uzyexeJul24,2016

この時間で学習できること

1. Arukasのインフラについて

2. Dockerコンテナの基盤運用について

3. 運用に伴う痛みについて

Server Server Server Server

Computing Resource Pool

Container Container Container Container

Service Discover

Service Scheduling

Service Registration Health Check

API Job Scheduler

Inter-Connectivity

Authorization

Customer Service

Service

Physical

Abstract

Process

Orchestration

Auth

Support

Service

Server Server Server Server

Computing Resource Pool

Container Container Container Container

Service Discover

Service Scheduring

Service Registration Health Check

API Job Scheduler

Inter-Connectivity

Authorization

Customer Service

Service

本日はこのレイヤのお話

Physical

Abstract

Process

Orchestration

Auth

Support

Service

アジェンダ• 自己紹介 • Arukas の紹介 (5分) • Arukas のインフラについて (15分) • Docker コンテナ基盤の運用について (15分) • まとめ (5分)

SHUJI YAMADA• さくらインターネット９年目• エンジニア• データセンター運用スタッフ• バックボーンネットワーク運用• さくらのクラウド運用• Docker ホスティング Arukas 担当 <- 今ココ

（山田 修司）

@uzyexe

What’s

Arukas?

Run Dockerized Applications

450,000+ Dockerized Applications

1500 Users

1700 Users

1850+ Users

900 Users

2016/04 2015/05 2016/06 Today

Users

Growth

1850+ Users

4000 Apps

6000 Containers

Dockerコンテナを直感的に操作できるWEBコントロールパネルを使って、複数台のコンテナでも簡単に管理するこ

とができます。

標準提供されているAPIを利用することで、それぞれのオペレーションに応じたプログラマブルな制御を実現する

ことができます。

コンテナ用に独自設計されたインフラと、高品質なさくらインターネットのインフラを利用して、Dockerコンテナ

をすぐに利用開始できます。

Docker準拠

API対応

高品質な国産サービス

外部サービス連携（開発中）

LATEST RELEASES最新リリース

internationalization (i18n)Arukasのコントロールパネルが国際化に対応しました。

Webブラウザの言語設定が英語の場合、説明や項目などが英語表示されます。

API対応パブリックAPIを公開しました。ユーザーは、それぞれのオペレーションに応じたプ

ログラマブルなAPI制御を実現することができるようになりました。

CLI対応コマンドライン操作に対応するGolang製バイナリをリリースしました。コマンドラインからの迅速な操作や、Golangモジュールとしての再利用が可能になりました。

Terraform for Arukas

i18n

API Support

CLI Support

システム構成管理ツールTerraformに対応するArukasのサードパーティプラグインが有志によってリリースされました。Infrastructre as Codeが実現できます。

その他

VISIONビジョン

インフラサービスの抽象化開発者が自分自身で自由にサービス提供環境を構築できる

アプリケーション開発に専念できるサービスをユーザーに提供する。

Arukas セントリックArukasを基盤としてPaas/SaaS/BaaSなどの高レベルなサービスを実現できる環境

を提供する。

インテグレーション機能の提供サードパーティ製の外部クラウドサービスを、

Arukas上からプラグインモジュールのように簡単に連携利用できるようにする。

Abstraction

Arukas Centric

Pluggable

ポータビリティの実現世界標準的なDockerコンテナに対応し、データを永続的には保持しないことで、

Arukasにロックインされない自由度の高い環境をユーザーに提供する。Portability

Arukasのインフラを支える技術

IaaS

InfrastructureKey Trend

lightweight PaaS (CaaS)

Baremetal

PaaS？

～2025

～2020

～2010

teal?

• Infrastructure as Code • Continuous Integration (CI/CD) • Secure Signing/Trust • +++

• Trusted Registries • Access Control • Policies • +++

• Container Management • Deploy and Scaling • Metrics/Monitoring/Logging • +++

Ship RunBuild

What’sContainer as a Service

Development Test Production

Version Control CI/CD Deploy

DockerfileDocker Image CloudOn-Premise

Registry

Development Test Production

Version Control CI/CD Deploy

DockerfileDocker Image

Registry

User Control Panel

Client

Compose

Container Hosting

Onpremises

Infrastructure

Orchestrator

or

or Volume

Netwroking

Logging

Monitoring

Integrations

Registry

Cloud

API

Container

Bins/Libs

App-3

Container

Operating System

Orchestrator/Container Scheduler

Infrastructure

Bins/Libs

App-1

APACHEZookeeper

Container

Bins/Libs

App-2

Infrastructureインフラ構成概要

ZooKeeper

Mesos-Master

Mesos-Master

Mesos-Master

Marathon

Mesos-Slave Mesos-Slave

Task Task Task Task

...

Architecture

Zookeeper / Mesos / Marathon

Executer Executer

Request

ZooKeeper

Mesos-Master

Mesos-Master

Mesos-Master

Marathon

Mesos-Slave Mesos-Slave

Container Container Container Container

...

Architecture

Zookeeper / Mesos / Marathon

Executer Executer

Request

Marathon API

Arukas API

Container

libcontainer

exec driver (native)

CLI (Command Line Tool)

Mesos Master

rootfs (overlayfs...)

other drivers...

Mesos Slave

docker daemondocker.sock

network driver

UCP(User Control Panel)

graph driver

Mesos/Marathon

Docker Engine

Arukas UIarukas run ...arukas start ...arukas stop ...

Registries(DockerHub)

Container Container ContainerContainer

コンテナネットワーク構成概要

収容ホストサーバ

veth

--net=“bridge”

eth0

eth0 (veth)

veth

--net=“bridge”

eth0 (veth)

veth

--net=“bridge”

eth0 (veth)

veth

--net=“bridge”

eth0 (veth)

Bridge (docker0)

ポートマッピング• コンテナには『ランダムな IPアドレス と ポート』がマッピングされる。（下図において、コンテナの Port 80 は収容ホストサーバの Port 49154 にマッピングされている。）

収容ホストサーバ コンテナ

port 49154

Bri

dge port 80

eth0

ランダム！

エンドポイント• エンドポイントで『 任意の *.arukascloud.io ドメイン URL 』がマッピングされる。（※ HTTP通信限定）

port 49154

Bri

dge

port 80

ホストサーバ＃1 コンテナ

port 32632

Bri

dge

port 80

ホストサーバ＃2 コンテナ

Endp

oint

HTTP

HTTPS eth0

eth0

*.arukascloud.io

Internet 空間

Arukas Domain Endpoint

App

App or DB or PaaS or etc...

Endpoint: https://*.arukascloud.io

Instances: 1

Arukas Domain Endpoint

AppAppAppAppApp

App or DB or PaaS or etc...

Endpoint: https://*.arukascloud.io

Load Balancing

Scale-OutInstances: 5

Blue-Green Deployment

Version 2

Version 1

EndpointApps

UpdateVersion 2

Version 1

EndpointApps

エンドポイントの実体• HAProxy によるリバースプロキシ。（marathon-lb）

• Marathon と連携し、コンテナの動的なポート変動にも追従する。

port 49154

Bri

dge

port 80

ホストサーバ＃1 コンテナ

port 32632

Bri

dge

port 80

ホストサーバ＃2 コンテナmar

atho

n-lb

HTTP

HTTPS eth0

eth0

*.arukascloud.io

Internet 空間

Arukas API

Domain

Domain

Domain

Route53

Marathon

Architecture

marathon-lb

marathon-lb

DNSimple

polling and

Auto-generate configure

RestfulJSON API

Request

marathon-lb 以外の候補• haproxy-consul• Hipache• Bamboo• moxy• Træfɪk• Vamp Router• Vulcand

評価指標• CPS (Connection per Seconds)

• Simple json Rest API

• SSL Support

• WebSocket Support

• Zero-DownTime (Hot-reload)

• Health Check

• Custom Configuration

• Dynamic name resolution

• Event Driven

• Least Connection (LC)

コンテナ収容リソース（ゾーン）• ユーザーコンテナを収容するリソースは、『ゾーン』という単位で資源管理。

東京第1ゾーン 東京第2ゾーン

1ゾーンあたりのクラスタ構成

User’s Container

Mesos* 5-node

Mesos Slave’s* 9+ node

Zookeeper * 5-node

Marathon* 5-node

marathon-lb* 5-node

Arukas UI• User Control Panel• Public API• CLI Tool

User’s ContainerUser’s Container ホストサーバ

コントローラーサーバ

ゾーンのスケール設計

東京第1ゾーン 東京第2ゾーン 東京第3ゾーン

• ゾーンには必ず何らかのボトルネックが存在する。

ゾーンのスケール設計• サービス全体としてスケールしていくためには、ゾーンを増設していくこと以外の方法はない。

東京第1ゾーン 東京第2ゾーン 東京第3ゾーン

監視• インフラのメイン監視/メトリクスは Datadog

• コンテナの HealthCheck は Marathon に委任

• L7までの HealthCheck は marathon-lb

重点監視ポイント

User’s Container

Mesos* 5-node

Mesos Slave’s* 10+ node

Zookeeper * 5-node

Marathon* 5-node

marathon-lb* 5-node

Arukas UI• User Control Panel• Public API• CLI Tool

User’s ContainerUser’s Container ホストサーバ

コントローラーサーバ

コントローラーサーバ群を重点的に監視！

運用に伴う痛みについて

Arukasを襲ったトラブル

46

ビットコインを全力で掘られて収容ホストがフラップ

Arukasを襲ったトラブル - 症例１

概要： 100コンテナ以上のビットコインマイナーが・・・

原因： iowait上昇でMesos-Slaveの通信がフラッピング

Zookeeperのログが肥大化してクラスタ不安定化

Arukasを襲ったトラブル - 症例２

概要： 余力十分だったはずのZookeeperがフラップ・・・

原因： 再起動を繰り返すコンテナがZookeeperログを逼迫

Zookeeper再起動後にクラスタ崩壊

Arukasを襲ったトラブル - 症例３

概要： 他のZookeeperがMaster昇格したのにクラスタ崩壊

原因： 半端に同期されたZookeeperがMasterになってた…

Dockerイメージを大量にダウンロードされてDisk Full

Arukasを襲ったトラブル - 症例４

症例： Dockerイメージが多すぎてDisk Full

原因： 定期クリーニング処理の実行間隔が甘かった。

アップデート作業後には大体動かなくなる！

Arukasを襲ったトラブル - 症例５

症例： アップデート作業後には大体動かなくなる！ 原因： ライブラリ仕様変更、設定書式の仕様変更、各種不具合、原因は多岐に渡る・・・。

対処方法

•こまめな定期クリーニング処理。•各種制限設定。•バージョン管理の徹底。•キレイに落とす処理の追加。

キレイにKill or rebootする

•メモリ使用率が逼迫しはじめてる？落とせ！•ディスク使用率が逼迫しはじめてる？落とせ！•サーバ起動時の設定が一部おかしい？落とせ！•中途半端に生き残るよりもキレイに落とす！

コンテナ基盤運用のリスク• 突然のタイミングで動かなくなる可能性がある。

• すぐに直せる人材が近くに居るとは限らない。

• 規模拡大とともに運用負担が肥大化しやすい。

• 冪○性は過信できない。。

収容効率の課題• 既存の機器はコンテナの運用など想定していない。（ネットワーク、ストレージ製品など）

• サーバすらコンテナ数千台の運用は想定してない。

• これらを大前提にした設計が必要。

CPU制限• CPUサイクル、または重み付け制限が可能。

• 大抵の環境では重み付け(cpu-share)だけでいい。

• 共用ホスティングは、サイクルでの制御が必要。

• しかし、CPUサイクル制限は固定的。数秒程度のバーストを許可する設定ができると幸せになれる。

ディスク容量制限• disk quota は一部ファイルシステムでは可能(device mapper, btrfs, zfs...)

• aufs と overlayfs は quota 非サポート

• ちなみに、Arukas は overlayfs を採用。

• 今後の状況次第では、btrfsに乗り換えるかも。

ディスク I/O 制限• read/write を iops と bps で制御可能。

• bps は [bytes per second] なので注意…。

• 対象とするディスクデバイス名の指定が必要。

• ディスクデバイス名が変動する環境だと一手間必要。

セキュリティ• ホストのroot権限を奪取されるリスクはある。

• レンタルサーバやVPSにも同等のリスクはある。

• そのような技術を一切使わない（リスク回避）か。

• 迅速にパッチを当てる努力をする（リスク低減）か。

まとめ

設計について• 基盤から検討するなら幅広いノウハウが必要。

• コンテナの増加に伴って、何がボトルネック（頭打ち）になるかは、常に見極めなければいけない。

• 各種トラフィック、パケット、ARP、CPU、メモリ、etc...

• １クラスタあたり○万コンテナ収容！は幻想です。

運用について• 初めて遭遇するタイプのトラブルが多い。

• 大体なんでも直せるスキルがないとツライ。

• こまめに保守しないと動かなくなる。

• 障害対応スキルがより重要に。

痛みを軽減できないものか• Dockerは枯れていない。

• 追い付く努力と姿勢は必要。

• しかし、Dockerの作法は大きく変化してない。

• Dockerの世界観 (UI/UX) に乗ると救われる…かも。

最後は「運用でカバー。」

(C) Copyright 1996-2016 SAKURA Internet Inc.