浅草橋青空市場

Microsoft Azure のニュースや情報を中心にあれこれと

サービスプリンシパル(パスワード)でAzure AutomationのRunbookを実行する

「仮想マシンの定期的な起動・停止」みたいな定期作業をAzure AutomationのRunbookで実行したいという話は良くあると思います。 が、サービスプリンシパル(パスワードの方)を使ったブログ記事やサンプルが意外と見つからなかったので書いておきます。

※ 証明書を使う方法は公式ドキュメントにあったはず

サービスプリンシパルについて

そもそも何？という話は真壁先生のスライドをどうぞ。

www.slideshare.net

簡単な作りは他はこちらの記事を。作成にはAzure ADにしかるべき権限が必要なので、無い場合は作ってもらいましょう。

asazure.hatenablog.jp

Automation Accountの作成

公式ドキュメントをどうぞ。こちらも「Azure実行アカウントの作成」を行うにはAzure ADに権限が必要です。

docs.microsoft.com

アセットの登録

スクリプト内で使う資格情報やテナントIDなどはAutomation Accountのアセットとして登録します。今回のスクリプトでは、サービスプリンシパルを「Credentials」に、テナントIDを「Variables」に登録しました。

サービスプリンシパルのAppIdをCredentialの「User name」に、パスワードを「Password」に登録します。テナントIDはVariableにStringとして登録しましょう。

f:id:yhara90:20180407224037p:plain

仮想マシン起動・停止のサンプルスクリプト

こんな感じです。PowerShell WorkflowタイプのRunbookとして使えます。

パラメーターはそれぞれ以下のようになります。実行時やタイマーにセットしておきましょう。

  • CredentialName : アセットに登録したサービスプリンシパルのCredential名
  • ResourceGroup : 操作対象のリソースグループ名
  • Action : 「Stop」もしくは「Start」
workflow Stop-Start-AzureVM
{
    Param 
    (    
        [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] 
        [String] 
        $credentialName,
        [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] 
        [String] 
        $ResourceGroup,
        [Parameter(Mandatory=$true)][ValidateSet("Start","Stop")] 
        [String] 
        $Action 
    ) 
     
    $credential = Get-AutomationPSCredential -Name $credentialName
    $tennantId = Get-AutomationVariable -Name 'tennantId'
    Login-AzureRmAccount -Credential $credential -Tenantid $tennantId -ServicePrincipal
 
    $AzureVMs = Get-AzureRmVM -ResourceGroup $ResourceGroup
 
    if($Action -eq "Stop")
    { 
        Write-Output "Stopping VMs"; 
        foreach -parallel ($AzureVM in $AzureVMs) 
        { 
            $AzureVM | Stop-AzureRmVM -Force
        } 
    } 
    else 
    { 
        Write-Output "Starting VMs"; 
        foreach -parallel ($AzureVM in $AzureVMs) 
        { 
            $AzureVM | Start-AzureRmVM
        } 
    } 
}

Azure Database for MySQL / PostgreSQL がGAしましたね

Azure Database for MySQL / PostgreSQL がGAとのアナウンス。お待ちしてました。

azure.microsoft.com

併せて、セキュリティとコンプライアンスのアナウンスも。

Securing Azure Database for MySQL and Azure Database for PostgreSQL | Blog | Microsoft Azure

Compliance offerings for Azure Database for MySQL and Azure Database for PostgreSQL | Blog | Microsoft Azure

SLAはSQL Databaseと同じく99.99%。なのですが、SLAのページを見るとMonthly uptime percentageが「< 99.9%」となってます(SQL DBと違う)。

(追記：2018年4月10日) いま見たら99.99%と表記されていました。

SLA for Azure Database for MySQL

GA価格は5月1日から適用、それまでは50%オフとのこと。コア数で比べるとRDS for MySQLのSingle-AZと同じくらいの金額ですかね。ベンチマークを取るとまたちょっと違った特性があるようなので、単純な比較はちょっと難しいかな？という印象でした。

サーバーをデプロイした後にPricing tier変更はまだできないようです。東日本、西日本ともハードウェアはGen4で、Memory Optimizedもまだ選べませんでした。

(追記： 2018年4月10日) こちらも東日本、西日本ともGen5、Memory Optiomizedとも選べるようになっていました。またストレージも最大2TB(6,144 IOPS)まで指定できるようになっていました。

azure.microsoft.com

ARMテンプレートのリファレンスはこちら。これも今後の充実に期待ですね。

docs.microsoft.com docs.microsoft.com

