昨日までのはこちら
100日後にエンジニアになるキミ - 88日目 - データ - データ転送について
100日後にエンジニアになるキミ - 86日目 - データベース - Hadoopについて
100日後にエンジニアになるキミ - 76日目 - プログラミング - 機械学習について
100日後にエンジニアになるキミ - 70日目 - プログラミング - スクレイピングについて
100日後にエンジニアになるキミ - 66日目 - プログラミング - 自然言語処理について
100日後にエンジニアになるキミ - 63日目 - プログラミング - 確率について1
100日後にエンジニアになるキミ - 59日目 - プログラミング - アルゴリズムについて
100日後にエンジニアになるキミ - 53日目 - Git - Gitについて
100日後にエンジニアになるキミ - 42日目 - クラウド - クラウドサービスについて
100日後にエンジニアになるキミ - 36日目 - データベース - データベースについて
100日後にエンジニアになるキミ - 24日目 - Python - Python言語の基礎1
100日後にエンジニアになるキミ - 18日目 - Javascript - JavaScriptの基礎1
100日後にエンジニアになるキミ - 14日目 - CSS - CSSの基礎1
100日後にエンジニアになるキミ - 6日目 - HTML - HTMLの基礎1
本日はに監視についてです。
監視について
プログラムの開発段階ではあまり気にすることではありませんが
サービスなどのリリース後は稼働状況を把握するために様々なところで監視を行っています。
監視ではどのようなことを行っているかと言うと
カテゴリとしては
サーバー監視
ログ監視
ネットワーク監視
などがあります。
サーバー監視
サーバー監視は一般的に以下2つカテゴリに大別できます。
異常監視
サーバーに何らか異常が起きている場合に、管理者へ通知します。
メールやツールといったオンラインでの通知や、音声・ランプ点灯といった
オフラインでの通知方法が普及しています。
サーバーの異常の内容としては
死活監視:サーバーがネットワークから切り離されていないかどうかを監視する
故障監視:サーバーが壊れていないかを監視する
などがあります。
異常を検知したらサービスに支障が出る場合はすぐに対応をしなければなりません。
監視を外部に委託した場合は24時間体制でサーバーの監視をしてもらうこともあり
インフラやアプリケーション担当者は夜中に電話でおこされる事もあります。
正常監視
正常なサーバーの稼働を常に監視し、正常監視は常時行われます。
稼働状況のチェックには、サーバーの監視ツールが用いられます。
正常に稼働していても、サーバーが故障の兆候を発信する場合もあり
オンプレミスでの稼働はデータセンターなどで交換作業を行ったりする事もありました。
クラウドベースになると故障の対応をする必要はないのでインフラ側は
かなり楽になります。
稼働状況を監視する場合は
CPUやメモリの利用率、過去の最大稼働時の負荷や平均的な負荷などを見て
サーバーの負荷が足りていなければ増設したり対応をすることになります。
ログ監視
アプリケーションが出力するログの内容を監視して対応をします。
アプリケーションが出力するログの種類としては
Webログ:ユーザーがアクセスした際のログ
アプリケーションログ:アプリケーションが稼働時に出力するログ
エラーログ:アプリケーションが異常を発した際のログ
etcなどかなりたくさんの種類があります。
良くあるケースだとアプリケーションログから毎日実行されている
バッチ処理の時間を見てみたりして、正常な時間の範囲で処理が終わっているかをみたりします。
毎日の集計が1日で終わらなければ当然問題になるので対応を迫られることになります。
また、サーバーの監視と同じくエラーログの監視は特に重要です。
エラーが頻発する場合は、そもそもアプリケーションの作りがあまく
ロジックを見直すなどの改修をしたり、負荷を分散させるために設計の見直しをしなければ
ならない可能性も出てきます。
マスターデータの投入に失敗していて、人為的なミスでエラーが検知されたりすることもあります。
そういった異常時の対応がきちんとできる仕組みづくりを考えておく必要があるので
アプリケーションの設計段階で、ログの出力をきちんと設計しておかねばなりません。
ネットワーク監視
ネットワークは、企業のビジネスにおいて不可欠なインフラです。
24時間365日の常時接続が一般的であるため、営業時間外にも
ユーザーは企業のWebサイトにアクセスしてきます。
そのためネットワークがダウンすると企業は大きな損害を被ります。
ネットワークの正常な稼働を維持する監視体制が重要になってきています。
データセンターではサーバー意外にも様々な機器が稼働しているため
それら全ての機器が正常に稼働し続けているかを常時監視しなければなりません。
またネットワークでは死活や遅延なども発生します。
ネットワークが正常に働かない場合にどう対処するのかも
監視体制と合わせて重要になってきます。
ここらへんは運用前に監視体制や障害時のフローをあらかじめ決めておかないと
対処する事はできません。
監視ツールについて
サーバーやネットワーク、ログなどの監視は、通常は監視ツールを用いて行います。
おおまかにはオンプレミスでサーバーにインストールして運用するものと
クラウドサービス側で用意をしている監視サービスに分かれます。
Zabbix
Zabbixはサーバ、ネットワーク、アプリケーションを監視するための統合監視ソフトウェアです。
オンプレミス環境でサービスを運用していた際に自分らも使用していました。
障害時は関係各所へメール送信したり細かく設定できます。
クラウド上であっても、EC2などのインスタンス上にインストールして
死活監視などを行うことができます。
AWS CloudWatch
CloudWatchは、AWS、ハイブリッド、オンプレミスのアプリケーションリソースと
インフラストラクチャのリソースに関するデータ、および、実用的なインサイトを
取得できるモニタリングと管理のサービスです。
フルマネージド運用監視サービスであるので、監視ツールなどを
インストールする必要もありません。
様々なクラウドサービスも監視できるので、これで十分と言う事もあります。
GCP Stackdriver
こちらはGoogleが提供するGCPのサービスです。
クラウドベースのアプリケーション向けに統合化された、監視機能やロギング機能を
提供するモニタリングツールでGCPだけでなく、AWS上で動くリソースの監視や
情報収集、診断が行うことができるというものです。
まとめ
サービスを安全に継続するためには監視の仕組みが不可欠です。
監視を正しく行うにはアプリケーションの設計段階で障害に対応するための考慮や
ログの出力などをうまく行う必要があります。
ログが正しく出なければ監視もできなくなりサービスが停止してしまい
サービス停止は企業に大きな損害をもたらします。
WEB系のサービス開発を志望するのであれば、ログの仕組みや
監視の仕組みなど運用面にも目を向ける必要があります。
君がエンジニアになるまであと09日
作者の情報
乙pyのHP：
http://www.otupy.net/
Youtube：
https://www.youtube.com/channel/UCaT7xpeq8n1G_HcJKKSOXMw
Twitter：
https://twitter.com/otupython