システムからの通知について
こんにちは、IT戦士の皆さん。
プロダクトGの大内です。
今日はシステムからの通知の実装について、
システムからの障害やリソース状況を通知するにあたって、構成したアーキテクチャや具体的な運用例を交えてお伝えします。
なお、弊社では主にAWSを活用しているため、ここで書くことはAWSサービスを前提にしています。
- システムからの通知について
- 1．通知の重要性
- 2．通知のためのMSP／監視SaaS／自前実装の検討
- 3．Slack通知のメリット
- 4．Chatbotの限界：カスタマイズ性を求めて
- 5．Lambdaでのカスタマイズ
- 6．Lambdaのデプロイ：IaC（Infrastructure as Code）とServerless Frameworkの棲み分け
- 7．まとめ: システム監視の未来へ向けて
1．通知の重要性
最初に、システムからの障害通知やCPU使用率／メモリ使用率の高騰などのリソース状況通知を使っていますか？
もし「はい」と答えたあなたは、すでに一歩先を行っています。
もし「いいえ」と答えたあなたは、システムが「助けて！」と通知しているのに、それを無視するとシステムダウンが発生し、ユーザーからのクレームに繋がる恐れがあります。
そのため、適切な通知の仕組みを構築することが重要です。
2．通知のためのMSP／監視SaaS／自前実装の検討
通知のための仕組みとしては以下の方法が考えられます。
- MSP（Managed Service Provider）に依頼
- 監視SaaS（Software as a Service）を利用
- 自前で実装
上記のどの方法を取るにしてもコスト（イニシャル／ランニング／運用）を考慮することが必要で、自社の組織やチームに合った手法を選択することがベターです。
MSP（Managed Service Provider）に依頼する場合
MSPに依頼する場合は、運用コストは低くなりますが、イニシャルコストやランニングコストが高くなることが予想されます。
また、後述する通知時のカスタマイズ性についても自由度がなくなってしまう可能性が高いです。
反面、障害時の初動対応を行なってもらえたりする可能性はあります。
外部監視SaaSを利用する場合
外部監視SaaSを利用する場合は、一例としてNewRelic／Datadog／mackerelなどがありますが、これらは運用コストは低い反面、ランニングコストが高くなりがちです。
例えば、NewRelicは優れた可視化機能を提供しますが、その分料金も高めです。
一方、mackerelは比較的安価ですが、機能が限られる場合があります。
自前で実装する場合
自前で実装する場合は、ランニングコストは低く済みますが、イニシャルコスト（構築コスト）や運用コスト（メンテナンス）がかかります。
今回弊社ではこちらの手法で実装しました。
自前での実装のアーキテクチャとしては、Chatbotを使う方法もありますが、Slackへの通知に加えて通知内容のカスタマイズをしたかったので、CloudWatchAlarm＋SNS（Simple Notification Service）＋Lambda＋Slackというアーキテクチャで実装しています。
通知のトリガーとしては、CPU使用率高騰やメモリ使用率高騰をCloudWatchAlarmで検知してSNSに飛ばすようしています。
ここまでの話を踏まえ構成図にまとめたのが以下の図です。
3．Slack通知のメリット
自前で実装するにあたり「どこに飛ばすか」というお話です。
弊社ではチャットツールのSlackがコミュニケーションの基本になっているため、通知はよくあるメールではなくSlackに飛ばすようにしました。
Slackであれば誰が対応しているかどうかのスタンプを付けることも可能です。
また、ChatOpsという言葉もあり、将来的にはSlackを使って運用作業をすることも視野に入れています。
Slack通知のもう一つの利点は、リアルタイムでの対応が可能になることです。
メールだと気づくのに遅れることがありますが、Slackなら即座に反応できます。
4．Chatbotの限界：カスタマイズ性を求めて
Slackに通知を飛ばすためのサービスと言えば、Chatbotですよね。
Chatbotは実装が簡単に出来て便利ですが、カスタマイズ性に欠けるのがネックで、決められた文言でしか飛ばせないため、ユーザーメンションやグループメンションを使いたい場合には不便です。
また、対応しているAWSサービス以外だとそもそもChatbotが処理できず通知が飛んでこないので注意が必要です。
5．Lambdaでのカスタマイズ
カスタマイズ性を求めるなら、自分でLambdaを使って通知システムを作成するのが良いです。
設計当初から特定のシステムに特化させず、他のシステムでも活用できるよう共通化を意識して拡張性を持たせた作りにします。
また、Lambdaに飛ばす前段としてSNSを介入させるのは設計の基本ですよね。
SNSは通知のハブとなり、メール、Slack、Lambdaなど様々なエンドポイントに通知を飛ばすことができます。
例えば、システムが障害を検知した場合、まずSNSに通知を送ります。
その後、SNSが設定されたエンドポイントに通知を配信します。
この仕組みを使えば、通知先の変更も簡単に行えます。
Lambdaでは言語としては、Pythonを選択しています。
Pythonは読みやすく、インフラエンジニアでも扱いやすい言語と考えています。
また、豊富なライブラリが揃っているため、通知システムの構築もスムーズに進められます。
将来的には、一次対応を自動化させることも視野に入れています。
運用フェーズに入り、特定の障害に対する対応方法が確立できたなら、それをコードに落として自動化させることができます。
例えば、特定のサービスがダウンした場合に自動的に再起動するスクリプトを作成し、Lambdaで実行させることができます。
これにより、運用負荷を大幅に軽減することができます。
6．Lambdaのデプロイ：IaC（Infrastructure as Code）とServerless Frameworkの棲み分け
最後に、Lambdaのデプロイ方法についてです。
弊社では、IaC（Infrastructure as Code）ツールとしてTerraformを採用しています。
ただ、TerraformでLambdaのコード管理とデプロイをやるのは辛いです。
また、コード改修やデプロイはインフラ／アプリ両方のメンバーができるようにしたいところです。
ここで今回採用したのがServerless Frameworkです。
CloudWatchAlarm＋SNS作成までをTerraformで行ない、Lambdaとトリガー設定（Terraformで作ったSNSに接続）までをServerless Frameworkで実装という形にしました。
ServerlessFrameworkを使うことで、デプロイの範囲をLambdaとトリガー部分だけに制限することで、改修作業が簡単になります。
これにより、インフラエンジニアとアプリケーションエンジニアの協力がスムーズに進みます。
7．まとめ: システム監視の未来へ向けて
システム監視と通知は、現代のIT環境において欠かせない要素です。
適切なツールと手法を選び、効率的に運用することで、システムの安定性を保つことができます。
- 障害通知やリソース状況通知を活用して、システムの健康状態を常にチェック
- MSP／外部監視SaaS／自前実装のメリット／デメリットを理解する
- 通知はメールよりもSlackを活用し、リアルタイムで対応
- Chatbotの限界を理解し、必要に応じてLambdaでカスタマイズ
- SNSとLambdaの連携で柔軟な通知システムを構築
- Pythonを使って簡単に実装し、将来的な自動化も視野に入れる
これらのポイントを押さえることで、システム監視＋初動対応が一段とレベルアップします。
このブログが皆さんのシステム運用のお手伝いになればと思います。
スパイダープラスでは一緒に旅をするIT戦士を募集中です。
採用サイトもぜひご覧ください。
