年間で1,000万件ものアラート　疲弊する現場を救う、コンテナ時代の運用管理

コンテナ技術でクラウドの運用はどうなるか

福原亮氏：みなさんこんにちは。（セミナーの）最後は、私から「クラウドの運用はどうなっていくのか」についてお話しさせていただきます。

誤解のないように申し上げますと、ここで言う運用はいわゆるコンテナ自身の「運用」だけじゃなくて、システム運用全般のところについての「運用」と捉えていただければと思います。

まず自己紹介です。（私は）もともとデータセンターのオペレーターをやっていまして、監視・運用だけで今まで生きてきました。

このスライドに載っているバスは僕の自家用車で、今年の夏に会社の人間とキャンプに行ってきた写真です。8月の末だったんですけど、なぜか栗がたくさん落ちている。夏なんですけど、よくわからない。「そんな寒かったっけ」と思いつつ（笑）。

週末はそんなことをしながら、今日ご紹介するIIJのサービス開発の責任者をやっています。

まず「アウトソーシングって何だったっけ？」ですが、これは釈迦に説法かもしれません。ご存知ない方もいらっしゃるかもしれませんけど、IIJはけっこう前からアウトソーシングをやっていまして。かれこれ10数年、僕が入社する前からやっているんですよ。

ここでは細かくご説明しませんが、いわゆるマルチクラウドの運用管理サービスです。まさに流行りですね。それから自動オペレーション。最近はRBAと言ったりします。クラウド型なのでSaaSで提供しています。この中身が一体何なのかを、今日これから順次ご紹介をさせていただきます。

年間に1,000万件ものアラート

まずこちらのスライドです。1,000万件というのは、私どものサービスで受けているアラートの年間件数です。いつも申し上げるんですが、あまり誇れる数字ではないですね。アラートが1,000万件も来る。「1日何件来てんだ!?」みたいな。

僕のメールボックスには、日にだいたい5,000～1万通くらい来ますけど、それよりはるかに多い（笑）。とんでもないアラートが出ているのが事実ですね。そうなってくると人件費や管理をどうするかが問題になってくると思います。

我々の現場がこうなっているとは言いにくいですが、みなさまもそうかもしれません。システムがどんどん増え続けていて、IT人口が減少していますから。

意外とあるあるな話なんですが、これが今日のテーマであるコンテナ技術が入ってくるとどう変わるのかを見ていきたいと思います。

状況をもう1回見ていくと、システムはAWS、Azure、Google。IIJも「GIO」というクラウドサービスをやっています。それからオンプレもありますよね。こういったものがどんどん増えていく中で、当然メールや基幹系のWebのシステムなどが、どんどん増えていく実感はあるかと思います。

もう1つ、IT人口は減少しています。日本の総人口もそうなんですけど、ITの人口がどんどん減っていく。減っていくだけじゃなくて高齢化している。どんどん高齢化していくことが統計として挙がっています。

こんな中でITシステム運用をしている現場が何をしているのかと言うと、（エラーのあった）メールを一生懸命管理するために、エクセルに細かく転記をしている。でも、たまに漏れて上司に怒られるみたいな。意外とこういうことやっていませんか？

最近お客様のところへお邪魔してサービス紹介をするときに、「転記やっていませんか？」と聞きます。転記をやっている会社もいますけど、それすらやっていない会社が圧倒的に多いです。

メールボックスにたくさんアラートメールが溜まっているだけの方が一番多いです。がんばろうとしてエクセルにするんだけど、がんばりきれない。「どうしようかな」という人のほうが圧倒的に多いです。

必要かもしれないですけど、効率的ではないです。ましてや生産的な活動でもない。こんなことは単純に面倒ですよね。

アラートの実態には3つの特徴がある

どうしても疑問になるのは、「我々のようなITの現場にいる人間はこのままでいいんでしょうか？」ということです。答えはわかっていて、いいわけないです。

そもそもシステムの保守・運用が何をしているのかを見ていくと、残念ながら障害が発生してしまいましたと。その障害（への対応）がいるのか、いらないのかを仕分けして、調査して、「どうしようかな」と検討して復旧させる。一般的にはこんな感じですよね。

