前へ

次へ

Azure ストレージ インフラストラクチャを作成する

完了

ネットワーク帯域幅が狭いときや需要が高いときに中断する可能性があるため、分散アプリケーションのコンポーネント間の直接通信には問題があります。

この種の中断はシステムで発生しています。Web ポータルにより Web サービスが呼び出され、サービスがタイムリーに応答するが、トラフィックが多いときに問題が発生する場合に有効です。 この計画では、キューを使用してフロントエンド アプリと中間層 Web サービス間の直接リンクを排除します。

Azure Queue Storage とは

Azure Queue storage は、クラウドベースのキューを実装する Azure サービスです。 各キューにはメッセージの一覧が保持されています。 アプリケーション コンポーネントは、REST API または Azure が提供するクライアント ライブラリを使用してキューにアクセスします。 通常は、1 つ以上の "送信側" コンポーネントと、1 つ以上の "受信側" コンポーネントがあります。 送信側コンポーネントは、メッセージをキューに追加します。 受信側コンポーネントは、キューの先頭から処理対象のメッセージを取得します。 次の図は、メッセージを Azure Queue に追加する複数の送信側アプリケーションと、メッセージを取得する 1 つの受信側アプリケーションを示しています。

価格は、キュー サイズと操作数に基づいています。 大きいメッセージ キューの方が小さいキューよりもコストが高くなります。 また、メッセージの追加やメッセージの削除などの操作ごとに料金が発生します。 価格の詳細については、Azure Queue Storage の価格に関するページを参照してください。

キューを使用する理由

待機中のメッセージをキューに一時的に保存することで、回復性が高くなります。 需要が低いときまたは通常のときは、宛先コンポーネントによってキューからメッセージが削除される場合の方が追加される場合よりも速いため、キューのサイズは小さいままです。 需要が高いときは、キューのサイズが大きくなる可能性がありますが、メッセージは失われません。 需要が正常に戻ると、宛先コンポーネントは処理に追いついて、キューを空にすることができます。

1 つのキューは最大で 500 TiB になる可能性があるため、"数百万個" 単位のメッセージが格納される可能性があります。 1 つのキューのターゲット スループットは 1 秒あたり 2,000 メッセージなので、大規模なシナリオを処理できます。

キューを使用すると、需要の変化に合わせて自動的かつ即時にアプリケーションをスケーリングできます。 この機能を使用することで、それらは、失ってしまうと損害をもたらす重大なビジネス データにとって有用なものとなります。 Azure には、自動的にスケーリングするサービスが他にも多くあります。 たとえば、自動スケーリング機能は、Azure Virtual Machine Scale Sets、クラウド サービス、Azure App Service プラン、App Service 環境で使用できます。 自動スケーリングにより、需要の高い期間を指定し、管理者の操作を介さずに自動的に容量を追加するように、Azure が使用するルールを定義できます。 自動スケーリングは需要にすぐに反応しますが、即時ではありません。 対照的に、Azure Queue Storage は、処理リソースを使用できるようになるまでメッセージを格納することで、高い需要を即時に処理します。

メッセージとは

キュー内のメッセージは、最大 64 KiB のバイト配列です。 メッセージ コンテンツは、どの Azure コンポーネントを使用してもまったく解釈されません。

構造化メッセージを作成する場合は、XML または JSON を使用してメッセージ コンテンツの形式を設定できます。 カスタム形式の生成と解釈は、コード側の役割です。 次の例のようなカスタム JSON メッセージを作成できます。

{
    "Message": {
        "To": "news@contoso.com",
        "From": "writer@contoso.com",
        "Subject": "Support request",
        "Body": "Send me a photographer!"
    }
}

ストレージ アカウントの作成

キューはストレージ アカウントの一部である必要があります。 Azure CLI (または PowerShell)、または Azure portal を使用してストレージ アカウントを作成できます。 Azure portal は、各情報の入力を求めるガイド付きエクスペリエンスであるため、最も簡単です。

次のスクリーンショットは、ストレージ アカウント カテゴリの場所を示しています。

アカウントの作成時に指定できるオプションがいくつかありますが、そのほとんどは既定の選択を使用できます。 前のモジュールではこれらのオプションについて説明しましたが、各オプションに関連付けられている (i) のヒントをポイントすると、その機能の概要が表示されます。 次に、Azure portal ペインの入力例を示します。

次のスクリーンショットは、[ストレージ アカウントの作成] ウィンドウとストレージ アカウントの作成に必要な情報を示します。

キューの設定

キューを含むストレージ アカウントを作成するときは、次の設定を考慮する必要があります。

• キューは、Azure 汎用ストレージ アカウント (v1 または v2) の一部としてのみ利用できます。 BLOB ストレージ アカウントに追加することはできません。
• 汎用 v2 ストレージ アカウントに対して表示される [アクセス層] 設定は、BLOB ストレージにのみ適用され、キューには影響しません。
• ソース コンポーネント、宛先コンポーネント、または (できれば) 両方のコンポーネントに近い場所を選択するようにします。
• データは常に複数のサーバーにレプリケートされるので、ディスク障害やその他のハードウェアの問題から保護されます。 レプリケーション戦略には選択肢があります。ローカル冗長ストレージ (LRS) は低コストですが、データセンター全体に影響する災害に対しては脆弱です。一方、geo 冗長ストレージ (GRS) では、データが他の Azure データ センターにレプリケートされます。 実際の冗長性のニーズを満たすレプリケーション戦略を選択してください。
• パフォーマンス レベルによって、メッセージの保存方法が決まります。Standard の場合は磁気ドライブが使用されていますが Premium の場合はソリッドステート ドライブが使用されています。 需要のピークが短いと予想される場合は、Standard を選択します。 キューの長さが長くなり、メッセージにアクセスする時間を最小限に抑える必要がある場合は、Premium を検討します。
• 機密情報がキューを経由する可能性がある場合は、安全な転送が必要です。 この設定により、キューへのすべての接続が Secure Sockets Layer (SSL) を使用して確実に暗号化されます。

続行