一から丁寧にAzureで仮想マシンを立ててみる。

#はじめに
Azureのイベントが開催されているので、せっかくなので参加してみることにしてみました。
2つテーマがあるのですが、こちらの記事は**『知らないと損？あなたのお勧めAzureテクニックを大募集！』**というテーマの方のネタです。

細かいテクニック一つという訳ではなく、普段何気なく立てている仮想マシンを一からちゃんと理解して作成するという大きな意味でのテクニックと思っていただければと思います。**知らないと損？**の方にフォーカスを当てているということでご容赦ください。

普段意識せずに使っていた設定もあったので、必要なものを必要な分だけ設定することでコストパフォーマンスに優れる使い方ができると思います。

既にAzureのサブスクリプションがある前提で話を進めていきたいと思いますので、よろしくお願いします。

また、Azure CLIではなくAzure Portalから作成していきます。

#リソースグループの作成
Azureにはリソースグループという概念があり、VMを含めた色々なサービス（リソース）をグループ化することができます。
例えば、app-production、app-staging、app-developとかに分ければリソースの管理がしやすいし、もうdevelopいらないなとなったらapp-developのリソースグループを削除すれば、その中のリソースも全て削除されます。

全てのリソースはこのリソースグループ内にある必要があるので下記MicroSoftのドキュメントを見ながらリソースグループを作成します。

リソースグループの作成方法

リソースグループを作成するときにタグの欄があると思いますが、これはリソースグループを横断したグループ分けをする時に使うことができます。

例えば、app1-developとapp2-developというリソースグループをdevelopという環境で一纏めに管理したいときに、下図のようにタグ付けしておくと後で確認がしやすくなります。

こちらはリソースグループだけでなくリソースにもタグは付けられるので、違うリソースグループでも同じタグで分類することができます。

とりあえずここでは特に何も設定しなくて構いません。

#仮想マシンの作成
それでは本題の仮想マシンを作っていきましょう。
トップバーでvirtual machinesと検索してください。
するとVirtual Machinesが現れるのでこちらをクリック。

その後の画面でメニューバーの+追加というボタンから+仮想マシンをクリック。
そうすると仮想マシンの作成という画面が現れると思います。
これから一個ずつ解説していきます。

基本タブ

ここでは作成する仮想マシンの基本的な情報を入力していきます。

プロジェクトの詳細

サブスリプション

先ほどリソースグループを作成したサブスクリプションを選択してください。

リソースグループ

先ほど作成したリソースグループを選択してください。

インスタンスの詳細

仮想マシン名

好きな名前を付けてください。

地域

実際に仮想マシンが置かれる地域です。日本で使うサービスであれば東日本とか西日本を選んでおけば良いかと思います。ただ、地域によって値段も異なったり、地域によっては使えないサービスがあることに注意してください。
####可用性オプション

可用性とはサービスを継続して提供できる能力のことです。
この能力はSLA（Service Level Agreement）で規程されており、後述するディスクの項目でPremium SSDを選べば単一の**仮想マシンでも99.9%**が保証されています。
https://azure.microsoft.com/ja-jp/support/legal/sla/virtual-machines/v1_9/

99.9%というと1時間で約3.6秒止まる可能性があるわけです。1年間で9時間弱くらい。
これを許容できない場合は以下の可用性オプションを指定しましょう。

可用性について

#####可用性ゾーン
可用性ゾーンが有効になっている地域（リージョン）ではそれぞれのリージョンで複数（最低3つ）のデータセンターがあり、それぞれが物理的に独立しています。これは**Availability Zones（AZ）**と呼ばれています。
違うAZにあれば、例えば一つのデータセンターが障害でダメになっても他のAZのデータセンターのVMでサービスを継続できるっていう寸法です。

可用性オプションで可用性ゾーンを選択すると、選択肢で1,2,3と選ぶことができます。
そのため、一つ目のVMを1に、二つ目のVMを2に置くことで冗長化を図ります。

つまり可用性ゾーンを有効活用するためには、最低でも2つのVMが必要、かつそれぞれのVMを同期させる実装が必要です（可用性ゾーンを設定しただけでは2つのVMは同期しません）。

可用性ゾーンを適用し、違うAZで2つ以上のVMを立てた場合には**SLAは99.99%**となります。

#####可用性セット

こちらは可用性ゾーンとは違い、同じデータセンター内での設置となりますが、こちらを説明する前に2つの概念を説明します。

