AudacityのSoundFinderを複数のファイルに一括適用します。 VADをしたいファイルを複数用意します。 以下のPython3用のスクリプトを実行します。

wavファイルをおいていたディレクトリにwav_list.lofというファイルができているのでAudacityで読み込みます。 Audacityで複数トラックの音声ファイルを時間をずらして読み込めます。 SoundFinderを実行します。この操作でVADを行うことになるので適宜パラメータを調整してください。 VADを行ったラベルデータを書き出します。 以下のPython3用スクリプトを実行します。ラベルのパスとlofファイルのパスは指定してください。

  複数の音声ファイルに一括で発話区間検出のラベルを作ることができました。 音声ファイル名.txtがAudacityで使えるラベルデータとなります。 あとはこれを読み込んでsoxで切り取るなりすれば発話ごとの音声ファイルになります。

前回に引き続き設計プラクティスです。 今回は前々回にLoadBalancerで複数のVMの負荷分散を行ったのに対し、TrafficManagerというものを利用してApp ServiceとVirtualMachine間で負荷分散を行います。 今回の構成はこのようになっています。 WebAppsとVirtualMachineの2つのWebホストへのアクセスをTrafficManagerによって分散します。 TrafficManagerはDNSレベルで動作し、*.trafficmanager.netに来たDNS要求に対し、ルールに基づいて決定したCNAMEを返します。 例えばgariweb1.azurewebsites.netにトラフィックをさばくべきだとTrafficManagerが判断すれば、DNSの名前解決要求が来た時にCNAMEレコードにgariweb1.azurewebsites.netを入れて返信します。 TrafficManagerの分散ルールは公式サイトにあるとおりです。 優先順位: すべてのトラフィックにプライマリ サービス エンドポイントを使用し、プライマリ エンドポイントまたはバックアップ エンドポイントが使用できない場合に備えてバックアップを用意する場合は、”優先順位” を選択します。 重み付け: 一連のエンドポイントに、均等にまたは定義した重みに従ってトラフィックを分散させる場合は、”重み付け” を選択します。 パフォーマンス: 複数のエンドポイントが地理的に異なる場所にあり、エンド ユーザーが、ネットワーク待ち時間が最も短いという意味で “最も近い” エンドポイントを使用できるようにする場合は、”パフォーマンス” を選択します。 地理的: DNS クエリの発信元の地理的な場所に基づいてユーザーを特定のエンドポイント (Azure、外部または入れ子になっている) に割り当てる場合に “地理的” を選択します。 こうすることで、Traffic Manager の利用者は、ユーザーのリージョンを把握し、そのリージョンに基づいてユーザーをルーティングすることが重要なシナリオを実現できます。 データ主権規制、コンテンツおよびユーザー エクスペリエンスのローカライズ、さまざまなリージョンからのトラフィックの測定がその例に挙げられます。 今回は優先順位のルールを用いて負荷分散を行います。 AppServiceを作る 負荷分散されるインスタンスの1つを作ります。 今回はWebAppsにPHPのアプリを作るということとします。 Virtual Machineを作る 続いて負荷分散されるもう片方のインスタンスであるVirtualMachineを作成します。 UbuntuのVirtualMachineを作成します。 LoadBalancerではVirtualMachineのスペックは負荷分散が書いてあるものでないとダメでしたがTrafficManagerでは必要ありません。 今回はA0としました。 仮想ネットワーク、セキュリティグループ等、デフォルトでOKです。 VirtualMachineを作成できたら、紐付いているパブリックIPにDNS名をつけましょう。 パブリックIPの構成から好きなDNS名をつけます。 さらに紐付いているネットワークセキュリティグループの受信ルールからhttpの80番ポートを許可します。 TrafficManagerを作成する 続いて上記の2つのインスタンスの負荷分散を行うTrafficManagerを作成しましょう。 TrafficManagerはAzureで「TrafficManagerプロファイル」と検索すると出てきます。 ルーティング方法は今回は「優先度」とします。 TrafficManagerを作成することができたら、エンドポイントを追加します。 […]

