2013年6月12日開催講演「Interop Tokyo 2013」 どうする？どうなる？SDN/クラウド時代の運用管理 ～データセンター、クラウド提供事業者の立場から～　さくらインターネット株式会社　山田修司

1. どうする？どうなる？
SDN/クラウド時代の運用管理
～データセンター、クラウド提供事業者の立場から～
さくらインターネット株式会社
運用部 山田 修司
Interop Tokyo 2013
1
2013年6月12日

2. もくじ
• 自己紹介
• 運用技術者を取り巻く現状など
• クラウド時代の運用管理の在り方
• 運用管理の現在や今後の展望
• 最後に
2

3. 自己紹介
• 名前： 山田 修司
• 所属： さくらインターネット株式会社 運用部
• 業務経験：
– クラウドサービス運用
• IaaSサービス「さくらのクラウド」の運用全般
– バックボーンネットワーク運用
• BGP/OSPF運用、障害対応、etc・・・
– データセンターの現場オペレーション
• 設置作業、配線作業、障害対応、etc・・・
3

4. 自己紹介
• 本日の立場： クラウド提供事業者の運用担当者
– ※ 所属組織を代表する意見ではありません。
– 個人的な意見として発言します。
• 「運用」に対する心構え
– 運用を通じて、ビジネスにコミットするのが運用のお仕事
– ありとあらゆる問題からインフラを死守する。
– 開発から降ってきた要望や機能を遅滞なくデプロイする。
– 改善（自動化、インフラ改善、自己研鑽）に取り組む。
4

5. もくじ
• 自己紹介
• 運用技術者を取り巻く現状など
• クラウド時代の運用管理の在り方
• 運用管理の現在や今後の展望
• 最後に
5

6. 生み出され続けるテクノロジーや用語
• 仮想化技術 - KVM, Xen, OpenStack、CloudStack、eucalyptus, Open
vSwitch …
• 仮想化支援機能 - VPID, EPT, IOV, I/O AT, VMDq, SR-IOV, IOMMU...
• ネットワーク - IPv6, SDN, ファブリック(TRILL, SPB, etc...), InfiniBand, VLAN-
Translation …
• ストレージ - Intelligent Storage, iSCSI, FCoE, SSD, IOPS …
• ツール - Chef, Puppet, Ruby, node.js, zabbix, munin, sensu, Graphite, stats,
JUnit, Fablic, selenium, glu, mongoDB, Redis, riak, ActiveMQ, RabbitMQ,...
6

7. 運用の生産性を低下させる要因
• 1. ソフトウェア品質の問題
– あらゆるソフトウェアによって引き起こされる様々な不具合
• 2. ヒューマンエラー
– 自動化不足
– リソース不足
– 手順書の品質不備
• 3. カスタマー対応
– 一時的な障害や問題に対するお問い合わせ対応
– 二次、三次エスカレーションへの対応
– 障害報告書等の作成、説明対応、etc・・・
7

8. 運用担当者を取り巻く現状
• 複数台のサーバをHA構成などでクラスタ化して運用す
るのが常識化しつつある。しかし、サーバの台数が多い
と、必然的にエラーや障害も発生しやすくなる。
• 昨今では、各サーバが巧妙に連携している構成が多く、
障害時に影響範囲の把握や予測が困難になりがち。
• 定型的な対応手順書の想定を超える事象が発生しやす
く、二次・三次エスカレーションされやすい。
• 台数が多く、設定項目等も多いため、手作業に頼ってい
てはオペミスし放題。
• 今、サービスを守るために運用はどうしたらいいのか？
8

9. もくじ
• 自己紹介
• 運用技術者を取り巻く現状など
• クラウド時代の運用管理の在り方
• 運用管理の現在や今後の展望
• 最後に
9

10. おそらく、合理的ないくつかの対策
1. 自動化/半自動化
2. サービス全体の可視化
3. 知見やノウハウを共有できる環境づくり
10

11. Deployment Automation
• アプリケーションの展開ミスは、重大なシステムトラ
ブルを引き起こす要因になります。
– あらゆるデプロイ作業は、巧妙に自動化/半自動化されて
いることが望ましいです。
• 具体的には・・・
– Chef、Puppet、capistranoのような構成管理ツールでアプ
リケーションをデプロイするなどの手段が有効です。
– また、Gitのような世代管理ツールを使って、設定ファイル
類を管理することも有効です。
11

12. Auto & Real-time Monitoring
• 手動での監視登録作業は、監視漏れや登録設定ミ
スを誘発します。
– 監視はあらゆるステータスが正常であることを確認するた
めに、確実に動作していることが求められるツールです。
• 具体的には・・・
– 監視ツールの自動ディスカバリ機能を使い、監視が自動
登録されるように巧妙に工夫するなどの策が有効です。
– 各サーバのプロセス監視は、Chefなどでプロセス監視用
のスクリプトを各サーバに配布してCronに登録するなどの
工夫も有効です。
12

