「クラウド市場シェアナンバーワン」に意味はない

「AWSが世界のクラウドサービス市場で首位陥落、マイクロソフトが逆転」というニュースが入ってきて、正直ちょっとあわてました。

AWSがクラウド業界のリーディングカンパニーであることは間違いなく、それを追うのがマイクロソフトという構図は変わっていません。また、市場シェアはAWSのざっと半分がAzureというのが一般的な見解です(調査会社によっては4倍程度まで開きます)。

「AWS vs. マイクロソフト」つまり、SaaSを含む全クラウドの売り上げを集計すると、僅差でマイクロソフトが勝ったということです。逆にいうと、ほとんどSaaSを持たないAWSが、僅差で2位というのはいかにAWSが支持されているかの証拠でもあります。

SaaS (Software as a Service) はクラウドの一種ではありますが、利用者の意識はちょっと違うように思いますし、IT技術者の意識もSaaSは区別して考える場合が多いようです。

AWSは最近までSaaSには手を付けていませんでした。マイクロソフトはIaaSとPaaSをAzureとして提供していますが、SaaSは別ブランドです(たとえばOffice 365)。IBMも、IaaSのSoftLayer、PaaSのBluemixを統合しIBM Cloudとしましたが、SaaSは別ブランドです。

SaaSを特別扱いするのは、それがビジネスと直結しているからです。電子メールやドキュメントツールくらいなら、会社による違いはそれほどありませんが、会計システムだと業界ごとの差は大きく、会社ごとの独自性もあります。

マイクロソフトもAWSも、業務に直結したアプリケーションの提案は、ビジネスパートナーの仕事です。マイクロソフトはDynamics 365というERPクラウドを持っていますが、これはクラウドプロバイダーとしてはかなり珍しい存在です。

ただ、近頃のSaaSはアプリケーションから利用するためのAPIが公開されており、実質的なPaaSとして利用できます。CRM(顧客管理)のSaaSで有名なSalesforceは、Salesforce CRMの動作基盤をPaaSとして利用できます。このように、SaaSとPaaSの区別はあまりなくなってきています。

このように、SaaSは定義的はクラウドですし、実体としてもPaaSに寄ってきたので、名実共にクラウドの一種ではあります。

それでも、現段階でSaaSをIaaSと同列に並べるのはちょっと抵抗を感じます。

そういうことを感じながら、「AWS首位陥落」という表現はちょっと違うなあと思いながら書いた記事がこちらです。

クラウド市場シェアナンバーワンはどこだ？～AWS vs. マイクロソフト～

英語版Windows Serverを日本語化する手順

Azureなどのクラウドが提供する仮想マシンの多くは英語版のOSしか利用できません。AWSの場合は、Community AMIとして日本語化されたものも選べるようですが、Azureにはありません。Azureには、中国語版が最近追加されたので、日本語版も追加される可能性はゼロではありませんが、可能性は低いでしょう。

そこで、以前「英語版Windows Server 2012 R2を日本語化する手順」というエントリを書きました。しかし、手順を紹介しただけで、画面ショットもありませんでした。

Windows Server 2019で操作手順が変わったため、改めて画面ショットも付けて書き直しました。

【図解】英語版Windowsの日本語化～画面ショット付き詳細手順～

今度は会社の公式ブログに載せてもらいました。

Windows Server 2019では[コントロールパネル]ではなく、[設定]を使います。Windows Server 2016では[コントロールパネル]と[設定]のどちらでも可能ですが、[設定]の手順がWindows Server 2016と微妙に違います。一方、コントロールパネルを使った手順はWindows Server 2012と同じなので、ブログではWindows Server 2019とWindows Server 2016以前の2つに分けています。

マイクロソフトMVPアワード受賞できませんでした

2003年4月から、連続して受賞してきた「Microsoft MVPアワード」ですが、今回は受賞できませんでした。

一昨年は書籍が2冊出たのですが、昨年は全くなかったことが要因かもしれません。現在、書籍執筆が2冊進行中なんですが、ちょっと残念です。

【Azure】マネージドディスクとイメージ、仮想マシンの課金

一般にクラウドコンピューティングサービスでは「使った分だけ課金」が基本ですが、何をもって「使ったか」というのはなかなか難しい問題です。

ストレージアカウントの場合(ページBLOB=非マネージドディスクを含む)

Azureのストレージは、Standard ページBLOBを使った仮想ディスクだけが「実際に使った分量に対してGB単価で課金」で、その他のストレージは「割り当てた分量に対して課金」です。

