はじめに

西日本テクノロジー&イノベーション室所属、入社二年目の寺澤です。

現在所属するプロジェクトにおいて、Microsoft Azure(以下、Azure)が提供しているApp Serviceを利用してWebサイトを構築しました。構築にあたって、プランや設定方法など決めなければいけないことがたくさんありました。何を利用しどのように設定するのがプロジェクトにとって最適なのかを考え選択しましたので、具体的にどのような基準で何を選んだのか、失敗体験も含めてお話します。

背景

我々の部門では他部門の開発プロジェクトに参画し、関係者と日々連携して業務を進めることがあり、これを協業開発と呼んでいます。 詳しくは次の記事を参照ください。

今回私は、Azure上で運用しているサービスを提供しているプロジェクトと協業開発させていただき、サービスの情報を掲載するポータルサイトを構築することを担当しました。Azureを利用してサービスを提供していることから、ポータルサイトの構築も同じくAzureを利用することになりました。

作成するWebサイトについて、以下のような要件がありました。

  • サービスの利用者に向けて情報を発信する
  • サービスの利用者のみが閲覧できる
  • HTMLのみの静的サイト
  • 常時接続できなくてもよい

これらを実現するために、Webサイトの構成を決めました。

Webサイトの構成と運用

まず今回作成したWebサイトの全体構成図を以下に示します。

使用したAzureサービスの用途は以下のようになっています。

Azureサービス 今回のプロジェクトでの用途
App Service Webサイトの構築、デプロイ
Azure DevOps ソースコードのバージョン管理
DNSゾーン カスタムドメインのマップ
Application Insights Webサイトの可用性を監視
モニター アラートの発報
ストレージアカウント バックアップの作成

次にデプロイ構成について説明します。

以下のドキュメントを参考にして、以下の図の構成にしました。構成図もドキュメントに掲載されている図を参考にしています。

またデプロイスロットについては、下記の構築で説明しているので参考にしてください。

最後に運用について説明します。

作業者と再鑑者の2名でWebサイトの更新を行うことにしました。フローは以下のようになります。カッコ内の番号は上図の番号と対応しています。

作業者
(1) developブランチから作業用にブランチを切り、ソースコードの編集を行います。
(2) 編集が完了したらdevelopブランチにマージします。
(3) develop-testスロットにデプロイされるのでテストを行います。

再鑑者
(4) 編集内容を確認後、developブランチをmainブランチにマージします。
(5) main-testスロットにデプロイされるので動作確認を行います。
(6) 運用スロットとmain-testスロットをスワップします。

またこの実現のため、アカウントを2つ用意しました。作業者は作業者アカウント、再鑑者は管理者アカウントでログインして作業を行うことにしました。

  • 管理者アカウント
    • 下記の構築手順は管理者アカウントでサインインして行います
  • 作業者アカウント
    • ソースコードの編集作業を行います
    • 誤って本番環境を更新しないようにアクセス制限を設定しています。詳しくは後述します

これから構築手順について説明していきます。

構築

構築にあたって行った操作、設定内容やその経緯をお話していきます。具体的な手順については公式ドキュメントのリンクを用意していますのでそちらをご確認ください。

行った作業の一覧を以下に示します。

ソースコードの管理方法の調査

開発者が自分一人であったことから、開発を進めながらプロジェクトに適したソースコードの管理方法を調べました。

調査の結果、ソースコードの管理にはAzure DevOpsのAzure Reposを利用することにしました。

Azure DevOpsの準備

Azure DevOpsとは

Azure DevOpsとは、「Development（開発）」と「Operations（運用）」に必要なAzureサービス群であり、以下の5つの機能で構成されています。 今回はソースコードの管理が目的であったため、Azure Reposのみを使用しました。

Azureサービス 概要
Azure Repos ソースコードのバージョン管理
Azure Pipelines 継続的インテグレーションと継続的デリバリーをサポート
Azure Boards かんばん機能
Azure Test Plans 手動テスト、探索的テスト、継続的テストなど、アプリをテストするためのツール
Azure Artifacts 自身で作成したパッケージを共有

Azure DevOpsを選んだ理由

利用するクラウドサービスがAzureのみになります。 App Serviceの各スロットやAzure Reposの各ブランチについて、作業者アカウントにAzureロールベースのアクセス制御を設定することで一元管理できます。具体的な設定は後述します。

Azure DevOpsのプロジェクトを作成

Azure DevOpsの組織・プロジェクトを作成し、ローカルGitリポジトリをインポートしました。

ブランチ

運用のイメージ図の構成を実現するために、「main」と「develop」の2つのブランチを用意しました。

App ServiceのリソースをFreeプランで作成

機能テスト・動作確認を行うために最初はFreeプランで作成しました。

App Serviceのアクセス制限の設定

初期設定では全てのIPアドレスからの通信を許可する設定になっています。

開発段階なのでアクセス制限を設定しました。開発は執務室内の端末で行ったため、社内ネットワークからのアクセスを許可するように、IPアドレスベースの規則を設定しました。

1つでも規則を追加するとそれ以外のIPアドレスからの通信は全て「拒否」の設定になります。

アクセス制限の設定方法

上記のIPアドレスベースの規則を追加する方法の他に、仮想ネットワークを利用する方法もありました。
公式ドキュメントには以下の記載があります。