アラートが発生してしまう理由を私どもの中で調査してみたんですが、大きくこんな感じで3つくらいに分かれます。

開発している人が「ごめん、メンテナンスしてた」。アプリケーション担当者に「ごめん、バグが入ってたのでアクセスするといろいろ出てしまう」。データベースが落ちてしまったので「ごめん、同じ障害だった」。そんなことがたくさんありました。

それがどれくらいなのかというと、なんと97パーセント。けっこう驚愕の数字だと思います。先ほど申し上げた、年間1,000万件あるアラートの97パーセントは、970万件です。この970万件はいらないんですよ。なぜなら対応が必要ないから。対応しなくていい。

振り分けた結果、捨てているだけのものがこれだけありました。本質的には障害を出さなければいいし、アラートは削減すればいい。そのとおりなんですけど、意外とそうじゃない現場のほうが多かったりするんですね。心当たりがありませんか？

ホワイトリスト的な形式でアラートを判定

我々がどうしてきたかと言うと、いらないものはいらないので、できれば機械的に捨てたい。僕らはフィルターと呼んでますけど、まず最初にそのアラートがいるのか、いらないのか、要否の判定をシステムで機械的にやっていきます。

これはファイアウォールに例えて言うと、ホワイトリスト的な形式になります。運用者からすると僕的には画期的だと思うんですけどね。なぜか？　基本アラートは全部受け付けるのが普通ですから。

でもこの仕組みは全部受けて全部捨てるんですね。なぜならホワイトリストだから。まず、ファイアウォールみたいに必要なものだけ、パーミットしてあげます。

もしくは、あらかじめメンテナンスとわかっているのであれば、ある一定期間特定のアラートを一番目に要否判定します。

続いて重複の排除。データベースでたくさん出てしまうものに対しては同一の障害ということで、5分単位でキュッとまとめてしまう。つまり、重複排除をしてあげましょう。

障害を検知したら誰かに伝える、教える、通知することなどは、最後にやらなければならない。そして、エクセルに書くのではなく、チケットを起票することは別に機械でもできますよね。そういうことをIIJとしては取り組んできています。

どんな感じかと言うと、これは画面のイメージですけれども。メールとかで入ってきた障害、AWSのpingの障害、そしてプロセスの障害などがあります。こうしたときにどうしますか？　

リストの一番上はなにも指定してない。捨てる。メールから来ても捨てます。リスト二番目のpingの障害が来たらどうしますか？　「メールと電話をしてください」「メールとSlackを送ってください」みたいな。

どこにどういう連絡をするかをホワイトリスト形式で登録してしまえばいい。発想としてはけっこう安直です。

障害回復の代表的な手順

フィルタリングできたとして、次はどうやって障害を回復するか。IIJはずっとアウトソーシングをやってきましたけど、そんな中の代表的な手順はスライドのとおりです。

Windowsのサービス起動を説明するまでもないですけど、Web画面でサービスのストップ、スタートを押すのがWindowsのサービス起動です。

Unixのプロセス起動は、スタートスクリプトを叩く手順だけです。こんなことがアウトソーシングの中では蔓延しています。

このスライドは、とある月で実際にどれくらいの手順書を使ったかを集計したリアルな数字です。横軸は手順書の種類で、縦軸は実行回数です。

一番左を見てください。実行回数が4,500回くらいになってますね。つまり1本の手順書を月に4,500回も実行した。じゃあ一番右側と言うと1回だけ実行したというのが一番右側です。

しかも、横軸は全部足しても180本しかないんです。ちなみに、IIJで今アウトソーシング等々を請け負っていて、だいたい数百社のお客さんがいらっしゃいます。手順書の数は5万本くらいあるんですよ。5万本あって180本しか使ってなかった。

これを比率にすると99.6パーセントを使ってない、ということですね。

結局手順書の内容がこういう状況なので、プロセスを再起動するのであれば、リモートでログインしてプロセスの再起動をすればよくないですか？　ワードできっちり起こした手順書でもやることですから。

