Japan OpenStack User Gourp at OSC2016

1. クラウド ネイティブアプリケーションとOpenStack
2017/9/1
Tomoaki Nakajima @irix_jp
Akira Yoshiyama @boot_vmlinuz1
OSC2016.Etnerprise

2. 発表者
 中島倫明（Tomoaki Nakajima） @irix_jp
o 日本OpenStackユーザ会 ボードメンバー（初代会長 2013-2015）
o 東京大学 非常勤講師（S1/S2 月曜 2限）
o 国立情報学研究所／TOPSE 講師
o 一般社団法人クラウド利用促進機構 技術アドバイザー
o 連載「@IT OpenStack超入門」
 http://www.atmarkit.co.jp/ait/subtop/features/kwd/openstack.html
2

3. 復習「OpenStackとは」
 インフラ層の抽象化を実現するクラウド基盤ソフトウェア
o 物理・仮想マシン、ストレージ、ネットワークが主な対象
o 実行層の隠蔽、標準化されたAPIの提供
o 一部のPaaS機能の提供
3
仮想サーバ
コントローラ
（Nova）
仮想NW
コントローラ
（Neutron）
仮想ストレージ
コントローラ
（Cinder）
認証/ユーザ管理
（Keystone）
ユーザ・アプリケーション
OpenStack API
OpenStackコントローラ
ドライバ
（OSS/製品）
ドライバ
（OSS/製品）
ドライバ
（OSS/製品）
実行層
管理層
サーバ
仮想化機能
汎用サーバ
仮想
サーバ
仮想
サーバ
ストレージ
仮想化機能
汎用サーバ/
ストレージ製品
ネットワーク
仮想化機能
汎用サーバ/
NW製品
仮想
ルータ
仮想
FW
API/独自インタフェース
（検証された組み合わせを提供）
※簡略化のため主要機能の概略のみ記載
仮想ストレージ
WebUI
（Horizon）
実行層のエコシステム
アプリ層のエコシステム

4. 日本OpenStackユーザ会
 国内のOpenStackの普及活動・人材育成を目的に
2010年に発足
o 運営団体数 26、会員数 約1,650名(2016/5/25時点)
o openstack.jp
4

5. 運営団体
 アセアン・ラボ株式会社
 伊藤忠テクノソリューションズ株式会
社（CTC）
 株式会社インターネットイニシアティ
ブ（IIJ）
 エヌ・ティ・ティ・コミュニケーショ
ンズ株式会社
 NTTソフトウェア株式会社
 株式会社ＮＴＴデータ
 ＮＴＴデータ先端技術株式会社
 沖縄科学技術大学院大学
 仮想化インフラストラクチャ・オペ
レーターズグループ
 Canonical
 一般社団法人クラウド利用促進機構
 クラウディアン株式会社
 クリエーションライン株式会社
5
 GMOインターネット株式会社
 大学共同利用機関法人 情報・システム
研究機構 国立情報学研究所
 デル株式会社
 日本電気株式会社（NEC）
 日本電信電話株式会社(NTT)
 株式会社日立製作所
 日本ヒューレット・パッカード株式会
社
 ビットアイル・エクイニクス株式会社
 富士通株式会社
 ミドクラジャパン株式会社
 ミランティス・ジャパン合同会社
 レッドハット株式会社
 KDDI株式会社

6. ユーザー会メンバー数の推移
 毎月メンバーが増えています！
6

7. 活動内容
 主な活動
o メーリングリストでの情報交換
o イベント開催・出展、勉強会・セミナーの開催
o トレーニング、ハンズオンの実施
o 国際化（マニュアル翻訳、UI日本語化）
7

8. 直近のイベント予定
 2016年9月13日 第29回 QA
 2016年9月7日 第30回 入門
 2016年10月 第31回 基礎ハンズオン
 2016年11-12月 第32回 基本機能の整理
 2017年1-2月 第33回 周辺機能の紹介
 2017年3月 第34回 ログ・監視運用
8

9. 参加してみましょう！
9

10. 最近の話題
10

11. 利用 → 最適化 → 常態化
 クラウドの浸透
11https://www.youtube.com/watch?v=d1n4qf1bN7g

12. 次のステップへ
 OpenStackが登場して6年。
o 様々な分野で活用が進んできた一方で、多くの失敗
例も生まれた。
 試行錯誤のから生まれた気づき
o "OpenStack のプライベート クラウドのメリット
を得る為には、APシステム開発・運用の文化を変え
なければならない"
o 単に稼働する場所をクラウドへ移行したら魔法のよ
うにメリット（コスト削減や効率化）が成し遂げら
れるわけではない。
12

13. 重要なのは「プロセス」の最適化
 単純な技術の活用ではなく、プロセス（やり方・進め方」の最適化なく
