본 문서의 저작권은 텐센트 클라우드(Tencent Cloud)에 단독으로 귀속됩니다. 텐센트 클라우드의 사전 서면 승인 없이는 어떠한 주체도 본 문서 내용의 전부 또는 일부를 복제·수정·표절·전송하는 등 어떠한 형태로도 이용할 수 없습니다.
상표 고지
텐센트 클라우드(Tencent Cloud) 및 관련 서비스의 모든 상표는 텐센트(Tencent) 그룹 산하 법인들(모회사, 자회사 및 계열사 포함)이 소유합니다. 본 문서에 언급된 제3자 상표는 해당 법적 권리자가 소유합니다.
서비스 고지
본 문서는 고객에게 텐센트 클라우드(Tencent Cloud) 제품 및 서비스 전부 또는 일부에 대한 현재적 개괄적 정보를 제공 하기 위한 것으로, 특정 제품·서비스의 내용은 수시로 변경될 수 있습니다. 고객이 실제 구매한 제품·서비스의 적용 기준은 고객과 텐센트 클라우드간 체결된 상업계약에 명시된 내용이 우선하며, 별도 서면 합의가 없는 한 텐센트 클라우드는 본 문서 내용에 대해 법적 효력이 있는 명시적·묵시적 진술이나 보증을 일체 하지 않습니다.
Tencent Cloud COS는 HTTP/HTTPS 프로토콜을 사용해 액세스하는 Web 스토리지 서비스입니다. REST API 또는 COS SDK를 사용해 COS에 액세스할 수 있습니다.
COS 액세스 요청 실행 시, COS 인증을 거쳐야만 리소스 작업이 가능합니다. 따라서 신분 식별 가능 여부에 근거하여, COS 액세스 요청은 익명 요청과 서명 요청의 2가지 유형으로 나뉩니다.
익명 요청: Authorization 또는 관련 매개변수를 가지고 있지 않거나, 관련 문자가 사용자의 신분 특징을 식별할 수 없는 경우, 익명 요청으로 간주되어 인증을 진행합니다.
서명 요청: 서명된 요청은 HTTP 헤더 또는 요청 패킷에 Authorization 필드가 포함돼야 합니다. 해당 필드의 콘텐츠는 Tencent Cloud의 보안 자격 증명 SecretID, SecretKey 및 요청된 일부 특징 값을 결합한 것이며, 암호화 알고리즘으로 생성됩니다.
COS SDK 호출을 사용할 경우 보안 자격 증명만 설정하면 요청을 발송할 수 있습니다. REST API 호출을 사용할 경우 서명 요청 문서를 참고하여 직접 요청 서명을 계산해야 합니다.
보안 자격 증명 얻기
CAM은 COS에 계정 및 보안 자격 증명 관련 기능과 서비스를 제공합니다. 주로 Tencent Cloud 계정에 있는 리소스의 액세스 권한을 안전하게 관리할 수 있도록 지원합니다. 사용자는 CAM을 통해 사용자(그룹)를 생성, 관리, 폐기할 수 있고 신분 관리 및 정책 관리를 사용해 기타 사용자의 Tencent Cloud 리소스 사용 권한을 제어할 수 있습니다.
루트 계정의 보안 자격 증명
루트 계정 로그인 후, CAM의 Tencent Cloud API 키 페이지를 통해 루트 계정 보안 자격 증명 SecretID와 SecretKey를 관리하고 얻을 수 있습니다. 다음은 한 그룹 키의 예시입니다.
36개 문자로 된 액세스 키 ID(SecretID): ************************************
32개 문자로 된 액세스 키(SecretKey): ********************************
액세스 키는 고유한 계정을 표시하는 데 사용할 수 있습니다. 키 서명을 사용하여 요청을 보내면 Tencent Cloud는 요청 실행자의 신분을 식별하고 인증한 후, 신분, 리소스, 작업, 조건 등 인증을 거쳐 이 작업 실행을 허가할지 여부를 판단합니다.
주의：
루트 계정 키는 그에 속한 모든 리소스의 모든 조작 권한을 가지고 있습니다. 키가 유출되면 클라우드 리소스 손실 가능성이 있으므로, 서브 계정을 생성하고 적절히 권한을 할당할 것을 강력히 권장합니다. 서브 계정의 키 생성을 요청하여 리소스에 액세스 및 관리하십시오.
서브 계정의 보안 자격 증명
사용자 및 클라우드 리소스를 다각도로 관리해야 하는 경우, 루트 계정에 속한 여러 개의 서브 계정을 생성한 후 리소스 권한을 여러 계정이 나누어 관리하도록 할 수 있습니다. 서브 계정 생성에 대한 자세한 내용은 CAM의 사용자 관리 관련 문서를 참고하십시오.
서브 계정을 사용한 API 요청 발송 전, 서브 계정을 위한 보안 자격 증명을 생성해야 하며, 서브 계정도 신분 식별을 위해 고유한 키 쌍을 가지고 있어야 합니다. 각 서브 계정의 사용자 정책을 작성하면 리소스에 대한 각 계정의 액세스 권한을 제어할 수 있습니다. 또한 사용자 그룹을 생성하고 사용자 그룹에 통일된 액세스 정책을 추가하면 인원 그룹별 및 리소스에 대한 통합 관리가 가능합니다.
주의：
서브 계정은 해당 권한을 할당 받은 후, 리소스를 생성 또는 수정할 수 있습니다. 이 경우 리소스는 여전히 루트 계정에 속하며, 해당 리소스에서 발생하는 비용 역시 루트 계정이 지불합니다.
임시 보안 자격 증명
루트 계정 또는 서브 계정의 보안 자격 증명을 통한 리소스 액세스 외에도 Tencent Cloud는 역할 생성을 지원하고, 임시 보안 자격 증명을 사용하여 Tencent Cloud 리소스를 관리합니다. 역할 관련 기본 개념 및 사용 방법은 CAM의 역할 관리 문서를 참고하십시오.
역할은 가상 신분이기 때문에 영구적인 키를 가지고 있지 않으므로 Tencent Cloud의 CAM은 임시 보안 자격 증명을 생성하기 위한 STS API를 제공합니다.
사용 방법과 세부 예시는 Using Role 문서나 CreateRole 문서에서 임시 보안 자격 증명 생성 방식을 참고하십시오. 임시 보안 자격 증명에는 보통 정책 제한(작업, 리소스, 조건) 및 시간 제한(시작 및 종료 유효 시간)만 포함되므로, 생성된 임시 보안 자격 증명은 자체 배포하거나 직접 사용할 수 있습니다.
임시 보안 자격 증명을 생성하는 인터페이스를 호출하면 한 쌍의 임시 키(tmpSecretId/tmpSecretKey)와 보안 토큰(sessionToken)을 획득하게 되며, 이는 COS에 액세스하는 데 사용하는 보안 자격 증명을 구성합니다. 예시는 다음과 같습니다.
41개 문자로 된 보안 토큰(SecurityToken): *****************************************
36개 문자로 된 임시 액세스 키 ID(SecretID): ************************************
32개 문자로 된 임시 액세스 키(SecretKey): ********************************
해당 인터페이스는 또한 expiration 필드를 통해 임시 보안 자격 증명의 유효 시간을 반환하는데, 이는 이 시간 내에 해당 보안 자격 증명을 사용해야만 요청을 실행할 수 있음을 의미합니다.
Tencent Cloud COS는 임시 키 생성에 사용되는 간단한 서버 SDK를 제공하며, COS STS SDK에 액세스하여 획득할 수 있습니다. 임시 보안 자격 증명을 받은 후 REST API를 사용하여 요청을 발송하려면 HTTP 헤더 또는 POST 요청 패킷의 form-data에 x-cos-security-token 필드를 전송하여 해당 요청에 사용한 보안 토큰을 표시한 한 후, 임시 액세스 키 쌍을 사용하여 요청 서명을 계산해야 합니다. COS SDK를 사용한 액세스 실행은 각 SDK 문서의 관련 부분을 참고하십시오.
도메인 이름 액세스
REST API
리전 및 액세스 도메인 문서에 REST API 호출 실행에 사용하는 리전 리스트가 나열되어 있습니다.
COS는 가상 호스팅형 도메인을 사용하여 버킷에 액세스하는 것을 권장합니다. HTTP 요청 실행 시 <BucketName-APPID>.cos.<Region>.myqcloud.com과 같이 직접 Host 헤더를 통해 액세스해야 하는 버킷을 가져옵니다. 가상 호스팅형 도메인을 사용해 가상 서버의 [루트 디렉터리]와 유사한 기능을 구현하며, favicon.ico, robots.txt, crossdomain.xml과 같은 파일을 호스팅하는 데 사용할 수 있습니다. 이 파일들은 여러 응용 프로그램이 호스팅 웹 사이트를 식별할 때 기본적으로 가상 서버의 [루트 디렉터리]에서 콘텐츠를 인덱스합니다.
경로형 요청을 통해 버킷에 액세스할 수도 있습니다. 예를 들어, cos.<region>.myqcloud.com/<BucketName-APPID>/의 경로를 사용하여 버킷에 액세스할 수 있습니다. 이와 마찬가지로, Host와 서명 요청은 cos.<region>.myqcloud.com을 사용해야 하며, SDK는 기본적으로 해당 액세스 방식을 지원하지 않습니다.
정적 웹 사이트 도메인
버킷의 정적 웹 사이트 기능 활성화 시, 관련 기능을 사용할 수 있도록 가상 호스팅형 도메인을 할당합니다. 정적 웹 사이트 도메인의 성능은 REST API와 다릅니다. 정적 웹 사이트 도메인은 특정 인덱스 페이지, 오류 페이지 및 리디렉션 설정을 제외하고 GET/HEAD/OPTIONS Object 등 몇 가지 작업만 지원하며, 업로드 또는 리소스 설정 작업은 지원하지 않습니다.
정적 웹 사이트 도메인 예시로는 <BucketName-APPID>.cos-website.<Region>.myqcloud.com가 있고, 콘솔의 버킷 [기본 설정 - 정적 웹 사이트 설정] 모듈을 통해 이 도메인을 얻을 수 있습니다.
사설망 액세스
Tencent Cloud COS의 액세스 도메인은 스마트 DNS 레졸루션을 사용하여 각 통신사 환경의 인터넷에서 COS 액세스를 검증하고 최적의 링크를 제공합니다.
Tencent Cloud에서 배포한 CVM 서비스가 사설망에서 COS에 액세스하려면, 먼저 CVM과 COS 버킷이 동일한 리전에 속하는지 확인한 후 CVM에서 nslookup 명령을 사용하여 COS 도메인 이름을 해석해야 합니다. 내부 IP가 반환되면 CVM과 COS 간에 사설망 액세스를 나타내고, 그렇지 않으면 공중망 액세스를 나타냅니다.
Tencent Cloud에서 배포한 CVM 서비스의 리전이 COS 버킷이 속한 리전과 다르지만, COS 사용 가능 리전 범위 내에 있는 경우, COS 사설망 전역 가속 도메인 이름을 통해 파일에 액세스하여 CVM과 COS의 리전 간 액세스를 구현할 수 있습니다.
사설망 액세스 판단 방법
동일한 리전 내의 Tencent Cloud 제품은 사설망을 통해 서로 액세스할 수 있으므로 트래픽 비용이 발생하지 않습니다. 따라서 비용을 절약하기 위해 다른 Tencent Cloud 제품을 구매할 때 동일한 리전을 선택하는 것이 좋습니다.
주의：
퍼블릭 클라우드 리전의 사설망은 금융 클라우드 리전의 사설망과 상호 연결되지 않습니다.
다음은 사설망을 통한 액세스를 확인하는 방법입니다.
Tencent CVM을 통한 COS 액세스의 경우, 내부 인터넷을 이용하여 COS에 액세스했는지 판단하려면, CVM에서 nslookup 명령어를 사용하여 COS 도메인을 해석할 수 있습니다. 내부 IP를 반환한다면 CVM과 COS 간 사설망으로 액세스한 것이고, 아니라면 공중망으로 액세스한 것입니다.
설명：
내부 IP 주소는 일반적으로 10.*.*.*, 100.*.*.* 형식이며, VPC 네트워크는 일반적으로 169.254.*.* 등의 형식입니다. 해당 두 가지 형식의 IP는 사설망에 속합니다.
examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com이 타깃 버킷 주소라고 가정하면, nslookup 명령어 실행 후 다음과 같은 정보를 확인할 수 있습니다.
여기서 10.148.214.13와 10.148.214.14의 두 IP는 사설망을 통해 COS에 액세스했음을 의미합니다.
연결성 테스트
기본 연결 테스트
COS는 HTTP 프로토콜을 사용하여 외부로 서비스를 제공합니다. 가장 기본적인 telnet 툴로 COS 액세스 도메인의 80 포트에 대해 액세스 테스트를 실행할 수 있습니다.
액세스 환경에 관계 없이, 명령어가 Escape character is '^]'. 필드를 반환한다면 연결에 성공했음을 의미합니다.
인터넷 테스트를 통한 설명
인터넷을 통해 COS에 액세스하면 ISP 네트워크를 거치게 됩니다. ISP 네트워크는 ICMP 프로토콜의 ping 또는 traceroute 등 툴을 사용한 연결성 테스트를 허용하지 않습니다. 따라서 TCP 프로토콜의 툴을 사용한 연결성 테스트를 권장합니다.
주의：
인터넷을 통해 액세스하면 다양한 인터넷 환경의 영향을 받을 수 있습니다. 만약 액세스가 원활하지 못하다면, 로컬 네트워크 링크를 진단하거나 로컬 통신사에 연락하여 피드백을 받으십시오.
ISP가 ICMP 프로토콜을 허용하는 경우 ping, traceroute 또는 mtr 툴을 사용해 링크 상황을 검사할 수 있습니다. ISP가 ICMP 프로토콜을 허용하지 않을 경우 psping(Windows 환경, Microsoft 공식 홈페이지에서 다운로드) 또는 tcping(크로스 플랫폼 소프트웨어) 등의 툴을 사용해 딜레이 시간을 테스트할 수 있습니다.
사설망 테스트 설명
같은 리전 내 Tencent Cloud VPC 네트워크를 통해 객체 스토리지 COS에 액세스하면, ICMP 프로토콜의 ping 또는 traceroute 등 툴을 사용하여 연결성을 테스트할 수 없습니다. 기본 연결 테스트 중 telnet 명령어를 사용하여 테스트를 진행할 것을 권장합니다.
psping 또는 tcping 등의 툴을 사용하여 직접 액세스 도메인의 80 포트에 대한 딜레이 시간 테스트를 시도해 볼 수도 있습니다. 테스트 전, nslookup 명령어를 통해 액세스 도메인이 사설망 주소에 정확하게 해석되었는지 조회 및 확인하십시오.
버킷
버킷 개요
최종 업데이트 날짜:：2025-10-11 17:41:47
소개
버킷(Bucket)은 객체를 저장하는 ‘컨테이너’로 이해할 수 있으며, 이 ‘컨테이너’는 용량의 상한이 없습니다. 객체는 폴더와 디렉터리의 개념이 없는 평면 구조의 버킷에 저장됩니다. 하나 또는 여러 버킷에 객체를 저장하도록 선택할 수 있습니다.
설명：
버킷은 객체를 얼마든지 포함할 수 있지만 하나의 루트 계정은 최대 200개의 버킷만 생성할 수 있습니다.
버킷 이름 생성 규칙
버킷 이름은 하이픈 ‘-’으로 연결된 버킷 이름(BucketName)과 APPID로 구성됩니다. 버킷의 명명 형식은 <BucketName-APPID>입니다.
버킷 이름(BucketName): 사용자가 수동으로 입력한 문자열로, 명명 규칙은 다음과 같습니다:
알파벳 소문자와 숫자 [a-z, 0-9], 하이픈 '-' 및 그 조합만 지원합니다.
버킷 이름에 포함될 수 있는 문자 수는 리전 약칭 및 APPID의 길이로 제한됩니다. 결합된 도메인 이름은 최대 60자까지 가능합니다. 예를 들어 도메인 이름 123456789012345678901-1250000000.cos.ap-beijing.myqcloud.com은 60자를 포함합니다.
버킷 이름 생성 시, '-'으로 시작하거나 끝날 수 없습니다.
APPID: Tencent Cloud를 성공적으로 가입한 후 얻은 계정으로, 시스템에서 자동으로 할당되며 고정적이고 전역적으로 고유합니다. 계정 정보에서 확인할 수 있습니다. 콘솔에서 버킷을 생성할 때는 사용자 입력이 필요하지 않지만, 도구, API, SDK를 사용할 때는 APPID를 지정해야 합니다.
명명 예시
예를 들어 버킷 examplebucket-1250000000에서 examplebucket은 BucketName(사용자가 수동으로 입력한 문자열)이고, 1250000000은 APPID(사용자가 Tencent Cloud를 가입할 때 시스템에서 자동으로 할당)입니다.
아래는 효율적인 버킷 이름 생성 예시입니다.
examplebucket-1-1250000000
mybucket123-1250000000
1-newproject-1250000000
버킷 소속 리전
리전(Region)은 객체 스토리지 COS의 데이터센터가 있는 지역을 의미합니다. 객체 스토리지는 사용자가 다른 리전에 버킷을 생성하는 것을 허용합니다. 업무 지역에서 가장 가까운 리전을 선택하고 버킷을 생성함으로써, 딜레이와 비용을 줄일 수 있고 컴플라이언스 기준을 충족할 수 있습니다.
예를 들어, 업무가 화난 지역에 분포되어 있는 경우 광저우 리전을 선택해 버킷을 생성하면 객체의 업로드 및 다운로드 속도를 향상시킬 수 있습니다. 리전에 관한 자세한 내용은 리전 및 액세스 도메인 문서를 참고하십시오.
주의：
리전은 버킷 생성 시 반드시 지정해야 하며, 지정 후 변경할 수 없습니다. 해당 버킷의 모든 객체는 상응하는 데이터센터에 저장되며, 객체 레벨별 리전 설정은 아직 지원하지 않습니다.
버킷 권한 유형
버킷은 기본적으로 공개 권한과 사용자 권한의 두 가지 권한을 제공합니다.
설명：
버킷이 개인 읽기/쓰기이거나 지정된 계정에 사용자 권한이 부여된 경우 객체 요청 시 본인 확인을 위해 서명이 필요하며 서명 방법은 Request Signature를 참고하십시오.
버킷이 공개 읽기/개인 쓰기 또는 공개 읽기/쓰기인 경우 객체 요청 시 서명이 필요하지 않아, 익명 사용자가 링크를 통해 객체에 직접 액세스할 수 있는 리스크가 있습니다. 데이터가 유출될 리스크가 있으니 신중하게 설정하십시오.
공개 권한
공개 권한에는 개인 읽기/쓰기, 공개 읽기/개인 쓰기 및 공개 읽기/쓰기가 포함됩니다. COS 콘솔에서 버킷의 권한 관리에서 버킷 액세스 권한을 수정할 수 있습니다. 자세한 내용은 액세스 제어 기본 개념을 참고하십시오.
개인 읽기/쓰기
해당 버킷의 생성자 및 권한 보유 계정만 해당 버킷에 있는 객체에 대한 읽기/쓰기 권한을 가지며, 그 외 사용자는 해당 버킷에 있는 객체에 대한 읽기/쓰기 권한이 없습니다. 버킷 액세스의 기본 권한은 개인 읽기/쓰기이므로 사용을 권장합니다.
공개 읽기와 개인 쓰기
익명 방문자를 포함해 누구나 해당 버킷의 객체에 대한 읽기 권한을 가지지만, 해당 버킷의 객체에 대한 쓰기 권한은 버킷 생성자 및 권한 보유 계정만이 가집니다.
공개 읽기/쓰기
익명 방문자를 포함해 누구나 해당 버킷의 객체에 대한 읽기/쓰기 권한을 가지므로 사용을 권장하지 않습니다.
사용자 권한
루트 계정은 기본적으로 버킷에 대한 모든 권한 즉, 전체 제어 권한을 갖습니다. 그 외에, COS는 서브 계정을 추가 생성하여 데이터 읽기/쓰기, 권한 읽기/쓰기, 심지어 완전 통제 가능한 최고 권한을 갖도록 지원합니다.
사용 방법
콘솔을 통해 버킷 개요 확인하기
설명：
서브 계정으로 데이터 개요를 조회할 수 없을 경우, 루트 계정 관리자에게 GetBucket 권한 부여를 문의하십시오.
3. 이동한 페이지에서 왼쪽 상단의 개요를 클릭하여 현재 버킷의 개요 페이지로 이동합니다.
사용량 개요
사용량 개요에는 현재 버킷의 객체 수, 파일 조각 수, 저장 용량, 트래픽 및 요청 수가 포함되어 있습니다.
주의：
사용량 개요는 실시간 데이터가 아니며, 약 2시간의 딜레이가 있습니다. 해당 데이터는 참고용 모니터링 데이터이며, 정확한 과금 계산 데이터는 과금 센터에서 사용량 명세서를 다운로드하여 확인할 수 있습니다.
객체 수/파일 조각 수: 각종 스토리지 유형의 객체 수 및 파일 조각 수를 확인할 수 있습니다.
스토리지 용량: 스토리지 유형별 사용량을 확인할 수 있습니다. 현재 확인 가능한 스토리지 유형은 STANDARD, MAZ_STANDARD, STANDARD_IA, MAZ_STANDARD_IA, ARCHIVE, MAZ_ARCHIVE, DEEP ARCHIVE, INTELLIGENT TIERING, MAZ_INTELLIGENT TIERING입니다.
주의：
MAZ_STANDARD, MAZ_STANDARD_IA, MAZ_ARCHIVE, DEEP ARCHIVE, INTELLIGENT TIERING, MAZ_INTELLIGENT TIERING은 특정 리전의 버킷만 지원하며, 지원되는 리전은 스토리지 유형 소개에서 확인할 수 있습니다.
트래픽: 스토리지 유형별로 이번 달 총 트래픽, 이번 달 공중망 다운스트림 트래픽, 이번 달 사설망 다운스트림 트래픽, 이번 달 CDN Origin-pull 트래픽, 이번 달 글로벌 가속 다운스트림 트래픽을 확인할 수 있습니다. 현재 확인 가능한 스토리지 유형은 STANDARD, MAZ_STANDARD, STANDARD_IA, MAZ_STANDARD_IA, INTELLIGENT TIERING, MAZ_INTELLIGENT TIERING입니다.
요청 수: 각종 스토리지 유형의 당월 총 요청수, 당월 읽기 요청 수, 당월 쓰기 요청 수를 확인할 수 있습니다.
검색량: STANDARD IA, ARCHIVE 유형의 데이터 검색량을 확인할 수 있습니다.
기본 정보
기본 정보에는 버킷 이름, 리전, 생성 시간, 액세스 권한 등이 포함되어 있습니다.
버킷 이름: 사용자 정의한 이름과 APPID로 구성되어 있으며, 이름 생성에 대한 자세한 설명은 이름 생성 규칙을 참고하십시오.
소속 리전: 버킷이 존재하는 리전
생성 시간: 버킷의 생성 시간
액세스 권한: 현재 버킷의 액세스 권한으로, 권한에 대한 자세한 내용은 버킷 액세스 권한을 참고하십시오.
도메인 정보
도메인 정보에는 현재 버킷에 설정된 모든 도메인이 표시됩니다.
액세스 도메인: COS 버킷 내 데이터에 액세스에 사용하는 기본 도메인으로, 버킷 생성 시 시스템이 버킷 이름 및 리전에 따라 자동으로 생성합니다.
주의：
기본 도메인 이름은 보안 위험이 있으며 민감한 정보가 노출될 수 있으므로 버킷에 사용자 정의 도메인 이름을 설정할 것을 권장합니다. 자세한 내용은 버킷 사용자 정의 도메인 이름 전환을 참고하십시오.
기본 CDN 가속 도메인 이름: CDN을 통한 가속 노드의 도메인 이름은 기본적으로 시스템에서 생성되며 사용자가 직접 구성할 수 있습니다. 사용자가 이전에 활성화한 경우 이 항목이 표시됩니다. 자세한 내용은 기본 CDN 가속 도메인을 참고하십시오.
사용자 정의 CDN 가속 도메인: 버킷에 ICP비안을 통과한 사용자 정의 도메인을 Tencent Cloud 중국 내 CDN 가속 플랫폼으로 바인딩할 수 있으며, 사용자 정의 도메인을 통해 버킷에 있는 객체에 액세스합니다.
사용자 정의 원본 서버 도메인: ICP비안을 통과한 사용자 정의 도메인을 현재 버킷에 바인딩할 수 있으며, 사용자 정의 도메인을 통해 버킷에 있는 객체에 액세스합니다.
글로벌 가속 도메인: 글로벌 가속을 활성화하면 시스템에서 기본적으로 글로벌 가속 도메인을 생성합니다. 사용자는 해당 도메인을 통해 데이터를 버킷에 업로드할 수 있으며, 글로벌 가속에 대한 자세한 내용은 글로벌 가속 개요를 참고하십시오.
정적 웹 사이트 도메인: 정정 웹사이트를 설정한 버킷은 정적 웹사이트를 통해 버킷 데이터에 액세스할 수 있습니다. 정적 웹사이트 설정에 대한 자세한 내용은 정적 웹사이트 설정을 참고하십시오.
버킷 설정
버킷 설정에는 버킷 관련 설정 상태 정보가 표시됩니다.
다중AZ 기능: 다중AZ 스토리지 아키텍처는 사용자 데이터에 대한 데이터 센터 수준의 재해 복구 기능을 제공할 수 있습니다. 자세한 내용은 다중 AZ(MAZ) 기능 개요를 참고하십시오.
메타데이터 가속: Tencent Cloud COS(Cloud Object Storage) 서비스에서 제공하는 고성능 파일 시스템 기능입니다. 자세한 내용은 메타데이터 가속 기능 개요를 참고하십시오.
크로스 도메인 액세스: 크로스 도메인은 HTTP 요청을 통해 도메인에서 다른 도메인으로 리소스를 요청하는 것을 의미합니다. 프로토콜, 도메인, 포트 중 하나라도 다른 경우 모두 다른 도메인으로 인식합니다. 자세한 내용은 CORS 설정을 참고하십시오.
버전 제어: 버킷 버전 제어 기능을 활성화하면 COS에서 동일한 이름의 객체 여러 버전을 저장하며, 이는 사용자가 잘못 삭제하였거나 응용 프로그램 장애로 인해 데이터 손실이 발생할 경우 복구하는데 도움이 됩니다. 자세한 내용은 버전 관리 설정을 참고하십시오.
Origin-pull: 버킷에 Origin-pul 규칙을 설정하면 사용자가 요청한 객체가 버킷에 존재하지 않거나 특정 요청이 필요하여 리디렉션하는 경우, Origin-pul 규칙을 통해 COS에서 상응하는 데이터에 액세스합니다. 자세한 내용은 Origin-pull 설정을 참고하십시오.
버킷 암호화: 버킷 암호화를 설정하면 기본적으로 버킷에 새로 업로드된 모든 객체를 지정된 암호화 방법으로 암호화할 수 있습니다. 자세한 내용은 버킷 암호화 개요를 참고하십시오.
리스트: 인벤토리 기능은 버킷의 객체 속성, 구성 세부 정보 등에 대한 인벤토리 목록을 매일, 매주 또는 매월 정기적으로 출력할 수 있습니다. 자세한 내용은 인벤토리 설정을 참고하십시오.
링크 도용 방지: 링크 도용 방지를 설정하여 악성 프로그램이 리소스 URL을 사용해 공용 네트워크 트래픽을 도용하거나 악의적으로 리소스를 도용하는 것을 방지합니다. 자세한 내용은 링크 도용 방지 설정을 참고하십시오.
라이프사이클: 라이프사이클 규칙을 설정하면 해당 규칙에 따라 COS에서 지정 객체를 지정한 시간 내에 자동으로 스토리지 유형을 전환하거나 삭제합니다. 자세한 내용은 라이프사이클 설정을 참고하십시오.
버킷 복제: 버킷 복제를 활성화한 후 원본 버킷에서 다른 리전의 대상 버킷으로 증분 객체를 비동기식으로 자동 복제합니다. 자세한 내용은 버킷 복제 설정을 참고하십시오.
로그 관리: 로그 기능을 사용하면 COS에서 버킷 작업과 관련된 다양한 요청 로그를 기록하여 버킷을 더 잘 관리하고 사용할 수 있습니다. 자세한 내용은 로그 저장 설정을 참고하십시오.
태그: 버킷 태그는 버킷을 관리할 수 있는 일종의 표식으로 사용자가 편리하게 버킷을 구분하여 관리할 수 있습니다. 자세한 내용은 버킷 태그 설정을 참고하십시오.
알람 설정
버킷 알람을 설정하여 일상적인 모니터링 수요를 만족할 수 있습니다.
현재 알림: 현재 계속하여 진행 중인 알림 데이터를 표시합니다.
설정된 알람 정책: 설정된 알림 정책 수를 표시합니다.
기타
위의 COS 관련 구성 외에도 COS는 콘텐츠 감사, 데이터 처리 등 Cloud Infinite(CI) 기능도 통합했습니다. 자세한 내용은 콘텐츠 감사 및 데이터 처리 개요를 참고하십시오.
관련 설명
객체 스토리지는 수평적 구조로 객체를 저장하며 폴더 개념이 없습니다. 자세한 내용은 객체 개요 문서의 '폴더 및 목록' 부분을 참고하십시오.
하나의 루트 계정(즉, 동일한 APPID)은 리전 구분 없이 최대 200개의 버킷을 생성할 수 있으나, 버킷 내 객체 수량에는 제한이 없습니다.
Tencent Cloud에서 동일한 APPID의 버킷 이름은 전역적으로 고유해야 하며 중복될 수 없습니다.
버킷 생성 완료 후에는 버킷 이름을 변경할 수 없고, 버킷을 삭제한 후 다시 생성하면 이름을 변경할 수 있습니다.
리전 설정 완료 후에는 리전을 수정할 수 없으므로, 사용자는 버킷 생성 시 소속 리전을 확인해야 합니다.
버킷 생성
최종 업데이트 날짜:：2025-10-13 10:31:27
파일을 Cloud Object Storage(COS)에 저장할 때, 먼저 객체를 저장할 버킷을 생성해야 합니다. 콘솔, 도구, API 또는 SDK를 통해 버킷을 생성할 수 있습니다. 버킷 개념에 대한 자세한 내용은 버킷 개요를 참고하십시오. 아래에서는 버킷 생성 방법을 설명하겠습니다.
버킷 생성 후, 객체를 해당 버킷에 업로드할 수 있으며, 버킷을 위한 기타 기능을 설정할 수 있습니다. 예를 들어, 정적 웹 사이트 설정, 버킷 태그 설정, 버킷 암호화 설정 등이 있습니다. 가이드 설정 관련 자세한 내용은 콘솔 개요를 참고하십시오.
제한 설명
하나의 루트 계정은 최대 200개의 버킷을 생성할 수 있습니다.
버킷 생성 완료 후에는 버킷 이름과 소속 리전을 수정할 수 없습니다.
하나의 루트 계정에서 각 버킷은 고유한 이름을 가지며 이름을 변경할 수 없습니다.
버킷 이름은 알파벳 소문자와 숫자, 즉 [a-z, 0-9], 하이픈 ‘-’ 만 사용 가능합니다. 버킷 이름의 최대 글자 수는 리전 약칭 및 APPID 글자 수의 영향을 받습니다. 완전한 요청 도메인의 최대 글자 수는 60자입니다. 예를 들어 요청 도메인 123456789012345678901-1250000000.cos.ap-beijing.myqcloud.com은 총 60자입니다.
소속 리전: 고객님의 비즈니스(또는 사용자 수)가 상대적으로 집중된 물리적 지역에 해당하는 COS 리전을 선택하십시오. 설정 후에는 수정할 수 없습니다. 리전에 대한 자세한 내용은 리전 및 접근 도메인을 참고하십시오.
이름: 사용자 정의 버킷 이름을 입력하십시오. 설정 후에는 수정할 수 없습니다. 명명 규칙에 대한 자세한 내용은 버킷의 명명 규칙을 참고하십시오.
접근 권한: 버킷은 기본적으로 비공개 읽기/쓰기, 공개 읽기/비공개 쓰기, 공개 읽기/쓰기 세 가지 접근 권한을 제공하며, 설정 후에도 수정할 수 있습니다. 자세한 내용은 버킷 접근 권한을 참고하십시오.
요청 도메인: 자동 생성됩니다. 버킷 생성 후 해당 도메인을 사용하여 버킷에 접근할 수 있습니다.
다중 AZ(MAZ) 기능: 다중 AZ 기능은 버킷의 식별자로, 다중 AZ 구성을 활성화하면 데이터가 동일한 리전의 다른 데이터 센터에 저장되어 동일한 도시 내 재해 복구 기능을 제공합니다. 현재 이 기능은 베이징, 상하이, 광저우, 중국 홍콩, 싱가포르 등 일부 리전에서만 사용할 수 있습니다. 적용 가능한 리전 및 기능에 대한 자세한 내용은 다중 AZ(MAZ) 기능 개요 문서를 참고하십시오.
주의:
다중 AZ 스토리지에 따른 스토리지 사용량 비용은 단일 AZ보다 높습니다. 자세한 내용은 각 리전의 제품 가격을 참고하십시오.
버킷 다중 AZ 구성은 활성화 후 변경할 수 없습니다. 활성화 후 데이터는 다중 AZ 기능을 지원하는 스토리지 유형(예: MAZ_STANDARD, MAZ_STANDARD_IA)으로 버킷에 저장되므로 신중하게 구성하십시오. 버전 관리도 동시에 활성화한 경우 버전 관리 상태 역시 변경할 수 없습니다.
이미 생성된 버킷은 다중 AZ 구성을 활성화할 수 없으며, 새로 생성하는 버킷에만 설정할 수 있습니다.
4.2 고급 선택 구성
설명:
이 설정 항목은 선택 사항이며, 필요에 따라 설정할 수 있습니다.
버전 관리: 활성화하면 동일한 이름의 객체를 업로드하거나 객체를 추가, 삭제, 수정하는 등의 작업 시 객체의 이전 버전을 쉽게 찾을 수 있도록 이전 버전이 저장됩니다.
주의:
버전 관리와 다중 AZ 기능을 동시에 활성화한 경우 버전 관리 상태를 변경할 수 없으므로 구성 시 주의하시길 바랍니다.
메타데이터 가속: 이 구성 항목은 현재 화이트리스트 사용자에게만 공개되어 있으며, 자세한 내용은 메타데이터 가속 기능 개요를 참고하십시오.
스마트 압축: 활성화하면 버킷 내 지정된 형식의 이미지에 접근할 때마다 이미지 형식을 변경하지 않고 실시간으로 압축하여 트래픽을 크게 절약할 수 있습니다. 자세한 내용은 스마트 압축 소개를 참고하십시오.
로그 저장: 버킷 작업과 관련된 다양한 요청 로그를 기록합니다.
버킷 태그: 버킷 태그는 버킷을 관리하기 위한 식별자로, 버킷에 태그를 설정하여 그룹별로 버킷을 관리할 수 있습니다. 자세한 내용은 버킷 태그 설정을 참고하십시오.
서버 측 암호화: 서버 측 암호화 방식을 선택할 수 있습니다. 서버 측 암호화에 대한 소개 및 지원 리전은 서버 측 암호화 개요를 참고하십시오.
4.3 구성 확인
버킷의 구성 정보를 확인합니다. 수정이 필요한 경우 이전 단계를 클릭하세요.
5. 정보를 확인한 후 생성을 클릭하면 버킷이 생성됩니다. 버킷 목록 페이지에서 방금 생성한 버킷을 확인할 수 있습니다.
설명:
버킷 목록은 Data Lake Compute(DLC)에서 생성한 버킷만 표시되며, 현재는 구성이 지원되지 않습니다. 구성을 원하시면 DLC 콘솔로 이동하여 작업하십시오. 자세한 내용은 호스팅 스토리지 구성을 참고하십시오.
툴 사용
COSBrowser, COSCMD 등의 툴을 사용하여 버킷을 생성할 수 있습니다. 자세한 내용은 툴 개요를 참고하십시오.
REST API 사용
REST API를 사용하여 버킷 생성 요청을 실행할 수 있습니다. 자세한 내용은 PUT Bucket API 문서를 참고하십시오.
SDK 사용
SDK 버킷 생성 메소드를 호출할 수 있습니다. 자세한 내용은 아래 각 언어로 된 SDK 문서를 참고하십시오.
5. 규칙 추가 팝업 창에서 버킷의 현재 버전 파일과 이전 버전 파일을 모두 삭제하도록 규칙을 설정합니다. 구성은 다음과 같습니다.
기본 정보:
상태: 켜짐.
규칙 이름: 필수 입력, 라이프사이클 규칙 이름을 입력하세요.
정책 유형: '마지막 수정 시간'을 선택하세요. 접근 추적 얼로우리스트 기능을 활성화한 경우 이 구성 항목이 표시됩니다. 이 구성 항목이 없는 경우 기본 정책 유형은 마지막 수정 시간이며 선택할 필요가 없습니다. 자세한 내용은 라이프사이클 설정을 참조하세요.
적용 범위: 전체 버킷을 선택하세요.
제외 범위: 꺼짐.
규칙 구성:
현재 버전 파일 관리: 파일 수정 시간으로부터 1일 후 삭제하도록 설정하세요.
이전 버전 파일 관리: 파일 수정 시간으로부터 1일 후 삭제하도록 설정하세요.
조각 삭제: 조각 생성 1일 후 삭제하도록 설정하세요.
설명:
버킷 데이터를 삭제하는 작업은 위험도가 높은 작업이므로 2차 확인이 필요합니다. 확인을 클릭하면 됩니다.
6. 라이프사이클 목록에서 삭제 규칙이 성공적으로 설정되었음을 확인할 수 있습니다.
7. 라이프사이클 규칙 실행이 완료된 후, 버킷 개요에서 버킷의 객체 수와 저장량이 모두 0으로 표시되면 버킷이 비어 있음을 의미합니다. 이때 버킷의 데이터는 이미 삭제되었으며, 더 이상 해당 버킷을 사용하지 않으시다면 삭제할 수 있습니다.
버킷 삭제
최종 업데이트 날짜:：2025-09-29 10:07:05
더 이상 버킷(Bucket)을 보관할 필요가 없을 경우 삭제할 수 있습니다. COS 콘솔을 통해 생성된 버킷 목록 페이지에서 버킷을 삭제할 수 있습니다. 또한 콘솔, 도구, API 또는 SDK를 통해 버킷을 삭제할 수도 있습니다.
주의：
버킷을 삭제한 후에는 복구할 수 없으니 신중히 하시기 바랍니다.
전제 조건
버킷 삭제를 시작하기 전에 다음 조건이 충족되었는지 확인하십시오:
버킷 내 모든 파일 및 해당 이전 버전 삭제가 완료되었습니다. 파일 및 해당 이전 버전을 삭제하는 방법은 버킷 비우기를 참조하세요.
버킷 내 모든 파일의 조각 파일 삭제가 완료되었습니다. 조각 파일을 삭제하는 방법은 조각 삭제를 참조하세요.
CDN 가속 도메인 및 사용자 정의 CDN 가속 도메인이 비활성화되었습니다. 비활성화 방법은 CDN 가속 설정을 참조하세요.
버킷 삭제 작업 권한이 확인되었습니다.
루트 계정은 기본적으로 버킷 삭제 권한을 보유합니다. 계정이 서브 계정인 경우, 다음 방법 중 하나를 선택하여 버킷 삭제 권한을 획득할 수 있습니다:
방법 1:즐겨찾기 경로 추가: 루트 계정으로 서브 계정에 특정 버킷의 사용자 권한을 부여하고, 서브 계정이 COS 콘솔에 로그인한 후 버킷의 즐겨찾기 경로를 추가하면 버킷 삭제 작업 권한을 구현할 수 있습니다.
방법 2:사전 설정 정책 추가: 서브 계정에 사전 설정 정책 QcloudCOSFullAccess 또는 QcloudCOSDeleteBucketAccess(특정 버킷 삭제 권한)를 추가하여 버킷에 접근하고 버킷 삭제 작업을 수행할 수 있습니다.
주의 사항
아래 정보를 반드시 자세히 읽어보시기 바랍니다. 해당 정보를 무시할 경우 업무에 영향을 미칠 수 있습니다.
버킷을 삭제할 때 작업을 수행하는 신원이 해당 작업에 대한 권한이 있는지 확인하고 올바른 버킷 이름(Bucket) 및 리전(Region) 매개변수가 전달되었는지 확인해야 합니다.
버킷을 삭제한 후에는 데이터를 복구할 수 없으므로 삭제하기 전에 데이터가 더 이상 사용되지 않는지 확인하십시오. 버킷의 데이터를 계속 사용해야 하는 경우 클라우드 데이터 백업을 참조하여 사전에 백업을 준비하시기 바랍니다.
버킷을 삭제한 후에는 동일한 이름으로 다시 생성하기까지 몇 시간(일반적으로 4~8시간)이 소요됩니다. 이 기간 동안 해당 이름은 모든 사용자에게 공개되어 새 버킷 생성에 사용할 수 있습니다. 원래 버킷 이름을 계속 사용하려면 버킷을 보존할 수 있도록 직접 삭제하는 대신 내용을 비우는 것이 좋습니다.
사용 방법
COS 콘솔 사용
1. COS 콘솔에 로그인한 후, 왼쪽 사이드바에서 버킷 리스트를 클릭해 버킷 리스트 페이지로 이동합니다.
2. 대상 버킷을 찾고 오른쪽의 작업 열에서 더 보기 > 삭제를 클릭합니다.
3. 팝업 창에서 시스템 점검 결과에 따라 작업을 수행합니다.
사용 툴
COSBrowser, COSCMD 등의 툴을 사용하여 버킷을 삭제할 수 있습니다. 자세한 내용은 툴 개요를 참조하십시오.
REST API 사용
REST API를 사용하여 버킷 삭제 요청을 실행할 수 있습니다. 자세한 내용은 DELETE Bucket API 문서를 참조하십시오.
SDK 사용
SDK의 버킷 삭제 메서드를 호출할 수 있습니다. 자세한 내용은 아래 각 언어로 된 SDK 문서를 참조하십시오.
Tencent Cloud COS는 악성 프로그램 URL에 의한 공용 네트워크 트래픽 도용이나 악의적 수단에 의한 리소스 도용으로 사용자가 불필요한 손해를 입지 않도록 링크 도용 방지 설정을 지원하고 있습니다. 보안을 위해 콘솔의 링크 도용 방지 설정 항목에서 블록리스트와 얼로우리스트를 설정할 것을 권장합니다.
주의：
객체 액세스 시 서명(URL과 Header 모두 해당)이 있으면 링크 도용 방지 인증을 진행하지 않습니다.
링크 도용 방지 설정 시, 대용량 파일 멀티파트 요청 시나리오에 대한 링크 도용 방지 얼로우리스트에 자신의 도메인을 추가할 수 있습니다.
작업 단계
1. COS 콘솔에 로그인하여 왼쪽 메뉴 바에서 버킷 목록을 클릭하면 버킷 목록 페이지로 이동합니다.
2. 링크 도용 방지 설정이 필요한 버킷을 찾아 버킷 이름을 클릭하여 버킷 관리 페이지로 이동합니다.
3. 보안 관리 > 도난 링크 방지 설정을 클릭하여 링크 도용 방지 설정을 찾고, 편집을 클릭하여 편집이 가능한 상태로 이동합니다.
4. 현재 상태를 켜기로 수정하고, 목록 유형(블랙리스트 또는 화이트리스트)을 선택한 후 Referer 설정 항목에 블랙리스트 또는 화이트리스트에 추가할 도메인 또는 IP 주소를 입력합니다. 확인 후 저장을 클릭하면 됩니다. 설정 항목 설명은 다음과 같습니다:
블록리스트: 이 항목을 선택하면 Referer의 도메인 또는 IP 주소가 버킷의 기본 접근 주소에 접근이 거부되며 403 오류가 반환됩니다.
화이트리스트: 이 항목을 선택하면 Referer의 도메인 또는 IP 주소가 버킷의 기본 접근 주소에 접근이 허용되며, 다른 도메인 또는 IP 주소는 버킷의 기본 접근 주소에 접근이 거부되고 403 오류가 반환됩니다.
빈 referer: HTTP 요청 header가 null referer입니다(referer 필드를 포함하지 않거나 referer 필드가 null).
Referer: 최대 10개의 도메인을 설정할 수 있으며, 동일한 접두사로 매칭할 수 있습니다. 각 행은 한 줄만 허용되니, 한 줄을 초과할 경우 행을 바꾸십시오. 다음 예시와 같이 도메인, IP, 임의 문자 기호 * 등 형식의 주소를 지원합니다.
www.example.com 설정: www.example.com/123, www.example.com.cn과 같이 www.example.com을 접두사로 하는 주소를 제한할 수 있습니다.
www.example.com:8080, 10.10.10.10:8080 등의 주소와 같이 포트가 있는 도메인과 IP를 지원합니다.
*.example.com 설정: a.b.example.com/123, a.example.com 등의 주소를 제한할 수 있습니다.
설명：
CDN 도메인 이름을 통해 접근을 가속화하는 경우, 먼저 CDN의 도난 방지 설정을 우선 실행한 후, 객체 저장소의 도난 방지 규칙을 실행합니다.
4. 보안 관리 > 객체 잠금을 클릭하고 객체 잠금 구성 항목을 찾은 다음 편집을 클릭하여 ‘활성화’합니다.
5. 보관 기간을 설정하고 저장을 클릭합니다.
보관 기간: 자연수를 입력합니다. 보관 주기는 연장만 가능하고 단축할 수 없으니 합리적으로 설정하시기 바랍니다.
6. 팝업 창에서 확인을 클릭합니다.
설정 후 파일 목록을 클릭해 확인할 파일을 선택하고 파일 오른쪽의 세부 정보를 클릭하여 객체 잠금 규칙이 만료되는 날짜(현지 시간)를 볼 수 있습니다.
설명：
이제 객체 잠금은 얼로우리스트에 있는 고객만 사용할 수 있습니다. 이 기능을 활성화하려면 당사에 문의하기로 문의하십시오.
Origin-pull 설정
최종 업데이트 날짜:：2026-03-26 11:08:46
소개
COS(Cloud Object Storage) 콘솔에서 버킷에 대한 Origin-pull 규칙을 구성할 수 있습니다. 요청한 객체가 버킷에 없거나 특정 요청을 리디렉션해야 하는 경우 COS를 통해 해당 데이터에 액세스하도록 Origin-pull 규칙을 구성할 수 있습니다. Origin-pull 구성은 주로 핫 데이터 마이그레이션, 특정 요청 리디렉션 및 기타 관련 시나리오에 사용됩니다. 귀하의 실제 필요에 따라 설정할 수 있습니다.
설명：
Origin-pull에 의한 데이터 풀링 성공률은 네트워크 환경과 관련이 있습니다. China Telecom, China Mobile, China Unicom 등의 IP를 우선적으로 사용하십시오.
금융 클라우드 리전의 버킷은 origin-pull 설정을 지원하지 않습니다.
퍼블릭 클라우드 리전 중 일부 리전만 동기 origin-pull을 지원합니다. 지원 리전: 베이징, 청두, 광저우, 난징, 상하이, 홍콩, 싱가포르, 자카르타, 서울, 방콕, 도쿄, 리야드, 실리콘밸리(미국 서부), 버지니아(미국 동부), 상파울루, 프랑크푸르트.
Origin-pull 규칙
트리거 조건
비동기 및 동기화 origin-pull 모드에서 origin-pull은,GET 요청에서 404가 반환된 경우에만 origin-pull이 트리거됩니다. HEAD 또는 기타 요청은 origin-pull을 트리거하지 않습니다.
리디렉션 모드에서 400~599 사이의 HTTP 상태 코드를 사용자 지정하여 origin-pull을 트리거할 수 있습니다.
원본 액세스
비동기화 및 동기화 origin-pull 모드에서 COS 액세스 요청의 QueryString 및 Header 정보를 원본에 전달할지 여부를 설정하고, 원본 요청 시 추가 Header 정보를 전달하도록 구성할 수 있습니다. 리디렉션 모드에서는 QueryString 통과 여부만 설정할 수 있습니다.
GET 연산 중에 GET range가 지정되면 COS는 완전한 객체 데이터를 가져와 COS에 저장하기 위해 원래 요청 외에 range가 없는 비동기 요청을 보냅니다.
응답 및 저장
원본은 chunked 인코딩으로 데이터를 반환할 수 있습니다.
원본이 404 상태 코드를 반환하면 COS로 전달되어 사용자에게 반환됩니다. 3XX 팔로우 정책이 활성화된 경우 원본이 3XX 상태 코드를 반환하면 COS는 다른 원본에서 데이터를 가져옵니다. 원본이 3XX가 아닌 다른 상태 코드를 반환하면 COS는 424 상태 코드를 반환합니다.
origin-pull에 의해 반환된 파일은 원본 요청 시 사용한 파일명으로 COS에 저장됩니다. 예를 들어 사용자가 요청한 example.jpg 파일이 버킷에 존재하지 않는 경우, COS는 구성된 origin-pull 주소 http://origin.com/example.jpg에서 파일을 풀링하고 example.jpg 버킷에 저장된 파일의 이름을 바꾸는 origin-pull 메커니즘을 트리거합니다.
COS에 저장된 새 객체에는 다음 메타데이터가 포함되며 데이터 콘텐츠는 원본 값을 따릅니다.
4. 왼쪽 사이드바에서 기본 설정 > Origin-pull 설정을 선택하고 Origin-pull 규칙 추가를 클릭합니다.
5. 팝업 창에서 다음 정보를 설정하고 다음 단계를 클릭합니다.
Origin-pull 모드: Origin-pull 모드는 실제 필요에 따라 선택할 수 있습니다.
Origin-pull 비동기화: 요청된 파일이 COS에 없으면 COS는 지정된 원본에서 파일을 찾아 클라이언트로 반환하지 않고 버킷에 업로드합니다.
설명：
비동기식 Origin-pull은 파일을 직접 반환하지 않습니다. 대신 먼저 클라이언트에 302 상태 코드를 반환한 다음 파일을 COS에 비동기식으로 업로드합니다.
원본에서 데이터를 가져오려면 Follow 302를 활성화하는 것이 좋습니다.
파일 업로드 시간은 여러 요인에 따라 달라지며 SLA는 약속할 수 없습니다. 비즈니스가 지연에 민감한 경우 Origin-pull 동기화를 선택하는 것이 좋습니다.
Origin-pull 동기화: 요청한 파일이 COS에 없는 경우, COS는 지정된 원본에서 파일을 검색하여 클라이언트에 반환하고 버킷에 업로드합니다.
주의:
동기 origin-pull을 사용할 때, 전체 파일이 다운로드되고 상태 코드 200이 반환된 경우에만 적시성을 보장할 수 있습니다. 클라이언트가 range 요청으로 파일에 접근하는 경우에는 적시성을 보장할 수 없습니다.
리디렉션: 버킷에 액세스할 때 지정된 오류가 보고되면 COS는 클라이언트에 리디렉션 주소를 반환하지만 원본에서 파일을 저장하지 않습니다. 클라이언트는 리디렉션 주소의 원본에서 리소스를 요청할 수 있습니다.
Origin-pull 조건: Origin-Pull을 트리거하기 위해 동시에 충족되어야 하는 모든 조건을 지정합니다.
HTTP 상태 코드 404: 비동기화 Origin-pull 또는 동기화 Origin-pull을 선택하는 GET 요청에서 HTTP 상태 코드 404를 반환할 때 origin-pull이 트리거됩니다. 이 항목은 필수이며 비활성화할 수 없습니다.리디렉션을 선택하면 400~599 범위의 HTTP 상태 코드를 입력할 수 있습니다.
파일명 접두사: 요청된 파일이 접두사와 일치하면 origin-pull 규칙이 트리거됩니다. 파일명 접두사를 prefix로 설정한 경우, GET를 통해 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/prefix123.jpg 요청하고 HTTP 상태 코드 404를 반환할 때 origin-pull 규칙이 트리거됩니다.
Origin-pull 프로토콜: COS가 지정된 원본에 액세스하는 데 사용하는 프로토콜입니다. 옵션에는 Force HTTPS, Force HTTP 및 Follow 요청 프로토콜이 포함됩니다.
Force HTTPS 또는 Force HTTP를 선택할 경우, COS는 각각 HTTPS 또는 HTTP를 사용하여 원본에 액세스합니다.
Follow 요청 프로토콜을 선택할 경우, COS는 요청에 사용된 프로토콜로 원본에 액세스합니다.
요청 매개변수: COS에 액세스할 때 가지고 다니는 queryString 요청 매개변수를 원본으로 전달할지 여부를 지정합니다.
요청 헤더: 모든 요청 헤더를 전달하거나 특정 요청 헤더만 전달하는 옵션이 있습니다. 모든 요청 헤더를 전달하는 경우 host 헤더는 전달 금지를 권장하며, 원클릭 설정이 지원됩니다.
특정 요청 헤더 전달: 특정 요청 헤더 전달 옵션을 선택하면, 원본 서버에 전달할 요청 헤더를 지정해야 합니다. 리디렉션 선택 시 설정할 필요가 없습니다.
특정 요청 헤더 전달금지: 원본 서버에 전달하지 않을 요청 헤더를 지정할 수 있습니다. 리디렉션 선택 시 설정할 필요가 없습니다.
요청 헤더 추가: 원본 서버로 돌아갈 때 추가 요청 헤더를 여기에서 추가할 수 있습니다. 원본으로 리디렉션 유형을 선택하면 이 항목은 설정하지 않아야 합니다.
6. 선택한 Origin-pull 모드에 따라 다음 정보를 구성하도록 선택하고 다음 단계를 클릭합니다.
Origin-pull 비동기화
Origin-pull 주소: http:// 또는 https:// 접두사 없이 도메인 이름 또는 IP 주소를 입력합니다. 도메인 이름이나 IP 주소 뒤에 포트 번호를 추가할 수도 있습니다.
정확한 주소의 예시는 다음과 같습니다.
abc.example.com
abc.example.com:8080
202.96.128.86
202.96.128.86:8080
대기 포워딩 주소: 백업 origin-pull 주소 설정을 지원합니다. 입력 형식은 Origin-pull 주소 설정 항목 설명을 참고하십시오. 이 설정은 버킷이 위치한 리전에 따라 다르며, 지원되는 경우에만 설정할 수 있습니다.
주소 설정: 특정 파일 또는 경로 설정 여부를 선택할 수 있습니다. 설정 항목 설명은 다음과 같습니다.
고정 파일설정: Origin-pull 규칙이 트리거되면 모두 고정 파일로 이동됩니다.
접두사및접미사설정: Origin-pull 규칙이 트리거될 경우, 지정한 접두사 또는 접미사가 포함된 파일 경로로 이동합니다.
예를 들어 접두사를 test로 지정하고 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/path/prefix123.jpg 접근 시 origin-pull 규칙이 트리거되면 <origin address>/test/path/prefix123.jpg 로 이동합니다.
또한 접미사를 .jpg로 지정하고 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/path/prefix123 접근 시 origin-pull 규칙이 트리거되면 <origin address>/path/prefix123.jpg 로 이동합니다.
주의:
지정한 접두사와 접미사 설정은 동시에 적용할 수 있습니다.
3XX 따라가기 정책: 활성화 시, 원본 서버가 3XX 리디렉션 상태 코드를 반환할 경우 COS는 기본적으로 3XX를 따라가 다른 원본 서버에서 데이터를 가져옵니다. 비활성화를 선택하면 리소스를 가져오지 않습니다.
주의:
원본 서버가 반환한 3XX 리디렉션이 사설망 주소로 이동하는 경우, COS는 이를 따르지 않습니다. 동기 origin-pull 모드에서는 COS가 사설망 주소로의 리디렉션을 따르지 않으며, 비동기 및 리디렉션 모드에서는 사설망 주소 반환 후 업무 로직에 따라 따를지 여부를 판단해야 합니다.
Origin-pull 동기화
Origin-pull 주소: http:// 또는 https:// 접두사 없이 도메인 이름 또는 IP 주소를 입력합니다. 도메인 이름이나 IP 주소 뒤에 포트 번호를 추가할 수도 있습니다.
정확한 주소의 예시는 다음과 같습니다.
abc.example.com
abc.example.com:8080
202.96.128.86
202.96.128.86:8080
대기 포워딩 주소: 백업 origin-pull 주소 설정을 지원합니다. 입력 형식은 Origin-pull 주소 설정 항목 설명을 참고하십시오. 이 설정은 버킷이 위치한 리전에 따라 다르며, 지원되는 경우에만 설정할 수 있습니다.
주소 설정: 특정 파일 또는 경로 설정 여부를 선택할 수 있습니다. 설정 항목 설명은 다음과 같습니다.
고정 파일설정: Origin-pull 규칙이 트리거되면 모두 고정 파일로 이동됩니다.
접두사및접미사설정: Origin-pull 규칙이 트리거될 경우, 지정한 접두사 또는 접미사가 포함된 파일 경로로 이동합니다.
예를 들어 접두사를 test로 지정하고 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/path/prefix123.jpg 접근 시 origin-pull 규칙이 트리거되면 <origin address>/test/path/prefix123.jpg 로 이동합니다.
또한 접미사를 .jpg로 지정하고 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/path/prefix123 접근 시 origin-pull 규칙이 트리거되면 <origin address>/path/prefix123.jpg 로 이동합니다.
주의:
지정한 접두사와 접미사 설정은 동시에 적용할 수 있습니다.
3XX 종속 정책: 이 정책이 활성화된 경우 원본이 3xx 리디렉션을 반환하면 COS가 이를 따라 다른 원본에서 데이터를 가져옵니다. 비활성화를 선택하면 리소스를 풀링하지 않습니다.
원본 사이트의 패킷: 이 기능이 활성화되면 상태 코드 및 기타 정보를 포함하여 원본의 패킷이 직접 반환됩니다.이 설정은 버킷이 위치한 리전에 따라 다르며, 지원되는 경우에만 설정할 수 있습니다.
리디렉션
Origin-pull 주소: http:// 또는 https:// 접두사 없이 도메인 이름 또는 IP 주소를 입력합니다. 도메인 이름이나 IP 주소 뒤에 포트 번호를 추가할 수도 있습니다.
정확한 주소의 예시는 다음과 같습니다.
abc.example.com
abc.example.com:8080
202.96.128.86
202.96.128.86:8080
주소 설정: 특정 파일 또는 경로 설정 여부를 선택할 수 있습니다. 설정 항목 설명은 다음과 같습니다.
고정 파일설정: Origin-pull 규칙이 트리거되면 모두 고정 파일로 이동됩니다.
접두사및접미사설정: Origin-pull 규칙이 트리거될 경우, 지정한 접두사 또는 접미사가 포함된 파일 경로로 이동합니다.
예를 들어 접두사를 test로 지정하고 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/path/prefix123.jpg 접근 시 origin-pull 규칙이 트리거되면 <origin address>/test/path/prefix123.jpg 로 이동합니다.
또한 접미사를 .jpg로 지정하고 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/path/prefix123 접근 시 origin-pull 규칙이 트리거되면 <origin address>/path/prefix123.jpg 로 이동합니다.
주의:
지정한 접두사와 접미사 설정은 동시에 적용할 수 있습니다.
리디렉션 Code: 301, 302, 307을 선택할 수 있으며, 기본값은 302입니다.
7. 설정된 Origin-pull 규칙이 정확한지 확인하고 확인을 클릭합니다.
8. 기본적으로 COS는 origin-pull을 수행하는 가장 최근 규칙에 항상 가장 높은 우선 순위를 부여합니다. 우선 순위를 수동으로 변경하려면 규칙 목록의 우선 순위 열에서 편집 아이콘을 클릭하면 됩니다.
주의:
고우선순위 소스가 실패한 후, 저우선순위 소스 주소로 돌아가지 않고 원본 소스의 백업 소스 주소로 돌아갑니다.
예시
배경
APPID가 1250000000인 사용자가 examplebucket-1250000000이라는 버킷을 생성하고, CDN 가속 엔드포인트 도메인 이름을 활성화했습니다.
examplebucket-1250000000.file.myqcloud.com
버킷의 origin-pull 주소를 다음과 같이 구성합니다.
abc.example.com
원본 http://abc.example.com에 이미지 picture.jpg를 저장합니다.
COS가 루트 디렉터리에 저장된 picture.jpg 객체에 직접 적중하여 클라이언트에 반환합니다.
CORS 설정
최종 업데이트 날짜:：2025-08-27 11:38:10
소개
Cloud Object Storage(COS) 콘솔에서 버킷의 객체에 대해 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)를 설정할 수 있습니다. COS는 OPTIONS 요청에 응답하기 위해 여러 규칙 구성을 지원합니다. CORS는 HTTP 요청을 통해 한 출처의 리소스를 다른 출처에서 요청할 수 있도록 하는 메커니즘입니다. 프로토콜, 도메인 이름 또는 포트가 다른 한 origin은 서로 다른 것으로 간주됩니다.
COS 서비스는 크로스 도메인 간 액세스를 위한 OPTIONS 요청 응답 기능을 지원하며, 개발자가 설정한 규칙에 따라 브라우저로 세부 설정 규칙을 반환합니다. 하지만 이후 실행되는 크로스 도메인 요청이 규칙에 부합하는지 여부는 서버에서 검사하지 않습니다. 자세한 내용은 HTTP 액세스 제어에 관한 설명과 CORS 설정의 모범 사례 문서를 참고하십시오.
Origin: 크로스 도메인 요청을 허용할 출처이며, 사용 중인 도메인 네임을 추가하세요. 도메인 네임(중국어 도메인 네임 포함) 및 IP 주소 추가를 지원합니다.
도메인 이름은 슬래시/로 끝날 필요가 없습니다.
한 줄에 하나씩 여러 도메인 이름을 지정할 수 있습니다.
*가 지원되어 모든 도메인 이름과 IP 주소가 허용됨을 나타내므로 권장하지 않습니다.
주의：
사용자가 AJAX 요청에 대해 xhr.withCredentials = true를 활성화한 경우(요청에 도메인 쿠키를 포함해야 함을 나타냄), 이 시나리오에서는 Access-Control-Allow-Origin: *를 구성할 수 없으며, 특정 도메인을 구성해야 합니다. 그러나 COS 도메인은 일반적으로 정적 웹사이트에 사용되며 쿠키가 필요하지 않으므로 xhr.withCredentials = true를 활성화하지 않는 것이 좋습니다.
http://www.abc.com 형식의 단일 특정 도메인 이름이 지원됩니다.
http://*.abc.com 형식의 두 번째 레벨 와일드카드 도메인 이름이 지원되지만 각 줄에는 *가 하나만 포함될 수 있습니다. http://*.example.com으로 설정하면 http://a.b.example.com 및 http://a.example.com과 같은 출처 주소를 허용합니다.
프로토콜 이름 http 또는 https를 생략하지 않도록 주의하십시오. 포트가 기본 포트 80이 아닌 경우 포트도 포함해야 합니다. 예시 IP 주소는 http://10.10.10.10입니다.
중국어 도메인 네임은 중국어 도메인 네임과 punycode 인코딩된 도메인 네임을 동시에 추가하는 것을 권장합니다. 예: https://중국어.cn 및 https://xn--fiq228c.cn.
Allow-Methods: GET, PUT, POST, DELETE 및 HEAD가 지원됩니다. 하나 이상의 허용된 CORS 요청 방법을 열거할 수 있습니다.
Allow-Headers: OPTIONS 요청을 통해 후속 요청에서 어떤 사용자 정의 HTTP 헤더(예시: x-cos-meta-md5)가 허용되는지 서버에 알립니다.
한 줄에 하나씩만 여러 Headers를 지정할 수 있습니다. 예시: Content-Type.
Header는 생략되는 경향이 있으며 달리 필요하지 않은 경우 모든 헤더가 허용됨을 나타내는 *로 설정하는 것이 좋습니다.
영어 대소문자 [a-z, A-Z]가 지원되지만.
Access-Control-Request-Headers에 지정된 각 Header는 Allow-Headers의 값과 일치해야 합니다.
Expose-Headers: Expose-Header는 COS의 상용 Header를 반환합니다. 자세한 내용은 Common Request Headers를 참고하십시오. 실제 상황에 맞춰 세부 설정을 할 수 있으며, 기본값으로 Etag 입력을 권장합니다. 임의 문자 기호는 허용하지 않으며, 대소문자를 구분하지 않습니다. 다수 행을 생성할 수 있으나, 각 행에는 한 개만 입력할 수 있습니다.
Max-Age: OPTIONS 요청으로 얻은 결과의 유효 기간(초). 값은 600과 같은 양의 정수여야 합니다.
Vary: Origin 반환: Vary: Origin Header 반환 여부를 설정합니다. 브라우저에 CORS와 비 CORS 요청이 동시에 있는 경우 이 옵션을 활성화하십시오. 그렇지 않으면 도메인 간 문제가 발생할 수 있습니다.
주의：
Vary: Origin 설정을 활성화하면 브라우저 캐시 또는 CDN Origin-pull 요청이 증가할 수 있습니다.
Vary: Origin 옵션은 전역 설정 항목으로, 수정 시 모든 크로스 도메인 규칙의 해당 필드 상태가 동기화됩니다.
6. 구성을 완료한 후 저장을 클릭하면 CORS 규칙이 추가된 것을 볼 수 있습니다. 수정하려면 수정을 클릭합니다.
하위 계정을 사용하여 도구 목록에 액세스
최종 업데이트 날짜:：2025-11-11 17:47:22
소개
서브 계정에 버킷 리스트 풀링 권한이 기본값으로 설정되지 않으면, 서브 계정으로 COS 콘솔에 로그인 시 데이터 개요, 버킷 리스트, 기타 권한 부여가 필요한 관리 항목을 조회할 수 없습니다.
서브 계정은 다음 두 가지 방법으로 버킷 리스트에 액세스할 수 있습니다.
액세스 경로 추가: 이 방법은 서브 계정이 객체에 대한 작업 수행 권한은 있지만 버킷 리스트 액세스 권한이 없는 시나리오에 적용할 수 있습니다. 액세스 경로는 [특정 버킷] 또는 [버킷 하위 특정 디렉터리]일 수 있으며, 추가한 경로에 권한을 부여했는지 확인하십시오.
사전 설정 정책 추가: 루트 계정에서 서브 계정에 사전 설정 정책 QcloudCOSGetServiceAccess(버킷 리스트 액세스 권한 획득)를 추가하여 버킷 리스트에 액세스할 수 있습니다. 이 방법은 콘솔에서 통계 데이터 개요를 조회하는 기능도 제공합니다.
주의：
이외에도 서브 계정으로 콘솔에 로그인하여 버킷 리스트를 액세스하는 시나리오에 적용할 수 있습니다.
액세스 경로 추가
기본값이 적용된 상태에서 서브 계정에 사전 설정한 정책(QcloudCOSGetServiceAccess)이 부여되지 않은 경우, 서브 계정은 버킷 리스트를 풀링할 권한이 없습니다. 하지만 루트 계정에서 서브 계정의 버킷에 사용자 권한(예: 데이터 불러오기, 데이터 입력 등의 사용자 권한)을 부여하면, 서브 계정도 액세스 경로 추가의 방법을 통해 버킷에 액세스할 수 있습니다.
전제 조건
루트 계정에서 서브 계정 버킷에 사용자 권한을 부여하는 것과 관련한 자세한 내용은 액세스 권한 설정을 참조하십시오.
작업 순서
1. 서브 계정으로 COS 콘솔에 로그인하여 액세스 경로 리스트 페이지로 이동한 뒤 [액세스 경로 추가]를 클릭합니다.
2. 액세스 경로 추가 알림창에서 버킷이 속한 리전을 선택한 뒤 액세스 경로를 입력합니다. 설정과 관련한 설명은 다음과 같습니다.
리전: 액세스 권한을 부여받은 버킷의 소속 리전을 선택합니다.
액세스 경로: 액세스 권한을 부여받은 버킷 이름(예: examplebucket-1250000000)을 입력합니다. examplebucket-1250000000/doc/exampleobject.txt와 같이 객체의 버킷 내 경로를 입력해도 됩니다.
3. 리전과 액세스 경로를 정확히 입력한 뒤 확인을 클릭하면, 권한을 부여받은 버킷이나 버킷 내 객체의 경로가 추가됩니다.
4. 오른쪽의 파일 리스트를 클릭하면 루트 계정으로부터 권한을 부여받은 서브 계정의 객체를 확인할 수 있습니다.
사전 설정 정책 추가
서브 계정에 사전 설정 정책 QcloudCOSGetServiceAccess(버킷 리스트 액세스 권한 획득)를 추가하는 방법으로 버킷 리스트에 액세스할 수 있습니다.
주의：
사전 설정한 정책 QcloudCOSFullAccess 또는 QcloudCOSReadOnlyAccess는 모두 서브 계정에 버킷 리스트 액세스 권한을 부여할 수 있습니다. 하지만 이 두 정책이 부여하는 권한의 범위가 넓으니 보안성을 고려하여 사용하지 않는 것을 권장합니다.
통계 데이터 개요는 버킷 리스트에 대한 액세스 권한이 있어야 합니다. 서브 계정으로 통계 데이터를 풀링하려면 루트 계정에서 서브 계정에 사전 설정 정책 QcloudCOSGetServiceAccess를 추가했는지 확인하십시오. 추가하지 않은 경우, 통계 데이터 액세스 권한이 없다는 알림이 표시됩니다.
5. 서브 계정명을 클릭하여 서브 계정 상세 페이지로 이동합니다. 상세 페이지에서 이미 추가한 정책을 확인할 수 있습니다. 추가한 정책을 사용하지 않으려면 바인딩을 해제합니다.
설명：
위 내용에 따라 루트 계정에서 서브 계정에 사전 설정 정책을 추가했다면, 서브 계정으로 COS 콘솔에 로그인하여 버킷 리스트 및 통계 데이터 개요를 정상적으로 조회할 수 있습니다.
도메인 관리
도메인 관리 개요
최종 업데이트 날짜:：2024-06-24 16:09:30
소개
파일을 버킷에 업로드 한 후, COS(Cloud Object Storage)는 파일 링크(파일 URL)를 자동 생성하므로, 파일 URL(COS 기본 설정 도메인)을 통해 해당 파일에 액세스할 수 있습니다. CDN 또는 자체 도메인을 통해 COS 상의 파일에 액세스하고자 하는 경우, CDN 도메인 또는 자체 도메인을 파일이 속해있는 버킷에 바인딩해야 합니다.
실제 니즈에 따라, 상응하는 도메인을 사용해 파일에 액세스할 수 있습니다. 예를 들어, CDN을 통해 파일에 가속 액세스하고 자 하는 경우, CDN 가속 도메인이 생성한 파일 링크에 액세스하면 됩니다.
설정 설명
사용자는 다음 도메인을 통해 버킷 내 객체를 신속하게 다운로드 및 전송할 수 있습니다.
기본 도메인: COS 원본 서버 도메인으로, 버킷을 생성할 때 버킷 이름 및 리전에 따라 자동으로 생성됩니다.
사용자 정의 CDN 가속 도메인: 버킷과 관련하여 ICP비안이 등록된 사용자 정의 도메인을 Tencent Cloud의 중국 내 CDN 가속 플랫폼에 바인딩할 수 있으며, 사용자 정의 도메인으로 버킷 내 객체에 액세스할 수 있습니다(기존 버전 COS 콘솔에서 '사용자 정의 도메인'을 사용한 경우, 신규 버전 콘솔에는 '사용자 정의 CDN 가속 도메인'이 표시되지 않고, '사용자 정의 도메인'이 표시됨).
사용자 정의 원본 서버 도메인: ICP비안을 통과한 사용자 정의 도메인을 현재 버킷에 바인딩할 수 있으며, 사용자 정의 도메인을 통해 버킷에 있는 객체에 액세스합니다.
주의：
현재 COS에서 사용자 정의 CDN 가속 도메인을 사용할 경우, CDN을 반드시 활성화해야 합니다. 상황에 따라 판단하십시오.
도메인으로 중국 내 CDN에 액세스할 경우 ICP비안이 필요합니다. 단, Tencent Cloud의 ICP비안이 반드시 필요한 것은 아니며, ICP비안이 등록된 액세스 도메인이면 가능합니다.
도메인으로 해외 CDN에 액세스할 경우 ICP비안이 필요하지 않습니다. 단, Tencent Cloud에 저장한 데이터와 조작에 관해서는 해당 국가의 관련 법률/법규 및 <Tencent Cloud 서비스 이용약관>을 준수해야 한다는 점에 유의하십시오.
사용자 정의 CDN 가속 도메인에 CDN 가속을 활성화한 상태에서 원본 서버가 공개 읽기 버킷인 경우, 사용자 정의 CDN 가속 도메인으로 원본 서버 내 객체에 바로 액세스하도록 기본 설정됩니다. 원본 서버가 개인 읽기 버킷인 경우, CDN Origin-pull 인증 및 CDN 인증 설정 옵션을 활성화하길 권장합니다.
Origin-pull 인증(활성화를 위해 CDN 서비스 라이선스를 추가해야 함): 요청한 데이터가 엣지 노드에서 캐시 미스된 경우, CDN은 Origin-pul을 통해 데이터 콘텐츠를 획득해야 합니다. COS를 원본 서버로 하여 Origin-pull 인증을 활성화하면 CDN 엣지 노드에서 특정 서비스 자격(CDN 서비스 라이선스로 해당 자격 확보해야 함)으로 COS 원본 서버에 액세스합니다. 이로써 버킷 내 데이터에 개인 액세스하여 데이터를 획득하고 캐싱할 수 있습니다.
CDN 인증 설정: 엣지 노드에 액세스하여 캐시 데이터를 획득할 경우, 엣지 노드에서 인증 설정 규칙에 따라 액세스 URL의 인증 필드를 검사합니다. 권한이 없는 액세스를 차단하여 링크 도용을 방지하기 때문에 엣지 노드 내 캐시 데이터의 보안성과 신뢰성이 향상됩니다.
CDN 인증 설정과 CDN Origin-pull 인증은 사용 시 상충하지 않습니다. 단, 각각의 설정 상태에 따라 데이터 보호 효과가 서로 다릅니다. 자세한 내용은 다음 표를 확인하십시오.
버킷 액세스 권한
CDN Origin-pull 인증 활성화 여부
CDN 인증 설정 활성화 여부
CDN 가속 도메인으로
원본 서버 액세스 가능 여부
COS 원본 서버 도메인으로
원본 서버 액세스 가능 여부
적용 시나리오
공개 읽기
비활성화
비활성화
액세스 가능
액세스 가능
전체 서버 공용 액세스
공개 읽기
활성화
비활성화
액세스 가능
액세스 가능
비권장
공개 읽기
비활성화
활성화
URL 인증 필요
액세스 가능
비권장
공개 읽기
활성화
활성화
URL 인증 필요
액세스 가능
비권장
개인 읽기+CDN 서비스 라이선스
활성화
활성화
URL 인증 필요
COS 인증 필요
전체 링크 보호
개인 읽기+CDN 서비스 라이선스
비활성화
활성화
URL 인증 필요
COS 인증 필요
비권장
개인 읽기+CDN 서비스 라이선스
활성화
비활성화
액세스 가능
COS 인증 필요
원본 서버 보호
개인 읽기+CDN 서비스 라이선스
비활성화
비활성화
액세스 불가
COS 인증 필요
비권장
개인 읽기
비활성화
활성화 또는 비활성화
액세스 불가
COS 인증 필요
CDN 이용 불가
주의：
상기 표의 첫 줄처럼, 원본 서버 버킷의 액세스 권한이 공개 읽기이며, CDN Origin-pull 인증과 CDN 인증 설정을 모두 비활성화한 경우, CDN 도메인으로 CDN 엣지 노드와 원본 서버 버킷에 바로 액세스할 수 있으며, COS 도메인으로 원본 서버 버킷에 바로 액세스할 수 있습니다.
상기 표에서 언급된 원본 서버 보호 시나리오의 경우, CDN 인증 설정을 활성화하지 않으면 CDN 엣지 노드에 캐싱된 데이터가 악의적으로 유실될 수 있습니다. 데이터 보안을 위해 CDN 인증 설정도 함께 활성화하시길 권장합니다.
사용자가 도메인의 CDN 가속을 활성화하면 누구나 해당 도메인으로 원본 서버에 바로 액세스할 수 있으므로, 인증 설정을 통해 기밀 유지가 필요한 원본 서버의 데이터를 보호하십시오.
본 문서에서는 Cloud Object Storage(COS) 콘솔에서의 사용자 정의 가속 도메인 추가 및 CDN 가속 활성화 관련 내용을 소개합니다. CDN 콘솔에서 사용자 정의 도메인을 추가하려면 CDN 도메인 연결 문서를 참고하십시오.
작업 단계
1. COS 콘솔에 로그인합니다. 왼쪽 사이드바에서 버킷 리스트를 클릭해 버킷 리스트 페이지로 이동합니다.
2. 도메인을 설정할 버킷을 클릭하여 버킷 설정 페이지로 이동합니다.
3. 도메인 및 전송 관리 > 사용자 정의 CDN 가속 도메인을 선택한 후, 사용자 정의 CDN 가속 도메인 구역에서 도메인 추가를 클릭하여 다음 옵션을 설정합니다.
설명：
레거시 COS 콘솔에서 ‘사용자 정의 도메인’을 활성화한 경우 ‘사용자 정의 CDN 가속 도메인’ 대신 ‘사용자 정의 도메인’이 새 콘솔에 표시됩니다.
도메인 이름: 대상 사용자 정의 도메인 이름(예시: www.example.com)을 입력합니다. 도메인의 ICP 비안이 완료되고 DNS 서비스 제공 업체에서 CNAME 레코드가 구성되었는지 확인하십시오. 자세한 내용은 CNAME 설정을 참고하십시오. 연결하려는 사용자 정의 CDN 가속 도메인이 다음과 같은 상황에 있는 경우 도메인 소유권 확인의 지침에 따라 도메인 소유권을 확인해야 합니다.
처음으로 연결하는 도메인
다른 사용자에 의해 연결된 도메인
와일드카드 서브도메인
가속 리전: CDN 가속은 중국 내, 중국 외 및 전 세계 리전에 대해 지원되며 모든 리전의 버킷에 대한 글로벌 가속이 있습니다.
원본 서버 유형: 기본 원본 서버, 정적 웹사이트 원본 서버, 글로벌 가속 원본 서버를 지원합니다. 버킷에 정적 웹사이트 기능 또는 글로벌 가속 기능이 활성화되어 있다면, 정적 웹사이트 원본 서버나 글로벌 가속 원본 서버를 선택할 수 있습니다.
인증: Origin-pull 인증을 활성화합니다. 개인 읽기 버킷의 경우, Origin-pull 인증을 활성화하여 오리진을 보호합니다.
주의：
개인 읽기 버킷의 경우 Origin-pull 인증과 CDN 서비스 권한 부여가 모두 활성화된 경우 CDN을 통해 원본에 액세스하는 데 서명이 필요하지 않으며 CDN의 캐시된 리소스는 공중망을 통해 전달되어 데이터에 영향을 미칩니다. 보안. 따라서 5단계의 지침에 따라 CDN 인증을 활성화하는 것이 좋습니다.
CDN 캐시 자동 퍼지: 활성화되면 COS 버킷 업데이트 파일 규칙이 트리거될 때 CDN 캐시가 자동으로 퍼지됩니다. COS 함수 계산 설정으로 이동할 수 있습니다. 작업 가이드는 CDN 캐시 퍼지 설정을 참고하십시오.
HTTPS 인증서: 사용자 정의 CDN 가속 도메인에 HTTPS 인증서를 추가하려면 CDN 콘솔로 이동하여 설정할 수 있습니다.
4. 설정을 완료한 뒤, 오른쪽 작업 열의 저장을 클릭합니다. 저장되면 CDN 인증을 위한 활성화 버튼이 인증 열에 나타납니다. 버튼을 클릭하여 사용자 지정 도메인 이름에 대한 CDN 인증을 활성화할 수 있습니다.
CDN 인증: 악의적인 사용자의 도용을 방지하기 위해 타임스탬프 인증을 구성할 수 있습니다. 도메인 이름을 추가한 후 기능을 활성화할 수 있습니다.
주의：
도메인 이름에 대해 CDN 가속이 활성화되면 누구나 도메인 이름을 통해 원본에 직접 액세스할 수 있습니다. 따라서 데이터를 비공개로 유지하려면 인증 설정을 통해 원본 데이터를 보호해야 합니다.
4. 왼쪽 네비게이션 바에서 도메인 및 전송 관리 > 사용자 정의 오리진 도메인을 선택하세요.
5. 사용자 정의 오리진 도메인 페이지에서 도메인 추가를 클릭하면 구성 항목 설명은 다음과 같습니다.
도메인 이름: 바인딩할 사용자 정의 도메인 이름(예: www.example.com)을 입력하거나 드롭다운에서 기존 Tencent Cloud 도메인 이름을 선택합니다. 입력한 도메인 이름이 DNS 서비스 제공업체에서 해석을 추가했는지 확인하세요.
설명:
사용 가능한 도메인이 없거나(또는 새 도메인을 추가해야 하는 경우) 새 도메인 등록을 클릭하여 도메인 등록 콘솔로 빠르게 이동하여 등록할 수 있습니다.
새 도메인 등록에 성공한 후, "Tencent Cloud 도메인 이름"을 선택하고 드롭다운에서 해당 도메인을 선택한 다음 다음 단계를 진행합니다.
CNAME: DNS 서비스 제공업체에서 해당 CNAME 레코드를 구성하여 요청을 COS로 라우팅합니다.
원 서버 유형: 다음과 같이 나뉩니다.
기본 원 서버: 사용자 지정 도메인을 기본 원 서버로 사용하려면 기본 원 서버를 선택합니다.
정적 웹사이트 원 서버: 사용자 지정 도메인을 정적 웹사이트로 사용하려면 먼저 버킷에 정적 웹사이트 기능을 활성화한 후 정적 웹사이트 원 서버를 선택합니다.
글로벌 가속 원 서버: 사용자 지정 도메인을 글로벌 가속으로 사용하려면 먼저 버킷에 글로벌 가속 기능을 활성화한 후 글로벌 가속 원 서버를 선택합니다.
6. 구성을 완료한 후 생성을 클릭하면 목록 페이지에서 구성된 사용자 정의 오리진 도메인을 볼 수 있습니다.
주의:
도메인 추가, 온라인 또는 오프라인 조작은 즉시 적용되지 않습니다. 실제 구성에는 일정 시간이 걸리며 일반적으로 30분 후에 적용되며 도메인의 실제 액세스 상태를 기준으로 합니다.
도메인에 이미 인증서가 바인딩된 경우, 기본 원본 서버 또는 정적 웹사이트 원본 서버에서 글로벌 가속 원본 서버로의 수정은 현재 지원되지 않습니다. 티켓 제출을 통해 처리해 주세요.
7. 인증서를 구성하려면
인증서 바인딩
을 클릭하여 구성합니다. 바인딩 후 30분 내에 적용될 예정입니다. 인증서 출처는 새로 업로드한 인증서와 이미 호스팅된 인증서 중에서 선택할 수 있으며, 설명은 다음과 같습니다.
새로 업로드한 인증서:기존 자체 인증서입니다. 자체 인증서를 사용하려면 이 옵션을 선택하세요.
이미 호스팅된 인증서:기존 텐센트 클라우드 인증서입니다. 텐센트 클라우드에서 신청한 인증서를 사용하려면 이 옵션을 선택하세요.
8. 선택한 인증서 출처에 따라 아래 정보를 구성합니다.
설명:
COS 모든 리전에서 호스팅된 사용자 정의 오리진 도메인 이름에 대한 HTTPS 인증서를 지원합니다. 도메인 이름에 아직 HTTPS 인증서가 없는 경우 텐센트 클라우드 인증서 신청을 클릭할 수 있습니다.
또한 리버스 프록시 설정을 통해 사용자 정의 도메인을 구성하고 (CDN 가속을 끄면) HTTPS 액세스를 구현할 수 있습니다. 방법 2를 참조하십시오.
새로 업로드한 인증서
인증서 내용:
일반적으로 인증서는 .crt 또는 .pem 등의 확장자를 가진 파일입니다(예: imgsc.aa.com_bundle.crt). 해당 텍스트 편집기를 사용하여 인증서 파일을 엽니다.
인증서 형식은 “-----BEGIN CERTIFICATE-----”로 시작하여 “-----END CERTIFICATE-----”로 끝납니다.
인증서 내용에는 완전한 인증서 체인이 포함되어야 합니다.
개인키 내용
일반적으로 개인키는 .key 또는 .pem 등의 확장자를 가진 파일입니다(예: imgsc.aa.com.key). 해당 텍스트 편집기로 개인키 파일을 열어주세요.
개인키 형식은 “-----BEGIN (RSA) PRIVATE KEY-----”로 시작하여 “-----END (RSA) PRIVATE KEY-----”로 끝납니다.
호스팅 SSL:
새로 업로드한 인증서를 SSL에 호스팅하는 것을 지원하며 기본적으로 체크되어 있습니다. SSL에 호스팅하는 것이 좋습니다. 호스팅 후 SSL 콘솔에서 인증서를 관리하며 인증서 만료 알림, 경고, 갱신 등의 호스팅 서비스를 이용할 수 있습니다.
일반적으로 개인키는 .key 또는.pem 등의 확장자를 가진 파일입니다(예: imgsc.aa.com.key). 해당 텍스트 편집기로 개인키 파일을 열어주세요.
개인키 형식은 “-----BEGIN (RSA) PRIVATE KEY-----”로 시작하여 “-----END (RSA) PRIVATE KEY-----”로 끝납니다."
호스팅된 인증서
인증서 목록: 호스팅된 인증서 목록을 표시합니다. 인증서 ID, 도메인 이름 및 인증서 만료 시간이 포함됩니다.
9. 바인딩에 성공하면 사용자 정의 오리진 서버 목록 페이지에서 현재 인증서의 인증서 ID와 만료 시간을 볼 수 있습니다.
10. 인증서를 다시 바인딩하려면 인증서 바인딩을 클릭합니다. 현재 인증서를 바인딩하지 않으려면 인증서 해제를 클릭합니다.
부록: 도메인 이름 해석 설정
해당 DNS 서비스에서 CNAME 레코드를 구성합니다. 주요 작업 단계는 다음과 같습니다.
1. 도메인 추가: 해석할 사용자 정의 오리진 서버 도메인을 입력합니다. 예: www.example.com.
2. 레코드 추가: 사용자 정의 오리진 서버 도메인에 CNAME 레코드 유형의 해석 레코드를 추가합니다. 레코드 값은 CNAME이 가리키는 버킷 기본 오리진 서버 도메인입니다. 예: bucket-1250000000.cos.ap-beijing.myqcloud.com.
3. 해석이 성공했는지 확인합니다. 해석 레코드는 일정 시간이 걸릴 수 있습니다. dig 명령어 또는 COS 콘솔을 통해 해석이 성공했는지 확인할 수 있습니다. 확인 방법은 다음과 같습니다.
명령 프롬프트 창에 명령을 입력합니다. dig mydomain.com. CNAME 레코드가 제대로 작동하는지 확인합니다. (사용 시 mydomain.com을 사용자 정의 도메인으로 바꿉니다.)
COS 콘솔에 로그인하여 버킷 사용자 정의 도메인을 확인합니다. 도메인 이름의 CNAME이 성공적으로 적용되지 않으면 해당 메시지가 표시됩니다.
서브 계정에 버킷 가속 도메인 설정 권한 부여
최종 업데이트 날짜:：2024-06-24 16:09:30
소개
Cloud Object Storage(COS) 버킷의 도메인 관리 설정 페이지에는 기본 가속 도메인, 사용자 정의 CDN 가속 도메인, 사용자 정의 원본 서버 도메인과 같은 세 가지 기능 설정 항목이 있습니다. 기본 가속 도메인과 사용자 정의 CDN 가속 도메인은 설정에 있어 CDN 서비스와 상관 관계가 있습니다. 따라서, 서브 계정에 COS 버킷의 기본 가속 도메인과 CDN 가속 도메인을 설정하려면, COS 서비스의 관리 권한을 부여하는 것 외에도(버킷의 기본 설정 권한 등) CDN 서비스와 관련한 권한을 추가로 부여해야 합니다.
서브 계정에 CDN 서비스와 관련한 권한을 부여하지 않고, COS 버킷의 기본 가속 도메인과 CDN 가속 도메인의 권한을 기본으로 설정하지 않은 경우, 서브 계정으로 COS 콘솔의 도메인 관리 설정 페이지에 로그인하면 권한을 보유하지 않았기 때문에 리소스 보안의 차원에서 다음 이미지와 같이 액세스 권한이 없다는 알림이 나타납니다.
서브 계정에 COS 버킷의 기본 가속 도메인과 CDN 가속 도메인을 정상적으로 설정하려면 CAM 콘솔에서 서브 계정에 권한을 부여해야 합니다. 자세한 작업 순서는 다음과 같습니다.
2. 사용자 지정 정책 생성 > 제품 기능별 또는 프로젝트별 권한 생성을 클릭하여 서비스 유형 구성 페이지로 이동합니다.
설명：
기본적으로 루트 계정에서 권한을 설정합니다. 서브 계정을 사용하면서 권한을 부여하려면, 루트 계정에서 권한 설정을 할 수 있는 권한을 부여했는지 확인하십시오. 이 때, 루트 계정에서 부여한 사용자 관련 정책 QcloudCamFullAccess가 필요합니다.
3. 정책 이름(예시: COS_DomainAccess)을 입력하고 서비스 유형을 CDN으로 선택하고, 다음을 클릭합니다.
4. 비즈니스 요구 사항에 따라 해당 기능 API에 대한 사용자 권한을 부여할 수 있습니다.
서브 계정으로 COS 버킷의 기본 가속 도메인 및 CDN 가속 도메인을 설정하고 이에 액세스하는 작업은 도메인 정보 조회, 도메인 추가, 도메인 활성화/비활성화, 도메인 삭제, 도메인 구성 변경의 다섯 가지 기능과 관련이 있습니다. 서브 계정의 버킷 도메인 설정 페이지에서 모든 가속 도메인과 사용자 정의 가속 도메인을 읽기/쓰기 모두 가능으로 설정하려면 앞서 언급된 기능 버튼을 활성화하십시오.
5. 해당 기능을 선택한 후 다음을 클릭하여 객체를 연결합니다.
6. 순서대로 기능을 객체와 연결합니다. **객체 연결 > 모든 객체(향후 구매할 새 리소스 객체 포함)**를 선택합니다. 이 때 **모든 객체(향후 신규 구매할 리소스 객체 포함)**의 정책 구성을 완전히 적용하려면 반드시 이 객체를 선택해야 합니다.
7. 권한 설정 정보에 오류가 없는지 확인하고 완료를 클릭하여 사용자 지정 정책을 생성합니다.
8. 사용자 지정 정책이 생성되면 사용자 목록 페이지로 전환하고 오른쪽의 권한 부여를 클릭하여 서브 계정을 정책과 연결합니다.
9. 정책 연결 팝업 창에서 방금 생성한 사용자 지정 정책을 검색하여 선택하고 확인을 클릭합니다.
10. 정책 연결이 완료되면 해당 서브 계정에 대한 권한 부여 절차도 마무리됩니다. 해당 서브 계정으로 COS 콘솔에 로그인하면 COS 버킷의 기본 가속 도메인과 CDN 가속 도메인을 정상적으로 설정하고 액세스할 수 있습니다. 다음 이미지를 참조하십시오.
객체
객체 개요
최종 업데이트 날짜:：2025-11-19 11:56:13
소개
객체(Object)는 Cloud Object Storage(COS)의 기본 단위로서 이미지, 문서, 멀티미디어 파일 등 다양한 포맷의 데이터라고 할 수 있습니다. 버킷(Bucket)은 객체의 저장 장치이며 각 버킷은 용량 제한 없이 객체를 수용할 수 있습니다. 객체는 COS에서 다양한 스토리지 유형으로 지정 가능합니다. 자세한 내용은 스토리지 유형 개요을 참고하십시오.
각 객체는 객체 키(ObjectKey), 객체 값(Value), 객체 메타데이터(Metadata)로 구성됩니다.
객체 키(ObjectKey): 객체 키는 버킷에 있는 객체의 고유 ID이며 일반적으로 파일 경로로 이해할 수 있습니다. API, SDK 예시 중 객체의 이름 생성 포맷은 <ObjectKey>입니다.
객체 값(Value): 업로드하는 객체 자체를 뜻하며 일반적으로 파일 콘텐츠(Object Content)로 이해할 수 있습니다.
객체 메타데이터(Metadata): 파일 수정 시간, 스토리지 유형과 같은 파일 속성에 해당하는 키 값 쌍입니다. 객체 업로드 후 조회가 가능합니다.
객체 키
Tencent Cloud COS 객체는 합법적인 객체 키를 보유해야 하며 객체 키(ObjectKey)는 버킷에 있는 객체의 고유 ID입니다.
예를 들어, 객체의 액세스 주소 examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com/folder/picture.jpg에서 객체 키는 folder/picture.jpg입니다.
이름 생성 규칙
객체 키 이름 생성 시 모든 UTF-8 문자를 사용할 수 있습니다. 이름과 기타 응용 프로그램의 호환성을 위해 영어 알파벳 대소문자와 숫자 [a-z, A-Z, 0-9]의 조합을 사용하는 것이 좋습니다.
코드 길이는 최대 850바이트입니다.
이름은 슬래시 / 또는 백슬래시 \로 시작할 수 없습니다.
객체 키에는 ASCII 제어 부호인 위(↑), 아래(↓), 오른쪽(→), 왼쪽(←)을 포함할 수 없으며 이는 각각 CAN(24), EM(25), SUB(26), ESC(27)에 대응됩니다.
파일 이름에 * 및 %와 같은 특수 기호를 사용하지 마십시오.
설명：
사용자가 업로드한 파일 또는 폴더 이름에 중국어 문자가 포함되어 있는 경우 파일 또는 폴더에 액세스하거나 요청할 때 중국어 문자는 URL Encode 규칙에 따라 백분율 인코딩된 문자열로 변환됩니다.
예를 들어, 문서.doc에 액세스할 때 객체 키는 문서.doc이지만 실제로는 URL Encode 규칙에 따라 백분율 인코딩된 문자열은 %e6%96%87%e6%a1%a3.doc입니다.
다음은 유효한 객체 키 이름의 예시입니다.
doc/exampleobject
my.great_photos-2016/01/me.jpg
videos/2016/birthday/video.wmv
특수 부호
어떤 부호는 객체 키에서 16진법 형태로 URL 인코딩 또는 참조 테이블이 필요합니다. 그 중 일부는 출력이 불가능하여 브라우저가 처리할 수 없으므로 특수한 프로세스가 필요한데, 해당 부호는 다음과 같습니다.
，
:
;
=
&
$
@
+
?
ASCII 부호 범위: 00-1F 16진법(0-31 10진법)과 7F(127 10진법)
(빈칸)
또한 어떤 부호는 많은 특수한 프로세스를 거쳐야만 모든 응용 프로그램 간 일관성을 유지할 수 있으므로 바로 사용하지 않는 것을 권장합니다. 사용을 피해야 할 부호는 아래와 같습니다.
`
^
"
\
{
}
[
]
~
%
#
|
*
>
<
ASCII 128-255 10진법
객체 액세스 주소
객체 액세스 주소는 버킷 액세스 주소와 객체 키로 구성되어 <버킷 도메인>/<객체 키>의 구조로 이루어져 있습니다.
예를 들어, 객체 exampleobject.txt를 광저우(화남) 리전 버킷 examplebucket-1250000000에 업로드하면 exampleobject.txt 액세스 주소는 examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com/exampleobject.txt입니다.
폴더와 디렉터리
COS 자체에는 폴더나 디렉터리의 개념이 없습니다. COS는 객체 project/a.txt를 업로드했다고 해서 project 폴더를 생성하지는 않습니다. 간편하게 사용할 수 있도록 COS는 콘솔과 COS browser 등의 도식화 툴에서 '폴더' 또는 '디렉터리' 디스플레이 방식을 모방합니다. 예를 들어, 키 값을 project/로 하여 생성하면 콘텐츠가 없는 객체는 일반적인 폴더로 표시됩니다.
예를 들어 API, SDK를 통해 객체 project/doc/a.txt를 업로드하면 세퍼레이터 /가 '폴더'의 디스플레이 방식을 모방하고, 콘솔에서 '폴더' project와 doc가 나타납니다. 그 중 doc는 project의 하위 '폴더'이며 a.txt 파일을 포함합니다.
주의：
버킷의 각 객체는 각 분산형 클러스터에 수평적으로 분포되어 있습니다. 따라서 특정한 객체 키 접두사로 객체의 크기를 바로 알 수 없으며 각 객체 크기를 누적 계산해야 전체 크기를 알 수 있습니다.
파일이나 디렉터리 삭제 작업은 비교적 복잡합니다. 자세한 내용은 다음과 같습니다.
경로 삭제
객체 또는 폴더 삭제
결과
콘솔
폴더 project
객체 키 접두사가 project/인 모든 객체를 삭제합니다.
콘솔
객체 project/doc/a.txt
project와 doc폴더는 보관할 수 있습니다.
API, SDK
객체 project/ 또는 project/doc/
객체 project/doc/a.txt는 보관할 수 있습니다. 폴더 내 객체를 모두 삭제하고 싶다면 코드 순회를 이용해 폴더 내 객체를 삭제해야 합니다.
객체 메타데이터
객체 메타데이터는 객체의 키 값 쌍을 의미하며, 서버가 HTTP 프로토콜 형식으로 HTML 데이터를 브라우저에 전송하기 전 보내는 문자열로써, HTTP Header라고도 합니다. 객체 업로드 시 HTTP Header를 수정하여 페이지 응답 형식을 바꾸거나 캐시 수정 시간과 같은 설정 정보를 전송할 수 있습니다.
객체 메타데이터는 시스템 메타데이터와 사용자 정의 메타데이터의 2가지 종류가 있습니다.
설명：
객체의 HTTP Header를 수정해도 객체 자체를 수정할 수는 없습니다.
시스템 메타데이터
객체 수정 시간, 객체 크기, 스토리지 유형 등 객체의 속성 정보를 의미합니다.
이름
설명
Content-Length
RFC 2616에서 정의한 HTTP 요청 콘텐츠 길이(바이트)를 의미합니다.
Last-Modified
객체 생성 날짜 또는 마지막 수정 날짜(나중에 생성된 객체 기준)를 의미합니다.
x-cos-version-id
객체 버전 ID. 버킷 버전 제어가 활성화될 경우 객체의 버전 ID를 반환하여 ID가 동일한 객체의 이전 버전을 표시합니다.
ETag
PUT Object를 통해 업로드한 객체의 MD5 값이나 멀티파트 업로드나 이전 버전 API를 통해 업로드한 객체의 고유 ID로 인증 기능이 없습니다.
사용자 정의 메타데이터
Content-Type, Cache-Control, Expires, x-cos-meta-* 등 객체의 사용자 정의가 가능한 매개변수를 의미합니다. 자세한 내용은 사용자 정의 Headers를 참조하십시오.
COS는 버킷 및 객체와 관련된 서브 리소스를 가집니다. 서브 리소스는 객체에 종속되므로 독립적으로 존재할 수 없고, 객체 또는 버킷과 같은 다른 엔티티와 연결됩니다. 액세스 제어 리스트(Access Control List)는 특정 객체의 액세스 제어 정보 리스트를 의미하며 COS에서 객체의 서브 리소스 역할을 합니다.
액세스 제어 리스트는 권한을 보유한 계정과 허가된 권한 리스트로 나눌 수 있고, 이를 통해 객체의 액세스 제어를 관리합니다. 객체 생성 시 ACL은 객체를 전체 제어할 수 있는 객체 소유자를 식별합니다. 사용자는 객체 ACL을 인덱스하거나 업데이트된 권한 리스트로 교체할 수 있습니다.
설명：
ACL을 업데이트하려면 기존 ACL을 교체해야 합니다.
액세스 권한 유형
COS는 공개 권한과사용자 권한이라는 2가지 객체 권한 설정 유형을 지원합니다.
공개 권한은 권한 상속, 개인 읽기/쓰기와 공개 읽기/쓰기를 포함합니다.
권한 상속: 객체가 버킷 권한을 상속하여 버킷과 액세스 권한이 일치합니다. 객체에 액세스할 경우 COS가 객체 권한을 버킷 권한 상속으로 인식하면 버킷과 권한을 매칭하여 액세스에 응답합니다. 다른 새로운 객체를 추가할 경우 버킷 권한의 상속을 기본으로 합니다.
개인 읽기/쓰기: 객체에 액세스할 경우 COS가 객체 권한을 개인 읽기/쓰기로 인식하면 버킷의 권한 종류와 무관하게 Request Signature를 통해서 액세스해야 합니다.
공개 읽기/개인 쓰기: 객체에 액세스할 경우 COS가 객체 권한을 공개 읽기로 인식하면 버킷의 권한 종류와 무관하게 객체를 바로 다운로드할 수 있습니다.
사용자 권한: 루트 계정은 기본적으로 객체에 대한 모든 권한 즉, 전체 제어 권한을 갖습니다. 그 외에, COS는 서브 계정을 추가 생성하여 데이터 읽기/쓰기, 권한 읽기/쓰기 및 전체 제어가 가능한 최고 권한을 갖도록 지원합니다.
적용 시나리오
개인 읽기/쓰기가 가능한 버킷에서 특정 객체에 공개 액세스를 설정했거나, 공개 읽기/쓰기가 가능한 버킷에서 특정 객체에 필요한 인증을 설정한 경우에만 액세스가 가능합니다.
스토리지 유형
스토리지 유형 개요
최종 업데이트 날짜:：2026-02-12 17:26:43
스토리지 유형은 Cloud Object Storage(COS)에서 객체의 스토리지 등급과 활성 정도를 나타냅니다. 접근 빈도와 재해 복구 수준에 따라 COS는 MAZ_STANDARD, MAZ_STANDARD_IA, MAZ_ARCHIVE, MAZ_INTELLIGENT_TIERING, INTELLIGENT_TIERING, STANDARD, STANDARD_IA, ARCHIVE, DEEP_ARCHIVE 등 다양한 스토리지 유형을 제공합니다. 각 스토리지 유형은 객체 접근 빈도, 데이터 내구성, 데이터 가용성 및 접근 지연 시간 등과 같은 서로 다른 특성을 가집니다. 사용자는 자신의 시나리오에 따라 어떤 스토리지 유형으로 데이터를 COS에 업로드할지 선택할 수 있습니다.COS에 있는 방법을 나타내며 액세스 빈도, 내구성, 가용성, 대기 시간 등이 서로 다릅니다. 필요에 따라 객체를 업로드할 스토리지 클래스를 선택할 수 있습니다.
주의：
객체를 업로드할 때, 스토리지 유형을 설정하지 않으면 기본적으로 STANDARD에 업로드됩니다.
MAZ_STANDARD 및 STANDARD 스토리지 클래스는 모두 핫 데이터용으로 설계된 매우 안정적이고 사용 가능하며 강력한 객체 스토리지 서비스이며 낮은 대기 시간과 높은 처리량을 특징으로 합니다.
MAZ_STANDARD는 STANDARD보다 데이터 내구성과 서비스 가용성이 높습니다. 동일한 리전의 다른 데이터 센터에 데이터를 저장하기 위해 다른 스토리지 메커니즘을 사용하여 한 데이터 센터의 장애가 전체 서비스에 영향을 미치지 않도록 방지하고 비즈니스 안정성을 더욱 보장합니다.
적용 시나리오
인기 동영상, 소셜 이미지, 모바일 앱, 게임 프로그램 및 정적 웹사이트를 포함하여 많은 핫스팟 파일 또는 빈번한 데이터 액세스와 관련된 시나리오에 적합합니다.
STANDARD 스토리지 클래스는 일반적인 사용을 위해 설계되었으며 대부분의 사용 사례를 다룹니다. MAZ_STANDARD보다 비용 효율적입니다.
그러나 MAZ_STANDARD는 데이터 내구성과 서비스 가용성이 더 높기 때문에 키 파일, 상업 데이터 및 민감한 정보를 포함하여 요구 사항이 더 높은 비즈니스 시나리오에 적합합니다.
MAZ_STANDARD_IA/STANDARD_IA
MAZ_STANDARD_IA 및 STANDARD_IA 스토리지 클래스는 스토리지 비용과 액세스 대기 시간이 낮은 매우 안정적인 객체 스토리지 서비스입니다. 저렴한 가격으로 밀리초 단위로 첫 번째 바이트에 액세스할 수 있으므로 기다리지 않고 신속하게 데이터를 검색할 수 있습니다. STANDARD와 달리 데이터에 액세스할 때 데이터 검색 요금이 부과됩니다.
MAZ_STANDARD_IA는 STANDARD_IA와 다른 스토리지 메커니즘을 사용하여 동일한 리전의 다른 데이터 센터에 데이터를 저장하여 한 데이터 센터의 장애가 전체 서비스에 영향을 미치지 않도록 방지하고 비즈니스 안정성을 한층 더 보장합니다.
적용 시나리오
클라우드 디스크 데이터, 빅데이터 분석, 정부 및 기업 데이터, 빈도가 낮은 아카이브, 모니터링 데이터 등 액세스 빈도가 낮은(예: 월 1 - 2회) 시나리오에 적합합니다.
주의：
MAZ_STANDARD_IA 및 STANDARD_IA 모두 최소 스토리지 요구 사항이 있습니다. 보관 기간이 30일 미만인 경우 청구서는 30일로 계산됩니다. 마찬가지로 파일 크기가 64KB 미만인 경우 요금은 64KB로 계산됩니다(파일 크기가 64KB보다 크거나 같으면 실제 파일 크기를 기준으로 요금이 계산됨). 자세한 내용은 가격 | Cloud Object Storage를 참고하십시오.
MAZ_INTELLIGENT_TIERING/INTELLIGENT_TIERING
MAZ_INTELLIGENT_TIERING 스토리지 클래스의 객체는 MAZ_STANDARD 및 MAZ_STANDARD_IA의 두 스토리지 레이어에 저장할 수 있습니다. INTELLIGENT_TIERING 스토리지 클래스의 객체는 STANDARD 및 STANDARD_IA의 두 스토리지 클래스에도 저장할 수 있습니다. COS는 데이터 검색 요금 발생 없이 객체의 액세스 빈도에 따라 스토리지 클래스 간에 자동으로 전환하므로 스토리지 요금이 절감됩니다. 자세한 내용은 INTELLIGENT_TIERING 개요를 참고하십시오.
MAZ_INTELLIGENT_TIERING은 INTELLIGENT_TIERING과 다른 스토리지 메커니즘을 사용하여 동일한 리전의 여러 데이터 센터에 데이터를 저장하여 한 데이터 센터의 장애가 전체 서비스에 영향을 미치지 않도록 방지하고 비즈니스 안정성을 더욱 보장합니다.
적용 시나리오
데이터 액세스 패턴이 불확실한 시나리오에 적합합니다. 비즈니스에서 비용을 엄격하게 제어하고 파일 읽기 성능에 덜 민감한 경우 MAZ_INTELLIGENT_TIERING 또는 INTELLIGENT_TIERING을 사용하여 비용을 줄일 수 있습니다.
주의：
MAZ_INTELLIGENT_TIERING 및 INTELLIGENT_TIERING의 경우 객체는 실제 크기를 기준으로 요금이 과금됩니다. 가격 책정에 대한 자세한 내용은 가격 | Cloud Object Storage를 참고하십시오.
MAZ_ARCHIVE/ARCHIVE
MAZ_ARCHIVE 및 ARCHIVE는 모두 콜드 데이터 유형에 속하며, 사용자에게 높은 신뢰성, 극도로 낮은 스토리지 비용 및 장기 보관을 위한 객체 저장 서비스를 제공합니다. MAZ_ARCHIVE 및 ARCHIVE 최소 저장 시간이 모두 90일이며, 데이터를 읽기 전에 데이터 복구(동결 해제)가 필요합니다.
COS는 ARCHIVE에 대해 다음 세 가지 복구 모드를 지원합니다.
고속 검색 모드: 1-5분 이내에 객체를 복구합니다.
일반 검색 모드: 3 - 5시간 이내에 객체를 복구합니다.
대량 검색 모드: 5 - 12시간 이내에 여러 객체를 복구합니다.
MAZ_ARCHIVE는 ARCHIVE와 비교하여, 데이터를 동일 도시의 다른 데이터 센터에 저장하는 다른 스토리지 메커니즘을 사용하여 사용자 비즈니스의 안정성이 단일 데이터 센터 장애의 영향을 받지 않도록 추가로 보장합니다.
MAZ_ARCHIVE 및 ARCHIVE는 모두 장기간 데이터 보관이 필요한 비즈니스 시나리오에 적합합니다. 예를 들어, 아카이브 데이터, 의료 영상, 과학 자료 등의 규정 준수 파일 아카이브, 라이프사이클 파일 아카이브, 운영 로그 아카이브 및 재해 복구에 사용됩니다.
주의：
MAZ_ARCHIVE 및 ARCHIVE는 모두 저장 시간과 저장 단위에 최소 제한이 있으며, 저장 시간이 90일 미만인 경우 90일로 계산됩니다. 단일 스토리지 파일이 64KB 미만인 경우 64KB로 계산되며, 64KB 이상인 경우 실제 크기로 계산됩니다. 가격 정보는 COS 가격을 참고하십시오.
DEEP_ARCHIVE
COS DEEP_ARCHIVE는 가장 낮은 스토리지 비용과 장기 데이터 보관을 제공하는 매우 안정적인 객체 스토리지 서비스입니다. 이 스토리지 클래스의 최소 보관 기간은 180일입니다. DEEP_ARCHIVE에 저장된 데이터를 읽으려면 먼저 STANDARD로 복구해야 합니다. 자세한 내용은 DEEP_ARCHIVE 소개를 참고하십시오.
COS는 DEEP_ARCHIVE에 대해 다음 두 가지 복구 모드를 지원합니다.
일반 검색 모드: 12 - 24시간 이내에 객체를 복구합니다.
대량 검색 모드: 24 - 48시간 이내에 여러 객체를 복구합니다.
설명：
데이터 복구 요청에는 QPS 제한이 있으며, 100회/초로 제한됩니다.
적용 시나리오
의료 영상, 뷰 데이터, 로그 데이터와 같은 장기 저장이 필요한 비즈니스 시나리오에 사용됩니다.
주의：
DEEP_ARCHIVE는 최소 스토리지 요구 사항이 있습니다. 보관 기간이 180일 미만인 경우 청구서는 180일로 계산됩니다. 마찬가지로 파일 크기가 64KB 미만인 경우 요금은 64KB로 계산됩니다(파일 크기가 64KB보다 크거나 같으면 실제 파일 크기를 기준으로 요금이 계산됨). 자세한 내용은 가격 | Cloud Object Storage를 참고하십시오.
스토리지 유형 비교
비교 항목
MAZ_STANDARD
MAZ_STANDARD_IA
MAZ_ARCHIVE
MAZ_INTELLIGENT_TIERING
INTELLIGENT_TIERING
STANDARD
STANDARND_IA
ARCHIVE
DEEP_ARCHIVE
스토리지 클래스 매개변수
MAZ_STANDARD
MAZ_STANDARD_IA
MAZ_ARCHIVE
MAZ_INTELLIGENT_TIERING
INTELLIGENT_TIERING
STANDARD
STANDARD_IA
ARCHIVE
DEEP_ARCHIVE
데이터 내구성
99.9999999999%
99.9999999999%
99.9999999999%
99.9999999999%
99.999999999%
99.999999999%
99.999999999%
99.999999999%
99.999999999%
서비스 가용성
99.995%
99.95%
99.50%
레벨 변환에 따라 변경됩니다. 고주파 방문 레벨에 있을 때, 서비스 가용성은 표준 저장소(다중 AZ)를 참조할 수 있습니다; 저주파 방문 레벨에 있을 때, 서비스 가용성은 저주파 저장소(다중 AZ)를 참조할 수 있습니다.
레벨 변환에 따라 변경됩니다. 고주파 방문 레벨에 있을 때, 서비스 가용성은 표준 저장소를 참조할 수 있습니다; 저주파 방문 레벨에 있을 때, 서비스 가용성은 저주파 저장소를 참조할 수 있습니다.
99.99%
99.90%
99.00%
99.00%
응답
밀리초
밀리초
사전에 복구를 신청해야 하며, 복구 작업은 세 가지 모드를 지원합니다.
빠른 복구 모드: 복구 작업은 1~5분 내에 완료될 수 있습니다.
표준 복구 모드: 복구 작업은 3~5시간 내에 완료됩니다.
일괄 복구 모드: 복구 작업은 5~12시간 내에 완료됩니다.
밀리초
밀리초
밀리초
밀리초
다음 세 가지 복구 모드 중 하나를 사용하여 미리 복구해야 합니다.
고속 검색 모드: 1 - 5분 이내에 객체를 복구합니다.
일반 검색 모드: 3 - 5시간 이내에 객체를 복구합니다.
대량 검색 모드: 5 - 12시간 이내에 여러 객체를 복구합니다.
두 가지 복원 모드 중 하나를 사용하여 미리 복원해야 합니다.
일반 검색 모드, 12 - 24시간 이내에 객체를 복구합니다.
대량 검색 모드, 24 - 48시간 내에 여러 객체를 복구합니다.
과금 가능한 최소 객체 크기
실제 객체 크기로 계산
64KB
64KB
실제 객체 크기로 계산
실제 객체 크기로 계산
실제 객체 크기로 계산
64KB
64KB
64KB
최소 보관 기간
제한 없음
30일
90일
제한 없음
제한 없음
제한 없음
30일
90일
180일
지원 리전
현재 베이징, 상하이, 광저우, 중국 홍콩, 싱가포르, 상하이 금융 리전만 지원됨
현재 베이징, 상하이, 광저우, 중국 홍콩, 싱가포르, 상하이 금융 리전만 지원됨
현재 베이징, 상하이, 광저우, 중국 홍콩, 싱가포르, 상하이 금융 리전만 지원됨
베이징, 상하이, 광저우, 싱가포르만 해당
현재 지원되는 지역은 베이징, 난징, 상하이, 광저우, 청두, 충칭, 싱가포르, 도쿄, 프랑크푸르트, 버지니아입니다.
모든 리전
모든 리전
퍼블릭 클라우드 지역(리야드를 제외하고), 금융 클라우드 지역에 적용
베이징, 난징, 상하이, 광저우, 청두, 충칭, 도쿄, 싱가포르만 해당
스토리지 요금
비교적 높음
비교적 높음
매우 낮음
인텔리전트 티어링 후 스토리지 클래스에 따라 다름
인텔리전트 티어링 후 스토리지 클래스에 따라 다름
표준
낮음
매우 낮음
매우 낮음
데이터 검색 요금
없음
비교적 낮음, 실제 읽은 데이터 양에 따라 과금
높음, 실제 복구된 데이터 양에 따라 청구되며 복구 모드에 따라 비용이 다름
없음
없음
없음
비교적 낮음, 실제 읽은 데이터 양에 따라 과금
비교적 높음, 복구 모드에 따라 실제 복구된 데이터 양으로 과금
높음, 복구 모드에 따라 실제 복구된 데이터 양으로 과금
요청 요금
일반
비교적 높음
표준. 데이터는 MAZ_STANDARD로 복구되어야 함
비교적 높음, 또한 INTELLIGENT_TIERING 객체 모니터링 요금이 과금됨
비교적 높음, 또한 INTELLIGENT_TIERING 객체 모니터링 요금이 과금됨
표준
비교적 높음
일반(데이터를 먼저 STANDARD로 복구해야 함)
높음(데이터를 먼저 STANDARD로 복구해야 함). DEEP_ARCHIVED 데이터를 검색하려면 데이터 검색에 대한 요청 요금이 발생함
데이터 처리
지원
지원
지원되지만 먼저 복구해야 함
지원
지원
지원
지원
지원(먼저 데이터 복구 필요)
지원(먼저 데이터 복구 필요)
스토리지 유형의 전환
COS는 활성 객체가 COS에 있는 방식을 나타내는 다양한 스토리지 유형을 제공합니다. 여전히 필요에 따라 객체의 스토리지 유형을 변경하거나 객체를 STANDARD_IA, ARCHIVE 또는 DEEP_ARCHIVE와 같은 덜 활성화된 스토리지 유형으로 전환할 수 있습니다.
설명：
변환 저장 유형 시, 현재 객체가 있는 스토리지 버킷이 해당 저장 유형을 지원하는지 먼저 확인하십시오.
객체가 아카이브 유형(예: ARCHIVE, DEEP_ARCHIVE 등)인 경우, 다른 스토리지 유형으로 변경하려면 STANDARD 유형(예: STANDARD)으로 먼저 복구해야 합니다. 자세한 내용은 아카이브된 객체 복구를 참고하십시오.
DEEP ARCHIVE는 Cloud Object Storage(COS)가 제공하는 보관 서비스로, 방대한 데이터를 장기간 보관할 수 있는 서비스입니다. DEEP ARCHIVE는 테이프 스토리지 등급별 스토리지 단가를 제공하며, 사용자의 데이터 장기 저장을 위한 저비용 솔루션을 제공합니다. 사용자는 로컬에서 복잡한 테이프 라이브러리 설정을 점검하거나 기저에 있는 스토리지 미디어의 발전에 관심을 기울일 필요가 없습니다. 객체 스토리지 COS가 제공하는 API, SDK, 생태 툴 및 콘솔과 같이 사용자와 컴퓨터 간의 풍부한 인터랙티브 수단을 통해 데이터를 저비용으로 간편하게 관리할 수 있기 때문입니다.
DEEP ARCHIVE는 데이터 액세스 빈도는 매우 낮지만 장기 보관이 필요한 시나리오에 적합합니다. 로그 콜드 스탠바이 시나리오에서 기업은 현지 법규에 따라 매일 발생하는 로그 데이터에 콜드 스탠바이를 실행하여 쉽게 추적 및 분석할 수 있습니다. 데이터 뷰 및 자율 주행 등의 비즈니스에서 기업은 대량의 이미지, 비디오 등 미디어 파일을 누적하게 되며 데이터를 사용한 후에도 장기간 보관하고 저장해야 합니다. 기업은 DEEP ARCHIVE를 통해 이러한 데이터를 클라우드에 저장하고 필요할 때만 복구하여 스토리지 비용을 낮추고 유지보수 관리의 어려움을 줄일 수 있습니다.
DEEP ARCHIVE는 99.999999999%의 내구성과 99.95%의 가용성을 위해 설계되었습니다. 또한 COS에서 제공하는 버전 관리 및 리전 간 복제 기능을 사용하여 데이터 보안을 추가로 보장할 수 있습니다.
6. SDK를 사용한 업로드
현재 COS에서 출시한 모든 SDK는 DEEP ARCHIVE로의 직접 업로드를 지원합니다. 파일을 업로드할 때 StorageClass 매개변수를 DEEP_ARCHIVE로 설정해야 합니다.
7. 툴을 사용한 업로드
COSBrowser, COSCMD 툴은 다이렉트 DEEP ARCHIVE를 지원합니다. 구체적인 방법은 파일 업로드 시, 헤더 필드 x-cos-storage-class를 늘리고 DEEP_ARCHIVE로 설정해 다이렉트 DEEP ARCHIVE를 구현하는 것입니다.
사용 제한
DEEP ARCHIVE는 다음과 같은 제한이 있습니다. 사용 과정에서 관련 제한이 스토리지 비용과 성능에 미치는 영향에 유의하십시오.
최소 스토리지 단위 제한: 최소 스토리지 단위는 64KB로, 64KB 이하의 객체는 64KB로 스토리지 용량을 계산합니다.
최단 스토리지 시간 제한: 최단 스토리지 시간은 180일로, 180일 이하는 180일로 과금됩니다.
설명：
스토리지 일수는 로직에 따라 24시간을 1일로 하며, 카운트 시작 시간은 파일 수정 시간으로 계산합니다.
검색 요청 QPS 제한: 100 요청/초.
지원 리전: 현재 베이징, 난징, 상하이, 광저우, 청두, 충칭, 도쿄 및 싱가포르 리전만 지원되며, 기타 리전은 순차적으로 지원 예정입니다.
사용 제한: 현재 DEEP ARCHIVE는 다중 AZ 버킷에 대해 지원되지 않습니다.
작업 제한: DEEP ARCHIVE 스토리지 클래스의 다른 객체에 객체를 추가할 수 없습니다.
검색 요청 제한: 객체에 대해 한 번에 하나의 검색 요청만 실행할 수 있으며, 여러 반복 요청은 병합되어 가장 빠른 검색 모드에 따라 처리됩니다. (N+1)번째 요청의 검색 모드가 N번째 요청보다 빠르면 (N+1)번째 요청이 새 요청으로 실행됩니다. 그렇지 않으면 실패합니다.
데이터 검색: DEEP ARCHIVE 스토리지 클래스의 파일에 대해 표준 검색(12 - 24시간) 및 대량 검색(24 - 48시간)이 지원됩니다.
INTELLIGENT TIERING 개요
최종 업데이트 날짜:：2026-04-02 10:50:03
개요
INTELLIGENT TIERING 유형은 데이터에 콜드/핫 레이어 메커니즘을 구분해 사용자 데이터의 액세스 모드에 따라 자동으로 데이터의 콜드/핫 레이어를 전환함으로써 사용자 데이터의 스토리지 비용을 줄일 수 있습니다.
INTELLIGENT_TIERING은 접근 패턴이 일정하지 않거나 접근 패턴을 예측할 수 없는 데이터에 적용되며, COS는 객체의 접근 상황을 모니터링하며, 스토리지 요금은 실제 데이터의 스토리지 계층(고빈도 접근 계층, 저빈도 접근 계층, 아카이브 계층, 딥 아카이브 계층)별로 부과됩니다.클라우드 스토리지 비용을 줄이기 위해 필요에 따라 액세스 패턴이 불확실한 객체의 스토리지 클래스를 STANDARD에서 INTELLIGENT TIERING으로 변경할 수 있습니다.
INTELLIGENT TIERING은 INTELLIGENT TIERING에 대한 스토리지 용량 및 객체 모니터링에 대한 요금이 발생하는 독립형 스토리지 클래스입니다. INTELLIGENT TIERING 스토리지 팩을 구매하여 사용할 수 있습니다. 자세한 가격은 제품 가격을 참고하십시오.
MAZ 버킷은 INTELLIGENT_TIERING 아카이브/딥 아카이브 계층 구성 활성화를 지원하지 않습니다.
강점
사용자가 데이터를 업로드할 때 INTELLIGENT TIERING 유형을 선택해 COS에 보관할 경우, COS는 주기적으로 데이터 액세스 횟수를 모니터링하며 데이터 액세스가 일정 기간 지속되지 않을 경우 데이터를 스토리지 비용이 더 저렴한 액세스 레이어로 이동합니다. 데이터가 다시 액세스되면, 다시 고빈도 액세스 레이어로 이동해 데이터 읽기 성능을 보장합니다. 데이터 핫/콜드 티어링 스토리지를 통해 사용자가 스토리지 비용과 읽기 성능 사이에서 균형점을 찾을 수 있게 도와줍니다. INTELLIGENT TIERING은 다음과 같은 장점이 있습니다.
비용 집약: 데이터를 지속적으로 INTELLIGENT TIERING 유형으로 저장할 경우, 저장 시간이 길어질수록 STANDARD 스토리지 비용은 상대적으로 낮아져 최대 20% 정도의 스토리지 비용을 절약할 수 있습니다. INTELLIGENT TIERING 유형은 객체 스토리지 라이프사이클 프로세스에 관여하여, 사용자는 필요에 따라 INTELLIGENT TIERING을 ARCHIVE로 전환해 데이터 저장 비용을 더 낮출 수 있습니다.
안정성 및 내구성: INTELLIGENT TIERING은 STANDARD 스토리지와 동일한 짧은 딜레이 시간, 높은 처리량을 제공합니다. 또한 삭제 코드를 사용하여 중복성을 달성함으로써 최대 99.999999999%(11개 9)의 안정성과 블록 스토리지 및 동시 읽기/쓰기를 사용하여 최대 99.99%의 가용성을 제공합니다. MAZ_INTELLIGENT TIERING은 최대 99.9999999999%(12개 9)의 안정성과 최대 99.995%의 가용성을 제공합니다.
편리성: 데이터에 객체 스토리지 유형만 지정하면 INTELLIGENT TIERING의 특징을 적용할 수 있습니다. INTELLIGENT TIERING 스토리지 유형은 COS의 API, SDK, 툴 및 생태 애플리케이션에 자연스럽게 융합되어, 사용자가 필요에 따라 클라우드에 저장된 데이터를 관리할 수 있게 합니다.
지원되는 스토리지 계층
설명:
64KB 이하의 작은 파일은 스탠다드 접근 계층에 유지되고, 저빈도 접근 계층, 아카이브 계층, 딥 아카이브 계층으로 이동되지 않습니다.
사용자는 API HEAD Object에서 반환된 헤드 x-cos-storage-tier를 통해 INTELLIGENT_TIERING 객체가 어느 계층에 있는지를 조회할 수 있습니다. 또한, API GET Bucket (List Objects) 및 GET Bucket Object Versions 를 호출하여 반환되는 객체 목록에서, INTELLIGENT_TIERING 객체는 객체가 위치한 계층을 조회하기 위한 필드 StorageTier를 반환합니다.
접근 계층
x-cos-storage-tier
고빈도 접근 계층
FREQUENT
저빈도 접근 계층
INFREQUENT
아카이브 계층
ARCHIVE_ACCESS
딥 아카이브 계층
DEEP_ARCHIVE_ACCESS
고빈도 접근 계층(기본 활성화)
INTELLIGENT_TIERING 객체 업로드 후 객체는 기본적으로 고빈도 접근 계층(FREQUENT) 상태에 있습니다. 객체가 본 계층에 위치한 경우, 스토리지 요금은 현재 리전의 표준 스토리지 정상가로 부과됩니다.
저빈도 접근 계층(기본 활성화)
버킷에 대해 INTELLIGENT_TIERING 구성을 활성화할 때 저빈도 접근 계층으로 전환되는 일수를 선택해야 하는데 30, 60, 90일을 선택할 수 있습니다. 일수는 설정 후 수정할 수 없습니다.
객체에 연속 30일(또는 60일, 90일) 동안 접근이 없는 경우, 객체는 고빈도 접근 계층에서 저빈도 접근 계층(INFREQUENT)으로 전환됩니다. 객체가 본 계층에 위치한 경우, 스토리지 요금은 현재 리전의 저빈도 스토리지 정상가로 부과됩니다. 해당 계층 객체는 접근된 후 다시 고빈도 접근 계층으로 돌아갑니다.
아카이브 계층(옵션)
아카이브 계층 객체는 먼저 복구 후 접근해야 합니다. 따라서, 아카이브 계층의 활성화는 옵션이며, 사용자는 하나 또는 다수의 INTELLIGENT_TIERING 아카이브 구성을 추가함으로써 지정 프리픽스, 태그를 갖는 객체에 대해 아카이브 계층을 활성화하고 전환 일수를 구성할 수 있습니다. 아카이브 계층의 전환 일수는 최소 91일이고 최대 730일입니다.
설명:
현재 리전이 아카이브를 지원하지 않고, 콘솔이 아카이브 구성 구칙 추가를 지원하지 않는 경우, INTELLIGENT_TIERING 객체는 아카이브 계층으로 이동되지 않습니다.
INTELLIGENT_TIERING 객체가 아카이브 계층에 위치하면, 스토리지 요금은 현재 리전의 아카이브 정상가에 따라 부과되고 조기 삭제 요금이 발생하지 않습니다.
아카이브 계층의 객체 복구
객체에 연속 N일 동안 접근이 없는 경우, 객체는 저빈도 접근 계층에서 아카이브 계층으로 전환됩니다. 일단 아카이브 계층에 들어가면 POST Object restore를 통해 복구한 후 데이터를 읽을 수 있습니다.
일반적인 아카이브 유형과는 달리, INTELLIGENT_TIERING 아카이브 계층 객체의 복구는 스탠다드 유형의 복사본이 생성되지 않고 객체 자체가 직접 고빈도 접근 계층으로 돌아갑니다.
일반적인 아카이브 유형과 같이, INTELLIGENT_TIERING 아카이브 계층 객체는 고속, 표준, 대량의 3가지 검색 모드를 지원합니다.
요금 측면에서:
INTELLIGENT_TIERING 아카이브 검색 요금:
표준 검색, 일괄 검색은 요금이 청구되지 않습니다.
빠른 검색은 요금이 부과되며, 가격은 동일한 리전 ARCHIVE의 빠른 검색 요금과 동일합니다.
INTELLIGENT_TIERING 아카이브 검색 요청 요금:
표준 검색 요청, 일괄 검색 요청은 요금은 청구되지 않습니다.
빠른 검색 요청은 요금이 청구되며, 가격은 동일한 리전 ARCHIVE의 빠른 검색 요청 요금과 동일합니다. ARCHIVE 빠른 검색 요청이 현재 요금이 청구되지 않으므로 여기서 INTELLIGENT_TIERING 아카이브 빠른 검색 요청도 일관성을 유지하도록 요금이 청구되지 않습니다.
딥 아카이브 계층(옵션)
마찬가지로, 딥 아카이브 계층 객체는 복구 후 접근이 가능합니다. 따라서, 딥 아카이브 계층의 활성화는 옵션이며, 사용자는 하나 또는 다수의 INTELLIGENT_TIERING 딥 아카이브 구성을 추가함으로써 지정 프리픽스, 태그를 갖는 객체에 대해 딥 아카이브 계층을 활성화할 수 있습니다. 동일한 규칙에서 아카이브 계층과 딥 아카이브 계층의 전환을 동시에 구성할 수 있습니다. 딥 아카이브 계층의 전환 일수는 최소 180일이고 최대 730일이며, 반드시 아카이브 계층의 전환 일수보다 커야 한다는 점에 유의해야 합니다.
설명:
현재 리전이 딥 아카이브를 지원하지 않고, 콘솔이 딥 아카이브 구성 구칙 추가를 지원하지 않는 경우, INTELLIGENT_TIERING 객체는 딥 아카이브 계층으로 이동되지 않습니다.
INTELLIGENT_TIERING 객체가 딥 아카이브 계층에 위치하면, 스토리지 요금은 현재 리전의 딥 아카이브 정상가에 따라 부과되고 조기 삭제 요금이 발생하지 않습니다.
딥 아카이브 계층의 객체 복구
객체에 연속 M일 동안 접근이 없는 경우, 객체는 저빈도 접근 계층/아카이브 계층에서 딥 아카이브 계층으로 전환합니다. 일단 딥 아카이브 계층에 들어가면 POST Object restore를 통해 복구한 후 데이터를 읽을 수 있습니다.
일반적인 딥 아카이브 유형과는 달리, INTELLIGENT_TIERING 딥 아카이브 계층 객체의 복구는 스탠다드 유형의 복사본이 생성되지 않고 객체 자체가 직접 고빈도 접근 계층으로 돌아갑니다.
일반 아카이브 유형과 같이, INTELLIGENT_TIERING 딥 아카이브 계층 객체는 표준, 대량의 2가지 검색 모드를 지원하고 검색 요금, 검색 요청 요금이 부과되지 않습니다.
INTELLIGENT_TIERING 아카이브 계층 및 딥 아카이브 계층 구성 활성화
규칙 설명
버킷의 INTELLIGENT_TIERING 구성이 활성화된 후, 사용자가 업로드한 INTELLIGENT_TIERING 객체는 기본적으로 고빈도 접근 계층, 저빈도 접근 계층 사이에서 전환되며, INTELLIGENT_TIERING 구성에 아카이브 및 딥 아카이브 계층 규칙을 추가한 후 아카이브, 딥 아카이브 계층의 전환을 활성화할 수 있습니다. 각 버킷은 최대 1000개 아카이브 및 딥 아카이브 계층의 구성 규칙 추가를 지원하며, 규칙에 포함되는 요소는 다음과 같다. 규칙 상세정보는 API 문서 PUT Bucket IntelligentTiering를 참고할 수 있습니다.
규칙 명칭(Id)
아카이브 및 딥 아카이브 규칙을 유일하게 식별하는 데 사용됩니다.
상태(Status)
아카이브 계층 및 딥 아카이브 계층은 활성화(Enabled) 또는 비활성화(Disabled)를 지원하며, 아카이브/딥 아카이브 계층 규칙이 설정되어 있어도 비활성화 상태에서는 실제로 아카이브 또는 딥 아카이브 계층으로 전환되지 않습니다.
적용 범위(Filter)
규칙의 적용 범위를 규정하는 것으로, 프리픽스 필터링 및 태그 필터링을 지원하며, 프리픽스 수는 1개를 초과하지 않고 태그 수는 10개를 초과하지 않습니다.
계층 설정
하나의 규칙에서 아카이브 계층과 딥 아카이브 계층의 전환 시간을 설정할 수 있으며, 해당 규칙이 설정되어야 INTELLIGENT_TIERING 객체는 아카이브, 딥 아카이브 계층의 전환이 활성화되며, 그렇지 않으면 고빈도 접근 계층, 저빈도 접근 계층 사이에서만 전환됩니다.
아카이브 계층(ARCHIVE_ACCESS): 91일～730일로 설정 가능합니다.
딥 아카이브 계층(DEEP_ARCHIVE_ACCESS): 180일～730일로 설정 가능합니다.
설명:
동일한 규칙에서 아카이브 계층과 딥 아카이브 계층 전환 규칙을 동시에 설정하는 경우, 딥 아카이브 전환 일수는 아카이브 전환 일수보다 많아야 합니다.
스토리지 계층 전환 순서
사용자는 아카이브 계층의 전환을 개별적으로 활성화하거나, 딥 아카이브 계층의 전환을 개별적으로 활성화하거나, 아카이브 및 딥 아카이브 계층의 전환을 동시에 활성화할 수 있습니다. 구성된 저빈도 접근 계층, 아카이브 계층, 딥 아카이브 계층의 전환 일수에 따라 계층별로 차례로 이동됩니다.
구성 예시
구성 상세정보
적용 결과
예시 1
저빈도 접근 계층 30일, 아카이브 계층 100일, 딥 아카이브 계층 190일
연속 30일 접근이 없으면 스탠다드 접근 계층에서 저빈도 접근 계층으로 전환됩니다.
연속 100일 접근이 없으면 저빈도 접근 계층에서 아카이브 계층으로 전환됩니다.
연속 190일 접근이 없으면 아카이브 계층에서 딥 아카이브 계층으로 전환됩니다.
예시 2
저빈도 접근 계층 30일, 딥 아카이브 계층 190일
연속 30일 접근이 없으면 스탠다드 접근 계층에서 저빈도 접근 계층으로 전환됩니다.
연속 190일 접근이 없으면 저빈도 접근 계층에서 딥 아카이브 계층으로 전환됩니다.
예시 3
저빈도 접근 계층 60일, 아카이브 계층 91일
연속 60일 접근이 없으면 스탠다드 접근 계층에서 저빈도 접근 계층으로 전환됩니다.
연속 91일 접근이 없으면 저빈도 접근 계층에서 아카이브 계층으로 전환됩니다.
아카이브 및 딥 아카이브 계층의 INTELLIGENT_TIERING 객체 복구
객체에 연속 여러 날 동안 접근이 없는 경우, 객체는 저빈도 접근 계층에서 아카이브 계층/딥 아카이브 계층으로 전환됩니다. 일단 아카이브 계층, 딥 아카이브 계층으로 들어가면 POST Object restore를 통해 복구한 후 데이터를 읽을 수 있습니다.
일반적인 아카이브 유형, 딥 아카이브 유형 객체의 복구와는 달리, INTELLIGENT_TIERING 아카이브 계층, 딥 아카이브 계층 객체의 복구는 스탠다드 유형의 복사본이 생성되지 않고 객체 자체가 직접 고빈도 접근 계층으로 돌아갑니다. 따라서, INTELLIGENT_TIERING 아카이브/딥 아카이브 계층 객체에 대해 검색 요청을 할 때 검색 일수를 지정할 필요가 없습니다.
일반적인 아카이브 유형과 같이, INTELLIGENT_TIERING 아카이브 계층 객체는 고속, 표준, 대량의 검색 모드를 지원하고, 일반적인 딥 아카이브 유형과 같이, INTELLIGENT_TIERING 딥 아카이브 계층 객체는 표준, 대량의 2가지 검색 모드를 지원합니다.
과금은 아카이브 계층의 고속 검색 요금(가격은 동일 리전의 아카이브 스토리지 고속 검색 요금과 동일함) 외에 검색 요금, 검색 요청 요금, 복구 복사본 스토리지 요금 등과 같은 기타 요금이 부과되지 않습니다.
아카이브 스토리지 유형
INTELLIGENT_TIERING 객체-아카이브 계층
딥 아카이브 스토리지 유형
INTELLIGENT_TIERING 객체-딥 아카이브 계층
스토리지 요금
현재 리전의 아카이브 스토로지 유형 스트로지 요금에 따라 부과됩니다.
현재 리전의 딥 아카이브 스토로지 유형 스트로지 요금에 따라 부과됩니다.
검색 후 복사본 생성 여부
예, 유지 일수를 지정해야 하고, 스탠다드 스토리지 가격에 따라 복사본 스토리지 요금이 발생합니다.
아니오, 복사본 스토리지 요금이 없습니다.
예, 유지 일수를 지정해야 하고, 스탠다드 스토리지 가격에 따라 복사본 스토리지 요금이 발생합니다.
아니오, 복사본 스토리지 요금이 없습니다.
검색 모드
고속 모드
표준 모드
대량 모드
고속 모드
표준 모드
대량 모드
표준 모드
대량 모드
표준 모드
대량 모드
검색 요금
(단위: USD/GB)
고속
아카이브 고속 검색 요금
INTELLIGENT_TIERING 아카이브 계층 고속 검색 요금(가격은 아카이브 스토리지와 동일함)
\
\
표준
아카이브 표준 검색 요금
무료
딥 아카이브 표준 검색 요금
무료
대량
아카이브 대량 검색 요금
무료
딥 아카이브 대량 검색 요금
무료
검색 요청 요금
(단위: USD/만 회)
현재 요금이 청구되지 않음
현재 요금이 청구되지 않음
딥 아카이브 표준 검색 요청 요금
딥 아카이브 대량 검색 요청 요금
무료
읽기/쓰기 요청 요금
복구 후의 스탠다드 스토리지 요금과 일치합니다.
INTELLIGENT_TIERING 읽기/쓰기 요청 요금
딥 아카이브 읽기/쓰기 요청 요금
INTELLIGENT_TIERING 읽기/쓰기 요청 요금
복구 과정에서 HeadObject를 통해 INTELLIGENT_TIERING 아카이브 계층/딥 아카이브 계층 객체의 복구 상태를 조회할 수 있습니다.
복구 상태에서 HEAD Object의 응답 헤드는 x-cos-restore 및 x-cos-restore-status를 포함하게 됩니다. 예를 들어, x-cos-restore: ongoing-request="true", cos-restore-status: tier="bulk"; request-date="Mon, 18 Nov 2019 09:34:50 GMT".
복구 완료 후 INTELLIGENT_TIERING 객체는 직접 고빈도 접근 계층으로 돌아가고,HEAD Object의 응답 헤더 x-cos-storage-tier 값은 FREQUENT입니다.
사용 방법
데이터를 INTELLIGENT_TIERING 유형으로 COS에 저장하려면 먼저 버킷의 INTELLIGENT TIERING 설정을 활성화해야 합니다. 활성화 후, 사용자가 객체를 업로드할 때 스토리지 유형을 INTELLIGENT TIERING 유형으로 지정하면 됩니다.
3. INTELLIGENT_TIERING을 설정할 버킷을 찾아 해당 버킷 이름을 클릭하여 버킷 관리 페이지로 이동합니다.
4. 기본 설정 > INTELLIGENT_TIERING을 클릭하여 INTELLIGENT TIERING 설정 항목을 찾은 후, 편집을 클릭해 현재 상태를 켜고 다음 설정 항목 설명에 따라 설정합니다.
주의:
INTELLIGENT_TIERING 설정이 완료되면 이후에는 종료하거나 일시 중지할 수 없습니다.
저빈도 계층 전환 일수: 이 매개변수는 저빈도 액세스 계층으로 전환되는 시간을 지정하며, 선택 가능한 일수는 30일, 60일, 90일입니다. 예를 들어 30일로 설정된 경우, 시스템은 연속 30일 동안 액세스가 없으면 객체를 고빈도 액세스 계층에서 저빈도 액세스 계층으로 이동시킵니다.
5. 설정 정보를 확인한 후 저장을 클릭하고, 안내에 따라 2차 확인을 완료하면 INTELLIGENT_TIERING이 활성화됩니다.
6. 활성화 후 INTELLIGENT_TIERING 아카이브 및 딥 아카이브 규칙 설정이 가능합니다. 즉, 설정 항목에서 지정한 범위 내의 INTELLIGENT TIERING 객체는 아카이브 계층과 딥 아카이브 계층으로 전환될 수 있습니다. INTELLIGENT TIERING 아카이브 및 딥 아카이브 규칙 구성이 필요하지 않다면 단계 10로 건너뛰십시오.
7. 규칙 추가를 클릭하면 설정 항목에 대한 설명은 다음과 같습니다.
규칙 이름: 규칙 이름을 입력합니다. 생성 후에는 수정할 수 없습니다.
적용 범위: 본 INTELLIGENT_TIERING 아카이브 및 딥 아카이브 규칙은 전체 버킷에 적용되거나 지정된 객체 범위에 적용할 수 있으며, 현재 다음 범위를 선택할 수 있습니다.
객체 접두사: 동일한 파일 접두사를 가진 객체에 대해 INTELLIGENT_TIERING 아카이브 및 딥 아카이브 규칙을 적용할 수 있습니다. 예: prefix/.
객체 태그: 동일한 태그가 있는 객체에 대해 INTELLIGENT_TIERING 아카이브 및 딥 아카이브 규칙을 적용할 수 있으며, 최대 10개의 태그를 지정할 수 있습니다. 영문 대소문자를 구분해야 합니다.
주의:
객체 접두사와 객체 태그를 동시에 지정할 수 있습니다. 객체 접두사와 객체 태그, 객체 태그 간은 모두 'AND' 관계로, 모든 조건이 동시에 충족되어야 합니다. 예를 들어 INTELLIGENT_TIERING 아카이브 및 딥 아카이브 규칙에서 객체 접두사를 doc으로 지정하고 객체 태그 키 값 쌍을 group = IT로 지정하면, 현재 버킷 내에서 객체 키 접두사가 doc이고 객체 태그가 group = IT인 모든 객체가 지정됩니다.
아카이브 규칙: INTELLIGENT_TIERING 객체가 아카이브 및 딥 아카이브로 전환되는 일수를 설정할 수 있으며, 최소 하나 이상을 지정해야 합니다.
8. 정보 확인 후 확인을 클릭하면 INTELLIGENT_TIERING 아카이브 및 딥 아카이브 규칙을 확인할 수 있습니다.
설명:
규칙의 적용 결과는 설정된 저빈도, 아카이브, 딥 아카이브 전환 일수에 따라 순차적으로 반영됩니다.
예를 들어 사용자가 세 가지 규칙을 설정한 경우: 저빈도 계층 전환 일수 30일, 아카이브 계층 전환 일수 100일, 딥 아카이브 계층 전환 일수 190일로 지정했다면, 적용 결과는 다음과 같습니다. 지정된 범위 내 INTELLIGENT_TIERING 객체가 30일간 액세스되지 않으면 표준 계층에서 저빈도 계층으로 전환되고, 100일간 액세스되지 않으면 저빈도 계층에서 아카이브 계층으로 전환되며, 190일간 액세스되지 않으면 아카이브 계층에서 딥 아카이브 계층으로 전환됩니다.
9. INTELLIGENT_TIERING 아카이브 및 딥 아카이브 규칙을 중지해야 할 경우 편집을 클릭하여 해당 규칙의 상태를 비활성화로 수정하거나 라이프사이클 규칙을 직접 삭제하면 됩니다.
10.
INTELLIGENT_TIERING 설정을 활성화한 후 왼쪽 네비게이션 바에서 파일 목록을 클릭합니다.
11. 파일 목록 페이지에서 파일 업로드를 클릭합니다.
12. 팝업창에서 파일 업로드를 선택하고 매개변수 설정을 클릭하여 객체 속성을 설정한 후 스토리지 유형 설정 항목에서 INTELLIGENT_TIERING을 선택합니다.
13. 업로드를 클릭하면 객체를 INTELLIGENT_TIERING 유형으로 업로드할 수 있으며, COS는 자동으로 데이터 스토리지 계층 변환을 수행합니다. 업로드 작업에 대한 기타 설정 항목 설명은 객체 업로드를 참고하십시오.
클라우드 상의 데이터를 INTELLIGENT_TIERING으로 전환
다음 단계를 참고하여 업로드된 인벤토리 데이터를 INTELLIGENT_TIERING 유형으로 전환할 수 있습니다.
1. 버킷 설정 페이지에서 라이프사이클 규칙을 생성합니다. 자세한 내용은 라이프사이클 설정 문서를 참고하십시오.
2. 지정된 규칙의 응용 범위를 설정하고 데이터를 INTELLIGENT_TIERING으로 전환합니다.
REST API 사용
다음 API를 통해 INTELLIGENT_TIERING을 직접 설정할 수 있습니다.
1. 먼저 REST API를 사용해 버킷의 INTELLIGENT_TIERING을 활성화합니다. 다음 API 문서를 참고하십시오.
현재 모든 COS SDK는 INTELLIGENT TIERING 및 MAZ_INTELLIGENT TIERING을 지원합니다. 이러한 스토리지 클래스를 사용하려면 파일을 업로드할 때 StorageClass를 INTELLIGENT_TIERING 또는 MAZ_INTELLIGENT_TIERING으로 설정하십시오. 객체 업로드 SDK 문서는 객체 업로드를 참고하십시오.
사용 제한
INTELLIGENT TIERING 사용에는 다음과 같은 제한이 있습니다.
구성 제한: 지능형 계층화가 활성화되면 비활성화할 수 없습니다. 지능형 계층화가 필요하지 않은 경우 파일의 스토리지 클래스를 변경할 수 있습니다.
변환 일수 제한: 한 번 설정된 변환 일수는 수정할 수 없습니다. 저빈도 액세스 계층의 변환 일수는 30, 60 또는 90일이며, 아카이브 계층의 변환 일수는 최소 91일, 최대 730일이어야 합니다. 깊은 아카이브 계층의 변환 일수는 최소 180일, 최대 730일이어야 하며, 아카이브 계층의 변환 일수보다 커야 합니다.
초기 스토리지 레이어 제한: INTELLIGENT TIERING 유형의 신규 객체는 기본적으로 고빈도 액세스 레이어에 저장됩니다. 일정 기간 동안 액세스가 없는 상태가 지속되어야만 저빈도 액세스 레이어로 전환됩니다.
최소 스토리지 단위 제한: 64KB 이하 객체는 고빈도 액세스 레이어에 영구 저장되며, 고빈도 액세스 레이어와 저빈도 액세스 레이어 간 전환은 불가합니다. 단일 스토리지 파일의 크기에 관계없이 실제 데이터 크기에 따라 과금됩니다.
작업 제한: 추가 업로드 인터페이스 통해 객체를 INTELLIGENT TIERING 유형으로 업로드하는 기능은 지원하지 않습니다.
라이프사이클 제한: INTELLIGENT TIERING 유형은 ARCHIVE 또는 DEEP ARCHIVE 유형으로만 전환될 수 있습니다. STANDARD 스토리지 유형이 INTELLIGENT TIERING 유형으로 전환될 때는 고빈도 액세스 레이어에 저장되며, STANDARD_IA 스토리지 유형이 INTELLIGENT TIERING 유형으로 전환될 때는 STANDARD_IA 스토리지 액세스 레이어에 저장됩니다.
버킷 복사 제한: 버킷 복사 시, 타깃 버킷의 INTELLIGENT TIERING 설정이 활성화되지 않았을 경우 객체를 INTELLIGENT TIERING 유형으로 복사할 수 없습니다.
FAQ
INTELLIGENT TIERING은 어떻게 과금되나요?
INTELLIGENT TIERING에는 INTELLIGENT TIERING 용량 요금 및 INTELLIGENT TIERING 객체 모니터링 요금이 포함됩니다. 그 중:
INTELLIGENT TIERING 용량 요금은 파일이 위치한 스토리지 레이어에 따라 다른 스토리지 요금을 부과합니다.
파일이 고빈도 레이어에 있을 경우 STANDARD 스토리지 요금에 따라 과금됩니다.
파일이 STANDARD_IA 레이어에 있을 경우 STANDARD_IA 스토리지 용량 요금에 따라 과금됩니다.
설명：
STANDARD 스토리지 및 STANDARD_IA 스토리지 용량 요금은 퍼블릭 클라우드 리전에 따라 가격이 상이하며, 구체적인 가격은 가격 | Cloud Object Storage를 참고하십시오.
INTELLIGENT TIERING 객체 모니터링 요금은 저장된 객체 수에 따라 부과됩니다(64KB 미만 파일 제외). 자세한 가격은 가격 | Cloud Object Storage를 참고하십시오.
예시
한 회사에 10만 개의 객체(모두 64KB 이상, 총 1TB)가 있고 데이터가 베이징 리전의 INTELLIGENT TIERING 스토리지 클래스에 저장되고 30일 후에 자주 액세스하지 않는 티어로 전환된다고 가정합니다. 객체의 20%(즉, 객체 2만 개)가 30일마다 비정기 액세스 티어로 전환되는 경우 매 30일 간의 객체 모니터링 요금 및 스토리지 사용 요금은 다음과 같습니다.
설명：
아래 표에서 베이징 리전 객체 모니터링 요금의 월 단가는 0.25 USD/만 개 객체이며, ‘일 단가 = 월 단가 / 30’의 변환 로직에 따르면 일 단가는 0.00833333 USD/만 개 객체/일입니다.
저장 일수
객체 모니터링 요금(USD)/30일
INTELLIGENT TIERING 스토리지 사용 요금(USD)/30일
STANDARD 스토리지 사용 요금(USD)/30일
30 x 1
0.25 USD/만 개 객체 x 10만
1024 x 0.024 / 30 x 30 = 24.58
1024 x 0.024 / 30 x 30 = 24.58
30 x 2
0.25 USD/만 개 객체 x 10만
819.2 x 0.024 / 30 x 30 + 204.8 x 0.08 / 30 x 30 = 23.35
1024 x 0.024 / 30 x 30 = 24.58
30 x 3
0.25 USD/만 개 객체 x 10만
655.36 x 0.024 / 30 x 30 + 368.64 x 0.08 / 30 x 30 = 22.36
1024 x 0.024 / 30 x 30 = 24.58
30 x 4
0.25 USD/만 개 객체 x 10만
524.288 x 0.024 / 30 x 30 + 499.712 x 0.08 / 30 x 30 = 21.58
1024 x 0.024 / 30 x 30 = 24.58
30 x 5
0.25 USD/만 개 객체 x 10만
419.4304 x 0.024 / 30 x 30 + 604.5696 x 0.08 / 30 x 30 = 20.95
1024 x 0.024 / 30 x 30 = 24.58
30 x 6
0.25 USD/만 개 객체 x 10만
335.54432 x 0.024 / 30 x 30 + 688.45568 x 0.08 / 30 x 30 = 20.45
1024 x 0.024 / 30 x 30 = 24.58
스토리지 기간이 길어질수록 30일 마다 소액의 모니터링 비용만 지불하면 되므로 상당한 비용 절감 효과를 얻을 수 있음을 알 수 있습니다.
INTELLIGENT TIERING은 어떤 유형의 파일에 적용됩니까?
INTELLIGENT TIERING은 오디오/비디오, 로그와 같이 파일 크기가 평균적으로 큰 파일에 적합하며 액세스 모드는 고정되어 있지 않습니다. 평균 파일 용량이 클수록 각 파일의 GB당 지불해야 하는 모니터링 비용이 줄어듭니다. 비즈니스 액세스 모드가 상대적으로 고정되어 있으면 INTELLIGENT TIERING을 사용할 필요 없이 라이프사이클을 통해 지정된 시간을 설정하여 STANDARD_IA 스토리지로 전환할 수 있습니다.
INTELLIGENT TIERING으로 파일을 저장하는 방법은 무엇입니까?
다음 두 가지 방법으로 파일을 INTELLIGENT TIERING으로 저장할 수 있습니다.
추가 파일: 업로드 시 스토리지 유형을 INTELLIGENT TIERING으로 지정하기만 하면 파일을 INTELLIGENT TIERING으로 저장할 수 있습니다.
기존 파일: COPY 인터페이스를 통해 파일 스토리지 유형을 INTELLIGENT TIERING 유형으로 수정하거나 라이프사이클 기능을 사용하여 STANDARD 스토리지 및 STANDARD_IA 스토리지 유형을 INTELLIGENT TIERING 유형으로 전환할 수 있습니다.
주의：
64KB보다 작은 INTELLIGENT TIERING 객체는 항상 STANDARD에 저장됩니다. 이러한 객체의 경우 비용 절감을 위해 필요에 따라 STANDARD, STANDARD_IA, ARCHIVE 또는 DEEP ARCHIVE 스토리지 클래스에 업로드하는 것이 좋습니다.
INTELLIGENT TIERING 설정을 끄는 방법은 무엇입니까?
INTELLIGENT TIERING은 활성화 후 비활성화할 수 없습니다. 파일을 INTELLIGENT TIERING으로 저장할 필요가 없는 경우 파일을 업로드할 때 파일 스토리지 유형을 STANDARD 스토리지, STANDARD_IA 스토리지, ARCHIVE 또는 DEEP ARCHIVE로 지정하기만 하면 됩니다.
INTELLIGENT_TIERING 아카이브 계층/딥 아카이브 계층 규칙은 삭제 가능하므로, 새로운 INTELLIGENT_TIERING 객체가 아카이브/딥 아카이브 계층으로 이동되는 것을 방지하기 위해 해당 규칙을 삭제할 수 있다.
INTELLIGENT_TIERING의 아카이브 및 딥 아카이브 계층의 과금 방식？
스토리지 요금: 동일 리전 아카이브 및 딥 아카이브 스토리지에 따라 과금됩니다.
검색 요금, 검색 요청 요금: 아카이브 계층 고속 검색 요금 외에 기타 검색 요금, 검색 요청 요금은 부과되지 않습니다.
복구 복사본 요금: 없습니다.
다이렉트 업로드 아카이브
최종 업데이트 날짜:：2024-06-24 16:12:03
소개
현재 Cloud Object Storage(COS)는 다이렉트 업로드 아카이브를 지원하며, 객체를 다이렉트 아카이브 유형으로 설정하여 COS에 업로드할 수 있습니다. 다이렉트 아카이브 방법에는 콘솔, API, SDK, COSCMD 등이 있습니다. 또한 COS의 라이프 사이클 기능을 통해 업로드된 객체를 아카이브 유형 또는 딥 아카이브 유형으로 전환할 수 있습니다. 아카이브 유형에 대한 자세한 소개는 스토리지 유형 개요를 참고하십시오.
아카이브 다이렉트 업로드 방법
콘솔 업로드
COS 콘솔의 파일 업로드에서 업로드할 객체를 선택한 후 객체 속성 설정에서 스토리지 유형에 ARCHIVE나 DEEP ARCHIVE를 선택합니다. 자세한 내용은 객체 업로드를 참고하십시오.
API 업로드
PUT Object, POST Object, Initiate Multipart Upload 중에서 x-cos-storage-class를 ARCHIVE 혹은 DEEP_ARCHIVE으로 설정하여 아카이브 다이렉트 업로드를 합니다.
주의：
Append Object는 다이렉트 업로드 아카이브를 지원하지 않습니다.
SDK 업로드
현재 COS에서 배포하는 모든 SDK는 아카이브 다이렉트 업로드를 지원합니다. 파일 업로드 시 StorageClass 매개변수를 ARCHIVE나 DEEP_ARCHIVE로 설정하여 아카이브 다이렉트 업로드를 구현할 수 있습니다.
아카이브와 딥 아카이브 유형의 객체 다운로드는 스탠다드 스토리지/스탠다드IA 스토리지와 다르게 아카이브 다운로드 전에 복구 작업(동결 해제)을 진행해야 합니다. 복구가 완료되면 다운로드가 가능하며 복구 작업은 아래 3가지 방식으로 할 수 있습니다.
고속 검색 모드: 소요 시간이 가장 짧으며 일반적으로 데이터를 검색하는 데 1 - 5분 정도 소요됩니다.
일반 검색 모드: 일반 검색 모드를 사용하면 일반적으로 데이터를 검색하는 데 3 - 5시간 정도 소요됩니다.
대량 검색 모드: 비용이 가장 적게 들며 일반적으로 데이터를 검색하는 데 5 - 12시간 정도 소요됩니다.
설명：
딥 아카이브 유형 파일은 고속 검색 모드의 복구 형식을 지원하지 않습니다. 일반 검색 모드일 경우 복구하는 데 12 - 24시간 소요되며 대량 검색 모드일 경우 24 - 48시간 소요됩니다.
콘솔, API, SDK, COSCMD 툴은 아카이브 복구와 다운로드를 모두 지원합니다.
아카이브 다이렉트 업로드 제한 설명
아카이브와 딥 아카이브 유형의 객체를 다운로드할 때 먼저 복구를 진행한 후 다운로드해야 합니다.
아카이브와 딥 아카이브 유형의 객체를 복사할 때 먼저 복구를 진행하고 복사할 수 있습니다.
아카이브와 딥 아카이브 유형의 객체는 리전 간 복제를 지원하지 않습니다.
아카이브와 딥 아카이브 유형 객체는 스탠다드 스토리지, 스탠다드IA 스토리지와 같은 활발한 스토리지 유형으로 전환할 수 없습니다.
스토리지 유형 수정
최종 업데이트 날짜:：2025-11-10 17:33:34
소개
개체 저장소 콘솔을 통해 업로드한 개체의 저장 유형을 언제든지 수정하여 다양한 시나리오의 비즈니스 요구 사항을 충족할 수 있습니다. 개체 저장소 COS는 다양한 저장 유형을 제공합니다: MAZ_STANDARD / STANDARD, MAZ_STANDARD_IA / STANDARD_IA, MAZ_INTELLIGENT TIERING / INTELLIGENT TIERING, MAZ_ARCHIVE / ARCHIVE 및 DEEP ARCHIVE. 자세한 내용은 스토리지 유형 개요를 참고하십시오. 다음 섹션에서는 객체의 스토리지 유형을 수정하는 방법을 안내합니다.
설명：
개체가 표준 MAZ_STANDAR D , MAZ_STANDARD_IA 등 다중 AZ 저장 유형인 경우, 저장 유형을 비다중 AZ 유형(예: STANDARD_IA, ARCHIVE)으로 다운그레이C드하는 것은 당분간 지원되지 않습니다.
아카이브 유형(예: ARCHIVE, DEEP ARCHIVE)에 속하는 경우, 다른 저장 유형으로 수정하려면 표준 유형(예: STANDARD)으로 복원해야 합니다. 자세한 내용은 아카이브된 객체 복구를 참고하십시오.
5. 대상 객체를 찾고 오른쪽의 작업 열에서 더 보기 > 스토리지 유형 수정을 클릭합니다.
6. 여러 객체의 스토리지 유형을 일괄 수정하려면 여러 객체를 선택하고 상단의 추가 작업 > 스토리지 유형 수정을 클릭합니다.
7. 대상 스토리지 유형을 선택하고 팝업 창에서 확인을 클릭합니다.
객체 업로드
간편 업로드
최종 업데이트 날짜:：2025-09-23 15:22:11
간편 업로드란 PUT Object 인터페이스를 사용해 객체를 업로드하는 것을 의미하며, 5GB 이하 단일 객체 업로드 요청에 사용됩니다.
5GB를 초과하는 단일 객체는 다음 방법을 사용하여 업로드할 수 있습니다.
콘솔을 통한 업로드: 콘솔을 이용해 최대 512GB의 단일 객체를 업로드할 수 있습니다. 자세한 내용은 객체 업로드 콘솔 가이드 문서를 참조하십시오.
API/SDK를 통한 멀티파트 업로드: 최대 48.82TB(50000GB)의 단일 객체를 업로드할 수 있습니다. 자세한 내용은 멀티파트 업로드를 참조하십시오.
COSCMD 툴을 사용해 최대 40TB의 단일 객체를 업로드할 수 있습니다. 자세한 내용은 COSCMD 툴을 참조하십시오.
설명：
지정된 폴더 또는 경로로 업로드를 요청하는 경우 /를 사용할 수 있습니다(예시: picture.png를 doc 폴더에 업로드 하는 경우 객체 키를 doc/picture.png로 설정).
적용 시나리오
간편 업로드는 5GB 이하의 객체 업로드에 활용할 수 있습니다.
고대역폭 혹은 약한 네트워크 환경에서 업로드하는 객체 크기가 큰 경우(100MB 이상~5GB 이하인 경우) 우선적으로 멀티파트 업로드 사용을 권장합니다. 멀티파트 업로드는 여러 개의 파트가 병렬 전송되며, 고대역폭 환경에서 리소스를 효과적으로 이용할 수 있습니다. 약한 네트워크 환경에서 단일 파트 업로드에 실패한 경우, 이미 업로드된 다른 파트에 영향을 주지 않기 때문에 실패한 부분만 다시 업로드하여 전체 업로드 성공률을 높여 줍니다. 약한 네트워크 환경에서의 모바일 업로드에 대한 자세한 내용은 약한 네트워크에서의 멀티파트 업로드 재개 실행을 참조하십시오.
5. 팝업 창에서 파일 선택 또는 폴더 선택을 클릭하고 필요에 따라 하나 이상의 로컬 파일(또는 폴더)을 선택합니다.
설명：
일부 브라우저는 파일 업로드를 지원하지 않으므로 IE10 이상, Firefox, Chrome 등 주요 브라우저를 권장합니다.
6. (옵션) 매개변수 구성을 클릭하고.
7. (옵션) 파일 업로드 창에서 객체 속성을 설정합니다.
설정은 다음 내용을 참고하십시오.
스토리지 유형: 필요에 따라 객체의 스토리지 클래스를 선택합니다. 이 필드는 기본적으로 표준 스토리지로 설정됩니다. 자세한 내용은 스토리지 유형을 참고하십시오.
주의：
버킷에 MAZ 구성이 활성화된 경우 스토리지 유형은 MAZ_STANDARD와 같은 MAZ 활성화 스토리지 클래스만 선택할 수 있습니다. INTELLIGENT TIERING 구성도 활성화된 경우 INTELLIGENT TIERING(MAZ)을 선택할 수도 있습니다.
액세스 권한: 필요에 따라 객체에 대한 액세스 권한을 선택합니다. 이 필드는 기본적으로 상속으로 설정됩니다(즉, 버킷의 권한 상속). 자세한 내용은 액세스 제어 기본 개념을 참고하십시오.
서버 측 암호화：파일을 업로드하는 동시에, 객체의 서버 측 암호화 속성을 설정합니다. 텐센트 클라우드 COS는 업로드된 객체에 데이터 암호화 보호 정책을 추가하여, 데이터가 쓰여지기 전에 자동으로 암호화하고, 데이터에 접근할 때 자동으로 복호화합니다. 현재 SSE-COS, SSE-KMS를 지원하며, 서버 측 암호화에 대한 소개와 적용 지역은 서버 측 암호화 개요 를 참조하십시오.
객체 태그: 객체 태그는 태그 키(tagKey), 태그 값(tagValue) 및 등호’=’로 구성됩니다(예: group = IT). 지정된 객체의 태그를 설정, 쿼리 및 삭제할 수 있습니다.
메타데이터: 객체 메타데이터는 또는 HTTP Header는 HTML 데이터를 브라우저로 보내기 전에 HTTP를 통해 서버에서 보내는 문자열입니다. HTTP Header를 수정하면 웹 페이지가 응답하는 방식과 캐싱 시간과 같은 특정 구성을 수정할 수 있습니다. 객체의 HTTP Header를 수정해도 객체 자체는 수정되지 않습니다. 자세한 내용은 사용자 정의 Headers를 참고하십시오.
8. 업로드를 클릭합니다.
9. 페이지 오른쪽 상단의 ‘완료한 작업’에서 업로드 진행 상황을 확인할 수 있습니다. 업로드가 완료되면 업로드된 객체가 ‘파일 목록’에 나타납니다.
설명：
그림에서의 작업 진행 상황은 현재 작업한 작업의 수를 통계로 나타냅니다. 예를 들어, 10개 파일을 업로드하는 업로드 작업을 실행했고, 모두 성공적으로 업로드되었다면, 해당 작업 진행 상황은"작업 완료(성공 10개)"로 표시됩니다.
REST API 사용
REST API를 통해 직접 객체 간편 업로드 요청을 보낼 수 있습니다. 자세한 내용은 PUT Object API 문서를 참조하십시오.
SDK 사용
SDK 호출을 통해 직접 객체 간편 업로드를 진행할 수 있습니다. 자세한 내용은 다음 언어별 SDK 문서를 참조하십시오.
멀티파트 업로드는 전체 객체를 여러 파트로 나누어 Cloud Object Storage(COS)에 멀티파트 업로드할 수 있습니다. 업로드 시 연속 일련번호에 따라 단일 업로드하거나 임의 순서대로 파트를 각각 업로드하면 마지막에 COS에서 파트 일련번호 순서대로 객체를 다시 결합합니다. 전송 실패한 파트가 생기더라도 재전송할 수 있으며 다른 파트나 콘텐츠 완성도에 영향을 주지 않습니다. 일반적으로 약한 네트워크 환경에서 단일 객체가 20MB보다 크면 우선적으로 멀티파트 업로드를 고려할 수 있으며 고대역폭에서는 100MB가 넘는 객체는 멀티파트 업로드를 진행합니다.
멀티파트 업로드는 큰 객체를 최대 10000개 파트로 분할할 수 있습니다. 분할한 파트의 크기는 일반적으로 1MB - 5GB입니다. 마지막 파트는 1MB보다 작을 수 있습니다.
설명：
간단 업로드는 최대 5GB 파일까지 업로드할 수 있지만 멀티파트 업로드는 5GB 이상파일도 업로드 가능합니다.
적용 시나리오
멀티파트 업로드는 약한 네트워크 혹은 고대역폭 환경에서 크기가 비교적 큰 객체를 업로드할 경우 활용할 수 있습니다.
멀티파트 업로드의 장점은 다음과 같습니다.
약한 네트워크 환경에서 작은 크기의 파트로로 네트워크 연결 실패로 인한 업로드 중단 현상을 줄이고 객체 전송을 지속할 수 있습니다.
고대역폭 환경에서 객체 파트 동시 업로드 시 네트워크 대역폭을 충분히 이용할 수 있으며 비순차적 업로드가 최종 결합한 객체에 영향을 주지 않습니다.
멀티파트 업로드를 사용하면 언제든지 업로드를 중지하고 단일 대형 객체 업로드를 재개할 수 있습니다. 작업을 끝내지 않는 이상 작업 완료되지 않은 모든 객체는 언제든지 업로드를 지속할 수 있습니다.
멀티파트 업로드는 객체의 전체 크기를 모르는 상황에서 업로드할 때 활용하기도 합니다. 먼저 멀티파트 업로드를 진행한 후 객체를 결합하여 전체 크기를 얻을 수 있습니다.
사용 방법
REST API 사용
REST API를 통해 즉각적으로 멀티파트 업로드 요청을 보낼 수 있습니다. 자세한 내용은 다음 API 문서를 참조하십시오.
기본적으로 버킷과 객체는 개인 소유입니다. 서드 파티가 버킷에 객체를 업로드할 수 있지만 CAM 계정 혹은 임시 키 사용을 원치 않는 경우 임시 업로드 작업을 완료하기 위해 URL 사전 서명을 사용해 서드 파티에게 서명을 제출합니다. 유효한 서명 URL을 받은 계정은 모두 객체 업로드를 진행할 수 있습니다.
URL 사전 서명 시 서명에 객체 키를 설정하여 지정한 객체 키만 업로드할 수 있도록 허용합니다. 절차에서 사전 서명 URL의 유효 기간을 지정하여 해당 URL 기간 만료 후 사용 권한이 없는 계정의 사용을 막을 수 있습니다.
설명：
CDN 도메인에 접근하려면 CDN의 인증 프로세스를 따라야 하므로 COS 서명을 사용할 수 없으며, 따라서 사전 서명된 URL은 CDN 도메인을 지원하지 않습니다.
영구 키를 사용하여 사전 서명을 생성할 때 허가 범위는 업로드 또는 다운로드 작업으로 제한되며, 생성된 서명의 유효 기간은 업로드 또는 다운로드 작업을 완료하는 데 필요한 최단 기간으로 설정해야 합니다.
지정된 사전 서명 URL의 유효 기간이 만료되면 요청이 중단됩니다. 새로운 서명을 신청한 후 실패한 요청을 다시 실행해야 합니다.
사전 서명된 URL은 단일 객체에 대해서만 서명을 지원하며, 여러 객체는 지원하지 않습니다.
사전 서명된 URL 업로드 방식은 간단한 업로드만 지원하며, 최대 5GB 파일을 업로드할 수 있습니다. 청크 업로드(재개 업로드)는 지원하지 않습니다.
사용 방법
SDK 사용
SDK에서 사전 서명된 URL 메소드를 직접 호출할 수 있습니다. 자세한 내용은 다음 언어별 SDK 문서를 참고하십시오.
COS(Cloud Object Storage)에서 객체 다운로드 요청을 직접 시작할 수 있습니다. 다음 기능이 지원됩니다.
전체 객체 다운로드: GET 요청을 시작하여 전체 객체 데이터를 다운로드합니다.
객체의 일부 다운로드: GET 요청에서 Range 요청 헤더를 사용하여 객체의 특정 바이트 범위를 검색합니다. 여러 범위 검색은 지원되지 않습니다.
객체의 메타데이터는 객체의 콘텐츠와 함께 HTTP 응답 헤더로 반환됩니다. GET 요청은 URL 매개변수를 사용하여 응답에서 특정 메타데이터 값 덮어쓰기를 지원합니다.
예를 들어 Content-Disposition의 응답 값을 덮어쓸 수 있습니다. 수정을 지원하는 응답 헤더는 다음과 같습니다.
버킷과 객체는 기본적으로 개인 소유입니다. 3rd party가 객체를 다운로드할 수 있도록 허용하지만 CAM 계정 또는 임시 키 사용을 제한하고 싶은 경우, URL 사전 서명 방식으로 3rd party에 서명을 제출함으로써 다운로드 작업을 완료할 수 있습니다. 유효한 URL 사전 서명을 받은 계정은 모두 객체 다운로드를 진행할 수 있습니다.
URL 사전 서명 시 서명에 객체 키를 설정하여 지정한 객체만 다운로드할 수 있도록 허용합니다. 또한 프로세스에서 URL 사전 서명 유효 기간을 지정하여, 해당 기간 만료 후 권한이 없는 계정의 사용을 제한할 수 있습니다.
주의：
CDN 도메인 이름에 액세스하려면 CDN 인증 프로세스를 따라야 하며, COS 서명을 사용할 수 없으므로 사전 서명된 URL은 CDN 도메인 이름을 사용할 수 없습니다.
사용자는 임시 키를 사용하여 사전 서명을 생성하고, 임시 승인을 통해 사전 서명 업로드 및 다운로드 요청의 보안성을 강화할 것을 권장합니다. 임시 키 신청 시, 최소 권한의 원칙 관련 가이드를 준수하여 타깃 버킷이나 객체 이외의 리소스가 유출되지 않도록 하시기 바랍니다.
사전 서명을 생성하기 위해 영구 키를 사용해야 하는 경우 위험을 방지하기 위해 영구 키의 권한 범위를 업로드 또는 다운로드 작업으로 제한하는 것이 좋습니다. 그리고 생성된 서명의 유효 기간은 업로드 또는 다운로드 작업을 완료하는 데 필요한 가장 짧은 기간으로 설정합니다.
지정된 프리사인 URL의 유효 기간이 만료되면 요청이 중단됩니다. 새로운 서명을 신청한 후에는 실패한 요청을 다시 실행해야 하며, 중단된 지점에서 재개는 지원하지 않습니다.
프리사인 URL은 단일 객체에 대해서만 프리사인을 지원하며, 여러 객체는 지원하지 않습니다.
사용 방법
SDK 사용
SDK의 URL 사전 서명 방식을 호출할 수 있습니다. 자세한 내용은 다음 언어별 SDK 문서를 참조하십시오.
Tencent Cloud Object Storage(COS)는 버킷에 업로드된 단일 또는 다수 객체 삭제를 지원합니다. 콘솔, API, SDK 등 다양한 방법으로 객체를 일괄 삭제할 수 있습니다. 기본적으로 삭제 작업이 모두 성공적으로 완료되면 반환 내용은 일반적으로 비어 있습니다. 오류가 발생한 경우에는 오류 정보가 반환됩니다.
설명:
단일 요청으로 최대 1000개의 객체를 삭제할 수 있으며, 더 많은 객체를 삭제해야 할 경우 목록을 분할하여 별도로 요청을 보내야 합니다.
'폴더'를 삭제하기로 선택하면 '폴더' 아래의 모든 객체가 함께 삭제되며, 버전 관리가 활성화되지 않은 경우 삭제된 데이터는 복구 및 접근이 불가능합니다.
현재 버킷에 버전 관리(활성화 또는 일시 중지 상태 포함)가 설정된 경우 삭제 작업을 수행해도 객체가 실제로 삭제되지 않고 현재 버전 객체에 삭제 표시가 추가되며, 저장 용량도 줄어들지 않습니다. 객체를 실제로 삭제하려면 버전 ID를 지정해야 합니다. 자세한 내용은 버전 관리 개요를 참고하십시오.
대량의 데이터 또는 중첩된 폴더를 삭제해야 하는 경우 삭제를 완료하는 데 상당한 시간이 소요될 수 있으므로, 해당 시나리오에서는 라이프사이클 설정을 통해 삭제하는 것이 좋습니다.
적용 시나리오
Tencent Cloud COS는 하나 이상의 객체를 직접 삭제하는 기능을 지원합니다. 단일 객체를 삭제할 경우 객체 키만 제공하면 API 요청을 통해 삭제할 수 있습니다.
5. 삭제하려는 단일 또는 여러 객체를 선택한 후 상단의 추가 작업 > 삭제를 클릭합니다.
6. 팝업 알림 창에서 삭제를 클릭하면 객체가 삭제됩니다.
버전 관리 활성화/일시 중지된 버킷에서 객체 삭제
설명:
버킷에서 버전 관리 기능을 사용한 적이 있는 경우, 객체를 삭제할 때 버전 ID를 지정해야 실제로 객체가 삭제됩니다. 버전 ID를 지정하지 않고 객체를 삭제하면 객체가 실제로 삭제되지 않고 현재 버전의 객체에 삭제 표시가 추가됩니다. 자세한 내용은 버전 관리 개요를 참고하십시오.
지정된 버킷을 삭제하려고 했지만 시스템에서 ‘삭제에 실패했습니다. 먼저 버킷의 유효한 데이터를 삭제하십시오’라는 메시지가 표시되면 불완전한 멀티파트 업로드를 입력하여 완전히 업로드되지 않은 파일을 조회해 삭제할 수 있습니다. 전체 및 부분적으로 업로드된 모든 파일이 버킷에서 삭제되었음을 확인한 후에만 버킷을 삭제할 수 있습니다.
주의：
객체 업로드가 진행되는 동안 일시 중지되거나 취소된 파일은 불완전한 멀티파트 업로드에 표시됩니다. 파일은 완전히 업로드된 후에만 파일 리스트에서 볼 수 있습니다.
객체와 마찬가지로 불완전한 멀티파트 업로드는 스토리지 용량을 소모하고 스토리지 용량 비용을 발생시킵니다.
3. 삭제할 불완전한 멀티파트 업로드가 있는 버킷을 찾고 버킷 이름을 클릭하여 버킷 관리 페이지로 이동합니다.
4. 왼쪽 사이드바에서 기본 구성 > 라이프사이클을 클릭하여 라이프사이클 관리 페이지로 들어갑니다.
5. 규칙 추가를 클릭하면 아래와 같이 구성 항목을 볼 수 있습니다. 예를 들어 생성 후 7일이 지나면 버킷 전체에서 불완전한 멀티파트 업로드를 삭제하도록 설정할 수 있습니다.
6. 확인을 클릭하면 콘솔에서 이 새 라이프사이클 규칙을 볼 수 있습니다.
객체 검색
최종 업데이트 날짜:：2025-11-28 18:09:59
소개
COS 콘솔 또는 객체 키를 통해 업로드된 객체 및 폴더를 검색할 수 있습니다.
객체 키(ObjectKey)는 버킷 내 객체의 고유 식별자로, 일반적으로 파일 경로로 이해할 수 있습니다. 예를 들어 객체 키가 doc/picture.jpg인 경우, 이는 이미지 파일 picture.jpg가 COS의 doc 경로(또는 폴더)에 저장되어 있음을 의미합니다.
객체 키를 나열하면 지정된 객체 키로 특정 객체를 검색할 수 있습니다. 또한 객체 키 접두사로 객체를 검색할 수도 있습니다. 즉, 객체 키 앞부분의 일부(예: doc)를 지정하여 동일한 접두사 doc를 가진 모든 객체를 찾을 수 있습니다.
적용 시나리오
Tencent Cloud COS는 접두사 순서대로 객체 키를 나열하는 것을 지원합니다. 또한 객체 키에 / 문자를 사용하여 기존 파일 시스템과 유사한 계층 구조를 구현할 수 있으며, COS는 구분자를 사용한 계층 구조 선택 및 탐색도 지원합니다.
단일 버킷 내의 모든 객체 키를 나열할 수 있으며, 접두사의 UTF-8 바이너리 순서에 따라 나열하거나 특정 접두사를 지정하여 객체 키 목록을 필터링할 수 있습니다. 예를 들어 매개변수 t를 추가하면 tencent로 시작하는 객체를 나열하고 a 또는 다른 문자로 시작하는 객체는 건너뜁니다.
/ 구분자를 추가하면 이 구분자에 따라 객체 키가 재구성됩니다. 접두사와 구분자를 결합하여 폴더 검색과 유사한 기능을 구현할 수 있습니다.
Tencent Cloud COS는 단일 버킷에서 무제한의 객체를 지원하므로 객체 키 목록이 매우 길 수 있습니다. 관리 편의를 위해 단일 객체 나열 인터페이스는 최대 1000개의 객체 목록을 반환하며, 잘림 여부를 알려주는 표시기도 함께 반환됩니다. 잘림이 있는 경우 다음 페이지에 더 많은 객체 목록이 존재함을 의미합니다. 표시기와 구분자를 활용하여 객체 키 나열 요청을 여러 번보낼 수 있어 모든 객체 키를 나열하거나 필요한 내용을 조회할 수 있습니다.
사용 방법
COS 콘솔 사용하기
COS 콘솔은 접두사 검색과 퍼지 검색을 지원합니다.
접두사 검색: 동일한 객체 접두사를 기준으로 검색하여 동일한 객체 접두사를 가진 객체 및 폴더의 검색 결과를 표시합니다.
퍼지 검색: 사용자 정의 키워드를 기준으로 검색하여 해당 키워드를 포함하는 객체 및 폴더의 검색 결과를 표시합니다.
설명:
객체 검색 시 입력하는 객체 접두사는 영문 대소문자를 구분해야 합니다.
이 외에도 COSBrowser 도구를 사용하여 퍼지 검색을 할 수 있으며, 자세한 내용은 COSBrowser 소개를 참고하십시오.
개체 저장소(Cloud Object Storage, COS)에서 저장된 개체를 간단한 복사 작업으로 새로운 개체 사본을 생성할 수 있습니다. 복제 작업은 단일 요청에서 최대 5GB의 COS(Cloud Object Storage) 객체 사본을 작성합니다. 5GB가 넘는 객체를 복제하려면 멀티파트 복제 API를 사용하십시오. 복제 작업으로 다음을 수행할 수 있습니다.
객체의 복제본을 생성합니다.
객체를 복제하고 원래 객체를 삭제하여 객체 이름을 바꿉니다.
객체의 스토리지 클래스를 수정합니다. 소스 및 대상 모두로 동일한 객체 키를 선택하고 스토리지 클래스를 수정할 수 있습니다.
각각 다른 Tencent Cloud COS 리전에서 객체를 복제합니다.
객체 메타데이터를 수정합니다. 소스 및 대상 모두로 동일한 객체 키를 선택하고 객체 메타데이터를 수정할 수 있습니다.
복제 작업에서 원본 객체의 메타데이터는 기본적으로 상속되지만 생성 날짜는 대상 객체의 생성 날짜에 따릅니다.
설명
아카이브 유형(예: 아카이브 스토리지, 딥 아카이브 스토리지)의 개체에 대해 PUT Object - Copy 요청을 시작할 수 없습니다.
멀티 AZ 구성이 활성화된 버킷은 멀티 AZ 스토리지 유형을 싱글 AZ 스토리지 유형으로 복사할 수 없습니다.
서브 계정이 개체를 복사하려면 PutObject, GetObject, GetObjectACL 이 세 가지 권한이 필요합니다. 자세한 내용은 객체 스토리지 권한 부여 인터페이스를 참조하십시오.
5GB 이상의 객체를 복사해야 할 때, 파트 복사 방법을 선택해 구현해야 합니다. 멀티파트 업로드한 API를 사용해 신규 객체를 생성하고 Upload Part - Copy 기능을 사용하여 x-cos-copy-source 헤더를 가져와 원본 객체를 지정합니다. 과정은 다음과 같습니다.
1. 멀티파트 업로드한 객체를 초기화합니다.
2. 원본 객체의 데이터를 복사하면 x-cos-copy-source-range 헤더를 지정할 수 있으며, 한 번에 최대 5GB의 데이터만 복사할 수 있습니다.
3. 멀티파트 업로드를 완성합니다.
설명：
Tencent Cloud COS가 제공하는 SDK를 사용하면 블록 복사 기능을 쉽게 수행할 수 있습니다.
사용 방법
REST API 사용
REST API를 직접 사용해 블록 복사 요청을 실행할 수 있습니다. 다음 API 문서를 참조하십시오.
현재는 파일 리스트에서 파일명, 크기, 수정 시간에 따른 정렬 및 스토리지 유형에 따른 필터링만 지원합니다.
아카이브된 객체 복구
최종 업데이트 날짜:：2025-08-15 16:37:50
소개
COS 콘솔을 통해 ARCHIVE 또는 DEEP ARCHIVE 스토리지 유형에서 객체를 복구할 수 있습니다. 복구 작업은 STANDARD 스토리지 유형에 객체의 복사본을 생성합니다. 유효 기간 내에 복사본에 대해 읽기, 다운로드 또는 기타 작업을 수행할 수 있습니다. 복사본은 만료 후 자동으로 삭제됩니다. 스토리지 유형에 대한 자세한 내용은 스토리지 유형 개요를 참고하십시오.
주의：
ARCHIVE에서 객체를 복구(동결 해제)하는 경우 객체 복사본에 STANDARD 요금이 청구됩니다. DEEP ARCHIVE에서 객체를 복구(동결 해제)하는 경우 객체 복사본에는 표시된 단가의 요청 요금과 STANDARD 요금의 트래픽 요금이 부과됩니다. 자세한 내용은 제품 가격 문서를 참고하십시오.
5. 복구할 객체를 찾고 작업 열에서 복구를 클릭합니다. 보관된 여러 객체를 한 번에 복구하려면 객체 목록에서 모두 선택하고 상단의 추가 작업 > 드롭다운 목록에서 복구를 클릭합니다.
6. 팝업 창에서 복구 모드와 복제본 유효 일수를 설정합니다.
설정 관련 정보는 다음과 같습니다.
복구 모드: 고속, 표준 또는 대량 검색.
고속 검색: 가장 빠른 모드입니다. 보관된 파일은 1 - 5분 이내에 복구할 수 있습니다. ARCHIVE 데이터에 급히 액세스해야 하는 경우 이 고속 검색 모드를 사용하여 복구 시간을 크게 줄일 수 있습니다. DEEP ARCHIVE에서는 고속 검색 모드를 사용할 수 없습니다.
표준 검색: 표준 검색 모드를 사용하면 ARCHIVE에서는 3 - 5시간 이내에, DEEP ARCHIVE에서는 12시간 이내에 파일을 복구할 수 있습니다.
대량 검색: 가장 비용이 적게 드는 모드입니다. ARCHIVE 데이터에 대한 필요성이 긴급하지 않은 경우 이 모드는 일반적으로 매우 저렴한 비용으로 ARCHIVE에서 5 - 12시간 이내에, DEEP ARCHIVE에서 48시간 이내에 방대한 양의 데이터를 복구할 수 있습니다.
설명：
데이터 복구 요청의 QPS는 100회/초로 제한됩니다.
다양한 모드에 따라 데이터 검색 비용이 다릅니다. 자세한 내용은 데이터 검색 비용을 참조하십시오.
복사본 유효 기간: 복사본이 자동으로 만료되고 삭제되는 일 수입니다. 값 범위는 1일-365일입니다. 객체가 성공적으로 복구된 후 복구를 다시 클릭하여 팝업 창에서 복사본의 유효 기간을 변경할 수 있습니다.
7. 확인을 클릭합니다. 객체가 복구 프로세스에 들어갑니다. 이 과정에서 다음 두 가지 방법으로 객체 복구 진행 상황을 확인할 수 있습니다:
7.1 페이지 파일 목록을 새로 고쳐 스토리지 유형 열에서 객체의 복구 상태와 예상 복구 시간을 확인합니다.
7.2 세부정보를 클릭하면 객체 세부정보 페이지로 이동하여 복원이 완료되었는지 확인할 수 있습니다.
8. 객체가 성공적으로 복원되면 해당 세부정보 페이지에서 객체에 접근하고, 다운로드하며, 저장 유형을 수정할 수 있습니다.
주의：
객체 복구가 완료된 후, 만료된 복사본을 삭제하기 전에 스토리지 유형을 수정해야 합니다(예: 표준 스토리지로). 원본 객체 유형은 아카이브 스토리지에서 표준 스토리지 유형으로 대체됩니다.
9. 복사본의 유효 기간을 수정하려면 5단계를 따라 복구를 다시 클릭하고 팝업 창에서 유효 기간을 수정합니다.
객체 URL 내보내기
최종 업데이트 날짜:：2024-06-24 16:12:04
소개
COS 콘솔을 통해 버킷 객체(업로드된 객체 및 폴더 내 객체 포함) URL 내보내기를 진행할 수 있습니다. 객체 URL 리스트 일괄 내보내기를 지원하며 자세한 내용은 작업 단계를 참고하십시오.
설명：
객체 URL 리스트 일괄 내보내기는 한번에 최대 100개 객체, 즉 최대 100건까지 가능합니다.
내보내야 할 객체 URL 수량 ＞ 100개일 경우 API 또는 SDK를 통해 내보내십시오. 자세한 내용은 GET Bucket(List Objects)을 참고하십시오.
5. URL을 내보내야 할 객체를 선택하고 상단의 [더 많은 작업] > [URL 내보내기]를 클릭합니다.
6. 팝업 창에서 다음과 같이 정보를 설정합니다.
전송 프로토콜: 기본적으로 HTTPS 프로토콜이 선택됩니다. HTTPS 프로토콜, HTTP 프로토콜을 지원하며 필요에 따라 선택할 수 있습니다.
지정 도메인: 기본 원본 서버 도메인을 지원합니다.
만료 시간: 기본 만료 시간은 60분입니다. 만료 시간을 5~60 사이의 정수로 사용자 정의할 수 있습니다.
7. [확인]을 클릭하면 객체 URL 리스트 파일을 내보낼 수 있습니다.
8. 내보내기 파일에서 객체 이름과 객체 URL 정보를 확인할 수 있습니다. 유효기간 내에 객체 URL을 확인해주십시오.
3. 파일을 생성할 버킷을 찾아 해당 버킷 이름을 클릭하여 버킷 관리 페이지로 이동합니다.
4. 왼쪽 네비게이션 바에서 파일 목록을 선택하여 파일 목록 페이지로 이동합니다.
5. 폴더 생성에 마우스를 올리면 자동으로 드롭다운 메뉴가 표시되며, 파일 생성을 클릭합니다.
6. 팝업창에서 파일 이름을 입력하고 확인을 클릭하면 됩니다.
주의:
완료 후, COS는 크기가 0이고 저장 유형이 STANDARD인 빈 파일을 기본적으로 생성합니다.
파일 목록 관리
최종 업데이트 날짜:：2025-12-17 11:47:29
소개
COS 콘솔에서 버킷 상세 정보로 이동합니다. 버킷의 파일 목록에서 파일 또는 폴더에 대해 관련 작업을 수행할 수 있습니다. 파일 목록에서 파일 업로드, 폴더 생성, 파일 조각 관리, 버킷 비우기, 이전 버전 나열, 검색 또는 목록 새로 고침, 폴더 권한 설정, 파일 상세 정보 보기, 미리 보기, 다운로드 등의 작업을 수행할 수 있습니다.
설명:
그리드 보기에서 썸네일 기능을 활성화할 수 있으며, 본 기능은 Cloud Infinite(CI)의 기술 지원으로 제공됩니다. 활성화 시 CI의 이미지 처리 비용 및 미디어 처리 비용이 발생합니다.
4. 왼쪽 네비게이션 바에서 파일 목록을 선택하여 파일 목록 페이지로 이동합니다.
파일 목록은 두 가지 보기를 지원하며, 파일 목록의 오른쪽 상단에서 필요한 보기로 전환할 수 있습니다(아래 그림의 빨간색 상자로 표시된 위치). 자세한 내용은 다음과 같습니다.
리스트 보기: 파일 및 폴더가 목록 형태로 표시됩니다.
그리드 보기: 파일 및 폴더가 격자 형태로 표시됩니다.
폴더 관리
폴더 생성
최종 업데이트 날짜:：2024-06-24 16:12:04
소개
COS는 폴더 개념 없이 플랫 구조로 객체를 저장하고, 사용자의 사용 습관에 맞춰 객체 키에 '/' 접미사를 붙여 이름을 생성한 객체를 통해 ‘폴더’를 구현합니다. 실제로 ‘폴더’는 COS의 스토리지 공간이 0KB인 객체입니다. 폴더 및 디렉터리에 대한 설명은 폴더 및 디렉터리를 참고하십시오.
주의：
폴더 이름 길이는 255자 이내로 제한되며, 다음과 같은 예약된 ASCII 제어 문자는 지원하지 않습니다.
3. 폴더가 위치한 버킷을 찾아 해당 버킷 이름을 클릭하면 버킷 관리 페이지로 이동합니다.
4. 왼쪽 네비게이션 바에서 파일 목록을 선택하여 파일 목록 페이지로 이동합니다.
5. 찾고자 하는 폴더를 찾은 후 오른쪽 작업 열에서 통계를 클릭하거나, 크기 열에 마우스를 올리면 나타나는 통계를 클릭합니다.
6. 팝업 창에서 해당 폴더 내의 통계 정보를 확인할 수 있으며, 여기에는 객체 총 수량과 객체 총 크기가 포함됩니다.
주의:
List Objects 통계 과정 중에는 팝업 창을 닫지 마십시오. 그렇지 않으면 통계가 중단됩니다.
7. 파일 수가 100,000개를 초과할 경우, 팝업 창에서 인벤토리 통계가 필요하다는 메시지가 표시됩니다. 즉시 인벤토리 사용을 클릭하여 인벤토리 통계를 수행하십시오. 파일 수가 100,000개 미만인 경우, 통계 완료 후 결과를 직접 확인하고 다운로드할 수 있습니다. 작업 단계는 통계 결과로 직접 이동하십시오.
8. 즉시 인벤토리 사용을 클릭하면 즉시 인벤토리 통계 구성 팝업 창으로 이동합니다. 필요에 따라 "스토리지 유형 필터링" 구성 항목을 설정한 후 통계 시작을 클릭하면 인벤토리 통계가 수행됩니다. 인벤토리에 대한 자세한 설명은 인벤토리 기능 개요를 참조하십시오.
9. 인벤토리 통계 과정 중에는 팝업 창을 닫고 나중에 확인하는 것이 가능하지만, 파일 목록 페이지를 전환하거나 새로고침하지 마십시오. 그렇지 않으면 목록에서 통계 상태가 더 이상 직접 표시되지 않습니다. 전환 또는 새로고침 시에는 인벤토리 보고서 저장 경로로 수동 이동하여 결과를 확인해야 합니다.
Cloud Object Storage (COS) 콘솔을 통해 폴더에 대한 접근 권한을 설정하여 사용자에게 폴더에 대한 지정된 작업을 부여할 수 있습니다. 최소 권한 원칙에 따라 권한을 구성하여 귀하의 데이터 자산 안전을 보호하는 것이 좋습니다.
주의：
COS는 플랫 구조로 객체를 보관하고, 폴더 개념은 없습니다. 사용의 사용 습관에 맞춰 객체 키에 /를 접미사로 붙여 이름을 생성한 객체를 통해 ‘폴더’를 구현합니다. 실제 객체 스토리지(Cloud Object Storage，COS)에서 ‘폴더’는 스토리지 용량이 0KB인 객체입니다.
폴더 권한은 본질적으로 오브젝트 차원 기반의 접근 권한 설정으로, 해당 권한의 우선순위는 버킷의 접근 권한보다 높습니다. 오브젝트 접근 권한과의 차이점이라면, 폴더는 공개 읽기/쓰기 설정을 지원합니다. 오브젝트의 접근 권한 소개는 오브젝트 개요의 권한 분류를 참고하시기 바랍니다.
6. 팝업창이 나타나면 필요에 따라 폴더 권한 설정을 진행하십시오.권한 설정에 대한 설명은 다음과 같습니다.
권한 유형
설정 페이지
설명
공용 권한
권한 상속
기본값과 버킷 권한은 동일하게 유지합니다.
개인 읽기 및 쓰기
루트 계정만 쓰기 및 읽기가 가능하며 루트가 아닌 계정 사용자(서브 계정, 기타 사용자의 루트 계정 또는 익명 사용자)는 이 폴더에 액세스할 수 없습니다.
공개 읽기와 개인 쓰기
루트 계정은 쓰기 및 읽기가 가능하며, 루트가 아닌 계정 사용자(서브 계정, 기타 사용자의 루트 계정 또는 익명 사용자)는 이 폴더의 콘텐츠를 읽을 수 있지만 새 데이터를 입력할 수 없습니다.
공개 읽기 및 쓰기
루트 계정 및 루트가 아닌 계정 사용자(서브 계정, 기타 사용자의 루트 계정 또는 익명 사용자) 모두 쓰기 및 읽기가 가능합니다.
사용자 권한
사용자 유형
루트 계정은 기타 사용자의 루트 계정 ID를 가리키며, 서브 계정은 현재 사용하는 루트 계정의 서브 계정을 가리킵니다. 기타 루트 계정의 서브 계정 액세스 설정이 필요할 경우, 먼저 기타 루트 계정에 액세스 권한을 부여한 후, 기타 루트 계정에 서브 계정 액세스 권한을 부여해야 합니다.
데이터 읽기
데이터를 읽을 수 있는 권한입니다.
데이터 쓰기
데이터를 쓸 수 있는 권한입니다.
읽기 권한
폴더의 권한 설정을 읽을 수 있는 권한으로, 이 권한이 부여된 사용자는 폴더 권한 설정의 자세한 정보를 얻을 수 있습니다.
쓰기 권한
폴더의 권한 설정을 수정할 수 있는 권한으로, 이 권한이 부여된 사용자는 폴더 권한 설정의 자세한 정보를 수정할 수 있습니다. 이 설정은 권한을 변경할 수 있으므로 신중하게 선택하십시오.
전체 제어
데이터 읽기 및 쓰기, 권한 읽기 및 쓰기 등 네 가지 권한을 가리킵니다. 이 권한 설정은 범위가 크므로 신중하게 선택하십시오.
7. 오른쪽 작업 열의 저장을 클릭하십시오.
8. 닫기를 클릭하십시오.
사용자 정의 Headers
최종 업데이트 날짜:：2025-11-18 16:52:54
소개
객체의 HTTP 헤더(메타데이터 헤더)는 서버가 HTTP 프로토콜로 HTML 자료를 브라우저에 전송하기 전 보내는 문자열입니다. HTTP 헤더(메타데이터 헤더) 수정을 통해서 페이지의 응답 형식이나 설정 정보를 전달할 수 있습니다. 캐시 시간 수정이 그 예입니다. 객체의 HTTP 헤더 수정으로 객체 자체를 수정할 수 없습니다.
설명：
아카이브(ARCHIVE), 딥 아카이브(DEEP ARCHIVE) 유형의 객체는 업로드 시 사용자 정의 Headers 설정만 지원되고 업로드된 객체에 대한 사용자 정의 Headers 설정은 지원되지 않습니다.
5. 사용자 지정 헤더가 필요한 객체를 찾고, 그 오른쪽에 있는 작업 열에서 추가 > 사용자 지정 헤더를 클릭하여 설정합니다. 다중 객체에 대한 사용자 지정 헤더가 필요하시면 다수의 객체를 선택하고, 위에 있는 추가 작업 > 사용자 지정 헤더를 클릭하여 설정합니다.
6. 팝업 창에서 설정할 메타데이터 헤더 매개변수 유형을 선택하고 해당 메타데이터 값을 입력한 후 확인을 클릭합니다.
COS는 설정을 위해 다음 6개의 객체 HTTP 헤더 식별자를 제공합니다. 헤더 설정 설명은 다음과 같습니다.
HTTP 헤더
설명
예시
Content-Type
파일의 MIME 정보
image/jpeg
Cache-Control
파일의 캐시 메커니즘
no-cache: 캐시를 직접 사용하는 것이 아니라 먼저 서버에서 Object 업데이트되었는지 여부를 확인해야 합니다. Object가 업데이트된 경우 캐시가 만료되었음을 의미하므로 서버에서 Object를 다시 다운로드해야 합니다. Object가 업데이트되지 않은 경우 캐시가 만료되지 않았음을 의미하므로 로컬 캐시를 사용합니다.
max-age=200: 캐시 내용의 상대적 만료시간, 단위는 초.
Content-Disposition
MIME 프로토콜의 확장
inline: 파일 내용을 직접 미리보기.
attachment: 원 파일 이름의 형식으로 브라우저 지정 경로로 다운로드.
attachment; filename="FileName": 사용자 지정 파일 이름의 형식으로 브라우저 지정 경로로 다운로드. FileName은 다운로드된 파일 이름의 사용자 지정에 사용되며, 예를 들면 example.jpg입니다. 첨부 파일 이름이 중국어인 경우 URL 코딩이 필요합니다. 예시 attachment; filename* = UTF-8' '%E4%B8%AD%E6%96%87.txt
Content-Encoding
파일의 코딩 포맷
gzip
주의: Header의 Content-Encoding을 gzip으로 변경하였지만 파일 자체가 사전에 gzip으로 압축되지 않았기 때문에 디코딩 에러가 발생할 수 있습니다.
Expires
캐시의 만료일 제어
Wed, 21 Oct 2015 07:28:00 GMT
x-cos-meta-\[사용자 지정 접미사\]
사용자 지정 내용
x-cos-meta-via: homepage
주의: 헤더 이름은 마이너스 부호(-), 숫자, 영어(a～z)만 지원됩니다. 영어 문자의 대문자는 소문자로 변환되며, 밑줄(_)을 포함하는 다른 부호는 지원되지 않습니다.
사용자 지정 헤더를 사용하는 경우 페이지의 응답 형식을 변경할 수 있음을 알 수 있습니다.
데이터 관리
라이프사이클 관리
라이프사이클 개요
최종 업데이트 날짜:：2024-06-24 17:04:20
개요
COS(Cloud Object Storage)는 객체 기반의 라이프사이클 구성을 지원합니다. 라이프사이클 규칙을 사용하여 해당 객체에 대해 수행할 작업을 정의할 수 있습니다.
설명：
버킷마다 최대 1,000개까지 라이프사이클 규칙을 추가할 수 있습니다.
사용 사례
로그 기록
라이프사이클이 구성되면 COS에 저장된 로그는 30일 후에 자동으로 보관되거나 2년 후에 삭제될 수 있습니다.
핫/콜드 데이터 티어링
핫 데이터는 업로드 후 짧은 시간 동안 자주 액세스하다가 일정 시간이 지나면 액세스가 거의 또는 전혀 이루어지지 않습니다. 따라서 30일 전에 업로드된 데이터는 STANDARD_IA 스토리지 클래스에, 60일 전에 업로드된 데이터는 ARCHIVE에 저장하도록 라이프사이클 규칙을 설정할 수 있습니다. 이 프로세스를 데이터 전환이라고 합니다.
아카이브 관리
파일 아카이브 관리에 COS를 사용하는 경우 금융, 의료 및 기타 산업의 컴플라이언스 요구 사항에 따라 파일의 모든 기존 버전을 장기간 저장해야 합니다. 이 경우 ARCHIVE 스토리지 클래스에서 파일의 기록 버전을 전환하고 저장하도록 라이프사이클을 구성할 수 있습니다.
구성 항목
라이프사이클 규칙을 생성하려면 다음 요소를 구성해야 합니다.
리소스
라이프사이클 실행 중에 히트할 데이터를 지정합니다. 범위 내에서 다루는 라이프사이클의 범위 및 데이터 유형을 사용자 정의할 수 있습니다. 라이프사이클 실행 중에 지정된 범위가 스캔되고 범위 내에서 구성된 데이터 유형에 대해 작업이 수행됩니다. 다음 규칙에 따라 범위를 지정할 수 있습니다.
접두사 지정: 디렉터리 이름 또는 파일 이름 접두사 매칭을 지원합니다.
태그 지정: 데이터를 태그로 필터링할 수 있습니다.
다음 데이터 유형을 구성할 수 있습니다.
현재 버전의 파일: 버킷의 최신 버전 객체입니다.
이전 버전의 파일: 버전 관리가 활성화된 후 저장된 이전 버전의 객체입니다. 버전 관리에 대한 자세한 내용은 버전 제어 개요를 참고하십시오.
삭제 마커: 객체가 삭제되었음을 나타내는 마커입니다. 라이프사이클 기능은 모든 기록 버전이 삭제된 후 마커를 자동으로 제거할 수 있습니다. 삭제 마커에 대한 자세한 내용은 삭제 마커를 참고하십시오.
조각 파일: 불완전한 멀티파트 업로드로 인해 생성된 조각입니다.
작업
객체가 히트될 때 수행할 작업:
데이터 전환: 지정된 기간 이후 객체를 STANDARD_IA, INTELLIGENT TIERING, ARCHIVE 또는 DEEP ARCHIVE로 전환합니다.
만료: 지정된 만료 시간이 지난 객체를 삭제합니다.
시간
상기 작업을 트리거하기 위한 시간 조건:
일 수 기준: 객체의 마지막 수정 날짜를 기준으로 객체에 정의된 작업을 수행할 시기를 지정할 수 있습니다.
규칙에서 정한 일수는 24시간을 기준으로 하며, 24시간 미만은 1일로 계산하지 않습니다.
예를 들어 1일 오후 3시에 파일을 수정하고 1일 후에 삭제되는 라이프사이클 규칙을 설정한 경우, 라이프 사이클 작업은 2일 0시에 파일 스캔을 시작하여, 2일 0시를 기준으로 최종 수정 시간이 1일을 넘은 파일에 대한 삭제 작업을 실행합니다. 1일 당일 업로드한 파일은 최종 수정 시간을 기준으로 1일을 초과하지 않았기 때문에 3일 0시까지 기다려야만 기록을 스캔하고 삭제를 실행할 수 있습니다.
최대 규칙 일수
라이프사이클은 최대 3650일까지 설정할 수 있습니다.
적용 시간
라이프사이클의 적용은 매일 스캔과 실행 두 가지 작업으로 나뉩니다.
스캔: COS는 현지 시간(GMT+8) 기준으로 매일 0시에 라이프사이클 규칙을 가져와 적용 범위 내의 모든 객체를 스캔합니다.
실행: 스캔에서 규칙이 지정한 날짜에 해당하는 객체가 스캔되면, 전환 또는 삭제 작업을 실행합니다.
예를 들어, 사용자가 2023년 1월 20일에 규칙 A를 설정하여 test.txt 파일의 수정 시간을 기준으로 10일 후에 삭제하도록 지정했다면, 2023년 1월 21일 0시부터 test.txt 파일의 수정 시간을 매일 0시에 스캔합니다. 만약 해당 파일의 마지막 수정 시간이 2023년 1월 15일인 경우, 2023년 1월 26일 0시에 실행되는 스캔 작업에서 파일이 삭제 조건을 충족시켰다고 판단되면, 스캔이 완료되면서 삭제 작업을 실행합니다.
주의：
규칙 스캔과 실행 기간 중 규칙 상태를 변경하지 마십시오.. 변경하면 기존 규칙이 종료되어 전환 또는 삭제 작업이 올바르게 실행되지 않을 수 있습니다.
데이터 전환
단방향 원칙
데이터 전환은 단방향(STANDARD > STANDARD_IA > ARCHIVE 또는 STANDARD > ARCHIVE)이며 역방향으로 수행할 수 없습니다. PUT Object - Copy(비 ARCHIVE/DEEP ARCHIVE 전용) 또는 POST Object restore(ARCHIVE 및 DEEP ARCHIVE 전용)만 호출하여 colder 스토리지 클래스에서 hotter 스토리지 클래스로 데이터를 복구할 수 있습니다.
최종 일관성
동일한 객체 집합에 대해 여러 규칙이 구성되어 있고 서로 충돌하는 경우(만료 시 삭제 구성 제외) COS는 객체를 coldest 스토리지 클래스로 전환하는 규칙을 실행합니다.
예를 들어 규칙 A와 B가 각각 파일 수정 후 90일 후에 객체를 STANDARD_IA로 전환 및 ARCHIVE로 전환하도록 구성되어 있고 둘 다 동일한 객체 test.txt에 도달하면 규칙 B가 실행됩니다.
규칙
리소스
운영
시간 조건
실행
규칙 A
test.txt
객체를 STANDARD_IA 클래스로 전환
파일 수정 후 90일
규칙 충돌로 인해 실행 실패
규칙 B
test.txt
객체를 ARCHIVE 클래스로 전환
파일 수정 후 90일
실행 성공
주의：
COS에서 동일한 객체 세트에 대해 충돌하는 라이프사이클 규칙을 구성하지 않는 것이 좋습니다. 이로 인해 요금이 달라질 수 있습니다.
객체를 전환해도 객체가 업로드되거나 수정된 시간은 변경되지 않습니다.
만료 삭제
처리 로직
객체가 만료 시 지정된 삭제 라이프사이클 규칙과 일치하면 Tencent Cloud는 해당 객체를 비동기 삭제 큐에 추가합니다. 실제 삭제에는 약간의 지연이 있을 수 있습니다. GET 또는 HEAD 객체 작업을 수행하여 객체의 현재 상태를 가져올 수 있습니다.
최종 일관성
같은 그룹에 속한 객체에 여러 규칙을 설정하고, 충돌 상황이 존재할 경우, COS는 최단 기간의 만료 시간을 기준으로 실행하고, 만료 삭제의 실행 효과는 전환 스토리지 유형보다 큽니다.
예를 들어 규칙 C와 D가 각각 파일 수정 180일 후 객체를 STANDARD_IA로 전환하고 객체를 삭제하도록 구성되어 있고 둘 다 동일한 객체 test.txt에 도달하면 규칙 D가 실행됩니다.
규칙
리소스
운영
시간 조건
실행
규칙 C
test.txt
객체를 STANDARD_IA 클래스로 전환
파일 수정 후 180일
규칙 충돌로 인해 실행 실패
규칙 D
test.txt
객체 삭제
파일 수정 후 180일
실행 성공
주의：
COS에서 동일한 객체 세트에 대해 충돌하는 라이프사이클 규칙을 구성하지 않는 것이 좋습니다. 이로 인해 요금이 달라질 수 있습니다.
비용 참고
수행 설명
라이프사이클 기능이 삭제 작업을 수행하면 백엔드 삭제 요청이 생성됩니다. 전환 작업을 수행하면 백엔드 삭제 및 쓰기 요청이 생성됩니다. 상기 작업으로 생성된 요청은 요청 청구서에 포함됩니다. 예를 들어 라이프사이클을 통해 STANDARD 스토리지 클래스의 'test.txt' 파일을 STANDARD_IA로 전환하면 두 개의 요청이 생성됩니다. 하나는 STANDARD의 데이터를 삭제하는 데 사용되고 다른 하나는 STANDARD_IA의 데이터를 쓰는 데 사용됩니다.
예외 상황이 발생하거나 버킷에 객체가 너무 많은 경우 라이프사이클 실행이 실패할 수 있습니다. 다른 이유로 인한 실패의 경우 GET 또는 HEAD Object 작업을 수행하여 현재 객체 상태를 가져옵니다.
Tencent Cloud는 라이프사이클 실행이 완료되지 않으면 정확한 청구서를 제공할 수 없습니다.
기간 제한
STANDARD_IA/INTELLIGENT TIERING, ARCHIVE 및 DEEP ARCHIVE 스토리지 클래스의 최소 스토리지 기간은 각각 30일, 90일 및 180일입니다. 전환 또는 삭제 작업 자체에 대해 추가 스토리지 요금이 발생하지 않습니다. COS는 30/90/180일 미만의 라이프사이클 구성을 무시하고 요청 시 올바른 구성만 수행합니다.
예를 들어 STANDARD_IA의 객체가 30일 이전에 전환되면 전환일부터 ARCHIVE 보관 요금이 발생하기 시작하고 30일까지 STANDARD_IA 보관 요금이 계속 부과됩니다. 또 다른 예는 보관된 객체가 90일 동안 저장되기 전에 만료 시 삭제되는 경우 90일까지 ARCHIVE 스토리지 요금이 계속 발생한다는 것입니다. DEEP ARCHIVE와 동일한 방식으로 작동합니다.
크기 제한
STANDARD_IA, ARCHIVE 및 DEEP ARCHIVE 스토리지 클래스에는 객체에 대한 최소 크기 제한이 있습니다. 예를 들어 64KB보다 작은 객체가 STANDARD_IA 스토리지 클래스에 업로드되면 64KB로 계산됩니다. 사용자 요금을 줄이기 위해 라이프사이클 실행은 64KB보다 작은 객체의 스토리지 클래스를 전환하지 않습니다.
설명：
라이프사이클은 64KB보다 작은 객체의 스토리지 클래스를 전환하지 않습니다.
라이프사이클 구성 요소
최종 업데이트 날짜:：2024-06-24 17:04:20
기본 구조
라이프사이클 설정은 XML 설명 방법을 사용합니다. 단일 또는 다중 라이프사이클 규칙을 설정할 수 있으며 기본 구조는 다음과 같습니다.
<LifecycleConfiguration>
<Rule>
<ID>**your lifecycle name**</ID>
<Status>Enabled</Status>
<Filter>
<And>
<Prefix>projectA/</Prefix>
<Tag>
<Key>key1</Key>
<Value>value1</Value>
</Tag>
</And>
</Filter>
**transition/expiration actions**
</Rule>
<Rule>
...
</Rule>
</LifecycleConfiguration>
모든 규칙은 다음 내용을 포함합니다.
ID(선택 사항): 규칙의 내용을 나타내며 사용자 정의할 수 있습니다.
Status: 규칙의 활성화 Enable 또는 비활성화 Disable 여부를 나타냅니다.
Filter: 규칙이 적용되는 객체를 식별합니다.
작업: 위의 설명과 일치하는 객체에 대해 수행해야 하는 작업입니다.
시간: Days(객체가 마지막으로 수정된 날짜부터 계산됨) 또는 객체에 대해 수행된 작업을 기반으로 하는 Date입니다.
규칙 설명
Filter 요소
버킷의 모든 객체 대상
비어있는 필터링 조건을 지정하면 버킷의 모든 객체에 적용됩니다.
<LifecycleConfiguration>
<Rule>
<Filter>
</Filter>
<Status>Enabled</Status>
**transition/expiration actions**
</Rule>
</LifecycleConfiguration>
지정된 객체 키 접두사 대상
객체 접두사를 지정하면 접두사 설명에 부합한 일부 객체 그룹에 대해 작업을 수행할 수 있습니다. 예를 들어, logs/를 접두사로 한 모든 객체를 설정합니다.
<LifecycleConfiguration>
<Rule>
<Filter>
<Prefix>logs/</Prefix>
</Filter>
<Status>Enabled</Status>
**transition/expiration actions**
</Rule>
</LifecycleConfiguration>
지정된 객체 태그 대상
객체 태그에 부합한 key와 value를 필터링 조건으로 지정하고, 특정 태그의 객체에 대한 작업을 수행합니다. 예를 들어, 태그의 key=type과 value=image를 필터링 조건으로 한 객체를 설정합니다.
<LifecycleConfiguration>
<Rule>
<Filter>
<Tag>
<Key>type</Key>
<Value>image</Value>
</Tag>
</Filter>
<Status>Enabled</Status>
**transition/expiration actions**
</Rule>
</LifecycleConfiguration>
다중 필터링 조건 통합 사용
Tencent Cloud COS(Cloud Object Storage)는 AND의 로직을 통해 다중 필터링 조건을 통합 사용할 수 있습니다. 예를 들어, logs/를 접두사로 하면서 객체 태그의 key=type과 value=image를 필터링 조건으로 한 객체를 설정합니다.
<LifecycleConfiguration>
<Rule>
<Filter>
<And>
<Prefix>logs/</Prefix>
<Tag>
<Key>type</Key>
<Value>image</Value>
</Tag>
</And>
</Filter>
<Status>Enabled</Status>
**transition/expiration actions**
</Rule>
</LifecycleConfiguration>
작업 요소
라이프사이클 규칙 중, 조건에 부합한 한 그룹 객체에 단일 또는 다중 작업을 수행할 수 있습니다.
전환 작업
한 스토리지 유형에서 다른 스토리지 유형으로 객체를 전환하려면 Transition 작업을 지정합니다. 버전이 지정된 버킷의 경우 전환 작업이 현재 객체 버전에 적용됩니다. Transition 날짜를 0일로 짧게 설정할 수 있습니다. 예를 들어 30일 후에 객체를 아카이브 스토리지로 전환합니다.
<Transition>
<StorageClass>ARCHIVE</StorageClass>
<Days>30</Days>
</Transition>
만료 삭제
만료된 객체를 삭제하려면 Expiration 작업을 지정합니다. 버전이 지정되지 않은 버킷의 경우 만료된 객체는 영구적으로 삭제됩니다. 버전이 지정된 버킷의 경우 만료된 객체가 DeleteMarker로 추가되고 현재 버전이 됩니다. 예를 들어 만료일이 30일인 객체를 삭제합니다.
<Expiration>
<Days>30</Days>
</Expiration>
미완성 멀티파트 업로드
주의：
동일한 라이프사이클 규칙에서 객체 태그 지정과 업로드 완료되지 않은 파일 조각 정리를 동시에 설정할 수 없습니다.
미리 정의된 기간 내에 성공적으로 완료되지 않은 경우 특정 UploadId가 있는 멀티파트 업로드 작업을 삭제하려면 AbortIncompleteMultipartUpload 작업을 지정하십시오. 이 경우 이러한 작업도 재개하거나 인덱싱할 수 없습니다. 예를 들어, 7일 이내에 성공적으로 완료되지 않은 멀티파트 업로드 작업을 중단합니다.
<AbortIncompleteMultipartUpload>
<DaysAfterInitiation>7</DaysAfterInitiation>
</AbortIncompleteMultipartUpload>
현재 버전이 아닌 객체
버전이 지정된 버킷에서 전환 작업은 최신 버전의 객체에만 적용되고 만료 작업은 객체에 삭제 마커를 추가하는 결과만 가져옵니다. 따라서 COS는 현재 버전이 아닌 객체에 대해 다음 작업을 제공합니다.
지정된 시간에 현재 버전의 객체를 다른 스토리지 클래스로 전환하려면 NoncurrentVersionTransition 작업을 지정합니다. 예를 들어, 30일 후에 객체의 이전 버전을 아카이브 스토리지로 전환합니다.
<NoncurrentVersionTransition>
<StorageClass>ARCHIVE</StorageClass>
<Days>30</Days>
</NoncurrentVersionTransition>
지정된 시간에 만료된 현재 버전의 객체를 삭제하려면 NoncurrentVersionExpiration 작업을 지정합니다. 예를 들어 30일 후에 만료된 이전 버전의 객체를 삭제합니다.
<NoncurrentVersionExpiration>
<Days>30</Days>
</NoncurrentVersionExpiration>
ExpiredObjectDeleteMarker를 지정하여 나머지 삭제 마커를 제거합니다. 입력 가능 값은 true 또는 false입니다. 이 옵션의 적용은 만료된 기록 버전(NoncurrentVersionExpiration) 제거 작업에 의해 트리거됩니다. 이 기능이 활성화되어 있으면 객체의 마지막 기록 버전이 라이프사이클에 의해 삭제될 때 나머지 여러 삭제 마커가 자동으로 제거됩니다.
만료된 기록 버전(NoncurrentVersionExpiration) 제거 작업이 적용되는 구체적인 상황은 다음과 같습니다.
ExpiredObjectDeleteMarker 활성화 여부와 상관없이 삭제 마커가 하나만 남아 있으면 마지막 삭제 마커가 자동으로 정리됩니다.
남은 삭제 마커가 여러 개인 경우 COS는 ExpiredObjectDeleteMarker가 활성화되어 있는지 확인합니다. true이면 나머지 여러 삭제 마커가 자동으로 정리되고, false이면 나머지 여러 삭제 마커가 정리되지 않습니다.
<ExpiredObjectDeleteMarker>
<Days>true|false</Days>
</ExpiredObjectDeleteMarker>
시간 요소
일별 계산
Days는 객체가 마지막으로 수정된 이후의 일 수를 나타냅니다.
예를 들어 객체가 0일 후 아카이브 스토리지로 전환되도록 설정되어 있는 경우 객체가 2018-01-01 23:55:00 GMT+8에 업로드되면 2018-01-02 00:00:00 GMT+8에 전환 대기열에 추가되고 2018-01-02 23:59:59 GMT+8 이전에 전환됩니다.
예를 들어 객체가 만료로 인해 1일 후에 삭제되도록 설정되어 있는 경우 객체가 2018-01-01 23:55:00 GMT+8에 업로드되면 객체가 2018-01-03 00:00:00 GMT+8에 만료 대기열에 추가되고 2018-01-03 23:59:59 GMT+8 이전에 삭제됩니다.
지정 날짜 기준
특정 Date의 필터 기준에 따라 모든 규정된 개체에 대해 미리 정의된 작업을 수행합니다. 날짜 값은 ISO8601 형식을 따라야 합니다. 시간은 항상 00:00 GMT+8입니다.
예를 들어, 2018년 01월 01일은 2018-01-01T00:00:00+08:00로 사용합니다.
라이프사이클 설정
최종 업데이트 날짜:：2025-12-03 11:50:24
적용 시나리오
라이프사이클 설정을 통해 규칙에 부합한 객체가 지정된 조건 하에 일부 조작을 자동 수행할 수 있습니다. 예시:
스토리지 유형 전환: 생성된 객체를 지정된 시간 후에 STANDARD_IA, INTELLIGENT_TIERING, ARCHIVE 및 DEEP_ARCHIVE로 변환합니다.
3. 라이프사이클 기능을 활성화할 버킷을 찾아 버킷 이름을 클릭하여 버킷 상세 페이지로 이동합니다.
4.
왼쪽의 기본 설정 > 라이프사이클 설정 항목을 선택하며, 설정 항목 설명은 다음과 같습니다.
접근 추적: '마지막 접근 시간' 정책 유형을 기반으로 한 라이프사이클 규칙을 설정하려면 이 옵션을 활성화하십시오. 활성화하면 접근 추적 시작 시간이 버킷 내 모든 객체의 마지막 접근 시간으로 설정됩니다. 5단계에서 정책 유형을 마지막 접근 시간으로 구성할 수 있습니다.
주의:
접근 추적 기능은 화이트리스트 기능으로, 화이트리스트에 추가된 후 사용할 수 있습니다. 해당 비즈니스 담당자에게 문의하거나 문의하기를 통해 화이트리스트에 추가하면 당일부터 적용됩니다.
접근 추적 기능의 사용 제한 사항은 다음과 같습니다.
현재 베이징, 상하이, 광저우, 베이징 1존, 충칭, 싱가포르, 난징의 버킷만 접근 추적을 지원합니다.
OFS 통합 버킷은 접근 추적을 지원하지 않습니다.
5. 규칙 추가를 클릭하면 설정 항목에 대한 설명은 다음과 같습니다.
기본 정보
규칙 이름: 라이프사이클 규칙 이름을 입력하세요.
정책 유형: 마지막 수정 시간, 마지막 접근 시간으로 구분됩니다. 이 설정 항목은 접근 추적 기능 화이트리스트에 추가된 사용자에게만 표시됩니다.
마지막 수정 시간: 객체의 마지막 수정 시간에 따라 규칙을 설정합니다.
마지막 접근 시간: 객체의 마지막 접근 시간에 따라 규칙을 설정합니다. 이 설정 항목은 화이트리스트에 추가되고 접근 추적 기능이 활성화되어야만 구성할 수 있습니다(4단계에서 활성화 가능). 현재는 데이터가 STANDARD_IA로 전환되는 것만 지원됩니다.
주의:
접근 추적을 활성화한 후에야 COS는 버킷 내 객체의 접근 시간을 기록하기 시작합니다. 접근 추적을 활성화하기 전의 모든 접근 행위는 접근 시간 분석에 포함되지 않습니다. 예를 들어, 4월 1일에 객체 a(STANDARD)가 10일 동안 접근되지 않은 것을 확인하고, 당일에 접근 추적을 활성화하고 "객체 a를 마지막 접근 시간 5일 후 STANDARD_IA로 전환"이라는 라이프사이클 규칙을 설정하면, 객체 a는 4월 2일이 아닌 4월 6일에 STANDARD_IA로 전환됩니다.
적용 범위: 본 라이프사이클 규칙은 전체 버킷에 적용될 수도 있고 지정된 범위의 객체에만 적용될 수도 있습니다.
지정 범위를 선택할 때 다음 중 최소 한 가지를 구성하십시오.
객체 접두사: 동일한 객체 키 접두사를 가진 객체에 대해 라이프사이클 규칙을 실행하도록 지정할 수 있습니다. 정규 표현식은 지원되지 않습니다.
객체 태그: 동일한 태그가 있는 객체에 대해 라이프사이클 규칙을 실행하도록 지정할 수 있으며, 여러 태그를 지정할 수 있습니다. 영문 대소문자를 구분하십시오. 정책 유형을 마지막 접근 시간으로 선택한 경우 이 항목을 구성할 수 없습니다.
주의:
객체 접두사와 객체 태그를 동시에 지정할 수 있습니다. 객체 접두사와 객체 태그, 객체 태그 간은 모두 'AND' 관계로, 모든 조건이 동시에 충족되어야 합니다. 예를 들어, 라이프사이클 규칙에서 객체 접두사를 doc으로 지정하고 객체 태그 키 값 쌍을 group = IT로 지정하면, 현재 버킷 내에서 객체 키 접두사가 doc이고 객체 태그가 group = IT인 모든 객체가 지정됩니다.
전체 버킷을 선택할 때 제외 범위를 구성할지 여부를 선택할 수 있으며, 기본적으로 비활성화되어 있습니다. 다음 구성 항목에 따라 설정할 수 있습니다.
객체 접두사: 동일한 파일 접두사를 가진 객체를 제외하여 라이프사이클 규칙을 실행하도록 지정할 수 있으며, 현재 단일 제외 접두사만 구성할 수 있습니다. 현재 구성된 제외 범위는 통합 버킷을 지원하지 않습니다.
규칙 구성
선택한 정책 유형에 따라 다음과 같은 정보를 구성하세요.
마지막 수정 시간
현재 버전 파일 관리: 현재 버전 파일 관리 옵션을 활성화하여 현재 버전 객체 스토리지 유형을 전환시키거나 객체를 삭제할 수 있습니다. 버킷의 객체가 STANDARD와 같은 핫 데이터에서 STANDARD_IA와 같은 콜드 데이터로 전환되도록 지원하며, 객체가 만료된 후 삭제되도록 지원합니다.
여기서 스토리지 유형은 핫에서 콜드로 각각 STANDARD > STANDARD_IA > INTELLIGENT TIERING > ARCHIVE > DEEP ARCHIVE이며, 스토리지 유형 전환은 핫에서 콜드로만 가능하며 역방향으로는 진행할 수 없습니다. 스토리지 유형에 대한 소개 및 적용 리전 설명은 설명은 스토리지 유형 개요 를 참고하십시오. 시간은 파일이 COS에서의 수정 시간을 기준으로 계산되며, 객체 수정 행위는 객체를 다시 업로드하는 것과 동일합니다.
설명:
다중 AZ 구성이 활성화된 스토리지 버킷의 경우, 라이프사이클 전환 순서는 MAZ_STANDARD > MAZ_STANDARD_IA > MAZ_INTELLIGENT TIERING/MAZ_ARCHIVE만 지원됩니다.
이전 버전 파일 관리: 이전 버전 객체 관리 옵션을 활성화하여 이전 버전 객체를 전환시키거나 삭제할 수 있습니다. 해당 옵션을 활성화하지 않은 경우, 최신 버전의 객체만 기본적으로 처리됩니다.
주의:
이전 버전 객체의 전환 및 삭제는 객체가 이전 버전이 된 시간을 기준으로 계산되며, 이전 버전의 업로드 시간을 기준으로 하지 않습니다.
이전 버전이 없는 삭제 마커 정리: 이전 버전이 없는 삭제 마커를 정리하려면 다음 두 가지 구성을 모두 활성화해야 합니다.
1. '이전 버전 파일 관리' 옵션을 활성화하고 이전 버전 파일의 만료 삭제를 설정합니다.
2. '이전 버전이 없는 삭제 마커 정리' 옵션을 활성화합니다.
주의:
이 옵션의 적용은 이전 버전 정리 규칙에 따라 달라집니다. 이 옵션을 선택하면 객체의 최신 버전이 삭제 마커(Delete Marker)이고 라이프사이클에 따라 마지막 이전 버전 객체가 삭제될 때, 다음 날 나머지 여러 삭제 마커가 자동으로 정리됩니다. 예: 1월 1일에 이전 버전 정리가 완료되면 1월 2일에 삭제 마커가 자동으로 정리됩니다. 자세한 내용은 ExpiredObjectDeleteMarker를 참고하십시오.
이 옵션은 현재 버전 파일 관리의 만료 삭제와 동시에 활성화할 수 없습니다.
조각 삭제: 파일 업로드 시 여러 이유로 인해 업로드가 실패하고 일부만 전송된 경우, 이러한 손상된 파일에 대해 정기 삭제를 설정할 수 있습니다.
마지막 접근 시간
버전 파일 관리: 버전 파일 관리 옵션을 활성화하여 파일이 연속 접근 일수 내에서 접근 횟수가 몇 번 미만인 경우 버전 객체를 전환시킬지 여부를 판단할 수 있습니다. 버킷 내 객체가 표준 유형(예: STANDARD)에서 저빈도 유형(예: STANDARD_IA)으로 전환하는 것을 지원합니다. 활성화하면 현재 버전과 이전 버전 모두 전환됩니다.
6. 정보 확인이 완료되면 확인을 클릭하면 라이프사이클 규칙을 확인할 수 있습니다.
주의:
라이프사이클 규칙을 설정한 후 반복적으로 수정하면 라이프사이클 규칙 실행에 영향을 미칠 수 있습니다. 규칙 적용 관련 설명은 규칙 적용 시간 설명을 참고하십시오.
7. 라이프사이클 규칙을 중지해야 할 경우 편집을 클릭하여 해당 규칙의 상태를 비활성화로 수정하거나 라이프사이클 규칙을 직접 삭제하면 됩니다.
8. 현재 버킷의 모든 라이프사이클 규칙을 지우려면 모든 규칙 지우기를 클릭하십시오.
규칙 실행 우선 순위
각 저장소는 최대 1000개의 수명 주기 규칙을 추가할 수 있습니다. 동일한 그룹의 객체에 대해 여러 규칙이 구성되어 있고 충돌이 있는 경우, 다양한 충돌 분류에 대해, 객체 저장소는 다음 우선 순위에 따라 수명 주기 규칙을 실행합니다. 자세한 내용은 수명 주기 개요 - 구성 요소 - 작업을 참조하십시오.
주의:
텐센트 클라우드 COS는 동일한 그룹의 객체에 대해 여러 충돌 조건이 포함된 수명 주기 규칙을 구성하지 않도록 강력히 권장합니다. 충돌 실행은 다른 비용 표현을 초래할 수 있습니다.
동일한 수명 주기 규칙의 다른 작업
만약 당신이 수명 주기 규칙을 구성하였고, 규칙 안에서 동일한 그룹의 객체에 대해 다른 작업(예: 침전, 삭제 작업)을 구성하였다면, 이러한 작업 간의 실행 규칙과 예시는 다음과 같습니다:
실행 규칙
예시
삭제 및 침전 작업이 동시에 충족되는 경우, 삭제 작업이 우선 실행됩니다.
규칙 R1 :
1. 파일 test.txt는 수정 후 90일 뒤 저주파 저장소로 침전됩니다.
2. 파일 test.txt는 수정 후 90일 뒤 삭제됩니다.
예상 결과 :
우선 2를 실행하며, 파일 test.txt는 90일 후에 삭제됩니다; 1 실행 실패합니다.
여러 삭제 작업이 동시에 충족되는 경우, 시간이 더 짧은 삭제 작업이 우선 일치됩니다.
규칙 R1 :
1. 전치사 a가 지정된 파일은 180일 후에 삭제됩니다.
2. 전치사 aa가 지정된 파일은 90일 후에 삭제됩니다.
예상 결과 :
버킷에 aaa.png 파일이 있다고 가정하고 전치사 a와 전치사 aa가 모두 동일한 aaa.png 파일을 명시하는 경우, 2가 우선 실행되어 aaa.png 파일이 90일 후에 삭제되고, 1은 실행 실패합니다.
여러 가지 침전 조작이 동시에 충족되는 경우, 대상 저장 유형이 더 차가운 침전 조작이 우선 일치합니다.
규칙 R1 :
1. 파일 test.txt는 수정 후 90일 뒤 저주파 저장소로 침전됩니다.
2. 파일 test.txt는 수정 후 90일 뒤 아카이브 저장소로 침전됩니다.
예상 결과 :
우선 2를 실행하며, 파일 test.txt는 수정 후 90일 뒤 아카이브 저장소로 침전됩니다; 1 실행 실패합니다.
다른 수명 주기 규칙의 다른 작업
만약 당신이 여러 개의 수명 주기 규칙을 구성하였고, 다른 규칙 안에서 동일한 그룹의 객체에 대해 다른 작업(예: 침전, 삭제 작업)을 구성하였다면, 이러한 작업 간의 실행 규칙과 예시는 다음과 같습니다:
실행 규칙
예시
여러 규칙 간에 다른 삭제 및 침전 작업이 동시에 충족되는 경우, 삭제 시간이 가장 짧은 작업이 우선 일치됩니다.
규칙 R1 :
1. 파일 test.txt는 수정 후 50일 뒤 저주파 저장소로 침전됩니다.
2. 파일 test.txt는 수정 후 10일 뒤 삭제됩니다.
규칙 R2 :
1. 파일 test.txt는 수정 후 10일 뒤 저주파 저장소로 침전됩니다.
2. 파일 test.txt는 수정 후 30일 뒤 삭제됩니다.
예상 결과 :
매칭 규칙 R1은 우선 순위 2를 실행하며, 파일 test.txt는 수정 후 10일 뒤에 삭제됩니다; 규칙 R2 실행 실패, R1의 1 실행 실패.
여러 규칙 간에 다른 삭제 작업이 동시에 충족되는 경우, 시간이 더 짧은 삭제 작업이 우선 일치됩니다.
규칙 R1:파일 test.txt는 수정 후 10일 뒤 삭제됩니다.
규칙 R2:파일 test.txt는 수정 후 30일 뒤 삭제됩니다.
예상 결과 :
규칙 R1이 일치하며, 파일 test.txt는 수정 후 10일 뒤에 삭제됩니다; 규칙 R2 실행 실패.
규칙 R3:파일 example.txt는 수정 후 10일 뒤 삭제됩니다.
규칙 R4:파일 example.txt는 수정 후 10일 뒤 삭제됩니다.
규칙 R5:파일 example.txt는 수정 후 50일 뒤 삭제됩니다.
예상 결과:
규칙 R3 또는 R4가 일치하며, 파일 example.txt는 수정 후 10일 뒤에 삭제됩니다; 규칙 R5 실행 실패.
여러 가지 규칙 간에 다른 침전 조작이 동시에 충족되는 경우, 대상 저장 유형이 더 차가운 침전 조작이 우선 일치합니다.
규칙 R1:파일 test.txt는 수정 후 10일 뒤 저주파 저장소로 침전됩니다.
규칙 R2:파일 test.txt는 수정 후 10일 뒤 아카이브 저장소로 침전됩니다.
예상 결과:
규칙 R2가 일치하며, 파일 test.txt는 수정 후 10일 뒤에 아카이브 저장소로 침전됩니다; 규칙 R1 실행 실패.
규칙 R3:파일 example.txt는 수정 후 10일 뒤 저주파 저장소로 침전됩니다.
규칙 R4:파일 example.txt는 수정 후 10일 뒤 아카이브 저장소로 침전됩니다.
규칙 R5:파일 example.txt는 수정 후 10일 뒤 아카이브 저장소로 침전됩니다.
예상 결과:
규칙 R4 또는 R5가 일치하며, 파일 example.txt는 수정 후 10일 뒤에 아카이브 저장소로 침전됩니다; 규칙 R3 실행 실패.
REST API 사용
REST API를 직접 사용해 버킷 중 객체의 라이프사이클을 설정 및 관리할 수 있습니다. 자세한 내용은 다음 API 문서를 참조해 주십시오.
정적 웹사이트는 HTML과 같은 정적 콘텐츠 또는 클라이언트 스크립트를 포함하는 웹사이트를 의미합니다. 사용자는 COS 콘솔을 통해 사용자 정의 도메인이 연결된 버킷에 정적 웹사이트를 구성할 수 있습니다.동적 웹 사이트에는 PHP, JSP 또는 ASP.NET과 같은 서버 스크립트가 포함되어 있으며 서버에서 처리되어야 합니다. Tencent Cloud COS(Cloud Object Storage)에서 정적 웹사이트를 호스팅할 수 있지만 서버 스크립트를 작성할 수는 없습니다. 동적 웹 사이트를 배포해야 하는 경우 서버 측 코드 배포에는 Cloud Virtual Machine(CVM) 사용을 권장합니다.
여기에서는 정적 웹사이트 호스팅 기능을 예시로 소개합니다.
사용자가 examplebucket-1250000000라는 이름의 버킷을 생성하여 다음과 같은 파일을 업로드하였습니다.
index.html
404.html
403.html
test.html
docs/a.html
images/
정적 웹 사이트
활성화 전: 다음 기본 액세스 도메인으로 버킷에 액세스하여 다운로드 알림을 팝업하면 index.html 파일을 로컬에 저장할 수 있습니다.
정적 웹 사이트의 첫 페이지인 인덱스 문서는 사용자가 웹 페이지의 루트 디렉터리 혹은 서브 디렉터리에 요청을 보낼 때 반환되는 웹 페이지로 index.html로 불립니다.
사용자가 버킷 액세스 도메인(예시로 https://examplebucketbucket-1250000000.cos-website.ap-guangzhou.myqcloud.com)으로 정적 웹 사이트에 액세스할 경우 특정 웹 페이지가 요청되지 않으며 웹 서버는 첫 화면을 반환합니다.
사용자가 버킷의 루트 디렉터리를 포함한 모든 디렉터리에 접근할 때, URL 주소가 /로 끝나는 경우 해당 디렉터리의 인덱스 문서가 우선적으로 자동으로 일치됩니다. 루트 URL의 /는 선택 사항이며, 다음 URL 중 어느 하나라도 인덱스 문서를 반환합니다.
http://www.examplebucket.com/
http://www.examplebucket.com
주의：
버킷에 폴더가 생성되면 폴더의 각 레벨에 인덱스 파일을 추가해야 합니다.
오류 문서
오류 문서를 설정하기 전이라고 가정한 후 아래 페이지에 액세스하면 404 상태 코드가 반환되며 페이지에 기본 오류 페이지 정보가 보입니다.
3. 정적 웹사이트 호스팅에 사용할 버킷을 찾아 해당 버킷 이름을 클릭하여 버킷 상세 페이지로 이동합니다.
4. 왼쪽 네비게이션 바에서 권한 관리 > 버킷 접근 권한을 선택하고, 공개 권한란에서 공개 읽기/비공개 쓰기를 선택한 후 저장합니다.
5. 왼쪽 네비게이션 바에서 기본 구성 > 정적 웹사이트를 선택하고, 정적 웹사이트란에서 편집을 클릭한 후 현재 상태의 활성화 버튼을 켭니다.
6. 정적 웹사이트 구성 항목을 순서대로 입력합니다.
구성 설명은 다음과 같습니다.
접근 노드: 정적 웹사이트를 활성화하면 해당 버킷과 연결된 정적 웹사이트 접근 노드(정적 웹사이트 도메인)를 얻게 됩니다. 이 접근 노드는 GET/HEAD Object 작업만 지원합니다.
주의:
정적 웹사이트의 접근 노드는 영문 대소문자를 구분합니다. 인덱스 파일, 오류 파일, 리디렉션 규칙 접두사 일치를 구성할 때 입력한 파일 이름과 확장자의 영문 대소문자가 버킷의 파일과 일치해야 함에 유의하십시오.
강제 HTTPS(선택 사항): 강제 HTTPS를 활성화하면 사용자가 정적 웹사이트에 접근할 때 정적 웹사이트 접근 노드가 HTTPS 프로토콜 방식으로 강제로 열립니다.
주의:
사용자 정의 도메인을 통해 정적 웹사이트에 접근하고 정적 웹사이트에서 강제 HTTPS가 활성화된 경우 해당 사용자 정의 도메인에 관련 인증서가 올바르게 구성되었는지 확인하십시오. 인증서에 이상이 있으면 기본 도메인으로 리디렉션되어 접근됩니다.
html 확장자 무시(선택 사항): 접근 경로가 index인 경우 index.html 객체를 자동으로 일치시켜 반환합니다.
인덱스 문서(필수): 인덱스 문서는 정적 웹사이트의 홈페이지로, 사용자가 웹사이트의 루트 디렉터리 또는 하위 디렉터리에 요청을 보낼 때 반환되는 웹페이지입니다. 일반적으로 이 페이지는 index.html로 명명됩니다.
주의:
버킷에 폴더가 생성되고 웹페이지가 해당 폴더를 참조하는 경우, 이러한 폴더 계층 구조 모두에 인덱스 문서를 추가해야 합니다.
2024년 1월 1일 이후 생성된 버킷의 경우 정적 웹사이트 도메인으로 접근할 때 인덱스 문서가 요청 시 웹 콘텐츠를 직접 반환하지 않고 다운로드됩니다.
오류 문서(선택): 오류 문서는 정적 웹사이트 접근 시 오류가 발생한 후 반환되는 페이지입니다. 이 구성 항목을 통해 사용자가 직접 오류 문서를 정의할 수 있습니다. 정적 웹사이트가 사용자의 요청에 응답할 수 없을 때 지정된 사용자 정의 오류 페이지가 반환됩니다. 예를 들어 error.html이라는 이름의 오류 문서를 구성한 경우, 사용자가 접근 시 HTTP 오류가 발생하면 error.html 페이지가 반환되어 도움말 안내를 제공합니다. 오류 문서를 구성하지 않은 경우, 사용자가 접근 시 HTTP 오류가 발생하면 기본 오류 메시지가 반환됩니다.
주의:
오류 문서 구성은 버킷 루트 디렉터리 또는 하위 디렉터리의 파일을 지원하며, 브라우저에서 인식할 수 있는 .html 또는 .htm 형식의 파일을 사용하십시오. 브라우저에서 인식할 수 없는 .zip과 같은 형식을 사용할 경우 대부분의 브라우저에서 오류가 발생하거나 접근이 거부될 수 있습니다.
오류 문서 응답 코드: 오류 문서가 설정된 경우 해당 항목이 표시됩니다. 오류 문서 반환 시 HTTP 응답 코드를 원본 오류 코드 또는 200으로 구성할 수 있습니다.
리디렉션 규칙(선택): 리디렉션 규칙을 사용하면 특정 파일 경로, 요청의 접두사 또는 응답 코드에 따라 조건부로 요청을 리디렉션할 수 있습니다.
예를 들어, 버킷에서 특정 파일을 삭제하거나 이름을 변경한 경우 해당 파일에 대한 접근 요청을 다른 파일로 리디렉션하도록 리디렉션 규칙을 추가할 수 있습니다.
유형: 리디렉션 규칙의 원본 유형을 의미합니다.
오류 코드: 현재 리디렉션 규칙은 4xx 오류 코드(예: 404)에 대한 리디렉션 구성만 지원합니다. 특정 오류 페이지를 사용자 정의할 수 있으며, 사용자가 해당 HTTP 오류를 트리거하는 경우 해당 오류 페이지에서 사용자에게 다른 안내를 제공할 수 있습니다.
접두사 일치: 버킷 내 파일 또는 폴더에 대한 리디렉션 설정을 위해 접두사 일치 규칙을 사용할 수 있습니다. 구체적인 예시는 리디렉션 규칙 예시를 참고하십시오.
주의:
접두사 일치는 와일드카드를 지원하지 않습니다. 접두사가 index1/, index2/인 두 폴더에 대해 리디렉션을 원하는 경우 index*/를 일치 규칙으로 사용할 수 없으며, 각각에 해당하는 일치 규칙을 설정해야 합니다.
설명: 리디렉션 규칙의 원본 오류 코드 또는 접두사.
규칙: 리디렉션 규칙의 대체 규칙으로, 대체 경로 및 대체 접두사를 포함합니다.
유형을 오류 코드로 선택한 경우, 규칙은 기본적으로 '대체 경로'로 설정됩니다. 대체 경로는 해당 리디렉션 규칙이 트리거된 후 원본 요청 주소가 새 페이지의 경로로 대체되는 것을 의미합니다.
유형을 접두사로 선택한 경우, 규칙은 '대체 경로' 또는 '대체 접두사'를 선택할 수 있습니다.
주의:
대체 경로는 버킷 내 객체 경로여야 합니다.
대체 내용: 대체될 파일 경로 또는 접두사.
7. 설정 완료 후 저장을 클릭하면 됩니다.
사용자 정의 도메인 설정
2024년 1월 1일 이후 생성된 버킷의 경우, 사용자가 기본 도메인(정적 웹사이트 도메인 포함)으로 파일에 접근하면 미리보기가 지원되지 않습니다. 따라서 정적 웹사이트 활성화한 후 정적 웹사이트를 미리 보려면 사용자 정의 도메인을 구성하고 사용해야 합니다. 작업 단계는 다음과 같습니다.
1. COS 콘솔에 로그인하여 버킷 상세 페이지로 이동한 후 도메인 및 전송 관리 > 사용자 정의 원본 서버 도메인을 선택합니다.
2. 사용자 정의 원본 서버 도메인 영역에서 도메인 추가를 클릭하고 사용자 정의 도메인을 입력합니다(없는 경우 도메인을 등록한 후 입력). 원본 서버 유형은 정적 웹사이트 원본 서버를 선택합니다. 구성 항목에 대한 자세한 내용은 사용자 정의 원본 서버 도메인 활성화하기를 참고하십시오.
3. 사용자 정의 도메인이 적용되도록 정적 웹사이트 CNAME 도메인으로 사용자 정의 도메인 해석도 설정해야 합니다. HTTPS로 접근하려면 HTTPS 인증서를 바인딩해야 합니다. 자세한 내용은 도메인 해석 구성 및 인증서 바인딩을 참고하십시오.
인벤토리 개요
최종 업데이트 날짜:：2025-12-08 16:19:03
인벤토리가 무엇인가요?
인벤토리는 사용자가 버킷의 객체를 관리하도록 도와주는 기능입니다. COS를 대신해 List API 동기화 작업을 주기적으로 할 수 있습니다. Cloud Object Storage(COS)는 사용자의 인벤토리 작업 설정에 따라 매일, 매주 또는 매월 사용자 버킷 내 지정된 객체 또는 동일한 객체 접두사를 가진 객체를 정기적으로 스캔하여 CSV 형식의 인벤토리 보고서를 생성하고 사용자가 지정한 버킷에 저장합니다. 또한 일회성 인벤토리 작업을 시작하여 즉시 인벤토리 보고서를 생성할 수도 있습니다. 파일에는 저장된 객체 및 해당 메타데이터가 나열되며 사용자의 구성 정보에 따라 사용자가 필요한 객체 속성 정보가 기록됩니다.
인벤토리 기능의 용도는 다음을 포함하며 이에 국한되지 않습니다.
객체 복사 및 암호화 상태를 심의하고 보고합니다.
비즈니스 작업 흐름 및 빅 데이터 작업을 간소화하고 가속화합니다.
주의：
사용자는 버킷에서 여러 개의 인벤토리 작업을 설정할 수 있으며 인벤토리 작업을 실행하는 동안 객체의 메타데이터 등의 속성 정보는 스캐닝할 수 있지만 객체 콘텐츠를 읽어 들일 수는 없습니다.
현재 금융 클라우드 리전은 지원하지 않습니다.
서브 계정으로 인벤토리 설정을 하려면 서브 계정이 루트 계정으로부터 cos:PutBucketInventory 및 cos:PutObject 작업 권한을 부여받았는지 확인하십시오.
인벤토리 매개변수
사용자가 인벤토리 작업을 설정한 후 COS는 설정에 따라 정기적으로 사용자 버킷 내에 지정된 객체를 스캐닝하며 CSV 형식 파일로 인벤토리 보고서를 출력합니다. 현재 COS 인벤토리 보고서는 다음 정보를 기록할 수 있습니다.
인벤토리 정보
설명
AppID
계정 ID
Bucket
인벤토리 작업을 실행할 버킷 이름
fileFormat
파일 형식
listObjectCount
나열된 객체 수량. 이 항목에 따라 요금이 부과되며, 자세한 사항은 관리 기능 요금 의 인벤토리 기능 요금 부분을 참고하십시오.
listStorageSize
나열된 객체 크기
filterObjectCount
선별된 객체 수
filterStorageSize
선별된 객체 크기
Key
버킷의 객체 파일 이름. CSV 파일 형식을 사용할 때 객체 파일 이름은 URL 코드 형식으로 복호화한 후 사용할 수 있습니다.
VersionId
객체 버전 ID. 버킷에서 버전 제어를 활성화한 후 COS는 버킷에 추가된 객체에 버전 번호를 지정할 수 있습니다. 인벤토리가 객체의 현재 버전 전용인 경우 해당 필드는 포함하지 않습니다.
IsLatest
객체가 최신 버전이라면 True로 설정합니다. 인벤토리가 객체의 현재 버전 전용인 경우 해당 필드는 포함하지 않습니다.
IsDeleteMarker
객체가 삭제 마커라면 True로 설정합니다. 인벤토리가 객체의 현재 버전 전용인 경우 해당 필드는 포함하지 않습니다.
Size
객체 크기(바이트 Byte)
LastModifiedDate
객체의 최근 수정 일자(늦은 일자 기준)
ETag
실물 태그는 객체의 해시 값입니다. ETag는 객체 콘텐츠의 변경 내용만 반영되며 객체 메타데이터의 변경 내용은 반영되지 않습니다. ETag는 객체 데이터 MD5의 요약일 수도 있고 아닐 수도 있습니다. 이 여부는 객체의 생성 방식과 암호화 방식으로 결정되지 않습니다.
객체가 멀티파트 업로드의 형식으로 업로드되면 True로 설정합니다. 자세한 내용은 멀티파트 업로드를 참고하십시오.
Replicationstatus
객체 복제에서 소스 및 복제본 파일의 상태입니다. 소스 파일 상태: PENDING(복제 예정), COMPLETED(복제됨) 또는 FAILED(복제 실패); 복제 파일 상태: REPLICA(생성된 복제 파일로 복제됨). 자세한 내용은 복사 작용 설명을 참고하십시오.
Tag
객체 태그
Crc64
객체의 CRC64 정보.
x-cos-meta-*
객체의 사용자 정의 메타데이터 정보(예: x-cos-meta-testheader). 인벤토리는 해당 객체 메타데이터를 출력하며, 객체에 해당 메타데이터가 없으면 비워둡니다.
주기적 인벤토리 및 일회성 인벤토리
인벤토리는 주기적 인벤토리와 일회성 인벤토리 두 가지 유형을 지원합니다.
주기적 인벤토리: 사용자가 인벤토리 규칙을 설정한 후 월별, 주별 또는 일별로 인벤토리 보고서를 생성할 수 있도록 지원합니다. 월별의 경우 생성할 날짜(1~28일 설정 가능)를 지정해야 하며, 주별의 경우 규칙은 설정한 요일에 따라 생성됩니다.
일회성 인벤토리: 일회성 인벤토리 작업을 시작하여 일회성 보고서를 생성합니다. 현재 COS는 일회성 인벤토리 작업에 대한 기록 조회를 지원하지 않으므로, 이후 보고서를 찾을 수 있도록 작업 시작 규칙 id, 인벤토리 저장 경로 등의 정보를 잘 보관하시기 바랍니다.
인벤토리 설정 방법
인벤토리를 설정하기 전 두 가지 개념을 알아야 합니다.
소스 버킷: 인벤토리 기능을 활성화하고 싶은 버킷.
인벤토리가 나열한 객체를 포함합니다.
인벤토리 설정을 포함합니다.
타깃 버킷: 스토리지 인벤토리의 버킷.
인벤토리 목록 파일을 포함합니다.
Manifest 파일을 포함하며 인벤토리 목록 파일 위치를 설명합니다.
다음은 인벤토리 설정 절차입니다.
소스 버킷에서 분석할 객체 정보 지정
COS에 어떤 객체 정보 분석이 필요한지 보고해야 합니다. 따라서 인벤토리 기능을 설정할 때 소스 버킷에서 아래 정보를 설정해야 합니다.
객체 버전 선택: 모든 객체 버전을 나열하거나 현재 버전만 나열합니다. 모든 객체 버전 나열을 선택했다면 COS는 동일 이름을 가진 객체의 지난 모든 버전을 인벤토리 보고서에 나열합니다. 현재 버전만 나열하도록 선택했다면 COS는 최신 버전 객체만 기록합니다.
분석이 필요한 객체 속성 설정: 객체 속성 중 어떤 정보가 인벤토리 보고서에 어떤 정보가 기록되는지 COS에 알려야 하며 현재 지원하는 객체 속성은 계정 ID, 소스 버킷 이름, 객체 파일 이름, 객체 버전 ID, 최신 버전 여부, 삭제 마커 여부, 객체 크기, 객체 최신 수정 일자, ETag, 객체 스토리지 종류, 리전 간 복제 표시, 멀티파트 업로드 파일에 속하는지의 여부가 포함됩니다.
인벤토리 보고서의 스토리지 정보 설정
COS는 어느 주파수에 따라 인벤토리 보고서를 내보낼지 공지하며 어느 버킷에 인벤토리 보고서가 저장되고 암호화 여부가 필요한지 결정합니다. 설정이 필요한 정보는 다음과 같습니다.
인벤토리 내보내기 빈도수 선택: 매일 혹은 매주. 이 설정을 통해 COS에 어떤 빈도수에 따라 인벤토리 기능을 실행할지 알릴 수 있습니다.
인벤토리 암호화 선택: 비암호화 혹은 SSE-COS. SSE-COS 암호화를 선택했다면 생성한 인벤토리 보고서에 대해 암호화를 진행합니다.
인벤토리를 내보낼 위치 설정: 버킷 저장이 필요한 인벤토리 보고서를 지정해야 합니다.
주의：
타깃 버킷은 반드시 소스 버킷과 동일 리전에 위치해야 하며 양자는 동일 버킷일 수 있습니다.
2. 왼쪽 네비게이션 바에서 버킷 목록을 클릭한 후 인벤토리 규칙이 생성된 버킷(소스 버킷)으로 이동합니다.
3. 왼쪽 기본 설정 > 인벤토리 설정을 클릭한 후 해당 인벤토리 규칙을 찾고 더보기 > 인벤토리 미리보기를 클릭하면 빠르게 인벤토리 결과를 확인할 수 있습니다.
4. 인벤토리 미리보기 페이지에서는 현재 규칙에 따라 생성된 모든 인벤토리(정기 인벤토리 및 실시간 인벤토리)가 표시됩니다. 인벤토리 디렉토리로 바로 이동하여 인벤토리 결과를 확인할 수 있으며, 날짜 및 인벤토리 유형별로 필터링이 가능합니다.
주의:
인벤토리 작업을 시작한 후 인벤토리 결과는 점차 업데이트되며, 인벤토리 디렉토리 아래의 manifest.json 파일이 생성된 후에야 인벤토리 결과가 완전히 생성됩니다.
5. 날짜 선택이 완료되면 인벤토리 디렉토리명 열에서 특정 디렉토리를 클릭하면 해당 디렉토리로 빠르게 이동할 수 있으며, 생성된 인벤토리 내용을 확인할 수 있습니다. 자세한 내용은 인벤토리 보고서 저장 경로를 참고하십시오.
6. 인벤토리 결과를 직접 확인하려면 작업 열에서 인벤토리 결과 보기를 클릭하면 구성한 필터 조건에 따른 객체 총 수와 크기를 확인할 수 있습니다. 더 자세한 인벤토리 정보는 다운로드를 클릭하여 압축 해제 후 확인할 수 있습니다.
7. 다운로드한 CSV 파일의 해당 필드명은 manifest.json 파일의 'fileSchema'에서 확인할 수 있습니다. 더 많은 필드 의미와 설명은 인벤토리 매개변수를 참고하십시오.
API로 인벤토리 설정
API를 사용해 지정 버킷에 인벤토리 기능을 활성화하려면 다음 단계를 참고하십시오.
1. COS 역할을 생성합니다.
2. COS 역할 권한을 바인딩합니다.
3. 인벤토리 기능을 활성화합니다.
1. COS 역할 생성
COS 역할 생성과 구체적인 인터페이스 정보는 CreateRole을 참고하십시오.
roleName은 반드시 COS_QcsRole이어야 합니다.
policyDocument:
{
"version":"2.0",
"statement":[{
"action":"name/sts:AssumeRole",
"effect":"allow",
"principal":{
"service":"cos.cloud.tencent.com"
}
}]
}
2. COS 역할 권한 바인딩
역할 권한 바인딩 권한과 구체적인 인터페이스 정보는 AttachRolePolicy를 참고하십시오.
policyName은 QcloudCOSFullAccess, roleName은 1단계의 COS_QcsRole입니다. roleName 생성 시 반환된 roleID를 사용할 수 있습니다.
3. 인벤토리 기능 활성화
인벤토리 파일을 저장할 대상 버킷과 소스 버킷은 동일한 리전에 있어야 하며, 인터페이스를 호출하여 인벤토리 기능을 활성화해야 합니다. 구체적인 인터페이스 정보는 다음과 같습니다.
인벤토리 작업을 시작한 후 인벤토리 결과는 점차 업데이트되며, 인벤토리 디렉토리 아래의 manifest.json 파일이 생성된 후에야 인벤토리 결과가 완전히 생성됩니다.
경로에서 나타내는 의미는 다음과 같습니다.
destination-prefix: 사용자가 인벤토리를 설정할 때 설치하는 ‘타깃 접두사’입니다. 타깃 버킷에서 공용 위치에 있는 모든 인벤토리 보고서를 그룹화하는데 사용할 수 있습니다.
source-bucket: 인벤토리 보고서와 일치하는 소스 버킷 이름입니다. 이 폴더는 각각의 인벤토리 보고서를 여러 소스 버킷에서 동일한 타깃 버킷에 발송할 때 발생하는 충돌을 방지하기 위함입니다.
config-ID: 사용자가 인벤토리를 설정할 때 설치된 ‘인벤토리 이름’으로 동일한 소스 버킷이 여러 인벤토리 보고서를 설치하고 이를 동일한 타깃 버킷에 발송할 때 config-ID로 상이한 인벤토리 보고서를 구분할 수 있습니다.
YYYYMMDD: 타임스탬프. 인벤토리 보고서를 생성할 때 버킷이 스캐닝하기 시작하는 시간과 일자를 포함합니다.
manifest.json: Manifest 파일을 가리킵니다.
manifest.checksum: manifest.json 파일 콘텐츠의 MD5를 가리킵니다.
그 중 Manifest와 관련된 파일은 총 2개의 파일로 manifest.json과 manifest.checksum 입니다.
설명：
Manifest 관련 파일 소개는 다음과 같습니다.
manifest.json과 manifest.checksum은 모두 Manifest 파일입니다. manifest.json은 인벤토리 보고서의 위치를 설명하고 manifest.checksum은 manifest.json 파일 콘텐츠의 MD5입니다. 새로운 인벤토리 보고서를 딜리버리할 때마다 새로운 Manifest 파일이 따라 나올 수 있습니다.
manifest.json이 포함하는 모든 Manifest는 인벤토리의 메타데이터와 관련된 기타 기본 정보를 제공하며 그 정보는 아래와 같습니다.
소스 버킷 이름.
타깃 버킷 이름.
인벤토리 버전.
타임스탬프. 인벤토리 보고서 생성 시 버킷 일자와 시간을 스캐닝하기 시작합니다.
매니페스트 파일의 형식과 구성.
타깃 버킷 인벤토리가 보고하는 객체 키, 크기, md5Checksum.
다음은 CSV 형식 인벤토리의 manifest.json 파일에 있는 Manifest 예시입니다.
COS 인벤토리 보고서는 새 객체와 덮어쓴 PUT 그리고 삭제의 최종 일관성을 제공합니다. 따라서 인벤토리 보고서에는 최근 추가되거나 삭제한 객체가 포함되지 않을 수 있습니다. 예시로 COS가 사용자 설정의 인벤토리 업무 과정을 실행할 때 사용자가 객체를 업로드하거나 삭제할 경우 이 작업 결과는 인벤토리 보고서에 반영되지 않을 수 있습니다.
객체가 작업을 실행하기 전 객체의 상태를 확인하려면 HEAD Object API를 사용하여 객체 메타데이터를 인덱스하거나 COS 콘솔에서 객체 속성을 조회하시기 바랍니다.
버킷 태그 개요
최종 업데이트 날짜:：2025-09-24 17:45:28
개요
버킷 태그는 키 값 쌍(key = value)입니다. 태그 키(Key), 태그 값(Value), “=”로 이루어집니다. 예시 group = IT. 버킷을 관리하는 표시로서 사용자가 버킷을 그룹 관리하는 경우 편리합니다. 지정 버킷에 태그 설정, 조회, 삭제 작업을 할 수 있습니다.
규격 및 제한
태그 키 제한
qcs:, project, 항목등을 첫 글자로 시작하는 태그 키는 시스템에 미리 남겨진 태그 키이며 시스템에 미리 남겨진 태그 키는 생성할 수 없습니다.
UTF-8 포맷은 문자 부호, 빈칸, 숫자, 특수 문자 + - = ._ : / @ 로 나타낼 수 있습니다.
태그 키 길이는 문자 부호 1 - 127개까지 허용합니다(UTF-8 포맷 적용).
태그 키는 영어 대소문자를 구별합니다.
태그 값 제한
UTF-8 포맷은 문자 부호, 빈칸, 숫자, 특수 문자 + - = ._ : / @ 로 나타낼 수 있습니다.
객체 태그 기능은 객체에 키 값 쌍을 식별자로 추가하여, 사용자가 버킷에 있는 객체를 그룹화하고 관리하는 데 도움이 되도록 설계되었습니다. 객체 태그는 태그 키(tagKey)와 태그 값(tagValue), 그리고 =로 연결되어 구성됩니다(예: group=IT). 사용자는 지정 객체의 태그 설정, 조회, 삭제 작업을 할 수 있습니다.
객체 태그를 설정한 후 동일한 객체 태그를 가진 객체에 대해 생명주기 규칙을 빠르게 설정할 수 있습니다. 자세한 내용은 생명주기 설정을 참조하세요.
이벤트 알림
최종 업데이트 날짜:：2024-06-24 17:04:20
개요
COS 리소스에 변동이 생긴 경우 (예를 들어 새 파일 업로드, 파일 삭제) 곧바로 공지 메세지를 받을 수 있습니다. 이벤트 공지는 SCF(Serverless Cloud Function)와 결합하여 더욱 많은 응용 시나리오를 만들어 냅니다.
제품간 연동: 새 파일을 COS에 업로드하면 CDN 캐시가 자동으로 새로 고침됩니다. 새 파일을 COS에 업로드하면 자동으로 데이터베이스가 갱신됩니다.
시스템 통합: COS 상의 파일에 변경(새로 만들기, 삭제, 덮어쓰기)이 생긴 경우 자동으로 서비스 인터페이스를 호출합니다. UGC(User Generated Content) 시나리오에서 이벤트 공지 기능을 기반으로 모바일과 서버가 연동됩니다.
데이터 프로세스: COS 파일은 자동으로 프로세스됩니다. 자동 압축 해제, AI 인식 등을 예로 들 수 있습니다.
COS 이벤트 공지는 다음과 같은 특징을 가집니다.
비동기화 프로세스: 공지 발송은 COS의 정상 작업에 영향을 주지 않습니다.
공지 타깃: 리전 내 SCF 함수로의 공지만 발송합니다.
현재 다음 COS 이벤트를 지원합니다.
이벤트 유형
설명
cos:ObjectCreated:*
아래 언급한 모든 업로드 이벤트는 SCF를 트리거할 수 있습니다.
cos:ObjectCreated:Put
PUT Object 인터페이스를 사용해 파일을 생성할 때 SCF를 트리거합니다.
cos:ObjectCreated:Post
POST Object 인터페이스를 사용해 파일을 생성할 때 SCF를 트리거합니다.
cos:ObjectCreated:Copy
PUT Object - Copy 인터페이스를 사용해 파일을 생성할 때 SCF를 트리거합니다.
cos:ObjectCreated:CompleteMultipartUpload
Complete Multipart Upload 인터페이스를 사용해 파일을 생성할 때 SCF를 트리거합니다.
cos:ObjectCreated:Origin
이미지 Origin-pull이 발생한 경우 SCF를 트리거합니다.
cos:ObjectCreated:Replication
리전 간 복제로 객체를 생성할 경우 SCF를 트리거합니다.
cos:ObjectRemove:*
아래 언급한 모든 삭제 이벤트는 SCF를 트리거할 수 있습니다.
cos:ObjectRemove:Delete
버전 제어 버킷을 활성화하지 않고 DELETE Object 인터페이스로 객체를 삭제하거나 versionid를 사용해 지정된 버전의 객체를 삭제할 경우 SCF를 트리거합니다.
cos:ObjectRemove:DeleteMarkerCreated
활성화되어 있거나 잠시 중지된 버전이 제어하는 버킷에서 DELETE Object 인터페이스로 객체를 삭제할 경우 SCF를 트리거 합니다.
cos:ObjectRestore:Post
보관 복구 작업이 생성될 때 SCF를 트리거합니다.
cos:ObjectRestore:Completed
보관 복구 작업이 완료되었을 때 SCF를 트리거합니다.
COS 이벤트 공지 사용 방법
다음은 COS 이벤트 공지 사용 절차입니다.
1. SCF 함수 생성
SCF 콘솔이나 CLI를 통해 함수를 생성할 수 있습니다. 함수 생성을 위해 실행 환경 선택(함수 편집을 할 때 사용할 언어 선택), 함수 코드(온라인 편집이나 로컬 업로드 코드 패키지 지원) 제출이 필요합니다.
미리 설정된 SCF 템플릿으로 생성 절차를 간소화시킬 수 있습니다. 자세한 내용은 함수 생성을 참조하십시오. 함수 작성 방법은 프로그래밍 언어에 따라 다릅니다. 자세한 내용은 SCF 문서를 참조하십시오.
2. 함수 테스트
함수 생성 완료 후 테스트 템플릿 기능을 사용해 테스트를 진행할 수 있습니다. 테스트 템플릿은 COS 이벤트를 시뮬레이션하며 함수 실행을 트리거 합니다. 자세한 내용은 함수 테스트를 참조하십시오.
3. 트리거 추가
테스트 완료 후 COS 트리거 생성을 통해 SCF 함수와 버킷을 바인딩할 수 있으며 콘솔이나 명령 라인으로 트리거를 추가할 수 있습니다. 자세한 내용은 트리거 생성 문서를 참조하십시오.
4. 실제 인증
위 절차를 완료한 후 COS 버킷을 조작하여 전체 프로세스가 정상인지 인증할 수 있습니다. 예를 들어 콘솔, COS Browser 등의 툴을 통해 파일을 업로드 및 삭제하며 SCF 콘솔 > 함수 세부 사항 > 일치하는 함수 명 > 실행 로그 순서로 정상 작동하는지 인증할 수 있습니다.
COS Select 기능은 구조화된 쿼리 명령(SQL)을 통해 Cloud Object Storage(COS)에 저장된 객체를 선별하여 객체나 사용자가 필요한 데이터를 인덱스하기 쉽도록 합니다. COS Select 기능으로 객체 데이터를 선별하여 COS에 전송된 데이터 양을 줄이면 데이터 검색에 필요한 비용과 딜레이 현상을 줄일 수 있습니다.
현재 COS Select 기능은 CSV, JSON, Parquet 포맷 형태의 버킷 객체와 GZIP이나 BZIP2로 압축된 객체(CSV, JSON 포맷의 객체) 인덱스를 지원합니다. 또한 COS Select 기능으로 결과물을 CSV나 JSON 포맷으로 지정할 수 있으며 결과 기록을 어떻게 구분할지 지정할 수 있습니다.
요청을 통해 SQL 표현식을 COS에 전송할 수 있습니다. 현재 COS Select는 일부 SQL 표현식만 지원합니다. COS Select가 지원하는 SQL 표현식에 대한 자세한 정보는 SQL 함수 문서를 참고하십시오.
COS 콘솔, API, SDK, COSCMD 등의 방식으로 SQL쿼리를 실행할 수 있습니다. COS 콘솔을 사용하여 파일 검색을 진행할 때는 일부 제한 사항이 있음을 주의하십시오. 최대 128M 파일 검색을 지원하며 데이터양은 40MB까지 반환됩니다. 더 많은 데이터를 인덱스 하려면 다른 방식을 사용해 주십시오.
설명：
COS Select가 지원하는 데이터 유형과 현재 예약된 필드는 데이터 유형과 보관 필드에서 자세히 볼 수 있습니다.
현재 검색 기능은 중국 본토의 퍼블릭 클라우드 지역, 자카르타, 버지니아(미국 동부) 지역을 지원합니다. 다른 지역에서는 이 기능이 아직 지원되지 않습니다.
사용 제한
COS Select을 사용할 때 다음과 같은 제한 사항이 있습니다.
조회 대상의 cos:GetObject 권한을 가지고 있어야 합니다. 루트 계정은 기본적으로 이 권한을 가지고 있습니다.
조회할 때 오류가 생기면 COS Select는 오류 코드와 관련 오류 메시지를 반환합니다. 관련 오류 코드와 설명 리스트는 Special error codes를 참고하십시오.
Select 명령어
최종 업데이트 날짜:：2024-06-24 17:04:20
개요
COS Select 기능은 필요한 일부 데이터를 쉽게 인덱스할 수 있도록 SELECT SQL쿼리 명령을 지원하여 비용을 감소시키고 요청 딜레이를 줄일 수 있습니다. 다음은 SELECT 조회에서 지원하는 표준 절입니다.
SELECT 명령
WHERE 절
LIMIT 절
주의：
현재 COS Select는 절 쿼리 혹은 joins를 지원하지 않습니다.
SELECT 명령
SELECT 명령으로 COS 객체에서 보고 싶은 데이터를 인덱스할 수 있습니다. 이름, 함수, 표현식 등으로 데이터 조회가 가능하며 리스트의 형식으로 조회 결과를 반환합니다. SELECT 명령 포맷은 다음과 같습니다.
SELECT *
SELECT projection [ AS column_alias | column_alias ][, ...]
첫번째 절의 SELECT 명령은 *(별표)가 표시되며 COS 객체에서 모든 열을 반환합니다. 두번째 절의 SELECT 명령은 사용자 지정을 사용하여 스칼라 표현식을 출력하고 projection은 모든 열에 사용자 지정 이름의 출력 리스트를 생성합니다.
WHERE 절
WHERE 절은 다음 구문을 사용합니다.
WHERE condition
WHERE 절은 condition을 통해 필터링을 진행합니다. condition은 Boolean 결과를 반환할 수 있는 표현식입니다. 반환 값이 TRUE인 행이어야 결과를 출력할 수 있습니다.
LIMIT 절
LIMIT 절은 다음 구문을 사용합니다.
LIMIT number
LIMIT 절은 조회 당 반환 되는 기록 수를 제한합니다. number 매개변수를 이용해 이 제한을 지정할 수 있습니다.
액세스 속성
SELECT와 WHERE 절은 파일 포맷이 CSV인지 JSON인지에 따라 다음 방식으로 조회할 필드를 선택할 수 있습니다.
CSV
열 번호: 제 N열의 조회할 데이터는 _N을 통해 지정할 수 있습니다. 어느 CSV 파일이든 열 번호는 1부터 증가합니다. 첫 열의 일련 번호가 _1인 경우 두번째 열의 일련 번호는 _2입니다. SELECT와 WHERE 절에서 _N이나 alias._N을 통해 조회할 열을 지정하는 것은 유효합니다.
열 헤더: 조회할 CSV 파일에 헤더가 있다면 SELECT나 WHERE 절에서 이 헤더를 통해 조회가 필요한 열을 지정할 수 있습니다. SQL 명령에서는 SELECT나 WHERE 절의alias.column_name 혹은 column_name으로 지정합니다.
JSON
문서(Document): alias.name방식을 사용하여 JSON 문서에 액세스할 수 있습니다. 중첩된 배열은 alias.name1.name2.name3과 같은 방식으로 액세스할 수 있습니다.
리스트(List): 0부터 일련번호가 매겨지고 [] 오퍼레이터를 사용하는 인덱스 기능으로 리스트 요소에 액세스할 수 있습니다. 예시로 alias[1]를 통해 JSON 리스트의 2번째 요소에 액세스할 수 있습니다. 중첩 배열에 액세스 해야 하는 경우 alias.name1.name2[1].name3과 같은 방식으로 액세스할 수 있습니다.
예시
다음은 예시 데이터 샘플입니다.
{
"name":"Leon",
"org":"Tencent",
"projects":
[
{"project_name":"project1", "completed":true},
{"project_name":"project2", "completed":false}
]
}
예시1: 다음은 데이터 예시 중 이름을 조회하는 SQL 명령 및 조회 결과입니다.
Select s.name from COSObject s
{"name":"Leon"}
예시2: 다음은 데이터 예시 중 프로젝트 이름을 조회하는 SQL 명령 및 조회 결과입니다.
Select s.projects[0].project_name from COSObject s
{"project_name":"project1"}
헤더와 속성 이름의 대소문자 민감성
큰따옴표를 사용하여 CSV 파일의 헤더와 JSON 파일의 속성 이름을 표시하여 대소문자를 구분하는지 알 수 있습니다. 큰따옴표를 추가하지 않으면 헤더/속성 이름은 대소문자를 구분하지 않으며 명확하게 설정이 되어 있지 않은 경우 COS Select가 이상 경고를 보냅니다.
예시 1: 헤더/속성 이름에서 "NAME"이 있는 객체를 조회합니다.
다음 SQL 예시는 큰따옴표를 사용하지 않았으므로 대소문자를 구분하지 않습니다. 이 헤더가 테이블에 포함되기 때문에 값이 반환될 수 있습니다.
SELECT s.name from COSObject s
다음 SQL 예시는 큰따옴표를 사용하여 대소문자를 구분합니다. 테이블에서 이 헤더를 포함하지 않아 400 오류인 SQLParsingError이 반환됩니다.
SELECT s."name" from COSObject s
예시2: 헤더/속성 이름을 조회할 때 "NAME"과 "name"객체가 있습니다.
다음 SQL 예시는 큰따옴표를 사용하지 않아 대소문자를 구분하지 않습니다. 테이블에 "NAME"과 "name" 두 개의 헤더를 함께 포함하여 조회 명령 설정이 명확하지 않으므로 AmbiguousFieldName 이상 경고가 반환될 수 있습니다.
SELECT s.name from COSObject s
다음 SQL 예시는 큰따옴표를 사용하여 대소문자를 구분합니다. 테이블에 "NAME" 헤더가 포함되기 때문에 조회 결과가 반환될 수 있습니다.
SELECT s."NAME" from COSObject s
예약된 필드를 사용자 지정 필드로 사용하기
COS Select의 SQL 표현식에는 함수 이름, 데이터 유형, 오퍼레이터 등의 예약된 필드가 있습니다. 사용자는 예약된 필드를 CSV 파일 열 헤더 혹은 JSON 파일의 속성 이름으로 사용할 수 있는데 이때 예약된 필드와 충돌할 가능성이 있습니다. 이런 경우 큰따옴표를 사용하여 사용자 지정 필드가 사용 중임을 나타냅니다. 그렇지 않은 경우 COS가 400 parse error 오류를 반환할 수 있습니다.
Cloud Object Storage(COS) Select를 사용하면 스토리지 수준에서 원하는 데이터를 필터링하여 COS에서 전송하는 데이터의 양을 크게 줄여 사용 비용을 낮추고 데이터 수집 효율성을 높일 수 있습니다. COS 콘솔에서 우리가 제공하는 표준 SQL 템플릿을 사용하거나 구문 규칙을 준수하는 명령문을 지정하여 버킷에 저장된 개별 파일에서 데이터를 추출할 수 있습니다.
설명：
검색 기능은 현재 JSON, CSV 및 Parquet 파일 형식의 객체에 적용됩니다. JSON 및 CSV 형식은 중국 본토의 공공 클라우드 지역과 버지니아 지역에서만 지원되며, Parquet 형식은 베이징 지역에서만 지원됩니다.
추출할 파일이 COS Select 사양을 준수하는지 확인하십시오. COS Select 사양에 대한 자세한 내용은 Select 개요를 참고하십시오.
콘솔의 COS Select는 최대 128MB 파일에서 최대 40M 데이터 추출을 지원합니다. 더 큰 파일을 처리하거나 더 많은 데이터를 추출하려면 API 또는 SDK를 사용하십시오.
현재 스탠다드 스토리지, 스탠다드IA 스토리지 및 인텔리전트 티어링 스토리지 클래스의 객체만 추출할 수 있습니다.
6. 파일 유형, 헤더 필드, 세퍼레이터, 압축 포맷 및 내보내기 포맷 필드를 구성합니다.
7. SQL 템플릿 선택을 클릭합니다.
8. 팝업 창에서 추출에 사용할 템플릿 구문을 선택하고 확인을 클릭합니다.
9. 실제 파일을 기반으로 텍스트 상자에서 명령문을 편집하고 SQL 실행을 클릭하십시오.
이제 맨 아래의 텍스트 상자에서 처음 100개의 결과를 볼 수 있습니다. 전체 데이터 세트를 얻으려면 추출 결과 내보내기를 클릭하십시오.
로그 관리
로그 관리 개요
최종 업데이트 날짜:：2025-10-10 09:50:02
소개
로그 관리 기능은 버킷을 더 편리하게 관리할 수 있도록 지정한 원본 버킷의 액세스 상세 정보를 기록하고 해당 정보를 로그 파일 포맷으로 지정할 수 있습니다.
대상 버킷에서 로그 기록 경로는 다음과 같습니다.
대상 버킷/경로 접두사{YYYY}/{MM}/{DD}/{time}_{random}_{index}
로그는 5분마다 생성되어 한 줄씩 기록됩니다. 모든 기록은 여러 개의 필드를 포함하고 각 필드는 빈칸으로 분할됩니다. 주의할 점은 단일 로그 파일의 최대 크기가 256MB이며, 5분 이내 발생된 로그량이 256MB을 초과할 경우 로그는 여러 개의 로그 파일로 분할된다는 것입니다. 현재 지원하는 로그 필드는 다음과 같습니다.
무효 필드 설명: 로그 중 - 이 문자가 존재한다면, 해당 필드가 무효 또는 기본값으로 기록됐다는 의미입니다.
로그에 기록되는 내용
사용자가 시작한 업로드/다운로드/객체 삭제, 및 버킷 생성/삭제, 버킷 설정 수정 등의 요청을 기록합니다.
사용자가 CDN을 통해 콘텐츠를 배포하고, CDN에서 COS 원본 서버로 데이터를 가져올 때 발생한 요청을 기록합니다.
로그에 기록되지 않는 내용
오프라인 원본 요청: 사용자가 원본을 설정한 후, COS에 객체가 없으면 사용자가 지정한 원본 서버에서 데이터를 다운로드합니다. 이 다운로드 작업, 즉 오프라인 원본 요청은 로그에 기록되지 않습니다.
정적 웹 사이트 내부 리디렉션 작업: 사용자가 정적 웹 사이트 기능에서 리디렉션을 설정했을 경우, index.html에 액세스하면 다른 페이지로 리디렉션될 수 있으며, 이런 리디렉션 작업은 로그에 기록되지 않습니다.
라이프사이클 전환, 삭제 등 작업: 사용자가 라이프사이클 기능을 설정해 객체에 만료 전환 또는 삭제를 진행할 경우, 이런 전환 및 삭제 작업은 COS 백그라운드에서 이뤄지며 로그에 기록되지 않습니다.
객체 리스트 나열 및 업로드 리스트 보고 작업: 리스트 기능은 사용자를 대신해 주기적으로 버킷 내 전체 또는 지정 객체를 나열하고, 생성된 리스트 보고를 사용자 버킷으로 전달하지만, 객체 나열 및 리스트 보고 전달 작업은 로그에 기록되지 않습니다.
리전 간 복제 객체 작업: 리전 간 복제 기능은 소스 버킷에서 객체를 얻고 객체를 타깃 버킷으로 업로드해야 합니다. 이런 작업은 COS 백그라운드에서 이뤄지며 로그에 기록되지 않습니다.
COS Select 기능 중 객체 다운로드 작업: COS Select 기능은 사용자의 객체 인덱스를 도와주며, 먼저 스토리지 디바이스에서 데이터를 가져와야 인덱스가 가능합니다. 객체 다운로드 작업은 COS 백그라운드에서 이뤄지며 로그에 기록되지 않습니다.
COS를 사용하여 Tencent Cloud 제품 로그 저장
최종 업데이트 날짜:：2024-06-24 17:04:20
소개
Tencent Cloud 서비스를 사용할 때 대량의 로그가 생성되는데, 이 로그들은 귀하의 업무 상황을 기록해 업무 상황을 분석하는 데 도움이 되며 귀하의 업무 발전과 의사 결정에 도움을 줍니다. COS 스토리지 기능을 이용해 클라우드 서비스 로그를 지속적으로 저장할 수 있으며, API, SDK 또는 툴 등을 통해 COS로부터 로그를 쉽게 얻고 분석할 수 있습니다.
COS 스토리지 클라우드 서비스 로그를 사용하면 다음 문제를 해결할 수 있습니다.
영구 스토리지: COS는 안정된 영구 스토리지 서비스를 제공하므로 낮은 비용으로 로그를 COS로 저장해 영속화 저장이 가능합니다. 업무 필요에 의해 로그를 기반으로 분석 또는 의사 결정 시, COS를 통해 언제 어디서나 임의 시간대의 로그를 얻을 수 있습니다.
데이터 인덱스: COS는 Select 기능을 제공하므로 해당 기능으로 COS에 저장된 로그에 대한 간단한 인덱스 및 추출이 가능합니다. 로그의 필드를 결합하면 필요한 정보를 인덱스하고 데이터 다운로드 트래픽을 줄일 수 있습니다.
데이터 분석: Sparkling 제품을 사용하여 COS에 저장된 로그를 분석할 수 있으며, 하나 이상의 로그 파일을 선택하고 Sparkling을 사용하여 로그를 분석하고 분석 결과를 기반으로 의사 결정을 내릴 수 있습니다.
로그 전송 방식
두 가지 방식으로 Tencent Cloud 서비스의 로그를 COS에 저장할 수 있습니다.
클라우드 서비스 자체 로그 전송 기능 사용: 예를 들어 COS, CA 등 제품은 로그를 COS로 직접 전송할 수 있습니다.
로그 서비스 CLS의 전송 기능 사용: CLS로 전송된 클라우드 서비스 로그는 CLS를 통해 COS로 전송돼 영구 저장됩니다.
현재 Tencent Cloud 서비스의 이 두 가지 방식에 대한 지원 상황은 다음과 같습니다.
경로 접두사는 자동 지정되며, 식별 가능한 경로 설정을 권장합니다. 예시: cos_bucketname_access_log/timestamp
설명：
메시지 큐는 해당 제품에서 생성된 정보 데이터의 전송을 지원합니다. CKafka 인스턴스 생성 등 동작 로그를 얻어야 할 경우, CA 제품을 전송할 로그를 선택하십시오.
CLS를 통해 COS로 로그 전송하기
다음 Tencent Cloud 서비스는 사용자가 인덱스 및 분석을 할 수 있도록 로그를 CLS로 전송하는 기능을 제공합니다. CLS는 COS로 전송하는 제품 기능도 동시에 제공하여, 사용자가 로그를 쉽게 영구 저장할 수 있게 합니다. CLS로의 로그 전송을 지원하는 제품도 CLS 밖에서 COS로 전송된 로그를 활성화하는 방식을 통해 데이터를 영구 저장해 스토리지 비용을 낮추고 보다 편리한 오프라인 분석이 가능합니다. 현재 CLS로의 직접 로그 전송을 지원하는 제품은 다음과 같습니다.
세퍼레이터 포맷 전송: 데이터를 세퍼레이터 포맷에 따라 COS로 전송합니다. 자세한 내용은 CSV Shipping을 참고하십시오.
JSON 포맷 전송: 데이터를 JSON 포맷에 따라 COS로 전송합니다. 자세한 내용은 JSON Shipping을 참고하십시오.
원문 포맷 전송: 데이터를 원문 포맷에 따라 전송합니다. 단일 행 텍스트, 다중 행 텍스트 전송을 지원하며, 부분적으로 CSV 포맷 전송을 지원합니다. 자세한 내용은 Source Format Shipping을 참고하십시오.
CLS를 통해 COS로 로그를 전송하려면 다음 작업을 수행해야 합니다.
1. 업무 필요에 따라 해당 제품을 선택하고, 위에서 제공한 제품 로그 전송 문서 링크 가이드에 따라 로그셋 및 로그 테마를 설정하면, 업무에서 발생한 데이터가 CLS로 연결됩니다.
2. 이후, 업무 필요에 따라 적합한 포맷을 선택해 데이터를 COS로 전송합니다. 로그를 COS로 보낼 때, 제품 이름을 경로 접두사로 삼아 서로 다른 제품 로그를 구분하길 권장합니다. 예를 들어, TKE 로그는 TKE_tkeid_log/timestamp로 이름을 생성합니다.
3. 전송 규칙 설정이 끝나면 별도로 SCF 제품 아래 파일 업로드 이벤트 공지를 설정할 수 있습니다. 로그 데이터가 COS로 전송되면 이벤트 공지에 따라 다음 단계 작업을 수행할 수 있습니다. 자세한 내용은 이벤트 알림을 참고하십시오.
로그 분석
로그를 로컬로 다운로드해 오프라인 분석하기
로그 데이터를 로컬로 다운로드해야 할 경우, 콘솔/SDK/API 또는 툴 등 다양한 방식으로 다운로드할 수 있습니다. 다음은 다운로드 방식에 대한 사용 문서 설명으로, 다음 문서를 참고해 코드에서 파일 경로와 관련된 부분을 로그 저장 경로로 바꾸면 로그 데이터를 로컬로 다운로드할 수 있습니다.
COS Select 기능을 통해 COS에 저장된 로그 파일을 직접 인덱스 및 분석할 수 있습니다. 전제 조건은 로그 파일을 CSV 또는 JSON 포맷으로 저장하는 것입니다. COS Select 기능을 통해 필요한 로그 필드를 선택할 수 있으며, 이로써 COS에서 전송하는 로그 데이터양을 크게 줄여 사용 비용을 줄임과 동시에 데이터 획득 효율을 높이게 됩니다. COS Select 기능에 대한 자세한 내용은 Select 개요를 참고하십시오.
로그 검색은 실시간 로그 기능이라고도 합니다. 클라우드 오브젝트 스토리지(Cloud Object Storage, COS)는 로그 검색 능력을 지원하고 버킷과 관련된 다양한 요청 로그를 기록하고 로그 데이터에 대한 실시간 검색과 분석을 구현할 수 있습니다. COS 콘솔에서 버킷에 대한 이 기능을 활성화하여 이상 사건 역추적 및 트러블 슈팅 등 작업을 완성하는 것을 도울 수 있습니다.
실시간 로그 조회 기능을 사용하면 클라우드 로그 서비스(CLS)로부터 청구되는 요금이 발생하며, 자세한 과금 기준은 CLS 과금 개요를 참고하십시오.
현재 COS의 로그 검색 기능이 지원되는 레진은 베이징, 광저우, 상하이, 청두, 난징, 충칭, 중국 홍콩, 실리콘 밸리, 싱가포르, 봄베이, 프랑크푸르트, 토론토, 선전 금융, 상하이 금융을 포함합니다. 후속적으로 더 많은 레진을 지원할 예정이니 제품 동향에 주목해 주시길 바랍니다.
COS는 로그 데이터의 100% 정확성을 보장하지 않으며, 참고용으로만 사용될 뿐 계량 및 과금 근거로 사용되지 않습니다.
3. 로그 검색 활성화가 필요한 버킷을 찾고, 해당 버킷 명칭을 클릭하여 해당 버킷 관리 페이지로 이동합니다.
4. 왼쪽 네비게이션바에서 로그 관리 > 로그 검색을 선택합니다.
5. 로그 검색 페이지에서 현재 버킷에 대한 실시간 로그 기능이 활성화되지 않았으면 즉시 활성화를 클릭하여 사용하십시오.
설명:
활성화 성공 후 해당 버킷의 접근 로그는 CLS의 동일한 레진의 로그 주제에 전달되며, 로그 주제 명칭은 cos-log-store입니다. 최초 활성화는 권한 부여가 필요합니다.
필드 통계분석 활성화
로그 검색은 쿼리문을 기입할 필요가 없이 필드에 따른 빠른 통계분석을 지원합니다. 기본적으로 지원되는 필드는 로그 필드 설명을 참고하시고 더 많은 정보는 빠른 분석을 참조하십시오.
주의:
로그에 대해 특정 필드에 따른 통계분석을 수행하려면 해당 필드에 대한 통계를 활성화해야 합니다. 다음 2가지 방식을 통해 빠르게 활성화할 수 있습니다.
방식 1: 원시 로그 페이지에서 활성화
1. 원시 로그 페이지로 이동합니다.
2. 활성화할 필드를 찾고 즉시 활성화를 클릭합니다.
방식 2: 인덱스 구성에서 활성화
1. 인덱스 구성을 클릭하여 인덱스 구성 페이지로 이동합니다.
2. 인덱스 구성 페이지에서 오른쪽 상단에 있는 편집을 클릭하고, 활성화할 필드를 찾은 다음 스위치를 켜고 오류가 없는지 확인한 후 확인을 클릭하여 저장합니다.
3. 활성화 성공 후 해당 필드의 통계분석 상황을 조회할 수 있습니다. 특정 숫자를 클릭하면 해당 검색 분석문 및 도표가 생성됩니다.
검색 분석문 입력
주의:
인덱스 구성은 클라우드 로그 서비스(Cloud Log Service, CLS)를 이용하여 검색 분석을 수행하기 위한 필수 조건이며, 로그에 대한 검색 분석을 수행하려면 반드시 검색을 활성화해야 합니다. 인덱스 구성은 비교적 복잡하므로 인덱스 구성 편집에 있는 추천 구성을 사용하면 대다수의 사용 수요를 충족시킬 수 있습니다. 더 많은 관련 정보는 인덱스 구성을 참고하십시오.
검색 분석문은 검색 조건 및 SQL문으로 구성되며, 검색 분석문을 입력하여 접근 로그에 대한 검색 및 통계분석을 수행합니다.
검색 조건: 로그 매칭에 필요한 조건을 지정하면 해당 조건에 부합되는 로그를 반환합니다. 예를 들어 status:404를 사용하여 응답 상태 코드가 404인 앱 요청 로그를 검색합니다. 검색 조건이 비어 있거나 *일 때 검색 조건이 없이 모든 로그를 나타냅니다. 더 많은 문법 규칙 및 예시 정보는 검색 조건 문법을 참고하십시오.
SQL문: 검색 조건에 부합되는 로그에 대한 통계분석을 수행하여 통계분석 결과를 반환합니다. 예를 들어 status:404 | select count(*) as logCounts를 사용하여 응답 상태 코드가 404인 로그 수량을 통계합니다. 더 많은 문법 사용 및 예시 정보는 SQL문 문법을 참고하십시오.
1. 로그 검색 페이지에서 분석문 검색 입력 모드를 선택하며, 인터랙션 모드와 스테이트먼트 모드의 두 가지 유형을 지원합니다.
인터랙션 모드: 마우스로 클릭하여 검색 조건 및 통계분석 규칙을 지정하면 검색 분석문이 자동으로 생성되므로 사용성이 높습니다.
스테이트먼트 모드: 문법 규칙에 부합되는 검색 분석문을 직접 입력하므로 유연성이 높습니다.
2. 문법 규칙을 전환하려면 풀다운을 클릭하여 문법 규칙을 선택하여 전환할 수 있습니다. CQL 및 Lucene를 지원하며, 더 많은 문법 규칙 및 예시 정보는 검색 조건 문법을 참고하십시오.
3. 검색 분석문을 입력한 다음 시간 범위를 선택하고, 검색 버튼을 클릭하면 해당 버킷에서 CLS로 보고된 접근 로그를 검색할 수 있습니다.
로그 검색 결과, 통계분석 결과 조회
검색 성공 후 로그 검색 페이지에서 접근 로그의 검색 결과, 통계분석 결과를 조회할 수 있습니다. 원시 로그 및 통계 도표에 각각 해당하며, 빠른 전환을 지원합니다. 자세한 설명은 다음과 같습니다.
원시 로그: 검색 분석문에 검색 조건만 포함되는 경우, 원시 로그에서 검색 조건과 매칭되는 로그를 조회할 수 있으며, 기본적으로 로그 시간에 따라 역순으로 나열됩니다.
통계 도표: 검색 분석문에 SQL문이 포함되는 경우, 통계 도표에서 분석 결과를 조회할 수 있고, 동시에 원시 로그에서 검색 조건에 부합되는 로그를 조회하여 분석 통계 결과와 원시 로그를 비교할 수 있습니다.
원시 로그
1.1 현재 검색 조건에서 지정된 시간 범위 내의 로그 통계 상황에 대한 조회를 지원하며, 주상도로 표시됩니다.
1.2 로그 데이터는 기본적으로 원시 형태로 표시되며, 사용자 정의 구성을 지원합니다.
1.3 로그 데이터에서는 ‘표시 필드’만 표시되며, 더 많거나 숨겨진 로그에 해당하는 필드 정보를 조회하려면 다음 3가지 방식을 통해 실현할 수 있습니다.
리스트 조작: 원시 로그에서, 왼쪽 패널에서 해당 필드를 빠르게 찾은 후 표시하기 또는 숨기기를 클릭하면 구성이 완성됩니다.
로그 상세정보: 특정 로그를 전개하여 상세정보를 조회하며, 조회 아이콘을 클릭하면 특정 필드를 빠르게 숨기거나 표시할 수 있습니다. 각 로그에 대해 JSON 포맷의 데이터를 조회할 수 있으며, 원클릭 복사가 지원됩니다. 또한 필드값을 클릭하여 사용자 정의 점프도 수행할 수 있습니다.
페이지 구성: 오른쪽에 있는 ‘페이지: 기본 구성’을 클릭하고 구성 관리를 선택합니다. 표시 필드를 일괄 설정할 수 있으며, 적용을 클릭하면 구성이 완성됩니다.
통계 도표
통계 도표는 기본적으로 테이블 유형으로 분석 결과를 표시하며, 오른쪽에 있는 ‘도표 구성’을 통해 도표 유형 및 관련 정보를 사용자 정의할 수 있습니다. 버킷 접근 로그에 대한 시각화 및 경고의 구성을 수행하려면 CLS 콘솔로 이동하십시오.
로그 다운로드 및 분석 결과 내보내기
로그 다운로드
1. 오른쪽에 있는 다운로드 버튼을 클릭하고 로그 다운로드를 선택합니다.
2. 팝업된 윈도우에서 아래와 같은 정보를 구성하고 오류가 없음을 확인한 후 내보내기를 클릭합니다.
3. 완성 후 하나의 내보내기 태스크가 생성되며, 이때 자동으로 내보내기 기록 페이지로 이동하여 현재 태스크 진행 상황을 조회할 수 있고, 태스크의 삭제 및 다운로드를 지원합니다. 대기 중에 현재 페이지에서 나갈 수 있으며, 오른쪽에 있는 다운로드 버튼에서 기록 내보내기를 클릭하면 해당 페이지로 다시 이동할 수 있습니다.
분석 결과 내보내기
오른쪽에 있는 분석 결과 내보내기를 클릭하면 분석 결과를 로컬로 다운로드할 수 있습니다.
로그 검색 끄기
특정 버킷에 대한 로그 검색 기능을 계속 사용하지 않으려면 로그 검색 끄기를 클릭할 수 있습니다.
주의:
끄기 전에 먼저 CLS 콘솔로 이동하여 빈 로그 주제가 있는지를 확인하십시오. 제때에 삭제하지 않으면 요금이 발생합니다.
4. 시간 범위를 선택하고, 검색을 클릭하여 통계분석 페이지로 이동하여 통계분석 결과를 조회할 수 있으며, 오른쪽에서 도표 유형을 전환할 수 있습니다.
사례 4: 특정 파일 접근 불가, 원인 파악
1. 인터랙션 모드를 선택하고 검색 조건 추가를 클릭합니다. 찾을 파일명을 지정하고, 시간 범위를 선택한 후 검색을 클릭하여 로그를 조회합니다.
2. 왼쪽에 있는 필드 명칭을 클릭하여 빠른 분석을 열고, resHttpCode 필드에 따라 통계분석을 수행합니다. 이상 상태 코드의 로그 정보, 예를 들어 403 상태 코드, 204 상태 코드 등을 조회합니다.
3. 이상 상태 코드에 대하여 상태 코드를 클릭하고,** 이번 검색에 추가\*\*를 선택하여 로그를 선별합니다. 로그 상세정보에서 기타 필드의 상황을 조회할 수 있으며, reqMethod 필드 등에 중점을 둘 것을 권장합니다. 예시에서는 해당 파일에 대한 삭제 조작이 실행되어 오브젝트 접근이 실패함을 나타냅니다.
로그 분석 설정
최종 업데이트 날짜:：2025-06-25 17:02:23
소개
COS(Cloud Object Storage) 로그 스토리지 기능을 활성화한 후 로그 분석 기능을 활성화하여 생성된 로그 파일에 대한 추가 데이터 분석을 수행할 수 있습니다. 로그 분석 기능은 데이터 분석을 위해 지정된 시간 범위 내에서 로그 파일을 통합하고 볼 수 있는 주요 지표를 추출합니다.
전제 조건
로그 저장 기능이 활성화되어 있습니다. 활성화되지 않은 경우, 로그 저장 설정 을 참조하여 활성화하십시오.
주의:
COS 로그 분석 기능이 지원되는 리전은 로그 저장 기능 설정에 따라 달라지므로, 로그 분석 기능을 사용하기 전에 먼저 로그 저장 기능을 활성화해 주십시오.
3. 로그 분석을 설정할 버킷을 찾아 해당 버킷 이름을 클릭하여 버킷 관리 페이지로 이동합니다.
4. 왼쪽 사이드바에서 로그 관리를 선택하고 로그 스토리지를 클릭합니다. 로그 저장 서비스가 활성화되어 있는지 확인하세요.
주의：
로그 분석 기능을 사용하여 먼저 로그 스토리지 서비스를 활성화해야 하며, 로그 관리 설정을 참고하여 로그 저장 서비스를 활성화하십시오.
5. 로그 저장 서비스가 활성화된 상태에서, 로그 분석 활성화 페이지가 표시됩니다. 지금 사용을 클릭하면, 시스템이 COS 로그 분석 함수가 추가되었는지를 확인하고, COS 로그 분석 함수를 생성하도록 안내하는 팝업창이 뜹니다. 관련 설정 설명은 COS 로그 분석 함수 추가를 참조하십시오.
6. COS 로그 분석 함수를 추가한 후, 이 페이지에서 해당 함수 이름을 선택하고, 분석하고자 하는 로그 기간을 선택하고, 분석 작업 생성을 클릭하고 팝업 창에서 다음 정보를 설정합니다.
소스 버킷: 기본값은 현재 버킷입니다.
시간 범위: 분석할 로그 시간대는 요청 종료 시간으로 검색되며 최대 30일까지 지원됩니다. 지정된 기간 내 로그 파일의 총 크기는 200GB를 초과할 수 없습니다.
SCF 선택: 현재 버킷이 위치한 리전에 추가된 COS 로그 분석 함수를 선택합니다.
제품 배송 디렉터리: 로그 분석 후, 시스템은 분석 결과 제품을 포장하여 지정한 배송 디렉터리에 저장합니다. 제품에는 결과 파일 및 매니페스트 파일이 포함되어 있습니다. 결과 파일은 선택한 분석 시나리오에 따라 분석한 결과입니다. 매니페스트 파일은 이 분석에서 인덱스된 로그 파일의 리스트를 나타냅니다.
7. 다음을 클릭하여 상세 설정 페이지로 이동하며, 설정 설명은 다음과 같습니다.
작업 유형: 통계 분석 및 작업 로그 검색을 지원합니다.
통계 분석: 객체 다운로드 시나리오에 따른 통계 분석을 지원합니다.
작업 로그 검색: 기능 작업 관련 로그를 기준으로 검색을 지원합니다.
통계 분석
시나리오 분류: 현재는 객체 다운로드 시나리오만 지원합니다.
시나리오 선택: 현재 지원하는 로그 분석 시나리오입니다. 예를 들어, 다운로드 트래픽 상위 N개 IP 또는 파일, 다운로드 횟수 상위 N개 IP 또는 파일, HTTP referer, UserAgent.
N 값: 시나리오에서 해당하는 N 값으로, 양의 정수를 입력해야 합니다.
작업 설명: 이 분석에 대한 설명을 사용자 정의할 수 있습니다.
작업 로그 검색
시나리오 분류: 버킷, 객체 관련 시나리오를 지원합니다.
시나리오 선택:
버킷 관련: 정적 웹사이트, Origin-pull 설정, 수명주기, 태그 관리, 인벤토리 설정, 리전 간 설정, 링크 도용 방지, 서버 측 암호화, 버킷 ACL, Policy 권한 설정, 글로벌 가속 도메인 설정, 버전 관리, 버킷 복제, 로그 저장 등 관련 항목이 포함됩니다.
작업 필터링: 읽기 및 쓰기 작업 필터링을 지원합니다.
객체 관련: 파일 업로드(단일 파일 업로드, 멀티파트 업로드, 파일 복사), 파일 다운로드, 단일 파일 삭제, 일괄 파일 삭제 시나리오를 지원합니다.
필터링 조건: 특정 객체 키(일괄 파일 삭제 제외), UserAgent, 출처 IP를 기준으로 필터링을 지원합니다.
필터링 모드: 퍼지 매칭과 정확 매칭을 지원합니다.
작업 설명: 이 분석에 대한 설명을 사용자 정의할 수 있습니다.
8. 설정이 정확한 경우, 확인을 클릭하면 분석 작업이 추가 완료됩니다. 설정에 잘못된 경우, 안내에 따라 수정을 완료하십시오.
생성된 분석 작업에 대해 다음 작업을 수행할 수 있습니다.
결과 조회를 클릭하면 이 로그 분석의 결과와 결과 파일이 저장된 주소를 볼 수 있습니다.
주의：
최근 3일 동안 생성된 로그 분석 작업을 쿼리할 수 있습니다.
로그 분석 작업이 실행 완료될 때까지 기다려야 결과를 조회할 수 있으며, 로그 분석은 로그 크기에 따라 보통 몇 분에서 수십 분이 소요됩니다.
실행 로그를 클릭하면 SCF 콘솔로 리디렉션하여 COS 로그 분석의 실행 로그를 조회할 수 있습니다.
일괄 프로세스
일괄 작업 개요
최종 업데이트 날짜:：2024-06-24 17:08:32
Cloud Object Storage(COS)의 일괄 작업 기능을 사용하면 버킷 내에서 지정된 객체 목록에 대한 작업을 지정할 수 있습니다. 이를 위해 두 가지 옵션이 있습니다. 인벤토리 기능을 사용하여 객체 인벤토리를 생성하거나 인벤토리와 같은 형식으로 원하는 객체를 CSV 파일에 나열합니다. 이렇게 하면 COS에서 지정된 대로 객체가 일괄적으로 작업됩니다.
일괄 작업 기능은 COS 콘솔에서 사용할 수 있습니다. 자세한 내용은 일괄 작업을 참고하십시오.
원리
일괄 작업을 수행하려면 먼저 객체 목록에 대해 지정된 작업을 수행하기 위해 필요한 모든 정보를 포함하는 일괄 작업을 생성해야 합니다. 객체 목록으로 인벤토리를 사용할 수 있습니다.
인벤토리 파일을 제공하고 생성한 일괄 작업을 시작한 후, 일괄 작업 기능은 인벤토리의 객체에 지정된 작업을 순차적으로 수행합니다. 작업 실행 중에는 COS 콘솔에서 실행 상태를 모니터링하거나 작업이 완료된 후 작업 보고서를 출력할 수 있습니다. 작업 보고서는 작업 내 각 작업에 대한 자세한 정보를 제공합니다.
주의：
일괄 작업 기능은 현재 버킷의 객체에만 적용됩니다. 다른 버킷의 객체에 대해 일괄 작업을 수행하려면 해당 버킷에 대해 일괄 작업 기능을 활성화해야 합니다.
객체 인벤토리
객체 인벤토리는 작업 대상인 모든 객체의 목록입니다. 일괄 작업을 생성하려면 먼저 COS에게 작업을 수행해야 할 객체를 알려주기 위해 객체 인벤토리를 제공해야 합니다. 객체 인벤토리 파일을 버킷에 넣고 파일 이름, ETag 및 VersionID(해당되는 경우)와 같은 정보를 제공해야 합니다. 객체 인벤토리는 다음 두 가지 방법으로 생성할 수 있습니다:
COS 인벤토리 기능: 이 기능은 객체 인벤토리를 CSV 형식으로 출력합니다. 자세한 정보는 인벤토리 개요를 참고하십시오. 객체 인벤토리에 버전 ID 정보가 포함된 경우, COS는 해당 버전 ID를 가진 객체들에 대해 일괄 작업을 수행합니다.
CSV 파일 구성: CSV 파일의 모든 행에는 일괄 작업을 위한 버킷 이름과 객체의 이름 및 버전 ID(버킷에 대해 버전 관리가 활성화된 경우)가 포함되어야 합니다. 버전 관리가 활성화된 적이 없는 경우 버전 ID 정보를 건너뛸 수 있습니다. CSV 파일은 다음과 같이 구성할 수 있습니다.
만약 버전 관리가 버킷에 활성화되었거나 활성화되었던 적이 있으며, 지정된 버전의 객체에 대해 일괄 작업을 수행하려면, 객체 인벤토리에서 객체 버전 ID 정보를 제공해야 합니다.
만약 버전 관리가 버킷에 활성화되었거나 활성화되었던 적이 있지만 인벤토리에서 버전 ID를 지정하지 않은 경우, COS는 기본적으로 객체의 최신 버전에서 작업을 수행합니다.
작업을 생성하기 전에 객체 이름이 같은 객체를 업로드했다면, COS는 객체 인벤토리가 생성될 때의 버전이 아닌 최신 버전의 객체에서 기본적으로 작업을 수행합니다. 이 문제를 피하기 위해서는 버전 관리를 활성화하고 객체 인벤토리에서 버전 ID를 지정할 수 있습니다.
객체 인벤토리는 버킷의 모든 객체를 포함할 수 있습니다. 그러나 많은 수의 객체에 대해 작업을 수행하는 데에는 시간이 더 오래 걸릴 수 있다는 점을 유의해야 합니다.
일괄 작업
이 섹션에서는 일괄 작업을 생성하는 방법과 생성 후 시스템이 어떻게 응답하는지 설명합니다.
일괄 작업 생성 시에는 다음 정보를 제공해야 합니다.
유형
설명
작업
객체에 대해 수행할 작업을 지정해야 합니다. 각 작업에 대해 해당 매개변수를 구성할 수 있으며, COS는 인벤토리의 객체에 대해 구성된대로 순차적으로 작업을 수행합니다.
객체 인벤토리
객체 인벤토리는 수행할 모든 객체의 목록입니다. 인벤토리 기능을 사용하여 객체 인벤토리를 생성할 수 있습니다. 자세한 내용은 인벤토리 개요를 참고하십시오. 인벤토리와 동일한 형식으로 CSV 파일에서 필요한 객체를 나열할 수도 있습니다.
우선순위
우선순위를 설정하여 현재 일괄 작업의 우선 순위를 다른 작업보다 높게 설정할 수 있습니다. 작업 우선 순위는 직접 작업이 완료되는 순서를 결정하지는 않습니다. 여러 작업의 순서를 제어하려면 직접 작업 실행 상태를 확인하고 현재 작업이 완료된 후 다음 작업을 시작해야 합니다.
규칙 권한
일괄 작업을 생성한 후 작업을 수행할 적절한 IAM 권한이 계정에 있는지 확인해야 합니다. 예를 들어 PUT Object-copy를 실행하는 일괄 작업을 생성한 경우 소스 버킷에서 Get Object 권한과 대상 버킷에서 PUT Object 권한을 확인해야 합니다. 또한 모든 일괄 작업에 대해 객체 인벤토리를 읽고 작업 보고서에 쓰는 권한이 있어야 합니다. 권한 구성에 대한 자세한 내용은 권한 설정 및 버킷 액세스 정책을 참고하십시오.
작업 보고서
일괄 작업이 완료된 후 작업 보고서를 출력하려면 작업 생성 시 해당 매개변수를 입력하여 시스템이 작업 보고서를 지정된 대상 버킷에 올바르게 출력할 수 있도록 설정해야 합니다. 필요한 정보는 작업 보고서를 저장할 버킷, 작업 보고서 형식 및 모든 작업 정보 포함 여부입니다. 작업 보고서의 파일 접두사는 선택 사항입니다.
작업 설명(옵션)
생성된 일괄 작업에 대해 256바이트 작업 설명을 입력하여 추적할 수 있습니다. 작업 설명은 COS 콘솔에서 표시되며 작업을 정렬하거나 필터링하는 데 사용할 수 있습니다. 유사한 작업(예: 매주 로그 데이터를 동기화하고 복사하는 것)에 동일한 작업 설명을 입력하여 중앙 집중식으로 관리할 수 있습니다.
일괄 프로세스 작업
일괄 작업
최종 업데이트 날짜:：2025-05-23 18:37:24
소개
COS(Cloud Object Storage)의 일괄 처리 기능은 버킷 내 객체에 대해 대규모 일괄 작업을 수행할 수 있습니다. 또한 CI(Cloud Infinite) 오디오 및 비디오 트랜스코딩, 음성 인식 등의 기능을 사용하여 버킷 내 특정 파일을 일괄 처리할 수도 있습니다. 현재 다음 작업에 대해 일괄 처리를 수행할 수 있습니다.
객체 복사
아카이브 객체 복구
오디오 및 비디오 트랜스코딩, 비디오 매팅, 음성 합성 등 데이터 처리
처리할 객체를 객체 인벤토리 파일에 정리합니다. 해당 인벤토리 파일은 인벤토리 기능으로 생성된 인벤토리 보고서(먼저 인벤토리 기능 활성화 필요)이거나 사용자가 지정한 포맷에 따라 직접 생성할 수도 있습니다. COS 일괄 처리 기능은 해당 객체 인벤토리 파일에 따라 일괄 처리를 진행합니다. COS의 일괄 처리 작업 사용에 대한 자세한 정보는 일괄 작업 개요를 참고하십시오.
일괄 처리 유형: COS Batch를 선택하면 복사, 아카이빙 등 기본 작업을 수행할 수 있으며, 독립 작업 및 워크플로우를 선택하면 CI의 관련 서비스를 사용할 수 있습니다.
작업 유형: COS Batch를 선택한 경우, 일괄 데이터 복사, 아카이브 유형 객체 일괄 복원, 일괄 삭제 중 선택할 수 있습니다.
인벤토리 리포트:
(1) 인벤토리 리포트가 없는 경우: '없음'을 선택하고, 시스템이 선택한 인벤토리 버킷에서 즉시 인벤토리를 생성합니다. 파일 범위, 객체 버전, 필터링 태그 및 필터링 시간 등 인벤토리 정보를 필요에 따라 설정할 수 있습니다. 추가 설정 항목 설명은 인벤토리 설정을 참조하십시오.
(2) 인벤토리 리포트 또는 CSV가 있는 경우: '있음'을 선택하고, 인벤토리가 저장된 버킷을 선택하세요.
소스 버킷: 인벤토리 파일이 저장된 버킷을 선택합니다.
설명：
현재 COS 일괄 작업 기능은 중국 본토, 실리콘 밸리, 상파울루, 싱가포르의 리전의 퍼블릭 클라우드 리전에서만 사용할 수 있습니다.
인벤토리 포맷: 인벤토리 객체에 사용할 유형을 선택하며, 다음과 같은 두 가지 포맷이 있습니다.
인벤토리 포맷
필드
구성
COS 인벤토리 보고서
-
COS 생성 인벤토리 보고서 또는 사용자 정의 CSV 파일 선택
CSV
Bucket
버킷 이름
Key
버킷에 있는 객체의 이름입니다. 객체 이름이 URL로 인코딩된 형식인 경우 사용하려면 먼저 일반 형식으로 디코딩해야 합니다.
VersionId
객체 버전 ID입니다. 버킷에 버전 제어를 활성화하면 COS는 버킷의 객체에 지정 버전을 추가합니다. 최신 버전이 아닌 객체 버전을 사용하고 싶은 경우 인벤토리에 포함된 객체의 버전 ID를 선택할 수 있습니다.
인벤토리 파일 경로: 인벤토리 파일 또는 CSV 파일의 경로를 각각 json 또는 csv 형식으로 지정합니다. 예를 들어 인벤토리 파일을 버킷 examplebucket-1250000000의 루트 디렉터리에 저장한 경우 인벤토리 경로는 manifest.json이 됩니다.
인벤토리 ETag: 인벤토리 파일 경로를 선택한 후 시스템이 자동으로 생성합니다. ETag(엔티티 태그)는 객체의 해시로, 객체 내용의 변경만 반영되며 메타데이터의 변경은 반영되지 않습니다. ETag는 반드시 객체 데이터의 MD5 요약이 되는 것은 아니며, 객체의 생성 방식과 암호화 방식에 따라 다릅니다.
4. 다음을 클릭하여 설정 항목 설명에 따라 설정합니다.
이전 단계에서 일괄 데이터 복사를 선택한 경우, 설정 항목 설명은 다음과 같습니다.
타깃 버킷: 인벤토리 리스트에 있는 객체를 복사하여 붙여넣을 버킷입니다.
접두사 작업: 복사한 객체에 접두사를 추가, 변경 및 삭제할 수 있습니다.
스토리지 유형: 복사한 객체에 스토리지 유형을 설정합니다. 스탠다드 스토리지, 스탠다드IA 스토리지, 아카이브 스토리지, 딥 아카이브 스토리지를 선택할 수 있습니다.
서버 암호화: 복사한 객체를 암호화할지 여부를 선택합니다. 암호화하지 않음, SSE-COS 암호화를 선택할 수 있습니다.
액세스 권한: 복사한 객체에 액세스 권한을 설정합니다. 모든 권한 복사, 모든 권한 변경, 신규 권한 추가를 선택할 수 있습니다.
객체 메타데이터: 복사한 객체에 메타데이터를 설정합니다. 모든 메타데이터 복사, 모든 메타데이터 변경, 신규 메타데이터 추가를 선택할 수 있습니다.
객체 태그: 복사한 객체에 객체 태그를 설정합니다. 모든 태그 복사, 모든 태그 변경, 신규 태그 추가를 선택할 수 있습니다.
이전 단계에서 아카이브 유형 객체 일괄 복원을 선택한 경우, 설정 항목 설명은 다음과 같습니다.
복구 모드: 표준 모드와 일괄 모드를 선택할 수 있으며, 복구 모드에 대한 자세한 내용은 아카이브된 객체 복구를 참고하십시오.
사본 유효 기간: 사본이 몇 일 후 자동 만료되어 삭제할지 설정하며, 설정 범위는 최소 1일 최대 365일입니다.
이전 단계에서 일괄 삭제를 선택한 경우, 절차 5로 진행합니다.
5. 다음을 클릭하고 다음 옵션을 구성합니다.
작업 우선순위: 우선순위가 높은 작업을 우선적으로 실행하며, 0을 제외한 자연수를 입력합니다. 숫자가 클수록 우선순위가 높아집니다.
작업 보고서: 작업 보고서 생성 여부를 선택합니다.
CAM 역할: CAM 역할을 생성하거나 기존의 CAM 역할을 선택하여 COS에 작업 권한을 부여합니다.
주의：
일괄 처리 작업은 CAM 역할 생성 방식을 통해 COS에 일괄 처리 권한을 부여해야 하며, CAM 역할에 대한 자세한 사항은 CAM Role Overview를 참고하십시오.
6. 다음을 클릭하고 설정한 일괄 처리 작업 구성을 확인하고 선택합니다. 이 옵션을 선택하면 생성 후 작업이 바로 시작됩니다. 상기 구성 정보가 올바른지 확인하십시오.
필요에 따라 정보를 수정하려면 수정 또는 이전을 클릭합니다.
7. 모든 것이 올바른지 확인한 후 생성/생성 및 실행을 클릭합니다.
그런 다음 작업 리스트에서 방금 생성한 작업을 찾습니다. 작업을 취소하려면 오른쪽에서 작업 취소를 클릭합니다.
객체 일괄 복사
최종 업데이트 날짜:：2024-06-24 17:08:32
객체 일괄 복사 작업은 리스트 상의 객체를 복사하는데 사용됩니다. 지정 객체를 원본 버킷에서 타깃 버킷으로 일괄 복사할 수 있습니다. 타깃 버킷과 원본 버킷의 리전의 동일 여부에 관계 없이 실행 가능합니다. 객체 일괄 복사 작업은 PUT Object-copy의 관련 매개변수를 사용자 지정 설정할 수 있으며, 해당 설정 정보는 복사본의 메타데이터 정보 또는 스토리지 유형 등의 정보에 영향을 미칩니다. PUT Object-copy 관련 자세한 내용은 PUT Object-copy를 참조하십시오.
관련 제한
모든 처리 대기 상태인 객체가 동일한 버킷에 있어야 합니다.
일괄 프로세스 작업별로 타깃 버킷은 한 개만 설정할 수 있습니다.
원본 버킷에 객체 읽기 권한과 타깃 버킷 객체 쓰기 권한을 부여해야 합니다.
처리 대기 중인 객체는 5GB를 초과할 수 없습니다.
ETags 조회 및 사용자 지정 키를 사용한 서버 암호화를 지원하지 않습니다.
타깃 버킷에 버전 제어가 활성화되어 있지 않고 동일한 이름의 객체 파일이 존재하는 경우, COS는 객체 파일을 덮어씁니다.
리스트 상의 객체에 여러 버전이 존재하는 경우 하나의 버전만 복사하며, 버전을 지정하지 않은 경우 기본적으로 최신 버전만 복사합니다.
아카이브된 객체 일괄 복구
최종 업데이트 날짜:：2024-06-24 17:08:32
보관된 객체를 일괄 복구하면 인벤토리에 보관된 객체를 복구하는 데 사용할 수 있습니다. 이 작업은 POST Object restore에 대한 구성 매개변수를 지원합니다. 구성 정보는 복사본의 복구 시간과 만료 시간에 영향을 미칩니다. 자세한 내용은 POST Object restore를 참고하십시오.
복구는 ARCHIVE 및 DEEP ARCHIVE 스토리지 클래스에 대해 지원됩니다. 이 두 가지 스토리지 클래스에 대한 자세한 내용은 스토리지 유형 개요를 참고하십시오.
보관된 객체 일괄 복구 작업을 생성할 경우 다음 두 가지 매개변수를 지정해야 합니다.
복구 모드: 표준 검색 또는 대량 검색. 자세한 내용은 아카이브된 객체 복구를 참고하십시오.
복사본 유효기간: 아카이브 유형의 객체는 복구 후 임시 복사본이 생성되며, 해당 복사본은 지정된 시간 후 자동으로 만료되어 삭제됩니다. 복사본 유효기간에 대한 자세한 내용은 아카이브된 객체 복구를 참고하십시오.
주의 사항
1. 일괄 복구 작업에 이미 복구된 객체의 복사본이 포함된 경우 작업이 시작될 때 이러한 복사본의 유효 기간이 업데이트되어 작업의 모든 복사본이 동일한 유효 기간을 갖도록 합니다.
2. 일괄 복구 작업은 객체 복구 요청만 시작합니다. 모든 요청이 전송된 후 일괄 작업 페이지에 작업이 완료된 것으로 표시됩니다. COS(Cloud Object Storage)는 객체가 복구되었을 때 사용자에게 알리지 않지만 알림을 수신하도록 이벤트 알림을 구성할 수 있습니다. 자세한 내용은 이벤트 알림을 참고하십시오.
객체 일괄 삭제
최종 업데이트 날짜:：2025-12-10 17:16:15
일괄 삭제 작업은 인벤토리에 있는 객체를 삭제하는 데 사용할 수 있으며, 삭제 작업에 대한 설명은 DELETE Object를 참고하십시오. 버킷의 버전 관리 상태는 일괄 삭제 실행 결과에 영향을 미칩니다. 자세한 내용은 버전 관리 개요를 참고하십시오.
주의 사항
1. 인벤토리에 객체의 versionid가 포함되어 있는지 여부에 따라, 일괄 삭제 작업을 실행할 때 발생하는 삭제 요청이 versionid를 포함하는지 여부가 결정됩니다.
인벤토리가 현재 버전만 유지하는 경우, versionid 없이 삭제 작업을 실행합니다. 즉 DELETE /example.txt
인벤토리가 이전 버전을 나열하는 경우, versionid를 포함한 삭제 작업이 실행됩니다. 즉 DELETE /example.txt?versionid=xxx
2. 버킷이 버전 관리 미사용, 일시 중지, 사용 중인 세 가지 상태일 때, versionid 없는 삭제 작업은 서로 다른 결과를 가져올 수 있습니다. versionid를 포함한 삭제 작업은 객체의 실제 삭제를 보장합니다. 자세한 내용은 버전 관리 개요를 참고하십시오. 다양한 상황에 따라 객체 일괄 삭제의 실행 결과는 다음과 같습니다.
작업
인벤토리 1(현재 버전만 유지)
인벤토리 2(이전 버전 나열)
삭제 작업
versionid 미포함
versionid 포함
버전 관리 미사용
실제 삭제
실제 삭제
버전 관리 사용 중
삭제 마커를 추가하고 실제로 삭제되지 않음
versionid에 따라 실제 삭제
버전 관리 일시 중지
삭제 마커를 추가하고, 버킷에 null 버전 객체가 있는 경우 해당 객체는 실제로 삭제되며, null 버전이 아닌 객체는 삭제되지 않음
versionid에 따라 실제 삭제
일괄 프로세스 작업 관리
최종 업데이트 날짜:：2025-11-24 17:46:11
콘솔을 통해 일괄 프로세스 작업을 관리할 수 있으며, 본 문서에서는 일괄 프로세스 작업과 관련한 관리 작업에 대해 자세히 소개합니다.
필터링 작업
List Jobs API를 통해 최근 90일 이내에 생성한 일괄 프로세스 작업을 확인할 수 있습니다. 일괄 프로세스 작업 리스트에는 작업 ID, 작업 설명, 작업 우선순위, 작업 상태, 작업 실행 상황 등 모든 일괄 프로세스 작업 정보가 포함되어 있으며, 작업 상태를 통해 일괄 프로세스 작업 리스트에서 동일한 상태의 작업을 필터링할 수 있습니다. 또한 콘솔에서 필터링 작업 시에는 작업 설명 또는 작업 ID를 통해 필터링할 수도 있습니다.
작업 상태 조회
작업 관련 더 많은 정보는 DescribeJob API를 통해 단일 업무에 대한 모든 정보를 확인할 수 있습니다. 해당 인터페이스는 지정한 작업의 조작 설정, 객체 리스트 정보, 작업 보고서 등의 정보를 반환하며, 이를 통해 지정한 작업에 대한 자세한 정보를 확인할 수 있습니다.
작업 할당 우선순위
작업에 우선순위를 설정할 수 있습니다. COS는 설정한 우선순위에 따라 일괄 프로세스 작업을 진행합니다. 우선순위가 높은 작업은 우선 처리되며, 우선순위는 정수값으로 수치를 표시하고 내림차순으로 정렬되어 있습니다. 즉, 숫자가 클수록 우선순위가 높다는 뜻입니다. 작업 실행 중 우선순위를 수정할 수 있으며, 작업 실행 중에 우선순위가 더 높은 작업을 추가하는 경우, 우선순위가 낮은 작업을 일시 정지하고 우선순위가 높은 작업을 먼저 실행합니다.
주의：
통상적으로 우선순위가 높은 일괄 프로세스 작업을 우선순위가 낮은 작업보다 먼지 실행하지만, 우선순위가 순차 작업의 표준이 되지는 없습니다. 여러 항목의 일괄 프로세스 작업을 순차적으로 실행해야 하는 경우 각 작업의 실행 상태를 모니터링하여 작업 상태를 확인하시기 바랍니다.
작업 상태
작업을 생성하면 아래 표의 작업 상태로 전환됩니다. 상태 전환 프로세스는 다음 이미지와 같습니다.
작업 상태에 대한 자세한 의미는 다음 표와 같습니다.
작업 상태
설명
다음 상태
New
작업이 막 생성된 경우 New로 표시됩니다.
Preparing으로 전환될 수 있으며, COS에서 작업 상의 리스트의 리졸브 작업을 시작했다는 의미입니다.
Preparing
COS에서 일괄 프로세스 작업에 설정된 리스트와 기타 정보에 대해 리졸브를 시작하면 Preparing 상태가 됩니다.
Ready 상태 또는 Suspended 상태로 전환될 수 있습니다. Ready 상태로 전환되면 일괄 프로세스 작업 설정 정보를 COS에서 리졸브를 완료했다는 의미입니다. 즉, COS가 설정에 따라 리스트의 객체에 대해 지정 작업을 실행할 예정이라는 의미입니다. Suspended 상태로 전환되면 일괄 프로세스 작업 설정 정보를 COS에서 리졸브를 완료했으나, 귀하가 확인을 해야만 실행할 수 있다는 의미입니다. 이 상태는 콘솔에서 일괄 프로세스 작업을 설정하는 경우 나타납니다.
Suspended
일괄 프로세스 작업이 귀하가 확인을 해야만 실행할 수 있을 경우 Suspended 상태가 됩니다. 이 상태는 콘솔에서 작업 생성 시 발생합니다. 귀하가 확인하고 COS에서 작업을 실행하면 다음 상태로 전환됩니다.
귀하가 작업 실행을 확인하면 Ready 상태로 전환됩니다.
Ready
COS에서 일괄 프로세스 작업의 객체 리스트와 작업 설정 정보에 대해 리졸브를 완료하고 곧 일괄 프로세스 작업을 실행할 때 Ready 상태가 됩니다.
Active 상태로 전환될 수 있으며, 이 때 COS에서 작업을 시작합니다. 우선순위가 더 높은 작업이 현재 실행 중인 경우 COS는 높은 우선순위 작업 상태가 Complete이 될 때까지 작업 상태를 Ready로 유지합니다.
Active
COS 일괄 프로세스 작업에 설정한 정보에 따라 리스트 상의 객체를 작업 중인 경우 Active 상태가 됩니다. 콘솔 또는 DescribeJob API 호출 등의 방법을 통해 진행 상태를 확인할 수 있습니다.
Complete, Failing, Pausing 또는 Cancelling 등의 상태로 전환될 수 있습니다. 작업이 성공적으로 종료되거나 실패할 경우, 또는 귀하의 중지 명령(예: 작업 취소) 등 구체적인 원인에 따라 상태가 전환됩니다.
Pausing
COS에서 현재 처리하고 있는 일괄 프로세스 작업을 중단하고 있는 상태로, Paused로 진행되는 상태가 Pausing 상태입니다.
Paused 상태로 전환됩니다. COS에서 실행 중인 일괄 프로세스 작업을 모두 중지한 경우 Paused 상태로 전환됩니다.
Paused
더 높은 우선순위의 일괄 프로세스 작업을 생성할 경우, 현재 실행 중인 일괄 프로세스 작업이 Paused 상태로 전환됩니다.
우선순위가 높은 작업이 완료, 실패 또는 확인 대기 상태가 되면 Paused 상태인 작업이 자동으로 Active 상태로 전환됩니다.
Complete
일괄 프로세스 작업의 모든 리스트 내 객체의 일괄 작업을 완료하였거나 실패하는 경우 Complete 상태로 전환됩니다.
작업 보고서 생성을 설정한 경우 COS에서 작업 상태를 Complete으로 전환 시 지정한 버킷에 작업 보고서를 전달합니다.
Complete 상태는 마지막 상태로, Complete 상태로 전환되면 다시 다른 상태로 전환되지 않습니다.
Cancelling
COS가 현재 처리하고 있는 일괄 프로세스 작업을 취소하는 중으로, Cancelled로 진행되는 상태가 Cancelling 상태입니다.
Cancelled 상태로 전환됩니다. COS에서 실행 중인 일괄 프로세스 작업을 모두 취소한 경우 Cancelled 상태로 전환됩니다.
Cancelled
일괄 프로세스 작업의 취소 처리가 완료되면 Cancelled 상태로 전환됩니다. 이 때에는 작업 상태를 수정할 수 없습니다.
Cancelled 상태는 마지막 상태로, Cancelled 상태로 전환되면 다시 다른 상태로 전환되지 않습니다.
Failing
COS에서 Failed로 진행되는 상태가 Failing 상태입니다.
Failed 상태로 전환됩니다.
Failed
작업 실패 시 Failed 상태가 됩니다. 작업 실패에 대한 자세한 정보는 실패 작업 추적을 참조하십시오.
Failed 상태는 마지막 상태로, Failed 상태로 전환되면 다시 다른 상태로 전환되지 않습니다.
실패 작업 추적
일괄 프로세스 작업 중 객체 리스트를 리졸브할 수 없는 등의 문제가 발생할 경우 일괄 프로세스 작업이 실패되고, COS에서 해당 에러 코드 및 오류 원인을 반환합니다. COS는 작업 실패 원인을 저장하며, DescribeJob API를 통해 작업 실패에 대한 자세한 정보를 확인할 수 있습니다. 또한 작업 보고서를 통해서도 관련 작업의 실패 사유 및 기타 관련 정보를 확인할 수 있습니다.
COS는 모든 일괄 프로세스 작업에 대해 작업 실패 임계값을 제공하여 생성한 작업에 대량의 실패 작업이 발생하지 않도록 방지합니다. 작업에 1000개 이상의 작업이 존재하는 경우 COS는 작업 실패율을 모니터링합니다. 언제든 작업 실패율(현재 진행 중인 작업 중 실패 작업에서 이미 진행된 모든 작업 수를 뺀 수)이 임계값인 50%를 초과하는 경우, COS는 작업을 중지하고 실패 상태를 반환합니다. 작업 실패율이 임계값을 초과한 이유를 필터링하여 확인할 수 있으며, 객체 리스트에 존재하지 않는 객체 정보가 대량으로 포함되어 있는 경우 오류 수정 후 다시 작업을 생성합니다.
주의：
COS 일괄 프로세스 작업은 비동기화 방식으로 실행되며, 객체 작업이 반드시 리스트 상의 객체 순서로 실행되지 않습니다. 따라서 객체 리스트 상의 객체 순서에 따라 어떤 객체까지 작업되었다고 판단할 수 없으며, 이에 따라 작업의 성공 또는 실패 상황을 판단합니다. 작업 보고서에서 작업의 성공 또는 실패 정보를 확인할 수 있습니다.
작업 보고서
작업 생성 시 작업 보고서 출력 여부를 설정할 수 있습니다. 작업 보고서 출력을 설정한 경우, COS는 작업 성공, 실패 또는 취소 시 보고서를 출력하며, 해당 보고서로 작업과 관련된 모든 성공 또는 실패 작업 상황을 확인할 수 있습니다.
작업 보고서에는 작업의 지정 작업에 대한 설정 매개변수, 실행 상태 등의 정보가 포함되어 있으며, 이외에도 처리된 객체의 객체 이름, 버전 ID, 작업 상태 코드, 오류 설명 등의 내용이 포함되어 있습니다.
글로벌 가속
글로벌 가속 개요
최종 업데이트 날짜:：2025-10-29 16:13:02
Tencent Cloud Cloud Object Storage(COS)의 글로벌 가속 기능은, Tencent의 전체 트래픽을 스케쥴링하는 CLB(Cloud Load Balancer) 시스템을 통해, 사용자의 요청을 스마트 라우팅 및 리졸브하여, 최적의 네트워크 액세스 링크를 선택하고, 요청에 따른 근접 액세스를 구현합니다. 전 세계에 분포한 클라우드 데이터 센터가 전 세계 각지의 사용자의 신속한 버킷 액세스를 구현하여, 액세스 성공률이 높을 뿐만 아니라, 안정적인 비즈니스 환경을 제공하고, 비즈니스 경험을 향상시킵니다. 또한 COS의 글로벌 가속 기능으로 더욱 신속하게 데이터를 업로드 및 다운로드할 수 있습니다.
주의：
글로벌 가속 기능은 COS 퍼블릭 클라우드리전 을 지원합니다.그러나 네트워크 격리로 인해 금융 클라우드 지역에서는 지원되지 않습니다.
글로벌 가속 기능을 사용하면, 정보 요청이 Tencent Cloud 내부 네트워크 전용 회선을 통해 가속 전송되기 때문에 요금이 부과됩니다. 자세한 요금 정보는 제품 가격을 참고하십시오.
글로벌 가속 기능을 활성화한 뒤, 두 가지 도메인으로 COS 내 파일에 액세스할 수 있습니다.
버킷 기본 도메인: 형식은 <BucketName-APPID>.cos.<Region>.myqcloud.com이며, 자세한 내용은 리전 및 액세스 도메인을 참고하십시오.
글로벌 가속 도메인: 형식은 <BucketName-APPID>.cos.accelerate.myqcloud.com입니다.
예를 들어, 광저우 리전의 버킷 examplebucket-1250000000에 글로벌 가속 기능을 활성화한 경우, 베이징에서 해당 버킷으로 파일 exampleObject.txt를 업로드할 때 선택할 수 있는 두 가지 업로드 방식이 있습니다.
글로벌 가속 도메인으로 액세스: 업로드할 때 도메인을 examplebucket-1250000000.cos.accelerate.myqcloud.com으로 지정하면 해당 도메인을 통해 객체를 업로드할 경우, COS 서비스는 네트워크 상태에 따라 스마트 리졸브 및 근접 액세스를 실행합니다. 예를 들어, 베이징의 액세스 레이어로 요청을 전달하면, 내부 네트워크의 전용 회선을 거쳐 광저우 스토리지 레이어로 전송되는 과정이 가속으로 이뤄집니다.
버킷 기본 도메인으로 액세스: 업로드 시 도메인을 examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com으로 지정합니다. 해당 도메인을 통해 객체를 업로드할 때, 요청이 광저우의 액세스 레이어로 바로 전달된 뒤, 다시 광저우 스토리지 레이어로 전송됩니다. 이때 외부 네트워크의 링크가 길기 때문에 전송이 불안정할 수 있습니다.
주의：
글로벌 가속 기능은 별도의 요금이 부과되므로 실제 비즈니스 상황을 잘 고려하여 선택하시기 바랍니다.
평소 읽기 작업보다 쓰기 작업을 많이 수행하고, 원격지에서 클라우드 데이터 센터로 데이터를 업로드(예: PUT Object, POST Object, Multipart Upload 작업)하는 경우, 글로벌 가속 도메인 사용을 권장합니다.
평소 쓰기 작업보다 읽기 작업을 많이 수행하고, 주로 파일을 다운로드(예: GET Objcet 작업)하는 경우, 비용 최적화를 위해, CDN 가속 솔루션을 권장합니다.
평소 설정이나 파일 인덱스 작업이 많다면, 버킷의 기본 도메인 사용을 권장합니다.
동일 리전의 내부 네트워크 환경에서 동일 리전 내 버킷을 액세스하거나 전용 회선으로 액세스할 경우, 버킷의 기본 도메인 사용을 권장합니다.
DNS 스마트 분석 구성
기업이 전 세계적으로 액세스해야 하는 경우 DNS 스마트 분석 구성을 통해 사용자가 국내 또는 해외에 있는지 판단하여 사용자 액세스에 더 빠르게 응답할 수 있습니다. 해당 DNS 서비스 공급자에서 CNAME 분석 레코드를 구성하세요. 주요 작업 단계는 다음과 같습니다:
1. 도메인 추가: 스마트 분석을 구성할 사용자 정의 도메인을 추가하고 해당 도메인의 레코드 관리 페이지로 이동합니다.
2. 레코드 추가: 2개의 CNAME 레코드 생성(예: 호스트 레코드를 'accelerate'로 설정). 첫 번째 분석 레코드의 라인 유형을 국내로 설정하고 레코드 값을 버킷의 기본 도메인 examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com으로 설정; 두 번째 분석 레코드의 라인 유형을 기본으로 설정하고 레코드 값을 글로벌 가속 도메인 examplebucket-1250000000.cos.accelerate.myqcloud.com으로 설정합니다.
3. 객체 스토리지 콘솔에 로그인하여 버킷에 사용자 정의 도메인을 구성하고 원본 사이트로 글로벌 가속 원본 사이트를 선택합니다. 사용자 정의 도메인 옆에 빨간색 느낌표가 표시되고 도메인 분석 문제를 알리는 메시지가 나타날 수 있지만 이 알림은 무시해도 됩니다.
4. 위와 같은 방법으로 구성한 후 구성한 사용자 정의 도메인에 접근하면 다음과 같은 효과를 얻을 수 있습니다:
귀하의 로컬 DNS 출구 IP가 해외에서 발생한 경우, DNS 쿼리에서 얻은 주소는 글로벌 가속 도메인입니다.
귀하의 로컬 DNS 출구 IP가 국내에서 발생한 경우, DNS 쿼리에서 얻은 주소는 버킷의 기본 도메인입니다.
5. COS SDK를 사용하는 경우, 필요한 효과를 얻기 위해 사용자 정의 도메인으로 클라이언트를 초기화할 수 있습니다. JS SDK를 예로 들면 다음과 같습니다:
import COS from 'cos-js-sdk-v5';
const cos =newCOS({
SecretId: 'your_tmpSecretId',// sts 서비스에서 발급한 임시 secretId
SecretKey: 'your_tmpSecretKey',// sts 서비스에서 발급한 임시 secretKey
SecurityToken: 'your_sessionToken',// sts 서비스에서 발급한 임시 SessionToken
Domain: 'your.custom.domain' //사용자 정의 도메인 입력
});
주의 사항
다음은 글로벌 가속 도메인 사용 시 주의사항입니다.
글로벌 가속 도메인을 활성화하고 약 15분 후에 적용되므로 잠시 기다려주십시오.
글로벌 가속 도메인을 활성화한 뒤 단일 버킷이 가속 도메인으로 액세스하는 최대 대역폭은 전체 네트워크 사용량에 따라 분배됩니다.
글로벌 가속 도메인을 활성화하면 가속 도메인에 의한 요청만 가속 효과가 적용되며, 버킷의 기본 도메인은 여전히 정상적으로 사용할 수 있습니다.
가속 도메인을 사용하는 경우, 요청 링크가 가속 링크일 때만 가속 요금이 부과됩니다. 예를 들어, 가속 도메인으로 베이징에서 베이징의 버킷으로 데이터를 업로드하면 링크에 대해 가속 기능이 작동하지 않아 요청 관련 요금이 발생하지 않습니다.
가속 도메인을 사용하는 경우, HTTP/HTTPS 전송 프로토콜을 지정하여 내부 네트워크의 전용 회선으로 정보 요청을 전송하면 COS에서 데이터 전송 보안을 위한 HTTPS 프로토콜의 채택 여부를 판단합니다.
과금 예시
글로벌 가속 도메인으로 데이터를 업로드하거나 버킷에 액세스하면 별도의 가속 요금이 부과되며, 가속 요금은 일별 결산됩니다. 관련 과금 항목 및 가격 정보는 과금 개요와 제품 가격을 참고하십시오. 다음은 가속 도메인과 버킷 기본 도메인을 사용했을 때의 요금 비교 내역입니다.
비즈니스 시나리오 1
주로 비디오 파일을 COS에 업로드하는 시나리오로, 전송 성공률에 대한 요구도가 높습니다. 광저우 리전에 설정된 버킷에 매일 신장과 싱가포르의 사무실로부터 각각 1GB의 비디오 데이터가 업로드됩니다. 이 경우, 30일 간의 요금을 계산하면 다음과 같습니다.
가속 도메인으로 업로드 시 발생하는 업로드 요금: 30 x 1GB x (0.07USD/GB + 0.18USD/GB) = 7.5USD
버킷 기본 도메인으로 업로드 시 발생하는 업로드 요금: 30 x 1GB x (0USD/GB) = 0USD
설명：
중국 내의 업로드 가속 요금 단가는 0.07USD/GB이며, 중국 외 지역의 업로드 가속 요금은 0.18USD/GB입니다. 버킷 기본 도메인으로 파일 업로드 시 업로드 트래픽 요금이 발생하지 않습니다.
비즈니스 시나리오 2
해외 파일 다운로드 가속 시나리오로, 전송 성공률에 대한 요구도가 높습니다. 버킷은 광저우 리전에 설정되어있으며, 매일 싱가포르 사무실로부터 1GB의 비디오 데이터를 다운로드합니다. 이 경우, 30일 간의 요금을 계산하면 다음과 같습니다.
가속 도메인으로 다운로드 시 발생하는 다운로드 가속 트래픽 요금 :30 x 1GB x 0.18USD/GB = 5.4USD
가속 도메인으로 다운로드 시 발생하는 공인 네트워크 다운스트림 트래픽 요금:30 x 1GB x 0.1USD/GB = 3USD
총 다운로드 트래픽 요금은 5.4 + 3 = 8.4USD입니다.
설명：
해외 다운로드 가속 요금 단가는 0.18USD/GB입니다. 글로벌 가속 도메인으로 파일 다운로드 시 외부 네트워크 다운스트림 트래픽 비용과 글로벌 가속 다운스트림 트래픽 비용이 청구됩니다.
사설망 글로벌 가속
최종 업데이트 날짜:：2024-06-24 17:08:32
Tencent Cloud의 글로벌 트래픽 스케쥴링 기능과 COS의 사설망 글로벌 가속화 경로를 활용하여 사용자 요청을 지능적으로 해결하여 최적의 네트워크 액세스 링크를 선택하고 개별 리전 간의 리소스에 빠르게 액세스할 수 있도록 지원합니다. 이를 통해 Tencent Cloud의 사설망 백본 라인의 안정적인 전송 품질을 충분히 활용하여 리전 간 데이터 전송의 안정성과 성능을 향상시킬 수 있습니다.
많은 비즈니스는 사설망을 통해 리전 간 데이터를 가져와야 하는 필요성이 있습니다. 예를 들어, 컨테이너 이미지 배포 시나리오에서는 이미지 리포지토리는 보통 한 리전에 중앙 집중식으로 저장되며, 컨테이너 클러스터는 비즈니스 요구에 따라 다른 리전에 배포될 수 있습니다. 애플리케이션 배포 중에는 컨테이너 클러스터가 다른 리전에서 이미지를 가져와야 하므로 많은 리전 간 요청이 발생합니다. 이러한 시나리오에서 사설망 글로벌 가속화 엔드포인트를 사용하여 안정적인 사설망 리전 간 직접 연결 라인을 제공하여 이미지 배포 안정성을 향상시킬 수 있습니다.
주의：
이 기능을 사용하면 요청 데이터 전송이 Tencent Cloud 사설망의 직접 연결 회선을 통해 가속화되므로 요금이 발생합니다. 자세한 가격 정보는 가격 | Cloud Object Storage를 참고하십시오.
사용 방법
COS 콘솔과 API 등 방식으로 글로벌 가속 기능을 활성화할 수 있습니다.
COS 콘솔 사용
COS 콘솔에서 버킷에 필요한 글로벌 가속 기능을 활성화할 수 있습니다. 글로벌 가속 활성화 콘솔 문서를 참고하십시오.
글로벌 가속 기능을 활성화한 후 <BucketName-APPID>.cos-internal.accelerate.tencentcos.cn 형식의 사설망 글로벌 가속 엔드포인트를 통해 사설망을 통해 다른 리전의 COS 파일에 액세스할 수 있습니다.
예를 들어, 어떤 비즈니스 애플리케이션 이미지가 광저우 리전에 있는 examplebucket-1250000000 버킷에 저장되어 있으며, 해당 애플리케이션의 컨테이너 클러스터가 광저우, 베이징, 상하이 리전에 배포되어 있다고 가정합니다. 컨테이너 이미지 배포를 가속화하기 위해 비즈니스 팀은 버킷 examplebucket-1250000000에 대한 글로벌 가속화를 활성화하여, 베이징, 상하이 및 광저우 리전의 컨테이너 클러스터가 사설망 글로벌 가속화 엔드포인트 examplebucket-1250000000.cos-internal.accelerate.tencentcos.cn를 통해 사설망을 통해 이미지 패키지를 가져올 수 있게 되었습니다.
광저우 리전의 컨테이너 클러스터가 엔드포인트를 통해 파일을 가져오면 COS는 광저우 리전의 사설망 액세스 레이어에 대한 요청을 지능적으로 해결하여 동일한 리전의 스토리지 클러스터에서 직접 파일을 풀링합니다.
베이징/상하이 리전의 컨테이너 클러스터가 엔드포인트를 통해 파일을 가져올 때, COS는 베이징/상하이 리전의 사설망 액세스 레이어에 대한 요청을 지능적으로 리졸브하고 사설망 액세스 레이어 장치를 사용하여 광저우 리전의 스토리지 클러스터에서 파일을 리전 간 백본 네트워크 직접 연결 회선을 통해 풀링합니다.
주의：
글로벌 가속 기능은 별도의 요금이 부과되므로 실제 비즈니스 상황을 잘 고려하여 선택하시기 바랍니다.
사설망 글로벌 가속 엔드포인트는 Tencent Cloud 사설망 환경에서만 사용할 수 있습니다. 요청 소스가 Tencent Cloud 사설망 환경에 있지 않으면 연결할 수 없습니다. 이 경우 기본 엔드포인트 또는 기본 글로벌 가속 엔드포인트 사용을 고려할 수 있습니다.
CVM, TKE 또는 SCF와 같은 다른 Tencent Cloud 제품에서 사설망 글로벌 가속 엔드포인트를 사용하는 경우 해당 제품은 COS를 사용할 수 있는 리전에 있어야 하며, 그렇지 않으면 사용할 수 없습니다. COS를 사용할 수 있는 리전에 대한 자세한 내용은 리전 및 액세스 도메인을 참고하십시오.
주의 사항
다음은 글로벌 가속 도메인 사용 시 주의사항입니다.
글로벌 가속 도메인을 활성화하고 약 15분 후에 적용되므로 잠시 기다려주십시오.
글로벌 가속 도메인을 활성화한 뒤 단일 버킷이 가속 도메인으로 액세스하는 최대 대역폭은 전체 네트워크 사용량에 따라 분배됩니다.
글로벌 가속 도메인을 활성화하면 가속 도메인에 의한 요청만 가속 효과가 적용되며, 버킷의 기본 도메인은 여전히 정상적으로 사용할 수 있습니다.
가속 도메인을 사용하는 경우, 요청 링크가 가속 링크일 때만 가속 요금이 부과됩니다. 예를 들어, 가속 도메인으로 베이징에서 베이징의 버킷으로 데이터를 업로드하면 링크에 대해 가속 기능이 작동하지 않아 요청 관련 요금이 발생하지 않습니다.
가속 도메인을 사용하는 경우, HTTP/HTTPS 전송 프로토콜을 지정하여 내부 네트워크의 전용 회선으로 정보 요청을 전송하면 COS에서 데이터 전송 보안을 위한 HTTPS 프로토콜의 채택 여부를 판단합니다.
모니터링 및 알람
모니터링 및 알람
최종 업데이트 날짜:：2025-11-19 15:17:54
개요
COS의 읽기/쓰기 요청량, 트래픽 등의 데이터는 Cloud Monitor를 기반으로 통계 및 표시합니다. COS 콘솔 또는 클라우드 모니터링의 콘솔에서 COS의 읽기/쓰기 요청량, 트래픽 등 자세한 모니터링 데이터를 확인할 수 있습니다.
설명:
본 문서는 COS 콘솔에서 통계를 얻는 방법을 설명합니다. Cloud Monitor API를 호출하여 더 자세한 데이터를 얻을 수 있습니다. 자세한 내용은 Cloud Monitor 제품 문서를 참고하십시오.
현재 CM에 보고된 모든 메트릭은 모든 COS 리전을 지원합니다. 자세한 내용은 리전 및 액세스 도메인을 참고하십시오.
기본 기능
Cloud Monitor는 COS에 다음과 같은 게이트를 제공하여 모니터링과 알람 기능을 구현합니다.
모듈
설명
주요 기능
모니터링 개요
제품의 현재 상태 표시
전체 현황, 알람 현황, 전체 모니터링 정보 목록 제공
알람 관리
알람 관리 및 설정 지원
COS에 신규 추가된 알람 정책, 사용자 정의 정보, 트리거 조건 템플릿 지원
모니터링 플랫폼
트래픽 모니터링 및 사용자 정의한 모니터링 지표 데이터 조회
사용자 전체 대역폭 정보 조회, 사전에 모니터링 지표 및 보고 데이터 사용자 정의
클라우드 서비스 모니터링
COS의 버킷 모니터링 도표 조회
현재 각 버킷의 읽기/쓰기 요청량, 트래픽 등 모니터링 도표 및 데이터 조회
시나리오
일상 관리 시나리오: Cloud Monitor 콘솔에 로그인하여 COS의 실행 상태를 실시간으로 확인합니다.
이상 경고 처리 시나리오: 모니터링 데이터가 알람 임계값에 도달하는 경우, 알람 정보를 발송하여 사용자가 빠르게 이상 경고 알림을 수신하고 원인을 찾아 즉시 처리할 수 있도록 합니다.
COS의 모니터링 인터페이스에 대한 자세한 내용은 COS 모니터링 지표 문서를 참고하십시오.
설명:
COS는 범용 리전을 사용합니다. 따라서 버킷이 어떤 리전에 소속되어 있든 COS 모니터링 지표 데이터 풀링 시, Region은 항상 '광저우' 리전으로 선택하십시오.
API Explorer를 사용해 데이터 풀링 시, Region 필드는 항상 '화남 리전(광저우)'으로 선택하십시오.
SDK 를 사용해 데이터 풀링 시, Region 필드는 항상 'ap-guangzhou'로 입력하십시오.
각 지표의 통계 단위(Period)는 모두 상이합니다. DescribeBaseMetrics 인터페이스를 통해 각 지표가 지원하는 통계 단위를 확인할 수 있습니다.
3xx, 4xx, 5xx 상태 코드에 관한 자세한 내용은 Error Codes를 참고하십시오.
각 차원의 해당 매개변수 개요
매개변수 이름
차원 이름
차원 설명
포맷
&Instances.N.Dimensions.0.Name
appid
루트 계정 APPID의 차원 이름
String 유형의 차원 이름 입력: appid
&Instances.N.Dimensions.0.Value
appid
루트 계정의 구체적인 APPID
루트 계정 APPID 입력. 예: 1250000000
&Instances.N.Dimensions.1.Name
bucket
버킷 차원 이름
String 유형의 차원 이름 입력: bucket
&Instances.N.Dimensions.1.Value
bucket
버킷의 구체적인 이름
버킷의 구체적인 이름 입력. 예: examplebucket-1250000000
입력 매개변수 설명
COS 모니터링 데이터를 조회합니다. 입력 매개변수 값은 다음과 같습니다.
&Namespace=QCE/COS
&Instances.N.Dimensions.0.Name=appid
&Instances.N.Dimensions.0.Value=루트 계정의 APPID
&Instances.N.Dimensions.1.Name=bucket
&Instances.N.Dimensions.1.Value=버킷 이름
모니터링 설명
모니터링 간격: Cloud Monitor는 실시간, 최근 24시간, 최근 7일, 사용자 정의 날짜 등 여러 가지 통계 구간에 따라 모니터링 데이터를 제공하며, 시간은 1분, 5분, 1시간, 1일로 세분화됩니다.
데이터 스토리지: 1분 단위 모니터링 데이터, 15일 저장 / 5분 단위 모니터링 데이터, 31일 저장 / 1시간 단위 모니터링 데이터, 93일 저장 / 1일 단위 모니터링 데이터, 186일 저장을 지원합니다.
알람 표시: Cloud Monitor는 COS의 모니터링 데이터를 통합하여 보기 쉬운 도표 형태로 표시합니다. 제품에 미리 정의된 알람 지표에 따라 알람을 보낼 수 있어 사용자가 전체적인 운영 상태를 파악할 수 있습니다.
알람 설정: 모니터링 지표 임계값을 설정하고, 모니터링 데이터가 알람 조건을 충족하면 Cloud Monitor가 즉시 알람 정보를 관련 그룹에 전송합니다. 자세한 내용은 Alarm Overview 및 모니터링 알람 설정을 참고하십시오.
데이터 모니터링
데이터 개요 조회
최종 업데이트 날짜:：2025-05-28 17:24:04
소개
Cloud Object Storage(COS) 콘솔은 스토리지 데이터 개요 페이지를 제공합니다. 페이지에서 버킷 수량, 객체 수량, 스토리지 사용량, 요청 수량 및 트래픽 등 데이터를 조회할 수 있습니다.
주의:
서브 계정으로 데이터를 조회하려면 버킷 리스트 액세스 권한이 있어야 합니다. 자세한 내용은 서브 계정으로 버킷 리스트 액세스 문서의 사전 설정 정책 추가 부분을 참고하십시오.
이 데이터 개요 중 버킷 수량은 실시간 데이터이며, 그 외의 데이터는 실시간 데이터에는 약 2시간의 딜레이가 있습니다. 해당 데이터는 모니터링 참고용 데이터이며, 정확한 요금은 과금 센터에서 조회할 수 있습니다.
데이터 그래프 조회
작업 단계
1. COS 콘솔에 로그인한 후, 왼쪽 사이드바에서 사용 통계 > 기본 사용 통계를 클릭해 데이터 모니터링 페이지로 이동합니다.
2. 데이터 개요 페이지에서 다음 정보를 조회할 수 있습니다.
버킷 수량: 현재 생성 완료된 총 버킷 수량입니다.
객체 수량: 현재 생성 완료된 모든 버킷의 총 객체 수량으로,드롭다운을 통해 다양한 스토리지 유형의 객체 수량을 확인할 수 있습니다. 오른쪽 상단의 전체 보기를 클릭하면 각 스토리지 유형의 상세 데이터를 빠르게 확인할 수 있으며, 데이터 내보내기도 지원합니다. 자세한 내용은 개요 데이터 조회 및 내보내기를 참조하십시오.
당월 일평균 스토리지 사용량: 각각 STANDARD, MAZ_STANDARD, STANDARD_IA, MAZ_STANDARD_IA,INTELLIGENT_TIERING, MAZ_INTELLIGENT_TIERING,ARCHIVE, MAZ_ARCHIVE, DEEP_ARCHIVE의 일일 평균 사용량을 확인할 수 있습니다. 이 중 일일 저장 용량 = 해당 일의 "5분 단위 저장 용량"의 합계 / 288(샘플링 지점 수)이고, 해당 월의 일일 평균 저장 사용량 = 해당 월의 각 요일의 일일 저장 용량의 합계 / 해당 월의 일 수입니다.전체 보기를 클릭하면 각 스토리지 유형의 상세 데이터를 빠르게 확인할 수 있으며, 데이터 내보내기도 지원합니다. 자세한 내용은 개요 데이터 조회 및 내보내기를 참조하십시오.
스토리지 사용량 그래프: 최근 90일 간의 STANDARD, MAZ_STANDARD, STANDARD_IA,MAZ_STANDARD_IA,INTELLIGENT_TIERING, MAZ_INTELLIGENT_TIERING, ARCHIVE, DEEP_ARCHIVE의 사용량 내역을 조회할 수 있습니다.각 쿼리의 기간은 31일을 초과할 수 없습니다.
트래픽 그래프: 최근 90일 간의 STANDARD, MAZ_STANDARD, STANDARD_IA , MAZ_STANDARD , INTELLIGENT_TIERING , MAZ_INTELLIGENT_TIERING의 공중망 다운스트림 트래픽, 사설망 트래픽, CDN Origin-pull 트래픽,글로벌 가속 다운스트림 트래픽은 내역을 조회할 수 있습니다.각 쿼리의 기간은 31일을 초과할 수 없습니다.
주의:
글로벌 가속 다운스트림 트래픽은 스토리지 유형에 따라 구분되지 않습니다.
요청 수량 그래프: 최근 90일 간의 STANDARD, MAZ_STANDARD, STANDARD_IA , STANDARD_IA,MAZ_STANDARD , INTELLIGENT_TIERING, MAZ_INTELLIGENT_TIERING유형의 읽기/쓰기 요청 내역을 조회할 수 있습니다. 각 쿼리의 기간은 31일을 초과할 수 없습니다.
사용자 유효 요청 비율 그래프:최근 90일 간의 STANDARD, MAZ_STANDARD의 사용자 유효 읽기/쓰기 요청 비율 내역을 조회할 수 있습니다. 각 쿼리의 기간은 31일을 초과할 수 없습니다.
데이터 검색량 그래프:STANDARD_IA, MAZ_STANDARD_IA, INTELLIGENT_TIERING, MAZ_INTELLIGENT_TIERING, ARCHIVE, MAZ_ARCHIVE, DEEP_ARCHIVE의 데이터 검색 볼륨을 확인할 수 있습니다. 아카이브 스토리지 유형에는 빠른 검색 볼륨, 표준 검색 볼륨, 배치 검색 볼륨이 포함됩니다. 이전 90일 동안의 데이터 세부 정보를 쿼리할 수 있으며, 각 쿼리의 기간은 31일을 초과할 수 없습니다.
3. 도표 오른쪽의 다운로드 버튼을 통해 핵심 데이터를 일괄 내보내기할 수 있습니다.
개요 데이터 조회 및 내보내기
작업 절차
다음 방법으로 객체 수, 이번 달 일일 평균 스토리지 사용량의 각 스토리지 유형 상세 데이터를 빠르게 확인하고 내보낼 수 있습니다.
1. 기본 사용 통계 페이지의 개요 모듈에서 오른쪽 상단의 전체 보기를 클릭하면 개요 데이터를 확인할 수 있습니다.
2. 데이터 내보내기를 클릭하면 개요 데이터를 다운로드할 수 있습니다.
버킷 차원 데이터 조회
작업 단계
1. COS 콘솔 로그인 후 왼쪽 사이드바에서 버킷 리스트를 클릭하고 인터페이스에서 통계 데이터를 선택합니다.
2. 통계 데이터 인터페이스에서 스토리지 유형과 시간대에 따라 버킷 사용량, 데이터 검색량, 트래픽, 요청 수량 등 각 버킷의 통계 데이터를 조회할 수 있습니다.
데이터 모니터링 조회
최종 업데이트 날짜:：2025-11-14 17:11:20
소개
Cloud Object Storage(COS)는 저장 데이터를 모니터링하는 기능을 제공합니다. 통계 데이터의 데이터 모니터링 창에서 요청량, 트래픽, 반환 코드, 읽어온 데이터 등의 데이터를 확인할 수 있으며, 데이터 모니터링 창을 통해 시간대별로 서로 다른 스토리지 유형의 데이터에 대한 데이터 양과 추세를 조회할 수 있습니다. 다음은 루트 계정 또는 서브 계정에서 단일 버킷의 모니터링 데이터를 조회하는 방법을 소개합니다.
설명：
사용자 계정의 모든 저장 데이터의 종합 정보를 조회하고 싶은 경우, COS 콘솔의 데이터 모니터링에서 조회할 수 있습니다.
2. 왼쪽 사이드바에서 정책 > 사용자 지정 정책 생성 > 정책 구문으로 생성을 클릭합니다.
3. 빈 템플릿을 선택하고 다음을 클릭합니다.
4. 정책 콘텐츠 편집 입력 상자에 다음 정책 구문을 입력합니다.
필요에 따라 쉽게 찾을 수 있도록 정책의 이름을 바꿀 수 있습니다.
정책 구문:
{
"version":"2.0",
"statement":[
{
"effect":"allow",
"action":[
"monitor:GetMonitorData"
],
"resource":"*"
}
]
}
5. 정책 생성을 클릭합니다.
정책 생성이 완료되면 서브 계정에 해당 정책을 추가할 수 있습니다. 자세한 작업 방법은 정책 템플릿으로 구성을 참고하십시오.
모니터링 알람 설정
최종 업데이트 날짜:：2024-06-24 16:12:03
소개
클라우드 모니터링 알람 정책을 통해 COS 모니터링 지표의 임계값 알람을 설정할 수 있습니다. 알람 정책에는 이름, 정책 유형 및 알람 트리거 조건, 알람 객체, 알람 공지 템플릿 등 5가지 필수 구성 요소가 포함됩니다. 다음 가이드에 따라 COS 알람 정책을 생성할 수 있습니다.
설명：
Tencent Cloud의 클라우드 모니터링은 클라우드 서비스 리소스에 대한 실시간 모니터링 및 알람 서비스입니다. 사용자는 클라우드 모니터링으로 COS의 모니터링 지표에 대한 알람 규칙 설정 및 알람 기록 조회가 가능하고 알람 공지를 받을 수 있습니다. 자세한 내용은 Creating Alarm Policy를 참고하십시오.
작업 단계
1. COS 콘솔에 로그인하여 콘솔 개요 페이지의 알람 설정 항목에서 알람 정책 설정을 클릭합니다.
설명：
버킷 개요 페이지에서도 알람 설정을 찾을 수 있습니다.
2. 아래와 같이 새로운 알람 정책을 구성합니다.
유형 설정
설정 항목
설명
기본 정보
정책 이름
사용자 정의 정책 이름.
비고
사용자 정의 정책 비고.
모니터링 유형
클라우드 서비스 모니터링 선택.
정책 유형
COS 선택.
정책 서브 프로젝트
정책 서브 프로젝트의 두 가지 역할:
알람 정책을 관리합니다. 서브 프로젝트를 설정하면 알람 정책 리스트에서 해당 프로젝트의 알람 정책을 빠르게 필터링할 수 있습니다.
인스턴스를 관리합니다. 필요에 따라 프로젝트를 선택하면 알람 객체 중 해당 프로젝트의 인스턴스를 빠르게 선택할 수 있습니다. 비즈니스 유형에 따라 클라우드 서비스를 각 프로젝트에 할당할 수 있습니다. 프로젝트 생성은 프로젝트 관리를 참고하십시오. 프로젝트 생성 후 각 클라우드 서비스 콘솔에서 각 클라우드 서비스 리소스에 프로젝트를 할당할 수 있으며 일부 클라우드 서비스는 프로젝트 할당을 지원하지 않습니다. 프로젝트 권한이 없을 경우 Cloud Access Management (CAM)를 참고하여 권한을 부여합니다.
알람 규칙 설정
알람 객체
인스턴스 ID를 선택할 경우 알람을 추가하고 싶은 버킷을 선택합니다.
인스턴스 그룹 나누기를 선택할 경우 해당 알람 정책은 사용자가 선택한 인스턴스 그룹 나누기를 바인딩합니다. 그룹을 나누지 않았다면 인스턴스 그룹 생성을 클릭해 버킷에 신규 그룹을 나누고 재선택할 수 있습니다.
전체 객체를 선택할 경우 해당 알람 정책은 현재 계정이 권한을 가진 모든 버킷을 바인딩합니다.
템플릿 선택
템플릿 버튼을 클릭하여 드롭다운 리스트에서 설정 완료한 템플릿을 선택합니다. 설정에 관한 상세 내용은 Configuring Trigger Condition Template을 참고하십시오. 생성한 템플릿이 표시되지 않을 경우 오른쪽에 있는 새로고침을 클릭하면 알람 템플릿이 트리거되어 선택 리스트를 새로 고칠 수 있습니다.
수동 설정(메트릭 알람)
알람 트리거 조건: 지표, 비교 관계, 임계값, 통계 주기, 지속 주기로 구성된 semantics 조건입니다. 도표의 지표 변화 추이에 따라 알람 임계값을 설정할 수 있습니다. 예시: 지표는 표준 스토리지 읽기 요청, 비교 관계는 >, 임계값 80회, 통계 주기 5분, 지속 주기 2회. 표시: 5분마다 표준 스토리지 읽기 요청 데이터를 수집하고 일정 버킷의 표준 스토리지 읽기 요청이 2번 연속으로 80회를 초과할 경우 알람이 트리거됩니다.
알람 빈도: 모든 알람 규칙에 반복 공지 정책을 설정할 수 있습니다. 즉, 알람 생성 시 특정 빈도로 반복 공지 알람을 정의할 수 있습니다.
옵션: 반복 없음, 5분, 10분, 주기 점차 증가 등
주기 점차 증가는 해당 알람에 1차, 2차, 4차, 8차... 2의 N승차로 트리거되었을 때 알람 정보가 발송된다는 의미입니다. 알람 정보 발송 시간 간격을 늘릴수록 반복 알람으로 인한 불편을 어느 정도 줄일 수 있습니다.
반복 알람 기본 로직: 설정된 반복 알림 빈도에 따라 알람 생성 후 24시간 내에 알람이 반복 전송됩니다. 알람 생성 후 24시간이 지나면 알람이 하루에 한 번 전송됩니다.
알람 전송 구성
알람 전송
시스템 사전 설정 공지 템플릿 및 사용자 정의 공지 템플릿을 선택할 수 있으며 알람 정책마다 최대 3개의 공지 템플릿을 바인딩할 수 있습니다.
고급 설정
오토 스케일링
활성화 및 설정 완료 후 알람 조건에 부합하면 오토 스케일링 정책이 트리거되어 스케일링이 진행됩니다.
3. 상기 정보를 설정한 후 완료를 클릭하여 COS 알람 정책을 성공적으로 생성합니다.
운영 센터
보안 관리
최종 업데이트 날짜:：2025-11-18 15:47:53
소개
COS(Cloud Object Storage) 콘솔은 사용자가 버킷의 구성 위험을 식별, 평가 및 제어할 수 있도록 보안 관리 기능을 제공하여 데이터의 안전성과 규정 준수를 보장합니다. 위험 감지, 평가 보고서 및 위험 관리 조치를 통해 스토리지 버킷 구성 오류로 인한 잠재적 보안 위험(예: 데이터 유출, 트래픽 도용 등)을 효과적으로 줄일 수 있습니다.
주의:
COS는 TSA(Tencent Cloud Smart Advisor)를 기반으로 보안 관리 서비스를 제공합니다. 보안 관리를 처음 사용하는 경우 먼저 TSA 서비스와 서비스 역할 권한을 활성화해야 합니다.
데이터 보안을 위해 서브 계정은 스토리지 버킷 목록 액세스 권한이 있어야 정상적으로 보안 관리를 사용할 수 있습니다. 권한이 없는 경우 루트 계정에 문의하여 해당 권한을 부여받으십시오. 자세한 내용은 사전 설정 정책 QcloudCOSGetServiceAccess 추가를 참고하십시오.
위험 평가 결과는 버킷 구성 항목의 속성에 따라 주로 도난, 보안, 신뢰성, 성능, 비용 다섯 가지 범주로 분류됩니다. 서로 다른 분류에서 해당 평가 항목의 평가 결과를 직관적으로 확인할 수 있으며, 평가 항목 이름, 평가 항목 소개 및 해당 평가 항목의 위험 버킷 수가 포함됩니다. 위험 평가 결과 확인 절차는 다음과 같습니다.
1. 보안 관리 페이지에서 평가 결과 영역을 확인하세요.
2. 기본적으로 전체 평가 결과가 표시되며, 이는 검토된 모든 버킷 구성 항목의 평가 결과를 의미합니다. 기본적으로 3개가 표시되며, 더 보기를 클릭하면 다른 평가 결과를 확인할 수 있습니다.
3. 전체 평가 결과를 필터링하려면 오른쪽 필터 상자를 클릭하여 드롭다운 선택을 할 수 있습니다.
4. 상단 탭 바를 클릭하여 다른 카테고리(예: 도용)의 평가 결과를 확인할 수도 있습니다.
결과 상세 및 관리
평가 결과 영역에서 각 평가 항목 아래에 위험이 있는 모든 버킷 목록과 트리거 규칙을 확인할 수 있으며, 해당 최적화 제안을 얻고 빠른 관리를 할 수 있습니다. 절차는 다음과 같습니다.
1. 보안 관리 페이지에서 평가 결과 영역을 확인하세요.
2. 평가 항목 카드를 클릭하면 오른쪽에 해당 항목의 결과 상세 및 관리 페이지가 자동으로 표시됩니다.
3. 페이지 상단에는 평가 항목 이름, 평가 항목 소개, 위험 버킷 수량, 트리거 규칙 및 최적화 제안이 표시되며, 페이지 하단에는 평가 중 및 무시된 버킷 목록이 표시됩니다.
4. 최적화 제안에 따라 지정된 버킷을 조치할 수 있으며, 목록에서 버킷을 클릭하면 빠르게 구성으로 이동할 수 있습니다.
5. 평가 중인 버킷 목록에서 목록 오른쪽의 무시를 클릭하여 해당 버킷을 설정할 수 있으며, 이 버킷은 무시된 버킷 목록에 포함되어 이후 평가에서 검사되지 않습니다.
6. 무시된 버킷 목록에서 오른쪽의 무시 취소를 클릭하여 해당 버킷을 설정할 수 있으며, 이 버킷은 평가 중인 버킷 목록에 포함되어 평가 시 해당 버킷을 계속 검사합니다.
3. 또한 특정 평가 항목 카드 내의 설정 아이콘을 클릭하여 TSA로 빠르게 이동하여 규칙을 조정할 수도 있습니다.
설명:
빠른 이동은 규칙 조정이 지원되는 평가 항목에만 적용됩니다.
위험 이력
위험 추세 변화를 조회하고 이력 위험 상세 정보를 확인할 수 있으며, 상세한 작업 방법은 다음과 같습니다.
1. 보안 관리 페이지에서 평가 결과 영역을 확인하세요.
2. 위험 이력을 클릭하면 TSA로 이동하여 위험 추세 변화와 위험 이력 상세 정보를 확인할 수 있습니다. 필요에 따라 위험 등급과 시간 범위를 선택하여 더 상세한 추세 정보를 얻을 수 있습니다. 자세한 내용은 위험 추세 조회 및 위험 이력 상세 정보 조회를 참고하십시오.
도용 차단 버킷 조회
COS는 트래픽 도용 방지 기능을 지원하며, 시스템이 이상 트래픽을 지능적으로 감지해 이상 버킷을 자동으로 차단하고 알림을 보냅니다. 버킷이 트래픽 도용으로 인해 차단된 경우, 이 영역에서 버킷 이름, 소속 리전 및 차단 시간 등의 차단 기록 상세 정보를 확인할 수 있습니다.
버킷 이름: 차단된 버킷의 이름을 표시합니다.
소속 리전: 해당 버킷이 위치한 리전을 표시합니다.
차단 시간: 해당 버킷이 차단된 구체적인 시간을 표시합니다.
설명:
자동 차단 전에 비정상 트래픽으로 인해 고액 요금이 발생하는 것을 방지하려면 필요에 따라 보호 조치를 취하십시오. 자세한 내용은 도용 방지 가이드를 참고하십시오.
2. 이미지가 있는 버킷을 찾아서 스토리지 이름을 클릭하여 버킷 관리 페이지로 이동합니다.
3. 이미지 파일의 오른쪽 작업 열 아래에서 [세부 사항]을 클릭해 파일 세부 사항 페이지로 이동합니다.
4. [객체 주소]를 복사해 브라우저 창 주소창에 붙여 넣습니다.
주의：
처리 이미지는 객체의 쓰기 권한이 있어야 하며, 객체 권한 관련 설정은 객체의 액세스 권한 설정을 참고하십시오.
5. 주소창에서 다음 형식에 따라 객체 주소 뒤에 관련 매개변수를 추가합니다. 이미지 처리 매개변수 및 설명에 대한 자세한 내용은 CI 기초 이미지 처리 API 문서를 참고하십시오.
객체 주소?처리 인터페이스 이름/처리 작업 이름/처리 매개변수
주의：
이미지 파일의 액세스 권한이 개인 읽기일 경우, 서명이 있는 주소에 이미지 처리 매개변수를 추가해야 합니다.
예시: 이미지의 너비와 높이를 원본 이미지의 50%로 크기 조정
원본 이미지 효과가 다음과 같다고 가정했을 때 객체의 액세스 권한은 공개 읽기, 개인 쓰기이며 객체 주소 URL은 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/sample.jpeg입니다.
그 후, URL 링크에서 다음과 같이 매개변수를 추가합니다.
처리 인터페이스 크기 조정: imageMogr2
수정된 작업 이름: thumbnail
처리 매개변수: !50p
매개변수 추가 후 주소는 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/sample.jpeg?imageMogr2/thumbnail/!50p입니다. 이 주소를 주소창에 붙여넣고 Enter 키를 누르면 다음과 같이 축소 및 확대 후의 이미지 효과를 볼 수 있습니다.
이미지 양식 사용
이미지 양식 기능은 각각 다른 처리 작업 매개변수를 템플릿 형식으로 나타내게 해 양식을 통한 이미지에 통합 처리가 가능하게 합니다. 여기에 설정된 양식은 이미지 다운로드 시 실시간 처리 매개변수를 위해 조합된 템플릿입니다. 다음은 이미지 크기 조정 제한을 너비 480px, 높이 270px로 설정한 예시입니다. 작업 방법은 다음과 같습니다.
2. 이미지가 있는 버킷을 찾아서 스토리지 이름을 클릭하여 버킷 관리 페이지로 이동합니다.
3. 왼쪽 사이드바에서 [이미지 처리]를 클릭해 양식 관리 페이지로 이동합니다.
세퍼레이터: 양식 구분 기호인 세퍼레이터는 하이픈(-), 언더바(_), 슬래시(/), 느낌표(!) 등이 있으며 파일 이름 및 처리 양식을 기호로 구분합니다. 여기서는 느낌표(!)를 선택한 후 저장하겠습니다.
4. [양식 추가]를 클릭해 양식 추가 페이지로 들어가 다음과 같이 정보를 설정합니다.
-양식 이름: 사용자 정의 양식 이름을 입력합니다. 여기서는 예시로 yunstyle을 입력하겠습니다.
주의：
양식 이름은 대소문자를 구분하며, 저장 후 수정할 수 없습니다.
혼선을 방지하기 위해 처리 양식 이름에 현재 활성화된 간격 표시 부호는 사용할 수 없습니다.
편집 모드: 기본 편집 선택
압축 방식: 축소 및 확대만 선택
축소 및 확대 선택: 제한 너비와 높이, 축소 및 확대를 선택
압축 사이즈: 너비 480px, 높이 270px.
점진적 표시: 활성화돼 있을 경우, 이미지 액세스 시 점진적 표시 방식으로 보입니다. 여기에서는 저장 기본값을 비활성화로 설정합니다.
출력 포맷: 이미지 출력 포맷을 선택할 수 있습니다. 여기에서는 기본값으로 원본 이미지를 유지합니다.
5. 정보 설정 완료 후 오른쪽 미리 보기 버튼을 클릭해 미리 보기 효과를 조회할 수 있습니다.
6. 미리 보기에 오류가 없음을 확인한 후, [저장]을 클릭하면 yunstyle이라는 이미지 양식이 추가된 것을 볼 수 있습니다.
설명：
동일한 버킷 아래 최대 100개까지 양식을 설정할 수 있습니다.
설정 적용 시간은 평균 30분입니다.
세퍼레이터를 수정하려면 캐시를 퍼지해야 하며, 전체 네트워크로 적용하는데 24시간이 소요됩니다.
7. 객체 세부 사항 페이지에 들어가 객체 주소를 복사하고 다음 형식에 따라 객체 주소 뒤에 세퍼레이터 및 양식 이름을 추가합니다.
객체 주소 + 세퍼레이터 + 처리 양식 이름
마지막으로 얻은 객체 주소는 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/sample.jpeg!yunstyle입니다. 이 주소를 주소창에 붙여넣고 Enter 키를 누르면 다음과 같이 크기 조정 후의 이미지 효과를 볼 수 있습니다.
서명을 전달하기 위해 URL은 https://examplebucket-1250000000.cos.ap-chengdu.myqcloud.com/sample.jpeg!yunstyle?q-sign-algorithm=<signature>, 그리고 /sample.jpg!yunstyle을 리소스로 사용하여 <signature> 서명을 계산합니다.
이미지 고급 압축 설정
최종 업데이트 날짜:：2024-06-24 16:12:04
소개
이미지 고급 압축은 COS(Cloud Object Storage)가 CI를 기반으로 출시한 이미지 압축 기능입니다. 이미지 형식을 TPG 또는 HEIF의 압축 비율이 높은 형식으로 효율적으로 트랜스 코딩할 수 있어 이미지 전송 링크 및 로딩 시 소모되는 시간을 효과적으로 단축하고 대역폭 및 트래픽 비용을 절감할 수 있습니다.
설명：
이미지 고급 압축 기능으로 JPG, PNG, WEBP 등 형식의 이미지를 TPG, HEIF 형식으로 트랜스 코딩할 수 있습니다.
TPG는 Tencent가 자체 개발한 이미지 형식입니다. 사용할 경우 이미지 로딩 환경에서 TPG 디코딩을 지원하는지 확인하십시오. Tencent Cloud CI는 TPG 디코더를 통합한 iOS, Android, Windows 터미널 SDK를 제공하여 TPG에 빠르게 액세스하고 사용할 수 있습니다.
현재 iOS 11 이상 및 Android P 시스템은 기본적으로 HEIF 형식을 지원합니다.
이미지 고급 압축은 유료 서비스이며, CI 서비스에서 요금이 청구됩니다. 요금에 대한 자세한 내용은 CI의 가격 문서를 참고하십시오.
3. 작업이 필요한 버킷을 찾아 해당 버킷 이름을 클릭하여 해당 버킷 관리 페이지로 이동합니다.
4. 왼쪽 네비게이션 바에서 작업 및 워크플로우를 선택하고 작업 관리를 클릭하여 작업 관리 페이지로 이동합니다.
5. 작업 오른쪽에 있는 보기를 클릭하면 작업의 상세 정보를 확인할 수 있습니다.
설명:
작업 상태는 총 6가지입니다(실행 성공, 실행 실패, 실행 중, 미실행, 일시 중지, 취소됨).
최근 1개월간의 작업 기록만 조회할 수 있습니다.
함수 컴퓨팅
CDN 캐시 퍼지 설정
최종 업데이트 날짜:：2024-10-24 18:49:31
소개
CDN(Content Delivery Network) 캐시 퍼지는 Serverless Cloud Function(SCF)을 기반으로 하는 Tencent Cloud COS(Cloud Object Storage) 기능으로 사용자가 CDN 엣지 서버에 캐시된 데이터를 자동으로 퍼지할 수 있도록 합니다. 버킷에 트리거 규칙을 추가하면 버킷의 파일을 업데이트할 때 COS에서 프로비저닝한 SCF 기능이 자동으로 트리거되어 캐시된 데이터를 퍼지합니다.
주의：
COS 콘솔에서 버킷에 캐시 퍼지 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 CDN 캐시 퍼지 함수를 볼 수 있습니다. 이 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
이미 런칭된 SCF의 리전에서는 CDN 캐시 퍼지 기능을 지원합니다. 이에는 광저우, 상하이, 베이징, 청두, 중국홍콩, 싱가포르, 실리콘밸리 등이 포함되어 있으며, 지원하는 리전에 대한 자세한 내용은 SCF 제품 문서를 참고하십시오.
CDN 캐시 퍼지 기능은 네트워크 링크 불안정 등 실패를 일으킬 수 있습니다. 기능이 귀하의 기대에 부합하지 않을 경우, COS 콘솔에서 생성된 함수 오른쪽의 로그 조회를 클릭해 SCF 콘솔로 리디렉션한 후, 로그 오류 세부 사항 조회를 통해 오류 발생 원인을 진단할 수 있습니다.
CDN 캐시 퍼지 기능은 SCF 서비스에 종속돼 있습니다. SCF 서비스는 사용자에게 무료 한도를 제공하며, 무료 한도를 초과한 부분은 SCF Pricing에 따라 과금됩니다. CDN 캐시 퍼지 기능을 사용할 경우, 제거 횟수가 많을수록 더 많은 호출 횟수를 소모하게 됩니다.
2. 왼쪽 메뉴에서 버킷 리스트를 클릭한 후, CDN 캐시 퍼지 규칙 추가가 필요한 버킷을 선택 및 클릭해 버킷 관리 페이지로 이동합니다.
3. 왼쪽 메뉴에서 함수 계산 > CDN 캐시 퍼지 함수를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 라이선스를 완료하십시오.
4. 함수 추가를 클릭한 후, 팝업창에서 다음 정보를 설정합니다.
함수 이름: 함수 이름은 함수의 고유한 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 확인할 수 있습니다.
이벤트 유형: 이벤트는 SCF 트리거 작업을 의미합니다. 업로드 작업을 예로 들면, 업로드 방식은 PUT Object 인터페이스 호출일 수 있고, POST Object 인터페이스 호출일 수도 있습니다. 이벤트를 PUT 유형으로 선택할 경우, PUT Object 인터페이스를 통해서만 파일 업로드 작업이 SCF를 트리거하여 CDN 엣지 노드의 캐시를 퍼지할 수 있습니다.
트리거 조건: 트리거 이벤트의 파일 소스 범위(예: 전체 버킷 또는 지정된 접두사 또는 지정된 접미사)를 지정할 수 있습니다. 접두사 또는 접미사를 지정한 후, 규칙은 매칭된 파일 소스에만 적용됩니다.
도메인 지정: 제거가 필요한 CDN 도메인을 의미합니다.
SCF 라이선스: CDN 캐시 퍼지는 SCF에 CDN을 호출할 수 있는 PurgeUrlsCache 인터페이스 라이선스을 부여해야 합니다. 이 라이선스는 CDN이 COS로 Origin-pull하여 최신 데이터를 가져올 수 있도록, CDN 캐시 퍼지에서 데이터를 삭제하는 데 쓰입니다.
5. 설정을 추가한 후 확인을 클릭하면 추가된 함수를 확인할 수 있습니다.
CDN 캐시 퍼지 기록을 보려면 로그를 클릭합니다.
필요 없는 CDN 캐시 퍼지 규칙을 삭제하려면 삭제를 클릭합니다.
스마트 툴 박스 사용 가이드
최종 업데이트 날짜:：2024-06-24 16:12:04
소개
스마트 툴박스는 이미지 워터마크, 이미지 압축, 오디오/비디오/파일 형식 변환 등 거의 모든 유형의 멀티미디어 파일을 처리할 수 있는 도구를 제공합니다. Cloud Object Storage(COS)의 다양한 기능을 쉽고 빠르게 콘솔에서 사용할 수 있도록 편리하고 빠른 도구 형태로 제공합니다.
주의 사항
스마트 툴박스의 모든 기능은 COS의 데이터 처리 API를 기반으로 구현되며 이를 사용하는 것은 해당 API를 호출하는 것과 같습니다. 사용하는 동안 다음 사항에 유의해야 합니다.
스마트 툴 박스 사용을 시작할 때 Cloud Infinite(CI) 서비스가 무료로 활성화됩니다.
툴박스를 통해 처리 작업이 완료될 때마다 데이터 처리 API를 한 번 호출하는 것과 같으며 아래와 같이 처리 요금이 발생합니다.
툴
요금
이미지 압축(WebP 또는 JPEG 형식), 이미지 편집, 이미지 워터마크 및 이미지 정보
4. 이미지가 추가되면 툴이 자동으로 처리하며 왼쪽에서 압축된 이미지의 크기를 볼 수 있습니다. 다운로드 버튼을 통해 압축된 이미지를 다운로드할 수도 있습니다.
2. 이미지 편집
이미지 편집 툴은 이미지 자르기, 회전, 크기 조정, 선명하게 하기, 밝기 조정 및 대비 조정 기능을 제공합니다.
작업 순서
이미지 압축 섹션의 1 - 3단계에 설명된 대로 이미지를 추가한 후 왼쪽에 있는 툴을 사용하여 해당 조정을 수행합니다.
3. 이미지 워터마크
이미지 워터마크 툴을 사용하면 이미지나 텍스트를 워터마크 형태로 다른 이미지에 추가할 수 있습니다.
작업 순서
이미지 워터마크: 이미지 압축 섹션의 1 - 3단계에 따라 이미지를 추가한 후 왼쪽에서 이미지 워터마크를 클릭하고 버킷에서 기존 이미지를 선택하고 여백을 조정한 다음 워터마크 생성을 클릭합니다.
텍스트 워터마크: 왼쪽의 텍스트 워터마크를 클릭하고 워터마크 텍스트를 입력하고 여백, 글꼴, 글꼴 크기를 조정하고 워터마크 생성을 클릭합니다.
4. 이미지 정보
이미지 정보 툴은 이미지의 형식, 크기 및 MD5 정보를 나열합니다.
작업 순서
이미지를 추가한 후 왼쪽의 정보를 클릭하면 해당 이미지의 정보를 볼 수 있습니다.
오디오/비디오 프로세싱
1. 오디오/비디오 형식 변환
오디오/비디오 형식 변환 툴은 오디오/비디오 파일을 MP4, MP3, MOV, AVI, MKV 및 기타 형식으로 변환할 수 있습니다. 이를 통해 변환하는 동안 비디오 해상도 및 오디오 비트 레이트와 같은 다양한 매개변수를 설정하여 다양한 터미널 및 네트워크 환경에 적응할 수 있습니다.
이미지 태그 툴은 이미지에서 장면, 사물, 사람 및 기타 정보를 식별할 수 있습니다. 자연 경관(산, 바다, 하늘, 일몰 등), 인공 환경(건물, 운동장, 회의실 등), 사람(남성, 여성, 셀카, 단체 사진 등), 사물(음식, 의복, 생필품 등), 애완동물/야생 동물(고양이, 개, 새, 포유류, 해양 동물 등) 등 8개 카테고리의 60개 이상의 서브 카테고리에 수천 개의 태그가 포함되어 있습니다.
4. PPT 파일이 추가되면 툴이 자동으로 처리를 시작하여 온라인 미리 보기용 HTML 웹 페이지를 생성합니다. 직접 미리 보거나 링크를 복사하여 브라우저에서 미리 볼 수 있습니다.
데이터 워크플로
사용자 정의 함수 처리
최종 업데이트 날짜:：2024-06-24 16:23:48
소개
Cloud Object Storage(COS) 미디어 처리의 서비스나 기능이 사용자의 요구를 충족시킬 수 없는 경우, Serverless Cloud Function(SCF)을 사용하여 함수 처리 기능을 사용자 정의하고 가장 핵심적인 코드 로직을 작성하여 비즈니스 요구를 유연하게 충족하고 R&D 비용을 절감할 수 있습니다. SCF에 대한 자세한 내용은 SCF 문서를 참고하십시오.
4. 왼쪽 사이드바에서 데이터 워크플로 > 워크플로를 클릭하여 워크플로 관리 페이지로 이동합니다.
5. 워크플로 생성을 클릭합니다.
6. ‘워크플로 설정’ 오른쪽에 있는 ‘+’를 클릭하여 사용자 정의 기능 노드를 추가합니다.
7. 팝업 창에서 다음과 같이 정보를 설정합니다.
입력 매개변수: 워크플로에서 사용자 지정 함수로 지정된 입력 매개변수는 수동으로 추가할 필요가 없습니다. 대신 사용자 정의 함수 앞의 노드에 따라 얻을 수 있습니다.
함수 Namespace: 생성된 함수는 기본적으로 COS 네임스페이스에 위치합니다.
함수 분류: 일반 기능을 선택하여 COS 객체에 대한 일반적인 작업을 빠르게 수행하거나, 다른 기능 관련 매개변수를 사용자 정의할 수 있습니다.
기능 유형: 일반 기능 선택 시 프리셋 기능을 지원합니다.
함수 선택: 현재 워크플로에서는 비동기 실행을 지원하고 상태 추적을 활성화하는 기능만 지원합니다.
함수를 생성하려면 ‘함수 생성’을 클릭하고 메시지에 따라 함수를 구성합니다.
8. 설정이 올바른지 확인하고 확인을 클릭합니다.
워크플로 설정
최종 업데이트 날짜:：2025-11-20 15:27:40
소개
데이터 처리 워크플로를 사용하면 필요에 따라 비디오 처리 프로세스를 빠르고 유연하게 생성할 수 있습니다. 워크플로는 입력 버킷의 경로에 바인딩됩니다. 비디오 파일이 경로에 업로드되면 미디어 워크플로가 자동으로 트리거되어 지정된 처리 작업을 수행하고 처리 결과는 대상 버킷의 지정된 경로에 자동으로 저장됩니다.
데이터 처리 워크플로를 사용하여 다음 기능을 구현할 수 있습니다. 오디오/비디오 트랜스코딩(최고 속도 코덱 및 방송 미디어 형식 트랜스코딩 포함), 비디오 프레임 캡처, 비디오를 애니메이션 이미지로 변환, 지능형 썸네일, 오디오/비디오 스플라이싱, 음성 분리, 하이라이트 생성, HLS 어댑티브 멀티 비트레이트, SDRtoHDR, 비디오 향상, 초고해상도, 오디오/비디오 세그먼트화, 사용자 지정 함수 및 이미지 프로세싱 등.
주의：
현재 워크플로는 3gp, asf, avi, dv, flv, f4v, m3u8, m4v, mkv, mov, mp4, mpg, mpeg, mts, ogg, rm, rmvb, swf, vob, wmv, webm, mp3, aac, flac, amr, m4a, wma 및 wav 파일을 처리할 수 있습니다. 미디어 처리 요청을 시작할 때 전체 파일 이름과 확장자를 입력해야 합니다. 그렇지 않으면 형식을 인식하고 처리할 수 없습니다.
현재 워크플로 기능은 업로드 중인 비디오 파일만 작업할 수 있습니다. 클라우드 데이터에 대한 미디어 작업을 수행하려면 작업 기능을 사용하십시오.
4. 왼쪽 사이드바에서 데이터 처리 워크플로를 선택하고 워크플로를 클릭하여 워크플로 관리 페이지로 이동합니다.
5. 워크플로 생성을 클릭합니다.
6. 워크플로 생성 페이지에서 다음 항목을 구성합니다.
워크플로 이름: 필수 항목이며 최대 128자의 중국어 영어 대소문자[A-Z,a-z], 숫자[0-9], 언더바(_) 및 하이픈(-)을 포함할 수 있습니다.
입력 버킷 이름: 기본적으로 현재 버킷입니다.
입력 경로: 선택 사항이며 /로 시작하고 끝나야 합니다. 지정하지 않으면 입력 버킷의 모든 경로에 대해 워크플로가 트리거됩니다. 미디어 워크플로가 활성화된 후 비디오 파일이 이 경로에 업로드되면 워크플로가 자동으로 트리거됩니다.
형식: 기본 오디오/비디오 또는 이미지 파일 필터 규칙 또는 사용자 지정 규칙을 선택합니다. 모든 파일을 선택하여 버킷의 모든 객체를 처리할 수도 있습니다.
큐: 필수입니다. 서비스를 활성화하면 시스템이 자동으로 사용자 큐를 생성합니다. 작업을 제출하면 작업이 큐에 먼저 정렬되고 제출 우선 순위와 순서에 따라 순서대로 실행됩니다. 공통 구성에서 큐 정보를 볼 수 있습니다.
콜백: 큐 콜백, 즉 큐에 바인딩된 콜백 URL을 사용할 수 있습니다. 수정하려면 해당 큐 목록으로 이동하십시오.
워크플로 구성: 오른쪽에서 ‘+’를 클릭하여 다음 노드를 추가합니다. 오디오/비디오 트랜스코딩(최고 속도 코덱 및 방송 미디어 형식 트랜스코딩 포함), 비디오 프레임 캡처, 비디오를 애니메이션 이미지로 변환, 지능형 썸네일, 오디오/비디오 스플라이싱, 음성 분리, 하이라이트 생성, HLS 어댑티브 멀티 비트레이트, SDRtoHDR, 비디오 향상, 초고해상도, 오디오/비디오 세그먼트화, 사용자 지정 함수 및 이미지 프로세싱. 워크플로우에서 하나 이상의 작업 노드를 구성하고 각 작업 노드에 대한 대상 버킷, 파일 이름(워크플로 변수 설명 참고), 경로 및 작업 템플릿을 설정해야 합니다. 템플릿 및 설정 방법에 대한 자세한 내용은 템플릿을 참고하십시오.
오디오/비디오 트랜스코딩
비디오 프레임 캡처
비디오를 애니메이션 이미지로 변환
지능형 썸네일
설명: 지능형 썸네일 기능은 Tencent Cloud의 고급 AI 기술을 통해 비디오 콘텐츠를 이해하여 3개의 최적 키프레임을 지능적으로 추출합니다.
오디오/비디오 스플라이싱
음성 분리
하이라이트 생성
HLS 어댑티브 멀티 비트레이트
설명: HLS 어댑티브 멀티 비트레이트 기능은 멀티 비트레이트 및 오디오 트랙이 포함된 여러 파일을 하나의 멀티 비트레이트 어댑티브 HLS 또는 DASH 비디오 파일로 캡슐화합니다.
SDRtoHDR
7. 구성이 올바른지 확인한 후 저장을 클릭합니다.
워크플로는 기본적으로 비활성화되어 있습니다. 워크플로를 활성화하려면 활성화 열에서 토글을 클릭합니다. 활성화되면 워크플로우는 5분 안에 적용됩니다. 그런 다음 이후에 업로드된 비디오 파일에 대해 미디어 처리 작업을 자동으로 수행합니다. 파일을 처리한 후 새로 생성된 파일을 지정된 파일 경로로 출력합니다.
워크플로 관리
생성된 워크플로 목록은 워크플로 관리 페이지에서 확인할 수 있습니다.
워크플로 목록에는 워크플로의 이름, 워크플로 ID, 입력 경로, 생성 시간 및 상태가 표시됩니다. 이름 및 ID로 워크플로를 검색하여 지정된 워크플로를 보거나 편집 또는 삭제할 수 있습니다.
활성화: 워크플로가 활성화되면 입력 버킷의 지정된 경로에 업로드된 비디오 파일이 워크플로 구성에 따라 자동으로 처리됩니다. 토글을 다시 클릭하여 워크플로를 일시 중지할 수 있습니다.
설명：
워크플로는 기본적으로 비활성화되어 있습니다. 워크플로를 활성화하려면 활성화 열에서 토글을 클릭합니다. 활성화되면 워크플로우는 5분 안에 적용됩니다.
세부 정보: 현재 워크플로의 구성 세부 정보를 볼 수 있습니다.
실행 인스턴스 보기: 워크플로 실행 상태 및 시간을 시간별로 볼 수 있습니다.
더보기:
작업 열에서 더보기 > 편집을 클릭하여 워크플로 구성을 수정할 수 있는 ‘워크플로 편집’ 페이지로 이동합니다.
작업 열에서 더보기 > 삭제를 클릭하여 워크플로를 삭제합니다.
주의：
활성화된 워크플로는 편집하거나 삭제할 수 없습니다.
실행 인스턴스 보기
각 비디오 파일에 대해 워크플로우가 실행된 후 실행 인스턴스가 생성됩니다. 실행 인스턴스 페이지에는 소스 파일 주소, 워크플로 실행 상태 및 실행 시간이 표시됩니다.
1. 워크플로 관리 페이지로 이동하여 대상 워크플로의 작업 열에서 실행 인스턴스 보기를 클릭하여 실행 인스턴스 목록 페이지로 들어갑니다.
2. 목록 페이지에서 대상 인스턴스의 작업 열에 있는 세부 정보를 클릭하여 인스턴스 세부 정보 페이지로 들어갑니다.
3. 인스턴스 세부 정보 페이지에서 각 워크플로 노드의 작업 ID, 실행 상태, 시작 시간 및 종료 시간을 볼 수 있습니다.
워크플로 트리거
워크플로가 생성된 후 지정된 버킷에 업로드된 파일에 대해 자동으로 트리거되거나 버킷의 기존 파일에 대해 수동으로 트리거될 수 있습니다.
1. 워크플로 관리 페이지에서 대상 워크플로의 더보기 > 실행 인스턴스 생성을 클릭합니다.
2. 실행 인스턴스 생성 페이지에서 워크플로를 트리거할 파일을 선택하고 저장을 클릭하여 워크플로를 즉시 트리거하고 실행합니다.
실행 인스턴스 페이지에서 워크플로 실행 상태를 볼 수 있습니다.
워크플로 변수 설명
워크플로는 다음 변수를 사용하여 렌더링 대상 파일 이름 및 URL을 지원합니다.
변수 이름
설명
InputName
입력 파일의 파일 이름(파일 확장자 없음)
InputNameAndExt
입력 파일의 파일 이름(파일 확장자 포함)
InputPath
파일 입력 경로
RunId
실행 인스턴스 ID
Ext
대상 파일 형식
Number
대상 파일 번호
예시
입력 파일의 이름이 test1.mp4 및 test2.mp4이고 이를 FLV 형식으로 변환하려는 경우(최종 파일 이름은 test1.flv 및 test2.flv) 대상 파일 이름의 매개 변수 형식을 ${InputName}.${Ext}로 설정합니다.
대상 파일 이름의 매개 변수 형식이 ${InputNameAndExt}_${RunId}.${Ext}로 설정된 경우.
워크플로가 실행 중에 두 개의 인스턴스(000001 및 000002)를 생성하면 최종 파일 이름은 test1.mp4_000001.flv 및 test2.mp4_000002.flv가 됩니다.
작업 구성
최종 업데이트 날짜:：2025-11-20 13:05:21
소개
버킷에 이미 있는 파일의 경우 미디어 처리, 음성 인식, 파일 처리 및 기타 작업을 위한 작업을 생성할 수 있습니다. 현재 지원되는 작업은 오디오/비디오 트랜스 코딩, 초고속 고화질 트랜스 코딩, 방송 미디어 형식 트랜스 코딩, 하이라이트 생성, 음성 분리, 오디오/비디오 스플라이싱, 비디오 향상, 오디오/비디오 분할, 초고해상도, SDR to HDR, 비디오 프레임 캡처, 비디오를 애니메이션 이미지로 변환, 스마트 썸네일, 디지털 워터마크 추출, 이미지 처리, TTS, 음성 인식 및 파일 미리보기입니다. 이 중 일부는 템플릿으로 생성할 수 있습니다. 시스템 템플릿을 사용하거나 템플릿을 사용자 정의할 수 있습니다. 자세한 내용은 Template을 참고하십시오.
설명：
현재 작업은 3gp, asf, avi, dv, flv, f4v, m3u8, m4v, mkv, mov, mp4, mpg, mpeg, mts, ogg, rm, rmvb, swf, vob, wmv, webm, mp3, aac, flac, amr, m4a, wma 및 wav 파일을 처리할 수 있습니다. 미디어 처리 요청을 시작할 때 전체 파일 이름과 확장자를 입력해야 합니다. 그렇지 않으면 형식을 인식하고 처리할 수 없습니다.
현재 작업 기능은 기존 파일만 작업할 수 있습니다. 업로드 중에 파일을 작업하려면 Workflow 기능을 사용하십시오.
작업이 생성된 후 기능 비용은 CI에서 과금됩니다. 과금 세부사항은 미디어 처리 요금을 참고하십시오.
작업 보기
작업 페이지에서 지정된 기간 동안 다른 유형의 모든 작업을 보고, 작업 상태를 클릭하여 다른 상태의 작업을 필터링 및 볼 수 있으며, 검색 상자에서 작업 ID로 작업을 검색할 수 있습니다.
비디오 프레임 캡처는 지정된 시점에서 비디오 프레임을 캡처하기 위해 CI에서 제공하는 화면 캡처 기능입니다. 콘솔에서 작업을 활성화한 후 출력 스크린샷은 기본적으로 JPG 형식입니다. 캡처된 프레임 압축을 활성화하면 스크린샷을 HEIF 또는 TPG 형식으로 출력할 수 있습니다.
설명：
비디오 프레임 캡처 작업은 템플릿으로 생성할 수 있습니다. 사용자 정의 비디오 프레임 캡처 템플릿에서 프레임 캡처 시작 시간, 프레임 캡처 간격, 캡처된 프레임, 출력 이미지 크기 및 출력 형식(캡처된 프레임 압축을 활성화해야 함)을 사용자 정의할 수 있습니다.
4. 왼쪽 사이드바에서 데이터 처리 워크플로를 선택하고 작업을 클릭하여 작업 관리 페이지로 들어갑니다.
5. 미디어 처리 탭을 선택하고 작업 유형으로 트랜스 코딩 > 비디오 프레임 캡처를 선택하고 작업 생성을 클릭하고 다음과 같이 구성합니다.
연결 파일 URL: 원본 파일 경로를 입력합니다. / 로 시작하거나 끝날 수 없습니다.
템플릿 유형: 시스템 또는 사용자 정의 템플릿을 선택합니다. 자세한 내용은 Template을 참고하십시오.
템플릿: 지정된 템플릿을 선택합니다.
출력: 콘솔에서 비디오 프레임 캡처 작업이 활성화된 경우 기본적으로 JPG 형식의 스크린샷이 출력됩니다. 템플릿에서 캡처된 프레임 압축이 활성화된 경우 HEIF 또는 TPG 형식의 스크린샷을 출력할 수 있습니다. 비디오 프레임 캡처 API를 사용하는 경우 JPG 또는 PNG 스크린샷을 출력하도록 선택할 수 있습니다. 자세한 내용은 Getting Media File Screenshot API 설명서를 참고하십시오.
대상 버킷: 현재 리전에서 미디어 처리 기능이 활성화된 버킷을 선택합니다.
대상 경로: 비디오 스크린샷의 저장 경로입니다.
대상 파일 이름: 출력 파일의 이름입니다. 비디오 프레임 캡처로 둘 이상의 파일이 출력되므로 출력 파일 이름에는 스크린샷의 시퀀스 번호로 ${Number} 매개변수가 포함되어야 합니다. 예를 들어 대상 파일 경로가 test-${Number}.jpg로 설정되고 작업이 두 개의 스크린샷을 캡처하는 경우 출력 파일의 실제 이름은 test-0.jpg 및 test-1.jpg가 됩니다.
4. 왼쪽 사이드바에서 데이터 처리 워크플로를 선택하고 작업을 클릭하여 작업 관리 페이지로 들어갑니다.
5. 미디어 처리 탭을 선택하고 이미지 품질 최적화 > SDRtoHDR을 작업 유형으로 선택하고 작업 생성을 클릭하고 다음과 같이 구성합니다.
설명：
입력 비디오는 30분 미만이어야 합니다.
연결 파일 URL: 원본 파일 경로를 입력합니다. / 로 시작하거나 끝날 수 없습니다.
HDR 표준: HLG 또는 HDR10을 선택합니다.
트랜스 코딩 템플릿: H.265 트랜스 코딩 템플릿을 선택합니다. 템플릿이 없으면 오디오/비디오 트랜스 코딩 템플릿을 만들고 인코딩 형식으로 H.265를 선택합니다. 템플릿을 만들고 매개변수를 구성하는 방법에 대한 자세한 내용은 사용자 정의 Template을 참고하십시오.
비디오를 애니메이션 이미지로 변환 기능을 사용하여 비디오를 애니메이션 이미지로 변환할 수 있습니다.
설명：
동영상을 애니메이션 이미지로 변환하는 작업은 템플릿으로 만들 수 있습니다. 트랜스 코딩 시작 시간, 트랜스 코딩 기간, 프레임 추출 방법, 출력 애니메이션 이미지 프레임 속도 및 출력 애니메이션 이미지 크기를 사용자 정의 비디오에서 애니메이션 이미지로 변환 템플릿으로 사용자 정의할 수 있습니다.
4. 왼쪽 사이드바에서 데이터 처리 워크플로를 선택하고 작업을 클릭하여 작업 관리 페이지로 들어갑니다.
5. 미디어 처리 탭을 선택하고 지능형 편집 > 스마트 썸네일을 작업 유형으로 선택하고 작업 생성을 클릭하고 다음과 같이 구성합니다.
연결 파일 URL: 원본 파일 경로를 입력합니다. / 로 시작하거나 끝날 수 없습니다.
대상 버킷: 현재 리전에서 미디어 처리 기능이 활성화된 버킷을 선택합니다.
대상 경로: 스마트 썸네일의 저장 경로입니다.
대상 파일 이름: 출력 파일의 이름입니다.
주의：
스마트 썸네일로 두 개 이상의 파일이 출력되므로 출력 파일 이름에는 썸네일 일련 번호로 매개변수 ${Number}가 포함되어야 합니다. 예를 들어 출력 파일 경로가 test-${Number}.jpg로 설정된 경우 출력 파일의 실제 이름은 test-0.jpg 및 test-1.jpg가 됩니다.
파일 미리보기 기능을 사용하면 원본 파일 스타일을 최대한 유지하면서 이미지 또는 HTML을 통해 거의 30가지 유형의 파일을 온라인으로 미리 볼 수 있습니다. 이것은 다른 장치에서 특정 파일 형식에 대한 지원 부족을 해결하고 PC, App 및 기타 터미널에서 온라인 파일 미리보기를 가능하게 합니다.
4. 왼쪽 사이드바에서 데이터 처리 워크플로를 선택하고 작업을 클릭하여 작업 관리 페이지로 들어갑니다.
5. 파일 미리 보기 탭을 선택하고 작업 생성을 클릭하고 다음과 같이 구성합니다.
원본 파일 URL: / 로 시작하거나 끝날 수 없습니다. 예시: doc/example.doc.
미리보기 설정: 전체 문서 또는 지정된 페이지를 미리 보려면 선택합니다. 작업은 최대 5000페이지를 지원합니다. 더 많은 페이지를 입력할 경우 처음 5000페이지만 변환할 수 있습니다.
출력 형식: 현재 JPG 및 PNG 형식이 출력 이미지에 지원됩니다. PDF 형식은 전체 문서 미리보기에서만 지원됩니다.
대상 버킷: 현재 지역에서 파일 미리보기 기능이 활성화된 버킷을 선택합니다.
대상 경로: 선택 사항입니다. 설정하지 않으면 입력 파일 경로와 동일합니다.
대상 파일 이름: 파일 미리보기 기능은 원본 파일의 각 페이지를 이미지로 변환합니다. 따라서 출력 이미지에 번호를 지정하려면 출력 파일 이름에 자리 표시자(${Number} 또는 ${Page})를 추가해야 합니다. 출력 번호는 파일 페이지 번호와 동일합니다. 예를 들어 세 페이지의 파일을 미리 보고 출력 파일 이름을 output${Number}.jpg로 설정하려는 경우 세 개의 이미지 output1.jpg, output2.jpg, output3.jpg가 출력됩니다.
큐: 현재 기본 파일 미리 보기 큐 queue-doc-process-1만 지원됩니다. 자세한 내용은 Queues and Callbacks를 참고하십시오.
이미지 처리 기능은 회전, 자르기, 코드 변환 및 확대/축소와 같은 유연한 이미지 편집을 지원합니다. Guetzli 압축, TPG 트랜스 코딩, HEIF 트랜스 코딩과 같은 다양한 이미지 다운사이징 솔루션과 이미지/텍스트/블라인드 워터마킹과 같은 다양한 저작권 보호 솔루션을 제공합니다. 이는 다양한 비즈니스 시나리오에서 이미지 처리 요구 사항을 충족합니다.
데이터 처리 워크플로 기능을 사용할 때 일반적으로 템플릿을 통해 결합할 수 있는 일련의 매개변수를 설정해야 합니다. 이는 작업을 단순화하고 반복적으로 입력할 필요 없이 구성된 매개변수를 재사용할 수 있도록 합니다.
오디오/비디오 트랜스 코딩, 오디오/비디오 스플라이싱, 비디오 프레임 캡처 및 비디오를 애니메이션 이미지로 변환과 같은 미디어 처리 기능의 경우 작업 또는 워크플로를 생성할 때 템플릿을 지정해야 합니다. 템플릿 페이지는 시스템 템플릿을 제공하며 비즈니스 요구 사항에 따라 템플릿을 사용자 정의할 수도 있습니다.
시스템 템플릿
시스템은 공통 매개변수를 시스템 템플릿에 사전 결합하므로 직접 사용할 수 있습니다. 작업 또는 워크플로를 생성할 때 템플릿 이름으로 이러한 템플릿을 선택할 수 있습니다.
4. 왼쪽 사이드바에서 데이터 처리 워크플로 > 템플릿 구성을 선택하여 다양한 처리 유형의 템플릿을 볼 수 있습니다.
‘작업’ 열에서 보기를 클릭하여 템플릿 세부 정보를 봅니다.
설명：
현재 시스템은 15개의 오디오/비디오 트랜스 코딩, 3개의 비디오 프레임 캡처, 18개의 비디오를 애니메이션 이미지로 변환 템플릿을 제공합니다.
시스템 템플릿의 정보를 볼 수는 있지만 편집하거나 삭제할 수는 없습니다.
오디오/비디오 트랜스 코딩을 위한 시스템 템플릿
템플릿 ID
템플릿 이름
컨테이너 형식
비디오 인코딩 형식
해상도
비디오 비트 레이트
오디오 인코딩 형식
오디오 비트 레이트
t0e2b9f4cd25184c6ab73d0c85a6ee9cb5
H264-MP4-LD-360P
MP4
H.264
640 * 자동 크기 조정
512 Kbps
AAC
128 Kbps
t0876739cd865042d1957d73c78f0484fb
H264-MP4-SD-480P
MP4
H.264
720 * 자동 크기 조정
1024 Kbps
AAC
128 Kbps
t0852e7ff4acd4484e99ba104f3840d3cb
H264-MP4-HD-720P
MP4
H.264
1280 * 자동 크기 조정
2000 Kbps
AAC
128 Kbps
t04df9eb0c373c4a8780ec894ce05469a7
H264-MP4-FHD-1080P
MP4
H.264
1920 * 자동 크기 조정
3500 Kbps
AAC
128 Kbps
t09d027135634d47048e5a30dc1e19ee90
H264-MP4-2K
MP4
H.264
2048 * 자동 크기 조정
4800 Kbps
AAC
128 Kbps
t0e634622e8dfb49339ba478d60ddc7188
H264-HLS-LD-360P
M3U8
H.264
640 * 자동 크기 조정
512 Kbps
AAC
128 Kbps
t0fa5bdbf58bb348e88bf73fae5d674fdf
H264-HLS-SD-480P
M3U8
H.264
720 * 자동 크기 조정
1024 Kbps
AAC
128 Kbps
t09d0f419921e44ed98190f355ec9fd629
H264-HLS-HD-720P
M3U8
H.264
1280 * 자동 크기 조정
2000 Kbps
AAC
128 Kbps
t080ae8a06f9074f3daa46201078f8d4b1
H264-HLS-FHD-1080P
M3U8
H.264
1920 * 자동 크기 조정
3500 Kbps
AAC
128 Kbps
t0ab68939cef0f40d19c4a135df540239f
H264-HLS-2K
M3U8
H.264
2048 * 자동 크기 조정
4800 Kbps
AAC
128 Kbps
t0e165bef65ed24d568eeecc8661248af6
H264-FLV-LD-360P
M3U8
H.264
640 * 자동 크기 조정
512 Kbps
AAC
128 Kbps
t057d0410c32444e48b9220f9571e6097a
H264-FLV-SD-480P
M3U8
H.264
720 * 자동 크기 조정
1024 Kbps
AAC
128 Kbps
t00daf332ba39049f8bfb899c1ed0134b0
H264-FLV-HD-720P
M3U8
H.264
1280 * 자동 크기 조정
2000 Kbps
AAC
128 Kbps
t0d41905a814434c8a81897ecb54d53a32
H264-FLV-FHD-1080P
M3U8
H.264
1920 * 자동 크기 조정
3500 Kbps
AAC
128 Kbps
t0e287e59454b94a8983ba78a6a30ee864
H264-FLV-2K
M3U8
H.264
2048 * 자동 크기 조정
4800 Kbps
AAC
128 Kbps
비디오 프레임 캡처를 위한 시스템 템플릿
템플릿 ID
템플릿 이름
프레임 캡처 시작 시간
프레임 캡처 간격
비디오 출력당 최대 프레임 수
출력 이미지 크기
출력 형식
t01d40e440761448fc8c538fb8d5a5b81e
snapshot_320 * 180_1
0s
2s
5
320px * 180px
JPEG
t0a60a2bc71a4b40c7b3d7f7e8a2779a81
snapshot_640 * 360_2
0s
10s
5
640px * 360px
JPEG
t07740e32081b44ad7a0aea03adcffd54a
snapshot_1280 * 720_3
0s
10s
5
1280px * 720px
JPEG
비디오를 애니메이션 이미지로 변환하기 위한 시스템 템플릿
템플릿 ID
템플릿 이름
트랜스 코딩 시작 시간
트랜스 코딩 지속 시간
프레임 추출 방법
애니메이션 이미지 프레임 레이트 출력
출력 애니메이션 이미지 크기
출력 형식
출력 애니메이션 화질
t04373959a69c04d47b62fd214dd13d8e9
gif_320 * 180_1
0s
600s
키 프레임만 추출
적응형
320px * 180px
GIF
\
t0341b0ab2b8a340ff826e9cb4f3a7baea
gif_320 * 180_2
0s
600s
10초마다 한 프레임씩 추출
적응형(0.10 FPS)
320px * 180px
GIF
\
t046b1d8e5bdf842c6a58d8028b48eafee
gif_320 * 180_3
0s
600s
초당 10프레임 추출
적응형(10 FPS)
320px * 180px
GIF
\
t0ef2077f215864c018a2fca73614ceca6
gif_640 * 360_4
0s
600s
키프레임만 추출
적응형
640px * 360px
GIF
\
t0d21406ca737a40869973a37a5daa349a
gif_640 * 360_5
0s
600s
10초마다 한 프레임씩 추출
적응형(0.10 FPS)
640px * 360px
GIF
\
t0878a9c9c1f054cb5bca68b8b06e556c2
gif_640 * 360_6
0s
600s
초당 10프레임 추출
적응형(10 FPS)
640px * 360px
GIF
\
t0dae821708cea4ba5b3e271810ac80a21
gif_1280 * 720_7
0s
600s
키프레임만 추출
적응형
1280px * 720px
GIF
\
t03fef67ad94d2466b9c0c89252ed72e87
gif_1280 * 720_8
0s
600s
10초마다 한 프레임씩 추출
적응형(0.10 FPS)
1280px * 720px
GIF
\
t030a64e9f9f5a4f53a9ef64bb7ce490b5
gif_1280 * 720_9
0s
600s
초당 10프레임 추출
적응형(10 FPS)
1280px * 720px
GIF
\
t03b0e9eca4fc34e2cba9da89d9c7c13a2
webp_320 * 180_1
0s
60s
키프레임만 추출
적응형
320px * 180px
WEBP
75
t016fcddf6bc3c44b793e9b7b07119b4ee
webp_320 * 180_2
0s
600s
10초마다 한 프레임씩 추출
적응형(0.10 FPS)
320px * 180px
WEBP
75
t0bf1f1ce6d2404b258c0f81fbb9aaece1
webp_320 * 180_3
0s
600s
10초마다 한 프레임씩 추출
적응형(10 FPS)
320px * 180px
WEBP
75
t098d6d3fcfd2c45309a408594a42559f6
webp_640 * 360_4
0s
60s
키프레임만 추출
적응형
640px * 360px
WEBP
75
t0169a6a9c2eec4b51972eb63bafcbf08d
webp_640 * 360_5
0s
600s
10초마다 한 프레임씩 추출
적응형(0.10 FPS)
640px * 360px
WEBP
75
t0ef9ba537011e4876b8777aebc19d10a5
webp_640 * 360_6
0s
600s
10초마다 한 프레임씩 추출
적응형(10 FPS)
640px * 360px
WEBP
75
t02743d344b5e74c579e50e9e135b432b8
webp_1280 * 720_7
0s
60s
키프레임만 추출
적응형
1280px * 720px
WEBP
75
t0dd27c136ff2741538bec96981e058868
webp_1280 * 720_8
0s
600s
10초마다 한 프레임씩 추출
적응형(0.10 FPS)
1280px * 720px
WEBP
75
t00ad05235d67a45a9a697b553052b7346
webp_1280 * 720_9
0s
600s
10초마다 한 프레임씩 추출
적응형(10 FPS)
1280px * 720px
WEBP
75
사용자 정의 템플릿
시스템 템플릿이 요구 사항을 충족할 수 없는 경우 사용자 정의 템플릿을 사용하십시오. 현재 오디오/비디오 트랜스 코딩, 초고속 고화질 트랜스 코딩, 하이라이트 생성, 비디오 프레임 캡처, 비디오를 애니메이션 이미지로 변환, 비디오 워터마크, 오디오/비디오 스플라이싱, 음성 분리, 비디오 향상, 초고해상도, 이미지 처리 및 브로드캐스트 미디어 형식 트랜스 코딩에 대한 사용자 정의 템플릿을 만들 수 있습니다.
오디오/비디오 트랜스코딩
오디오/비디오 트랜스 코딩 기능은 오디오/비디오 파일 비트스트림을 변환합니다. 코덱, 해상도 및 비트 레이트와 같은 소스 비트스트림의 매개변수를 변경하여 다양한 장치 및 네트워크 조건에 적응합니다. 사용자 정의 오디오/비디오 트랜스 코딩 템플릿에서 템플릿 매개변수를 사용자 정의할 수 있습니다.
초고속 고화질 트랜스 코딩 기능은 낮은 비트 레이트에서 비디오의 주관적인 화질을 향상시킵니다. 일반 오디오/비디오 트랜스 코딩과 비교하여 더 작은 파일과 더 선명한 비디오 이미지를 출력하고 낮은 네트워크 리소스 사용량을 보장하여 더 나은 시각적 경험을 제공합니다. 사용자 정의 초고속 고화질 트랜스 코딩 템플릿에서 코덱, 해상도 및 비트 레이트와 같은 매개변수를 사용자 정의할 수 있습니다.
비디오 프레임 캡처 기능은 지정된 시점의 비디오 프레임을 캡처합니다. 출력 스크린샷은 기본적으로 JPG 형식입니다. 캡처된 프레임 압축을 활성화하면 스크린샷을 HEIF 또는 TPG 형식으로 출력할 수 있습니다. 사용자 정의 비디오 프레임 캡처 템플릿에서 템플릿 이름, 프레임 캡처 시작 시간, 프레임 캡처 간격, 캡처된 프레임, 출력 이미지 크기 및 형식을 사용자 정의할 수 있습니다.
비디오를 애니메이션 이미지로 변환하는 기능은 비디오를 애니메이션 이미지로 변환합니다. 사용자 정의 비디오를 애니메이션 이미지로 변환 템플릿에서 템플릿 이름, 트랜스 코딩 시작 시간, 트랜스 코딩 지속 시간, 프레임 추출 방법, 출력 애니메이션 이미지 프레임 레이트, 출력 애니메이션 이미지 크기 및 형식을 사용자 정의할 수 있습니다.
오프셋 방법: 워터마크 오프셋은 원점을 기준으로 합니다. 비율 또는 고정 위치로 오프셋을 선택할 수 있습니다.
워터마크 재생 시간: 동영상 재생 시간과 동일 또는 지정된 시간을 선택하십시오. 후자를 선택하면 워터마크 시작 시간과 종료 시간을 설정할 수 있습니다. 시작 시간만 설정하면 기본적으로 동영상이 끝날 때까지 워터마크가 표시됩니다.
이미지 워터마크 매개변수
이미지 선택: 이미지 워터마크를 선택하면 소스를 선택해야 합니다. 현재는 같은 버킷에 있는 워터마크 이미지만 선택할 수 있습니다. 버킷에 원하는 이미지가 없으면 새 이미지를 업로드해야 합니다.
이미지 레이어: 이미지를 비디오의 상단 또는 하단 배치 여부를 선택합니다.
비디오 상단에 이미지를 배치하면 아래와 같은 효과가 나타납니다.
이미지가 비디오 하단에 배치되면(배경으로) 효과는 다음과 같습니다.
워터마크 크기:
입력 이미지 크기: 원본 워터마크 이미지 크기는 처리 없이 유지됩니다. 워터마크 이미지가 동영상 이미지보다 클 경우 워터마크가 완전히 표시되지 않을 수 있습니다.
비율: 너비 또는 높이만 또는 둘 다의 백분율[1, 100]을 설정할 수 있습니다. 너비 또는 높이가 설정되지 않은 경우 크기가 비례 조정됩니다. 너비 비율이 a이고 높이 비율이 b라고 가정하면 워터마크 너비는 w = W * a가 되고 워터마크 높이는 h = H * b가 됩니다(여기서 W와 H는 각각 비디오 너비와 높이입니다).
고정 크기: 워터마크 너비와 높이를 [8, 4096]px 사이로 지정할 수 있습니다.
오프셋 방법(비디오 상단):
비율별: 너비 또는 높이의 백분율[0, 100]을 설정할 수 있습니다. 아래 이미지와 같이 수평 오프셋 비율이 a이고 수직 비율이 b라고 가정하면 수평 오프셋은 Dx = W * a, 수직 오프셋은 Dy = H * b가 됩니다(여기서 W와 H는 비디오 너비와 높이).
고정 위치: [0, 4096]px 사이의 값을 선택합니다. 수평 오프셋은 Dx이고 수직 오프셋은 Dy입니다.
워터마크 크기:
입력 이미지 크기: 원본 워터마크 이미지 크기는 처리 없이 유지됩니다. 워터마크 이미지가 동영상 이미지보다 작으면 워터마크가 완전히 표시되지 않을 수 있습니다.
비율별: 너비 또는 높이만 또는 둘 다의 백분율[100, 300]을 설정할 수 있습니다. 너비 또는 높이가 설정되지 않은 경우 크기가 비례 조정됩니다. 너비 비율이 a이고 높이 비율이 b라고 가정하면 워터마크 너비는 w = W * a가 되고 워터마크 높이는 h = H * b가 됩니다(여기서 W와 H는 각각 비디오 너비와 높이입니다).
고정 크기: 워터마크 너비와 높이를 [8, 4096]px 사이로 지정할 수 있습니다.
오프셋 방법(비디오 아래):
비율별: 너비 또는 높이의 백분율[-300, 0]을 설정할 수 있습니다. 아래 이미지와 같이 수평 오프셋 비율이 a이고 수직 비율이 b라고 가정하면 수평 오프셋은 Dx = W * a, 수직 오프셋은 Dy = H * b가 됩니다(여기서 W와 H는 비디오 너비와 높이).
고정 위치: [-4096, 0]px 사이의 값을 선택합니다. 수평 오프셋은 Dx이고 수직 오프셋은 Dy입니다.
텍스트 워터마크 매개변수
워터마크 텍스트: 최대 64자의 중국어, 영어, 숫자, 밑줄(_), 하이픈(-), 별표(*)를 포함할 수 있습니다.
글꼴 크기: [5 100]px 사이의 값을 선택합니다.
글꼴: 현재 중/영 혼합 워터마크는 Fangsong, heiti, kaiti, songti, huawen heiti, huawen heiti zhong, you yuan을 지원하고, 영어 워터마크는 ariblk, arial, ahronbd, Helvetica 및 HelveticaNeue의 선택을 지원합니다. 순수한 영어 글꼴은 영어 입력만 지원하므로 워터마크에 중국어가 포함된 경우 글자가 깨져서 나타납니다.
글꼴 색상: 0xRRGGBB 형식입니다.
7. 확인을 클릭합니다.
템플릿 생성 성공 후 사용자 정의 템플릿 목록에서 보기, 편집, 삭제할 수 있습니다.
미리보기를 클릭하여 세 가지 일반적인 해상도의 비디오에서 워터마크의 위치와 크기를 보고 템플릿을 빠르게 조정할 수 있습니다.
이미지 처리 기능은 CI에서 제공하는 풍부한 기능과 비용 효율적이고 신뢰성이 높은 이미지 처리 서비스입니다. 회전, 자르기, 트랜스 코딩 및 확대/축소와 같은 유연한 이미지 편집을 지원합니다. Guetzli 압축, TPG 트랜스 코딩, HEIF 트랜스 코딩과 같은 다양한 이미지 다운사이징 솔루션과 이미지/텍스트/블라인드 워터마킹과 같은 다양한 저작권 보호 솔루션을 제공합니다. 이는 다양한 비즈니스 시나리오에서 이미지 처리 요구 사항을 충족합니다.
TDSQL-C for MySQL 백업은 Tencent Cloud COS(Cloud Object Storage)에서 제공하는 Serverless Cloud Function(SCF) 기반 기능입니다. TDSQL-C for MySQL 에서 COS로 데이터를 저장할 수 있습니다. 데이터를 지속적으로 저장하고 데이터 손실이나 손상으로부터 보호할 수 있습니다. 버킷에 대한 백업 기능 규칙을 설정하면 SCF는 TDSQL-C for MySQL 백업 파일을 주기적으로 스캔하여 버킷에 저장합니다.
참고 사항
TDSQL-C for MySQL 백업 기능은 TDSQL-C for MySQL의 binlog 백업 파일만 백업합니다. 따라서 TDSQL-C for MySQL에 binlog 정기 백업이 활성화되어 있지 않으면 기능을 실행할 수 없습니다. TDSQL-C for MySQL 백업에 대한 자세한 내용은 Backup and Rollback Overview를 참고하십시오.
논리적 백업 및 스냅샷 백업은 이 기능을 통해 COS에 백업할 수 없습니다.
COS 콘솔에서 버킷에 TDSQL-C for MySQL 백업 규칙을 추가한 경우 SCF 콘솔에 백업 기능이 나타납니다. 이 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
TDSQL-C for MySQL 데이터 백업은 광저우, 상하이, 베이징, 청두, 중국홍콩, 싱가포르 및 실리콘밸리 리전에서 지원됩니다. 자세한 내용은 Regions and AZs를 참고하십시오.
2. 왼쪽 사이드바에서 버킷 리스트를 선택한 후 TDSQL-C for MySQL 백업 설정이 필요한 버킷을 클릭하여 버킷 관리 페이지로 이동합니다.
3. 왼쪽 함수 계산을 클릭하여 TDSQL-C for MySQL 백업 함수 설정 항목을 찾습니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
4. 함수 추가를 클릭합니다.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
트리거 주기: TDSQL-C for MySQL 데이터 백업 함수는 주기적인 트리거를 통해 백업 저장 작업을 트리거하며 트리거 주기는 매일, 매주, 사용자 정의 주기를 지원합니다.
Cron 표현식: 트리거 주기를 사용자 정의로 설정한 경우 Cron으로 구체적인 트리거 주기 규칙을 지정할 수 있습니다. Cron은 현재 베이징 시간인 UTC+8 중국 표준 시간(China Standard Time)을 기준으로 실행합니다. 정책 설정에 관한 상세 내용은 Cron 관련 문서를 참고하십시오.
데이터베이스 인스턴스: 현재 버킷이 위치한 리전의 TDSQL-C for MySQL 데이터베이스 인스턴스 리스트입니다.
전송 경로: 백업 파일의 전송 경로 접두사로, 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장됩니다.
SCF 라이선스: TDSQL-C for MySQL 데이터 백업은 TDSQL-C for MySQL 백업에서 데이터베이스 인스턴스 및 백업 파일을 읽을 수 있는 권한을 SCF에 부여하여 백업 파일을 지정 버킷에 저장합니다. 따라서 해당 라이선스를 추가해야 합니다.
6. 설정을 추가한 후 확인을 클릭하면 추가된 함수를 확인할 수 있습니다.
새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 TDSQL-C for MySQL 데이터 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
더 보기 > 편집을 클릭하여 TDSQL-C for MySQL 데이터 백업 규칙을 수정합니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 TDSQL-C for MySQL 데이터 백업 규칙을 삭제합니다.
COS 인벤토리 분석 함수 추가
최종 업데이트 날짜:：2025-05-21 18:47:08
소개
COS 인벤토리 분석은 다양한 시나리오의 인벤토리 분석 서비스를 제공하여 인벤토리 파일에서 핵심 정보를 보다 효율적으로 추출할 수 있도록 지원합니다. 본 문서에서는 COS 인벤토리 분석 함수 추가 방법을 설명합니다. 함수를 생성한 후 인벤토리 분석 설정을 참조하여 COS 인벤토리 분석 기능을 사용하세요.
주의 사항
이전에 COS 콘솔에서 버킷에 COS 인벤토리 분석 규칙을 추가한 경우, SCF 콘솔에서 생성한 COS 인벤토리 분석 함수를 확인할 수 있습니다. 해당 COS 인벤토리 분석 함수를 삭제하지 마세요. 그렇지 않으면 규칙이 정상적으로 작동하지 않을 수 있습니다.
현재 기능은 COS와 SCF가 동일한 리전에 있을 때만 지원되며, 일부 리전(예: 충칭 리전)은 사용이 지원되지 않습니다. 사용 가능 여부는 COS 및 SCF 콘솔의 리전 표시를 기준으로 합니다.
COS 인벤토리 분석 기능은 SCF 서비스에 의존하며, SCF 서비스는 사용자에게 프리 티어를 제공합니다. 초과 사용 시 SCF 제품 요금에 따라 과금됩니다.
2. 왼쪽 네비게이션 바에서 애플리케이션 통합 > 확장 기능을 선택하여 COS 인벤토리 분석을 찾습니다.
3. 분석 기능 설정을 클릭하여 COS 인벤토리 분석의 함수 규칙 설정 페이지로 이동합니다.
4. 페이지에서 함수를 추가할 리전을 선택한 후 함수 추가를 클릭하여 팝업 창에서 다음 정보를 설정합니다.
함수 이름: 함수 이름은 함수의 고유 식별자이며, 생성 후 수정할 수 없습니다. 해당 함수는 SCF 콘솔에서 확인할 수 있습니다.
연결된 버킷: 인벤토리 분석 기능이 설정된 COS 버킷을 선택합니다.
실행 설정: 현재 비동기 실행만 지원되며, 호출 후 비동기 실행 상태로 전환되어 실행 결과를 반환하지 않지만 더 긴 실행 시간을 지원합니다.
인증 방식: 현재는 SCF 인증만 지원됩니다.
인벤토리 설정 상태: 해당 기능을 사용하려면 버킷에 인벤토리 기능을 설정해야 합니다. 설정 방법은 인벤토리 설정을 참조하십시오.
SCF 권한 부여: COS 인벤토리 분석은 SCF가 사용자의 버킷에서 해당 파일을 읽고 인벤토리 분석 결과 파일을 지정된 위치에 저장할 수 있도록 권한이 필요합니다. 해당 항목을 선택하여 SCF 서비스 권한 부여를 완료해야 합니다.
5. 설정이 올바른지 확인한 후 확인을 클릭하면 잠시 후 함수 추가되며, 팝업 메시지에 따라 버킷의 인벤토리 설정 항목으로 이동하여 인벤토리 분석 작업을 생성할 수 있습니다. 자세한 내용은 COS 인벤토리 분석을 참조하십시오.
6. 새로 생성된 함수에 대해 다음 작업을 수행할 수 있습니다.
사용 안내를 클릭하면 사용 안내를 다시 열고 COS 버킷으로 빠르게 이동할 수 있습니다.
로그를 클릭하여 COS 인벤토리 분석 함수의 과거 실행 내역을 확인할 수 있습니다. 오류 발생 시 로그를 클릭하여 SCF 콘솔로 빠르게 이동하여 로그 오류 상세 정보를 확인할 수도 있습니다.
상세 정보를 클릭하면 함수 및 트리거의 상세 정보를 확인할 수 있습니다.
더 보기 > 편집을 클릭하여 COS 인벤토리 분석 함수 규칙을 확인합니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 COS 인벤토리 분석 함수 규칙을 삭제합니다.
COS 인벤토리 분석 설정
최종 업데이트 날짜:：2025-08-15 16:47:25
소개
Cloud Object Storage(COS) 인벤토리 기능을 추가한 후 인벤토리 분석 기능을 활성화하여 생성된 인벤토리 파일에 대한 추가 데이터 분석을 수행할 수 있습니다. 인벤토리 분석 기능은 지정된 시간 범위 내의 인벤토리 데이터를 통합하여 통계 분석을 수행하고, 핵심 지표를 추출하여 제공합니다.
3. 인벤토리 분석이 필요한 버킷을 찾아 해당 버킷 이름을 클릭하여 해당 버킷 관리 페이지로 이동합니다.
4. 왼쪽 네비게이션 바에서 기본 설정 > 인벤토리 설정을 선택합니다.
주의:
인벤토리 분석 기능을 사용하기 전에 인벤토리를 이미 추가하고 인벤토리 파일을 생성했는지 확인해야 합니다.
5. 인벤토리 분석 설정 항목에서 COS 인벤토리 분석 함수를 추가되지 않은 경우, 아래 지금 사용을 클릭하면 시스템이 COS 인벤토리 분석 함수 규칙이 설정되었는지 자동으로 확인합니다. 함수 추가는 COS 인벤토리 분석 함수 추가를 참조하십시오.
COS 인벤토리 분석 함수를 이미 추가한 경우, 인벤토리 분석에서 해당 함수 이름을 선택하고, 분석할 인벤토리 시간 범위를 선택한 후 분석 작업 생성을 클릭하며 팝업 창에서 다음 정보를 설정하세요.
주의:
인벤토리 분석을 위해 버킷 내 객체의 총 수는 1억을 초과할 수 없습니다.
기본 설정
인벤토리 이름: 분석할 인벤토리를 선택합니다.
인벤토리 타임스탬프: 인벤토리 파일 객체 키에 포함된 타임스탬프 값.
결과 저장 디렉토리: 이번 분석 결과 파일과 인벤토리 파일은 모두 해당 디렉토리로 저장됩니다.
작업 설명: 이번 분석의 설명 정보를 사용자 정의할 수 있습니다.
필터 설정
필터 조건: 객체 키, 객체 크기, 최신 수정 시간, 최신 버전 여부에 따라 필터링할 수 있습니다.
객체 키: 객체 키 템플릿을 입력하세요. 와일드카드*를 지원합니다, 예를 들어 test/*는 test/ 접두사를 가진 객체를 의미합니다.
최신 수정 시간: 어제, 최근 3일 또는 사용자 지정 시간 범위를 지원합니다.
객체 크기: 객체 크기의 범위를 지정합니다.
최신 버전 여부: 최신 버전 여부를 선택할 수 있습니다.
통계 설정
작업 유형: 통계 결과를 내보내거나 객체 목록을 내보낼 수 있습니다.
통계 기준: 디렉터리 접두사, 객체 접미사, 저장 유형 중 선택할 수 있습니다.
통계 내용: 객체 총 크기, 객체 수 중 선택할 수 있습니다.
통계 항목 최대 수: 통계 항목 최대 수, 즉 결과 파일에 통계 결과의 최대 행 수를 입력하세요. 최대 10,000개를 초과할 수 없습니다.
6. 설정이 올바른지 확인한 후 확인을 클릭하여 분석 작업을 추가합니다.
생성된 분석 작업은 다음과 같은 작업을 수행할 수 있습니다.
결과 보기를 클릭하여 이번 인벤토리 분석 결과와 결과 파일 저장 경로를 확인할 수 있습니다.
주의:
최근 3일 동안 생성된 인벤토리 분석 작업을 조회할 수 있습니다.
분석 작업이 완료된 후에만 결과를 조회할 수 있으며, 분석 소요 시간은 인벤토리 크기에 따라 몇 분에서 수십 분 정도 걸릴 수 있습니다.
실행 로그를 클릭하여 SCF 콘솔로 이동하며 COS 인벤토리 분석의 실행 로그를 확인할 수 있습니다.
MySQL 데이터 백업
최종 업데이트 날짜:：2024-10-24 18:58:08
소개
MySQL 백업은 Tencent Cloud COS(Cloud Object Storage)가 Serverless Cloud Function을 기반으로 사용자에게 제공하는 데이터베이스 백업 기능입니다. MySQL 데이터베이스의 백업 파일을 COS에 장기적으로 저장하여 데이터 손실 및 손상을 방지합니다. 사용자가 지정 버킷에서 백업 함수 규칙을 설정하면 SCF는 정기적으로 MySQL 백업 파일을 스캔하여 버킷에 파일을 저장합니다.
주의 사항
MySQL 데이트 백업 함수는 Tencent Cloud MySQL 데이터베이스의 백업 파일을 백업합니다. 기존에 MySQL 데이터베이스 백업을 활성화하지 않은 경우 백업 함수를 실행할 수 없습니다. Tencent Cloud MySQL 데이터베이스 백업에 대한 자세한 내용은 MySQL 데이터베이스 백업을 참고하십시오.
COS 콘솔에서 버킷에 MySQL 데이터 백업 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 MySQL 데이터 백업 함수를 볼 수 있습니다. 이 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
광저우, 상하이, 베이징, 청두, 중국홍콩, 싱가포르, 실리콘밸리 등 SCF를 런칭한 리전은 MySQL 데이터 백업을 지원합니다. 지원 리전에 대한 자세한 내용은 SCF 제품 문서를 참고하십시오.
2. 왼쪽 사이드바에서 버킷 리스트를 선택한 후 MySQL 백업 설정이 필요한 버킷을 클릭하여 버킷 관리 페이지로 이동합니다.
3. 왼쪽 함수 계산을 클릭하여 MySQL 백업 함수 설정 항목을 찾습니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
4. 함수 추가를 클릭합니다.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
트리거 주기: MySQL 데이터 백업 함수는 주기적인 트리거를 통해 백업 저장 작업을 트리거하며 트리거 주기는 매일, 매주, 사용자 정의 주기를 지원합니다.
Cron 표현식: 트리거 주기를 사용자 정의로 설정한 경우 Cron으로 구체적인 트리거 주기 규칙을 지정할 수 있습니다. Cron은 현재 베이징 시간인 UTC+8 중국 표준 시간(China Standard Time)을 기준으로 실행합니다. 정책 설정에 관한 상세 내용은 Cron 관련 문서를 참고하십시오.
데이터베이스 인스턴스: 현재 버킷이 위치한 리전의 MySQL 데이터베이스 인스턴스 리스트입니다.
전송 경로: 백업 파일의 전송 경로 접두사로, 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장됩니다.
SCF 라이선스: MySQL 데이터 백업은 MySQL 백업에서 데이터베이스 인스턴스 및 백업 파일을 읽을 수 있는 권한을 SCF에 부여하여 백업 파일을 지정 버킷에 저장합니다. 따라서 해당 라이선스를 추가해야 합니다.
6. 설정을 추가한 후 확인을 클릭하면 추가된 함수를 확인할 수 있습니다.
새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 MySQL 데이터 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
더 보기 > 편집을 클릭하여 MySQL 데이터 백업 규칙을 수정합니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 MySQL 데이터 백업 규칙을 삭제합니다.
MongoDB 데이터 백업
최종 업데이트 날짜:：2025-07-10 14:55:16
소개
MongoDB 데이터 백업은 Tencent Cloud COS(Cloud Object Storage)가 SCF(Serverless Cloud Function를 기반으로 사용자에게 제공하는 데이터베이스 백업 기능입니다. MongoDB CDB 파일을 COS에 장기적으로 저장하여 데이터 손실 및 손상을 방지합니다. 사용자가 지정 버킷에서 백업 함수 규칙을 설정하면 SCF는 정기적으로 MongoDB 백업 파일을 스캔하여 버킷에 파일을 저장합니다.
주의 사항
MongoDB 데이터 백업 함수는 Tencent Cloud MongoDB 데이터베이스 백업 파일을 백업합니다. 기존에 MongoDB 데이터베이스 백업을 활성화하지 않은 경우 백업 함수를 실행할 수 없습니다. Tencent Cloud MongoDB 데이터베이스 백업에 대한 자세한 내용은 TencentDB for MongoDB 백업을 참고하십시오.
COS 콘솔에서 버킷에 MongoDB 데이터 백업 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 MongoDB 데이터 백업 함수를 볼 수 있습니다. 이 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
배포된 클라우드 함수 SCF 지역은 모두 MongoDB 데이터 백업을 지원합니다. 여기에는 광저우, 상하이, 난징, 베이징, 청두, 홍콩, 싱가포르, 방콕, 서울, 도쿄, 실리콘밸리, 버지니아 등이 포함됩니다. 지원 리전에 대한 자세한 내용은 SCF 제품 문서를 참고하십시오.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 데이터 백업을 클릭하고 MongoDB 데이터 백업을 찾습니다.
3. 백업 규칙 설정을 클릭하여 규칙 설정 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
연결 버킷: MongoDB 백업 파일을 저장할 버킷입니다.
트리거 주기: MongoDB 데이터 백업 함수는 주기적인 트리거를 통해 백업 저장 작업을 트리거하며, 트리거 주기는 매일, 매주 및 사용자 정의 주기를 지원합니다.
설명：
예를 들어, 어떤 사용자가 2023년 7월 3일에 MongoDB 백업 규칙을 설정하고 매일 00:00에 MongoDB 인스턴스 파일을 COS에 백업하도록 지정한 경우.
이 경우, 클라우드 함수는 2023년 7월 4일 00:00:03에 실행을 시작합니다(클라우드 함수 시작에는 몇 초의 지연이 있습니다), 그리고 최근 3일간의 MongoDB 인스턴스 파일을 스캔한 후 COS에 업로드합니다.
클라우드 함수 실행 시간이 2023-07-04 00:00:03이므로, 최종 백업 파일의 시간 범위는: 2023-07-01 00:00:00 ~ 2023-07-04 00:00:03입니다.
Cron 표현식: 트리거 주기를 사용자 정의로 설정한 경우 Cron으로 구체적인 트리거 주기 규칙을 지정할 수 있습니다. Cron은 현재 UTC +8 중국 표준시(CST)에서 실행되고 있으며, 이는 베이징 시간입니다. 정책 설정에 관한 상세 내용은 Cron 관련 문서를 참고하십시오.
데이터베이스 인스턴스: 현재 버킷이 속한 리전의 MongoDB 데이터베이스 인스턴스 리스트입니다.
전송 경로: 백업 파일의 전송 경로 접두사로, 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장됩니다.
SCF 라이선스: MongoDB 데이터 백업은 MongoDB에서 백업에서 데이터베이스 인스턴스 및 백업 파일을 읽을 수 있는 권한을 SCF에 부여하여 백업 파일을 지정 버킷에 저장합니다. 따라서 해당 라이선스를 추가해야 합니다.
6. 설정을 추가한 후 확인을 클릭하면 추가된 함수를 확인할 수 있습니다.
새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 MongoDB 데이터 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
상세를 클릭하여 함수 및 트리거의 설정 정보를 확인합니다.
더 보기 > 편집을 클릭하여 MongoDB 데이터 백업 규칙을 수정합니다.
더보기 > 트리거를 클릭하면 지정된 주기에 도달하지 않고도 클라우드 함수를 즉시 트리거할 수 있습니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 MongoDB 데이터 백업 규칙을 삭제합니다.
SQL Server 데이터 백업
최종 업데이트 날짜:：2025-10-09 15:03:36
소개
SQL Server 데이터 백업은 Tencent Cloud COS(Cloud Object Storage)가 SCF(Serverless Cloud Function)를 기반으로 사용자에게 제공하는 데이터베이스 백업 기능입니다. SQL Server CDB의 백업 파일을 COS에 영속 저장하여 데이터 손실 및 손상을 방지합니다. 사용자가 지정 버킷에서 백업 함수 규칙을 설정하면 SCF는 정기적으로 사용자 Server 백업 파일을 스캐닝하여 버킷에 파일을 저장합니다.
주의 사항
SQL Server 데이터 백업 함수는 Tencent Cloud SQL Server 데이터베이스의 백업 파일을 백업합니다. 기존에 SQL Server 데이터베이스 백업을 활성화하지 않은 경우 백업 함수를 실행할 수 없습니다. 텐센트 클라우드 SQL Server 데이터베이스 백업에 대한 자세한 정보는 SQL Server 백업을 참조하세요.
COS 콘솔에서 버킷에 SQL Server 데이터 백업 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 SQL Server 데이터 백업 함수를 볼 수 있습니다. 이 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
현재 기능은 COS와 SCF가 동일한 지역에서만 지원됩니다. 일부 지역(예: 충칭 지역)에서는 사용할 수 없습니다. 구체적인 내용은 COS 및 SCF 콘솔에 표시된 지역을 기준으로 합니다.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 데이터 백업을 클릭하여 애플리케이션 통합 관리 페이지로 이동합니다.
3. SQL Server 데이터 백업을 찾아 백업 규칙 설정을 클릭하여 규칙 설정 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름
함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다.SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
연결 버킷
SQL Server 백업 파일이 저장되는 버킷입니다.
트리거 주기
SQL Server 데이터 백업 함수는 주기적인 트리거를 통해 백업 저장 작업을 하며 트리거 주기는 매일 및 사용자 정의 주기를 지원합니다.
Cron 표현식
트리거 주기를 사용자 정의로 설정한 경우 Cron으로 구체적인 트리거 주기 규칙을 지정할 수 있습니다. Cron은 현재 현지 표준 시간을 따릅니다. 정책 설정에 관한 상세 내용은 Cron 관련 문서를 참고하십시오.。
데이터베이스 인스턴스
현재 버킷이 위치한 지역의 SQL Server 데이터베이스 인스턴스 목록입니다.
전송 경로
백업 파일의 전송 경로 접두사로, 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장됩니다.
SCF 라이선스
SQL Server 데이터 백업은 SQL Server 백업에서 데이터베이스 인스턴스 및 백업 파일을 읽을 수 있는 권한을 SCF에 부여하여 백업 파일을 지정 버킷에 저장합니다. 따라서 해당 라이선스를 추가해야 합니다.
6. 설정을 추가한 후 확인을 클릭하면 추가된 함수를 확인할 수 있습니다.
새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 SQL Server 데이터 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
상세를 클릭하여 함수 및 트리거의 구성 정보를 확인하세요.
더 보기 > 편집을 클릭하여 SQL Server 데이터 백업 규칙을 수정합니다.
더보기 > 트리거를 클릭하면 SQL Server 데이터 백업 규칙을 수동으로 트리거할 수 있습니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 SQL Server 데이터 백업 규칙을 삭제합니다.
PostgreSQL 데이터 백업
최종 업데이트 날짜:：2025-12-17 11:54:15
소개
PostgreSQL 데이터 백업은 Cloud Object Storage(COS)가 Serverless Cloud Function(SCF)을 기반으로 제공하는 데이터베이스 백업 기능으로, 사용자가 TencentDB for PostgreSQL의 백업 파일을 COS로 전송·저장하여 데이터 손실 또는 손상을 방지할 수 있도록 지원합니다. 사용자가 지정된 버킷에 백업 함수 규칙을 구성하면, SCF이 정기적으로 PostgreSQL 백업 파일을 스캔하여 버킷으로 전송·저장합니다. 기본적으로 트리거 시간 기준 3일 이내의 백업 파일을 저장합니다.
주의 사항
PostgreSQL 데이터 백업 함수는 Tencent Cloud PostgreSQL 데이터베이스의 백업 파일을 백업합니다. 이전에 PostgreSQL 데이터베이스 백업을 활성화하지 않은 경우 백업 함수를 실행할 수 없습니다. Tencent Cloud PostgreSQL 데이터베이스 백업에 대한 자세한 내용은 PostgreSQL 자동 백업 설정을 참고하십시오.
이전에 COS 콘솔에서 버킷에 PostgreSQL 데이터 백업 규칙을 추가한 경우, SCF 콘솔에서 생성한 PostgreSQL 데이터 백업 함수를 확인할 수 있습니다. 해당 함수를 삭제하지 마십시오. 그렇지 않으면 규칙이 적용되지 않을 수 있습니다.
현재 기능은 COS와 SCF가 동일한 리전에 있을 때만 지원되며, 일부 리전(예: 충칭 리전)은 사용이 지원되지 않습니다. 사용 가능 여부는 COS 및 SCF 콘솔의 리전 표시를 기준으로 합니다.
개별 백업 파일 크기는 2TB 이내여야 합니다. 2TB를 초과할 경우 백업이 실패할 수 있습니다.
2. 왼쪽 네비게이션 바에서 애플리케이션 통합 > 데이터 백업을 클릭하여, PostgreSQL 백업을 찾습니다.
3. 백업 규칙 구성을 클릭하여 구성 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의:
SCF 서비스를 활성화하지 않은 경우, SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료해 주시기 바랍니다.
Cloud Log Service(CLS)를 활성화하지 않은 경우, CLS 콘솔로 이동하여 안내에 따라 CLS 활성화 절차를 완료해 주시기 바랍니다.
5. 팝업 창에서 다음 정보를 구성하십시오.
함수 이름: 함수의 고유한 식별 이름으로서 생성 후 변경할 수 없습니다. SCF 콘솔에서 해당 함수를 확인할 수 있습니다.
연결된 버킷: PostgreSQL 백업 파일을 저장하는 버킷입니다.
주의:
백업할 PostgreSQL 데이터 소속 리전은 연결된 버킷의 소속 리전과 동일해야 합니다.
트리거 주기: PostgreSQL 데이터 백업 함수는 정기 트리거를 통해 백업 및 저장 작업을 실행하며, 트리거 주기는 매일 또는 사용자 정의 주기를 지원합니다.
Cron 표현식: 트리거 주기를 사용자 정의로 설정한 경우 Cron을 통해 구체적인 트리거 주기 규칙을 지정할 수 있습니다. Cron은 현재 UTC+8 중국 표준시(China Standard Time, 베이징 시긴)로 실행됩니다. 자세한 구성 방법은 Cron 관련 문서를 참고하십시오.
데이터베이스 인스턴스: 현재 버킷이 위치한 리전의 PostgreSQL 데이터베이스 인스턴스 목록입니다.
전송 경로: 백업 파일의 전송 경로 접두사로, 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장됩니다.
SCF 권한 부여: PostgreSQL 데이터 백업은 SCF가 사용자의 PostgreSQL 백업에서 데이터베이스 인스턴스 및 해당 백업 파일을 읽고, 지정된 버킷으로 백업 파일을 저장할 수 있는 권한이 필요합니다. 따라서 해당 권한을 부여해야 합니다.
6. 구성을 추가한 후 확인을 클릭하면 함수가 추가 완료된 것을 볼 수 있습니다.
새로 생성된 함수에 대해 다음과 같은 작업을 수행할 수 있습니다.
로그를 클릭하여 PostgreSQL 데이터 백업의 실행 이력을 확인합니다. 백업에 오류가 발생한 경우, 로그를 클릭하여 SCF 콘솔로 빠르게 이동하여 로그 오류 상세 정보를 확인할 수도 있습니다.
상세 정보를 클릭하면 함수 및 트리거의 상세 정보를 확인할 수 있습니다.
더보기 > 편집을 클릭하면 PostgreSQL 데이터 백업 규칙을 수정합니다.
더보기 > 트리거를 클릭하면 PostgreSQL 데이터 백업 규칙을 수동으로 트리거할 수 있습니다.
더보기 > 삭제를 클릭하면 사용하지 않는 PostgreSQL 데이터 백업 규칙을 삭제합니다.
2. 왼쪽 네비게이션 바에서 버킷 목록을 선택하고, PostgreSQL 데이터 백업을 설정할 버킷을 클릭하여 버킷 관리 페이지로 이동합니다.
3. 왼쪽의 함수 계산을 클릭하고 PostgreSQL 백업 함수 구성 항목을 찾습니다.
주의:
SCF 서비스를 활성화하지 않은 경우, SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료해 주시기 바랍니다.
Cloud Log Service(CLS)를 활성화하지 않은 경우, CLS 콘솔로 이동하여 안내에 따라 CLS 활성화 절차를 완료해 주시기 바랍니다.
4. 함수 추가를 클릭합니다.
5. 팝업 창에서 다음 정보를 구성하십시오.
함수 이름: 함수의 고유한 식별 이름으로서 생성 후 변경할 수 없습니다. SCF 콘솔에서 해당 함수를 확인할 수 있습니다.
트리거 주기: PostgreSQL 데이터 백업 함수는 정기 트리거를 통해 백업 및 저장 작업을 실행하며, 트리거 주기는 매일 또는 사용자 정의 주기를 지원합니다.
Cron 표현식: 트리거 주기를 사용자 정의로 설정한 경우 Cron을 통해 구체적인 트리거 주기 규칙을 지정할 수 있습니다. Cron은 현재 UTC+8 중국 표준시(China Standard Time, 베이징 시긴)로 실행됩니다. 자세한 구성 방법은 Cron 관련 문서를 참고하십시오.
데이터베이스 인스턴스: 현재 버킷이 위치한 리전의 PostgreSQL 데이터베이스 인스턴스 목록입니다.
전송 경로: 백업 파일의 전송 경로 접두사로, 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장됩니다.
SCF 권한 부여: PostgreSQL 데이터 백업은 SCF가 사용자의 PostgreSQL 백업에서 데이터베이스 인스턴스 및 해당 백업 파일을 읽고, 지정된 버킷으로 백업 파일을 저장할 수 있는 권한이 필요합니다. 따라서 해당 권한을 부여해야 합니다.
6. 구성을 추가한 후 확인을 클릭하면 함수가 추가 완료된 것을 볼 수 있습니다.
새로 생성된 함수에 대해 다음과 같은 작업을 수행할 수 있습니다.
로그를 클릭하여 PostgreSQL 데이터 백업의 실행 이력을 확인합니다. 백업에 오류가 발생한 경우, 로그를 클릭하여 SCF 콘솔로 빠르게 이동하여 로그 오류 상세 정보를 확인할 수도 있습니다.
상세 정보를 클릭하면 함수 및 트리거의 상세 정보를 확인할 수 있습니다.
더보기 > 편집을 클릭하면 PostgreSQL 데이터 백업 규칙을 수정합니다.
더보기 > 트리거를 클릭하면 PostgreSQL 데이터 백업 규칙을 수동으로 트리거할 수 있습니다.
더보기 > 삭제를 클릭하면 사용하지 않는 PostgreSQL 데이터 백업 규칙을 삭제합니다.
Ckafka 메시지 백업
최종 업데이트 날짜:：2024-10-24 18:58:08
소개
Ckafka 메시지 백업은 Tencent Cloud COS가 Serverless Cloud Function(SCF)을 기반으로 제공하는 기능으로, Ckafka 메시지를 COS에 저장합니다. Ckafka 메시지를 저장하면 편리하게 데이터 분석 및 다운로드 등의 작업을 진행할 수 있습니다.
Ckafka는 오픈 소스인 Apache Kafka 메시지 큐 엔진을 기반으로, 처리 성능이 뛰어나고 확장성이 높은 메시지 큐 서비스를 제공합니다. 자세한 내용은 Ckafka 제품 개요를 참고하십시오.
버킷에 백업 함수 규칙을 설정하면, CKafka 인스턴스에 메시지가 발생할 때 SCF가 일정 시간 간격으로 메시지를 획득하고 COS 버킷에 저장합니다.
주의 사항
COS 콘솔에서 버킷에 Ckafka 메시지 백업 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 Ckafka 메시지 백업 함수를 확인할 수 있습니다. 이 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
광저우, 상하이, 중국홍콩, 베이징, 청두, 싱가포르, 실리콘밸리 등 SCF를 런칭한 리전은 Ckafka 메시지 백업을 지원합니다. 지원 리전에 대한 자세한 내용은 SCF 제품 문서를 참고하십시오.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 데이터 백업을 클릭하고 Ckafka 메시지 백업을 찾습니다.
3. 백업 규칙 설정을 클릭하여 규칙 설정 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
연결 버킷: Ckafka 메시지를 저장할 COS 버킷입니다.
시간 간격: 메시지 양에 따라 메시지를 취합할 시간 간격을 선택하며, 시간 간격은 5~15분으로 설정할 수 있습니다. 저장 성능의 보장을 위해 취합할 파일 수는 Partition 수 및 partition_max의 설정 값과 연관되어 있습니다. Partition에 대한 자세한 내용은 파티션을 참고하십시오.
SCF 라이선스: CKafka 메시지 백업은 Ckafka 서비스에서 관련 인스턴스 메시지를 읽고 메시지를 지정한 버킷에 저장할 수 있는 SCF 라이선스가 필요합니다. 따라서 해당 라이선스를 추가해야 합니다.
6. 다음 단계를 클릭하여 Ckafka를 설정합니다. 설정 항목에 관한 설명은 다음과 같습니다.
인스턴스 선택: 메시지 소스의 Ckafka 인스턴스를 선택합니다. 리전 내 Ckafka 인스턴스만 지원합니다.
제목 선택: 메시지 소스의 제목을 선택합니다.
시작 위치: 메시지 덤프 백업 시 이전 메시지 처리 방식은 topic offset으로 설정합니다.
액세스 주소: 반드시 VPC 내부 네트워크의 액세스 주소여야 하며, 기본 네트워크의 CKafka 인스턴스의 경우 라우팅 정책을 추가해 주십시오. 자세한 사항은 라우팅 정책 추가를 참고하십시오.
주의：
해당 VPC 서브넷에는 가용 IP가 있어야 하며, DHCP를 지원해야 합니다.
7. 다음 단계를 클릭하여 설정을 전송합니다. 설정 항목에 대한 설명은 다음과 같습니다.
전송 경로: 백업 파일의 전송 경로 접두사로, 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장되며, 접두사를 지정하는 경우 반드시 슬래시 /로 끝나야 합니다.
8. 설정을 추가한 후 확인을 클릭하면 추가된 함수를 확인할 수 있습니다.
새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 Ckafka 메시지 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
더 보기 > 편집을 클릭하여 Ckafka 메시지 백업 규칙을 수정합니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 Ckafka 메시지 백업 규칙을 삭제합니다.
TDMQ 메시지 백업
최종 업데이트 날짜:：2024-06-24 16:23:48
소개
TDMQ 메시지 백업은 Tencent Cloud COS가 SCF를 기반으로 제공하는 기능이며, TDMQ 메시지를 COS에 저장합니다. TDMQ 메시지를 저장하면 데이터 분석 및 다운로드 등의 작업을 편리하게 진행할 수 있습니다.
오픈 소스 Apache Pulsar 프로젝트를 기반으로 하는 TDMQ는 재무 수준에서 Tencent Cloud가 개발한 분산 메시징 미들웨어로 리전 간 강력한 일관성, 높은 안정성 및 동시성을 특징으로 합니다. 자세한 내용은 TDMQ 제품 개요를 참고하십시오.
지정 버킷에 백업 함수 규칙을 설정하면, TDMQ에 메시지가 생성될 때 SCF에서 일정 시간 간격으로 메시지를 획득하고 COS 버킷에 저장합니다.
주의 사항
COS 콘솔에서 버킷에 TDMQ 메시지 백업 규칙을 추가한 적이 있는 경우, SCF 콘솔에서 기존에 생성한 TDMQ 메시지 백업 함수를 볼 수 있습니다. 해당 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
현재 COS로 TDMQ 메시지 백업을 지원하는 리전은 광저우, 상하이, 중국 홍콩, 베이징, 청두, 싱가포르, 실리콘밸리입니다.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 데이터 백업을 클릭하고 TDMQ 메시지 백업을 찾습니다.
3. 백업 규칙 설정을 클릭하여 규칙 설정 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
연결 버킷: TDMQ 메시지를 저장할 COS 버킷입니다.
시간 세분성: 메시지 양에 따라 메시지를 취합할 시간 간격을 선택하며, 시간 간격은 5 - 15분으로 설정할 수 있습니다. 단일 메시지 파일은 최대 5,000개로 제한되며, 메시지 파일은 최대 500MB로 제한됩니다.
SCF 라이선스: TDMQ 메시지 백업은 TDMQ 서비스에서 관련 메시지를 읽고 메시지를 지정한 버킷에 저장할 수 있는 SCF 라이선스가 필요합니다. 따라서 해당 라이선스를 추가해야 합니다.
6. 다음 단계를 클릭하여 TDMQ 설정을 진행합니다. 설정 항목에 대한 설명은 다음과 같습니다.
클러스터 선택: 메시지 소스의 TDMQ 클러스터를 선택합니다. 리전 내 TDMQ 클러스터만 지원합니다.
네임스페이스: 클러스터의 네임스페이스를 선택합니다.
제목 선택: 메시지 소스의 제목을 선택합니다.
구독 선택: 해당 주제 구독을 선택합니다. 현재 구독이 요구 사항을 충족하지 않는 경우 TDMQ 콘솔로 이동하여 구독을 생성할 수 있습니다.
시작 위치: 이전 메시지의 시작 위치
역할 선택: TDMQ 역할을 선택합니다. TDMQ의 '역할'은 TDMQ 내부 전용 개념으로 Tencent Cloud의 '역할'과 다르며, 사용자가 TDMQ 내부에서 권한을 구분하는 최소 단위입니다. 사용자는 여러 역할을 추가할 수 있으며, 각각 다른 네임스페이스의 생성 및 소비 권한을 부여할 수 있습니다.
-역할 키: TDMQ의 역할 키를 선택합니다. TDMQ의 '키'는 일종의 인증 툴입니다. 사용자는 클라이언트에게 키를 추가해 TDMQ에 액세스하며 메시지를 생성 및 소비할 수 있습니다. 키와 역할은 일대일 대응되고, 모든 역할은 각자 유일한 키를 가지고 있습니다.
액세스 주소: VPC 사설망 액세스 주소가 필요하며 TDMQ 클러스터가 VPC에 연결되어 있어야 합니다. 자세한 내용은 VPC 액세스를 참고하십시오.
주의：
해당 VPC 서브넷에는 가용 IP가 있어야 하며, DHCP를 지원해야 합니다.
7. 다음 단계를 클릭하여 설정을 전송합니다. 설정 항목에 대한 설명은 다음과 같습니다.
전송 경로: 백업 파일의 전송 경로 접두사입니다. 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장되며, 지정 접두사는 반드시 슬래시 /로 끝나야 합니다.
8. 설정을 추가한 후 확인을 클릭하면 추가된 함수를 확인할 수 있습니다.
새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 TDMQ 메시지 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
더 보기 > 편집을 클릭하여 TDMQ 메시지 백업 규칙을 수정합니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 TDMQ 메시지 백업 규칙을 삭제합니다.
Redis 데이터 백업
최종 업데이트 날짜:：2025-10-09 14:59:26
소개
Redis 데이터 백업은 Tencent Cloud Cloud Object Storage(COS)가 Serverless Cloud Function을 기반으로 사용자에게 제공하는 데이터베이스 백업 기능입니다. Reids CDB의 백업 파일을 COS에 영속화 저장하여 데이터 손실 및 손상을 방지합니다. 사용자가 지정 버킷에서 백업 함수 규칙을 설정하면 SCF는 정기적으로 Reids 백업 파일을 스캔하여 버킷에 파일을 저장합니다.
주의 사항
Reids 데이터 백업 함수는 Tencent Cloud Redis 데이터베이스의 백업 파일을 백업합니다. Redis 데이터베이스 백업이 활성화되어 있지 않은 경우, 백업 함수를 실행할 수 없습니다. Tencent Cloud Redis 데이터베이스 백업에 대한 자세한 내용은 TencentDB for Redis 백업을 참고하십시오.
COS 콘솔에서 버킷에 Reids 데이터 백업 규칙을 추가한 경우 SCF 콘솔에서 기존에 생성한 Reids 데이터 백업 함수를 볼 수 있습니다. 이 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
현재 기능은 COS와 SCF가 동일한 리전에 있을 때만 지원되며, 일부 리전(예: 충칭)은 사용이 지원되지 않습니다. 사용 가능 여부는 COS 및 SCF 콘솔의 리전 표시를 기준으로 합니다.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 데이터 백업을 클릭하여 애플리케이션 통합 관리 페이지로 이동합니다.
설명:
위의 기능 경로 외에도 버킷 목록을 클릭하고 해당 버킷 이름을 선택한 후 함수 계산 > Redis 백업 함수를 클릭하여 함수 구성 추가 페이지로 들어갈 수 있습니다.
3. Redis 데이터 백업을 찾아 백업 규칙 설정을 클릭하여 규칙 설정 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
연결 버킷: Redis 백업 파일을 저장하는 버킷입니다. 지정된 버킷의 함수 계산 기능 항목에서 구성하는 경우에는 이 항목이 표시되지 않습니다.
트리거 주기: Redis 데이터 백업 함수는 정기 트리거를 통해 백업 및 저장 작업을 실행하며, 트리거 주기는 매일 또는 사용자 정의 주기를 지원합니다.
설명:
예를 들어, 사용자가 2023년 7월 3일에 Redis 백업 규칙을 구성하여 매일 00:00에 Redis 인스턴스 파일을 COS에 백업하도록 지정했다고 가정합니다.
이 경우 SCF는 대략 2023년 7월 4일 00:00:03에 실행되며(SCF 시작에는 몇 초의 지연이 있음), 최근 3일간의 Redis 인스턴스 파일을 스캔한 후 COS에 업로드합니다.
SCF 실행 시간이 2023-07-04 00:00:03이므로 최종 백업 파일의 시간 범위는 2023-07-01 00:00:00 ~ 2023-07-04 00:00:03입니다.
Cron 표현식: 트리거 주기를 사용자 정의로 설정할 경우 Cron을 통해 구체적인 트리거 주기 규칙을 지정할 수 있습니다. Cron은 현재 UTC +8 중국 표준시(China Standard Time, 베이징 시긴)로 실행됩니다. 자세한 구성 방법은 Cron 관련 문서를 참고하십시오.
데이터베이스 인스턴스: 현재 버킷이 위치한 리전의 Reids 데이터베이스 인스턴스 리스트입니다.
전송 경로: 백업 파일의 전송 경로 접두사로, 입력하지 않은 경우 기본적으로 버킷의 루트 경로에 저장됩니다.
SCF 라이선스: Reids 데이터 백업은 Reids 백업에서의 데이터베이스 인스턴스 및 백업 파일 읽기 권한을 SCF에 부여하여 백업 파일을 지정 버킷에 저장합니다. 따라서 해당 라이선스를 추가해야 합니다.
6. 설정을 추가한 후 확인을 클릭하면 추가된 함수를 확인할 수 있습니다.
새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 Redis 데이터 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
상세 정보를 클릭하면 함수 및 트리거의 상세 정보를 확인할 수 있습니다.
더 보기 > 편집을 클릭하여 Redis 데이터 백업 규칙을 수정합니다.
더 보기 > 트리거를 클릭하면 Redis 데이터 백업 규칙을 수동으로 트리거할 수 있습니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 Redis 데이터 백업 규칙을 삭제합니다.
CDN 로그 백업
최종 업데이트 날짜:：2024-10-24 18:58:08
소개
도메인을 CDN(Content Delivery Network)에 액세스하면 모든 사용자 측의 리소스 요청이 CDN 노드에 스케쥴링됩니다. 노드에 해당 리소스가 캐시되어 있는 경우 콘텐츠를 직접 반환하며 캐시되어 있지 않으면 도메인 구성의 원본 서버에 요청을 전달하여 필요한 리소스를 풀링합니다.
CDN 노드는 대부분의 사용자 요청에 응답하므로 사용자 액세스를 쉽게 분석하기 위해 전체 네트워크 액세스 로그를 시간 단위로 패키징합니다.
CDN 로그 백업은 Tencent Cloud COS(Cloud Object Storage)가 SCF(Serverless Cloud Function)를 기반으로 CDN 로그를 COS에 저장하는 기능으로, CDN 로그를 변환하여 저장하면 사용자가 액세스 분석 및 서비스 품질 모니터링 등을 편리하게 할 수 있습니다.
사용자가 버킷에 로그 백업 규칙을 설정하면 SCF가 일정 시간 간격으로 CDN 로그를 획득하여 COS 버킷에 저장합니다.
주의 사항
COS 콘솔에서 버킷에 CDN 로그 백업 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 CDN 로그 백업 함수를 볼 수 있습니다. 이 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
광저우, 상하이, 중국 홍콩, 베이징, 청두, 싱가포르, 실리콘밸리 등 SCF를 런칭한 리전은 CDN 로그 백업을 지원합니다. 지원 리전에 대한 자세한 내용은 SCF 제품 문서를 참고하십시오.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 데이터 백업을 클릭하고 CDN 로그 백업을 찾습니다.
3. 백업 규칙 설정을 클릭하여 규칙 설정 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
연결 버킷: CDN 로그를 저장할 COS 버킷입니다.
트리거 주기: CDN 로그 백업은 주기적인 트리거를 통해 백업 작업을 하며 매일, 사용자 정의 주기를 지원합니다.
Cron 표현식: 트리거 주기를 사용자 정의로 설정한 경우 Cron으로 구체적인 트리거 주기 규칙을 지정할 수 있습니다. Cron은 현재 현지 표준 시간(Local Standard Time)을 따릅니다. 정책 설정에 관한 상세 내용은 Cron 관련 문서를 참고하십시오.
CDN 도메인: 하나 또는 여러 개의 지정 도메인 로그를 선택할 수 있습니다.
전송 경로: 루트 디렉터리 또는 지정된 경로 접두사로 전송할 수 있는 로그 파일 전송 경로입니다.
SCF 라이선스: CDN 로그 백업은 SCF에 권한을 부여하여 CDN 서비스를 이용할 때 로그 파일을 읽고 지정 버킷에 저장하므로 해당 라이선스 추가가 필요합니다.
6. 설정을 추가하고 확인을 클릭한 후 CDN 로그 백업 규칙이 생성될 때까지 기다립니다. 생성이 완료되면 리스트에서 이미 생성된 CDN 로그 백업 규칙을 조회할 수 있습니다.
새로 생성한 CDN 로그 백업 규칙에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 CDN 로그 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
더 보기 > 편집을 클릭하여 CDN 로그 백업 규칙을 수정합니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 CDN 로그 백업 규칙을 삭제합니다.
CLS 로그 백업
최종 업데이트 날짜:：2024-10-24 18:58:08
소개
CLS 로그 백업은 Tencent Cloud COS가 Serverless Cloud Function을 기반으로 제공하는 기능으로, 사용자가 Cloud Log Service(CLS) 로그를 COS에 저장할 수 있도록 합니다.
사용자가 지정 버킷에 로그 백업 규칙을 설정하면 SCF가 일정 시간 간격으로 CLS 로그를 획득하여 COS 버킷에 저장합니다.
CLS 로그 백업은 제품 생태계 다운 플로우를 통해 로그 데이터를 COS에 전송하여 로그 백업 시나리오 니즈를 충족시키고, 로그 데이터의 가치를 발굴합니다. 로그 백업은 비동기화 과정으로, 로그 데이터가 생성되면, SCF가 트리거를 통해 자동으로 데이터를 COS에 백업하여 저장합니다.
주의 사항
COS 콘솔에서 버킷에 CLS 로그 백업 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 CLS 로그 백업 함수를 볼 수 있습니다. 해당 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
광저우, 상하이, 베이징, 중국 홍콩, 청두, 싱가포르, 실리콘밸리 등 SCF를 런칭한 리전은 CLS 로그의 COS 백업을 지원합니다. 지원 리전에 대한 자세한 내용은 SCF 제품 문서를 참고하십시오.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 데이터 백업을 클릭하고 CLS 로그 백업을 찾습니다.
3. 백업 규칙 설정을 클릭하여 규칙 설정 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
연결 버킷: CLS 로그 파일을 저장할 COS 버킷입니다.
로그셋: 로그셋 은 CLS의 프로젝트 관리 단위로, 서로 다른 프로젝트의 로그를 구분하기 위해 사용됩니다. 메시지 소스의 로그셋을 선택할 수 있으며, 해당 로그셋은 반드시 함수가 있는 리전에 위치해야 합니다.
로그 토픽: 로그 토픽(Topic)은 CLS의 기본 관리 단위로, CLS 트리거를 관리 및 설정하는 최소 단위입니다. 한 로그셋에 여러 개의 로그 토픽이 포함될 수 있습니다. 메시지 소스의 로그 토픽을 선택할 수 있습니다.
최대 대기 시간: 대기 시간 설정을 통해 로그 획득 빈도를 컨트롤 할 수 있으며, 3 - 300초 사이로 설정 가능합니다. 만약 최대 대기 시간인 300초로 설정하였을 경우, SCF는 300초 이내의 로그 데이터를 수집하고, 로그 파일로 패키징하여 백업합니다.
SCF 라이선스: CLS 로그 백업은 SCF에 권한을 부여하여 CLS 서비스를 이용할 때 로그 파일을 읽고 지정 버킷에 저장하므로 해당 라이선스 추가가 필요합니다.
6. 다음 단계를 클릭하여 다음 정보를 설정합니다.
압축 설정: 로그를 압축한 후 백업할 것인지 선택합니다. 압축 후 용량은 최대 128KB까지 지원합니다. 현재 지원되는 압축 형식은 gzip, lzop, snappy입니다.
파티션 형식: strftime 구문에 따라 디렉터리를 자동으로 생성합니다. 예: 파티션 형식이 %Y/%m/%d/%Y%m%d%H%M인 경우, 2021/06/25/202106252232 디렉터리가 생성됩니다.
디렉터리 접두사: 로그 백업 경로, 루트 디렉터리 또는 지정된 경로 접두사에 백업할 수 있습니다.
전달 파일 예시: 최종 백업된 파일명 형식은 {COS 버킷}{디렉터리 접두사}{파티션 형식}_{random}.{type}입니다.
7. 설정을 추가하고 확인을 클릭한 후 CLS 로그 백업 규칙이 생성될 때까지 기다립니다. 생성이 완료되면 리스트에서 이미 생성된 CLS 로그 백업 규칙을 조회할 수 있습니다.
새로 생성한 CLS 로그 백업 규칙에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭해 CLS 로그 백업 기록을 조회합니다. 백업 시 오류가 보고된 경우 로그를 클릭하고 빠르게 SCF 콘솔에 리디렉션하여 로그 오류 상세 내용을 조회할 수 있습니다.
더 보기 > 편집을 클릭하여 CLS 로그 백업 규칙을 수정합니다.
더 보기 > 삭제를 클릭하여 사용하지 않는 CLS 로그 백업 규칙을 삭제합니다.
로그 분석 함수 추가
최종 업데이트 날짜:：2025-05-21 18:47:09
소개
Cloud Object Storage(COS) 로그 분석은 로그 파일에서 주요 정보를 보다 효율적으로 추출할 수 있도록 다양한 시나리오의 로그 분석 서비스를 제공합니다. 본 문서는 COS 로그 분석 함수를 추가하는 방법에 대해 설명하고 있으며, 함수 생성 후 로그 분석 설정을 참고하여 COS 로그 분석 기능을 사용하시기 바랍니다.
주의 사항
COS 콘솔에서 버킷에 COS 로그 분석 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 COS 로그 분석 함수를 볼 수 있습니다. 해당 COS 로그 분석 함수를 삭제하지 마십시오. 삭제할 경우 규칙이 적용되지 않을 수 있습니다.
현재 기능은 COS와 SCF가 동일한 리전에 있을 때만 지원되며, 일부 리전(예: 충칭 리전)은 사용이 지원되지 않습니다. 사용 가능 여부는 COS 및 SCF 콘솔의 리전 표시를 기준으로 합니다.
COS 로그 분석 기능은 SCF 서비스에 종속됩니다. SCF 서비스는 사용자에게 Free Tier를 제공하며 무료 한도를 초과분에 대해서는 SCF Pricing에 따라 청구됩니다.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 확장 기능을 클릭하고 COS 로그 분석을 찾습니다.
3. 분석 기능 구성을 클릭하여 COS 로그 분석의 함수 규칙 구성 페이지로 이동합니다.
4. 페이지에서 함수 추가 리전을 선택하고 함수 추가를 클릭한 후 팝업 창에서 다음 정보를 설정합니다.
함수 이름: 함수 이름은 함수의 고유한 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 확인할 수 있습니다.
연결된 버킷: 로그 분석 기능이 설정된 COS 버킷을 선택합니다.
실행 구성: 현재 비동기화 실행만 지원합니다. 호출 후 비동기화 실행 상태가 되면 실행 결과를 반환하지 않지만, 충분한 실행 시간을 지원합니다.
인증 방식: 현재 SCF 인증만 지원합니다.
로그 저장 상태: 로그 저장 상태가 활성화되어 있는지 확인해야 합니다. 조작 안내는 로그 저장 설정을 참조하십시오.
SCF 인증: COS 로그 분석은 SCF가 귀하의 스토리지 버킷에서 해당 파일을 읽고, 로그 분석 결과 파일을 지정된 위치에 저장하도록 인증해야 하므로 이 옵션을 체크해야 SCF 서비스 인증이 완료됩니다.
5. 설정이 올바른지 확인한 후 확인을 클릭하면 잠시 후 함수 추가되며, 팝업 메시지에 따라 버킷의 로그 관리 설정 항목으로 이동하여 로그 분석 작업을 생성할 수 있습니다. 자세한 내용은 COS 로그 분석을 참조하십시오.
6. 새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
사용 안내를 클릭하면 사용 안내를 다시 열고 COS 버킷으로 빠르게 이동할 수 있습니다.
로그를 클릭하면, COS 로그 분석 함수의 이전 실행 상황을 조회할 수 있습니다.
세부 사항을 클릭하면, COS 로그 분석 함수의 특정 설정 규칙을 조회할 수 있습니다.
더 보기 > 편집을 클릭하여, COS 로그 분석 함수 규칙을 수정합니다.
더 보기 > 삭제를 클릭하여, 사용하지 않는 COS 로그 분석 함수 규칙을 삭제합니다.
CKafka로 데이터 내보내기
최종 업데이트 날짜:：2024-06-24 16:23:48
소개
CKafka로 데이터 내보내기는 Serverless Cloud Function 기반의 Tencent Cloud COS에서 제공하는 데이터 내보내기 솔루션으로, 사용자는 CSV, JSON 등의 파일 형식의 데이터를 리전 내 Tencent Cloud CKafka 서비스로 내보낼 수 있으며, 대용량 메시지 및 로그 데이터의 취합 분석에 사용됩니다.
주의 사항
CKafka로 데이터 내보내기 기능에는 COS 데이터 인덱스 인터페이스가 포함되며, 제한 사항에 대한 자세한 내용은 Select 개요를 참고하십시오.
COS 콘솔에서 버킷에 CKafka로 데이터 내보내기 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 CKafka로 데이터를 내보내기 함수를 확인할 수 있습니다. CKafka로 데이터 내보내기 함수를 삭제하거나 수정하지 마십시오. 그렇지 않으면 규칙이 적용되지 않을 수 있습니다.
현재 CKafka로 데이터 내보내기 기능은 광저우, 상하이, 베이징, 청두만 지원합니다.
COS CKafka로 데이터를 내보내기 기능은 SCF 서비스에 종속됩니다. SCF 서비스는 사용자에게 Free Tier를 제공하며 무료 한도를 초과한 부분에 대해서는 SCF Pricing에 따라 청구됩니다.
2. 왼쪽 사이드바에서 애플리케이션 통합 > 데이터 내보내기를 클릭하고 CKafka로 데이터 내보내기를 찾습니다.
3. 규칙 설정을 클릭하여 규칙 설정 페이지로 이동합니다.
4. 함수 추가를 클릭합니다.
주의：
SCF 서비스가 활성화되지 않은 경우 SCF 콘솔에서 SCF 서비스를 활성화하고 안내에 따라 서비스 권한 부여를 완료하십시오.
5. 팝업 창에서 다음과 같이 정보를 설정합니다.
함수 이름 접두사: 함수의 고유 식별자로, 생성 후에는 수정할 수 없습니다. SCF 콘솔에서 해당 함수를 조회할 수 있습니다.
시나리오 선택: 내보낼 로그 소스를 선택하십시오. COS 로그 파일 내보내기 사용을 권장합니다.
소스 버킷: 로그가 저장되는 버킷의 이름으로, COS 로그 파일 내보내기를 선택하는 경우 먼저 COS 로그 스토리지 기능을 활성화해야 합니다.
로그 스토리지 상태: 로그 스토리지 상태가 활성화되어 있는지 확인해야 합니다.
전달 버킷: 로그가 저장될 버킷입니다.
로그 접두사 전달: 로그를 찾기 쉬운 경로 접두사를 입력합니다.
SCF 권한 부여: CKafka로 데이터를 내보내려면 SCF가 버킷에서 로그 파일을 읽을 수 있는 권한이 필요합니다. 따라서 이 권한 부여를 추가해야 합니다.
6. 사전 설정 매개변수 입력을 클릭하여 CKafka로 데이터 내보내기를 설정합니다. 설정 항목에 대한 설명은 다음과 같습니다.
액세스 방법: CKafka의 액세스 방법입니다. VPC 내부 네트워크 액세스를 선택하는 경우 해당 VPC를 입력해야 합니다.
액세스 주소: CKafka의 액세스 주소입니다.
주제 이름: 생성한 CKafka 주제의 이름입니다.
인증 설정: CKafka 인증 방식으로 인증 필요를 선택하면 해당 사용자 이름과 사용자 비밀번호를 입력해야 합니다.
속도 최댓값: CKafka로 내보내기 위한 속도 최댓값입니다.
7. 일부 맞춤 설정된 로그 데이터 추출은 이전을 클릭하여 설정할 수 있습니다. 일반적으로 확인을 직접 클릭하여 함수 추가를 완료할 것을 권장합니다.
새로 생성한 함수에 다음과 같은 작업을 진행할 수 있습니다.
로그를 클릭하여 CKafka로 데이터 내보내기의 이전 실행을 조회합니다. CKafka로 데이터 내보내기 시 오류가 발생하면 로그를 클릭하여 SCF 콘솔로 빠르게 리디렉션하여 로그 오류 세부 정보를 조회할 수도 있습니다.
세부 사항을 클릭하면 현재 함수의 설정 세부 사항을 볼 수 있습니다.
편집을 클릭하여 CKafka로 데이터 내보내기 규칙을 수정합니다.
트리거를 클릭하여 버킷의 기존 로그를 선택하고 CKafka로 내보내기를 직접 트리거할 수 있습니다.
삭제를 클릭하여 사용하지 않는 CKafka로 데이터 내보내기 규칙을 삭제합니다.
ES로 데이터 내보내기
최종 업데이트 날짜:：2024-06-24 16:23:48
소개
Elasticsearch Service(ES)로 데이터 내보내기는 Serverless Cloud Function 기반의 Tencent Cloud COS에서 제공하는 데이터 내보내기 솔루션으로, 사용자는 CSV, JSON 등의 파일 형식의 데이터를 리전 내 Tencent Cloud Elasticsearch 서비스로 내보낼 수 있으며, 로그 분석, 이상 모니터링 등 다양한 서비스를 빠르게 구축하는데 사용됩니다.
주의 사항
ES로 데이터 내보내기 기능에는 COS 데이터 인덱스 인터페이스가 포함됩니다. 제한 사항에 대한 자세한 내용은 Select 개요를 참고하십시오.
COS 콘솔에서 버킷에 ES로 데이터 내보내기 규칙을 추가한 적이 있는 경우 SCF 콘솔에서 기존에 생성한 ES로 데이터 내보내기 함수를 확인할 수 있습니다. 이 ES로 데이터 내보내기 함수를 삭제하거나 수정하지 마십시오. 삭제 및 수정할 경우 규칙이 적용되지 않을 수 있습니다.
현재 ES로 데이터 내보내기 기능은 광저우, 상하이, 베이징, 청두만 지원합니다.
COS의 ES로 데이터 내보내기 기능은 SCF 서비스에 종속됩니다. SCF 서비스는 사용자에게 Free Tier를 제공하며 무료 한도를 초과한 부분에 대해서는 SCF Pricing에 따라 청구됩니다.
