さくらのDockerコンテナホスティング-Arukasの解説とインフラを支える技術（July Tech Festa 2016 『IoTxAIxインフラ時代の最新技術、やってみたSP－俺の屍を越えて行け－』）

さくらのDockerコンテナホスティング-Arukasの解説とインフラを支える技術（July Tech Festa 2016 『IoTxAIxインフラ時代の最新技術、やってみたSP－俺の屍を越えて行け－』）

1. 1. さくらのDockerホスティング Arukasの解説とインフラを支える技術 Shuji Yamada (山田 修司) @uzyexeJul 24, 2016
2. 2. この時間で学習できること
3. 3. 1. Arukasのインフラについて
4. 4. 2. Dockerコンテナの基盤運用について
5. 5. 3. 運用に伴う痛みについて
6. 6. 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
7. 7. 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
8. 8. アジェンダ • 自己紹介 • Arukas の紹介 (5分) • Arukas のインフラについて (15分) • Docker コンテナ基盤の運用について (15分) • まとめ (5分)
9. 9. SHUJI YAMADA • さくらインターネット９年目 • エンジニア • データセンター運用スタッフ • バックボーンネットワーク運用 • さくらのクラウド運用 • Docker ホスティング Arukas 担当 <- 今ココ （山田 修司） @uzyexe
10. 10. What’s Arukas?
11. 11. Run Dockerized Applications 450,000+ Dockerized Applications
12. 12. 1500 Users 1700 Users 1850+ Users 900 Users 2016/04 2015/05 2016/06 Today Users Growth
13. 13. 1850+ Users 4000 Apps 6000 Containers
14. 14. Dockerコンテナを直感的に操作できる WEBコントロールパネルを使って、複 数台のコンテナでも簡単に管理するこ とができます。 標準提供されているAPIを利用するこ とで、それぞれのオペレーションに応 じたプログラマブルな制御を実現する ことができます。 コンテナ用に独自設計されたインフラ と、高品質なさくらインターネットの インフラを利用して、Dockerコンテナ をすぐに利用開始できます。 Docker準拠 API対応 高品質な国産サービス 外部サービス連携（開発中）
15. 15. 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が実現できます。 その他
16. 16. VISION ビジョン インフラサービスの抽象化 開発者が自分自身で自由にサービス提供環境を構築できる アプリケーション開発に専念できるサービスをユーザーに提供する。 Arukas セントリック Arukasを基盤としてPaas/SaaS/BaaSなどの高レベルなサービスを実現できる環境 を提供する。 インテグレーション機能の提供 サードパーティ製の外部クラウドサービスを、 Arukas上からプラグインモジュールのように簡単に連携利用できるようにする。 Abstraction Arukas Centric Pluggable ポータビリティの実現 世界標準的なDockerコンテナに対応し、データを永続的には保持しないことで、 Arukasにロックインされない自由度の高い環境をユーザーに提供する。 Portability
17. 17. Arukasのインフラを支える技術
18. 18. IaaS Infrastructure Key Trend lightweight PaaS (CaaS) Baremetal PaaS？ ∼2025 ∼2020 ∼2010 teal?
19. 19. • 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’s Container as a Service
20. 20. Development Test Production Version Control CI/CD Deploy Dockerfile Docker Image CloudOn-Premise Registry
21. 21. Development Test Production Version Control CI/CD Deploy Dockerfile Docker Image Registry
22. 22. User Control Panel Client Compose Container Hosting Onpremises Infrastructure Orchestrator or or Volume Netwroking Logging Monitoring Integrations Registry Cloud API
23. 23. Container Bins/Libs App-3 Container Operating System Orchestrator/Container Scheduler Infrastructure Bins/Libs App-1 APACHE Zookeeper Container Bins/Libs App-2 Infrastructure インフラ構成概要
24. 24. ZooKeeper Mesos-Master Mesos-Master Mesos-Master Marathon Mesos-Slave Mesos-Slave Task Task Task Task ... Architecture Zookeeper / Mesos / Marathon Executer Executer Request
25. 25. ZooKeeper Mesos-Master Mesos-Master Mesos-Master Marathon Mesos-Slave Mesos-Slave Container Container Container Container ... Architecture Zookeeper / Mesos / Marathon Executer Executer Request
26. 26. Marathon API Arukas API Container libcontainer exec driver
 (native) CLI
 (Command Line Tool) Mesos Master rootfs (overlayfs...) other drivers... Mesos Slave docker daemon docker.sock network driver UCP
 (User Control Panel) graph driver Mesos/Marathon Docker Engine Arukas UI arukas run ... arukas start ... arukas stop ... Registries
 (DockerHub)
