URI 와일드 카드

Google Cloud CLI에서는 파일, 버킷, 객체에 대해 URI 와일드 카드 사용이 지원됩니다. 와일드 카드를 사용하면 지정된 명명 패턴과 일치하는 파일 그룹에서 효율적으로 작업할 수 있습니다. 이 페이지에서는 지원되는 와일드 카드에 대해 설명하고 명령어에서 와일드 카드를 사용할 때 중요한 고려사항에 대해 설명합니다.

와일드 카드 문자

gcloud CLI는 다음과 같은 와일드 카드를 지원합니다.

문자 설명
* 현재 디렉터리 수준 내에서 하나 이상의 문자와 일치합니다. 예를 들어 cp gs://my-bucket/abc/d*abc/def.txt 객체와 일치하지만 abc/def/g.txt 객체와는 일치하지 않습니다. ls와 같은 명령어를 나열하는 경우 후행 *가 현재 디렉터리 수준의 하위 디렉터리와 일치하면 하위 디렉터리의 내용도 나열됩니다.
** 디렉터리 경계에서 0개 이상의 문자와 일치합니다. 로컬 파일 경로의 일부로 사용되는 경우 ** 와일드 카드는 항상 디렉터리 구분 기호 앞에 와야 합니다. 예를 들어 my-directory/**.txt은 유효하지만 my-directory/abc**는 그렇지 않습니다.
? 단일 문자와 일치합니다. 예를 들어 gs://bucket/??.txt는 정확하게 두 문자 다음에 .txt가 포함된 객체와만 일치합니다.
[CHARACTERS] 지정된 문자와 일치합니다. 예를 들어 gs://bucket/[aeiou].txt는 단일 모음 뒤에 .txt가 포함된 객체와 일치합니다.
[CHARACTER_RANGE] 문자 범위를 일치시킵니다. 예를 들어 gs://bucket/[a-e].txt는 문자 a, b, c, d, e 다음에 .txt가 포함된 객체와 일치합니다.

와일드 카드를 조합하여 더 강력한 일치 항목을 제공할 수 있습니다. 예를 들면 다음과 같습니다.

gs://*/[a-m]??.j*g

명령어의 결과에 이전 객체 버전을 반환하는 플래그가 포함되어 있지 않으면 이러한 와일드 카드는 라이브 객체 버전과만 일치합니다.

gcloud CLI는 객체 및 파일 이름 모두 동일한 와일드 카드를 지원합니다. 따라서 예를 들면 다음과 같습니다.

gcloud storage cp data/abc* gs://bucket

로컬 파일 시스템의 data 디렉터리에서 abc로 시작하는 모든 파일과 일치합니다.

동작 고려사항

