アジェンダと自己紹介
森田亙昭氏（以下、森田）：みなさんこんにちは。森田と申します。今日はクラウド運用者として、私が経験したエピソードを共有したいと思います。20分程度のお付き合いとなりますが、よろしくお願いします。
それではさっそくですが、今回は、「KCPSの運用で直面した仮想化基盤拡大に伴う課題と対策」というタイトルで発表します。アジェンダですが、KCPSの概要と運用で直面した課題、運用経験を活かした課題解決の順に説明します。
まずは自己紹介をします。私は2003年にKDDIに入社し開発業務に従事してきましたが、2012年からクラウド設備であるKCPS（KDDI Cloud Platform Service）の担当として、運用業務に携わっています。約8年間にわたり、クラウドオペレーターとして、さまざまな苦労を味わいながら改善を実施してきました。
次にクラウドオペレーターとしての私の立ち位置を知ってもらうために、KCPSに関わる運用体制を紹介します。KCPSを含め、KDDIが提供する設備については、24時間365日で監視をする監視部隊がいて、各システムで起きた異常の検知および復旧対応を行っています。
その後ろにシステムごとの専任担当がいて、監視からのエスカレーションのサポートや改善したマニュアルの提供といった、品質向上のためのアクションを行っています。私はこのKCPS専任担当のチームリーダーをやっていて、言うなればKCPSの品質に絶対の責任を持つ立場です。
KCPSの2つの特徴
ここからは、KCPSのサービスの内容について紹介したいと思います。まずKCPSとは何かですが、KCPSはKDDIクラウドプラットフォームサービスの略です。一言で言うと、KDDIが通信キャリアとして提供するクラウドサービスになります。細かい内容については割愛しますが、特徴についてはここで紹介したいと思います。
その特徴としてはネットワーク親和性と、運用・サポートという2点があります。これでお客さまに安全と安心を提供しています。
まず1つ目の特徴であるネットワーク親和性ですが、KCPSは通信キャリアが提供するクラウドサービスですので、自社の通信インフラを利用したサービス提供を実施しています。そのため、無料で安定したネットワークが利用できる強みがあります。
もう1つの特徴の運用・サポートは、これまで通信キャリアとしてライフライン関連のサービスなど、非常に厳しいSLAを守るための運用を実施してきています。そのために作り上げられた体制とノウハウがKCPSにも適用されているため、結果として非常に充実した通信サービスレベルのサポートを提供できています。
こういった点から、KCPSはQuality Cloudというコンセプトでサービスを提供しています。
このサービスは安心して利用できるクラウドとして評価され、2012年のサービス開始以降、多数のご利用があり国内で最大級のクラウドに成長しています。このような背景があるので、KCPSとしては品質をいかに高い水準に保ち続けるかが、運用者としての絶対的な使命となっています。
KCPSの運用で直面した2つの課題
そんな中、KCPSの運用で直面してきた課題について説明したいと思います。課題としては2つあり、まず1つ目を紹介します。
背景には、設備規模の拡大があります。これはクラウド設備のインフラあるあるですが、利用するお客さまが増えれば増えるほど、設備の規模が拡大していきます。サイト冗長を考慮した東西両拠点への配備や、サーバー、ネットワーク、ストレージといった多種多様なコンポーネントの導入も起因して、KCPS最大級となったこのサービスを支えるために、かなりの規模の機器数が必要になっています。
そんな中、1つ目に発生した課題は、システムの設備数が増えれば増えるほど、発生するアラーム数が右肩上がりに増加していくことです。
機器が増えてハードウェア故障が増えることは仕方ないですが、その機器から通知される異常は、1機器あたり1件とは限りません。そのため、設備数が増えるスピードよりも早くアラーム数がどんどん増えていき、結果として監視者が対応すべきアラームが急増してしまいました。
そして次の課題は、こちらの背景もクラウドインフラでよくある話ですが、クラウド設備は絶え間なくインフラを提供し続ける必要があるので、構成機器のジェネレーションも日々変化し続けています。
例えば、増設契機で新しい機種を導入したり、設備の更改、バグ改修のためのバージョンアップの実施など、安定したインフラリソースを提供するために、継続的に更新し続けています。
この変化し続けるジェネレーションによって発生するのが、もう1つの課題です。これまで機器が増えてアラーム数が増えてくると、対策としてアラーム数を減らす対応を実施してきました。発生したアラームを分析し、必要性を判断することによって、要らないアラームは2度と出さなくする。こういったことに時間をかけて、何度も繰り返してきました。
しかし、どれだけアラームを抑止しても、ここで機器のジェネレーションによる課題が発生します。新しい機器では通知内容が丸ごと変わってしまい、これまでがんばって潰してきたアラームがすべてなかったことにされて、初めから対応をやり直すという、イタチごっこに陥ってしまう課題がありました。
これまでの課題を整理すると、設備の拡大に合わせて増え続ける故障対応。あとは設備のジェネレーションの移り変わりによって、実施するアラーム削減が追いつかないという2点の課題がありました。
最初に述べたとおり、KCPSはQuality Cloudとして品質を重視してきたクラウドになります。今回のような運用稼働が増え続ける状態が続くと、高い品質を維持できなくなってしまうという、非常に悩ましい状況に直面しています。これが私が運用を通じて直面した課題でした。
運用業務の見直しで得た2つの気づき
次にこの直面した課題について、専任担当として実施してきた対策について説明したいと思います。まずは自分自身を知るということで、業務分析を開始しました。業務分析をして、改善前の運用方法がどうなっていたかについてお話しします。
まず1つ目は、これまで構成機器すべてから何でもかんでもアラームを出して、それを監視担当者が1件1件マニュアルに沿って正常性の状態を確認し、故障かどうかを判断することを実施してきていました。これが1つ目です。
改善前の運用方法2つ目ですが、ハードウェアは故障が起きたら必ず即時交換を実施していました。アラームが上がって調べた結果、「ハードウェアが故障しているよ」ということがわかった時点で、もう有無を言わさずすぐに対応を進めていました。
この2点の状況を改めて認識したうえで、このやり方にはけっこう無駄があるのではないか、という気づきがありました。
気づきその1です。まずなんでも通知して人力で対応するという監視のやり方ですが、こちらはマニュアルに沿って対応した結果、正常性に問題がないのにアラームを通知してくる。対応不要なのにいろいろな切り分けを実施しているというケースがとても多く、実に発生したアラームの半数以上が最終的には対処不要というものでした。
そのため、そもそもこういった対応不要なアラーム自体をなくして、本当に故障の時だけアラームを鳴らすべきではないか、という考えに至っています。
気づきのその2ですが、ハードウェア故障時に即時で対応していた件についてです。クラウドインフラは、比較的冗長度を高く構築しているものも多いのですが、そういった冗長度の高さにかかわらず、なんでもかんでも交換をしていました。
例えば2台中の1台が壊れた場合、これは当然急いで交換するべきですが、10台あってそのうちの1台が壊れてもまだ残り9台ある場合、こういった時でも即時交換を実施していた状況でした。
このハードウェア交換対応は、故障した部位の冗長度に応じて対応緊急度が変わるのがあるべきかたちではないか、という考えに至っています。
このように、不要な対応と即時交換という2つの無駄が見えてきましたので、そこから何かできることはないかと、改めて対策の検討を開始しました。
具体的な対策
検討した結果、実施することに決めた対策の2つを紹介します。
まず1つ目の対策ですが、これまで人手でやっていたアラームごとに用意したマニュアルに従って1つ1つの状態確認と正常性判断を実施する業務を、すべて監視のイチ機能として組み込もうと考えました。
（スライドを指して）こちらの図では、上段がこれまでのやり方、下段が今回考えたやり方です。これまで何でもかんでも人手でやっていた対応を、新たに機能を作り、状態取得と正常性の判断を実施しました。結果として「異常だよ」と判断されたものだけをアラームとして通知する、いわゆる「正常性監視機能」を実現しました。
この正常性監視機能ですが、KCPSの選任担当としての経験と知識をフル活用して作り上げています。これまでの対応の経験とナレッジを元にした、何を見ればすべての状態を網羅できるか。また、その把握した状態からどうなっていたら正常と判断できるか。このコマンドとシナリオ、これを組み合わせて新たな正常性監視ツールを作り出しました。
この画面に出ているような状態を取得して、正常性の判断を行い、結果として異常があるかないか、対処が必要かどうかを判断する、正常性監視機能を実現しています。
次に2つ目の対策になりますが、こちらは、ハードウェア交換稼働を減らすために、冗長度を監視して、緊急性に応じた対応判断を実施しています。
対策としては、故障した機器について、まず故障した部位が何で、その冗長度がどうなっているのか。そしてその冗長度の結果として、リスク状況はどうなのかを判断する冗長度監視機能を導入しています。
この監視によって冗長度が低く、すぐに対応が必要なもののみアラームを通知し、それ以外は翌日以降でまとめて対応するかたちを採用しています。
この冗長度監視機能の構築に関してですが、こちらも選任担当としての知識を活用しました。設備の構成、特にパーツまで掘り下げた細かい冗長度と、それがどれくらいの台数の冗長度を組んでいるか。壊れたらどういったリスクがあるかをもとに、機能を構築しています。
例えばディスクが1台壊れたが全20台あるうえに、さらに予備のディスクは4つある場合はまだ冗長度は高いので、即時対応は要らないといった判断を自動で実施できるようになりました。
実現した監視方式の2点を整理すると、これまではなんでも飛んできたアラームを人手で確認して、異常とわかったものはすべて即時交換を実施してきていました。しかし、今回追加した機能、「正常性監視」と「冗長度監視」によって、まずは故障対応が必要なもののみを検出して通知し、その中でもさらに冗長度に応じて即時対応が必要なのか、後で対応すればいいのかを判断して、今やらなければいけないものだけを通知してくれる機能を実現しましたす。
この監視方式の実現によって、これまで稼働に悩まされていたアラーム数と対応時間が大幅に削減ができました。アラーム数では90パーセントの削減、対応時間でも70パーセントの削減に成功しています。
検知漏れへの対策
今説明したとおり、稼働の削減には無事に成功しましたが、まだ終わりではありません。なぜかと言いますと、我々はQuality Cloudを運用していますので、そのクオリティを考えた時に1つ気になるポイントがありました。
ツールが定期的に動いて正常性をチェックするうえで、検知の漏れがないかという点です。例えば定期的に動く間に発生したアラームを、間欠的なアラームとして拾えなかったら困るのではないかということです。
その対応として統計監視を入れています。こちらは機能として停止したアラームを収集、分析することで、検知漏れに対応しています。
すべてのアラームをストップすることをまずやりましたが、何でもかんでもストップして切り捨てるというわけではなく、ストップしたアラームの情報をいったんログとして保存します。そして保存した内容を分析する方法を採っています。
分析した結果として、例えばDown／Upが繰り返し発生しているような、正常性監視で拾えてはいないものの、なんらかの対処が必要なものをアラームとして通知する対応を、この統計監視で実現しています。
この統計監視の機能についても、これまでの運用者としての知識、経験を元にしています。どのようなアラームをこの統計監視に適用すべきか。あとは発生頻度に応じてどういった対応を緊急度として設定すべきかをもとに、ツールを作り込んでいます。
例えばネットワークが1ヶ月に2回、同じポートで停止した場合は、予防交換を実施する。5分に5回連続して同じポートのDown／Upが出るような場合は、これはもう状態の異常と判断して即時対応を行うなどです。こういった統計監視機能を実現することで、アラームの漏れ、予兆の検知が実現できました。
3つの監視機能で稼働の削減と品質の維持を実現
まとめとして、今回は3つの監視機能を導入したことについて説明しました。1つがアラーム監視から移行した正常性監視。2つ目がハードウェアの交換の時に導入した冗長度の監視。そして最後に、検知漏れを防止するための統計監視。この3つによって、大幅な稼働の削減と、品質の維持を実現しています。
それぞれの監視のポイントですが、まず1つ目は、正常性監視の移行について、機器を導入する時に何を見て、何をもって正常と判断するのか。2つ目の冗長度監視に関しては、冗長構成を正確に把握し、即時交換となる条件を定義しておくこと。
3つ目の統計監視については、間欠的に発生するアラームについて、対応の要否とその発生頻度による緊急度をしっかりと定義すること。このポイントを掲げて、3つの監視を成功させたことが、今回の成果となっています。
最後に、今回かなり稼働の削減と品質の維持と改善を進めてきましたが、今後もお客さまに安心して利用してもらえるよう、KCPSの品質向上に努めますという宣言をして、本プレゼンの締めとします。ご清聴ありがとうございました。
