![エンタープライズIT [COLUMNS]](https://ent.iij.ad.jp/wp-content/themes/liquid-smart-child/img/logo.svg){kind=logo}
2018年11月開催のマジセミ…
コンテナ技術でクラウドの運用はどうなる？ ｰ 前編
2018年11月開催のマジセミ「Docker、Kubernetesなど「コンテナ技術」のクラウドサービス（AWS、Azure、Google Cloud）での活用と、コンテナ時代のシステム運用」での講演内容をご紹介します。仮想化技術であるコンテナの運用現場について語りました。
コンテナ技術でクラウドの運用はどうなるか
福原亮：みなさんこんにちは。私からは「クラウドの運用はどうなっていくのか」についてお話しさせていただきます。
誤解のないように申し上げますと、ここで言う運用はいわゆるコンテナ自身の「運用」だけじゃなくて、システム運用全般のところについての「運用」と捉えていただければと思います。
まず自己紹介です。私はもともとデータセンターのオペレーターをやっていまして、監視・運用だけで今まで生きてきました。
このスライドに載っているバスは僕の自家用車で、今年の夏に会社の人間とキャンプに行ってきた写真です。8月の末だったんですけど、なぜか栗がたくさん落ちている。
夏なんですけど、よくわからない。「そんな寒かったっけ」と思いつつ（笑）。
週末はそんなことをしながら、今回ご紹介するIIJのサービス開発の責任者をやっています。
まず「アウトソーシングって何だったっけ？」ですが、これは釈迦に説法かもしれません。ご存知ない方もいらっしゃるかもしれませんけど、IIJはけっこう前からアウトソーシングをやっていまして。かれこれ10数年、僕が入社する前からやっているんですよ。
ここでは細かくご説明しませんが、いわゆるマルチクラウドの運用管理サービスです。まさに流行りですね。それから自動オペレーション。最近はRBAと言ったりします。クラウド型なのでSaaSで提供しています。この中身が一体何なのかを、今回これから順次ご紹介をさせていただきます。
年間に1,000万件ものアラート
まずこちらのスライドです。1,000万件というのは、私どものサービスで受けているアラートの年間件数です。いつも申し上げるんですが、あまり誇れる数字ではないですね。アラートが1,000万件も来る。「1日何件来てんだ!?」 みたいな。
僕のメールボックスには、日にだいたい5,000～1万通くらい来ますけど、それよりはるかに多い（笑）。とんでもないアラートが出ているのが事実ですね。そうなってくると人件費や管理をどうするかが問題になってくると思います。
我々の現場がこうなっているとは言いにくいですが、みなさまもそうかもしれません。システムがどんどん増え続けていて、IT人口が減少していますから。
意外とあるあるな話なんですが、これが今回のテーマであるコンテナ技術が入ってくるとどう変わるのかを見ていきたいと思います。
状況をもう1回見ていくと、システムはAWS、Azure、Google。IIJも「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」と僕らは呼んでいます。昨日今日で完成したのではなくて、いろいろな失敗をしながら気がついたらここまで成長してきた。このサービスそのものを今回はご紹介せずに、ここで終わりにします。