Azure: 新しいDocumentDB NoSQLサービス、新しいSearchサービス、新しいSQL Server AlwaysOn VMテンプレートなど

Posted: 2014/08/25 カテゴリー: Uncategorized
タグ:, , , , , , , , ,

本日、Microsoft Azureに対する重要な一連のアップデートをリリースしました。本日のリリースは、次の通りです:

  • DocumentDB: Azure向けの新しいNoSQLドキュメント サービスのプレビュー
  • Search: Azure向けの新しいSearch-as-a-Service (サービスとしての検索) 機能のプレビュー
  • Virtual Machines: SQL Server AlwaysOn、コミュニティ主導のVMのポータル サポート
  • Websites: プレビュー ポータルでのWebJobs、Webサイト プロセスのサポート
  • Azure Insights: Microsoft Azure Monitoring Services Management LibraryのGA (一般提供)
  • API Management: API Management REST APIのサポート

これらの改善すべては現在利用可能になっており、今すぐ使うことができます (いくつかの機能はまだプレビューであることに注意してください)。詳細は、次の通りです:

DocumentDB: Azure向けの新しいNoSQLドキュメント サービスの発表

スケーラブルで高いパフォーマンスのモダン アプリケーション向けに設計されたNoSQLドキュメント データベース サービスである、新しいDocumentDBサービスのプレビューを発表できて、興奮しています。DocumentDBは、エンタープライズ級のSLAがあるフル マネージドのサービスとして提供されます (これは、自分でインフラストラクチャやVMを管理する必要がないことを意味します)。

NoSQLストアとして、DocumentDBには本当にスキーマがありません。DocumentDBによって、スキーマに関係なく、任意のJSONドキュメントを格納、クエリできます。このサービスは、組み込みの自動インデックス作成のサポートを提供しています。これは、JSONドキュメントをストアに書き込み、なじみのあるドキュメント指向SQLクエリ文法を使って、即座にそれらをクエリできることを意味しています。また、オプションとして、クエリ文法を拡張し、サーバー側JavaScriptで書かれたユーザー定義関数 (UDF) のサーバー側評価も実行できます。

DocumentDBは、アプリケーションのニーズを満たすために、線形にスケールするよう設計されています。DocumentDBサービスは、キャパシティ ユニットで購入します。各キャパシティ ユニットは、高いパフォーマンスのストレージの予約と占有パフォーマンス スループットを提供します。キャパシティ ユニットは、スケールのニーズを基に、AzureポータルやRESTベースの管理APIを介して簡単に追加、削除できます。これによって、単にキャパシティ ユニットを増減することによって、予測可能なパフォーマンスのきめ細かい増加で、アプリケーションのダウンタイムなしに、データベースを伸縮自在にスケールできます。

過去1年間にわたって、Microsoft内部で、いくつかの注目されているサービスに対してDocumentDBを使ってきました。現在では、それぞれのサイズが数百TBであり、1桁ミリ秒の短い待機時間の予測可能なパフォーマンスで、それぞれ一日あたり数百万の複雑なDocumentDBクエリを処理する、複数のDocumentDBデータベースを持っています。DocumentDBは、このようなアプリケーションやソリューションを信じられないサイズまでスケールさせる、素晴らしい方法を提供します。

また、DocumentDBでは、特定のアプリケーションやシナリオ向けにインデックス ポリシーと整合性レベルをカスタマイズすることによって、さらにパフォーマンスをチューニングできます。これによって、DocumentDBは、アプリケーション向けの信じられないほど柔軟で強力なデータ サービスになります。DocumentDBは、クエリと読み取り操作に対して、4つの異なる整合性レベル (Strong、Bounded Staleness、Session、Eventual) を提供します。これらの整合性レベルによって、整合性とパフォーマンスとの間の正当なトレードオフを選択できます。各整合性レベルは、予測可能なパフォーマンス レベルによって支えられており、アプリケーションで信頼性の高い結果を達成できることを保証しています。

DocumentDBは、任意のWeb、モバイル アプリケーションから活用し始めるのを簡単にする、JSON、HTTP、RESTといったユビキタスなフォーマットに大きな賭けをしています。また、本日のリリースでは、.NET、Node.js、JavaScript、PythonのSDKも提供します。また、RESTfulなHTTPインターフェイスを介してサービスにアクセスすることもでき、Azureプレビュー ポータルを介してサービスを簡単に管理できます。

