第2回、普通ならAzureのテクノロジー面を掘り下げる回ですが、いきなり事例にいっちゃいます。
これは私がリアルタイムで経験していることですが、Azure（というよりはパブリッククラウド全般）では、後になって誰も知らない、どこにも書かれていないクリティカルな問題が日常茶飯事に起こります。
端的に言ってしまうと、

技術がまったく枯れていない、運用もまったく枯れていない

ということなんですね。
実際に、この後挙げるポイントがどうしても回避できないという案件も出てくると思いますので、重要度を上げる意味で先にご紹介させていただくことにしました。
イントロでお話ししました泥くさい情報提供の部分です。

計画済みメンテナンスの問題

Azureでは、サーバーやネットワークスイッチへのパッチ適用などの理由により、仮想マシンの再起動を伴うメンテナンスが発生することがあり、これが計画済みメンテナンス（Planned Maintenance）と呼ばれるものです。計画済みメンテナンスはマルチインスタンス構成（可用性セットで複数の仮想マシンを稼働させている構成）で48時間前・シングルインスタンス構成で1週間前に、電子メールによりメンテナンス開始時間の通知が行われます。
というところまで聞くと問題なさそうなのですが、実は結構厄介でして…。

電子メールの問題

過去1度だけですが、この電子メール通知が来たことがあるので、実際の文面を抜粋します。

このメールから読み取れる問題は3点です。

1. どの仮想マシンが対象になるのかが記載されていない
2. メンテナンス時間がやたら長い（これは場合によると思いますが）
3. 日中帯・夜間帯関係なし

これが商用環境なら72時間ものメンテナンス時間の間、全仮想マシンを監視する必要があるのか？というちょっとした絶望感にかられてしまいます。（この事例では対象が検証環境でしたので軽く無視しましたが）また当たり前といえば当たり前なのかもしれませんが、夜間メンテナンス時間なんていう考慮もゼロです。

仮想マシンごとの再起動開始と終了の通知

これは行われません、予告なく再起動が行われ終了します。
この計画済みメンテナンスに対する対処を検討していた際、データベースであればあらかじめ計画フェールオーバーをさせておくことで逃げられるのではないかと考えたのですが、この仕様であえなく潰されたという経緯がありました。計画フェールオーバーさせたところでフェールオーバー先の方が先に再起動してしまう可能性があるのでは意味なし、という結論でした。

対処方法はないのか

一応仮想マシンを配置するリージョンを分けることでメンテナンス時間が別日程になりますので（確実かどうかは事例からではわかりませんでしたが）、リージョンまたぎの冗長化構成＆計画フェールオーバーで逃げられる可能性があります。ただリージョンが違うと仮想ネットワークも分かれますし、その他もろもろ設計面の考慮が大変そうでしたので採用は見送っています。
それから、SQLServerのAlwaysOnであれば数秒で切り替わったりなど、実害のほとんどないものもあると思いますが、すべてがすべてそのレベルで対処可能なわけではありませんし…。

と1つの話題で長々と書かせていただきましたが、Azure活用の最大のポイント（問題点）がこれです。
私も詳しくはないのですが、AWSの場合、計画済みメンテナンスにおける再起動のタイミングを制御することが出来たと思いますので、この点は明らかにAWSの方が良いところだと思います。

みんなで共有利用することの弊害

第1回で書かせていただいた「みんなで共有利用」することの弊害の事例です、題材に挙げるのはAzure Backupの仮想マシン保護になります。
Azure Backupの仮想マシン保護は2015年4月にリリースされた機能で、その名の通りAzureの仮想マシン（IaaS）のバックアップを取ることが出来る機能です。詳細な機能のご紹介は今回省かせていただきますが、ご興味のある方は下記のリンク先などをご参照ください。

• [Azure 仮想マシンのバックアップ]
  https://azure.microsoft.com/ja-jp/documentation/articles/backup-azure-vms/#-7

さてここからが本題ですが、この機能でバックアップを取る際、内部的には、

1. スナップショットの取得
2. バックアップ コンテナーへのデータ転送

というステップが実行されます。
今回問題になったのが2番目のステップで、端的に言うとここがものすごく遅いのです。しかも調査・検証を行ったところ夜間帯での劣化が著しいということがわかりました。
理由ですが、この処理では単純にデータ転送を行っているだけでなく重複排除処理なども行っており、この処理の実行リソースが「みんなで共有利用」されている、かつその処理が集中してしまっていることにより劣化が発生するというのが結論でした。バックアップは当然のようにみなさん夜間帯に取るでしょうから処理も集中しますよね。
そして上記の問題に対するAzureの公式情報が以下の通りです。

