こんにちは。斎藤です。
前回につづき、当社で実践しているITインフラ構築・運用の自動化やコード化のお話になります。今回は、hb-acns(あくねす、といいます)といって、当社の監視・メトリック取得設定の自動化を行う内製のシステムについてご紹介します。
※最後にお知らせがあります
TL;DR
- データセンタ・IaaS事業者が入り乱れている中で、既存ツールで自動化するのが難しかった。また、既存業務をできる限り維持したい。そこで内製した。
- hb-acns は軽量なエージェントとサーバで構成される。そのうえで、既存の監視システムに設定を自動登録できるシステムとなっている。
- 監視設定時間が1/10に短縮されるなど、大きな導入効果が得られた。
- Issue, PRベースで開発を進めることで、利用者が自分のツールとして理解し、利用するようになり、そして改善に協力してもらえた。
動機
幾多にもある案件をどうこなすか
当社はMSPとして、数多くのお客様の物理サーバ・IaaS インスタンスの運用を行っています。この状況には、以下の3つの特徴があります。
- データセンタの場所がバラバラ。同一のお客様でも違う場合がある。
- IaaS 事業者がバラバラ。同一のお客様でも違う場合がある。
- サーバ構成や導入しているミドルウェアの種類がバラバラ。
以上の状況下で、当社では全て自前で設置・運用しているNagiosサーバ(2015年6月現在 4.0系)で監視を行い、一部の案件はCactiでメトリックを収集しています。従って、お客様毎に違う環境がある中で、いかに同じ監視基盤を利用しながら効率よくセットアップを進められるかは積年の課題となっていました。大規模案件でインストール作業の自動化にある程度効果がある案件ならまだしも、中小規模かつ複数の案件を同時にこなす場合は自動化のメリットが出しづらく、効率の良い構築が行いづらい状況にありました。
さらに、2010年代に入ってからのIaaSの勃興によってサーバの構築量・速度ともにスピードが上がってきており、日に各社合計数百台を構築することも珍しくない当社にとって、監視設定の効率化は早急に解決すべき課題として持ち上がってきました。
既存の業務といかにバランスを取るか
先ほど当社ではNagiosを利用しているとお話ししました。さらに、当社はNagiosをベースにした運用監視の業務体制が確立しており、この状況がお客様に対し安定した運用監視を行える基盤として成立しています。
一方、Pushベースで監視項目追加が実施できるツールとして、ZabbixやSensuがあります。また、サーバの増減に対して柔軟に対応できるツールとして、Consulも登場しています。ここには挙げていませんが、他にもツールがどんどん出てきています。
しかし、Nagios から運用管理ツールを切り替えることは、社内の基幹業務を大きく変えることにつながります。これは、当社の運営の根幹に関わることでして、極めて慎重に考慮しなければならないことでした。可能であれば、業務フローへの影響を小さく抑えながら、業務効率を上げて行くことが理想でした。
従って、新しいツールを導入するには、容易ではない状況にありました。
ツールの選択ではなく開発に踏み切る
以上より、「様々な環境に対しての監視設定の効率化」と「既存業務への影響を最小限にする」という2つの課題を同時に解決することが求められました。
その上で、CTOの馬場と私が決めた方針は、後にhb-acnsとなるシステムを内製することでした。
一般的には、既存のソフトウェアを活用して導入することがリードタイムが短くよいとされています。恐らく、多くの業務はそれで良いかと思います。しかし、当社の場合は監視業務は基幹業務であり、現在の当社がお客様から最も求められている価値の部分となります。従って、先の2つの課題を同時に解決する手法が既存ツールにないとなると、内製してでも取り組むことで効率が出せるのではと考えたのです。
しくみ
全体像
hb-acnsは、既存の監視業務で利用しているNagios, Cactiに一切手を加えること無く、監視設定作業を自動化します。
ポイントは、監視対象サーバ(実際に業務を行っているWebサーバなど)と、hb-acnsサーバにあります。
まず、監視対象サーバには、hb-acns用のエージェント(以下、エージェント)を導入します。エージェントは、監視対象サーバにあらかじめhb-agentなどで設定されている監視設定を自動的に収集し、hb-acnsサーバに伝える役割を負っています。
次に、hb-acnsサーバは、エージェントから転送されてきた監視設定情報を基に、Nagios用の監視設定ファイル、そしてCactiのメトリック登録のための情報を生成します。そして、実際に監視設定を反映するには、当社で利用しているHipChatの業務用の部屋においてChatOps用コマンドを実行するように作ってあります。
特徴
エージェントですが、2つの特徴があります。
- Red Hat系OS(CentOS含む)にて追加ライブラリ無しで実行できる。
- インストールは社内RPMリポジトリからyumコマンド経由で可能。
1は、前回のhb-agentの説明でもお話ししたことなのですが、お客様のサーバ環境を汚さないことが大変重要になっています。そこで、Red Hat 系OSなら必ず導入されているPythonを利用して開発することで、この問題を解決しています。なお、エージェントはRed Hat Enterprise Linux 5系以上で実行可能となっています。
2は、導入が煩雑だと普及しません。そのため、RPM化してyumコマンドで導入できるようにしています。なお、hb-agentを利用していれば、エージェントも同時に導入されるようになっています。
続いて、hb-acnsサーバです。
技術的にはエージェントから情報が届いた段階で自動的に監視設定を登録することは可能なのですが、hb-acnsではそのようには行いませんでした。これは、構築担当者が意図したタイミングで監視を始められるようにしたためです。当社では「Enterを押したら戻れない」と新人研修で指導が徹底されており、このポリシーに沿ってツール側も安全側に振って設計をしています。
導入の流れ
数値の評価
- 3週間: 基本構想〜プロトタイプ完成まで。
- 1/10: パイロットプロジェクトで短縮できた監視設定時間。
- 3ヶ月: プロトタイプ完成〜全部署に普及するまでの期間。
3週間は、実際にCTOと開発を開始する約束をしてから仕上げるまでの時間となります。コードを書いている時間は1週間程度なのですが、それよりも設計やテストの方が時間がかかった、というのが実態です。
1/10は、これまで監視設定を登録するときに設定ファイルを起こしていた時間が無くなり、監視の疎通確認のみとなったためです。パイロットプロジェクトとして選定したプロジェクトは当社では大規模に当たる案件であったためもともと自動化はやや進んでいたのですが、それでも1/10に短縮できています。そのため、自動化が行いづらい中小規模の案件に対しての効果は更なるものになると期待できる数値でした。
3ヶ月は、プロトタイプ完成後、ハンズオンを通じて利用の説明を行い、最終的に各部署が利用し始めるまでの期間となります。ハンズオンの詳細は「ツール普及のために社内ハンズオンに取り組んでみた」でも取り上げていますが、一度触ることで「あっ、これは自分にも使えそう！」と感じてもらい、実際に業務で使ってもらえることへつなげる大変重要なプロセスとなっています。
作業内容の変化
構築作業に、次のような変化が起こりました。
- 設定ファイルのtypoがなくなる
- 設定ファイル作成漏れがなくなる
- 早く帰られるようになる
設定ファイルの作成は作業以上のものではなく、誰かに任せられるものであればそうすべきです。また、構築を担当できる技量のあるエンジニアが単純作業に時間を取られるのは大変もったいないことであります。そのようなものがほぼ0に削減できたことは非常に大きなものだと考えています。
日々の改善とその手法
他のツールでもそうなのですが、特にhb-acnsでは社内専用のGitLabをベースにしたIssue, Pull Request(PR)駆動での改善を行っています。これを通じてわかったことがあります。
- 「自分のこと」としてリクエストを出してくれるようになった
- 自分のツールとして使ってくれるようになった
- 当初はサポートできなかった例外に対してツールが強くなった
私のような横串を通す部門と、実際に業務を行う部門の間では、時として衝突や意識の齟齬が起こることがあります。これは、組織の大きな目的こそ同一ですが、喫緊に解決しなければならない問題に視点が行き過ぎる場合に起こると、私は考えています。その中で、実際に業務部門の人から出てくる意見をIssue, PRとして公開で吸い上げ、議論することでお互いに自分のこととして考えてくれるようになったのは、私個人としては非常に嬉しいのです。
その上で、無理の無い範囲で遅滞無く改善を進めることで、リクエストしてくれた業務部門の人との間で「話が通っている」という信頼関係を高めることにつなげるよう、努めている所です。また、意見が出るサイクルが回り出すと、hb-acns が当初サポートできていなかった境遇、いわゆる「例外」を埋めて行くことができ、ツールとしての完成度が上げられることにもつながっています。
この取り組みは、今現在も続いています。
今後の展望
hb-acnsですが、引き続き改善を進めて行く予定です。
一方で、IaaS ベースであること、そしてより速報性や自動化を推進される時代となっている今、抜本的な改革が必要であるとも考えています。そのあたりについては、また成果が出たら本ブログでご紹介したいと考えています。
まとめ
本記事では、監視・メトリック取得設定の自動化システム hb-acns についてのご紹介をしました。既存ツールでは当社の環境や業務に適応しづらいために内製したこと、監視対象サーバに手軽に導入できること、そして所要時間が1/10にできるパフォーマンス向上が確認できたことをお話ししました。また、Issue, PRベースでの開発は利用者を巻き込んで成長させやすいことをお話ししました。
ソフトウェア開発をやっていると、ついついいきなりコードを書き始めてしまうことがあります。しかし、既存のツールはそれなりに前提が練られており、周到な設計の上に完成されたものも少なくありません。また、メンテナンスも行き届いている可能性も高いのです。そのような背景がある上で内製をすることは、非常に挑戦的な仕事であったと考えています。
それではみなさま、ごきげんよう。
お知らせ: YAPC::Asia Tokyo 2015 トークへの投票をお願いします！
今年で一旦最後の開催になる、YAPC::Asia Tokyo 2015にて、「辛いことをやめる！から始まる業務改善とInfrastructure as Code」というタイトルでトークに応募しています。
このトークでは、ITインフラを取り巻く環境の変化、特にIaaSが普及したことによる業務内容の変化に対して、ハートビーツの社内でどのような取り組みを行ったかをお話ししたいと考えています。その中で、成功した話ばかりでなく、いろいろな失敗とその対策を含めて、組織全体をどのように変えて行ったのかに焦点を当てる予定です。
「組織での開発のやり方を変えたい」「部署横断的に業務改善に取り組んでみたい」そして「実際に取り組んでいるけどほかはどうやっているのだろう」と考えている方にお話しできたら幸いです。
このトーク、もし聞いてみたい・興味がある方は、ぜひプロポーザルをTwitterでシェア・Facebookのいいね！・はてブして頂けますと大変嬉しいです。ソーシャルメディアでのシェア数が採択の基準の一つになるようです。
どうぞよろしくお願いします。
