このポストは、8 月 13 日に投稿した Announcing general availability of Mobile Services .NET supportの翻訳です。

このたび、Mobile Services の .NET バックエンドの一般提供が開始されました。Mobile Services の .NET バックエンドを利用すると、ASP.NET Web API と任意の .NET 言語を使用して独自のサービスを開発することができます。また、クラウド上でホストされているバックエンドをモバイル アプリケーションに追加し、データ ストレージ、認証、柔軟なプッシュ通知などの機能をすばやく活用できるようになります。詳細については、Scott Guthrie のブログ記事 (英語) (翻訳: SATO NAOKI ブログ: Azure: 仮想マシン、機械学習、IoTイベント取り込み、モバイル、SQL、Redis、SDKの改善) と、以下の記事を参照してください。

• ブログ記事: ASP.NET の開発者が Azure Mobile Services に関心を持つべき理由
• ブログ記事: Mobile Services のオフライン同期
• 新しい Mobile Services のドキュメント ページ (英語)

このポストは、8 月 12 日に投稿した Azure Automation: Runbook Input, Output, and Nested Runbooksの翻訳です。

Microsoft Azureの新しい機能である Azure Automationを使用すると、開発者、運用者、および IT 担当者は Runbook の作成と実行が可能となり、Azure のリソース上の複雑な反復作業を自動化できます。Azure Automation は PowerShell ワークフロー エンジンを使用して Runbook を実行します。つまり、Runbook は PowerShell ワークフローとして作成されるということです。詳しくは Runbook の概念 (英語)の記事を参照してください。

Azure Automation Runbook を作成する際には、システムを最大限に活用するためにベスト プラクティスを参考にしたいと思われるでしょう。Runbook を作成するには、PowerShell、PowerShell ワークフロー、および Azure Automation に関する知識が必要です。結局のところ、PowerShell に精通していれば Azure Automation Runbook の作成は造作なく行えます。

このブログ記事では、高品質な Runbook を作成するのに役立つ基本的な概念を説明します。このシリーズの他のブログ記事では、Runbook の作成および管理に関するその他の便利な面について説明します。この記事で取り上げる概念は以下のとおりです。

• 入力パラメーターの定義
• 出力型の定義
• Runbook 内の子 Runbook の呼び出し

入力パラメーターの定義

ほとんどの Runbook は、実行前に渡される入力データを必要とします。そのため、必要となる入力パラメーターは Runbook のオーサリング中に定義するのが一般的です。入力パラメーターを定義する主な属性は次のとおりです。

• 名前
• 型 (.NET の型)
• 必須かどうか
• 既定値 (ある場合)

Azure Automation では、Runbook で使用する入力パラメーターでこれらの属性をサポートしています。PowerShell では、入力規則、エイリアス、パラメーター セットなど、入力パラメーターのより多くの属性がサポートされますが、現在 Azure Automation でサポートしているのは上記の項目のみです。

下記は、Runbook で定義されるパラメーターを表すコードの一部ですパラメーターについての詳細な解説は、スクリプト センターの Automation サブ カテゴリにあるパラメーターを使用した Runbook のサンプル (英語)を参照してください。

workflow Add-User
{
    param (
        [Parameter(Mandatory=$true)]
        [PSCredential] 
        $Credential,

        [Parameter(Mandatory=$true)]
        [object] 
        $FullName,

        [Parameter(Mandatory=$true)]
        [string] 
        $Alias,

        [Parameter(Mandatory=$false)]
        [string]
        $Company="Contoso",

        [Parameter(Mandatory=$false)]
        [boolean]
        $HasAdminRights = $false            
    )
    # システムにユーザーを追加する処理を行う
}

Runbook 内で任意の Runbook をインラインで呼び出したい場合には、入力パラメーターに関する以下の点についてご留意ください。

• 入力パラメーターが単純型または複合オブジェクト ([PSCredential] など) である場合は、単純型の値または複合オブジェクトを、必要に応じて入力値として直接渡せます。
• [object] 型は、PowerShell ハッシュ テーブルとして渡すことができます。名前/値のペアが、オブジェクトのプロパティになります。次の例では、パラメーター “FullName” がハッシュ テーブルとして渡されています。

$name = @{"FirstName"="Joe";"MiddleName"="Bob";"LastName"="Smith"}
    Add-User -FullName $name -Alias "jsmith" -HasAdminRights $true -Credential $cred

Azure Automation Runbook では、パラメーター型 [switch] が便利なときがありますが、通常は [boolean] 型を使用したほうが結果の予測ができます。どちらの型が使用しやすいかとその理由についての詳細は、こちらのブログ記事 (英語)を参照してください。[switch] ではなく [boolean] を使用するのがベスト プラクティスです。その理由は、PowerShell ワークフローで使用する際にそのほうが複雑にならないためです。

PowerShell ワークフローでは、アクティビティまたは他のワークフロー (Runbook) を呼び出す際、パラメーターが位置ではなく名前で参照される必要があります。ワークフローで他の Runbook、アクティビティ、またはコマンドレットを呼び出す際には、念のため常に名前付きパラメーターを使用するとよいでしょう。

ベストプラクティス: Runbook での入力パラメーターは、完全に明示的に宣言することをお勧めします。前述の Add-User の例を参考にして、常にパラメーターの型、名前、および必須であるかどうかを宣言に含めるようにします。パラメーターに既定値を設定している場合は、属性が必須に設定されているかどうかにかかわらず、PowerShell ではオプション パラメーターと見なされる点にご注意ください。必須の属性を省略した場合は、パラメーターは既定でオプションになりますが、この属性は常に明示的に宣言するのが最善の方法です。パラメーターの名前には、英字、数字、アンダースコアを使用します (ハイフンを使用すると特別な扱いが必要となるので、これを避けるためハイフンは使用しないでください)。

Azure Automation のポータルから Start Runbook ウィザードの UI を使用して Runbook を開始できるようにする場合は、入力パラメーターに関して以下の点にご留意ください。

• このウィザードの UI では、数値、文字列、日付/時刻、スイッチ、ブール値、Azure Automation の資格情報アセット名、JSON 配列、または JSON オブジェクトで表わされる値を、Runbook パラメーターに入力できます。
• Runbook のパラメーターに既定値が設定されている場合、この既定値は UI には表示されませんが、ウィザードでこのパラメーターを空欄のままにして Runbook を実行すると、既定値が使用されます (このような挙動については、今後のリリースでの改善を検討中です)。
• Runbook のパラメーターが [array] または [object] 型をとる場合は、これを START Runbook ウィザードで JSON 形式で渡す必要があります。
• プロパティ バッグで入力される [object] 型のパラメーターは、この UI から JSON 文字列の形式で渡すことができます (例: {"StringParam":"Joe","IntParam":42,"BoolParam":true})。
• [array] 型のパラメーターは、JSON 文字列の形式で入力できます (例: ["Joe",42,true])。
• Runbook のパラメーターが PSCredential 型をとる場合は、Azure Automation の資格情報アセットの名前文字列を渡す必要があります。内部的には、その名前を持つ Azure Automation の資格情報アセットが取得され、Runbook に渡されます。

Runbook を PowerShell コンソールまたは Runbook 内から非同期に開始したい場合は、Start-AzureAutomationRunbook コマンドレット (英語)を使用します (このコマンドレットについては、後ほど詳しく説明します)。入力パラメーターについて、次の点にご留意ください (この後のコード例を併せてご覧ください)。

• Start-AzureAutomationRunbook アクティビティによって開始される Runbook の入力パラメーターは、キー/値のペアとしてハッシュ テーブルに渡されます。キーがパラメーター名で、値はそのパラメーターの値です。
• Start-AzureAutomationRunbook により開始される Runbook は、数値、文字列、日付/時刻、スイッチ、ブール値、Azure Automation の資格情報アセット名、JSON 配列、または JSON オブジェクトで表わされる入力パラメーターを持ちます。
• 入力パラメーターが PSCredential 型の場合は、Azure Automation の資格情報アセットの名前文字列を渡す必要があります。内部的には、その名前を持つ資格情報アセットが取得され、Runbook に渡されます。
• 入力パラメーターがスイッチ型の場合、値がブール値 ($true または $false) のハッシュ テーブルでパラメーターを宣言する必要があります。たとえば、HasAdminRights が [switch] パラメーターだった場合は、この後の例のように宣言します。ブール値のパラメーターの場合も、これと同様に宣言します。
• 入力パラメーターがプロパティ バッグの場合、呼び出された Runbook で [object] 型に定義し、PowerShell ハッシュ テーブル オブジェクトを入力値として渡します。例として、以下に示す $name パラメーターをご覧ください。
• 入力パラメーターが複合オブジェクト (例: [System.Diagnostics.Process]) の場合は、呼び出された Runbook で [object] 型に定義し、その複合オブジェクトを入力値として渡します。

    $name = @{"FirstName"="Joe";"MiddleName"="Bob";"LastName"="Smith"}
    $params = @{"Credential"="MyCred";"Alias"="jsmith";"FullName"=$name;"HasAdminRights"=$true}
    $job = Start-AzureAutomationRunbook `
                -Name "Add-User" `
                -Parameters $params `
                -AutomationAccountName $account

複合型を入力パラメーターに割り当てるときに留意すべきことは、Runbook が今後他の Runbook から呼び出されるかどうか、また呼び出される場合は、インライン呼び出しなのかまたは Start-AzureAutomationRunbook を使用して開始されるのかということです。インライン呼び出しのみと考えられる場合は、複合型の入力パラメーターを割り当てることができます。これは、Runbook をインラインで呼び出したときに、その複合型を直接渡すことができるためです。しかし、Runbook が前述の UI を使用して手動で開始される場合、または Start-AzureAutomationRunbook を使用して子 Runbook として開始される場合は、あらゆる複合型の型を [object] に設定する必要があります。これは、Web サービスを介して渡せるのが JSON 配列、または JSON ハッシュ テーブルのみだからです。Runbook の開始方法が明確に決まっていない場合は、複合入力パラメーターの型を [object] に設定するのがベスト プラクティスです。

出力型の定義

PowerShell は、機能およびコマンドレットで OutputType 属性 (英語)を使用した出力型の定義を長い間サポートしてきました。この属性は、実行時には影響を及ぼしませんが、設計時にオブジェクトの型を把握するツールとして提供されてきました。オブジェクトの型は、コマンドレットの実行を必要とせずに出力されます。

OutputType は PowerShell ワークフローで使用できます。出力のある Runbook には OutputType を含めるとよいでしょう。Runbook の最上部付近の、どのパラメーター宣言よりも上に OutputType 属性を配置します。Runbook での OutputType の使用例を次に示します。

workflow Get-UserNames
{
    [OutputType([string])]

    $names = @()
    # ここで名前を取得する処理を行う

    Write-Output $names
}

Azure Automation が進化し、Runbook 作成用のツールセットが拡張、強化されるのに伴い、コマンドレットおよび Runbook に OutputType 定義を含め、コントラクトを忠実に実行することが重要となってきています。

ベスト プラクティス:出力のあるコマンドレットおよび Runbook は、常に OutputType を含むようにします。

Runbook 内の他の Runbook の呼び出し

あらゆる種類のコードを作成する場合に通じるベスト プラクティスの 1 つは、モジュラー化 (分離した、再利用可能なコード単位の作成) です。Azure Automation においては、コマンドレットおよび Runbook 内に自己完結型のタスクを配置し、これらのコマンドレットおよび Runbook を、その機能を必要とする Runbook 内で呼び出すということになります。したがって、親 Runbook で実行中のプロセスの一部として 1 つまたは複数の子 Runbook を呼び出すことは一般的な手法です。

Azure Automation で子 Runbook を呼び出す方法には、次の 2 つがあります。

• インライン呼び出し
• Start-AzureAutomationRunbook コマンドレット (英語)による開始

なお、親 Runbook から呼び出される子 Runbook を表すために「入れ子」または「子」という一般的な言葉を使用しています。PowerShell では、同期的に開始、実行される操作を「呼び出し」という言葉で表します。また、非同期に開始、実行される操作については「開始」という言葉を使用しています。この先例に従い、同期的または非同期的な子 Runbook に対して、「呼び出し」および「開始」という言葉を使い分けます。

Runbook のインライン呼び出し

インラインで呼び出された Runbook は、親 Runbook と同一のジョブ内で動作します。つまり、親ワークフローは、子 Runbook が終了するのを待ってから (同期的に) 次の処理を続けます。また、子 Runbook によってスローされたあらゆる例外、および子 Runbook により生成されたすべてのストリーム出力は、親のジョブと関連付けられます。そのため、子 Runbook の実行と出力の追跡は、すべて親 Runbook に関連づけられたジョブを通して行われます。

インラインで呼び出される子 Runbook を持つ Runbook を開始するとき、その子 (およびすべての子孫の) Runbook は、実行開始前に親 Runbook にコンパイルされます。このコンパイル段階の間、親 Runbook は子 Runbook の名前について構文解析されます。この解析はすべての子孫 Runbook で再帰的に行われます。Runbook の完全なリストが取得されると、これらの Runbook 用のスクリプトは Storage から取得され、PowerShell ワークフロー エンジンに渡される単一のファイルにまとめられます。以上の理由から、Runbook のジョブが送信されるときには、親および子孫の Runbook は既に発行されている必要があります。発行されていない場合はコンパイル中に例外が発生します。現在のところ、発行の順番も重要です。まず子 Runbook を発行してから親を発行する必要があります。同様に、Azure Automation のオーサリング ページで親 Runbook のテストを行うときは、子 Runbook を先に発行してから親のテストを行う必要があります。もう 1 つの重要な点は、インラインで呼び出される子 Runbook の名前を渡すために変数を使用できないということです。つまり、親 Runbook 内では、子 Runbook を常に明示的に指定する必要があります。

次に示すのは、2 つの子 Runbook をインラインで呼び出す Runbook の例です。片方の子 Runbook は出力を返し、他方は出力を返しません。

workflow Process-VMs
{
    param (
        [Parameter(Mandatory=$true)]
        [string]
        $ScaleUnit
    )

    # オブジェクトを返す子 Runbook の呼び出し
    $vms = Get-VMs -scaleunit $ScaleUnit

    # オブジェクトを返さない子 Runbook の呼び出し
    Do-StuffToVMs -vm $vms
}

Start-AzureAutomationRunbook コマンドレットによる Runbook の開始

Start-AzureAutomationRunbook コマンドレット (英語)を使用して、別々のジョブで Runbook を開始できます。このコマンドレットは、Azure PowerShell モジュールの Azure Automation コマンドレット (英語)の 1 つで、Azure Automation にあらかじめインポートされています。Start-AzureAutomationRunbook を使用して子 Runbook を開始すると、この Runbook 用の新しいジョブが作成されます。

この方法で子 Runbook を開始すると、親 Runbook は子 Runbook が完了するのを待たずに (非同期的に) 処理を続けます。この方法は、親 Runbook から処理を分離して、その処理については関知しない場合に便利です。ただし、これはシステムでより多くのジョブを作成するとう代償を伴います。ジョブが多いということは、トラブルシューティングがより複雑になるということです。子 Runbook から出力を戻す必要がある場合には、さらに複雑なことになります。

この後に示すのは、Start-ChildRunbook (英語)という Runbook のコードです。これは、Start-AzureAutomationRunbook を使用して子 Runbook を開始します。また、ジョブが完了するのを待つかどうか、出力を取得するかどうかのオプションが用意されています。この Runbook は、Get-AzureAutomationJob (英語)および Get-AzureAutomationJobOutput (英語)といった他の Azure Automation コマンドレットも使用します。子 Runbook を開始する処理と、何らかの出力を返す処理のすべてをカプセル化しているので、ご利用の Runbook で子 Runbook を開始したい場合に便利に利用していただけます。この便利な Runbook (英語)は、スクリプト センターからダウンロードできます。お客様の Azure Automation アカウントにインポートして、幅広くご活用ください。

workflow Start-ChildRunbook
{
    [OutputType([object])]

    param (
        [Parameter(Mandatory=$true)]
        [string] 
        $ChildRunbookName,

        [Parameter(Mandatory=$false)]
        [hashtable] 
        $ChildRunbookInputParams,

        [Parameter(Mandatory=$true)]
        [string] 
        $AzureConnectionName,

        [Parameter(Mandatory=$true)]
        [string] 
        $AutomationAccountName,

        [Parameter(Mandatory=$false)]
        [boolean] 
        $WaitForJobCompletion = $false,

        [Parameter(Mandatory=$false)]
        [boolean] 
        $ReturnJobOutput = $false,

        [Parameter(Mandatory=$false)]
        [int] 
        $JobPollingIntervalInSeconds = 10,

        [Parameter(Mandatory=$false)]
        [int] 
        $JobPollingTimeoutInSeconds = 600
    )

   # パラメーターの値が適切であるかどうかを判定
   if(!$WaitForJobCompletion -and $ReturnJobOutput) {
       $msg = "The parameters WaitForJobCompletion and ReturnJobOutput must both "
       $msg += "be true if you want job output returned."
       throw ($msg)
   }

    # この Runbook で Azure コマンドレットを呼び出せるように Azure に接続する
    Connect-Azure -AzureConnectionName $AzureConnectionName

    InlineScript {
        # ワークフロー スコープのパラメーターをインライン スクリプト スコープに変換する
        $AutomationAccountName = $using:AutomationAccountName
        $AzureConnectionName = $using:AzureConnectionName
        $ChildRunbookInputParams = $using:ChildRunbookInputParams
        $ChildRunbookName = $using:ChildRunbookName
        $JobPollingIntervalInSeconds = $using:JobPollingIntervalInSeconds
        $JobPollingTimeoutInSeconds = $using:JobPollingTimeoutInSeconds
        $ReturnJobOutput = $using:ReturnJobOutput
        $WaitForJobCompletion = $using:WaitForJobCompletion

        # 処理の対象となる Azure サブスクリプションを指定する
        Select-AzureSubscription -SubscriptionName $AzureConnectionName

        if ($ChildRunbookInputParams -eq $null) { $ChildRunbookInputParams = @{} }

        # 子 Runbook を開始し、ジョブを取得
        $job = Start-AzureAutomationRunbook `
                    -Name $ChildRunbookName `
                    -Parameters $ChildRunbookInputParams `
                    -AutomationAccountName $AutomationAccountName `
                    -ErrorAction "Stop"

        # ジョブが存在するかどうか、ジョブの出力が必要かどうかを判定
        if ($job -eq $null) {
            # ジョブが作成されていない場合は例外をスローする
            throw ("No job was created for runbook: $ChildRunbookName.")
        }
        else {
            # ジョブが存在する

            # 開始された Runbook のジョブ ID を、追跡できるように記録する
            Write-Verbose "Started runbook: $ChildRunbookName. Job Id: $job.Id"

            if ($WaitForJobCompletion -eq $false) {
                # ジョブが完了するのを待たずに、すぐにジョブ ID を返す
                Write-Output $job.Id
            }
            elseif ($WaitForJobCompletion -eq $true) {
                # ジョブが完了するか、タイムアウトの制限に達するまで監視
                $maxDate = (Get-Date).AddSeconds($JobPollingTimeoutInSeconds)

                $doLoop = $true

                while($doLoop) {
                    Start-Sleep -s $JobPollingIntervalInSeconds

                    $job = Get-AzureAutomationJob `
                        -Id $job.Id `
                        -AutomationAccountName $AutomationAccountName

                    $status = $job.Status

                    $noTimeout = ($maxDate -ge (Get-Date))

                    if ($noTimeout -eq $false) {
                        $msg = "The job for runbook $ChildRunbookName did not "
                        $msg += "complete within the timeout limit of "
                        $msg += "$JobPollingTimeoutInSeconds seconds, so polling "
                        $msg += "for job completion was halted. The job will "
                        $msg += "continue running, but no job output will be returned."
                        throw ($msg)
                    }

                    $doLoop = (($status -ne "Completed") `
                              -and ($status -ne "Failed") `
                              -and ($status -ne "Suspended") `
                              -and ($status -ne "Stopped") `
                              -and $noTimeout)
                }

                if ($job.Status -eq "Completed") {
                    if ($ReturnJobOutput) {
                        # ジョブから出力を取得
                        $jobout = Get-AzureAutomationJobOutput `
                            -Id $job.Id `
                            -Stream Output `
                            -AutomationAccountName $AutomationAccountName

                        # Return the output string
                        Write-Output $jobout.Text
                    }
                    else {
                        # Return the job id
                        Write-Output $job.Id
                    }
                }
                else {
                    # The job did not complete successfully, so throw an exception
                    $msg = "The child runbook job did not complete successfully."
                    $msg += "  Job Status: $job.Status.  Runbook: $ChildRunbookName."
                    $msg += "  Job Id: $job.Id.  Job Exception: $job.Exception"
                    throw ($msg)
                }
            }
        }
    }
}

Start-AzureAutomationRunbook を使用して子 Runbook を開始すると、戻り値はジョブ オブジェクトにな���ます。子 Runbook からデータを返したい場合は、ジョブを監視していつジョブが完了したのかを把握したうえで出力を抽出します。上記の Runbook の例でご覧いただけるように、Get-AzureAutomationJob および Get-AzureAutomationJobOutput コマンドレットを使用してジョブを監視して、子 Runbook ジョブから出力を取得します。なお、ジョブが想定した時間内に終了しない場合にループから抜けられるように、タイムアウト要素が含めてあります。また、数個の子ジョブを開始した場合に、システムはジョブが開始される順番を保証しないことにご注意ください。

