個人でAzureに触れる・・・ものの。

個人でMicrosoft Azureに触れるようになって３年が経過しました。なんだかんだ言いながら結局3年ほどAzureを使い続けています。

どこのPublic Cloudもそうですが、めちゃくちゃ機能が豊富であるとともに、その中のリソースによっては安いものもあれば高いものもあり、場合によっては「作るだけならただ」というのもあります。私自身決して裕福ではない環境下にいますが、それでも結構さわれるリソースがあるもんです。

今回はそうした構成例について書いていくことにしてみました。

RHEL Developer Subscriptionの有効活用

過去に取り上げたような気もするのですが、RedHatには開発者のための無償サブスクリプションがあり、これをDeveloper Subscriptionとよんでいます。このSubscriptionを使用することで、ノンサポート扱いではあるものの、れっきとしたRHELを正規にサブスクリプション権限を持って使用することが可能となります。

このサブスクリプション管理機能の一つとして、CloudAccessという機能があります。この機能はパブリッククラウドに対して自身を紐つけたOSイメージを連携させることができるというものです。これを活用することで、OSに対する課金を回避し、OSをBYOSとして使うことが可能となります。

スポットインスタンス

スポットインスタンスとは、所謂「一切のSLAを保証しないインスタンス」です。MS側がリソース確保上停止する必要があると判断したら、30秒前の通知が行われた後に強制停止させられます。その代わり、驚きの低価格でVMが使用できるようになります。

ただ、気をつけるべきはソフトウェアライセンスです。OSに対して課金される額はスポットインスタンスであっても普通のインスタンスと大差なく徴収されます。よって、普段B2sとか使ってるような私がD2sとかでWindowsを触ったりすると、結構な課金額になります。

ちなみにソフトウェアライセンスはそのVMのグレードによって課金額が変わります。やっぱり最安値なのはブースト型であるB,Bsあたりです。故に、先述したような無償OSサブスクリプションやBYOLなライセンスをこのスポットインスタンスを組み合わせると強いのです。

Traffic Managerで負荷分散

Traffic Managerというのは、名前解決を活用した負荷分散機能で、私の環境だと今Mastodonインスタンスのフロントエンドに役立てています。Traffic Managerは各エンドポイントの状態をL7で監視し、その結果に応じてDNSリクエストが届いた際にどっちのエンドポイントのIPアドレスを返すかを判断します。

リソースはリージョンを考慮しないグローバルリソースですので、可用性という点については結構強いリソースだと思います。

WVDを使ってなんちゃって踏み台

Azureには「Bastion」という踏み台サーバリソースがあります。これはSSH/RDPを中継する踏み台サーバとしてスケールセットが構成される代物で、直接そのサーバに乗り入れることはできませんが、Azure Portalを通じていろんなVMにお手軽に乗り入れることができるようになります。

ところがこの踏み台、なにげに高い。法人向けには格安に見えるが個人にはなかなか強烈に痛い、月額15,000円程度という微妙な金額。私自身一時期使おうとしてた時期がありましたが、その課金額に撤退を余儀なくされました・・・

しかし、これをWVDで実現したらどうか？となると意外とこれが長持ちしたのでありまして。実はこのブログを書いてる端末もWVDから払い出したVMだったりするのですよね。

中でも便利なのがRemoteAppです。所謂公開アプリケーション機能で、あたかも他のアプリケーションのようにそれがWVDセッションなのかどうかを意識する必要なく操作をすることが可能になります。

私はこの機能を用いてHorizon Client及びリモートデスクトップ接続をRemote Appとして使用しています。これにより、アプリケーションのみのプロセス負荷でWVDセッションホストを利用し、より安定した踏み台接続ができるようにしています。

azureCDNによるコンテンツ配信

最後はこちら、私が最初に使ったリソースでもあります、Azure CDNです。

私のウェブサイトはおよそ月間3,000PVという弱小サイトということもあり、AzureCDNのか金額は100円前後にとどまっています。長らくこのCDNのお世話になっていますが、Verizon Premiumでこの金額は美味しいなぁと。

重要なのは、トラフィクに乗るコンテンツの容量でして、この容量（ＧＢ単位）が金額にはねます。
また、グローバルリージョンということもあり、己でゾーンを選択することはどうやら出来なさそうです。
大体私の環境ですと、ゾーン1（北米系）、ゾーン2（アジア系）がよくアクセスされてるようで、そこの課金額が発生しているように見えます。

その他もろもろ

VNETに関しては、定義だけ作成するなら課金されません。そこから通信を発生させなければいいだけなので、経路を構成するとかのレベルであればかなりお金をかけずに色々試せます。Global Peering、VNET Peeringなどを構成して経路を覗く・・・・とかはその代表例かなと思います。

逆にDDOS Protection Standardのように、作成したら突然莫大な課金が発生するリソースも存在します。課金の仕方は本当にリソースによってまちまちなので注意するようにしてください。

WebAppsのようなコンテナ系リソースは、仮にそのリソースを停止しても課金が継続します。故に、使わない間は金額を下げたい等の場合は、そのWebAppsのサイズを縮小する、あるいはスケールアウト台数を減らすなどの対応が必要になるかなと思われます。

こうして、課金の考え方を広く把握することは、やがてAzureの仕組みを知っていくことにもつながっていくので、ぜひぜひ機能面だけの学習にとどまらずこうしたところも覚えていくとよいのかなと思います。