Azure DevOps障害に翻弄された月曜日

 

■ はじめに

知り合い数人と進めている共同開発プロジェクト。3月に入った途端、メンバーの一人から「Gitのpushで認証エラーが出るようになった」と連絡が。

「あぁ、またPAT（アクセストークン）の期限切れか、月替わりの認証情報の更新かな」なんて、この時はまだ高を括っていた。

■ 迷走の始まり：自分だけ「成功」するという罠

まずは状況の切り分け。

「こっちでは普通にpullもpushもできるよ」

この一言が、原因特定を遅らせる最大のフラグになった。

自分ができる以上、プロジェクトの設定やAzure側の障害ではないはず。メンバーのローカル環境の問題だと断定し、以下の指示を飛ばした。

• 資格情報マネージャーの古い情報を消してみて

• git config --global credential.useHttpPath true を試して

• ブラウザのキャッシュをクリアして……

しかし、返ってくるのは「全部ダメだった」という絶望のレスポンス。

■ エラーメッセージとの格闘

送られてきた画面には、無慈悲なメッセージ。

TF10216: Azure DevOps services are currently unavailable.

Activity Id: 35b9da34...

Activity IDまで出ているのに、Azure DevOpsのStatus Portal（稼働状況）は「All Green」。アジアリージョンも正常。

「Activity IDまで出てるんだから、そっち（Azure）のせいだろう」と思いつつも、公式が「正常」と言い張る以上、こちら側の設定（認証ポリシーの変更など）を疑わざるを得ない。

■ 衝撃の結末

数時間が経過し、再度Status Portalをリロードしてみると……。

さっきまで鮮やかな緑色だった「Asia」のアイコンが、真っ赤な「Unhealthy」に変わっていた。

結局、Microsoft側の認証基盤の障害。

私がpushできていたのは、たまたま認証セッションが有効なサーバーに繋がっていたか、キャッシュが生きていただけだった。時間が経てば、いずれ私の環境でもエラーが出ていたはず。

■ 今回の教訓：ステータスサイトは「後出しジャンケン」

今回の件で学んだ教訓は3つ。

1. 「自分だけ動く」は環境が正常な証拠にはならない。（運がいいだけの場合がある）

2. 公式ステータスの「All Green」は、リアルタイムとは限らない。（反映にラグがある）

3. Activity IDが出たら、それはもう自分たちの範疇を超えている。

特に月替わりのタイミングは「自分のミス」を疑いがちだが、メンバー全員で一斉に起きた時は、公式ステータスが緑でも「コーヒーを飲んで1時間待つ」のが、精神衛生上もっとも正しいエンジニアの振る舞いかもしれない。

締めの一言

「Activity IDを必死にググっていたあの時間を返してほしい……（笑）」

Azure Database for PostgreSQLで突然の504。ログから遅延SQLを特定して改善するまで

 はじめに

自習環境でPDF出力機能を検証していたときのことです。

ある日、突然処理が終わらなくなりました。

しばらく待っていると、画面には 504 Gateway Timeout。

「メモリが足りないのか？」

最初はそう思いました。

メモリを疑う

Azure App Service のメトリクスを確認。

メモリ使用率はおよそ45％。

上限に張り付いているわけではありません。

念のため、コンテナ内でも確認しました。

cat /sys/fs/cgroup/memory/memory.limit_in_bytes

表示された値は、実質無制限に近い数字。

少なくとも、メモリ制限で落ちているわけではなさそうでした。

ではなぜ504が出るのか。

「タイムアウトかもしれない」

処理時間を見直す

ログを丁寧に追っていくと、リクエストが300秒以上かかっていることが分かりました。

これなら504になってもおかしくありません。

問題はメモリではなく、単純に「遅い」ということでした。

SQLを疑う

PDF出力処理では、データを取得してループしながら帳票を組み立てています。

もしかして、特定のSQLが遅いのでは？

そう思ってAzure Database for PostgreSQLを確認しました。

