Azure Application Gatewayを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の15日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

15日目はAzure Application Gatewayです。HTTP/HTTPSのトラフィックを柔軟に負荷分散することができます。

概要

Azure Application Gatewayは、アプリケーション層 (OSIネットワーク参照モデルの第7層)で動作する負荷分散機能です。Azure Load Balancerでも負荷分散はできますが、Application Gatewayではより柔軟に、パスベースの振り分け等の機能も提供されます。

機能

Application Gatewayを作成すると、エンドポイントがAzure Load Balancerによって提供されます。Azure Load BalancerはトラフィックをApplication Gatewayインスタンスに分散し、インスタンス上で各種の処理が行われます。


https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-introduction から引用

Application GatewayはSmall、Medium、Largeの3つのサイズが選べます。上のサイズになるほど以下の表のようにスループットが向上します。
Application Gatewayは、サブスクリプションごとに最大50個まで作成できます。各Application Gatewayには最大10個のインスタンス(L7の仮想負荷分散装置)を割り当てることができます。また、Application Gatewayには20個のHTTPリスナーを作成できます。


https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-introduction から引用

・トラフィックの分散

Application Gatewayへのトラフィックはラウンドロビン方式でバックエンドのサーバに分散されます。

・SSL終端とオフロード

Application GatewayがSSL終端となってHTTPSとHTTPへの変換を行います。復号・暗号化をApplication Gateway上で行うことでバックエンドのCPU負荷を削減します。

・エンド・ツー・エンドSSL

Application Gateway上でHTTPS通信をHTTPに変換、URLパスベースのルーティング、CookieベースのセッションアフィニティなどのApplication Gateway上での処理を行ったうえで、再びHTTPからHTTPSに変換して、バックエンドにトラフィックを流します。Application Gatewayとバックエンド間のエンド・ツー・エンドのHTTPS通信を維持しながら、Application Gatewayの各種機能も利用することが可能になります。

・Cookieベースのセッションアフィニティ

Cookieを利用して、ユーザセッションを特定のバックエンドに送ることができます。ユーザのセッション情報をバックエンドで保存したり管理したりする場合に役に立ちます。

・URLパスベースのルーティング

事前に設定したURLパスベースのルールに則って、特定のバックエンドにトラフィックを振り分けることができます。例えば、http://contoso.com/video* に対する要求はVideoServerPoolに、http://contoso.com/images* に対する要求は ImageServerPool にそれぞれルーティングできます。


https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-url-route-overview から引用

・複数サイトのホスト

最大で20のWebサイトを1つのApplication Gatewayで処理、バックエンドに転送することができます。例えば、1つのApplication Gatewayを使って、www.hogehoge.com と www.foobar.com のような2つのドメインへのトラフィックをコントロールできます。

・リダイレクト

Application Gateway上でリダイレクトも可能です。HTTPからHTTPSへのリダイレクト、パスに基づくリダイレクト、外部サイトへのリダイレクトが可能です。サーバを立てなくてもいろんなパターンのリダイレクトを行えるのは便利です。

・Webアプリケーションファイアウォール(WAF)

WAFがApplication Gatewayで提供され、脆弱性や攻撃からWebアプリケーションを保護できます。SQLインジェクション、クロス・サイト・スクリプティングなどからの保護が提供されます。
WAFには、検出モードと防止モードがあります。検出モードの場合は、許可されない通信が発生すると、ログに記録されます。防止モードは検知と同時にさらに通信がブロックされ、アクセスしたユーザには「403 不正アクセス」が表示されセッションが終了します。

・監視

Application Gatewayにつながるバックエンドの死活監視を行い、異常なインスタンスへの振り分けを停止することもできます。
「既定の正常性プローブ」はルートパスに対するHTTP応答確認により死活を監視できます。「カスタムの正常性プローブ」では、さらに柔軟にURLパスや監視のパラメータを個別に設定できます。

その他

・Application Gateway は、インターネット接続ゲートウェイ、または内部的にのみ使用されるゲートウェイのいずれかとして構成できる

・Application Gatewayの属するサブネット上にネットワークセキュリティグループ(NSG)がある場合、65503~65534のポート範囲をインバウンドトラフィック用に開いておく必要がある。

・WebSocket通信もサポートされる

・WAFはサイズMediumとLargeで利用可能。

料金

・Application Gatewayを構成して利用した時間とApplication Gatewayによって処理されたデータ量(GB単位)に対して課金されます。

・Azureデータセンター外へ出ていくデータの転送量ももちろん課金されます。

まとめ

SSL終端、URLパスベースのルーティング、複数サイトの管理など、Application Gatewayでだいたい何でもできます。これまで、ネットワーク機器のレイヤ、HTTPサーバのレイヤなど、複数の機器、ソフトにまたがって行っていた設定を、Application Gateway上で一括して管理することができて、とても便利です。スループットレベルやインスタンス数を自分である程度コントロールできるのも、事前に想定した負荷に備えることができて良いです。


Azure ExpressRouteを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の14日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

14日目はAzure ExpressRouteです。

概要

Azure ExpressRouteは、専用線を利用してAzureデータセンターと自社データセンター、オンプレサーバを接続することができるサービスです。インターネットを経由しないので、安定した品質の回線で、機密情報などの情報を安全にAzureデータセンターと通信することができます。

機能

・接続モデル

3つの接続形態があります。

CloudExchangeでのコロケーション(同一場所配置):データセンターに配置されたネットワーク機器から専用線を介してAzureと通信する。
ポイント間(ポイント・ツー・ポイント)のイーサネット接続:自社のオフィスやデータセンターから専用線を介してAzureと通信する。
Any-to-Any(IPVPN)接続:IPVPN網を介してAzureと通信する。

https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-connectivity-models#CloudExchange から引用