インラインで呼び出した場合と、Start-AzureAutomationRunbook を使用して開始した場合の子 Runbook の比較

インライン呼び出し

• メリット
• 親および子 Runbook は同じジョブ内で実行されるのでシステム内のジョブ数は比較的少数であり、そのためジョブの追跡が容易です。
• 親 Runbook は子 Runbook が終了するのを待ってから処理を続けます。また、親 Runbook は子 Runbook から返されるあらゆるデータを直接取得できます。
• 子 Runbook からスローされた例外、および子 Runbook により生成されたストリーム出力は、親のジョブに関連付けられます。このため、調査対象となるジョブが 1 つだけなので、トラブルシューティングが容易です。
• Runbook 入力パラメーターは、プリミティブ型から複合型まであらゆる型が使用できます。
• 子 Runbook は親 Runbook と同じジョブで実行されているため、料金を課されるのは 1 つのジョブの実行時間だけです。

• デメリット
• 親 Runbook は子 Runbook の完了を待つ必要があるため、親 Runbook が処理を完了するまでにかかる全体の時間が増加することがあります。
• 親 Runbook 内でインラインの子 Runbook の名前を渡すために、変数またはパラメーターを使用することができません。
• 親 Runbook の発行前に、子 Runbook を発行する必要があります。
• 親子両方の Runbook が、同一の Automation アカウントにある必要があります。

Start-AzureAutomationRunbook による開始

• メリット
• 親と子の Runbook が異なるジョブで実行されるため、親は複数のジョブを分離して並列して実行できます。
• 親 Runbook は子 Runbook を待たないため、子 Runbook の実行中も処理を継続できます。
• 親 Runbook でパラメーターまたは変数を使用して、子 Runbook の名前を渡して呼び出すことができます。
• 同じサブスクリプションの異なる Automation アカウントに格納された Runbook を開始できます。また、Azure サブスクリプションが異なる場合でも、対象の Azure サブスクリプションへの Automation の接続アセットを指定すれば開始できます。

• デメリット
• 親および子の Runbook が異なるジョブで実行され、例外およびストリーム出力が別々に格納されるため、それぞれを追跡する必要があります。このためトラブルシューティングが難しくなる場合があります。
• システムでより多くのジョブが作成されるため、ジョブが開始される前にキューで待機する時間が長くなる可能性があります。
• 子 Runbook ジョブが返すデータの取得が簡単ではありません。
• Start-AzureAutomationRunbook が Runbook を開始し、Runbook が出力の取得を完了するのを待つ場合、両方の Runbook の実行時間に対し課金されます。ただしこれは、[Start] を使用した場合には当てはまりません。
• Start-AzureAutomationRunbook で Runbook を実行すると、すぐにジョブ ID を返します。
• Runbook 入力パラメーターは、プリミティブ型、配列、およびオブジェクトのみ使用できます。これは、Web サービスを介した呼び出しによって、パラメーターがオブジェクトの JSON シリアル化を経る必要があるためです。

まとめ

Azure Automation は便利なツールです。これを使用すると、PowerShell ワークフロー エンジンが備える数多くの有益な機能を活用できる Runbook を作成することができます。Azure Automation および PowerShell ワークフローの内部的な働きをある程度理解し、ベスト プラクティスを学ぶことにより、高品質で信頼性が高く、保守性に優れた Runbook の作成が可能となります。

この記事では、入力パラメーターの定義、Runbook の出力の定義、そして子 Runbook の呼び出しに関するベスト プラクティスについて説明しました。この情報を最後までお読みになったところで、もう少しお時間をいただき、ぜひ Azure Automation のサンプル Runbook をお試しになってください。Runbook および Automation の機能について実感いただけると思います。お読みいただきありがとうございました。今回ご紹介した新しい知識を実践で活用していただくことで、お客様の Azure リソースの管理をよりリンプルに、予測可能に、そして信頼性のあるものにするお手伝いができれば幸いです。

Azure Automation をまだご利用でない方は、プレビュー版にサインアップしお試しください。また入門ガイドをご覧ください。

このポストは、8 月 13 日に投稿した Auditing Media Assets Lifecycle – Part 3の翻訳です。

パート 1とパート 2では、メディア アセットが作成/削除された日時や、メディアを処理する VM にコピーされた日時を記録したアセット監査レポートの作成を中心に取り上げました。このパート 3 では、個々のファイルがアセットに追加された日時を記録してレポートをより充実させる方法について説明します。嬉しいことに、まったくコードを記述せずに達成できます。

Storage のアセット ファイル

アセット ファイルは Storage のアセット コンテナーに BLOB として保存されます。パート 1 で説明したように、アセット コンテナーの名前は “asset-” で始まります。これを利用して、アセットとアセット ファイルのデータを Excel の Power Query を使用して Excel にインポートします。Excel の Power Query を使用したことがない場合は、「Microsoft Power Query for Excel のダウンロード (英語)」から入手できます。インストールして Excel を起動すると、[POWER QUERY] というタブが表示されます。このタブをクリックし、[From Other Sources] ボタンをクリックすると、[From Windows Azure Blob Storage] というメニュー項目が表示されます (下のスクリーンショットを参照)。

このメニュー項目をクリックし、(Media Services アカウントに関連付けられている) ストレージ アカウント名を入力して [OK] をクリックします。次の画面でアカウント キーを入力し [OK] をクリックします。右側に [Navigator] ウィンドウが表示されます (下のスクリーンショットを参照)。

[Navigator] ウィンドウのストレージ アカウント名を右クリックし、[Edit] をクリックします。別のウィンドウが開き、すべてのコンテナーが一覧表示されます (下を参照)。

[Name] 列の横にあるドロップダウン ボタンをクリックして、[Text Filters]、[Begins With...] の順にクリックします (下を参照)。

[begins with] に「asset-」と入力し [OK] をクリックします (下を参照)。

これで、表にアセット コンテナーのみが読み込まれます。[Data] 列の横にあるボタンをクリックし [OK] をクリックすると、コンテナーのすべての BLOB に関するデータが表示されます。[Data.Attributes] 列の横にあるボタンをクリックし [OK] をクリックすると、下のように表示されます。

ここで [Apply & Close] をクリックすると、全データが Excel ワークシートに読み込まれます。ピボット テーブルにデータを読み込むと次のようなビューが生成されます。

これで、アセットのすべてのファイルと、各ファイルの最終更新日時のタイムスタンプを確認できます。

考慮すべき点

次の点に注意してください。

• 上記の方法では、アセット ファイルが削除された日時は取得できない��で、Storage ログから DeleteBlob 操作を検索します。パート 1 で使用したサンプル コードに手を加えて、DeleteBlob 操作を検索し、AssetAuditテーブルにエントリを追加するようにします。
• 多くのアセット ファイルで最終更新日時のタイムスタンプが同じになっている可能性があるので、LastModified タイムスタンプを RowKey としてアセット ファイルのエントリを AssetAuditテーブルに記録する場合は注意してください。

このポストは、8 月 21 日に投稿した New Azure services and updates expand openness, choice and flexibilityの翻訳です。

Microsoft Azure の戦略の中核的なコンセプトの 1 つとして、「開発者が自由に選択したテクノロジを使用してアプリケーションを開発できる柔軟性を備えたオープンなプラットフォームを構築すること」というものがあります。今回、開発者が望む方法で技術革新を実現するというマイクロソフトの取り組みを後押しする新サービスと新機能が発表されました。

Azure DocumentDB のパブリック プレビュー版

今日の開発者は、複数のプラットフォームや複数のバージョン、複数のアプリケーション間のデータ交換をサポートし、ユーザーが生成したデータ、ゲームのデータ、ソーシャル コンテンツを活用する Web およびモバイル アプリケーションを作成したいと考えています。また、これらのアプリケーションによって、拡張性と信頼性の高いパフォーマンスを実現することを望んでいます。これらのニーズに応えるために最適なデータベース テクノロジとして、NoSQL が登場しました。今回プレビュー版がリリースされた Azure DocumentDB は、管理された NoSQL ドキュメント データベースを提供するサービスとしてのデータベース (Database as a Service) で、NoSQL ドキュメント データベースのメリットが得られるだけでなく、リレーショナル データベースのシステムで一般的なクエリ処理やトランザクションのセマンティクスも備えています。

Azure ストアから入手可能な MongoDB、MongoLabs、Nodejitsu、Redis、RavenHQ の既存の NoSQL サービスに Azure DocumentDB が加わることで、NoSQL を使用したシナリオでお客様に提供できる選択肢がさらに拡大されました。

DocumentDB は Azure 管理ポータル (プレビュー)から入手可能です。詳細については、DocumentDB (英語)の Web ページをご覧ください。

Apache HBase™ 対応 Azure HDInsight の一般公開

Apache HBase が HDInsight の機能として一般公開されました。Apache HBase は、Apache Hadoop エコシステムの NoSQL データベース コンポーネントです。この機能により、Web トランザクションやセンサーのデータを Azure BLOB ストレージに書き込み、HDInsight を活用して分析できるようになりました。

詳細については、入門ガイド (英語)をご覧ください。

Azure ギャラリーの VM Depot

今回、コミュニティ主導型の VM Depot イメージの次のステップとして、Azure 管理ポータル (プレビュー) および Azure ギャラリーに VM Depot のオープン ソース イメージが追加されました。ベース オペレーティング システム ディストリビューション (Debian、Ubuntu、CentOS、Suse、FreeBSD など) から、開発者スタック (LAMP、Ruby on Rails、Node、Django など)、完全なアプリケーション (WordPress、Drupal、Apache Solrfor Microsoft Azure など) まで、多岐にわたる約 300 の構成済み Virtual Machines のイメージが紹介されています。これらはすべて、統合された Azure ギャラリーから入手することができます。

Azure Search のプレビュー版

大量のデータを管理するアプリケーションでデータを操作する方法として、検索は一般的な方法になっています。しかし、大規模な検索インフラストラクチャの管理は困難かつ時間がかかり、専門的なスキルや知識を必要とする場合も少なくありません。Azure Search は完全に管理されたサービスとしての検索 (Search as a Service) で、アプリケーションに完全な検索機能を組み込んだり、高精度のランク付けプロファイルにより検索結果をビジネス目標に結び付けたりすることができます。ソーシャル コンテンツまたはユーザーが生成したコンテンツを使用する E コマース向けの Web またはモバイル アプリケーションを作成する場合に、検索インフラストラクチャの複雑なデプロイ、維持、管理に対処する必要はありません。

Azure Search では、Azure 管理ポータルまたは管理 API を使用することで、1 秒あたりのクエリ数やドキュメント数といったキャパシティを負荷の変化に合わせて増減することができます。そのため、検索シナリオにおいて最もコスト効率の良いソリューションを提供することが可能です。

Azure Search は Azure 管理ポータル (プレビュー)から入手可能です。詳細については、Azure Search (英語)の Web ページをご覧ください。

継続的なクラウドの拡大とサービスの革新

お客様の選択肢の拡大は、テクノロジや開発プラットフォームの話だけにとどまりません。購入方法についても、さらなる選択肢が提供されます。今回、新たに 51 か国で Azure の購入およびグローバル展開のデータセンターへのサービスのデプロイの際にクレジット カードをご利用いただけるようになりました。

また今回、Azure WebSites、API Management、Virtual Machines についても魅力的な機能更新が発表されました。これらすべてを含む更新の詳細については、Scott Guthrie のブログ (英語)をご覧ください。

このポストは、8 月 13 日に投稿した Migrate On-Premise Virtualized Workloads to Azure using Azure Site Recoveryの翻訳です。

先日、マイクロソフトのサービスとしての障害復旧 (Disaster Recovery as a Service) ソリューション (英語)である Azure Site Recovery のプレビュー版を発表しました。このサービスは企業のプライベート クラウドや Microsoft Azure に、自動保護、非同期複製、仮想ワークロードの順序立てた復旧の機能を提供します。障害復旧のダウンタイムは最小限に抑えられ、データの正確さと一貫性が保証されます。

このサービスは、シンプルで堅牢性が高い点が好評です。大規模な構成、目標復旧時点 (RPO) の細かさ (30 秒から設定可能)、クラス最高レベルのセキュリティと暗号化、セルフサービス型の障害復旧、復旧計画を活用したワンクリックでの障害復旧などの主要機能があります。

Azure Site Recovery は、IT インフラストラクチャの設備投資を抑え運用コストを最適化した、低コストで高機能な障害復旧戦略を実現します。しかも、簡単な操作で追加の開発/テスト環境を個別に展開したり、オンプレミスの仮想マシンを Microsoft Azure に移行したりすることができます。

オープンで多様かつ柔軟なクラウド プラットフォームである Microsoft Azure は、IT 戦略の一環としてクラウドを導入しようとしている企業にとって理想的です。Windows や Linux をはじめとする任意のオペレーティング システムで、SQL Server、Oracle、.NET、Java、PHP、Python、Ruby、Node.js、Hadoop などのさまざまなフレームワークと言語を使用してアプリケーションを開発できます。

オンプレミスの既存の仮想ワークロードを Azure に移行するソリューションを検討する場合は、次の 3 つの条件を考慮する必要があります。

移行中の運用ワークロードによるダウンタイムの削減

• 運用環境の仮想マシンの移行によるビジネスへの影響を最小限に抑える
• 移行開始後の目標復旧時間 (RTO) を最小限に抑える。実際の移行処理を開始する前に、運用環境のレプリケーションとプロビジョニングを完了しておく

ダウンタイム ゼロの移行を実行する前に Azure 内のアプリケーションを検証

• Azure への移行を実行する前に、ネットワーキングとパフォーマンスの要件に注目して、すべてのアプリケーションを検証する
• 検証作業は運用環境と切り離して行う。移行によって運用環境にダウンタイムが発生したり、悪影響が及んだりすることがあってはならない

シンプルなソリューション

• 使いやすく、移行作業を容易にするソリューションであること。移行の完了後も変更が可能であること

Azure Site Recovery とその組み込み機能は、上記の基準をすべて満たす統合ソリューションです。このサービスを利用することにより、簡単な操作ですばやく確実に Azure への移行を実現することができます。オンプレミスの仮想アプリケーションを Azure へ移行する手順は次のとおりです。

テスト フェールオーバー (DR ドリル) とネットワークマッピングにより、実稼働ワークロードに影響を及ぼすことなくアプリケーションとネットワーク構成をテストすることが可能です。テスト フェールオーバーでは、開発/テスト環境をオンデマンドで拡張できるだけでなく、アプリケーションを最終的に Azure に移行する前に、その機能とパフォーマンスを検証することができます。

復旧計画は、多層アプリケーションの複数の仮想マシンをグループ化し、1 つの統合フェールオーバー ユニットにまとめます。このため、簡単なクリック操作で Azure へ移行できるだけでなく、目標復旧時間 (RTO) も短縮されます。復旧計画は、計画されたフェールオーバーもサポートするので、Azure にフェールオーバーする前にオンプレミスのワークロードを正常にシャットダウンすることができます。その時点で仮想マシンの保護を無効化し、Microsoft Azure で実行することができます。ステップごとの詳しい手順については、Azure Site Recovery に関するドキュメント (英語)を参照してください。

Azure Site Recovery は Microsoft Azure ポータルから利用可能です。プライベート クラウド、パートナー クラウド、パブリック クラウドで一貫したシンプルなユーザー エクスペリエンスが提供されます。また、簡単な操作で Azure への移行を実現できます。

Azure Site Recovery の詳細については、プレビュー版発表時の TechEd 2014 のセッション動画 (英語)をご覧ください。他のユーザーと情報を共有したい場合は、MSDN の Azure Site Recovery フォーラム (英語)をご活用ください。

��入の準備ができましたら、詳しい製品情報をご確認のうえ、Azure の無料評価版にサインアップしてください。これで、Azure Site Recovery を使用して Microsoft Azure に仮想ワークロードを移行することができます。

Azure Site Recovery は、Windows Server 2012 R2 で既に仮想化を行っているお客様が Azure への仮想マシンの移行や障害復旧を行う場合の理想的な選択肢です。任意のクラウドで実行中の物理ワークロードまたは Windows Server 2012 R2 以前の仮想ワークロードを Microsoft Azure に移行する必要があるお客様には、InMage の新しいテクノロジを利用した移行サービスをまもなく提供開始する予定です。

このポストは、8 月 14 日に投稿した Introduction to Azure Backupの翻訳です。

Azure Backupは Azure の復旧サービスの一部です。“セキュアで効率的な” 設定により、Azure でデータを “シンプルかつ信頼性の高い” 方法で管理および保護できます。Azure Backup を使用すると、必要なストレージをいくらでも調達し、コスト効率よくデータを長期保存できるため、オフサイトのテープ バックアップの代替策として最適です。Azure Backup はマイクロソフトの既存のデータ保護ツールと緊密に統合することができ、広範なマイクロソフト製品に対し、ワークロードの保護機能を提供します。

シンプル

Azure Backup はすぐに使い始められるだけでなく、使用方法もシンプルです。通常、小規模な企業であれば、Azure Backup のみでファイルとフォルダーをバックアップするか、Windows Server バックアップを併用します。中～大規模の企業では、Azure Backup のシンプルさと System Center Data Protection Managerの強力な機能セットを組み合わせて活用し、SQL Server、Hyper-V VM、SharePoint、Exchange など、各種マイクロソフト製品のワークロードをバックアップおよび復元できるようになります。保護フローの自動化は、PowerShell コマンドレットを通じて管理できます。

セキュア

Azure Backup は転送中と保管中の両方のデータを暗号化することにより、卓越したセキュリティ機能を提供し、お客様の社内環境の外に出るすべての企業データを確実に暗号化します。暗号化キーは、常にお客様自身で管理できます。マイクロソフトはプロバイダーとしてオンライン バックアップ サービスを提供し、暗号化キーには関知しません。

信頼性

Azure Backup では、地理レプリケーションを通じ、地理的に離れた場所に自動的に冗長コピーを作成して管理することで信頼性を確保します。99.9% のサービスの可用性が SLA (英語)に基づいて保証されます。

効率性

Azure Backup は Azure への増分バックアップを実行することにより、帯域幅とストレージの効率的な利用を実現します。また、データ圧縮と帯域幅調整の機能を使用し、さらに最適化を促進できます。

優れたコスト効率

初期導入時のソフトウェアとハードウェアに対する設備投資、および継続的な管理に伴う時間とコストが抑えられるだけでなく、Azure Backup では従量課金制モデルにより、使用したストレージ容量 (GB 単位) に応じて使用量が課金されます。

サポート範囲の広さ

Azure Backup は、Windows Server 2008 R2 以上の SKU でサポートされます。Azure 管理ポータルは 11 か国語、89 か国で利用でき、米国、欧州、および南アジアの 8 か所のデータ センターからサービスを提供します。

利用の開始方法

Azure Backup は、Azure のサブスクリプションを開始し、Azure 管理ポータルの復旧サービスでバックアップ用コンテナーをプロビジョニングすれば使い始めることができます。説明用のショート ビデオ (英語)を用意しましたのでご利用ください。Microsoft Azure Backupの詳しい使用方法については、MSDN を参照するほか、よく寄せられる質問とサポートのページでも追加情報をご覧いただけます。

フィードバック

ユーザー フォーラム (英語)で、お客様からのフィードバックや質問をお待ちしています。Microsoft Azure Backup フォーラム (英語)でも、さまざまな質問を投稿できます。

このポストは、8 月 14 日に投稿した New: Configurable Idle Timeout for Azure Load Balancerの翻訳です。

このたび Azure Load Balancerで、Cloud Services と Virtual Machines の TCP アイドル タイムアウトの構成を変更できるようになりました。この構成は、Service Management API、PowerShell、またはサービス モデルを使用して行えます。

概要

Azure Load Balancer の既定では、アイドル タイムアウトが 4 分に設定されています。

つまり、確立した TCP セッションまたは HTTP セッションを一定時間操作せず、タイムアウトの設定値を超えた場合、クライアントとサービス間の接続の維持は保証されません。

接続が解除されると、「基になる接続が閉じられました: 維持される必要があった接続が、サーバーによって切断されました」というエラー メッセージが、クライアント アプリケーションに表示されます。

接続をアクティブに維持する時間を延ばすには、TCP キープアライブ (英語)を使用するのが一般的です。.NET の例をこちら (機械翻訳)からご覧いただけます。この手法では、接続のアクティビティがなくなったことを検知すると、パケットが送信されます。こうして継続的なネットワーク アクティビティを維持することで、アイドル タイムアウトを回避して接続を長時間維持します。

TCP キープアライブはバッテリの制約がないシナリオでは有効ですが、通常、モバイル アプリケーションには適しません。モバイル アプリケーションから TCP キープアライブを使用すると、デバイスのバッテリの消耗を速める可能性が高くなります。

こうしたシナリオをサポートするために追加されたのが、構成可能なアイドル タイムアウトです。これにより、タイムアウトを 4 ～ 30 分に設定できるようになりました。この設定は、受信側の接続のみに適用されます。

シナリオ

Virtual Machines上のエンドポイントに、PowerShell または Service Management API 経由で TCP タイムアウトを構成

負荷分散されたエンドポイント セットに、PowerShell または Service Management API 経由で TCP タイムアウトを構成