しかし、Query Storeは無効。

さらにサーバーパラメータを見ると、

log_min_duration_statement = -1

遅いSQLは一切ログに出力されていませんでした。

見えないものは、直せない。

まずは可視化から

log_min_duration_statement を 1000 に変更しました。

これで1秒以上かかったSQLがログに出ます。

その状態で、問題のPDF出力をもう一度実行。

Azureポータルのログを開き、息を詰めて確認しました。

出てきました。

duration: xxxx ms

同じSELECT文が何度も並んでいます。

そして、1回あたりも決して軽くない。

ようやく、ボトルネックが見えました。

インデックス不足

検索条件に使っているいくつかの列があります。

しかし、それらをまとめてカバーするインデックスはありませんでした。

複合インデックスを追加しました。

ロック影響を避けるため CONCURRENTLY を使用。

そして再度実行。

結果は

約10秒 → 約2秒。

はっきり分かる改善でした。

学び

今回の一件で感じたことがあります。

最初にメモリを疑ったのは、完全に思い込みでした。

504が出ると「リソース不足」と考えてしまう。

でも実際は、単純なインデックス不足。

そして何より大きかったのは、

推測ではなく、ログで確認したこと。

log_min_duration_statement が -1 のままだと、何も見えません。

見えないまま議論しても前に進みません。

まずは可視化。

そこからボトルネックを特定し、最小限の対処をする。

遠回りに見えて、それが一番早いと感じました。

おわりに

今回の問題はインデックスで改善しました。

ただし、ループ内でのクエリ実行は構造的な負荷を生みやすい部分でもあります。

N+1の可能性も含め、設計レベルでの見直しも今後の課題です。

それでも、504の正体を一つずつ剥がしていく過程は、とても良い学びになりました。

エラーの裏には、必ず理由がある。

焦らず、数字を見て、順番に潰す。

改めてその大切さを実感した出来事でした。

夜間はタダ！？Azure Container Apps vs App Service 料金比較と使い分けのポイント

 

1.Azure App serviceが最高だと思ってました

「誰も使っていない夜中のサーバー代、もったいないな…」と思ったことはありませんか？

開発した社内ツールや個人開発のアプリ。便利に使っているけれど、ふとコスト画面を見ると、誰もアクセスしていない深夜や休日も律儀に課金が続いている。Azure App Serviceを使っていると、これは「当たり前」の光景ですよね。

でも、AZ-900の勉強をしていたら見つけてしまったんです。「リクエストがない時は料金をタダにできる」という、魔法のようなサービスを。

今回は、App ServiceからAzure Container Appsに乗り換えるだけで、どれだけコストが浮くのか、その衝撃の事実をまとめました。

2. 詳細な料金計算の比較

※ 料金は目安（東日本リージョン、2024年現在の概算）としてご覧ください。

前提条件

• アプリのスペック: 1 vCPU / 2GB RAM 相当

• 稼働状況: 平日9:00〜18:00（月20日）だけリクエストがあり、それ以外はアクセスゼロ。

• 月間稼働時間: * 稼働中：9時間 × 20日 = 180時間

• アイドル中（夜間・休日）：550時間

A. Azure App Service (Basic B1プラン)

App Serviceは、アクセスがなくてもサーバーを維持するため、730時間フルで課金されます。

• 計算: 月額固定 約 $13.00〜$15.00

• 特徴: アクセスがなくても、常にこの金額が発生。

B. Azure Container Apps (消費プラン)

アクセスがない時間は「0」にスケールアウト（停止）させると仮定します。

• 稼働中の料金: * vCPU: $0.000024/秒 × 3,600秒 × 180時間 ≒ $15.55

• メモリ: $0.000003/秒 × 3,600秒 × 180時間 ≒ $1.94

• 停止中（夜間・休日）の料金: $0

• 合計: 約 $17.49 > あれ？高くなった？ と思われるかもしれませんが、ここがポイントです！実はContainer Appsには、毎月の 「無料枠」 があります。

