読者です 読者をやめる 読者になる 読者になる

WEBエンジニア奮闘記

日々の業務から思ったこと、学んだことを書き連ねていきます。

社内のAWS勉強会「監視について」のメモ

前回の社内のAWS勉強会(続き)のメモの続き。今回は結構実運用的な話。本日の内容はこちら。

  • AWSの監視
  • 他の監視サーバとの統合監視について
  • 監視に関連するサービスの紹介
  • 監視事例の紹介

※以下、価格については東京リージョンのものとします。

AWSの監視

AWSの監視の中核はCloudWatch

  • AWSの監視サービスの全体像
    CloudWatchがAmazon SNS(通知)やS3(ログ出力など)やLambda(バッチなどの処理実行)やCloudTrail(操作記録)などをキックする。

  • AWAの監視Cloud Watchについて

    • できること
      • 外からの監視
        • EC2の監視
        • CPU利用率
        • ディスクIO状況
        • ネットワーク利用量
      • その他のAWSサービスの監視
        • DynamoDB
        • EBSボリューム
        • RDS
        • ELB
        • SQSなど
      • カスタムメトリクスの利用
        • DMのメールキュー数を監視
      • ログのモニタリングと保存
      • アラームの設定
        • しきい値を超えた場合の処理の設定
        • 自動的なスケールアウトなど
      • グラフィカルなグラフ表示
      • ServiceChargeTotalを監視(課金の監視など)
    • できないこと
      • 1分未満のリアルタイム性(通常は5分間隔)
      • サーバ内部の状態監視
        • モリー監視など
        • サーバ側に細工が必要
      • ディスクの使用率、残容量
      • アラーム時にサーバー内部のコマンド実行
      • 2週間以上の監視データの保存
        • DynamoDB等を利用した簡単なスクリプト等で処理させる必要あり
      • ELBの負荷状況の見る つまり外からの監視は可能!サーバ内部のOS依存部分は直接監視不可。
  • 料金体系
    ちょっと複雑な体系。

    • 無料枠
      • EC2インスタンスの基本モニタリングのメトリクスを5分間隔で利用可
      • 最大50個のメトリクスからなるダッシュボード3つを利用可
      • 1ヶ月あたり5GBまでのストレージ利用
    • 有料
      • 1ダッシュボード追加
        → 1ダッシュボードあたり $3/月
      • EC2の1分間隔の詳細モニタリング
        → 1インスタンスあたり $3.5/月
      • メトリクスのカスタマイズ
        → 1メトリクスあたり $0.50/月
      • アラーム
        → 1アラームあたり $0.5/月
      • APIリクエスト
        GetMetricStatistics, ListMetrics, or PutMetricDataのリクエスト1,000 件あたり $0.01/月
      • ログ
        → 取り込み GBあたり $0.76
        → GBあたりのアーカイブ $0.033/月
      • カスタムイベント
        → 100万カスタムイベント作成あたり $1.00

多くのメトリクスを設定せず、通常の利用範囲なら結構安価。

他の監視サーバとの統合監視について

  • AWS側の監視とサーバ側の監視
    • AWS監視とは?
      • AWSが提供するのはインフラ、つまり、よりサーバ側に近い部分の監視
      • CPU使用料の監視
      • ネットワークの監視
      • ディスクIOの監視
    • 一般的なサーバ内部の監視
      • nagios, zabbix, MRTG, munin等でリソースの監視、死活監視
      • AWS側(つまりハードより)の監視は直接はできない
  • 監視の二重化による問題点
    • AWSの監視とサーバ内部の監視を別々に行う必要あり
      • CloudWatchzabbixの2つをそれぞれ監視するのが面倒
    • 監視の統合
      • CloudWatch側の監視値を外部チェック設定でzabbixに送信
      • zabbixは外からの情報は受け付けられる
      • もしzabbixが落ちたらCloudWatchが通知を送る設定、などが必要

監視に関連するサービスの紹介

CloudWatchEventについて

  • 2016/1にリリース
  • ほぼリアルタイムに監視可能
  • イベントはLambdaSNSトピックなどにふりわけられる
  • 周期的な実行が可能
  • その他利用方法
    • EC2の起動・停止時のイベント処理
    • 決められた時間にEBSのスナップショット取得
  • つまりバッチサーバ的な動作が可能
  • 100万イベント(データ量64KBにつき1イベントとする)で$1

CloudTrailについて

  • AWSAPIの呼び出しの記(ログの記録ではない!)
  • EC2の起動・停止も含む
  • 誰がいつ何をどのように処理したのかを可視化
  • コンプライアンス
  • 一定の操作を行った場合のSNSの通知機能
  • 基本的に無料
    • 追加証跡情報を利用すると、10万イベントで$2発生
    • 7日間以内のイベント参照であれば無料
    • 7日以降はS3のストレージ料金が発生

SQSについて

  • AWSのメッセージキューサービス
  • 個別送信、ブロードキャスト送信に対応
  • iOS, Android, Java, Python, PHP, Node.jsなどに配信可能
  • キューサービス、Lambda関数, 電子メール, HTTPエントリポイントに配信可能
  • CloudWatchと連携し、モバイルへのSNS通知の成功・失敗率の算出が可能
  • 料金
    • キューの発行 $0.5 / 100万件
    • キューの送信 $0.5 / 100万件

Lambdaについて

  • 今後主流のサービス
  • サーバレスでコードを実行可能
  • API Gatewayを使用したHTTPリクエストからもコードを実行可能
    • APIサーバとしての役割が可能
  • 現時点でNode.js, Python, Javaに対応
  • 1秒ごとに数個から数千までのリクエストに対してオートスケール
  • サーバレスのマイクロサービスが構築可能
  • 制限
    • テンポラリの容量は512MBまで
    • リクエストの最大実行時間300秒
    • リクエスト・レスポンスのデータ容量は6MBまで
    • アップロードプログラムサイズは250MBまで
  • 料金は $0.2 / 100万リクエスト
    • メモリの利用時間じ応じたコスト(コスト単位)

AutoScaleについて

  • 高負荷をCloudWatchが検知し、自動的にEC2をスケールアウト
  • 指定した最大台数までスケールアウト可能
  • 自動でインスタンスを追加・削除の設定が可能

監視事例の紹介

  • 事例の構成

    • ELB, EC2-2台(webサーバ), それぞれのEC2の裏にEC2(APIサーバ)、RDS(詳しくは下図参照) f:id:kito0039:20160613114014p:plain
  • 問題点

    • APIサーバで障害が発生しても、ELBからWEBサーバへのアクセが発生しエラー
  • 解決方法
    • webサーバに監視用のphpスクリプトを実装し、APIサーバを監視
    • ELBがそのPHPスクリプトを監視
    • API障害時には404を返却するのでELBがエラーと認識できる
    • ELBは傘下のwebサーバでエラーを検知した場合、そのサーバとの接続をやめる
    • APIサーバが復旧するとPHPもステータス200を返すので、ELBがInServiceとする

最後に

駆け足の説明だったので、一部説明が足りない部分があると思うので、確認しつつ更新します。