また、利用するサービスに合わせて3つの経路が提供されます。

Microsoftピアリング:Office 365やDynamics 365などのサービスにプライベートなネットワークでアクセスできます。
Azureパブリックピアリング:Azure Storage、SQL Databaseなど、パブリックIPでアクセスするサービスと通信できます。
Azureプライベートピアリング:Azureの仮想ネットワーク内にある仮想マシンやサービスと通信できます。

https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-circuit-peerings から引用

・回線
50Mbps、100Mbps、200Mbps、500Mbps、1Gbps、2Gbps、5Gbps、10Gbpsの回線速度が提供されます。
日本国内では東京と大阪で以下のプロバイダーを利用できます。

東京:Aryaka Networks、AT&T NetBond、British Telecom、Colt、Equinix、Internet Initiative Japan Inc. - IIJ、Level 3 Communications、NTT Communications、Softbank、Verizon
大阪:Equinix、Internet Initiative Japan Inc. - IIJ、NTT Communications、NTT SmartConnect、Softbank

・冗長性

ExpressRoute回線はルーター間で二重化されています。
さらなる冗長性が必要な場合は、異なるプロバイダーの回線を使用して二重化したりIPVPNを組み合わせた二重化も可能です
いろんなパターンの接続ができます。Tech Summit 2017のセッション「CLD015 百戦錬磨のAzureアーキテクトが語る、Azure Virtual Machines設計の勘所」の資料が分かりやすかったのでリンクを載せておきます。

https://www.slideshare.net/Microsoft_TechSummit_2017/japan-tech-summit-2017-cld-015/31 から引用

その他

・接続を壊さずにExpressRoute回線の帯域幅を増やすことができます。でも減らすことはできない。

・ExpressRoute Premiumアドオンを追加すると機能がさらに強化できる。ルート上限が増えたり、ExpressRouteからすべてのリージョンにアクセスできたりするようになる。

料金

・無制限データプランと従量制課金データプランがある。Premiumアドオンを使う場合にはさらに費用が上乗せになる。

・無制限データプランは、ExpressRoute回線は月額料金が課金され、受信・送信ともデータ転送量に応じた課金はない。

・従量制課金データプランは、ExpressRoute回線は月額料金が課金され送信データにGB単位で課金されます。受信は無料。

・従量課金制の場合の、データ転送料金は地域によって異なる。ゾーン1では2.55円/GB、ゾーン2では5.10円/GB、ゾーン3では14.28円/GB。日本はゾーン2。
ゾーン 1: 米国西部、米国東部、米国中北部、米国中南部、米国東部 2、米国中部、西ヨーロッパ、北ヨーロッパ、カナダ東部、カナダ中部
ゾーン 2: 東アジア、東南アジア、オーストラリア東部、オーストラリア南東部、東日本、西日本、韓国中部、韓国南部、インド南部、インド西部、インド中部
ゾーン 3: ブラジル南部

まとめ

Azureを使いたいけどインターネットを使った通信は機密情報があるからちょっと、という場合にExpressRouteを使えば、セキュアに、高品質な回線を利用して通信を行うことができます。例えば、Azure Stackを自社データセンターにおいて、Azureデータセンターとの間はExpressRouteでつなぐ構成などが、これからますます増えていきそうです。


Azure Content Delivery Networkを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の12日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

12日目はAzure Content Delivery Networkです。その名の通り、コンテンツ・デリバリー・ネットワークです。AkamaiやCloudFlare、クラウドだとAWSのCloudFrontが良く知られています。
世界中に分散されたエンドポイントにWebサイト、画像、動画などのコンテンツを配置することで、世界中のどこからアクセスしても、低レイテンシで快適にWebサービスを利用することが可能になります。

概要

Azure Content Delivery Networkは、Microsoft Azureが提供するコンテンツ・デリバリー・ネットワーク(CDN)です。

CDNにコンテンツをキャッシュすることが3つのメリットがあります。

・ユーザに近いところにコンテンツを配置することで、読み込みにかかる時間を小さくして、サービスの操作性を改善する。
・イベント実施時、大きなニュースの発表など際の瞬間的高負荷に対応したスケーリングができる。
・コンテンツをエッジサーバーから配信することにより、配信元サーバなどへのトラフィックを削減する。

Azure CDNはAkamaiとVerizonから提供され、目的や配信する地域に合わせて2社を選ぶことができますか

サービスとしては、以下の3つが提供されます。

・Azure CDN Standard from Akamai
Akamaiが提供。動画などのストリーミング配信にも対応する。

・Azure CDN Standard from Verizon、Azure CDN Premium from Verizon
Verizonが提供。独自ドメインのHTTPSでの配信にも対応する。Premiumになると、ルールエンジンによるURL書替などの処理、リアルタイム統計情報も提供される。

それぞれで提供されるサービスの違いは以下のようになります。

Azure Portalの「CDNのプロファイル」画面から引用

機能

・オリジン

Web Apps、Storage、Cloud Services、Media ServicesなどのAzureサービスに加えて、カスタムオリジンもサポートしており、任意の仮想マシンやオンプレ環境のリソースもCDNで配信させることができます。

https://blogs.msdn.microsoft.com/windowsazurej/2015/06/14/azure-cdn/

・圧縮

CDNでオブジェクトを圧縮して容量を削減してクライアントに配信することも可能です。圧縮を有効にすると、オリジンですでに圧縮されている場合は、CDNは圧縮したままスルーして配信し、未圧縮の場合はCDNで圧縮して配信します。圧縮するファイルタイプを指定することもできます。ただし、Azure CDN from Verizonの場合は128バイトより大きく1MB未満のファイルのみが圧縮されます。
圧縮を有効にした場合、Azure CDN from Akamaiは通常は反映は1分以内で完了、Azure CDN from Verizonは通常は反映は90分以内で完了します。

