概要 最近AmazonConnectを触っていますが、ConnectではAmazonPollyによる音声読み上げに対応しており、一般的な用語に関しては日本語でも比較的スムーズな発音で読み上げてくれます。 しかし、造語だったり、復数の意味があるものだったりすると自然な発音をしてくれない場合があります。 そこで、調べてみると、AmazonPollyではSSML（Speech Synthesis Markup Language）というXMLベースのマークアップ言語を使うことで、読み上げ方をカスタマイズできるそうです。 12ヶ月は500万文字まで無料で、超えても3100文字で0.01USDなので試してみることにしました。 AmazonPollyの料金 中々発音が疑問になるような単語を探すのが難しいのですが、今回はいつもお世話になっている「はてなブックマーク」を選択してみました。 SSMLを使わないパターン まずはSSMLを使わずに、プレーンテキストにします。 https://inamuu.com/wp-content/uploads/2020/04/polly_01.mp3 そのままだと「はてなブックマーク」の「ブック」が強調されて、やや違和感があります。（いやこれが正しいんだという意見もあるかもしれませんが、一応Youtubeではてなの中の人の発音を聴いて判断してます） SSMLを使ってみる 早速SSMLを使って書いてみます。 文字を強調したり、速度を変えたりすることで雰囲気を変えられるようですが、今回はピッチを調整するようにしました。 <speak> <prosody pitch="-20%">はてな</prosody> <prosody pitch="0%">ブック</prosody> <prosody pitch="+10%">マーク</prosody> </speak> https://inamuu.com/wp-content/uploads/2020/04/polly_02.mp3 今度は、ブックマークの部分はマークの部分が強くなったので自然になった反面、「はてな」の部分が尻下がりになりました。 これでも良さそうですが、より普通っぽくするには「はてな」を平坦にしたいと思い、思考錯誤した結果が下記です。 <speak> <prosody pitch="-20%">ハテナ</prosody> <prosody pitch="0%">ブック</prosody> <prosody pitch="+10%">マーク</prosody> </speak> https://inamuu.com/wp-content/uploads/2020/04/polly_03.mp3 「はてな」の部分をカタカナの「ハテナ」へ変更しました。 こうした所、「はてな」の部分のアクセントが無くなり、意図したアクセントの発音になりました。 なお、音声を女性のMizukiからTakumiに変えた所、マークが強調されて逆におかしく聴こえるようになりました。 音声によっても、微調整が必要そうです。 まとめ 今回はAmazonConnectの流れで、Pollyを試してみました。 機械音声だから、ある程度のアクセントの微妙さは仕方がないと思いつつ、アレクサのように喋らせたいと思ったら同様にSSMLを調整することで、自然な発音になりそうです。 どうしても日本語の処理は微妙になりがちですが、今はこのようにやればある程度は調整ができるので、アレクサ開発やAmazonConnectのアナウンスで調整してみようと思います。 <p style='padding: 5px;'>

