Azureで「お問い合わせフォーム付きサイト」をサーバーレスで作ってみた！前編

（2020年1月24日掲載）

ソフトバンク株式会社のエキスパートSE 葉山恵一です。
法人のお客さま向けに各種クラウドの提案、設計、構築を担当しています。

さて、今回はMicrosoft Azure上にお問い合わせフォーム付きサイトをサーバレスで作ってみたという内容で、ポイントとなる箇所や特に法人のユースケースで選定すべきCDN等、お役立ち情報を発信したいと思います。

前後編の2部構成で、この記事は 「前編」 です。後編は、下記からご確認ください。
Azureで「お問い合わせフォーム付きサイト」をサーバーレスで作ってみた！後編

目次

はじめに

サーバレスでWebサイトを構成するということは、以前からあるWebホスティングサービスにコンテンツを配置することとよく似ています。
ホスティングサービスは、ホスト元となるインフラの維持管理やOSのメンテナンスが不要で管理コストが低く、コンテンツを配置するだけで簡単にWebサイトを公開できる手軽さから、現在も幅広く利用されています。

これに対して、Azure、GCP、Alibaba Cloud等のパブリッククラウドサービスでは、スケーラブルで拡張性・可用性の高い標準サービスを利用し、IaaSサービス上で仮想マシンをOSも含めて利用することも可能ですし、PaaS/サーバレスの環境でWebサイトを公開することも可能です。
PaaS/サーバレスの環境では、従来型Webホスティングサービスと比べてより抽象化が進んでおり、これまで以上にバックエンドのインフラに対する考慮が不要になることや、スケーラビリティが確保されていること等、利用者は稼働するコンテンツやアプリケーションに、より集中出来るようになったという点が大きなメリットです。
一方PaaS/サーバレスの環境でさまざまなこと(今回の例ですとWebホスティング)を実現するためには、いくつかのサービスを組み合わせて利用することが多く、設定や操作の範囲が広くなってしまい、これによって「難しい！」と感じてしまいがちなようです。

決して難易度が高いわけではなく、ある程度決まった手順や推奨される構成がありますので、「前編」ではMicrosoft Azureを利用し、以下の内容に絞って勘所を解説いたします。

• コンテンツ置き場を作成
• コンテンツ置き場からHTTPSで直接Webサイトを公開
• 独自ドメインでのHTTPS公開

セルフデプロイを試そうとされるすべての方にとって、この記事が有益なものになれば幸いです。それでは早速作業を開始しましょう。

1. Blobストレージによる静的サイト公開

ここではBlobストレージコンテナーを用意し、HTMLファイル等のWebコンテンツを配置した後に、Blobストレージコンテナーの機能のみを使いHTTPSでWeb公開することを目指します。

1.1 コンテンツの用意

まずはコンテンツを用意しましょう。今回は後編に向けて以下の2コンテンツを用意してみました。

• トップページ兼フォーム     - index.html
• 共通スタイルシート          - common.css

今回のコンテンツはSanwebe.comより「10 CSS HTML Form Designs」のForm Style 2を参考にさせていただいています。

ご自身でコンテンツを用意する場合も後編のPOSTに備えて、フォームの各プロパティは以下のように調整してください。

<form action="" method="post">
<input name="field1" type="text" value="" />
<input name="field2" type="text" value="" />
<input maxlength="4" name="tel_no_1" type="text" value="" />
<input maxlength="4" name="tel_no_2" type="text" value="" />
<input maxlength="10" name="tel_no_3" type="text" value="" />
<select name="field4">
	<option value="general">一般的なお問い合わせ</option>
	<option value="tech">技術的なお問い合わせ</option>
	<option value="other">その他</option>
</select>
<textarea name="field5"></textarea> <input type="submit" />
</form>

1.2 ストレージアカウントの作成とコンテンツの配置

コンテンツが用意出来たらコンテンツ置き場兼、Webフロントエンドになるストレージアカウントを作成します。

BLOBストレージコンテナーで静的サイトをホストするためには、アカウントの種類で図のように「StroageV2 (汎用 v2)」を選択します。
また、今回最終的にはAzure CDNを利用するのですが、BLOB単体で静的サイトとして公開する機能も試しますので、ここではパフォーマンス Standardを選択します。
サブスクリプションやリソースグループは保有する環境に合わせて選択、もしくは作成してください。ストレージアカウント名はここでは「serverlessformpoc」としました。

また、以下の通り「安全な転送が必須」の項目が有効であることと、「接続ポイント」がパブリックエンドポイント(すべてのネットワーク)になっていることを確認してください。

デプロイが完了したら、「静的なWebサイト」を有効化します。