この情報は案件にとっては後出しでしたので当時かなりしびれました。
オンプレミス環境であれば専用のバックアップ基盤を構築して対処を行うことも可能だと思いますが、パブリッククラウドでこの手の問題が出た場合、基本的に事業者側でのリソース増強などの対処を待つしかありません。また代替案を積み上げていって結局コスト高のようなことにもつながりかねません。
パブリッククラウドにおいて提供されている機能のどれを利用するか（利用できるか）の判断は、共有利用云々といった従来あまり考慮する必要のなかった要件が出てきますので、非常に難しいものだと思います。
もう一点、真にひどいのは後出しじゃんけんの部分なのですが、それは言っても詮無き事なので。
ただこちらは代替手段がありまして、Blobのスナップショット機能であれば（少なくとも見た目上では）性能問題なくバックアップを取る事ができます。PowerShellなどでの実装が必要ですが、情報はわりと出てきますのでご興味があれば検索してみてください。

ライセンスの難解さ

ライセンスは往々にして難解さが付きまとうものですが、ことパブリッククラウドとなるとさらに難解さがグレードアップします。
最たる例であるAzureにおけるOracleライセンスの事例を通してご紹介しましょう。

AzureにおけるOracleライセンス

AzureでOracleを使用するには3つの提供形態があります。

1. 持ち込みライセンス（BYOL - Bring Your Own License）
2. Microsoft提供のVMイメージの導入（ギャラリー）
3. Oracle提供のVMイメージの導入（マーケットプレイス）

表にしてみましょう。

(1) Azureとの契約がEAの場合Oracleライセンスを含まれず、別途請求されます
(2) BYOL用のVMイメージというのがマーケットプレイスにあるようです
(3) 英語版、かつOracleをアンインストールしてしまうとライセンスが無効になりますのでおそらく日本語化が難しいかと思われます

提供形態によりライセンスとサポートが入り組んでいるのが良くわかりますね。
特にAzureVMイメージを使用する場合のEA契約の (1) は、普通に考えると意味不明です。そして、Azureで本当にOracleサポート出来るのでしょうかね？（もちろんエスカレーションはしているのでしょうが・・・）
コスト面は通常1が一番安くなると思いますが、2・3は仮想マシンを止めてしまえば料金は発生しません。例えば負荷状況を見てデータベース集約しつつインスタンスを減らすといった削減方法が取り得るのは、パブリッククラウドならではでしょう。
もう一つ、Oracleライセンスにはもっと大きな問題が発生しているのですが…、これは案件に紐づいた情報になりますのでここでの記載は控えさせていただこうかと思います。ご興味のある方もいらっしゃると思いますが、提供は要調整で。

マーケットプレイスでRHEL7.2およびRHEL6.7のイメージが公開されました。ライセンスはBYOL、またはAzure料金に含む、どちらでも利用可能なようです。
次にAzureを含めたパブリッククラウドにおけるプロセッサー／コアライセンスの考え方についてご紹介します。こちらもOracleを例にとってのお話です。

バーチャル・コアと係数

• [クラウド・コンピューティング環境のOracleライセンス]
  http://www.oracle.com/jp/store/cloud-lic-170290-ja.pdf

こちらは現時点では最新の情報ではありませんが、お話を進める上での題材としてご覧ください。
上記の資料にAWS上でのOracleライセンスの計算例が掲載されています。（「本資料は、以下のベンダーが提供するクラウド・コンピューティング環境に適用されます」というくだりにAzureも含まれます）

1. Amazon EC2環境でOracle Database Enterprise Edition（Processorライセンス）を許諾
   1台の承認されたクラウド環境のインスタンスにおいて、Intel製のマルチコア・チップで8バーチャル・コア保有する環境では4Processorライセンスが必要です。（8バーチャル・コア×係数=4Processor）
2. Amazon EC2環境でOracle Database Standard Edition（Processorライセンス）を許諾
   1台の承認されたクラウド環境のインスタンス（バーチャル・コア数1以上4以下を保有）では、1ソケットとしてカウントされるため、1Processorライセンスが必要となります。
   (以下略)

