Build Insiderオピニオン：竹原貴司（2）
“小さな会社”が選択したログ管理の手法 ― バランスの取れたテクノロジ選択をしよう
ちゃんとやるけど、やりすぎない。そんなバランスの取れた「運用技術の選択」とは？ 小さな会社が開発・運用するシステムでは、どうログ管理しているのか。Logentriesというサービスに全ログを集約した筆者の事例を紹介する。
バランスのとれた選択
スポーツでカラダを動かすことが楽しい。週2回。基本的にフリーウェイトで、ベンチプレス中心の筋トレを行っている。最大挙上重量を伸ばしていくのが現在の目的だ（目標は自重の倍）。
筋トレアルアルなのだが、やはり挙上重量が伸びない時期＝プラトー（停滞期）が何度となく訪れる。その都度、トレーニング内容を見直し、あれやこれや試行錯誤しながら今に至っている。その試行錯誤が楽しくもある。
周りによく言われるのが「何を目指しているのか」というもの。別に何も目指してはいない。目標を設定してそれに向かって進むのが楽しいし、ジムの知り合いの方々とお話するのも楽しいから、続いているんだろう。
もともとが運動するのが好きで、カラダを動かしていないと死んだ魚のような目になってしまい、抜け殻のようにボケーっとしてしまう。最近、フットサルも始め、全然思ったようにできないのが楽しくてこれもまた週2～3回ほど遊んでいる。
ただ、やはりというか、年齢的に（1974年寅年生まれ）常にカラダのどこかが痛い。オーバーワーク。Life is pain。
いくら運動が健康によいといっても、やりすぎたら逆にカラダを痛めてしまう。カラダを動かすにしても、健康とのバランスは大事だと感じる。
そして、「バランス」は運動と健康といった自身の生活スタイルだけではなく、システムにおけるテクノロジを選択する場面でも大事なことだろう。みんながみんな、GoogleやFacebookのようなサービスを、あるいはソーシャルゲームを、はたまた大規模BtoCサービスを提供しているわけではない。
思うに、大きなシステムの事例などはよく見かけるが、世の中の99％は占めるであろう中小規模のシステムの事例は少ない気がする。つまり単純にネットで調べると、自分たちのシステムにフィットした性能や機能・予算に合う事例は見つかりにくい気がする。
「大は小を兼ねる」かもしれないが、それでもやはり「バランス」が大事だと思う。中小規模なシステムにおけるバランスのとれたテクノロジの選択は、過剰なリソースロスを生み出さないためにも、ROI（投資対効果）の高いシステム構築を行うためにも重要だ。
テクノロジの選択というと言語やフレームワーク、実行環境のことをイメージしてしまうかもしれないが、運用フェーズのことをないがしろにはできない。作っている時間より運用している時間の方が圧倒的に長いからだ。適切にシステムが稼働しているかを観測するためにログ管理とメトリクス管理は必須の要素となる。
そこで今回は、現在、弊社で実際に利用しているログ管理システムについて紹介したい。だが、具体的な話に移る前に考えておくべきことがある。
障害をなくすことはできない
人と人とが会話をする、もしくはテキストを使ってコミュニケーションする。その際に、一切の齟齬が発生しない、つまり意識や思考を他者と完全に共有することは可能なのだろうか。もちろんそんなことは無理だ（※「完全共有」に近づけていくことはできるだろうが）。
アーキテクチャを考えるのも、コードを書くのも人であろう。そして、人がやることである以上は、全てのシチュエーションを考慮することが難しいというのもあるし、人為的なミスも発生する。さらには人が絡まなくとも、ハードウェアは故障するものだ。
つまり、システム障害をゼロにすることは現実的ではない。というか、不可能だろう。
「だから何だ」といわれるだろうが、「障害は発生するものである」という考え方から始めた方が、今のところ建設的だと思う。
小さな挙動の変化を見逃さない
障害は発生するものだという前提に立つなら、その兆候を見逃さないことが重要になってくる。
自分たちが作ったシステムが、普段、どのような挙動をしているかを理解しているだろうか。「仕様は知っているし、コードも書いたし、そんなことは理解しているよ」と思われるだろう。
サーバーのメトリクス、それからOSやWebサーバーのログ、アプリケーションのログがどのように出力されていて、正常な状態で出力されるのはどのようなログかを把握できているだろうか（WebだとRPM（分間リクエスト数）や、バッチ実行の処理時間など）。また、それらを簡単に監視できるようになっているだろうか。ログは取っているけど見てはいないとか、有効利用していないということもありがちだろう。
ログから観測できる小さな変化を捉えることができれば、大きな変化が起きる前に対処できることもある。
弊社のログ収集システムの構成
弊社はWindowsサーバー／IIS／ASP.NET／C#／SQL Serverを基本として開発／運用を行っているため、以下のようなログが生成される。
- Windowsイベントログ（OS）
- IISアクセスログ（Web）
- アプリケーション出力ログ（log4net、NLog、Serilogなど）
これらのログは基本的には各サーバーに個別に保存される。そのままでは、何か調べたいときや、自動でアラート通知したいときなど、それぞれのサーバーへのアクセスや設定が個別に必要となる。台数が少なければ何とかなるが複数台（2台以上）になると、運用がどんどん大変になってくる。つまりコストがかかる。
コスト（人もお金も）がかかるアプローチは、弊社のような（売上規模や人数の）小さな会社では非常に困る。ありがちなのは「人件費は固定費だから、人手がかかる＝コストがかかるではない」という発想だ。そうではなく、人的リソースは最も価値のあるものなので、可能な限り本質的な部分だけに人が持つエネルギーを注ぎたい。自分たちが持つリソースをどう振り分けるかが、バランスの取れたテクノロジ選択においては重要だ。
ログ管理の文脈でいうなら、それは「ログ基盤の構築・運用ではなく、いかに便利に効率よくログ基盤を使うかに注力していきたいと」いうことだ。
Logentries
弊社ではLogentriesというログ管理＆分析サービスを利用している。本稿の目的はサービス紹介ではないので細かいことは省くが、構造化ログの集積／検索／ビジュアライズ／リアルタイムモニタ／アラート通知をまるっと行えるSaaSである（2015年10月にRapid7配下になった）。
ログを構造化して保持できるのはとても重要で、単なるテキスト検索以上の利便性がもたらされる（ちなみに、Logentriesではなく、ElasticsearchやBigQuery、Azure Storage Tableなどを利用しても同様のことは実現できる）。そして重要なのは大変な安価なサービス（無料から始められる）ところだろう（※参考：「Logentriesの価格プラン（英語）」）。
Logentriesnの無料プランでは、5GBytes／月までのログを保持可能で、保持期間は7日間という制限がある。つまり、ログの量が少ないとか、長期間の保持が必要ないのであれば、Logentriesを使えばお金は必要ない。ちなみに「Amazon S3に転送する」というオプション機能があるので長期保存問題はそれほど致命的にはならない（Logentries内からの検索はできなくはなるが、S3に取りにいけばいい）。ちなみに急激なログのスパイクが発生して許容量をオーバーしてもうまいこと対応してくれるのでご心配なく。
イベントログとアクセスログは各サーバーにインストールするエージェントプログラムからLogentiresへ送信し、アプリケーションログは専用のトレースリスナーを作成することで、弊社では全てのログをLogentriesサービスに集約している。
アプリケーションログの話は次回以降にすることにして、今回はイベントログとアクセスログをどのように収集しているのかを紹介したい。
ログの収集
Logentriesには専用のエージェントが用意されている（※参考：「Windows用のLogentriesエージェント（英語）」）。
しかし、弊社ではこれを利用せず、「NXLog Community Edition」という別のエージェント（以下、NXLogエージェント）を利用している。
今はどうか知らないが、Logentriesを使い始めた当初、専用エージェントではIISのログが構造化されず送信されていたことと、監視したいIISのアクセスログのフォルダーを個別に指定しなければならず（これだと、1台のサーバーに複数のサイトをセットアップしている場合、アクセスログはそれぞれW3SVC1、W3SVS2、……とフォルダーが分かれてしまうため）、管理が大変だったことが大きな理由だ。
その当時は、やりたいこと（要件）として以下のものを想定していた。
- イベントログをフィルタリングして収集
- アクセスログを個別にフォルダー指定をせずに収集
- アクセスログを構造化して収集
- エージェントログのローテーション
- ログ送信先の制御
環境によっては必要のない項目もあるが、弊社ではいずれも必要なことだった。そして、専用エージェントではこれらの要件を満たすことができなかったために、これらを満たすエージェントとしてNXLogエージェントを選択したわけである。体調と相談しながら、どれくらいカラダを動かすかを決めるのと同じように、自分たちが必要としている要件と相談しながらテクノロジを選択したわけだ。
ちなみにLogentriesの専用エージェントではなく、なぜNXLogエージェントが選択肢として浮上したかというと、Logentriesに似たサービスのlogglyというのもあり、そちらのエージェントがNXLogであったことがその理由に挙げられる。いずれのサービスもsyslogでのログ収集を受け付けている。そして、「要件を満たさない専用エージェントではなく、syslogで送信できるエージェントがあるなら何でもいいじゃないか」とNXLogを試してみたら要件を満たせたという次第だ。ちなみにlogglyもステキなサービスだが日本語が表示できないので利用はあきらめた。
Logentriesの使い方や、NXLogの設定方法などをHowTo記事にしてもよかったのだが、検索すればいくらでも情報は出てくるし、HowTo記事は書いていても面白くなかったので途中でやめた。できることなら、これを読んでいる方々が自身で実際に試して、その簡単さと便利さを体感してもらいたい。
小さな会社で活用するためのLogentries Tips
弊社のような開発／運用環境では、以下のことに気を付けておこう。
IISのログファイルが増えすぎて、エージェントの負荷が高まる
これは、エージェントがファイル監視をしているためで、監視対象のファイルが大量になってくると、ファイル監視そのものにCPUリソースを使われてしまい、大変もったいない事態となる。監視の間隔は調整できるのだが、それでも、ファイル数が数百を超えるとやはり負荷が目につくようになる（エージェントがCPUを20～40％くらい消費する）。
どうやって対処するのかというと、アクセスログを削除(または別フォルダーに移動)してしまえばいい。単純だが非常に効果のある対処法である。
弊社の場合は、リスト1のようなPowerShellスクリプトを使って、一日に一度、ファイルを移動している。
|
param
(
[Parameter(Mandatory=$True)]
[string]$src,
[Parameter(Mandatory=$True)]
[string]$dst,
[int]$hour = 24
)
$srcDir = Get-ChildItem $src
# destination root folder
if(!(Test-Path $dst)){
New-Item $dst -ItemType Directory
}
foreach($logDir in $srcDir){
$srcFullDir = $src + "\" + $logDir.Name
$dstFullDir = $srcFullDir.Replace($src,$dst)
# destination sub folder
if(!(Test-Path $dstFullDir)){
New-Item $dstFullDir -ItemType Directory
}
$srcFiles = Get-ChildItem $srcFullDir | Where-Object {$_.LastWriteTime -lt (Get-Date).AddHours(-1*$hour)}
foreach($target in $srcFiles){
Write-Output $target.FullName,"->",$dstFullDir,$target.Name
Move-Item $target.FullName $dstFullDir -Force
}
}
|
Azure VM環境の場合、Logentriesへの接続が頻繁に失敗する
弊社はインフラをAzureとAWS、その他の複数のSaaSを利用して構築している。中でもWebサーバーは集積度を上げるため、Azure VM上に展開している。しかしこの場合、Azureのネットワークの制限からVM上のエージェントからLogentriesのエンドポイント（api.logentries.com）への接続が断続的に切断され、一定時間接続できなくなってしまうことがたまに発生していた。Azure VMからのDNSクエリのスロットルによるものなのか、その他の要因があるのかを現在調査中ではあるものの、現状では以下の回避策を採っている。
オフィスからAzureへはVPN接続しており、オフィスと同一のネットワーク上になるようAzure VNETを組み、同時にオフィス内にログ中継サーバーを設置している。Azure VMからはオフィスのログ中継サーバーに送信し、経路としてVPNを通すことで、Azureのネットワークの制限を回避している。これにより、現在は安定したログ収集を実現している。
ログ中継サーバーといっても、特別なことはなくNXLogをインストールし、以下のように設定しているだけだ。
|
<Input LogentriesIn>
Module im_tcp
Host 0.0.0.0
Port 10000
</Input>
<Output LogentriesOut>
Module om_tcp
Port 10000
Host api.logentries.com
</Output>
<Processor LogentriesBuffer>
Module pm_buffer
MaxSize 1024
Type Mem
WarnLimit 256
</Processor>
<Route Logentries>
Path LogentriesIn => LogentriesBuffer => LogentriesOut
</Route>
|
まとめ
正常な状態を認識する、変化を捉える、異常を検知する、通知する。それらを低コストで達成できるなら、事象に対して「後の先」を取ることができるなら、日常の不安は減っていくことだろう。ログは生成するだけで終わりではない。ログを生成してから、それを利用することまでを想定した運用こそ意味を成すのだ。
普段の体調管理、自分たちに合ったテクノロジの選択、そして文字だけじゃなく図やスクリーンショットをバランスよく配置した技術文章。バランスは大事だ。本コラムもスクリーンショットもなく文字ばかりであまりにも分かりにくいと感じる方もいらっしゃるだろう。なので次回はもう少し具体的に、アプリケーションログのためのトレースリスナー実装、サーバーやアプリケーションのメトリクス可視化、Logentriesでのアラート通知について触れてみたい。
竹原 貴司（たけはら たかし）
2014年9月より株式会社CommerbleにてECプラットフォームの提供に従事。
コンピューターと向き合い始めて四半世紀。
ゆかいな仲間たちと、素晴らしいプロダクトを提供し続けていきたい。
1. 仕事とプライベートは分け「ない」方が自分らしく気持ちよく働けるという考え方
日々をどう過ごすか。仕事とは何なのか。小さなチームに所属するソフトウェアエンジニアが考える仕事とライフスタイルの関係、そして「アトムの世界をハックする」ために必要なこととは。
2. 【現在、表示中】≫ “小さな会社”が選択したログ管理の手法 ― バランスの取れたテクノロジ選択をしよう
ちゃんとやるけど、やりすぎない。そんなバランスの取れた「運用技術の選択」とは？ 小さな会社が開発・運用するシステムでは、どうログ管理しているのか。Logentriesというサービスに全ログを集約した筆者の事例を紹介する。
3. 殻を破り、傾聴しよう ― ログの収集・可視化・監視はリスク管理である
ビジネスモデルの観点からサービスの安定提供が求められる場合、サーバーの“わずかな悲鳴”を聞き逃さないためのリスク管理が必要になる。なぜそれが大切なのかを示し、.NETでログ収集する方法を説明する。
