まとめ
- 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で表現できない全角文字のリソースグループ名(ふがふが)が入ってるからでは…?
もしこの読みが正しいなら、
リソースグループ名を英数字に変えたらうまくいくんじゃね…?
できちゃったねえ…
お気持ち
実際のところリソースグループ名に使える文字に制限はあるのだろうか。
公式ドキュメントを漁って調べてみた。
Azure リソースの名前付け規則と制限事項によると、
一応リソースグループ名に使用できる文字は
アンダースコア、ハイフン、ピリオド、括弧と、Char.IsLetterOrDigit関数で定義されている文字または数字。
となっているので、おそらくちゃんと読まずに日本語でふざけたリソースグループ名をつけた俺が100%悪い。
…が、ちょっともやもやするのはリソースグループ作成時に普通にマルチバイト文字が指定できちゃうこと。
リソースグループ名の入力時と作成前の検証ステップで何も怒ってくれないのはどうなんだろう…?
バリデーションは機能しているのだろうか…?
おわり
Azure初心者すぎてこんなところでコケてそこそこの時間を無駄にしてしまったので、
戒めとして書いてみた。
もちろんちゃんとルールを把握せず雰囲気で触った俺が100%悪いんだけど、
システムを壊すような操作はそもそもバリデーション等でユーザーがいじれないようにするべきだと思っているのでやっぱりもやもやする。
Azureとは仲良くなれなさそうだな…
おまけ