して、大きな効果は望めない。
 アプリケーション導入プロセスの効率化の例
13https://www.youtube.com/watch?v=d1n4qf1bN7g
OpenStack導入前 導入後 プロセス改革後

14. ツールチェーンを効果させるための"環境作り"が重要
 素晴らしいツールチェーンも、それを取り組まく環境
が整っていなければ効果が出ない。
14
環境の作成要求
チケット発行
Notebook
実行
Job実行
プレイブックノートブック
Playbook
実行
環境の構築
テスト
結果の保存
結果の確認
チケットクローズ
環境の利用

15. 技術の活用ではなく、企業文化の変革という視点
 文化を構成する「人」を如何に変えるか？
o 今までの「やり方」を変える。
o 今までの業務ルール・プロセスを変える。
o 新しいスキルを浸透させる。
15https://www.youtube.com/watch?v=d1n4qf1bN7g

16. クラウドネイティブ
16

17. クラウドネイティブとは？
 定義は様々
o クラウド上で動作するのが「当たり前」という思想で開発され
たアプリケーション。
o クラウド特性（メリット・デメリット）を考慮したシステム。
o クラウド上に「インストール」して利用する。
o 概念としての「サーバレス」など
17
クラウド以前の時代に開発された
アプリケーション
openstack
様々な外部ツール
VM VM VM
openstack
VM VM VM
クラウドネイティブアプリケーション
APP APP APPAPP APP APP
クラウド以前のアプリケーションは、クラウ
ドが持つ命令系統を知らないため、外
部ツールを介した間接的な連携を行う。
クラウドが持つ命令系統を理解し、直接
的に連携を行う。

18. クラウドネイティブのイメージ（想像図）
 現在のアプリケーションとの対比
18
ハードウェア
（CPU, MEM, NIC）
カーネル(Linux等)
ドライバ
システムコール
ハードウェア
（サーバー、ネットワーク、ストレージ）
OpenStack
ドライバ
OpenStack API
クラウドエコシステムアプリケーションエコシステム
実
資
源
層
資
源
管
理
層
ユ
ー
ザ
層 ライブラリライブラリ

19. 実装例
 Real Application Centric Kernel
o OpenStackのAPIを変換して、アプリケーションセ
ントリックに利用できるようにしたソフトウェア。
o アプリケーション開発者がクラウドを意識すること
なくプログラミング可能となります。
o オープンソースとして公開中
 https://github.com/openstack/rack
19
API
Expansion
&
Additional
Data Structure
VM
app
VM
app
VM
app
RACKApplication
APIs
for
Operating
Infrastructures
APIs
for
Developing
Applications
https://wiki.openstack.org/wiki/RACK/ja

20. RACKの動作例
 Linux/UNIX上のマルチプロセス・マルチス
レッドモデルを参考デザイン
 クラウド（OpenStack）上で、この動作を模
倣し、VMを「実行すると何かの仕事をするプ
ロセス」のように振る舞わせることができる。
20
option1
option2
launch(exec)
option3
options
libraries
source compile
httpd
executable
binary
Linux
processprocessprocess
forkfork
options
ライブラリ
プログラム compile
psコマンド
OS
middleware
libraries
source
表示内容
表示範囲
出力形式
option1
option2
option3
launch(exec)
openstack
shared memory/pipe
signal
filesystem
process process
VM
Template
executable
binary
process
forkfork
従来型アプリケーションのモデル クラウドネイティブアプリケーション

21. クラウドネイティブへの道
 クラウドネイティブへ到達するには時間がかかります。
o 技術力が高い組織では成し遂げている例もあり。
o 一般に広がるにはエコシステムの充実が不可欠。
 まずは「最適化」の実現から始めていきましょう。
o Infrastructure as a Code
 ITの現場から「不確定」な要素を取り除き、品質向上と結果としてのコスト削減を実
現する。
 人為的ミス（見間違え、入力ミス、やったつもり、対象間違えなど）の防止
 確実な再発防止
 単純リソースの提供ではなく、「機能」を提供していくためにも有効。
 開発チームが使いやすい、手間の少ない環境を提供
 単純リソースの提供がしたいならパブリッククラウドでほとんどのケースは十分。
 「機能」を提供することでプライベートクラウドの意味が出てくる。
o そして、これらを活かすプロセスの変革
 そのために活用できるOpenStackの機能を紹介していきます。
21

22. 最適化をサポートする
OpenStackの機能
22

23. よく使われる機能 → でも、これだけじゃないよ
23
以下のコンポーネントだけで構成されていませんか？
ポータル
（Horizon）
IaaS
（Nova）
SDN管理
（Neutron）
VMテンプレート管理
（Glance）
ボリューム
ストレージ管理
（Cinder）
ユーザ・テナント
管理
（Keystone）
最低限のIaaS機能のみ。
VMware基盤の更改案件に多い。
⇒IaaSユーザ側の導入メリットが
ほぼ無く、失敗事例化しやすい。