와일드 카드를 사용하면 예기치 못한 동작이 발생할 수 있는 몇 가지 경우가 있습니다.

  • 버킷 이름에 와일드 카드를 사용할 경우 일치는 단일 프로젝트의 버킷으로 제한됩니다. 많은 명령어에서 플래그를 사용하여 프로젝트를 지정할 수 있습니다. 명령어에 프로젝트 플래그가 포함되지 않거나 프로젝트 플래그 사용이 지원되지 않으면 일치 항목이 기본 프로젝트의 버킷으로 제한됩니다.

  • bash 및 zsh와 같은 셸은 gcloud CLI에 인수를 전달하기 전에 와일드 카드를 확장하려고 할 수 있습니다. 와일드 카드가 클라우드 객체를 참조해야 하는 경우 '찾을 수 없음' 오류가 예기치 못하게 발생할 수 있습니다. 예를 들어 셸이 로컬 머신에서 와일드 카드 gs://my-bucket/*을 확장하려고 하면 일치하는 로컬 파일이 없어 명령어가 실패합니다.

    또한 일부 셸에는 와일드 카드 문자 집합의 다른 문자가 포함됩니다. 예를 들어 extendedglob 옵션을 사용 설정한 상태에서 zsh를 사용하는 경우 #을 특수문자로 취급하므로 버전 관리된 객체를 참조 시 해당 문자 사용과 충돌합니다(예시는 이전 객체 버전 복원 참조).

    이러한 문제를 방지하려면 와일드 카드 표현식을 작은 따옴표(Linux) 또는 큰 따옴표(Windows)로 입력합니다.

  • 명령줄 도구는 와일드 카드 문자를 리터럴 문자로 사용하는 대신 확장하려고 하므로 와일드 카드 문자가 포함된 파일 이름을 지정하려고 해도 작동하지 않습니다. 예를 들어 다음 명령어를 실행합니다.

    gcloud storage cp './file[1]' gs://my-bucket

    절대 file[1]이라는 로컬 파일을 복사하지 않습니다. 대신 gcloud CLI는 항상 [1]을 와일드 카드로 처리합니다.

    gcloud CLI는 와일드 카드 문자가 포함된 파일 이름을 사용하도록 허용하는 "원시" 모드를 지원하지 않습니다. 이러한 파일의 경우 Google Cloud 콘솔과 같은 다른 도구를 사용하거나 와일드 카드를 사용하여 파일을 캡처해야 합니다. 예를 들어 file[1]이라는 파일을 캡처하려면 다음 명령어를 사용하면 됩니다.

    gcloud storage cp './file*1*' gs://my-bucket
  • 표준 Unix 동작마다 와일드 카드 *. 문자로 시작하지 않는 파일과만 일치합니다(모든 Unix 디렉터리에 있는 ... 디렉터리와의 혼동을 방지하기 위함). gcloud CLI는 파일 시스템 URI에서 와일드 카드를 사용할 때와 동일한 동작을 제공하지만 클라우드 URI에서는 이 동작을 제공하지 않습니다. 예를 들어 다음 명령어는 gs://bucket1~gs://bucket2의 모든 객체를 복사합니다.

    gcloud storage cp gs://bucket1/* gs://bucket2

    그러나 다음 명령어는 .로 시작하지 않는 파일만 dir 디렉터리에서 gs://bucket1으로 복사합니다.

    gcloud storage cp dir/* gs://bucket1

효율성 고려사항

  • 와일드 카드가 아닌 객체 이름 프리픽스가 있는 다음과 같은 와일드 카드를 사용하는 경우 보다 효율적이고, 빠르며, 네트워크 트래픽도 줄어듭니다. 예를 들면 다음과 같습니다.

    gs://bucket/abc*.txt

    와일드 카드를 객체 이름의 첫 번째 부분으로 사용하면 다음과 같습니다.

    gs://bucket/*abc.txt

    이는 gs://bucket/abc*.txt 요청이 버킷 루트에서 객체 이름이 abc로 시작하는 결과의 하위 집합을 서버에 전송하도록 요청한 후 .txt로 끝나는 객체의 결과 목록을 필터링하기 때문입니다. 반대로 gs://bucket/*abc.txt는 서버에 버킷 루트의 전체 객체 목록을 요청한 다음 이름이 abc.txt로 끝나는 객체를 필터링합니다. 이러한 효율성 고려사항은 수천 개 이상의 객체가 포함된 버킷을 사용할 때 더욱 두드러집니다. 서버 측 프리픽스 요청의 효율성을 활용하기 위해 예상되는 와일드 카드 일치 패턴에 맞게 객체 이름을 설정할 수도 있습니다.

  • 다음 객체가 포함된 버킷이 있다고 가정해 보겠습니다.

    gs://bucket/obj1
    gs://bucket/obj2
    gs://bucket/obj3
    gs://bucket/obj4
    gs://bucket/dir1/obj5
    gs://bucket/dir2/obj6

    다음 명령어를 실행합니다.

    gcloud storage ls gs://bucket/*/obj5

    그러면 gcloud storage/로 구분된 최상위 버킷 목록을 수행한 다음 하위 디렉터리당 하나의 버킷 목록을 수행하여 총 3개의 버킷 목록을 만듭니다.

    GET /bucket/?delimiter=/
    GET /bucket/?prefix=dir1/obj5&delimiter=/
    GET /bucket/?prefix=dir2/obj5&delimiter=/
    

    와일드 카드가 필요한 버킷 수가 많을수록 속도가 더 높아지고 비용이 더 많이 듭니다. 필요한 버킷 목록 수는 다음과 같이 증가합니다.

    • 와일드 카드 구성요소의 수(예: gs://bucket/a??b/c*/*/d에는 와일드 카드 구성요소 3개가 있음)

    • 각 구성요소와 일치하는 하위 디렉터리의 수

    • 결과 수(결과 수가 너무 많으면 페이지 나누기를 구현하고 각 항목에 마커 지정)

    중간 경로 와일드 카드를 사용하려는 경우 재귀 와일드 카드를 대신 사용할 수도 있습니다. 예를 들면 다음과 같습니다.

    gcloud storage ls gs://bucket/**/obj5

    이는 디렉터리를 포괄하므로 gs://bucket/*/obj5보다 많은 객체와 일치하지만, 구분 기호가 없는 버킷 나열 요청을 사용하여 구현됩니다. 즉, 더 적은 버킷 요청을 의미하나 전체 버킷과 필터를 로컬에서 나열하므로 상당한 네트워크 트래픽을 유발합니다.