C. Container Apps（無料枠適用後）

Container Appsには、毎月以下の無料枠がついてきます。

• 無料枠: 最初の180,000 vCPU秒、360,000 GiB秒

• 実質コスト: このシミュレーションの規模（月180時間稼働）だと、無料枠を差し引くと 月額 数ドル（約$2〜$5程度） まで抑えられるケースが多いです。

3. 比較まとめ表

• Azure App Service (PaaS)

• Cost Model: Fixed Monthly Fee (固定料金)

• Nighttime Cost: Always On (夜間も課金継続)

• Key Strength: Easy setup for Web Apps (Webアプリ特化で管理が楽)

• Best For: High-traffic sites (24時間安定稼働が必要なサイト)

• Azure Container Apps (Serverless)

• Cost Model: Pay-per-use (使った分だけ秒単位課金)

• Nighttime Cost: Zero / Free (夜間停止で0円が可能)

• Key Strength: Scale-to-Zero (リクエストがなければ自動停止)

• Best For: Internal tools & Dev environments (社内ツールや検証環境)

補足: 

App Serviceも手動やスクリプトで停止（Stop）できますが、プラン自体の料金（インスタンス予約代）は発生し続けるため、Container Appsのように「動いていない時は本当にタダ」というレベルにするには、プランの削除・再作成が必要で手間がかかります。

まとめ

個人でやる分にはコスパ最高のContainer Appsなのですが、お客様向けには、Webサイトを安全に運用するための機能が全部入りのApp serviceが良さそうです。そんなに甘くはなかったか、、、。でも、要件によっては使えそうなサービスと感じました。

Azure DevOpsで「Invalid clientid or client secret」エラーが出た時の解決策！Workload Identity Federationへの移行手順

Azure DevOpsからApp ServiceへDockerイメージをデプロイしようとしたら、突然のエラー。

Invalid clientid or client secret.

昨日まで動いていたのになぜ？

原因はサービス接続（Service Connection）の裏側にある「アプリの登録」の有効期限切れでした。

今回は、今後二度と期限切れに悩まされない「Workload Identity Federation」を使った最新の修正方法をまとめます。

1. 発生したエラー：Build and Push Web Imageで失敗

まずは、私が発生したエラーログを共有します。

• ##[error]error from registry: Invalid clientid or client secret.

• ##[error]The process '/usr/bin/docker' failed with exit code 1

一見するとApp Service側の問題に見えますが、実はAzure Container Registry (ACR) へのログイン失敗が原因でした。

2. 原因：サービス接続（サービスプリンシパル）の有効期限切れ

Azure DevOpsの「サービス接続」は、裏側でAzure Entra ID（旧Azure AD）の「アプリの登録」を利用しています。

インフラ管理画面（Entra ID > アプリの登録 > 証明書とシークレット）を確認したところ、シークレットの有効期限がバッチリ切れていました。

3. 解決策：Workload Identity Federation (automatic) で再作成

シークレットを更新しても直りますが、また数年後に同じエラーが起きます。

今回は、Microsoftが推奨している「パスワードレス」な方式、Workload Identity Federation を使って作り直しました。

設定の手順：

• Project Settings > Service connections > New service connection

• Azure Resource Manager > Workload Identity Federation (automatic) を選択

• 対象のサブスクリプションとリソースを選択して保存

4. YAMLファイルの修正と承認（Permit）

接続を新しく作った後は、azure-pipelines.yml の containerRegistry や azureSubscription の名前を新しいものに書き換えます。

初回実行時は、パイプライン画面で 「Permit（許可）」 ボタンを押すのを忘れないようにしましょう。

※パイプライン実行した後、しばらくしてサイト見てみたら表示できなくて、焦ってパイプライン状況をみたら途中で止まっててびっくりしました。許可が必要だなんて知らなかった、、、

Excelマクロの呪縛を解く。20年目のエンジニアがkintone集計ツールにkrewDataを選んだ理由

 