インスタンスレベルのパブリック IPに TCP タイムアウトを構成

Web/Worker ロールにサービス モデル経由で TCP タイムアウトを構成

PowerShell の例

必ず最新の Azure PowerShell (英語)をダウンロードしてインストールしてください。

インスタンスレベルのパブリック IPの TCP タイムアウトを 15 分に構成する

Set-AzurePublicIP –PublicIPName webip –VM MyVM -IdleTimeoutInMinutes 15

IdleTimeoutInMinutes はオプションです。設定しない場合、既定のタイムアウトは 4 分になります。この値は、4 ～ 30 分の間で設定できるようになりました。

Virtual Machines 上で Azure エンドポイントを作成する際にアイドル タイムアウトを設定する

Get-AzureVM -ServiceName "mySvc" -Name "MyVM1" | Add-AzureEndpoint -Name "HttpIn" -Protocol "tcp" -PublicPort 80 -LocalPort 8080 -IdleTimeoutInMinutes 15| Update-AzureVM

アイドル タイムアウトの構成を取得する

PS C:\> Get-AzureVM –ServiceName “MyService” –Name “MyVM” | Get-AzureEndpoint

VERBOSE: 6:43:50 PM - Completed Operation: Get Deployment

LBSetName : MyLoadBalancedSet

LocalPort : 80

Name : HTTP

Port : 80

Protocol : tcp

Vip : 65.52.xxx.xxx

ProbePath :

ProbePort : 80

ProbeProtocol : tcp

ProbeIntervalInSeconds : 15

ProbeTimeoutInSeconds : 31

EnableDirectServerReturn : False

Acl : {}

InternalLoadBalancerName :

IdleTimeoutInMinutes : 15

負荷分散されたエンドポイント セットに TCP タイムアウトを設定する

負荷分散されたエンドポイント セット内のエンドポイントの場合は、負荷分散されたエンドポイント セットに対して TCP タイムアウトを設定する必要があります。

Set-AzureLoadBalancedEndpoint -ServiceName "MyService" -LBSetName "LBSet1" -Protocol tcp -LocalPort 80 -ProbeProtocolTCP -ProbePort 8080 -IdleTimeoutInMinutes 15

Cloud Services の例

Azure SDK for .NET 2.4を利用すると、使用中の Cloud Services を更新できます。

Cloud Services のエンドポイント設定は、.csdef ファイルで定義します。そのため、Cloud Services 環境の TCP タイムアウトを更新するには、デプロイメントの更新が必要になります。ただし、パブリック IPに対する TCP タイムアウトのみを指定する場合は除きます。パブリック IP の設定は .cscfg ファイルで定義され、デプロイメントの更新およびアップグレードによって更新できます。

エンドポイント設定に関しては、.csdef を次のように変更します。

<WorkerRole name="worker-role-name" vmsize="worker-role-size" enableNativeCodeExecution="[true|false]">
  <Endpoints>
    <InputEndpoint name="input-endpoint-name" protocol="[http|https|tcp|udp]" localPort="local-port-number" port="port-number" certificate="certificate-name" loadBalancerProbe="load-balancer-probe-name" idleTimeoutInMinutes="tcp-timeout" />
  </Endpoints>
</WorkerRole> <!-- パブリック IP のタイムアウト設定については、.cscfg を次のように変更します。 -->

<NetworkConfiguration>
  <VirtualNetworkSite name="VNet"/>
  <AddressAssignments>
    <InstanceAddress roleName="VMRolePersisted">
      <PublicIPs>
        <PublicIP name="public-ip-name" idleTimeoutInMinutes="timeout-in-minutes"/>
      </PublicIPs>
    </InstanceAddress>
  </AddressAssignments>
</NetworkConfiguration>

API の例

TCP アイドル タイムアウトの構成は、Service Management APIからも行えます。

必ず x-ms-version ヘッダーを追加し、バージョンを 2014-06-01 以降に設定してください。

デプロイメント内の全 Virtual Machines 上で、特定の負荷分散された入力エンドポイントの構成を更新する

要求

POST https://management.core.windows.net/<subscription-id>/services/hostedservices/<cloudservice-name>/deployments/<deployment-name>

応答

<LoadBalancedEndpointList xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

<InputEndpoint>

<LoadBalancedEndpointSetName>endpoint-set-name</LoadBalancedEndpointSetName>

<LocalPort>local-port-number</LocalPort>

<Port>external-port-number</Port>

<LoadBalancerProbe>

<Path>path-of-probe</Path>

<Port>port-assigned-to-probe</Port>

<Protocol>probe-protocol</Protocol>

<IntervalInSeconds>interval-of-probe</IntervalInSeconds>

<TimeoutInSeconds>timeout-for-probe</TimeoutInSeconds>

</LoadBalancerProbe>

<LoadBalancerName>name-of-internal-loadbalancer</LoadBalancerName>

<Protocol>endpoint-protocol</Protocol>

<IdleTimeoutInMinutes>15</IdleTimeoutInMinutes>

<EnableDirectServerReturn>enable-direct-server-return</EnableDirectServerReturn>

<EndpointACL>

<Rules>

<Rule>

<Order>priority-of-the-rule</Order>

<Action>permit-rule</Action>

<RemoteSubnet>subnet-of-the-rule</RemoteSubnet>

<Description>description-of-the-rule</Description>

</Rule>

</Rules>

</EndpointACL>

</InputEndpoint>

</LoadBalancedEndpointList>

このポストは、8 月 18 日に投稿した Enabling Command-line or Continuous Delivery of Azure WebJobsの翻訳です。

Visual Studio 2013 Update 3でリリースされた WebJob 発行ツールの開発にあたって、マイクロソフトでは、Azure API および Management Libraries の機能強化に対応できるように設計を行いました。これにより、WebJob ツールに対する更新プログラムは迅速にリリースが可能です。また、開発者の皆様が継続的インテグレーションのビルドにおいて使い慣れている発行機能の使用を求めていることを理解していましたし、WebJob を発行する新しいツールによって、既存のツールと発行の自動化シナリオで対応できなかったことが実現できるだろうと考えました。そしてこのたび、コマンド ラインを使用した WebJob の発行シナリオと継続的インテグレーションのシナリオに改善の余地を見つけたため、これらの不足を解消する更新プログラムを用意しました。今回の記事では、この更新プログラムと、Visual Studio の正式な更新プログラムの発表直後にマイクロソフトがこの更新プログラムをリリースできたしくみ、Azure WebJob の継続的インテグレーションまたはコマンド ライン発行を実行してそのメリットを活用する方法について概要をご説明します。

NuGet による迅速なツール更新プログラムの実現

最大限の柔軟性を提供するために、WebJob の発行ロジックを実際に実行するコードの大部分を含む WebJobs Publish NuGet パッケージ (英語)が公開されています。以下の図は、WebJob ツールによる発行チェーンのアーキテクチャの概要を示しています。

Scheduler のジョブ コレクションや WebSites といった Azure リソースをセットアップするため、また API を効果的に使用してそれらのコンポーネントを NuGet パッケージに統合するために必要となる API 呼び出しをカプセル化することで、より広範な Visual Studio の更新プログラムを必要とすることなく、API の機能強化、修正プログラム、リファクタリングなどを実行することができます。上記の図は、NuGet を利用して基本的なツールのワークフローに更新プログラムをリリースすることのメリットも示しています。Visual Studio とコマンド ラインによる両方のプロセスで NuGet 更新プログラムのメリットを得ることが可能です。これらの機能強化は NuGet を通じて有効化されるため、コマンド ラインから WebJob を発行するための最初の手順として、まずは WebJobs Publish NuGet パッケージをバージョン 1.0.1 に更新する必要があります。以下の NuGet パッケージの更新ダイアログのスクリーンショットでは、Visual Studio 2013 からこの更新を実行しています。

コマンド ライン発行のメリット

この記事では、Microsoft WebJobs Publish 1.0.1 NuGet パッケージ (英語)のコマンド ライン関連の機能強化と、Azure WebJob のコマンド ライン配信または継続的デリバリを実行する方法を中心にご説明します。これは、おそらく WebJob 所有者の大半が抱える主要な要件であるため、包括的な Visual Studio 3 Update に含めることを検討しましたが、数点の機能強化を追加する必要がありました。そこで、Azure WebJob 所有者が反復的な WebJob の発行シナリオを設定するうえで複数の選択肢を提供できるように、可能な限り多くの認証シナリオをテストして実現させました。

非対話式操作による Azure 認証を実行する

上記の図を見ると、WebJob ツールが Microsoft Azure Management Libraries (MAML、英語)を基盤として構築されていることがわかります。MAML では、Active Directory トークンと管理証明書という、主に 2 種類の方法で Azure への認証を実行することができるため、WebJob ツールでもこの両方の認証方法を使用できます。Visual Studio には、Active Directory トークンにダイヤルインするための優れた方法が提供されており、WebJob を手動で発行する際にはこの認証方法が既定として使用されます。しかし、Visual Studio からの発行とコマンド ラインからの発行を比較した場合、以下の認証ウィンドウは Visual Studio あるいはその他のクライアントから手動で認証する場合にのみ有用です。

ビルド サーバーなど、機械やサービスによって実行されるコマンド ライン環境では、ログイン ダイアログを利用する方法は適切ではありません。継続的インテグレーションのビルド中に Azure へのビルド サーバーの認証方法が利用できなければ、WebJob 発行の自動化を実現することはできません。おもしろいことに、WebJob 発行の自動化シナリオを実現する最適なソリューションは私たちの目の前にありました。私たち自身のテスト環境で使用されているテクニックを流用したのです。当たり前のことながら、WebJob ツールを自動化する方法を考え出すためには、マイクロソフト自身の自動化シナリオのテスト方法を参考にするのが最善の策でした。ところが、あまりにも数多くのテストを実行していたため、コマンド ラインを使用したシナリオのテストを独立したものとして詳細に注目することがなかったのです。そこで、Visual Studio の更新プログラムが完成した後、コマンド ラインを使用したシナリオの完全なテストと改善に着手しました。

WebJob の発行プロセスを管理証明書による認証に変更する

Azure API への認証には、Active Directory トークンを使用する代わりに管理証明書を使用することもできます。私たち自身のツールのテストでは、ビルド サーバーの認証に管理証明書を使用していたため、お客様も MSBuild プロセスで管理証明書を使用できるようにしました。その結果、継続的インテグレーション環境で作成されたプロジェクトで Azure に WebJob を発行し、関連する Scheduler のジョブを適切に作成して関連付けることができるようになりました。WebJobs Publish NuGet パッケージ バージョン 1.0.1 (上記参照) のインストール後、発行する Web アプリケーション プロジェクトまたはコンソール アプリケーションのプロパティ フォルダーに webjobs.propsという名前のファイルを追加します。

このファイルでは、3 種類の方法で管理証明書を使用した WebJob の発行プロセスの認証を行うことができます。

新規の Azure 発行設定ファイルを取得する

管理証明書を使用した Azure への認証で最も簡単なのは、Azure 発行設定ファイルに格納された情報を使用する方法です。Azure 発行設定ファイルを取得するには、Azure PowerShell コマンドレットをインストールし、Get-AzurePublishSettingsFileコマンドを実行するのが簡単です。この操作で、Azure 発行設定のダウンロード用 URLが表示されます。

webjobs.props ファイルを編集する

1 つ目の方法は、Base64 でエンコードされた管理証明書の文字列の値を手動で入力することです。管理証明書のエンコード済みの形式は、*.publishsettings ファイルから webjobs.props ファイルに直接コピーすることができます。証明書の値と Azure サブスクリプション ID が存在することで、WebJob の発行プロセスで、(有効期限切れまたは存在しない可能性のある) AAD トークンを使用した既定の認証の代わりに、管理証明書を使用した認証が行われます。

WebJob の発行プロセスで認証情報を使用する 2 つ目の方法は、webjobs.props ファイルで *.publishsettings ファイル自体を使用することです。これにより、Azure API への認証に使用できる認証情報を含む発行設定ファイルが MSBuild に対して指定されます。注: 以下のスクリーンショットでは、2 つの認証方法を示しています。実行する場合は、両方ではなく、いずれか一方を使用してください。

3 つ目の方法は、発行プロセスに対して、以前に Azure にアップロードした CER ファイルと対になる PFX ファイルを指定することです。PFX ファイルをビルド サーバーのユーザーが使用できるように設定するか、webjobs.props ファイルに証明書のパスワードを直接入力します。

webjobs.props ファイルにいずれかの認証方法を記述したら、ビルドをコマンド ラインから実行することができます。

コマンド ラインから WebJob を発行する

お客様の環境を反映するように webjobs.props ファイルを設定したら、コマンド ラインから以下のような MSBuild スクリプトを実行して、WebJob と共にアプリケーションを作成してデプロイすることができます。発行プロセスにスケジュールが設定された WebJob が含まれる場合、WebJob のスケジュールを設定する Azure Scheduler のジョブも作成されます。以下のコードをコピーして Visual Studio 2013 の開発者コマンド プロンプトの実行中のインスタンスに貼り付けると、ビルドを実行して発行することができます。

msbuild WebJobDemo.Web.csproj /p:DeployOnBuild=true /p:PublishProfile=WebJobDemo /p:VisualStudioVersion=12.0 /p:Password=asdfasdf

ビルドが完了すると、Web の発行が完了したこと、また WebJob のスケジュールを設定する Scheduler のジョブ コレクションおよびジョブが��成されたことを示すログが MSBuild によって出力されます。

矢印の箇所は、スケジュールが設定された WebJob を作成するエンドツーエンドのプロセスの主要なステップを示しています。

まとめとロードマップ

コマンド ラインを使用したシナリオを実行するために必要な唯一のツールである WebJobs Publish NuGet パッケージ 1.0.1 (英語)の更新プログラムがリリースされました。今すぐパッケージをアップデートしてご活用ください。今後も Azure API の機能が強化されたり、マイクロソフトのミドルウェアおよびコマンド ラインを使用したシナリオで Azure Management Libraries などのリソースが共有されたりすることで、反復的な発行の自動化を活用できる機会がさらに増加するでしょう。マイクロソフトでは、認証されていない AAD 認証の提供や、新しいリソース管理 API のサポートなど、その他の機能強化についても検討中です。これらの機能強化が提供されるたびに、Azureや Web 開発とツール (英語)に関するブログのコミュニティを更新してお知らせする予定ですので、引き続きご注目ください。またご意見、ご感想がありましたら、ぜひお知らせください。

このポストは、8 月 26 日に投稿した New Azure SQL Database service tiers generally available in September with reduced pricing and enhanced SLAの翻訳です。

先日の発表 (英語)に引き続き、今回、Azure のデータ サービスに関する新たな発表が行われました。これは、広範なデータ プラットフォームの一環として、Azure 上で連携の取れた豊富なデータ サービスを提供するマイクロソフトの取り組みを表すものと言えます。9 月より、サービスとしてのデータベース (Database as a Service) を提供する Azure SQL Databaseのサービス レベルが新しくなります。これにより、クラウド アプリケーションのコスト パフォーマンスとビジネ��継続性をさらに向上させることが可能になります。マイクロソフトは、プレビュー期間を通してお客様からのご意見に積極的に耳を傾け、一般提供に向けて改善を重ねました。そして、皆様のご要望にお応えすべく、従来よりも価格を抑えたサービス レベルを実現すると共に、新しいパフォーマンス レベルと時間単位での課金制度を導入します。さらに、99.99% の稼働率を保証する、より高度なサービス レベル アグリーメント (SLA) が採用されることになりました。

Azure SQL Database の新しいサービスレベル

4 月の発表では、Basic、Standard、Premium の各サービス レベルの導入についてお知らせしました。これらのサービス レベルは、一定のリソース群を提供することで、低い負荷はもちろん高い負荷のトランザクション アプリケーションにも対応する予測可能なパフォーマンスを実現し、また、アプリケーションのパフォーマンスが他のお客様のアプリケーションやワークロードの影響を受けることがないようになっています。今回の新しいサービス レベルでも、幅広いビジネス継続性機能と最大 500 GB という大容量のデータベース サイズが提供されます。また 4 月以来、機能の追加やアップグレードの簡易化、最大 5 倍のパフォーマンスの向上といった改善を継続的に行ってきましたが、今回はさらに、皆様からのフィードバックを基に新たな変更が行われています。これらの変更について、以下にご説明します。

• Premium および Standard レベルの料金の値下げ:最終価格として、以前発表された料金に比べて最大 50% の値下げを行います。この料金改定によって、より多くのお客様がパフォーマンスとビジネス継続性の向上を実現できるようになります。
• 新しいパフォーマンスレベル「S0」の導入: Standard サービス レベルで、新たに S0 というパフォーマンス レベルが提供されることになりました。低価格でエントリ向けのこの新しいレベルを導入することで、より多くのお客様に Standard サービス レベルの機能を活用していただけるようになります。パフォーマンス レベルとは、スループットの特定のレベルを指すもので、パフォーマンスのニーズに応じて高い値にも低い値にも簡単に調整できます。
• 時間単位の課金制度: Azure SQL Database の新しいサービス レベルでは、時間単位での課金制が適用されるようになります。これにより、サービス レベルやパフォーマンス レベルを需要パターンに応じて柔軟に変更できるようになり、コスト効率と信頼性の高いパフォーマンスが得られます。

ビジネス運用に欠かせないワークロードが続々とクラウドに移行される中で、マイクロソフトは高可用性の重要性を強く認識しています。こうしたことから、Azure SQL Database の新しいサービス レベルでは、99.99% の稼働率を保証する、より高度な SLAを提供することになりました。

さらに、プレビュー期間中、数多くのデータベースと多様なパフォーマンス ニーズを抱える複数の ISV のお客様から、データベースのリソースを個別に管理するのではなく、データベース間でパフォーマンスのためのリソースを柔軟に共有できるようにしたいとのご意見を頂戴しました。たとえば、顧客ごとに個別の SQL Database を管理している一部の SaaS ISV のお客様は、データベースごとにアクティビティが異なるため、こうした複数の顧客データベース全体で特定の予算に基づいてリソース プールを管理できるようにしたいと考えていらっしゃいます。私たちは、今後のサービス更新の際に新たなサービス レベルによってこうしたシナリオにも対処できるようにしていきたいと考えています。同じような状況に置かれている ISV のお客様は、こちらのページ (英語)で登録を行い、詳しい情報をご確認ください。

次に、サービス レベルの概要と改定後の料金についてご説明します。

• Basic: ワークロードの低いトランザクション アプリケーション向けに設計されています。
• Standard:クラウド向けに設計されたビジネス アプリケーションの利用を開始するユーザーを対象とした、Microsoft Azure SQL Database の中心となるサービスです。Premium レベルと Basic レベルの中間のパフォーマンスとビジネス継続性機能を提供します。
• Premium:ミッション クリティカルなデータベース向けに設計されています。Premium レベルでは、最高レベルのパフォーマンスが提供されるほか、高度なビジネス継続性機能を利用できます。

*99.99% の稼働率を保証する SLA は、SQL Database の Web Edition または Business Edition には適用されません (これらのエディションには、99.9% が適用されます)。

**CPU、メモリ、および読み取り/書き込みレートを合わせた指標です。詳細については、こちらのページをご覧ください。

新しいサービス レベルは来月 (2014 年 9 月) より一般提供される予定であり、改定後の料金は 2014 年 11 月 1 日よりすべてのお客様に適用されます。現行のサービス レベルから移行されるお客様のために、現行の Web Edition および Business Edition の終了は 2015 年 9 月まで (新しいサービス レベルの一般提供開始より 1 年後まで) 延長されます。なお、Web Edition および Business Edition の終了に先立って、複数のデータベースにわたって DTU の割り当てをプールできる ISV 向けの新しいサービス レベルが提供される予定です。これをご利用いただくことで、ISV のお客様はスムーズな移行が可能になります。

Microsoft Azure のデータサービス

Azure のデータ サービスでは、あらゆる種類のデータをシームレスに処理、管理、接続するための優れた方法をお選びいただけます。また、こうした各種サービスの更新を通じて、お客様がパフォーマンスのニーズを達成し、クラウドのコスト面でのメリットを活用できるようお手伝いします。Azure Virtual Machines で SQL Server を使用してデータベースを制御、管理する場合でも、あるいは、管理された「サービスとしてのリレーショナル データベース」を提供する Azure SQL Database をフル活用する場合でも、お客様が必要とする可用性とパフォーマンスを確実にご提供いたします。

ぜひ現行のサービスをお試しいただき、9 月に一般提供される新しいサービス レベルのご参考にしていただくことをお勧めします。今すぐ無料評価版をお試しください。

このポストは、8 月 20 日に投稿した WordPress Troubleshooting Techniques on Azure Websitesの翻訳です。

WordPress は Azure WebSites ギャラリーで提供されている一般的な Web アプリケーションの 1 つで、動的な Web サイトの構築に使用します。WordPress サイトを運用していると、何らかの問題が発生しトラブルシューティングを行う機会があるかと思いますが、この記事ではよくある問題について説明し、その対策をご紹介します。

自分の WordPress サイトで php.ini の構成を更新する方法

ユーザーに許可するファイル アップロード時の最大サイズを規定の 8 MB から 12 MB に変更するなど、アプリケーションの要件に応じて WordPress サイトの php.ini ファイルの変更が必要となる場合があります。

