やべえ
「(120万・・・？)」
何かの間違いだと思った。
TwitterやQiitaでたまに見かけてはいたが、実際に我が身に降りかかると実感が湧かないものである。
正確にいうと、他人事のように思えてしまうんですよね。現実味がないというか。
で、事態を理解してくると滝のような汗が湧き出てきた。
まずは状況を把握しよう
深呼吸。
そして第一にするべき事、それは現状把握である
- なぜ起きたのか
- いつから課金が発生したのか
- どのサブスクリプションのどのアクティビティで起きたのか
をAzure Portalのサブスクリプションリソースから確認する。
そしてどう見ても課金自体は発生しているようなので、このタイミングで直属の上司に報告・相談。
(冷静かつ穏やかに指示を貰えたので、ほんっとうに感謝しています。一生ついていきます。)
まぁ最後に関してはそもそもサブスクリプションから料金確認してたら発覚したので、追加で確認するまでもなかったのですが、とにかく5W1Hをベースに慎重に確認していきました。
そこからは上司に画面共有しながら、ログを漁っていきました。
サブスクリプション＞疑わしいサブスクリプションを選択＞アクティビティ ログ からAzureで行った操作のログが全て残っているため、そこからディープダイブしていきます。
で、見つけた。
Azure AI Foundryが原因か・・・
Azure AI Foundryを使うと、GPT4などいろんなモデルが(プログラムするよりは)簡単にデプロイできる。
そして、今回は業務でAzure AI Foundryの機能調査が必要だったため、MS Learnという公式のハンズオンドキュメントに従ってモデルをデプロイしていた。
で、ここが啓蒙ポイントなのだが、Azure OpenAI ServiceではProvisioning Throughputというモデルがリクエストに応じて処理する能力を事前に設定・管理する機能が備わっていて、これが指定のリージョンとモデル次第ではデフォルトで選択されていることがある、という事がある。
そのため、高額なGPUサーバーが前借り契約されてしまった結果、1回のデプロイで120万の請求が発生したというわけである。
クラウドサービスのようなGUIベースの作業というのは後からシマッタ・・・、が多すぎて筆者は嫌いですね。
何言うてるかわからん、って人のために前提の話をすると、まずクラウドというのは通常は従量課金のシステムになっていて一気に高額な費用請求が発生するという事はあまりないのである。
一方で、このProvisioning Throughputでは先にまとめて費用を払うので、通常の利用料金より割引いたるわ、というようなシステムなんですね。
一次対処
まずやったのは、Azureのサイトから直接サポートへの連絡である。Azureに限った話ではないのだが、ないのだが、メジャークラウドというのはサポート窓口が実に見つけづらい。いや、正確に言えばサポート窓口は見つかるが、文字をしたためるための記入欄がちょっとやそっとの内容じゃ表示されないのである。
サポート窓口へ連絡するというのは、まぁよっぽどの事情がある時が殆どだと思うので、文字で書かなくても伝わるような内容はいちいちサポートに報告なんかしないんですよね。
正直この仕様はほんとにいかがなものかと思いました。いやほんとに勘弁してくれと、思った。
ついでにこのとき、社内の有識者なるヤツを上司から紹介されたので、事情を説明したら「リソースは削除してSRは上げたんか？？まずやるべきことやってから相談してよ」みたいな言われ方をして激しく気分が害されました。
なんかIT系の人で性格悪い人って専門用語捲し立てて私って色々知っててスゴいでしょ？みたいな物言いしてきますよね。気色悪いですね〜。
ちなみにSRとはサポートリクエストの略です。原文ママです。
営業に泣きついてみる
うちの会社はMS製品全般を商材として扱っているため、MS担当の営業というものがいる。そこでその営業にコンタクトを取り、日本Microsoftの営業の方を紹介頂いた。その方を経由して、検証中にとんでもない料金発生したから助けてくれ〜、てな感じでエスカレしてみた。
そのため、最低限の努力はしてみますと返事を頂けた。
3週間の時を経て
サポート窓口の担当者からAzureのサポート画面に回答がきた。
結論から言うと、「今回は特別に取り消してあげるね。今度から気をつけてね」とのこと。
いや〜、もうほんとにこの時ばかりは嬉しかったですね。
人間は0から＋1000に達するより、ー1000から0に戻った時の方が気持ちいいんですかね。
入試で合格したときより脳汁でました。
後始末
さてそんなこんなあって事の顛末の報告を関係各位や上層部へ向けて実施しました。
普段の仕事の際は、報告資料は(内容はさておき)それなりにデザインもおしゃれな方が良いと思うのですが、ゴメンナサイな報告資料はそうもいかず、ひっじょーに頭抱えながら書きました。
おしゃれではなく反省している事が伺えるが、分かりにくくてもいけないという絶妙な描きっぷりをなんとか実現し、いろんなところにシオシオな顔でお礼参りをしてなんとか火消しを終えた、てなわけです。
まとめ
失敗から学ぶことは多い、などと道徳の教科書に書いてあるような事を人に対して平気でのたまう輩もいますが、そんなもん言われんでも分かるわ！って思います。
それは側から見た他人がかける言葉なのではなく、転んだ本人が起き上がる際にただ怪我をして終わらないために自分にかける言葉なのだと思います。
そんなわけであえて言いましょう。失敗から学ぶことは多いです。
少なくとも私は二度とProvisioning Throughputという機能は忘れないでしょう。
コメント