https://docs.microsoft.com/ja-jp/azure/cdn/cdn-improve-performance

・トークン認証

参照元、IPアドレス、有効期限などの条件を埋め込んだトークンを発行してCDNにアクセスさせることで、特定の許可された利用者にのみコンテンツを参照させることが可能です。Azure CDN Premium from Verizonでのみ対応しています。

https://docs.microsoft.com/ja-jp/azure/cdn/cdn-token-auth

・キャッシュの消去

TTLを待つことなく、エッジノードのキャッシュを手動で削除(Purge)することができます。CloudFrontでいうところのInvalidationです。エッジ上のキャッシュ削除には、Azure CDN from Verizonで約2~3分、Azure CDN from Akamaiで約7分かかります。

https://docs.microsoft.com/ja-jp/azure/cdn/cdn-purge-endpoint

・資産の事前読み込み

大量の更新やアクセス増加が見込まれる場合に、事前にエッジノード上にコンテンツをキャッシュとしてロードすることもできます。 Azure CDN from Verizonのみのサービスになります。

https://docs.microsoft.com/ja-jp/azure/cdn/cdn-preload-endpoint

その他

・ワイルドカードによるキャッシュ消去は、Azure CDN from Akamaiではサポートされていない。

・クエリ文字を含むURLは、クエリ文字列を無視する、クエリ文字列のあるリクエストはCDNエッジノードでキャッシュさせない、一意なクエリははキャッシュする、の3つのキャッシュ方法を選択できる。

・カスタムドメインもサポートする。

・DDoS攻撃に対する防御機能も有する。

料金

・転送量(GB単位)に応じて、ゾーンごとに定められた料金が課金されます。

・ソーン割り当ては以下の通り。
ゾーン 1: 北米、ヨーロッパ、中東およびアフリカ
ゾーン 2: アジア太平洋 (日本を含む)
ゾーン 3: 南米
ゾーン 4: オーストラリア
ゾーン 5: インド

・転送量は、南米→インド→オーストラリア→アジア太平洋(日本を含む)→北米・ヨーロッパ・中東およびアフリカの順に高い

まとめ

クラウドベンダから提供されるサービスは手軽に設定できる一方で、設定項目に制約があって痒いところに手が届かない、ということもありますが、Azure CDNの場合はかなり細かいところまで設定できそうです。また、AkamaiとVerizonがベースになっているので、もともとこれらのCDNを使っていた場合はとっつきやすく、Azureに移行することでポータルから管理も統一することができ、運用や管理面のコストが省けて良いのではないかと思います。


Azure Load Balancerを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の11日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

11日目はAzure Load Balancerです。ロードバランサーはWebサイトなどへのアクセスを各サーバに分散して振り分けてくれるもので、ロードバランサー+仮想マシンはクラウドでよく使われる構築パターンです。

概要

Azure Load Balancerは、クラウドで提供されるロードバランサーです。
ネットワーク機器であるロードバランサーのハードウェアレベルやネットワーク接続といった煩雑な設定は不要で、簡単に負荷分散環境を構築することができます。Azure Load BalancerはBasicとStandardというふたつのレベルがありますが、今回はBasicを紹介します。
なお、Standardは2017年12月10日時点でプレビューでBasicと比較して、分散先の仮想マシンが千台規模と多数の機器に分散できたり、セキュリティグループが使えたりと、Basicより機能が強化されているようです。

機能

・負荷分散
レイヤー 4 (TCP、UDP) ロードバランサーです。「負荷分散セット」に登録された仮想マシンなどのサービスに対してアクセスを振り分けることができます。この負荷分散セットは、例えば仮想マシンを作成するときに、あらかじめ負荷分散セットを指定して登録しておく必要があります。
インターネットからの通信を振り分けるパブリック(Public)なロードバランサと、Azure内部の通信を振り分ける内部的(Internal)なロードバランサーを定義できます。

・負荷分散の方式

負荷分散はは、ハッシュベースの分散アルゴリズムを使用します。デフォルトでは、送信元IP、送信元ポート、接続先IP、接続先ポート、プロトコルの5つの値を組み合わせて求められるハッシュ値(5タプルハッシュ)から振り分け先が決められます。あるIPからの接続はいつも同じインスタンスに振り分けられない可能性があります。TCPまたはUDP セッションが続く限りは同じインスタンスに送信されますが、同じIPからの接続でも、新しいセッションを開始されるとと送信元ポートが変更、ハッシュ値も変わって別のインスタンスに送信されるケースがあります。

・ポートフォワーディング

入力側のポートと振り分け先のポートはルールを決めて変換することができます。例えば、インターネットからは80番ポートで受けて、81番ポートに転送することもできます。

サービスの監視

Load Balancerからインスタンスの正常性を監視することができます。あるインスタンスが異常状態と検知されると、Load Balancerは、そのインスタンスへの振り分けを停止します。正常性の確認は3種類のプローブが提供されます。

・ゲストエージェントプローブ
仮想マシンの状態を仮想マシン内のエージェントが応答します。HTTP 200 OK応答っを正常状態として、それ以外の状態の場合は振り分けを停止します。

・HTTPカスタムプローブ
例えば、インスタンスのCPU使用率が90%を超えた場合に200以外の状態を返すようなカスタムロジックが考えられます。

・TCPカスタムプローブ
情報が少ないのですが、TCPポートとのセッションが確立できるか(ポートが空いているか?)で正常、異常を判断するというものではないかと考えています。

他の負荷分散機能との違い

Azure Load Balancer以外にもネットワークトラフィックを分散するサービスがAzureにはあります。

