少人数で大規模環境運用には監視運用の効率化は必須
Yahoo! JAPANの月間800億ページビューを支えるIaaS基盤の舞台裏

運用編の紹介

奥野修平氏（以下、奥野）：それでは運用編をお話しします。

まず私の自己紹介をさせてください。私は2014年にヤフー株式会社に新卒で入社しまして、プライベートクラウドに一貫して従事しています、奥野と申します。よろしくお願いします。

それでは運用編のアジェンダです。まず守りの運用として監視・アラート対応編で1つ。こちらは少ない人数でいかに大規模環境を運用するかのために工夫している点を何点か紹介いたします。もう1つは攻めの運用として仮想化推進編です。こちらは新しい技術を積極的に試してさまざまなVMを受け入れていくという話になります。

監視・アラート対応のチーム体制

では監視・アラート編についてお話しします。その前に現在のチーム体制について簡単に説明させてください。人数としては20人強で、タスクとしては検証、開発、構築、運用すべてをやっています。またその内容としては仮想化全般、及び周辺システムになります。仮想化全般と申しますと、コンピュート、ストレージ、ネットワークの仮想化に関わることすべて行っています。

ここで指す周辺システムとはDNSであったりとか提供するWeb UIであったりとか、その辺のプライベートクラウドを提供する上で必要な周辺システムを指しています。この中で運用というタスクは非常に重要ですが、やはり他のタスクも重要ですので、ここで運用のタスクは減らしていきたいので、いかに減らすための工夫をしているかということを話していきます。

ただ20人強でプライベートクラウドを運用しているといっても、IaaSのすべてをプライベートクラウドチームで見ているわけではありません。ネットワークであったりストレージであったり、ラックであったりとかは専用のチームがいまして、そこでスイッチの面倒を見たりストレージの面倒を見たりラックの面倒を見ていただき、我々はそのいただいたリソースを基にOpenStackを構築しています。

構築したOpenStackは通常のユーザーにも使っていただくのですが、CaaSであったりPaaSであったり、そういったプラットフォームの方々にも提供して使っていただいています。DBチームにはOpenStackのTroveを使っていただき、Database as a Service等を提供しています。

現在の規模のおさらいです。ここでおさらいしておきたいのは20人強でクラスタ202、ハイパーバイザー2万台以上を運用しているということをもう一度。

アラートに対する工夫

3番目にアラート対応を常に見直すということ挙げています。内容としては監視の内容は現在のままで必要十分であるかを定期的に見直ししているということになります。

アラートを出さないようにする

これについては別の発表で詳細に話していますので、今回については軽く触るだけでスキップいたします。

アラート対応を減らす

次にアラート対応を減らすという点についてお話しします。これは正確にはアラート対応の手間を減らすというか、不必要な作業を減らすのが本質になります。実際にハイパーバイザー障害を例に話してみたいと思います。我々の一般的なフローではハイパーバイザーに障害が発生しますと、現地や監視側にまず連絡がいきます。その後クラウドチームに連絡が来て、我々が状況を確認して現地に調査依頼等を出すことになります。

ただこちらのフローを見ていただければわかるんですが、我々のクラウドチームは連絡をもらって依頼を出すという、ただプロキシするようなかたちになっています。こういったプロキシは不要なのでできるだけ減らしていきたいので改善を行っています。

こちらが改善後のフローになります。具体的にどのように改善したかと言いますと、クラウドチームに連絡なしでハイパーバイザー障害を検知・監視のみで復旧できるような体制づくりを行いました。もちろん監視や現地の人はハイパーバイザーにログインすることは一切できないです。

フローとしては、ハイパーバイザーがダウンしました。そうしたら現地や監視側に連絡がいきます。その後現地や監視側はもうすぐにそのハイパーバイザーの筐体調査を行うというフローになります。その後筐体の調査が完了し、電源が入るようになって電源を入れてもらう。電源が入ると同時にシェルが走り、そのシェルが走り切ったら復旧というかたちになります。

それで起動するだけでサービスイン可能なハイパーバイザーを作ることが今回のフロー改善の1つ。もう1つがログインできない人でもハイパーバイザーの復旧状況がわかるようなWeb UIを作成し提供したことで、このようなフローを作ることができました。この結果、我々クラウドチームにまったく連絡がなくてもハイパーバイザーが現地の監視対応だけで完結するようなフロー作りができると。

アラートを定期的に見直す

3番目にアラート内容を定期的に見直すということをやっています。監視の内容は常に追加が行われます。これはやはり何か問題があったときに足りないものであるとか、大きなシステムや機能が入ったときにガバッと追加が入ることが多いです。そのため監視が過剰に入るということが大いにあります。

ただこれは漏れるよりは全然いいと考えています。ただやっぱり見直さないと監視はどんどん不要なものが増えていくということがあります。体系的に入れられないので、こういった二重で監視する、三重で監視するので不要なアラートが出てくるということがあります。

どのような頻度で見直しを行っているかと言いますと、およそ四半期や半期に1回程度です。30件ぐらいの監視が廃止になることもあります。やっぱり実際に監視を入れて見ると「この監視いらなかったね」ということが大いにしてあります。これもよいと思っていまして、漏れるよりはやはり全然いいです。やっぱり監視はその時々によって必要な内容は異なりますので、状況によって常に見直しを行っています。

アラート・監視編のまとめ

