どうする？どうなる？ SDN/クラウド時代の運用管理

～データセンター、クラウド提供事業者の立場から～

さくらインターネット株式会社

運用部 山田 修司

Interop Tokyo 2013

1

2013年6月12日

もくじ

• 自己紹介

• 運用技術者を取り巻く現状など

• クラウド時代の運用管理の在り方

• 運用管理の現在や今後の展望

• 最後に

2

自己紹介

• 名前： 山田 修司

• 所属： さくらインターネット株式会社 運用部

• 業務経験： – クラウドサービス運用

• IaaSサービス「さくらのクラウド」の運用全般

– バックボーンネットワーク運用

• BGP/OSPF運用、障害対応、etc・・・

– データセンターの現場オペレーション

• 設置作業、配線作業、障害対応、etc・・・

3

自己紹介

• 本日の立場： クラウド提供事業者の運用担当者

– ※ 所属組織を代表する意見ではありません。

– 個人的な意見として発言します。

• 「運用」に対する心構え

– 運用を通じて、ビジネスにコミットするのが運用のお仕事

– ありとあらゆる問題からインフラを死守する。

– 開発から降ってきた要望や機能を遅滞なくデプロイする。

– 改善（自動化、インフラ改善、自己研鑽）に取り組む。

4

もくじ

• 自己紹介

• 運用技術者を取り巻く現状など

• クラウド時代の運用管理の在り方

• 運用管理の現在や今後の展望

• 最後に

5

生み出され続けるテクノロジーや用語

• 仮想化技術 - 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

運用の生産性を低下させる要因

• 1. ソフトウェア品質の問題

– あらゆるソフトウェアによって引き起こされる様々な不具合

• 2. ヒューマンエラー

– 自動化不足

– リソース不足

– 手順書の品質不備

• 3. カスタマー対応

– 一時的な障害や問題に対するお問い合わせ対応

– 二次、三次エスカレーションへの対応

– 障害報告書等の作成、説明対応、etc・・・

7

運用担当者を取り巻く現状

• 複数台のサーバをHA構成などでクラスタ化して運用す

るのが常識化しつつある。しかし、サーバの台数が多いと、必然的にエラーや障害も発生しやすくなる。

• 昨今では、各サーバが巧妙に連携している構成が多く、障害時に影響範囲の把握や予測が困難になりがち。

• 定型的な対応手順書の想定を超える事象が発生しやすく、二次・三次エスカレーションされやすい。

• 台数が多く、設定項目等も多いため、手作業に頼っていてはオペミスし放題。

• 今、サービスを守るために運用はどうしたらいいのか？

8

もくじ

• 自己紹介

• 運用技術者を取り巻く現状など

• クラウド時代の運用管理の在り方

• 運用管理の現在や今後の展望

• 最後に

9

おそらく、合理的ないくつかの対策

1. 自動化/半自動化

2. サービス全体の可視化

3. 知見やノウハウを共有できる環境づくり

10

Deployment Automation

• アプリケーションの展開ミスは、重大なシステムトラブルを引き起こす要因になります。

– あらゆるデプロイ作業は、巧妙に自動化/半自動化されていることが望ましいです。

• 具体的には・・・

– Chef、Puppet、capistranoのような構成管理ツールでアプリケーションをデプロイするなどの手段が有効です。

– また、Gitのような世代管理ツールを使って、設定ファイル類を管理することも有効です。

11

Auto & Real-time Monitoring

• 手動での監視登録作業は、監視漏れや登録設定ミスを誘発します。

– 監視はあらゆるステータスが正常であることを確認するために、確実に動作していることが求められるツールです。

• 具体的には・・・

– 監視ツールの自動ディスカバリ機能を使い、監視が自動登録されるように巧妙に工夫するなどの策が有効です。

– 各サーバのプロセス監視は、Chefなどでプロセス監視用のスクリプトを各サーバに配布してCronに登録するなどの工夫も有効です。

12

Real-time Metrics & Measure

• サービスの状況をいち早く把握するためには、運用に必要とされる情報がリアルタイムで可視化されていることが望ましいです。

– グラフを見ればサービスの状況を概ね把握できる環境は、すべての人にとって望ましいことです。

• 具体的には・・・

– Cacti、Ganglia、Monit、Graphite、statsd、 opentsdbのよう

なリソース監視向けのツールや、グラフ生成に向いたツールを活用し、必要なデータはグラフ化しましょう。

13

Real-time Sosialization

• サービス担当者同士は、常にリアルタイムにコミュニケーションできる環境にあることが望ましいです。

– 最も望ましいのは、チーム全員が同じ時間に同じ場所で作業することです。担当者間のコミュニケーションの遅延はサービス品質に直結します。

• 具体的には・・・ – チームが遠隔地に分離されている場合には、IRCやチャッ

トのようなリアルタイムコミュニケーションツールやサービスを活用するなどの工夫が有効です。

14

SaaSのススメ

• 運用を楽にするために、以下のような運用向けのSaaSを利用するのも効果的かもしれません。

– pingdom： Web監視

– NeuSter WebMetrics: Web監視

– PagerDuty: アラート通知

– Datadog: リアルタイムダッシュボード、メトリクス

– Twilio：電話連絡の自動化

– HipChat: グループチャット

15

SDNは救世主になりえるか？

• データセンター屋さん視点だと・・・

– VLANの4Kの壁を超えたいときや、ある種の特殊なパケット操作をしたいときには、SDNやOpenFlow技術等を使ったほうがシンプルなので、サービスの一部でSDNを導入することは考えられうる。