これにより $web コンテナーが透過的にデプロイされます。
この後の作業に備えてプライマリエンドポイントのURLをメモしておきます。
インデックスドキュメントは index.html を指定しましょう。
エラードキュメントは今回配置しませんが error.html を指定しておきます。

デプロイされた $web コンテナーに早速コンテンツをアップロードしましょう。

1.3 プライマリエンドポイント宛のhttps接続テスト

1.1でメモしたプライマリエンドポイントのURLへの接続をテストしてみましょう。以下のように用意したコンテンツが表示されたことを確認してください。
今回のデモではSanwebe.comより「10 CSS HTML Form Designs」のForm Style 2をベースにお問い合わせフォームのサンプルページを作りました。)

念のため、証明書を確認してみると、DigiCertをルートCAとするドメイン認証ベースのワイルドカード証明書がホストされていることが確認できます。

試しにURLを https:// から http:// に変更してみると、接続できません。

これはデプロイ時に「安全な転送が必須」の項目を有効にしたためで、これによって常時SSL化が有効化されていることを確認できます。
実際の運用シーンでは、HTTP接続の場合にはHTTPSへのリダイレクトを希望されることが多いと思います。これは 「3.6 Rewrite ruleの設定、ついでにHTTP to HTTPSリダイレクト設定」で解説しています。

2. ストレージアカウントへのカスタムドメイン登録

さて、BLOBストレージコンテナーから払い出されたURLベースでのアクセスを試しましたが、SEOの観点等からも当然独自ドメインを使いたいですよね。
ここでは私が個人的に保有しているゾーンに「www」Aレコードを登録し、カスタムドメインでアクセスできるように構成してみようと思います。

2.1 Azure DNSへのゾーン登録

Azure DNSゾーン上に、保有しているドメインの登録を実行します。 セキュリティの観点から、画像上DNSゾーン名の一部にマスクをかけています。

すでに所有しているゾーンからサブドメインを切り出す場合はNSレコードを、新規に取得したドメインをホストする場合はレジストリ登録のNSレコードを、それぞれAzure DNSゾーンで払い出されたNSレコードに紐づけます。
今回使用した個人所有のゾーンについては、サブドメインの切り出しです。

2.2カスタムドメインの登録

ここではBlobストレージに対して、カスタムドメインを登録していきます。
ストレージアカウント > Blob service > カスタムドメインと進みます。
カスタムドメインのセットアップ方法が2種類アナウンスされていますが、推奨は「2」の方法です。
書かれている通りなのですが、「1」の方法は実際に登録するCNAMEレコードをあらかじめBLOBストレージコンテナーに向けてしまい、これをAzure側で確認するという流れになっています。当然ダウンタイムが発生します。 対して「2」の方法は、asverifyという検証用のCNAMEレコードを登録するというものですので、既設/新設のドメインに関わらず影響がなく安全です。

Azure ストレージ アカウントの BLOB データまたは Web サイト データにアクセスするためのカスタム ドメイン (www.contoso.com など) を構成します。カスタム ドメインのセットアップ方法は 2 種類あります。

• 1. DNS プロバイダーで、ドメイン (例: www.contoso.com) から serverlessformpoc.blob.core.windows.net または serverlessformpoc.z11.web.core.windows.net をポイントする CNAME レコードを作成し、ドメインを下に入力します。この方法の方がシンプルですが、Azure がドメインの登録を確認している間に若干のダウンタイムが発生します。
• 2. DNS プロバイダーで、"asverify" サブドメイン (例: asverify.serverlessformpoc.blob.core.windows.net) から asverify.serverlessformpoc.z11.web.core.windows.net または asverify.間接 CNAME 検証を使用する までを指定した CNAME レコードを作成します。この手順が完了したら、ドメインを下に入力します ('asverify' サブドメインを除く)。この方法では、ダウンタイムが発生しません。この方法を使用するには、[{3}] チェックボックスをオンにします。

今回はデプロイをした静的Webサイトコンテナー($web)に対してカスタムドメインを登録するため、赤枠の「serverlessformpoc.z11.web.core.windows.net」と、「asverify.serverlessformpoc.z11.web.core.windows.net」をメモします。
ちなみに青枠の「serverlessformpoc.blob.core.windows.net」はこのBLOBストレージ自体のFQDNです。

Azure DNSゾーンに移動し、「asverify.www」というCNAMEレコードを「asverify.serverlessformpoc.z11.web.core.windows.net」向けに設定します。
今回は新規に取得したドメインですので、「www」というレコードのCNAMEとして先程メモした「serverlessformpoc.z11.web.core.windows.net」を一緒に登録します。
もし、既存で利用中のレコードを変更する場合には、「asverify.www」レコードの登録のみとし、本番「www」レコードはしっかりとスケジュールしてから切り替えてくださいね。