RBAは、けっこう前から流行っていて、去年か今年くらいでピークになっていますが、たぶんPBAほどはいらないんですね。RBAが悪いとは言ってないですが、実際に必要とされている機能はさほど多くないんです。

アラートのフィルターでビジネス規模拡大

こんなことをずっとIIJではやってきていまして。その結果、どうなっているのかを示した数字がこれです。

左側はアラートをフィルタリングした結果を指したものです。フィルターに引っかかった97パーセントがゴミでしたが、全部はフィルターが無理でした。しかし、94パーセントくらいは機械的にバサッと消せました。

でも、まだ残りが6パーセントあります。この6パーセントの中の半分くらい、つまり48パーセントが機械的にオペレーションできた。トータルで見ると97パーセントくらいが自動化したことが今のIIJの実態です。

ビジネス的にはどうだったか。その結果として、お客さんの運用対象ノードが今10万台くらいありますが、アラートの97パーセントを削減しています。

一番いいことは1人あたりが5倍のお客様を持てるようになったことです。届いたアラートのいる・いらないを見ていたのを、機械に置き換えた。単純オペレーションを機械に乗せましたので、やらなきゃいけない目の前のオペレーションに専念できるようになった。

やはりアウトソーシングビジネスをやっている僕たち、もしくはアウトソーシングではなくインソース型であっても、この手のアラートの仕分け作業をされている方はたくさんいると思います。そういう方々のビジネス規模や生産性を上げることができると思います。

機械化した結果、思わぬことがいろいろありました。例えばこちらでは、チケッティングのシステムが連動しています。オペレーションは機械でやっているものですから、いつ・どこで・誰に電話したことや、オペレーションしたことなどが、タイムラインで自動で書けるようになりました。ログを持っていますからね。

監視もしっかりすると、監視しているキャパシティーデータをもとにして未来を予測してみることなどできます。

これはAIではないんですが、予測してみることもできます。

月次報告書を作るのが面倒くさいのであれば、レポーティングも自動でできます。

いろいろなデータがあると、こんなことがホイホイできるようになってくる。言われてみればそりゃそうですよね。人がやると大変なんですけど、機械だとすぐにできてしまう。

オンプレ、Iaas、コンテナのイメージは若干異なる

こんなことをやって生まれてきたのがIIJ統合運用管理サービスです。「UOM」と僕らは呼んでいます。昨日今日で完成したのではなくて、いろいろな失敗をしながら気がついたらここまで成長してきた。このサービスそのものを今日ご紹介せずに、ここで終わりにします。

今日の本題はコンテナです。コンテナがなにかについては別のセッションで触れられているので、私からは触れないですが、私が今お話したような流れで、従来のノリでいけるのかが僕自身もまだまだ疑問なところがあるんですね。

そこで、我々はどうしていくのかについてこれからお話しします。おもしろいなと思うんですが、（オンプレ、Iaas、コンテナのイメージについて）みなさんが描いている絵が微妙にみんな違います。この絵が正しいかどうかは置いておきますが、みんな違うんですよね。変遷でいくと、オンプレやIaaS、PaaS、SaaS、コンテナがあります。

ざっくり運用者の視点から見るとどうか。開発者ではなく、運用者から見ると、オンプレは実は楽なんですよ。IaaSはまあまあわかりやすい。コンテナになると正直よくわからないとという気がします。

順次見ていきますと、例えば、オンプレの構成は変わらない。上から下まで全部管理対象だし、自動化しようと思ったらがんばればできるのがオンプレの特徴です。

スライドの63パーセントという数字は「オンプレがこの先増えますか？　減りますか？」というアンケートの答えですね。63パーセントが「たぶんこのままオンプレ使います」と言っています。意外と「へ～」ですよね。

オンプレの監視や運用について

オンプレの監視をどうするか？　ご存知のとおりですね。UOMでも監視できますが、JP1やZABBIX、Nagiosなど、いろいろなオープンソースもあって、ずっとオンプレの環境に対して見にいくので、当然、従来型の仕組みでできます。

