이 아키텍처는 BigQuery 백업 전략을 개발하는 데 도움이 되는 프레임워크와 참조 배포를 제공합니다. 이 권장 프레임워크와 자동화는 조직이 다음을 수행하는 데 도움이 될 수 있습니다.
- 조직의 재해 복구 목표를 준수합니다.
- 인적 오류로 인해 손실된 데이터를 복구합니다.
- 규정 준수
- 운영 효율성 개선
BigQuery 데이터의 범위에는 폴더, 프로젝트, 데이터 세트, 테이블이 포함되거나 제외될 수 있습니다. 이 권장 아키텍처에서는 반복되는 백업 작업을 대규모로 자동화하는 방법을 보여줍니다. 각 테이블에 BigQuery 스냅샷과 Cloud Storage로의 BigQuery 내보내기라는 두 가지 백업 방법을 사용할 수 있습니다.
이 문서는 조직에서 데이터 정책을 정의하고 자동화하려는 클라우드 설계자, 엔지니어, 데이터 거버넌스 책임자를 대상으로 합니다.
아키텍처
다음 다이어그램은 자동 백업 아키텍처를 보여줍니다.
위의 다이어그램에 표시된 워크플로에는 다음 단계가 포함됩니다.
- Cloud Scheduler는 포함 및 제외된 BigQuery 데이터의 범위가 포함된 Pub/Sub 메시지를 통해 Dispatcher 서비스 실행을 트리거합니다. 실행은 크론 표현식을 사용하여 예약됩니다.
- Cloud Run에 빌드된 디스패처 서비스는 BigQuery API를 사용하여 BigQuery 범위 내에 있는 테이블을 나열합니다.
- 전달 서비스는 Pub/Sub 메시지를 통해 구성기 서비스에 각 테이블에 대한 요청을 하나씩 제출합니다.
Cloud Run 구성 도구 서비스는 다음과 같이 정의된 옵션 중 하나에서 테이블의 백업 정책을 계산합니다.
- 데이터 소유자가 정의하는 테이블 수준 정책입니다.
- 정의된 정책이 없는 테이블에 대해 데이터 거버넌스 책임자가 정의하는 대체 정책입니다.
백업 정책에 대한 자세한 내용은 백업 정책을 참고하세요.
구성 도구 서비스는 계산된 백업 정책에 따라 각 테이블에 대해 하나의 요청을 다음 서비스에 제출합니다.
백업 방법에 따라 다음 커스텀 Cloud Run 서비스 중 하나가 BigQuery API에 요청을 제출하고 백업 프로세스를 실행합니다.
- BigQuery 스냅샷 서비스는 테이블을 스냅샷으로 백업합니다.
- 데이터 내보내기 서비스는 테이블을 Cloud Storage로의 데이터 내보내기로 백업합니다.
백업 방법이 테이블 데이터 내보내기인 경우 Cloud Logging 로그 싱크는 다음 단계의 비동기 실행을 사용 설정하기 위해 내보내기 작업 완료 이벤트를 리슨합니다.
백업 서비스가 작업을 완료하면 Pub/Sub가 태그 지정 서비스가 트리거됩니다.
태그 지정 서비스는 각 테이블의 백업 서비스 결과를 로깅하고 Cloud Storage 메타데이터 영역에서 백업 상태를 업데이트합니다.
사용 제품
이 참조 아키텍처에는 다음과 같은 Google Cloud 제품이 사용됩니다.
- BigQuery: 머신러닝 지리 정보 분석 및 비즈니스 인텔리전스와 같은 기본 제공 기능으로 데이터를 관리 및 분석하는 데 도움이 되는 엔터프라이즈 데이터 웨어하우스입니다.
- Cloud Logging: 스토리지, 검색, 분석, 알림을 지원하는 실시간 로그 관리 시스템입니다.
- Pub/Sub: 메시지 생성 서비스를 메시지 처리 서비스와 분리하는 비동기식의 확장 가능한 메시징 서비스입니다.
- Cloud Run: Google의 확장 가능한 인프라에서 직접 컨테이너를 실행할 수 있게 해주는 서버리스 컴퓨팅 플랫폼입니다.
- Cloud Storage: 다양한 데이터 유형에 적합한 저비용, 무제한 객체 저장소입니다. Google Cloud 내부 및 외부에서 데이터에 액세스할 수 있고 중복성을 위해 여러 위치에 복제됩니다.
- Cloud Scheduler: 지정된 시간 또는 일정한 간격으로 실행되도록 예약된 작업 단위를 설정할 수 있는 엔터프라이즈 수준의 완전 관리형 크론 작업 스케줄러입니다.
- Datastore: 웹 및 모바일 애플리케이션을 위한 확장성 높은 NoSQL 데이터베이스입니다.
사용 사례
이 섹션에서는 이 아키텍처를 사용할 수 있는 사용 사례의 예시를 제공합니다.
백업 자동화
예를 들어 회사가 규제되는 업계에서 운영되고 BigQuery를 기본 데이터 웨어하우스로 사용하는 경우를 들 수 있습니다. 회사에서 소프트웨어 개발, 코드 검토, 출시 엔지니어링에 관한 모범 사례를 따르더라도 인적 오류로 인해 데이터가 손실되거나 손상될 위험이 있습니다. 규제되는 업계에서는 이러한 위험을 최대한 최소화해야 합니다.
이러한 인적 오류의 예는 다음과 같습니다.
- 테이블을 실수로 삭제한 경우
- 잘못된 데이터 파이프라인 로직으로 인한 데이터 손상
이러한 유형의 인적 오류는 일반적으로 최대 7일 전의 데이터를 복구할 수 있는 시간 여행 기능으로 해결할 수 있습니다. 또한 BigQuery는 장애 안전 기간을 제공합니다. 이 기간에는 삭제된 데이터가 시간 이동 기간 후 7일 동안 장애 안전 스토리지에 보관됩니다. 이 데이터는 Cloud Customer Care를 통해 긴급 복구에 사용할 수 있습니다. 그러나 이 총 기간 내에 이러한 오류를 발견하고 수정하지 않으면 삭제된 데이터를 더 이상 마지막 안정적인 상태에서 복구할 수 없습니다.
이 문제를 완화하려면 소스 데이터에서 재구성할 수 없는 BigQuery 테이블 (예: 이전 레코드 또는 진화하는 비즈니스 로직이 적용된 KPI)에 대해 정기적으로 백업을 실행하는 것이 좋습니다.
회사에서 기본 스크립트를 사용하여 수십 개의 테이블을 백업할 수 있습니다. 하지만 조직 전반에서 수백 또는 수천 개의 테이블을 정기적으로 백업해야 하는 경우 다음을 실행할 수 있는 확장 가능한 자동화 솔루션이 필요합니다.
- 다양한 Google Cloud API 한도를 처리합니다.
- 백업 정책을 정의하기 위한 표준화된 프레임워크를 제공합니다.
- 백업 작업에 투명성과 모니터링 기능을 제공합니다.
백업 정책
회사에서 다음 사용자 그룹이 백업 정책을 정의하도록 요구할 수도 있습니다.
- 테이블에 가장 익숙하고 적절한 테이블 수준 백업 정책을 설정할 수 있는 데이터 소유자
- 데이터 거버넌스팀: 테이블 수준 정책이 없는 테이블을 처리하기 위한 대체 정책이 마련되어 있는지 확인합니다. 대체 정책을 사용하면 회사의 데이터 보관 규정을 준수하기 위해 특정 데이터 세트, 프로젝트, 폴더가 백업됩니다.
이 참조 아키텍처의 배포에서 테이블의 백업 정책을 정의하는 방법에는 두 가지가 있으며, 이 두 가지 방법을 함께 사용할 수 있습니다.
데이터 소유자 구성 (분산형): 테이블에 수동으로 연결되는 테이블 수준 백업 정책입니다.
- 데이터 소유자가 공통 버킷에 저장되는 테이블 수준 JSON 파일을 정의합니다.
- 솔루션에서 테이블의 백업 정책을 결정할 때 수동 정책이 대체 정책보다 우선 적용됩니다.
- 배포에 관한 자세한 내용은 테이블 수준 백업 정책 설정을 참고하세요.
조직 기본 구성 (중앙 집중식): 수동으로 연결된 정책이 없는 테이블에만 적용되는 대체 정책입니다.
- 데이터 거버넌스팀은 솔루션의 일부로 Terraform에서 중앙 JSON 파일을 정의합니다.
- 대체 정책은 폴더, 프로젝트, 데이터 세트, 테이블 수준에서 기본 백업 전략을 제공합니다.
- 배포에 관한 자세한 내용은 대체 백업 정책 정의를 참고하세요.
백업과 복제 비교
백업 프로세스는 데이터가 손실되거나 손상된 경우 복원할 수 있도록 특정 시점의 테이블 데이터 사본을 만듭니다. 백업은 일회성으로 실행하거나 예약된 쿼리 또는 워크플로를 통해 반복적으로 실행할 수 있습니다. BigQuery에서는 스냅샷을 사용하여 특정 시점 백업을 실행할 수 있습니다. 스냅샷을 사용하여 7일의 시간 여행 기간을 초과한 데이터 사본을 소스 데이터와 동일한 저장소 위치에 보관할 수 있습니다. BigQuery 스냅샷은 지역 장애 복구보다는 데이터 손실 또는 손상으로 이어지는 인적 오류 후 데이터를 복구하는 데 특히 유용합니다. BigQuery는 버전에 따라 99.9% ~99.99%의 서비스 수준 목표 (SLO)를 제공합니다.
반면 복제는 데이터베이스 변경사항을 다른 위치의 보조 (또는 복제) 데이터베이스로 복사하는 연속적인 프로세스입니다. BigQuery에서 리전 간 복제를 사용하면 소스 데이터 리전과 다른 보조 Google Cloud 리전에 데이터의 읽기 전용 사본을 만들어 지역 중복을 제공할 수 있습니다. 하지만 BigQuery 리전 간 복제는 전체 리전 중단 시나리오의 재해 복구 계획용으로 의도되지 않았습니다. 지역 재해에 대한 복원력을 높이려면 BigQuery 관리형 재해 복구를 사용하는 것이 좋습니다.
BigQuery 교차 리전 복제는 데이터 소비자와 가까운 리전에 데이터의 동기화된 읽기 전용 사본을 제공합니다. 이러한 데이터 사본을 사용하면 공동 배치된 조인을 사용하고 리전 간 트래픽과 비용을 방지할 수 있습니다. 그러나 사람의 실수로 인한 데이터 손상인 경우 손상된 데이터가 자동으로 복제본에 복사되므로 복제만으로는 복구에 도움이 되지 않습니다. 이 경우 특정 시점 백업 (스냅샷)을 사용하는 것이 더 좋습니다.
다음 표는 백업 방법과 복제 방법을 요약하여 비교한 것입니다.
| 메서드 | 빈도 | 스토리지 위치 | 사용 사례 | 비용 |
|---|---|---|---|---|
| 백업 (스냅샷 또는 Cloud Storage 내보내기) |
일회성 또는 반복적으로 | 소스 테이블 데이터와 동일 | 시간 여행 기간을 초과한 원본 데이터 복원 | 스냅샷에는 스냅샷의 데이터 변경사항에 대해서만 스토리지 요금이 청구됩니다. 내보내기에는 표준 스토리지 요금이 청구될 수 있습니다. 비용 최적화를 참고하세요. |
| 리전 간 복제 | 지속적인 | 원격 | 다른 리전에 복제본 만들기 리전 간 일회성 이전 |
복제본에 데이터 저장 요금이 발생합니다. 데이터 복제 비용이 발생합니다. |
설계 고려사항
이 섹션에서는 이 참조 아키텍처를 사용하여 보안, 안정성, 비용 최적화, 운영 효율성, 성능에 대한 특정 요구사항을 충족하는 토폴로지를 개발할 때 고려해야 할 사항을 안내합니다.
보안, 개인정보 보호, 규정 준수
배포는 설계 및 구현에 다음과 같은 보안 조치를 통합합니다.
- Cloud Run의 네트워크 인그레스 설정은 인터넷에서의 액세스를 제한하기 위해 내부 트래픽만 허용합니다. 또한 인증된 사용자와 서비스 계정만 서비스를 호출할 수 있습니다.
- 각 Cloud Run 서비스 및 Pub/Sub 구독은 필요한 권한만 할당된 별도의 서비스 계정을 사용합니다. 이렇게 하면 시스템에 하나의 서비스 계정을 사용하는 것과 관련된 위험을 완화하고 최소 권한의 원칙을 따를 수 있습니다.
개인 정보 보호를 위해 이 솔루션은 개인 식별 정보 (PII)를 수집하거나 처리하지 않습니다. 그러나 소스 테이블에 노출된 PII가 있는 경우 이러한 테이블의 백업에도 노출된 데이터가 포함됩니다. 소스 데이터의 소유자는 소스 테이블의 모든 개인 식별 정보를 보호할 책임이 있습니다 (예: 열 수준 보안, 데이터 마스킹 또는 삭제 적용). 백업은 소스 데이터가 안전한 경우에만 안전합니다. 또 다른 방법은 노출된 PII가 포함된 백업 데이터를 보유한 프로젝트, 데이터 세트 또는 버킷에 승인된 사용자만 액세스할 수 있도록 제한하는 필수 Identity and Access Management (IAM) 정책이 적용되어 있는지 확인하는 것입니다.
범용 솔루션인 참조 배포는 특정 업계의 특정 요구사항을 반드시 준수하지는 않습니다.
안정성
이 섹션에서는 안정성에 관한 기능과 설계 고려사항을 설명합니다.
세부사항을 고려한 실패 완화
수천 개의 테이블을 백업하려면 기본 Google Cloud 제품의 API 한도 (예: 각 프로젝트의 스냅샷 및 내보내기 작업 한도)에 도달할 수 있습니다. 그러나 구성 오류나 기타 일시적인 문제로 인해 한 테이블의 백업이 실패하더라도 전체 실행 및 다른 테이블을 백업하는 기능에는 영향을 미치지 않습니다.
잠재적인 실패를 완화하기 위해 참조 배포는 세분화된 Cloud Run 서비스를 사용하고 Pub/Sub을 통해 연결하여 처리 단계를 분리합니다. 테이블 백업 요청이 마지막 태그 지정 서비스 단계에서 실패하면 Pub/Sub은 이 단계만 다시 시도하고 전체 프로세스를 다시 시도하지 않습니다.
하나의 Cloud Run 서비스에서 호스팅되는 여러 엔드포인트 대신 흐름을 여러 Cloud Run 서비스로 분할하면 각 서비스 구성을 세부적으로 제어할 수 있습니다. 구성 수준은 서비스의 기능과 통신하는 API에 따라 다릅니다. 예를 들어 전달자 서비스는 실행당 한 번 실행되지만 BigQuery 백업 범위 내의 모든 테이블을 나열하는 데 상당한 시간이 걸립니다. 따라서 디스패처 서비스에는 더 높은 시간 제한 및 메모리 설정이 필요합니다. 하지만 BigQuery 스냅샷용 Cloud Run 서비스는 단일 실행에서 테이블당 한 번 실행되며 디스패처 서비스보다 짧은 시간에 완료됩니다. 따라서 Cloud Run 서비스에는 서비스 수준에서 다른 구성 세트가 필요합니다.
데이터 일관성
테이블과 뷰 간의 데이터 일관성은 안정적인 백업 전략을 유지하는 데 매우 중요합니다. 데이터는 지속적으로 업데이트되고 수정되므로 서로 다른 시점에 찍은 백업은 데이터 세트의 서로 다른 상태를 캡처할 수 있습니다. 이러한 백업이 서로 다른 상태로 있으면 데이터를 복원할 때 특히 동일한 기능 데이터 세트에 속하는 테이블의 경우 불일치가 발생할 수 있습니다. 예를 들어 판매 테이블을 해당 인벤토리 테이블과 다른 시점으로 복원하면 사용 가능한 재고가 일치하지 않을 수 있습니다. 마찬가지로 여러 테이블의 데이터를 집계하는 데이터베이스 뷰는 불일치에 특히 민감할 수 있습니다. 기본 테이블이 일관된 상태인지 확인하지 않고 이러한 뷰를 복원하면 부정확하거나 혼동을 야기하는 결과가 나올 수 있습니다. 따라서 BigQuery 백업 정책 및 빈도를 설계할 때는 이러한 일관성을 고려하고 복원된 데이터가 특정 시점의 데이터 세트의 실제 상태를 정확하게 반영하는지 확인해야 합니다.
예를 들어 이 참조 아키텍처의 배포에서 데이터 일관성은 백업 정책의 다음 두 구성을 통해 제어됩니다. 이러한 구성은 모든 테이블을 동시에 백업하지 않고도 시간 이동을 통해 정확한 테이블 스냅샷 시간을 계산합니다.
backup_cron: 테이블이 백업되는 빈도를 제어합니다. 실행의 시작 타임스탬프는 이 실행에서 백업된 모든 테이블의 시간 이동 계산을 위한 참조점으로 사용됩니다.backup_time_travel_offset_days: 테이블의 정확한 시간 여행 버전을 계산하기 위해 시간 참조점 (실행 시작 시간)에서 빼야 하는 과거 일 수를 제어합니다.
자동 백업 복원
이 참조 아키텍처는 대규모 백업 자동화에 중점을 두지만 이러한 백업을 자동화된 방식으로 복원할 수도 있습니다. 이 추가 자동화는 다운타임이 줄어들면서 복구 효율성과 속도가 개선되는 등 백업 자동화와 유사한 이점을 제공할 수 있습니다. 이 솔루션은 태그 지정 서비스에서 모든 백업 매개변수와 결과를 추적하므로 유사한 아키텍처를 개발하여 대규모로 복원 작업을 적용할 수 있습니다.
예를 들어 BigQuery 데이터 범위를 디스패처 서비스로 전송하는 주문형 트리거를 기반으로 솔루션을 만들 수 있습니다. 이 디스패처 서비스는 구성기 서비스에 테이블당 하나의 요청을 전달합니다. 구성 도구 서비스는 특정 테이블에 대해 원하는 백업 기록을 가져올 수 있습니다. 그러면 구성 도구 서비스는 BigQuery 스냅샷 복원 서비스 또는 Cloud Storage 복원 서비스에 전달하여 적절하게 복원 작업을 적용할 수 있습니다. 마지막으로 태그 지정 서비스는 이러한 작업의 결과를 상태 저장소에 저장할 수 있습니다. 이렇게 하면 자동 복원 프레임워크가 이 문서에 설명된 백업 프레임워크와 동일한 설계 목표의 이점을 누릴 수 있습니다.
비용 최적화
이 아키텍처의 프레임워크는 전반적인 비용 최적화를 위해 다음 매개변수를 설정하는 백업 정책을 제공합니다.
- 백업 메서드: 프레임워크는 다음 두 가지 백업 메서드를 제공합니다.
- BigQuery 스냅샷: 기본 테이블과 비교하여 업데이트 및 삭제된 데이터를 기준으로 스토리지 비용이 발생합니다. 따라서 스냅샷은 추가 전용 테이블이나 업데이트가 제한된 테이블에 더 비용 효율적입니다.
- BigQuery에서 Cloud Storage로 내보내기: 표준 스토리지 요금이 청구됩니다. 그러나 자르기 및 로드 접근 방식을 따르는 대용량 테이블의 경우 덜 비싼 스토리지 클래스에서 내보내기로 백업하는 것이 더 비용 효율적입니다.
- 스냅샷 만료: 스냅샷에 대한 스토리지 비용이 무한정 발생하지 않도록 단일 테이블 스냅샷에 TTL (수명)이 설정됩니다. 테이블에 만료일이 없으면 시간이 지남에 따라 스토리지 비용이 늘어날 수 있습니다.
운영 효율성
이 섹션에서는 운영 효율성을 위한 기능과 고려사항을 설명합니다.
세분화되고 확장 가능한 백업 정책
이 프레임워크의 목표 중 하나는 비즈니스 입력을 비교적 낮고 관리 가능한 수준으로 유지하면서 비즈니스 출력을 확장하여 운영 효율성을 높이는 것입니다. 예를 들어 출력은 정기적으로 백업되는 테이블의 수가 많지만 입력은 유지되는 백업 정책 및 구성의 수가 적습니다.
이 프레임워크는 테이블 수준에서 백업 정책을 허용하는 것 외에도 데이터 세트, 프로젝트, 폴더, 전역 수준에서 정책을 허용합니다. 즉, 상위 수준 (예: 폴더 또는 프로젝트 수준)에서 몇 가지 구성만으로 수백 또는 수천 개의 테이블을 정기적으로 대규모로 백업할 수 있습니다.
관측 가능성
자동화 프레임워크를 사용하려면 프로세스의 상태를 이해하는 것이 중요합니다. 예를 들어 다음과 같은 일반적인 검색어에 대한 정보를 찾을 수 있습니다.
- 시스템에서 각 테이블에 사용하는 백업 정책입니다.
- 각 테이블의 백업 기록 및 백업 위치
- 단일 실행의 전반적인 상태 (처리된 테이블 수 및 실패한 테이블 수)입니다.
- 단일 실행에서 발생한 치명적인 오류와 이러한 오류가 발생한 프로세스의 구성요소 또는 단계입니다.
이 정보를 제공하기 위해 배포는 Cloud Run 서비스를 사용하는 각 실행 단계에서 Cloud Logging에 구조화된 로그를 씁니다. 로그에는 입력, 출력, 오류와 기타 진행 상황 체크포인트가 포함됩니다. 로그 싱크는 이러한 로그를 BigQuery 테이블로 라우팅합니다. 여러 쿼리를 실행하여 일반적인 관측 가능성 사용 사례에 대해 실행을 모니터링하고 보고서를 가져올 수 있습니다. BigQuery의 로그 및 쿼리에 관한 자세한 내용은 BigQuery로 라우팅된 로그 보기를 참고하세요.
성능 최적화
각 실행에서 수천 개의 테이블을 처리하기 위해 솔루션은 백업 요청을 동시에 처리합니다. 전달 서비스는 BigQuery 백업 범위에 포함된 모든 테이블을 나열하고 각 실행 시 테이블당 하나의 백업 요청을 생성합니다. 이렇게 하면 애플리케이션에서 수천 개의 요청과 테이블을 순차적으로가 아니라 동시에 처리할 수 있습니다.
이러한 요청 중 일부는 기본 Google Cloud API의 한도에 도달하거나 네트워크 문제가 발생하는 등 일시적인 이유로 처음에 실패할 수 있습니다. 요청이 완료될 때까지 Pub/Sub은 지수 백오프 재시도 정책을 사용하여 요청을 자동으로 다시 시도합니다. 잘못된 백업 대상 또는 누락된 권한과 같은 심각한 오류가 있는 경우 오류가 로깅되고 전체 실행에 영향을 주지 않으면서 해당 테이블 요청의 실행이 종료됩니다.
한도
이 아키텍처에는 다음 할당량과 한도가 적용됩니다.
테이블 스냅샷의 경우 지정하는 각 백업 작업 프로젝트에 다음이 적용됩니다.
- 하나의 프로젝트에서 최대 100개의 동시 테이블 스냅샷 작업을 실행할 수 있습니다.
- 하나의 프로젝트에서 하루에 최대 50,000개의 테이블 스냅샷 작업을 실행할 수 있습니다.
- 하나의 프로젝트에서 하루에 테이블당 최대 50개의 테이블 스냅샷 작업을 실행할 수 있습니다.
자세한 내용은 테이블 스냅샷을 참고하세요.
내보내기 작업 (Cloud Storage로 내보내기)의 경우 다음이 적용됩니다.
- 공유 슬롯 풀을 사용하여 프로젝트에서 하루에 최대 50TiB의 데이터를 무료로 내보낼 수 있습니다.
- 하나의 프로젝트에서 하루에 최대 100,000회의 내보내기를 실행할 수 있습니다. 이 한도를 늘리려면 슬롯 예약을 만드세요.
이러한 한도를 연장하는 방법에 관한 자세한 내용은 작업 내보내기를 참고하세요.
동시 실행 제한과 관련하여 이 아키텍처는 Pub/Sub를 사용하여 이러한 제한으로 인해 실패한 요청을 API에서 처리할 때까지 자동으로 다시 시도합니다. 그러나 프로젝트당 하루의 작업 수에 대한 다른 제한의 경우 할당량 증가 요청을 제출하거나 백업 작업 (스냅샷 또는 내보내기)을 여러 프로젝트에 분산하여 완화할 수 있습니다. 프로젝트에 작업을 분산하려면 다음 배포 섹션에 설명된 대로 백업 정책을 구성합니다.
배포
이 아키텍처를 배포하려면 확장 가능한 BigQuery 백업 자동화 배포를 참고하세요.
다음 단계
- BigQuery에 대해 자세히 알아보세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
저자: 카림 와디 | 전략적 클라우드 엔지니어
기타 참여자:
- 크리스 디포레스트 | 사이트 안정성 엔지니어
- Eyal Ben Ivri | 클라우드 솔루션 설계자
- Jason Davenport | 개발자 애드보킷
- 잘리야 에카나야케 | 엔지니어링 관리자
- 무함마드 자인 | 전략적 클라우드 엔지니어