名前解決から透けて見える Azure PaaS の裏側

Azure PaaS の FQDN を dig で引いて、返ってくる CNAME / A レコードから「裏で何が動いていそうか」を読む

Transcript

1. 名前解決から透けて見える Azure PaaS の裏側 Yona Yona Azure Club ほりひろ dig
2. About me
3. Azure PaaS の FQDN を dig で引く nslookup は古いらしい 返ってくる CNAME / A を見る そこから「裏で何が動いていそうか」を読む 公式ドキュメントで明示される情報 + 公開 DNS 応答からの推測を含む 今日のテーマ 2
4. Azure PaaS の多くは 1 ホップでは終わらない CNAME チェーンに Azure の共通基盤が見える 代表例: trafficmanager.net : グローバル分散の気配 azurefd.net : Azure Front Door 配下の気配 cloudapp.azure.com : 計算基盤側の入口の気配 privatelink.* : Private Endpoint 化済み 先に結論 3
5. CNAME -> CNAME -> ... -> A チェーンを追う 途中の fqdn を読む 見方の基本 4
6. 例: myip.japaneast.cloudapp.azure.com 返ってくるのは基本的に A レコードだけ 「素の IP 直結」の世界 VM、VMSS、LB はこのタイプ 0. .<region>.cloudapp.azure.com Public IP Address リソースの既定ドメイン 5
7. 例: myapp.azurewebsites.net azurewebsites.windows.net 配下に多段 CNAME waws-prod-* （Web スペース）から、App Service のマルチテナント基盤が見える App Service Plan のリソースグループ・リージョン・OS が同じ -> 同じ Web スペースに配置 異なるリージョン OR 異なるリソースにある App Service Plan OR 異なる OS -> 異なる Web スペースに配置(かもしれない) 1. .azurewebsites.net App Service / Function App の既定ドメイン 6
8. 例: mystapp.0.azurestaticapps.net trafficmanager.net が先頭に見える: グローバル分散の入口 p.azurewebsites.net / azurewebsites.windows.net まで降りる: 実体は App Service 系基 盤に接続される 2. .azurestaticapps.net Azure Static Web App の既定ドメイン 7
9. 例: mystapp-entedge.1.azurestaticapps.net azurefd.net が見える: Enterprise Edge で Azure Front Door 経由になっている tm-azurefd.net は Front Door 側のルーティング/トラフィック制御レイヤー 先頭 FQDN に含まれる識別子は、環境/エンドポイントを一意に識別するための名前 最後の A はアプリ本体ではなく、まず Edge ノードへ到達するための IP 2. .azurestaticapps.net # Enterprise-grade Edge が有効の場合 8
10. 例: myapim-std-v1.azure-api.net trafficmanager.net が先頭: APIM 入口でグローバルなトラフィック分散を実施 regional.azure-api.net を経由: 利用リージョンの APIM エンドポイントへ誘導される 最終的に <region>.cloudapp.azure.com で解決: バックエンドは Azure 計算基盤上に ただしこれは V1 の話 3. .azure-api.net API Management の既定ドメイン 9
11. 例: myapim-std-v2.azure-api.net .azurewebsites.net が先頭: V2 は入口が App Service 系ホスティングに寄っている sip.azurewebsites.windows.net に続く: マルチテナントの App Service がフロント層 App Service 同様、別の APIM リソースと Web スペースが重なる可能性がある 最終的に <region>.cloudapp.azure.com で解決: 実体はリージョン内の計算基盤上に存 在 V1 のような trafficmanager.net / regional.azure-api.net が見えない点が差分 3. .azure-api.net # APIM V2 の場合 10
12. 例: myaiservice.cognitiveservices.azure.com cognitiveservices.azure.com から api.cognitive.microsoft.com へ: 各リージョンの Cognitive Services 系エンドポイント集約 trafficmanager.net を経由: リージョン/可用性を意識した分散ルーティングの層 azure-api.net が見える: API Management を経由してバックエンドへ到達 4. .cognitiveservices.azure.com Azure AI - .openai.azure.com や .services.ai.azure.com も同様 11
13. 例: mystorage.blob.core.windows.net *.store.core.windows.net が見えたら Storage フロントエンドの気配 最初のサブドメインは blob / file / queue / table で分かれる 次のサブドメインはリージョンやテナントで分かれる RA-GRS 構成では secondary endpoint も別名で存在 5. .blob.core.windows.net Blob Storage - Queue等も同様 12
14. 例: myapp.<env-id>.<region>.azurecontainerapps.io アプリのドメインは A レコード直結 実態は Environment 単位で決まっている その先でリビジョン/ルーティング制御 6. .<env-id>.<region>.azurecontainerapps.io Azure Container Apps 13
15. CNAME チェーンに privatelink.<service-domain> が入る VNet 内から名前解決すると、プライベート IP アドレスで解決される 例: App Service つまり「名前は同じ、答えだけ変わる」 余談. Private Endpoint を入れると何が変わるか 14
16. 名前解決は Azure PaaS のアーキを覗く観測窓 CNAME の suffix を追うだけで学びが増える 次にトラブルシュートするときも効く カスタムドメイン不通 Private Endpoint 切替ミス フェイルオーバー時の名前解決差分 まとめ 15
17. ブラウザ拡張機能、 使ってくれよな 最後に宣伝 Text Blurrer TweakIt for Microsoft Azure Portal Skip Video Ads 16