オンプレの運用は？　プロセスやサービスの再起動とかクラスタの切り替えですね。クラスタサービスとか入っているかもしれないですけども。

こういったものを、いわゆる手順書ベースでやっていくのが基本的な考え方です。最近はRBAでコマンドラインを自動化していく感じになってきました。

地味にオンプレで面倒なのは、閉域接続をどうするのか。だいたいオンプレですから、自分たちの箱の中にものが作られていきますからね。

そこに対して我々みたいにアウトソーシングする人たちは、リモートから入らないと仕事できないので、接続する回線を作らないといけない。一般的には閉域接続や広域イーサなどでつないでいきますけど。

各社のモニターツール活用事例

こちらはIaaSです。ご存知のとおり、スライドでは年率20パーセントくらいで成長することが示してあります。20パーセントではなく、もっとすごい数字を示しているところもたくさんあります。成長しているという意味ではみなさんのご理解のとおりですね。

IaaSは作る側からしてみたら動的に構成が変わったりすることもあって、いい面もあります。運用から見て、いいところはOSより下は基本的に見ない。

また、意外とAPIが出てくるので、自動化はしやすいです。コマンドラインじゃなくてAPIを実行すると、いろいろできるのが大きな特徴です。

IaaSを監視しようと思ったら、あまり気になくても従来型の監視システムでだいたいできます。OSが見えているので、エージェントを突っ込んだり、リモートでログインができますね。オンプレかどうかは、あまり考えないですね。あまり問題にならないです。

強いて言えば、VMwareなどを使った場合にハイパーバイザーの監視をどうするのか？　弊社はVMwareベースの「VWシリーズ」を提供しています。

こういったESXiに対するログの監視は、APIベースで取ります。リソース、ログ、構成情報を取るのなど、今はこういったものも必要ですね。

だんだんレイヤーが最近になってきました。PaaSやSaaSなど、言い方はいろいろありますけど、こうなってくるとどうなるのか？　実は先ほど出てきたような監視ツールで監視はできないです。なぜか？　それぞれ各パーツでしかないことを考えると、そもそもログインでできないからです。

そのため、我々としては、どうしようとしているか。AzureMonitorやStackdriver、CloudWatchなど、各社がいろいろなモニターツールを出されていますけど、そういったところと連携させようとしています。

例えば、メールやAPIで取り込む。CloudWatchはUOMでは標準的にメトリックを取れたりします。こういったものがないとPaaSやSaaSを見られないです。

ただ、ご注意いただきたいのはSaaSやPaaSを細かく下まで見る必要があるのか？　ということが本質的にあります。オンプレと同じように全部見なきゃいけないというのは少し間違っています。そこはご留意ください。

閉域接続のメリット・デメリット

それでは、IaaSの運用の話に戻します。基本的にはリモートログインベースでやっていくのはいいと思います。オンプレと同じです。しかし、APIが出ていますから、各社のAPIをうまく使っていくほうが楽だと私は思っています。

我々としては今ちょうど作りかけたところではありますが、年明けくらいに各社のクラウドをCLIベースで実行できるものを順次リリースすることにしています。コマンドラインでオペレーションする時代ではないと思っているので、こういうふうにしていくのは必然だと思っています。

そしてIaaSの接続が難儀です。AzureやAWS、GCPなどがあったときに、これとどうやってつなぐのかがなかなか難しいんですね。例えば、IIJだとExpressRouteでAzureにつなぐことや、DirectConnectでAWSをつなぐことはもうできています。

そのため、監視の仕組みであるUOMもこういったものに接続すべく、近々リリースします。マルチクラウドへの接続はやはり必要ですよね。

ただご存知の方もいらっしゃいますが、これらの接続はコストが高いんですよ。コストを重視するなら、VPNという選択もなくはないですが、VPNはなかなか設定が面倒くさいです。できないことはないですけど、ちょっとハードルが高いと思います。

ちなみに「IIJ GIO」というブランドでやっています。プライベートリソースをVMwareベースで作っているのがありますが、こういったものはIIJの中だと標準接続でプライベートでつながれています。これは宣伝ですけど、そんなこともやっています。