基本的なメトリックはAzure Monitorで取得出来ます。

docs.microsoft.com

ログはCLIでダウンロードする方式です。

docs.microsoft.com

そしてClearDBはMarketplaceから削除されたようです。これまでお世話になりました。

ClearDB removal from the Azure Marketplace

(追記： ARMのテンプレートを作っておきました)

gist.github.com

Hyper-Vの.vhdファイルからAzure仮想マシンのイメージを作成する(ポータルのGUIで)

たぶんもうちょっと前からあった機能だとは思いますが、ポータルのGUIから仮想マシンのイメージが作れたので記録しておきます。
「日本語版DVDからインストールしたWindows Server 2016が欲しい」というリクエストがあったのでやってみたらできました。

ここで紹介する手順は、いわゆる「仮想マシンのひな形」としての「イメージ」を作る手順なので、仮想マシンをそのままコピーする手順ではありません。そちらのケースは、今のところ.vhd経由だとGUIでは完結しないので、どうしてもと言うことであればAzure Site Recoveryをつかうとか別のアプローチになると思います。

Hyper-V 仮想マシン側の準備

基本的には公式ドキュメントにあるとおりに準備を進めて、Azure用の.vhdファイルを作ります。

docs.microsoft.com

Hyper-V仮想マシンが第2世代の場合はこのあたりで第1世代に変換しておくのが良いと思います。

第２世代仮想マシンを第１世代仮想マシンに変換

.vhdxから.vhdへの変換や固定サイズ化などは、Hyper-VマネージャのGUIでもできます。

www.atmarkit.co.jp

ちなみに、一部の仮想マシンシリーズではNested Virtualizationをサポートしているので、Azure仮想マシン上でHyper-Vを立ち上げてこのあたりの作業を進められるようになりました。Dv3やEv3シリーズあたりがそれです。

Azure Storageへのアップロードには、Azure Storage Explorerも使えます。「ページBLOB」としてアップロードしましょう。

azure.microsoft.com

「イメージ」の作成

アップロードが終わったらイメージの作成です。「イメージ」ブレードを開きます。

f:id:yhara90:20180114090518p:plain

「追加」をクリックします。

f:id:yhara90:20180114090557p:plain

名前などを適宜付けていきます。「ストレージBLOB」で、アップロードした.vhdを指定します。

f:id:yhara90:20180114090625p:plain

「作成」を押してしばらくすると、仮想マシンのイメージが出来上がります。

仮想マシンの作成

「イメージ」ブレードからイメージを開いて「VMの作成」をクリックします。

f:id:yhara90:20180114090752p:plain

あとはいつも通りに仮想マシンを作るだけです。

f:id:yhara90:20180114090903p:plain

ここまで。

気付かないうちにポータルもどんどん便利になりますね。

Azureクラシックポータルが終息

既報の通り、クラシックポータルが2018/1/8をもって終息していました。URLにアクセスすると現行ポータルにリダイレクトされるようになっていました。 https://manage.windowsazure.com/

▼クラシックポータル終息のアナウンス

Azure portal update for classic portal users

移行ガイド的なドキュメントが12月に公開されていたようなので参考まで。

docs.microsoft.com

念のためですが、クラシックリソース(クラシックVMやクラシックVNet)については引き続き現行のAzureポータルからアクセスできます。

クラシックポータルにはずいぶんとお世話になりましたので、ちょっと寂しいですね。

Azure仮想マシンのメンテナンスを見守ったメモ

(2018年1月25日 追記)

Azure公式ドキュメントにFAQが記載されていました。オフィシャルな情報としてはこちらをご覧下さいませ。「Accelerated maintenance」なんて名前が付いたんですね。

docs.microsoft.com

(追記終わり)

年始からバタバタしてますね。

CPU の脆弱性から Azure のお客様を保護するために (2018/1/25 補足情報の更新) – Japan Azure Technical Support Engineers' Blog

[重要: 2018 / 1 / 6 更新] [告知] 2018 年 1 月 2 日より Azure IaaS 仮想マシンのメンテナンス期間が開始します – Japan Azure Technical Support Engineers' Blog

背景等を含め、こちらの記事で分かり易く説明されています。

www.publickey1.jp

この記事ではメンテナンスの立ち会いがてらに、実際のところどんな感じだったかのメモを残しておこうと思います。

メンテナンス対象となっているVMをまとめて確認したい

「サービス正常性 → 計画済みメンテナンス → 影響を受けるリソース」で、いまのアカウントで管理している全サブスクリプションの情報がまとめて一覧で見られます。メンテナンスが終わったリストは残念ながら見あたりませんでした。