DocumentDBアカウントのプロビジョニング

DocumentDBの作業を開始するには、新しいデータベース アカウントをプロビジョニングします。これを行うには、新しいAzureプレビュー ポータル (http://portal.azure.com) を使い、Azureギャラリーをクリックし、「Data, storage, cache + backup」カテゴリを選択し、DocumentDBギャラリー項目を見つけます。

image

DocumentDB項目を選択したら、Createコマンドを選択し、DocumentDBのCreateブレードを表示します。

Createブレードでは、作成したいサービスの名前、DocumentDBインスタンスをスケールさせたいキャパシティ量、デプロイしたい世界中の場所 (米国西部Azureリージョンなど) を指定します:

image

プロビジョニングが完了したら、Azureポータル ダッシュボードの新しいインスタンスのアイコンをクリックすることで、DocumentDBアカウントを管理し始められます。

image

プログラムによってDocumentDBサービスにアクセスするために使うセキュリティ キーを取得するために、Keysタイルを使えます。

DocumentDBでの開発

DocumentDBは、プログラミングする多数の異なる方法を提供しています。HTTPS上で直接REST APIを使うか、または、.NET、Node.js、JavaScript、PythonのクライアントSDKから選択できます。

今回の例で使うJSONデータは、2つの家族です:

// AndersonFamily.jsonファイル
{
    "id": "AndersenFamily",
    "lastName": "Andersen",
    "parents": [
        { "firstName": "Thomas" },
        { "firstName": "Mary Kay" }
    ],
    "children": [
        { "firstName": "John", "gender": "male", "grade": 7 }
    ],
    "pets": [
        { "givenName": "Fluffy" }
    ],
    "address": { "country": "USA", "state": "WA", "city": "Seattle" }
}

および

// WakefieldFamily.jsonファイル
{
    "id": "WakefieldFamily",
    "parents": [
        { "familyName": "Wakefield", "givenName": "Robin" },
        { "familyName": "Miller", "givenName": "Ben" }
    ],
    "children": [
        {
            "familyName": "Wakefield",
            "givenName": "Jesse",
            "gender": "female",
            "grade": 1
        },
        {
            "familyName": "Miller",
            "givenName": "Lisa",
            "gender": "female",
            "grade": 8
        }
    ],
    "pets": [
        { "givenName": "Goofy" },
        { "givenName": "Shadow" }
    ],
    "address": { "country": "USA", "state": "NY", "county": "Manhattan", "city": "NY" }
}

Visual StudioでNuGetパッケージ マネージャーを使って、DocumentDB .NETパッケージを検索し、任意の.NETアプリケーションにインストールできます。Azure管理ポータルから取得済みのDocumentDBサービスのURIと認証キーで、プロビジョニングしたばかりのDocumentDBサービスに接続し、データベースを作成し、コレクションを作成し、いくつかのJSONドキュメントを挿入し、即座にそれらをクエリし始められます:

using (client = new DocumentClient(new Uri(endpoint), authKey))
{
    var database = new Database { Id = "ScottsDemoDB" };
    database = await client.CreateDatabaseAsync(database);

    var collection = new DocumentCollection { Id = "Families" };
    collection = await client.CreateDocumentCollectionAsync(database.SelfLink, collection);

    // DocumentDBは、強く型指定されたPOCOオブジェクトと動的オブジェクトをサポート
    dynamic andersonFamily =  JsonConvert.DeserializeObject(File.ReadAllText(@".DataAndersonFamily.json"));
    dynamic wakefieldFamily = JsonConvert.DeserializeObject(File.ReadAllText(@".DataWakefieldFamily.json"));

    // DocumentDBにドキュメントを永続化
    await client.CreateDocumentAsync(collection.SelfLink, andersonFamily);
    await client.CreateDocumentAsync(collection.SelfLink, wakefieldFamily);

    // 単純なWHERE句に合致する完全なJSONドキュメントを返す、非常に単純なクエリ
    var query = client.CreateDocumentQuery(collection.SelfLink, "SELECT * FROM Families f WHERE f.id = 'AndersenFamily'");
    var family = query.AsEnumerable().FirstOrDefault();

    Console.WriteLine("The Anderson family have the following pets:");              
    foreach (var pet in family.pets)
    {
        Console.WriteLine(pet.givenName);
    }

    // 子供の性別が男性である、家族レコード内の子供レコード「だけ」を選択
    query = client.CreateDocumentQuery(collection.DocumentsLink, "SELECT * FROM c IN Families.children WHERE c.gender='male'");
    var child = query.AsEnumerable().FirstOrDefault();

    Console.WriteLine("The Andersons have a son named {0} in grade {1} ", child.firstName, child.grade);

    // データベースをクリーンアップ
    await client.DeleteDatabaseAsync(database.SelfLink);
}

このコードを見ればわかるように、DocumentDB向けの.NET APIは.NET非同期パターンを完全にサポートしており、よくスケールさせたいアプリケーションでの使用に理想的です。

サーバー側JavaScriptストアド プロシージャ

家族間でペットを交換するといった、トランザクション内で複数のドキュメントに影響を与えるいくつかの更新を実行したい場合、JavaScriptを使ってストアド プロシージャを定義できます。このシナリオでは、不測の事態が発生したために、ある家族がすべてのペットを持ち、もう1つの家族がペットを持たない状態で終わらないようにすることが、重要です。そのため、交換プロセス中にエラーが発生した場合、データベースがトランザクションをロールバックし、データを整合性のある状態のままにすることが、極めて重要です。DocumentDBサービス内で実行する次のストアド プロシージャで、これを行えます:

function SwapPets(family1Id, family2Id) {
    var context = getContext();
    var collection = context.getCollection();
    var response = context.getResponse();

    collection.queryDocuments(collection.getSelfLink(), 'SELECT * FROM Families f where f.id  = "' + family1Id + '"', {},
    function (err, documents, responseOptions) {
        var family1 = documents[0];

        collection.queryDocuments(collection.getSelfLink(), 'SELECT * FROM Families f where f.id = "' + family2Id + '"', {},
        function (err2, documents2, responseOptions2) {
            var family2 = documents2[0];

            var itemSave = family1.pets;
            family1.pets = family2.pets;
            family2.pets = itemSave;

            collection.replaceDocument(family1._self, family1,
                function (err, docReplaced) {
                    collection.replaceDocument(family2._self, family2, {});
                });

            response.setBody(true);
        });
    });
}

たとえばレコード更新時の同時実行違反のために、JavaScript関数で例外がスローされた場合、トランザクションは破棄され、システムは関数が開始される前の状態に戻されます。

(たとえば、デプロイ スクリプトやスタートアップ コードにおいて) 次のようなコードでストアド プロシージャを登録することは、簡単です:

    // ストアド プロシージャを登録
    StoredProcedure storedProcedure = new StoredProcedure
    {
        Id = "SwapPets",
        Body = File.ReadAllText(@".JSSwapPets.js")
    };

    storedProcedure = await client.CreateStoredProcedureAsync(collection.SelfLink, storedProcedure);

そして、アプリケーションからストアド プロシージャを実行することも、同様に簡単です:

    // ペット交換に関係する2つの家族のドキュメントを渡して、ストアド プロシージャを実行
    dynamic result = await client.ExecuteStoredProcedureAsync<dynamic>(storedProcedure.SelfLink, "AndersenFamily", "WakefieldFamily");

Anderson家族にリンクされるようにあったペットを確認すれば、ペットが交換されていることがわかります。

さらに学ぶ

数分のうちにDocumentDBで作業を開始し、動作する単純なアプリケーションを作成することは、本当に簡単です。前述の例は、DocumentDBを使い始める1つの単純な例に過ぎません。DocumentDBはスキーマレスなので、文字通り任意のJSONドキュメントとともにDocumentDBを使えます。DocumentDBは、格納されたあらゆるJSONドキュメントに対して自動インデックス作成を実行するので、格納済みのJSONドキュメントを後でクエリする際に、素晴らしいパフォーマンスを得られます。DocumentDBは一貫性のあるパフォーマンスで線形にスケールするので、巨大になる可能性があるとあなたが考えているアプリケーションにとって、理想的です。

こちら (英語 / 日本語 / 日本語) の新しいDocumentDBデベロッパー センターで、DocumentDBについてさらに学べます。

Search: Azure向けの新しいSearch as a Service (サービスとしての検索) のプレビューの発表

新しいAzure Searchサービスのプレビューを発表できて、興奮しています。Azure Searchは、開発者が任意のWeb、モバイルアプリケーションに素晴らしい検索のエクスペリエンスを追加することを、簡単にします。

Azure Searchは、開発者に、実世界の検索サービスの管理、チューニング、スケールに伴う典型的な複雑さに取り組む必要なしに、検索のエクスペリエンスを構築するために必要なすべての機能を提供します。これは、エンタープライズ級のSLAがあるフル マネージドのサービスとして提供されます。また、本日、サービスのFreeレベルをリリースします。これによって、Azure上の小規模なソリューションで、無料で使えるようになります。

Searchサービスのプロビジョニング

作業を開始するには、新しいSearchサービスを作成しましょう。Azureプレビュー ポータル (http://portal.azure.com) で、Azureギャラリーに進み、「Data storage, cache + backup」カテゴリを選択し、Azure Searchギャラリー項目を見つけます。

image

「Search」サービス アイコンを見つけ、「Create」を選択してサービスのインスタンスを作成します:

image

2つの料金オプションから選択できます。自分のSearchサービスに対して占有キャパシティを提供するStandardオプションと、あらゆるAzureサブスクリプションで共有環境の小さい無料サービスを得られるFreeオプションです。

Standardレベルは簡単にスケールアップ、ダウンでき、アプリケーションで検索パフォーマンスが予測可能であることを保証する、占有キャパシティの保証を提供します。また、多数のインデックスで、数千万ドキュメントのインデックスを作成できる機能をサポートしています。

Freeレベルは、10,000ドキュメント、最大3つのインデックスに制限されており、占有キャパシティの保証はありません。ですが、これは完全に無料であり、Azure Searchのすべての機能を学んで試す、素晴らしい方法を提供します。

Azure Searchサービスの管理

Searchサービスをプロビジョニングした後、ポータルでSearchブレードにアクセスします。ここで、サービスの管理、使用量データの表示、サービスのパフォーマンスのチューニングを行えます。

image

この「Scale」タブをクリックして、自分のSearchサービスに割り当てられたリソース数の詳細を表示できます。StandardレベルのSearchサービスを作成した場合、これを使って、さらに多くの毎秒検索数をサポートする (あるいは、高可用性を提供する) ためにレプリカ数を増やし、自分のSearchサービス内でさらに多くのドキュメント数をサポートするためにパーティション数を増やせます。

検索インデックスの作成

Searchサービスを作成したので、検索対象のドキュメント (データ) を保持する検索インデックスを作成する必要があります。作業を開始するには、Azureポータルから2つの情報が必要です。(「Properties」タイルでアクセスできる) 自分のAzure SearchサービスにアクセスするためのサービスURL、(「Keys」タイルでアクセスできる) サービスに対して認証するための管理キーです。

image

このSearchサービスURLと管理キーを使って、SearchサービスAPIを使い始め、インデックスを作成し、その後にデータをアップロードし、検索リクエストを発行できます。このキーを使ってAPIに対してHTTPリクエストを送信します。次のように、これを行うために、.NET HttpClientオブジェクトを設定します:

HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Add("api-key", "19F1BACDCD154F4D3918504CBF24CA1F");

検索インデックスを作成することから始めます。今回は、自分のデータセット内の連絡先を検索するために使いたいインデックスが欲しいので、連絡先の名前とタグに対する検索可能フィールドが欲しいと思います。また、(後で最新の連絡日に対してフィルターや並べ替えを行えるように) 最新の連絡日と (同様にフィルターで住所を使えるように) 緯度、経度の位置としての住所を追跡したいと思います。物事を簡単にするため、オブジェクトをJSONにシリアル化するために、JSON.NETを使います (これを行うには、自分のVSプロジェクトにNuGetパッケージを追加します)。

var index = new
{
    name = "contacts",
    fields = new[]
    {
        new { name = "id", type = "Edm.String", key = true },
        new { name = "fullname", type = "Edm.String", key = false },
        new { name = "tags", type = "Collection(Edm.String)", key = false },
        new { name = "lastcontacted", type = "Edm.DateTimeOffset", key = false },
        new { name = "worklocation", type = "Edm.GeographyPoint", key = false },
    }
};

var response = client.PostAsync("https://scottgu-dev.search.windows.net/indexes/?api-version=2014-07-31-Preview",
                                new StringContent(JsonConvert.SerializeObject(index), Encoding.UTF8, "application/json")).Result;
response.EnsureSuccessStatusCode();

自分のデプロイ コードの一部として、あるいは、アプリケーション初期化の一部として、このコードを実行できます。

検索インデックスへのデータ投入

Azure Searchでは、データのインデックス作成のためにプッシュAPIを使います。一度に最大1000のインデックス作成対象ドキュメントのバッチで、このAPIを呼び出せます。データをインデックスにプッシュするのは自分のコードなので、元データは (Azure SQL Database、DocumentDBデータベース、BLOB/テーブル ストレージなど) どこにあっても構いません。オンプレミスやAzure以外のクラウド プロバイダーに格納されているデータを投入することすらできます。

インデックス作成が1回限りの操作であることは稀であることに注意してください。恐らく、自分のデータ ソースからロードするデータの初期セットを持っていますが、それから、新規ドキュメントをプッシュし、既存ドキュメントの更新、削除を行いたいでしょう。Azure Websitesを使っている場合、これは、バックグラウンドで定期的に自分のインデックス作成コードを実行できる、WebJobs (英語 / 日本語) の自然なシナリオです。

データをどこにホストしているかに関係なく、データのインデックスを作成するコードは、ソースからデータをプルし、それをAzure Searchにプッシュする必要があります。次の例では、単にデータを作り出していますが、SQLやLINQクエリの結果、あるいは、前に識別したインデックス フィールドに合致する一連のオブジェクトを生成するものなら何でも使えることが分かるでしょう。

var batch = new
{
    value = new[]
    {
        new
        {
            id = "221",
            fullname = "Jay Adams",
            tags = new string[] { "work" },
            lastcontacted = DateTimeOffset.UtcNow,
            worklocation = new
            {
                type = "Point",
                coordinates = new [] { -122.131577, 47.678581 }
            }
        },
        new
        {
            id = "714",
            fullname = "Catherine Abel",
            tags = new string[] { "work", "personal" },
            lastcontacted = DateTimeOffset.UtcNow,
            worklocation = new
            {
                type = "Point",
                coordinates = new [] { -121.825579, 47.1419814}
            }
        }
    }
};

var response = client.PostAsync("https://scottgu-dev.search.windows.net/indexes/contacts/docs/index?api-version=2014-07-31-Preview",
                                new StringContent(JsonConvert.SerializeObject(batch), Encoding.UTF8, "application/json")).Result;
response.EnsureSuccessStatusCode();

インデックスの検索

インデックスを作成し、そのインデックスにデータを投入した後、そのインデックスに対して検索リクエストを発行できます。検索はインデックスに対する単純なHTTP GETリクエストであり、レスポンスには、もともとアップロードしたデータや付随するスコアリング情報が含まれています、

searchTextが (たとえば「abel work」のような) ユーザー入力を含む文字列である、次のコードを実行することで、単純な検索を行えます:

var response = client.GetAsync("https://scottgu-dev.search.windows.net/indexes/contacts/docs?api-version=2014-07-31-Preview&search=" + Uri.EscapeDataString(searchText)).Result;
response.EnsureSuccessStatusCode();

dynamic results = JsonConvert.DeserializeObject(response.Content.ReadAsStringAsync().Result);

foreach (var result in results.value)
{
    Console.WriteLine("FullName:" + result.fullname + " score:" + (double)result["@search.score"]);
}

さらに学ぶ

これは、できることの単純なシナリオに過ぎません。検索でできることは、他にも多数あります。たとえば、結果に対するフィルター、並べ替え、投影、ページングを行うために、クエリ文字列オプションを使えます。結果を表示するためのより高度な方法を作成するために、ヒット ハイライトやファセットを使え、Web、モバイルUI内での自動補完を実装するために、候補 (suggestion) を使えます。

今回の例では、スコアを計算するためにインデックス作成されたテキストと検索文字列の統計を使う、既定のランキング モデルを使いました。自分のアプリケーションのニーズに合致する方法でスコアをモデリングする、独自のスコアリング プロファイルを作成することもできます。

作業の開始方法に関するさらなる詳細と、活用可能なより高度ないくつかのユース ケースについては、Azure Searchのドキュメント (英語 / 日本語 / 日本語) を確認してください。あらゆるAzureサブスクライバー向けに無料でFreeレベルが利用可能になったので、Azure Searchを自分のアプリケーションに完全に統合しない理由は、もはやありません。

Virtual Machines: SQL Server AlwaysOn、VM Depotイメージのサポート

先月、Azureプレビュー ポータル (http://portal.azure.com) でのVMの管理のサポートを追加しました。また、複数VMのSharePoint Server Farmや、多数の追加のAzure Certified VMイメージを簡単に作成できる、ポータルの組み込みサポートもリリースしました。これらのアップデートについて、私の前回のブログ ポスト (英語 / 日本語) でさらに学べます。

本日、AlwaysOnが構成されたSQL ServerのVMを自動的にデプロイするための新しいサポートと、コミュニティがサポートするVM Depotのイメージのポータルでの統合されたサポートを発表できて、興奮しています。

SQL Server AlwaysOnテンプレート

(SQL Server 2012でリリースされ、SQL Server 2014で拡張された) AlwaysOn可用性グループは、ミッション クリティカルなワークロードのための高可用性を保証します。昨年、Azure Infrastructure ServicesにおけるSQL Server可用性グループ (英語 / 日本語) のサポートを開始しました。この構成では、それぞれが独自のAzure VM内にある2つのSQLレプリカ (プライマリ、セカンダリ) が、自動フェールオーバーのために構成され、リスナー (英語 / 日本語) (DNS名) がクライアント接続性のために構成されます。必要となる他のコンポーネントは、「スプリット ブレイン」シナリオの回避のために構成内のクォーラムを保証するためのファイル共有監視、および、すべてのVMが同じドメインに参加するためのドメイン コントローラーです。各レプリカが異なるAzure障害ドメイン、アップグレード ドメインに配置されることを保証するため、SQL Serverのレプリカやドメイン コントローラーのレプリカは、それぞれ1つの可用性セットにデプロイされます。

本日のリリース以前は、可用性グループの構成 (英語 / 日本語) の設定は、退屈で時間のかかるものでした。Azureギャラリーにおける新しいSQL Server AlwaysOnテンプレートを介して、このエクスペリエンスを劇的に単純化しました。このテンプレートは、可用性グループを使って、Azure Infrastructure Servicesにおける可用性の高いSQL Serverのデプロイの構成を、完全に自動化します。

Azureプレビュー ポータル (http://portal.azure.com) でAzureギャラリーに進み、左側の「Virtual machines」カテゴリを選択し、「SQL Server 2014 AlwaysOn」ギャラリー項目を選択することで、このテンプレートを見つけられます。ギャラリー詳細ページで「Create」を選択します。必要なのは、VMの管理者の資格情報といったいくつかの基本的な構成情報を提供することだけです。残りの設定は既定値になります。リスナー名は、自分のアプリケーションがSQL Serverに接続するために使うものなので、リスナー名の既定値からの変更を検討するかもしれません。

image

作成時に、リソース グループ内に5つのVMが作成されます。SQL Serverのレプリカ向けに2つのVM、ドメイン コントローラーのレプリカ向けに2つのVM、ファイル共有監視向けに1つのVMです。

作成後、SQL ServerのVMの1つにRDP接続し、次に示すような可用性グループの構成を確認できます:

image

今すぐAzure プレビュー ポータルでSQL Server AlwaysOnテンプレートを試し、我々にフィードバックしてください!

AzureギャラリーにおけるVM Depot

コミュニティ主導のVM Depotイメージは、Azureプラットフォームで数年間サポートされてきました。しかし、本日のリリース以前は、それらは主流のユーザー エクスペリエンスに完全に統合されてはいませんでした。

本日、コミュニティのVMをAzureプレビュー ポータルとAzureギャラリーに統合したことを発表できて、興奮しています。今回のリリースでは、300近い事前構成済みのMicrosoft Azure向けの仮想マシン イメージにアクセスできます。

これらのイメージを使って、フル機能の仮想マシンをプレビュー ポータルで数分でデプロイでき、特定のユース ケース向けにカスタマイズできます。(Debian、Ubuntu、CentOS、Suse、FreeBSDといった) ベースのOSディストリビューションから、(LAMP、Ruby on Rails、Node、Djangoといった) 開発者スタック、(WordPress、Drupal、Apache Solrといった) 完全なアプリケーションまで、VM Depotには誰もに何かがあります。

Azureギャラリーの「Virtual machines」カテゴリから、VM Depotイメージを試してください。

image

Websites: プレビュー ポータルでのWebJobs、プロセス管理

Azureの本日のリリースから、Azureプレビュー ポータルでWebsitesのWebJobsがサポートされるようになりました。また、自分のWebサイトに進み、サイト内で実行されている任意のプロセス (自分のWebサイトのコード、および、自分のWebジョブをホストしているプロセス) の正常性を監視できるようになりました。

WebsitesのWebJobs

WebJobsを使って、Azure Websites内で任意のコードを実行できるようになりました。さらに、すぐに並列化可能で、グローバルにスケーラブルで、リモートデバッグ、完全なVSサポート、作成を容易にするオプションのSDKを備えています。WebJobsのさらなる情報については、Azure WebJobsの推奨リソース (英語 / 日本語) にアクセスしてください。

Azureの本日のリリースでは、2種類のWebJobs (オンデマンド、連続的) をサポートするようになりました。プレビュー ポータルでWebJobsを使うには、自分のWebサイトに進み、Webサイト ブレードの「WebJobs」タイルを選択します。このタイルが利用可能なWebJobs数を示すようになったことにも注意してください。

image

このタイルに進むことで、既存のWebJobsを表示でき、オンデマンドの、または連続的なWebJobsを新規作成できます。スケジュールされたWebJobsは、プレビュー ポータルでまだサポートされていませんが、近い将来にサポートされる予定です。

Websitesのプロセス

Azure Websitesのプレビュー ポータルでのエクスペリエンスに関する新機能「Websites Processes」を発表できて、興奮しています。Websites Processesを使って、自分のサイトの異なるインスタンスを列挙し、各インスタンスの異なるプロセスを表示し、各プロセスに関連付けられたハンドルやモジュールにドリル ダウンすることすらできます。それから、バージョン、言語といった詳細情報を確認できます。

image

加えて、プロセス レベルでのCPU、ワーキング セット、スレッド数の高度な監視も提供されています。Widnowsのタスク マネージャーと同様に、「Websites Processes」ブレードを開いた際にデータ収集が開始され、閉じた際に停止されます。

image

この機能は、自分のサイトをスケール アウトしており、特定のインスタンスでは問題があるが、他のインスタンスでは問題がない際に、特に便利です。問題のあるプロセスを迅速に識別し、オープン ファイル ハンドルを見つけ、特定のプロセス インスタンスを強制終了することすらできます。

Monitoring and Management SDK: プログラムからの監視データへのアクセス

Azure管理ポータルは、Azureにデプロイされたアプリケーションやソリューションの正常性の追跡を簡単にする、監視、管理の組み込みサポートを提供しています。

また、Azureの監視、管理機能にプログラムからアクセスしたい場合、NuGetから入手できる.NET SDKも使えるようになりました。本日、このSDKを GA (一般提供) としてリリースするので、運用環境のサービス向けにこのSDKを使えるようになりました!

たとえば、自分のサービスのメトリック データを示す独自のカスタム ダッシュボードを構築したい場合、SDKを介してメトリック データを取得できます:

// 特定のサムプリントの証明書を取得することで、メトリック クライアントを作成
MetricsClient metricsClient = new MetricsClient(new CertificateCloudCredentials(SubscriptionId, GetStoreCertificate(Thumbprint)));

// リソースID文字列を構築
string resourceId = ResourceIdBuilder.BuildWebSiteResourceId("webtest-group-WestUSwebspace", "webtests-site");

// メトリック定義を取得
MetricDefinitionCollection metricDefinitions = metricsClient.MetricDefinitions.List(resourceId, null, null).MetricDefinitionCollection;

// 利用可能なメトリック定義を表示
Console.WriteLine("Choose metrics (comma separated) to list:");
int count = 0;
foreach (MetricDefinition metricDefinition in metricDefinitions.Value)
{
    Console.WriteLine(count + ":" + metricDefinition.DisplayName);
    count++;
}

// どのメトリックに興味があるか、ユーザーに尋ねる
var desiredMetrics = Console.ReadLine().Split(',').Select(x =>  metricDefinitions.Value.ToArray()[Convert.ToInt32(x.Trim())]);

// 直近20分のメトリック値を取得
MetricValueSetCollection values = metricsClient.MetricValues.List(
    resourceId,
    desiredMetrics.Select(x => x.Name).ToList(),
    "",
    desiredMetrics.First().MetricAvailabilities.Select(x => x.TimeGrain).Min(),
    DateTime.UtcNow - TimeSpan.FromMinutes(20),
    DateTime.UtcNow
).MetricValueSetCollection;

// ユーザーにメトリック値を表示
foreach (MetricValueSet valueSet in values.Value )
{
    Console.WriteLine(valueSet.DisplayName + " for the past 20 minutes:");
    foreach (MetricValue metricValue in valueSet.MetricValues)
    {
        Console.WriteLine(metricValue.Timestamp + "t" + metricValue.Average);
    }
}

Console.Write("Press any key to continue:");
Console.ReadKey();

監視SDKで、多様なサービスのメトリックをサポートしています:

サービス 典型的なメトリック 頻度
Cloud Services CPU、ネットワーク、ディスク 5分、1時間、12時間
Virtual Machines CPU、ネットワーク、ディスク 5分、1時間、12時間
Websites リクエスト、エラー、メモリ、応答時間、送信データ 1分、1時間
Mobile Services API呼び出し、送信データ、SQLパフォーマンス 1時間
Storage リクエスト、成功率、エンド ツー エンド遅延時間 1分、1時間
Service Bus メッセージ、エラー、キューの長さ、リクエスト 5分
HDInsight コンテナー、実行チュのアプリ 15分

ポータルでは行えない高度な自動スケール設定を管理したい場合、SDKを介して行えます。たとえば、カスタム メトリックを基にして自動スケールを構成できます。MetricDefinitionsから返される任意のものによって自動スケールできます。

SDKのドキュメントのすべては、MSDN (英語 / 日本語 / 日本語) で入手可能です。

API Management: サービスのREST APIのサポート

今年5月、Azure API Managementサービスのプレビューを開始しました。API Managementサービスによって、お客様は、パートナー、公開の開発者コミュニティ、および、内部開発者にすら、APIを迅速かつセキュアに発行できます。

本日、多数の新しいシナリオを可能にする、API Management REST APIが利用可能になったことを発表できて、興奮しています。API分析へのアクセスに加えて、API、製品、サブスクリプション、ユーザー、グループの管理のために、このREST APIを使えます。実際、API Managementポータルで利用可能なほぼすべての管理操作が、プログラムからアクセス可能になりました。これは、自分で選んだコマース プロバイダーでのAPIの直接のマネタイズ、ユーザーやサブスクリプションの管理の引き継ぎ、APIのデプロイの自動化といった、統合や自動化のシナリオを可能にします。

追加のSAS (共有アクセス署名) セキュリティ オプションも提供します。発行者ポータルでの統合されたエクスペリエンスによって、SASトークンを生成できるので、自分のAPIサービスをセキュアに呼び出すことが最高に簡単です。3つの簡単な手順です:

  1. 発行者ポータルのシステム設定ページで、APIを有効化します
  2. 手動で、または、プログラムから、時間制限されたアクセス トークンを取得します (英語 / 日本語 / 日本語)
  3. 各リクエストでトークンを提供して、APIへのリクエスト送信を開始します

image

完全な詳細については、REST APIのリファレンス (英語 / 日本語 / 日本語) をご覧ください。

ユーザー登録と製品サブスクリプションの委任

新しいAPI Management REST APIによって、他のプロセスをAPI Managementと自動化、統合することが簡単になります。このように統合している多くのお客様は、すでにユーザー アカウント システムを持っており、開発者ポータルが提供する組み込み機能より、この既存リソースを使う方を好みます。「委任」と呼ばれるこの機能によって、既存のWebサイトやバックエンドが、ユーザー データを所有し、サブスクリプションを管理し、API Managementの動的生成APIドキュメントとシームレスに統合できます。

image

委任を有効化するのは簡単です。発行者ポータルで「Delegation」セクションに進み、「Delegate sign-in & sign-up」を有効化し、エンドポイントURLと検証キーを提供したら、準備完了です。さらなる詳細については、ハウツー ガイド (英語 / 日本語 / 日本語) を確認してください。

まとめ

Microsoft Azureの本日のリリースによって、多数の素晴らしい新シナリオが可能になり、クラウドにホストされたアプリケーションの構築がさらに簡単になります。

もしAzureアカウントをまだ持っていない場合は、無料評価版 (英語 / 日本語) に登録して、これらの機能すべてを今すぐ使い始めることができます。それから、Microsoft Azureデベロッパー センター (英語 / 日本語) にアクセスして、アプリの構築方法についてさらに学んでください。

関連情報

コメント
  1. […] Azure: 新しいDocumentDB NoSQLサービス、新しいSearchサービス、新しいSQL Server Alw… 2014/08/25 […]

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中