Azure Load Balancerは、トランスポート層で動作します(OSIネットワーク参照モデルの第4層)。AWSだとNLB相当で柔軟にTCP/UDPの振り分けができます。
Application Gatewayは、アプリケーション層で動作します(OSIネットワーク参照モデルの第7層)。AWSだとCLBからALBに相当するかと思います。SSLの終端も可能です。
Traffic Managerは、DNSレベルの分散を行います。

https://docs.microsoft.com/ja-jp/azure/load-balancer/load-balancer-overview#load-balancer-differences から引用

その他

・プローブの監視はロードバランサーのフロントIPからではなく168.63.129.16から行われる。デフォルトのセキュリティグループルールでも許可するようになっているが、誤って禁止しないように注意したほうがいい。

・IPは静的、動的とも割り当て可能。

料金

・Basic Load Balancerは無料。

・Standard Load BalancerはLoad Balancerルール数、NATルール数、データ処理量(GB単位)に応じて課金される (プレビュー期間中は無料)

・Standardも内部負荷分散であれば無料。

まとめ

Azure Virtual MachineとAzure SQL Database、そしてAzure Load Balancerがあれば、クラウド上でマネージドベースでオートスケールするシステム環境を簡単に構築することができます。現状ではBasic Load Balancerは無料で使えるので、後日負荷分散する構成を作ってみたいです。


Azure Database for PostgreSQLを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の10日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

10日目はAzure Database for PostgreSQLです。昨日紹介したAzure Database for MySQLとほぼ同じ基盤を使っています。

概要

Azure Database for PostgreSQLは、クラウドで提供されるマネージド型のPostgreSQLデータベースです。
データベースへのパッチ適用、バックアップ、監視、セキュリティ、フェールオーバー等のもろもろをAzureがよしなにやってくれます。既存のオンプレをクラウドのマネージドサービスにに移行することで、管理の手間を減らすことができます。
2017年12月7日時点では、パブリックプレビューのステータスです。

・データベース

PostgreSQL 9.6.2とPostgreSQL 9.5.7が利用可能です。
PostgreSQL拡張機能が主要なものはサポートされていますが、ユーザが独自で作成することはできません。
サポートされる拡張機能の一覧は以下にあります。

https://docs.microsoft.com/ja-jp/azure/postgresql/concepts-extensions

・リソース・性能

価格レベルと呼ばれる3つのレベルがあり、さらに各価格レベルの中で、コンピューティングユニットと呼ばれる処理性能を選択できます。

価格レベルは、Basic、Standard、そしてPremiumの3つのレベルがありますが、プレビューではPremiumは2017年12月8日時点では利用できません。

Basic:IOPS保証なしの小規模なワークロード向けです。開発環境や小規模なアプリケーションやWebサイトに向いています。
Standard:高スループットのIOPSが保証されます。中規模以上のWebアプリケーションや分析アプリケーションに向いています。
Premium:大量のトランザクションと低レイテンシが必要なワークロードに最適です。同時実行ユーザーが多く、低レスポンスが要求される、いわゆるミッション・クリティカルなアプリケーションに向いています。プレビュー段階では利用できません。


https://docs.microsoft.com/ja-jp/azure/postgresql/concepts-service-tiers から引用

コンピューティングユニットは、CPU処理性能の測定値で、CPUとメモリリソースの組み合わせです。
100個のコンピューティングユニットが1つのコアに相当します。またメモリ量はコンピューティングユニット数に比例して増えます。
同じコンピューティングユニット数でも、Basicに比べてStandardは2倍のメモリが提供されます。メモリに余裕があるため、クエリを高速に、多数の同時実行数で処理することができます。

・高可用性

ハードウェア障害などでデータベースノードに障害が発生した場合には、Azure内部でフェールオーバーされます。切り替えに伴い、数十秒データベースが中断しますが、ユーザのアプリケーション側での接続先の切り替え等は必要はありません。

・バックアップ

自動バックアップが5分おきに取得されます。バックアップの保持期限はBasicが7日、Standardが35日です。バックアップを使って新しいサーバを作ることで、過去のある時点のデータベース状態に復元することができます。

・セキュリティ

SQL Databaseと同じように許可IPのホワイトリストをAzure Portalから、「サーバー ファイアウォールの設定」から定義できます。

その他

・Standard同士など、同じ価格レベル内でのコンピューティングユニット数の変更は可能(数十秒程度の処理中断あり)。BasicからStandardのように異なる価格レベルへの変更はできない。

・サーバーログは、Azure PortalとAzure CLI、Azure REST APIを使用して、一覧表示およびダウンロードできます。ログの保存期間は既定値は3日間、最大7日間に設定できます。ログのローテーションは、1時間ごとか100MBごとのどちらか早い方のタイミングで行われます。

・マイナーバージョンアップは自動管理される。パブリック プレビュー段階では、メジャー バージョンのアップグレードはサポートされない。PostgreSQL 9.5 から PostgreSQL 9.6へのアップグレードはできない。

・プレビューでは、既存のサーバー上のストレージサイズの変更はできない。サーバー作成時にストレージ容量を選択する。

料金

・現在はプレビュー料金となっているため、今後価格が変更される可能性があります。

・Basicはコンピューティングユニット50と100が選べます。ストレージは50GBを標準で含み、以降はGB単位で課金されます。

・Standardはコンピューティングユニット100/200/400/800が選べます。ストレージは125GBを標準で含み、以降はGB単位で課金されます。ストレージが増えるとGBごとにIOPSも3ずつ増えていきます。

・Premiumは未公開。

まとめ

仮想マシンはAzure Database for MySQLと同じものを使っているようで、価格レベルやコンピューティングユニット数の組み合わせは同じです。プレビュー版ということもあり、SQL Databaseと比べると不足している機能もありますが、今後の機能追加と早い時期に正式サービスとなることを期待したいと思います。


Azure Database for MySQLを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の9日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

