Cloud Computing から
Cloud Native への潮流
さくらインターネット株式会社
クラウド事業本部
前佛雅人 @zembutsu
2021年10月25日

https://docs.docker.jp/

ZEMBUTSU Masahito

前佛 雅人@zembutsu@zembutsu_works

zembutsu

さくらインターネット株式会社 クラウド事業本部
Technology Evangelist / Developer Advocate⚫ ホスティング・ISP事業者のサポートおよび保守としてキャリアをスタート⚫ 興味範囲：運用監視、自動化、オープンソース関連技術の調査・翻訳、プログラミング教育⚫ 最近の趣味：ランニング、料理
私は何をしたいの？：情報処理技術者ではない普通の人が、当たり前に計算資源を活用し、豊かな生活を育めるように支援する

本日のテーマ

Cloud Computing から
Cloud Native への潮流
⚫ 日本における「Cloud Computing」認知から10年、改めてクラウドを問う• ビジネスチャンス先行のための手段 （例：コロナ禍で強いられるクラウド対応）⚫ 「Cloud Native」導入には、しかるべき道順(Trail)がある• スケール可能なサービス※実現に、コンテナ化 → CI/CD → オーケストレーション※広義の”サービスとしてのソフトウェア”⚫ 「Docker」 や 「コンテナ」 とは？ & Hacobune(β) ご紹介

3

Cloud Computing

4

クラウド

クラウド

移行

ネイティブ

Cloud Migration

Cloud Native⚫ データセンタが提供するインフラサービスは、物理サーバから仮想化、そしてクラウドコンピューティングへと変わりつつあります。
⚫ 近年は新しい要素としてコンテナ技術が注目を集めています。

5

6

The Big Switch: Rewriting the world, From Edition to Google• 20世紀の「電力会社」のように、インターネットを通したクラウドコンピューティング• Nicholas G. Carr
• 2008年1月発売（邦訳10月発売)
• 翔泳社

7

電力会社（20世紀初頭）の例え
巨大電力ネットワーク
ELECTRIC GRID

クラウド
コンピューティング
COMPUTING GRID

• 発電設備• 送電設備• 保守• サーバ設備(計算)• ネットワーク設備• 保守• 電力網を通した家電の普及・利用• 豊かな生活• スマートフォンを通したアプリやサービスの普及・利用• 豊かな生活10

クラウドは特別な存在ではなくなった• 個々のマシンやデータセンタ上のサーバにデータを持ち、システムを動かす時代の終焉を予測• ただし、１つのマシン（One Machine）に集約されるのではなく、分散した

http://www.roughtype.com/?p=8314

11仮想化からクラウド・ネイティブへ
From Virtualization to Cloud Native• クラウド・ネイティブ・コンピューティングはオープンソースのソフトウェアを積み重ね、次のために用います：
アプリケーションをマイクロサービス(microservices)に分割し、– 各パーツ自身をコンテナにパッケージし、– リソース利用を最適化するために、動的に統合 /オーケストレート(orchestrate)する
–

12

非仮想化
ハードウェア

仮想化

IaaS

2000

2001

2006

© 2018 Cloud Native Computing Foundation

PaaS

オープンソース
IaaS

オープンソース
PaaS

コンテナ

クラウドネイティブ

2009

2010

2011

20132015※ https://github.com/cncf/presentations からの引用

“ペット vs 家畜”

Architectures for open and scalable clouds
http://www.slideshare.net/randybias/architectures-for-open-and-scalable-clouds

13

Cloud Native Computing Foundation (CNCF)
ベンダロックイン無くクラウドを移動できるようにオープンソースのソフトウェアを積み重ねて：⚫ コンテナ化
2015年設立

プロジェクトを支援

アプリケーションやプロセス等の各パートをコンテナ内にパッケージ化し、再利用性、透明性、、リソースを分離⚫ 動的なオーケストレーション
コンテナを活発にスケジュールし、リソース利用率の最適化を管理
2000年設立。Linuxを中心としたオープンソースのエコシステムを築くため、コンピュータ業界を中心に自動車業界など、50以上のサブプロジェクトを持つ。
幅広く業界との調整や標準化のために努める非営利団体。
【参考】 CNCF About https://www.cncf.io/about/faq/⚫ マイクロサービス指向
アプリケーションをマイクロサービスに分割し、全体的な敏捷性(agility)とメンテナンス性を極めて向上

