SQL Datababse Migration InstanceのIOPSの考え方

SQL ServerをAzure上に配置する場合、ディスクごとにIOPSのキャップがかかるので、データファイルを複数のディスクに分散配置させることでパフォーマンスを向上させることができます。

SQL Database Managed Instanceの場合はこれとは異なり、Premium Storageがデータファイルごとに使われるため、データファイルごとにIOPSのキャップがかかります。このため、データファイルの数やサイズの設計を考える必要があります。

Premium StorageはP10～P50が使われ、データファイルの大きさに従って動的に切り替わります。例えばデータファイルの大きさが100GBの場合はP10が使われるため、IOPSのキャップは500になります。大きさが200GBになるとP10のサイズは128GBであるためP20に切り替わり、IOPSのキャップが1100になります。
データファイルのサイズが小さくなる場合も同様の動きになります。例えば、200GBのデータファイルが100GBに縮小された場合、P20からP10に切り替わり、IOPSのキャップは500になります。

自分のPCからAzure DCへの通信速度を計測する方法

自分のPCのブラウザから、Azureの各データセンターへの通信速度が計測できます。
地方にお客様がいる場合、どこのデータセンターが近いかを確認できますね。

http://azurespeedtest.azurewebsites.net/

Azure Active DirectoryのExpressRouteサポートが変わったようです

以下、結構要注意なので備忘録を兼ねて。

ExpressRouteでPublicピアリングやMicrosoftピアリングを有効にして利用している環境では、Azure ADに対する認証トラフィックがExpressRouteを経由していました。
これが 2018 年 8 月 1 日から次のように変更されます。
Microsoftピアリング、かつExpressRouteを利用するサービスとして“その他のOffice 365 Onlineサービス (12076:5100)”のBGPコミュニティを利用するように構成されている場合のみExpressRouteを経由する。

ただし、2018/5/1現在ではサポートリクエストをあげることにより利用可能となっているようです。

詳細は以下のURLを参照してください。
https://blogs.technet.microsoft.com/jpazureid/2018/07/19/azuread-expressroute/

SQL Data WarehouseのGen2 アーキテクチャがGAになりました

従来のSQL Data Warehouseのアーキテクチャに加えてGen2と呼ばれるアーキテクチャがGAになりました。 これはメモリやディスク配置のキャッシュを使い、アクセスが多いデータを透過的にキャッシュする機構を持っています。また、同時クエリも128までに拡大されました。

ただし、2018/5/1現在ではサポートリクエストをあげることにより利用可能となっているようです。
詳細は以下のURLを参照してください。
https://azure.microsoft.com/en-us/blog/blazing-fast-data-warehousing-with-sql-data-warehouse-gen2/

pythonでdlibのインストール、インポートでエラーが発生する場合

以下、Windows環境での対応

「pip install dlib」を実行するとcmakeの実行でエラーが起きる場合は、「conda install -c menpo dlib」を実行してみる。

python実行時に「import dlib」で「ImportError: DLL load failed」エラーが発生する場合、CNTK環境の場合はzlib.dllのファイル名を変更してみる。(他への影響は検証中)

Azureで日本語化済みWindows環境をゴールデンイメージにするときの注意点

AzureでWindows Serverの仮想マシンを作成すると英語環境になるので、これを日本語化してゴールデンイメージを作成することが多いと思います。

ゴールデンイメージの作成は以下のドキュメントの手順に沿えばできるのですが、
Azure で一般化された VM の管理対象イメージを作成する

これを行う前に、コントロールパネルの「地域」から「ようこそ画面と新しいユーザーアカウント」セクションの「設定のコピー」を選択して、新しいユーザーアカウントに現ユーザーの設定をコピーしてください。これを行うことで、作成したゴールデンイメージから作成した仮想マシンのユーザーも日本語になります。

CPU脆弱性に対する各パブリッククラウドベンダーの対応

年始に騒がれたCPU脆弱性に対して、各パブリッククラウドベンダーの対応状況をまとめて頂いているサイトがあったので備忘録として。
Azure、AWS、GCP、Alibaba CloudのCPU脆弱性対応のまとめ

Azure VMからの送信通信量はMicrosoftは管理できないということ

Microsoftに限らずパブリッククラウドサービスではクラウド利用者とクラウド提供事業者の間で責任範囲を分担しています。例えばIaaSで言えばハードウエア、ホストOSまでのレイヤでは事業者に責任があり、ゲストOSより上位のレイヤは利用者に責任があるということになります。

責任分担の考え方からいうと、VM内部のOS以上のレイヤーで行っている通信内容は利用者の持ち物ということになりますので、Microsoftではデータプライバシーの観点からも原則的にVMの通信に干渉したり、通信内容や宛先を記録することは行っていません。

AzureではVMからインターネットまたは他のデータセンターに出ていく通信に対しては料金が発生しますが、上記の理由からMicrosoftではこの通信量について調査することはできません。ですが、利用者が通信量を調査できるようにする仕組みは提供していますので、これをうまく活用して通信量を把握しましょう。

詳細は以下のリンクを参照してください。
VM からの送信方向の通信量 (Data Transfer Out) について

Azure VM からのメール送信に関する動作変更について

Azureでは、Azure上のVMから直接SMTP等を使ってメール送信することはプラットフォームとしてサポートをしていません。その代わりにSMTPリレーサービスを利用することを推奨しています。詳細は以下のリンクを参照してください。
Azure 上にメールサーバー/SMTP サーバーを構築する場合の注意事項

この動作は不正なユーザーによるAzureからのスパムメールの送信やIP アドレスのレピュテーション(メールの送信元としての信頼性)を保ち、正当な利用を行っているお客様に対して影響が及ばないようにするためのものですが、この対策がさらに強化され、Azure VMから外部ドメインへの直接のメール送信は、特定の契約種別のサブスクリプションでのみ許可するよう動作が変更されました。許可されていない契約種別のサブスクリプションにおいては、Azure VMからのTCP/25 ポートによる外部へのメール送信を Azureプラットフォームがブロックする動作が加わります。ただし、これは2017年11月15日以降に作成されたサブスクリプションのみに適用されます。詳細は以下のリンクを参照してください。
Azure VM からのメール送信に関するアナウンス (2017 年 11 月)