COLUMN

2023.03.01 ｜ Writer：NTT東日本　okuda

【テックメモシリーズ】AWSエンジニアが基本的なweb三層構築からMicrosoft Azureを紐解いてみた　【第1回】

	NTT東日本が行ってきたさまざまな開発テクニックを紹介する「テックメモシリーズ」、開発者が実際の業務のなかで書き溜めていった作業メモをそのままリアルにご紹介するシリーズとなります。

今回はAWSのエンジニアがMicrosoft Azureを構築する手順をAWSの場合と比較しながら全３回に分けてご紹介します。

今回、Microsoft Azureに構築していくものはAWSでは一般的なロードバランサ―、Webサーバ、データベースから成る「Web三層構造」になります。

その第１回は仮想ネットワーク環境の構築とWebサーバの実行環境となる仮想マシン(Virtual Machine：VM)の構築についてご紹介します。

VM(Virtual Machine)の構築

リソースグループを作成する。

「リソースグループ」を作成していきます。リソースグループはAzureにおいて必須のものとなり、一つのシステムとしての各リソースをグルーピング、マッピングしてくれるサービスとなります。

名前やリージョンを設定していきます。

この時設定するリージョンはグループに属する各リソースとのリージョンと一致させる必要はなく、あくまで各リソースのグループとしてのメタデータが保存される場所となります。

仮想ネットワークを作成します。

この「仮想ネットワーク」はAWSにおけるVPC+サブネットの包括的な設定のようなものでネットワーク空間を作成します。

ただしAWSと異なり、サブネットはゾーン（AWSにおけるAZ）をまたいで作成できます。実際に設定画面にゾーンの選択はありませんでした。

セキュリティの設定には見慣れないものが3つ並んでいます。

Azure Bation はAWSにおけるSSMのセッションマネージャに類似するwebコンソールからのホストへのターミナルアクセスを可能にします。ただし、当該VMからエンドポイントへの疎通性や、Baationの存在するネットワークの明示化などの対応が必要となり、関連してAzure Bastion には 'AzureBastionSubnet' という名前のサブネットの用意が必要となります。

Firewall はAWSにおけるNetowork firewall に該当するものでネットワーク空間を出入りするパケットのフィルタリングなどができるようです。

Azure DDoS Protection StandardはAWSにおけるAWS Shieldにあたるもので、DDos攻撃対策に用いられます。

今回はこれら機能はOFFにしておきます。

IPアドレスの設定においては”既定”という名前のサブネットをsubnet1に変更し、subnet2,subnet3を追加します。

サブネットの追加画面では画像の様に設定を行っていきます。

セキュリティの項目については特段設定しないでおきます。

AWSにおいては、サブネットに対するACL、リソースに対するセキュリティグループで通過通信の許可設定を定義しておりましたが、Azureにおいてはネットワークセキュリティグループという一つリソースのみで、サブネットに対してもリソースに対してもアタッチを行うことができ、通信の許可・拒否設定します。アタッチは必須ではないですが、リソースとサブネットへの許可・拒否設定は＆条件で評価されます。どちらにもアタッチされていない場合は、許可も拒否も設定がされていないことになるので疎通性がなくなります。

ルートテーブルについてはなしとなっていますが、サブネット作成時点で自動でシステムルートというものが作成、適用されています。このシステムルートにより、デフォルトで0.0.0.0/0の向き先はインターネットへとなっており、AWSの様に0.0.0.0/0の宛先次第でパブリック、プライベートなどの区別はありません。ただしカスタムでルートテーブルを作成し適用すると、ルーティングルールは上書きされます。

そのような関係上、NATゲートウェイを利用する場合はカスタムルートテーブルが必要となります。

ここで私の環境では下記のエラー(PublicIPCountLimitReached)が発生しました。

エラー文のままですが、PublicIPの数のクォータに引っかかった模様です。

「クォータ」から各種制限状況を確認することができるのですが、AWSの「サービスクォータ」より見やすい点がいいと思いました。

緩和申請を行うと。すぐに承認されました。

VM（VirtualMachine）を作成します。

AWSにおけるEC2に該当する「VM（VirtualMachine）」を作成します。

リソースグループやスペック、OSイメージなどの項目を画像の通りに設定していきます。

イメージはCentOS7.9を使います。ユーザ名は後ほどのSSH接続の際に用いるOSユーザ名です。

AWSとの違いという観点で気になるのは可用性オプションです。

この時の可用性ゾーンはリージョン内のどのゾーン(AZ)にVMを立てるか？というもの明示的に指定できるようになるものです。東京リージョンにおいては1～3の中から選びます。

可用性セットVMをどのハードウェアに立てるか？というものを分離することができるものです。

複数のVMを立てるときに可用性ゾーンは、ゾーンごとでのデプロイを明示化することによってゾーン単位での可用性を実現したのに対し、可用性セットはハードウェア単位での可用性を実現するものとなります。

今回は冗長は必要なしとして作成します。

ネットワーク設定にて

ネットワークセキュリティグループは前述の通り、設定しなくても作成は出来てしまいますが、画像の通り”Basic”でHTTP（80）とSSH（22）をパブリック受信ポートとして許可したものを作成しておきます。

その他の設定はデフォルトで作成します。

PemキーのダウンロードはAWSとおなじですね。忘れずにダウンロードします。

Apacheのインストール

パブリックIPをVMの概要から確認し、sshアクセスします。

Apacheをインストールしてhtml の設定をします。

sudo su -
yum install httpd

systemctl start httpd.service

systemctl status httpd.service

systemctl enable httpd.service

systemctl is-enabled httpd.service

cd /var/www/html

cat <<EOF > index.html
<html>
<head><title>好きな文字</title></head>
<body>
<p>こんにちは奥田[ご自分の名前]です</p>
</body>
</html>
EOF

「概要」からパブリックIPを確認します。httpブラウザしてみると。

確認したIPにアクセスしてみると

できました。

おわりに

今回からAWSのエンジニアがAWSと比較しながらMicrosoft Azureを構築してみたというテーマで、AWSでは一般的な「Web三層構造」（ロードバランサ―、Webサーバ、データベース）の構築手順を３回に分けてご紹介しています。

第１回目として「仮想ネットワーク環境の構築」と「仮想マシン(Virtual Machine：VM)の構築」について、一連の操作記録をご紹介しました。

次回は「ロードバランサ―部分」、Microsoft Azureの場合では「負荷分散サービスのApplication-Gateways」の部分についての構築手順をご紹介します。

AWS経験者視点で構築手順をご紹介しましたので、Microsoft Azureをあまりご存じないAWSのエンジニアの方々にはMicrosoft Azureとの違いがよくお分かりになったと思います。今後Microsoft Azureの構築に手を広げる際のご参考になれば幸いです。

これからもNTT東日本が行ってきたさまざまな開発テクニックを紹介していきますのでご期待ください。

Amazon Web Services(AWS)および記載するすべてのAmazonのサービス名は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
Microsoft Azureは、Microsoft Corporationの米国及びその他の国における登録商標または商標です。