また、「www」レコードのTTLについてはこの先レコード内容を変更する作業が予定されていますので、短め(ここでは1分)に設定しておきます。
DNSレコードの設定が完了したら、手元の端末から nslookupコマンドなどを使い登録したレコードを正しく解決できるか確認してください。
問題なければいよいよカスタムドメインを登録します。

先程登録したレコードをカスタムドメインとして設定するわけですが、この時「間接CNAME検証を使用する」に忘れずにチェックをいれてください。
これは先程説明した、「2」の方法(asverifyを利用した検証)の場合に有効化しておくべきチェックボックスです。

2.3カスタムドメイン宛のhttps接続テスト

登録が完了したカスタムドメインに早速アクセスしてみましょう。
今回は「安全な転送が必須」オプションを有効にしているので、HTTPSでのみ接続可能です。

https:// www.<登録したカスタムドメイン名>/

SSL証明書の警告が表示されてしまいました。
カスタムドメインを使うとサーバ証明書と接続先ドメインの不一致が起きるため、このような状態になります。
警告を無視して閲覧を進めればコンテンツは表示出来ますが、これでは問題がありますね。
BLOBストレージコンテナーでは独自のSSL証明書をホストすることが出来ないため、Azure CDNを使用して課題を解決してみます。

3. CDN経由でのHTTPS接続、署名付きURL、HTTP to HTTPSリダイレクト

カスタムドメインを利用し警告なくHTTPS接続をするためには、カスタムドメイン用のSSL証明書をホストする必要があります。
今回はAzure CDNを利用して、Azure上で無償で提供されるDV SSL証明書をホストします。OV証明書やEV証明書を利用する場合、別途取得した証明書を、キーコンテナーへインポートすることで利用可能です。

3.1 BLOBストレージコンテナーの移動

今回CDNを利用する為、BLOBストレージコンテナー側での静的サイト公開は不要になりました。
別途「web」というコンテナーを作成し、「$ｗeb」へ配置した各コンテンツを予め移動しておきましょう。

3.2 Azure CDNのデプロイ

コンテンツを移動したら、CDNをデプロイします。
デプロイするCDNですが、Azureでは以下4タイプのCDNを選択可能です。

• Standard Microsoft
• Standard Akamai
• Standard Verizon
• Premium Verizon

それぞれに特徴がありますが、一般的に企業のコーポレートサイト等をホストする場合は「Premium Verizon」がおすすめです。
以下表に今回利用した機能に関わる対応表をまとめましたが、高度な機能は現状(2019/12)だと Premium Verizonのみ対応となっているものばかりです。

	Microsoft	Akamai	Verizon	Premium Verizon
カスタム ドメイン HTTPS	〇	〇	〇	〇
キャッシュ/ヘッダーの設定				〇
URL のリダイレクト/書き換え				〇
最初の10TB転送料金 (ゾーン2) (2019/11時点)	¥14.448/GB	¥14.448/GB	¥14.448/GB	¥26.096/GB

例えば、「HTTPアクセス時にHTTPSへのリダイレクトを実行」や、脆弱性検査で指摘されがちな「カスタムHTTPヘッダーの挿入」等、従来フロントWebサーバ上のミドルウェアや、L7ロードバランサーで実装されていたような機能が簡単に手に入ります。
また、後述する Shared Access Signature (SAS)を利用する場合、URLに含まれるトークンをURL書き換えによって隠蔽できることも Premium Verizonを選択する理由になるでしょう。
その分、転送量あたりの従量課金額は高く設定されていますが、上述したような機能を別な手段で構築・維持・管理等されるようでしたら、Premium Verizonを選択するほうが安上がりかもしれません。(もちろん転送量によりますが...)
そんなわけで今回は、Premium Verizon を選定します。

Azure上でのCDNの識別名(ここでは serverlessformpoc)、価格レベルを「Premium Verizon」、エンドポイント名(ここでは serverlessformpoc)を入力し、CDNを作成します。
ちなみにエンドポイント名はAzure CDNで一意な名称である必要があります。
作成が完了したらリソースへ移動します。

3.3 Azure CDNへのカスタムドメイン登録とSSL証明書発行

先程BLOBストレージコンテナーへ登録したように、今度はAzure CDNへカスタムドメインを登録しましょう。

2-2 「2」と同様の要領で、「cdnverify」CNAMEレコードを登録し、値をCDNエンドポイントのFQDN(ここでは serverlessformpoc.azureedge.net)とすることで、本番環境に影響なく検証することが可能です。
今回は登録済みの「www」レコードを変更可能でしたので、直接これをCDNエンドポイントのFQDNへ変更します。

