データが覗いたOpenStack Summit Vancouver

Copyright © 2015 NTT DATA Corporation
データが覗いたOpenStack Summit Vancouver
2015/06/10
NTTデータ基盤システム事業本部
武田健太郎 takedakn@nttdata.co.jp
1

覗いてきたひとたち
2
Takedakn
やいやい言ってひっか
きまわす役割
Tobinait
HA, デプロイメントを
見るチームの良心
Kajinamit
Swiftをエクストリー
ムスポーツとして生き
がいとしていたが、
俺のマグナム
Sagaray
Nova, Neutron, Heat
をエクストリームス
ポーツとして生きがい
とする
Ankit
Libertyにすでに11個
もパッチが入ってるぞ
(fixtypoじゃないよ！)
Abhishek
どんなCore Devとも
すぐに話せるぞ

about.me/takedakn
• TOMOYO Linux
• Eucalyptus
• OpenStack
• Docker, Docker, Docker……
• Gitポケットリファレンス(技術評論社)
• qiita.com/takedakn
3

ちょっとまじめに全体像
• OpenStack Summit Vancouver
• 2015年5月18日 – 22日 @ Vancouver Convention Centre
• IaaS, オブジェクトストレージを実現するオープンソースソフト
ウェアであるOpenStackに関する半年に一度の国際イベントで、
今回が12回目の開催
• 通常のSummitとDesign Summitの2本立ての並列開催
– ユーザ事例やベストプラクティスが紹介されるSummit (Mon-Thu)
– 今後のOpenStackの開発に向けた議論の場であるDesign Summit (Tue-Fri)
• 公表参加者数は6000名と過去最大となり、相変わらずの注目度の
高さを伺わせる
4
以降開催予定
2015年秋: Tokyo, Japan
2016年春: Austin, Texas USA
2016年秋: Barcelona, Spain

https://www.openstack.org/summit/vancouver-2015/
5

いつものHype Cycle by Gartner
• Q: OpenStackはどこに位置すると思いますか？
6

Momentum 1: 汎用Integration Engine
• IaaS, オブジェクトストレージとしての円熟期に達した
OpenStackは、今後本格的な幻滅 && 普及期に入る
– すなわち、盛り上がりに乗じていただけの者たちは立ち去り、真に競争力を
生み出せると判断した者たちはプロダクションで使いはじめる
• 真に競争力を生み出せるかどうか？は、どのようにインテグレー
トされ、どのように使われるかにかかってくる
7
OpenStackは汎用のIntegration Engineに
(アプリケーションカタログMurano, コンテナをコンテナとして扱うMagnum)
OpenStackを使ったことがことさらに取り上げられることはなくなり、
どのような競争力のあるアプリを動かしたかが重要となる – Investors Panel

Momentum 2: Dev♥Ops
• Ops: Operators; 実際にOpenStackを運用しているひとたち
• Devs: Developers; OpenStackを開発しているひとたち
• Opsの発言力強化 && Devへのフィードバックのサイクル
• “Ops” sessions during the Design Summit?
– 2014/Spring @Atlanta: Ops Meetup
– 2014/Fall @Paris: Ops Summit
– 2015/Spring @Vancouver: Ops
8
ops

Momentum 3: Defragmentation of OpenStack
• 円熟期に達する一方で、プロジェクトスコープの拡大と各商用ベ
ンダ、サービスが群雄割拠することによる混乱も見られた
– OpenStackの”Fragmentation”
• OpenStack Foundation + DefCoreチームの定義する試験セット
と試験結果の公表により、ベンダロックイン回避と
Interoperabilityの向上を図る
9
ビジネス面:
手綱を締める

Momentum 4: コミュニティのリファクタリング
• refactoring
– 【名】リファクタリング◆プログラムのソースコードなどを意味・動作は
保ったまま、保守性・可読性を高めるように書き直すこと。
• OpenStackはBig Tentである
– 直下にはプロジェクトチーム (プロダクトではなく)
– From “Is this OpenStack?” to “Are you OpenStack?”
• 短期実質的には……Incubatedなプロジェクト+αの一斉昇格
10
コミュニティ面:
手綱を緩める
refactoringの意味・用例｜英辞郎 on the WEB：アルク
http://eow.alc.co.jp/search?q=refactoring

“We’re OpenStack!”
Integration
Dev♥Ops
Defragmentation
Community
11

では、事例を見ていきましょう
12

