こんにちは。旅行プラットフォーム部エンジニアの高嶋です。
突然ですが、皆さんアプリの品質や安定運用を担保するためには何が必要だと思われますか？テストや定期的なアップデート、保守性の高いコードなど様々ありますが、それらの他にも重要なものがあります。
そう、監視ですね。アプリも人間と同じで定期的な健康診断が必要です。また、FORCIA で提供している Web アプリは toC 展開しているものも多く、異常が生じた場合にはお客様である各企業様の他、多くのエンドユーザーにも影響が出てしまいます。そのため、異常をすぐに検知できる仕組みも非常に重要と言えます。
本記事ではアプリやシステムを陰で見守る「監視」の全体像についてご紹介します。
何を監視するのか
FORCIA では受託や SaaS 型の web アプリを提供しております。監視対象はアプリによって異なりますが、web サービスが正常に閲覧できること、データの更新が正常に行われていること、各種インフラリソースなどが基本の内容です。
主な監視の項目についてこちらに書き出してみます。
① 外形監視
サービスの HTTP エンドポイントを監視します。こちらに異常をきたしている場合はサービス提供不能の状態になっている可能性が高く、早急な対応が求められます。
② ログ監視
ログの中に ERROR など特定の文字列が入っていないかを監視します。SQL のエラーやアプリ内のエラーをログとして吐きだしている場合に役立ちます。
③ リソース監視
CPU、メモリ、ディスク容量などのサーバリソースをメインに見ています。リソース自体を監視するほか、これらは障害発生時の原因調査の一助にもなります。
その他独自の項目
④ フラグ監視
各サーバに「異常アリ」や、「メンテナンス中（＝したがって外形監視に失敗しても異常ではない）」などのサーバ状態を知らせるためのファイルを用意しており、その有無を監視しています。それらファイルを社内ではフラグと呼んでおり、フラグによってサーバーの状態が分かりやすくなるだけでなく、特定の処理に失敗した場合に「異常アリ」を示すフラグを立てることで監視システムに異常を検知させることもあります。
⑤ バッチ監視
FORCIA では１日に数回検索 DB を全件再構築するバッチ処理を行っており、その際の異常終了やタイムアウトを検知します。こちらは実際にはログ監視やフラグ監視を内包しています。
※DB の再構築については過去記事「検索が爆速になるデータベース設計を公開します」をご覧ください！
⑥crontab 監視
crontab で行っている定時処理を一時的にコメントアウトした場合に、そのまま忘れてしまわないようにコメントアウトされていることをリマインドする仕組みがあります。
⑦ データバージョン監視
バッチによる DB の更新が何らかの理由によって行われず、DB のデータが一定期間より古い状態を検知します。
どのように監視しているか
自社製監視ツールや、監視 OSS である Prometheus、AWS によるインフラ・ログ監視を併用しています。
自社製監視ツール
長らく Perl 製の社内ツールを利用しており、上記で挙げたような監視を複数のツールで分担して行っています。
社内のアプリケーションフレームワークや共通のシステム構成に合わせた設計となっており、監視や通知だけでなく障害発生したサーバを LB から切り離すなど細やかな対応も行っています。
Prometheus
k8s などインフラ構成が動的に変化するようなケースでは Prometheus を利用し監視しています。
Prometheus はオープンソースのシステム監視およびアラートツールキットで AWS EC2, Azure, GCP, k8s のような様々なプラットフォームに対応しており、分散環境の監視を得意としています。
また、監視対象に導入する exporter と呼ばれる目的別の監視エージェントにより、手軽に様々な監視を行えることが魅力です。その柔軟性から、k8s 利用のアプリ以外にも導入を推進しています。
AWS によるインフラ・ログ監視
AWS 環境でホストしているアプリでは Amazon CloudWatch により監視することもあります。CloudWatch でどのようなことができるかについては本記事では言及しませんが、FORCIA ではインフラレイヤーの監視やログ監視のために補助的に利用していることが多いです。
監視してどうするのか
緊急度の高い異常を検知
外形監視やデータ更新失敗時にはメール、電話で異常を即時通知します。また、社内のメインコミュニケーションツールである Slack の障害対応用チャンネルにも投稿がなされるようになっています。これにより、担当エンジニアが速やかに障害対応にあたれるようになっています。
随時対応レベルの異常を検知
即座に対応する必要はないが検知・修正が必要な事象の場合は Slack での通知や監視システム DB への蓄積等を行っており、後から参照し調査が行えるようになっています。また、どのような事象をここに振り分けるかはアプリによって異なっています。あまりにも多くの内容を通知してしまうと重要な通知を見逃すことになり、逆に絞りすぎても必要な対応が取れないことがあるため、適当な通知を行えるよう定期的に見直しを行う必要が有ります。
アプリやシステムの状態把握
特に異常がない場合でもサーバーリソース等の情報を保持し、不具合調査やインフラリソースをどの程度確保すべきかの検討などに役立てています。
Prometheus や Amazon CloudWatch にはグラフ化の機能が標準で備わっており、取得した監視データの可視化が容易に行えます。また、自社製監視ツールにも CPU やメモリなどのサーバリソースのグラフ化機能があり、サーバ状態を一覧で把握することが可能となっています。
このようなシステムやアプリの可観測性は一般的にオブザーバビリティと呼ばれており、強化・活用することでより安定的なシステム運用が見込めます。現状、弊社でも上記のような活用は進めているものの監視は障害検知のためという側面が強く、オブザーバビリティの観点ではまだ向上余地があると考えています。
最後に
本記事では FORCIA の監視についてご紹介しました。自社製監視ツールで何をやっているのか？Prometheus をどのように運用しているのか？などより詳細な内容につきましてもいずれご紹介したいと思います！
この記事を書いた人
高嶋 ありさ
2021 年新卒入社
デスクでまりもを育てています。定期的に水換えをしていますが、大きさなど特に変化がないので本当はただのスポンジなのかもしれないと疑っています。
Discussion