Build Insiderオピニオン：竹原貴司（3）
殻を破り、傾聴しよう ― ログの収集・可視化・監視はリスク管理である
ビジネスモデルの観点からサービスの安定提供が求められる場合、サーバーの“わずかな悲鳴”を聞き逃さないためのリスク管理が必要になる。なぜそれが大切なのかを示し、.NETでログ収集する方法を説明する。
思考の深まり、発想の広がり
以前にも書いたことだが、筆者は現在ECプラットフォームを提供する会社に勤めている。普段の仕事の中でも重要なのが、「サイトが正常に稼働し続けているか」「パフォーマンスに問題はないか」「エラーの頻度はどの程度か」などの監視をしつつ、問題がありそうな兆候を発見したら、それに対処するためのコードを書いたり設定を見直したりする、いわば「安定したサービス提供を実現するためのSRE（Site Reliability Engineering）」としての仕事である。
ちなみにECに関わりだして8年、それまでは普通に受託開発の仕事に15年ほど従事していた。当時、サーバーの運用監視を行うこともあったが、今ほど細かく見てはいなかった。納品してその後のことについては無関心というか、顧客から連絡がないと何もせず、次の案件に突入するということを繰り返していた。契約や責任分担（DevとOpsの分離）などの理由はあったが「しっかりと運用状況を把握しておこう」と思うことが、そもそもなかったのである。「言われたものを、言われた通り、言われた期間に作ればいい」と、それが自分の仕事であると思っていたのだ。そこから先のことは意識もしていなかったし、考えもしなかった。
今にして思えば、少しもったいないことをしていたと思う。作ったものが仕様通りに機能することはいいのだが、その時のアーキテクチャ・設計・実装で予期せぬエラーの発生やパフォーマンス面に対応しきれていたのか、改善する箇所がどこに残ってはいないか、というフィードバックを自ら遮断してしまっていたと言ってもいいだろう。もっと、きちんと監視していれば、より良くする方法を早く的確に把握できていたはずではないのか。そうすることで、その案件の改善のみならず、以降の案件にその知見を生かすことができたのではなかっただろうか。自分も顧客も気が付いていないシステムからの“わずかな悲鳴”を聞き逃さない仕組みを構築できていれば、よりたくさんの価値を顧客に届けることもできたかもしれない。
なぜ正常稼働を重要視しているかといえば、顧客ビジネスに影響がないようにするという理由ももちろんだが、弊社の収益モデルからくる要因も大きい。弊社では受注1件当たりに対して課金をするという収益モデル（トランザクション課金）を採用している。月額固定料金ではないので、システムのパフォーマンスが低下したり、サイトがダウンしたりしていると、弊社としては売上が減るのである。常に最高のパフォーマンスでサイトが稼働し続けることが、自社ビジネスを成立させるために重要なのだ。
収益モデルのみならず、提供するサービスやオペレーションの仕組み、それらが集合したものを「ビジネスモデル」だと定義した場合、ビジネスモデルが開発者自身の思考や日々の仕事にどれだけの影響を及ぼすのか。ビジネスモデルを意識すればするほど、その影響は大きくなるのではないか。
「組織の伝達構造を反映したシステムを生み出してしまう」というコンウェイの法則がある。「組織の構造」は何が決めているのかといえば、ビジネスモデルが少なからず関与していることは、前述の「弊社における収益モデル」の説明で明らかだ（ほとんどの企業でも同じように考えられるだろう）。そして「組織の伝達構造」とは、その「組織の構造」に所属する個々人の思考を伝達するための構造であることを考えれば、「ビジネスモデルが、個人の思考を決定するうえでとても比重の大きな要因になっている」と感じずにはいられない。
組織の構造がビジネスモデルに縛られ、個人の思考が組織の構造に縛られているということはないだろうか。漫然と日々を過ごしていると、こうした構造に気が付かないまま、何か大切なことを見落とすことにもなりかねない。この構造に自覚的になることで、見えてくる何かがあるはずで、それは個人だけの問題ではなく、組織の問題でもあるはずだ。ビジネスモデルという殻、組織構造という殻をどうすれば打ち破ることができるのか。これが大事だと感じている。
収益モデルやビジネスモデルと言われたところで、自社サービスを運営していたり、自身で会社を運営していたりしないとピンとこないし、自分には関係ないと思われる方もいるだろう。だが、視点を変えて、「これからの自分の在り方を組織のビジネスモデルに沿ったものとしていくのか」、それとも「個人のビジネスモデル（生存戦略、人生観や価値観、幸福の定義）に合致した組織に所属するか」、または「既存組織内において、自身のビジネスモデルを中心に、組織のビジネスモデルに貢献する役割を見つけるのか」を考えてみてほしい。そのように組織と個人それぞれにモデルがあると考えれば、「ビジネスモデルから思考が決まっていく」という話もあながち的外れではないのではないか、と勝手に思っている。
何が言いたかったかというと、「自分で意識してなかったことが多すぎたためにもったいないことをしてきたな」という反省と、意識することで初めて「解決しなければいけない問題が発見でき、それに対して対処をするのか／備えるのか／保留するのかを判断できる」ようになるということだ。
稼働させているシステムであれば、ログを収集・可視化・監視することで、リスク管理を行い、危機に備えることが重要なのだ、という話につなげる。無理やり。
ログの可視化はリスク管理である
前回まででWindows OSのイベントログとIISのアクセスログの収集方法を紹介したが、今回はアプリケーションログの収集方法を紹介したい。
アプリケーションログといえば、一般的にはlog4net／NLogなどを利用したものが多いのではないかと思うが、筆者の場合、収集先（Sink）に合わせたTraceListenerを実装することがほとんどである。理由は、記述が統一されて簡単（Trace.WriteLine）なのと、設定ファイルでTraceListenerを指定することで、どんな場所にもログを集約できるからである（TRACEコンパイラーオプションは忘れずに）。
ちなみ現職で最初のころに書いたコード（8年前）に含まれるTrace.WriteLineは今もそのままログ収集のためにプロダクションコードに含まれており、設定ファイルのTraceListener実装が差し替わったことから、収集先はLogentriesになっている。収集先は適宜都合のよいものを利用してきたので、かつてはMongoDBにログを入れたりもしていた。
もちろんlog4netやNLogをすでに導入済みの場合でも、下記リンク先のドキュメントにもあるように、必要なアセンブリを追加して、LogentriesをSinkにすることも可能である。
弊社ではカスタムのTraceListenerを実装して利用しているが、もちろんGitHubに公開済みのTraceListenerもあるので、Trace.WriteLineですでにログ出力を実装している場合は、ぜひ試してみるといいだろう。ログが管理画面で簡単に確認できるようになると、障害対応もはかどるというものだ。
そして、ログが集約されるようになったら、条件指定でアラート通知も欲しいところ。弊社ではメールと組織用チャットサービス（HipChat）のそれぞれに対してLogentriesからのアラートを通知するよう設定している。詳しくは、下記リンク先のドキュメントを参照してもらいたいが、検出したいログのパターンを指定し、そのパターンにマッチした場合にはラベルを付けるように指定をしておく。ラベル付けされたものはログ管理画面からも簡単に検索できるようになり、さらにアラート登録することが可能となる。
メール以外のパートナーサービスへの通知チャネルとして現時点で、
- Logentries iPhone App
- Web hook
- Slack
- Campfire
- PagerDuty
- HipChat
が用意されているので、都合のいいものを利用するといいだろう。使い方については、下記リンク先を参照してほしい。
ここまでで、Logentriesへのログの集約は一通りできるようになったわけだが、これで見たい情報全てが集まったわけではない。サーバーモニターも必要であり、KPI（重要業績評価指標）として見たい数値が他にもある。
弊社ではサーバーとアプリケーションモニタリングにNewRelicのServerMonitorと.NET Agent（設定ファイルはカスタム。初期設定のままではパフォーマンスがそれなりに劣化する）を利用している。従って、突然のトラフィック増や、エラーの発生、パフォーマンスの低下などのアラートはNewRelicから送られるようにしている。
ただ、別々のサービスにメトリクスが集まっているので、このままでは見たい情報が別々の管理画面に分散してしまい、筆者の会社のメンバーにとっては使い勝手がよくない。そこで現在は、独自の集約ダッシュボードをスクラッチで実装している。たいしたものではないが、常時見ておきたい情報は詰まっている。
ダッシュボードに表示している内容はおおむね以下の通りだ。
- Request／Minute
- Order／Hour
- Response Time
- Throughput
- Apdex ScoreとError Rate
- バッチジョブの実行結果
- 個別サーバーのCPU／Memory／Diskの使用率
それぞれのメトリクスが通常時とは異なる動きを見せた場合、その原因がどこにあるのかを、ログから調べたり、NewRelicのダッシュボードやAzureのダッシュボードを見て調べたりしている。これによって、システムに問題があるのかどうかを判断する。もちろん問題が発生したのではなく、単なるスパイク（例えば顧客が目玉商品を売り出してアクセスが急増したなど）であったり、外部連携先のバッチの不具合や設計ミスだったりする場合もあるので、全てをプラットフォーム側で対応するわけでもない。
だが、見逃すことで致命的な問題を招いてしまうことだけは避けたい。かつて聴き逃していたシステムからの“悲鳴”をきちんと聴き、適切な対処を行うことで、リスクが危機（インシデント）に発展することを防ぎたいと考えているため、リスク対応にコストをかけているのである。
『熊とワルツを』という書籍をご存じだろうか。読まれている方も多いと思うが、ソフトウェアプロジェクトのリスク管理に関する書籍である。リスク管理それ事態はプロジェクトの開発段階だけではなく、もちろん運用フェイズでも重要だ。その本にこんな記述がある。
起こりうる悪い事態（リスク）をはっきりと認識し、それらに備えておくことが、成熟のしるしである。
また、このようにも。
問題が勃発する前には、かならずといっていいほど何らかの予兆がある。われわれは、そのような予兆にあえて気づかないように自分を訓練してしまっている。リスク管理とは、この訓練を解除するものである。
システム運用で、予兆に気付かないと、問題に対して後手に回ってしまう。そうなると、顧客にも迷惑をかけてしまうし、自社ビジネスに致命的な打撃を与えかねない。自分の置かれている状況が、気付かないことを肯定してしまっているかもしれないと考えることで、当たり前に受け入れてしまっていたものが、実は危険と隣り合わせになっていたことに気付けるかもしれない。筆者も状況に慣れすぎて従属せず、せっせと殻を破り続けていくつもりだ。
竹原 貴司（たけはら たかし）
2014年9月より株式会社CommerbleにてECプラットフォームの提供に従事。
コンピューターと向き合い始めて四半世紀。
ゆかいな仲間たちと、素晴らしいプロダクトを提供し続けていきたい。
1. 仕事とプライベートは分け「ない」方が自分らしく気持ちよく働けるという考え方
日々をどう過ごすか。仕事とは何なのか。小さなチームに所属するソフトウェアエンジニアが考える仕事とライフスタイルの関係、そして「アトムの世界をハックする」ために必要なこととは。
2. “小さな会社”が選択したログ管理の手法 ― バランスの取れたテクノロジ選択をしよう
ちゃんとやるけど、やりすぎない。そんなバランスの取れた「運用技術の選択」とは？ 小さな会社が開発・運用するシステムでは、どうログ管理しているのか。Logentriesというサービスに全ログを集約した筆者の事例を紹介する。
3. 【現在、表示中】≫ 殻を破り、傾聴しよう ― ログの収集・可視化・監視はリスク管理である
ビジネスモデルの観点からサービスの安定提供が求められる場合、サーバーの“わずかな悲鳴”を聞き逃さないためのリスク管理が必要になる。なぜそれが大切なのかを示し、.NETでログ収集する方法を説明する。