14

TRAILMAP
コンテナやマイクロサービスのようなクラウドネイティブ技術は、組織が開発とデプロイをスケーラブルに、アジャイル・アプリケーションとサービスを動的に、かつ分散環境で行えるようになります。 これらの特長の考慮した設計のシステムであれば、回復力のある（resilient）、弾力的（elastic）で、疎結合（loosely coupled）となり、管理可能な抽象化と宣言型の API を通すので、つまり、効率的で信頼性のある自動化をもたらすのです。これにより、エンジニアはアプリケーションを監視できたり、影響の大きな変更も簡単に行えたりします。そしてプロセスとワークフローは結果的に、これらの環境を最大限に活かし、苦痛を最小化するのです。
https://github.com/cncf/trailmap

15

16

1. コンテナ化• 一般的にDocker コンテナを使う。
• あらゆる大きさのアプリケーションと依存関係を（エミュレータ上で実行する PDP-11 のコードですら）コンテナ化できる。

• 時間がたてば、適切なアプリケーションの分割を求めるようになり、次世代の機能をマイクロサービスとして書くでしょう。

17

開発
環境

サービスを提供したい
アプリを動かしたい

コンテナ

開発

テスト
環境

準備
環境

本番
環境

課題

都度、環境構築課題

異なるOS環境

課題

都度、プロビジョニング

課題

時間がかかる

課題

テスト

準備

課題

遅い動かない課題

面倒

本番

18

どちらも「中身」を気にせず輸送・移動できる

Docker
コンテナ

アプリ

積み荷

Docker
イメージ

コンテナ
輸送手段

物流コンテナの輸送

アプリケーションをDockerイメージで移動しDockerコンテナとして実行

19

Docker≠コンテナ型仮想化• アプリケーション・コンテナ• システム・コンテナ（コンテナ型仮想化）

https://www.docker.com/resources/what-container

20

2. CI/CD• 継続的インテグレーション/継続的デリバリ(CI/CD)をセットアップすると、ソースコードに対する変更の結果、自動的に新しいコンテナが構築、テストされ、定期的にテスト環境に展開するだけでなく、本番環境にすら展開する。
• ロールアウト、ロールバック、テストを自動的に行うようセットアップする。

21

高品質で持続的な開発・運用を行うため CI / CD
• コンテナ化

22

Continuous Integration / Continuous Delivery• Docker ... アプリケーションを開発・移動・実行するプラットフォーム• Kubernetes ... アプリケーションをデプロイ、スケーリング、管理をする• バージョン管理• Git ... ソースコードの変更履歴を記録・追跡するバージョン管理システム• GitHub ... 内部に git を使う、GUI のソフトウェア開発プラットフォーム• テスト自動化• Jenkins ... ソフトウェアのビルド、検証、インストールなどを自動化できるツール

3. オーケストレーション• Kubernetes は業界トップのオーケストレーション・ソリューションです。
• 認証 Kubernetes ディストリビューション、対応（Hosted）プラットフォーム、インストーラーから選択すべきです。

23

Cloud Native 参照アーキテクチャ

24

Application Definition / Development

マイクロサービス・パターン

Orchestration & Management

分散オーケストレーションと管理

RuntimeProvisioning

コンテナ化

Networking
ComputeStorage

インフラ※ CNCFプロジェクトが定義する範囲外【参考】 https://github.com/cncf/presentations/blob/master/2016-software-circus/what-is-cloud-native/what-is-cloud-native.pdf

Orchestration

