Web Developer's Struggle Memories

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

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

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の監視とサーバ内部の監視を別々に行う必要あり
      • CloudWatchとzabbixの2つをそれぞれ監視するのが面倒
    • 監視の統合
      • CloudWatch側の監視値を外部チェック設定でzabbixに送信
      • zabbixは外からの情報は受け付けられる
      • もしzabbixが落ちたらCloudWatchが通知を送る設定、などが必要

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

CloudWatchEventについて

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

CloudTrailについて

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

最後に

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