(2018年1月6日 追記)

メンテナンス期間に突入したせいか、「サービス正常性 → 計画済みメンテナンス → 影響を受けるリソース」と辿ると、メンテ完了したVMも表示されるようになっていました。

(追記終わり)

f:id:yhara90:20180104161258p:plain

(2018年1月5日 11時21分 追記)

メンテナンス完了 → ホスト障害 → メンテナンス終わってないホストに着地 → またメンテナンス対象に

という流れで再度メンテナンス対象になるケースを見かけました。やはり推奨されているとおり、Azure Monitor や Instance Metadata でこまめに見ておくのが良さそうです。

(追記終わり)

(2018年1月9日 14時06分 追記)

「サービス正常性 → 計画済みメンテナンス」から今回の告知自体が消えていました。今日の午前中に「COMPLETED: Required Maintenance for Azure Platform impacting Virtual Machines」という件名のメールが届いていたので、一連のメンテナンスが完了したと考えていいんでしょうね(本文内には「REGION(S): Australia East」と書いてありますが…)。

(追記終わり)

各VMのメンテナンスウィンドウを確認したい

仮想マシン一覧のブレード(Virtual Machine)で列を追加できます。今回のようにプラットフォーム側でスケジュールを設定された場合は、「メンテナンス - 自動スケジュールされたウィンドウ」列に表示されます。ここが空欄であれば実施済みと判断して良さそうに思います。セルフサービス期間には「メンテナンス」列に「完了」と出ていたんですが、セルフサービス期間を過ぎると何故か消えてしまうようです。

f:id:yhara90:20180104161633p:plain

(2018年1月4日 20時57分 追記)

と思ったら、いま見た感じだと「完了」はちゃんと表示されるようになっていて、逆に「メンテナンス - 自動スケジュールされたウィンドウ」列が無くなっていました。列の追加からも消えてしまいました。

f:id:yhara90:20180104205806p:plain

(追記終わり)

メンテナンスがいつ頃行われたのか確認したい

「メンテナンス - 自動スケジュールされたウィンドウ」欄が空欄になっているがちょっと不安、という場合には、仮想マシンの「リソース正常性」から「履歴の表示」でメンテナンス(による再起動)が実施されたかどうかを確認することができます。メッセージにはいくつかのパターンがあるようです。

  1. この仮想マシンを実行しているホスト サーバーに対してメンテナンス更新プログラムを適用しています
  2. 計画メンテナンス アクティビティの一部として、この仮想マシンは別のホスト サーバーに再デプロイされています。再デプロイの完了後、オンラインに戻ります。

おそらく前者はホスト移動無しでパッチ適用した場合、後者はホスト更新のため自動再デプロイされた場合のメッセージかなと思います。

f:id:yhara90:20180104170454p:plainf:id:yhara90:20180104170509p:plain

セルフサービス期間を過ぎているがなんとか手動でやりたい

公式情報によると 「Azure インフラストラクチャの大部分は、本脆弱性に対応するため更新済みとなります」 ということで、割り当て解除・開始や再デプロイ、(主に)v3系へのサイズ変更なんかでメンテナンス済みのホストに移動する可能性はあるかなと思います。

といっても、相当な勢いでメンテナンスが進んでいるようなので、あまりジタバタしない方が良さそうには思います。今日のお昼頃に手動で再デプロイしてみた仮想マシンではこんな感じのログになっていまして、正常にアクセス可能になるまで結構な時間がかかりました。

f:id:yhara90:20180104171353p:plain

ゲストOSへのパッチ適用は必要？

必要なはずです。詳しくは各ベンダーやディストリビューションの情報を確認しましょう。

Azure以外のクラウドは？

AWSで年末からずっとメンテナンスが走っていたのもこの件だったんでしょうね。公式なリリースはこちら。あと数時間で基盤側のアップデートが終わるので、ユーザー側でもOSパッチを当てるようにとのこと。Amazon Linuxはパッチ提供済みなので yum update kernel で適用されるそうです。

Processor Speculative Execution Research Disclosure

Google Cloud Platform については、基盤側は対応済みなのでゲストOS側のパッチを当てるようにとのこと。影響があるのはGCE、GKE、Cloud Dataflow、Cloud Dataproc。

Google Online Security Blog: Today's CPU vulnerability: what you need to know

クラウドではありませんが、VMwareについてはパッチが提供されているようですね。