ユーザーが PHP の構成を定義する場合は、サイトのルート (D:\home\site\wwwroot) で .user.iniという名前のファイルを作成して、次の文を追加します。

upload_max_filesize = 12M

その後、Web サイトを再起動します。変更が上書きされたことを確認するには、次の文を含む phpinfo.phpという名前の PHP ファイルを作成し、サイトのルート フォルダーに保存します。

<?php phpinfo(); ?>

次に、このファイルを参照して upload_max_size の値を確認します。

メディア コンテンツ (uploads フォルダー) のサイズが 10 GB で Web アプリケーションのサイズが 1 GB の場合、どの料金レベルが適切か検討する

各料金レベルでサポートされている Storage の容量は、Shared では 1 GB、Basic では 10 GB、Standard では 50 GB です。WebSites の Storage を最大限に活用したいとお考えの場合は、uploadsフォルダーに格納されているすべてのメディア コンテンツを Azure Storage に移動し (この場合 0.048 米ドル/GB の料金がかかります)、WordPress サイトのメディア コンテンツの管理に Azure Storage プラグイン (英語)を使用します。これにより、メディア コンテンツを Web アプリケーションと分離させることができます。

また、メディア コンテンツのサービスを提供する Azure Storage アカウントの Azure CDN エンドポイントを作成することもできます。これを行うには、まずプラグインの設定ページで CNAME プロパティの設定を確認し、以下の欄に Azure CDN の名前 (http://az628210.vo.msecnd.net/ など) を入力します。

WordPress サイトで SSL をセットアップする方法

SSL は、Standard レベルと Basic レベルでのみサポートされています。サイトに SSL のサポートを追加する場合は、下記に関するページを参照してください。

• Azure WebSites で SSL のサポートを構成する
• WordPress で SSL を使用できるようにする (英語)

Azure WebSites で mod_rewrite は使用できるか

Azure WebSites では IIS Web サーバーを使用しているため、Apache モジュールである mod_rewrite は使用できません。Azure WebSites ではその代わりに Url Rewrite モジュールが既定で有効になっており、web.configファイルを使用して書き換えルールやリダイレクト ルールを作成できます。

これを行うには、まずサイトのルート フォルダー (D:\home\site\wwwroot) にある web.configファイルを開きます。このフォルダーに web.config が存在しない場合は作成します。

次に、下記の XML 文をコピーして system.webServer 要素に貼り付けます。

<rewrite>
<rules>
<rule name="Main Rule" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.php" />
</rule>
</rules>
</rewrite>

このルールは、すべての要求された URL について照合を行います。URL に対応するファイルやフォルダーがファイル システム内に存在しない場合は、ルールに従って URL が index.php に書き換えられます。その次に、書き換えられる前の URL に含まれている REQUEST_URI サーバー変数に基づいて、どのコンテンツをサービスとして提供するかが決定されます。

URL の書き換えルールの作成についての詳細は、「URL の書き換えに関する 10 のヒントとテクニック (英語)」を参照してください。

依存要求を .woff ファイルで行うときに 404.3 “Mime Type missing” エラーが発生する場合の対処

Azure WebSites の既定では .woff 拡張子は無効化されています。WordPress などのアプリケーションで .woff ファイルを使用する場合は、サイトのルート フォルダーにある web.config ファイルに下記の <system.webServer> の部分を追加します。

<configuration>
<system.webServer>
<staticContent>
   <mimeMap fileExtension=".woff" mimeType="application/x-font-woff" />     </staticContent>
</system.webServer>
</configuration>

その後、Web サイトを再起動します。

Azure で実行している WordPress サイトのページの読み込みが遅い場合の対処

WordPress サイトの速度が遅い場合は、次の項目について確認してください。

• 料金レベルが Free ではありませんか。

Free レベルのパフォーマンスは運用環境には不十分です。Shared、Basic、Standard のいずれかのレベルへのアップグレードをお勧めします。Azure WebSites の料金詳細ページで各料金レベルの機能を確認し、適切なレベルを選択してください。

• Web サイトとデータベースが存在するデータ センターが異なっていませんか。

Web サイトが米国西部、データベースが米国東部に存在するなど、コンポーネントが存在するデータセンターの場所が異なっていると、データベースを呼び出すときにネットワークのレイテンシの影響によりページの読み込みが遅くなる場合があります。Web サイトとデータベースは同じリージョンの同じデータセンターに配置することをお勧めします。

• 無料の ClearDB MySQL データベースを使用していませんか。

無料の ClearDB MySQL データベースは、運用環境の Web サイトに向けたものではありません。Azure 用の ClearDB のプラン (英語)と Azure ストアから購入する方法をご確認ください。

PHP のエラーの診断結果を取得する方法

Azure WebSites では、Web サーバーの診断を有効にすると Web サーバーのログ記録、詳細なエラー メッセージ、失敗した要求のトレースなどが得られます。エラー情報の取得に関する詳細については、Azure WebSites での PHP の診断に関するブログ (英語)を参照してください。

新たに導入された Diagnostics as a Service (DaaS) では、これらのログを解釈し、問題解決を支援したり、ガイドとして役立つ情報を提供したりします。詳細については、Azure WebSites の Diagnostic as a Service (DaaS) に関するブログを参照してください。

WordPress で詳細なデバッグ機能を有効化する方法

WordPress では、WordPress サイトのデバッグに関してさまざまなオプションを提供しています。WordPress サイトのデバッグ機能を有効にするには、WP_DEBUG 定数をオンにします。既定では、この定数は wp-config.phpファイルでオフに設定されています。

define('WP_DEBUG', false);

この値を TRUE に設定して有効化します。

define('WP_DEBUG', true);

デバッグ作業が終了した後は、この機能は必ずオフにしてく��さい。WordPress のデバッグに関する詳細は、「WordPress でのデバッグ (英語)」を参照してください。

WordPress サイトで電子メール サービスを有効化する方法

Azure WebSites では電子メールおよび SMTP をサポートしていないため、Azure ストアで SendGrid を購入する必要があります。SendGrid の Freeプラン (最大で 1 か月に 25,000 通の電子メールを利用可能) で、たいていの WordPress サイトに十分対応可能です。Free プランで不十分な場合は、こちらのページ (英語)で Azure 用の SendGrid のプランをご確認いただけます。

詳細については、「PHP から SendGrid 電子メール サービスを使用する方法」を参照してください。

WordPress サイトのバックアップと復元の方法

Azure WebSites には自動バックアップ機能と自動復元機能があります。詳細については、Azure WebSites のバックアップ方法と復元方法を参照してください。

WordPress サイトはオンラインで編集可能か

WebSites では、Visual Studio の機能を備えたオンライン エディターが使用できます。詳細については、Monaco を使用した Azure WebSites のオンライン編集に関するページ (英語)を参照してください。

WordPress でデータベース接続時のエラーを修正する方法

WordPress がデータベースと接続できない場合にはエラーが発生します。その原因には次のようなものが考えられます。

• wp-config.php ファイルのデータベース情報が不正確

MySQL Client でデータベースにアクセスして wp-config.phpの情報を訂正します。

• WordPress サイトのフロントエンドとバックエンドのそれぞれでエラーの種類が異なるかどうかを確認する

WordPress の管理ページで “One or more database tables are unavailable. The database may need to be repaired” などの異なる種類のエラーが発生している場合には、データベースを修復する必要があります。この場合、wp-config.php に次の文を追加します。

define('WP_ALLOW_REPAIR', true);

追加したら、http://<サイトの URL>/wp-admin/maint/repair.phpに移動し確認します。

いったんこの定義を設定すると、ユーザーはこの機能にアクセスする際にログインする必要がなくなります。この機能は破損したデータベースを修復することを主目的としたもので、データベースが破損している場合にはユーザーがログインできないことが多く、そうした状況に対応するためにこのような仕様になっています。データベースの修正と最適化が終了したら、必ずこの部分を wp-config.php から削除してください。

• wp-config.php が破損している可能性がある

wp-config.php を修正して、最終更新日時のタイム スタンプを変更します。

• 読み込み負荷が高いときにサイトで断続的にエラーが発生する

wp-includes/wp-db.php ファイルを下記のように変更して WordPress との固定接続を使用します。

PHP のバージョンが 5.4 以前の WordPress の場合

//1147 行目をコメントアウト
//$this->dbh = mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, $new_link, $client_flags );
//次の行を追加

$this->dbh = mysql_pconnect( $this->dbhost, $this->dbuser, $this->dbpassword,  $client_flags );
if ( false !== $error_reporting ) {
error_reporting( $error_reporting );
}
} else {
//1152 行目をコメントアウト
//$this->dbh = mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, $new_link, $client_flags );
//次の行を追加
$this->dbh = @mysql_pconnect( $this->dbhost, $this->dbuser, $this->dbpassword,  $client_flags );
}

PHP のバージョンが 5.5 以降の WordPress 3.9.1 の場合

