https://www.coursera.org/에서 제공되는 Google Cloud Fundamentals: Core Infrastructure 강의를 수강 시작한다. 일주일 동안 무료로 진행되기 때문에, 이후 49달러를 내기 싫다면 일주일간 부단하게 강의를 완벽하게 이해하고 수료해야 한다. 그나저나 한국어가 지원되지 않는 점이 조금 아쉽긴 하다.
[1주차] 코스 소개
구글 클라우드는 Compute, Storage, Big Data, Machine Learning, Application Services로 구분된다.
이 강의를 들으며 내가 이해해야 할 것은 6가지이다. 강의가 끝났을 때 아래의 6가지에 답할 수 있기를 바란다.
1. 구글 클라우드 제품 및 서비스의 목적과 가치 파악하기
2. 구글 클라우드에서 인프라가 어떻게 구성되고 제어되는지 정의하기
3. 구글 클라우드에서 기본 인프라를 만드는 방법 설명하기
4. 구글 스토리지 옵션을 선택하고 사용하는 방법 설명하기
5. 구글 쿠버네티스 엔진의 목적과 가치 설명하기
6. 서버리스 구글 클라우드 서비스의 사용 사례 파악하기
[2주차] 구글 클라우드 소개
학습목표
1. 구글 클라우드의 이점 파악하기
2. 실재 지점, 데이터 센터, 리전과 존을 포함하여 구글 네트워크 인프라의 구성 요소 정의하기
3. 서비스형 인프라(IaaS)와 서비스형 플랫폼(PaaS)의 차이점 파악하기
[2-1] 클라우드 컴퓨팅 개요
미국 NIST에서 클라우드 컴퓨팅이라는 용어를 만들었는데, 클라우드 컴퓨팅은 5가지 중요한 특성을 지닌 정보 기술(IT)을 사용하는 하나의 방법이다.
1. 고객은 온-디맨드 및 셀프 서비스인 컴퓨팅 리소스를 얻는다. 웹 인터페이스를 통해 사용자는 인간의 개입 없이 그들이 필요로 하는 처리 능력, 스토리지, 네트워크를 얻는다.
2. 고객은 인터넷을 통해 연결된 모든 곳에서 이러한 리소스에 엑세스할 수 있다.
3. 클라우드 제공업체는 엄청난 풀의 해당 리소스를 보유하고 있으며, 리소스를 해당 풀에서 사용자들에게 할당한다. 그렇기에 제공업제는 대량으로 리소스를 구매하여 그것을 고객에게 덜어낼 수 있는 것이다. 대량으로 구매하는 것에 대한 부담을 고객들에게 지우는 느낌이랄까. 이때 고객은 해당 리소스의 정확한 물리적 위치를 신경 쓸 필요도, 알 필요도 없다. 이것은 위의 2번에서 이미 이유가 설명된다.
4. 리소스는 탄력적이다. 무슨 말이냐면, 그것들은 유연하고, 그렇기에 고객도 그에 따라 반응할 수 있다. 더 많은 리소스가 필요하면 그만큼 더 많이, 신속하게 얻으면 된다. 반대로, 리소스가 조금만 필요하다면 규모를 축소하면 그만인 일이다.
5. 고객들은 그들이 사용한 것이나, 사용하기로 예정한 것에 대해서만 값을 지불한다. 만약 리소스 사용을 멈춘다면, 지불도 멈추는 것이다.
이 다섯 가지가 클라우드의 정의이다. 그렇다면 클라우드 모델은 왜 이렇게나 핫한 걸까?
클라우드 컴퓨팅에 대한 트렌드는 Colocation으로 알려진 제 1의 물결에서 시작됐다. 이는 고객에게 데이터 센터를 위한 부동산에 투자하는 것을 대신하여, 물리적인 공간을 렌트하는 것에 대한 재정적 부담을 덜어주었다.
제 2의 물결은 오늘날의 가상화된 데이터 센터다. 이것은 수십 년 전에 이미 있었던 프라이빗 데이터 센터, 그리고 콜로케이션 시설과 유사점이 존재한다. 가상화된 데이터 센터의 구성 요소는 호스팅되는 컴퓨팅의 물리적 구성(서버, CPU, 디스크, 로드 밸런서 등)과 일치하지만, 그것들이 가상화 장치가 된 것이다. 가상화를 통해 각 기업은 여전히 인프라를 유지하지만, 사용자 제어 및 사용자 구성 환경 또한 남게 됐다.
몇 년 전, 구글은 그들의 비즈니스가 가상화 모델의 '제한' 안에서는 충분한 속도를 낼 수 없음을 인지했다. 그래서 구글은 컨테이너 기반 아키텍처, 즉 완전히 자동화된 클라우드로 전환하게 된 것이다. 이것이 제 3의 물결이다. 이 클라우드는 자동화된 서비스와 확장 및 축소가 가능한 데이터의 조합으로 이루어져 있다. 서비스는 애플리케이션을 실행하기 위해 사용되는 인프라를 자동으로 프로비저닝하고 구성한다. 그래서 구글은 이 3의 물결 클라우드를 구글 고객들이 이용할 수 있도록 하고 있다.
구글은 미래에 특정 규모나 산업에 무관하게 모든 회사가 기술력을 통해 경쟁사들과의 차별점을 확보할 것이라 믿고 있다. 그리고 여기서의 '기술력'이란, 점점 더 소프트웨어의 형태가 될 것이다. 훌륭한 소프트웨어 기술이란, 결국 높은 퀄리티의 데이터를 기반으로 한다. 이것은 결국, 모든 회사가 데이터 회사화 될 것을 시사한다.
[2-2] IaaS 와 PaaS
실제 데이터 센터에서 가상화된 데이터 센터로 이동하면서 고객들은 2가지의 제공을 얻게 됐다. 그것이 IaaS와 PaaS인 것이다. IaaS는 온-디맨드 인프라 리소스를 클라우드를 통해 제공한다. raw compute, 스토리지, 네트워크 기능 같은 것을 말이다. IaaS는 리소스가 가상으로 구성되어 있으며, 이는 물리적인 데이터 센터와 유사하다. 컴퓨팅 엔진은 구글 클라우드 IaaS 서비스의 예시라고 할 수 있다.
이와 달리, PaaS는 인프라 애플리케이션 요구사항에 엑세스를 제공하는 라이브러리에 코드를 바인딩한다. 이를 통해 더 많은 리소스가 애플리케이션 로직에 집중될 수 있다. 앱 엔진이 구글 클라우드 PaaS 서비스의 예시라고 할 수 있다. IaaS 모델에서 고객은 할당한 리소스에 대해 미리 비용을 지불한다. 하지만 PaaS에서는 고객은 실제 사용하는 리소스에 대해서 비용을 지불할 뿐이다.
클라우드 컴퓨팅이 발전함에 따라, 흐름은 관리형 인프라 및 관리형 서비스로 넘어가고 있다. 관리형 인프라와 서비스를 활용하면, 기업은 더욱 그들의 비즈니스 목표에 집중할 수 있고, 그들의 기술 인프라를 구성하고 유지하는 데에 있어 시간과 비용을 아낄 수 있다. 따라서 기업은 고객에게 그들의 제품과 서비스를 신속하고 안정적으로 제공할 수 있게 됐다.
서버리스는 클라우드 컴퓨팅의 또 다른 발전 단계이다. 이를 통해 인프라 관리의 필요성이 제거되면서, 개발자는 서버 구성이 아닌 그들의 코드에 집중할 수 있게 됐다. 구글이 제공하는 서버리스 기술에는 이벤트 기반 코드를 종량제 서비스로 관리하는 Cloud Functions와 고객이 컨테이너화된 마이크로서비스 기반 애플리케이션을 완전한 관리 환경에서 배포할 수 있는 Cloud Run이 포함된다.
한편, 이 강의의 범위 밖에 있기는 한데, 우리는 SaaS에 대해서도 이미 익히 들어 알고 있다. 그럼 그것은 무엇이고, 어떻게 클라우드 환경에 적합한 것일까? SaaS는 우리의 로컬 컴퓨터에 설치된 것이 아니다. 대신, 그것은 클라우드에서 서비스로서 실행되며, 최종 사용자가 인터넷을 통해 직접 사용한다. 우리에게 친숙한 Gmail, Docs, Drive같은 Google Workspace가 모두 SaaS의 예시인 것이다.
[2-3] 구글 클라우드 네트워크
구글 클라우드는 구글의 자체 글로벌 네트워크에서 운영된다. 그 분야에선 가장 큰 네트워크이고, 구글은 이 네트워크를 만들기 위해 수 년에 걸쳐 수십억 달러를 투자했다. 이 네트워크는 고객에게 가능한 최고의 처리량과 가능한 최저의 지연 시간을 제공하도록 설계됐다. 전 세계적으로 100개 이상의 콘텐츠 캐싱 노드를 활용해서 말이다. 이것은 더욱 빠른 엑세스를 위해 높은 수요의 콘텐츠가 캐시된 위치들로, 가장 빠른 응답시간을 제공할 위치로부터의 사용자 요청에 응답할 수 있도록 하는 허용한다. 간단히 말해, 엑세스 속도를 최고로 높인다는 것이다. 구글 클라우드의 이러한 '위치'라는 것은 그들이 고객을 위해 하는 모든 중요한 작업을 뒷받침하는 개념인 것이다. 많은 클라우드 리전들에서 해저 케이블을 통한 고대역폭 연결에 이르기까지, 구글 인프라의 모든 측면은 사용자가 전세계 어디에 있건 상관없이 사용자에게 서비스를 제공할 수 있도록 설계되었다.
구글 클라우드의 인프라는 5가지의 주요 지리적 위치에 기반을 두고 있다. 북미, 남미, 유럽, 아시아, 호주가 그 다섯이다. 5대륙에서 아프리카만 호주로 바뀐 것이다. 애플리케이션을 찾을 위치를 선택하는 것은 가용성, 내구성, 지연시간을 비롯한 품질에 영향을 미치므로, 여러 서비스 위치를 갖는 것이 중요하다. 여기서 지연시간이라 함은, 정보 패킷이 출발지에서 목적지까지 도달하는 데 걸리는 시간을 말한다.
그리고 '위치(location)'이라는 것은 이제 여러 개의 리전(regions)와 구역(zones)으로 나뉜다. 리전은 독립적인 지리적 지역을 나타내며, 여러 개의 구역으로 구성된다. 즉, 리전은 구역의 상위 개념인 것이다. 예를 들어, europe-west2라는 리전은 europe-west2-a, europe-west2-b, europe-west2-c의 3개 구역으로 구성된다.
구역은 구글 클라우드 리소스가 배포되는 영역이다. 예를 들어, 컴퓨트 엔진을 사용하여 가상 머신을 시작하는 경우, 리소스 중복을 보장하기 위해 우리가 지정한 구역에서 가상 머신이 실행된다. 물론, 우리는 다른 리전에서 리소스를 실행할 수도 있다. 이는 애플리케이션을 전 세계 사용자에게 더욱 가깝게 제공하며, 자연 재해와 같이 전체 리전에 문제가 생길 경우를 대비하여 보호하는 데 있어 매우 유용하다. 구글 클라우드의 서비스 중 일부는 우리가 이른바 멀티-리전이라 부르는 곳에 리소스를 배치하는 것을 지원한다. 예를 들어, 클라우드 스패너 멀티-리전 구성은 데이터베이스의 데이터를 복제하게 해주는데, 단순 여러 구역이 아니라, 여러 리전에 걸친 구역에서 그것을 가능케 허용한다. 인스턴스 구성에서 정의한 대로 말이다. 이러한 추가적인 복제본을 활용하면, 네덜란드와 벨기에와 같이, 구성 안에서 해당 리전 내에 있거나 혹은 가까이에 있는 여러 위치에서 낮은 지연시간으로 데이터를 읽을 수 있게 된다. 구글 클라우드는 현재 39개 리전, 118개의 구역을 지원하고 있지만, 이 숫자는 계속해서 늘어나고 있다. cloud.google.com/about/locations에서 업데이트되는 숫자를 확인할 수 있다.
[2-4] 환경적 영향
구글 클라우드의 네트워크를 포함한 가상 세계는 물리적 인프라를 기반으로 구축되었으며, humming 서버의 모든 랙은 엄청냔 양의 에너지를 사용한다. 전체로 보았을 때, 기존의 데이터 센터는 전 세계 전력의 약 2%만을 사용한다. 그래서 구글은 이를 인지하여, 그들의 데이터 센터를 가능한 효율적으로 운영하려 한다. 구글도 지구를 위해 올바른 일을 하려 노력한다는 것이다. 구글은 고객들이 각자의 환경적 목표를 갖고 있으며, 구글 클라우드에서 그들의 워크로드를 실행하는 일이 이러한 목표를 달성하는 데 일부가 될 수 있다는 것을 이해하고 있다. 실제로, 구글의 데이터 센터가 가장 먼저 ISO 14001 인증을 획득했다는 것은 그러한 말을 함에 있어 설득력이 있다고 할 수 있다. ISO 14001 인증은 조직이 자원 효율성 향상과 낭비의 감소를 통해 환경적 성능을 강화할 수 있는 구성을 위한 프레임워크를 마련하는 표준이다.
이것이 어떻게 이루어지고 있는 가에 대한 예시로, 핀란드의 하미나에 있는 구글 데이터 센터를 들 수 있다. 이 시설은 구글에서 가장 진보적이고 효율적인 데이터 센터 중 하나다. 핀란드 만의 해수를 사용하는 쿨링 시스템은 에너지 사용을 줄이게 만드는데, 이것은 세계 최초의 시설이다. 구글은 탄소 중립을 달성한 최초의 메이저 기업이 되었으며, 20년 간, 구글은 100% 재생에너지를 달성한 최초의 기업이었다. 구글은 이에 멈추지 않고, 2030년까지 완전히 탄소에서 벗어나는 최초의 메이저 기업이 되는 것을 목표로 하고 있다.
[2-5] 보안
구글의 서비스 중 9개에는 각각 10억 이상의 사용자가 존재한다. 정말이지 감탄이 나오는 숫자다. 이런 수 많은 사용자를 위한 보안 설계는 구글 클라우드와 구글 서비스가 운영하는 인프라 전반에 걸쳐 널리 퍼져 있다. 여기서는 구글이 고객의 데이터를 안전하게 보호하기 위해 노력하는 몇 가지에 대해 밝힌다. 보안 인프라는 점진적인 계층들로 설명될 수 있다. 데이터 센터의 물리적 보안에서 시작하여, 인프라의 기초가 되는 하드웨어와 소프트웨어가 어떻게 보안되는지, 마지막으로 운영 상의 보안을 지원하기 위한 프로세스와 기술적 제약을 설명하는 것에 이르기 까지 말이다.
먼저 하드웨어 인프라 계층은 3가지의 주요 보안 기능으로 구성된다. 첫 번째는, 하드웨어 설계 및 검증이다. 구글 데이터 센터의 서버 보드와 네트워킹 장비는 모두 구글에서 커스텀 디자인한 것이다. 구글은 또한 현재 서버와 주변장치에 모두 배포되고 있는 하드웨어 보안 칩을 포함하여 커스텀 칩을 디자인하고 있다. 다음으로 두 번째는, 보안 부트 스택이다. 구글 서버 머신은 다양한 기술을 활용하여 올바른 소프트웨어 스택을 부팅하고 있는지 확인한다. BIOS를 통한 암호화 서명, 부트로더, 커널, 기본 운영체제 이미지와 같은 것도 포함하여 말이다. 이 계층의 마지막 특징은 프레미스 보안이다. 구글은 여러 계층의 물리적 보안 및 보호 기능을 통합한 자체 데이터 센터를 설계하고 구축한다. 이러한 데이터 센터에 대한 엑세스는 매우 적은 수의 구글 직원들로만 제한된다. 그러니 저기에 들어갈 수 있다는 것만으로 자부심이 생기지 않을까 싶다. 구글은 데이터 센터 운영자가 제공하는 보안 계층 위에서 구글이 제어하는 물리적 보안 조치가 있는지 확인하는 제3자 데이터 센터에도 추가적으로 일부 서버를 호스트한다.
다음은 서비스 배포 계층으로, 서비스 간 통신의 암호화가 주요 특징이다. 구글의 인프라는 네트워크에서 원격 프로시저 호출(RPC) 데이터에 대한 암호화와 무결성을 제공한다. 구글의 서비스는 RPC를 사용하여 서로 통신한다. 따라서 인프라는 데이터 센터 간에 연결되는 모든 인프라 RPC 트래픽을 자동적으로 암호화한다. 구글은 이런 디폴트 암호화를 구글 데이터 센터 내의 모든 인프라 RPC 트래픽으로 확장할 수 있도록 하는 하드웨어 암호화 가속기를 배포하기 시작했다.
다음은 사용자 신분 계층이다. 일반적으로 구글 로그인 페이지로써 최종 사용자에게 보이는 구글의 중앙 신원 서비스는 단순히 사용자 이름과 패스워드 요구하는 것을 넘는다. 이 서비스는 사용자에게 그들이 과거에 동일한 장치 또는 유사한 장소에서 로그인했는지 여부와 같은 위험 요소를 기반으로 사용자에게 지능적으로 추가 정보를 요청한다. 생각해 보면, '새로운 장소에서 로그인되었다.', '새로운 기기에서 로그인되었다.' 등의 알림은 구글이 시작이었던 것 같기는 하다. 그리고 사용자는 로그인할 때 U2F 공개 표준에 기반한 장치를 포함하여, 2번째 팩터를 사용할 수도 있다. 이것이 그간 내가 줄창 주장한 기업의 기본적인 보안 자세인 것이다.
한편, 스토리지 서비스 계층에서는 정지 상태의 보안을 위한 암호화 기능이 있다. 구글에서의 대부분의 애플리케이션은 스토리지 서비스를 통해 물리적 스토리지(=파일 스토리지)에 간접적으로 엑세스하며, 중앙 관리 키를 사용하는 암호화는 이러한 스토리지 서비스 계층에서 적용된다. 또한, 구글은 하드 드라이브와 SSD에서 하드웨어 암호화 지원을 가능케 한다.
다음 계층은 인터넷 통신 계층이며, 여기에는 2가지 주요 보안 기능이 포함된다. 인터넷에서 사용할 수 있게 된 구글 서비스는 구글 프론트 엔드(GFE)라 불리는 인프라 서비스에 등록된다. 이 서비스는 모든 TLS 연결이 공개-비밀 키 쌍과 CA의 X.509 인증서를 사용하여 종료되도록 보장할 뿐만 아니라, 완벽한 비밀 전송을 지원하는 것과 같은 모범 사례를 따른다. 거기에 GFE는 DoS 공격에 대한 보호를 추가적으로 적용한다. 구글은 그들의 인프라 스케일 덕분에 많은 DoS 공격을 빨아들일 수 있다. 구글은 또한 멀티 티어를 갖고 있는데, GFE 뒤에서 실행되는 서비스에 대해 DoS 영향의 위험을 더욱 줄이는 다중 계층 DoS 보호 기능을 갖추고 있다.
마지막 계층은 4개의 핵심 기능을 제공하는 구글의 운영 보안 계층이다. 그 기능의 첫 번째는 침입 탐지다. 규칙과 기계 지능을 통해 구글 운영 보안 팀은 가능한 사고에 대한 경고를 제공한다. 구글은 탐지 및 대응 메커니즘의 효과를 측정하고 개선하기 위해 레드 팀 연습을 수행한다. 사실 이는 모든 메이저 기업이 당연히 수행해야 하는 일이기야 하다. 다음은 내부자 위험을 줄이는 일이다. 구글은 인프라에 대한 관리 권한을 받은 직원들의 활동을 적극적으로 제한하며, 또한 그들을 모니터링한다. 보통 이런 건축에서의 감리 같은 존재는 확실히 역할을 수행할 때는 정말 효과적이라 할 수 있다. 다음은 직원의 U2F 사용이다. 구글 직원을 향한 피싱 공격을 방어하기 위해 직원 계정은 U2F 호환 보안 키를 사용해야 한다. 마지막으로, 엄격한 소프트웨어 개발 관행이 있다. 구글은 중앙 소스 제어를 사용하며, 새로운 코드 리뷰를 위해서는 양측의 검토가 필요하다. 또한, 구글은 개발자들이 특정 클래스에 보안과 관련된 버그를 삽입하는 것을 방지하는 라이브러리를 제공한다. 추가적으로, 구글은 인프라 또는 애플리케이션 안에서 비용 지불을 통해 버그를 발견하고 알려줄 수 있는 취약점 보상 프로그램을 운영한다. 결국 이 보안 편을 읽으면서 느낀 것은, 구글은 모든 면에서 제로 트러스트를 실현하고 있다는 점이다. 그리고 cloud.google.com/security/security-design에서 구글의 기술-인프라 보안에 대한 추가 정보를 얻을 수 있다.
[2-6] 오픈 소스 생태계
일부 조직은 워크로드가 특정 공급업체에 갇힐 것을 우려하여, 워크로드를 클라우드로 가져오는 것을 꺼린다. 그러나 어떤 이유로든, 고객이 만약 구글이 더이상 그들의 니즈에 걸맞는 최고의 공급업체가 아니라고 판단하는 경우, 구글은 다른 곳에서 애플리케이션을 실행할 수 있는 기능을 제공한다. 이러한 기조는 구글의 검색 엔진만 보더라도 알 수 있다. 그들은 네이버를 비롯한 국내 검색 사이트와 달리, 사용자를 가두기를 원하지 않는다. 그들은 통로를 제공할 뿐이다. 다시 돌아와서, 구글은 오픈 소스 라이센스를 사용하여 기술의 핵심 요소를 공개하고, 그리하여 고객에게 구글 이외의 옵션을 선택할 수 있는 생태계를 조성한다. 예를 들어, 구글에서 개발된 머신 러닝용 오픈 소스 소프트웨어 라이브러리인 TensorFlow는 강력한 오픈 소스 생태계에 있어 핵심이라 할 수 있다. 구글은 스택의 여러 계층에서 상호운용성을 제공한다. 쿠버네티스와 구글 쿠버네티스 엔진은 고객이 서로 다른 클라우드에서 실행하는 마이크로서비스를 섞고, 매치할 수 있게 하는 기능을 제공하며, 구글 클라우드의 운영 제품군은 고객이 여러 클라우드 제공업체의 워크로드를 모니터링할 수 있도록 한다.
[2-7] 프라이싱 및 빌링
드디어 2주차의 마지막으로 구글 클라우드의 가격 책정 구조에 대해 알아보도록 한다. 구글은 메이저 클라우드 제공업체 중 처음으로 IaaS, 컴퓨트 오퍼링, 컴퓨트 엔진에 대한 초당 과금을 도입했다. 게다가 이제는 서비스형 컨테이너 인프라인 구글 쿠버네티스 엔진 사용자를 위한 초당 과금도 제공된다.
이는 빅데이터 시스템인 하둡과 동일하긴 하지만, 서비스로 운영되는 데이터 프로와 앱 엔진, 유연한 환경, 가상 머신, PaaS, 컴퓨트 엔진은 자동으로 적용되는 지속 사용 할인을 제공한다. 이 할인은 과금한 달의 상당 부분 동안 가상 머신 인스턴스를 실행할 때 얻을 수 있는 자동 할인이다. 특히 한 달에 25% 이상을 실행할 경우, 컴퓨트 엔진은 해당 인스턴스에 사용하는 매 분마다 자동으로 할인을 제공한다. 커스텀 가상 머신 타입을 선택하면, 컴퓨팅 엔진 가상 시스템을 애플리케이션에 맞게 최적의 가상 CPU와 메모리 양으로 미세 조정하여 워크로드에 맞게 가격을 조정할 수 있다. 한편, 구글의 온라인 가격 계산기는 고객이 비용을 추정하는 데 도움이 될 수 있다. cloud.google.com/products/calculator 에서 그러한 도움을 받을 수 있다.
그리고 우리는 이제 한 가지 고민이 생길 수 있다. 실수로 인해 엄청난 금액의 클라우드 비용 청구서가 발생하지 않게 하려면 어떻게 해야 하는지 말이다. 누구나 조직에서 실수하는 것을 좋아할 리는 없으니 말이다. 이에 우리는 빌링 계정 레벨이나 프로젝트 레벨에서 예산을 정의할 수 있다. 그 예산은 제한이 고정된 것일 수도 있고, 다른 메트릭과 연동될 수도 있을 것이다. 예를 들어, 전월 지출 비율이 있다. 비용이 우리의 예산 한도에 가까워지면, 우리는 알림을 생성해 받아 볼 수 있다. 예를 들어, 예산 한도가 2만 달러고, 그것의 90%에 달할 때 경고를 받게 설정한다면, 비용이 1.8만 달러에 도달할 때 우리는 경고를 받게 된다. 이 알림이라는 것은 일반적으로 50%, 90%, 100% 중에 선택할 수 있지만, 우리가 특정 퍼센트를 정의할 수도 있다. 그리고 보고서를 통해 구글 클라우드 콘솔의 시각적 도구로 프로젝트나 서비스를 기반으로 지출을 모니터링할 수도 있다.
마지막으로, 구글 클라우드는 '쿼터'의 개념을 구현한다. 계정 소유자와 구글 클라우드 커뮤니티 전체를 보호하는 오류 또는 악의적인 공격으로 인한 리소스 과소비를 방지하기 위해 설정된 '쿼터'의 개념이다. 이 분담 몫에는 '요금 쿼터'와 '할당 쿼터'의 2가지 유형이 존재한다. 둘다 프로젝트 레벨에서 적용되는 것으로, 요금 쿼터는 특정 시간 후에 리셋되는 것이다. 예를 들어, 기본적으로 GKE 서비스는 각 구글 클라우드 프로젝트에서 API에 대해 매 100초마다 3,000회의 호출 쿼터를 구현한다. 그 후, 100초가 지나면 제한은 리셋되는 것이다. 할당 쿼터는 프로젝트에서 가질 수 있는 리소스의 양을 결정한다. 예를 들어, 기본적으로 각 구글 클라우드 프로젝트에는 15개 이하의 가상 프라이빗 클라우드 네트워크를 허용하는 쿼터가 존재한다. 프로젝트는 모두 동일한 쿼터로 시작하지만, 구글 클라우드 서포트에서 증가를 요청하여 일부를 변경할 수 있다.
※ 퀴즈
3개 중 2개만 입력해도 통과라서 다소 허무했다. 그런데 fault tolerance 개념은 여기서 설명을 안해줬는데 문제 마다 나오길래 엥? 했다. 이 개념을 알고 있어서 다행이었다. fault tolerance는 결함 감내라는 의미로, 하드웨어나 소프트웨어에 결함, 오동작, 오류 등이 발생하더라도 진행 중인 작업이 훼손되거나, 데이터가 분실되지 않도록 대응하는 능력을 말한다. 그러니 구글이 많은 리전과 구역을 유지하고, 늘리는 일도 이 결함 감내와 의미가 있다고 할 수 있다.