WebアプリケーションをMicrosoft Azure上のPaaSにホスティングしている。気が向いたのでどんな構成で付き合っているのか書く。
見出しは以下辺り。
- アプリケーションの構成
- 環境
- 監視など
一言で表すと『ASP.NET Core のアプリケーションを Visual Studio で何となく開発 App Service で何となく運用』している感じだ。
この『何となく』は大事で、難しいことを考えずにゆるくWebアプリケーションの開発運用と付き合えている。楽しい。
アプリケーションの構成
以下の様なフレームワーク、ライブライリのWebアプリケーションだ。
- ASP.NET Core
- ASP.NET Identity
- Entity Framework Core
- Bootstrap3
ビジネスロジックはほぼ全てコントローラに実装している。いうなればスーパーファットコントローラといったところだろうか。
外部サービスへ依存する処理のみServiceクラスに実装して、DIしている。ローカル環境ではスタブを使うなどできるかと考えていたが、結局ローカルでも本物にアクセスして動作確認しているのであまり意味はなかった。
// あるコントローラのコンストラクタ // 添付された画像ファイルをBlob Storageに保存して外部サービスで検証、の様な処理を行う public UploadController( ApplicationDbContext context, IBlobService uploader, IPhotoCognitiveService photoCognitiveService)
データベースマイグレーションはコードファーストで行っている。基本的にエンティティクラスとプロパティへの属性付けで済ませているが、たまにFluent APIでインデックスを貼ったりしている。
// ユニークインデックスや複合インデックスは属性では宣言できなかった気がする // そういう場合はFluent APIを使って構成している public static void OnModelCreating(ModelBuilder builder) { builder.Entity<Board>() .HasIndex(c => new { c.Slug }) .IsUnique(true); }
マイグレーションの適用はアプリケーション立ち上げ時にしている。
それで困ることのない程度の規模。
環境
- ローカル
- 動作確認
- 本番
の3環境がある。
ローカル
開発はVisual Studioだけで行っている。どんなコンポーネントをインストールしているかは覚えていない。
F5を押すとブラウザが立ち上がってアプリケーションの画面が表示されるようにしている。RDBにはSQL Server LocalDBを使用していて、アプリケーションから接続すると勝手にインスタンスが作成される。
Visual Studioのプロジェクト作成ウィザードに従うとこの形が大体構成される。楽。
デバッグ実行状態ならラインブレイクもし放題だ。非同期呼び出しが混ざっていなければブレーク中にコードの変更だってできる。
Azure固有のリソースはローカル用にリソースを作成していたり、エミュレータを使用していたりしている。
動作確認・本番
Azure上の環境は動作確認用と本番用の二つの環境をリソースグループで分けて運用している。
主なリソースは以下のようなものがある。
- App Service
- アプリケーションの実行環境
- 動作確認はリソース共有の安いプラン、本番はリソース占有のプラン
- SQL Database
IaCはしておらずAzure Portalや、たまにVisual Studioからリソースを操作している。 アプリケーションのデプロイにはApp Serviceのデプロイ機能を使っていて、特に難しいCDは構成していない。Gitリポジトリの指定したブランチを変更すると、デプロイされる。便利。
CI？ ユニットテスト？ ない。ローカル環境で人力で動作確認している。
リソース共有の動作確認環境ではたまにデプロイに失敗しているが、本番ではそう言うことは起きないので特に気にしていない。再起動なりすれば回復する。
環境を増やそうか、となった時にはARMのテンプレートを整備しておくくらいはすると楽そうなのだけれど、まぁまぁリソースの種類があって変数化など面倒くさいので二の足を踏んでいる。いざ必要になってから考えようと思っている。
監視など
異常発生時の通知も含めてAzure Monitorで済ませている。
ダッシュボードも作りやすく必要十分といった感覚だ。
Cognitive Services の画像認識は500msec弱くらいかかっているらしい。へー。
Mackerel
しばしば記事を書いたり、イベントに参加したり、提供している会社に入社したりするほどにはMackerelが好きだけれど、ここではURL外形監視のみをしていた。
Azureインテグレーションは対応リソースが少なく、手軽に構成する監視の核には据えづらい。 （メトリクス収集用ホストの運用だとか面倒くさいことはしたくない！）
とは言え自社サービスなので、対応分（SQL Database）はどんなものか体験する目的でインテグレーションし始めた。
MackerelのAWS/Azureインテグレーションはとにかく手軽にメトリクスを収集してMackerelに集約できる点が利点だと思っている。今回は集約という点では弱いけれど、ちょいちょい見てわくわくしていきたい。
オチが付いただろうか。
