コンテナ今昔物語_2021_12_22

Tech Dojo
コンテナ今昔物語
~コンテナ技術開発のモチベーションに迫る~
日本アイ・ビー・エム株式会社
テクノロジー事業本部カスタマーサクセス
カスタマーサクセスマネージャー
黒沢勇
2021/12/22

Who Are you?
Group Name / DOC ID / Month XX, 2020 / © 2020 IBM Corporation 2
自己紹介
氏名:黒沢勇
出身:神奈川県川崎市
前職: VMware SE (2017年入社)
現職: IBM CSM (2021/11月入社)
趣味: 自宅ラボ、ゲーム、積みプラモ
前職の登壇: vForum 2019-20, Cloud Operator Days Tokyo 2021
得意技術：仮想化、k8s、クラウド管理自動化可視化
Twitter: https://twitter.com/Torlek96
Linkedin: https://www.linkedin.com/in/kurosaway-b7486714b/

現在の自宅ラボ
現在はIntel NUC４台をVMware ESXiとして使用
Corei7, 64GB DDR4を４台なので大抵のことはできる
しかしk8sを満足に動かすためには若干力不足.
現在yahoo オークションで
1Uのラックサーバに張り付いて落札を狙ってます。
(ちなみに明日21:00が落札期限)
Skylake以上の世代、
かつ24コア以上のサーバをお持ちの方はぜひご連絡を
Twitter: https://twitter.com/Torlek96
Linkedin: https://www.linkedin.com/in/kurosaway-b7486714b/

Agenda
Group Name / DOC ID / Month XX, 2020 / © 2020 IBM Corporation
1. コンテナ技術が台頭する前の時代のお話
2. PaaS出現
3. コンテナの出現

コンテナ技術が
台頭する前の時代
昔々のそのまた昔、仮想化ができる前から話は始まります
人類がアプリケーションの起動を祈っていた時代です
(ちなみに私は今でもちゃんと祈りを捧げます)

プロセス技術の開発
chroot
1980年代に開発、ユーザが使用できるディレクトリを
制限する機能としてUnixに追加
セキュリティ技術を向上させ、
ユーザが使えるリソースを制限することが可能
コンテナと仮想マシン技術の肝は
リソースの制限と隔離。
そのため、本技術は仮想化技術の大祖先にあたる
FreeBSD Jail
chrootを発展させ仮想のFreeBSD環境を実行できる環境
を用意できる機能
usr
home
etc
bin
usr
home
etc
bin
dirB
dirA
chroot
root
Jail

仮想マシン技術の開発
2000年代に時は移動、元祖仮想マシンはVMwareからスタート
仮想マシン (VM) 技術が
コンテナ技術の開発に先立ち、開発が進む.
必要なリソースをファイルとしてパッケージングし、
内部的にはプロセスとしてVMを動かす技術は大ヒット
この技術により全く違うOSも、バージョンが違うOSも
同じホストで動かすことができるようになった。
ハイパーバイザ型の仮想化よりも
ホスト型仮想化の方が先に開発されている
1999〜
2007〜
2010〜
2008〜
※あえて古いロゴを使用

仮想マシン技術のサーバへの適用
サーバを１つずつ管理していくことが困難になってくる
ハイパーバイザー型の仮想技術が発達することで、
仮想マシンを本番環境で運用できるようになる
次第にホスト数が増えていき
単一コンソールでは管理がしきれなくなったため、
VMwareではvCenter Server、
KVMではHorizonと呼ばれる管理ソフトウェアが開発された
2003年にvCenter Server 1.0をリリース
2012年にEssex versionからHorizonをリリース

パブリッククラウドの出現
大量のコンピュートリソースを間借りできるサービスがリリース
2006年リリース 2010年リリース 2008年リリース
2005年リリース
(SoftLayerからカウント)
2016年リリース 2011年リリース

Solaris Container と LXC
一方でコンテナの元となる技術出始める
2004年〜
Solaris Unix 上でコンテナ仮想化を実装する技術が
2004年にパブリックベータとして公開。
Solaris Zoneと呼ばれる技術を用いて
Zoneごとに独立したアプリケーションを稼働可能にした
従来の仮想マシンと比較して起動が早く、
仮想化によるオーバーヘッドも少ないという特徴も併せ持つ。
本格的な商用コンテナ初号機
2008年にLinuxでも本格的なコンテナ仮想化が使用可能に
2006年に開発されたProcess Containerがcgroupsと名前を変え、
Linux Namespaceと組み合わせて軽量なVMをデプロイする機能としてリリース
Dockerとは思想が異なるため使い分けが必要

