少人数で回せるクラウド運用の試み (1)

少人数で回せる クラウド運用の試み SAPPORO ENGINEER BASE #17 クラウド Kou

自己紹介 Kou アプリ開発者（Laravel など） 業務システムを少人数で開発・運用 インフラ専任ではなく、業務で必要に迫られて Azure を触っています

1個目のシステムは push すれば動く。 では14個目は？ 14 20 App Service Azure SQL の DB

少人数で足りないもの → 3つの方針 少人数で足りないもの → 全部を覚えている人がいない → 管理し続ける手が無い → 14個のアプリを、毎朝見て回る時間は無い → 今日は完成形ではなく「試み」の話です 方針  寄せる  なくす  見張る 定義を1か所に 管理するもの自体を減らす 集約と判断を自動に

 01 寄せる 定義の置き場が、ばらばらだった ポータル リポジトリ Bicep ポータルで手で作った もの システムごとのリポジト リの中の Terraform Bicep で書かれたもの 定義がどこにも残っていない state は手元のファイル Terraform とは別の書き方で定義 それぞれはその時点で正しく作られた。ただ、全体で何があるかは把握できていなかった

 01 寄せる インフラ専用のリポジトリへ寄せる ディレクトリの形 systems/ <system>/ envs/dev システムのリポジトリにあった Terraform は、移して元から消す ポータルで作った既存のものは terraform import で取り込む。作り直さ ない 新しい環境は最初からここで作る（本番環境、プレビュー環境） プレビュー環境の作り方は共通の型として文書に envs/stg envs/prod 一気に全部はやらない。触るときに、触った部分だけ寄せる

 01 寄せる なぜポータルではなく Terraform に寄せたか 01 02 03 同じ環境を作り直せる 読めば設定値が分かる 開発・検証・本番や、プレビュー環境を 同じ定義から作れる 何を設定したかがコードに残り、暗黙の 設定や見落としが減る。新しく入った人 も読めば分かる 命名や作り方をそろえら れる 共通の型（モジュール）を使えば、リソ ースの名前の付け方や設定がシステムを またいでそろう

 02 なくす 上手に管理するより、 管理するもの自体を減らす 01 02 03 DB のパスワード デプロイ用の鍵 使っていないリソース 定期的な更新と、漏えい時の対応が要る 中身は実質パスワード 誰も見ないまま、請求だけが続く

 02 なくす DB のパスワードをなくす いま これまで SQL 認証 App Service のアプリ設定に、ID とパスワード → マネージド ID で Entra 認証 DB 側にその ID の利用者を作る DB_AUTHENTICATION=ActiveDirectoryMsi 2 / 7 システムが本番まで完了（2件目は昨日の本番リリースで切り替え）

 02 なくす デプロイ用の鍵をなくす いま これまで 発行プロファイル GitHub Actions のシークレットに保存。中身は 実質パスワード OIDC で短命の許可 → デプロイ用のマネージド ID ＋ フェデレーション資格情報 （Environment prod からだけ信頼） Web App への Website Contributor 後片付け：発行プロファイルのシークレットを削除、FTP の基本認証を無効化

 02 なくす 使っていない DB を消す 20 件を洗い出し → 4 接続数と、アプリ設定からの参照で仕分け 消す前に BACPAC で Blob Storage へ書き出し 件を削除 減らすのは、増やすための原資

 03 見張る 14個のアプリを、毎朝見て回る時間は無い Azure Monitor のメトリクス（リクエスト・5xx・応答時 間・CPU・メモリ） レポート Log Analytics（送っているのは14個中7個だけ） Resource Health → 毎朝1枚のレポート いつもと違うか、急ぎかまで分かる アクティビティログ（誰が何を変えたか） 証明書の期限 すぐ気づくべきもの（5xx など）はアラートで鳴らす。毎朝見たいのは、アラートにならない変化

 03 見張る CLI で集めて、AI が判定する 1 2 3 Python ＋ az で集める 平常時の値と比べる AI が判定する az webapp list az monitor metrics list 毎日取り続けているメトリクスと 比べて、Markdown のレポートに する Claude Code が基準表と「既知の事 象」を読み、異常だけを報告。必 要なら KQL や az で掘る az monitor log-analytics query → Resource Health・アクティビティログ・証 明書も AI は読み取りだけ。再起動や設定の変更はしない →

 03 見張る 朝のうちに、急ぎかどうかまで分かる 事例 1 事例 2 事例 3 夜の 502 が31件 応答時間が 70ms → 1〜2秒？ 自分以外の変更 アラートは鳴って止んでいた。PHP へ の接続拒否と、同じ時刻の別アプリの 再起動まで AI が報告。プラットフォー ム側の再起動とみられる 正常な応答（200）だけで比べると約1.5 倍。軽い応答の混ざり具合で全体の値 が動いていた。急ぎではないと判断 別の人が新しいリソースを作り、アプ リの設定を変えたことに、翌朝気づ ける 何で比べるか（平均か、正常な応答だけか）を決めるのも監視の一部

まとめ 少人数で自走できる構成へ 全部を覚えている人がいない → 管理し続ける手が無い → 毎朝14個×5か所を見る時間が無い →  寄せる  なくす  見張る 覚えなくていい 管理しなくていい 毎回見なくていい これから触る人へ もう触っている人へ 1個目から、定義は1か所に書き、パスワードを置かない設定（マネー ジド ID、OIDC）を選ぶ 既存のものは terraform import で少しずつ寄せる。監視は「見る場所 の集約」と「平常時との比較」を自動に

試みは続く これから 各システムの構成を評価して、合ったプラン設定やコストの分析につなげる Log Analytics のログで、アプリ特有の問題も見つけて直せるようにする