DynamoDBがオンデマンド(リクエスト数課金)を選択できるようになったので本番投入してみる

どうもこんにちは。

DynamoDBがオンデマンド(リクエスト数課金)を選択できるようになり本当に涙が出そうなくらい喜んだわんこ。です。

f:id:tt-utsumi:20200707145415j:plain Photo

HAROiDでは、TV番組のプレゼント応募の仕組みなどを運用していたりもします。このプレゼントの運用がなかなか曲者で…色んな番組や特番、または定常的にWebからの応募も受け付けるというものでして…

設計段階で、できれば 大型特番とか被っても大丈夫なスケーラビリティあふるる設計に という要望がありました。

そのためプレゼント企画ごとにDynamoDBを分けてしまい、その企画規模にあったスケールを行っていたのですが…

めちゃくちゃむずい

視聴率や告知のタイミングによっては想定の30倍くらいのリクエストになることもあったり、はたまた逆もあったり…。でも心配だから大きめにスケールしておいて番組終了時にまた下げる…なんてことをやってたんですが…そこに女神のごとく降臨したオプションが…

BillingModeのPayPerReuqustですよ!!!!

いや、ほんと神様は見てくれてるんだなって思いました。この発表の前日でも某音楽番組のプレゼント企画を行っていて、90個以上のテーブルのスケール作業や監視作業を行っていました。

TV番組での連動だと、負荷ってほんとに高スパイク短時間なので、スケールしているほとんどの時間はリクエストがない状態です。

もう、ね？完璧にこのプロダクトのためにリリースしてくれたんだな。って思いました。

ってことで早速負荷検証してみたいと思いまして、さくっと千手観音でぶん殴ってみました。

APIでの設定

aws-sdk-goでは対応済み (2018/11/30 12時現在)
dynamodb.CreateTableInput の BillingMode に dynamodb.BillingModePayPerRequest を設定
BillingModePayPerRequest と ProvisionedThroughput は同時に設定できない（当たり前
このモードでは ProvisionedThroughput は 0 として返ってくるので注意が必要
UpdateTableで同様に既存のテーブルに対しての変更も可能

こんな感じにするだけです。めっちゃ簡単。

input := &dynamodb.CreateTableInput{
    TableName: aws.String(tableName),
    AttributeDefinitions: []*dynamodb.AttributeDefinition{
        {
            AttributeName: aws.String("user_hash"),
            AttributeType: aws.String("S"),
        },
    },
    KeySchema: []*dynamodb.KeySchemaElement{
        {
            AttributeName: aws.String("user_hash"),
            KeyType:       aws.String("HASH"),
        },
    },
    BillingMode: aws.String(dynamodb.BillingModePayPerRequest),
}