11 Feb 2016, 12:00

Azure Blob Upload ツール別ベンチマーク

同じ目的を達成できるツールがたくさん

やりたいことがあり、それを達成する手段がたくさん。どう選ぼう。じゃあ特徴を知りましょう。という話です。

端末からAzureへファイルをアップロードする手段は多くあります。CLIツール、GUIツール、SDKで自作する、etc。

そして、端末と、そのおかれている環境も多様です。Windows、Mac。有線、無線。

で、大事なのは平行度。ブロックBlobはブロックを平行に転送する方式がとれるため、ツールが平行転送をサポートしているか? どのくらい効くのか? は重要な評価ポイントです。

なので、どのツールがおすすめ?と聞かれても、条件抜きでズバっとは答えにくい。そしてこの質問は頻出。なのでこんな記事を書いています。

環境と測定方式

おそらくファイルを送る、という用途でもっとも重視すべき特徴は転送時間でしょう。ではツール、環境別に転送時間を測定してみます。

環境は以下の通り。

  • Windows端末
    • Surface Pro 4 Core i7/16GB Memory/802.11ac
    • 1Gbps Ethernet (USB経由)
    • Windows 10 (1511)
  • Mac端末
    • Macbook 12inch Core M/8GB Memory/802.11ac
    • USB-C… 有線テストは省きます
    • El Capitan
  • Wi-Fiアクセスポイント/端末間帯域
    • 100~200Mbpsでつながっています
  • Azureデータセンタまでの接続
    • 日本マイクロソフトの品川オフィスから、首都圏にあるAzure Japan Eastリージョンに接続
    • よってWAN側の遅延、帯域ともに条件がいい
  • 対象ツール
  • 転送ファイル
    • Ubuntu 15.10 ISOイメージ (647MBytes)

そして測定方式。

AzCopyはPowerShellのMeasure-Commandにて実行時間をとります。NCが平行度指定です。デフォルトの平行度はCPUコア数の8倍です。わしのSurface、OSから4コア見えていますので、32。