27. 27. 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)
28. 28. ポートマッピング • コンテナには『ランダムな IPアドレス と ポート』がマッピングされる。
 （下図において、コンテナの Port 80 は収容ホストサーバの Port 49154 にマッピングされている。） 収容ホストサーバ コンテナ port 49154 Bridge port 80 eth0 ランダム！
29. 29. エンドポイント • エンドポイントで『 任意の *.arukascloud.io ドメイン URL 』
 がマッピングされる。（※ HTTP通信限定） port 49154 Bridge port 80 ホストサーバ＃1 コンテナ port 32632 Bridge port 80 ホストサーバ＃2 コンテナ Endpoint HTTP HTTPS eth0eth0 *.arukascloud.io Internet 空間
30. 30. Arukas Domain Endpoint App App or DB or PaaS or etc... Endpoint: https://*.arukascloud.io Instances: 1
31. 31. Arukas Domain Endpoint AppAppAppAppApp App or DB or PaaS or etc... Endpoint: https://*.arukascloud.io Load Balancing Scale-Out Instances: 5
32. 32. Blue-Green Deployment Version 2 Version 1 Endpoint Apps Update Version 2 Version 1 Endpoint Apps
33. 33. エンドポイントの実体 • HAProxy によるリバースプロキシ。（marathon-lb） • Marathon と連携し、コンテナの動的なポート変動にも追従する。 port 49154 Bridge port 80 ホストサーバ＃1 コンテナ port 32632 Bridge port 80 ホストサーバ＃2 コンテナ marathon-lb HTTP HTTPS eth0eth0 *.arukascloud.io Internet 空間
34. 34. Arukas API Domain Domain Domain Route53 Marathon Architecture marathon-lb marathon-lb DNSimple polling and Auto-generate configure Restful
 JSON API Request