//1378 行目
if ( WP_DEBUG ) {
     //$host の前に 'p:'を追加
     mysqli_real_connect( $this->dbh, 'p:'.$host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
              }
      else {
      //$host の前に 'p:'を追加
     @mysqli_real_connect( $this->dbh, 'p:'.$host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
            }

WordPress の自動機能が有効になっている場合、このファイルが上書きされ変更内容が失われる場合があります。このため、WebJob機能を使用してファイルの変更の有無を確認し、この変更が wp-db.phpファイルに適用されていない場合は改めて適用することをお勧めします。WordPress で使用している PHP のバージョンが 5.4 またはそれ以前の場合は、こちらのリンクから WebJob をダウンロードできます。PHP 5.5 を使用している場合はこちらのリンクをご利用ください。

• Web サイトのサービスがデータベースに接続できるかどうかを確認する

データベースに接続できるかどうかを確認するには、testdbconnection.phpという名前の新しいファイルを作成して、次のコードを貼り付けます。

<?php
//データベースの接続情報に合わせて、mysql_connect の
//ホスト名、ユーザー、パスワードを設定
$link = mysql_connect('localhost', 'username', 'password');
if (!$link) {
die('Could not connect: ' . mysql_error());
}
echo 'Connected successfully';
mysql_close($link);
?>

ブラウザでこのページを実行して “Connected successfully” というメッセージが表示されたら、Web サイトのサービスがデータベースに接続可能であるということです。“Could not connect” というメッセージが表示された場合は、MySQL のエラーを確認して問題の原因を特定します。“Could not connect” が表示される場合に問題を解決できないときは、Azure サポートまでご連絡ください。

“1203 SQLSTATE: 42000 (ER_TOO_MANY_USER_CONNECTIONS)” というエラーの解決方法

解決方法は、使用している MySQL サーバーの種類によって異なります。

• ClearDB MySQL データベースを使用している場合、データベース プランに応じて max_user_connections の制限が適用されます。詳細についてはこちらのページ (英語)を参照してください。制限が適用された場合はこのエラーが発生します。プランをアップグレードするとこの問題は解消されます。
• MySQL Azure VM で WordPress サイト用のデータベースをホストしている場合は、my.ini (Windows の場合) または my.cnf (Linux の場合) の構成を編集します。

max_connections = 250

max_connections の設定値が高過ぎると、“Out of memory” エラーが発生して MySQL サーバーが強制終了します。MySQL サーバーの VM のメモリ容量を考慮しつつ適切な値を設定してください。

白い画面や空白ページが表示される場合の対処

Web サイトにアクセスしたときに白い画面や空白ページが表示される場合は、プラグインかテーマに関する問題が考えられます。こちらの手順ごとの説明 (英語)を参考にしながら、問題の原因となっているテーマやプラグインを特定してください。

メモリ容量不足のエラーが発生した場合の対処

メモリ容量は、既定では 128 MB に設定されています。メモリ容量の制限は次のいずれかの方法で引き上げることが可能です。

• wp-config.php に次の文を追加する

define('WP_MEMORY_LIMIT', '128M');

• サイトのルート (D:\home\site\wwwroot) にある .user.ini に次の文を追加する

memory_limit=256M

その後、Web サイトを再起動します。

Azure WebSites の機能やドキュメントへのフィードバックについて

新しいドキュメントへのご意見や不足している情報に関するご要望、新機能や既存機能へのご意見は、フォーラム (英語)からエンジニアリング チームまでお寄せください。

関連情報へのリンク

WordPress のトラブルシューティング ガイド (英語)
WordPress のサポート (英語)

このポストは、8 月 21 日に投稿した Announcing the 0.4.0-beta preview of Microsoft Azure WebJobs SDKの翻訳です。

マイクロソフトはこのたび、Microsoft Azure WebJobs SDK プレビューの新しいバージョンをリリースしました。WebJobs SDK については Scott Hanselman 氏がこちらの記事 (英語)で紹介しています。また、以前のバージョンの詳細についてはこちらの記事を参照してください。

今回のリリースでは、0.3.0-beta に含まれていた基本機能に加えて、新機能が搭載されて��ます。

このリリースをダウンロードする

新しい WebJobs SDK は NuGet ギャラリーからダウンロードできます。NuGet ギャラリーで NuGet Package Manager Console を使用して、パッケージをインストールまたは更新します。

Install-Package Microsoft.Azure.WebJobs –Pre

Microsoft Azure Service Bus のトリガーを使用したい場合は、次のパッケージをインストールしてください。

Install-Package Microsoft.Azure.WebJobs.ServiceBus -Pre

パッケージ名が 0.3.0-beta から変更されたため、今回は最新バージョンへの更新を支援するリダイレクト パッケージをアップロードしています。

Update-Package Microsoft.Azure.Jobs.Core –Pre

Update-Package Microsoft.Azure.Jobs –Pre

WebJobs SDK とは

Microsoft Azure WebSites の WebJobは、サービスやバックグラウンド タスクなどのプログラムを WebSites で簡単に実行できるようにするための機能で、.exe、.cmd、.bat などの各種実行形式ファイルを WebSites にアップロードして実行することができます。これらを WebJob として、トリガーで実行したり継続的に実行したりすることが可能です。WebJobs SDK なしでバックグラウンド タスクの接続や実行を行うとなると、複雑で膨大な量のプログラミングが必要になりますが、SDK が提供するフレームワークを使用すれば、最低限の量のコードで一般的なタスクを実行することが可能になります。

WebJobs SDK のバインディング システムとトリガー システムは、Service Bus だけでなく、Microsoft Azure Storage サービスの BLOB、Queue、Table にも対応しています。バインディング システムを使用すれば、Microsoft Azure Storage オブジェクトに対して読み取りや書き込みを行うコードを簡単に作成できます。トリガー システムは、Queue や BLOB が新しいデータを受け取るたびに、コードに記述されている関数を呼び出します。

今回のプレビューで更新された点

非同期のサポート

関数の中で async と await を使用し、関数から Task を戻すことができます。

1 つの JobHost 内の複数の関数が並行して実行されます。つまり、異なる Queue をリッスンする 2 つの関数がある場合、それらが並行して実行されるということです。

次のコードは、関数内で async と await を使用して Task を戻す方法を示しています。この関数は、Azure Queues 上の inputqueue というメッセージでトリガーされ、そのメッセージを BLOB に書き込みます。

class Program
{
    static void Main()
    {
        JobHost host = new JobHost();
        host.RunAndBlock();
    }
   public async static Task HelloWorldFunctionAsync(
   [QueueTrigger("inputqueue")] string inputText,
   [Blob("output/output.txt")] TextWriter output)
   {
       await output.WriteAsync(inputText);
   }
}

またオプションで、関数の引数として CancellationToken を受け取ることもできます。たとえば、次の関数は「input」というコンテナー内で新しい BLOB が検出されるとトリガーされ、CancellationToken を CopyToAsync 関数に渡すことができます。また、この関数は SDK がファイル名と拡張子をどのようにバインドするかも示しています。SDK を使用すれば、ファイル名や拡張子に簡単にアクセスできます。

class HelloWorldAsyncCancellationToken
{
    static void Main()
    {
        JobHost host = new JobHost();
        host.RunAndBlock();
    }
    public async static Task ProcessBlob(
    [BlobTrigger("input/{name}.{extension}")] Stream input,
    string name, // SDK が File の名前をバインド
    string extension, // SDK が File の拡張子をバインド
    [Blob("output/{name}.{extension}", FileAccess.Write)] Stream output,
    CancellationToken token)
    {
        await input.CopyToAsync(output, 4096, token);
    }
}

関数は明示的に呼び出すことができます。これは、Azure Scheduler を使用してスケジュールで WebJob を実行する場合や、単純に関数を呼び出す場合に便利です。この方法でも、診断や、長時間実行されている関数のキャンセルといった SDK の便利な機能は活用できます。

class Program
{
    static void Main()
    {   
        JobHost host = new JobHost();
        Task callTask = host.CallAsync(typeof(Program).GetMethod("ManualTrigger"), 
                                      new { value = 20 });

        Console.WriteLine("Waiting for async operation...");
        callTask.Wait();
        Console.WriteLine("Task completed: " + callTask.Status);
    }

    [NoAutomaticTrigger]
    public static void ManualTrigger(
    TextWriter log, int value, [Queue("outputqueue")] out string message)
    {
        log.WriteLine("Function is invoked with value={0}", value);
        message = value.ToString();
        log.WriteLine("Following message will be written on the Queue={0}", message);
    }
}

Azure Queues 内の有害メッセージの処理

0.3.0-betaの SDK では、Queue の DequeueCount プロパティにバインドするオプションがありましたが、今回のリリースではメッセージが自動的に有害な Queue に移動されるようになりました。

これにより、有害メッセージを調査のためにログに記録するなど、アプリケーション コード内で処理できるようになりました。方法は単純に関数を QueueTrigger("Queue 名-poison") にバインドするだけです。

次のコードはこの Queue のメッセージを処理しています。Queue にバインドされている関数の処理中に例外が発生した場合、SDK はメッセージを 5 回 (既定) 処理するとそのメッセージを有害と見なし、メッセージを別の Queue に移動します。

class ProcessPoisonMessages
{
    static void Main()
    {
        JobHost host = new JobHost();
        host.RunAndBlock();
     }
     public async static Task ProcessQueue(
     [QueueTrigger("inputqueue")] string inputText,
     [Blob("output/output.txt")] TextWriter output)
     {
       await output.WriteAsync(inputText);
     }
     public static void ProcessPosionQueue(
     [QueueTrigger("inputqueue-poison")] string inputText)
     {
       //有害メッセージを処理し、ログに記録するか、通知を送る
     }
}

Azure Queues に対するポーリング ロジックの改良

今回のリリースでは新しいポーリング戦略が採用されました。アイドル時の Queue のポーリングによるストレージ トランザクション コストへの影響を減らすために、SDK にはランダムな指数バックオフ アルゴリズムが実装されています。

Queue の高速な通知

• 0.3.0-beta の SDK は最大 2 秒間隔でポーリングを行っていました。つまり、20 個の関数が連続するチェーン (1 つの関数が Queue に書き込みを行い、これがトリガーとなって次の関数が Queue に書き込みを行い、またこれが次の関数のトリガーとなる、という処理が繰り返される) の場合、20 個のメッセージの処理には最大で 40 秒かかりました。今回の変更により、これは最大 8 秒に短縮されます。

Queue のポーリングの構成オプション

新しい SDK では、Queue のポーリング動作を開発者が構成できるようにいくつかの設定オプションが提供されています。

• MaxPollingInterval: Queue を空にしたまま、メッセージを確認せずに待機する最長の時間。既定値は 10 分です。
• MaxDequeueCount: Queue メッセージを有害な Queue に移動するタイミング。既定値は 5 です。

次のコードはこれらの設定を構成する方法を示しています。

static void Main()
{
       JobHostConfiguration config = new JobHostConfiguration();
       config.Queues.MaxDequeueCount = 3;
       config.Queues.MaxPollingInterval = TimeSpan.FromMinutes(20); 
       JobHost host = new JobHost(config);
       host.RunAndBlock();
 }

パッケージおよび名前空間の変更

一般的な語「Job」と区別しやすくするためにパッケージ名を変更しました。「Job」は混同しやすく、検索も困難でした。

この変更を取り込むには、既存アプリケーションの再コンパイルと ConnectionString の変更が必要です。

ダッシュボード インデックス処理の高速化

すべての WebJob を表示する場合や WebJob の関数の詳細を表示する場合のダッシュボードのパフォーマンスが向上しました。

ダッシュボードのデータが古いことを警告

ダッシュボードで、ホスト データがバックグラウンドで処理されるようになりました。大量の作業が残っている場合には警告が表示されます。

ダッシュボード インデックスのエラー

インデックスのエラーがある場合、ダッシュボードの [About] ページに表示されるようになりました。ダッシュボードがログのインデックス付けに失敗している場合、このページでエラーの発生を確認できるので便利です。

バグの修正

今回のリリースで多くのバグが修正されました。フォーラムや StackOverflow で報告されたバグを優先的に修正しています。

SDK の既存の機能

0.3.0-beta に引き続き今回のリリースでもサポートしている機能は次のとおりです。

Azure の使用

今回の SDK では、Azure Blobs、Queues、Tables、Service Bus 用のトリガーとバインディングが追加されています。

トリガー

Queue または BLOB 上で新しい入力が検出されたときに関数を実行できます。トリガーの詳細については、こちらの記事 (英語)を参照してください。

バインディング

この SDK ではバインディングがサポートされており、C# プリミティブ型と、BLOB、Table、Queue といった Azure Storage との間でモデル バインディングを行います。これにより、BLOB、Table、Queue のデータを読み書きする処理が簡単になり、Azure Storage に対して読み書きを実行するコードを開発者が習得する必要がなくなります。

現在、Stream、TextReader/Writer、Stringのバインディングがサポートされています。また、カスタム型や Storage SDK のその他の型へのバインディングのサポートを追加することが可能です。詳細については、後述のサンプルを参照してください。

ホスティング

JobHost は、プログラムに含まれる関数を認識している実行コンテナーです。JobHost オブジェクト (Microsoft.Azure.WebJobs (英語)から使用) は、バインディングを読み取り、トリガーをリッスンし、関数を呼び出します。次の例では、JobHost のインスタンスを作成し RunAndBlock() を呼び出します。これにより、JobHost はこのホストに定義された関数に対するすべてのトリガーをリッスンするようになります。

static void Main()
{
    JobHost host = new JobHost();
    host.RunAndBlock();
}

WebJob の監視用ダッシュボード

WebJob (言語、型を問わない) の実行中にリアルタイムで監視を行い、WebJob の状態 (Running、Stopped、Successfully completed)、最終実行日時、実行ログを確認することができます。次のスクリーンショットのように、WebSites で稼動するすべての WebJob が表示されます。

関数実行の詳細

「ImageProcessing」という WebJob の実行を監視する場合、プログラム内の関数呼び出しに関して次のような詳細情報を確認できます。

• この関数のパラメーター
• 関数の実行所要時間
• BLOB からの読み取りの所要時間と、読み書きのバイト数

ImageProcessing WebJob のコードは次のとおりです。この WebJob が使用している機能を以下に説明します。

using Microsoft.Azure.WebJobs;
using System.IO;
using System.Threading;
using System.Threading.Tasks;
using System.Web.Helpers;

namespace ImageResizeAndWaterMark
{
    class ImageProcessingFunctions
    {
        public static void Resize(
        [BlobTrigger(@"images-input/{name}")] WebImage input,
        [Blob(@"images2-output/{name}")] out WebImage output)
        {
            var width = 80;
            var height = 80;
            output = input.Resize(width, height);
        }
        public static void WaterMark(
        [BlobTrigger(@"images2-output/{name}")] WebImage input,
        [Blob(@"images2-newoutput/{name}")] out WebImage output)
        {
            output = input.AddTextWatermark("WebJobs is now awesome!!!!", fontSize: 6);
        }
    }
    public class WebImageBinder : ICloudBlobStreamBinder<WebImage>
    {  
        public Task<WebImage> ReadFromStreamAsync(Stream input, CancellationToken cancellationToken)
        {
            return Task.FromResult(new WebImage(input));
        }

        public async Task WriteToStreamAsync(WebImage result, Stream output, CancellationToken cancellationToken)
        {
            var bytes = result.GetBytes();
            await output.WriteAsync(bytes, 0, bytes.Length,cancellationToken);
        }
    }
}

呼び出しと再実行

上の例では、Resize 関数が何らかの理由で正常に動作しない場合、新しい画像をアップロードして Resize 関数を再実行できます。すると実行チェーンがトリガーされ、Watermark 関数も呼び出されます。このような詳細情報は、関数どうしが複雑に組み合わされている場合に問題を診断してデバッグするのに便利です。また、ダッシュボードから関数を実行することも可能です。

関数の因果関係

上の例では、Resize 関数が BLOB への書き込みを行うと、それがトリガーとなって WaterMark 関数が呼び出されます。ダッシュボードには、このような関数間の因果関係が表示されます。多数の関数が複雑に絡み合い、新しい入力が検出されるたびにトリガーされるような場合に、この因果関係グラフが役立ちます。

BLOB の検索

[Search Blobs] をクリックし BLOB を検索すると、該当する BLOB で発生した事象に関する情報を確認できます。たとえば、ImageProcessing の場合は Resize 関数が実行されるので、BLOB に対する書き込みが行われています。BLOB の検索の詳細については、こちらの記事 (英語)を参照してください。

サンプル

WebJobs SDK のサンプルは次の場所を参照してください。https://github.com/Azure/azure-webjobs-sdk-samples (英語)

• BLOB、Table、Queue、および Service Bus でのトリガーやバインディングの使用例をご覧いただけます。
• PhluffyShuffy というサンプルは画像処理を行う Web サイトです。ユーザーがここに写真をアップロードすると、BLOB ストレージのその画像を処理する関数がトリガーされます。

関連資料

• チュートリアル: Azure WebJobs SDK の使用を開始する (英語)
• Channel 9 のビデオ: Azure WebJobs SDK で仕事を便利に (英語)
• Scott Hanselman 氏による WebJob と SDK の紹介 (英語)
• Brady Gaster 氏による WebJobs SDK と ASP.NET を使用した Web サイト モニターの構築に関する記事 (英語)
• Azure の WebJob に関する参考資料 (英語)
• Azure Friday の WebJob ビデオ シリーズ (英語)

SDK を使用した WebJob のデプロイ

Visual Studio 2013 Update 3 および Azure SDK 2.4 では、WebJob を Azure WebSites に公開する Visual Studio ツールのサポートが追加されています。詳細については、「Azure WebJob を Azure WebSites にデプロイする方法 (英語)」を参照してください。

0.3.0-beta から 0.4.0-beta への移行時の既知の問題

新しい API に合わせた名前空間の更新

変更前
Microsoft.WindowsAzure.Jobs
Microsoft.Azure.Jobs.Core

変更後
Microsoft.WindowsAzure.WebJobs
Microsoft.Azure.WebJobs.Core

connectionString 名の更新

connectionString を設定する際、WebJob の app.config または Microsoft Azure WebSites の [Configure Tab] で connectionString の名前を、次のように変更する必要があります。

変更前
AzureJobsRuntime
AzureJobsDashboard

変更後
AzureWebJobsRuntime
AzureWebJobsDashboard

connectionString のログアカウントへの保管

最新バージョンの SDK (0.4.0-beta) までは、AzureJobsRuntime ストレージ アカウントの接続文字列が AzureJobsDashboard ログに保管されます。このログを表示できるのは管理ユーザーのみであり、接続文字列を表示およびリセットできるユーザーと同じです。これは大きな問題とはなっていませんが、今後このような運用は取り止めます。今後 1 か月の間に、ダッシュボードを更新してこれまでに保管された接続文字列を削除する予定です。

今すぐに接続文字列を削除するには、AzureJobsDashboard connectionString で指定されたログ��開きます。

"azure-jobs*" という名前の BLOB コンテナー名を削除します (ただし、"azure-jobs-host"、"azure-jobs-host-output"、"azure-jobs-host-archive"、"azure-jobs-dashboard" は除きます)。

"AzureJobs*" という名前のテーブルを削除します。

"azure-jobs*" という名前の Queue を削除します。

ダッシュボードは 0.4.0-beta でデプロイされた WebJob にのみ対応

WebJob を 0.3.0-beta の SDK でデプロイしている場合、ダッシュボードでその WebJob のログを確認すると、「Host not running」という警告が表示されます。これは、今回のリリースにより最新バージョンのダッシュボードがすべての Azure WebSites にデプロイされることが原因です。新しいダッシュボードはプロトコルが若干変更されており、0.3.0-beta との互換性がありません。このエラーを回避するには 0.4.0-beta NuGet パッケージを使用するよう WebJob を更新し、WebJob を再度デプロイしてください。

フィードバックとヘルプについて

Microsoft Azure WebSites の WebJob機能と Microsoft Azure WebJobs SDK は現在プレビュー版です。このプレビュー版の改良に役立つフィードバックをぜひご提供ください。

このチュートリアルに直接的には関係のないご質問は、Azure フォーラム、ASP.NET フォーラム (英語)、または StackOverflow.com (英語)までお寄せください。Twitter の場合は #AzureWebJobs SDK を付けてフィードバックをお願いします。StackOverflow では「Azure-WebJobsSDK」タグをご使用ください。

このポストは、8 月 20 日に投稿した Automate Linux VM Customization Tasks Using CustomScript Extensionの翻訳です。

こちらの Azure ブログ記事をご覧になった皆様は、既に Windows VM 用カスタム スクリプト拡張 (CustomScript Extension) についてご存知かと思いますが、このたびこの拡張機能が Linux VM でもご利用いただけるようになりました。

また、cloud-init についても以前の記事でご紹介しましたが、これはプロビジョニング時にスクリプトやメタデータを Azure Linux VM に挿入する機能です。カスタム スクリプト拡張では、さらに強力な VM カスタマイズ機能が利用でき、プロビジョニング中とプロビジョニング完了後のどちらのタイミングでもスクリプトを実行できます。また Azure でサポートされているすべての Linux VM でも使用できます。

カスタム スクリプトでできること

Azure で Linux VM を作成した後、通常は VM にワークロード (Web サーバーやデータベースなど) をデプロイします。この場合、作業を一連のスクリプトで実行することが理想的です。

• カスタム スクリプト拡張では、指定した場所から指定したパラメーターを使用してスクリプトを自動的にダウンロードし、実行できます。
• カスタム スクリプト拡張は、Linux でサポートされているあらゆるスクリプト言語 (Python や Linux シェル スクリプトなど) で記述されたスクリプトをサポートしています。ただし、対応するスクリプト インタープリターが VM にインストールされている必要があります。
• カスタム スクリプト拡張では、VM のプロビジョニング中でもプロビジョニング完了後の任意のタイミングでもインストールや構成を実施できます。
• カスタム スクリプト拡張のデプロイメントは、Azure PowerShell コマンドレットから行えます。クロスプラットフォーム スクリプトによるデプロイメントと Azure ポータルからのデプロイメントも、今後数週間以内にサポートされる予定です。詳細については後日改めてお伝えいたします。

前提条件

• Microsoft Azure Linux Agent (バージョン 2.0.5 以降) がインストールされていること。
• 実行するスクリプトの準備が完了して Azure Storage の BLOB、または GitHub にアップロードされていること。このとき、スクリプト インタープリターが VM にインストールされていることを確認します。
• Azure PowerShell コマンドレットから拡張機能をデプロイする場合は Azure PowerShell がインストールされていること (こちらのページからダウンロードできます)。

カスタム スクリプト拡張のデプロイメント

拡張機能のデプロイメントには、Azure PowerShell、クロスプラットフォーム スクリプト、および Azure ポータルを使用できます。この記事では、Azure PowerShell を使用して拡張機能をデプロイする場合についてご説明します。

まず、Azure PowerShell がインストールされていることを確認します。拡張機能をデプロイしスクリプトを実行する方法は 2 つあり、スクリプトが格納されている場所によって異なります。

Azure Storage の BLOB に格納されているスクリプトを実行する場合

1. スクリプトを作成して BLOB にアップロードします。
2. プロビジョニング中またはプロビジョニング完了後に、VM に拡張機能を追加します。
3. スクリプトをアップロードした BLOB の場所とオプションのパラメーターを入力します。
4. VM 内で拡張機能によってスクリプトがダウンロードされます。
5. 拡張機能によってスクリプトが起動されます。このとき、ユーザーが指定したパラメーターが使用されます。

# Azure BLOB に格納されている Linux シェル スクリプトを実行するサンプル スクリプト
# VM 名、Azure ストレージ アカウント名、およびキーを入力する
$VmName = 'MyVM'  
$vm = Get-AzureVM $VmName
$PrivateConfiguration = '{"storageAccountName": "MyAccount","storageAccountKey":"Mykey"}' 
# スクリプトが格納されている Azure BLOB の場所と、実行するコマンドを指定する
$PublicConfiguration = '{"fileUris":["http://MyAccount.blob.core.windows.net/vhds/MyShellScript.sh"], "commandToExecute": "sh MyShellScript.sh" }' 

# 拡張機能を VM にデプロイする
$ExtensionName = 'CustomScriptForLinux'  
$Publisher = 'Microsoft.OSTCExtensions'  
$Version = '1.0' 
Set-AzureVMExtension -ExtensionName $ExtensionName -VM  $vm -Publisher $Publisher -Version $Version -PrivateConfiguration $PrivateConfiguration -PublicConfiguration $PublicConfiguration  | Update-AzureVM

GitHub に格納されているスクリプトを実行する場合

1. スクリプトを作成して GitHub にアップロードします。
2. プロビジョニング中またはプロビジョニング完了後に、VM に拡張機能を追加します。
3. スクリプトをアップロードした GitHub の場所とオプションのパラメーターを入力します。
4. VM 内で拡張機能によりスクリプトがダウンロードされます。
5. 拡張機能によりスクリプトが起動されます。このとき、ユーザーが指定したパラメーターが使用されます。

# GitHub に格納されている Python スクリプトを実行するサンプル スクリプト
# VM 名を入力する
$VmName = 'MyVM'  
$vm = Get-AzureVM $VmName
#Specify the Location of the script and the command to execute
$PublicConfiguration = '{"fileUris":["https://github.com/MyProject/Archive/MyPythonScript.py"], "commandToExecute": "python MyPythonScript.py" }' 

# スクリプトが格納されている場所と、実行するコマンドを指定する
$ExtensionName = 'CustomScriptForLinux'  
$Publisher = 'Microsoft.OSTCExtensions'  
$Version = '1.0' 
Set-AzureVMExtension -ExtensionName $ExtensionName -VM  $vm -Publisher $Publisher -Version $Version -PublicConfiguration $PublicConfiguration  | Update-AzureVM

結果のクエリ

• カスタム スクリプト拡張は、ユーザーが作成したスクリプトをデプロイ完了直後から実行します。
• 実行結果は Azure PowerShell コマンドレットの Get-AzureVM または Get-Deployment で取得できます。また、ステータスはクロスプラットフォーム スクリプトおよび Azure ポータルから確認できます (近日中に導入予定)。
• カスタム スクリプト拡張のログ ファイルは /var/log/azure/Microsoft.OSTCExtensions.CustomScriptForLinux/1.0/extension.log に格納されます。ユーザーが作成したスクリプトの通常の出力も、このログ ファイルに記録されます。

補足

• 複数のスクリプトを使用する場合は、依存スクリプトを呼び出すエントリ ポイントのスクリプトを作成し、次にエントリ ポイントのスクリプトや依存スクリプト、その他の依存関係にあるバイナリを、Azure Storage の BLOB または GitHub にアップロードします。
• この拡張機能は、VM 作成後に 1 回のみ実行するタスクを想定しています。同じ構成で拡張機能を再度呼び出しても、指定したスクリプトは実行されません。カスタム スクリプト拡張を複数回実行する必要がある場合は、次のような構成変更を行います。

1. スクリプト名を変更する。
2. 次のコードのように、[PublicConfiguration] パラメーターとしてタイムスタンプを追加する。

# カスタム スクリプト拡張を実行するたびに構成が確実に変更されるように、現在のタイムスタンプを生成し構成に追加する
$TimeStamp = (Get-Date).Ticks
$PublicConfiguration = '{"fileUris":[“MyAccount.blob.core.windows.net/vhds/MyShellScript.sh”], "commandToExecute": "sh MyShellScript.sh", “timestamp”: “' + $TimeStamp + '“}'

このポストは、8 月 25 日に投稿した SQL Server AlwaysOn Template in Microsoft Azure Portal Galleryの翻訳です。

現在プレビュー段階にある Microsoft Azure ポータルのギャラリーに、新しいテンプレートが追加されました。追加されたのは SQL Server 2014 AlwaysOnテンプレートで、これを使用することで SQL Server AlwaysOn 可用性グループの作成を自動化し、セットアップ作業をバックグラウンドで処理できるようになります。Scott Guthrie が先日投稿したブログ記事 (英語) (翻訳: NAOKI SATO ブログ: Azure: 新しいDocumentDB NoSQLサービス、新しいSearchサービス、新しいSQL Server AlwaysOn VMテンプレートなど) では、このテンプレートのことを他の便利な機能と併せて紹介しています。

AlwaysOn テンプレートで基本的な設定 (または既定値) を選択すると、ホスト名のプレフィックス、可用性グループ名、オプションのリスナー名、VM 料金レベル (グループ参加者と監視 VM 用)、サービス アカウント/パスワードといった高レベルのオプションが指定されます。複雑な作業はすべてこのテンプレートで処理され、一連の VM の作成が完了し、以下のスクリーンショットのように接続された状態となります。

あとはデータベース サーバーに接続して、可用性グループにデータベースを作成するだけです。

これならすぐにセットアップを完了して使用し始めることができます。AlwaysOn 可用性グループを Azure で実行する方法や新しいテンプレートの詳細については、SQL サーバーのブログ サイトの「Microsoft Azure ポータルのギャラリーで SQL Server AlwaysOn テンプレートを提供開始 (英語)」をご覧ください。

このポストは、8 月 25 日に投稿した Azure HDInsight makes HBase (NoSQL database) a GA Feature の翻訳です。

マイクロソフトは 6 月 6 日に Azure HDInsight の HBase をプレビューとしてリリースしたことを発表しました。また 8 月 21 日には、Azure DocumentDB と Azure Search のプレビューと並んで、HBase の一般提供 (英語)を発表しました。Apache HBase は、Apache Hadoop エコシステムを構成する単票形式の NoSQL (「Not only Structured Query Language」、つまり、SQL を使わない) 分散データベース プロジェクトです。

HBase は Hadoop エコシステムにトランザクション機能を提供し、Azure Blobs の大規模なデータセットの迅速なレコード更新や検索を可能にします。分散データベースである HBase は、負荷やパフォーマンスのニーズの増大に合わせて拡張できるよう設計されています。つまり、HBase は数百万行から十数億行にも上る膨大なデータのトランザクション処理が必要なお客様に最適だということがわかります (一般提供時には、Azure Blobs で最大 500 テラバイトをサポートする予定です)。ただし HBase には、オプティマイザー、セカンダリ インデックス、高度なクエリ言語といった機能がないため、標準的な RDBMS を完全に置換するものではありません。

HBase の一般的な使用例として、以下のようなものがあります。

• モノのインターネット (Internet of Things)– デバイス、センサー、装置/機器、あるいはソーシャル メディアからは数百万件ものリアルタイム イベントが上がってきますが、こうしたデータを処理するためのストレージとして HBase が利用できます。これにより、Azure Blobs に格納されたデータを HDInsight の Hadoop で一括分析することができます。
• Web のログ– HBase を使用して、Web のログとクリックストリーム データの格納やインデックス化を行うことができます。これにより、こうしたデータを HDInsight の Hadoop で一括分析することが可能です。
• ソーシャルセンチメント– HBase を使用して、Twitter などのソーシャル メディア上で交わされる大量のセンチメント データを書き込み、格納することができます。

HBase の詳細については、以下の HDInsight のドキュメントや入門ガイドでご確認いただけます。ぜひご覧ください。

• HBase の概要: http://azure.microsoft.com/en-us/documentation/articles/hdinsight-hbase-overview (英語)
• HBase の使用方法: http://azure.microsoft.com/en-us/documentation/articles/hdinsight-hbase-get-started (英語)
• HBase を使用したリアルタイムのソーシャル センチメント分析: http://azure.microsoft.com/en-us/documentation/articles/hdinsight-hbase-analyze-twitter-sentiment (英語)
• その他の HDInsight 関連ドキュメント: http://azure.microsoft.com/ja-jp/documentation/services/hdinsight/

また、以下の Hadoop と HDInsight の関連資料もぜひご確認ください。

• Azure HDInsight (Hadoop) の関連資料: http://azure.microsoft.com/ja-jp/services/hdinsight/
• Channel 9 の HDInsight 入門ガイドのビデオ シリーズ: http://channel9.msdn.com/Series/Getting-started-with-Windows-Azure-HDInsight-Service (英語)

このポストは、8 月 25 日に投稿した Using VMAccess Extension to Reset Login Credentials for Linux VMの翻訳です。

Azure VM のパスワードや SSH キーを忘れてしまって VM にアクセスできなくなった経験はありませんか? そんなときに VMAccess 拡張機能を使用すれば、パスワードや SSH キー、SSH 構成をリセットして、再びアクセスできるようになります。

この拡張機能は Linux VM を対象としています。Windows VM については、こちらのページをご参照ください。

また、初めて VM 拡張機能を使用するという場合は、関連する情報についてこちらのブログ記事でご確認ください。

前提条件

• 最新の Microsoft Azure Linux Agent (バージョン 2.0.5 以降) をインストールします。
• Azure PowerShellをインストールします。VMAccess 拡張機能をデプロイするには、他の VM 拡張機能と同様、Azure PowerShell コマンドレットを使用します。なお、クロスプラットフォーム スクリプトを使用したデプロイメントも数週間以内にサポートされる予定です。詳細については別途お知らせしますので、引き続きご注目ください。
• リセット後に VM で使用する新しいパスワードまたは SSH キーを準備します。

VMAccess 拡張機能を使用する

VM の何をリセットするかによって、VMAccess を使用する 5 つのシナリオが考えられます。それぞれのシナリオについて、対応する PowerShell スクリプトの例をご紹介したいと思います。ご注目いただきたいのは、シナリオに応じて異なるパラメーターを指定するだけでよい点です。後半の「処理を開始」以降の部分は、どのシナリオも同じです。スクリプトはきわめて単純です。

1. パスワードのみをリセットする

#パスワードをリセットするためのサンプル スクリプト
#VM 名を入力
$VmName = “VMName”
$vm = Get-AzureVM $VmName
#現在のユーザー名と新しいパスワードを入力
$UserName = "CurrentName"
$Password = "NewPassword"
$PrivateConfig = '{"username":"' + $UserName + '", "password": "' +  $Password + '”}'

#処理を開始
$ExtensionName = 'VMAccessForLinux'
$Publisher = 'Microsoft.OSTCExtensions'
$Version =  '1.0'
Set-AzureVMExtension -ExtensionName $ExtensionName -VM  $vm -Publisher $Publisher -Version $Version -PrivateConfiguration $PrivateConfig | Update-AzureVM

2. SSH キーのみをリセットする

#SSH キーをリセットするためのサンプル スクリプト
#VM 名を入力
$VmName = “VMName”
$vm = Get-AzureVM $VmName
#現在のユーザー名と新しい SSH 公開キーのパスを入力
$UserName = "CurrentName"
$cert = Get-Content "CertPath"
$PrivateConfig = '{"username":"' + $UserName + '", "ssh_key":"' + $cert + '"}'

#処理を開始
$ExtensionName = 'VMAccessForLinux'
$Publisher = 'Microsoft.OSTCExtensions'
$Version =  '1.0'
Set-AzureVMExtension -ExtensionName $ExtensionName -VM  $vm -Publisher $Publisher -Version $Version -PrivateConfiguration $PrivateConfig | Update-AzureVM

3. パスワードと SSH キーをリセットする

#パスワードと SSH キーをリセットするためのサンプル スクリプト
#VM 名を入力
$VmName = 'VMName'
$vm = Get-AzureVM $VmName
#現在のユーザー名と共に、新しいパスワードと新しい SSH 公開キーの証明書パスを入力
$UserName = "CurrentName"    
$Password = "NewPassword"
$cert = Get-Content "CertPath"
$PrivateConfig = '{"username":"' + $UserName + '", "password": "' +  $Password + '", "ssh_key":"' + $cert + '"}'

#処理を開始
$ExtensionName = 'VMAccessForLinux'
$Publisher = 'Microsoft.OSTCExtensions'
$Version =  '1.0'
Set-AzureVMExtension -ExtensionName $ExtensionName -VM  $vm -Publisher $Publisher -Version $Version -PrivateConfiguration $PrivateConfig | Update-AzureVM

4. 新しい sudo ユーザー アカウントを作成する

ユーザー名を忘れた場合、VMAccess を使用して sudo 権限が付与されたユーザー名を作成することができます。このとき、元のユーザー名とログイン キーは変更されず、引き続き有効です。

パスワードでアクセスする sudo ユーザーを新たに作成する場合はシナリオ 1 のスクリプトを、SSH キーでアクセスする sudo ユーザーを新たに作成する場合はシナリオ 2 のスクリプトを、また、両方を使ってアクセスするユーザーを新たに作成する場合はシナリオ 3 のスクリプトを使用します。このとき、“UserName” を新しいユーザー名に変更することを忘れないでください。

5. SSH 構成をリセットする

SSH 構成がうまくいかないと、VM にアクセスできなくなる恐れもあります。VMAccess 拡張機能を使用すれば、既定の構成にリセットできます。既定の構成にリセットするには、構成内の新しいアクセス用パラメーター (ユーザー名、パスワード、または SSH キー) すべてを削除するだけで済みます。この拡張機能では、SSH サーバーを再起動し、VM の SSH ポートを開き、SSH 構成を規定の構成にリセットします。VM のユーザー アカウント (パスワードまたは SSH キー) は変更されません。

なお、リセットされる SSH 構成ファイルは /etc/ssh/sshd_config に配置されています。

#VM の SSH 構成をリセットするためのサンプル スクリプト
#VM 名のみを入力
$VmName = 'VMName'
$vm = Get-AzureVM $VmName
$PrivateConfig = '{"reset_ssh": "True"}'

#処理を開始
$ExtensionName = 'VMAccessForLinux'
$Publisher = 'Microsoft.OSTCExtensions'
$Version =  '1.0'
Set-AzureVMExtension -ExtensionName $ExtensionName -VM  $vm -Publisher $Publisher -Version $Version -PrivateConfiguration $PrivateConfig | Update-AzureVM

結果を問い合わせる

VMAccess 拡張機能のステータスは、Azure PowerShell コマンドレットの Get-AzureVM または Get-Deployment で取得できます。

リセット後に VM にアクセスする

VMAccess 拡張機能を用いて資格情報や構成のリセットが完了したら、新しいアカウント名、パスワード、または SSH キーでインスタンスにログオンできます。

注意事項

既存のユーザー アカウントのパスワードまたは SSH キーだけをリセットする場合は、入力するユーザー名が元のユーザー名と同じであることを確認してください。元の名前と異なるものを入力すると、VMAccess 拡張機能では上述のシナリオ 4 に該当するものと判断され、新しいユーザー アカウントが作成されます。

このポストは、8 月 26 日に投稿した How to Use Socket.IO with Azure Mobile Service Node Backendの翻訳です。

Azure Mobile Services の .NET バックエンドでは、SignalR を使用してリアルタイムのコミュニケーションを行うことができます。ただし、これまでこのオプションはノード バックエンドのお客様にはご利用いただけませんでした。Azure Mobile Services のノード バックエンドの最新の更新プログラムにより、Mobile Services での Socket.IO (英語)の利用が簡単になりました。

インストール

まず、次のように Mobile Services の Git リポジトリをローカルに複製します。

C:\> git clone <a href="http://YOUR-SERVICE-NAME.scm.azure-mobile.net">http://YOUR-SERVICE-NAME.scm.azure-mobile.net</a>

次に、カレント ディレクトリを service フォルダーに変更し、socket.io モジュールをインストールします。

cd nodetestapp\service
npm install socket.io –save

注: リモート リポジトリの node_modules フォルダーがプッシュされないようにするために、.gitignore ファイルを追加する必要があります。詳細については、「Azure Mobile Services での package.json のサポート (英語)」をご覧ください。

次に、ディレクトリを extensions フォルダーに移動し、次の内容を含む startup.js という名前のファイルを作成します。

var path = require('path');

exports.startup = function (context, done) {
    var io = require('socket.io')(context.app.server);
    io.on('connection', function(socket){
      socket.on('chat message', function(msg){
        io.emit('chat message', msg);
      });
    });    

       context.app.get('/public/chat.html', function(req, res) {
        res.sendfile(path.resolve(__dirname, '../public/chat.html'));
    });    
    done();
}

上記のスニペットでは、Socket.IO を構成し、作成するチャット アプリをホストするルートを追加しています。

チャット アプリ

次の HTML を含む chat.html という新しいファイルを作成し、service フォルダー内に新たに public フォルダーを作成して保存します。

<!doctype html>
<html>
  <head>
    <title>Socket.IO chat</title>
    <style>
      * { margin: 0; padding: 0; box-sizing: border-box; }
      body { font: 13px Helvetica, Arial; }
      form { background: #000; padding: 3px; position: fixed; bottom: 0; width: 100%; }
      form input { border: 0; padding: 10px; width: 90%; margin-right: .5%; }
      form button { width: 9%; background: rgb(130, 224, 255); border: none; padding: 10px; }
      #messages { list-style-type: none; margin: 0; padding: 0; }
      #messages li { padding: 5px 10px; }
      #messages li:nth-child(odd) { background: #eee; }
    </style>
  </head>
  <body>
    <ul id="messages"></ul>
    <form action="">
      <input id="m" autocomplete="off" /><button>Send</button>
    </form>
    <script src="http://code.jquery.com/jquery-1.11.1.js"></script>
    <script src="http://cdn.socket.io/socket.io-1.0.0-pre5.js"></script>    
    <script>
      var socket = io();
      $('form').submit(function(){
        socket.emit('chat message', $('#m').val());
        $('#m').val('');
        return false;
      });
      socket.on('chat message', function(msg){
        $('#messages').append($('<li>').text(msg));
      });
    </script>
  </body>
</html>

最後に、Git の add、commit、push コマンドを使用して、すべての変更をコミットし、Mobile Services にプッシュします。

その後、http://<サービス名>.azure-mobile.net/public/chat.htmlにアクセスすると、下部にテキスト ボックスとボタンが表示されたページを確認することができます。ブラウザーでこのページのインスタンスを 2 つ開きます。メッセージを入力して Enter キーを押すと、もう一方のウィンドウにメッセージが表示されます。

スケールアウト

上記のサンプルは、Mobile Services のインスタンスが 1 つの場合にのみ動作します。複数のインスタンスがある場合、Socket.IO と共に、リアルタイム コミュニケーションのバッキング ストアとして Redis を使用する必要があります。そのためには、npm から socket.io-redis ノード モジュールをインストールします。

https://www.npmjs.org/package/socket.io-redis (英語)

その後、Azure の Redis インスタンスに対して動作するように構成します。詳細については、下記の記事を参照してください。

http://azure.microsoft.com/en-us/documentation/articles/cache-dotnet-how-to-use-azure-redis-cache/ (英語)

このポストは、8 月 25 日に投稿した A Boost in Security for Azure SQL Database: Auditingの翻訳です。

待望の監査機能のプレビュー版、Auditing が Azure SQL Database 向けにリリースされました。この大きなセキュリティ強化により、クラウドでのデータベース管理に関するビジネス上の障壁が解消されます。

数週間前にプレビュー版がリリースされたこの SQL Database Auditing を利用すると、データの更新や照会などデータベース内で発生したイベントや変化をより的確に把握できるようになります。非常にシンプルで直観的な構成インターフェイスを使用すれば、数分でデータベース上に稼働させることができます。Auditing がもたらすメリットについては、Eyal Carmel と Scott Klein が Channel 9 のビデオ (英語)でこの新機能をわかりやすく紹介していますので、ぜひご覧ください。

Auditing は Basic、Standard、Premium レベルのデータベースでご利用いただけます。設定は新しい Azure 管理ポータル (プレビュー)、または標準 API を通じて行います。

Auditing を使用すべき理由

データベースで Auditing を有効にするだけで、さまざまな目的に役立つ貴重な情報の宝庫が手に入ります。

• コンプライアンス関連の作業が円滑に

Auditing は、PCI-DSS、SOX、HIPAA といった業界の諸規制の要件を満たすのに役立つ有益なツールです。こうした規制の多くでは、データベースのデータに関する活動の監査証跡が必要とされています。

• データベースの稼働状況を把握

監査証跡を残すことによって、データベースで “どのような処理” が “だれ” によって “いつ” 行われたのかを正確に知ることができるようになり、業務の透明性が向上します。また、こうしたデータはビジネス トレンドの把握や、懸念すべき兆候をキャッチするのにも役立ちます。たとえば、データを分析した結果、ある場所に配置されているデータベースの稼動レベルが徐々に低下していることが判明したのでその対策を講じた、というようなメリットが得られます。

• セキュリティ違反の可能性を検知

監査データの分析により、社内全体で発生しているデータ関連の不整合や異常を確認でき、セキュリティ インシデントの特定につながります。

とても重要なことですが、Auditing やその他のセキュリティ機能を活用することで諸規制に適合したアプリケーションを簡単に構築することはできますが、それによってコンプライアンスが確保されるわけではありません。企業が自己の責任に基づいて、自社または業界のセキュリティおよびコンプライアンスの基準に沿ったアプリケーション設計やデータベースの使用を徹底する必要があります。

Auditing による SQL Database のイベントの追跡方法

Auditing を有効化して設定が完了すると、指定した SQL Database が受信、発信するすべてのイベントが追跡されます。対象とするデータベースの処理やイベントのカテゴリを設定することができ、該当するイベントが発生するたびに Azure Storage の監査ログに記録されます。

監査で毎回参照されている “ユーザー” (またはプリンシパル) は SQL Database にログインしたデータベース ユーザーであって、必ずしもアプリケーション ユーザーではありませんのでご注意ください。

記録されるデータとその保存場所

Auditing を構成する際に、監査ログの書き込み先となるストレージ アカウントを指定します (Azure Storage の料金が課金されます)。Auditing が有効になると、自動的に Azure Table が指定のストレージ アカウントに作成され、設定に従って指定のイベントのレコードが書き込まれます。下の Auditing のアーキテクチャの図を参照してください。

監査の書き込みエントリは、フィールドがあらかじめ定義されているスキーマに従います。詳しくはこのスキーマの詳細な仕様 (英語)をご覧ください。こちら (英語)からもダウンロードできます。

監査ログは Azure ストレージ アカウントに直接書き込まれるため、このデータへのアクセスは完全にコントロールできます。ログを閲覧するには、Azure Storage Explorer (英語)または定義済みの Excel ダッシュボードとレポート テンプレート (英語)などの任意のツールで Azure ストレージ アカウントに接続します。後者は Power Query を使用して Azure ストレージ アカウントからログを取得できます。Office 2013 ユーザーは Power Query for Excel アドインを無料でダウンロードできます。

SQL Database で Auditing をセットアップするには

Azure 管理ポータル (プレビュー) の構成インターフェイス (下図参照) を使用すると、データベースに対して Auditing を簡単に構成できます。

Auditing をセットアップするには Basic、Standard、Premium のいずれかのレベルのデータベースを使用します。

Azure 管理ポータル (プレビュー)で目的のデータベースに移動し、[Enable and setup Auditing] をクリックして Auditing 構成ブレードを起動します。監査ログを保存する Azure ストレージ アカウントを選択し、ログに記録するイベントを指定します。

Auditing の構成が完了したら、データベースに接続する既存のクライアント アプリケーションでセキュリティ対応接続文字列 (Security Enabled Connection Strings) を使用するよう変更します。これでアプリケーションによるデータベース処理がログに記録されるようになります。セキュリティ対応接続文字列はこれまでの接続文字列とは書式が若干異なります。

Auditing のセットアップが完了して稼動し始めたら、Azure ポータルの Auditing ダッシュボードでデータベースの稼働状況をひとめで確認できます。直近 24 時間の監査対象データベース イベントが表示されます (最短で 15 分おきに更新)。イベントの種類別に表示されるので、データベースで発生しているイベントの分布がわかり、異常または予期しない動きをすぐに把握できます。

複数の SQL Database に一括で Auditing をセットアップするには

単一の Auditing ポリシーを 1 台のデータベース サーバー上のすべてのデータベースに適用することができます。そのためには、そのサーバーの既定のポリシーを指定します。

ポリシーを作成するには、サーバー上のいずれかのデータベースに Auditing を設定後、[SAVE AS DEFAULT] をクリックします。これで、同じ設定がデータベース サーバー上のすべてのデータベースに自動的に適用されます (データベース サーバーに Auditing の構成が明示的に定義されていないことが条件)。以下のスクリーンショットをご参照ください。

近日中に、データベース サーバー コンテキストからもサーバー上の全データベースに対して既定の設定を作成できるようになる予定です。

データベースでの活動に関するデータを分析するには

任意のアプリケーションを使用して監査ログを分析できます。監査記録を Azure Storage から CSV 形式 (他のファイル形式も利用可能) でエクスポートしてください。

すぐに使える分析ツールとして、インタラクティブな Excel テンプレートと定義済みのダッシュボードおよびレポート (英語)も用意されています。Power Query for Excel アドインを使用すれば、監査ログ データを Azure Storage から直接取得できます。レポートにはストレージ アカウントから読み込んだ監査ログに記録されているデータベースの活動内容が自動的に表示されます。レポート テンプレートを監査ログが保存されている Storage にアタッチする方法や、ビルトインの分析テンプレートの使用法については、Excel テンプレート (英語) に関するこちらの資料 (英語) をご参照ください。

複数のデータベースを監査している (そしてログを同じストレージ アカウントに保存している) 場合は、ビルトイン レポートで活動やトレンドをデータベース間で比較し、異常を発見できます。インタラクティブなレポートなので、Power View や PowerPivot でデータを視覚化し、データベース、イベントの種類、時間枠などでビューを切り分けることができます。また、カスタマイズや拡張も可能なので、自社の要件に沿ったレポートやビューを作成できます。レポートのサンプルをご覧ください。

まとめ

Auditing はイベントやデータベースの活動を追跡、記録する Azure SQL Database のセキュリティ レイヤーを提供します。監査データを利用してデータベースの活動を的確に把握し、セキュリティを脅かす可能性のある問題を突き止め、セキュリティ違反が疑われる処理を記録し、コンプライアンス関連の作業を円滑に進めることができます。

さらに詳しい内容については、「SQL Database Auditing の使用を開始する (英語)」や、Eyal と Scott が Auditing のメリットや容易なセットアップ方法を紹介する Channel 9 のビデオ (英語)をご覧ください。Auditing 機能はすぐに使用を開始できます。Basic、Standard、Premium レベルのデータベース (まだお持ちでない方は、新しいサービス レベルのプレビュー版にサインアップしてください) を使用します。また、Auditing プレビュー版へのサインアップが必要です。データベースに対する Auditing の構成は Azure 管理ポータル (プレビュー)で行います。

マイクロソフトは皆様の声に耳を傾けています。ぜひお試しになった感想をお聞かせください!

このポストは、8 月 27 日に投稿した Azure Automation: Authenticating to Azure using Azure Active Directoryの翻訳です。

Cloud services の稼動状態を維持させるためのタスクの中には、手動での操作が必要な作業、実行時間が長い作業、繰り返し実行する必要がある作業、ミスが発生しやすい作業などがあります。Azure Automationをご利用のお客様は、こうした作業を自動化することが非常に便利であることを既にご存知かと思います。また、証明書ベースの認証を使用して Azure に接続できるように Azure Automation をセットアップする (英語)には、多くの手順を踏む必要があることもご存知のはずです。Azure Automation チームと Azure PowerShell チームはこのたび、Azure への Azure Automation の認証に、Azure Active Directory を使用した組織 ID ベースの認証を使用できるようにしました。この機能により、Azure Automation をこれまで以上に手軽にご利用いただけるようになりました。

Azure Active Directory による認証を使用して管理できるように Azure を構成する

現在、Azure Automation には Azure PowerShell モジュールのバージョン 0.8.6 が同梱されています。このバージョンでは、手動での操作を行わなくても組織 ID (Azure Active Directory ユーザー) の証明書ベースの認証を使用して Azure への認証を行うことができます。この認証タイプを使用して Azure に接続するように Azure Automation をセットアップするには、下記の手順を実行します。

Azure Active Directory ユーザーを作成する

既に Azure Active Directory ユーザーを作成済みで、この組織 ID を Azure の管理に使用する予定である場合は、この手順は省略できます。

1. Azure Automation を使用して管理したい Azure サブスクリプションのサービス管理者として Azure ポータルにログインします。

2. Azure ポータルで、[ACTIVE DIRECTORY] をクリックします。

3. 事前に作成したディレクトリの名前をクリックします。ディレクトリをまだ作成していない場合は、ここで作成します。

4. [USERS] タブに移動して [ADD USER] ボタンをクリックします。

5. [TYPE OF USER] で「New user in your organization」を選択し、作成するユーザーの名前を入力します。

6. ユーザーのプロファイルを入力します。[ROLE] には「User」を選択します。[MULTI-FACTOR AUTHENTICATION] のチェックはオフにします。

7. [create] をクリックします。

8. 完全なユーザー名 (@ 記号以降の部分も含む) と一時パスワードをメモします。

指定した Azure Active Directory ユーザーにこの Azure サブスクリプションの管理を許可する

1. [Azure] タブの一番下の [STORSIMPLE] の下にある [SETTINGS] をクリックします。

2. [ADMINISTRATORS] をクリックします。

3. [ADD] ボタンをクリックします。Azure の管理用にセ���トアップする Azure Active Directory のユーザー名を完全な形 (@ 記号以降の部分を含む) で入力します。サブスクリプションの場合は、このユーザーに管理させたい Azure サブスクリプションのチェック マークをオンにします。

Azure Active Directory ユーザーのパスワードを一時パスワードから変更する

1. Azure からログアウトします。

2. 完全なユーザー名 (@ 記号以降の部分も含む) と一時パスワードを使用して、上記の手順で作成した Azure Active Directory ユーザーとして Azure にログインします。

3. すると、パスワードの変更を促すメッセージが表示されるので、パスワードを変更します。

指定した Azure Active Directory ユーザーがこの Azure サブスクリプションの管理を行うようにAzure Automation を構成する

1. 上記の手順で作成した Azure Active Directory ユーザーのユーザー名とパスワードを含む Azure Automation 資格情報を作成します。

Azure Automation の Runbook で Azure を管理する

Azure と Azure Automation で Azure Active Directory の認証情報のセットアップが完了したら、その後はこの認証情報を使用して Azure Automation の Runbook から Azure を管理できるようになります。次のサンプルの Runbook は、Azure Active Directory の認証情報を前述の Automation 資格情報から取得し、Azure サブスクリプション内のすべての Virtual Machines で表示できるようにするものです。

この Runbook を使用する場合は、Select-AzureSubscription の SubscriptionName パラメーターに管理する Azure サブスクリプションの名前を入力します。このとき、Azure Active Directory ユーザーがこのサブスクリプションへの管理者アクセスを付与されていることを確認します (この手順は前述のとおりです)。

これで、Azure ポータルの [SETTINGS] タブで Azure サブスクリプションの名前が表示されます。

上記のサンプルの Runbook は、こちらのスクリプト センターのページ (英語)からダウンロードできます。

Azure Automation から Azure への認証に管理証明書 (英語)を使用する従来の方法は、Connect-Azure (英語) Runbook で引き続きご利用いただけます。ただし、この Runbook はサポートの終了が予定されているため、代わりに Azure Active Directory を使用した組織 ID の証明書ベースの認証方法をご利用ください。

まとめ

ここでは、Azure Active Directory の組織 ID ユーザーと Azure Automation を使用して Azure サービスを管理するための設定についてご説明しました。これを利用すると、作成した Runbook をセットアップして実行し、クラウド サービスの管理をさらに簡単に自動化できるようになります。今回の更新の一環として、この認証に使用する Azure Automation のサンプル Runbook とユーティリティ Runbookをすべて更新しました。セットアップの際に役立つだけでなく、既存の Runbook ギャラリーのコンテンツを活用する際にもご活用いただけます。

この記事を参考に、Azure Active Directory を使用して自動化を進めていただけますと幸いです。次回の記事にもご期待ください。

Azure Automation をまだご利用でないお客様は、プレビューにサインアップ (英語)しお試しください。また入門ガイドもご覧ください。

このポストは、8 月 27 日に投稿した How to plan your migration to Azure Websitesの翻訳です。

クラウド プラットフォームへの移行は、非常に手間がかかる場合があります。Azure WebSites をホスティング ソリューションとして使用する場合には重要な考慮事項がいくつかありますが、この記事では、Azure WebSites に移行する場合に知っておく必要のあるプラットフォーム関連の知識について説明します。

1. 世界中で利用可能

Azure WebSites は、世界中に存在する複数のデータ センターで利用できます。このため、お客様と関係の深い地域の市場ニーズに Web サイトを最適化できます。サポート対象のリージョンのリストはこちらのページでご覧いただけます。

2. 負荷分散機能が組み込み済み

IaaS を基盤とするソリューションで Web サイトをセットアップする場合、Ngnix (英語)などのソリューションを使用して負荷分散機能をセットアップする必要があります。Azure WebSites では、Azure Traffic Manager を使用すると複数リージョン間で負荷分散機能を実現できるため、複数の Virtual Machines にまたがる Azure WebSites の負荷分散機能をセットアップする必要はありません。ただし、Azure WebSites の Free レベルをご利用の方はこの負荷分散機能は使用できませんのでご注意ください。

それ以外のレベルをご利用の方は、Azure WebSites の負荷分散機能を自分で構築する必要はありません。

3. Web サーバーを使用

Azure WebSites では、Windows を基盤とするインフラストラクチャ上で、Web サーバーとして IIS を実行しています。この IIS サーバーでは .NET、PHP、Node.js、Python、Javaの各フレームワークを使用できます。また、Azure WebSites ではセキュリティ、診断、パフォーマンスのそれぞれにおいて IIS の全機能を活用しています。IIS の詳細については、こちらのページ (英語)を参照してください。

4. SLA について

Azure WebSites で構築されたどのアプリケーションも、ホスティング サービスの稼働率が 100% であることは保障されません。Azure WebSites の SLA (英語)には、Azure WebSites はお客様の Web サイトで月間 99.9% の可用性を提供することが記載されています。この文書をお読みになり、内容をご確認ください。

データベース、Azure Storage、CDN サービス、YouTube サービスなど、お客様のアプリケーションと緩やかに、または緊密に連携している Azure の他のサービスや Azure 以外のサービスをご利用の場合、それらのサービスの SLA も確認してください。

月間 99.9% よりも高い可用性をお望みのお客様は、障害が発生する可能性のあるコンポーネントに留意し、Azure WebSites のフェールオーバーや障害復旧の管理方法を理解しておくことをお勧めします。

5. 料金レベルと機能

Azure WebSites には、Free、Shared (プレビュー)、Basic、Standardの 4 つの料金レベルがあります。

• Shared (プレビュー): プレビュー期間中は、WebSites インスタンス 1 つにつき 1 時間あたり 0.013 ドルでご利用いただけます (最大 10 ドル/月)。この料金には、33% のプレビュー期間割引が適用されています。
• Basicおよび Standard: 複数のインスタンス サイズが用意されているだけでなく、必要な容量の変化に合わせてスケーリングが可能ですす。Basic レベルは 56 ドル (S サイズのインスタンス 1 つ)、Standard レベルは 75 ドル (S サイズのインスタンス 1 つ) からご利用いただけます。

料金レベルと機能の詳細については、こちらのページをご覧ください。

6. Azure WebSites をホストしている Virtual Machines へのアクセスは不可能

Azure WebSites ではアプリケーションをホストするインフラストラクチャを提供しますが、お客様が Virtual Machines に実際に接続してアクセスすることはできません。このため、Virtual Machines に何らかのソフトウェアをインストールすることはできません。アプリケーションは物理デバイス上ではなく Virtual Machines 上に存在しており、スケール アップやスケール ダウンでき、Virtual Machines で障害が発生した場合は置換が可能です。

以上の理由により、このような環境で動作するアプリケーションは必ずステートレスになります。

7. オートスケール機能

オートスケール機能は Standard レベルでご利用いただけます。手動操作を行うことなく Azure WebSites のスケーリングができるので、コスト効率が向上します。オートスケール機能は、サイトへの受信トラフィックがユーザー指定の範囲に収まるように適切なスケールを自動的に選択します。このため、Azure WebSites のインスタンス数を手動で増減する必要はありません。詳細については、オートスケールの構成方法 (英語)を参照してください。

8. ファイル サーバーはすべてのインスタンスで共有可能

ファイル サーバーは、Azure WebSites が使用するすべてのインスタンスで共有されます。複数のインスタンスを使用する場合、何らかのセッション データをキャッシュして特定のコンピューターに格納すると一部のインスタンスはこのデータにアクセスできなくなるというわけではありません。

アプリケーションの使用目的に応じて、Azure WebSites が実行されている Virtual Machines すべてでデータの整合性を保つ必要がある場合は、永続ストレージを使用します。その必要がない場合は、Virtual Machines インスタンスの一時フォルダーにデータを保存できます。

9. キャッシュ機能

Azure WebSites では、PHP アプリケーション用の WinCache (英語)および IIS サーバー レベルのキャッシュ機能 (出力のキャッシュ) をご利用いただけます。WinCache は対応している PHP アプリケーションで使用可能です。また、サーバー レベルのキャッシュ機能は IIS でホストされているあらゆるアプリケーションで使用可能です。

ほとんどの場合はこれらの機能で十分ですが、さらに高度なキャッシュ機能が必要な場合は、下記のいずれかを使用します。

• Azure Redis Cache プレビュー (英語)
• Azure マネージ キャッシュ
• Azure Virtual Machines (独自のキャッシュ クラスターを構築する)

10. ステージング環境へのデプロイメントおよび発行

Azure WebSites の Standard レベルで実行されているサイトでは、SiteSlotsを使用するとステージング環境へのデプロイメントや発行が可能です。この機能では、それぞれの初期状態の運用環境の Azure WebSites (これが運用環境のスロットになります) に合わせて開発環境またはステージング環境の Site Slots を作成し、このスロットをダウン タイムを発生させずにスワップすることができます。詳細については、構成手順と Site Slots にデプロイする方法を参照してください。

11. SSL

サイト訪問者が HTTPS を使用して Web サイトにアクセスする場合、Web サイトとブラウザーの間の通信は Secure Socket Layer (SSL) による暗号化機能でセキュリティが確保されます。これは、インターネットでデータ通信のセキュリティを確保する場合に最も一般的に使用されている方法で、訪問者と Web サイトとの間のトランザクションの安全性を保証します。Azure WebSites で HTTPS を有効化する方法についての詳細は、SSL の構成方法を参照してください。

12. カスタム ドメイン

Microsoft Azure WebSites では、Web サイトを作成するときに、azurewebsites.net というドメインの下にユーザーが理解しやすいサブドメインを追加した形の URL (http://<サイト名>.azurewebsites.net) が付与されます。また、お客様の Web サイトを contoso.com などのカスタム ドメイン名に関連付けて、ユーザーに対してよりわかりやすいドメイン名を使用することもできます。詳細については、Azure WebSites でカスタム ドメイン名を追加する方法を参照してください。

13. WebJob (プレビュー) を利用したバックグラウンド プロセス

Microsoft Azure WebSites では、オンデマンド、常時実行、スケジュール設定のいずれかの方法でプログラムやスクリプトをお客様の Azure WebSites で実行できます。Always On 機能を使用しない場合、Microsoft Azure WebJob は無料でご利用いただけます。詳細については、Azure WebSites で WebJob を作成する方法を参照してください。

14. 自動復旧機能

Azure WebSites でこの機能を有効にすると、特定の条件を自動的に検知し復旧を支援します。“Always On” 機能の一部として機能強化が実施され、Web アプリケーションをホストしている Worker ロールのプロセス (仮想マシン インスタンス) が自動的に再起動されるようになりました。詳細については、自動復旧機能を有効化する方法を参照してください。

15. バックアップと復元

Azure WebSites のバックアップおよび復元機能を使用すると、Azure WebSites のバックアップを手動と自動のいずれでも簡単に作成できます。この機能では、Azure WebSites を以前の状態に復元したり、お客様が所有するいずれかの Azure WebSites のバックアップから新しい Azure WebSites を作成したりできます。

バックアップから Azure WebSites を復元する方法の詳細については、Azure WebSites の復元方法を参照してください。バックアップの構成の詳細については、Azure WebSites のバックアップ方法を参照してください。

16. SMTP で SendGrid サ���ビスを使用

Azure WebSites では、SMTP は既定で無効に設定されています。Web アプリケーションで電子メール サービスを使用する必要がある場合、SendGrid サービスを購入します。このサービスでは、こちらのページ (英語)で紹介されているように、無料のプラン (1 か月あたり 2,500 通の電子メールを利用可能) から高機能なプランまでお選びいただけます。詳細については SendGrid の構成方法を参照してください。

Azure WebSites の利用を開始するためのチェックリスト

• データ センター (Azure WebSites をホストする場所) を決定する。
• Azure WebSites のホスティング プランを理解する。すべての Azure WebSites で同じホスティング プランを使用する場合と、アプリケーションによって運用環境のサイトとステージング環境のサイトを使い分ける場合があります。
• ニーズに合ったデプロイメント ソリューションを選択する。Git (英語)、Web Deploy (英語)、Bitbucket、DropBox、Github (英語)などの既成のソリューションのほか、Git や Web Deploy の API を使用して構築したカスタム ソリューションを使用できます。
• キャッシュやデータベースなど、アプリケーションが使用する依存コンポーネントをすべてセットアップする (必要な場合)。
• Web アプリケーションの開発およびテスト用の Azure WebSites をセットアップする。次のいずれかの方法を選択します。
  • Site Slots を使用する。
  • 開発用サイトの要件に応じて個別に Azure WebSites を作成する。たとえば、開発用アプリケーションが使用するデータベースや Azure WebSites のモード、ホスティング プランが異なる場合は、この方法を使用します。
• Web アプリケーション用のステージング環境の Azure WebSites をセットアップする。次のいずれかの方法を選択します。
  • Site Slots を使用する。
  • 開発用サイトの要件に応じて個別に Azure WebSites を作成する。たとえば、開発用アプリケーションが使用するデータベースや Azure WebSites のモード、ホスティング プランが開発用サイトで異なる場合は、この方法を使用します。
• 運用環境の Web アプリケーションをセットアップする。投資を最大限に活用するために、Web アプリケーションは Basic レベルまたは Standard レベルで運用することをお勧めします。Web サーバーのログを Azure Storage に記録するように設定して、運用環境、ステージング環境、および開発環境の各サイトでアプリケーションに不具合が発生したときにデバッグできるようにします。
• 本番環境のサイトのカスタム ドメインをセットアップする。
• アプリケーションが画像や動画などのメディア コンテンツを多用する場合、Azure Storage などの他のサービスを使用してメディア コンテンツをホストします。動画のストリーミングには Azure Media Services (.NET アプリケーションの場合) や、サードパーティーの YouTube (PHP/Python/Node.js/Java の各種アプリケーションの場合) などのサービスを使用します。
• 開発環境、ステージング環境、運用環境のすべてのサイトで SSL をセットアップする (アプリケーションで必要な場合)。
• すべての Azure WebSites で自動復旧機能をセットアップする。
• 自動バックアップ機能をセットアップする。マイクロソフトのバックアップ機能を使用するか、WebJob や Azure VM を使用した自社製のソリューションを構築して、バックアップの Web サービス プロセスをホストします。
• 運用環境のサイトでオートスケールをセットアップする。開発環境およびステージング環境のサイトではコスト効率を考慮する必要はありませんが、スケールやパフォーマンスのテストを実施しているときに有効化することが可能です。

まとめ

Azure WebSites にはコスト効率の高さ、スケーラビリティ、フォールト トレランスという特長がありますが、このようなメリットを活用するには、アーキテクチャや設計について数多くの事項を検討する必要があります。このドキュメントでは、Azure WebSites が提供するプラットフォームのベスト プラクティスと主な特長についてご説明しました。デプロイメントの際や運用の省力化にご活用ください。

このポストは、8 月 21 日に投稿した Advanced Encoding Features in Azure Media Encoderの翻訳です。

Azure Media Encoder では、既定のプリセットによって利用可能な機能以外にも、高度なビデオおよびオーディオ処理を実行できる多数の機能が提供されています。今回の記事では、高度なサンプルの数々やポータル エクスペリエンスの後ろに隠れている Azure Media Encoder の優れた機能の一部をご紹介します。今回取り上げたシナリオでは、メールやフォーラムからお問い合わせをいただいた中で特に多かったものを選びました。

カスタム プリセット

初めて利用するユーザーがわかりにくいと感じる機能の 1 つに、カスタム プリセットの定義と送信があります。私たちが提供しているエンコーダーには既に幅広い種類の定義済みのシステム プリセットがあり、詳細情報は MSDN にまとめられています。また、特定のデバイスへの配信にどのプリセットを使用すればよいかを記載したガイダンス ページもあります。

エンコーダーのすべての機能と設定は、XML プリセット ファイル形式を利用して完全に構成することもできます。これにより、特定の用途のシナリオで必要となる設定やパフォーマンスを構成できます。XML プリセット ファイル形式の完全なスキーマについては、Media Services Encoder の構成スキーマのページを参照してください。さらに、カスタム変更を加えるための「ベスト プラクティス」のたたき台を利用できるように、すべてのシステム定義のプリセットの完全な XML も提供されています。たとえば、こちらのリンクでは H264 Adaptive Bitrate MP4 Set 720P の完全な XML をご覧になれます。

プリセット スキーマの構造は非常にシンプルです。すべての XML は <Presets> 要素から始まり、その中に 1 つ以上の <Preset> 定義を含めることができます。これは、単一のエンコード タスクに対して複数の出力やエンコード設定を定義する場合に非常に便利です。たとえば、1 つのエンコード ジョブで複数のオーディオ プロファイルに出力する必要がある場合があります。その良い例として、ステレオ AAC とサラウンド サウンド用の Dolby DD+ 形式 (英語)の両方をエンコードする場合などが挙げられます。

プリセット XML の最も基本的な構造は次のようになります。エンコーダーのプロセッサに主要な変更が加えられた際にはバージョンの改訂が行われるため、プリセットにもバージョン文字列を含めています。

<?xml version="1.0" encoding="utf-16"?>
<Presets version=”5.0”>
  <Preset>
    <MediaFile>
      <OutputFormat>
      </OutputFormat>
    </MediaFile>
  </Preset>
</Presets>

プリセットに新しい出力を追加し、設定を変更するには、<OutputFormat>以下にさまざまな XML 要素を追加します。たとえば、現時点では次の出力形式がサポートされています。

• MP4OutputFormat
• WindowsMediaOutputFormat

上記の各出力形式では、次の 2 つの主要な要素を使用して、オーディオとビデオの両方の詳細な基本ストリーム設定をセットアップできます。

• AudioProfile
• VideoProfile

完全に定義されたオーディオ用カスタム プリセットの簡単な例は次のようになります。この例では、既存のオーディオのみのプリセットからビットレートだけを 96 kbps に変更しています。オーディオの場合、AudioProfile 以下にさまざまなコーデックを追加できます。現時点では、AAC、Dolby、WMV の各プロファイルがサポートされています。詳細については、AudioProfile要素のページをご覧ください。

<?xml version="1.0" encoding="utf-16"?>
<!—My Custom AAC Audio Preset -->
<Presets>
 <Preset
   Version="5.0">
    <MediaFile>
     <OutputFormat>
       <MP4OutputFormat
         StreamCompatibility="Standard">
         <AudioProfile Condition="SourceContainsAudio">
           <AacAudioProfile
             Codec="AAC"
             Channels="2"
             BitsPerSample="16"
             SamplesPerSecond="44100">
             <Bitrate>
               <ConstantBitrate
                 Bitrate="96"
                 IsTwoPass="False"
                 BufferWindow="00:00:00" />
             </Bitrate>
           </AacAudioProfile>
         </AudioProfile>
       </MP4OutputFormat>
     </OutputFormat>
   </MediaFile>
 </Preset>
</Presets>

ビデオ エンコードを行っていて、ジョブの H264 エンコードの詳細設定にアクセスする場合には、<VideoProfile> 要素以下の次の要素を設定することができます。これらの要素ではあらゆるエンコード設定を調整することができ、それによってエンコードに要する時間が非常に短くなることも、非常に長くなることもあります。そのため、編集している内容を十分に理解するようにしてください。

VideoProfile 要素以下の H264 設定で最も一般的に使用されるのは、Basic、Main、High の各プロファイル設定です。

• BaselineH264VideoProfile
• MainH264VideoProfile
• HighH264VideoProfile

上記の各プロファイル設定では、エンコード先の各 <Streams>を指定します。高度なマルチビットレート MP4 エンコード プリセットでは、解像度と出力ビットレートの異なる複数の出力ストリームを定義することができます。

プリセットは、オーディオのみのシンプルなものから、複数の出力 Preset と MediaFile を組み合わせた非常に複雑な「スーパー プリセット」まで、多岐にわたります。ドキュメント化されている複雑なカスタム プリセットの良い例として、こちらの複数のオーディオ トラックへのエンコードを実行する膨大なプリセット ファイルをご覧ください。この非常に複雑なプリセットでは、1 つのジョブ プリセットで 8 つのビデオ ファイルと 5 つの個別のオーディオ エンコード (Dolby DD+ を含む) を出力しています。

定義したカスタム プリセットは、Configuration プロパティに XML を設定して簡単にエンコード タスクに送信することができます。次のサンプル コードでは、configuration 文字列にカスタム プリセット XML を読み込んでから、タスクに使用しています。

string configuration = File.ReadAllText(pathToCustomXMLConfigFile));
ITask task = job.Tasks.AddNew("My Custom Encoding Task",
                encoderProcessor,
                configuration,
                TaskOptions.None);

高度なサムネイル生成

カスタム プリセットの設定を指定するか、サムネイル タスクを使用した完全なスタンドアロンのタスクとして、エンコード中にサムネイルを簡単に作成することができます。Azure Media Encoder には、パーセントや特定の時点または間隔を指定するなど、ビデオからサムネイルを生成するさまざまなオプションが用意されています。

サムネイル タスクでは、ビデオから一連の画像を生成し、Media Services アカウントのアセットに書き込みます。その後、それらのサムネイルを Azure Storage から直接利用することも、発行されたストリーミング コンテンツと共に Media Services のストリーミング サーバーから利用することもできます。

サムネイルを生成するには、スタンドアロンのサムネイル タスクをジョブに送信し、アカウント内のビデオ アセットを指定するか、タスクを連結してまずエンコードしてから、ジョブの後にサムネイルを生成します。
サムネイル タスクを送信する場合、Azure Media Encoder と共に、サムネイルを生成するために必要なすべての情報を指定したカスタム XML ファイルを使用する必要があります。

この XML の最もシンプルな形式は次のようになります。この例では、固定幅、可変の高さ、JPEG 形式とカスタマイズした命名テンプレート、さらに、入力タイムラインの位置に特定のパーセントを指定して、サムネイルを生成する方法を示しています。

<?xml version="1.0" encoding="utf-8"?>
<Thumbnail Size="100%,*" Type="Jpeg" Filename="{OriginalFilename}_{Size}_{ThumbnailTime}_{ThumbnailIndex}_{Date}_{Time}.{DefaultExtension}">
        <Time Value="10%" Step="10%" Stop="90%"/>
</Thumbnail>

Thumbnail 要素である次の属性により、サムネイルの出力サイズと種類の詳細を設定することができます。

• Size – 作成するサムネイルの幅と高さを設定します。パーセントや正確なピクセルの値を指定することも、アスタリスク (*) を使用して元のビデオの縦横比を維持することもできます。
• Type – 出力ファイル形式を設定します。サポートされている値は、JPEG、BMP、GIF、PNG です。

@FileName 属性は、サムネイルの出力命名テンプレートを指定する際に利用可能な一連のマクロを使用します。次のマクロ名がサポートされています。

• OriginalFilename – サムネイル ジョブの生成元の入力ファイル名
• Size – @Size 属性で設定されたサムネイル タスクのサイズ (幅 x 高さ)
• ThumbnailTime – ビデオからサムネイルが抽出された時点
• ThumbnailIndex – サムネイルの絶対インデックス番号
• Date – サムネイルが抽出された短い形式の日付 (DD-MM-YYYY)
• Time – サムネイルが抽出された時間 (HH.MM AM/PM)
• DefaultExtension – 選択された出力形式の @Type に使用されている拡張子。Type=”Jpeg” の場合は、”jpg” に設定されます。

XML の <Time> 要素では、3 つのプロパティによってサムネイルが生成元のビデオから抽出される方法を制御します。@Value 属性はサムネイルの抽出の開始位置を指定します。この例では、ビデオの再生時間の 10% に設定されています。@Step 属性は開始位置の値から先に進む間隔を制御します。終了位置として指定された Stop の限度 (この例では 90%) に達するまで、指定された間隔で取得する動作を繰り返します。パーセント指定の単位を使用することのメリットは、正確なタイム コードを設定したり、ジョブに使用する XML ファイルを作成する前にビデオ全体の再生時間を把握したりする必要がないということです。@Filename 属性で命名テンプレートを作成する場合、Filename プロパティの値にパーセント エンコードの予約文字 (英語)である「!*’();:@&=+$,/?%#[]“」を使用することはできません。また、ファイル名の拡張子には「.」を 1 つしか使用できません。

上記の XML の出力では、次のようにテンプレート設定に基づくファイル名が生成されます。このサンプルはわずか 5 秒のとても短いものだったため、それほど多くのサムネイルが取得されませんでした。

サムネイルを生成する場合のもう 1 つのオプションとして、ビデオから抽出する正確な時点がわかっていれば、「時間:分:秒」の形式で指定したタイム コードを使用して修正した XML を送信することができます。

<?xml version="1.0" encoding="utf-8"?>
<Thumbnail Size="300,*" Type="Jpeg" Filename="{OriginalFilename}_{ThumbnailIndex}.{DefaultExtension}">
  <Time Value="0:0:0" Step="0:0:5" />
</Thumbnail>

上記のサンプルはビデオの最初 (0:0:0) から開始し、ビデオの最後に到達するまで Step の値に指定した 5 秒 (0:0:5) 間隔で新しいサムネイルの取得を続けます。
このテンプレートでは上記と同じ短いビデオを使用したため、インデックス値 ”1” を含む 1 つのサムネイルのみが生成されました。

Media Services API のジョブとしてカスタマイズした XML 設定を送信する方法の詳細とサンプル コードについては、「ビデオのサムネイルの作成」をご覧ください。

ビデオとオーディオのオーバーレイ

エンコーダーでビデオに目に見える透かしを追加することで、画像のオーバーレイを適用して、コンテンツの不正な配布の防止やコンテンツのブランディングを行うことができます。たとえば、テレビ局では番組画面の隅にロゴを配置することにより、コンテンツを特定できるようにしています。また、航空会社では、配信される映画の途中にたびたび航空会社の透かしが表示されます。もちろん、目に見える透かしを追加しても完全にビデオの流用を防ぐことができるわけではありませんが、他者による流用を抑え、所有者を明確に特定するためには役立ちます。配布を防止したり、ビデオへのアクセスを制御したりするために、今後公開されるマイクロソフトの PlayReady コンテンツ保護サービスなどのデジタル著作権管理機能を利用することをお勧めします。

注: 現時点では、Media Services でいわゆる「フォレンジック」透かしは提供されていません。フォレンジック透かしとは、内容に影響しない形でビデオ ストリームに適用される目に見えない透かしのことで、後から検出することでコンテンツを漏えいした人物または所有者を特定することができます。

Azure Media Encoder では、既存のビデオに画像 (*.jpg、*.bmp、*.gif、*.tif、*.png)、ビデオ、オーディオ トラックをオーバーレイすることができます。オーバーレイの設定を使用して、オーバーレイの表示時間、フェード、不透明度、出力ビデオ上の位置を制御できます。

オーバーレイ設定は、エンコード ジョブの XML で制御されます。ビデオ オーバーレイの制御には次の属性を使用できます。

• OverlayFileName – ビデオ オーバーレイを含むファイルの名前。下記の例では、トランスコードする入力ビデオと入力ビデオにオーバーレイするファイルの両方を含む、単一のタスクへの入力アセットを使用します。
• OverlayRect – オーバーレイする長方形の左上の頂点の X/Y 座標、幅と高さ (ピクセル単位)。これらの寸法は、出力エンコード設定ではなく、オーバーレイされるアセットの寸法と相対的なものです。
• OverlayOpacity – ビデオ オーバーレイの透明度。有効な値は 0 ～ 1 で、0 を指定すると完全に透明、1 を指定すると完全に不透明になります。
• OverlayFadeInDuration – ビデオ オーバーレイがフェードインするまでにかかる時間。有効な値は hh:mm:ss:fff 形式の時間です。入力ビデオのタイムラインに収まることを確認してください。
• OverlayFadeOutDuration – ビデオ オーバーレイがフェードアウトするまでにかかる時間。有効な値は hh:mm:ss:fff 形式の時間です。
• OverlayLayoutMode – オーバーレイをタイムラインの全体を通して表示するか、タイムラインの特定の部分にのみ表示するかを指定します。有効な値は次のとおりです。

1. WholeSequence – ビデオ シーケンスの全体を通してオーバーレイを表示します。
2. Custom – OverlayStartTime および OverlayEndTime 属性で指定された範囲でオーバーレイを表示します。

• OverlayStartTime – ビデオ オーバーレイが開始するビデオ タイムライン上の位置。OverlayLayoutMode が ”Custom” に設定されている場合にのみ使用されます。有効な値は hh:mm:ss:fff 形式の時間です。入力ビデオのタイムラインに収まることを確認してください。
• OverlayEndTime – ビデオ オーバーレイが終了するビデオ タイムライン上の位置。OverlayLayoutMode が ”Custom” に設定されている場合にのみ使用されます。有効な値は hh:mm:ss:fff 形式の時間です。入力ビデオのタイムラインに収まることを確認してください。
• 例として、Azure Media Services アカウントのビデオ ファイルにこのシンプルなアイコンをオーバーレイします。

Media.png – こちらのページからソースをダウンロード。そのためには、まずこの画像をオーバーレイされるビデオと共に Media Services アカウントにアップロードする必要があります。あるいは、この画像をスタンドアロン アセットにアップロードすることもできます。これは、複数のジョブで再利用する場合に便利な方法です。

Azure Media Services.MP4 – こちらのページからソースをダウンロード。
両方のファイルを同じアセットにアップロードしたら、次にオーバーレイのカスタムのエンコード ジョブを作成します。ここでは、“H264 Broadband” MP4 エンコード システム プリセットを基にエンコード XML を作成します。
次の例では、このプリセットの XML 全体を表示する代わりに、このオーバーレイ ジョブを送信するために編集および変更する必要のある箇所のみを表示しています。

Ÿここでは、プリセットの <MediaFile> 要素に次の属性を追加して、送信するために XML ファイルを保存しました。@OverlayFileName 属性には、ビデオと共にアップロードした “Media.png” の画像を指定しています。

 <MediaFile
     ...
     OverlayFileName="Media.png"
     OverlayRect="200, 100, 40, 40"
     OverlayOpacity="0.9"
     OverlayFadeInDuration="00:00:02"
     OverlayFadeOutDuration="00:00:02"
     OverlayLayoutMode="Custom"
     OverlayStartTime="00:00:05"
     OverlayEndTime="00:00:20">

プリセット XML に上記の修正を加えてジョブを送信すると、作成されたビデオでは、Media Services のロゴが開始 5 秒の時点でフェードインし、15 秒間画面に表示され、20 秒の時点でフェードアウトします。

不透明度は 90% に設定されているため、ビデオ画面が透けて見えます。@OverlayRect は画像の位置を制御しています。@OverlayRect には、オーバーレイする長方形の左上の頂点の X/Y 座標、その後に完成版の画像の幅と高さをピクセル単位で指定しています。

この値を調整する場合、オーバーレイされるビデオの寸法に収まることを確認してください。収まらない場合、エラー メッセージが返されます。同様に、StartTime および EndTime に使用する時間もオーバーレイされるビデオのタイムラインに収める必要があります (この属性ではパーセント指定はサポートされていません)。

このサンプルをビデオとして構成して再生すると、次のように表示されます。出力されたビデオ ファイルはこちらのページからダウンロードして再生できます。

ビデオ オーバーレイの他に、オーディオ オーバーレイもサポートされています。オーディオ オーバーレイでは、サポートされている任意のオーディオ ファイル形式を使用して、ビデオにフェードインおよびフェードアウトさせることができます。これは、ボイスオーバーや音楽を追加する場合に便利です。上記の例と同様の方法で、MediaElement に次の属性を使用することでオーディオ オーバーレイ機能を制御できます。オーディオ オーバーレイの制御に使用できる属性は次のとおりです。

• ŸAudioOverlayFileName – オーバーレイするオーディオを含むファイルの名前。ジョブの入力アセットを指定するためには、個別のファイル名を使用することも、%n% 形式のゼロベース インデックスを使用することもできます。
• ŸAudioOverlayLoop – オーディオ オーバーレイをループさせるかどうかを指定します。有効な値は True または False です。
• ŸAudioOVerlayLoopingGap – オーディオ オーバーレイが終了してから再度開始するまでの時間。有効な値は hh:mm:ss:fff 形式の時間です。
• ŸAudioOverlayLayoutMode – エンコードしたビデオ ストリームのどの部分でオーディオ オーバーレイを再生するかを表します。有効な値は “WholeSequence” または “Custom” です。“WholeSequence” を指定するとストリームの全体を通してオーディオ オーバーレイを再生します。“Custom” を指定すると AudioOverlayStartTime および AudioOverlayEndTime 属性で指定された範囲でオーディオ オーバーレイを再生します。
• ŸAudioOverlayStartTime – オーディオ オーバーレイが開始するビデオ タイムライン上の位置。有効な値は hh:mm:ss:fff 形式の時間です。入力ビデオのタイムラインに収まることを確認してください。
• ŸAudioOverlayEndTime – オーバーレイが終了するビデオ タイムライン上の位置。有効な値は hh:mm:ss:fff です。入力ビデオのタイムラインに収まることを確認してください。
• ŸAudoOverlayGainLevel – オーディオ オーバーレイのゲイン レベル。有効な値は 1 ～ 10 (0.1 単位) です。
• ŸAudioOverlayFadeInDuration – オーディオ オーバーレイがフェードインするまでにかかる時間。有効な値は hh:mm:ss:fff です。
• ŸAudioOverlayFadeOutDuration – オーディオ オーバーレイがフェードアウトするまでにかかる時間。有効な値は hh:mm:ss:fff です。

オーディオ オーバーレイのファイル名の設定方法は、ビデオ オーバーレイの場合と同様です。単一のアセットを使用して、そのアセットに含まれる特定のオーディオ ファイルを指定することも、エンコード ジョブのソースとして複数のアセットを送信して、%n% ベースの構文でファイル名を設定することもできます。

API の詳細とオーバーレイを含むエンコード用のジョブの送信方法については、「オーバーレイの作成」をご覧ください。

ビデオのトリミング

ビデオ���ら数ピクセルを切り取ったり (スキャンした線の除去)、別の理由でビデオの一部を抽出したりする必要がある場合、カスタム プリセットの単一の設定によって簡単にこれを実行することができます。
MediaElement の @CropRect 属性を設定することで、ビデオをトリミングできます。

• ŸCropRect – 入力ビデオのトリミングに使用する長方形を指定します。有効な値は、トリミングする長方形の左上の頂点の X/Y 座標、幅と高さです (ピクセル単位)。これらの座標は入力ビデオに適用されるため、この長方形を設定する場合には元のビデオの寸法を考慮する必要があります。

たとえば、ビデオから 150 x 150 ピクセルの長方形をトリミングする場合は、次の属性の設定を使用します。

   <MediaFile CropRect="0,0,150,150"/>

トリミングした長方形に合うように、完成後のエンコードのサイズを適切な高さと幅に設定する必要があります。値が不適切な場合、ビデオが奇妙に変形する可能性があります (もちろん、その効果を意図したのであればかまいません)。

ビデオのサブクリップ

多くの場面で、既存のビデオまたはオーディオ アセットの一部をクリップやハイライトとして切り取る必要があります。これを実行するために、Azure Media Encoder ではサブクリップ機能をサポートしています。

カスタム プリセットに <Clips> 要素とクリップの一覧を追加して、ビデオから抽出する各クリップの開始時間と終了時間を設定します。その結果、複数のクリップが合成された出力アセットが作成されます。
たとえば、既存のプリセットの <MediaFile> 要素内に次のスニペットを追加することで、ビデオの最初の 30 秒間をクリップとして抽出することができます。これは XML の抜粋であるため、システム プリセットまたは完全なカスタム プリセットのいずれかに組み込む必要があることに注意してください。

     <Sources>
       <Source>
        <Clips>
          <Clip
            StartTime="00:04:00"
            EndTime="00:04:30" />
        </Clips>
      </Source>
      </Sources>

ビデオのサブクリップの方法を示すために、ビデオのどの時点からクリップを切り取ったかをはっきりと確認できる次のタイム コード付きのクリップを使用します。クリップは 00:58:00;00 の時点から開始し、1 時間の表示を超えて、約 11 分間カウントを続けます。

Timecode.wmv– このクリップはこちらのリンクからダウンロードできます。

上記のカスタム プリセットでは、<Source>、<Clips>、単一の <Clip> 要素を追加し、開始時間と終了時間をそれぞれ 00:04:00 と 00:04:30 に設定してビデオから 30 秒間のクリップを切り取っています。抽出されたクリップでは、ビデオに埋め込まれたタイム コードが 1:00:02:00 から開始されるはずです。

このカスタマイズしたプリセットと共にエンコード ジョブを Azure Media Encoder に送信すると、アセットが 30 秒間にクリップされます。出力アセットの MP4 はこちらのページからダウンロードできます。

ビデオの合成

場合によっては、2 つ以上のビデオを合成して長いビデオを作成する必要があります。これは、マーケティング用ビデオを作成したり、ビデオに広告 (「バンパー」) を追加したりする場合に該当します。また、この機能を使用して複数の短いビデオを結合して 1 つの長いクリップを作成することもできます。合成するビデオの開始時間と終了時間を変更したり、それぞれ異なる Media Services アカウントのアセットを使用したりできるため、既存のアセットから新しいビデオにバンパー広告や予告編などを簡単に追加できます。

Azure Media Services でビデオを合成するには、カスタム プリセットの <MediaFile> 要素内に <Sources> 要素と <Source> 要素を追加します。エンコード タスクの入力にはアセットのコレクションを指定できます。

2 つのクリップを合成する簡単な例は次のようになります。この例では、2 つの <Source> 要素を使用しています。1 つ目の <Source> は 1 つ目の入力アセットを表しています。2 つ目の <Source> は、@MediaFile 属性を “%1%” に設定することで、2 つ目の入力アセットとして識別されます。この構文により、入力アセットのゼロベース インデックスから 2 つ目のファイルが取得されます。

   <MediaFile>
     <Sources>
      <Source
        AudioStreamIndex="0">
      </Source>
      <Source
        AudioStreamIndex="0"
        MediaFile="%1%">
      </Source>
     </Sources>

次に、2 つの異なる入力アセットを 1 つのクリップに合成するプリセットを示した、より高度な例をご紹介します。このサンプルの XML では、<Sources> 要素を使用して複数の入力 <Source> ファイルを定義する方法と、エンコーダーのサブクリップ機能を使用して、<Clip> 要素によって合成元の各クリップの開始時間と終了時間を設定する方法を示しています。

まず、各ファイルを個別のアセットとしてアップロードします。その結果、ジョブの入力の一部として 2 つのアセットを送信してから、<Source> 要素の @MediaFile 属性の %n% 命名規則を使用した入力アセット配列のインデックスにより、各アセットを参照することができます。
ゼロベースのインデックス位置では、入力アセットに “%0%” を使用することはできません。1 つ目の入力アセットにアクセスするには、@MediaFile 属性を省略します。
繰り返しになりますが、下記の XML スニペットは部分的なものであるため、完全なカスタム XML プリセットに組み込む必要があることに注意してください。上記の「カスタム プリセット」のセクションでご紹介したシステム プリセットのいずれかを基にして、変更を加えることをお勧めします。

この合成元のアセットは、次のリンクからダウンロードできます。

• ŸAzure_Media_Services.mp4 をダウンロード
• ŸTimecode.wmv をダウンロード

XML スニペット (完全なプリセットの XML に追加してください)

<MediaFile>  …
    <Sources>
      <Source
        AudioStreamIndex="0">
        <Clips>
          <Clip
            StartTime="00:00:30"
            EndTime="00:00:41" />
        </Clips>
      </Source>
      <Source
        AudioStreamIndex="0"
        MediaFile="%1%">
        <Clips>
          <Clip
            StartTime="00:00:00"
            EndTime="00:00:10" />
        </Clips>
      </Source>
      <Source
        AudioStreamIndex="0">
        <Clips>
          <Clip
            StartTime="00:2:50"
            EndTime="00:02:58" />
        </Clips>
      </Source>
     </Sources>
</MediaFile>

ジョブを送信すると、完成したエンコード済みのアセットでは、ビデオの 3 つのセクションが結合されて 1 つのアセットとなります。このジョブの出力を確認するには、こちらのページから完成した MP4 をダウンロードしてください。

API の使用方法の詳細については、「ビデオのセグメントの結合」をご覧ください。

出力ファイル名のカスタマイズ

多くの場合、出力ファイル名を詳細に制御する必要があります。Azure Media Encoder では、出力ファイル名を制御できる一連のマクロと命名規則が提供されています。<Preset> 要素に @DefaultMediaOutputFileName 属性を設定することで、カスタマイズした命名テンプレートを指定できます。

たとえば、次のカスタム プリセットでは、マクロとカスタムの命名設定を組み合わせて命名テンプレートを制御する方法を示しています。

<Preset Version="5.0" DefaultMediaOutputFileName="{Original File Name}{Video Codec}{Video Bitrate}{Audio Codec}{Audio Bitrate}.{Default Extension}">
<MediaFile …>

複数のマクロを追加した場合、各マクロの間にアンダースコアが挿入されます。たとえば、上記の構成では、MyVideo_H264_4500kpbs_AAC_128kbps.mp4 のようなファイル名が生成されます。

サポートされているマクロは次のとおりです。

• {Original File Name}
• {Audio Bitrate}
• {Audio Codec}
• {Channel Count}
• {Default Extension}
• {Language}
• {StreamId}
• {Video Codec}
• {Video Bitrate}

API の詳細については、「Media Service Encoder の出力ファイル名の制御 (英語)」をご覧ください。

音声を含むオーディオ ファイル

主に音声を含む (音楽や効果音がほとんど使用されていない) コンテンツをエンコードする場合、既定のエンコーダー プリセットでは周囲の雑音が増幅されて、オーディオ トラックに不快な音として残る場合があります。
この望ましくない副作用を防ぐためには、プリセットのあまり知られていない設定を無効にする必要があります。その設定は、プリセットの <MediaFile> 要素の @NormalizeAudio 属性です。

既存のシステム プリセットのいずれかをコピーし、@NormalizeAudio 属性を削除するか、次のサンプル XML スニペットのように False を指定して、この設定を調整します (これらの変更例は完全な XML プリセットに追加する必要があります)。

<MediaFile
     DeinterlaceMode="AutoPixelAdaptive"
     ResizeQuality="Super"
     NormalizeAudio="False"
     AudioGainLevel="1"
     VideoResizeMode="Stretch">

音声のみを含むオーディオ ファイルを処理し、API を使用してジョブを送信する方法の詳細については、「ほとんどが話し声であるプレゼンテーションのエンコード」をご覧ください。

MP4 ファイルのキャプションの保持

エンコード元の MP4 ファイルの基本ストリーム内で、H264 でエンコードされたストリームの SEI メッセージに EIA-608 および 708 データとしてキャプションが埋め込まれている場合、これらのキャプションを保持して新しくエンコードされた出力ファイルに渡すことができます。

これを実行するために、プリセットの <MediaFile> 要素の @ClosedCaptionSEIPassThrough 属性の設定が用意されています。この属性を “True” に設定することで、キャプションを保持して出力ファイルに渡すことができます。

これは、クライアントで CEA-608 キャプション データのネイティブ デコードをサポートする iOS などの HLS プロトコル デバイスにキャプションを配信する場合に非常に便利です。

<MediaFile
      WindowsMediaProfileLanguage="en-US"
      VideoResizeMode="Letterbox"
      ClosedCaptionsSEIPassThrough="True">

現時点では、この機能は MP4 ファイル形式のソース ファイルのみをサポートしており、ソース基本ストリームは H264 でエンコードされています。また、このエンコード タスクでは、サブクリップや 2 つ以上のビデオの合成を実行しないでください。

まとめ

今回ご紹介したのは、Azure Media Encoder のお客様のために取り組んできた画期的な高機能のごく一部です。これまで影に隠れていた機能をいくつかご紹介でき、お客様自身のメディア アプリケーションやワークフローで優れたシナリオを実現するうえでお役立ていただけるようであれば幸いです。

エンコードを続ける中で有意義なご意見や機能に関するご要望が出てきましたら、MSDN の Azure Media Servicesフォーラムでぜひお知らせください。