初めてのAzure構築で、契約のトラップに巻き込まれた話

Azureの契約で経験した問題について

岩井大祐氏（以下、岩井）：それでは、技術ではなくて、Azureの契約というお話になってしまうんですが、私の実体験ということでお話ししたいと思います。

「初めてのAzure構築～契約のトラップに巻き込まれたお話～」ということで、パーソルテクノロジースタッフ株式会社の岩井と申します。

簡単な自己紹介です。

パーソルテクノロジースタッフでMicrosoft系プロダクトをメインにやっております。ただ、昨年から触り始めたので、オンプレメインというところでございます。

会社の紹介を簡単にしておくと、旧テンプ・スタッフテクノロジーと旧インテリジェンスが合併して昨年からできた会社になります。

派遣のイメージが強いんですが、IT関連の部隊では、日本で400人ぐらいしかいないVMware VCAPの有資格者も社員としていたりする集団でございます。

何かご縁がありましたらよろしくお願いいたしますということで、本題にいきたいと思います。

今回のお題目と注意点ということで、Azureを契約して使う上で、多くの人が意識していないであろうと思う部分で、はまってしまってけっこう泣いたというお話です。

もちろん重要なポイントは事実なんですが、もろもろぼかして書いている部分もあります。そのあたりはお察しいただければ幸いでございます。

問題発覚までの経緯

今回関わった内容というのは、オンプレミスのWindowsサーバやSQLデータベースをAzureのIaaSとPaaSで置き換えて、既存環境とExpressRouteを使って繋いで、環境をリプレイスするというものでした。

私がこの業務に参画した時点ではすでにAzureは契約されていた状態だったので、あとはエンドユーザーさんが使うAzureADアカウントにMFAからアクセス制限をかけてから構築するという条件がありました。

そして、直接ではないものの、トラブルの火種となったのが実は入札案件だったというところがありました。

構築の前段階で発注関係書類も確認して、AzureAD Premium P1（AADP）が買ってあるということは確認しました。

いざAzureの構築に入ろうとしたところだったんですが、この画面の再現なんですが、AzureポータルでAADPという表示がなされなくて、「結果はありません」という、けっこう無常な表示が出ておりました。

「あれ？　AADPついてないじゃん！」という状態で、けっこう現場が固まりまして、私もさすがにといったありさまでした。

当然なんですが、当初のお約束である以上、AADPの設定ができないということで、これ以上作業ができなくなってしまったと。

ご存知のとおり、MFAだけだったらなんとかするという方法もあるにはあったので、それでごまかそうかという話も出たんですが、納入前の検査時に、結局AADPを何で使わなかったの？　という話になったり、けっこう問題になってしまうので、小手先の対処はやめようと。

1時間悩んだ末にサポートにサブスクリプションとオーダー番号を伝えて、対応を依頼してみたんですが、なんと「そのご契約でついたAADPはこちらのサブスクリプションについております」ということで教えてもらったサブスクリプション名は、私は聞いたことがありませんでした、という回答されました。

当然つくった覚えもないので、「そんなものつくったことないですよ」という回答をしたところ、サポートからは「サポート単独の範疇を超えましたので、関係部署を巻き込んで対応します」ときて、ここで長期戦ですねという状況に陥った次第でございます。

原因はAzureADの基本ルール

エンドユーザーに正直に報告したところ、ちょうどこの時期に別の入札案件でAzureを使った構築案件が並行で動いていたそうなんですが、こちらでもやはり同じ問題が発生してしまって、やはり構築作業ができないという話がありました。

サポートから教えてもらったサブスクリプション名をお客さんにお伝えして、「何かご存知ないですか？」と聞いたところ、何年か前にOffice365版で作成したサブスクリプション名だということが判明いたしました。

発注処理上の問題もなかったし、我々がいくらひねってもどうしようもないということで、Microsoftの担当者さんを呼んで話を聞こうということで、呼んでお話をお願いしたんです。

「AzureADの基本的ルールによるものである」というのが第一の回答でした。

ご存知の方多いと思いますが、会社1つにつき1つのパブリックカスタマ（PCN）番号、ボリュームライセンスを買っている方だと、たまにボリュームライセンスのサイトで使ったりすることもあるんですが、こちらのPCN番号とディレクトリ（AzureAD）がそれぞれ割り当てられるというのが原則のルールだそうです。

AADPなどAzureAD関連のオプションは、その会社でもっとも古いサブスクリプションに割り当てられていたということで、今回は何年か前についたOffice365案件に割り当てられていたということで、発注した分が十数個、すべてそちらのOffice365のサブスクリプションに紐づけられていて、確認してもらったら確かに十何個あるということでした。

「どうなっているんだ」とお客さんは当然Microsoftの担当者を詰めたわけなんですが、そもそもMicrosoftの担当者も驚いていたんですが、サブスクリプションが分けられた理由がよくわからない、なんで分けられたんだろうと。