コンテナ管理を自動化する重要性

そしてついにコンテナまでたどり着きました。最近の話ですね。いろいろなものがどんどん変えられる。すぐ作って潰せるのがいいところですよね。コンテナ自身が管理してくれます。この状況下でコンテナをどうやって監視しますか？　

結論ですが、従来の監視じゃ無理です。やってやれないことはないですが……。スクラッチ＆ビルドされるものに対して、監視を1個1個すれば可能だと思います。

しかし、何の意味もないですよね。今日のコンテナの講演を聞いていただいたら、みなさんわかると思います。違う方式を考えざるを得ないと思います。

じゃあどうするか。コンテナはコンテナ自身で見てくれますから、コンテナ自身が見てくれた情報を集めるものが必要じゃないですか？　自分で見に行く時代はそろそろ終わりだと思います。

コンテナから来る矢印が（今までと違って）逆になっているんですね。これは情報を拾ってあげる受け口がないと運用できなくなりませんか？　さらに運用するときには従来型のログインする作業はできないことはないですが、やはり難しいんじゃないかと思います。

そもそもコンテナ自身が管理してくれているんですから、いっそのこと任せてしまったらどうでしょうか？　運用屋の私が言うのもどうかと思いますが、たくさんコンテナ（の接続）を切りますから、従来通りでやるのは無理です。1個1個手順書作るのは絶対あり得ないですよね。

管理してくれているコンテナ自身を制御する方向に持っていくなど、もっと上段の管理が必要。すなわち統合的な運用を考えないといけないなと思っています。

そういったコンテナへの接続はどうするのか。インターネットで接続するのもいいかもしれないですけど、やはり閉域がいいですよね。ずっと運用をやってきた僕としてはやはり閉域が一番だと思います。

マルチクラウド時代の運用管理をどうするか

こうして、いろいろな状況を見てきました。クラウドは多様化しています。そして、複数のクラウドが使われます。

これは弊社のお客さんのアンケートです。73パーセントくらいのお客さんが「いろいろなクラウドを一緒に使います」とおっしゃっています。我々のお客さんなので、GIOを使ってくれると一番ありがたいんですけど、そういうお客さんはあまりいないんです。いろいろなクラウドを一緒に使っています。

なぜか。「各社さんがいろいろな長所があるじゃないですか」「どこか1択より、あれとこれを使いたくなりますよね」。当然だと思います。どうしてもマルチクラウド化は避けられないんですね。

そこに今日のお題です。コンテナが入ってきたとなると、冒頭の絵と似ていますが、オンプレやメガクラウドがあって、その上にコンテナなどがあります。いろいろなところに行ったりするわけですよね。オンプレまで降ってくると、とてつもなく複雑ですよね。運用屋としてはあまり考えたくない状況ですね。

簡単に言えば、各社さんでできることがバラバラになってきています。それぞれできることが違うので、これをどうにかまとめる仕組みが必要ですね。

マルチクラウド時代の運用管理をどうしていくか。ざっくり絵で描きました。統合管理をするためのツールを置かないとやはり厳しいでしょう。

その下にぶら下がらなきゃいけないものは各メガクラウドやオンプレ、そのほかに拠点やVPN設備もあるので、いろいろなものにつながらないといけないです。

なぜならばシングルで使う人は絶対いないですし、オンプレもなくならないですから。運用管理する人たちはどこかを見ていればよいですが、絶対ならないです。統合的に見ないと疲弊します。

どうやるかと言うと、IIJはネットワークの会社なので「IIJ Omnibus」という接続サービスがあります。こういったネットワークサービスと組み合わせていただくことでいわゆるメガクラウドと接続できて、オンプレとも接続できます。WANの構成でも、拠点でも接続できます。そういったところまで考えていかないと、この先の運用者はいろいろなツールを見なきゃいけないですからね。

今日のセミナーでご紹介があったいろいろなツールは、みんなそれぞれ個性があってすごくいいと思います。しかし、それを全部知っていて、運用するかと言うと難しい気がします。