AzureでSMTPサーバを構築する

はじめに

かつてはサーバというのは自前で構築するものでしたが、どうしてもメンテナンスコストがかかります。人力でこなせばいいだけのことですが、生産性を上げるなら専門のサービスに任せてしまうのが今の時代です。

また、公開サーバを用意すると支那人が攻撃に来るので、この対策にも費用がかかります。

今更、電子メールなのか

電子メールはインターネット黎明期から存在する通信プロトコルで細かな改良は加えられてますが基本的なものは変わっていません。そもそもToまで到達することが保証されてないです。その割に構築は面倒でSMTPとPOPの2つがセットで必要となります。

その上、支那人対策もしないといけないので、うちの電子メール環境はすべてGoogleさんにおまかせしました。

ではなぜいまさらSMTPが必要になるかというと、垂れ流し方式の警告を行うのにGMailは面倒だからです。SMTPがあれば複雑な手順を踏まずにメールが送信できます。

Azure Virtual Machines は使えない

サーバが必要なので真っ先に思いつく構築は仮想マシンなのですが、Azureの仮想マシンでSMTPは構築できません。これはAzureがSMTPの構築を禁止していて通信ポートを塞いでるからです。

前述の通り、SMTPは簡単にメールが送信できて、しかもFrom情報の検証は行いません。このため、電子メールは犯罪行為や迷惑行為に利用されてしまいます。インターネットの通信を中継するルーターにはこの種のメールのフィルタ機能があって、頻繁にこの種のメールを送信するサーバのIPアドレスをブラックリストとして共有します。このため、IPアドレスを共有する仮想マシンはすぐにブラック化されてしまい、仮想環境の提供元も被害を受けてしまします。これが禁止の理由です。

Send Grid を使う

クラウドサービスではこの問題は一般的なので普通はSMTPを行うサービスがあります。しかし、Azureでは自前のものがないでのSend Gridサービスを利用することになります。MicrosoftもSend Gridを推奨しています。

Send Grid をデプロイするときに設定する内容は次の3つです。

• 名前
  アカウント名って説明があるけど、認証のIDは別に発行される。
  ここで言う名前はAzure上のリソースを管理するときの名前です。
  私はアカウント名と間違った・・・
• パスワード
  こっちは認証用に使うパスワードです。
  上の名前とセットの入力欄になっているのがいやらしい。
• プラン
  料金プランです。Freeでも月25000通のメールが送信できるのでFreeで十分

以上です。

Send Grid の接続情報

SMTPに接続するための情報

• サーバ名：smtp.sendgrid.net
• ポート：25 / 465 / 587 / 2525
• 認証：SMTP認証

ポートは25は暗号化なし、465はSSL、587はTLSです。

2525は非推奨となっています。

このため、ポートは587の一択となります。

Send Grid の管理

Send Grid の管理はAzureのコンソールからManageを選択すると管理画面に遷移することができます。

ユーザー登録する時に送信される確認メールから認証画面が開きますが、そこからは遷移できないです。Azure経由の登録だからなのかな？

Send Grid のサービスステータス

サービスのステータスは以下のリンクから確認が可能です。

サービスステータス

Azure Cosmos DB の価格

Azure の価格はとてもわかりにくいです。
これは半分以上自分のためのメモです。

このメモは Azure Cosmos DB を構築する際の費用のかかり方のメモです。

Cosmos DB の特徴

そもそもこの名前からは内容がわかりにくいこのサービスはなにか。Microsoft のネーミングセンスからは珍しいです。
簡単に言うと、MicrosoftのオリジナルのNoSQL系データベースです。
小宇宙という大仰なネーミングが付いているのは各地域リージョンで自動的に同期が取られるという機能が基本機能でついているからのようです。

