実用段階に入ったOpenStack~ もうすぐ絶滅するというPrivate Cloudの多様性について ~

Jan/26/2015

Kentaro Sasaki

Global Operations Department, Rakuten, Inc.

2

Presenter

佐々木 健太郎

所属:

• System Engineer@Rakuten

担当分野:

• OpenStack

• 分散ストレージ

3

http://goo.gl/3Qitfy

この発表について

• OpenStack導入論拠 ~ なぜCloudが必要なのか

• OpenStack開発に至る道のり

• OpenStackの功罪、そして心得

• Private Cloudの先にあるもの

4

OpenStack導入論拠

5

OpenStack以前

We’re aiming to be aNo.1 Private Cloudin the world.

RakutenInfrastructureasaService

6

楽天スーパーSALEリソースの”短期納品”とピーク負荷を捌くための”VM大量確保”

7

仮想環境へのシフトN

um

ber

of

Serv

ers

Physical RIaaS 1.0 RIaaS 2.0

物理環境

仮想環境

8

RIaaSによる効果

コストとOPEXの削減$

高集約によるサーバ単価の削減

ラック数・スイッチ数を1/30に

デリバリータイムを数週間から数10分に

RIaaSの先にある目的

9

Platform-nization

10

• 非Infra依存のアプリ設計

• REST APIによる管理運用

• セルフサービスによる提供

http://goo.gl/3LvhNF

Platform化

Free(自由)なSWが重要

11

• オープンソース活用

• 製品EOSLからの開放とライフサイクル

• サポートに頼らないマインドの改革

土台となるOpen Source

Open Cloudの採用

12

Open Cloudの候補

パブリック プライベート

オープンソース

プロプライエタリ

Amazon Web Service

Microsoft Azure

Google Cloud Platform

VMware

OpenStack

CloudStack

Eucalyptus

13

http://goo.gl/VcprPx

第3の領域としてのCloud

Computingの候補

OpenStack

14

100% OSS cloud management software:

• 2010年プロジェクト開始

• NASA Nebula -> Nova

• Rackspace Cloud Files -> Swift

10 core components in Icehouse (2014.1)

OpenStackとは

http://goo.gl/3Qitfy

15

Project規模

19303people

144countries

Community

16

Open Cloudは幼年期の終わりを告げる

幼年期以前 ~2008 幼年期 2009~2012 幼年期の終わり 2013~2014 整理と融合の時代 2015~

多様性がない

ただ多様性があればよかった

多様性がありすぎる

よりシンプルに- OpenStack- CloudStack- Eucalyptus

OpenStack

が成熟期へ

Hybrid Cloud

Google Trends: http://goo.gl/5n2zis

17

• オープンである

• 耐久性がある

• 複雑さを解消しつつある

• 他の製品群と統合性がある

http://goo.gl/f3OFLi

OpenStackは成熟期へ

http://goo.gl/u4Nqj5

OpenStackがベストな選択

18

OpenStack開発に至る道のり

19

まずは触ってみる2014年 2月 ~ 4月

エンジニア: 2名 -> 4名

20

プロジェクト発足

• 初期の目的はREST APIの提供

• カンファレンス参加

• まずは公式ドキュメントを読む

• まずAll-in-Oneで動かしてみる

とにかく動かしてみる

21

この時点での苦労点

• 公式のドキュメントを読む気がしない

• なぜ動いているのかわからない

• Icehouseが未リリース

• vSphereのドキュメントがほぼ無い

一番苦労した時期

22

Agile Board大活躍JIRA / HipChat / Stash

23

4月にSandbox(開発)環境を提供

この時点では、プロジェクトとしてREST APIの提供が最大目的:

• 商用クラウドソフトも並行して検証していた

OpenStackを提案、OpenStackでプロジェクトを進めることで合意:

• 4月までにSandbox(開発)環境を提供することが決定(3月14日時点)

まだ自動化がまったくできておらず

すべて手作業で構築

24

Bugとの格闘、そしてOSS開発2014年 4月 ~ 11月エンジニア: 4名

25

OpenStack導入

• Sandbox(開発)環境の提供

• OpenStack Summit参加

• 全部自動化してみる

• オープンソース開発開始

導入のための”試行錯誤”の始まり

26

OSS開発のきっかけ

