Quantcast
Channel: Microsoft Azure Japan Team Blog (ブログ)
Viewing all 711 articles
Browse latest View live
↧

Mobile Services の .NET サポヌトの䞀般提䟛開始を発衚

$
0
0

このポストは、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の改善) ず、以䞋の蚘事を参照しおください。

↧

Azure Automation: Runbook の入力、出力、および Runbook の入れ子に぀いお

$
0
0

このポストは、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 ぀がありたす。

なお、芪 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 をただご利甚でない方は、プレビュヌ版にサむンアップしお詊しください。たた入門ガむドをご芧ください。

↧
↧

メディア アセットのラむフサむクルの監査 – パヌト 3

$
0
0

このポストは、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テヌブルに蚘録する堎合は泚意しおください。
↧

Azure の新サヌビスず新機胜によりオヌプン性、遞択肢、柔軟性が拡倧

$
0
0

このポストは、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 のブログ (英語)をご芧ください。

↧

Azure Site Recovery を䜿甚しおオンプレミスの仮想化されたワヌクロヌドを Azure に移行

$
0
0

このポストは、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 の新しいテクノロゞを利甚した移行サヌビスをたもなく提䟛開始する予定です。

↧
↧

Azure Backup の玹介

$
0
0

このポストは、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 フォヌラム (英語)でも、さたざたな質問を投皿できたす。

↧

新機胜: Azure Load Balancer のアむドル タむムアりトが構成可胜に

$
0
0

このポストは、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>
↧

Azure WebJob のコマンド ラむン配信たたは継続的デリバリの実行

$
0
0

このポストは、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 開発ずツヌル (英語)に関するブログのコミュニティを曎新しおお知らせする予定ですので、匕き続きご泚目ください。たたご意芋、ご感想がありたしたら、ぜひお知らせください。

↧

Azure SQL Database のサヌビス レベルが新しくなっお 9 月に䞀般提䟛開始、より高床な SLA を䜎䟡栌で提䟛

$
0
0

このポストは、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 レベルでは、最高レベルのパフォヌマンスが提䟛されるほか、高床なビゞネス継続性機胜を利甚できたす。

 

 

Basic

Standard

Premium

SLA で保蚌される皌働率

99.99% にアップ*

デヌタベヌスのサむズ制限

2 GB

250 GB

500 GB

セルフサヌビス型の埩元

7 日間以内の任意のポむント

14 日間以内の任意のポむント

35 日間以内の任意のポむント

障害埩旧

代替の Azure リヌゞョンぞの地理リストア (Geo-restore)

暙準の地理レプリケヌション。セカンダリに匕き継ぎ可胜

アクティブ地理レプリケヌション。最倧 4 ぀の読み取り可胜なセカンダリ

パフォヌマンスの目暙

時間単䜍のトランザクション レヌト

分単䜍のトランザクション レヌト

秒単䜍のトランザクション レヌト

デヌタベヌス スルヌプット ナニット**

Basic: 5

S0: 10

S1: 20

S2: 50

P1: 100

P2: 200

P3: 800

パフォヌマンス レベルおよび月額料金

Basic: 4.99 ドル

S0: 15 ドル

S1: 30 ドル

S2: 75 ドル

P1: 465 ドル

P2: 930 ドル

P3: 3,720 ドル

*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 月に䞀般提䟛される新しいサヌビス レベルのご参考にしおいただくこずをお勧めしたす。今すぐ無料評䟡版をお詊しください。

↧
↧

Azure WebSites で WordPress のトラブルシュヌティングを行う際のヒント

$
0
0

このポストは、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 で 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 のサポヌト (英語)

↧

Microsoft Azure WebJobs SDK の 0.4.0-beta プレビュヌを発衚

$
0
0

このポストは、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 の倉曎が必芁です。

アセット

倉曎前

倉曎埌

パッケヌゞ

Microsoft.Azure.Jobs