実はこの地域リージョン間での同期というのはクラウドが全世界規模でサービス適用され始めて問題となった点です。
世界規模で見ると地球は広い。日本国内なら北海道と九州でも数十msといったレベルでも国外に出ると100msはゆうに超える。世界レベルでサービスを展開する際に単一地点にサーバがあるとこの時間が割と問題になります。特に最近のクラサバモデルではクライアントは単なるコンソールに徹することが多いという点も通信時間の短縮が求められます。では「クラウドサービスを駆使して世界各地にサーバを用意すればいいのでは」となると各サーバの同期というのが問題となります。Azure Cosmos DB はこれらの問題をクラウドサービスレベルで解決してくれます。正に次世代のクラウドDBと言えます。

NoSQLとしては割と普通です。データ構造は流行のJSON構造です。また、1要素をキーとして登録することができ、このキー要素でアクセス範囲を絞り込みが可能となっています。このキー要素は Partition Key という名前になります。アクセス範囲を絞り込むことでI/Oを少なくでき速さもお金も優しくなります。途中で変更できないので設計がとても大事です。

DB Account

サービスのアカウントのこと。
最上位の管理単位。
地域リージョンの設定はこのレベルで行う。

Database

DB Account に登録する。
提供サービスごとに作るのがいいかな。

Container

Database の下に登録する。
Partition Key や Time to Live を設定するのはこの単位となる。

Request Unit (RU)

要求に対する処理の大きさの単位。
一体どのような計算になってるかはよくわからない。
基本的にI/Oが大きくなると大きくなる。
数KB程度のデータだと1~2RUという感じ。

最小構成

１アカウント、１データベース、１コンテナ
400RU/s、ストレージ1GB
地域リージョン１つ
これが最小構成となる。
金額は2,975円/月となる。
複数リージョン書き込み設定で地域リージョン１つだと約6,000円/月といったところ。
機能から考えても納得のお値段。払うとなると高いけど・・・

無料枠

テストで最小構成を構築しても、費用が発生することので敬遠されていたのか、最小構成の場合は無料で使えるようになりました。
１請求単位で最小構成１つまでは無料になった。
ストレージは5GBまで、400RU/sまでのアクセスに耐えられる。
RUはデータベース単位で制限をかけられるのでクラウド死も防げます。

Azure SQL Database の価格

Azure の価格はとてもわかりにくいです。
これは半分以上自分のためのメモです。

このメモは Azure で SQL Database を構築する際の費用のかかり方のメモです。

Microsoft SQL Server は RDB としてはかなり優秀です。Azure SQL Database ではこの優秀なRDBのほぼフル機能を利用することができます。Edition でいうと Enterprise 相当になります。ちなみに Microsoft SQL Server Enterprise Edition の値段は150万円です。しかもコアライセンスです。今どき1コアで動かすとかありえないので、コア数倍かかるというちょっと払えないお値段です。Azureクラウドで使えば不要になったらお金かからなくなるし、最新バージョンも使い続けられるという点でお得です。

３つのオプション

まず、用途に応じてオプション（というかモード）を選びます。

マネージドインスタンス

いわゆる専有モード
オンプレから移行するならこれになると思う。
最小単位はvCore4個、メモリ20GB、ストレージ32GBで値段は89,000円/月
Enterpriseだと考えると納得の値段だけど高い・・・

エラスティックプール

複数のSingle Databaseを纏めて扱える。Databaseが複数あって高負荷が同時に発生しないときに効率よく扱える。しかし、Single Database を足し合わせたときよりも高額になる。
マネージドインスタンスと違ってDTU購入モデルが使える。
DTUはCPU時間とストレージアクセスを指数化したもので細かく設定変更できるのが利点となる。その点を考慮して、vCoreよりもDTUだと思う。
最小構成はEDTU50、ストレージ5GBで9,400円/月。
なかなかのお値段・・・

Single Database

単一のDatabaseを扱う。ちなみに、オンプレからAzure SQL Databaseに転送するツールは用意されている。（ちょっと時間かかるけど）
vCoreモデルとDTUモデルがあるけど、エラスティックプールのときと同様にDTUモデルのほうが利便性が高い。
最小構成はDTU5、ストレージ2GBで620円/月。
エントリーとしてはここから攻めていくのがいいと思う。

DTUとは