– データセンターではネットワーク機材の数が多すぎるため、SDN対応機器の価格が相当に安くならない限りは、SDNをデータセンター全体に適用するというのは考え難い・・・

16

ここまでを一旦まとめると

• 新たなテクノロジーが増える一方で、運用の手助けとなる新たなツールやサービスも増えている。

• 新たなツールをプロセスに適用することで、運用が楽になる環境づくりに取り組むことがポイントだと思います。

17

もくじ

• 自己紹介

• 運用技術者を取り巻く現状など

• クラウド時代の運用管理の在り方

• 運用管理の現在や今後の展望

• 最後に

18

What's DevOps?

• 一方で、DevOpsというムーブメントが起きている。

• 広義におけるDevOps：

– Lean & Agile & Velocity: 生産性に着目し、開発部門と運

用部門の円滑なビジネスコラボレーションを実現することによって、高速、かつ着実にサービス（ビジネス）の価値を高めていくことを目的とするIT活動。

– Tool & Process & Calture: ツールの積極的活用、ムリ・ム

ダ・ムラの排除によるプロセスの最適化、あらゆるステータスが可視化されるカルチャーづくりが重要視される。

19

DevOpsが生まれた背景

• 大規模な組織では、開発、品質保証(QA)、運用、営業部門などがそれぞれ独立していることが多い。

• そのような組織体制においては、担当者・グループ間の意識のすれ違い、利害関係、調整・根回し、etc・・・などの問題が日常的にプロセスを遅延させます。

• 極端な場合、チームは地理的に異なる組織に分断、または完全に異なる管理体制下に置かれ、分離されているようなことも多々ある。

• DevOpsは、このような閉塞的で生産性が低迷しやすいサイロ型の組織体制を打破するための活動です。

20

DevOpsの特徴

1. Cross-functional teams

2. Widely shared metrics

3. Automating repetitive tasks

4. Post-mortems

5. Regular releases

21

1. Cross-functional teams

• 複数の部門・職位、多種多様な経験・スキルを持つメンバーによって構成される部門横断的なチーム体制を特徴とします。

• 既存の文化を打ち破ぶる行動は異なるスキルを持つ人々でチームが構成されているときに最も容易に実行に移されます。

• チームが自己組織的に行動する必要がある場合に有効です。

22

2. Widely shared metrics

• サービス全体の可視化、ハイレベル、ローレベルのメトリクスの共有。

• サービスがどのような状態にあるかを把握することは誰にとっても重要です。

• 様々な観点から取得した数値をグラフで共有することは、システムやサービスの状況を理解するために有効な手法です。

23

3. Automating repetitive tasks

• 定形作業の自動化。

• タスクを自動化するツールを使うと、サービス運用コストの改善に繋がります。

• 反復的な定形作業から運用担当者を解放するために有効な手法です。

24

4. Post-mortems

• 重大なトラブルが発生した際はチーム全員が問題解消に向けて全力を尽くし、後日に振り返りを実施することで知見を共有する。

• あらゆる問題に対してチーム全員で協力して解決することは、異なる知見・ノウハウを共有するのに有効な手法です。

25

5. Regular releases

• 頻繁で定期的な機能リリース。

• 多くの場合、ユーザーは、サービスやシステムがある日突然全く別のものに切り替わることを望んではいません。

• 極端な変更は不具合と混乱の元になります。多くの場合において、機能は小さく頻繁に追加・変更されるほうが合理的です。

• ただし、これを達成するには、極限のチームコラボレーションが必要とされます。

26

NoOps？

• 昨今におけるDevOpsムーブメントの一方で、NoOps（運用担当者不要論）という考え方も主張されている。

• 広義におけるNoOps：

– 高度に発達したクラウドサービスを巧みに活用することで、専任の運用技術者という存在は一切不要になるという考え方。

• ただし、個人的には運用技術者が不要になる時代が来るとは思いません。

• あらゆるものをソフトウェアだけでカバーすることはできません。

27

もくじ

• 自己紹介

• 運用技術者を取り巻く現状など

• クラウド時代の運用管理の在り方

• 運用管理の現在や今後の展望

• 最後に

28

クラウド前、クラウド後の変化

• クラウドファーストというムーブメント

– 初めからクラウド前提で検討される顧客が増加している。

– クラウドへの抵抗感というのはそれほど感じられない。VPSサービスからのアップグレード目的や、ハウジングサービスからの乗り換え検討が多いように感じる。

– 一方で、専用サーバを知らない世代のエンジニアが次第に増加しており、専用サーバが初めから比較検討対象外にされることが増えてきたように感じる。

– しかし、専用サーバはコストパフォーマンスの王者。慎重に検討した結果、「専用サーバで」というケースは絶えない。

29

ユーザへ推奨する運用管理の在り方

• 「クラウドだから安心」ということはありません。

• クラウド最大のメリットは、安価なサーバを迅速に複数台増設することができるスケールアウト戦略です。

• 台数が多くなると、必然的に未知のエラーや障害との遭遇は避けられません。

• クラウドで運用の一部をアウトソーシングしたつもりになっても、ひとたび障害により重大な影響が発生したときにユーザーは許してくれません。

• クラウド環境上のサーバだとしても、最後には自分達の手で管理しているという自覚と責任をもって運用しなければなりません。

30

ユーザへ推奨する運用管理の在り方

• 本当に自分達にクラウドが必要かなのかという点については、慎重に検討することも大切です。

• ただし、DevOpsやアジャイルな開発/運用を目指す

場合においては、クラウドは間違いなく向いていると思います。

31

参考資料

• 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

参考資料

• 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