こんにちは。クチコミ機能で賑わっているferciを開発しているマネックスラボの佐藤です。
今回は、ferciシステムにDatadogを入れた経緯を追いつつ、小規模なシステムこそマネージドの監視サービスを使った方が良いのではないか、ということを書きたいと思います。
Datadogについて深掘りする記事ではないことをご承知おきください。
システム構築前
Datadogへの思い込み
Datadog、いいですよね。たくさんの導入事例記事が出てきて、どんなに大規模なシステムでも監視でき、素早い原因の特定ができることが伝わってきます。
その一方で、多くの人が知っているような有名なサービスへの導入事例が多く、記事に出てくる画像には、インスタンスを示す六角形のマークが無数に並んでいたり、複雑なAPMのグラフが出ていたり。
まだ小規模な我々のシステムにはまだ早いんじゃないかな、という気持ちになっていました。
ferciのシステム規模と、初期の構成について
ferciのシステム規模をセキュリティ的に問題ない範囲で説明すると、「冗長構成をとった最小限のWeb,AP,DB層を持ち、それらを運用するためのサーバーがいくつか上がっている程度」と書けば、Webシステムを作ったことがある方には伝わるかなと思います。
次に初期段階の構成を説明すると、ferciは立ち上げ当初は、監視にZabbixを、ログの集約にELKスタックをセットアップして使っていました。ZabbixはEC2を起動して自前でセットアップし、ELKは省力化のためAWSのElasticSearchサービスを使いました。
これらの構成をとった経緯としては下記のような理由があります。
- 構築当初、Zabbixをセットアップしたことのあるメンバーがいた。
- Datadogのライセンス料が年間20万円以上になりそうだった。
- Datadogのログ監視機能について調べると、Loggly等他のサービスも組み合わせた方が良いようなブログ記事がいくつかヒットした。
- 管理上、支払先を増やしたくなかった。
特に、リリースまで時間が無いため未知のプロダクトを使うリスクを取りたくなかったこと(万が一Datadogだけでは機能不足となった場合、明らかに間に合わなかった)、大規模システムでもないのにDatadogなんてもったいない、というあたりから、最初はZabbixで小さく始めましょうということになりました。
上の絵が、Datadogへの切り替え前と後の構成です。Datadogへの切り替え後にも、非監視対象のログをバックアップする目的で、Fluentdも併用しています。
前置き(構築メンバーとOSSに対して感謝の意を)
ここからはZabbixとELKを入れて後悔した話を書くことになりますが、最初に前置きをしたいと思います。
Zabbixを入れることの決定は構築メンバー全員で行ったことであり、また当時Zabbixをセットアップしてくれたメンバーは他の領域も見ながら作業してくれていたので、そのメンバーを責める気持ちはなく、むしろ色々引き受けてくれたことに感謝したいと思います。
当然のことながら、Zabbix、Elasticsearch、Fluentd、KibanaといったOSSコミュニティや、無償でソフトウェアを提供されている組織にも感謝しています。
ferciシステム構築後
Zabbix辛い。ElasticsearchとFluentd辛い。
一方で、いざZabbixとELKで運用してみると、かなりの時間をこれらのメンテナンスに割くことになりました。
Zabbixからアラートが上がって調べてみると、トリガーの計算式に書かれている数字が実装と異なっている。
AWSのコストを抑えるために環境ごとにEC2インスタンスやRDSのサイズを変えていたのですが、計算式に書かれているメモリサイズが実態と異なり、上がるはずのないアラートが上がることが度々起こっていました。
AutoScalingグループの新規ホストがZabbixに正しく登録されない。
OS起動時にZabbixAgentからZabbixサーバに対して自動的にホストを登録させるようにしていましたが、AMIを作成した時のEC2インスタンスが持っていたホスト名で登録されることがあり、新規にインスタンスが起動するたびにZabbixが認識したホスト名をメモしておく、といったアナクロな運用が発生しました。
監視対象サーバのセキュリティグループと、監視サーバのセキュリティグループ間の双方向の通信が必要。
インフラは原則CloudFormationで管理していますが、双方向の通信が存在すると二つのセキュリティグループ間に相互の依存関係が発生し、ParametersとConditionsを使って一工夫しないと、セキュリティグループを定義できない状態になりました。
一番CPUとディスクを使っているのがZabbixサーバ
弊社では月に一度、システムごとにCPUやメモリ、ディスクなどのキャパシティが十分であることを確認する会議が開かれます。そしてferciシステムの場合にはZabbixサーバが一番ディスク使用率、CPU使用率共に高く、何かと報告の対象になっていました。システムの異常を知るために立てた監視サーバーの監視が一番大変という状況でした。
Elasticsearchのmappingを簡単に変更できない。
ログのフォーマットを変更することはほとんどありませんが、変更するとなると大仕事です。一度アプリケーション実装メンバーから変更の依頼がきたのですが、作業時間的に難しく、要望に答えられず申し訳ない気持ちになりました。
簡単に潰れる開発環境のElasticsearch
開発環境はお金をかけたくないためt2タイプの1ノードで起動していました。しかしApacheBenchで簡単な負荷テストを行ったところ、ログを大量に受信したElasticsearchがあっさり潰れてしまい、ElasticsearchエンドポイントもKibanaも応答せず、AWS上からも制御不能になってしまいました。こうなると、ゼロからElasticsearchクラスタを作り直すしかありません。本番環境は十分な数のノードを並べていたつもりでしたが、万が一同じように潰れてしまうと復旧不可能になるリスクがあり、このまま運用するのは難しいと考えました。
Fluentdの正規表現を書くのが大変。
新しいログが増えるたびに、正規表現を書き、td-agentを再起動し、転送されているか確認し、といった作業がかなり辛かったです。FluentdはOSSプロジェクトの中ではドキュメントが読みやすい部類だと思うのですが、プラグインの組み合わせ次第でうまく動かないこともあり、それらの調査に工数を割かれるのもなかなか辛いものがありました。他にも細々としたことが起きるたびに工数を割くことになり、一部のメンバーがアプリケーション開発に集中できない状態が続きました。
切り替えの検討
ferciは2019年12月までは取引機能を提供していなかったため上記のような状態でも”なんとか”なっていましたが、その後、弊社基幹システムが提供するOpenAPIを利用した取引機能を実装することになり、上記オンプレミスの監視できちんと運用できるかどうかに不安が残りました。また、監視サーバーの監視に時間を取られるという本末転倒な状況を鑑み、SaaSに任せた方が良いのでは、ということになりました。同時に、ElasticsearchServiceも毎月数万円のコストになっていたため、ログの転送と検索もSaaSに寄せることにしました。
Datadogへの切り替え
ここからは事前検証と、開発環境での準備と本番環境へのリリースまでの二週間でやったことを書きたいと思います。
なおferciチームはDatadogに精通しているメンバーはおらず、インフラを担当しているメンバーも2人で、それぞれ他の作業も持っているため実質的にはDatadog初心者0.7人が作業したという前提の元に参考にしていただければと思います。
Datadogの事前検証
それまでDatadogのドキュメントや導入事例をなんとなく見ただけであったため、まずは時間を決めて試してみよう！ということになりました。
ferciチームの田代が30分だけ使ってDatadogを試したところ、1台のインスタンスにDatadogAgentをインストールし、インスタンスから取りうるメトリクスが一通り取れていること、それらの監視設定がGUIで簡単に行えそうであること、ログの監視もサンプルをほぼそのまま使えそうだということまで確認できました。一番驚いたのがメトリクスで、AWSから取れるメトリクスはもちろん、OS内部から見える、パーティションとその使用率など、何も設定せずにあらゆるものが正確に取得できていました。
Zabbixで何日も頑張って設定して取っていたメトリクスが、コマンド一つでインストールしただけで取れる。これが決定的なポイントになりました。
1週目 - エージェントインストールと監視設定の追加
最初は、いきなりアプリケーションが乗るAutoScaling対象のサーバーからセットアップを始めました。難易度的には固定されたインスタンスで起動している管理用のサーバーの方が小さく始められるという点でメリットがありましたが、Ansibleを使ったDatadogのインストールからAMIの作成、CodeDeployでのオンラインデプロイとAutoScalingまでを通して実装してしまえば、他のサーバーはそれを真似すれば済むので、一番工数のかかるところから着手しました。
最初の2,3日をかけて開発環境でDatadogAgentセットアップ用のAnsiblePlaybookを書きAMIを作成し、プロセス監視とログ監視設定を行いました。(ferciシステムのAMI作成プロセスはこちら)
ハマったのは、ログのTimeZoneの指定。ログファイルにいくらechoでテスト用のログを書いても、LiveTailで見ると流れてくるものがSearchで見えません。サポートに問い合わせをした翌日に自己解決に至りましたが、ログに記録された時間がJSTだったものの、UTCとして扱われていたため、9時間先の未来の時間としてDatadogに転送されていました。過去の時間であればSearchで広い時間でログを表示すれば見えたはずですが、未来の時間を指定することはできないのでなかなか気づきませんでした。
ログ周りではハマりましたが、このあとは粛々とMonitorをGUI上からぽちぽちと追加していって、プロセスやログが監視できているか、CodeDeployでデプロイしても古いインスタンスが監視から外れて新しいインスタンスを監視できているか、といった大雑把な確認までを終えることができました。
2週目 - テストの実施とドキュメント整理
前半で、1週目で作ったWeb,AP層のテストケースを作りながらテストをしてドキュメントを整理しつつ、周りの管理サーバーへのセットアップを進めました。1週目で大雑把に確認は取れていたので、粛々と作業をするだけで特に問題は起きませんでした。
後半は本番環境でZabbixとELKからDatadogに切り替えるためのリリース手順のドキュメントを作る時間に当て、さらに一週間後にリリースをするための社内申請を行うところまでを完了させました。
本番環境の切り替え作業
ZabbixサーバーとElasticsearch Serviceの削除は念の為1ヶ月様子を見た後に作業しましたが、監視とログ転送をDatadogに切り替えることは何の問題もなく数時間程度で完了できました。Datadogというプロダクトが安定しているおかげか、開発環境およびステージング環境での切り替えも躓くことなくスムーズに進み、本番環境でも安心して作業できました。
Datadogにしてよかったところ
ログの正規表現を簡単に記述できる
Fluentdだと設定ファイルにログのフォーマットを記述し、プロセスの再起動をして反映させてさらにテスト用のログを書き込まなければなりませんでしたが、DatadogだとGUI上にログのサンプルを貼り付けておき、正規表現を記述した後にテストボタンを押すだけでログにマッチするかを確認できるため、ストレスなく作業することができました。
問題に素早くたどり着ける
ログの検索が行いやすく、アラートが上がった時に、対象のログとその前後のログを調べることができるため、短い時間で原因の特定ができるようになりました。
他のサービスとの連携が楽
アラートはSlackとPagerDutyにも飛ばすようにしていますが、それぞれのSaaSが相互にサポートしているため、簡単にセットアップすることができました。仮にオンプレミスで監視を立てていたとすると、頑張ってスクリプトを書くことになっていたと思います。
モノのコストが安くなった
Datadogのライセンスは今のところ、年間20万円程度です。その一方で、ZabbixとElasticsearchServiceに毎月約$1,000、年間で約132万円のコストがかかっていたものを丸ごと減らすことができました。管理工数は正確に記録していないこと、Datadogを使い倒そうとすればそれだけ工数がかかるため一概には比較できるものではありませんが、ZabbixとELKだけでDatadogと同じ品質のものを作ろうとすれば、それだけで何人も雇わなければいけないことははっきりしていると思います。
ライセンスをAWSマーケットプレイスで購入できる
最初は支払先が増えることを懸念していましたが、DatadogのライセンスはAWSのマーケットプレイスで購入することができます。そのため、請求書の処理に時間を奪われることはありません。また、値段は直販で購入するのと変わりません。ただし、ある程度ライセンス料が大きくなってくると、Datadogから直で購入した方がディスカウントが効くことがあるそうなので、Datadogの営業の方に問い合わせるのが良いと思います。
アプリケーションの実装に集中できるようになった
これが一番大きな成果だと思います。監視の監視に工数や気を取られることなく、ビジネス的にインパクトのある機能の実装に、皆が集中できる環境を作ることができました。チームの人数的に保守をしながら開発せざるを得ないものの、アラートが上がってもすぐに原因を調べ、問題が無いとわかればすぐに開発に戻ることができます。以前であれば、アラートが上がるべくして上がったのかを調べるという、精神的にもプラスにはなりづらい作業が発生していました。
最後に
以上、Datadogに切り替えた経緯を振り返ってみました。
オンプレミスで監視を作っていた時に比べて、監視することにかけなければいけないエネルギーが大幅に減り、よりビジネス的にインパクトのあるアプリケーションの実装に人的リソースを集中できるようになったと思っています。
同時に、今までの経験を使うだけでなく、未知のプロダクトを理解するために工数を使い、将来のメンテナンスコストを下げることの重要性も思い知らされました。
特に小規模なシステムはどうしても少ない人数でメンテナンスを行うことになりがちなので、非機能要件の一つである監視はSaaSに任せることで、アプリケーション実装に有効にリソースを配分することができるのではと考えています。
佐藤 俊介マネックス・ラボ
