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

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の料金については
わたしもそう思います

Dynamo DB も「確保した量」じゃなくて「使用した量」に課金してくれるようになると使いやすくて嬉しいんだけどなー #serverlesstokyo

— もっぱら (@toricls) November 9, 2016

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

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

• 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で使用できない文字が入るため、問題ない文字列に置換して送信する

  • DynamoDB Streamは、ラベル名に 2015-05-11T21:21:33.291 と日時が入ってしまう
    • [http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Streams.html]
  • Mackerelのサービスメトリックに使えるのは、 （[a-zA-Z0-9._-]+）
    • [https://mackerel.io/ja/api-docs/entry/service-metrics#post:title]
    • つまり、そのままMackerelに送るとエラーになってしまう
  • 2015-05-11T21:21:33.291 がメトリクス名に入っても意味不明なのでStreamだよってわかりやすい名前に置き換えて送った

さいごに

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