設定ファイルをベースにサービスを定義・維持((計算資源の抽象化)

Scheduling••••• Kubernetes• Docker Engine(swarm mode)+ Docker Compose• Rancher• Nomad

複数のホスト・システム上を横断するアプリケーションをスケール（拡大・縮小）できる機能※コンテナに依存しない

Marathon, chronos
Docker swarm
Deisfleet

Cluster Management• Apache Mesos• DCOS (Mesosphere)25従来のオーケストレーション

クラスタ一方通行【参考】 https://www.slideshare.net/Docker/container-orchestration-from-theory-to-practice/726

宣言型サービス・モデルのオーケストレーションDeclarative service model27

D = 期待状態

O = オーケストレータ
並列遅延D

O

S = 状態Δ = 状態から期待状態への収束

SΔクラスタ⚫ レプリカ作成⚫ グローバル・サービス
変更可能

フィードバック【参考】 https://www.slideshare.net/Docker/container-orchestration-from-theory-to-practice/7

大切なのは目的達成のための順番

コンテナ化

CI/CD

28

オーケスト
レーション

システムの柔軟性が高まる一方、開発・運用の変化を迫られる。
必要があれば、手法だけでなく、人や組織（文化）も変える必要がある。

ここまでのポイント 『手段としてのコンテナ活用』

30⚫ クラウドコンピューティングの振り返り
1つの巨大なコンピュータに集約される予測（「クラウド化する世界」）は外れ、世界各地のデータセンタやスマートフォンに至るまで処理が分散し、生活に密着した。

⚫ Dockerコンテナ登場から、Kubernetesオーケストレーションに至る経緯
クラウドネイティブに至る流れは、物理→仮想化→クラウドの延長線だが、技術は別。
活用には、CNCFのCloud Native Trail Map にあるように、システムの「コンテナ化」→「CI/CD」→「オーケストレーション」の順番が大事。

⚫ 「コンテナ」とは何か？ システムを作る場合の考慮点
Linuxカーネルの名前空間・cgroupの分離技術を使って、素早い開発・運用を可能に。
仮想化ではない。そのまま移行は無理。スケール可能なシステムへの対応が必要。
近年は、技術要素よりも、開発文化がネックになりつつある。

システム基盤も、サービス側も変わり続ける前提
STATIC

静的
安定性
信頼性

31

DYNAMIC

スケーラブル

agile

より速く

12 Factor
App
DevOps

柔軟に

動的
現在の課題
かつ、安定性
信頼性

Microservices

SRE

コストと速さ・柔軟さが釣り合わない
ハードウェアとソフトウェアを所有する時代

物理サーバ

仮想化技術

⚫ メインフレーム⚫ ワークステーション⚫ 携帯電話⚫ パーソナルコンピュータ

釣り合う

開発者のみならずエンドユーザもサービスとしての計算資源を利用する時代

クラウドコンピューティング⚫ タブレット端末

クラウドネイティブ⚫ スマートフォンちなみに： Cloud Computing / COVID-19• 今すぐシステムが必要な場面• 大規模アクセスが予想されるため、アプリケーションはスケール前提

32

コンテナ / Docker

33仮想化からクラウド・ネイティブへ
From Virtualization to Cloud Native• クラウド・ネイティブ・コンピューティングはオープンソースのソフトウェアを積み重ね、次のために用います：
アプリケーションをマイクロサービス(microservices)に分割し、– 各パーツ自身をコンテナにパッケージし、– リソース利用を最適化するために、動的に統合/オーケストレート(orchestrate)する
–

34

非仮想化
ハードウェア

仮想化

IaaS

2000

2001

2006

© 2018 Cloud Native Computing Foundation

PaaS

オープンソース
IaaS

オープンソース
PaaS

コンテナ

クラウドネイティブ

2009

2010

2011

2013

2015

※ https://github.com/cncf/presentations からの引用

Build, Ship(Share), Run

The future of Linux Containers - YouTube
https://www.youtube.com/watch?v=wW9CAH9nSLs35

Docker
コンテナ

アプリ

積み荷

Docker
イメージ

コンテナ
輸送手段

物流コンテナの輸送

アプリケーションをDockerイメージで移動しDockerコンテナとして実行

36

DockerDockerイメージとして全ての依存関係をパッケージ化して、コンテナとして動かすLinuxファイルシステムを“Docker allows you to package an application
with all of its dependencies into a standardized
unit for software development.”
www.docker.com 37

BUILD（構築）SHARE（共有）

RUN（実行）

Dockerイメージの公開レジストリ

Docker Hub

ソースコードdocker image push(docker push)

バイナリ

Dockerイメージ送信
設定ファイルライブラリ

docker image pull(docker pull)
Dockerイメージ取得

Dockerコンテナ

実行

Dockerイメージ構築

docker container run

docker image build(docker build)
アプリケーションに必要なすべてをDockerイメージに集約

Dockerイメージの共有や自動構築、コラボレーションのための場所(docker run)DockerイメージのアプリケーションをDockerコンテナ内で実行

38

Dockerコンテナ
Dockerイメージ
docker push

dockerCLI

Docker API

DockerEngineサーバ

クライアントDockerHub

docker pull

制御

DockerDesktop

Linux
カーネル

namespaces

ctoups39

ではなく× docker～.img
Dockerイメージは「１つのファイル」ではなく「概念」。抽象的なイメージ・レイヤの積み重ね40Dockerイメージはイメージ・レイヤの積み重ね
利用者からは１つに見える

利用者からは１つに見える

親子
関係

派生も共有

プログラムやライブラリとメタ情報（実行するプログラムやポートなど）

だから高速に移動できる・開発を高速化できるリソースを有効に使える “lightweight” な性質41Dockerコンテナもイメージ・レイヤを持つ
利用者からは１つに見える

元のレイヤに対する変更情報を記録
Copy on Write の性質

利用者からは１つに見えるだから高速に移動できる・開発を高速化できるリソースを有効に使える “lightweight” な性質

42

コンテナは特別なプロセスの状態
コンテナA

名前空間の isolate

コンテナB

・プロセス
・ファイルシステム・ネットワーク
・ホスト名
・UID・GID・プロセス間通信、等

ruby
PID 1

httpd
PID 1

chris.rb
PID 2

プロセスB

プロセスA

cgroupでリソース制限
・CPU
・メモリ
・I/O
・ディスク・クォータ、等///etc/bin(/data/ubuntu/etc)(/data/ubuntu/bin)

コンテナAのファイルシステム…

/etc/bin(/data/centos/etc)(/data/centos/bin)

コンテナBのファイルシステム…

43

Linux上のPID空間

init (PID 1)
PID 1

コンテナ専用のPID名前空間

PID名前空間の分離/

Linux上のファイルシステム//bin
MNT名前空間の分離/opt

コンテナ専用用のファイルシステム

Dockerコンテナは複数の名前空間が制限されホスト上にあるものの、自分の名前空間しか見えない

Dockerコンテナは「特別な状態」のプロセス

44

45

CentOS 8 の公式イメージを使った Dockerfile 例Dockerfile

FROM centos:8
RUN dnf -y install httpd php
ADD https://raw.githubusercontent.com/dockerlibrary/httpd/077141ee37fca63972292c562ec0f632d0f831b1/2.4/httpd-foreground/usr/local/bin/
RUN chmod 700 /usr/local/bin/httpd-foreground
RUN sed -i -e 's%^#LoadModule mpm_prefork_module
modules/mod_mpm_prefork.so%LoadModule mpm_prefork_module
modules/mod_mpm_prefork.so%' /etc/httpd/conf.modules.d/00-mpm.conf
RUN sed -i -e 's%^LoadModule mpm_event_module
modules/mod_mpm_event.so%#LoadModule mpm_event_module
modules/mod_mpm_event.so%' /etc/httpd/conf.modules.d/00-mpm.conf
EXPOSE 80
COPY ./html/* /var/www/html
CMD ["httpd-foreground"]46

PHP7 の公式イメージを使った Dockerfile 例
Dockerfile

FROM php:7.2-apache
COPY ./html/* /var/www/html

47

CentOS 6 の公式イメージを使った Dockerfile 例
Dockerfile

FROM centos:centos6.10
RUN sed -i'/^mirrorlist/s/^/#/;/^#baseurl/{s/#//;s/mirror.centos.org¥/centos¥/$releas
ever/vault.centos.org¥/6.10/}' /etc/yum.repos.d/*B* && ¥yum install -y epel-release && ¥yum update -y && ¥cp -f /usr/share/zoneinfo/Japan /etc/localtime
RUN yum -y install php httpd
EXPOSE 80
RUN echo '<?php phpinfo(); ?>' > /var/www/html/index.php
ADD https://raw.githubusercontent.com/dockerlibrary/httpd/077141ee37fca63972292c562ec0f632d0f831b1/2.4/httpd-foreground/usr/local/bin/
RUN chmod 700 /usr/local/bin/httpd-foreground
CMD ["httpd-foreground"]48

PHP5 の公式イメージを使った Dockerfile 例
Dockerfile

FROM php:5.6-apache
COPY ./html/* /var/www/html

49

Docker 化にあたっての注意点• 【最重要】 Docker は「仮想化技術」ではありません• 「アプリケーション・コンテナ」と「システム・コンテナ」は考え方が違う• 稼働中の環境を、丸っと移行は無理• 例：initがない• 例：セキュリティ対策や日々の運用をどうするか• 既存環境をコンテナ移行ではなく、環境再構築検証の用途に• 従来の手順書で再現ができるかどうか• なければこの機会に手順化• CloudNative 的な技術習得やチャレンジの機会に• いきなり未知のものをコンテナ化して取り組むより、よく知っているもののほうが移行しやすい• ただし、コンテナ活用の用途は「アプリケーション・コンテナ」に限るべきであり、無理矢理すべてを「そのまま」コンテナ化すべきという話ではない

50

“Dockerは銀の弾丸ではない”
ハードウェアの• 前提として、Dockerは（いわゆる）「仮想化技術」とは異なる思想・技術背景• 「コンテナ型仮想化」として表現・比較されるが [要出典]• セキュリティ要件によっては、コンテナの利用より仮想化技術を選択すべき• （特性を理解した上で）有用な場面もある• 技術（再）検証や手順の（再）作成• デプロイを素早く行いたい• バッチ的な処理• どうしても使わざるを得ない場合は• Docker の基本概念を理解した上で利用する• 丸ごと移植ではなく、移行のための一時措置• 最新の公式ドキュメントが常に正しい

アプリケーションの“Build, Share, Run” を素早く簡単に

51

Lab Products

Hacobune (β)

52さくらインターネット株式会社
VPS

レンタルサーバ

クラウド

専用サーバ

さくらのレンタルサーバ
さくらのマネージドサーバ

さくらのVPS

1台のサーバを複数の契約者でサーバを共有または占有することができ、管理はさくらインターネットに任せて使うサービス

仮想化技術を用い、1台の物
理サーバ上に複数の仮想サーバを構築し、仮想専用サーバとして分けた領域の占有サービス

1台を共有

1台を占有

高性能サーバと拡張性の高いネットワークを圧倒的なコストパフォーマンスで利用できるIaaS型パブリック・クラウド・サービス

データセンター

新サービス

ハウジング

日本発のオープン＆フリーなデータプラットフォームです。衛星から取得出来る情報を含め、世界中のあらゆるデータを集積

さくらの専用サーバ

リモートハウジング

高性能で拡張性と信頼性の高いサーバをまるごと独占して利用することができ、自由にカスタマイズして利用可能なサービス

データセンター内にお客様専用のハウジングスペースを確保し、ネットワーク機器やサーバなどの機 材 を 自 由 に 置 け る サ ー ビス

1台～複数台www.tellusxdp.com/

通信環境とデータの保存や処理システムを一体型で提供する
IoTプラットフォーム・サービス

https://iot.sakura.ad.jp/

サービスの主な利用用途
ウェブサイト運営、ブログ、インターネット・メール
エンタープライズ
ネットビジネス、電子商取引、動画・音楽配信、開発環境
会員制サイト、キャンペーン・サイト
SNS、ウェブ・アプリケーション、SaaS、ASP

https://www.sakura.ad.jp

高火力コンピューティング
https://www.sakura.ad.jp/
koukaryoku/

さくらインターネット株式会社

ISHIKARI

石狩
データセンター・専用サーバ

東京ドーム約1個分の敷地面積（51,448㎡）
札幌から車で20～30分とアクセスも容易さくらのクラウドのコンセプト
開発者志向のシンプルなクラウド
IaaS クラウド（サービスとしてのインフラ）基盤を、圧倒的なコストパフォーマンスで提供

高い自由度
高性能サーバーをスケールアウト
ネットワークも物理環境のように自由に設計・実装できるブラウザで仮想データセンターを操作「サーバ」という概念を大切にしたい

https://cloud.sakura.ad.jp/

56基本用語と解説
ハイブリッド接続対応

さくらのクラウド

専用サーバ・ハウジング
リモートハウジング

リージョン

リージョン

データセンタさくらのクラウドにおける、データセンターの地理的な単位です。
石狩リージョン（北海道）または東京リージョンを選択できます。

複数のリージョンを利用可能地理的な単位です。専用サーバは石狩(北海道)・東京、ハウジングは東新宿・西新宿・代官山です。

ゾーン

ゾーン

リージョン内にあるネットワーク管理単位であり、 各ゾーンは物理的に独立ゾーン しています。石狩第1ゾーン、石狩第2ゾーン、東京第1ゾーンを選択できます。
専用セグメント

ネットワーク単位でグローバルIPアドレスが付与

共有セグメント

１つのグローバルIP
アドレスが付与

共有セグメント

専用グローバルネットワーク

共有ネットワーク

ルータ＋スイッチ
パケットフィルタ

サーバ

スイッチ

IPアドレス(/28 - /24)
グローバルに接続しない

サーバ サーバも設定可能

ローカルネットワーク

サーバ

サーバ

サーバ

スイッチ

ローカルネットワーク

イッチ

スイッチ

オンデマンドで異なるゾーン間やサービス間をローカルネットワーク(L2)で接続

ブリッジ接続異なるゾーン間やサービス間をローカルネットワーク(L2)で接続。
ブリッジ接続よりも接続可能なサービスが多い。要申請。

57

58

SaaS
PaaS Hacobune
2021 88 27|
https://www.sakura.ad.jp/information/announcements/2021/08/12/1968207782/12

Hacobune (β)

59• 『 小さなチームで始めるサービス開発のためのWeb アプリケーションプラットフォーム 』⚫ 高速にサービス開発からリリースまでのサイクルをまわす仕組みを提供⚫ インフラ構築や運用から開発者を解放
課題例：・ クラウド上にスケール可能なアプリケーションを、高速に開発するには？

https://manual.c1.hacobuneapp.com/docs

Hacobune(β)が提供する機能

60• アプリケーションのデプロイ• 作成元は、Docker イメージ、プライベートレジストリ、GitHub リポジトリから選択• Web UI からログの参照やモニタリング、再起動など操作可能• 公開先は https://<名前>.c1.hacobuneapp.com/ （BASIC認証も追加可能）• ヘルスチェックやオートスケール機能

スケーラブルな HTTPS エンドポイント• データのボリューム（永続化）を提供• 付加機能• アドオン ( MySQL, Redis )• ジョブ機能 ( cron的な概念 )• コンテナレジストリ

Hacobune
プロジェクト
ボリューム

基盤

プロジェクト

レジストリ

アドオン

今後のロードマップ

61

振り返り

62

仮想化からクラウド・ネイティブへ
From Virtualization to Cloud Native• クラウド・ネイティブ・コンピューティングはオープンソースのソフトウェアを積み重ね、次のために用います：
アプリケーションをマイクロサービス(microservices)に分割し、– 各パーツ自身をコンテナにパッケージし、– リソース利用を最適化するために、動的に統合/オーケストレート(orchestrate)する
–

63

非仮想化
ハードウェア仮想化

IaaS

2000

2001

2006

© 2018 Cloud Native Computing Foundation

PaaS

オープンソース
IaaS

オープンソース
PaaS

コンテナ

クラウドネイティブ

2009

2010

2011

2013

2015

※ https://github.com/cncf/presentations からの引用

ここまでのポイント 『手段としてのコンテナ活用』

64⚫ クラウドコンピューティングの振り返り
1つの巨大なコンピュータに集約される予測（「クラウド化する世界」）は外れ、世界各地のデータセンタやスマートフォンに至るまで処理が分散し、生活に密着した。

⚫ Dockerコンテナ登場から、Kubernetesオーケストレーションに至る経緯
クラウドネイティブに至る流れは、物理→仮想化→クラウドの延長線だが、技術は別。
活用には、CNCFのCloud Native Trail Map にあるように、システムの「コンテナ化」→「CI/CD」→「オーケストレーション」の順番が大事。

⚫ 「コンテナ」とは何か？ システムを作る場合の考慮点
Linuxカーネルの名前空間・cgroupの分離技術を使って、素早い開発・運用を可能に。
仮想化ではない。そのまま移行は無理。スケール可能なシステムへの対応が必要。
近年は、技術要素よりも、開発文化がネックになりつつある。

ありがとうございました。
facebook.com/zembutsu

m-zembutsu@sakura.ad.jp

65