PaaS移行で沼った細々したことを供養する

PaaS移行で沼った細々したことを 供養する 第0回 JAZUG for Women Kick off 2023/07/17 長瀬 マキ（@yuma_prog)

自己紹介 ● ● ● ● 長瀬マキ（Twitter:@yuma_prog） 文系出身エンジニア 2020年にWeb系ベンチャーに新卒入社 APIサービスの開発・運用＋SREを担当 ● ● ● 2022年3月頃 クラウド移行プロジェクト本格開始 2022年6月頃 IaaS移行→PaaS移行に大転換 2023年6月末 メインサービスの移行完了

アジェンダ 1. 2. 3. 4. Blob Container Blob Storage の静的Webサイト Front DoorとStatic Web Apps 移行してみて1ヶ月の所感

移行の概要 ● アプリケーション改修 ○ ○ ○ ○ ● ● BlobStorageも参照できるように EventHub経由でログ記録 ファイルストレージ移行 SendGridでのメール送信 Github Actionsでデプロイ Terraformでリソース管理

1.Blob Storageで地味に詰まった仕様

ファイルストレージ移行のためのライブラリ作成 ● ● ● .NET 用 Azure Blob Storage クライアント ライブラリを使用 ファイルストレージをBlobStorageに移行するためのライブラリを作成 System.IOのクラス名のままBlobStorageとのやりとりができる ○ ○ オンプレのファイルストレージのパスと BlobStorageでのContainer名をマッピング 「using System.IO」 を作成したライブラリ名に書き換えるだけで組み込み完了

if(Directory.Exists(path)) Directory.Delete(path, true); Directory.CreateDirectory(path);

Directory=Containerになるよう実装 if(Directory.Exists(path)) Directory.Delete(path, true); Directory.CreateDirectory(path); CreateDirectoryで409(Conflict)

Blob Containerの仕様

Container削除後 少なくとも 30 秒間は 同じ名前のContainerを作成 することはできない .NET を使用して BLOB コンテナーを削除して復元する - Azure Storage | Microsoft Learn

• https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-blob-container-delete#delete-a-container

Container削除後30秒問題 ● ● ● オンプレではフォルダごと削除して同名フォルダを作る処理がよく存在した その処理のまま、ファイルストレージをBlob Storageにしようとするとこの問題に直 面 Containerごと削除ではなくBlobを上書きするように改修して回避

2.BlobStorageの静的Webサイト

BlobStorageの静的Webサイト ● ● ● ＄webというContainerの下にある静的コンテンツ (HTML、CSS、JavaScript、画像 ファイル) を直接提供できる機能 AzureStorageがホストしてくれる Storage Accountで有効にすることで利用できる

静的Webサイトで配信しているhtmlにア クセスするとhtmlがダウンロードされる だけで表示されない ＄webにアプリケーションから静的コンテンツをアップロードしていた

静的Webサイトの仕様

htmlのCONTENT-TYPE プロパティが空だと ブラウザはファイルの ダウンロードを要求する

CONTENT-TYPE 空問題 ● ● ● ● ブラウザでファイルの内容を表示する場合は、そのファイルのコンテンツの種類を text/html に設定する必要がある ポータルなどからアップロードすれば基本は自動的に text/html が設定される プロパティを text/html に設定しなかった場合、ブラウザーはファイルのダウンロー ドを要求 対応 ○ Blobのアップロード時に拡張子から CONTENT-TYPEを判別してセットする処理を追加 Azure Storage で静的 Web サイトをホストする | Microsoft Learn

• https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-blob-static-website-how-to?tabs=azure-portal#upload-files

3. FrontDoor＋Static Web Apps

Front DoorとStatic Web Apps Front Door ● コンテンツを配信するためのサービス ○ ○ L7 (HTTP/HTTPS) のルーティング コンテンツのキャッシュ など Static Web Apps ● HTML、CSS、JavaScript、画像などの静的コンテンツの Web ホスティングをしてく れるサービス Azure Front Door | Microsoft Learn Azure Static Web Apps とは | Microsoft Learn

• https://learn.microsoft.com/ja-jp/azure/frontdoor/front-door-overview
• https://learn.microsoft.com/ja-jp/azure/static-web-apps/overview

今まで test.jp/Static/App1/~ test test.jp/Static/App2/~ ローカルでビルドした結 果を手動でコピーしプロ ジェクトに含める bin Web.config static App1/index.html App2/index.html Web Apps Static Web Apps

2つのアプリケーションをStatic Web Appsにデプロイ ● ビルド対象のコードは同じでパスを分けたい ○ 出力されるhtmlのtitleとbase が異なるため。 script で指定するjsなどのファイルは同一。 ➡一つのStaticWebApp内で2つのindex.htmlを持ち、FrontDoorでそれぞれに ルーティングさせる ● angular.json, package.jsonに手を入れて、2回ビルドしてサブディレクトリに出力＋ 空のdist/index.htmlを作成して配置

2つのアプリケーションをStatic Web Appsにデプロイ 一致するパターン : /Static, /Static/* 配信元のパス :空文字 test.jp/Static/App1/~ Front Door Static Web Apps test.jp/Static/App2/~ SWAの制約のため 空のindex.htmlを配置 dist App1/~ index.html App1/index.html App2/~ App2/index.html

2つのアプリケーションをStatic Web Appsにデプロイ 一致するパターン : /Static, /Static/* 配信元のパス :空文字 test.jp/Static/App1/~ Front Door ⇨/app1/~のようなリクエストが 404になったため Rule Setで小文字に変換 Static Web Apps test.jp/Static/App2/~ dist app1/~ index.html App1/index.html app2/~ App2/index.html

404になったり正常に表示できたりする

大文字小文字問題 ✖FrontDoorの不具合 ＝沼

大文字小文字 ● ● Case Sensitive(CS) : 大文字小文字を区別する Case Insensitive (CI) : 大文字小文字を区別しない ○ WindowsはCI

大文字小文字問題 CI CS test.jp/Static/App1/~ 一致するパターン : /Static, /Static/* 配信元のパス :空文字 ルールセット：小文字に変換 Front Door CS Static Web Apps test.jp/Static/App2/~ ルールセットの不具合 「App1/~」「app1/~」それ でたまに「App」のまま ぞれで配信されていた 配信 dist app1/~ index.html App1/index.html app2/~ App2/index.html サブフォルダが大文字 だから404 リソース内で Appとappが混在

最終系 CI CS test.jp/Static/app1/~ 一致するパターン : /Static, /Static/* 配信元のパス :空文字 ルールセット： 何もしない Front Door CS test.jp/Static/app2/~ dist app1/~ 全て小文字で統一 Static Web Apps index.html app1/index.html app2/~ app2/index.html

移行してみて1ヶ月弱の所感

品質向上のきっかけに！ リリーススピードも 早くなった！

移行してみて1ヶ月弱の人のお気持ち ● Application Insightsのおかげで今まで気づけなかった不具合を発見しやすくなっ た ○ ● レスポンスが遅すぎると不具合になる ○ ○ ○ ● オンプレでも導入していたが、より詳細にエラーが取れるようになった FrontDoorのタイムアウト時間はデフォルト 30秒、最大240 秒 「遅いから改善したいなー」 →「改修しないと動かない」に格上げ Application Insightsによるパフォーマンスの可視化も便利！ Github Actionsでリリース作業を自動化してリリースが楽に ○ ○ ○ ○ プルリクの作成やマージで適した環境にデプロイ 本番リリース時にリリースタグを自動作成 修正したパスからデプロイ先を判断してくれる Web.config変換導入でWeb.config手動リリースが不要に

Azure移行沼の供養完了！