蛇足: Sunのコンテナといえば
Project Blackboxと呼ばれるコンテナ型DCの発表も！
中にネットワーク機器も入っている小さなDC！
まさにコンテナなので
上に積んでスケールアップもできるし、
横に並べてスケールアウトもできるという
コンテナの考えを引き継いだDC！
※本当にその思想でできたかは知りません

仮想マシン技術について
ハイパーバイザー仮想化
仮想マシン(VM)
ゲストOS
アプリ
アプリ
仮想マシン(VM)
ゲストOS
アプリ
アプリ
ハードウェア
ホスト仮想化
アプリ
アプリ
仮想マシン(VM)
ゲストOS
アプリ
アプリ
bin/lib
vCPU vRAM vNIC vCPU vRAM vNIC vCPU vRAM vNIC
bin/lib bin/lib
ハイパーバイザー
(専用OS)
ホストOS
bin/lib
ホスト仮想化はオーバーヘッドが大きくゲストOSのパフォーマンスが低くなることもあるが、気軽に扱える。
ハイパーバイザ仮想化は専用OSを用いるため、オーバーヘッドが少なくなるが別途踏み台が必要になる。
また、Intel VT-x, AMD-SVMと呼ばれるCPU側でVMを高速化する技術も発達している。
ハードウェア
CPU RAM NIC
CPU RAM NIC

PaaSの出現
時は2010年台に移り、VMを使うのが当たり前の時代
VMでみんな大満足したはずなのに何でPaaSができたのでしょうか？
IaaS、SaaSだけでいいんじゃないか？と思いませんか？

閑話休題:要求と要件
コンテナは要求ではなく、要件であることに注意
要求定義の例要件定義の例
• 開発スピードを早めるため、
フロントシステムとバックエンドシステムに
コンテナを採用
• 安定性を高めるため、DBはベアメタル、
もしくは大型の仮想マシンで構築
• 開発者のストレスを減らすためにPaaSを採用
• テスト/リリーススピードを早めるために
CI/CDシステムを構築
• 承認スピードを早めるためにCI/CDを使用
• ソフトウェアリリースを6ヶ月サイクルから
３ヶ月サイクルに短縮
• メンテナンス時間のオーダーを
DayからHourに削減
• 承認に関わる時間をDayからHourに削減
• 開発者の雇用満足度を２割向上

開発者の究極のモチベーションその１
俺はコードだけ書きたい！

仮想マシン技術で開発者の要求は満たせたか？
No.
仮想マシンは様々なOSをVMとして
気軽にデプロイすると言う要件を満たした。
しかし、VMの中で実行環境を構築したり、
パイプライン管理ツールなどでテスト管理した
りとやることは非常に煩雑なままであった。
=依然開発者はストレスフルなままであった。
設定
パイプライン処理
Compute Storage Network
クラウドリソース
VM VM VM
Application
開発者
コード

開発者の究極のモチベーション
開発者はコードを書いて、
素敵な機能を実装し、
ユーザや自社に貢献することがモチベーション
コードを書き終わったらコマンド１つで
さっさとリリースして欲しい
(インフラのことなんか気にしたくない)
VM VM VM
Application
開発者コードだけにしたい

開発者の究極のモチベーション
VM VM VM
Application
開発者
１つのコードだと思いたい
＝Infrastructure as a Code (IaC)でやりたい、
もしくは気にせずにプッシュしたらリリースしたい
Application
コードだけ

PaaSの台頭
Rubyの実行環境を提供する商用サービスとして2007年にリリース
様々なコードをアップロードするだけで
簡単にwebサービスを立ち上げることが可能。
無料プログラムがあるためスタートアップ、個人開発にも大人気
内部的にはDynoと呼ばれるコンテナが稼働している
Ruby/PHPの実行環境を提供する商用サービスとして2009年にリリース
Herokuと同じく簡単にWebサービスをリリースできる
プラットフォームとして人気
Javaコードをプッシュするだけでアプリケーションがリリースされる
PaaSのソフトウェアとして2011年リリース
(現在はPHP,Ruby,Goなどにも対応)
VMwareが開発を行っていたがPivotal Softwareに開発を移管
IBM Cloudを含めた様々なクラウドで実行されている