1. はじめに：エンジニアがkintoneに触れる

ずっとスクラッチのシステム開発（フルスクラッチでの設計・実装）を主戦場としてきた私ですが、最近はお客様から「開発コストを抑えたい」「導入後、自分たちで保守・運用できる仕組みにしたい（ノーコード）」という切実な声を多く聞くようになりました。

そこで数あるノーコードツールの中から、特にカスタマイズ性の高いkintoneに着目しました。

背景にあるのは、多くの現場で「負の遺産」となっている「Excelマクロのブラックボックス化」という普遍的な課題です。これをkintoneという近代的なプラットフォームで、いかに「持続可能な形」に再構築できるか。そこがエンジニアとしての私の挑戦の始まりでした。

2. 直面した課題：標準機能だけでは超えられない「集計の壁」

RDB（リレーショナルデータベース）でいう「テーブル」を、kintoneでは「アプリ」という単位で扱います。

「社員マスタ」「サービスマスタ」といったマスタデータを参照し、日々の活動を記録する「トランザクションアプリ」を作ること自体は、kintoneの標準機能で驚くほどスムーズに実現できました。

しかし、大きな壁となったのが「複雑な集計ロジック」です。

単なる数値の足し算ではなく、以下のようなビジネスルールが絡む場合、標準機能だけでは対応が難しくなります。

• 「利用開始月は無料にする」

• 「解約日が15日以前なら当月分は0円、16日以降なら満額請求」

これをノーコードで、かつ誰が触っても壊れない「堅牢なシステム」として実装するには、標準機能の枠を超える必要がありました。

3. 解決策の比較：DataCollect vs krewData

この「標準機能の限界」を突破するための外部サービスとして、市場で圧倒的なシェアを持つのが、トヨクモ社の『DataCollect（データコレクト）』と、メシウス社の『krewData（クルーデータ）』です。

■ DataCollect（関数型・リアルタイム集計）

アプリの画面上で、Excelのように数式（SUMやIFなど）を直接入力して計算させるツールです。

• メリット： Excelの延長線上で設定できる手軽さがある。

• 懸念点： 数式の中にロジックが隠蔽されがち。数が増えると「どのフィールドにどんな式があるか」の把握が難しく、スクラッチ開発でいう「スパゲッティコード」に近い状態になるリスクを感じました。

■ krewData（ETL型・バッチ処理集計）

複数のアプリからデータを吸い上げ、工場のライン（フローチャート）のように加工して、別のアプリへ一括で書き出すツールです。

• メリット： データの結合（JOIN）やフィルタリングの流れが視覚的に固定される。

• エンジニア視点： データフローが可視化されているため、不具合時の切り分けが容易で、構造が非常に直感的です。冒頭にフローイメージも作ってみました。

4. 決め手は「3年後のメンテナンス性」と「デバッグ」

システムは「動く」のは当たり前です。本当に大切なのは「3年後に自分以外の誰かがメンテナンスできるか」という点です。

お客様の中にはExcelに詳しい方もいらっしゃいます。しかし、なまじExcelが使えてしまうと、複雑な数式を無理やり組み込んでしまい、結局「作った本人しか直せない」状態に戻ってしまう危険性があります。

その点、krewDataは「数式を意識させすぎない」UIです。集計や条件分岐がノード（図）として表現されるため、エンジニアも非エンジニアも同じ土俵で「データの流れ」を理解できます。結果的に、これが「お客様自身で運用を回せる」という真のノーコードの価値に繋がると確信しました。

5. まとめ：エンジニアがノーコードを扱う「真の価値」

Excelで実現されている現行業務には、必ずといっていいほど「泥臭く複雑な条件」が潜んでいます。

その要件をただツールに詰め込むのではなく、いかにシンプルで安定した「データのパイプライン」に落とし込めるか。そこがエンジニアの腕の見せ所です。

道具が変わっても、設計思想の重要性は変わらない。そう感じたツール選定でした。