障害ドメイン：障害が及ぶ範囲のこと（電源とかを共有している範囲。同じラックにあると考えてください）
更新ドメイン：メンテナンス等、システム都合のVM停止が行われる範囲のこと

障害ドメインも更新ドメインも数を設定します。
つまり障害ドメインを2つにすると同じ可用性セットに2つのVMを立てた時に2つの障害ドメインに自動的に振り分けます。同様に更新ドメインを5つにするとこの可用性セットにVMを作成するたびにがその5つのどれかに自動的に振り分けられます（この5つが同時にメンテナンスで止まることはなく、停止しても1つずつです）。

障害ドメインを2、更新ドメインを5で可用性セットを設定し、VMをその可用性セットに10個立てた場合を下図に示します。
障害ドメイン1がなんらかの問題で使えなくなった場合、VM1~VM5が使用不可になりますが、VM6~VM10は生き残ります。
更新ドメイン1でメンテナンス作業が入った場合、VM1とVM6は使用不可になりますが、他の8台のVMは継続使用できます。

この図からも分かるとおり、可用性ゾーンと同様に複数のVMを立て、かつそれぞれのVMを同期する実装をしないと可用性の向上はしません。

デメリットとしては可用性セットはデータセンター内での障害には強いですが、データセンター自体がダメになってしまうとサービス継続ができなくなります。

可用性ゾーンの方がSLAが高いので、サービス継続が必要なものは可用性ゾーンを使い、レスポンスが重要なサービスでは同一データセンターで処理を行う可用性セットを選ぶという使い分けになるかと思います。

####イメージ
こちらでOSの種類を選びます。
OSの種類については説明を割愛させて頂きます。
####Azureスポットインスタンス
こちらはAzure側が持て余してるリソースを割引価格で使うことのできるサービスです。
安価な代わりに、Azureが提供できるリソースがなくなった場合には仮想マシンの継続利用ができなくなります。
急になくなっても良い開発環境やテスト環境を安価に構成できるサービスです。
「はい」を選んだ場合以下の選択ができます。

#####削除の種類
容量のみ：Azureが提供できるリソースがなくなった場合にサービス停止されます。
価格または容量：Azureが提供できるリソースの量により価格が変動するため、ユーザーが設定した価格を超えた場合にサービスを停止します。もしくはAzureが提供できるリソースがなくなった場合にサービス停止されます。

#####削除ポリシー
停止/割り当て解除：VMを停止状態（割り当て解除状態）にします。この状態でもディスクストレージの課金は停止しません。また、再割り当ても成功する保証はありません。
削除：ストレージ含めて削除されるので関連する課金は停止します。

####サイズ
必要なスペックのVMを選んでください。サイズによってはスポットインスタンス使えないものもあります。
Virtual Machines シリーズ

管理者アカウント

どのように仮想マシンにアクセスするかを設定します。

認証の種類

SSH公開キーかパスワードでアクセスするかを決めます。ただ、パスワードでアクセスしたことないので申し訳ないですが、ここはセキュリティも考慮してSSH公開キーでのアクセスのみ説明します。
パスワードの場合は仮想マシンにアクセスする時にユーザー名とパスワードを要求されるだけかと思います。

ユーザー名

自分で決めたユーザー名を設定してください。

SSH公開キーのソース

新しいキーの組の生成を選択すると、VM作成時に秘密鍵（pemファイル）をダウンロードできます。

ダウンロードした秘密鍵で作成したVMに接続します。
こちらを選択するとリソースグループに公開鍵のリソースが生成されます。

Azureに格納されている既存のキーを使用するを選択する場合には上記のようなキーセットを作成しておく必要があります。

既存の公開キーを使用を選択する場合にはローカルでキーを作成し、公開鍵を入力し、ペアの秘密鍵でVMにアクセスします。

###受信ポートの規則
こちらはあとでネットワークの項目でセットするので一旦無視してください。

##ディスク

###ディスクのオプション
####OSディスクの種類

デフォルトはPremium SSDになっています。（VMのSLAの99.9%もこれが基準）
Premium SSD > Standard SSD > Standard HDD
という順番で価格もパフォーマンスも上がりますが、Premium SSDにはバーストという機能がついており、急にディスクへのアクセスが増えた時にでも対応できるようになっています。

そのためI/Oが多い本番ではPremium SSD
I/Oが比較的少ないアプリケーションサーバー、WebサーバーではStandard SSD
バックアップや開発環境、不定期アクセスの環境ではStandard HDD
という使い分け等が考えられます。
Ultra DiskはPremium SSDの上位版という位置付けなので、高いI/Oを必要とするNoSQL等に適用すると良いですが、使用可能なリージョンやシリーズに制限があります。

