Amazon Web Services ブログ

SAP on AWSにおけるVPCサブネットのゾーニングパターン 第3回:内部および外部接続

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。 VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。第2回目では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明しました。このシリーズの最後の記事として、内部接続と外部接続の両方を必要とするSAPアプリケーションの接続パターンを説明します。外部ソースからの接続は管理されていてもよく(つまり、既知の外部の関係者を含む)、管理されていない(つまり、公開されていてもよい)場合もあります。両方のシナリオについて説明します。 内部および管理された外部接続 外部向けインターフェースに対する信頼された外部の関係者からの接続と、内部向けインターフェースに対するSAPと非SAPシステム間またはどちらかの間の接続が必要となる、SAP Process Orchestration(PO)とSAP Process Integration(PI)がこのシナリオの典型的な例です。内部向けインターフェースは簡単に管理できます。基本的には、ルートテーブル、ネットワークアクセスコントロールリスト(ACL)、およびセキュリティグループに適切なトラフィックを定義します。しかしながら、外部接続を安全に提供することには課題があります。そこで、信頼できる外部の関係者からのトラフィックの入口と出口に着目しましょう。典型的な選択肢が4つあります。 入口と出口の両方のための仮想プライベートネットワーク(VPN)接続 入口用のElastic Load Balancing、および出口用のネットワークアドレス変換(NAT)ゲートウェイ NATデバイス(NATインスタンスまたはNATゲートウェイ) リバースプロキシ VPN接続 (入口と出口) 信頼できる外部の関係者と専用の仮想接続を作成する場合は、VPCでVirtual Private Gateway(VGW)を使用するか、パブリックサブネット内にAWS Marketplaceで公開されているような独自のソフトウェアVPNサーバを使用することで、サイト間IPsec VPN接続を確立できます。 注釈   この記事のアーキテクチャ図では、簡単にするために単一のアベイラビリティゾーンで示しています。実際には、高可用性を実現するために、少なくとも2つのアベイラビリティゾーンにわたってソリューションを構成することをお勧めします。 図 1: 管理された外部接続のためのVPNコネクション Elastic Load Balancing (入口) / NATゲートウェイ (出口) Elastic Load Balancingには、次の3つのタイプがあります。 Classic Load Balancer Network Load Balancer Application Load Balancer […]

Read More

AWS コミュニティの新しいヒーローのご紹介 (2017 年 – 秋版)

AWS コミュニティヒーロープログラムでは、世界中の腕の良い AWS デベロッパーによって行われている革新的な作業の一部を紹介しています。このようなヒーローは、クラウドの専門知識と、コミュニティ構築および教育に対する熱意を組み合わせて、ソーシャルメディアや実際に顔合わせができるイベントで時間と知識を共有しています。また、カンファレンスで積極的にコミュニティ型の方向性を促進しています。今年の re:Invent では、多くのヒーローが Monday Community Day トラックでお話しする予定です。 大変うれしいことに、今年の 11 月、AWS のクラウド革新者ネットワークに 4 名のヒーローを迎えます。それでは早速、AWS コミュニティの新しいヒーローをご紹介します。 Anh Ho Viet Thorsten Höger Becky Zhang Nilesh Vaghela Anh Ho Viet Anh Ho Viet は、AWS ベトナムのユーザーグループ の設立者でありながら、OSAM の共同設立者兼 CEO、ベトナムの AWS コンサルティングパートナー、AWS 認定ソリューションアーキテクトという肩書きを持つクラウド愛好家です。 OSAM で、Anh と彼の熱意あふれるチームは、SMB からエンタープライズに至るまで、多くの企業の AWS クラウドへの移行をサポートしてきました。AWS の移行やコンサルティング、アーキテクチャ、ソリューション設計など、そのサービス範囲は多岐にわたります。OSAM に対する Anh のビジョンは、クラウドサービスプロバイダーの範囲にとどまりません。同社は、完全な AWS エコシステムをベトナムに構築し、トレーニングやコラボレーションといった活動を通して、ベトナムの他の企業に AWS パートナーになる機会を与える取り組みを行っています。 2016 […]

Read More