VMSA-2018-0002.1

(2018年1月5日 追記)

IBM Cloud からもリリースがありました。1/5から1/8の間にパッチ適用、インスタンスの再起動あり、バックアップ推奨。タイミングはメンテナンスチケットで通知されるとのこと。

We're taking action to secure our cloud against recent security vulnerabilities - IBM Cloud Blog

(追記終わり)

性能が落ちるという情報があるが大丈夫？

(2018年1月24日 追記)

日本マイクロソフトから記事が出ていましたので、まずはこちらをご覧頂くのが良さそうです。

Windows システム上の Spectre および Meltdown に対する緩和策のパフォーマンスへの影響について – 日本のセキュリティチーム

(追記終わり)

AWSのフォーラムで話題になっていたようですね。実際に、身近なEC2でも特にParavirtualizedなインスタンスでは比較的大きめな影響が出ていたようです。

Degraded performance after forced reboot due to AWS instance maintenance

Azureについては、ネットワークに影響が出る可能性があるかも、ということで、これは後ほど実測してみようかと思います。

CPU の脆弱性から Azure のお客様を保護するために (2018/1/25 補足情報の更新) – Japan Azure Technical Support Engineers' Blog

(2018年1月5日 追記)

と言うわけで実測してみました。

まずはUbuntuでUnixBenchを実行した結果です。誤差程度といいますか、東日本のAシリーズはむしろ新しいハードウェアに乗って性能アップしちゃったのかもしれません。Bシリーズについては、ちょっと性能が出すぎてしまっている感があるので参考程度に。

リージョン インスタンスタイプ スコア
(メンテ前)		 スコア
(メンテ後)		 前後比
東日本 Standard A1 (1 vcpu, 1.75 GB memory) 742 799 108%
東日本 Standard_A1_v2 (1 vcpu, 2 GB memory) 785 820 105%
東日本 Standard F1s (1 vcpu, 2 GB memory) 1,770 1,676 95%
西日本 Standard B1ms (1 vcpu, 2 GB memory) 1,015 1,890 186%
米国西部2 Standard F2s_v2 (2 vcpus, 4 GB memory) 2,877 2,914 101%

続いてネットワークのパフォーマンス。公式ドキュメントの案内通り、NTttcp で測定しました。 見た感じ、アナウンス通り少しパフォーマンスが落ちているように見えますね。SR-IOVを有効にした場合で以前と同程度という結果でした。Dシリーズ(Dv2、Dv3)だけの結果なので偏りがあるかもしれませんが、ご参考まで。

(2018年1月5日 訂正)

Windows Updateの影響を考慮してなかったので、改めて測定し直しました。
結果、プラットフォームのメンテナンス前後ではパフォーマンスは変わらず、Windows Update を適用すると少し落ちて、SR-IOVを有効にすると回復する、といった結果になりました。

f:id:yhara90:20180105152737p:plain

最後に、ストレージのベンチマークを簡単に(2018年1月5日 追記)。L4sにアタッチしたデータディスク(P30)を CrystalDiskMark のデフォルト設定で計測しました。結果としてはアップデートの影響は無く、スペック通りの性能が出ていました。

▼Azureメンテナンス前(2017年12月 計測) f:id:yhara90:20180105130026p:plain

▼Azureメンテナンス後、Windows Update未適用(2018年1月5日 計測) f:id:yhara90:20180105130109p:plain

▼Azureメンテナンス後、Windows Update適用(2018年1月5日 計測) f:id:yhara90:20180105130149p:plain

(2018年1月6日 追記)

AzureのホストメンテナンスというよりWindows Updateの話になりますが、KB4056892でRAMDISKのパフォーマンスが落ちるということでL4sにiSCSIでアタッチして簡単に試してみました。数パーセントから銃数パーセントの低下といったところですかね。

▼KB4056892 適用前 f:id:yhara90:20180106100804p:plain

▼KB4056892 適用後 f:id:yhara90:20180106100837p:plain

(追記ここまで)

シングルコア仮想マシンでunixbench

ふと見かけたページのベンチマークでStandard A1が使われていたのを見かけて、さすがにイマドキは他の選択肢もあるだろうということでいくつか測定してみました。

いきなり結果

基本は東日本リージョンで測定しましたが、せっかく西日本にBシリーズがあるので参考までに測ってみました。

いつも通りですが、性能ならFシリーズ、コスパはBシリーズという感じですね。