Standard ページBLOB以外のストレージは、いくつかの容量が事前に用意されており、それを選ぶ「カタログ方式」となっています。実際には1GB単位で指定できるのですが、課金はカタログ単位の切り上げになります。たとえば128GBの次は256GBなので、129GBを割り当てると256GBの課金が発生します。

請求は1ヶ月単位のサイクルで行なわれますが、ストレージの使用が1ヶ月に満たない場合は毎日の平均(日割り計算)となります。

Azure Storage を月に数日間のみ使用した場合、料金は日割りされますか?

はい。ストレージ容量は、1 か月にわたり、保存されていたデータ量の 1 日あたりの平均 (GB 単位) を基準に請求されます。たとえば、月の前半は 10 GB のストレージを常に使用し、後半は使用しなかった場合は、ストレージの平均使用量の 5 GB が課金されます。

(ストレージのFQAより)

課金は1日のピークで行なわれるので、図の例で6月15日にゼロにするためには、6月14日中に削除しておく必要があります。

マネージドディスクの場合

ただし、マネージドディスク(管理ディスク)の場合はStandard HDDを含むすべての種類が割り当て単位で課金されます。また、カタログにある容量を超えた場合は課金が切り上げられます。

ストレージアカウントと同様、請求は1ヶ月単位のサイクルで行なわれますが、マネージドディスクの使用が1ヶ月に満たない場合は1時間単位の課金となります。

以下に示す料金が月額になります。管理ディスクを 1 か月未満使用した場合はどのように課金されますか。

料金は月額を使用して、時間単位で計算されます。たとえば、P15 の Premium SSD は ¥4,896.720 になります (リージョンによって料金が異なります)。10 月は、¥4,896.720/(31 日 x 24 時間) = ¥6.582/時間で課金されます。

(マネージドディスクのFQAより)

仮想マシンイメージの課金

マネージドディスクから仮想マシンイメージを作った場合、「スナップショット」と同等の料金がかかります。「無料」と書いてある記事もあるようですが、課金されることはサポートに問い合わせたので間違いありません。

しかし、実際に課金状況を調べてみると、はるかに小さな金額しか請求されていません。「課金サポートではこれ以上のことは分かりかねるので、有償の技術サポートに連絡して欲しい」と言われました。詳細が分かったら報告します。

仮想マシンの課金

Azureの仮想マシンは、分単位課金です。仮想マシンが実行状態になってから課金がスタートして、最初の1分は無条件に1分が課金されます。

その後、1分59秒までは追加の課金がなく、2分になってから次の1分の課金が行なわれます。

AzureのWebサイトには「秒単位課金」という言葉や「時間課金」という言葉が混じっていて混乱していますが、ブログ執筆時点で分単位で課金されることは間違いありません。

「秒単位課金」は「秒単位計測」の意味のようです。1分59秒までが1分、2分ちょうどから次の1分と、正しく認識するには秒単位の計測が必要です。

「時間赤金」は課金明細の記載単位だそうです。確かに、利用明細には「0.92 1時間」のように、1時間単位で記載されています。

ちょっと紛らわしいですね。

なお、後損仁通り、仮想マシンの課金は単なるシャットダウンでは停止せず、「割り当て解除」状態に移行しないと課金が継続します。ハードウェアの割り当てをしている以上は「使っている」とみなすわけですが、これも直感に反します。理屈が分かれば不思議ではないのですが。

【Azure】Azureの仮想マシンにドメインコントローラーを構成する

Microsoft Azureの仮想マシンにドメインコントローラーを構成する場合、以下の注意が必要です。

• データベースはCドライブに置かない
• 仮想ネットワークのDNSサーバーアドレスをドメインコントローラーのものに変更する

AzureのシステムディスクにはRead/Writeキャッシュが設定されていて、不慮の事態によるデータロスがあり得ます。SLAでは稼働率99.9%とか99.95%となっていても、落ちるときは落ちます。

ドメインコントローラー昇格時は、ディレクトリデータベースを配置したディスクドライブのキャッシュを無効にするため、データロスの問題は発生しませんが、パフォーマンス劣化の問題があり、いずれにしてもCドライブににディレクトリデータベースを配置するのは好ましくありません。

と思っていたんですが、Azureキャッシュは無効にできないようです。つまり「データベースはCドライブに置かない」という結論は同じですが、その理由は「予期せぬ停止により、データロスが発生する可能性があるから」ということになります。

このあたりの話は、以下のコースで扱っています。

Microsoft Azureによるサイト間ネットワークの構築 ～ハイブリッドクラウド構成の基礎～

Linuxのお客様も増えてきたので、カリキュラムの変更も考えているのですが、当分の間Windows Serverの話をしています。ただし、最後の1時間くらいです。

AzureとAWSの可用性ゾーン(AZ)