35. 35. marathon-lb 以外の候補 • haproxy-consul • Hipache • Bamboo • moxy • Træfɪk • Vamp Router • Vulcand
36. 36. 評価指標 • 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)
37. 37. コンテナ収容リソース（ゾーン） • ユーザーコンテナを収容するリソースは、『ゾーン』という単位 で資源管理。 東京第1ゾーン 東京第2ゾーン
38. 38. 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 Container User’s Container ホストサーバ コントローラーサーバ
39. 39. ゾーンのスケール設計 東京第1ゾーン 東京第2ゾーン 東京第3ゾーン • ゾーンには必ず何らかのボトルネックが存在する。
40. 40. ゾーンのスケール設計 • サービス全体としてスケールしていくためには、ゾーンを増設し ていくこと以外の方法はない。 東京第1ゾーン 東京第2ゾーン 東京第3ゾーン
41. 41. 監視 • インフラのメイン監視/メトリクスは Datadog • コンテナの HealthCheck は Marathon に委任 • L7までの HealthCheck は marathon-lb
42. 42. 重点監視ポイント 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 Container User’s Container ホストサーバ コントローラーサーバ コントローラーサーバ群を重点的に監視！
43. 43. 運用に伴う痛みについて
44. 44. Arukasを襲ったトラブル
45. 45. 46
46. 46. ビットコインを全力で掘られて収容ホストがフラップ
47. 47. Arukasを襲ったトラブル - 症例１ 概要： 100コンテナ以上のビットコインマイナーが・・・ 原因： iowait上昇でMesos-Slaveの通信がフラッピング
48. 48. Zookeeperのログが肥大化してクラスタ不安定化
49. 49. Arukasを襲ったトラブル - 症例２ 概要： 余力十分だったはずのZookeeperがフラップ・・・ 原因： 再起動を繰り返すコンテナがZookeeperログを 迫
50. 50. Zookeeper再起動後にクラスタ崩壊
51. 51. Arukasを襲ったトラブル - 症例３ 概要： 他のZookeeperがMaster昇格したのにクラスタ崩壊 原因： 半端に同期されたZookeeperがMasterになってた…
52. 52. Dockerイメージを大量にダウンロードされてDisk Full
53. 53. Arukasを襲ったトラブル - 症例４ 症例： Dockerイメージが多すぎてDisk Full 原因： 定期クリーニング処理の実行間隔が甘かった。
54. 54. アップデート作業後には大体動かなくなる！
55. 55. Arukasを襲ったトラブル - 症例５ 症例： アップデート作業後には大体動かなくなる！ 原因： ライブラリ仕様変更、設定書式の仕様変更、各種 不具合、原因は多岐に渡る・・・。
56. 56. 対処方法 •こまめな定期クリーニング処理。 •各種制限設定。 •バージョン管理の徹底。 •キレイに落とす処理の追加。
57. 57. キレイにKill or rebootする •メモリ使用率が 迫しはじめてる？落とせ！ •ディスク使用率が 迫しはじめてる？落とせ！ •サーバ起動時の設定が一部おかしい？落とせ！ •中途半端に生き残るよりもキレイに落とす！
58. 58. コンテナ基盤運用のリスク • 突然のタイミングで動かなくなる可能性がある。 • すぐに直せる人材が近くに居るとは限らない。 • 規模拡大とともに運用負担が肥大化しやすい。 • 冪○性は過信できない。。
59. 59. 収容効率の課題 • 既存の機器はコンテナの運用など想定していない。
 （ネットワーク、ストレージ製品など） • サーバすらコンテナ数千台の運用は想定してない。 • これらを大前提にした設計が必要。
60. 60. CPU制限 • CPUサイクル、または重み付け制限が可能。 • 大抵の環境では重み付け(cpu-share)だけでいい。 • 共用ホスティングは、サイクルでの制御が必要。 • しかし、CPUサイクル制限は固定的。数秒程度の バーストを許可する設定ができると幸せになれる。
61. 61. ディスク容量制限 • disk quota は一部ファイルシステムでは可能
 (device mapper, btrfs, zfs...) • aufs と overlayfs は quota 非サポート • ちなみに、Arukas は overlayfs を採用。 • 今後の状況次第では、btrfsに乗り換えるかも。
62. 62. ディスク I/O 制限 • read/write を iops と bps で制御可能。 • bps は [bytes per second] なので注意…。 • 対象とするディスクデバイス名の指定が必要。 • ディスクデバイス名が変動する環境だと一手間必要。
63. 63. セキュリティ • ホストのroot権限を奪取されるリスクはある。 • レンタルサーバやVPSにも同等のリスクはある。 • そのような技術を一切使わない（リスク回避）か。 • 迅速にパッチを当てる努力をする（リスク低減）か。
64. 64. まとめ
65. 65. 設計について • 基盤から検討するなら幅広いノウハウが必要。 • コンテナの増加に伴って、何がボトルネック（頭打ち）に なるかは、常に見極めなければいけない。 • 各種トラフィック、パケット、ARP、CPU、メモリ、etc... • １クラスタあたり○万コンテナ収容！は幻想です。
66. 66. 運用について • 初めて遭遇するタイプのトラブルが多い。 • 大体なんでも直せるスキルがないとツライ。 • こまめに保守しないと動かなくなる。 • 障害対応スキルがより重要に。
67. 67. 痛みを軽減できないものか • Dockerは枯れていない。 • 追い付く努力と姿勢は必要。 • しかし、Dockerの作法は大きく変化してない。 • Dockerの世界観 (UI/UX) に乗ると救われる…かも。
68. 68. 最後は「運用でカバー。」
69. 69. (C) Copyright 1996-2016 SAKURA Internet Inc.