DTU は Azure SQL Database を使う上では重要なものとなります。
いろいろな要素がありますが、単純化するとCPU時間とストレージへのIOを指数化したものです。ではどの程度必要なのかと言われれば、「？」となります。
Microsoft にはオンプレからAzureへの移行用にDTU算出ツールがあるので使ってみたところ、4コアサーバで200～300DTUといったところ。
最小構成の5DTUだとsp_helpでTableの情報を出すにも数秒掛かる程度といった感じになります。
DTUは1単位では設定できないものの、Standardで10、20、50、100、200、400、800，1600、3000と設定は結構豊富なので必要なときに必要分のDTUを設定するのがいいです。つまるところ、負荷が低いときに高DTU設定とすると無駄に課金してしまうことになります。
注意点としてはDTUの設定を変更すると接続中のConnectionは切断される可能性があること。全自動のスケーリングというわけにはいかない。

オンプレから移行時の注意点

オンプレからだと制限されている機能があるのでそのままでは移行できないことがあります。

他のデータベースへのアクセス

セキュリティの関係から基本的にデータベース名を指定してのアクセスはできないと考えていい。

CLR

これも多分セキュリティの問題でCLRはインストールできない。魔改造してあるデータベースは要注意となる。

ログイン

初期がID、PASS方式で管理者権限アクセスとなるので、セキュリティ的には少し弱い。
そもそも、ID、PASS方式の認証があると支那人が多量にアタックしてくる。うざい

Azure Functions の価格

Azure の価格はとてもわかりにくいです。
これは半分以上自分のためのメモです。

このメモはAzureでFunctionsを構築する際の費用のかかり方のメモです。

Functions は Web Apps と同じような機能を持っています。
ただし、Web Apps が HTTP Request に対して動作するだけなのに対して、Functions はTimer、Cosmos DB など 他の Azure サービスをトリガーに動作させることも可能です。

価格のパターンは、完全従量制の使用量プランと、リソースを予め確保できるPremiumプランの２つです。
と思わせておきながら、Web Appsのプランも実は使えます。
ただし、Web Appsのプランは共有のFやDは使えません。
利用してないときに領域が確保されるのでトリガーが発火する条件になっても動かないことがあります。

Premiumプランは最低構成でも月額16,000円程度となかなかのプレミアム感なので使わない。そんなお金はない。

使用量プランは実行時の使用CPU時間と使用メモリを乗算したGB秒と実行回数で課金されます。
ただし、無料枠があり、40万GB秒、100万回実行までは無料となります。
この無料枠は大変美味しいので Functions は使用量プラン1択ですね。

使用量プランで価格を抑えるためにはメモリの消費を抑えたプログラムにすることが肝心となります。
例えば、多量のデータをメモリーに一時格納して演算するとかすると、無料枠がゴリゴリ削れていきます。

使用量プランの難点は1実行の実行時間に限度があって、超えるとタイムアウトの例外が走ることです。
規定では5分で、設定で変更できますが、上限は10分です。
無制限に実行してクラウド死しても困るし、上限があるのはありがたいのですが、予め10分超えることがわかっている場合は困りものです。
この場合は、プログラムで処理を分割して1実行が10分超えないようにする必要があります。
Microsoft.Azure.WebJobs.Extensions.DurableTask.IDurableOrchestrationContext.CallSubOrchestratorAsync
などで実行を分割できます。実行回数は増えますが、100万実行回数を消化しきっても、次の100万実行回数は22円なので価格インパクトはないです。

Functions を使う上での注意はスレッドです。
実は作る関数に制約があって、注意してても例外がよく起こります。
特に他のサービスのAPIを利用するときにAPIライブラリの中でTaskが使われていてNonDeterministicOrchestrationExceptionが発生することがよくあります。
ハマります。これなんとかならないものか・・・

Azure Web Apps の価格

Azure の価格はとてもわかりにくいです。
これは半分以上自分のためのメモです。

このメモはAzureでWeb Appsを構築する際の費用のかかり方のメモです。