13. Real-time Metrics & Measure
• サービスの状況をいち早く把握するためには、運用
に必要とされる情報がリアルタイムで可視化されて
いることが望ましいです。
– グラフを見ればサービスの状況を概ね把握できる環境は、
すべての人にとって望ましいことです。
• 具体的には・・・
– Cacti、Ganglia、Monit、Graphite、statsd、 opentsdbのよう
なリソース監視向けのツールや、グラフ生成に向いたツー
ルを活用し、必要なデータはグラフ化しましょう。
13

14. Real-time Sosialization
• サービス担当者同士は、常にリアルタイムにコミュ
ニケーションできる環境にあることが望ましいです。
– 最も望ましいのは、チーム全員が同じ時間に同じ場所で
作業することです。担当者間のコミュニケーションの遅延
はサービス品質に直結します。
• 具体的には・・・
– チームが遠隔地に分離されている場合には、IRCやチャッ
トのようなリアルタイムコミュニケーションツールやサービ
スを活用するなどの工夫が有効です。
14

15. SaaSのススメ
• 運用を楽にするために、以下のような運用向けの
SaaSを利用するのも効果的かもしれません。
– pingdom： Web監視
– NeuSter WebMetrics: Web監視
– PagerDuty: アラート通知
– Datadog: リアルタイムダッシュボード、メトリクス
– Twilio：電話連絡の自動化
– HipChat: グループチャット
15

16. SDNは救世主になりえるか？
• データセンター屋さん視点だと・・・
– VLANの4Kの壁を超えたいときや、ある種の特殊なパケッ
ト操作をしたいときには、SDNやOpenFlow技術等を使った
ほうがシンプルなので、サービスの一部でSDNを導入する
ことは考えられうる。
– データセンターではネットワーク機材の数が多すぎるため、
SDN対応機器の価格が相当に安くならない限りは、SDNを
データセンター全体に適用するというのは考え難い・・・
16

17. ここまでを一旦まとめると
• 新たなテクノロジーが増える一方で、運用の手助け
となる新たなツールやサービスも増えている。
• 新たなツールをプロセスに適用することで、運用が
楽になる環境づくりに取り組むことがポイントだと思
います。
17

18. もくじ
• 自己紹介
• 運用技術者を取り巻く現状など
• クラウド時代の運用管理の在り方
• 運用管理の現在や今後の展望
• 最後に
18

19. What's DevOps?
• 一方で、DevOpsというムーブメントが起きている。
• 広義におけるDevOps：
– Lean & Agile & Velocity: 生産性に着目し、開発部門と運
用部門の円滑なビジネスコラボレーションを実現すること
によって、高速、かつ着実にサービス（ビジネス）の価値を
高めていくことを目的とするIT活動。
– Tool & Process & Calture: ツールの積極的活用、ムリ・ム
ダ・ムラの排除によるプロセスの最適化、あらゆるステー
タスが可視化されるカルチャーづくりが重要視される。
19

20. DevOpsが生まれた背景
• 大規模な組織では、開発、品質保証(QA)、運用、営業部
門などがそれぞれ独立していることが多い。
• そのような組織体制においては、担当者・グループ間の
意識のすれ違い、利害関係、調整・根回し、etc・・・など
の問題が日常的にプロセスを遅延させます。
• 極端な場合、チームは地理的に異なる組織に分断、ま
たは完全に異なる管理体制下に置かれ、分離されてい
るようなことも多々ある。
• DevOpsは、このような閉塞的で生産性が低迷しやすい
サイロ型の組織体制を打破するための活動です。
20

21. DevOpsの特徴
1. Cross-functional teams
2. Widely shared metrics
3. Automating repetitive tasks
4. Post-mortems
5. Regular releases
21

22. 1. Cross-functional teams
• 複数の部門・職位、多種多様な経験・スキルを持つ
メンバーによって構成される部門横断的なチーム体
制を特徴とします。
• 既存の文化を打ち破ぶる行動は異なるスキルを持
つ人々でチームが構成されているときに最も容易に
実行に移されます。
• チームが自己組織的に行動する必要がある場合に
有効です。
22

23. 2. Widely shared metrics
• サービス全体の可視化、ハイレベル、ローレベルの
メトリクスの共有。
• サービスがどのような状態にあるかを把握すること
は誰にとっても重要です。
• 様々な観点から取得した数値をグラフで共有するこ
とは、システムやサービスの状況を理解するために
有効な手法です。
23

