2015年7月13日（月）に開催されたイベント「5周年特別企画： OpenStack Summitの歩き方」でのセッション「OpenStack オペレータの抱える課題とサミットでの議論 ～gooでのOpenStack導入事例を交え～」の後半部分の講演資料です。 （前半はエヌ・ティ・ティ レゾナント株式会社の事例紹介でした。）

1. OpenStack オペレータの抱える課題とサミットでの議論
～gooでのOpenStack導入事例を交え～
2015年7月13日（月）
日本電信電話株式会社
NTTソフトウェアイノベーションセンタ
夏目貴史
5周年特別企画： OpenStack Summitの歩き方

2. 2
内容
• OpenStack Summitで運用者（オペレータ）の課題が
どのように扱われているか
– Vancouverのサミットでの前半の事例紹介の課題に関す
る発表と議論の紹介
• 運用者（オペレータ）の立場からOpenStack Summit
Tokyoに期待できること

3. 3
運用者（Ops）から見たVancouver Summit
• Conference
– キーノート/ゼネラル/ブレイクアウト・セッション
• 事例
• ノウハウ
• Design Summit
– Opsセッション
• 運用のエキスパートが事例、課題、改善方法などについて議論する
• 運用者の観点から開発者にフィードバックを行なう

4. 4
アップグレード
• さきほどの事例での課題
– アップグレード戦略（2バージョン・アップグレード）
– ライブ・アップグレードは可能か
• サミットでの主な発表や議論の内容
– アップグレード戦略
• 事例としてはHavanaからIcehouseの事例が多かった
（IcehouseからJunoの事例も）
• HavanaからJunoへの2バージョン・アップグレードの事例も[1]
• コンポーネントによってはアップグレードしない選択肢もある
– ライブ・アップグレード
• ユーザのAPI実行のダウンタイムをゼロとした事例はなかった
• アップグレードの途中はユーザにAPIリクエストをさせないが、
管理者がAPIリクエストできるようにしておくのが良い
– ツールによる自動化
• Ansible/Puppetの事例が多い
– 検証環境
• 段階的なアップグレード検証（ステージング環境）が必要

5. 5
スケーラビリティ
• さきほどの事例での課題
– Cell(Nova)のスケジューリング
– 将来的な複数データセンタ構成への対応
• サミットでの主な発表や議論の内容
– Cell v2（Nova）
• 現在開発中
• Cell v1は複数Cellに跨った処理に
問題があったため、開発が開始された
• CellとAvailability Zoneの関係[2]
– CellとAvailability Zoneは独立であるべき
（包含関係にはない）
– Novaプロジェクトにフィードバックする
（Novaプロジェクトからの意見照会）
• ロードマップ
– Liberty(2015年10月リリース予定)では最低限シングル・セル構成の実
装が目標
– 次のMリリースで複数セル構成に対応させる予定
– Cell v1からのコンバージョン（移行）パスも議論されている

6. 6
スケーラビリティ（続き）
• サミットでの主な発表や議論の内容（続き）
– 複数データセンタ構成への対応
• データセンタごとにリージョンを
構成している事例があった[3]
（Walmart）
– ネットワーク・セグメンテーション（Neutron）[2]
• 現在はNeutron を導入する上で、同一リージョン内の全てのノー
ドがL2ネットワークで接続されている必要があり、L2ネットワーク
を分割して構成することができない
• 上記の要件が大規模なシステムを構築する上で問題であるとい
う声が数多くあがり、 Neutronプロジェクトに要望としてネット
ワーク・セグメンテーション（複数のL2ネットワークへの分割）の
導入を上げることになった

7. 7
ログ
• さきほどの事例での課題
– トラブルシューティング
– DEBUGレベルだとログの出力量が多い
• サミットでの主な発表や議論の内容
– ログ解析
• データサイエンスに基づく分析手法による
ログ解析の効率化の事例[4]（Cisco Systems）
– 膨大な量のログが出力されることを前提とした解決方法
– メトリックとグループ化したログ・メッセージについて、その相関関係を利用してログ
解析を効率化
• コンポーネントを跨った処理の追跡
– APIリクエストに紐付くRequest IDがコンポーネントごとに異なるので、追跡
が厳密には難しい
– NTTとNTTデータが現在提案しているLog request id mappings[5]の他の案
と比較した議論
→ Log Working GroupやCross ProjectのIRCミーティングで引き続き議論し
て活動中
– 課金の議論
• Ceilometerを利用している企業がセッション参加者の3分の2程度と多
かった[6]が、スケールに課題あり

8. 8
OpenStack Summit Tokyoで期待できること
• 事例の収集
– 他のユーザ（運用者）のベスト・プラクティス、
アンチ・パターン、課題
• 開発へのフィードバック
– 運用者の意見の反映
• 自分たちの提案のアピールおよび
議論
– それ以降の議論に繋げることができる

9. ご清聴ありがとうございました。
9

10. 10
参考サイト
• [1] Hold my beer and watch this! Upgrading from Havana to
Juno in one fell swoop with live customers.
– https://www.openstack.org/summit/vancouver-2015/summit-
videos/presentation/hold-my-beer-and-watch-this-upgrading-from-havana-to-
juno-in-one-fell-swoop-with-live-customers
• [2] Large Deployments Team Work Session
– https://etherpad.openstack.org/p/YVR-ops-large-deployments
• [3] Walmart's Openstack Journey
– https://www.openstack.org/summit/vancouver-2015/summit-
videos/presentation/walmart-and-039s-openstack-journey
• [4] Demystifying Logs in OpenStack Clouds
– https://www.openstack.org/summit/vancouver-2015/summit-
videos/presentation/demystifying-logs-in-openstack-clouds
• [5] Log request id mappings（Return request ID to caller）
– https://review.openstack.org/#/c/156508/
• [6] Ops: Billing / show back / charge back - how do I do that?
– https://etherpad.openstack.org/p/YVR-ops-billing