13 Jun 2017, 17:00

Azureでグローバルにデータをコピーするとどのくらい時間がかかるのか

ファイルコピーの需要は根強い

グローバルでAzureを使うとき、データをどうやって同期、複製するかは悩みの種です。Cosmos DBなどリージョン間でデータ複製してくれるサービスを使うのが、楽ですし、おすすめです。

でも、ファイルコピーを無くせないもろもろの事情もあります。となると、「地球の裏側へのファイルコピーに、どんだけ時間かかるのよ」は、課題です。

調べてみた

ということで、いくつかのパターンで調べたので参考までに。測定環境は以下の通り。

ツールと実行環境

  • AzCopy 6.1.0
  • Azure PowerShell 4.1.0
  • Windows 10 1703
  • ThinkPad X1 Carbon 2017, Core i7-7600U 2.8GHz, 16GB Memory

アクセス回線パターン

  1. 一般的な回線

    • 自宅(川崎)
    • OCN光 100M マンションタイプ
    • 宅内は802.11ac(5GHz)
    • 川崎でアクセス回線に入り、横浜(保土ヶ谷)の局舎からインターネットへ
    • ゲートウェイ名から推測
  2. いい感じの回線

    • 日本マイクロソフト 品川オフィス
    • 1Gbps 有線
    • Azureデータセンターへ「ネットワーク的に近くて広帯域」

コピーするファイル

  • 総容量: 約60GB
    • 6160ファイル
    • 1MB * 5000, 10MB * 1000, 100MB * 100, 500MB * 50, 1000MB * 10
  • Linux fallocateコマンドで作成

ファイル形式パターン

  1. ファイル、Blobそのまま送る (6160ファイル)
  2. ディスクイメージで送る (1ファイル)
    • Managed Diskとしてアタッチした100GBの領域にファイルシステムを作成し、6160ファイルを配置
    • 転送前にデタッチ、エクスポート(Blob SAS形式)
    • AzCopyではなくAzure PowerShellでコピー指示 (AzCopyにBlob SAS指定オプションが見当たらなかった)

対象のAzureリージョン

  • 東日本 (マスター、複製元と位置づける)
  • 米国中南部 (太平洋越え + 米国内を見たい)
  • ブラジル南部

転送パターン

  • ユーザー拠点の端末からAzureリージョン: AzCopy Upload
  • Azureリージョン間 (Storage to Storage)
    • ファイル: AzCopy Copy
    • イメージ: PowerShell Start-AzureStorageBlobCopy

結果

形式  コピー元      コピー先         コマンド   並列数  実行時間(時:分:秒)
ファイル  自宅 Azure 東日本 AzCopy Upload 2 07:55:22
ファイル  自宅 Azure 米国中南部 AzCopy Upload 2 10:22:30
ファイル  自宅 Azure ブラジル南部 AzCopy Upload 2 12:46:37
ファイル  オフィス Azure 東日本 AzCopy Upload 16 00:20:47
ファイル  オフィス Azure 米国中南部 AzCopy Upload 16 00:45.11
ファイル  オフィス Azure ブラジル南部 AzCopy Upload 8 02:07.58
ファイル  Azure 東日本 Azure 米国中南部 AzCopy Copy N/A 00:28:55
イメージ  Azure 東日本 Azure 米国中南部 PowerShell N/A 00:11:11
ファイル  Azure 東日本 Azure ブラジル南部 AzCopy Copy N/A 00.25:33
イメージ  Azure 東日本 Azure ブラジル南部 PowerShell N/A 00.09:20

