Amazon PollyのCloudWatchメトリクスについて #reinvent

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

今日はAmazon PollyのCloudWatchメトリクスについて確認してみました。

Amazon PollyのCloudWatchメトリクスについて

メトリクスの種類

Amazon PollyのCloudWatchメトリクスは以下の種類があります。

Operationディメンション メトリクス 概要 単位
DescribeVoices 2XXCount DescribeVoices APIに対して正常なレスポンスとして返された200番台のHTTPステータスコード。
DescribeVoices 4XXCount DescribeVoices APIに対してエラーレスポンスとして返された400番台のHTTPステータスコード。
DescribeVoices 5XXCount DescribeVoices APIに対してエラーレスポンスとして返された500番台のHTTPステータスコード。
ListLexicons 2XXCount ListLexicons APIに対して正常なレスポンスとして返された200番台のHTTPステータスコード。
ListLexicons 4XXCount ListLexicons APIに対してエラーレスポンスとして返された400番台のHTTPステータスコード。
ListLexicons 5XXCount ListLexicons APIに対してエラーレスポンスとして返された500番台のHTTPステータスコード。
SynthesizeSpeech 2XXCount SynthesizeSpeech APIに対して正常なレスポンスとして返された200番台のHTTPステータスコード。
SynthesizeSpeech 4XXCount SynthesizeSpeech APIに対してエラーレスポンスとして返された400番台のHTTPステータスコード。
SynthesizeSpeech 5XXCount SynthesizeSpeech APIに対してエラーレスポンスとして返された500番台のHTTPステータスコード。
SynthesizeSpeech ResponseLatency SynthesizeSpeech APIに対してのリクエストからレスポンスまでのレイテンシー。 ミリ秒
SynthesizeSpeech RequestCharacters SynthesizeSpeech APIに対してリクエストされた文字数。SSMLタグはカウントされない。

このうちHTTPステータスコードのカウントは試しても面白くないので、SynthesizeSpeech関連のメトリクスを試してみたいと思います。

SynthesizeSpeech: RequestCharacters

まず、以下の文章をPollyに食わせます。

aws polly --region="us-east-1" synthesize-speech \
--text "Classmethodはブログの会社です。" \
--voice-id Mizuki \
--output-format mp3 speech.mp3

レスポンスは以下の通り。21キャラクターです。

{
    "ContentType": "audio/mpeg",
    "RequestCharacters": "21"
}

CloudWatchで確認。ちゃんと21キャラクターと出力されています。

CloudWatch_Management_Console 3

次に、もっと長い文章をPollyに食わせます。

aws polly --region="us-east-1" synthesize-speech \
--text "Classmethodはブログの会社です。年間3000本の技術ブログ記事をアウトプットしています。" \
--voice-id Mizuki \
--output-format mp3 speech.mp3

レスポンスは以下の通り。49キャラクターです。

{
    "ContentType": "audio/mpeg",
    "RequestCharacters": "49"
}

CloudWatchで確認。ちゃんと49キャラクターと出力されています。

CloudWatch_Management_Console 4

SynthesizeSpeech: ResponseLatency

まず、以下の21キャラクターの文章をPollyに食わせます。

aws polly --region="us-east-1" synthesize-speech \
--text "Classmethodはブログの会社です。" \
--voice-id Mizuki \
--output-format mp3 speech.mp3

CloudWatchで確認。ResponseLatencyは124.85msです。

CloudWatch_Management_Console_2

次に、もっと長い49キャラクターの文章をPollyに食わせます。

aws polly --region="us-east-1" synthesize-speech \
--text "Classmethodはブログの会社です。年間3000本の技術ブログ記事をアウトプットしています。" \
--voice-id Mizuki \
--output-format mp3 speech.mp3

CloudWatchで確認。ResponseLatencyは127.64msです。ちょっとレイテンシが上がりました。

CloudWatch_Management_Console 5

ではもっと長文を食わせてみましょう。以下の文章は272キャラクターあります。

aws polly --region="us-east-1" synthesize-speech \
--text "クラスメソッド株式会社は、「クラウド、センサー、ビッグデータ、モバイル」の技術を活用した企業向けの技術支援を行っており、800件を超える実績を残しています。2015年よりAWSプレミアコンサルティングパートナーとして多くのお客様のAWS活用を支援し、お客様ビジネスに貢献しています。全社的な取り組みとして、社員による情報発信に力を入れており、オウンドメディア「Developers.IO」にて約7,000本の技術情報を公開しています。また、多様な働き方を支える取り組みにも力を入れ、2013年に東京ワークライフバランス認定企業に認定されました。" \
--voice-id Mizuki \
--output-format mp3 speech.mp3

CloudWatchで確認。ResponseLatencyは144msです。文章量が5倍になった分レイテンシは上がっていますが、大幅な向上ではありません。早いですね。

CloudWatch_Management_Console 6

さいごに

CloudWatchのメトリクスについての確認と、文章量が増えても大幅にレスポンスが遅くなる訳ではないことがわかりました。もちろんWebページ全体とか本1冊とかを読ませるとその分時間が長くはなりますが、ある程度細切れに処理すればストレスになるほどでは無さそうです。