GTB2020; Introduction to virtualization technology on GMO Tech Bootcamp

Introduction to virtualization technology on GMO Tech. Bootcamp.

These materials are materials for learning about virtualization in GTB2020, using services and existing products owned by group companies of GMO internet Inc., as examples.

Please listen to the latest technology and terminology and put it in one corner of your head.
The purpose is to help you remember "this happened" when you touch the technology, study, or touch a new development style when you actually enter the field or in the future. I will.
For that reason, we need to study an introduction to virtualization technology.

------------------
仮想化技術概論

これらの資料は、GTB2020にて、GMO internet Inc., のグループ企業がもつサービスや実在の製品を例に、仮想化について概要的に学習するための資料である。

どうか、最新の技術や用語については、とりあえず聞いておいて、頭の片隅に入れておいてください。
あなたがこの先、実際の開発や現場に入ったときに、技術に触ったり、勉強したり、また新たな開発スタイルに触れたときに、「こんな事あった」と思い出せるようにすることを目的とします。
その理由より、我々は仮想化技術の概論を勉強する必要があります。

------------------

Transcript

1. GMO Technology Bootcamp, 2020 仮想化基礎 @2020版 (座学) GMO Internet, Inc. System Division Cloud Service Development Department Naoto Gohko (@naoto_gohko) (2019/05/18, 11:13 – (1コマ))
2. 郷古 直仁(Gohko, Naoto) mail: naoto-gohko@gmo.jp Twitter: @naoto_gohko github ID: naototty 所属：GMOインターネット システム本部 クラウドサービス開発部 略歴：Bekkoame, 3webなどホスティング お名前.com VPS(VZ, KVM), ConoHa お名前.com Cloud Z.com Cloud GMOアプリクラウド クラウド型IaaSサービスの開発をやっています 私は誰?
3. Agenda • 1) About us (GMO Internet Groupについて) • グループのクラウドインフラサービス • 2) 「仮想化」は「抽象化」、抽象化を⽣かしたツールの活⽤ • 3) 「仮想化」は「リソースの有効活⽤」 • 4) 「仮想化」は「冗⻑化」と「負荷分散」の始まり • 5) 「仮想化」と「クラウド化」は「簡単DevOps」の活⽤ • 6) まとめ
4. 1)About US (GMO Internet Group)
5. Infrastructure Business Bank and Trade
6. The Cloud IaaS in our GMO Group
7. OpenStack • OpenStack Foundationで開発のIaaS cloud – https://www.openstack.org/ – NASAとRackspaceがOSSとしてソースコードを持ち寄って開発が始まる – ストレージ、ネットワーク などの多くの仮想化技術 を⽣み出した – 運⽤ • ConoHa (public) • z.com Cloud (public) • Pepabo private cloud
8. Cloudstack • Apache Foundationで開発のIaaS cloud system – http://cloudstack.apache.org/ – もとは、商⽤のOSSで、Apache Found.に提供され開発が継続された – 運⽤ • ALTUS cloud
9. Public Clouds : Exp) OpenStack We are offering four public cloud services.
10. OpenStack Juno: 2 service cluster Mikumo ConoHa Mikumo Anzu Mikumo = 美雲 = Beautiful cloud クラウド商材の仮想⼈格化???
11. Cloud Provider (top 3) with Virtulization • Amazon Web Service – Xen based Hypervisor è Linux KVM based Hypervisor – Network? Storage? • Google Cloud – Linux KVM based Hypervisor – Andromeda SDN • Microsoft Azure – Hyper-V based Hypervisor – BGP based networking – Azure Managed Disk, Ultra Disk – ref インフラ野郎Azureチーム: • https://www.slideshare.net/slideshow/embed_code/key/gPmm4YB7nSmbob
12. 多くの仮想化技術に⽀えられている クラウドシステム どんな仮想化技術が使われているのか? それを知る、そして、活⽤する
13. えっ?_ 仮想化って、?
14. 仮想化って? VR?
15. 仮想化って? VR?
16. 「かそうか」 VR[仮想現実]も「仮想化」という⾔葉の⼀つの 姿である コンピューティングとして(コンピュータに) 「なに」を実現させるかの違い
17. ここで疑問: • 仮想化って? – サービスを仮想化するってどういうこと? • クラウドサービスとかいうけど? – 「なに」を仮想化して「提供」しているの? • なにがお得なの? • 利⽤は簡単なの?
18. 以上のことについて、例を踏まえて触れ ていく
19. 2)仮想化は抽象化、抽象化 を⽣かしたツールの活⽤
20. Using Cloud and Virtulization on our Infrastructure GMOグループのサービスは様々な仮想化技術を⽤いて提供されている • Server • Application • Network • DNS(Onamae.com), DNSaaS • BGP • VPN • LB, L7LB • Storage • Block Storage • Cloud Storage • Blockchain etc 仮想化技術 := リソース(Network, Server, Storage)を”何処かで”使っている
21. 世の中のいろんなサービス(EC, SNS, ゲーム)など • どんなシステムの構成なのか • どんな技術を使っているのか • そのサービスは”どんな仮想化技術”を使ってい るのか 「興味」 > 他のサービス事例などを⾃分に⽣かせるように
22. 世の中のいろんなサービス、ゲーム どんなシステムなんだろうか? >> そのための、きっかけとなる話
23. 仮想化 ABC まずは、物理の抽象化 pA) 分割: 物理リソースの抽象化と分割、動的 利⽤を可能にする pB) 結合: 複数の抽象化リソースを⼀つの抽象 化リソースとして利⽤可能にする pC) 独⽴性: 複数の抽象化リソースはつねに、 複数のまま独⽴利⽤できる
24. 仮想化ってなんですか?: 抽象化リソースの提供: 分割 A) あるシステムのリソースを”抽象化(Object)”して、機能として”動的”に提供 できるようにすることができる 例)リソース: 仮想マシン VLAN コンテナ
25. ex)仮想マシン
26. ex) VLAN(仮想ネットワーク, VLANタギング: IEEE 802.1Q ) 仮想マシンの仮装ネットワーク として⽤いられる
27. ex) コンテナ型: OS仮想化、アプリケーション仮想化 一般的に、コンテナは、OSを含めた、 「アプリケーションの可搬性」に優れる (かるい) ハイパーバイザを利用したコンテナ(Windows container, Noah(mac), kata-container, gVisor)なども考案されている
28. 仮想化ってなんですか?: 抽象化リソースの生成: 統合 B) あるシステムのリソースを”抽象化(Object)”して、あたらな”抽象化”リソースとして 見せることができる(複数のモノから、仮想的な一つのモノ) 例)リソース: 仮想メモリ RAID 分散ストレージ Load Balancer Database
29. ex) 仮想メモリ OSの仮想メモリは、仮想アドレス空間 をアプリケーションから利用するものが 多い(仮想記憶) その他、RDMA経由でネットワークアク セスするなども考えられている
30. ex) RAID disk 複数のdiskをつかって、大容量化や、 安全性を提供する Network経由で複数のdiskを組み合わ せる分散ストレージSDS(Software Defined Storage)というものもある
31. ex) Load Balancer 一番シンプルなLoad Balancer構成 後ろには複数台のwebサーバ Load Balancerによって、1台のwebでは捌ききれないような、 大規模なwebトラフィックをさばくことができるようになる
32. ex) Database (分散DB, 例) 一つの PostgreSQL RDBに みえるが、実際は ・SQL層 ・分散KV層 などの複数ノードに分かれて いる (他、Amazon Auroraなど)
33. 仮想化ってなんですか?: 抽象化リソースの独立性 C) あるシステムのリソースの”抽象化(Object)”は複数の独立したリソースとして常に 取り出すことができる(独立したモノ) 例)リソース: VLAN VXLAN VPN
34. ex) VLAN, VXLAN, (VPN) 全体では、一つの物理ネットワークだが、 VLANにより複数のネットワークとして使 うことが出来る SWTICHの間は、物理線が1つだが、 VLAN同士で独立している
35. ex) Load Balancer (Layer 7, Reverse Proxy) .js, .html, .php HTTP コンテンツやURLごとに、 それぞれのバックエンド に振り分ける PHPは動的にwebコン テンツを生成するので 遅い Jpg, JS, htmlなど静的 なファイルを分散して高 速に配信することで、 web表示の体感速度を 早めたりする
36. ex) Load Balancer (API Gateway; ex: Traefik) HOSTやURI path, Methodごとに、振り 分け先を設定できる POST /api/buy/item -> API GET /html/index.html -> Web みたいに処理をURI ごとに分散できる
37. Reverse Proxy, API Gateway HTTP Method(GET, POST, PUT, DELETE) + URIごとに分散 • èバックエンドサーバを別々にできる • è開発⼯程を別々にできる 開発の割り振り ex) クラスごとのwebサーバの開発の分割 := マイクロサービス化 /servers :à server-sv:10080 :à 開発Group A /users :à server-usr:11080 :à 開発Group B • ConoHa APIでもこの技術は使われている • è異なるAPI body(コンテンツ)のものを変換して配信できる(API Gateway) • request JSON API :à backend XML API コンテンツ(Layer 8)の変換のサポートするものもある • ex) public service: IFTTT, Zapiar, n8n.io(OSS), Microsoft Flow • ex) n8n.io : https://github.com/n8n-io/n8n
38. 抽象化 :: 仮想化の⼀歩 (Hardware依存を減らす) 以下、実例
39. ex) コンピュータやシステムの抽象化: qemu, qemu-kvm 物理リソース 論理リソース(仮想化) 抽象化されたリソース CPU Core i7 Xeon E5-2670 qemu kvm Core i7 (Emulation) qemu kvm Core i7 disk /dev/sda HGST WesternDigital disk image node.qcow2.img /dev/sda disk image /dev/sda /dev/vda (ConoHa) Netw ork eth0 Broadcom NIC Intel NIC(e1000) eth0 Virt-io NIC Intel NIC(e1000) (Emulation) eth0 物理リソースとして使っていたものから、システムとしての機能の部分 だけを抽出化して、システムで利⽤できるようにする 仮想化ソフトウェアがDeviceを仮想とし⾒せている
40. 仮想化する Þ ソフトウェアでハードウェアを表現 できる(仮想化されたDriver) Þ ソフトウェア(Tool)の組み合わせに よって、⾼度な仮想化=クラウドへ (Hypervisor +α)
41. 3) 仮想化はリソースの有 効活⽤
42. 物理的な制約を 論理的に解決するための技術 • ハードウェアの⾼速化、⾼機能化(仮 想化⽀援機能)などの進歩により実現 された (汎⽤サーバの低価格、⾼性能)
43. 仮想化を助けたハードウェアの進化 CPU, Memory • ムーアの法則に沿った半導体の進化 • Manycore Processer / GPU Storage • HDDから • SSD(Flash Storage)への変化 (ConoHa) Network • 1G bps Networkから • 10G bps Network (ConoHa) • 40G bps Network • 100G bps Network (GMO GPU cloud)
44. 仮想化はなぜ必要? : 効率的利⽤ 決められたリソースを如何に効率良く使うのか? • 例)8GB MemoryのノートPCを開発で活⽤するには? • VMやコンテナを動かして、開発環境をON/OFFして切り替えて使う • 例) 使⽤頻度が少ない古いアプリケーションは、vmにして、たまに使う 仮想化で少ないリソースを複数集めて、⼤きなリソースを提供する • 例)最近のソーシャルゲームの通信した先にあるたくさんのサーバ • 多くのゲームトラフィックを捌くための • ネットワーク仮想化 • サーバ仮想化 • スレトージ仮想化 場合によっては、リソースの変更が容易 • メモリ割り当て変更
45. ex) ConoHa WING: https://www.conoha.jp/wing/ 商⽤Hosting OSである “CloudLinux” の以下の機能により、ユー ザー空間をスレッド単位で仮想化している • LVE (Linuxのプロセス・スレッドをuser IDごとにCPU, Memory割当) • CageFS (ストレージアクセスの仮想化、牢獄[jail]化) コンテナ技術より派⽣したHosting仮想化技術 実現されること: • webサービスの仮想化(Virtual Host)に より、たくさんのユーザをHardwareに 収容できる (CPU coreが多いサーバが必要) • 仮想化によりAutoスケールup/downが容易
46. ex) Lolipop Managed Cloud: https://mc.lolipop.jp/ Linux Container技術の⼀つ ”haconiwa” 実装により、FastContainerを実現 • ex) https://github.com/FastContainer/nginx-haconiwa • アプリケーション・コンテナの実現 リソース活⽤と、負荷分散(スケールアウト)が実現 è オートスケールが実現、「早い」が特徴 ロリポップ！マネージドクラウド FastContainerの裏側 https://www.slideshare.net/ssuser6e4f0a1/fastcontainer ref) 歴史から紐解くLinuxカーネルのコンテナ機能 https://speakerdeck.com/tenforward/cndt2019 Linuxコンテナ機能について学べます
47. ex) ConoHa VPS 複数の仮想化の組み合わせ • Linux KVMによる仮想化 • CPU, Memory, Disk(SSD)のリソースの分割提供 • VXLANにより、ネットワーク仮想化 • ユーザごとのNetworkの分割提供 • ロードバランサによる負荷分散ネットワークの提供 • ストレージ仮想化 • ブロックストレージの提供 • オブジェクトストレージの提供 • リソースサービスごとの管理 • マイクロサービス化
48. ex) 仮想マシンによるリソース分割 仮想マシンのOSには、仮想化された ハードのみ見える
49. 仮想マシン: ホストOS型、ハイパーバイザ型 今現在はこの区分は明 確ではなくなってきてい る。 ホストOSにハイパーバイ ザをKernel driverとして もっているもの(Linux KVM, Mac OS X+ xhyveなど)を利用するも のもあり、わかりにくい
50. 仮想化する Þ リソース分割でサーバリソースを有効活⽤でき る Þ ConoHaのように、クラウドサービスは⾃分と 他⼈を分離して独⽴性のあるリソースを提供で きる Þ Lolipop Managed Cloudのようにコンテナ活 ⽤によるリソース提供を⾼速に実現することも できる
51. 4)仮想化は冗⻑化と負荷分 散の始まり
52. 分散ストレージ なぜ必要とされるのか クラウドストレージの要件 • 利便性 (簡単に払い出し) • 可⽤性 (冗⻑性) • Scale out性能 (運⽤性のある簡単増設) • ⾼速性 ストレージの仮想化は⾯倒な最後の領域
53. どんな仮想化? *) 複数のDISKを⼀つのストレージ領域として仮想的 に⾒せる *) 集約した仮想ストレージ領域を、必要に応じて リソースを切り出して提供する *) 分散ストレージから分割したリソースは⾒た⽬上 独⽴して運⽤が可能である
54. ストレージはバケツ!?のようなもの 1つ払い出しました いっぱいになりました 2つ目を払い出しました … 使う方 数だけふえても、使いづらい è 数を増やしたら、容量と性能を増やせないか?
55. データが増え続けるStorageと分散処理の両⽴ (かなり重要)⾜りないリソースに対して、スケールアウトできるIOPS 0 2 4 6 8 10 12 14 16 0 1 2 3 4 5 6 1K x IOPS Number of Nodes
56. 分散ストレージ: Distributed Storage 商⽤製品 • ScaleIO (Dell EMC) • SolidFire (NetApp) • NexentaEdge (Nexenta) • Storage Spaces Direct [S2D] (Windows Server 2019) • Nutanix (Nutanix) • … etc. Opensource • GlusterFS • Ceph • DRBD • Lustre • OpenIO • … etc.
57. Software Defined Storageの発生(ex: Ceph) 仮想化だけでなく ・ストレージの冗⻑化 ・性能のスケールアウト についても考えられるようになってきた Linux KVM host
58. S2D (Storage Spaces Direct) Windows server 2019 スケールアウトできる分散ストレージ • レプリカ分散 • Erasure code Windows 2016から 実装が始まる Azure Storageから ⼀般向けに 利⽤ • Azure Stack
59. Ceph スケールアウトできる分散ストレージ • レプリカ分散 • Erasure code 利⽤ • NiftyCloud • DigitalOcean • DreamHost • OVH • CERN
60. GlusterFS スケールアウトできる分散ストレージ • レプリカ分散 • Erasure code 利⽤ • Facebook • ConoHa (image storage)
61. Storage server: many NVMe SFF-8639 For Software Defined Storage? Ceph or ScaleIO or etc. çNVMeの活⽤ (Softwareにより) 次世代Flash ストレージの進化
62. NVMe over Fabric (NVMeoF) 1) 多くの public cloudでは、50Gbps以上のネットワーク帯域で提供される ようになってきた (25 Gbps x 4 = 100 Gbps = 400 Gbps / 4) 2) 100Gbps ó PCI-Eの速度を超える (NVMe over TCP) 3) Linux kernel 5.0などで、使えるようになる (AWSなどで⾒えるnvme device) $ sudo nvme list Node SN Model Namespace -------------- -------------- ---- ------------------ --------- /dev/nvme0n1 VB1234-56789 ORCL-VBOX-NVME-VER12 1 /dev/nvme0n2 VB1234-56789 ORCL-VBOX-NVME-VER12 2 Usage Format FW Rev -------------------------- ---------------- -------- 2.15 GB / 2.15 GB 512 B + 0 B 1.0 2.15 GB / 2.15 GB 512 B + 0 B 1.0
63. ex) NVMe over Fabric (NVMeoF): NVMeの仮想化
64. 冗⻑化(可⽤性) x86サーバー (ストレージ・ コントローラ) JBOD(HDD/SSD) HA JBOD(HDD/SSD) JBOD(HDD/SSD) ・・・ CPU RAM CPU RAM x86 x86 SAS ファイル/ブロック (CIFS/SMB/NFS/iSCSI/FC) 冗⻑化とは、故障にあってもサービス を継続するための仕組みのこと。 仮想技術でEndpointを作り出し、⽚ 側のDownを検出したら(keepalive)、 サービスエンドポイントが、他⽅にマ イグレーションする ストレージ、ネットワーク機器など停 ⽌困難なシステムに組み込まれている 左の例では、ストレージの”コント ローラ”がHA(冗⻑化)され、ディスク も複数本共有され冗⻑化されている ex) ストレージ冗⻑化(可⽤性)
65. ex) Virtual IPとストレージの冗⻑化 ARC (DRAM) 大容量キャッシュ 例: 256GB SAS 12Gbps x86サーバー JBOD/ディスクエンクロージャ 書込み完了 ACK HDDへのコミット(事後処理) (シーケンシャル書込み) SLOG/ZIL Writeログ SSD プール データディスク HDD/SSD 書込み完了(ACK) クライアント 書込み処理 Data (未) Dat a (未) Dat a (完) Dat a (完) コミット (HA後処理) 書込み完了 ACK 自動 HA フェイル オーバー ARC (DRAM) 大容量キャッシュ 例: 256GB Virtual IP (VIP) の Fail over Virtual IP Fail
66. 5)仮想化とクラウド化は簡 単DevOpsの活⽤、 Deployに⼯夫しよう
67. クラウド化によって ・ リソースとして抽象化された(CPU, Memory, DISK)を APIでプログラマブルに利⽤できる • è vagrant, terraform, ansible, pulumiなどの仮想 化、クラウド両⽅にインフラがdeployできるツール ・ ⼀つのクラウドで⾜りない分は、別のクラウドから追加 すれば良い ・ アプリケーションの最適化と⾃動化
68. 仮想化とクラウドサービス: 開発者主体となる 開発者1stな環境 • 開発ツールがクラウドへのDeployに対応している • 開発⽤のクラウドサービスの充実 • サービス間の連携(Hooks, RESTful API) • クラウドのライフサイクル管理(⾃動化)による運⽤効率化 • Terraform, Ansible, Vagrant, Pulumiなどの活⽤ アプリケーションDeploy環境の変化 • コンテナと”Docker”の登場とアプリの動作環境の変更 • マイクロサービス化 • “Kubernetes”, “Rancher”などの登場 • 「次のリリースとしてのDeploy環境」 : Staging • 現在稼働中の「本番環境」 : Production これらをなるべく同じようなツールを⽤いて、アプリケーションを 開発・運⽤したい è 複数Cloudの併⽤と開発でのインフラ⾃動化(code)
69. vagrant : https://www.vagrantup.com/ 適⽤範囲: 仮想化、クラウドへの開発環境のdeploy plugin: あり、(rubygems) 仮想化VMとしてイメージを配布 起動して、プロビジョニング実⾏ クラウド⽤にはイメージを指定する だけなので、有⽤ デメリット: VM配布なので、ローカルキャッシュ されるまで起動に時間がかかる
70. terraform : https://www.terraform.io/ 適⽤範囲: 仮想化、クラウドへの開発環境のdeploy plugin: あり、(go binary) DSLで記述 主にクラウドプロビジョニング の⾃動化、構成のバージョン管理 クラウド⽤にはイメージを指定する だけなので、有⽤ ConoHaはOpenStack driverが 活⽤できる
71. pulumi : https://www.pulumi.com/ 適⽤範囲: 仮想化、クラウドへの開発環境のdeploy plugin: あり js, pythonでも記述できる よりプログラマブルに使える ConoHaはOpenStack driverが 活⽤できる
72. ansible : https://docs.ansible.com/ 適⽤範囲: 仮想化、クラウドへの開発環境のdeploy plugin: あり pythonで作られ、yaml記述 GTBでハンズオンあり (午後より) ConoHaは OpenStack cloud driverが 活⽤できる
73. ⾃前クラウドの構築 ~ Private Cloudの構築 ~
74. Public Cloud と Private Cloud の運⽤の使い分け Private Cloud環境 • Deploymentするまでのローカル動作環境 • PCのCPU向上、メモリの搭載量の向上、仮想化技術 (HyperVisor)の搭載などにより実現できるようになった • なんらかの変換処理がされるPoint Public Cloud環境 • リソースの読めない「新規性サービス」の⽴ち上げ • Private CloudであふれたリソースをPublicから借りる • Public Cloud + Private Cloudで、運⽤の冗⻑性、継続性を保つ これらをなるべく同じようなツールを⽤いて、アプリケーションを開発・運 ⽤したい
75. OpenStack, CloudStack, AzureStackなどの出現 èPrivate Cloudの構築の敷居が 下がってきた
76. ex) OpenStack構築 : Private cloud構築 : OpenStack microstack • https://microstack.run/ • PC上やサーバにsnapパッケージ(コンテナイメージ)で構築可能 • OpenStackの環境が⼿軽に構築可能 • 複数台構成も可能
77. ex) OpenStack構築 : ubuntu VM簡単起動 インフラ構築も”multipass” を使ってubuntu VMを作成する • https://multipass.run/ • “multipass” コマンドをWindows / Linux / Mac にインストールして Ubuntu VMを構築するツール
78. AzureStack: è Private CloudはHyper-Converged化する Darryl van der Peijl [MVP] Azure Stack - The Fabric Layer (2016/1/5) https://www.linkedin.com/pulse/azure-stack-fabric-layer-darryl-van-der-peijl-mvp-
79. AzureStack AzureのPublic Cloudと全く同じサービスをローカルに構築 • ストレージ、ネットワークの仮想化が内蔵されている • ストレージとコンピューティングノードの同⼀化 è HCI (Hyper-Converged Infrastructure) の実現 • public cloud / private cloudがマルチクラウドとして管理できる
80. Cloud と PC 環境の使い分け PCでの環境 • Deploymentするまでのローカル動作環境 • PCのCPU向上、メモリの搭載量の向上、仮想化技術(HyperVisor)の 搭載などにより実現できるようになった • なんらかの変換処理がされるPoint • Private Cloud on My Laptop(OpenStack, CloudStackを自分のPCで) • Docker cluster development Cloudでの環境 • 「結合テストなどのDeploy環境」 : (Combined)Testing Environment • 「次のリリースとしてのDeploy環境」 : Staging • 現在稼働中の「本番環境」 : Production これらをなるべく同じようなツールを用いて、アプリケーションを開発・運用したい
81. コンテナの活⽤ ~ docker, LXC, Kubernetes ~
82. Container (LXC, etc) (OS, App仮想化) 仮想化の種類と活⽤例 だがしかし、今現在最も注⽬され、発展途上である技術 Google: >> 我々はXen, KVMなどの仮想化技術を⾃社サービスに使って いない。独⾃のコンテナ技術をつかっており、Googleでは全部を コンテナで実⾏している
83. Container (LXC, etc) (OS, App仮想化) 仮想化の種類と活⽤例 >> リソースアクセス(IO, CPU)へのオーバーヘッドが少 >> コンピューティングを効率よく実⾏できる >> Baremetal Server + Container + クラスタ管理
84. Container (LXC, etc) (OS, App仮想化) 仮想化の種類と活⽤例 Docker LXCなどのコンテナ技術を再発明、世代管理やリポジトリ管理など の運⽤にひつような機能を追加 >> Vagrantのあとに出現
85. Container (LXC, etc) (OS, App仮想化) 仮想化の種類と活⽤例 Dockerムーブメント Google, Amazon, Microsoft, … それにあわせて、コンテナ技術の⾒直し、LXC(Linux container)の開発の活性 化、様々な社会変化が起こった Dockerの哲学 • Unix哲学の「⼀つのことをするプログラム」 を「⼀つのアプリケーション」に置換 • Linux Foundationも標準化を推進 : CNCF • https://www.cncf.io/ Cloud Native Computing Foundation
86. Container (LXC, etc) (OS, App仮想化) 仮想化の種類と活⽤例 Microsoft 次期 Hyper-Vでコンテナ技術の投⼊ Dockerでも管理できるようになる >> Docker社と協⼒、 Windows Applicationでのコンテナによる 「ライフサイクル管理」による運⽤
87. Container (LXC, etc) (OS, App仮想化) 仮想化の種類と活⽤例 http://kubernetes.io/ クゥバネィテス と発⾳ èDocker本体にもオーケストレーション機能が含まれる(2016) コンテナによる運⽤の⾃動化を⽬指し、実現してきている ⾃動⾞ベンダー è ⾃動運転のプラットフォームに アプリケーション更新、なども ⾃動運⽤に含めて採⽤
88. Container (LXC, etc) (OS, App仮想化) 仮想化の種類と活⽤例 kubernetes(クゥバネィテス) : k8s IUUQTHJUIVCDPNLVCFSOFUFTLVCFSOFUFT オープンソースにより開発される Azure, AWS, GKE, Privateのk8sは これにより相互運⽤性が保たれている クラウドごとの “CloudProvider Driver” も ここで開発
89. Container (LXC, etc) (OS, App仮想化) 仮想化の種類と活⽤例 LVCFSOFUFT ΫΡόωΟςε
    
    ֤ࣾͷίϯςφࢀೖ ։ൃ؀ڥ
    • NJOJLVCF • LT • NJDSPLVCF • LVCFTQBXO • %PDLFS
    $& • 0,%
    0QFO4IJGU 1SPEVDU
    LT • 0QFO4IJGU 3VOUJNF͸ίϯςφԽ͞Εͨ΋ͷͳ Βͱ֦େ • ίϯςφ 7.
    #BSFNFUBM
