Azure Websites運用時に気をつけてること

こんにちは。日山(@hiiyan0402)です。
私がAzure Websites運用時に気をつけてることを共有します。(Azure Websitesって最近名前変わったんですね・・・)


ログ設定

サイトログとアプリケーションログを両方共出力するように設定してます。

サイトログはBLOBストレージに、アプリケーションログはTableストレージに格納するように設定します。
ファイルシステムに出力しないのは、Webサイトを削除した時にログも一緒に消えてしまわないようにするためです(念のため)。また、ログはできれば出力時刻でフィルタリングができるTableストレージに出力するようにします。

ログを出力するとコストがかかるとの懸念がありますが、たとえ1GB出力されても月額10円程度と考えると安いものだと思います。ログ出力が明らかに不要なモックやプロトタイプレベルでなければ、出力するようにしています。

スケール設定

スケール設定するならWebアプリがスケール対応していることを確認します。

例えば、セッション情報を用いている場合で、そのセッション情報を外部ストレージ(RedisCacheやSQLServerなど)に格納しておらず、インメモリに格納しているのであれば、スケールアウトして複数インスタンスにすることによりデータ不整合が発生する可能性があります。

あとSインスタンス1台で明らかに対応できるWebサイトに対して、「なんとなく」で自動スケール設定のはやめます。上記のようにスケールアウト非対応のサイトなのに勝手にスケールアウトされて問題が起きることを避けるためです。複数人で運用していると、誰かが勝手に設定したりする場合があるので気をつけます。

バックアップ設定

以下のいずれかに当てはまる場合なら、バックアップ機能を有効にしています。取得間隔は最短間隔の1日です。

  1. 対象となるWebサイトがCMS等で、動的にローカルフォルダにコンテンツ(HTML等)を配置するサイトである
  2. Webサイトのコードをコード管理ソフト等で自動でバックアップする仕組みがない (※1)
  3. Webサイトを再デプロイことができない状況 (※2)

(※1) 「人間の手で定期的に」だと必ず実施されなくなるので、「ツールによる自動化」が行われていることが重要
(※2) コードを管理する人が存在せず安全にデプロイできる確証がないソースコードが消失済み、など

バックアップ機能はサイトモードが「標準」でないと使えません。有効化にするべきサイトであれば、サイトモードを「標準」にあげます。それぐらいに必須だと考えてます。
上記に該当しない場合も、していると何かと便利なので有効化にしておくといいと思います。例えば、ソースコード管理が徹底されていてWebサイトが万が一に消えてもソースからすぐに再デプロイできますよ、という状況でも、バックアップからのリストアのほうが早いし確実です。必要なときに実はコード管理に不備があって、再デプロイに時間がかかります、ってことを避けます。

デプロイ時のプロセス

サイトモードが「標準」であれば、展開スロット機能によりステージング環境を構築可能になるため、クラウドサービスのように安全なデプロイができます。ステージング環境用の展開スロットを作成して、以下のプロセスでデプロイしています。

  1. 新バージョンのWebアプリケーションをステージング環境スロットにデプロイする
  2. ステージング環境スロットで総合テストを行う
  3. テストで問題がなければ、本番環境とスワップを行う
  4. ステージング環境スロットを停止させる

ぶっつけ本番リリースは絶対に避けます。

Azureアラート設定

「500エラー」「削除イベント」「停止イベント」で通知するように設定しておきます。

メトリック「HTTPサーバエラー」で条件を「最後の5分間の合計 : 1回 : より大きい」と設定しておくことで、サーバでの例外発生時に通知されるようにします。
またオペレーションミス検出のために、Webサイト削除時と停止時のイベントで通知されるように設定します。もちろん毎イベントで通知するようにします。イベントでのアラートは新ポータルでのみ設定可能です。

サイトモード検討

できれば標準モードにしています。

余程コストに制約がない限りは標準モードにします。展開スロット機能が使えるためです。展開スロット機能によりステージング環境を用いた安全なデプロイが可能になるので、まともなシステム運用をするのであれば、この機能は必須だと考えています。またバックアップ機能や、WebJobsなどを活用することで運用の安全化、効率化することができるようになります。

あと同じホステッドプランなら何個サイトを作っても同じ値段になるので、あまりリソースを使わないサイトであればまとめてしまいます。コストを抑えます。

無料モードはモック&プロトタイプ用、共有モードは低コストサイト用、基本モードは使わないで、あとは標準モードを使用しています。基本と標準の違いが月額2,000円程度なので、運用費等々を考えると標準を使ったほうがコストが低いと考えています。

操作権限管理

本番用サイトであれば開発者は一切操作できないようにしています。

本番用と開発用でサブスクリプションを分けて、本番用サブスクリプションには開発者は一切アクセスできないようにしています。これにより、開発者による本番サイトへの開発中サイトの誤デプロイを防ぎます。人間誰しも間違いは起こしますし、開発に集中しすぎてよくわからない状態になって間違ってデプロイ、ってのは有るのではないかと思います(ヒヤリとしたことは個人的に何度もあります)。

また、開発者が本番用データベースの接続文字列を知る手段を遮断するためでもあります。管理ポータルにアクセスできる以上、何かしら方法でデータベースの接続情報を知ることができます(余程の対策をしない限り)。もし開発者が本番用DBへの接続情報を開発用のと混同して使用して、テストデータを混入させたり、データを消してしまったり、というった重大な事故を引き起こしてしまう可能性が発生します。そういった可能性を消すためにも、開発者が本番用接続情報を知る手段を遮断します。

最近ならRBAC(Role Based Access Control)を使って権限制御を行っても良いと思います。これならサブスクリプションを分ける必要なく、本番用リソースへのアクセスを制御することができます。

いち開発者として私は開発中に本番環境に触れられる状況が怖いので、すぐにアクセスできない状況にするように対応します。おっちょこちょいなのでアクセスできるとすぐに事故を起こす自信があるので・・・^^;

今回も最後までご覧いただきありがとうございました!


TechTarget

クラウドエンジニア  日山 雅之による記事「Microsoft Azure スマート解説」がTechTarget Japanにて好評連載中です (全7回)