2-2でBLOBストレージコンテナーで静的サイトをホストした際には「serverlessformpoc.z11.web.core.windows.net」を登録しましが、今回はストレージコンテナー自体のFQDNである「serverlessformpoc.blob.core.windows.net」をセットすることに注意してください。
DNSレコードの登録が完了したら、カスタムドメインを登録します。

カスタムドメインの登録が完了したら、登録されたドメインをクリックし、「カスタムドメインHTTPS」をオンに変更します。
「証明書の管理の種類」をCDNマネージドに設定し、保存します。

保存が完了すると、図のようにプログレスが進捗します。
DNSレコードの設定が間違っていなければ、24時間以内には完了しますので気長に待ちましょう。
たったこれだけの手順で、AzureからDVベースのSSL証明書が発行され、CDN上にデプロイされます。
さらには有効期限切れ時の更新すらも自動で実行されますので、定期的な運用作業も必要ありません。
また、これら調達や更新にかかる追加費用も無しという、夢のようなサービスになっています。ぜひご検討を。

3.4 CDN配信元のパスとプロトコル設定

HTTPS有効化の完了を待つ間に「配信元」設定で「配信元のパス」を /web とし、「プロトコル」のHTTPチェックを外しておきます。
配信元のパス設定を設定しない場合は、接続先URLとして常にコンテナー名を指定する必要が生じます。

3.5 BLOBストレージへのShared Access Signature (SAS)設定

カスタムドメインHTTPSが有効化されるのを待っている間、BlobストレージからShared Access Signature (SAS)トークンを発行しておきましょう。 これはCDNからBLOBに対しての読み取りアクセスを有効化するために必要です。
匿名アクセスに対して読み取りの権限を与えることもできるのですが、より高いレベルのセキュリティを維持するためにも、SASトークンを発行しておきましょう。

図の通り必要な権限に絞りSASトークンを発行します。
有効期限は本来短期間ローテートすることが望ましいのですが、ここでは長期間有効なトークンを作成しました。

トークンが発行されたら、「SASトークン」をメモしておきます。

3.6 Rewrite ruleの設定、ついでにHTTP to HTTPSリダイレクト設定

ここでは Premium Verizon CDNの機能であるURLのリダイレクト/書き換えを、専用のUIから設定していきます。

Azure CDNから 高度な機能 > 管理 とクリックし、Rules Engineの管理コンソールを開きます。
上部メニュー HTTP Large > Rules Engine を開きましょう。

以下のルールを追加します。

ルール名: SAS Rewrite rule
IF: 常に
機能: URL Rewrite
Source : /×××/<エンドポイント名> /         (.*)
Destination : /×××/<エンドポイント名> /   $1<3.5でメモしたSASトークン文字列>

設定が完了したら「追加」をクリックします。

今回ついでにHTTP接続時に自動でHTTPS接続へリダイレクトされる設定も投入してみましょう。

ルール名: Redirect HTTP to HTTPS
IF: リクエストスキーム
機能: URL Redirect
Code: 301
Source : /×××/<エンドポイント名>         / (.*)
Destination : /×××/<エンドポイント名> /　

https:// %{host}/$1

設定が完了したら同様に「追加」をクリックします。
ルールが反映されるまでに最大4時間かかるので気長に待ちます。

ステータスが「有効」になったら無事反映完了です。

3.7 カスタムドメイン宛のhttps接続テスト

HTTPS証明書のデプロイと、ルール反映が完了したらHTTPSで接続可能なことを確認してみましょう。

SSL証明書エラーの警告なくアクセスできるようになりました。
コンテンツが正常に表示出来ていれば、BLOBストレージにもSASトークンでアクセス出来ていることが確認できます。
ホストされている証明書を確認すると、サブジェクト代替名にカスタムドメインが設定されていることを確認できます。

試しにHTTP接続でアクセスをしてみると、しっかりHTTPSへリダイレクトされました。
Google Chromeの開発機能を使ってリクエストの様子を見てみると、Rules Engineで設定した通りレスポンスコード301が返っていることが確認できます。

いかがでしたでしょうか。
前半だけでもボリュームたっぷりな内容になりましたが、これだけ高機能なWebホスティング環境が簡単に手に入ってしまいました。
さらに、OSのアップデートや、ミドルウェアの脆弱性対応に無駄な手間を取られる必要もありません。
その上、今回Azure CDNを利用していますので、静的コンテンツがメインであれば世界中さまざまなロケーションからのアクセスが高速化することも期待できると、いいこと尽くしですね。

後半ではいよいよこのお問い合わせフォームのPOST先をデプロイしていきます。

あわせて読みたい記事

オンプレミスからMicrosoft Azureへの移行事例についてご紹介

パブリッククラウド活用によるメリットを最大限に！オンプレミスからMicrosoft Azureへの移行事例についてご紹介

Microsoft Azure上でCisco CSR 1000Vを動かしてみた！