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キャラクターと出力されています。
次に、もっと長い文章を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冊とかを読ませるとその分時間が長くはなりますが、ある程度細切れに処理すればストレスになるほどでは無さそうです。