本来であれば同じPCN番号できているので、AzureADは最初につくったOffice365のAzureADに自動的に紐づいて、Azureも構築されるはずなんですが、Microsoftの方も訳が分からない状態に陥ったという状況でした。

発覚が遅れた理由

どういうことか？

先に、なぜこうなってしまったのかということは、1つ目の入札案件とあったので、エンドユーザー内部の契約状況を把握していなかったと。

通常、入札案件のばあいは把握しておく必要すらないので、当然ながらこういうトラブルがない限りこちらから聞くようなこともないというのが普通です。

そして2番目で、リセラーも含めてこのような仕様をそもそも知らなかったと。今回Microsoftの人に聞いて初めて「こんなことあるの？」ということを聞かされたという、なかなかしびれる状況でありました。

3つ目が、AzureADとAADPが対にならなかったので、さらに発覚が遅れたと。

AzureADごと古いサブスクリプションに紐づいていれば、入った時点で「あれ、Office365がついてる」というところでわかったり、つくった覚えがないAzureADアカウントがつくられていたとか、そういうので発覚したんですが、そもそもAzureADそのものが別につくられていたので、そこが発覚しなかったので対応が遅れてしまいました。

仮に割り当てられても全部やり直しになったので、それはそれで大事になっていましたが。

この時の事例は結局どうしたかというと、結局Azureそのものは全部再契約にして、案件ごとにPCN番号を分けてもらうかたちで再契約をお願いして、サブスクリプションの譲渡処理を使うかたちで、最初につくってしまったAzureADをそれぞれ完全に分離するという処理をやって、AADPが無事にそれぞれのサブスクリプションに割り当たったので、そこから作業続行ということになりました。

ですが、折悪くお盆シーズンを挟んでしまったため、すべての書類が整って対応できるまでに2ヶ月ほどかかりました。

Microsoftさん曰く、通常は最速で15営業日程度見込んでほしいということなので、会社さんの倫理によっては、おおむね1ヶ月前後はかかるのが一般的ではないのかなと思います。

この案件は、その後、ExpressRouteがらみでいろいろあったんですが、これは別のお話ということで、ここでは割愛したいと思います。

傾向と対策

傾向と対策……もとい、Azure契約に関わる際の注意点ということで、最後に軽くまとめていきたいと思います。

契約する前にエンドユーザー内で過去のAzureやOffice365の契約がないか確認すること。当たり前といえば当たり前なんですが、入札など少し特殊な契約になったりするとなかなかわかりませんが、あとで発覚してしまうと後処理が極めて大変な上に、スケジュールにも大きな影響が出ます。なので、説明して協力をお願いするというのが一番よろしいのかなということです。

逆に我々SI側に立つ身にしても、「こういう事象が実際にありましたので、確認させていただいております」というかたちで聞くのが、お客さまにも怒られず、あとでもめずということでいいのかなと思います。

あともう1つ、契約があった場合、そのAzureADはのちのちユーザー認証などを再利用する可能性があるのかどうかを検討してもらう必要があります。

これはMicrosoftの方にも念押しされたんですが、AzureADを分割してしまうと、あとから統合するのは不可能です。分けたら分けっぱなしになりますので、あとでAzureADの認証を使って何かをやりたいとなると、もうできませんよと言われました。

ですので、今後情報システムの統一でOffice365とAzureを組み合わせて何かやりたいとか、そうした計画が万が一にもあるのであれば、AzureADを分割するのはやめて、AzureAD回りを再設計するかたちでご一考いただくのが一番よろしいのではないかと思いました。

万が一巻き込まれてしまうと大変なことに

最後になるんですが、今回のお話はMicrosoftとの契約もからむので、みなさまのような技術者の方がそこにからむ例は非常に少ないのかもしれません。

とくにインフラレイヤーの人でなければあまりないのかもしれませんが、体験してわかったのは、Microsoftさんサイドとエンドユーザーさんサイドの基準は当然のことながら異なるので、巻き込まれてしまうと対処に非常に時間も手間もかかって、お客さんは当然構築できないからスケジュールどうするんだとなるし、Microsoftさんも書類がそろわないとどうしようもないですということになるので、お互いけっこう大変な目に遭います。

結局最終的には全部SIerさんも含めてまるっと解決するまで、12月だったので約4ヶ月ほどかかりました。ご記憶の片隅に入れておいていただければと思います。

このようなトラブルを事前に退治して、気持ちよく構築や運用に力を注いでいただけるとよろしいのではないでしょうか。最後はいつもお世話になっていますということで、Qiitaさんやブログ等で経験を書かれているみなさまのおかげで、今ここでこういうお話もできています。

少し駆け足というか早口になってしまったんですが、閉めたいと思います。

ご清聴どうもありがとうございます。

（会場拍手）