[小売] Walmart
• 小売大手としての規模の認識はふたつに分かれている
– Physical Scale: 世界中に店舗があり、しかも、各店舗の規模が大きい (日本
国内ではSEIYUと合弁)
– Digital Scale: eCommerceとして拡大を続けている
• eCommerce 3.0
– Physical scale x Digital scale
– 物理の規模とデジタルの規模の両方を揃えるという戦略により、Any
products, Anytime, Anywhereを実現する
13
これがしたい、これは非Cloudyだ、とい
うアプリ側とのバトルはあったしまだあ
るが、それはHealthyな会話だ
@walmartlabs
Amandeep Singh Juneja
140,000 cores
Rapidly provisioned, Flexible, Elastic
On-demand Self-Service computing
resources.
Rapidly becoming de-fact standard
for vendors up and down the stack
@WalmartLabs
James Downs

[Eコマース][ペイメント] eBay & PayPal status
• VMwareから大規模にOpenStackに乗り換えた事例として著名な
eBay & PayPal
• 2015年春の状況として特記すべきは以下
– 使用物: Havana / 100% KVM / 100% OpenVSwitch
– 規模: 300K cores / 10+ AZs / 1.6 PB block storage
– ワークロード
14

[Eコマース][ペイメント] LBaaS商用事例: eBay/PayPal
• eBay/PayPalの大規模なプライベートクラウドでLBaaSを積極活用、いくつか独自拡張
を実施している
– VIPの再利用、SSL証明書サポート、Designate (DNSaaS)との統合、など
• LBaaS利用前に内製していたLoad Balancer管理システムをLBaaSに置き換えた
15
Challenges, Architecture and Solutions for massive scale LBaaS deployment at eBay/Payal - YouTube
https://www.youtube.com/watch?v=fNR0SW3vj_s

[CATV, 動画配信] Comcast
• 音声認識からリアルタイムビデオまで、種々のサービスを
OpenStack上でホストしているが、続々と規模が拡大中
• 2015年5月期のSuperuser Awardsを受賞
16

[銀行] TD Bank: Toronto-Dominion Bank
• 銀行という保守的な業界と言えどもコンシューマサービスであり、
新たな商品やサービスを迅速に届ける、変化の大きい業務を実施
している
• OpenStackのような変化に追従できる基盤にくわえて、変化を許
容するための”Cultural Change”が重要
17

[金融サービス] FICO
• クレジットスコアFICO Scoreが有名、信用力に関する各種ツール
チェインをサービスとして提供している
– 動機: ツールチェインのXaaS化 (サービス化)
– 動機: vCloudで4000VMを動作させさらに増加傾向にあった
• FICO Analytic CloudのProductionとして利用を開始
– ハードウェア: Cisco USC
– ブロックストレージ: SolidFire, Ceph (用途に応じて選択)
– ソフトウェア: RHEL7, Puppet&Foreman, (TODO: CloudForms,
Spacewalk, etc.)
18
PoC的なイテレーションを繰り返し最適な基盤を模索

[Webサービス] Ancestry.com
[ゲノム研究] Fred Hutch, HudsonAlpha
• SwiftStack社関連の事例紹介3件
– Ancestry.com
– Fred Hutchinson Cancer Research Institute
– HudsonAlpha Institute for Biotechnology
# 3セッション連続で1社が独占するのは異例
• 性能・コスト面でSwiftが有利であることをアピール
• ゲノム分野については、SwiftStack社から新たに書籍が出版され、今後のター
ゲット領域であることがうかがえる
19

IPv6検証事例: Cisco + Nephos6
• パブリッククラウドサービスの実現にあたり、アドレスの重複やNATの悩みから開放さ
れるIPv6は重要
• Red Hat OpenStack (Icehouse)ベースでIPv6 enabledなOpenStackリファレンスを検
討・構築し、性能を測定
• 過程で直面した課題はそれぞれコミュニティに還元
20
Implementing an IPv6 enabled environment for a public cloud tenant – a case study - YouTube
https://www.youtube.com/watch?v=5Zybe33GaXU
課題例
• SLAAC based address provisioning
• IPv6 operation in a provider network model
• integration of external routers providing router Advertisements
• stateless DHCPv6 with dnsmasq
• client side behavior
• security group enhancements and Horizon integration

技術ネタももちろん見てるよ！
21

Compute nodeのHA化？
• Pacemaker: OpenStack’s PID 1
– http://www.slideshare.net/DavidVossel/pacemaker-openstacks-pid-1
– Pacemaker, HA-Proxy, Galeraを使用したコントローラのHA構成が一般的
になる中、コンピュートのクラスタ化に踏み込んだセッション
– pacemaker remoteという軽量なデーモンで多数のコンピュートを管理し、
故障時はコンピュートの電源OFFとevacuateによるVMの復旧まで実施する
– “systemdが担当するような依存関係、順序性のあるサービス起動は、クラ
スタお構成においてはpacemakerが担当すべき” – David Vossel
22