24. 3. Automating repetitive tasks
• 定形作業の自動化。
• タスクを自動化するツールを使うと、サービス運用コ
ストの改善に繋がります。
• 反復的な定形作業から運用担当者を解放するため
に有効な手法です。
24

25. 4. Post-mortems
• 重大なトラブルが発生した際はチーム全員が問題
解消に向けて全力を尽くし、後日に振り返りを実施
することで知見を共有する。
• あらゆる問題に対してチーム全員で協力して解決す
ることは、異なる知見・ノウハウを共有するのに有効
な手法です。
25

26. 5. Regular releases
• 頻繁で定期的な機能リリース。
• 多くの場合、ユーザーは、サービスやシステムがあ
る日突然全く別のものに切り替わることを望んでは
いません。
• 極端な変更は不具合と混乱の元になります。多くの
場合において、機能は小さく頻繁に追加・変更され
るほうが合理的です。
• ただし、これを達成するには、極限のチームコラボ
レーションが必要とされます。
26

27. NoOps？
• 昨今におけるDevOpsムーブメントの一方で、NoOps
（運用担当者不要論）という考え方も主張されている。
• 広義におけるNoOps：
– 高度に発達したクラウドサービスを巧みに活用することで、
専任の運用技術者という存在は一切不要になるという考
え方。
• ただし、個人的には運用技術者が不要になる時代
が来るとは思いません。
• あらゆるものをソフトウェアだけでカバーすることは
できません。
27

28. もくじ
• 自己紹介
• 運用技術者を取り巻く現状など
• クラウド時代の運用管理の在り方
• 運用管理の現在や今後の展望
• 最後に
28

29. クラウド前、クラウド後の変化
• クラウドファーストというムーブメント
– 初めからクラウド前提で検討される顧客が増加している。
– クラウドへの抵抗感というのはそれほど感じられない。
VPSサービスからのアップグレード目的や、ハウジング
サービスからの乗り換え検討が多いように感じる。
– 一方で、専用サーバを知らない世代のエンジニアが次第
に増加しており、専用サーバが初めから比較検討対象外
にされることが増えてきたように感じる。
– しかし、専用サーバはコストパフォーマンスの王者。慎重
に検討した結果、「専用サーバで」というケースは絶えな
い。
29

30. ユーザへ推奨する運用管理の在り方
• 「クラウドだから安心」ということはありません。
• クラウド最大のメリットは、安価なサーバを迅速に複数
台増設することができるスケールアウト戦略です。
• 台数が多くなると、必然的に未知のエラーや障害との遭
遇は避けられません。
• クラウドで運用の一部をアウトソーシングしたつもりに
なっても、ひとたび障害により重大な影響が発生したと
きにユーザーは許してくれません。
• クラウド環境上のサーバだとしても、最後には自分達の
手で管理しているという自覚と責任をもって運用しなけ
ればなりません。
30

31. ユーザへ推奨する運用管理の在り方
• 本当に自分達にクラウドが必要かなのかという点に
ついては、慎重に検討することも大切です。
• ただし、DevOpsやアジャイルな開発/運用を目指す
場合においては、クラウドは間違いなく向いていると
思います。
31

32. 参考資料
• Mary and Tom Poppendieck: Implementing Lean Software Development: From
Concept to Cash. Addison-Wesley. 2006. （邦訳：リーン開発の本質ソフトウエア開
発に生かす７つの原則、日経BP社、2007年）
• Sam Guckenheimer: Agile Software Engineering with Visual Studio: From Concept
to Continuous Feedback. Addison-Wesley Professional. 2011.（邦訳：アジャイルソ
フトウェアエンジニアリング ~ 基本概念から継続的フィードバックまで、日経BP社、
2012年）
• Ash Maurya: Running Lean, 2nd Edition.O’Relly Media.2012.（邦訳：Running Lean
実践リーンスタートアップ、オライリージャパン社、2012年）
• Eric Ries: The Lean Startup: How Constant Innovation Creates Radically Successful.
Crown Business.2011. （邦訳：リーン・スタートアップ ―ムダのない起業プロセスで
イノベーションを生みだす、日経BP社、2012年）
32

33. 参考資料
• 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
• GOV.UK: Government Service Design Manual
https://www.gov.uk/service-manual/operations/devops.html
• Publickey: DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012
http://www.publickey1.jp/blog/12/devopsdevops_day_tokyo_2102.html
• Rebel Labs release: IT Os & DevOs Productivity Report 2013
http://zeroturnaround.com/labs/rebel-labs-release-it-ops-devops-productivity-report-2013/#!/
• DevOps Cufe
http://devopscafe.org/
• dev2ops
http://dev2ops.dtosolutions.com/
33

34. おわり
34