アラート・監視編のまとめです。アラートを出さないようにする、アラート対応を減らす、アラートを常に見直すということを心がけながら、少人数で大規模環境を運用するということを行っています。

仮想化しなければならない理由

次に仮想化推進編です。こちらは攻めの運用として、積極的に新しい技術を取り入れていろいろなVMを受け入れるという話です。

そもそも少人数で効率よく運用するためには、当然同じような構成ばかりのほうがいいんですね。同じようなconfigで同じようなサーバ、そうすれば1つのパターンでどれだけ増えようがあまり手間がかからないということになります。

ただ実際にはそういうことはなくて、いろいろな構成が必要になります。なぜならば、どのようなワークロードのVMでも収容しなければならないというミッションがあるからです。

なんでそこまでしてVMにしなきゃいけないの？　というのがまず疑問にあるかと思います。大きく3つ理由がありまして、1つはVM化して可搬性を高くする。リサイズであるとかマイグレーションしてVMの抽象度を上げてユーザーメリットを出すのが1つあります。もう1つ、ユーザーはハードウェア管理から解放されて手間がなくなるのがあります。この2つはパブリッククラウドでもよく言われるメリットかと思います。

3つ目が我々プライベートクラウド環境でけっこう重要なのですが、コスト・DC運用的にもVM化するとやはり優位な点があるからです。具体的に申しますと仮に2016年製のベアメタルサーバ群が3ラックあったとして、これを2019年製のハイパーバイザーでVM化すると1ラックで収まってしまうという例は往々にしてあります。

社内にはハイパーバイザー以外のベアメタルサーバはまだまだいっぱいありますので、VM化してラックを圧縮してコストパフォーマンスを最適化するというメリットがあります。

パフォーマンスの最適化

そのためにはどんなサーバでもVM化できなければなりません。CPUが重要なサーバ、ネットワークレイテンシが重要なサーバ等々、どんなサーバでも受け入れる必要があります。そのために我々はユーザーのためにパフォーマンスの最適化を行います。

例えばハイパーバイザーのC-Stateの状況をユーザーのワークロードに合わせて最適化するとか、そういったハイパーバイザーの設定を個々に変えてユーザーの納得のいくパフォーマンスの出るようなハイパーバイザーの提供を行います。その結果、専用環境が増えていったりします。

どういった流れで、この専用環境が増えていくのかを例にしてお話しします。まずユーザーからVM化に際しての要望や要件が上がります。どんな要望かというと、とてもネットワークレイテンシが重要であったり、ハイパーバイザーでファイアウォールをかけてほしいであったり、1VMで25G、100Gのネットワークトラフィックを出したい、さらにCPUもいっぱい使いたいといった要望です。

当然我々としてはちょっと頭を悩ませて、普通のクラスタだったらとても条件に合わないですね。NICはパススルーしないとそれだけトラフィックは出ないだろうし。ハイパーバイザーでファイアウォールをかけるとなるとOvSのflow rule等で制御しないといけない。CPUもpinningとかをしないといけないし、というのでいろいろ頭を悩ませます。

我々は検証、開発、運用の全部をやっていますから、「検証中のあのシステムを入れてみよう」となります。具体的にNICはSR-IOVでパススルーして直接見せます。ファイアウォールはOVS-TCでNICにオフロードしてトラフィックとかも十分確保できるようにします。CPUをガッツリ使いたいよね、ノイジーネイバーが出ないようにCPUもpinningします。

その結果、ユーザーから従来環境より1.5倍以上の性能が出ましたという報告をいただいています。

新しい技術の導入

こういったいろいろな環境を作っていくと専用環境は増えていきます。ただ、やはりこういうのはすべてユーザーのためです。ユーザーのためにいいハイパーバイザー、いい環境を提供することを行っています。こういった厳しい要求は我々の新しい技術に挑戦できる場でもあるんですね。具体的に、ざっくり挙げるとOVS-TCだったりvGPU、VPP等を新しい環境で試して導入しています。

こういった多様な環境を管理するためにはInfrastructure as a codeは必須になります。

さっき挙げた技術はどういうところに使っているかを簡単に紹介いたします。OVS-TCはHadoopのパイプラインの一部で使用されています。vGPUに関しては機械学習用社内プラットフォームで利用されています。VPPは社内のソフトウェアロードバランサで使用されています。

仮想化推進のまとめ

仮想化推進のまとめです。オンプレ環境のいいところは伸ばしていきたいです。それはどういったものかと言うとユーザーに適した環境を提供し、ユーザーとともにパフォーマンスを最適化しお互いに満足のコストパフォーマンスのいい環境を提供していくことです。もう1つは新しい技術を積極的に試していくということを行っています。それをやることによって、我々の受け入れの幅は広がりますので、我々もよいですしユーザーにとってもよいことであります。

運用編のまとめ

運用編のまとめです。少ない人数で大規模環境を運用するためには監視運用の効率化は必須です。また、どんなVMでも受け入れるために専用環境を構築してユーザーとともに最適化を行っています。または積極的に新しい技術を導入して試していたりもします。

総まとめ

発表の全体のまとめです。プライベートクラウドではやはりコストメリットを出すために集約率は非常に重要になります。ユーザーのために、ユーザードリブンで新しい技術にも積極的に対応して導入・検証等を行っています。やはりコストとユーザーメリットのバランスを考えてなんでもかんでも受け入れるのではなくて、お互いに満足できる位置を探しつつ、導入・運用を行っています。

以上で発表を終わります。ご清聴ありがとうございました。