• 調子に乗ってIcehouse-RC1とUbuntuデイリービルドを使いバグ祭りに

• 毎日Launchpadのバグ情報と睨めっこ

• 学ぶべき情報量が多すぎるため進捗MTGが勉強会に…

この選択が後の

オープンソース開発に繋がる

27

Upstream training• 開発者育成トレーニング

• コミットまでの道のりを学ぶ

• ここで初めて1コミットする

日本版トレーニングでは講師として壇上

28

MTG

週1のMTGでは、振り返ること・

やるべきことを共有しきれない

Daily meeting実施毎日新たな発見がある

29

自動化の仕組み ~ ここで初めてDockerを使ってみた

Local PC

CI environment

Chef server

Chef cookbook

git push

hook

deploy

OpenStack nodes

MariaDB

RabbitMQ

http://goo.gl/MGIUwA

http://goo.gl/hRogWM

SERVERSPEChttp://goo.gl/PPEj46

http://goo.gl/WIFg8A

Chef cookbook

30

Sandbox展開

• 開発環境として小さく開始

• Ubuntu/vSphere/Icehouseを利用

• 数百台規模のVMが稼動

• セルフサービス

リリース直後はバグが多くユーザーから大量のFeed Backをもらう

31

バグ祭りの一例VM構築ができない!

原因:

• Ubuntu14.04のPython-suds clientが新しすぎる

解決:

• sudsのバージョンを下げる

• 原因に気付くのに1週間かかった• 問題解決までにNovaのコードをだいたい読んだ• 8月のポイントリリースまで改善されなかった

その結果…

32

何かあったらすぐ修正

• 毎日どこかしらで問題発生

• 人的ミスもたまに発生する

問題が起こっても誰かが即時対応し、

可能な限り”属人化”させない

33

Launchpadとの格闘、開発への参加• 発見したバグがLaunchpadにあるかチェック

• 無ければ自分でバグチケットを上げパッチを送る

• 致命的バグが無ければバージョンアップも検討

いつの間にか自分たちも”OpenStack自体”の開発をすることに

34

Open Platformへの昇華2014年 12月 ~ 今後のチャレンジ

エンジニア: 4名

35

Open Platform #1

KVM導入KVM

OpenStack

VMware

RIaaS

“適材適所”で使い分け

36

OpenStack

Open Platform #2

OpenStack on Dockerにトライする

37

Open Platform #3

• Cloud Foundry v2を稼動させる

• オープンなSW/HWを積極的に使う

OpenStack

Cloud Foundry

より”オープン”なものを活用

http://goo.gl/Iw68y0

38

1年を振り返り思うこと内発的動機を持って取り組む:

• 各エンジニアの情熱がプロジェクトを動かす

• Crowdsourcing的チームがよいかも

メンバー全員が全部やる:

• 属人化させると開発停滞も

必ずソースコードまで読む:

• ドキュメントにもバグはある

39

OpenStackの功罪、そして心得

40

OpenStackの功罪 ~ 功績

• ベンダー囲い込みからの自由

• システム構築の主導権を握る

• 先進機能を導入しやすい

http://goo.gl/kAcSjG

41

OpenStackの功罪 ~ 罪過トラブル時の責任の所在が不明瞭:

• OSの動作不良/ネットワークの不調/OpenStackのバグ/etc…

システム最適化が難しい:

“罪”の部分を負いきれるか見極めが必要

http://goo.gl/ycQk3A

42

心得ておくべきことOpen Sourceと向き合う:

• ベンダーサポートは本当に必要か

ユーザーはどこまで理解すればよいのか:

• 使い方だけ? or 内部構造まで?

OpenStackが全てを解決するわけではない:

• 社内のニーズを捉えているのか

43

Private Cloudの先にあるもの

44

整理と融合の時代を見据えて特殊化/画一化の果てにあるのは、ゆるやかな死:

• OpenStackに全てを委ねない方がベター

• Private Cloudの多様性は失われHybrid Cloudという新たな多様性へ向かう

Hybrid Cloud:

• 要件ごとにPrivate / Publicを使い分けるとよい

• インフラを跨ぐ抽象化レイヤーがあると障壁が低くなる (PaaSなど)

Private Cloud

OpenStack Microsoft AzureAmazon Web Service

Public Cloud

Cloud Foundry

45

Thank you