はじめに
本番環境などでやらかしちゃった人 Advent Calendar 2024の18日目になります。
私が新卒2年目の頃のお話です。顧客名や構成などの内容は一部ぼかして記載しています。
こんな人に読んで欲しい
- 仕事に慣れてきた若手
- 公式Docsを鵜呑みにしている人
こんなことが分かります
- 既存環境を細かく確認をすることの大切さ
- 公式Docsでも安易に信用しない懐疑心
何をやらかしたのか
簡単にまとめると、DNSの条件付きフォワーディングの設定を入れたせいで、オンプレミス環境から既存のAzure SQL Databaseへの接続ができなくなりました。
構成図
※引用元はこちらの公式Docs
インシデント発生までの経緯
既にAzureを利用されているクライアントの環境に、新たにAzure SQL Databaseを導入するプロジェクトのリーダーをしていました。
DBにはオンプレミスから接続するのですが、クライアント端末からプライベートリンク（リソースにプライベートIPを付与するサービス）経由でのDBへは、構成図のようなプロセスを経て接続します。
ここで肝心なポイントは、オンプレミスのDNSサーバー（構成図のInternal DNS）です。
クライアント端末はオンプレミスのDNSサーバーで名前解決をしますが、このDNSサーバーはリソースのプライベートIPなんて知りません。このままではパブリックIPで名前解決されてしまいます。
「なら、DNSに無理やりAレコードを書けばいいのでは？」と思われるかもしれませんが、Azureは仕様上「Private DNS Zoneと呼ばれるリソースが紐づけられた仮想ネットワークからのみプライベートIPでの名前解決が可能」になります。
つまり、構成図のVNet-hub-001上に存在するDNS Forwarder経由で名前解決を行う必要があります。
既存環境にはこのDNS Forwarderに該当するDNSサーバーがあったので、あとはInternal DNS→DNS Forwarderへの再問い合わせ処理を実現するだけです。
これを実現する技術が条件付きフォワーディングです。簡単に言えば
ドメイン：database.windows.net
問い合わせ先：DNS ForwarderのIPアドレス
のような設定をすることで、database.windows.netをドメイン名に含む名前解決をDNS ForwarderというDNSサーバーに丸投げするようになります。
ここで考えてみてほしいのですが、もしも今回新たにデプロイするDB以外のAzure SQL Databaseにオンプレミスから接続する場合はどうなるでしょうか。
はい、ドメインにdatabase.windows.netが含まれるのでDNS Forwarderに丸投げです。
この設定を入れた直後、クライアントから「既存DBに接続できなくなりました。」という連絡を受けました。別サブスクリプションで管理するDBに接続できなくなってしまったのです。
このDBでは、業務にかなり密接に関わるデータを管理しており、時期的にデータの棚卸しをしていたので、結果的にクライアントの業務を止めてしまいました。
DBへの接続については、接続元IPを制限して、管理者がオンプレミスからパブリックIPで接続するという運用を行っていました。
この問い合わせを受けて、条件付きフォワーディングのドメイン条件にリソースのFQDNを設定することで事なきを得ました。
なぜこのようなミスが発生したのか
プロジェクト自体は単純なものですが、気を付けるべきポイントがいくつかありました。
- 既存のAzure環境についての知見がない
- プロジェクト自体の開始が遅れてスケジュールがギリギリ
- 私がコロナに感染して出勤停止で大幅な遅延
スケジュール遅れもありますが、特に1つ目が今回のインシデントを発生させてしまった要因になります。既存環境や運用方法の知見が十分にないことで引き起こしたインシデントです。
既存のDBやその運用方法を知っていれば、安易に条件付きフォワーディングの設定を入れずに、初めからFQDNで対処できていました。
また公式のDocsではドメインを指定してましたが、今後リソースが増えることを考慮してFQDNを採用することもできました。
同じミスを引き起こさないためには
- 既存環境については前もってヒアリングを徹底する
- 「公式のDocsに書かれているから」と安易に信用しない
この2つに尽きます。
ここまで読んでいただきありがとうございます。
Xではエンジニアに有益な発信をしていますので、ぜひフォローよろしくお願いします！！