Azureのリソースグループ名に日本語を使うのはやめよう

2023-12-12

まとめ

Azureのリソースグループ名に日本語(英数字以外の文字)を使用するとAzure内部での一部API呼び出し時にエラーが発生する
ASCIIで表記できる文字(英数字と簡単な記号だけ)を使おう

経緯

Azure Data Factoryを試したくてリソースを作成していたときのこと。

Azure Data Factory 用の Azure Private Linkを参考に、
同時にプライベートエンドポイントを作成しようとした。

各項目の設定はほぼデフォルトで、問題なくデプロイが開始した…と思ったら、
Data Factory自体のデプロイはできたもののプライベートエンドポイントの作成がコケてしまった。

なにいってだこいつ…

俺は愚かなお猿さんなので、
これを一時的なエラーと決めつけて脳死で再試行を10回程度繰り返したが、
一度も成功することはなかった…

~~〜fin〜~~

原因調査

俺は人類の誇りを取り戻し、
おとなしくエラーの内容を読むことにした。

表示されたエラーはこんな感じ。

{
    "code":"DeploymentFailed",
    "target":"/subscriptions/xxxxxxxxxxxxxxxxxxxxx/resourceGroups/ふがふが/providers/Microsoft.Resources/deployments/Microsoft.DataFactory-20231212010148",
    "message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
    "details":[
        {
            "code":"ResourceDeploymentFailure",
            "target":"/subscriptions/xxxxxxxxxxxxxxxxxxxxx/resourceGroups/ふがふが/providers/Microsoft.Resources/deployments/deployPrivateEndpoint-fugafuga-df-01-private-endpoint",
            "message":"The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."
        }
    ]
}

Call to Microsoft.DataFactory/factories failed. Error message: The request URI ‘https://management.azure.com:443/subscriptions/xxxxxxxxxxxxxxxxxxxxx/resourcegroups/%25E3%2581%25B5%25E3%2581%258C%25E3%2581%25B5%25E3%2581%258C/providers/Microsoft.DataFactory/factories/fugafuga-df-01/privateEndpointConnectionProxies/fugafuga-df-01-private-endpoint.f596276c-4285-425c-9019-b5553ce6006e/operationstatuses/da7d1374-a224-428c-a13e-81c969ac4fa6?api-version=2018-06-01' is not valid, because it contains double encoding sequence ‘%25’. (コード: InvalidDoubleEncodedRequestUri)

重要そうなのは2つ目のエラー文のInvalidDoubleEncodedRequestUriの部分。
なんかデプロイ時に内部で叩かれてそうなAPIのURLに%25が含まれているのが問題と言われている(気がする)。

ここで怒られているURLをJSONのエラーメッセージに含まれるURLと比較すると、
%25E3%2581%25B5%25E3%2581%258C%25E3%2581%25B5%25E3%2581%258Cとふがふがの部分が対応してそうというか、
ふがふががURLエンコードされたものがそれっぽい。

実際に試してみると、ふがふがを2回エンコードしたものがまさに一致した。

# jqでURLエンコード
$ echo 'ふがふが' | jq -Rr @uri
%E3%81%B5%E3%81%8C%E3%81%B5%E3%81%8C

# 2回エンコードしたら'%25'を含むエラーメッセージのURLと同じものが出てきた
$ echo '%E3%81%B5%E3%81%8C%E3%81%B5%E3%81%8C' | jq -Rr @uri
%25E3%2581%25B5%25E3%2581%258C%25E3%2581%25B5%25E3%2581%258C

エラーの名前的にもこいつが原因と見て間違いなさそう。
(エラー名もInvalidDoubleEncodedRequestUri:リクエストURIの不正な二重エンコード(意訳)だし)

じゃあこのふがふがはどこからきているのかというと、
リソース作成時に指定するリソースグループの名前だった。

つまり…
リソースグループ名にマルチバイト文字を使用していると、
それがAPIのURLにエンコードされた時にエラーが発生する
…ってコト!?

修正

ならリソースグループ名がURLエンコードが発生しない文字、
すなわち半角英数ならいいんじゃね？

できちゃったねぇ…

というわけで、
Azureのリソースグループ名に全角文字を使うのはやめようと心に誓った。

他のケース

上記の例はかなりわかりやすかったが、
他のところでも全角文字が原因でData Factoryがうまく動かないことがあった。
(というか、本当のところはプライベートエンドポイントではなくこっちでめちゃめちゃ時間消費してこの問題に気づいた)

問題が起きたのはAzure Data Factory または Azure Synapse Analytics を使用して Azure Blob Storage のデータをコピーし変換するなどを参考にAzure Blob Storage上のExcelデータをData Factoryで整形するフローを作っていた時のこと。

Azure Blob Storage上のExcelをデータセットとして参照できる状態で、
それをデータフローのソースとして参照すると接続時にエラーが発生してしまった。

Request headers must contain only ASCII characters. - RunId: 69672633-6312-4832-95fc-90a3d2b54678

なにいってだこいつ…
他にエラーログが出ていないのでこのメッセージしかヒントにならないが、
どうやら文字コードで怒られている様子。

一瞬Excelのデータに全角文字列があるから…? と思ったが、
.xlsx形式で保存するときは文字コード選べないし、
そもそもデータセットとして.xlsxが参照できるようになっている時点でデータ中身の文字コードが原因とは考えづらい。
(実際.xlsx内の文字列を英数のみに替えたり、UTF-8で.csvとして出力したファイルに変えても変わらなかった)

リクエストヘッダがどうとか言ってるし、
これも内部で叩こうとしてるアクセス先(Azure Blob Storage)のURLにASCIIで表現できない全角文字のリソースグループ名(ふがふが)が入ってるからでは…?