リージョン インスタンスタイプ スコア 価格
(円/h)		 所要時間 ベンチマーク費用
(円)		 1円あたりのスコア
東日本 Standard A1 (1 vcpu, 1.75 GB memory) 741.9 8.262 28:00 3.9 192
東日本 Standard_A1_v2 (1 vcpu, 2 GB memory) 785 5.508 27:56 2.6 306
東日本 Standard F1s (1 vcpu, 2 GB memory) 1,770 6.426 28:09 3.0 587
西日本 Standard B1ms (1 vcpu, 2 GB memory) 1,015 3.264 28:24 1.5 657
米国西部2 Standard F2s_v2 (2 vcpus, 4 GB memory) 2,877 9.080 28:04 4.2 677

(2017年12月19日 追記) ついでにFv2シリーズも測定しておきました。これはまだ日本に来ていないので米国西部2リージョンで。米国安いですねぇ。 (追記ここまで)

測り方

各インスタンスを立ち上げてunixbenchをデフォルトで走らせました。

$ sudo apt-get update
$ sudo apt-get -y install gcc make perl git
$ git clone https://github.com/kdlucas/byte-unixbench
$ cd byte-unixbench/UnixBench
$ ./Run

Dv3, Ev3, Bシリーズ仮想マシンの性能検証

これは Microsoft Azure Advent Calendar 2017 11日目の記事です。

さて、先日も軽く触れたように西日本リージョンでDv3, Ev3, Bシリーズの仮想マシンが使えるようになりました。

asazure.hatenablog.jp

ということで、改めて各シリーズの性能を検証して、使いどころを探ってみたいと思います。

コア単価とメモリ単価

まずはスペックシートの情報と価格から、よく使いそうな4コア仮想マシンのコア単価とメモリ単価を算出してみました。
以前に東南アジアリージョンで算出していたものの西日本版です。

▼コア単価
f:id:yhara90:20171213065712p:plain

▼メモリ単価
f:id:yhara90:20171213065720p:plain

テキスト版はGistに置きました

傾向は東南アジアの時と似ています。コア単価上位にAシリーズがいますが、Fシリーズがほぼ同価格でACUが倍ということで、実質的にはFシリーズの圧勝ですね。

EとDでは、よりメモリが必要であればEシリーズ、CPU性能が高いのはDシリーズ、という棲み分けになりそうです。

ネットワーク

続いてネットワークですが、Azure公式サイトのスペック情報には記載があったり無かったりしましたので、おもだったインスタンスでスループットを実測してみました。
Azureのドキュメントで紹介されているNTttcp.exe を用いて、同じ仮想ネットワーク上の同じサイズの仮想マシン間で測定しました。

▼シリーズ間での違い f:id:yhara90:20171213071716p:plain

▼コア数による違い f:id:yhara90:20171213071728p:plain

こちらもテキスト版をGistに置きました

インスタンスのシリーズによる違いは、Bシリーズが遅めな他は(物理)コア数にほぼ比例するような結果になりました。Dシリーズであれば、同じコア数のv3よりv2の方が広帯域ということです。そしてLシリーズは飛び抜けてますね。
Dシリーズを使って、同じシリーズでのコア数による違いも実測してみました。ほぼコア数に比例して倍々で増えてますね(間にv2が挟まっていますがお気になさらず)。

ストレージ

個人的にはここがいちばん気になるところです。 西日本で今回新たに使えるようになった3種類に加えて、比較用に3種類を加えて測定しました。

サイズ スペック 特徴
Standard B4ms 4 vcpus, 16 GB memory CPUがバーストできる。要するにt2。データディスクのキャッシュは有効にできない。
Standard E4s v3 4 vcpus, 32 GB memory Turbo BoostとHyper Threadingできてメモリ多め。
Standard D4s v3 4 vcpus, 16 GB memory DシリーズのHyper Threading対応版。
Standard D8s v3 8 vcpus, 32 GB memory Dv3シリーズのコア数による違いの比較用。
Standard DS3 v2 4 vcpus, 14 GB memory Dv3とDv2シリーズの比較用。Dv2は物理コア。
Standard L4s 4 vcpus, 32 GB memory 参考用(東日本)、ストレージ最適化インスタンス。データディスクのキャッシュは有効にできない。

デフォルトのCドライブ、Dドライブに加えて、データディスクとしてPremiumStorage(P30)をFドライブとしてアタッチしてそれぞれ計測しました。
キャッシュはC, DドライブでRead/Write有効、FドライブはReadのみ有効…とするつもりでしたが、測っていて気付いたのですが、Bシリーズ、Lシリーズは追加したディスクのキャッシュは有効化できないようです。ポータルから見るとこんなメッセージが出ていました。

