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

はじめに

今日は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キャラクターと出力されています。

次に、もっと長い文章を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キャラクターと出力されています。

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です。

次に、もっと長い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です。ちょっとレイテンシが上がりました。

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