考察

  • アクセス回線の差が大きく影響

    • 自宅パターンでプロバイダから帯域制限されていたかは不明 (自宅からAzure東日本まで16Mbpsくらいは出た)
    • アクセス回線が細い場合はユーザー拠点から「まとめて」送らないほうがいい
    • こまめに送る
    • Azure内でデータを生成する
    • もしくはExpressRouteを引く (自宅で、とは言っていない)
  • アクセス回線が細い場合、AzCopy Uploadの並列数を下げる

    • AzCopyのデフォルト並列数は実行環境のCPUコア数 *8だが、今回実施した端末での並列数(4コア * 8 = 32)ではかえって性能が劣化した
    • アクセス回線に合わせて並列数は調整する
  • Azureのリージョン間コピーは早い

    • Azureバックボーンを通るから
    • 端末よりAzureストレージのほうがリソース的に強いし負荷分散しているから
  • 地理的な距離感覚だけで考えてはダメ

    • 地理的な近さではなく、ネットワーク的な近さと太さ
    • Azureバックボーンを使うと日本とブラジルの間でもそれなりのスループット
  • ファイル数が多いときはイメージで送るのも手

    • ファイル数がコピー時間に影響する (1 vs 6160)
    • そもそもアプリがBlobとして使うのか、ファイルシステムとして使うかにもよるが…
    • もしファイルシステムとして、であれば有効な手段
    • エクスポートのひと手間は考慮
  • Azureバックボーンを使うと、意外にブラジル近い

    • 土管か(ない

Azureバックボーンの帯域にはSLAがありませんが、意識して仕組みを作ると得をします。

09 Apr 2017, 15:15

Azureユーザー視点のLatency測定 2017/4版

関東の片隅で遅延を測る

Twitterで「東阪の遅延って最近どのくらい?」と話題になっていたので。首都圏のAzureユーザー視線で測定しようと思います。

せっかくなので、

計測パターン

  1. 自宅(神奈川) -> OCN光 -> インターネット -> Azure東日本リージョン
  2. 自宅(神奈川) -> OCN光 -> インターネット -> Azure西日本リージョン
  3. 自宅(神奈川) -> OCN光 -> インターネット -> Azure米国西海岸リージョン
  4. Azure東日本リージョン -> Azureバックボーン -> Azure西日本リージョン
  5. Azure東日本リージョン -> Azureバックボーン -> Azure米国西海岸リージョン

もろもろの条件

  • 遅延測定ツール
    • PsPing
    • Azure各リージョンにD1_v2/Windows Server 2016仮想マシンを作成しPsPing
    • NSGでデフォルト許可されているRDPポートへのPsPing
    • VPN接続せず、パブリックIPへPsPing
    • リージョン間PsPingは仮想マシンから仮想マシンへ
  • 自宅Wi-Fi環境
    • 802.11ac(5GHz)
  • 自宅加入インターネット接続サービス
    • OCN 光 マンション 100M
  • OCNゲートウェイ
    • (ほげほげ)hodogaya.kanagawa.ocn.ne.jp
    • 神奈川県横浜市保土ケ谷区の局舎からインターネットに出ているようです
  • 米国リージョン
    • US WEST (カリフォルニア)

測定結果

1. 自宅(神奈川) -> OCN光 -> インターネット -> Azure東日本リージョン

TCP connect statistics for 104.41.187.55:3389:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 11.43ms, Maximum = 15.66ms, Average = 12.88ms

2. 自宅(神奈川) -> OCN光 -> インターネット -> Azure西日本リージョン

TCP connect statistics for 52.175.148.28:3389:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 17.96ms, Maximum = 19.64ms, Average = 18.92ms

3. 自宅(神奈川) -> OCN光 -> インターネット -> Azure米国西海岸リージョン

TCP connect statistics for 40.83.220.19:3389:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 137.73ms, Maximum = 422.56ms, Average = 218.85ms

4. Azure東日本リージョン -> Azureバックボーン -> Azure西日本リージョン

TCP connect statistics for 52.175.148.28:3389:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 8.61ms, Maximum = 9.38ms, Average = 9.00ms

5. Azure東日本リージョン -> Azureバックボーン -> Azure米国西海岸リージョン

TCP connect statistics for 40.83.220.19:3389:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 106.38ms, Maximum = 107.38ms, Average = 106.65ms

Azureバックボーンを通すと首都圏からの遅延が半分になりました。Wi-Fiの有無など、ちょっと条件は違いますが。

ひとこと

インターネット、および接続サービスの遅延が性能の上がらない原因になっている場合は、Azureで完結させてみるのも手です。

たとえば、

  • 会社で契約しているインターネット接続サービスが、貧弱
  • シリコンバレーの研究所からインターネット経由でデータを取得しているが、遅い

こんなケースではAzureを間に入れると、幸せになれるかもしれません。なったユーザーもいらっしゃいます。

23 Mar 2017, 15:00

Azure Resource Manager テンプレートでManaged Diskを作るときのコツ

お伝えしたいこと

  • ARMテンプレートのドキュメントが使いやすくなった
  • Visual Studio CodeとAzure Resource Manager Toolsを使おう
  • ARMテンプレートでManaged Diskを作る時のコツ
  • 可用性セットを意識しよう

ARMテンプレートのドキュメントが使いやすくなった

docs.microsoft.com の整備にともない、ARMテンプレートのドキュメントも使いやすくなりました。ARMテンプレート使いのみなさまは https://docs.microsoft.com/ja-jp/azure/templates/ をブックマークして、サクサク調べちゃってください。

Visual Studio CodeとAzure Resource Manager Toolsを使おう

これがあまり知られてないようなのでアピールしておきます。

コードアシスト

コードアシストしてくれます。

画面スクロールが必要なほどのJSONをフリーハンドで書けるほど人類は進化していないというのがわたしの見解です。ぜひご活用ください。

Get VS Code and extension

ARMテンプレートでManaged Diskを作る時のコツ

Managed Diskが使えるようになって、ARMテンプレートでもストレージアカウントの定義を省略できるようになりました。Managed Diskの実体は内部的にAzureが管理するストレージアカウントに置かれるのですが、ユーザーからは隠蔽されます。

Managed Diskは Microsoft.Compute/disks で個別に定義できますが、省略もできます。Microsoft.Compute/virtualMachines の中に書いてしまうやり口です。

"osDisk": {
  "name": "[concat(variables('vmName'),'-md-os')]",
  "createOption": "FromImage",
  "managedDisk": {
    "storageAccountType": "Standard_LRS"
  },
  "diskSizeGB": 128
}

こんな感じで書けます。ポイントはサイズ指定 “diskSizeGB” の位置です。”managedDisk”の下ではありません。おじさんちょっと悩みました。

可用性セットを意識しよう

Managed Diskを使う利点のひとつが、可用性セットを意識したディスク配置です。可用性セットに仮想マシンを配置し、かつManaged Diskを使うと、可用性を高めることができます。

Azureのストレージサービスは、多数のサーバーで構成された分散ストレージで実現されています。そのサーバー群をStorage Unitと呼びます。StampとかClusterと表現されることもあります。Storage Unitは数十のサーバーラック、数百サーバーで構成され、Azureの各リージョンに複数配置されます。

参考情報:Windows Azure ストレージ: 高可用性と強い一貫性を両立する クラウド ストレージ サービス(PDF)

可用性セットは、電源とネットワークを共有するグループである”障害ドメイン(FD: Fault Domain)“を意識して仮想マシンを分散配置する設定です。そして、可用性セットに配置した仮想マシンに割り当てたManaged Diskは、Storage Unitを分散するように配置されます。

Unmanaged vs Managed

すなわち、Storage Unitの障害に耐えることができます。Storage Unitは非常に可用性高く設計されており、長期に運用されてきた実績もあるのですが、ダウンする可能性はゼロではありません。可用性セットとManaged Diskの組み合わせは、可用性を追求したいシステムでは、おすすめです。

さて、この場合の可用性セット定義ですが、以下のように書きます。

{
  "type": "Microsoft.Compute/availabilitySets",
  "name": "AvSet01",
  "apiVersion": "2016-04-30-preview",
  "location": "[resourceGroup().location]",
  "properties": {
    "managed": true,
    "platformFaultDomainCount": 2,
    "platformUpdateDomainCount": 5
  }
},

Microsoft.Compute/availabilitySets を読むと、Managed Diskを使う場合は”propaties”の”managed”をtrueにすべし、とあります。なるほど。

そしてポイントです。合わせて”platformFaultDomainCount”を指定してください。managedにする場合は必須パラメータです。

なお、リージョンによって配備されているStorage Unit数には違いがあるのでご注意を。例えば東日本リージョンは2です。3のリージョンもあります。それに合わせて可用性セットの障害ドメイン数を指定します。

Azure IaaS VM ディスクと Premium 管理ディスクおよび非管理ディスクについてよく寄せられる質問

Managed Disks を使用する可用性セットでサポートされる障害ドメイン数はいくつですか?

Managed Disks を使用する可用性セットでサポートされる障害ドメイン数は 2 または 3 です。これは、配置されているリージョンによって異なります。

28 Feb 2017, 08:00

Docker for WindowsでインストールレスAzure CLI 2.0環境を作る

Azure CLI 2.0版です

Docker for WindowsでインストールレスAzure CLI環境を作る、のAzure CLI 2.0版です。Azure CLI 2.0の一般提供開始に合わせて書いています。

動機

  • Docker for Windows、もっと活用しようぜ
  • がんがんアップデートされるAzure CLI2.0をいちいちインストールしたくない、コンテナ引っ張って以上、にしたい
  • 開発端末の環境を汚したくない、いつでもきれいに作り直せるようにしたい
  • WindowsでPythonのバージョン管理するのつらくないですか? コンテナで解決しましょう
  • ○○レスって言ってみたかった

やり口

  • もちろんDocker for Windows (on Client Hyper-V) を使う
  • いちいちdocker run…と打たなくていいよう、エイリアス的にPowerShellのfunction “az_cli” を作る
  • “az_cli”入力にてAzure CLIコンテナを起動
  • コンテナとホスト(Windows)間でファイル共有、ホスト側のIDEなりエディタを使えるようにする

作業の中身

  • Docker for Windowsをインストール
    • 64bit Windows 10 Pro/Enterprise/Education 1511以降に対応
    • Hyper-Vの有効化を忘れずに
    • Hyper-VとぶつかるVirtualBoxとはお別れです
    • モードをLinuxにします。タスクトレイのdockerアイコンを右クリック [Switch to Linux containers]
    • ドライブ共有をお忘れなく。 タスクトレイのdockerアイコンを右クリック [settings] > [Shared Drives]
  • PowerShell functionを作成
    • のちほど詳しく

PowerShellのfunctionを作る

ここが作業のハイライト。

PowerShellのプロファイルを編集します。ところでエディタはなんでもいいのですが、AzureやDockerをがっつり触る人にはVS Codeがおすすめです。Azure Resource Manager TemplateDockerむけextensionがあります。

PS C:\Workspace\ARM> code $profile

こんなfunctionを作ります。

function az_cli {
   C:\PROGRA~1\Docker\Docker\Resources\bin\docker.exe run -it --rm -v ${HOME}/.azure:/root/.azure -v ${PWD}:/data -w /data azuresdk/azure-cli-python
}
  • エイリアスでなくfunctionにした理由は、引数です。エイリアスだと引数を渡せないので
  • コンテナが溜まるのがいやなので、–rmで都度消します
  • 毎度 az login しなくていいよう、トークンが保管されるコンテナの/root/azureディレクトリをホストの${HOME}/.azureと-v オプションで共有します
  • ARM TemplateのJSONファイルなど、ホストからファイルを渡したいため、カレントディレクトリ ${PWD} をコンテナと -v オプションで共有します
  • コンテナはdocker hubのazuresdk/azure-cli-pythonリポジトリ、latestを引っ張ります。latestで不具合あればバージョン指定してください

ではテスト。まずはホスト側のファイルを確認。

PS C:\Workspace\ARM> ls


    ディレクトリ: C:\Workspace\ARM


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2017/02/28      8:29           4515 azuredeploy.json
-a----       2017/02/28      8:30            374 azuredeploy.parameters.json

いくつかのファイルがあります。

コンテナを起動してみましょう。az_cli functionを呼びます。

PS C:\Workspace\ARM> az_cli
bash-4.3#

コンテナを起動し、入出力をつなぎました。ここからは頭と手をLinuxに切り替えてください。Azure CLI 2.0コンテナはalpine linuxベースです。

カレントディレクトリを確認。

bash-4.3# pwd
/data

ファイル共有できているか確認。

bash-4.3# ls
azuredeploy.json             azuredeploy.parameters.json

できてますね。

azコマンドが打てるか確認。

bash-4.3# az --version
azure-cli (2.0.0+dev)

acr (0.1.1b4+dev)
acs (2.0.0+dev)
appservice (0.1.1b5+dev)
batch (0.1.1b4+dev)
cloud (2.0.0+dev)
component (2.0.0+dev)
configure (2.0.0+dev)
container (0.1.1b4+dev)
core (2.0.0+dev)
documentdb (0.1.1b2+dev)
feedback (2.0.0+dev)
iot (0.1.1b3+dev)
keyvault (0.1.1b5+dev)
network (2.0.0+dev)
nspkg (2.0.0+dev)
profile (2.0.0+dev)
redis (0.1.1b3+dev)
resource (2.0.0+dev)
role (2.0.0+dev)
sql (0.1.1b5+dev)
storage (2.0.0+dev)
taskhelp (0.1.1b3+dev)
vm (2.0.0+dev)

Python (Linux) 3.5.2 (default, Dec 27 2016, 21:33:11)
[GCC 5.3.0]

タブで補完も効きます。

bash-4.3# az a
account     acr         acs         ad          appservice

しあわせ。

03 Feb 2017, 18:00

Azure N-SeriesでPaintsChainerを動かす

PaintsChainer面白い

クラスメソッドさんのDevelopers.IOでのエントリ“PaintsChainerをAmazon EC2で動かしてみた”が、とても面白いです。

畳みこみニューラルネットワークを駆使して白黒線画に色付けしちゃうPaintsChainerすごい。EC2のGPUインスタンスでさくっと動かせるのもいいですね。

せっかくなのでAzureでもやってみようと思います。AzurerはN-Series & NVIDIA-Dockerのサンプルとして、Azurerでない人はUbuntuでPaintsChainerを動かす参考手順として見ていただいてもいいかと。

試した環境

  • 米国中南部リージョン
  • Standard NC6 (6 コア、56 GB メモリ、NVIDIA Tesla K80)
  • Ubuntu 16.04
  • NSGはSSH(22)の他にHTTP(80)を受信許可

導入手順

NVIDIA Tesla driversのインストール

マイクロソフト公式ドキュメントの通りに導入します。

Set up GPU drivers for N-series VMs

Dockerのインストール

Docker公式ドキュメントの通りに導入します。

Get Docker for Ubuntu

NVIDIA Dockerのインストール

GitHub上のNVIDIAのドキュメント通りに導入します。

NVIDIA Docker

ここまでの作業に問題がないか、確認します。

$ sudo nvidia-docker run --rm nvidia/cuda nvidia-smi
Using default tag: latest
latest: Pulling from nvidia/cuda
8aec416115fd: Pull complete
[...]
Status: Downloaded newer image for nvidia/cuda:latest
Fri Feb  3 06:43:18 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 367.48                 Driver Version: 367.48                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla K80           Off  | 86BF:00:00.0     Off |                    0 |
| N/A   34C    P8    33W / 149W |      0MiB / 11439MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

PaintsChainer-Dockerのインストール

Liam Jones氏が公開しているPaintsChainer-Dockerを使って、PaintsChanierコンテナーを起動します。ポートマッピングはコンテナーホストの80番とコンテナーの8000番です。

$ sudo nvidia-docker run -p 80:8000 liamjones/paintschainer-docker

PaintsChainerを使ってみる

VMのパブリックIP、ポート80番にアクセスすると、先ほどコンテナーで起動したPaintsChainerのページが開きます。クラウディアさんの白黒画像ファイルで試してみましょう。

結果

PaintsChainer、すごいなぁ。 クラウディアさん、おなか寒そうだけど。