インフラ監視の「ぴえん（;_;）」を解消　Kubernetesにおけるプライベートクラウドの監視術

プライベートクラウドの監視術

中西建登氏：みなさん監視ってされていますでしょうか？　我々はプライベートクラウドを運用しているんですけれども、このビデオを見ている方々はけっこういろいろな立場がいらっしゃると思います。

アプリケーション、例えばtoCのサービスを開発されている方もいると思いますし、toBのアプリケーションを開発されている方、いろいろな方がいらっしゃると思うんですけど、やっぱりいろいろなところで監視って必要になってくるかなと思います。

例えばアプリケーションを開発されている方であれば、ユーザーさんのリクエストに対してちゃんと返せているのかという監視をやっている場合もあると思います。そして例えばtoBのサービスも同じく、会社の人たちがアクセスしてきたものを監視するというようなのをやっているかと思います。

我々も社外に対してサービスを提供しているという立場でプライベートクラウドというのを意識しています。先ほども言ったとおり、APIによっていろいろと（機能を）提供しているんですけれども、例えば「そのAPIのリクエストがちゃんと通るんだっけ？」という話であったりとか、例えば、いろいろなネットワークの機器とか、さまざまなものを監視しています。

インフラ監視のぴえん(;_;)

インフラの監視ってけっこうつらい面があると思っています。もちろんアプリケーションの監視もつらいと思うんですけれども、（インフラでは）物理的な故障というのはけっこう起こり得ます。

例えばTop of Lackのスイッチが2つあって2つとも壊れましたといった時は、もうそのラック全体が障害になってしまいます。

ラックの監視をしていて、もちろんその下に挿さっているそれぞれCompute Nodeの監視もしている。そのCompute Nodeの中にあるプロセスももちろん監視している。というような感じですごい細かく監視項目を設定している場合、ラック全体が障害になってしまうと、それが全部アラートになってしまうと、ものすごい量のアラートになってしまうんですね。

例えばメールで受けている場合であるとか、最近であればSlackやチャットツールに対してアラートを流すということをやられている方も多いと思うんですけれども、そのメールサーバがそもそも耐えきれなくなっちゃうぐらいメールが配送されたりだとか。

それからSlackには通知した時にあまりにも通知数が多すぎるといったんもうそれ以上通知しなくなるというような機能があるんですけれども、本当にそのぐらいのレベルの投稿数が投稿されてしまうというぐらいにアラートが爆発してしまうということがわりと起こり得るんじゃないかなと思います。

また、監視の数も相当多くなっていたり……。ネットワークの都合で例えば踏み台経由で監視したりすると思うんですけれども、その時にもうメトリクスが多すぎる。例えばZabbixなんかは全部メトリクスをDBに保存したりしていますけれども、それもメトリクスが多くなると、DBサーバのスペックが相当要求されるとか、そういったような背景があると思っていて、そういったところでかなり負荷が強くなってしまうのではないかと。

どこまでの冗長化が必要か

そういった監視ツールを起動させるということはやると思うんですけれども、そういった時に「どこまで冗長すれば監視サーバって冗長できたと言えるんだっけ？」的なところもあると思っていて、やっぱりプライベートクラウドみたいな少しレイヤーの低いようなところを扱っていると、どこまで壊れるのかというのはいろいろ考えると思います。

例えばもうデータセンターが全部落ちちゃいましたという時になると、もうラックを冗長して監視サーバを立てていたとしても、「もうそもそもそいつらって動かないですよね」みたいな話になったりとか。もっと言えば、例えば東京で大きな震災が発生してしまった場合に、大阪に置いておかないと駄目ですよねとか。

いろいろ考えていて、これっていったい……。「でも、そんなに冗長って必要なの？」みたいな話がもちろんあって、「いったいどこまでやればいいんですかね？」みたいな話があると思います。やっぱりこのへんも「ぴえん(;_;)ですよね」となると思います。

でも、やっぱりやらなきゃならないというのは間違いなくあって、そういった時にやっぱり便利なものに乗っかりたいというのが人間の性（さが）でございます。

インフラ周りに便利なKubernetes

最近のインフラ周りにおいて便利なものといいますと、もう猫も杓子もKubernetesかなと。これは間違いないことだなと思います。コンテナを便利に管理してくれるGoogleが作ったプロダクトですけれども、これはもうみんな使っているのではないかなと思っています。