Azure 仮想ネットワークを使用する理由
Azure 仮想ネットワークにより、Azure リソースは、他の Azure リソース、インターネット、オンプレミス ネットワークと安全に通信できます。 仮想ネットワークを使用して実現できる主なシナリオには、Azure リソースとインターネットの通信、Azure リソース間の通信、オンプレミス リソースとの通信、ネットワーク トラフィックのフィルタリング、ネットワーク トラフィックのルーティング、Azure サービスとの統合などがあります。

今回はインターネットとの通信しか行わないことから、仮想ネットワークは利用しませんでした。

Azure DevOpsからApp Serviceへデプロイ

Azure DevOpsからApp Serviceへデプロイします。 デプロイが完了するとブラウザで作成したWebサイトが確認できるので、テストを行いました。

Webサイトが公開できる状態になりましたので、運用していくうえで必要な設定を行っていきます。

App Serviceのプラン変更

Basic以下のプランは開発利用が目的であるため、Standard以上のプランで一番料金の低いStandard S1プランを選択しました。

アクセス制限の設定更新

Webサイトのアクセス制限を特定の利用者のIPアドレスからのアクセスを許可するように設定しました。

また後述のURLテストで発生する通信を許可するためにサービスタグの「ApplicationInsightsAvailability」も追加しました。

SCMサイトのアクセス制限

SCMサイトについてもアクセス制限を設定しました。「＜app_name＞と同じ設定」のチェックボックスがあったので、「こちらにもアクセス制限を設定しておいた方が良いだろう」と考えてチェックを入れました。

これが大きな間違いでデプロイができなくなってしまいました。

SCMサイトについて

SCM サイトは Web デプロイ エンドポイントと Kudu コンソールの両方です。

つまりデプロイの際、Azure DevOpsからSCMサイトへの通信が生じています。SCMサイトにアクセス制限を設定した結果、この通信が拒否されており、デプロイが失敗していました。

対応

SCMサイトのアクセス制限を開発・運用者およびAzure DevOpsからの通信を許可するように設定することにしました。

しかしAzure DevOpsのサービスタグは現在存在しないため、リージョンのIPアドレスブロックを許可することでデプロイできるようになりました。

今回指定したリージョンはAsia Pacific(Hong Kong)なので20.189.107.0/24を許可しました。

デプロイスロットの作成

デプロイスロットとは

掲載情報の更新などWebサイトを更新した際、デプロイの前にテストを行う必要があります。ここで利用するのがデプロイスロットです。

各スロットは、その Web アプリの別々のインスタンスであり、別々のホスト名を持っている。 異なるバージョンの Web アプリを、各スロットにデプロイできる。

つまり分離された環境でテストを行うことができます。また、「スワップ」という機能を利用することで、デプロイ処理中に予期しない動作をする可能性をなくすことができます。

スロットをスワップすると、スロットのホスト名が交換されて、アプリの新しいバージョンに運用トラフィックがすぐに送信されます。 スロットのスワップを使用してデプロイすると、アプリが部分的にデプロイされた状態でパブリックな Web に公開されることがなくなります。

デプロイスロットはStandard以上のプランで作成でき、Standardプランでは5個まで無料で作成できます。

作成

スロットを2つ作成し、運用スロットとあわせて3つのスロットを用意しました。

スロット名 継続的デプロイ 概要
運用スロット なし
（main-testスロットをスワップ）		 ユーザーが接続したときに表示される
main-testスロット mainブランチ 動作確認を完了したのち運用スロットへスワップする
develop-testスロット developブランチ Azure環境でテストを行う

カスタムドメインの設定

既にワイルドカード証明書を取得しているドメインのサブドメインを構築したWebサイトに割り当てました。

監視設定

URLテスト・メモリ監視・ファイルシステム監視を設定しました。 URLテストについては［Application Insights］で可用性テストを作成しました。
［モニター］でアラートルールを作成しました。

バックアップの設定

［ストレージアカウント］のリソースを作成し、コンテナーを作成しました。1日1回、6:00にバックアップが作成されるように設定しました。

自動スケールとインスタンス数の設定

自動スケールは有効にせず、インスタンス数は1つで運用することにしました。

App ServiceのSLAが適用されるのは2つ以上のインスタンスを用意した場合ですが、インスタンス数を2つに増やすと料金が倍増してしまいます。 今回作成したWebサイトは特定の人のみが閲覧するものであり負荷があまりかからないこと、常時接続出来なくても大丈夫なことから、費用対効果を考慮した結果、インスタンス1つで運用することにしました。Webサイトが閲覧できないようになってしまった場合はアラートが発生するので、そこから復旧作業を行うことにしました。

作業者アカウントのアクセス制限設定

以下の表のように作業者アカウントのアクセス制限を設定しました。 こうすることで作業者が誤って本番環境を更新してしまうことが防げます。

App Service Azure Repos
運用スロット main-testスロット develop-testスロット mainブランチ developブランチ
× × 〇 × 〇

以上で環境構築が全て完了しました。

おわりに

Azure App Serviceを利用したWebサイトの構築について紹介を行ってきました。

Webサイトを構築・運用していくうえで必要なこと、特に運用面で必要なことを理解出来ていなかったため、全容がなかなか見えず苦労しました。そして必要なことがわかっても、それを実現する方法が多様に存在していたので、どれが最適なのかを判断するのが難しかったです。

そんな苦労がありながらも、Webサイトの要件や運用方針など様々な要素を判断材料に、プランや設定方法を選択しました。みなさんがWebサイトを作る際の参考になれば、と考えています。

本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。