こんにちは、いのうえとよです。 LOHACOの運用を担当しています。どうぞよろしくお願いしますね。
運用業務の手作業をやめたいな
と、思い始めたのはアスクルに中途入社して1年、引継ぎやシステム理解もひと段落して、そろそろ自分の色を出していこうかなと思っていた頃でした。
自己紹介になりますが、高専を卒業して20歳で上京してから、運用・維持が私のキャリアの全てです。で、LOHACOを含め、これまで様々なシステム運用に関わってきたわけですが、運用が担当する基本的な業務内容は、どんなシステムでもおおよそ以下の4つでした。
- データ、ログ抽出
- 調査依頼対応
- アプリケーションのリリース
- トラブル対応
これです。システム運用経験のあるエンジニアの方にはある程度共感していただけるかと思いますが、この作業たちがまあ、とにかく時間を取られる。LOHACOに限らずです。
トラブルを除けば基本的に依頼作業。かつ依頼する側からすればすぐに対応してほしい内容だったりするので、スケジュールにどんどん割込みが発生し、クリエイティブに使いたい時間がどんどん分断されていってしまうのです。 長距離ランナーがフルマラソン中、10分~15分刻みに何度も何度もタップダンスを要求される様子をイメージしてみてください。早くゴールに向かいたいのに!
で、作業効率を上げるべく運用ツールを作ったりもしたものの、運用者個人がそれぞれ思い思いに作っていくし、たくさんあるLOHACOのサーバごとにツールを用意する必要があるしで、今度はツールの運用維持が大変になってくる。良くないぞ……。
幸いなことに、アスクルは「運用改善」というタスクに対し、理解と評価を行う企業です。というわけで、この運用作業たちにメスを入れて業務改善をしてやろう、そして会社内で評価を得てやろうと考えたわけです。
解決したい課題はなにか
いろいろありました。
- 同じような作業を毎回人の手で行っている
- 個人のスキルや経験に頼るシーンが多く、作業の割り振りが偏る(個人に負荷が集中する)
- 各サーバにツールが散らばっている、かつどこにあるのかわかりづらい
- ツールの実行は結局運用担当の手作業
- 本番サーバにアクセスできるのは運用担当のみのため、どんな細かい調査もすべて依頼を受ける形になる
わかりやすいところではこんなところでしょうか。これらをぎゅっと絞って抽出すると、
「自動化したい」「ツール環境を統一したい」「ツールを運用担当の外に公開したい」
=「運用を楽にしたい」
となります。「ツールを運用担当の外に公開したい」が重要で、先に挙げた課題の4つ目など「はたして運用担当を介する必要があるのか?」という作業も多々あります。運用稼働も無駄なら、運用担当への依頼と回答にかかるリードタイムも無駄。改善すべきです。
Rundeckを使おう
というわけで、まず「自動化したい」「ツール環境を統一したい」を解決するためにRundeckを導入しました。ポイントは、
- エージェントレスであること
- UIがわかりやすいこと
- ジョブ実行に引数を指定できること
の3点です。
Jenkinsでもよかったのですが、管理する範囲が肥大化して運用が大変になり、大前提の「運用を楽にしたい」がつぶれてしまうので無し。サクッとサーバ立ち上げ+Rundeckを導入。
やったー。早速テストプロジェクトを作ってジョブ作成。
やったー。30分置きに/varのサイズを監視して、Optionsで指定されているborderline(閾値)を超えたら異常ステータスを返すジョブです。簡素。
今回はジョブ内に直接bashを記述しましたが、サーバに配置したスクリプトファイルを指定して実行することももちろん可能です。スケジューラは脱cronしたいけど、これまでに作ったスクリプトは流用したい、 みたいなケースにも応えられるのは良いですね。実行!
やったー!
RundeckはSlackやメール等に実行ステータスのNotificationを送信できるので、閾値を超えたら障害通知、というような使い方が可能です。これだけでもcronから脱却する価値アリ。
ディスク使用量などのクリティカルかつ汎用的な監視は専用の監視ソフトウェアを導入すべきかと思いますが、例えば「あるRDBのテーブルにデータ不整合が発生しないかクエリを定期的に発行し、有事の場合はアラート発報」のような限定的な監視を行う場合などに大いに役立ちます。
さらに、前述のOptionsはジョブの実行画面でパラメータとして指定可能なので、然るべき権限を与えて開発チームに公開することで、ちょっとしたデータ抽出ツールとしても利用してもらえると言うわけです。「ツールを運用担当の外に公開したい」ですね。
運用作業の最適化に向けた+α
続いてApache/PHP/MySQLのインストール。
ApacheやPHPが必要なのはなぜか。今回「ツールを運用担当の外に公開したい」を解決するにあたり、機能の提供先を3つのロールに分けています。
- 運用担当(ジョブの作成、実行権限)
- 開発担当(ジョブの実行権限)
- LOHACO業務担当(参照のみ)
アスクルはエンジニアだけで成り立っている企業ではありません。「LOHACO業務担当」はつまり、「商品の管理」「広告・販売促進」「物流」など、LOHACOを運営するエンジニア以外の担当者です。先に挙げた運用作業の中では主に「データ・ログ抽出」を必要とする側ですね。
Rundeckはリッチで分かりやすいUIがウリの一つですが、「エンジニアにとっては」という前置詞が付きます。Rundeckのアカウントを提供するから好きに使っていいよと言われても、業務担当の方は困ってしまうと思うので、業務担当に向けては、定期的に抽出されるデータや、データをもとに作成したレポートなどを参照できる社内WEBサイトを公開することで対応しようと考えました。
LAMP+バッチサーバとしてRundeck。シンプルって素晴らしい。構成が膨らんでくると維持が大変になってきますし、一連のツール、アプリケーション開発を行うのは運用担当なので、開発環境の構築に手間取らない構成を意識しました。
サクサクと作っていきます。
作ったもの一例
w2ui + Chart.jsで構築。Rundeckジョブで各サーバのアラートログを10分置きに取得してMySQLに格納、アラートの内容ごとに集計し、結果をグラフとテーブルで表示します。
Stackdriver等のロギングツールとはまた目的が異なり、発生したアラートに対してどのようなアクションを行うか、 どのチームに調査を依頼するかなど、トラブル調査の起点で運用担当がいちいち判断していた部分を視覚化・機能化することに重きを置いています。
素のPHPで構築。これまで依頼を受けてきたデータ抽出依頼で定型化できるものを定期実行し、所定のディレクトリに保存したものをリスト表示するものです。 これには、データ抽出の定型化と合わせてデータ抽出自体を最適化したいという狙いもあります。データ抽出の依頼を受けていると、抽出項目・条件がほとんど同じような依頼が結構あったりします。
依頼による手作業ベースだと、個人対個人のやりとりになるので、誰がなんのデータを持っているのかがわからなくて二度手間になったりするんですよね。公開可能なデータに限定していますが、誰からもアクセスできる社内のサイトにデータを置くことで、余計な依頼を減らしていこう、という取り組みです。
……。
Datatables+Bootstrapで構築。機密情報だらけなのでもはや何も見せられませんが、抽出キーを入力するとキューとして登録され、裏で5分おきにRundeckが溜まっているキーでDB検索し、結果をファイルで提供するツールです。
これまではこのような単純なツールも開発担当に開発を依頼していましたが、運用チームが直接開発できるようになったのはスピード感のある業務改善の点で大きな意味を持ちます。
そして現状は
Rundeckの構築は完了し、既存のcronジョブは全て移行完了。新規に発生するデータ抽出依頼は(可能な範囲で)Rundeckジョブとして作成、登録する運用フローが回っています。結果、時間にして月40時間ほどの改善。会社からも評価を受けました。
終わりに
最新の技術、流行りの技術はシステムにとっての銀の弾丸にはなりえませんが、導入後続いていく運用によって銀の弾丸に近づけていくことはできます。 つまりは最適化です。システム全体を見通せて、他部署がどのようなデータを欲しているかを把握できる運用チームだからこそ行えるタスクとして、私は最適化に自信を持って取り組んでいますし、そのための技術の習得や導入をアスクルはサポートしてくれます。
本稿には技術ブログらしい、テクニカルなコードや環境設定のための華麗な手管などは登場していませんが、「エンジニアではない方に対して技術を提供するための技術」を記事にした、ということで、まとめとさせていただきますね。ありがとうございました。
アスクルではシステムを裏から支え、発展していく意欲と情熱のあるエンジニアを募集しています!