Measure-Command {AzCopy /Source:C:\Users\myaccount\work /Dest:https://myaccount.blob.core.windows.net/mycontainer /DestKey:mykey /Pattern:ubuntu-15.10-server-amd64.iso /Y /NC:count}

Azure CLIも同様にMeasure-Commandで。–concurrenttaskcountで平行度を指定できますが、ソースを確認したところ、平行度のデフォルトは5です。”StorageUtil.threadsInOperation = 5;“ですね。

Measure-Command {azure storage blob upload ./ubuntu-15.10-server-amd64.iso -a myaccount -k mykey mycontainer ubuntu1510 --concurrenttaskcount count}

残念ながらMacむけAzCopyはありませんので、Azure CLIのみ実行します。timeコマンドで時間をとります。

time azure storage blob upload ./ubuntu-15.10-server-amd64.iso -a myaccount -k mykey mycontainer ubuntu1510 --concurrenttaskcount count

Azure Storage Explorer Cross Platform GUIは、目視+iPhoneのストップウォッチで。

結果

平行度上げても伸びないな、というタイミングまで上げます。

 実行No   クライアントOS   ネットワーク接続   クライアント   並行数   転送時間(秒) 
1 Windows 10 1Gbps Ethernet AzCopy (default:32) 9.62
2 Windows 10 1Gbps Ethernet AzCopy 5 12.28
3 Windows 10 1Gbps Ethernet AzCopy 10 10.83
4 Windows 10 1Gbps Ethernet AzCopy 20 10.43
5 Windows 10 1Gbps Ethernet Azure CLI (default:5) 49.92
6 Windows 10 1Gbps Ethernet Azure CLI 10 29.47
7 Windows 10 1Gbps Ethernet Azure CLI 20 21.05
8 Windows 10 1Gbps Ethernet Azure CLI 40 20.12
9 Windows 10 1Gbps Ethernet Storage Explorer N/A 50.10
10 Windows 10 802.11ac AzCopy (default:32) 74.87
11 Windows 10 802.11ac AzCopy 5 53.32
12 Windows 10 802.11ac AzCopy 10 58.85
13 Windows 10 802.11ac Azure CLI (default:5) 57.23
14 Windows 10 802.11ac Azure CLI 10 50.71
15 Windows 10 802.11ac Azure CLI 20 54.37
16 Windows 10 802.11ac Storage Explorer N/A 54.63
17 Mac OS X 802.11ac Azure CLI (default:5) 40.86
18 Mac OS X 802.11ac Azure CLI 10 33.97
19 Mac OS X 802.11ac Azure CLI 20 58.57
20 Mac OS X 802.11ac Storage Explorer N/A 58.20

考察

  • 有線AzCopy早い。単純計算で67MByte/s出ています。それぞれの計測点の解釈の違いでBlobサービス制限の60MBytes/sを超えてしまっていますがw。データセンタまでのボトルネックがなければ、ポテンシャルを引き出せることがわかります。
  • 平行度は大きく性能に影響します。
    • 平行度が高すぎてもだめ
      • 無線AzCopyのデフォルト(平行度32)が平行度10、20より時間がかかっていることからわかる
    • デフォルトで遅いからといってあきらめず、平行度変えて試してみましょう
    • SDK使って自分で作る時も同じ。平行度パラメータを意識してください
      • .NET: BlobRequestOptions
      • Java/Android: BlobRequestOptions.setConcurrentRequestCount()
      • Node.js: parallelOperationThreadCount
      • C++: blob_request_options::set_parallelism_factor
  • Azure CLIよりAzCopyが早い。
    • .NETで最適化できているから合点
    • Node.jsベースでマルチOS対応のAzure CLIは比べられると分が悪い
    • でも、802.11acでも無線がボトルネックになっているので、いまどきのWi-Fi環境では似たような性能になる
    • No.18の結果は無線状態がよかったと想定
  • Azure Storage Explorer Cross Platform GUIは、現時点で平行度変えられないので性能面では不利。でも直観的なので、使い分け。

WAN条件がいいベンチマークでなので、ぜひみなさんの条件でも試してみてください。遅延の大きなリージョンや途中に帯域ボトルネックがある条件でやると、最適な平行度が変わってくるはずです。

でも一番言いたかったのは、Macbookの有線アダプタ欲しいということです。

07 Feb 2016, 17:00

Linux on Azureでファイル共有する方法

ファイル共有、あまりおすすめしないです

いきなりタイトルを否定しました。ロック。

さて、これからクラウド、というお客様に、よく聞かれる質問があります。それは「NFSとかの、ファイル共有使える?」です。頻出です。クラウド頻出質問選手権では、西東京予選で毎年ベスト8入りするレベルの強豪校です。

ですが個人的にはあまりおすすめしません。クラウドはなるべく共有部分を減らして、スケーラブルに、かつ障害の影響範囲を局所化するべき、と考えるからです。特にストレージはボトルネックや広範囲な障害の要因になりやすい。障害事例が物語ってます。その代わりにオブジェクトストレージなど、クラウド向きの機能がおすすめです。

でも、否定はしません。アプリの作りを変えられないケースもあるかと思います。

そこで、もしAzureでファイル共有が必要であれば、Azure File Storageを検討してみてください。Azureのマネージドサービスなので、わざわざ自分でサーバたてて運用する必要がありません。楽。

対応プロトコルは、SMB2.1 or 3.0。LinuxからはNFSじゃなくSMBでつついてください。

使い方は公式ドキュメントを。

“Azure Storage での Azure CLI の使用”

“Linux で Azure File Storage を使用する方法”

もうちょっと情報欲しいですね。補足のためにわたしも流します。

Azure CLIでストレージアカウントを作成し、ファイル共有を設定

ストレージアカウントを作ります。fspocは事前に作っておいたリソースグループです。

local$ azure storage account create tomakabefspoc -l "Japan East" --type LRS -g fspoc

ストレージアカウントの接続情報を確認します。必要なのはdata: connectionstring:の行にあるAccountKey=以降の文字列です。このキーを使ってshareの作成、VMからのマウントを行うので、控えておいてください。

local$ azure storage account connectionstring show tomakabefspoc -g fspoc
info:    Executing command storage account connectionstring show
+ Getting storage account keys
data:    connectionstring: DefaultEndpointsProtocol=https;AccountName=tomakabefspoc;AccountKey=qwertyuiopasdfghjklzxcvbnm==
info:    storage account connectionstring show command OK

shareを作成します。share名はfspocshareとしました。

local$ azure storage share create -a tomakabefspoc -k qwertyuiopasdfghjklzxcvbnm== fspocshare

エンドポイントを確認しておきましょう。VMからのマウントの際に必要です。

local$ azure storage account show tomakabefspoc -g fspoc
[snip]
data:    Primary Endpoints: file https://tomakabefspoc.file.core.windows.net/

Linux * 2VMで共有

Ubuntuでやりますよ。SMBクライアントとしてcifs-utilsパッケージをインストールします。Marketplace提供の14.04 LTSであれば、すでに入ってるはずです。

fspocvm01:~$ sudo apt-get install cifs-utils

マウントポイントを作り、マウントします。接続先の指定はエンドポイント+share名で。usernameはストレージアカウント名。パスワードはストレージアカウントのキーです。 パーミッションは要件に合わせてください。

fspocvm01:~$ sudo mkdir -p /mnt/fspoc
fspocvm01:~$ sudo mount -t cifs //tomakabefspoc.file.core.windows.net/fspocshare /mnt/fspoc -o vers=3.0,username=tomakabefspoc,password=qwertyuiopasdfghjklzxcvbnm==,dir_mode=0777,file_mode=0777

マウント完了。確認用のファイルを作っておきます。

fspocvm01:~$ echo "test" > /mnt/fspoc/test.txt
fspocvm01:~$ cat /mnt/fspoc/test.txt
test

2台目のVMでも同様のマウント作業を。

fspocvm02:~$ sudo apt-get install cifs-utils
fspocvm02:~$ sudo mkdir -p /mnt/fspoc
fspocvm02:~$ sudo mount -t cifs //tomakabefspoc.file.core.windows.net/fspocshare /mnt/fspoc -o vers=3.0,username=tomakabefspoc,password=qwertyuiopasdfghjklzxcvbnm==,dir_mode=0777,file_mode=0777

1台目で作ったファイルが見えますね。

fspocvm02:~$ ls /mnt/fspoc
test.txt
fspocvm02:~$ cat /mnt/fspoc/test.txt
test

ファイルをいじりましょう。

fspocvm02:~$ echo "onemoretest" >> /mnt/fspoc/test.txt
fspocvm02:~$ cat /mnt/fspoc/test.txt
test
onemoretest

1台目から確認。

fspocvm01:~$ cat /mnt/fspoc/test.txt
test
onemoretest

ご利用は計画的に

2016年2月時点で、Azure File Storageには最大容量:5TB/share、1TB/file、ストレージアカウントあたりの帯域:60MBytes/sという制約があります。これを超えるガチ共有案件では、Lustreなど別の共有方法を検討してください。

なおファイルサーバ用途であれば、Azure File Storageではなく、OneDriveなどオンラインストレージSaaSに移行した方が幸せになれると思います。企業向けが使いやすくなってきましたし。運用から解放されるだけじゃなく、便利ですよ。

27 Jan 2016, 00:19

Linux on AzureでDisk IO性能を確保する方法

“俺の鉄板”ができるまで

前半はポエムです。おそらくこのエントリにたどり着く人の期待はLinux on AzureのDisk IO性能についてと思いますが、それは後半に書きます。

クラウド、Azureに関わらず、技術や製品の組み合わせは頭の痛い問題です。「これとこれ、組み合わせて動くの?サポートされるの?性能出るの?」という、あれです。技術や製品はどんどん進化しますので、同じ組み合わせが使えることは珍しくなってきています。

ちなみにお客様のシステムを設計する機会が多いわたしは、こんな流れで検討します。

  1. 構成要素全体を俯瞰したうえで、調査が必要な技術や製品、ポイントを整理する
    • やみくもに調べものしないように
    • 経験あるアーキテクトは実績ある組み合わせや落とし穴を多くストックしているので、ここが早い
  2. ベンダの公式資料を確認する
    • 「この使い方を推奨/サポートしています」と明記されていれば安心
    • でも星の数ほどある技術や製品との組み合わせがすべて網羅されているわけではない
    • 不明確なら早めに問い合わせる
  3. ベンダが運営しているコミュニティ上の情報を確認する
    • ベンダの正式見解ではない場合もあるが、その製品を担当する社員が書いている情報には信ぴょう性がある
  4. コミュニティや有識者の情報を確認する
    • OSSでは特に
    • 専門性を感じるサイト、人はリストしておく
  5. 動かす
    • やっぱり動かしてみないと
  6. 提案する
    • リスクがあれば明示します
  7. 問題なければ実績になる、問題があればリカバリする
    • 提案しっぱなしにせずフォローすることで、自信とパターンが増える
    • 次の案件で活きる

いまのわたしの課題は4、5です。特にOSS案件。AzureはOSSとの組み合わせを推進していて、ここ半年でぐっと情報増えたのですが、まだ物足りません。断片的な情報を集め、仮説を立て、動かす機会が多い。なので、5を増やして、4の提供者側にならんとなぁ、と。

Linux on AzureでDisk IO性能を確保する方法

さて今回の主題です。

結論: Linux on AzureでDisk IOを最大化するには、MDによるストライピングがおすすめ。いくつかパラメータを意識する。

Linux on AzureでDisk IO性能を必要とする案件がありました。検討したアイデアは、SSDを採用したPremium Storageを複数束ねてのストライピングです。Premium Storageはディスクあたり5,000IOPSを期待できます。でも、それで足りない恐れがありました。なので複数並べて平行アクセスし、性能を稼ぐ作戦です。

サーバ側でのソフトウェアストライピングは古くからあるテクニックで、ハードの能力でブン殴れそうなハイエンドUnixサーバとハイエンドディスクアレイを組み合わせた案件でも、匠の技として使われています。キャッシュやアレイコントローラ頼りではなく、明示的にアクセスを分散することで性能を確保することができます。

Linuxで使える代表的なストライプ実装は、LVMとMD。

ではAzure上でどちらがを選択すべきでしょう。この案件では性能が優先事項です。わたしはその時点で判断材料を持っていませんでした。要調査。この絞り込みまでが前半ポエムの1です。

前半ポエムの2、3はググ、もといBing力が試される段階です。わたしは以下の情報にたどり着きました。

“Configure Software RAID on Linux”

“Premium Storage: Azure 仮想マシン ワークロード向けの高パフォーマンス ストレージ”

“Azure Storage secrets and Linux I/O optimizations”

得られた情報の中で大事なのは、

  • 公式ドキュメントで
    • LVMではなくMDを使った構成例が紹介されている
  • マイクロソフトがホストするブログ(MSDN)で、エキスパートが
    • LVMと比較したうえで、MDをすすめている
    • MDのChunkサイズについて推奨値を紹介している
    • そのほか、ファイルシステムやスケジューラに関する有益な情報あり

なるほど。わたしのこの時点での方針はこうです。

  • LVMを使う必然性はないため、MDに絞る
    • LVMのほうが機能豊富だが、目的はストライピングだけであるため、シンプルなほうを
    • 物理障害対策はAzureに任せる (3コピー)
  • MDのChunkをデフォルトの512KBから64KBに変更する (ここは結果によって調整)
  • Premium StorageのキャッシュはReadOnly or Noneにする予定であるため、ファイルシステムのバリアを無効にする

上記シナリオで、ディスク当たり5,000IOPS、ストライプ数に比例した性能が実際出れば提案価値あり、ということになります。 ですが、ズバリな実績値が見つからない。ダラダラ探すのは時間の無駄。これは自分でやるしかない。

構成手順は前述のリンク先にありますが、ポイントを抜き出します。OS=Ubuntu、ファイルシステム=ext4の場合です。

MDでストライプを作る際、チャンクを64KBに変更します。

sudo mdadm --create /dev/md127 --level 0 --raid-devices 2  /dev/sdc1 /dev/sdd1 -c 64k

マウント時にバリアを無効にします。

sudo mount /dev/md127 /mnt -o barrier=0

では、Premium Storage(P30)をMDで2つ束ねたストライプにfioを実行してみましょう。

  • 100% Random Read
  • キャッシュ効果のないデータをとるため、Premium StorageのキャッシュはNone、fio側もdirect=1
  • ブロックサイズは小さめの値が欲しかったので、1K

結果。

randread: (g=0): rw=randread, bs=1K-1K/1K-1K/1K-1K, ioengine=libaio, iodepth=32
fio-2.1.3
Starting 1 process

randread: (groupid=0, jobs=1): err= 0: pid=9193: Tue Jan 26 05:48:09 2016
  read : io=102400KB, bw=9912.9KB/s, iops=9912, runt= 10330msec
[snip]

2本束ねて9,912IOPS。1本あたりほぼ5,000IOPS。ほぼ期待値。

24 Jan 2016, 00:19

クラウドは本当に性能不足なのか

このエントリは2016/1/24に書きました。使えるリソースはどんどん増えていくので、適宜その時点で情報をとってください。

具体的な数値で、正しい理解を

“クラウドは性能不足、企業システムが重すぎる”という記事が身の回りで話題になりました。公開から4日たっても「いま読まれている記事」の上位にあり、注目されているようです。

記事で訴えたかったことは、クラウドを過信しないように、そして、クラウドはクラウドらしい使い方をしよう、ということでしょう。ユーザの声は貴重ですし、同意できるところも多い。でも、「企業システム」とひとくくりにしてしまったこと。タイトルのバイアスが強いこと。そして、具体的な根拠に欠けることから、誤解を招いている印象です。

どんな技術、製品、サービスにも限界や制約はあります。具体的な数値や仕様で語らないと、そこから都市伝説が生まれます。

いい機会なので、わたしの主戦場であるAzureを例に、クラウドでどのくらいの性能を期待できるか、まとめてみようと思います。

シングルVMでどれだけ

話題となった記事でも触れられているように、クラウドはその生まれから、分散、スケールアウトな作りのアプリに向いています。ですが世の中には「そうできない」「そうするのが妥当ではない」システムもあります。記事ではそれを「企業システム」とくくっているようです。

わたしは原理主義者ではないので「クラウドに載せたかったら、そのシステムを作り直せ」とは思いません。作りを大きく変えなくても載せられる、それでクラウドの特徴を活かして幸せになれるのであれば、それでいいです。もちろん最適化するにこしたことはありませんが。

となると、クラウド活用の検討を進めるか、あきらめるか、判断材料のひとつは「スケールアウトできなくても、性能足りるか?」です。

この場合、1サーバ、VMあたりの性能上限が制約です。なので、AzureのシングルVM性能が鍵になります。

では、Azureの仮想マシンの提供リソースを確認しましょう。

“仮想マシンのサイズ”

ざっくりA、D、Gシリーズに分けられます。Aは初期からあるタイプ。DはSSDを採用した現行の主力。Gは昨年後半からUSリージョンで導入がはじまった、大物です。ガンダムだと後半、宇宙に出てから登場するモビルアーマー的な存在。現在、GシリーズがもっともVMあたり多くのリソースを提供できます。

企業システムではOLTPやIOバウンドなバッチ処理が多いと仮定します。では、Gシリーズ最大サイズ、Standard_GS5の主な仕様から、OLTPやバッチ処理性能の支配要素となるCPU、メモリ、IOPSを見てみましょう。

  • Standard_GS5の主な仕様
    • 32仮想CPUコア
    • 448GBメモリ
    • 80,000IOPS

メモリはクラウドだからといって特記事項はありません。クラウドの特徴が出るCPUとIOPSについて深掘りしていきます。

なお、現時点でまだ日本リージョンにはGシリーズが投入されていません。必要に応じ、公開スペックと後述のACUなどを使ってA、Dシリーズと相対評価してください。

32仮想CPUコアの規模感

クラウドのCPU性能表記は、なかなか悩ましいです。仮想化していますし、CPUは世代交代していきます。ちなみにAzureでは、ACU(Azure Compute Unit)という単位を使っています。

“パフォーマンスに関する考慮事項”

ACUはAzure内で相対評価をする場合にはいいのですが、「じゃあAzureの外からシステムもってきたとき、実際どのくらいさばけるのよ。いま持ってる/買えるサーバ製品でいうと、どのくらいよ」という問いには向きません。

クラウドや仮想化に関わらず、アプリの作りと処理するデータ、ハードの組み合わせで性能は変わります。動かしてみるのが一番です。せっかくイニシャルコストのかからないクラウドです。試しましょう。でもその前に、試す価値があるか判断しなければいけない。なにかしらの参考値が欲しい。予算と組織で動いてますから。わかります。

では例をあげましょう。俺のベンチマークを出したいところですが、「それじゃない」と突っ込まれそうです。ここはぐっと我慢して、企業でよく使われているERP、SAPのSAP SDベンチマークにしましょう。

“SAP Standard Application Benchmarks in Cloud Environments”

“SAP Standard Application Benchmarks”

SAPSという値が出てきます。販売管理アプリケーションがその基盤上でどれだけ仕事ができるかという指標です。

比較のため、3年ほど前の2ソケットマシン、現行2ソケットマシン、現行4ソケットマシンを選びました。単体サーバ性能をみるため、APとDBを1台のサーバにまとめた、2-Tierの値をとります。

DELL R720 Azure VM GS5 NEC R120f-2M FUJITSU RX4770 M2
Date 20124 20159 20157 20157
CPU Type Intel Xeon Processor E5-2690 Intel Xeon Processor E5-2698B v3 Intel Xeon Processor E5-2699 v3 Intel Xeon Processor E7-8890 v3
CPU Sockets 2 2 2 4
CPU Cores 16 32 (Virtual) 36 72
SD Benchmark Users 6,500 7,600 14,440 29,750
SAPS 35,970 41,670 79,880 162,500

3年前の2ソケットマシンより性能はいい。現行2ソケットマシンの半分程度が期待値でしょうか。ざっくりE5-2699 v3の物理18コアくらい。4ソケットは無理め。

なお補足ですが、もちろんSAPはAPサーバをスケールアウトする構成もとれます。その性能は3-Tierベンチマークで確認できます。Azure上で247,880SAPS出たそうです。

80,000IOPSの規模感

IOPS = IO Per Second、秒あたりどれだけIOできるかという指標です。Azure VM GS5ではPremium Storageを接続し、VMあたり最大80,000IOPSを提供します。

一般的に企業で使われているディスクアレイに載っているHDDのIOPSは、1本あたりおおよそ200です。IOPSに影響する要素は回転数で、よく回る15,000rpm FC/SAS HDDでだいたいこのくらい。

なので80,000 / 200 = 400。よって80,000IOPSを達成しようとすると、HDDを400本並べないといけません。小さくないです。

もちろんディスクアレイにはキャッシュがあるので、キャッシュヒット次第でIOPSは変わります。ベンダが胸を張って公開している値も、キャッシュに当てまくった数字であることが多いです。ですが誠実な技術者は「水物」なキャッシュヒットを前提にサイジングしません。アプリがアレイを占有できて、扱うデータの量や中身に変化がない場合は別ですが、それはまれでしょう。ヒットしない最悪の場合を考慮するはずです。

なお、数十万IOPSをこえるディスクアレイがあるのは事実です。でも「桁が違う。クラウドしょぼい」と思わないでください。ディスクアレイ全体の性能と、VMあたりどのくらい提供するかは、別の問題です。ひとつのVMがディスクアレイを占有するのでない限り、VMあたりのIOコントロールは必要です。そうでないと、暴れん坊VMの割を食うVMがでてきます。見えていないだけで、クラウドのバックエンドにはスケーラブルなストレージが鎮座しています。

結論

  • Intel x86 2ソケットモデルサーバで動いているようなシステムの移行であれば検討価値あり
  • メモリが448GB以上必要であれば難しい
  • サーバあたり80,000IOPS以上必要であれば難しい、でも本当にサーバあたりそれだけ必要か精査すべき

ちょっと前までオンプレ案件も担当していましたが、ここ数年は2ソケットサーバ案件中心、ときどき、4ソケット以上で興奮。という感覚です。みなさんはいかがでしょう。データはないのでご参考まで。

なにはともあれ、プロのみなさんは噂に流されず、制約を数値で把握して判断、設計しましょう。Azureではそのほかの制約条件も公開されていますので、ぜひご一読を。上限を緩和できるパラメータも、あります。

“Azure サブスクリプションとサービスの制限、クォータ、制約”

11 Jan 2016, 00:20

Azureでインフラデプロイツールを選ぶ時に考えていること

ケースバイケースだけど

Azureを生業にして、3か月たちます。ここまで、もっとも質問や議論が多いのが、デプロイメントの自動化についてです。進化が早いですし、選択肢も豊富。クラウド採用に合わせて自動化に挑戦するケースも増えてますので、自然なことと思います。

特に話題になるのが「どのツールを選べばいいか」。ツールというのは課題を解決する手段なので、まず課題を掘るべきです。ですが、まだ成熟していない領域で変化が激しいですし、ツールひとつで課題を解決できるとも限らない。複数のツールを組み合わせることも多く、依存関係もありそう。となると、考えるきっかけが欲しいのは、ごもっとも。

なので「ケースバイケース。以上」とは、言いにくい。

私見であっても、たたき台となる考え方なりパターンがWebに転がっていれば、参考になるかもしれない。それがこのエントリを書く動機です。わたしは他のプラットフォームからAzureに主戦場を移していますので、新鮮な意見が書けるかも、という背景も、あります。

書く前に前提など

対象はインフラレイヤのデプロイメントに絞ります。そして、インフラ = 物理/仮想ハードウェア(サーバ、ストレージ、ネットワーク) + OS + プラットフォームソフト(アプリじゃないもの、Webサーバ、ユーティリティ、etc)と定義します。

レイヤリングや用語は、 @gosukenator さんの“インフラ系技術の流れ”が参考になるので、合わせて読むと幸せになれるでしょう。このエントリで言うBootstrapping/Configurationレイヤが今回の焦点です。

では、わたしがツールを選ぶ時にどんなことを考えているのか、脳内をダンプしていきましょう。

そもそもツールで自動化すべきかを考える

いきなり萎えるそもそも論で恐縮ですが、重要です。たとえばあるソフトの試用目的で、同じ構成のサーバのデプロイは今後しなさそう、台数は1台、使うのは自分だけ、なんていう環境のデプロイまで、自動化する必要はないはずです。時短、工数削減、オペレーションミスリスクの軽減、そもそも自動化しないと運用がまわらない、など自動化によって得られる利益がその手間を上回るかを判断します。

なお「知っている/できる」人でないとその価値、利益はわかりません。やらないという判断は、腕があってはじめてできることです。

使い捨てられないかを考える

次は、ツールによって作った環境がどのように変化するか、変えられるかを検討します。ストレートに言うと、変化のタイミングで捨てられないか?新しいものに置き換えられないか?を考えます。もしこれができるのであれば、方式はとてもシンプルにできます。Immutable Infrastructure、Blue/Green Deploymentなどのやり口が注目されていますが、これらの根っこには「ちまちま変化を加えて複雑化するくらいなら、使い捨て/入れ替えてしまえ」という意識があります。

ですが、とは言ってもそんな大胆にできない事情もあると思います。Blue/Green Deploymentでは、入れ替えのタイミングでBlue、Green分のリソースが必要になりますし、切り替えにともなうリスクもあります。それを許容できない場合、同じインフラに変化を積んでいくことになります。ChefなどConfigurationレイヤで冪等なオペーレーションができるツールが注目されたのは、この変化を維持しやすいからです。

変化を積む場合にやるべきでないのは、中途半端に職人が真心こめて手作業してしまうことです。ツールでやると決めたら、少なくともそのカバー範囲はツールに任せましょう。でないといわゆる「手作業汚れ」「スノーフレークサーバ(雪の結晶のように、全部同じように見えて実はそれぞれ違う)」のダークサイドに堕ちます。

変化を積まないのであれば、インフラデプロイメント用途ではConfigurationレイヤのツールを導入しないという割り切りもできるでしょう。

優先事項や制約条件を洗い出す

アーキテクトが真っ白なキャンバスに画を描けることはほぼありません。きっと、先になんらかの優先事項や制約条件があるはずです。そして、ほとんどのシステムにおいて、インフラのデプロイは主役ではありません。ツールに合わせてもらえることはまれでしょう。様々な条件を選定にあたって洗い出す必要があります。

  • 社内/プロジェクト標準

 周知されていないだけで、推奨ツールが決まってたりします。あるある。そのツールの良し悪しは置いておいて、社内ノウハウの蓄積など、大きな目的がある場合には従うべきでしょう。

  • 他レイヤでの優先ツール

 インフラのデプロイに影響がありそうなツールがアプリ開発側で決まっていたりします。最近華やかなのがDockerです。Docker社が出してるツール群は上から下までカバー範囲も広く、デプロイツールと重複しがちです。組み合わせを検討しなければいけません。また、Apache Mesosもインフラとアプリのグレーゾーンに鎮座します。なかなか悩ましいですが、優先せざるをえません。

  • 規模

 いきなり1000台とか10000台規模を扱うユーザは多くないと思いますが、その規模になるとツールの性能限界にぶち当たったりします。念のため、意識はしましょう。ちなみに、1000台をひとつのツールの傘に入れずとも、たとえば10*100台にする設計ができないか、事前に考えておくと打ち手が増えます。

  • チーム or ひとり

 本番環境のデプロイ自動化はチームプレイになるので、ツールの導入はサーバ上になるでしょうし、構成ファイルの共有、バージョンコントロールなど考慮点は多いです。一方で、開発者が開発、検証用途で端末に導入し実行する使い方では、手軽さが求められます。誤解を恐れず例をあげると、前者にはChefが、後者にはAnsibleやTerraformがフィットしやすいです。

  • Windows or Linux

 Azure ARM Templateなど、はじめからマルチOS環境を前提に作られているツールはありますが、ほとんどのツールはその生まれがWindows、Linuxに寄っています。マルチOS対応が進んではいますが、活用にあたって、参考となる情報量には大きな差があります。たとえばマルチOS対応のツールであっても、DSCはWindowsの、ChefやAnsibleはLinuxの情報が圧倒的に多いです。これは意識せざるを得ません。使うOSでの十分な情報があるか確認します。

マネージドサービス、機能を活用する

マネージドサービス = プラットフォームが提供している機能です。Azureであれば、今回対象としているレイヤではARMがそれにあたります。デプロイツールは有用ですが、その導入や維持運用には本質的価値はありません。プラットフォームに任せられるのであれば、そうしたほうが楽です。

また、Azureのインフラは進化が早いため、それに対応するスピードも、本家ツールのほうが期待できます。

ですが、以前のエントリで触れたように、本家のツールであっても、すべてのレイヤをカバーできるほど万能ではありません。たとえばARM TemplateはインフラのBootstrappingには向いていますが冪等性が限定的であるため、ソフトウェアパッケージを足す/消す/入れ替えるを頻繁に繰り返す環境のConfiguration用途では、苦しいです。

よってARM Templateは、Immutableな環境で使う、もしくは、ChefなどのConfigurationツールと組み合わせて使うことを念頭に設計をします。

ARM Templateでは、ハード(VM、ストレージ、ネットワーク)の割り当て、OSの導入と設定、各種エージェントの導入が基本。それに加え、Immutableな環境ではプラットフォームソフトを導入してしまっていいでしょう。ARM TemplateにはDSCやシェルを実行するエクステンションが使えるので、活用します。

また、Bootstrapping時点で、Configurationツールを導入できてしまうのであれば、せっかくなので入れてしまいましょう。たとえばChefサーバのインストールは、ここで。

以上、ちょっとまとまりに欠けますが、ざっとわたしが意識していることを、挙げてみました。

汎用的 リファレンスアーキテクチャ

具体例があったほうが分かりやすいので、最後に汎用的な組み合わせを紹介します。

“Automating Deployment with Azure & Chef”

  • ARM TemplateでBootstrapping

    • VMを4つ作成、1つはLinux、他はWindows
    • ストレージ、ネットワークの作成
    • VMのストレージ、ネットワーク設定
    • OSの導入
    • ドメインコントローラサーバへのソフト導入、各種設定 (DSC/PowerShell Extension)
    • 他Windowsサーバへのソフト導入、各種設定、ドメイン参加 (PowerShell Extension)
    • LinuxへChefサーバを導入、各種設定 (Shell Extension)
  • ChefでConfiguration

    • 各ノードのChef bootstrap(言葉が混同しやすいので注意)
    • Chef Clientサービスの起動設定
    • DBサーバのDB領域ディスク作成、フォーマット
    • DBサーバへSQL Server 2014のインストール
    • ChefがDBサーバが設定通りになるよう維持し続ける

どうでしょう、役割分担がイメージできたでしょうか。いいドキュメントがあったので、ChefのLinux/Windows混在例を紹介しましたが、Windowsとの親和性や情報量を重視するなら、ChefをAzure Automation DSCに置き換えて挑戦してもいいでしょう。そのまた逆もありで、ChefならLinux染めな環境で、とこだわってもいいと思います。

書くことが意外に多かったので、また機会があれば、参考例を交えて紹介します。