COLUMN

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

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

本コラムでは、AWSのエンジニアがMicrosoft Azureを構築する手順をAWSの場合と比較しながら全3回に分けてご紹介しています。

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

第2回は「負荷分散サービスのApplication-Gateways」(AWSの「ロードバランサ―」部分に相当)の構築についてご紹介します。

負荷分散(Application Gateway)の構築

Application Gatewayを作成します。

AWSにおけるALBに該当する「Application Gateway」を作成します。

ロードバランサーを作成しそうになりますが、こちらはレイヤー4なのでAWSにおけるNLB相当になります。

画像の様に設定していきます。ALBと異なり、ゲートウェイ自身のスケーリング性能を”最大/最小インスタンス数”で指定する模様です。

また仮想ネットワークの選択においては、他のリソースが存在しないサブネットを選択する必要があるもようです。VMの存在するsubnet1を選択すると画像の様に警告が出現します。

今回はsubnet2を選択します。

アプリケーションゲートウェイに紐づけるパブリックIPを新規作成します。

バックエンドプールはAWSのALBにおけるターゲットグループのようなものとなります。

バックエンドプールを追加しターゲットとして、作成したVMのネットワークインターフェースを選択します。

最後にルーティング規則を設定します。AWSのALBにおけるリスナー設定とターゲットグループ設定のようなもので、バックエンドへのルーティング規則(ポートなど)を設定します。

リスナー設定として画像の様に設定します。フロントエンドIPはパブリックとすることを忘れないでください。

バックエンドターゲット設定として、先ほど作成したバックエンドプールを選択します。

バックエンド設定については新規作成しました。

以上の設定で作成した、アプリケーション ゲートウェイの概要より割り当てられたフロントエンドパブリックIPを確認しhttpアクセスしてみると無事 第一回で作成したApacheサイトが表示されました。ALBとは異なりFQDNは払い出されない模様です。

おわりに

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

第2回目として「負荷分散サービスのApplication-Gateways」(AWSの「ロードバランサ―」部分に相当)の構築について一連の操作記録をご紹介しました。

次回は「データベース」の構築と「Webサーバ」へのWordPressの導入手順をご紹介します。

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

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

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

ページ上部へ戻る

相談無料!プロが中立的にアドバイスいたします

クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。