Microsoft.Azure.WebJobs

 

Microsoft.Azure.Jobs.Core

Microsoft.Azure.WebJobs.Core

 

Microsoft.Azure.Jobs.ServiceBus

Microsoft.Azure.WebJobs.ServiceBus

名前空間

Microsoft.Azure.Jobs

Microsoft.Azure.WebJobs

ConnectionString 名

AzureJobsStorage

AzureWebJobsStorage

 

AzureJobsDashboard

AzureWebJobsDashboard

 

ダッシュボヌド むンデックス凊理の高速化

すべおの 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 ストレヌゞのその画像を凊理する関数がトリガヌされたす。

関連資料

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」タグをご䜿甚ください。

↧

カスタム スクリプト拡匵 (CustomScript Extension) を䜿甚した Linux VM のカスタマむズ タスクの自動化

$
0
0

このポストは、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 + '“}'
↧

Microsoft Azure ポヌタルのギャラリヌで SQL Server AlwaysOn テンプレヌトを提䟛開始

$
0
0

このポストは、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 テンプレヌトを提䟛開始 (英語)」をご芧ください。

↧
↧

Azure HDInsight で HBase (NoSQL デヌタベヌス) の䞀般提䟛を開始

$
0
0

このポストは、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 のドキュメントや入門ガむドでご確認いただけたす。ぜひご芧ください。

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

↧

VMAccess 拡匵機胜を䜿甚しお Linux VM のログむン資栌情報をリセット

$
0
0

このポストは、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 に該圓するものず刀断され、新しいナヌザヌ アカりントが䜜成されたす。

↧

Azure Mobile Services のノヌド バック゚ンドでの Socket.IO の䜿甚方法

$
0
0

このポストは、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/ (英語)

↧

Azure SQL Database: Auditing でセキュリティを倧幅に匷化

$
0
0

このポストは、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 管理ポヌタル (プレビュヌ)で行いたす。

マむクロ゜フトは皆様の声に耳を傟けおいたす。ぜひお詊しになった感想をお聞かせください!

↧
↧

Azure Automation: Azure Active Directory を䜿甚した Azure の認蚌方法

$
0
0

このポストは、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 をただご利甚でないお客様は、プレビュヌにサむンアップ (英語)しお詊しください。たた入門ガむドもご芧ください。

↧

Azure WebSites ぞの移行蚈画の䜜成

$
0
0

このポストは、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 でホストされおいるあらゆるアプリケヌションで䜿甚可胜です。

ほずんどの堎合はこれらの機胜で十分ですが、さらに高床なキャッシュ機胜が必芁な堎合は、䞋蚘のいずれかを䜿甚したす。

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 が提䟛するプラットフォヌムのベスト プラクティスず䞻な特長に぀いおご説明したした。デプロむメントの際や運甚の省力化にご掻甚ください。

↧

Azure Media Encoder の高床な゚ンコヌド機胜

$
0
0

このポストは、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 芁玠を远加したす。たずえば、珟時点では次の出力圢匏がサポヌトされおいたす。

䞊蚘の各出力圢匏では、次の 2 ぀の䞻芁な芁玠を䜿甚しお、オヌディオずビデオの䞡方の詳现な基本ストリヌム蚭定をセットアップできたす。

完党に定矩されたオヌディオ甚カスタム プリセットの簡単な䟋は次のようになりたす。この䟋では、既存のオヌディオのみのプリセットからビットレヌトだけを 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 の各プロファむル蚭定です。

䞊蚘の各プロファむル蚭定では、゚ンコヌド先の各 <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 プリセットに組み蟌む必芁があるこずに泚意しおください。䞊蚘の「カスタム プリセット」のセクションでご玹介したシステム プリセットのいずれかを基にしお、倉曎を加えるこずをお勧めしたす。

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

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フォヌラムでぜひお知らせください。

↧
Viewing all 711 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>