24. アベイラビリティゾーン（Nova/Cinder）
24
アベイラビリティ・ゾーン
２
アベイラビリティ・ゾーン
１
物理サーバ
物理サーバ
VM VM
※アベイラビリティ＝可用性
物理サーバ
物理サーバ
物理サーバ
物理サーバ
場合によっては、
①１つの物理サーバ上に同じプログラムを
実行するVMが集中し、
②その物理サーバや、関連するストレージ・NW機
器がダウンする事もありうる
ストレージ
NW機器
IaaSユーザが意図的にVMの配置先
ゾーンを変える事で問題を回避する
物理サーバ
VM VM
物理サーバ
物理サーバ
物理サーバ
物理サーバ
物理サーバ
ストレージ
NW機器
ストレージ
NW機器

25. LBaaS （Neutronの一機能）
25
HAクラスタ（Act-Stby）
LB VM#1 LB VM#2
IaaSユーザが自分でLBを用意するのは面倒
①HA化をする必要がある
②スケールアウト／イン時の設定変更が面倒
③VM上のLBを使うしかない
リクエスト
LB
OpenStack の LBaaS 機能を用いれば
①HA化はクラウド基盤が責任を持つ
②スケールアウト／イン時の設定変更も簡単
③商用LB（仮想・物理）が使える
リクエスト
REST API
LBaaS

26. DNSaaS（Designate）
26
LB
DNS の登録が手作業だと
APデプロイ～テスト～サービスイン
の過程をスピードアップ出来ない
リクエスト
DNS登録は
手作業
LB
DNSaaS を利用して、以下を自動化できる
①新規APデプロイ／AP更新／AP廃止時の
DNSエントリ操作
②DNSラウンドロビン使用時、スケールアウト／
イン時のDNSエントリ操作
リクエスト
DNSaaSDNS
REST API

27. オーケストレーション（Heat）
IaaS
LB
リクエスト DNSaaS
名前解決
指示
指示
指示
IaaS
LB
リクエスト DNSaaS
名前解決
オーケストレー
ション
指示
手作業で指示を出しながらの構築では、
分散システムであるMSA APシステムの
デプロイに非常に手間がかかる
オーケストレーション機能で、以下を自動化できる
①各種クラウドリソースのデプロイ
②VM上のAP等の設定
LBaaSLBaaS
27

28. MONaaS,オートスケール（Ceilometer/Monasca/Aodh/Senlin)
IaaS
LB
リクエスト
手作業によるスケールアウト／インでは、
①負荷の急増に迅速に対応できず
②運用コストもかかる
オーケストレー
ション
指示
監視
IaaS
LB
リクエスト
オーケストレー
ション
監視
オート スケーラを用いる事で、定義された
ポリシーに従って、負荷に応じた仮想リソース
の増減を自動的に行う
オート
スケーラ
指示
28

29. DBaaS、MQaaS（Trove、Zaqar/Que）
IaaS
MSA で多用されるメッセージキューや
DBのデプロイと運用もそれぞれ知識を
必要とし、面倒
IaaS
メッセージ
キュー
DB
MQaaS
DBaaS
Web/
REST API
遅延処理A
遅延処理B
定時処理A
定時処理B
MQaaSでメッセージキューを、
DBaaSでDBを自動デプロイ・運用する事で、
AP全体の自動デプロイ・運用を簡素化
29

30. 様々な機能を利用して最適化を実現
 運用系サービス、ミドルウェア系サービスを充実
 周辺ソフトと組み合わせたツールチェーンへ
30
ポータル
（Horizon）
MONaaS
（Ceilometer／
Monasca／Aodh）
オートスケーラ
（Senlin）
オーケストレーション
（Heat）
DNSaaS
（Designate）
LBaaS
（Neutron）
IaaS
（Nova）
SDN管理
（Neutron）
VMテンプレート管理
（Glance）
ボリューム
ストレージ管理
（Cinder）
DBaaS
（Trove）
MQaaS
（Zaqar／Que）
メータリング
（Ceilometer）
ユーザ・テナント管理
（Keystone）

31. まとめ
31

32. まとめ
 利用 → 最適化 → 常態化(Cloud Native)
 クラウドネイティブな世界の実現はもう少し先
o 様々な定義、実現方法によるエコシステムが必要
 まずはクラウドへの最適化から
o Infrastructure as a Code
 OpenStackの基本機能以外の活用
 ツールチェーンによる単純リソース以外の提供
o プロセスの改善
 「人」「文化」の変革を。
32

33. 33
ご静聴ありがとうございました