このスライドは2015年1月26日にITインフラSummit2015での講演に使われました。 クラウド基盤構築のオープンソースソフト「OpenStack」は、プライベートクラウド構築のデファクトスタンダードになりつつあります。しかし導入のハードルは決して低くありません。OpenStackならではの“心構え”が必要です。楽天のインフラ環境を整備する立場から、OpenStack導入の経緯、構築のポイント、構築時に必要なチームビルディングなどについて説明します。

1. 実用段階に入ったOpenStack
~ もうすぐ絶滅するというPrivate Cloudの多様性について ~
Jan/26/2015
Kentaro Sasaki
Global Operations Department, Rakuten, Inc.

2. 2
Presenter
佐々木 健太郎
所属:
• System Engineer@Rakuten
担当分野:
• OpenStack
• 分散ストレージ

3. 3
http://goo.gl/3Qitfy
この発表について
• OpenStack導入論拠 ~ なぜCloudが必要なのか
• OpenStack開発に至る道のり
• OpenStackの功罪、そして心得
• Private Cloudの先にあるもの

4. 4
OpenStack導入論拠

5. 5
OpenStack以前
We’re aiming to be a
No.1 Private Cloud
in the world.
Rakuten
Infrastructure
as
a
Service

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

7. 7
仮想環境へのシフト
NumberofServers
Physical RIaaS 1.0 RIaaS 2.0
物理環境
仮想環境

8. 8
RIaaSによる効果
コストとOPEXの削減$
高集約によるサーバ単価の削減
ラック数・スイッチ数を1/30に
デリバリータイムを数週間から数10分に
RIaaSの先にある目的

9. 9
Platform-nization

10. 10
• 非Infra依存のアプリ設計
• REST APIによる管理運用
• セルフサービスによる提供
http://goo.gl/3LvhNF
Platform化
Free(自由)なSWが重要

11. 11
• オープンソース活用
• 製品EOSLからの開放とライフサイクル
• サポートに頼らないマインドの改革
土台となるOpen Source
Open Cloudの採用

12. 12
Open Cloudの候補
パブリック プライベート
オープンソース
プロプライエタリ
Amazon Web Service
Microsoft Azure
Google Cloud Platform
VMware
OpenStack
CloudStack
Eucalyptus

13. 13
http://goo.gl/VcprPx
第3の領域としてのCloud
Computingの候補
OpenStack

14. 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. 15
Project規模
19303
people
144
countries
Community

16. 16
Open Cloudは幼年期の終わりを告げる
幼年期以前 ~2008 幼年期 2009~2012 幼年期の終わり 2013~2014 整理と融合の時代 2015~
多様性がない
ただ多様性があればよかった
多様性がありすぎる
よりシンプルに- OpenStack
- CloudStack
- Eucalyptus
OpenStack
が成熟期へ
Hybrid Cloud
Google Trends: http://goo.gl/5n2zis

17. 17
• オープンである
• 耐久性がある
• 複雑さを解消しつつある
• 他の製品群と統合性がある
http://goo.gl/f3OFLi
OpenStackは成熟期へ
http://goo.gl/u4Nqj5
OpenStackがベストな選択

18. 18
OpenStack開発に至る道のり

19. 19
まずは触ってみる
2014年 2月 ~ 4月
エンジニア: 2名 -> 4名

20. 20
プロジェクト発足
• 初期の目的はREST APIの提供
• カンファレンス参加
• まずは公式ドキュメントを読む
• まずAll-in-Oneで動かしてみる
とにかく動かしてみる

21. 21
この時点での苦労点
• 公式のドキュメントを読む気がしない
• なぜ動いているのかわからない
• Icehouseが未リリース
• vSphereのドキュメントがほぼ無い
一番苦労した時期

22. 22
Agile Board大活躍
JIRA / HipChat / Stash

23. 23
4月にSandbox(開発)環境を提供
この時点では、プロジェクトとしてREST APIの提供が最大目的:
• 商用クラウドソフトも並行して検証していた
OpenStackを提案、OpenStackでプロジェクトを進めることで合意:
• 4月までにSandbox(開発)環境を提供することが決定(3月14日時点)
まだ自動化がまったくできておらず
すべて手作業で構築

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

25. 25
OpenStack導入
• Sandbox(開発)環境の提供
• OpenStack Summit参加
• 全部自動化してみる
• オープンソース開発開始
導入のための”試行錯誤”の始まり