OracleDBからPostgreSQLへの移行

  Knievel Co は、アマゾン ウェブ サービスのデータベースエンジニアです。 このブログ記事では、Oracle データベースを PostgreSQL に移行する方法の概要について説明します。データベース移行の2つの主要部分は、スキーマの変換とデータの複製です。)AWS スキーマ変換ツール (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して、これら 2 つの部分に取り組む方法について説明します。 SCT と DMSについて説明する前に、予備的な手順を実行する必要があります。これらは、すべての移行に役立つことが判明しています。移行を容易にする方法の 1 つは、移行の前に、通常更新フェーズと呼ばれるものを行うことです。このフェーズでは、Oracle データベース内のオブジェクトのインベントリを作成し、いくつかの決定を下します。 最初に、不要になったオブジェクトを削除します。オブジェクトの移行にかかる時間は誰も気にかけませんが、無駄にしないでください。また、不要になった履歴データを削除することもできます。一時的なテーブルや過去のメンテナンス時のテーブルのバックアップコピーなど、不要なデータを複製するために時間を無駄にすることはありません。次に、LOB、CLOB、LONG などに保存されているフラットファイルおよび長い文字列を Amazon S3 または Amazon Dynamo DB に移動します。このプロセスではクライアントソフトウェアの変更が必要となりますが、データベースが簡素化されサイズが削減されることで、システム全体がより効率的になります。最後に、PL/SQL パッケージとプロシージャを移動します。特にビジネスロジックを含むものをクライアントソフトウェアに戻してみます。これらのオブジェクトは、SCT が変換できない場合は手動で変更する必要があります。 次の手順は、異なるデータベースエンジン (この場合は Oracle から PostgreSQL へ) に移行するための手順です。別のプラットフォームに移動していない場合は、データベースを移動するためのより適切なネイティブツールやその他のテクニックがあります。 ターゲットデータベースでスキーマを作成します。 ターゲットデータベースの外部キーとセカンダリインデックスを削除し、トリガーを無効にします。 データを複製するためのDMSタスクを設定します (全ロードと変更データキャプチャ (CDC))。 全ロードフェーズが完了したらタスクを停止し、外部キーとセカンダリインデックスを再作成します。 DMS タスクを有効にします。 […]

Read More

詳解: Amazon ECSのタスクネットワーク

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはコンテナにElastic Network InterfaceをアタッチできるようにするAmazon ECSのTask Networkingを発表しました。 この記事では、ECSが管理するインスタンス(コンテナインスタンスと呼ばれます)上でContainer Networking Interfaceプラグインを使って、この新しいコンテナネイティブなawsvpcネットワークモードがどのように実装されているかを詳しくご紹介したいと思います。 こちらはAmazon ECSでタスクネットワークが動作するかにdeep diveしたものです。もし自身のコンテナ化したアプリケーションでどうやってタスクネットワークを使い始めれば良いかについて学びたい時には、Amazon ECSコンテナにCloud Native Networkingが登場をご覧下さい。Cloud Native Computing Foundation (CNCF)がContainer Networking Interface (CNI)プロジェクトをホストしており、Linuxコンテナでネットワークインターフェースを設定するためのプラグインを書くための仕様やライブラリが含まれています。AWSのクラウドネイティブコンピューティングについての詳細は、Adrian CockcroftのCloud Native Computingについての投稿をご覧下さい。 コンテナインスタンスのセットアップ コンテナインスタンス上でのタスクネットワーク有効化の詳細をご説明する前に、ECSの典型的なインスタンスがどのようになっているかを見てみましょう。 上の図は典型的なコンテナインスタンスを示しています。ECS agentは自身もコンテナとして実行されているのですが、以下のような責任を負っています: EC2インスタンスをECSのバックエンドに登録 コンテナインスタンスに対してECSバックエンドが発生させたタスク状態の変化を、正しく適応 Dockerデーモンと会話しながら、コンテナの作成、開始、停止、監視 コンテナの状態とタスクの状態の遷移をECSバックエンドにリレー ECS agentはその管理下のコンテナのスーパーバイザーの様に動作するので、Dockerデーモン(Dockerのデフォルトネットワークモードで設定されたコンテナ用)、又はCNIプラグイン達(ネットワークモードがawsvpcで設定されたタスク内のコンテナ)のための、ネットワーク設定をする難しさをオフロードしてくれます。 いずれの場合にも、コンテナのネットワークスタックは、ネットワークのnamespaceを通じて設定されます。ip-netns(8)のマニュアルによると「ネットワークnamespaceは論理的なネットワークスタックのコピーで、自身のルーティング、ファイアウォールルール、ネットワークデバイスを持っています。」 とあります。ネットワークnamespaceの構成によって、ホスト上で動いているプロセスやコンテナ間でのネットワークスタックの隔離を可能としてくれます。 ネットワークnamespaceとCNIプラグイン CNIプラグインとは、CNI仕様を満たしコンテナのネットワーク接続性の設定を行う実行ファイル群です。CNIプロジェクトではプラグインの仕様を定義し、プラグインが利用するライブラリを提供することで、一貫していて信頼でき、かつ簡素なプラグイン用のインタフェースを提供してくれます。 コンテナやネットワークnamespaceを指定してプラグインを呼び出す時に、ADDコマンドでコンテナにネットワークインターフェースを追加したり、DELコマンドでそれを落としたりします。例えばリファレンスのBridgeプラグインは、ホストネットワークnamespaceの中にいるブリッジに対してホスト上の全てのコンテナを追加します。 このプラグインのモデルはECS agentの「コンテナのライフサイクルへの最小限の介入」というモデルと相性が良く、agentはコンテナのネットワーク設定の詳細について考慮する必要がなくなります。また拡張性の高いモデルなので、将来必要になった時には、agentが異なるプラグイン群を利用できるようにスイッチさせることもできます。最後に、これらプラグインは必要な時に呼び出されるだけなので、その死活監視をECS agentがする必要はありません。 ECS agentからCNIプラグインを呼び出す ECSがElastic Network Interfaceをインスタンスにアタッチし、agentに対しそのElastic Network Interfaceをタスク内のコンテナに対してプロビジョンするようにメッセージを送った時には、(任意のネットワークデバイスを使う) そのElastic […]

Read More

Amazon ECSコンテナにCloud Native Networkingが登場

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはAmazon ECSのTask Networkingを発表しました。これによって、Elastic Network Interfaceを使ったAmazon EC2のネットワーク機能をタスクに持ち込むことができるようになります。 Elastic Network InterfaceはVPC内のインスタンスにアタッチすることができる仮想的なネットワークインタフェースです。EC2の仮想マシンを起動する時には、インスタンスにネットワークの機能を提供するために自動的に1つのElastic Network Interfaceがプロビジョンされます。 タスクは実行されるコンテナの論理的なグループです。これまでは、Amazon ECSで実行されるタスクはそれが動くEC2ホストのElastic Network Interfaceを共有していました。これからは、新しいawsvpcというネットワークモードを使うことで、Elastic Network Interfaceが直接タスクにアタッチされます。 これによってネットワークの設定を簡略化することができ、VPCが持っているネットワークの全機能、隔離性、そしてセキュリティの制御を各コンテナにEC2インスタンスと同様のレベルで利用することができます。 この記事では、awsvpcモードがどのように動作し、ECSのタスクでどのようにElastic Network Interfaceを使い始めることができるかをご紹介します。 背景: EC2のElastic Network Interface VPC内にEC2インスタンスを起動する時には、各インスタンスが互いに通信できるようにするために、追加のオーバーレイネットワークを設定する必要はありません。標準で、VPCのルーティングテーブルがインスタンスや他のエンドポイント間での通信をシームレスに実現してくれます。これは、Elastic Network Interfaceと呼ばれるVPC内の仮想的なネットワーク・インタフェースによって可能となっています。全ての起動されるEC2インスタンスは自動的に1つのElastic Network Interface(プライマリネットワークインタフェース)がアサインされます。サブネット、セキュリティグループといった全てのネットワークパラメータは、このプライマリネットワークインタフェースの属性として扱われます。 さらに、各Elastic Network Interfaceは作成時にVPCによってIPv4アドレス(プライマリIPv4アドレス)が割当られます。このプライマリアドレスはユニークでVPC内でルーティング可能なものです。これによって、VPCは実際はフラットなネットワークとなり、ネットワークトポロジを簡潔なものとしてくれます。 Elastic Network InterfaceはVPC上で多様なエンドポイントとの接続を実現するための基本的なビルディングブロックとみなすことができ、そのうえでより高レベルな抽象レイヤを構築することができます。これによってElastic Network Interfacdeは以下の機能を利用することが可能となっています: VPCネイティブなIPv4アドレスとルーティング (VPC上でのインスタンス間や他のエンドポイントとの間) ネットワークトラフィックの隔離 ACLとファイアウォールルール(セキュリティグループ)を使ったネットワークポリシーの強制 (サブネットのCIDRを通じた)IPv4アドレスレンジの強制 なぜawsvpcを使うのか? 以前はECSはDockerが提供する標準のネットワークの挙動が提供するネットワーク機能に依存した形でコンテナ向けのネットワークスタックを構成していました。デフォルトのBridgeネットワークモードでは、インスタンス上のコンテナ達はdocker0ブリッジを使って互いにつながっています。インスタンス外のエンドポイントと通信する時には、コンテナはこのブリッジを利用し、それが実行されているインスタンスのプライマリネットワークインタフェースを使います。コンテナは、ファイアウォールルール(セキュリティグループ)やIPアドレスは、そのプライマリElastic Network Interfaceのネットワーク属性を共有しまた依存しています。 これは、Dockerによって割当られたIPアドレス(ローカルスコープのアドレスプールから割当られます)を使ってもこれらのコンテナに到達できないことと、細かいNetwork ACLやファイアウォールルールを強制できないことを意味します。代わりに、VPCからはインスタンスのプライマリElastic Network […]

Read More

Amazon ElastiCache for Redis を使ったChatアプリの開発

Sam Dengler は、アマゾン ウェブ サービスのソリューションアーキテクトです。 このブログ記事では、チャットアプリケーションに関連する概念とアーキテクチャのパターンについて説明します。また、チャットクライアントとサーバーの実装の詳細、サンプルのチャットアプリケーションを AWS アカウントに展開する方法についても説明します。 背景情報 チャットアプリケーションを構築するには、クライアントがチャットルームの他の参加者に再配信されるメッセージを送信できる通信チャネルが必要となります。この通信は、一般に publish-subscribe パターン (PubSub) を使用して実装されます。このパターンでは、メッセージが中央トピックチャネルに送信されます。関係者は、このチャンネルをサブスクライブして更新の通知を受けることができます。このパターンでは、発行者の知識なしに受信者のグループを拡大または縮小できるように、発行者と受信者を切り離しています。 PubSubは、クライアントが WebSockets を使用して通信するバックエンドサーバーに実装されます。WebSockets は、クライアントとサーバー間で双方向にストリーミングされるデータのチャネルを提供する永続的な TCP 接続です。単一サーバアーキテクチャでは、1 つの PubSub アプリケーションが発行者と受信者の状態を管理し、WebSocket を介してクライアントにメッセージを再配布することもできます。次の図は、単一サーバー PubSub アーキテクチャ上の 2 つのクライアント間でメッセージが WebSocket を通過するパスを示しています。 単一サーバーアーキテクチャは、通信フローを説明するのに役立ちます。しかし、ほとんどのソリューションビルダーはマルチサーバーアーキテクチャで設計したいと考えています。マルチサーバーアーキテクチャは、信頼性を高め、伸縮性を高め、クライアントの数が増えるにつれてアプリケーションを水平的に拡大するのに役立ちます。 マルチサーバーアーキテクチャでは、クライアントはサーバープールにトラフィックを転送するロードバランサーに対して WebSocket 接続を行います。これらのサーバーは、WebSocket 接続とそれを経由してストリーミングされるデータを管理します。WebSocket 接続が PubSub アプリケーションサーバーとの間で確立されると、その接続は永続化され、データは両方向のアプリケーションにストリームされます。ロードバランサーは、WebSocket 接続のリクエストを健全なサーバーに配信します。つまり、2 つのクライアントが異なるアプリケーションサーバーに WebSocket 接続を確立できます。   複数のアプリケーションがクライアントの WebSocket 接続を管理するため、アプリケーションはメッセージを再配布するためにそれらの間で通信する必要があります。この通信が必要なのは、メッセージが WebSocket を介して 1 つのアプリケーションサーバーにストリームアップされ、別のアプリケーションサーバーに接続されたクライアントにストリームダウンされる必要があるためです。クライアント接続を管理しているアプリケーションから PubSub ソリューションを外部に出すことで、アプリケーション間の共有通信の要件を満たすことができます。   次の図は、マルチサーバー PubSub […]

Read More

がんの早期発見を促進するために Matrix Analytics が AWS でディープラーニングを使用

Matrix Analytics は人の命を救うために使われています。コロラド州のスタートアップ企業は肺結節と診断された患者の疾患の進行経過を追うために、アマゾン ウェブ サービス (AWS) でディープラーニングを使用しています。大方の場合、結節が良性でも慎重に監査したりフォローアップ治療を行うことは、結節が悪性腫瘍になった場合に重要な意味を持つことになります。 同社の設立者である Dr. Aki Alzubaidi 氏は、Glenwood Springs 病院に勤務していた時に見過ごされている患者が何人もいることに気付きました。患者の様子を把握するためのシステムは面倒な上にまとまりがなく、肺結節と診断された多くの患者が推奨されているフォローアップ治療を受けていないという、避けられるはずの粗末な結果を生み出していました。 がんリスクの予測と治療の管理 同社のフラッグシップアプリケーションである LungDirect は、初期のがん介入に二面性を持つアプローチを使用して悪性の危険性を予測したりフォローアップ治療を自動化しています。 まず、ディープラーニングのアルゴリズムを使用して構築した高度なコンピュータビジョン機能は、肺結節の悪性のリスクを結節の大きさや形、密度、容積、そして患者の喫煙年数、年齢、性別、人種などをもとに診断します。「放射線検査、臨床検査、個人的な臨床レベルでの変化など、臨床的な情報を考慮に入れ、病状について説明し次の対策に関する実用的な提案と管理方法を提供することが、ディープラーニングを利用する我々が目指すゴールです」と Dr. Alzubaidi 氏は述べています。 データに潜んでいるかもしれない非線形性クラスから成るがんリスクの診断を行うために、Machine Learning の 5 つのクラスを適用しています。こうした機能の 4 つのクラスは、一連のコンピュータビジョンアルゴリズムを使用してイメージから直接自動的に抽出されます。 がんの予測や診断を行うために、患者のスキャンを自動的に読み取れるツールを開発することは簡単ではありませんでした。けれども、Matrix Analytics は PoC (実証支援) を示すプロトタイプを素早く開発することができました。次に、当社のディープラーニングモデルを実装して、既存の論文で表示されている基準と比較しました。

Read More

Amazon ElastiCache の更新 – Redis クラスターのオンラインサイズ変更

Amazon ElastiCache では、高速なインメモリ型データストアおよびキャッシュを簡単にセットアップできます。ElastiCache は、最も人気のある 2 種類のオープンソースのソフトウェア (Redis および Memcached) をサポートしているため、要求の高いゲームのリーダーボードやインメモリアナリティクス、大規模なメッセージングのニーズに対応できます。 本日は、Amazon ElastiCache for Redis に追加された重要な機能についてご紹介します。最大 15 のシャードを作成して、それぞれに特定のスロットセットのキーと値を保存することができます (各クラスターの厳密なスロット数は 16,384 個)。1 つのクラスターで 3.55 テラバイトのインメモリデータを保存できると同時に、1 秒あたり 2,000 万回の読み取りと 450 万回の書き込みが可能です。 オンラインのサイズ変更 実行中の Redis 用 Amazon ElastiCache クラスターでシャード数を調整しながら、そのクラスターのオンライン状態を維持してリクエストに応答できるようになりました。これにより、クラスターをオフラインにしたり、空のキャッシュを使用しなくても、トラフィックやデータのボリュームの変更に対応することができます。また、シャード数を変更せずに、実行中のクラスターを再分散してスロットスペースを均一に再配置することもできます。 リシャーディングオペレーションまたは再分散オペレーションを開始すると、Redis 用 ElastiCache は、クラスターのシャード間でスロットが均等分散されるように計画の準備を開始します。その後、シャード全体にスロットを転送し、効率性を重視して並列的に多数のスロットを移動します。これは、クラスターでリクエストに応答する場合に行われ、送信時のスロットへ書き込む書き込みスループットが少し上がります。移行率は、インスタンスタイプ、ネットワーク速度、スロットへの読み込み/書き込みトラフィックによって異なり、通常 1 分あたり約 1 ギガバイトです。 リシャーディングオペレーションと再分散オペレーションは、クラスタモードを有効にして作成された Redis クラスターに適用されます。 クラスターのリシャーディング 一般的に、大幅なメモリプレッシャーの問題に直面したり、個々のノードがボトルネックになった場合は、リシャーディングでクラスターを拡張します。クラスターの CloudWatch メトリクスを監視すれば、以下のような状況を識別できます。 メモリプレッシャー – FreeableMemory、SwapUsage、BytesUsedForCache。 CPU ボトルネック […]

Read More

12 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。プロフェッショナル サービスの宮本です。AWS Black Belt オンラインセミナー12月の配信についてご案内させて頂きます。サービスカットは、10/24 に Generally Available を迎えた Amazon Aurora with PostgreSQL Compatibility をはじめ、今月も様々なテーマを取り扱います。また、ソリューションカットは、「AWSサービスを利用したアプリケーション開発を始めよう」と題して、AWSにおけるアプリケーション開発に活用できる様々なサービスについてご紹介や、AWSにおけるIPv6のサポート状況についてご紹介します。                         12月の開催予定 サービスカット 12/6(水) 18:00-19:00 Amazon Elasticsearch Service 12/14(木) 18:00-19:00 Amazon ElastiCache ※ 通常の開催曜日と異なりますのでご注意ください。 12/20(水) 18:00-19:00 Aurora PostgreSQL ソリューションカット 12/1(金) 12:00-13:00 AWS re:Invent 2017 Report  ※ 通常の開催曜日と異なりますのでご注意ください。 12/5(火) 12:00-13:00 […]

Read More

SSML の新しい声道機能を使用して Amazon Polly の声の音色を変更

本日、Amazon Polly チームは、開発者がテキスト読み上げ (TTS) 音声の音色を変更できるようにする、新しい音声合成マークアップ言語 (SSML) 機能のリリースを発表します。これは、Amazon Polly ポートフォリオの既存の音をカスタマイズし、ユースケース用に探している特定のペルソナの音に近づけることを希望するお客様にとって魅力的な機能です。特に、多くの異なる音が関連するシナリオを持つお客様にとって有益です。音色機能により、利用可能な各 Amazon Polly の声から複数の音のペルソナを簡単にカスタマイズできるためです。 音色とは 音色は、ピッチや大きさとは独立した、音の知覚色または品質を表します。これは、よく音楽で金管楽器と弦楽器の違いを指摘したり、ビオラとバイオリンの微妙な区別を表したりする場合などに使用されます。音色は、各楽器が同じボリュームで同じ音符を演奏していても、それぞれを区別する知覚属性です。音声においても同様に、ピッチ (基本周波数) と大きさ (振幅) が同じでも、音色により 1 つの声が別の声から区別されます。 各個人の声の音は、その人物の生理機能や発声方法を含むさまざまな要素により、独自のものになります。個人の声帯、声道、そして体全体の大きさや形でさえも、その人物の標準的な音声品質を形作るうえで重要な役割を果たします。人の舌の位置、筋肉を緊張または弛緩させる方法、空気圧を加える方法は、声のピッチ、ボリューム、音色を変えるための技法の一部にすぎません。訓練を受けた物まね役者は、自分の声をまるで他人のように変えることができるレベルまで、これらの動きを制御する方法を会得しています。 声道とピッチ 音声の音色に貢献する重要な生理機能として、声道があります。これは声帯上部から唇の端までにおよぶ空気の通り道です。声道を長くしたり短くしたり、または広げたり狭めたりして、その形を変更できるようにするさまざまな筋肉があります。こうした変更の効果によって、音声が増幅または除去されて聞こえます。 ピッチは、音声を高く、または低く聞こえるようにする聴覚属性です。音声生成においては、ピッチは声帯の振動周波数によって決定されます。一般的に、女性の声帯は男性と比較して短く、より多く (1 秒あたり 180~200 回) 振動します。男性の声帯は平均的により長く、より少なく (1 秒あたり 最大 110 回) 振動します。同様に、平均的な声道の長さは、女性が男性よりも短くなっています (最大 14cm 対最大 17cm)。 声帯の長さと声道の長さとの間には自然な相関関係があり、どちらか 1 つが大きければ、もう一方も大きくなる傾向があります。音色機能では、開発者がピッチを制御する機能を維持しながら、声道の大きさを変更することができます。 声道と音声合成 vocal-tract-length SSML タグを使用して話者の声道の長さを変更することで、入力音声の音色を制御できるようになりました。これは話者の体の大きさを変更したかのように聞こえます。 vocal-tract-length を変更すると、話者の音声は体が大きくなったかのように聞こえます。このタグを小さくすると、小さい体のような音になります。このタグは Amazon Polly のテキスト読み上げポートフォリオのいずれの声にも使用できます。 話者の声道の長さを変更する方法は次のとおりです。 +n% または -n%: 現在の声で、相対割合 (%) […]

Read More