セキュリティ対応自動化の一連の流れ
安達寛之氏：では、次にセキュリティ対応の自動化について話をしたいと思います。まずみなさん、セキュリティ対応ってちゃんとできていますか？ 「できている」「ちゃんとやってます」っていう方は、すばらしいと思います（笑）。
一方で、やらないといけないのはわかっているんだけど、「クローズドな環境だから」とか、「他に優先すべきことがあるから」といったことで、できてない方もいらっしゃるんじゃないかなと思います。
弊社では、YJ-CSIRTという社内のセキュリティを一元的に管理する部署があり、その指示のもと、期限を決めて対応しています。とはいえ、数千台あるサーバーのそれぞれの種類に応じて期限内に人の手で適切に対応するというのは非常に難しい状況です。ですので、これも自動化というか、ワンコマンド化しました。
先ほどと同じように、DataNodeとかNodeManagerといったスレーブノード群もそうですし、NameNodeやResourceManagerなどのマスター系のものであったり、HiveServer2のようなロードバランシングしてるツールのサーバーなど、それぞれに応じて自動化しました。これについては本番環境で稼働させています。
DataNode、NodeManagerの脆弱性対応を自動化
まずDataNode、NodeManagerの脆弱性対応の自動化についてご紹介します。
少し細かくなって申し訳ないんですが、最初にDataNodeとNodeManagerのサービスアウトを行います。NodeManagerにラベルという機能がありまして、それを付けたノードに新しいジョブがアサインされないようにします。
そのうえで、DataNodeをデコミッション。つまり、持っているデータを他にコピーさせて、そのノードを外すための準備を開始させて、あとはラベル付けしたそのNodeManagerによって実行されているジョブがなくなるまで待って、今度はNodeManagerも外し、DataNodeのデコミッションが完了するのを待つ、といったようなことを行います。
完全に持っているデータがアクセスされない状況になって、処理も実行されない状況になったということを確認して、セキュリティアップデートを適用して、そのサーバーをリブートします。それが完了したら、DataNode、NodeManagerをサービスインさせるという順番で、処理を行ってます。これをHadoopの処理に影響を与えない程度の単位で自動化し、順番に処理していっています。
次に、NameNodeの脆弱性対応の自動化ですが、HadoopのNameNodeはアクティブのものとスタンバイのものでHA構成になっています。この2台と、あとはコールドスタンバイ用のサーバーというのを使って、上から順番に実行していきます。
まずはコールドスタンバイに、セキュリティアップデートを適用します。その後、スタンバイのNameNodeからメタデータをコピーして、コールドスタンバイがNameNodeとして使えるような状態にします。そして、スタンバイのNameNodeを停止します。
その後、スタンバイのNameNodeに割り当てているVIP、バーチャルホスト名をこっちのコールドスタンバイのほうに付け替えて、利用者から……というかHadoopクラスタとしてみた時に、そのアクセスポイントは変わらないようにしてます。その状態でコールドスタンバイをスタンバイNameNodeとして起動します。
セキュリティ対応自動化の効果
それら一連の作業が問題なく動作することを確認した後で、今度はアクティブのNameNodeとコールドスタンバイのNameNodeをフェイルオーバーさせて入れ替えて、今度は一番左のアクティブのNameNodeに対するアップデートを提供していくといったようなかたちで、NameNodeを止めることなく安全に脆弱性対応をしています。
このあたりの、例えばメタデータのコピーやVIPの付け替えみたいなところについては、手順化してきちんとまとめていたりしても、どうしてもミスしたり時間かかってしまったりするようなところがあると思うんですけど、そういったところを自動化して、ちゃんと安全にツール内でチェックしつつ、できるだけ早くこの入れ替え作業などを行えるようにしています。
次にHiveServer2。先ほど申し上げたように、このHiveServer2などのツール系のサーバーは、ロードバランシングして運用していて、ユーザーはこのロードバランサ―のDNS名に対してアクセスをしてます。
あるHiveServer2でジョブが実行されているという状況で、このHiveServer2をいったんロードバランサーから外します。
ただし、この上で実行されているジョブはまだ動き続けているので、それが終わるまで待って、完了したらセキュリティアップデートをします。
この間、ロードバランサーからは外れてるので、新しいジョブがアサインされることはなく、ユーザー影響はないという状態になってます。バージョンアップが完了したらここに戻す、という感じです。
このようにしてセキュリティ対応を自動化したことにより、運用工数の削減に大きく貢献しました。運用者としては1回つくってしまえばコンポーネントごとにワンコマンドで実行すればいい状況になります。
また、安全にオペレーションを実行することができます。人の手で全部やってしまうと、このセキュリティ対応が期限内に終わらないんですけれど、自動化だとそのplaybookを実行して放置しておけばいいので、昼夜を問わずでき、ちゃんと期限内にセキュリティ対応ができるという効果を発揮してます。
不良ノードの対応
3つ目の不良ノード対応についてです。背景として、数百台あるいは1,000台以上のサーバーを運用していると、やっぱり普通に壊れます。
だいたいディスクとメモリがエラーになります。それによって、HDFSのブロックが壊れてデータが読めなくなったり、特定のマウントしてるパスにライブラリを配置してたりするんですけれども、運悪くそこが壊れてしまうと、そのライブラリが読めなくなって、Hadoopのタスクが失敗するといったようなことが起きます。
また、どういう状態になったらこのサーバーをサービスアウトするかという、明確な判断基準がなかったりということもあって、これもちゃんとしたいという背景もありました。
それに対しては、非常に単純なんですけれど、dmesgなどのハードウェアエラーのメッセージをもとにそれぞれの種類に応じてスコアリングし、それを足し上げて閾値を超えたら筐体不良であるとみなしています。
仕組みとしては各DataNodeとかNodeManagerのサーバーにインストールされているAmbariエージェントから、これらのスコアをAmbariサーバーにレポートして、オペレーション用のサーバーから定期的にその数値を取ってきて、閾値を超えていればデコミッションすべきだというふうにAPIから指示を出して、それを外すというようなことをやっています。
この効果として、まずSLAの維持ができるということがあります。自動的にこれを判断してくれるので、故障を早期に検出して、順番に修理に出すことができます。ですので、いきなりその台数が減ってしまうというようなことがなくて、性能を保つということができています。
もう1つ、これまでと同じように運用工数の削減ができます。人の手でサービスアウトをするという作業が減ったりだとか、あとは、この不良ノードに起因した問い合わせ対応が少なくなる、といったような効果が期待されます。
現在の課題からはじめよう
これらの運用の自動化全体を振り返ってみてどうだったかというと、私は自動化するツールを開発するチームにいて、開発環境、ステージング、そして本番と、運用チームの人と協力してリリースしていくんですけども。やっぱり運用チームが直面している課題というのが、受け入れられやすかったです。
どうしても開発していく中で、あれもこれもだったりとか、「こういうケースもあるよね」って未来のことを考えたり、あとは過去起きた問題に対してだとか、そういったものもやるんですけれども、それらよりもやはり現在の課題っていうのが受け入れられやすくて、そういうところから徐々に歩調を合わせていくのが良さそうだな、と感じています。
「まずはスモールスタートから」と書いているのは、いきなり大量に自動化するというと、やはり不安に感じられるんですね。ですので、できるだけ小さいケースで自動化の効果が確認できるところに持っていってから、徐々に機能を拡大していくといい感じに働いています。
また、あって便利だったなと思っているのが、リードオンリーモードです。先ほどの自動のサービスアウトとかだと、いきなりそれを本番でやると怖いというのもありますし。
とはいえ、開発環境だとかステージングの環境では起きなくて、本番の環境でしか起きてないハードウェア障害といったようなものもあるので、そこのスコアリングはするけど、サービスアウトはせずに、単にbot的に通知・速報するだけとか、そういった挙動をオンラインで変更できるようにしていたりするとけっこう便利でした。
今後の成長に向けた取り組み
というところで最後に、これからの成長に向けて思ってることを少しお話しさせていただきます。
まずはデータ基盤についてなんですけれども、これからもやはりデータ量というのはどんどん増加していくと考えていますし、実際そうなっています。これはHadoopに限らないんですけれど、新しくワシントン州にデータセンターを建設していて、そういったところで規模を大きくしてこれからもデータ基盤全体を運用していきます。
あとは、Erasure Codingという機能がHadoopにあるんですけれども、これを使うとデータ量を普通に単純にファイルを複製するのと比べると抑えることができるので、今後Hadoop 3.0を使用するとなってきた時に、これを使ってデータの増加に耐えられるようにしていきたいな、と思っています。
また、NameNodeの負荷対策というのを現在やっていて。Log Aggregationといって、Hadoop上で実行されたジョブのログをHDFSに書くという処理があるんですけれども、この書き込み処理があまりに同時に起きすぎて、Hadoop上で動いてるジョブによってHadoopが殺されてしまう現象が起きました。なので、今、それ専用のHadoopクラスタをつくって、そちらにオフロードするというようなことをやってます。
これも新しいHadoopのバージョンではFederationという機能があって、NameNodeが管理する領域をそれぞれ分けるといったことができます。それでわざわざ小さいHadoopクラスタ立ててオフロードするなんてことはしなくていいんじゃないかな、と期待しています。
その他に、まだまだHadoopは実際の物理的なサーバーの上で動かしていますが、コンテナ技術との連携であったり、機械学習フレームワークの導入であったり、あとはHadoopからGPUを使うといったことも、今後できるようになっていく見込みなので。そういったものの導入をしたりなど、いろいろありますけれども、どんどんこのデータ基盤も拡大していくかな、と感じています。
また、運用体制としてもスケーラブルにしていかないといけない、と今感じています。先ほど言ったように、Hadoopにせよデータ基盤にせよ、どんどんこれから大きくなっていくことが見込まれているんですが、一方で、クラスタが大きくなるからといってそれと同じだけ人が増やせるかっていうと、そんなことはないので（笑）。スケーラブルにしていかないといけないです。
本日のまとめ
これまでも自動化してきましたけど、やっぱり自動化できるものは自動化するであったりとか、あとは共通化ですね。我々のチームでは、さっきのHadoopクラスタだけではなく、他にもいくつかのHadoopクラスタを管理してるんですけど、意外と共通化できてなかったりするのでそういったところをちゃんと共通化していき、スケールするようにする必要があると感じています。
あとは、Infrastructure as Codeですね。「おまえ、今さら何言ってんだ」って感じがするかもしれないんですけども（笑）、オンプレでHadoopクラスタみたいなものを運用してると、なかなかこれができてないんです。
どうしてもサーバーの投入時期であったり、そのタイミングで運用してたメンバー、あと緊急対応で「一部のサーバーにだけこの機能をリリースします」みたいなことがあったりで、個別にサーバーごとに変更が加えられていて、もはや状態がバラバラになっちゃってます。
一度そうなってしまうと、先ほどやったような自動化でなにか変更を加えようとなった時に、不統一の状態なので「なにかがぶっ壊れてしまうかもしれない」みたいな不安感が先に来てしまい、変えることができないといった状態になります。
自動化ツールで変えられないので、人ががんばってそれに対応する、そしてまた不統一感が出てきて……という悪循環になっていくので、やはりどこかのタイミングで1回ちゃんとコード化して、変化を恐れないというか、それをくり返しデプロイすることで、恐れなくてもいいようにしていく必要があると感じてます。
ということで、取り組みの内容を少しまとめますと、我々のチームではHadoopの運用の自動化というのに取り組んでいました。バージョンアップであったり、セキュリティ対応であったり、不良ノード対応であったりといったことの自動化に取り組みました。
今後は、データ基盤と運用をよりスケーラブルにしていかないといけないと感じていて、そのために先ほど紹介したようないろんな取り組みをしています。といったところで、発表を終わらせていただきます。どうもありがとうございました。
（会場拍手）