Azure Web AppsはWeb アプリケーションを配置する上で非常に便利です。
Visual Studioで構築して即配置できるなど、親和性が高いです。
開発は.NET Coreが必要ですが、よもや.NET Frameworkをいまさら使う人もいるまい。

価格もわかりやすく、F,D,B,S,Pのランクとコア数だけ選択すれば価格は決定します。
Fは無料の共有サーバになりますが、小規模のアクセスならばこれで十分なくらいです。

注意すべき点は、FとDは共有サーバになるので一定時間アクセスがないと演算領域が解放されるのか、初回アクセスがやや遅延します。（まあ、シビアなアプリケーションでなければ問題ないレベルだとは思います）

もっと注意すべき点は仮想ネットワークです。
オープンなアプリケーションでなく、クローズなものを構築する際に仮想ネットワークに所属させて制御したいところですが、Web Appsを仮想ネットワークに参加させるためにはS以上のランクが必要となります。
S以上のランクで最安はS1で月額9000円余りします。維持費としてはそこそこレベルになります。

Azure Virtual Machines の価格

Azure の価格はとてもわかりにくいです。
これは半分以上自分のためのメモです。

このメモはAzureで仮想マシンを構築する際の費用のかかり方のメモです。

Azureの仮想マシンは設定が色々たくさんありますが、まずはデフォルトで用意されているセットの中で選ぶと思います。その際に費用対効果を考えながらセットを選ぶと思いますが、注意すべき点が1つあります。

Azureの仮想マシンは使わないときでもお金がかかる

これです。
なぜなのか。これを説明したいと思います。

Azureで仮想マシンを作る際には多くの種類のリソースが必要になります。
次のリソースがだいたい必要となります。

1. 仮想マシン
2. ストレージ（ディスク）
3. ストレージアカウント
4. ネットワークインターフェイス
5. パブリックIPアドレス
6. ネットワークセキュリティグループ
7. 仮想ネットワーク

以上です。

この中で費用がかかってお財布にインパクトが出るものは、１・２・４・５となります。

Microsoftが提示するセットの価格表示は１・２です。

この時点でなんでやと思いますが、まだ安心です。

４はAzureの同一リージョン内の通信は無料ですし、外部との通信もAzureに入る方向は無料で、出る方向は5GBまで無料です。

Azureのストレージはなかなかの高額なので、「Azureでコンピューティングして結果を大量に外部ストレージに吐き出す」といったような構成にしなければ問題ないです。

５はちょっとだけ注意が必要です。IPの割り振りが存在する時間だけ課金対象となります。そのため、外部からIPアドレス指定で通信を行う必要があって固定IPが必要となると固定でお金がかかることになります。この点はだいたい想像できます。

問題となるのは仮想マシンがOFFになってもIPアドレスを開放しなければ課金対象になる点です。動的IPアドレスの設定になっていてもIPアドレスは速やかに開放されません（たぶん、再起動時にIPアドレスが変わることを防ぐためだと思う。）。余計な課金を避けるためには仮想マシンの電源を落とした時点でIPアドレスの開放操作をする必要があります。

１は電源を落とせば課金対象から外れます。たぶん、これが世間一般的な認識だと思います。

最大の問題は２です。

これは仮想マシンが動いてなくても、読み書きが発生しなくても常に課金対象になります。

しかも、容量の確保した分に比例した課金が発生します。

つまり、Windowsマシンを使う上で必ず必要なスワップ領域も課金対象となります。スワップとか仮想マシン使ってないときには空なのに・・・

もちろんWindows Updateで太る領域もストレージ容量として必要になります。

そして、Azureのストレージがめっさ高いという罠付きです。

できるだけ費用を抑えるためには、「SSDでなくHDDを選択する」「Windowsが稼働するだけのストレージにしておき、データなどは別のサービスを利用する」などの方法を取る必要があります。

※Azureのストレージは高いですが、サービス内容を考えると値段は妥当なものです。

ただ、サービスが全部入り状態なので高いってだけです。用途に応じてAzure内外の他のサービスも活用することで費用は抑えられます。ご利用は計画的に