DynamoDBの監視をMackerelでやって苦労したとこ

  • 2
    いいね
  • 0
    コメント

Advent Calendarっぽいことを

昨日までは、HaiToによる記事二連発です。明日は期待の若手がまた何か深いことを書いてくれそうです。
僕は、自分の仕事内容について社内LTで話したときの内容をまとめてみました

DynamoDBとは

DynamoDBは、AWSによって管理されるNoSQLサービスです。
データとトラフィックが多数のサーバで分散されて管理されます。
利用者は容量の増加やパフォーマンスに関する心配事を減らすことができます。

より詳細にDynamoDBを知りたい方は、ぜひおググりいただければと思います。
一応、ドキュメントへのリンクを置いておきますね。

Amazon DynamoDB ドキュメント

Mackerelとは

Mackerelは、はてなが開発したサーバ管理・監視ツールです。
いい感じの見た目をしていて、APIであれこれできたり、Goで書かれたCLIツール(mkr)があったりします。
個人的には、監視設定をmkrコマンドで pull/push できる機能が好きです。

Mackerelについても詳しく知りたい方は、ぜひおググりいただければと思います。

DynamoDBならではなところ

DynamoDBの料金は、確保したキャパシティの量が関わってきます。
CloudWatchでは、確保したキャパシティの量と、消費したキャパシティの量を取得することができます。
そして、確保したキャパシティを超えたリクエストは失敗してしまうので、
現在のキャパシティ消費率が気になるところでしょう。
後述しますが、このキャパシティ消費率を計算してMackerelにサービスメトリクスとして投稿するようにしています。

ところで、DynamoDBの料金については
わたしもそう思います

監視をする上で工夫したところ

実際のコードなどは載せませんが、工夫した点をざっとまとめました

  • DynamoDBのキャパシティ消費率に関するメトリクスがないため、Lambdaで計算する
    • CloudWatch→Lambda→Mackerelという流れでメトリクスを収集している
    • 各テーブルのRead/Writeそれぞれについて
    • (Consumed[Write/Read]Capacity / Provisioned[Write/Read]Capacity)*100 を計算して割合としてMackerelに送信
  • CloudWatchが5分以上昔のDynamoDBメトリクスを送ってくるため、0で埋める
    • タイムスタンプを見て、古い値は0で埋めてMackerelに送るようにした
  • CloudWatchのDynamoDBメトリクスが歯抜けすることがあるため、0で埋める

    • 歯抜けしてるメトリクスがあれば、0で埋めてMackerelに送るようにした
  • DynamoDB StreamのラベルにMackerelで使用できない文字が入るため、問題ない文字列に置換して送信する

さいごに

サーバーレス時代のイケてる監視について、知見を深めていくぞい!