ディスクの種類

####暗号化の種類

保存したデータをどのように暗号化するかを選択します。
暗号化することで、仮に保存されたデータが盗み取られたとしても復号化しないと盗んだ人も中身が見られない状態になります。

プラットフォームマネージドキーを使用した保存時の暗号化：Azureが用意したキーを使って勝手に暗号化してくれるので、普通はこれを選んでおけば問題ないかと思います。

カスタマーマネージドキーを使用した保存時の暗号化：こちらは自分でキーを準備しなければなりません。こちらを選択するとディスク暗号化セットを選択する欄が出てきますので、先にディスク暗号化セットを作成してください（作成方法は割愛。作成方法はこちら）

プラットフォームマネージドキーとカスタマーマネージドキーを使用した二重暗号化：これが一番強い暗号化の方法です。名前の通りですが、上記二つを組み合わせた方法です。

###データディスク
仮想マシンを作成した時点でデータディスクは作られますが、新たにディスクを追加したい場合にはこちらで新しいディスクを作成する、もしくは既存のディスクを接続することができます。
ディスクの作成についての詳細はここでは割愛させて頂きます。
###詳細
####マネージドディスクを使用
MicroSoftも基本的にはマネージドディスクに使用を推奨しています。
可用性セットや可用性ゾーンもマネージドディスクのみで使用可能となっています。
Azure マネージド ディスクの概要

オンプレミスのデータをそのまま持ってくる際などにはアンマネージドディスクが使用されるようです。

####エフェメラルOSディスクを使用する
まずAzureのストレージは永続化されているディスクとホストマシンのストレージに分かれています。
VMの再起動の度にデータが消えては困るので、OSディスクは通常永続化されているディスクに保存されており、ホストマシンのストレージは一時的なデータを保存しています。

OSディスクをこのホストマシンに保存することで、データが消える可能性はありますが、高速なレスポンスを期待することができます。バッチ処理などはこちらを使うことでメリットがあると考えられます。

##ネットワーク
Azureでは（Azureじゃなくてもですが）、下記のような構成になっています。

仮想ネットワークは外部から分離されたプライベートネットワークになっています。
後述するパブリック受信ポートを選択しないと外部からアクセスすることはできません。

さらにその中でサブネットを作ることができ、サブネット内では設定したプライベートIPアドレスで各VM間のアクセスが可能です。（同じ仮想ネットワークにいても同じサブネット内でないとプライベートIPではアクセスできない）

###ネットワークインターフェース
####仮想ネットワーク
ここは特に指定しなければ勝手に作成されます。
必要であれば新規作成し、必要なプライベートIPの割り当てを行ってください。
サブネットも同様です。
####パブリックIP
こちらも指定しなければ勝手に作成されます。
新規作成時にはSKUと割り当てが選べます（Standardの場合は静的割り当てのみ）。

BasicとStandardの違いですが、Standardではゾーンの冗長性を選択することができます。
また、ロードバランサーを設定する際に、このSKUはロードバランサーのSKUと合わせないといけません。
つまり、ロードバランサーでStandardを選ぶ際にはこちらのPublic IPのSKUもStandardを選ぶ必要があります。

パブリック IP アドレスについて

####NICネットワークセキュリティグループ
なし：なしの場合は全ポートがパブリックになる可能性があります。
Basic：後の設定で基本的なポート番号を許可する設定をすることができます。
詳細：許可するポート番号やサービスの詳細設定を行うことができます（こちらの設定の説明は割愛）。
####パブリック受信ポート
上記でBasicを選択した場合に選べる選択肢です。
なしの場合はどのポートもオープンにならないので外部からアクセスできません。
選択したポートを許可するの場合は、受信ポートを選択の欄で選択したポートにアクセス可能です。
####高速ネットワーク
オンにした場合にはネットワークが高速化されます。
これは色々なフィルタリングを行う仮想スイッチの処理を物理的なハードウェア側に移すことで高速化されます。

