Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
이 튜토리얼에서는 Cloud Composer에서 실패한 Airflow DAG를 디버그하고, 로그 및 환경 모니터링을 사용하여 작업자 메모리 또는 저장공간 부족과 같은 작업자 리소스 관련 문제를 진단하는 단계를 제공합니다.
소개
이 튜토리얼에서는 DAG를 디버그하는 방법을 보여주는 리소스 관련 문제를 중점적으로 설명합니다.
할당된 작업자 리소스가 없으면 DAG 오류가 발생합니다. Airflow 태스크에 메모리 또는 스토리지가 부족하면 다음과 같은 Airflow 예외가 표시될 수 있습니다.
WARNING airflow.exceptions.AirflowException: Task received SIGTERM signal
INFO - Marking task as FAILED.
또는
Task exited with return code Negsignal.SIGKILL
이러한 경우 일반적으로 Airflow 작업자 리소스를 늘리거나 작업자당 태스크 수를 줄이는 것이 좋습니다. 그러나 Airflow 예외가 일반적이라서 문제를 일으키는 특정 리소스를 식별하는 것이 어려울 수 있습니다.
이 튜토리얼에서는 DAG 실패 이유를 진단하고 작업자 메모리 및 스토리지 부족으로 인해 실패하는 두 가지 예시 DAG를 디버그하여 문제를 일으키는 리소스 유형을 식별하는 방법을 설명합니다.
목표
다음과 같은 이유로 실패한 예시 DAG를 실행합니다.
- 작업자 메모리 부족
- 작업자 스토리지 부족
실패 이유 진단
할당된 작업자 리소스 늘리기
새 리소스 한도로 DAG 테스트
비용
이 튜토리얼에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
이 튜토리얼을 마치면 만든 리소스를 삭제하여 비용이 계속 청구되지 않도록 할 수 있습니다. 자세한 내용은 삭제를 참조하세요.
시작하기 전에
이 섹션에서는 튜토리얼을 시작하기 전에 필요한 작업을 설명합니다.
프로젝트 생성 및 구성
이 튜토리얼에는 Google Cloud 프로젝트가 필요합니다. 다음과 같은 방법으로 프로젝트를 구성합니다.
Google Cloud 콘솔에서 프로젝트를 선택하거나 만듭니다.
프로젝트에 결제가 사용 설정되어 있는지 확인합니다. 프로젝트에 결제가 사용 설정되어 있는지 확인하는 방법을 알아보세요.
Google Cloud 프로젝트 사용자에게 필요한 리소스를 만들 수 있는 다음 역할이 있는지 확인합니다.
- 환경 및 스토리지 객체 관리자(
roles/composer.environmentAndStorageObjectAdmin) - Compute 관리자(
roles/compute.admin) - 모니터링 편집자 (
roles/monitoring.editor)
- 환경 및 스토리지 객체 관리자(
프로젝트에 API 사용 설정
Cloud Composer API 사용 설정
Cloud Composer 환경 만들기
환경을 만들 때 Composer 서비스 에이전트 계정에 Cloud Composer v2 API 서비스 에이전트 확장 프로그램(roles/composer.ServiceAgentV2Ext) 역할을 부여합니다. Cloud Composer는 이 계정을 사용하여 Google Cloud 프로젝트에서 작업을 수행합니다.
작업자 리소스 한도 확인
해당 환경에서 Airflow 작업자 리소스 한도를 확인합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
환경 목록에서 환경 이름을 클릭합니다. 환경 세부정보 페이지가 열립니다.
환경 구성 탭으로 이동합니다.
리소스 > 워크로드 구성 > 작업자로 이동합니다.
값이 vCPU 0.5개, 메모리 1.875GB, 스토리지 1GB인지 확인합니다. 다음은 이 튜토리얼의 다음 단계에서 사용하는 Airflow 작업자 리소스 한도입니다.
예: 메모리 부족 문제 진단
다음 샘플 DAG를 이전 단계에서 만든 환경에 업로드합니다. 이 튜토리얼에서 이 DAG의 이름은 create_list_with_many_strings입니다.
이 DAG에는 다음 단계를 실행하는 태스크 하나가 포함됩니다.
s라는 빈 목록을 만듭니다.- 주기를 실행하여 목록에
More문자열을 추가합니다. - 목록이 소비하는 메모리 양을 출력하고 1분 반복마다 1초 동안 대기합니다.
import time
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import sys
from datetime import timedelta
default_args = {
'start_date': airflow.utils.dates.days_ago(0),
'retries': 0,
'retry_delay': timedelta(minutes=10)
}
dag = DAG(
'create_list_with_many_strings',
default_args=default_args,
schedule_interval=None)
def consume():
s = []
for i in range(120):
for j in range(1000000):
s.append("More")
print(f"i={i}; size={sys.getsizeof(s) / (1000**3)}GB")
time.sleep(1)
t1 = PythonOperator(
task_id='task0',
python_callable=consume,
dag=dag,
depends_on_past=False,
retries=0
)
샘플 DAG 트리거
create_list_with_many_strings라는 샘플 DAG를 트리거합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
Airflow 웹 서버 열에서 해당 환경의 Airflow 링크를 따릅니다.
Airflow 웹 인터페이스의 DAG 페이지에 있는 해당 DAG의 링크 열에서 DAG 트리거 버튼을 클릭합니다.
트리거를 클릭합니다.
DAG 페이지에서 트리거한 태스크를 클릭하고 출력 로그를 검토하여 DAG가 실행되었는지 확인합니다.
태스크가 실행되는 동안 출력 로그는 DAG가 사용 중인 메모리 크기(GB)를 출력합니다.
몇 분 후 Airflow 작업자 메모리 한도인 1.875GB가 초과되므로 태스크가 실패합니다.
실패한 DAG 진단
오류 발생 시 여러 태스크를 실행한 경우 하나의 태스크만 실행하고 해당 기간 동안 리소스 압력을 진단하여 리소스 압력을 유발하는 태스크와 늘려야 하는 리소스를 식별합니다.
Airflow 태스크 로그 검토
create_list_with_many_strings DAG의 태스크가 Failed 상태인지 확인합니다.
태스크의 로그를 검토합니다. 다음과 같은 로그 항목이 표시됩니다.
```none
{local_task_job.py:102} INFO - Task exited with return code
Negsignal.SIGKILL
```
`Netsignal.SIGKILL` might be an indication of your task using more memory
than the Airflow worker is allocated. The system sends
the `Negsignal.SIGKILL` signal to avoid further memory consumption.
워크로드 검토
워크로드를 검토하여 태스크 부하로 인해 포드가 실행되는 노드가 메모리 소비 한도를 초과하지 않는지 확인합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
환경 목록에서 환경 이름을 클릭합니다. 환경 세부정보 페이지가 열립니다.
환경 구성 탭으로 이동합니다.
리소스 > GKE 클러스터 > 워크로드에서 클러스터 워크로드 보기를 클릭합니다.
일부 워크로드 포드의 상태가 다음과 유사한지 확인합니다.
Error with exit code 137 and 1 more issue. ContainerStatusUnknown with exit code 137 and 1 more issueExit code 137은 컨테이너 또는 포드가 허용된 것보다 많은 메모리를 사용하려 함을 의미합니다. 메모리 사용을 방지하기 위해 프로세스가 종료됩니다.
환경 상태 및 리소스 소비 모니터링 검토
환경 상태 및 리소스 소비 모니터링을 검토합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
환경 목록에서 환경 이름을 클릭합니다. 환경 세부정보 페이지가 열립니다.
Monitoring 탭으로 이동하고 개요를 선택합니다.
환경 개요 패널에서 환경 상태(Airflow 모니터링 DAG) 그래프를 찾습니다. 여기에는 로그가 오류 출력을 시작한 시간에 해당하는 빨간색 영역이 포함됩니다.
작업자를 선택하고 총 작업자 메모리 사용량 그래프를 찾습니다. 메모리 사용량 선에서 태스크가 실행된 시점에 급상승 구간이 있는 것을 확인합니다.
실패 이유를 진단할 때는 그래프의 메모리 사용량 선이 한도에 도달하지 않더라도 할당 가능한 메모리만 고려해야 하며, 그래프의 메모리 한도 선은 사용 가능한 총 메모리(GKE에서 예약한 용량 포함)를 나타냅니다.
이 예시에서는 작업자 메모리 한도가 1.875GB로 설정되었습니다. GKE는 처음 4GiB 메모리 중 25%를 예약합니다. 또한 GKE는 kubelet 제거를 위해 각 노드에 100MiB 메모리라는 추가 eviction-threshold를 예약합니다.
할당 가능한 메모리는 다음과 같은 방식으로 계산됩니다.
ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD
메모리 한도가 1.875GB인 경우 실제 할당 가능한 메모리는 다음과 같습니다.
1.75 GiB (1.875GB) - 0.44 (25% GiB reserved) - 0.1 = 1.21 GiB (~1.3 GB).
이 실제 한도를 메모리 사용량 그래프에 추가하면 태스크의 메모리 사용량 급상승 구간이 실제 메모리 한도에 도달하는 것을 확인할 수 있으며, 작업자 메모리 부족으로 인해 태스크가 실패했다고 결론을 내릴 수 있습니다.
작업자 메모리 한도 늘리기
샘플 DAG가 성공할 수 있도록 추가 작업자 메모리를 할당합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
환경 목록에서 환경 이름을 클릭합니다. 환경 세부정보 페이지가 열립니다.
환경 구성 탭으로 이동합니다.
리소스 > 워크로드 구성을 찾고 수정을 클릭합니다.
작업자 섹션의 메모리 필드에서 Airflow 작업자의 새 메모리 한도를 지정합니다. 이 튜토리얼에서는 3GB를 사용합니다.
변경사항을 저장하고 Airflow 작업자가 다시 시작될 때까지 몇 분 정도 기다립니다.
새 메모리 한도로 DAG 테스트
create_list_with_many_strings DAG를 다시 트리거하고 실행이 완료될 때까지 기다립니다.
DAG 실행의 출력 로그에
Marking task as SUCCESS가 표시되고 태스크 상태가 성공으로 표시됩니다.Monitoring 탭의 환경 개요 섹션을 검토하고 빨간색 영역이 없는지 확인합니다.
작업자 섹션을 클릭하고 총 작업자 메모리 사용량 그래프를 찾습니다. 메모리 한도 선은 메모리 한도의 변경사항을 반영하며 메모리 사용량 선은 실제 할당 가능한 메모리 한도보다 훨씬 낮은 것을 확인할 수 있습니다.
예: 스토리지 부족 문제 진단
이 단계에서는 대용량 파일을 만드는 DAG 두 개를 업로드합니다. 첫 번째 DAG는 큰 파일을 만듭니다. 두 번째 DAG는 대용량 파일을 만들고 장기 실행 작업을 모방합니다.
두 DAG의 파일 크기는 기본 Airflow 작업자 스토리지 한도인 1GB를 초과하지만 두 번째 DAG에는 인위적으로 기간을 연장하는 추가 대기 태스크가 있습니다.
다음 단계에서는 두 DAG 동작의 차이점을 살펴봅니다.
대용량 파일을 만드는 DAG 업로드
다음 샘플 DAG를 이전 단계에서 만든 환경에 업로드합니다. 이 튜토리얼에서 이 DAG의 이름은 create_large_txt_file_print_logs입니다.
이 DAG에는 다음 단계를 실행하는 태스크 하나가 포함됩니다.
- Airflow 작업자 스토리지에 1.5GB
localfile.txt파일을 씁니다. - Python
os모듈을 사용하여 만든 파일의 크기를 출력합니다. - DAG 실행 지속 시간을 1분 단위로 출력합니다.
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time
default_args = {
'start_date': airflow.utils.dates.days_ago(0),
'retries': 0,
'retry_delay': timedelta(minutes=10)
}
dag = DAG(
'create_large_txt_file_print_logs',
default_args=default_args,
schedule_interval=None)
def consume():
size = 1000**2 # bytes in 1 MB
amount = 100
def create_file():
print(f"Start creating a huge file")
with open("localfile.txt", "ab") as f:
for j in range(15):
f.write(os.urandom(amount) * size)
print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")
create_file()
print("Success!")
t1 = PythonOperator(
task_id='create_huge_file',
python_callable=consume,
dag=dag,
depends_on_past=False,
retries=0)
장기 실행 작업으로 대용량 파일을 만드는 DAG 업로드
장기 실행 DAG를 모방하고 태스크 기간이 종료 상태에 미치는 영향을 살펴보려면 두 번째 샘플 DAG를 환경에 업로드합니다. 이 튜토리얼에서 이 DAG의 이름은 long_running_create_large_txt_file_print_logs입니다.
이 DAG에는 다음 단계를 실행하는 태스크 하나가 포함됩니다.
- Airflow 작업자 스토리지에 1.5GB
localfile.txt파일을 씁니다. - Python
os모듈을 사용하여 만든 파일의 크기를 출력합니다. - 파일에서 읽기와 같은 파일 작업에 필요한 시간을 모방할 때까지 1시간 15분 동안 기다립니다.
- DAG 실행 지속 시간을 1분 단위로 출력합니다.
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time
default_args = {
'start_date': airflow.utils.dates.days_ago(0),
'retries': 0,
'retry_delay': timedelta(minutes=10)
}
dag = DAG(
'long_running_create_large_txt_file_print_logs',
default_args=default_args,
schedule_interval=None)
def consume():
size = 1000**2 # bytes in 1 MB
amount = 100
def create_file():
print(f"Start creating a huge file")
with open("localfile.txt", "ab") as f:
for j in range(15):
f.write(os.urandom(amount) * size)
print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")
create_file()
for k in range(75):
time.sleep(60)
print(f"{k+1} minute")
print("Success!")
t1 = PythonOperator(
task_id='create_huge_file',
python_callable=consume,
dag=dag,
depends_on_past=False,
retries=0)
샘플 DAG 트리거
첫 번째 DAG인 create_large_txt_file_print_logs를 트리거합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
Airflow 웹 서버 열에서 해당 환경의 Airflow 링크를 따릅니다.
Airflow 웹 인터페이스의 DAG 페이지에 있는 해당 DAG의 링크 열에서 DAG 트리거 버튼을 클릭합니다.
트리거를 클릭합니다.
DAG 페이지에서 트리거한 태스크를 클릭하고 출력 로그를 검토하여 DAG가 실행되었는지 확인합니다.
create_large_txt_file_print_logsDAG로 만든 태스크가 완료될 때까지 기다립니다. 이 작업은 몇 분 정도 걸릴 수 있습니다.DAG 페이지에서 DAG 실행을 클릭합니다. 스토리지 한도를 초과했더라도 태스크는
Success상태로 표시됩니다.
태스크 Airflow 로그를 검토합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
환경 목록에서 환경 이름을 클릭합니다. 환경 세부정보 페이지가 열립니다.
로그 탭으로 이동한 후 모든 로그 > Airflow 로그 > 작업자 > 로그 탐색기에서 보기로 이동합니다.
유형별로 로그를 필터링하여 오류 메시지만 표시합니다.
로그에 다음과 비슷한 메시지가 표시됩니다.
Worker: warm shutdown (Main Process)
또는
A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.
이러한 로그는 사용한 스토리지가 한도를 초과하여 1시간 내에 제거되었기 때문에 포드가 '웜 종료' 프로세스를 시작했음을 나타냅니다. 하지만 DAG 실행은 Kubernetes 종료 유예 기간 내에 완료되었으므로 실패하지 않았습니다. 종료 유예 기간은 이 튜토리얼에 자세히 설명되어 있습니다.
종료 유예 기간의 개념을 보여주는 두 번째 샘플 DAG long_running_create_large_txt_file_print_logs의 결과를 검토하세요.
두 번째 DAG인 long_running_create_large_txt_file_print_logs를 트리거합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
Airflow 웹 서버 열에서 해당 환경의 Airflow 링크를 따릅니다.
Airflow 웹 인터페이스의 DAG 페이지에 있는 해당 DAG의 링크 열에서 DAG 트리거 버튼을 클릭합니다.
트리거를 클릭합니다.
DAG 페이지에서 트리거한 태스크를 클릭하고 출력 로그를 검토하여 DAG가 실행되었는지 확인합니다.
long_running_create_large_txt_file_print_logsDAG 실행이 실패할 때까지 기다립니다. 약 1시간 정도 걸릴 수 있습니다.
DAG 실행 결과를 검토합니다.
DAG 페이지에서
long_running_create_large_txt_file_print_logsDAG 실행을 클릭합니다. 태스크는Failed상태이고 실행 시간은 정확히 1시간 5분이었음을 알 수 있습니다. 이는 태스크의 대기 시간인 1시간 15분보다 짧습니다.태스크의 로그를 검토합니다. DAG가 Airflow 작업자의 컨테이너에
localfile.txt파일을 만들면 DAG가 대기를 시작한 후 1분 간격으로 태스크 로그에 실행 기간이 출력됩니다. 이 예시에서 DAG는localfile.txt size:로그를 출력하며localfile.txt파일의 크기는 1.5GB입니다.
Airflow 작업자의 컨테이너에 기록된 파일이 스토리지 한도를 초과하면 DAG 실행이 실패합니다. 하지만 태스크는 즉시 실패하지 않으며 기간이 1시간 5분에 도달할 때까지 계속 실행됩니다. 왜냐하면 Kubernetes가 태스크를 즉시 종료하고 '종료 유예 기간'이라고 하는 1시간의 복구 시간 동안 계속 실행되기 때문입니다. 노드의 리소스가 부족하면 Kubernetes 종료 처리를 유예하기 위해 포드를 즉시 종료하지 않으므로 최종 사용자에게 미치는 영향이 최소화됩니다.
종료 유예 기간은 사용자가 태스크 실패 후 파일을 복구하는 데 도움이 되지만 DAG를 진단할 때 혼란을 초래할 수 있습니다. Airflow 작업자 스토리지 한도를 초과하면 DAG 실행 기간에 따라 최종 태스크 상태가 달라집니다.
DAG 실행이 작업자 스토리지 한도를 초과하더라도 1시간 이내에 완료되면 태스크가 종료 유예 기간 내에 완료되었으므로
Success상태로 완료됩니다. 하지만 Kubernetes가 포드를 종료하고 기록된 파일이 컨테이너에서 즉시 삭제됩니다.DAG가 작업자 스토리지 한도를 초과하고 1시간 넘게 실행되면 DAG가 1시간 동안 계속 실행되어 스토리지 한도를 수천 퍼센트 초과할 수 있습니다. 그러면 Kubernetes가 포드를 제거하고 Airflow가 태스크를
Failed로 표시합니다.
실패한 DAG 진단
오류 발생 시 여러 태스크를 실행한 경우 하나의 태스크만 실행하고 해당 기간 동안 리소스 압력을 진단하여 리소스 압력을 유발하는 태스크와 늘려야 하는 리소스를 식별합니다.
두 번째 DAG인 long_running_create_large_txt_file_print_logs의 태스크 로그를 검토합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
환경 목록에서 환경 이름을 클릭합니다. 환경 세부정보 페이지가 열립니다.
로그 탭으로 이동한 후 모든 로그 > Airflow 로그 > 작업자 > 로그 탐색기에서 보기로 이동합니다.
유형별로 로그를 필터링하여 오류 메시지만 표시합니다.
로그에 다음과 비슷한 메시지가 표시됩니다.
Container storage usage of worker reached 155.7% of the limit.
This likely means that the total size of local files generated by your DAGs is
close to the storage limit of worker.
You may need to decrease the storage usage or increase the worker storage limit
in your Cloud Composer environment configuration.
또는
Pod storage usage of worker reached 140.2% of the limit.
A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.
This eviction likely means that the total size of dags and plugins folders plus
local files generated by your DAGs exceeds the storage limit of worker.
Please decrease the storage usage or increase the worker storage limit in your
Cloud Composer environment configuration.
이러한 메시지는 다음을 나타냅니다. 태스크가 진행됨에 따라 DAG로 생성된 파일의 크기가 작업자 스토리지 한도를 초과했을 때 Airflow 로그가 오류 출력을 시작했으며 종료 유예 기간이 시작되었습니다. 종료 유예 기간 동안 스토리지 소비 한도가 복구되지 않아 종료 유예 기간이 종료된 후 포드가 제거되었습니다.
환경 상태 및 리소스 소비 모니터링을 검토합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
환경 목록에서 환경 이름을 클릭합니다. 환경 세부정보 페이지가 열립니다.
Monitoring 탭으로 이동하고 개요를 선택합니다.
환경 개요 패널에서 환경 상태(Airflow 모니터링 DAG) 그래프를 찾습니다. 여기에는 로그가 오류 출력을 시작한 시간에 해당하는 빨간색 영역이 포함됩니다.
작업자를 선택하고 총 작업자 디스크 사용량 그래프를 찾습니다. 태스크가 실행되었을 당시에 디스크 사용량 선이 급상승하고 디스크 한도 선을 초과하는지 확인합니다.
작업자 스토리지 한도 늘리기
샘플 DAG가 성공할 수 있도록 추가 Airflow 작업자 스토리지를 할당합니다.
Google Cloud 콘솔에서 환경 페이지로 이동합니다.
환경 목록에서 환경 이름을 클릭합니다. 환경 세부정보 페이지가 열립니다.
환경 구성 탭으로 이동합니다.
리소스 > 워크로드 구성을 찾고 수정을 클릭합니다.
작업자 섹션의 스토리지 필드에서 Airflow 작업자의 새 스토리지 한도를 지정합니다. 이 튜토리얼에서는 2GB로 설정합니다.
변경사항을 저장하고 Airflow 작업자가 다시 시작될 때까지 몇 분 정도 기다립니다.
새 스토리지 한도로 DAG 테스트
long_running_create_large_txt_file_print_logs DAG를 다시 트리거하고 실행이 완료될 때까지 1시간 15분 동안 기다립니다.
DAG 실행의 출력 로그에
Marking task as SUCCESS가 표시되고 태스크 상태가 성공으로 표시됩니다. 이는 DAG 코드에 설정된 대기 시간과 동일한 1시간 15분 동안 지속됩니다.Monitoring 탭의 환경 개요 섹션을 검토하고 빨간색 영역이 없는지 확인합니다.
작업자 섹션을 클릭하고 총 작업자 디스크 사용량 그래프를 찾습니다. 디스크 한도 선은 스토리지 한도의 변경사항을 반영하며 디스크 사용량 선은 허용 범위 내에 있는 것을 확인할 수 있습니다.
요약
이 튜토리얼에서는 DAG 실패 이유를 진단하고 작업자 메모리 및 스토리지 부족으로 인해 실패하는 두 가지 예시 DAG를 디버그하여 압박을 일으키는 리소스 유형을 식별했습니다. 그런 다음 작업자에 더 많은 메모리와 스토리지를 할당한 후 DAG를 성공적으로 실행했습니다. 그러나 특정 기준점을 초과하여 리소스를 늘리는 것은 불가능하므로, 애초에 작업자 리소스 소비를 줄일 수 있도록 DAG를 최적화(워크플로)하는 것이 바람직합니다.
삭제
이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트는 유지하되 개별 리소스를 삭제하세요.
프로젝트 삭제
- Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
- 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
- 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.
개별 리소스 삭제
여러 튜토리얼과 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.
Cloud Composer 환경을 삭제합니다. 이 절차 동안의 환경 버킷도 삭제합니다.