9日目はAzure Database for MySQLです。データベースは、メインフレーム系からExadataまでいろいろやってきたので好きな分野のひとつです。

概要

Azure Database for MySQLは、クラウドで提供されるマネージド型のMySQLデータベースです。
データベースへのパッチ適用、バックアップ、監視、セキュリティ、フェールオーバー等のもろもろをAzureがよしなにやってくれます。OSSで多くのシステムで使われているMySQL。既存のMySQL環境からクラウドに移行することで、管理の手間を減らすことができます。
2017年12月7日時点では、パブリックプレビューのステータスです。

・データベース

InnoDBエンジンを使用したMySQL Community Editionが利用できます。MySQL 5.6.35とMySQL 5.7.18が利用可能です。

・リソース・性能

価格レベルと呼ばれる3つのレベルがあり、さらに各価格レベルの中で、コンピューティングユニットと呼ばれる処理性能を選択できます。

価格レベルは、Basic、Standard、そしてPremiumの3つのレベルがありますが、プレビューではPremiumは2017年12月8日時点では利用できません。

Basic:IOPS保証なしの小規模なワークロード向けです。開発環境や小規模なアプリケーションやWebサイトに向いています。
Standard:高スループットのIOPSが保証されます。中規模以上のWebアプリケーションや分析アプリケーションに向いています。
Premium:大量のトランザクションと低レイテンシが必要なワークロードに最適です。同時実行ユーザーが多く、低レスポンスが要求される、いわゆるミッション・クリティカルなアプリケーションに向いています。プレビュー段階では利用できません。


https://docs.microsoft.com/ja-jp/azure/mysql/concepts-service-tiers から引用

コンピューティングユニットは、CPU処理性能の測定値で、CPUとメモリリソースの組み合わせです。
100個のコンピューティングユニットが1つのコアに相当します。またメモリ量はコンピューティングユニット数に比例して増えます。
同じコンピューティングユニット数でも、Basicに比べてStandardは2倍のメモリが提供されます。メモリに余裕があるため、クエリを高速に、多数の同時実行数で処理することができます。

・高可用性

ハードウェア障害などでデータベースノードに障害が発生した場合には、Azure内部でフェールオーバーされます。切り替えに伴い、数十秒データベースが中断しますが、ユーザのアプリケーション側での接続先の切り替え等は必要はありません。

・バックアップ

自動バックアップが5分おきに取得されます。バックアップの保持期限はBasicが7日、Standardが35日です。バックアップを使って新しいサーバを作ることで、過去のある時点のデータベース状態に復元することができます。

・セキュリティ

SQL Databaseと同じように許可IPのホワイトリストをAzure Portalから、「サーバー ファイアウォールの設定」から定義できます。

その他

・Standard同士など、同じ価格レベル内でのコンピューティングユニット数の変更は可能(数十秒程度の処理中断あり)。BasicからStandardのように異なる価格レベルへの変更はできない。

・サーバーログは、Azure PortalとAzure CLIを使用して、一覧表示およびダウンロードできます。ログは、最大7日間保存されます。ログの合計サイズが7.5GBを超える場合は、古いファイルから削除されます。ログのローテーションは、24時間ごとか7.5GBごとのどちらか早い方のタイミングで行われます。

・マイナーバージョンアップは自動管理される。パブリック プレビュー段階では、メジャー バージョンのアップグレードはサポートされない。MySQL 5.6から MySQL 5.7へのアップグレードはできない。

料金

・現在はプレビュー料金となっているため、今後価格が変更される可能性があります。

・Basicはコンピューティングユニット50と100が選べます。ストレージは50GBを標準で含み、以降はGB単位で課金されます。

・Standardはコンピューティングユニット100/200/400/800が選べます。ストレージは125GBを標準で含み、以降はGB単位で課金されます。ストレージが増えるとGBごとにIOPSも3ずつ増えていきます。

・Premiumは未公開。

まとめ

Azure SQL Databaseなどと同じくMySQLもAzure上でマネージドサービスとして利用できます。MySQLは手軽で使いやすく、特にOSSのプロダクトと組み合わせて使うことが多いため、管理不要で使えるのは魅力的です。プレビュー版ということもあり、SQL Databaseと比べると不足している機能もありますが、今後の機能追加と早い時期に正式サービスとなることを期待したいと思います。


IoT Centralを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の8日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

8日目はIoT Centralです。12月5日にパブリック・プレビューが開始されました。

https://japan.zdnet.com/article/35111485/

Azureサービスではないですが、IoT CentralはAzure IoT SuiteやAzure IoT Hubとも連携し、パブリック・プレビュー版を触ってみたところ面白かったので紹介していきます。

概要

IoT CentralはフルマネージドのIoT SaaSです。

IoT機器からの情報収集、蓄積、可視化、アラートなどの機能をSaaSとして提供してくれます。
Azure IoT Hubは、IoT機器がMQTT、HTTPS、AMPQPSなどのプロトコル通信するためのインフラとや端末認証基盤を提供し、Azure IoT SuiteはIoTアプリケーションのバックエンドを開発のためのカスタマイズや管理提供するPaaSでIoT Centralはこれらと連携します。

IoT Centralでは以下のような機能が提供されます。

・IoT機器の接続とデータの収集
・ダッシュボード上でのデータの可視化、分析
・ルールを設定して設定した条件が満たされるとこれをトリガーに、アラート通知などのアクションを実行

さらに詳しいことは以下のサイトで紹介されています。(英語)

https://docs.microsoft.com/ja-jp/microsoft-iot-central/overview-iot-central

パブリック・プレビュー版を使ってみた

パブリック・プレビューに登録して、基本機能を触ってみたので紹介します。

https://www.microsoft.com/en-us/iot-central/get-started/ からサインインします。

サインインすると、「Create Application」のフォームが表示されます。
アプリケーション名、利用するディレクトリ、サブスクリプション、リソースグループ、リージョンを入力します。

