こんにちは。斎藤です。
私の記憶では2012年頃から盛り上がり始めた、ITインフラ構築・運用の自動化やコード化のお話ですが、その後みなさまどのような形で推進されていますか？あれから3年ほど経ちまして、当社でも取り組んできた内容を一旦棚卸しできるかなと考え始めています。そうそう、「MSPでのChefの使い方 --- 運用ノウハウをコードに落とす」という記事を書いた日から考えても、2年以上経っています。
そこで、何回かに分けまして、私が担当していたITインフラ構築・運用の自動化・コード化に関する取り組みについてご紹介していきます。
TL;DR
hb-agentは、「初期構築作業の自動化」「監視項目洗い出しの自動化」そして「ノウハウをコードに集約」を実現する社内ツールです。
導入を通じて、構築時間の短縮、ノウハウの共有がすすみました。その結果、新しいスタッフが入った時でも習熟度のぶれを押さえ、構築品質を担保しやすくなりました。
また、ハンズオンやドキュメンテーションを通じて利用を促進し、社内GitlabのIssueやPull Request(Merge Request)を通じて常に改善を続け、環境の変化に対応しています。
hb-agent とは？
3つの業務を持っています。
- 初期構築作業の自動化
- 監視項目洗い出しの自動化
- 以上に関するノウハウをコードに集約
当社はお客様からサーバをお預かりし、構築・運用・障害対応・コンサルティングを行っています。従って、自社サービスのようにある程度サーバ毎に業務が固定はしておらず、大規模案件でもない限り構成はほぼバラバラである事情があります。従って、自動化の際に「こういう構成だからこうだ」と決め打ちして構築することが難しいのです。
そこで、自動化を行うにあたっては、エンジニアの「判断」をコード化することが求められました。
hb-agent 導入前後比較
初期構築作業の自動化→構築時間短縮
以前は、社内に存在したいわゆる「秘伝の手順」を逐次入力することが求められました。これですと、1台構築するだけで待ち時間を含めて数時間かかり、同時に環境によって特別な判断が必要が求められることもありました。これは、コマンドを打ってパッケージをインストールするのを待ったり、設定ファイルを編集するなどしてじわじわと時間がかかっていたことによるものです。
hb-agentを導入した後は、「秘伝の手順」を利用した構築結果の状態にするまで 5倍程度早い 、数十分で実現できるようになりました。この短縮は、判断する→パッケージインストールコマンドを打つ→インストールを待つ、を繰り返す際のオーバーヘッドが削減されたことが大きいことによります。もちろん、設定ファイルの自動生成も貢献していると考えています。
監視項目洗い出しの自動化→監視品質向上
当社で監視項目を設定する際、以前は以下のような問題が存在していました。
- 人により監視設定にばらつきがある
- 必要な監視項目を見落とす
- 監視項目設定方法の新しいノウハウが拡散しない
1は、過去に監視設定を実施した実績を基に、新しい案件の監視設定を施す流れができていました。この「実績」の源流が人が増えますと1カ所ではなくなり、人によって違う設定が追加・変更されて行くようになります。ひょっとしたら、それぞれ説明可能な理由があって違う設定が施されているかもしれません。しかし、実際に通知が飛んだ際に一貫性がないと、設定を施していない担当者が監視通知を受け取ったときに、案件による食い違いに混乱してしまうかもしれません。
2は、ps やインストールしたパッケージを手動で洗い出していたため、必要な監視項目を見落とす可能性がありました。
3は、新しいミドルウェアや問題の事象を経験した際に監視設定を追加・強化を施します。理想は、その知見が遅滞無く全員に素早く共有されることですが、組織が大きくなりますと徐々にやりづらくなります。また、その知見が必要となるタイミングも数ヶ月ずれることもざらです。そうしますと、担当者毎に車輪の再発明が行われることになりかねません。
hb-agentを導入した後は、以上の状況は次の通り改善しました。
1は、Chefの監視設定(実際はNagios NRPEのnrpe.cfg)を自動生成するCookbookが、プロセス・待ち受けポート・インストール済みパッケージの情報を基にサーバの構成を棚卸しし、監視項目を生成しています。従って、人により監視設定のばらつきが起こることはほぼ無くなりました。案件毎の特殊な設定は、いわゆる".d"ディレクトリを用意して、自動生成のものとは別に準備しています。
2は、1とともに解決しました。
3は、改めに導入・強化した監視項目について、構築担当エンジニアから社内GitlabにIssueを立ててもらうことで、情報を得ています。その中で、利用されやすいものから順にChef Cookbookに実装して行きます。これで、ノウハウをコード化しつつ共有を進めています。
ノウハウをコードに集約→品質の安定化・スケーラビリティの強化
以前は、ノウハウの共有は社内勉強会や社内Wikiで行っていました。
hb-agent導入後は、さらにコードベースでノウハウを共有することができるようになりました。同時に、一通りのエンジニアが使うことで共通の結果が得られるようになったのは、先に述べた通りです。
また、hb-agentを導入することで、構築作業、特に初期の構築作業や監視設定の習熟度のぶれを低くすることができるようになりました。従って、新たに構築担当エンジニアになった方は、hb-agent内に構築された仕組みを通じて先輩に近い結果を得ることができ、担当者を増やしやすい状況を作ることができます。また、習熟した構築担当エンジニアは手間のかかる繰り返し作業から解放されるようになります。
hb-agentの内部構造
概要
hb-agentは、主に3つの部位で構成されています。
- hb-agent 実行の基礎となるRPM
- hb-agent
- hb-agent-lite
1は、hb-agentのChef Cookbook実行環境を初めとした、hb-agent利用に際して必要なプログラムをパッケージングしたRPMファイルとなります。これらは、お客様のアプリケーションに影響を与えないよう、hb-agent専用のパスにRuby, Chefなどをインストールしています。fluentdのtd-agentに近い形かも知れません。
2は、初期構築を行うChef Cookbookの総称です。
3は、監視設定を自動化するためのChef Cookbookの総称です。構築済みのサーバをお預かりする際は、監視設定の自動化のみを実施しています。
冪等性を諦める
Chefといえば冪等性と、耳にたこができるほど聞いた方もいらっしゃるはずです。
ただ、hb-agentはそれは諦めています。初期構築スクリプトを柔軟に書くことができるツールとしてChefを利用しています。オーケストレーションツールを使って完成まで構築を進めている案件もありますが、その際はhb-agentにプラスして利用しています。
hb-agentの普及への取り組み
ハンズオン
ドキュメントを見る立場となると辛いという気持ちもある一方、作った人間としては使ってもらいたい気持ちで一杯な訳です。
そこで、使い方と良さを知ってもらえるように、ハンズオンを実施しています。これをやる前とやった後では、使ってもらえる割合がずいぶん変わります。
詳細は「ツール普及のために社内ハンズオンに取り組んでみた」というエントリを書いたのでご覧ください。
ドキュメンテーション
ドキュメントは、次の段階を踏んで書いています。
- Getting Started
- より細かな使い方
- カスタマイズ
- FAQ
- 意見・要望の寄せ方
ハンズオンを受けて頂いた後、「あれ、これどうやってやるんだっけ？」となった際に読みやすいように構成しています。
改善への取り組み
環境は常に変わり続け、案件は多様化します。従って、改善を絶やさないことを心がけています。
構築担当エンジニアから社内GitlabにIssueやPull Request (Merge Request)を受け、週単位で改善する業務を回しています。また、できるかぎり遅滞無くやることで、利用する構築担当エンジニアの方々に「改善されている」「意見が反映されている」ムードを醸し出し続けてるよう取り組んでいます。
普及の期間
hb-agentを作り始めたのが2012年末です。それから2年半経過ほどしていますが、ほぼ全ての構築担当エンジニアに利用して頂いています。特に、台数が多くなくとも小さな案件をたくさん支えているチームに使って頂いている印象があります。ツールとしても小さな案件をたくさんこなせるようなポリシーで作っているため、理想的だと考えています。
まとめ
ここまで、構築・監視項目検出自動化ツール hb-agentを紹介しました。
当社は完全にITインフラに関わる業務に特化しているため、アプリケーションの話は出ていません。しかし、AWSをはじめとしたITインフラのリソースを柔軟に利用できるようになった昨今、利用する側も柔軟に対応できる必要があります。そのためには、プログラムの力を使うことは不可欠です。
ツールとしては改善したい課題がまだまだあり、いろいろ考えなければならないことも多いのですが、こうして全社的に業務に組み込まれていることは安心しているところです。
それではみなさま、ごきげんよう。