概要 AmazonConnectでコールセンターを提供したいと考えた場合、幾つかの設定を変えないと、そのままでは意図しない英語のメッセージが流れることがあります。 Connectではデフォルト設定ですぐに始められるようになっている分、自動的に流れるアナウンスや英語設定のままになっているところがあります。 そのため、日本語で対応をしたい場合の初期セットアップをメモしておきます。 顧客キュー 単純な日本語分岐でループなどを考えない一方通行のフローでしたら、問い合わせフローエディターで一番最初に 音声の設定 でMizukiかTakumiを選べば日本語になります。 しかし、一般的にコールセンターであれば対応出来るメンバー（AmazonConnectではエージェントと呼ばれる権限）は人数が限られ、その人数を超えた場合に問い合わせがあると待機状態になります。 AmazonConnectではこれを顧客キュー という名前でループさせることが可能です。 デフォルトでは、顧客に対してキューに入ると一度 英語 のアナウンスが流れてから軽快なメロディーが流れ出します。 Thank you for calling. Your call is very important to us and will be answered in the order it was received. と聴こえたら Default customer queue という顧客キューのキューに入った状態です。 英語が突然流れてきたら顧客は驚いてしまいますので、下記手順で新らたに顧客キューを作成してあげることで英語を流さないようにする（または日本語アナウンスにする）ことが可能です。 まず、Connectへログインして、問い合わせフローエディターのルーティングから問い合わせフローを選択します。 次に「顧客キューフローの作成」を選択します。なお、このプルダウンの選択を間違えるとあとから変更が出来ないのでよく見て選択しましょう。 顧客キューフローで必須なのは エントリーポイント→プロンプトのループ→エラー時の処理→終了 です。 プロンプトのループでは幾つかデフォルトで選択できるwav形式のファイルがあり、そこから待機音楽が流せます。 もしも、キューに入れる前に 現在混み合っております 的なメッセージを流したければ、ここで一度プロンプトの再生でテキストメッセージを流してからループに入れるのが良さそうです。 ここまできたら、後はメインの問い合わせフローをエディタから開き、対象のキューにセットしたい箇所でセットします。 今回は分岐を入れていませんが、顧客の押下したボタンの番号に応じて、キューを分けることが可能です。 分岐の後に顧客キューをセットするのが良さそうです。 ここまで実施すると、簡単な問い合わせフローが日本語で設定出来ます。 分岐先にLambdaを設定したり、Lambdaが返した戻り値をそのままConnectで流すことも可能です。 まとめ 昨年、とある業務で簡単なフローはAmazonConnectで作成できましたが、コールセンターのフローまでは未検証でした。 今回ちょっと検証してみたことで、小さなコールセンターであれば対応できる人さえいれば、数日以内には作成できてしまうでしょう。 他にも、Lambda連携をすることで、プログラマブルに電話をハックすることが出来て大変面白いツールになっていますし、メッセージもAmazonPollyがデフォルトで対応していて日本語にも対応しているため、若干機械音声ではあるもののテキストを自動音声でそのまま読み上げてくれます。（英語は流暢に聴こえます） 大変便利なツールなので、是非試してみてください。 <p style='padding: 5px;'>

はじめに 副業先で一からAWS環境を作成することになり、そろそろ準備を考えてたときに、ふとTerraformCloudのことを思い出しました。 https://www.hashicorp.com/products/terraform/pricing/ 最低の有料プランのチームで使う場合の違いとして権限管理が異なり、個人ユーズなら無料でも十分使えます。 また、tfstateをS3等で管理したくないのもあり、思い切ってTerraformCloudに任せてみることにしました。 ※なお、AWSアカウントがあり、Terraformに触れたことがある方だったら30分もかからずにセットアップができます。 まずはリポジトリ連携 GitHubでTerraformを管理するリポジトリを作成し、TerraformCloudでWorkspaceを作成します。 この時に、特定のディレクトリをTerraform専用ディレクトリとしている場合は、変更を検知するディレクトリを指定できます。 私の場合は、今回は同じリポジトリでインフラを全部管理する予定だったため、シンプルに「terraform」というディレクトリを作成して指定しました。 backend.tfで変数指定 backend.tfファイルを作成して、varでAWSのアクセスキーとシークレットキーを変数で指定します。 provider "aws" { access_key = var.aws_access_key secret_key = var.aws_secret_key region = "ap-northeast-1" } variables.tfで下記のようにします。 variable "aws_access_key" {} variable "aws_secret_key" {} variable "aws_region" { default = "ap-northeast-1" } そして、Pushする前にTerraformCloudでAWSのアクセスキーとシークレットアクセスキーを登録します。 秘匿情報の場合はSENSITIVEを選択すると、中を確認することが出来ないように設定できます。 この辺はCircleCIなんかと使い方は似ていますね。 早速VPC用のtfを作ります。 resource "aws_vpc" "test-vpc" { cidr_block = "192.168.0.0/16" instance_tenancy = "default" enable_dns_support = true enable_dns_hostnames = true tags = { Name = "test-vpc" } } ここまで来たらテストなのでmasterへPush。