アプリケーションテンプレートを選択します。とりあえず試すだけなら Custom Application、Raspberry Piを実際につなぐなどSDKを使いたい場合は Sample Devkits を選ぶといいようです。今回は Custom Application を選択します。
支払プランを選びます。30日の無料枠があるのでこちらを選択します。通常だと月500ドルとなります。有償の場合には試してみるには少しお高いので、別プランを用意して使いやすくしてもらえるとよいです。[Create]を押すとアプリケーションの作成が開始されます。

アプリケーションのダッシュボード画面から Create Device Templateを選択します。

デバイステンプレート名を入力します。

表示名、単位などを入力していきます。

デバイスが作成され、何かの値が取れていることが確認できます。今回は、シミュレートされた仮想の機器のテレメトリー値が表示されています。

なお、グラフのタイプはLine、Smooth、Step、Scatterの表示が選べます。

[Rules]を選択してみます。現状ではTelemetryのみ利用可能です。機器のテレメトリーを監視してアクションを起こすことができます。今回はこれを選びます。
現状では、Coming Soonになっていますが、機器の状態変化、イベント、接続断を検知できるイベントも今後利用可能となるようです。

次の画面で閾値と条件(以上、以下など)を入力します。

アクションも設定できます。現在使えるのはEmailのみです。今後はWebhook、SMS、SAPやSalesforceなど外部システム連携、Logic Appsの呼び出し、Azure Functionsの呼び出し、Dynamics 365との連携も予定されているようです。

Emailを選ぶと、通知先のメールアドレスを指定できます。閾値、通知先とも設定してみましたが、メールは来ませんでした。シミュレータの場合は何か制約があるのかもしれません。

料金

・30日間の無料お試し期間の場合は、10台までの機器、100MBまでのデータ転送が可能です。

・有償プランの場合は、月500ドルの固定料金で100台の機器、1000MBのデータ転送が可能です。

・デバイスを追加する場合は1台0.5ドル/月、10MBのデータ転送がついてきます。

・追加のデータ転送は、1GBあたり30ドルです。

まとめ

実機での接続は試せていませんが、接続から可視化、分析まで一貫してIoT Central上で行えるので、IoTの初期構築やその後の管理の手間がかなり省けそうで、魅力あるサービスです。Raspberry Piなど実機を使って今後検証したいと思います。


Azure SQL Data Warehouseを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の7日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

7日目はAzure SQL Data Warehouseです。昨日のCosmos DBに続きデータベース系サービスです。

概要

Azure SQL Data Warehouseは、クラウドのデータウェアハウスです。データは並列に接続されたサーバで処理され、テラバイト、ペタバイト級のデータに対して短時間でクエリ結果を得ることができます。AWSでいうとRedshift、GCPだとBigQueryに相当するサービスです。

・データベース

SQL Data Warehouseはカラム型ストレージを使用してデータを格納します。データのストレージ容量を節約するとともに、クエリのパフォーマンスが改善されます。さらに並列処理により、これまで日単位の時間がかかっていたクエリが、時間単位で処理できるようになります。

・性能

分析ワークロードに最適化された2つのパフォーマンスレベルが提供されます。

弾力性パフォーマンスレベルのための最適化:
単語が分かりにくいですが、英語だとThe Optimized for Elasticity performance tierとなります。「エラスティック用に最適化」と表記される場合もあります。
コンピューティング層がストレージ層と分離されているので、コンピューティング層のスケーリングを頻繁に行うことができます。
データはコンピューティング層のローカルにはなく、ネットワーク経由でSSDストレージ上に置かれており、この大量のデータをコンピューティング層が柔軟に並列、スケールして処理していくイメージです。このレベルが最も安価で、ワークロードの大半をサポートできます。

コンピューティングパフォーマンスレベル用の最適化:
英語だとThe Optimized for Compute performance tierとなります。「計算用に最適化」と表記される場合もあります。
超高速なワークロードに適したレベルです。ハードウェアは最新のものを利用し、NVMe接続のSSDのキャッシュが提供されます。すべてのIOがコンピューティング層のローカルで行われるので、複雑なクエリをさばくことができます。サイズ制限なしでデータを格納できるように列ストアも強化されています。
同じcDWUだと、弾力性のために最適化されたパフォーマンスレベルに比較して2.5倍のメモリが提供されます。メモリに余裕があるため、クエリを高速に、多数の同時実行数で処理することができます。

https://docs.microsoft.com/ja-jp/azure/sql-data-warehouse/performance-tiers から引用

・リソース

SQL Data Warehouseのリソースは、CPU、メモリ、IOからなるData Warehouse ユニット(DWU)という単位で決定します。ユニット数を増やすほど性能は向上します。パフォーマンスレベルでDWUの測定単位は若干異なり、「弾力性パフォーマンスレベルのための最適化」ではData Warehouse ユニット(DWU)、「コンピューティングパフォーマンスレベル用の最適化」ではコンピューティングData Warehouseユニット(cDWU)で測定されます。
DWUは明示的に増減させることもできます。DWU変更を行うと、継続中のトランザクションを中止、ロールバックして一貫性のある状態を確保してから、スケーリングが行われます。完了までには数分かかります。
DWUはSQL Data Warehouseが稼働している間だけ課金されます。夜間・休日など利用しない時間にSQL Data Warehouseを停止することで、コンピューティング分の課金を節約できます。停止している場合もストレージには利用サイズに応じて課金されます。

・バックアップ

4~8時間ごとにスナップショットが作成され、7日間使用できます。また、SQL Data Warehouseでは、8時間の回復ポイントの目標(RPO)を定めており、8時間前のデータまでさかのぼって復旧できます。
geoバックアップは、1日に1回、ペアのデータセンターにSQL Data Warehouseのバックアップを保管します。geo復元のRPOは24時間です。geoバックアップからgeoペアリージョン内のサーバーに復元できます。geoバックアップは標準で有効になっています。