26. 26
OSS開発のきっかけ
• 調子に乗ってIcehouse-RC1とUbuntuデイリービルドを使いバグ祭りに
• 毎日Launchpadのバグ情報と睨めっこ
• 学ぶべき情報量が多すぎるため進捗MTGが勉強会に…
この選択が後の
オープンソース開発に繋がる

27. 27
Upstream training
• 開発者育成トレーニング
• コミットまでの道のりを学ぶ
• ここで初めて1コミットする
日本版トレーニングでは
講師として壇上

28. 28
MTG
週1のMTGでは、振り返ること・
やるべきことを共有しきれない
Daily meeting実施
毎日新たな発見がある

29. 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
SERVERSPEC
http://goo.gl/PPEj46
http://goo.gl/WIFg8A
Chef cookbook

30. 30
Sandbox展開
• 開発環境として小さく開始
• Ubuntu/vSphere/Icehouseを利用
• 数百台規模のVMが稼動
• セルフサービス
リリース直後はバグが多くユーザー
から大量のFeed Backをもらう

31. 31
バグ祭りの一例
VM構築ができない!
原因:
• Ubuntu14.04のPython-suds clientが新しすぎる
解決:
• sudsのバージョンを下げる
• 原因に気付くのに1週間かかった
• 問題解決までにNovaのコードをだいたい読んだ
• 8月のポイントリリースまで改善されなかった
その結果…

32. 32
何かあったらすぐ修正
• 毎日どこかしらで問題発生
• 人的ミスもたまに発生する
問題が起こっても誰かが即時対応し、
可能な限り”属人化”させない

33. 33
Launchpadとの格闘、開発への参加
• 発見したバグがLaunchpadにあるかチェック
• 無ければ自分でバグチケットを上げパッチを送る
• 致命的バグが無ければバージョンアップも検討
いつの間にか自分たちも
”OpenStack自体”の開発をすることに

34. 34
Open Platformへの昇華
2014年 12月 ~ 今後のチャレンジ
エンジニア: 4名

35. 35
Open Platform #1
KVM導入 KVM
OpenStack
VMware
RIaaS
“適材適所”で使い分け

36. 36
OpenStack
Open Platform #2
OpenStack on Dockerにトライする

37. 37
Open Platform #3
• Cloud Foundry v2を稼動させる
• オープンなSW/HWを積極的に使う
OpenStack
Cloud Foundry
より”オープン”なものを活用
http://goo.gl/Iw68y0

38. 38
1年を振り返り思うこと
内発的動機を持って取り組む:
• 各エンジニアの情熱がプロジェクトを動かす
• Crowdsourcing的チームがよいかも
メンバー全員が全部やる:
• 属人化させると開発停滞も
必ずソースコードまで読む:
• ドキュメントにもバグはある

39. 39
OpenStackの功罪、そして心得

40. 40
OpenStackの功罪 ~ 功績
• ベンダー囲い込みからの自由
• システム構築の主導権を握る
• 先進機能を導入しやすい
http://goo.gl/kAcSjG

41. 41
OpenStackの功罪 ~ 罪過
トラブル時の責任の所在が不明瞭:
• OSの動作不良/ネットワークの不調/OpenStackのバグ/etc…
システム最適化が難しい:
“罪”の部分を負いきれ
るか見極めが必要
http://goo.gl/ycQk3A

42. 42
心得ておくべきこと
Open Sourceと向き合う:
• ベンダーサポートは本当に必要か
ユーザーはどこまで理解すればよいのか:
• 使い方だけ? or 内部構造まで?
OpenStackが全てを解決するわけではない:
• 社内のニーズを捉えているのか

43. 43
Private Cloudの先にあるもの

44. 44
整理と融合の時代を見据えて
特殊化/画一化の果てにあるのは、ゆるやかな死:
• OpenStackに全てを委ねない方がベター
• Private Cloudの多様性は失われHybrid Cloudという新たな多様性へ向かう
Hybrid Cloud:
• 要件ごとにPrivate / Publicを使い分けるとよい
• インフラを跨ぐ抽象化レイヤーがあると障壁が低くなる (PaaSなど)
Private Cloud
OpenStack Microsoft AzureAmazon Web Service
Public Cloud
Cloud Foundry

45. 45
Thank you