Microsoft Azureの「可用性ゾーン(AZ)」が東日本で利用できるようになっています。西日本はもう少しかかりそうですが、いずれは利用できるようになるそうです。

AzureのAZは、リージョンあたり3つと決まっています。AWSは「2つ以上」だったでしょうか。

Azureのリージョン間は数百Km以上離れているので非常に安全ですが、少々距離が遠すぎます。一方、AZ間の距離は(同一リージョン内の)数十Kmと、かなり短くなっています(AWSと同程度です)。阪神大震災でも40Kmも離れればほとんど影響はありませんでしたから、実用上はAZで十分でしょう。

従来の可用性セット(AS)は、最短でサーバーラックが分離されるだけですから、大規模災害に対しては少々不安が残ります。災害リスクを考えるとAZが必要でしょう。また、日本に関しては、可用性セットで分離できる障害ドメイン(サーバーラック)は2つですから、障害範囲に関しても現時点ではAZの方が有利なようです。

ただし、AZは仮想マシンを作るときにゾーンを明示的に指定する必要があります。それに対してASは「とりあえず同じASにする」という設定で、適当に分散してくれます。何も考えなくてもいいので、ASの方が設定は楽です。

以上のことから、災害対策を想定する場合はAZ、ハードウェア障害を想定する場合はASと使い分けるのがいいようです。なお、Azureでは災害対策にはASR(Azureサイトリカバリ)も利用できます(ASRはリージョン間の複製です)。ASRを使っているならAZを使う必要はないでしょう。

また、「AzureのAZはAWSのAZと同じ」という説明がされていますが(私もしています)、実際には違いもあります。

AWSでは、AZ単位でサブネットを分割する必要があります。これに対して、Azureでは同一サブネット内に異なるAZのサーバーを配置できます。

もっとも、AZが違えばデータ伝送遅延時間が違うので、異なるAZを同じサブネットにするのが適切かどうかは分かりません。AWSと同じように、異なるAZは異なるサブネットにした方が分かりやすいのではないでしょうか。

試しに、複数のAZに複数のサブネットを構成してpingを実行してみました。Windowsのpingは応答時間の分解能が低いのでLinux(Ubuntu)を使っています。

図のように、AZ内では1ミリ秒程度、AZ間では2ミリ秒程度の遅延がありました。サブネットの有無は速度に影響しません。これもAWSと同様のようです。

アプリケーションにとっては1ミリ秒と2ミリ秒の違いが重要な場合もあるので、サブネットを自分で分けた方が分かりやすそうです。

Azure管理用PowerShellモジュール「AzureRM」の削除手順

Microsoft Azureの展開モデルには「クラシックモデル(別名サービスマネージャー)」と、「リソースマネージャー」があります。

PowerShellから管理する場合、クラシックモデルはAzureモジュールを、リソースマネージャーはAzureRmモジュールを使っていました。

Azureモジュールのコマンドレット(PowerShellのコマンド)は「動詞-Azure名詞」の形式で、たとえばGet-AzureVMのようになります。

AzureRmモジュールのコマンドは「動詞-AzureRm名詞」の形式で、たとえばGet-AzureRmVMのようになります。

よく使うリソースマネージャーの方がコマンド名が長くなっているのは、リソースマネージャーがあとから登場したためです。

昨年から提供されているのは、AzureRmモジュールに変わるAzモジュールです。こちらは「Get-AzVM」のようにAzを識別子として使うため、コマンドレットが少し短くなっています。

しかし、これにより2つの問題が発生しました。

• 既存のスクリプトが動かなくなる
• AzモジュールがAzureRmモジュールと共存できない

以下が解決方法です。

【既存のスクリプトが動かなくなる】

コマンドレットの名前が変わると既存のスクリプトが動作しなくなります。そこで、Enable-AzureRmAliasというコマンドレットが用意されました。このコマンドレットを実行することで、AzureRmモジュールのコマンドレットがAzモジュールのコマンドレットの別名として利用できます。

【AzモジュールがAzureRmモジュールと共存できない】

PowerShellのAzureRmモジュールが残っている場合は、Azモジュールのインストール前にAzureRmモジュールをアンインストールしてください。Azureモジュールはそのままで構いません。

詳しい手順は以下を参照してください。

Azure PowerShell モジュールのアンインストール

私の環境では、それでもいくつかのサブモジュールが残ってしまいました。そこで、以下のコマンドを実行しました(全体で1行です)。

Get-Command *az* | where module -Like "azurerm*" | Sort-Object -Unique module | ForEach-Object {Uninstall-Module $_.module}

きちんとデバッグしていないので、利用する場合は十分テストしてからにしてください。