はじめに
DiscordでTodo管理できるBotを作成するまでの流れと、その際に調べた内容についてをまとめていきます。基本的に説明は「後で自分が同じことをするときに、調べなおさなくてもざっくり理解できる」ことを目標に書いているので、正確なことや詳細なことはドキュメントや既存サイトにお任せです。
AzureによるWebアプリケーション構築
今作成しようとしているBotはかなりシンプルなものであり、かつ自分が管理しているのDiscordサーバーでのみ使用するような、規模も使用人数も頻度もかなり限られた(最大50人くらい)ものを想定して作成していってます。
大まかな構成図はこちら。今回はこの中のSQL DBを作成するときに調査した内容をまとめました。

USMで始めに実装するタスクセットを「やるべきことを登録する」「リスト内のタスクを一覧で見る」「タスクのステータスをDoneにする」だけにしたので、本当はFunctions要らないんですけど、図としてさみしかったので入れちゃいました。実際にFunctions使うのはかなり後になります。
Azure SQL DBの作成
AzureでSQL DBを新規作成するときの設定について。
- Azure SQL Databse
- Basics|基本
- Project details
- Subscription
- Resouce group
ここはDBを使用するアプリケーションと同じサブスクリプション・リソースグループを選択。
- Database details
- Database name
- Server
SQL DBはSQL Server内に作成する。既存のSQL Serverが無い場合は Create new で新規作成する。SQL DB(Server)に接続するアカウントはSQL Serverに対して設定を行う。
- SQL elastic pool
複数のDBを管理したい要件が無ければ基本的にNoを選択。
SQLエラスティックプールについての詳細はこちらを参照。 - Compute + storage
使用するDBの性能とサイズを設定する。デフォルトで結構高めのものが設定されているので注意。わかりづらいけど、必ず確認すること。Configure databseをクリックして、適したものを選択。
簡単かつ規模の小さいDBならDTUのBasicを選択する、で良さそう。 - Backup storage redundancy
バックアップの冗長性の設定。コストの高さと冗長性が比例。LRS<ZRS<GRS。
このページの説明がわかりやすかった。- Locally-redundant backup storage
LRS。ローカル冗長ストレージ。低コストでシンプル。データを置いてるデータセンターがつぶれると死ぬ。 - Zone-redundant backup storage
ZRS。ゾーン冗長ストレージ。3つのデータデンターで冗長化。リージョンレベルの災害が起きると死ぬ。 - Geo-redundant backup storage
GRS。geo冗長ストレージ。ZRSに加えて、さらに別のリージョンで冗長化を行う。日本の場合は、西日本と東日本のリージョンがある。西日本をプライマリにしてる場合、西日本リージョンに何かあったとしても、東日本のリージョンにデータがあるので安心。ただし一番高い。
- Locally-redundant backup storage
- Project details
- Networking|ネットワーク
- Network connectivity
SQL DBへの接続口をどうするか設定する。詳細はこちらを参照。- No access
アクセスなし。孤立無援。どこからも繋がらない。このままだとDBの意味がないので後で設定しなおす前提の設定。 - Public endpoint
基本的にどこからでもアクセスできるが、ファイアウォールの規則によって制限をかける。- Fire wall rules
AzureリソースとIPアドレスのホワイトリストで設定。共用じゃないネットワーク(自宅とか)からつないでる場合は Add current client IP address を Yes にしておく。
- Fire wall rules
- Private endpoint
プライベートエンドポイントと呼ばれる、仮想ネットワーク内にあるエンドポイントを設定する。この設定をするには、Private Linkの理解が必要。
- No access
- Connection policy
SQL DBにどう接続させるかを設定する。ひとまずよしなにしてくれる Default を使用。 - Encrypted connections
暗号化の設定。要件による細かな定義や制約がない場合はとりあえず最新でOK。
- Network connectivity
- Security|セキュリティ
- Microsoft Defender for SQL
よしなにSQLを守ってくれる「Microsoft Defender for SQL」を有効にするかどうか。30日間のフリートライアルの後から、1680円/サーバー/月かかる。後からでも有効にできるし、サブスクリプション単位で有効にすることもできる。お金はかかる。 - Ledger
Azure SQL Database Ledger。データの改ざんがなされていないか、定期的にチェックする機能のよう。まだプレビュー段階。 - Identity
マネージドIDを利用するか否かの設定。WebアプリからDBに接続するとき、接続文字列なんかを利用して認証する必要があるけど、その代わりににマネージドIDを利用することができる。設定によるけど、Azure内の特定の範囲で有効なサービス間の接続用IDって感じ。自分でアプリ⇒DB接続用のパスワードを管理する必要がないから、よりセキュアになる。 - Transparent data encryption
TDE。透過的なデータ暗号化。データを出し入れするときに暗号化してくれるので、複合化のKeyなしで接続しても、何が何やらわからないデータになっている。このページがわかりやすかった。
- Microsoft Defender for SQL
- Additional settings|その他の設定
その他の設定。あまり重要な設定はないので飛ばしてもOK。 - Tags|タグ
リソースごとにつけることができるタグ。管理するリソースが増えてきたら運用を考える。 - Review + create|レビュー+作成
作成前の最後の確認ページ。これまでの設定に抜け漏れがあるとエラーで教えてくれる。
- Basics|基本
SQL Database|Compute + storage
大きく「vCore」と「DTU」どちらで設定するかが分かれる。
ざっくりいうと、DTU(Dtabase Transaction Unit)はいい感じの性能とサイズの組み合わせをセットにしてくれたもの。vCoreは性能やサイズをいろいろと選択できる。要件に対してきっちり設定したい場合はvCore、とりあえずなんとなくつくろうって感じの場合はDTUになるんじゃないかな。詳細はこちらを参照。
Azure Priavte Link
パブリックな場所に開かれた複数のサービスをセキュアに使用・接続するとき、複雑な設定が必要になる場合がある。そういったサービスをVNET(仮想ネット)内のプライベートな空間で運用しつつ、外部からの接続はプライベートエンドポイントを介して行う、というのがPrivate Link。
VNETの設定が必要だから、今回のTodo管理Botみたいにシンプルな構成のものをつくるときは必要なさそう。このページの説明がわかりやすかった。
後で調べること
- SQL DBの接続ポリシーについて。リダイレクトの接続が速いことは理解したけど、デメリットは?
SQL DB接続ポリシーのドキュメントはここ。 - Microsoft Defender for SQL って結局何をしてくれるの? よしなにしてくれそうな印象はある。毎月約1500円かかるに値するサービスなの?