IaCに関わるツールの紹介(ごく一部)
インフラリソースをファイル形式で定義し、
あまねくクラウドへリソースをデプロイする機能を提供
仮想マシンをパッケージとしてデプロイすることが可能
コマンド１つでローカル環境にデフォルトでVirtualbox環境の仮想マシンをデプロイ
PHP, Pyton, Javaなどのコード開発環境をコマンド１つでデプロイ可能
Playbook単位でサーバの構成管理をYamlファイル形式で管理
サーバのあるべき姿を定義してインストールを実行
Ansible towerというGUI管理ソフトウェアを提供

他にもツールはまだまだある
時間はないので割愛しますが、他にも様々なソフトウェアがあります

コンテナの本格利用
PaaS環境が整ってきましたが、まだまだ技術の進化は止まりません
ごく一部で使っていたコンテナがあまねく環境に広がっていきます

開発者の究極のモチベーションその２
リクエストが尽きることはない
秒単位で起動してくれ！

仮想マシンの起動は少し遅い
仮想マシンはOSが稼働するCPU、メモリなどのHWをエミュレーションしている
そのため起動時には当然OSが１から立ち上がってくる
そのため再起動するのに数分かかるし、
クローンをすると場合によっては数十分から数時間かかることもある
仮想マシン(VM)
ゲストOS
アプリ
仮想マシン(VM)
ゲストOS
アプリ
bin/lib bin/lib
vCPU vRAM Disk vCPU vRAM Disk
仮想マシン(VM)
ゲストOS
アプリ
bin/lib
vCPU vRAM Disk
再起動時はOSから再起動するため最低数分は必要ディスクもクローンするため数十分、場合によっては数時間必要
仮想マシンの再起動イメージ仮想マシンのクローンイメージ
ハードウェア
ハードウェア

コンテナとは
OSのレイヤで起動するので早いし、どこでも実行可能
ハードウェア
ホストOS
コンテナエンジン
コンテナ
bin/lib
アプリ
Kernel
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
Ø ホストOSのレイヤで
CPUやメモリ、プロセスなどの
リソースを隔離、独自のアプリも実行可能
例: PHPのバージョン違いを同時に稼働
Ø ポイントはKernelの共有
• カーネルを共有することでVMと比較して
早くデプロイ、起動が可能
Ø Linux Kernelとイメージさえあれば、
どんな環境でもアプリケーションが
動作する(冪等性)ということも魅力の１つ

Dockerの誕生 (2013〜)
コンテナエンジンのデファクトスタンダード
コンテナ技術の開発により、手元のローカル環境で素早く実行環境を用意
世に出回ったときのバージョンは0.xで、商用環境は非推奨だったが
Docker 1.0のリリース(2016〜)により、商用環境広まっていくことになった
Dockerfileなど Docker
イメージなど
DockerHub
など
マニフェストで
コンテナの詳細を記述
開発者
コンテナイメージ
作成
レジストリーへ
登録
アプリ実行
コンテナー
コンテナー
コンテナー
開発環境
テスト環境
本番環境
Dockerが受けた理由はいろいろあるが下記が代表例
• イメージが元からDocker Hubにあったため簡単に試せるということ
• コマンドで１発でどこでも動かせる実行環境を用意できること

しかし、Dockerの限界も見えてきた
わがままなのは開発者だけじゃなかった
• コンテナたくさんデプロイしたけど冗長性はどうやって担保？
• マイクロサービス、目指したはいいけれどLBは、まさか手動？
• システム毎にリソースの制限したいけどどうするの？
VM時代はできたよそれ！
• Dockerって基本NATで外に出ていくけど、
どうやって他のホストのコンテナと通信するの？
• このコンテナ絶対にこのホストで動かしたいんだけど？
• コンテナってデータ消えるじゃん！

Googleの衝撃的なプレゼン(2014年)
https://speakerdeck.com/jbeda/containers-at-scale
Googleは全アプリケーションを
コンテナ上で稼働
• 毎週20億コンテナを起動
• リソースの隔離、QoSを実現
• Google App Engineの内部も
コンテナ化をアナウンス
• GoogleはDockerではなく、
lmctfyを使用

オーケスレーションシステムの代表例
Dockerの限界を越えるためにコンテナを自動的にうまく管理する仕組みを導入
事実上この２つが争っているだけだったが現状はKubernetesの勝利