Ceilometerはどうなのよ？
• スケーラビリティ・信頼性の改善に向けての取り組み
– エージェントのAct-Act HA化  スケールアウト可能に
• Polling Agent, Notification Agent, Collectors
– データストレージの分離  負荷分散
• JunoからはAlarm DBを分離可能
• Kiloでは全てのDBを分離可能
23
Stabilizing the Jenga Tower: Scaling out Ceilometer - YouTube
https://www.youtube.com/watch?v=zrGTy-Znxco

Ceilometerの今後
• Gnocchi: 根本的なスケーラビリティの改善へ
– 軽量な時系列データ格納ストレージ
– リソースのデータモデルと時系列データを分離
– MongoDBに格納する場合と比べて大幅なサイズ減へ
24
Stabilizing the Jenga Tower: Scaling out Ceilometer - YouTube
https://www.youtube.com/watch?v=zrGTy-Znxco

Swift開発動向
 コミュニティの状況
• Erasure Codeを中心に、運用中の課題に対する改善や、各種の機能追加が行わ
れている。各開発課題は、コミュニティ内で担当が定められ、平行して進行中。
 機能拡張系
• Erasure Code : Kiloリリースから引き続き。安定性向上が中心
• データ暗号化 : セキュリティ性の向上のための機能追加
• Storlets : ストレージ内でのデータ処理を実現
• Tape Storage : テープや光ディスクによる低コストストレージの実現
• Notification : データ更新をMQを介して別システムに通知
 課題に対する改善
• Policy移行, Tiering : ポリシー移行をサポート
• Container Sharding: データが増えた際の性能ボトルネック改善
• Part Powerの増加 : クラスタ拡張時のペインポイント解消
• Hummingbird : Object-serverをGOで再実装し、性能改善
25

IPv6開発の状況
• Kiloでの達成項目
– IPv6 routerのフルサポート
• https://blueprints.launchpad.net/neutron/+spec/ipv6-router (blueprint)
• https://review.openstack.org/#/c/142224/ (neutron-specs)
• https://review.openstack.org/#/c/156283/ (IPv6 router implementation)
• https://review.openstack.org/#/c/173206/ (IPv6 HA router support)
– 複数IPv6プレフィックス/アドレス
• http://specs.openstack.org/openstack/neutron-
specs/specs/kilo/multiple-ipv6-prefixes.html
• Libertyに向けての実施予定
– IPv6プレフィックス委譲 (Prefix Delegation)
– http://specs.openstack.org/openstack/neutron-
specs/specs/liberty/ipv6-prefix-delegation.html
• やらない予定
– Floating IP: IPv6では必要ない概念、との認識
• [NATの観点] “IPv6 means globally routable IPs, not a scarce resource”
• [障害普及の観点] “Alternatives like load balancing, any cast, etc.”
26

LBaaS開発の状況
• Kiloでの達成状況
– LBaaS API/Data model v2
– http://specs.openstack.org/openstack/neutron-
specs/specs/kilo/lbaas-api-and-objmodel-improvement.html
• Libertyに向けて
– 優先事項
• LBaaS v2のHorizon対応
• L7バランシング http://specs.openstack.org/openstack/neutron-
specs/specs/liberty/lbaas-l7-rules.html
– この他の項目は適宜neutron-specsでレビューされる
• https://review.openstack.org/#/q/message:lbaas+project:openstack/neu
tron-specs,n,z
27

これからのOpenStackのはなしをしよう
28

Road to Liberty
• 方式改善により、魅力ある、”驚き最小のIaaS”に
– Unshelve操作による真の意味での電源On/Off機能の実現
– Nova-spec: improve-unshelve-performance
– https://review.openstack.org/#/c/135387/
• 運用上発生した事象追跡の容易化
– APIリクエスト識別子のハンドリング
– OpenStack-spec: log-request-id-mappings
– https://review.openstack.org/#/c/156508/
• Active/Passiveしか取れないコンポーネントをゼロに
– Cinder-volume, Neutron-lbaas-agent
• Opsの観点からのpain pointの解消
– DBスキーマ変更のロック最小化 (bp: online-schema-changes)
– 根本的なスケーラビリティ改善 (cell v2)
Any challenges? Please let us know!
29

Feedback cycle
Deploy &
Operate
Face Challenges
Organize
Feedback
30

We know the number is not everything, however,
31
Stackalytics (Liberty commits for integrated projects) on June 4, 2015
http://stackalytics.com/?metric=commits&project_type=integrated

We know the number is not everything, however,
32
Stackalytics (Liberty commits for integrated projects) on June 4, 2015
http://stackalytics.com/?metric=commits&project_type=integrated
Almost there!!!

嗚呼すばらしきVancouver, 嗚呼すばらしきTokyo?
33

データが覗いたOpenStack Summit Vancouver

More Related Content

What's hot

Viewers also liked

Similar to データが覗いたOpenStack Summit Vancouver

データが覗いたOpenStack Summit Vancouver