以前「builderscon tokyo 2019」というようなイベントがあっとき、これを使って便利にプライベートクラウドをやっていますというのを「なぜディスクレスハイパーバイザに至ったのか」として発表しました。「ディスクレスハイパーバイザ」とかで検索していただくとたぶん出てくると思います。

見ていない方ももちろんいると思うので、ある程度おさらいしたいと思います。

これがプライベートクラウドの全体的な概要図です。1個1個説明すると、下側の部分、赤いところですね。一番下は先ほど書いてあったんですけれども、Compute Nodeかk8s master。これは我々が「k8s master」呼んでいる物理的な筐体なんですけれども、これがそれぞれKubernetesのノードとして管理しています。

これは先ほど言ったとおり、Bearmanによって2段階目のOSとしてCompute Node用のプロファイルを設定してあったりとか、k8s masterのプロファイルを設定してあったりとかがあります。

そこからKubernetesを使ってPodを起動できるんですけれども、OpenStackやいろいろなプロセスを起動させる必要があると思います。Nova APIであるとかCinder APIであるとかっていうコントロールプレーンのところもそうですし、Compute Node上に起動させないといけないnova-computeとかNeutralのエージェントとかあると思います。我々はそれをKubernetesのPodとして定義して運用しています。

こうすることによって、例えばコントローラのAPIが1つ落ちてしまったという時には、自動的にPodが復旧してくれますし、リスタートなども完全にかけられるため、かなり自動的に回復するプライベートクラウドを運用できています。

そこから、nova-computeがCompute Node上で動いていて、それが下にあるlibvirtと連携してユーザー用のVMを起動するということをやっています。そこの上でユーザーさんがいろいろなサービスを展開しているというのが、この概要図です。

我々、特にCompute Nodeの部分なんですけれども、それをディスクレスで運用しています。ディスクレスは何かというと、そのCompute Nodeに対して物理的なストレージというのをつけていないんですね。こうすることによってオンメモリに起動するので、何らかの障害があった時にもう完全にハイパーバイザーは自動的に復活する。これはBearmanの2段階目のOSの部分になるんですけれども、自動的に復旧する。

ユーザーさんのVMに関してはiSCSIでのディスクの接続を行っているので、それに関してはデータを救うことができるというふうな設計をとっています。これはBearmanと連携することによって本当に簡単に復旧することになるので、あんまり故障とか障害というのにも恐れずに対応できるようになっています。

これは先ほどの図をCompute Nodeというふうに書き換えた図です。CentOSで起動してきたあとに、我々はUbuntuを利用しているんですけれども、これをメモリ上に展開します。そのメモリ上で展開したOSからさまざまなlibvirtdであるとか。これはkubelet経由で起動したnova-computeが叩くんですけれども、それからユーザーのVMが起動する。ストレージはiSCSI経由なので安心というふうになっています。

監視プロダクト「Prometheus」

これの監視についてなんですけれども、我々としてはPrometheusというようなプロダクトを使っています。特徴はいろいろあるんですけれども、我々のメリットとしてはKubernetesのサポートがかなり充実しているというところと、exporterを自分で開発できる。これはちょっと後ほどにあるんですけれども。というところをメリットとして挙げています。

ログ監視というのは現状していないです。ただOpenStackは、すごい量のログを吐きます。特に我々もうデバッグログ吐かないとやっていられないのでデバッグログを吐いているのですが、それは全部Fluentd経由でKubernetesがDockerコンテナが吐いたログを吸収して、それをFluentd経由でVM上に流しています。だいたい5分か10分ぐらいにローテートしているぐらいにはやらないとストレージの容量が厳しいぐらいには激しい量を吐いています。

Prometheusには、いろいろ特徴があるんですけれども、Golangで作ったプル型のモニタリングツールになっています。動的な設定変更ができるというのがすごく大きくて、KubernetesのPodなどを自動的に検知できるというのをやっています。

我々の規模感なんですけれども、ターゲット数がだいたい2.7K個ぐらい監視していて、メトリクス数でいうとだいたい5Mぐらいで監視しています。

これは1週間の値にさっきの同じメトリクスを変えたものなんですけれども、なんかピョコンと出ているところがありますよね。これは何だろうなと思って調べたんですけれども、実は新しいコンテナのデプロイをしていた時に起きたことで。