90. Container (LXC, etc) (OS, Appの仮想化) 仮想化の種類と活⽤例 PaaS系のコンテナ Heroku(PaaS) https://www.heroku.com/ Cloud Foundry http://cloudfoundry.org/index.html HP Helion Cloud PaaS http://www8.hp.com/us/en/cloud/helion-devplatform-overview.html IBM Bluemix http://www.ibm.com/developerworks/jp/bluemix/ さまざまなクラウドサービスが、コンテナ(or Docker)のキーワードに Dockerを使って、様々なOpenSource(Free soft)でも開発が進むPaaS
91. 4)Rancher (Latest ver. 2.2.4) https://rancher.com/ 2) 仮想化の種類と活⽤例 Docker cluster や kubernetes(クゥバネィテス) を管理、マルチユーザで運⽤
92. CNCF: Rook.io https://rook.io コンテナでも必要とされる、 ストレージの仮想化 Ceph というストレージ(SDS)の 「コンテナによる運⽤性の 付加」と、 「コンテナ環境へのBlock volume, File Server, Object Storageの提供」 ★CNCFがホストしている というのも注⽬
93. CNCF: Rook.io https://rook.io StatefulSet なコンテナに ストレージを提供 DB, KVS, noSQL 冗⻑性と⾃動運⽤
94. Rancher: Project Longhorn Longhorn というのも 内部はiSCSIによる Mirrorストレージの ⽣成のコンテナ運⽤
95. Rancher Longhorn https://github.com/longhorn/longhorn
96. Rancher Longhorn (OpenEBS based) https://github.com/longhorn/longhorn 仮装的なiSCSI disk がMirrorされている (冗⻑性)
97. ストレージの仮想化とSoftware Defined Storage ストレージの仮想化 • ボトルネック(IO gateway)などが存在する • しかし、Hardwareの⾼速化、ネットワークの⾼速化などにより、汎⽤の Hardwareによっても、近年、実⽤的に構築できるようになってきた • 前述の問題が物理的に改善する • これにより、Nutanixなど製品、Windows serverのStorage spacesなど のHyper Converged Infrastructureが注⽬されてきている • DockerなどへのVolume Driverとしても提供されるようになってきた • DockerへのVolumeとしても簡単に検証/利⽤できる • KubernetesへのVolumeとしての利⽤、運⽤
98. 6) さいごに、まとめ
99. 仮想化基礎としてのまとめ #1 1) まずはグループのサービスについて • クラウドインフラとして提供されるサービス 2) 「仮想化」は物理の「抽象化」、抽象化を⽣かしたツールの活⽤がキモ • さまざまなツールによって、仮想的にみせてサービスを構築しよう 3) 「仮想化」は「リソースの有効活⽤」、複数リソースを稼働させてお得に • CPU, Disk, Memory, Networkを有効活⽤でコストDown、うまいOvercommit • 仮想ネットワークでリソース分割とセキュリテイの確保 • リソースのscale upでだめならscale outができるアプリケーション構成づくり • そして、最終的にはマイクロサービスに⾏き着くかもしれない、仕事の負荷分散 にもなるかもね
100. 仮想化基礎としてのまとめ #2 4) 「仮想化」は「冗⻑化」と「負荷分散」のはじまり、安全運⽤できる環境を利⽤しよう • 仮想ストレージは「冗⻑化」によりdiskの有効活⽤ • 仮想IP、LBによる冗⻑化の確保で安⼼確保 5) 「仮想化」と「クラウド化」は「簡単DevOps」の活⽤、Deployに⼯夫しよう • vagrant, terraform, ansible, pulumi など仮想基盤の抽象化を利⽤して環境を構築 しよう • 環境構築は、Desktopとオンプレミス、クラウドの使い分け「抽象化」によりツー ルで素早く構築 • ⾃前クラウド構築も抽象化で構築 • Docker, kubernetes, k3s などコンテナの活⽤
101. 以上です