Kubernetesリリース (2014〜)
デプロイしたコンテナをいい感じに管理してくれるスーパーソフトウェア
Googleが内部用に開発していたBorgと呼ばれるソフトウェアを
Kubernetesとしてオープンソース化
簡単に商用コンテナ環境をスケーリングできるし、障害時には自動復旧可能
おまけにネットワーク周りの問題もよしなにしてくれます
リソース要求と可用性を保ち、また、制約に基づき、自動的にコンテナの配置を決定。
リソースの有効利用を実現。
障害コンテナの再起動、ノード障害時には、コンテナの再配置の実施。
また、ユーザー定義のヘルス・チェックに応答しないコンテナの削除も実施可能。
コマンドやUIから簡単にアプリケーションのスケール・アップ / ダウンが可能。
また、CPU使用率などに基づく、自動スケーリングも可能。
複雑なサービス・ディスカバリー・メカニズムのアプリケーションへの組み込みは不要。
Kubernetesは、コンテナの集合に単一のDNSネームを付与し、負荷分散を実現。
アプリケーションの変更を順番に適用。（ローリングアップデートなど）
何か不具合が発生した場合には、ロールバックも可能。
リソース管理
(スケジューリング)
自己修復(セルフ・ヒーリング)
水平スケーリング
負荷分散
(サービス・ディスカバリー)
ロールアウトとロールバック
構成管理コンテナを実行・管理するために必要なメタデータが含まれる。
パスワードやOAuthトークン、SSHキーのような機密情報も管理が可能。

どういい感じにしてくれるのか？
31
３ページ前の悩みは全て解決してくれます
マニフェスト
(Yamlファイル)
開発者
フロントは2pod、
バックエンドは 3pod、
DB podは
この永続ストレージを使って、
port はこの番号を開けて、
LBの分散方式はラウンドロビン
各コンテナのイメージは
docker hubの
このURLのやつを使って
Master Node

32
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
Software LB
(Ftont用)
Software LB
(Backend用)
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
マニフェスト
(Yamlファイル)
開発者
Master Node
マニフェストの
ルールに従って
Deploy

33
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
Software LB
(Ftont用)
Software LB
(Backend用)
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
マニフェスト
(Yamlファイル)
開発者
Master Node
ホストのダウンで
コンテナが落ちた

34
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
Software LB
(Ftont用)
Software LB
(Backend用)
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
マニフェスト
(Yamlファイル)
開発者
Master Node
Master nodeが
障害を検知して
別のホストに
Deploy

35
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
Software LB
(Ftont用)
Software LB
(Backend用)
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
コンテナ
bin/lib
アプリ
マニフェスト
(Yamlファイル)
開発者
Master Node
Master nodeが
障害を検知して
別のホストに
Deploy

時代は繰り返されているように見える
開発環境から商用環境へ適用
VMware Workstation
開発環境商用環境
仮想マシン技術
コンテナ技術

各ベンダーのKubernetesへのコミット
https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1
多くのITベンダーがk8sコミュニティに投資、
コミットを行っており開発が盛んな状況。
次世代のOSになるというコメントも出ているほど

VanillaなKubernetesの課題
機能が不十分
Dev Ready だが
IT Ops Ready
ではない
Supportが
Communityのみ
Enterpriseで使うには
可視化機能やLog機能が不十分
単体でCI/CDは実現できない
習得には学習コストがかかる
Enterpriseな
ユーザ企業が使うには不安

各ベンダーのKubernetes技術
Red Hatが開発したコンテナ技術を丸ごとパッケージとして提供
リソース管理、カタログ、デプロイ機能、CI/CD機能を提供
VMwareが開発したコンテナ技術をパーツとして提供
Build自動化やマルチクラウド管理機能なども提供
既存vCenterからKubernetesの管理をすることも可能
Rancher Labsが主導となって開発しているマルチクラウド向けの
KaaS(Kubernetes as a Service) ソリューション
KubernetesをGUI上で簡単に管理できるため、初心者にも易しい。

パブリッククラウド上のk8s
各クラウドベンダーのマネージドk8sを利用できるKaaSサービスを各社でリリース

まとめ
コンテナ技術が生まれ
たモチベーション
歴史は繰り返す残った課題の対応
開発者の生産性向上から始まり、
本番環境での適用がスタート
コンテナ技術は開発者の生産性
を劇的に向上させるために生ま
れ、実際に向上
様々なベンダーがk8s技術に注力
次世代OSとして期待

コンテナ今昔物語_2021_12_22

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to コンテナ今昔物語_2021_12_22

Similar to コンテナ今昔物語_2021_12_22 (20)

コンテナ今昔物語_2021_12_22