Prometheusでは、先ほど動的な変更ができるという話をしたと思うんですけれども、これも同じところです。なので、Prometheusの設定変更とかを特にしていないんだけど、コンテナを新しくデプロイすることによってこういったふうにピョコンと上がるというふうな現象を観測。

先ほど言ったとおり、その監視対象、exporterと呼ぶんですけれども、これもKubernetesのPodとして展開していまして、これがちょっと見たところですね。「prd-metrics-prometheus-exporter」というのでノード情報を管理できたりしています。

Prometheus自体はすべてVMにデプロイしていて、コンフィグは全部AnsibleのJinja2を使って監視しています。先ほど言ったとおり、主にKubernetes連携でのターゲット監視というのをやったりしています。だいたい設定のymlファイルは2,300行くらい書いていますね。

自作exporterもけっこういろいろありまして、このような感じでいくつか開発しています。

自作exporterとは何かというと、Prometheusからリクエストが飛んできた時にそれへ返答するというようなものになっています。けっこういろいろできるので、metrics format、つまり数字になればなんでも監視できるというところで、けっこう便利に使っています。

どういうモチベーションがあるか。例えば世の中にこのexporterがまだ存在していないだとか、障害の再発検知用に使っているとか、あと世にあるOSSのexporter、同じようなのがあるんだけど、大規模な環境を想定していなくて、特にプライベートクラウドになるとすごい数が多くなったりすることがあって、あまりこれ大きくならないよねというのがあったりするので、その結果、世のexporterだと耐えきれないというのがいくつかあります。

その例をいくつか紹介しますが、これがlibvirt_exporterです。OSS版が存在するんですけれども、novaと連携してVMを起動させた時に、nova専用のattributeというのがlibvirtのXMLにつくんですけれども、これがOSS版では少ししか対応できていない。特に、novaのdisplay_nameとかっていうのが出てこなかったりしますね。

そして我々はCPUのPinningを行っているんですけれども、そのPinningもあまり監視できていなくて。これはちょっとCPUのPinningを……novaの部分がちょっとバグっていたことがあってそれで障害が起きたことがあったので、それを検知したいと。なにかそういったおかしな状態になっていないかというのをPrometheusで監視したいので、そういったもので自作したりしています。

dirty-flow-exporterというのは、これは完全に障害の再発検知用のものですね。Open vSwitchに挿入するflowがおかしいという障害が発生してしまいまして、これの即検知をしたいというために「自作でexporterを書くぞ！」というような気持ちになっています。

流れとしては書いてあるとおりなんですけれども、ovs-ofctlのdump-flowsを打って、そこからおかしいフローがないかというのを検知して、おかしいフローがあるとメトリクスとして投げるというようなことをやっています。そうすることによって、dirty flow、おかしいフローが上がったのが、1上がった瞬間に「しきい値超えたね」っていってアラートを流すというようなことができます。

このへんは、かなりメリットだと思っていて、アプリケーションの正常性をチェックするのはもちろんなんですけれども、全部メトリクスに落とし込んで全部アラートを監視することによって、人間のチェックだけじゃなくてちゃんとPrometheusという監視ツールがそういった再発の検知とかもできるようになるというのがけっこう大きいところです。

特に自作のexporterを使っていろいろ監視して可視化もできるようになっているので、何が起こったのか、この時何が起こっていたのかというのがいろいろな観点から見れるというところが大きなメリットになっています。これでインフラエンジニアが安心して眠れるように……なったのかな？　ちょっと怪しいんですけど、まぁ、なったと思っています（笑）。

まとめ

最後、まとめです。Cycloudにおいて行っている日々の運用や監視について紹介しました。

それぞれBearmanとPrometheusを使ってこういうふうにやっているよというのを説明しました。低いレイヤーでもうまくコード化することによって安全に運転を行えるように、なれるように、これからも「ぴえん（;_;）」しないような取り組みを続けていきたいと思っています。

宣伝

最後の宣伝です。「We are Hiring！」ということで、ぜひぜひみなさん興味あればお声がけいただければと思います。連絡先、ちょっと適当にインターネットを探して連絡してください。

そして我々、「ISUCON10」というのものにインフラ提供して、これは絶賛開発中でございます。これもぜひ楽しみにしてもらえればと思います。

以上で発表は終了です。ありがとうございました。