Azure Blob Storage の HTBB (High-Throughput Block Blob) が何も考えずに使っても結構速い件。

# 目標
[Azure Blob Storage の高スループット ブロック BLOB](https://blogs.technet.microsoft.com/mssvrpmj/2019/04/01/high-throughput-with-azure-blob-storage/) という Blob 記事の内容によれば、Azure Block Blob のスループットがだいぶ上がってて、しかも何にも考えなくとも、その高スループット機能が使えるようになってるみたいなので、ざくっと検証してみます。

# 背景
この機能が出てくるまでの Azure Block Blob Storage は、書き込み時の負荷分散処理として Blob 名を使ったパーティショニングをしており、この関係で単一 Blob への書き込みスループットに 60MiB/s の制限がかかっていました。
HTBB では、このパーティショニング処理を刷新し、ブロックごとの ID もコミで負荷分散を行うようにしたため、単一 Blob へのスループットの上限が外れ、「ストレージアカウントの Ingress / Egress の上限」までスループットを出せるようになりました。

[参考ドキュメント]
[ストレージ アカウントでの Azure Storage のスケーラビリティとパフォーマンスのターゲット](https://docs.microsoft.com/ja-jp/azure/storage/common/storage-scalability-targets)

# とりあえず何も考えずに書き込みをしてみるテスト
今回は、60MiB/s の上限が外れてることだけ確認できればいいや、というざっくり試験なので、サクッと Azure 上に Ubuntu Linux で仮想マシンを立てることにします。RAM Disk を 10GB くらい確保したかったので、何となく雰囲気で Standard D4s v3 (4 vcpu 数、16 GB メモリ) を選択しました。

んで、VM 起動後にザクっと RAM Disk 作成。そして中身ランダムな 5GB くらいのファイルを生成。この辺 Linux だと楽でいいですなぁ。

```
mkdir /mnt/ramdisk
mount -t tmpfs -o size=10240m /dev/shm /mnt/ramdisk
head -c 5120m /dev/urandom > mnt/ramdisk/tempfile.bin
```

Linux VM に azcopy v10 をセットアップ。

```
wget https://aka.ms/downloadazcopy-v10-linux
tar xvf azcopy_linux_amd64_10.1.1.tar
cd azcopy_linux_amd64_10.1.1
```

[Storage Explorer](https://azure.microsoft.com/en-us/features/storage-explorer/) で書き込み先のコンテナの SAS を生成しまして…。
![storageexplorer001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/199379/82464202-0236-b68c-9095-1ebb24c5f855.png)

![storageexplorer002.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/199379/5f6a84bc-43e1-bb67-c748-1aa284c512bb.png)

azcopy から RAM Disk 内にある 5GB 程のファイルをおもむろに Azure Block Blob へコピー！

```
tokawa@<VM Name>:~/azcopy_linux_amd64_10.1.1$ ./azcopy cp "/mnt/ramdisk/" "https://<storage account>.blob.core.windows.net/<container>?<SAS Token>" --recursive=true
INFO: Scanning...

Job 13abe6dc-cbdc-6d4f-4b5b-807c22664dcb has started
Log file is located at: /home/tokawa/.azcopy/13abe6dc-cbdc-6d4f-4b5b-807c22664dcb.log

0 Done, 0 Failed, 1 Pending, 0 Skipped, 1 Total, 2-sec Throughput (Mb/s): 1534.3966


Job 13abe6dc-cbdc-6d4f-4b5b-807c22664dcb summary
Elapsed Time (Minutes): 0.4334
Total Number Of Transfers: 1
Number of Transfers Completed: 1
Number of Transfers Failed: 0
Number of Transfers Skipped: 0
TotalBytesTransferred: 5368709120
Final Job Status: Completed
```

というわけで、結果としては 5368709120 Bytes のファイルを 0.4334 分で転送できたという結果に…。
んでこれ何 MB/s なのよ…というわけで計算。

5368709120 [Bytes] / 0.4334 [Min] = 12,387,422,981 [Bytes/Min]
12,387,422,981 [Bytes/Min] / 60 [Sec] = 206,457,050 [Bytes/Sec]
となりまして、何も考えずにとりあえず VM からがーっと書き込むだけでも、あっさり 206 [MBytes/Sec] というスループットが出てることを確認できたわけでした。

まだまだボトルネックになっているところは色々あると思うので、その辺引き続きの課題として色々やってみます。
あとはブログ記事にあったように、複数台の VM で分散して Block Blob の書き込みを行うことで、まだまだスループットは上げられそうですね！

# まとめ
今までは Blob 名とか、パーティション処理のことを何となく考えないと、場合によっては激遅になっていたものが、何も考えずに負荷分散されるようになってるのはホントのことでした！
これ、昔作った Storage でも、ある一定サイズを超えた Block Blob の書き込みだと自動的に有効になるらしいので、長らくの Azure ユーザーにも嬉しい限り。

というわけで、負荷分散処理のことをあまり考えなくとも速くなった＆ちゃんと負荷分散を考えれば超速になる、Azure Blob Storage 、いろいろな用途に使えそうですねー。

例えば、でっかい動画ファイルをドーン！と書き込んでみたりとか…。
でっかい 3D モデルのファイルをドーン！と書き込んでみたりとか…。

それでは！