ここでポイントとなるのは太字＆下線で強調している、バーチャル・コアと係数と言う考え方です。
まずバーチャル・コアですが、AWSの場合、これは仮想CPU（vCPU）と完全に一致しているわけではなく、例えばm3.2xlargeやm4.2xlargeではvCPU:8／バーチャル・コア:4とバーチャル・コアの方が少なく設定されています。

• [Amazon EC2 および RDS DB インスタンスタイプ別の仮想コア数]
  http://aws.amazon.com/jp/ec2/virtualcores/

ちなみにAzureの場合はここが一致することになっていますので、AWSよりは少しシンプルです。

• [論理コアと物理コアは 1 対 1 対応]
  https://mspartner.microsoft.com/ja/jp/Pages/Solutions/windows/azure-iaas-report2.aspx

次に係数については、Oracleの場合はCPUベンダーとプロセッサーの種類によって下記資料のように決められています。

• [Oracle Processor Core Factor Table]
  http://www.oracle.com/jp/direct/processor-core-factor-table-jp-168076-ja.pdf

Azure・AWSともに現在Intel Xeonシリーズを使っていますので、係数0.5となりますね。
バーチャル・コアと係数についてOracleの事例をご紹介しましたが、ここで本当にお伝えしたいことは、「バーチャル・コアも係数や適用方法はベンダーが任意に決めてくる」ということです。これも実際の事例ですが、AWS上でのライセンスがオンプレミスやAzureの数倍になる、という係数が設定されている製品もあります。

パブリッククラウドのライセンスをオンプレミスと同じように考えない

ということにご注意ください。ここを見落とすとパブリッククラウド最大のメリットであろうコスト面が破綻をきたすこともあり得ると思いますので。実際のところベンダー側もこのあたりは結構締め上げてきています。

Azureのサポート

さて「第2回：事例から見るAzure活用のポイント」の最後はAzureのサポートについての話題にしましょう。ここに来てやっと活用のポイントらしい話です。
最初に原則ですがマイクロソフトに製品保守はありません。一部SurfaceやXboxなどのハードウェア製品中心に例外はありますが、そこを置いておくとマイクロソフトには製品ごとの保守はなくすべてプレミアサポートに集約されます。（ここも覚えておいていただけるといろいろ役立つと思います）
ですがAzureには上記の原則を覆す形の専用のサポートサービスが存在します。

• [Azure Support]
  https://azure.microsoft.com/ja-jp/support/plans/

中段あたりにある Get the Azure Support datasheet と言うリンクからダウンロードした資料よりの抜粋です。

ここでポイントとなるのは有償のDeveloper～ProDirect1ではなく、「Included with your Azure subscription」という形で無償のサポートサービスが設定されていることです。（利用料の方にはねている可能性はありますが）
これが結構使えるサービスになっていて、

1. まずAzureポータルからいつでもサポートリクエストを上げることが出来ます

2. 同じポータルからサポートリクエストのトレースを行うことが出来ます

3. サポートのクオリティはそこそこ高いです

商用稼働に入ると「Maximum initial response time」「Maximum severity」といったあたりが必要になってくることもあると思いますが、開発・構築フェーズにおいてはこれを上手く使うとコストを抑えられると思います。ただ、問い合わせ内容によってはプレミアサポートにエスカレーションされますのでそこはご注意ください。NTTデータグループの方は件の「技術問い合わせサービス」の有効活用もご検討ください。
ちなみに、表の右端にある通りプレミアサポートも使えます。

まとめ

さて今回は次回予告ではなくまとめで締めたいと思います。Azure（パブリッククラウド）活用のポイントとは何でしょうか？
私の回答は、

割りきり

です。
パブリッククラウドにおいては、金を積もうが人を呼ぼうが解決できない問題は絶対に解決できません。事業者側が対応しないと言ったら対応しないですし、後出しであっても仕様と言われたらそれまで、ライセンスも然りです。かつパブリッククラウドはまさに分進時歩のスピード感で変わっていく世界ですので、ある時点で仕様を固めてと言うアプローチが通用しないことも起こり得ます。
ですので今回ご紹介した事例などをお客様にしっかりインプットした上で、未来に発生する問題含めて割り切ることが出来るかを見極めることが非常に重要となります。ここは非常に難しい作業だと思います。

未来に発生するかもしれない問題に対して「割り切ってください」

なんて普通言えないですよね、でも多分それが必要なんです。