Azure CLI で、高速ネットワークを使用する Linux 仮想マシンを作成する
###負荷分散
**この仮想マシンを既存の負荷分散ソリューションの後ろに配置しますか？**という質問がされますが、はいを選んだ場合に作成するVMを既に作っているロードバランサーやアプリケーションゲートウェイの後ろに配置することができます。
##管理
###監視
####ブート診断
こちらはVM立ち上げ時のエラーの診断を行う機能です。
マネージドストレージアカウントで有効にする場合はAzureで管理するストレージにログを保存するので、新しいユーザーストレージアカウントが作成されず、VM作成にかかる時間が短縮できます（推奨方法）。
カスタムストレージアカウントで有効にするを選択した場合には自分で診断データを保存するストレージを選択することになります。
無効化はこちらの診断を無効化します。

Azure のブート診断
####OSのゲスト診断
こちらはONにすることで仮想マシンのログを収集することができます。
ログを保存するストレージの料金がかかるようです。
###ID
####システム割り当てマネージドID
こちらをONにすることでAADに登録され、他リソースに対してロールベースのアクセスが可能になります。
つまり、このVMがあるリソース（例えばデータベース）にアクセスできるけど、別のリソースにはアクセスできないといった設定を可能にします。
###Azure Active Directory
####AAD資格情報を使用してログインする
こちらの設定をすることで、AADのあるロールがないとアクセスできないように設定することができます。（プレビュー機能）
###自動シャットダウン
こちらは名前の通りですが、VMを自動でシャットダウンさせ無駄な課金を止めることができます。主にテスト環境で使用すると良いかと思います。
###バックアップ
こちらも名前通りですが、定期的にVMのバックアップを取ることができます。
Recovery Services コンテナーはバックアップ用のストレージサービスです。
また、バックアップポリシーでどのタイミングでバックアップを行い、そのバックアップをどの程度保存するかなどを設定することができます。

Recovery Services コンテナーに Azure VM をバックアップする
##詳細
###拡張機能
こちらで色々な拡張機能を追加することができます。
（例：外部のインフラ監視システム等）
###カスタムデータとcloud-init
VMの初回起動時に設定するデータやインストールしておきたいパッケージを指定しておくことでVM作成時に実行することができます。

Azure での仮想マシンに対する cloud-init のサポート
###ホスト
Azureでは物理サーバーを専有して使うことができます。
その物理サーバー内に好きなように仮想マシンを構成したり、自由度の高い設計が可能です。
専有した物理サーバーのスペック内で好きなだけ仮想マシンを構成できます（ソフトウェアライセンス料は都度必要です）。
また、物理的に同じサーバーに構成できるため仮想マシン間でのデータ通信の速度の向上も期待できます。
ただし、使用しなくても専有した物理サーバーの料金はかかってしまうので注意が必要です。

Azure 専用ホスト

###近接配置グループ
可用性ゾーンの説明と少し矛盾してしまいますが、同じ可用性ゾーンを設定した場合でもそのゾーンには物理的に離れたデータセンターが含まれることがあります。つまり1ゾーンに複数のデータセンターがセットで含まれていることがあります。

近接配置グループを設定することで同じデータセンターに設置し、物理的に仮想マシン間の距離を短くすることができます。物理的な距離が近づくことで仮想マシン間通信の速度の向上が期待できます。（ラックの位置まで近づくかどうかは分かりませんでした。）

近接通信配置グループ

###VMの生成
Azureでは第一世代のVM（Gen1）と第二世代のVM（Gen2）を選択することができます。ただし、第二世代を選択できるVMのサイズや種類は制限があります。
詳細は公式の下記リンクにまとまっていますが、例えば第二世代の場合は、ブートやディスクコントローラーが異なったり、扱えるOSのサイズが異なっています。

第 1 世代と第 2 世代の機能の比較

ドキュメントによれば起動速度やインストール速度が第二世代の方が早いらしいですが、パフォーマンスに大きな違いはないということです。
価格は同じなので特に理由がなければ第二世代を選んで問題ないかと思います。

##タグ
こちらはリソースグループを作成した時と同じで、リソースグループ外でのグルーピングに使用可能です。
##確認および作成
設定項目に不備がないかAzureが検証してくれます。
問題がなければ仮想マシンの作成を行うことができます。
お疲れ様でした。

#まとめ
ただ仮想マシンを立てるといっても意外に知っておいた方が良いことがたくさんありました。
自分の環境に必要な設定をここでやっておくことでコスト最適化が図れるんじゃないかと思います。

ちなみに本文中の画像はダークモードでやってるのですが、トップバーのポータルの設定のテーマの選択で変えられます（これがある意味一番のお手軽目に優しいテクニック）。

使ったことない設定もあったのでもし間違いがありましたら是非ともご指摘頂けると幸いです。