・セキュリティ

SQL Databaseと同じように許可IPのホワイトリストをAzure Portalから、「サーバー ファイアウォールの設定」から定義できます。
透過的データ暗号化(TDE)も設定可能です。Azure Portalから有効/無効を設定できます。

その他

・データベースエンジンはSQL Server

・データのロードにはbcpコマンドだけでなく、PolyBaseによるBlob Storageからの高速ロード、Data FactoryのGUIでのロードも可能
・データは60個ののディストリビューションと呼ばれる単位に分割して保存される。振り分け方は、ラウンドロビンとハッシュ分散が選べる

・データはPremium Storageに格納されるのでSSDで高速(だけど高い)

料金

・コンピューティングリソースはパフォーマンスレベル(エラスティック用に最適化か計算用に最適化)とDWUで課金される

・ストレージはTB単位でPremium Storage料金(12,533.76円/1 TB/月)で課金。データウェアハウス本体のデータと7日分の増分スナップショット ストレージが含まれる

・geoバックアップにはStandard Diskの読み取りアクセスのGeo冗長ストレージ(12.24円/GB/月)で課金。

まとめ

超高性能なData Warehouse環境を、Azureクラウドの力を借りて簡単に使い始めることができます。
停止中はコンピューティングリソースに課金されなかったり、ストレージIO量に課金されずコストの見通しを立てやすいことは、他社クラウドのDWHにはない強みだと思います。


Azure Cosmos DBを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の6日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

6日目はAzure Cosomos DBです。昨日のSQL Databaseに続きデータベース系サービスです。

概要

Azure Cosomos DBは、低レイテンシで、世界中のデータセンターにグローバルに分散したデータベースをクラウド上で構築できるサービスです。AWSでいうとDynamoDB、GCPだとCloud Spannerに相当するサービスです。

・データモデル
ドキュメント、グラフ、キーと値、テーブル、列指向の各データモデルを利用できます。
DocumentDB:JSONベースのデータに対してSQLクエリによる操作ができます。
MongoDB:ドキュメント指向のデータベース。名前の通りMongoDBライブラリ、ドライバー、ツール、アプリケーションと互換性があります。
Table API:Key-Value型データベースです。Storageサービスの一部だったTable StorageがCosmos DBに統合されました。
Graph (Gremlin):グラフ型データベースを提供します。
Cassandra API: Apache Cassandra実装で構築されたKey-Value型データベースです。

・グローバル分散
一部のリージョンを除いて、全リージョンに対してレプリケートできます。どのリージョンにレプリケートするか、フェールオーバー時にどのリージョンを優先的に使うかなどの設定も可能です。

・性能・スケール
Cosmos DBでは、要求ユニットという単位でCPU、メモリ、IOPSが割り当てられます。新しいコレクション、テーブル、グラフを使い始める時に、1秒あたりの要求ユニット(RU/秒) を指定します。
ストレージについては、容量の上限はありません。テーブルなどデータが作った分だけ、GB単位で課金されます。

Cosmos DBは割り当てられた要求ユニット数に基づいて、物理パーティションを割り当て、データの増加に応じてデータ分割やバランス調整を行います。
この要求ユニットですが、データベースに対する読み取り、書き込み、クエリなど操作の種類によって、消費される要求ユニット数は変わってきます。ある操作で使用された要求ユニット数は、リクエストに対するレスポンスヘッダーに含まれており、そこで確認できます。要求ユニット数に影響を与える要因は下表のようなものがあります。

https://docs.microsoft.com/ja-jp/azure/cosmos-db/request-units から引用

事前に指定した秒間の要求ユニット数を超えた場合は、操作は実行できず、超過が解消するまで待機となります。このスロットルが発生すると、RequestRateTooLargeException (HTTP状態コード 429) のレスポンスを返し、ヘッダの x-ms-retry-after-ms で待機しなければならない時間がミリ秒で返ってきます。なお、.NET クライアントSDKを使っている場合は、SDKが待機と再試行を行ってくれるため、アプリロジックでの考慮は不要になります。

・整合性レベル
5つの整合性レベルが提供されます。レベルによって、整合性、可用性、待ち時間、スループットが変わってきます。
厳密(Strong)、有界整合性制約(Bounded Staleness)、セッション(Session)、一貫性のあるプレフィックス(Consistent Prefix)、、結果的(Eventual Consistency)の順に一貫性は弱くなりますが、低レイテンシでIO性能、スループットは良くなっていきます。

https://docs.microsoft.com/ja-jp/azure/cosmos-db/consistency-levels から引用

・バックアップ
Cosmos DBは4時間ごと自動バックアップを取得し、最新2世代のバックアップが保存されます。データの破損などで自動バックアップから復旧させたい場合は、ユーザ自身の操作ではできず、8時間以内にAzureサポートに連絡する必要があります。

・セキュリティ
データはCosmos DBへの保存時に暗号化されます。ユーザで意識する必要はありません。

その他

・Strong一貫性を使用する場合は、複数のリージョン分散はできない。

・Azure Cosmos DB Emulatorというローカル マシンでCosmos DBを使ったアプリケーションの開発とテストを行うことができるツールも提供されている。AWSのDynamo DBにもDynamoDBローカルがあるけど、NoSQL系だけローカル開発ツールが提供されている理由を知りたい。 https://docs.microsoft.com/ja-jp/azure/cosmos-db/local-emulator

・要求ユニットの計算ツールも提供されている https://www.documentdb.com/capacityplanner

・インデックスの指定有無、パーティションの分割もできる模様。

料金

・データが格納されたSSDストレージにGBあたりで課金される(¥25.50 GB/月)