概要 今回は、ElasticCloudからAmazon Elasticsearch Searvice（Amazon ES）への移行を検証するために手動によるスナップショットの取得手順を確認したのでその記録。 ElasticCloudはElastic社が提供するElasticsearchのマネージドサービス。 サーバーへインストールするタイプと同じで、RESTfulAPIによる手動スナップショットがサポートされている。 なお、30分おきに自動でもスナップショットが取得されており、リストアができる。 ポイント ElaticCloudのバックエンドはAWSで、スナップショットの取得先として、Amazon S3を使用している。 そのため、ElasticCloudで利用しているリージョンと同じリージョンのS3を自分たちで管理しているアカウント上に作成し、下記権限を与えてあげることでリポジトリ登録ができる。 Snapshot and Restore with Custom Repository 本作業はElaticCloudのES環境で実施したが、Elasic社のドキュメントを見る限りは自分でインストールして管理しているESでも（細かい点は不明だが）基本的には同様のことがおこなえると思われる。 手順 バケットを作成したら、下記IAMポリシーを作成する。 { "Statement": [ { "Action": [ "s3:*" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::自分で作成したバケット名", "arn:aws:s3:::自分で作成したバケット名/*" ] } ] } 新規でIAMユーザーを作成して、上記IAMポリシーをアタッチする。 ※新規でというのは、作成したIAMユーザーのアクセスキーとシークレットアクセスキーをElasticCloudへ設定する必要があるため。 手動のスナップショット取得 Elasticsearchのスナップショット取得は、スナップショット取得の前にリポジトリ登録が必要である。 このリポジトリというものがなんなのか最初わからなかったが、スナップショットを取得するのに必要なもののようだ。 リポジトリ登録前 上述の通り、ElasticCloudは自動的にスナップショットが取得されている。 そのため、下記を実行するとfound-snapshotsというリポジトリが既に登録されているのがわかる。 curl -XGET "https://エンドポイント/_snapshot/_all?pretty" { "found-snapshots" : { "type" : "s3", "settings" : { "bucket" : "バケットを示す文字列", "server_side_encryption" : "true", "base_path" : "snapshots/文字列", "

先日、とあるサービスで自前運用していたDNSサーバーをAWSのRoute53へ移設しました。 その移設の際に学んだ下記二点について、大変良い勉強になったので、折角なのでまとめておきます。 BINDからRoute53への移設方法 DNSのNSレコード移設時のポイント 移設前の環境 移設前のサーバーは他社のマネージドタイプの専用サーバーを契約しており、CentOS5のBINDで稼働していました。 DNSのセカンダリーには、そのマネージドサービスの無料のセカンダリーDNSサービスを利用しており、管理はマスターのみ実施しておりました。 移設が必要なゾーンは１つ。レコードが5000程度ありました。 また、ユーザーさんから申し込みがあった際に、BINDの動的更新を利用してレコードの追加が行われていました。 移設に至った経緯 大きくはCentOS5がEOLになったこと、BINDの脆弱性が多く、DNSの運用コストが課題となっており、自前運用のメリットが殆どなかったことが挙げられます。 そこで、マネージド・サービスであるRoute53への移設することで、BINDの脆弱性対応などのDNS運用コスト、および専用サーバー費用を下げられないかを検討することになりました。 Route53のコスト計算 Route53のコスト計算で最も重要なのは、現在のDNSでどの程度のクエリが発行されているかということになります。 とは言え、BINDのクエリーログの出力はIO負荷が高く、常時オンにしている環境は殆ど無いと思われます。 そこで、一時的にクエリーログをオンにして、そこから単純計算を実施しました。 クエリーログの有効には、named.confに直接記述する方法と、rndcコマンドで一時的に有効にする方法があります。 今回は一時的に出力する目的でしたので、rndcを使って、クエリーログを出力しました。 なお、デフォルトではmessagesにqueryログが出力されます。 query logがoffであることを確認する。 # rndc status query logging is OFF query logをonにする。 # rndc querylog query logがonになっていることを確認する。 # rndc status query logging is ON query logを停止する # rndc querylog query logがOFFであることを確認する。 # rndc status query logging is OFF 上記でクエリーログをオンにした時間とクエリーログ数で、概算の月間のクエリー数を算出し、Route53の見積もりを出します。 Route53の見積もりについては、言うまでもなくAWS簡易見積もり計算ツールを利用しています。 結果、専用サーバーの月額費用よりも圧倒的に安価であることがわかったので、Route53への移設を進めることにしました。 ※これは私の肌感ですが、AWSのEC2などのVMのサービスと比較すると、Route53だけ突出して安いように思います。 移設の手順 ここで言う移設は、事前準備が終わった状態で、レジストラに登録されているNSレコードまで切り替えが完了するまでになります。 安全に、そして、スムーズに移設するために実施した手順の概要が下記流れになります。