f:id:yhara90:20171211234737p:plain

また、Dv2シリーズは物理コア数、Dv3シリーズはHyper Threadingもカウントした論理コア数ということで、スペック表の記載でもそもそも列の数からして違っています。どういう違いになるか、実測して試してみましょう。ツールはいつものCrystalDiskMarkです。

docs.microsoft.com

シーケンシャルリード / ライト (MB/s)

こんな感じになりました。

サイズ 測定項目 Cドライブ
(MB/s)		 Dドライブ
(MB/s)		 Fドライブ(P30)
(MB/s)
Standard B4ms Sequential Read 30.4 32.0 35.3
Sequential Write 30.4 32.1 35.4
Standard E4s v3 Sequential Read 67.5 69.2 67.5
Sequential Write 67.5 69.2 67.5
Standard D4s v3 Sequential Read 67.5 69.2 67.3
Sequential Write 67.5 69.2 67.5
Standard D8s v3 Sequential Read 134.9 136.1 135.0
Sequential Write 135.0 136.7 135.0
Standard DS3 v2 Sequential Read 134.1 136.7 134.2
Sequential Write 101.0 136.7 135.0
Standard L4s Sequential Read 205.1 207.3 127.9
Sequential Write 197.9 207.9 128.8

BシリーズはEv3, Dv3の約半分という結果でした。スペック通りではありますね。

docs.microsoft.com

Dシリーズは、Dv3の8コアとDv2の4コアが同じくらいという結果になりました。
Lシリーズはさすが「ストレージ最適化インスタンス」ですね。

Random Read/Write その1 (IOPS, Q= 32,T= 1)

Q= 32,T= 1 の結果です。

サイズ 測定項目 Cドライブ
(IOPS)		 Dドライブ
(IOPS)		 Fドライブ(P30)
(IOPS)
Standard B4ms Random Read 4KiB 3,684 3,898 3,935
Random Write 4KiB 2,333 3,910 3,955
Standard E4s v3 Random Read 4KiB 8,217 8,440 8,230
Random Write 4KiB 7,994 8,443 5,137
Standard D4s v3 Random Read 4KiB 8,240 8,375 8,235
Random Write 4KiB 8,177 8,413 5,115
Standard D8s v3 Random Read 4KiB 16,357 16,574 16,417
Random Write 4KiB 16,316 16,675 5,134
Standard DS3 v2 Random Read 4KiB 16,433 16,627 16,476
Random Write 4KiB 15,109 16,553 5,130
Standard L4s Random Read 4KiB 20,540 20,800 5,141
Random Write 4KiB 20,401 20,772 5,149

こちらもシーケンシャルリード/ライトと概ね同じ傾向です。キャッシュが効く範囲ではインスタンスのサイズというかお値段がそのまま反映されますね。

Random Read/Write その2 (IOPS, Q= 1,T= 1)

こちらは Q= 1,T= 1 の結果です。

サイズ 測定項目 Cドライブ
(IOPS)		 Dドライブ
(IOPS)		 Fドライブ(P30)
(IOPS)
Standard B4ms Random Read 4KiB 2,929 2,561 320
Random Write 4KiB 3,529 3,377 338
Standard E4s v3 Random Read 4KiB 3,967 2,924 3,992
Random Write 4KiB 6,306 3,667 346
Standard D4s v3 Random Read 4KiB 6,290 5,571 6,216
Random Write 4KiB 8,176 8,352 345
Standard D8s v3 Random Read 4KiB 16,030 5,506 15,880
Random Write 4KiB 15,242 9,549 359
Standard DS3 v2 Random Read 4KiB 9,100 4,014 12,308
Random Write 4KiB 8,572 5,932 336
Standard L4s Random Read 4KiB 18,662 6,079 441
Random Write 4KiB 19,585 11,122 514

ちょっと面白い感じになりましたね。それでもLシリーズが速いのはさすが。

まとめ

というわけで、スペック表にあまり記載の無い項目をいろいろと実測してきました。インスタンスタイプ選定のお手伝いになりましたら幸いです。
尚、あくまで個人的に測定した結果ですので、今後、インフラ増強などで変化する可能性がありますのでご注意ください。

過去のベンチマークシリーズ

こちらからどうぞ。

▼Lシリーズ asazure.hatenablog.jp

▼Ev3シリーズ asazure.hatenablog.jp

▼Fv2シリーズ asazure.hatenablog.jp