・予約済みの要求ユニット数(RU)に対して課金される(100RUごと、最低400R)

・他リージョンにレプリケーションを持つ場合は、リージョン数分に課金される

・レプリケーションに伴うリージョン間データ転送にも課金される。

まとめ

AWS、GCPでもグローバル分散型のデータベースは提供されますが、Cosmos DBはドキュメントDB、グラフ型DB、キー・バリュー型など様々なデータモデルを1サービスで使えるところは他クラウドにはなく魅力的です。Azure FunctionsとCosmos DBを組み合わせれば、今流行りのサーバレス構成も、すぐに構築できます。さらにMachine LearningやCognitiveサービスも組み合わせて、サーバレスでいろいろできるアプリを作ってみたいです!


Azure SQL Databaseを解説 【シリーズ Azureサービスいちから紹介】

このエントリはQiita Advent Calendar 2017 Microsoft Azureサービスいちから紹介 の5日目です。

ナレッジコミュニケーションの大柳です(@oyngtmhr)

5日目はAzure SQL Databaseです。Azureにおけるデータベースサービスの中心的存在です。

概要

Azure SQL Databaseは、Microsoft SQL Serverデータベースエンジンをベースとしたデータベースシステムを提供するマネージド型のサービスです。

・リソースのサイズ

Basic、Standard、Premium、Premium RSの4つのサービスレベルが提供されます。
Basic、Standard、Premiumの順で利用可能なリソース量、自動バックアップの期間などが拡大されます。
Premium RSは耐障害性を犠牲にする代わりに、Premiumと同等の性能をコストを抑えて利用することができます。

https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-service-tiers から引用

サイズはDTU(Database Transaction Unit)という単位で定義され、CPU、メモリ、I/Oの組み合わせからなります。
DTUが大きくなるほど、コンピューティングリソースが多く使えるようになり、標準で付属するストレージ、追加できるストレージも大きくなります。後述するように、ダウンタイムを発生させずにスケールの変更ができます。

https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-technical-overview から引用

・バックアップ

Azure SQL Databaseでは、完全バックアップ、差分バックアップ、トランザクションログバックアップが自動的に実行されます。
ポイントインタイム・リストアで、自動バックアップの期間内の任意の時点への回復もサポートされます。

・可用性

アクティブgeoレプリケーションを使用すると、同じデータセンター内、または世界各地のリージョンに分散して、最大4つの読み取り可能なセカンダリデータベースを構成でき、読み取り処理の負荷分散ができます。
また、フェールオーバー・グループを使えば、障害時のグローバルスケールでの負荷分散もできます。監視やルーティング、フェールオーバーの手当は、Azure SQL Databaseが面倒を見てくれます。

・SQLエンジン

2017年12月4日時点のエンジンは以下の通りでした。


Select @@version

Microsoft SQL Azure (RTM) - 12.0.2000.8
Nov 29 2017 09:37:51
Copyright (C) 2017 Microsoft Corporation

Azure SQL Databaseがある機能に対応しているかはAzureのオンラインドキュメントに記載されたタグを確認すれば分かります。

・スケールの変更

データベースのサービスレベルやDTUをオンラインで変更できます。内部的には、新しいインスタンスサイズで元のデータベースのレプリカが作成され、レプリカにデータの移行が完了したら、接続先が新レプリカに切り替えられるようです。切り替え時間の際には、通常4秒の間、トランザクションが受けられなくなります。

・セキュリティ

不審なデータベースアクセス、潜在的な脆弱性、SQLインジェクショ攻撃、が見つかった場合に、ユーザーにアラートを通知することもできます。
透過的データ暗号化(TDE)も2017年5月以降に新しく作成されたデータベースは、自動的に適用されるようになっています。
Virtual Machineのセキュリティグループに相当する許可IPのホワイトリストもAzure Portalから、「サーバー ファイアウォールの設定」から定義できます。

その他

・スケールアップに伴うレプリカの作成にかかる時間は変更前後のデータベースのサイズとサービスレベルによって変わる。Standard同士で、250GBのデータベースなら6時間以内、Premiumサービスレベル内で250GBなら3時間以内で完了する、と公式ドキュメントより。

・メンテナンスもあると想像しているけどドキュメントから記載見つけられず。

・Data Lakeを使えばAzure Portal上でデータのロードができる。bcpコマンドも使える。データベースが動くマシンにOSログインはできないのでローカルファイルから読み込むような処理ができないのは、AWS RDSとかと同様

・単一のデータベースではなく、ある一定のプールを割り当てそこから必要なリソースを利用するエラスティックプールと呼ばれる使い方もある。エラスティックプールを利用することで、DBのコストを一定で予測可能にすることができる。

・SQL Database以外のデータベースでは、マネージド型のAzure Database for MySQLとAzure Database for PostgreSQLも提供されている。

・SQL DatabaseはDDLにも明示的なコミットが必要。OracleはDDLは暗黙コミットなので、Oracleと同じだと思い込んでいるとはまる(はまった)。

料金

・課金はサービスレベルとDTUに応じて利用した時間に対して課金される。最小構成のBasic、5DTUなら月570円。

・通常割り当てサイズを超過するストレージは1GB単位で課金される。

・アクティブgeoレプリケーションを使う場合は、マスタと同じ価格が、各レプリケーションサイトにも課金される。

・脅威検出のオプションは有料となる。60日間の無償使用期間あり。

まとめ

オンプレでのSQL Serverは、インストール、構築が大変なイメージがあり、Azure上でSQL Databaseだとすぐに手軽にデータベース環境を構築できるのはとても魅力的です。バックアップ、可用性、セキュリティなど一通りの機能も標準で提供され、手数を少なくして、ビジネス用途にも耐えうるデータベース環境を構築できそうです。