Azure SQL Databaseはgeoレプリケーションをサポートしており管理ポータルから数クリックで冗長構成を実現できます。 レプリケーションとは同じデータを持つデータベース(レプリカ)を2つ以上別のデータセンターなどに配置しておくことによって、データを保証したり可用性を実現するものです。 例えば1つのデータベースに障害が発生したとき、同じデータを持つデータベースが別のサーバーにあれば即座に元のデータを復元できます。 さらに、データベースに障害が発生した時にレプリカのデータベースが障害が発生したデータベースの代わりにマスターDBになることでフェールオーバーを実現します。 geoレプリケーションとは地理的に離れたデータセンター間でデータをレプリケーションすることを指します。 今回はAzure SQL Databaseをつかってgeoレプリケーションを実現してみましょう。 今回の構成はこのようにします。 SQL Databaseは東日本リージョンと米国西部リージョンの2つでレプリケーションすることとし、App Serviceからのトランザクションをさばきます。 上記の構成では東日本リージョンにあるDBのみにデータを書き込むことができ、このようなDBをMaster(Azureの場合はプライマリ)と呼びます。 米国西部にあるリージョンは読み込み専用とし、App Serviceからの読み込みのみのトランザクションを受け付けます。このようなDBをSlave(Azureの場合はセカンダリ)と呼びます。 もし東日本リージョンで障害が発生し、Masterが機能しなくなったとき、SlaveのDBがMasterに昇格し、書き込み可能となることでフェールオーバーを実現します。 WebAppsを作る まず最初に、DBにアクセスするためのWebアプリケーションを作成します。 リージョンは東日本とします。 Master DBを作る 東日本に置くMaster DBを作ります。 リージョンは東日本とし、サーバーも新しく作成してください。 価格レベルは一番安いもので大丈夫です。 Slave DBを作る 続いてレプリカ用のSlave DBを作ります。 先ほど作成したMaster DBの管理画面を開き、「geo レプリケーション」を選択します。 ターゲットリージョンから「米国西部」を選択します。 Slave DBの構成を聞かれますがMasterと同じ性能にしなければいけないのでそのままにします。 サーバーは米国西部に新しく作成します。 Slave DBを作成することができたらレプリケーションは完了です。 プライマリと表示されているのがMasterでセカンダリと表示されているのがSlave DBです。 ASP.net MVCから接続するアプリケーションを作る ではこれらの冗長構成のSQL DatabaseのMaster DBにデータを入れるアプリをASP.netで作ってみます。 ASP.net MVCで新規プロジェクトを作成します。 NugetからEntityFrameworkを追加します。 Web.configを編集し、接続文字列を追加します。 接続文字列は作成したMaster DBの管理画面から取得することができます。 接続文字列の中にはユーザー名とパスワードが埋まっていないので自身のDBServerに設定したユーザー名とパスワードを設定します。 接続文字列の名前は後ほど作成するDbContextと同じものにする必要があります。今回はItemContextとしました。 […]

そういえばMicrosoft Azureを使っているとはいえPaaSの使い方を勉強していることが多く、クラウドらしくないとふと思いたったのでちゃんとクラウドらしいことをやってみようと思って公式ドキュメントを貪ってみたらあまりよい情報が載っていなかったので続くまで練習がてら書いてみようと思います。 対象はAzureにある程度課金できる人を想定しています。   今回の想定は以下のような構成です インターネットからのアクセスをLoadBalancerで受け取り、VirtualNet内にある2つのVMに負荷分散しながらトラフィックをさばきます。 さらに2つのVMはSecurityGroupによって80番ポートが開放されています。 このような同じVirtualMachineを複数台用意し、負荷分散をすることを冗長構成と呼びます。 もし片方のマシンが障害で止まってしまったとしてもLoadBalancerによってもう片方のマシンにトラフィックを集め、ユーザーからのアクセスに的確に応答します。 今回はこのような冗長性のあるUbuntu Virtual Machineを構成し、ApacheでWebサイトを作ってみます。 ネットワークを構築する まず、ロードバランサーへのアクセス先となるパブリックIPを一つ作成します。 このIPへのトラフィックがロードバランサーによって分散されることになります。 続いて2台のVMを包むVirtual Netを作成します。 サブネットのアドレス空間は192.168.0.0/24とします。 セキュリティグループを作成します。 このセキュリティグループはファイアウォールのような役割を果たし、特定のポート以外のアクセスを遮断します。   仮想マシンを作成する 負荷分散するAzure Virtual Machineを2台作成します。 OSはUbuntuとしてください。 この時、サイズは「負荷分散」のオプションが書いてあるものにしてください。Basicプランなどは負荷分散のオプションがありません。 今回は負荷分散がある中で一番安いA0 Standardとしました。 設定ではVirtual Networkとサブネット、ネットワーク・セキュリティグループは必ず先ほど作成したものを指定してください。 パブリックIPアドレスだけは新規作成してください(なぜなら前に作成したパブリックIPはロードバランサーに紐付けるものだからです) 作成時の設定では可用性セットを設定してください。 可用性セットとは複数のAzure Virtual Machineのグループの・ようなもので同一可用性セット内のVirtual MachineはAzureインフラないで分散配置されます。 分散配置されることによって、Azureのハードウエア的な障害や計画メンテナンスなどがおこなわれたとしても対象となっていないVirtualMachineが稼働し続けることができます。 何番のドメインにVMを配置するかは「障害ドメイン」と「更新ドメイン」の数字を切り替えて設定します。 2台目のVirtualMachineを作成します。同様のA0インスタンスでVirtualNetやネットワーク・セキュリティグループは前に作成したものを、パブリックIPアドレスは新規作成。可用性セットは先ほど作成した可用性セットを指定します。 VMを2つ、同一の可用性セット内に作成することができました。 ロードバランサーを作成する 続いてロードバランサーを作成します。 ロードバランサーとはネットワークのトラフィックを複数の機器に分散する負荷分散機です。 Azureには負荷分散装置として以下の3つがあります。 Azure Load Balancer Application Gateway Traffic Manager それらの違いはこちらのページに書いてあります。 その中でもLoad BarancerはOSI参照モデルのトランスポート層で動作し、負荷分散先としてはAzure […]