[5주차] 클라우드의 스토리지
학습목표
1. 클라우드 SQL과 클라우드 스토리지를 사용하는 애플리케이션 배포하기
2. 구글 클라우드 데이터베이스 스토리지 옵션들을 구분하기
3. 클라우드 스토리지 클래스들을 구분하기
4. 클라우드 스토리지의 목적과 사용 용례를 파악하기
[5-1] 구글 클라우드 스토리지 옵션
모든 애플리케이션은 스트리밍될 미디어와 같은 데이터 또는 심지어 장치에 있는 센서 데이터까지도 저장할 필요가 있다. 그리고 애플리케이션과 워크로드에 따라 스토리지 데이터베이스 솔루션은 달라진다. 구글 클라우드는 정형, 비정형, 트랜잭션형, 그리고 관계형 데이터에 대한 스토리지 옵션을 갖고 있다. 이번 섹션에서 우리는 구글 클라우드의 5가지 제품인 클라우드 스토리지, 클라우드 SQL, 클라우드 스패너, 파이어스토어, 그리고 클라우드 빅테이블에 대해 살펴보게 된다. 어떤 애플리케이션이냐에 따라 이러한 서비스 중 하나 또는 여러 개를 사용하여 작업을 수행할 수 있을 것이다.
[5-2] 클라우드 스토리지
클라우드 스토리지는 개발자와 IT 조직에게 내구성 있고, 고가용성인 객체 스토리지를 제공하는 서비스다. 그렇다면 객체 스토리지라는 것은 무엇일까? 객체 스토리지는 데이터를 파일과 폴더 계층 구조(=파일 스토리지)나 디스크의 청크(=블록 스토리지)가 아닌 '객체'로 관리하는 컴퓨터 데이터 스토리지 아키텍처다. 이러한 객체들은 실제 데이터의 바이러니 형식 뿐만 아니라, 관련 메타데이터(생성일, 작성자, 리소스 유형, 권한 등)와 전역적으로 고유한 식별자를 포함하는 패키지 포맷으로 저장된다. 이러한 고유 키는 URL 형태로 되어 있으며, 이는 객체 스토리지가 웹 기술과 잘 상호작용한다는 것을 의미한다. 일반적으로 객체로 저장되는 데이터에는 비디오, 사진, 오디오 녹음이 포함된다. 클라우드 스토리지는 구글의 객체 스토리지 제품이다. 그것은 고객들이 어떠한 양이건 데이터를 저장할 수 있게 하고, 필요한 만큼 그것을 다시 되찾을 수 있게 해준다. 그것은 정말이지 넓고 다양한 용도로 사용할 수 있는 완벽하게 관리되는 확장 가능한 서비스다.
웹 사이트 콘텐츠 서비스, 기록용 혹은 재해 복구를 위한 데이터 저장, 다이렉트 다운로드를 통해 최종 사용자에게 대용량의 데이터 객체를 배포하는 것들이 그것의 예시에 속한다. 클라우드 스토리지의 주요 용도는 비디오, 사진 같은 온라인 콘텐츠, 백업과 아카이브 데이터, 일을 처리하는 중에 중간 결과를 저장하기 위해 바이너리 대용량 객체 스토리지(BLOB)가 필요할 때다. 클라우드 스토리지 파일은 버킷으로 구성된다. 여기서 버킷은 데이터를 담는 기본 컨테이너다. 클라우드 스토리지에 저장하는 모든 컨테이너가 버킷에 포함되어야 한다.
버킷은 세계적으로 고유한 이름과 저장해야 할 특정 지리적 위치가 요구되며, 버킷의 이상적인 위치는 지연 시간이 최소화되는 곳이다. 예를 들어, 대부분의 사용자가 유럽에 있는 경우, 우리는 당연히 유렵에 있는 특정 구글 클라우드 리전이나 다른 EU 멀티 리전을 고르길 원할 것이다.
클라우드 스토리지에서 제공되는 스토리지 객체는 변경할 수 없고, 따라서 우리는 이것을 수정할 수 없다. 대신, 매번 변경이 있을 때마다 새 버전이 생성된다.
관리자는 각 새 버전이 이전 버전을 완전히 덮어쓰도록 허용하거나, 버킷 내에서 '버저닝'을 사용할 수 있도록 하여 특정 객체가 변경된 각 버전을 추적할 수 있다. 만약 우리가 버저닝을 선택할 경우, 클라우드 스토리지는 해당 버킷에 포함된 모든 객체에 대한 수정, 즉 덮어쓰기나 삭제에 대한 상세한 역사를 유지할 것이다. 만일 객체 버저닝을 설정하지 않으면, 기본적으로 새 버전은 언제나 이전 버전을 덮어쓸 것이다.
객체 버저닝을 사용하도록 설정하면, 필요에 따라 객체의 기록된 버전을 나열하거나, 객체를 이전 상태로 복원하거나, 객체의 버전을 영구적으로 삭제할 수 있다. 많은 경우, 개인적으로 식별가능한 정보가 데이터 객체에 포함될 수 있으므로, 저장된 데이터에 대한 엑세스를 제어하는 것은 보안 및 개인정보보호를 보장하는 데 있어서 필수적이다.
조직은 IAM 역할과 필요한 경우에는 엑세스 제어 목록(ACL)을 사용하여 각 사용자가 그들의 작업을 수행하는 데 있어 필요한 리소스에 대한 최소한의 엑세스와 권한을 갖는 보안 모범 사례를 준수할 수 있다. 객체와 버킷에 대한 사용자 엑세스를 제어하는 몇 가지 옵션이 존재한다. 대부분의 목적에서, IAM만 있으면 충분하다. 역할은 프로젝트 → 버킷 → 객체로 상속된다. 만약 더욱 세밀한 제어가 필요하다면, ACL를 만들면 된다. 각 ACL는 2가지 정보로 구성된다. 첫 번째는 범위로, 누가 엑세스하고, 누가 작업을 수행하는지 정의한다. 이것은 특정 사용자나 사용자 그룹일 수 있다. 두 번째는 권한으로, 읽기나 쓰기와 같은 수행할 수 있는 작업의 성격에 대해 정의한다.
대량의 객체 데이터를 저장하고 되찾는 것에 들어가는 비용이 빠르게 늘어날 수 있기 때문에, 클라우드 스토리지는 또한 라이프사이클 관리 정책도 제공한다. 예를 들어, 클라우드 스토리지에 365일도 더 지난 객체를 삭제하거나, 2013년 1월 1일 이전에 생성된 객체를 삭제하거나, 버저닝을 사용하도록 설정된 버킷에 각 개체의 최신 버전 3개만 저장하도록 지시할 수 있다. 이런 제어를 통해 우리는 실제 필요한 것 이상의 비용을 지불하지 않도록 보장받는다.
[5-3] 클라우드 스토리지: 스토리지 클래스와 데이터 전송
클라우드 스토리지에는 4개의 주요 스토리지 클래스가 존재한다. 첫 번째는 스탠다드 스토리지다. 스탠다드 스토리지는 빈번하게 엑세스하는 핫 데이터에 가장 적합하다. 또한, 짧은 시간 동안에만 저장되는 데이터에도 매우 적합하다. 두 번째는 니어라인 스토리지다. 이것은 평균적으로 한 달에 1번 또는 그 이하로 데이터를 읽거나 수정하는 것과 같이, 자주 엑세스하지는 않는 데이터를 저장하는 데 가장 적합하다. 예를 들어, 데이터 백업, 장기 멀티미디어 콘텐츠, 또는 데이터 기록이 포함될 수 있다. 세 번째는 콜드라인 스토리지다. 이것은 자주 엑세스하지 않는 데이터를 저장하기 위한 저렴한 옵션이다. 니어라인 스토리지와 대조하면, 콜드라인 스토리지는 최대 90일에 1번 데이터를 읽거나 수정하기 위한 용도다. 마지막으로 네 번째는 아카이브 스토리지다. 이는 데이터 기록, 온라인 백업, 재해 복구에 있어 이상적으로 사용되는 최저 비용 옵션이다. 365일의 최소 저장 기간에서 데이터 엑세스와 운영에 대한 비용이 높기 때문에 1년에 1번 미만으로 엑세스할 계획이 있는 데이터에 가장 적합한 선택이다.
이 4가지 클래스는 분명 각각 다른 점을 갖고 있지만, 이 모든 스토리지 클래스에 적용되는 몇 가지 특징들이 있다는 점에 주목할 필요가 있다. 그것에는 최소한의 객체 사이즈 요구사항이 없는 무제한 스토리지, 전 세계적인 접근성과 위치, 낮은 지연 시간과 높은 내구성, 보안 도구와 API로 확장되는 동일한 경험, 데이터가 멀티 리전이나 듀얼 리전에 저장된 경우의 지리적 중복성이 포함된다. 이는 지리적으로 다양한 데이터 센터에 물리적인 서버들을 배치하여 재난적인 사건과 자연 재해로부터 보호하고, 최적의 성능을 위해 트래픽의 균형을 낮게 유지하는 것을 의미한다.
또한, 클라우드 스토리지는 자동 클래스라는 기능을 제공하는데, 이것은 각 객체의 엑세스 패턴에 따라 객체를 그에 적절한 스토리지로 자동적으로 전환하는 것이다. 이 기능은 더 차가운 스토리지 클래스에 엑세스할 수 없는 데이터를 이동시킴으로써 스토리지 비용을 절감하고, 스탠다드 스토리지에 엑세스할 수 있는 데이터를 이동시켜 향후 엑세스를 최적화한다. 자동 클래스는 우리의 클라우드 스토리지 데이터에 대한 비용 절감을 단순화하고 자동화하는 것이다. 클라우드 스토리지는 사용한 것에 대해서만 값을 지불하기 때문에 최소 지불액 개념이 없다. 그리고 용량의 사전 프로비저닝은 필요치 않다. 클라우드 스토리지는 언제나 추가적인 비용 없이 디스크에 쓰여지기 전에 항상 서버 측의 데이터를 암호화한다. 고객의 기기와 구글 간에 이동하는 데이터는 기본적으로 전송 계층 보안인 HTTPS/TLS를 사용하여 암호화된다.
어떤 스토리지 클래스를 선택하건, 클라우드 스토리지로 데이터를 가져오는 방법에는 여러 가지가 있다. 많은 고객이 클라우드 SDK의 클라우드 스토리지 명령인 Cloud storage를 사용하여 자신만의 온라인 전송을 수행한다. 구글 크롬 웹 브라우저를 통해 엑세스할 경우, 클라우드 콘솔에서 Dragon Drop 옵션을 사용함으로써 데이터를 이동시킬 수도 있지만, 만일 테라 바이트, 심지어는 페타 바이트의 데이터를 업로드해야 한다면 어떻게 해야 할까? 스토리지 전송 서비스를 사용하면 대용량의 온라인 데이터를 클라우드 스토리지로 빠르고 비용 효율적으로 가져올 수 있다. 스토리지 전송 서비스를 사용하면, 다른 클라우드 스토리지 리전의 다른 클라우드 공급업체 또는 HTTPS 엔드포인트에서 클라우드 스토리지로 배치 전송을 예약하고 관리할 수 있다. 그런 다음 구글 클라우드에서 임대하는 랙(rack) 가능한 대용량 스토리지 서버인 전송 장치가 있다. 우리는 그것을 사용하여 네트워크에 연결하여 데이터를 로드한 다음, 데이터가 클라우드 스토리지에 업로드되는 업로드 시설로 옮긴다. 이때 단일 어플라이언스에서 최대 패타 바이트의 데이터를 전송할 수 있다. 클라우드 스토리지는 다른 구글 클라우드 제품, 서비스와 긴밀하게 통합되어 있으며, 이는 데이터를 서비스로 이동할 수 있는 수 많은 방법이 존재함을 의미한다. 예를 들어, 빅쿼리와 클라우드 SQL 모두로부터 테이블을 가져오거나 내보낼 수 있다. 또한, 앱 엔진 로그, 백업용 파일, 이미지와 같이 앱 엔진 애플리케이션에서 사용하는 객체를 저장할 수도 있다. 클라우드 스토리지는 또한 인스턴스 시작 스크립트, 컴퓨트 엔진 이미지, 컴퓨트 엔진 애플리케이션에 의해 사용되는 객체를 저장할 수도 있다.
[5-4] 클라우드 SQL
구글 클라우드의 2번째 핵심 스토리지 옵션은 클라우드 SQL이다.
클라우드 SQL은 MySQL, PostgreSQL, 서비스로의 SQL 서버를 포함하여 완전하게 관리되는 관계형 데이터베이스를 제공한다. 그것은 패치 및 업데이트 적용, 백업 관리, 복제 구성과 같이 평범하지만 필수적이고 시간을 꽤나 잡아먹는 작업을 구글에 전달하도록 설계되어 있다. 그래서 작업자는 우수한 애플리케이션을 구축하는 데에 더욱 집중할 수 있다. 클라우드 SQL은 어떠한 소프트웨어 설치나 유지보수를 필요로 하지 않는다. 최대 128개의 프로세서 코어, 864GB의 램, 64TB의 스토리지까지 확장할 수 있다. 클라우드 SQL primary 인스턴스, 외부 primary 인스턴스, 외부 MYSQL 인스턴스와 같은 자동 복제 시나리오도 지원한다. 클라우드 SQL은 백업을 지원하므로, 백업된 데이터가 안전하게 저장되고, 복구가 필요하다면 엑세스할 수도 있다. 인스턴스 비용은 7개의 백업을 포함한다. 클라우드 SQL은 구글 내부 네트워크에 있을 때와 데이터베이스 테이블, 임시 파일, 그리고 백업에 저장될 때 고객의 데이터를 암호화한다. 그리고 그것은 네트워크 방화벽을 포함하여 각 데이터베이스 인스턴스에 대해 네트워크 엑세스를 제어할 수 있다. 클라우드 SQL 인스턴스의 장점은 다른 구글 클라우드 서비스, 그리고 심지어는 외부 서비스에 의해서도 엑세스가 가능하다는 것이다. 클라우드 SQL은 자바용 Connector/J 또는 파이썬용 MYSQLdb와 같은 표준 드라이버를 사용하여 앱 엔진과 함께 사용할 수 있다. 컴퓨트 엔진 인스턴스는 클라우드 SQL 인스턴스에 엑세스하고 클라우드 SQL 인스턴스를 가상 머신과 동일한 구역에 구성하도록 권한을 부여할 수 있다.
클라우드 SQL은 또한 SQL 워크벤치, Toad, 그리고 표준 MYSQL 드라이버를 사용하는 다른 외부 애플리케이션들과 같이 우리가 사용할 만한 도구와 애플리케이션을 지원한다.
[5-5] 클라우드 스패너
구글 클라우드가 제공하는 3번째 핵심 스토리지 옵션은 클라우드 스패너다.
클라우드 스패너는 완전하게 관리되는 관계형 데이터베이스 서비스로, 수평적으로 확장되고, 일관성이 강력하며, SQL을 구사한다. 구글의 자체 미션-크리티컬 애플리케이션과 서비스에 의해 테스트된 스패너는 구글의 800억 달러 비즈니스에 힘을 실어주는 서비스다. 클라우드 스패너는 특히 다음이 필요한 애플리케이션에 적합하다. 조인 및 보조 인덱스가 포함된 SQL 관계형 데이터베이스 관리 시스템이 내장된 고가용성의 강력한 글로벌 일관성 및 초당 높은 입출력 작업을 하는 것에 말이다. 초당 수만 번 이상의 읽기와 쓰기에 대해 말하는 것이다.
[5-6] 파이어스토어
구글 클라우드가 제공하는 4번째 핵심 스토리지 옵션은 파이어스토어다. 파이어스토어는 모바일, 웹, 서버 개발을 위한 유연하고, 수평적으로 확장 가능한 NoSQL 클라우드 데이터베이스다.
파이어스토어를 사용하면, 데이터가 문서에 저장된 다음, 컬렉션으로 구성된다. 그 문서에는 하위 컬렉션 외에 복잡한 중첩된 객체가 포함될 수 있다. 각 문서에는 키-값 쌍의 셋이 포함되어 있다. 예를 들어, 사용자를 나타내는 문서는 그에 연관된 값과 함께 이름과 성에 대한 키가 있다. 그런 다음 파이어스토어의 NoSQL 쿼리는 개별의 특정 문서를 검색하거나 쿼리 매개변수와 일치하는 컬렉션 내의 모든 문서를 검색할 수도 있다. 쿼리에는 여러 개의 체인 방식 필터가 포함될 수 있으며, 필터링과 정렬 옵션을 결합할 수 있다. 또한, 기본적으로 그것들은 인덱싱되므로, 쿼리 성능은 데이터셋이 아닌 결과 셋의 크기에 비례한다. 파이어스토어는 데이터 동기화를 사용하여 연결된 장치의 데이터를 업데이트한다. 그러나 그것은 또한 간단한, 일회성의 패치 쿼리를 효율적으로 만들도록 설계되었다.
앱이 활발하게 사용하는 데이터를 캐시하기 때문에 설령 기기가 오프라인이더라도 앱이 데이터를 쓰고, 읽고, 듣고, 질의할 수 있다. 그러다 기기가 다시 온라인 상태가 되면, 파이어스토어는 모든 로컬 변경사항을 파이어스토어로 동기화한다. 파이어스토어는 자동적인 멀티 리전 데이터 복제, 강력한 일관성 보장, 극소의 배치 작업, 그리고 실제 트랜잭션 지원과 같은 구글 클라우드의 강력한 인프라를 활용한다. 프라이싱 측면에서 볼 때, 파이어스토어에서 수행하는 각 문서에 대해 읽기, 쓰기, 그리고 삭제에 대해 비용이 부과된다. 쿼리는 쿼리가 데이터를 반환하는지의 여부에 관계 없이, 쿼리당 하나의 '문서 읽기' 속도로 가격이 부과된다. 또한, 데이터에 엑세스하는 데 사용되는 특정 유형의 네트워크 대역폭에 대해 데이터 소비 용량이 부과된다. 유입(전송)은 현재 무료고, 많은 경우에서 유출(전송)도 무료다. 자세한 사항은 파이어스토어의 프라이싱 페이지를 참조하거나, 구글 빌링 계산기를 사용하여 특정 사용 사례의 가격을 추정할 수 있다.
파이어스토어는 미국 리전 사이에서 월 10GiB의 네트워크 무료 유출(전송) 외에도, 5만 건의 문서 읽기, 2만 건의 문서 쓰기, 1GB의 저장 데이터를 하루마다 무료로 할당한다. 요금은 일일 무료 할당량을 초과한 경우에만 부과가 시작된다. 이를 통해 우리는 아주 적은 돈으로, 심지어는 무료로 파이어스토어를 사용할 수 있다.
[5-7] 클라우드 빅테이블
구글 클라우드의 핵심 스토리지 옵션 마지막은 클라우드 빅테이블이다. 클라우드 빅테이블은 구글의 NoSQL 빅데이터 데이터베이스 서비스다. 그것은 검색, 분석, 지도, 지메일을 포함하는 많은 핵심 구글 서비스에 힘을 주는 동일한 데이터베이스다.
빅테이블은 지속적인 낮은 지연 시간과 높은 처리량으로 대용량 워크로드를 처리하도록 설계되었다. 따라서 사물 인터넷, 사용자 분석, 그리고 재무 데이터 분석을 포함한 운영적인, 분석적인 애플리케이션 모두에 적합하다. 어떤 스토리지 옵션이 최선인지를 결정할 때, 고객들은 1TB 이상의 반정형 혹은 정형 데이터로 작업하는 경우에 빅테이블을 선택하곤 한다. 데이터는 높은 처리량과 함께 매우 빠르거나, 혹은 빠르게 변화하고 있다. 사람들은 NoSQL 데이터로 작업을 하고 있다. 이것은 일반적으로 강력한 관계적 의미가 요구되지 않는 트랜잭션을 의미한다. 데이터는 시계열이거나 자연스러운 의미론적 순서를 갖고 있다. 그래서 데이터에 대해 비동기 배치 또는 동기 실시간 처리를 실행하는 빅데이터로 작업하거나 데이터에 대해 기계 학습 알고리즘을 실행한다.
클라우드 빅테이블은 다른 구글 클라우드 서비스, 타사 클라이언트와 상호작용이 가능하다. API를 사용하면, 관리되는 VM, HBase REST 서버, 또는 HBase 클라이언트를 사용하는 자바 서버와 같은 데이터 서비스 계층을 통해 클라우드 빅테이블에서 데이터를 읽고 쓸 수 있다. 일반적으로, 이것은 애플리케이션, 대시보드, 그리고 데이터 서비스에 데이터를 제공하는 데 사용된다. 데이터는 플로우 스트리밍, 스파크 스트리밍, 그리고 스톰과 같은 다양한 인기 있는 스트림 처리 프레임워크를 통해 스트리밍될 수도 있다.
그리고 만약 스트리밍이 옵션이 아닌 경우, 하둡 맵리듀스, 데이터플로우, 스파크 같은 배치 프로세스를 통해 클라우드 빅테이블에서 데이터가 읽고 쓰여질 수 있다. 요약되거나 새로 계산된 데이터는 클라우드 빅테이블 또는 다운스트림 데이터베이스에 다시 기록되는 경우가 많다.
[5-8] 스토리지 옵션 비교
구글 클라우드의 핵심 스토리지 옵션을 모두 살펴 보았으니, 특정 애플리케이션에 워크플로우에 가장 적합한 서비스가 무엇인지를 확인하며, 그 옵션들을 비교해보도록 한다.
큰 이미지나 영화와 같이 10MB 이상의 수정 불가능한 blob를 저장해야 하는 경우, 클라우드 스토리지를 사용하는 것을 고려해볼 수 있다. 이 스토리지 서비스는 페타바이트 용량을 제공하며, 객체당 최대 단위 크기는 5TB다. 온라인 트랜잭션 처리 시스템에 대한 전체 SQL 지원이 필요한 경우, 클라우드 SQL이나 클라우드 스패너의 사용을 고려해볼 수 있다. 클라우드 SQL은 머신 유형에 따라 최대 64TB를 제공하며, 클라우드 스패너는 페타바이트를 제공한다. 클라우드 SQL은 사용자 자격증명과 고객 주문을 저장하는 것과 같은 웹 프레임워크와 기존 애플리케이션에 있어 최고의 선택이라 할 수 있다. 만일 단순히 사본을 읽기 뿐 아니라, 수평적 확장성이 필요해서 클라우드 SQL이 요구사항에 적합하지 않는다면, 그때는 클라우드 스패너 사용을 고려해보는 것이 좋다. 실시간 쿼리 결과와 오프라인 쿼리 지원과 함께 대규모 확장과 예측가능성이 필요한 경우에는 파이어스토어 사용을 고려하는 것이 좋다. 이 스토리지 서비스는 엔티티당 최대 단위 크기가 1MB인 테라바이트 용량을 제공한다. 파이어스토어는 모바일과 웹 앱들을 위한 데이터를 저장하고, 동기화하고, 쿼리하는 데 있어 가장 적합하다. 마지막으로, 수많은 정형 객체를 저장해야 하는 경우 클라우드 빅테이블 사용을 고려하는 것이 좋다. 클라우드 빅테이블은 SQL 쿼리를 지원하지 않으며, 멀티-로우 트랜잭션도 지원하지 않는다. 이 스토리지 서비스는 셀당 10MB, 로우당 100MB의 최대 단위 크기로 페타바이트의 용량을 제공한다. 빅테이블은 애드테크, 금융, 또는 IoT 데이터와 같이 읽기, 쓰기 이벤트가 아주 많은 분석형 데이터에 가장 적합하다. 애플리케이션에 따라 이러한 서비스들 중 하나 혹은 여러 개를 선택하여 작업을 수행할 수 있을 것이다.
그리고 아직까지 빅쿼리에 대해서는 언급을 하지 않았는데, 왜냐하면 데이터 그건 저장과 데이터 처리 사이의 가장자리에 위치하며, 다른 과정에서 깊이 다룰 것이기 때문이다. 빅쿼리에 데이터를 저장하는 일반적인 이유는 그것의 빅데이터 분석, 대화형 쿼리 기능을 사용할 수 있기 때문이지만, 그것은 순수한 데이터 스토리지 제품은 아니다.
[5-9] 클라우드 스토리지와 클라우드 SQL 시작하기
우선 VM 인스턴스를 생성했다. 인스턴스를 생성할 때 스크립트를 제대로 된 필드에 넣어야 함을 주의해야 한다. 다른 필드에 들어갈 경우 실행이 되지 않을 수도 있을 것이다.
이번엔 gcloud 스토리지 명령줄을 이용하여 클라우드 버킷을 생성한다. 클라우드 스토리지 버킷은 미국, EU, 아시아의 리전 또는 멀티 리전과 연결될 수 있다. 나는 클라우드 셸을 활성화하고, 사전에 배정된 것에 따라 지역으로 US를 입력했다. 그런 다음 프로젝트의 ID를 딴 버킷을 생성했다.다음 엑세스하기 위한 배너 검색을 하고, 새로 만든 클라우드 스토리지 버킷에 배너 이미지를 복사했다. 그리고 ACL을 수정하여 모든 사용자가 읽을 수 있게 하였다.
이번엔 클라우드 SQL 인스턴스를 생성한다. 비밀번호는 국룰 1Q2W3E4R!@. 생성 후에 SQL 인스턴스의 공용 IP를 알아둬야 한다. 나중에 쓸 일이 있기 때문이다. 그나저나 생성까지 시간이 몇 분은 걸리는 것으로 보인다. 이후 생성이 완료되면, 사용자 계정을 만들고, 네트워크도 추가한다. 네트워크에서 공용, 사설을 고를 수 있는데, 여기선 본인 목적에 맞게 선택하도록 한다. 여기에서 이제 IP를 기입해야 하는데, 여기서는 VM 인스턴스의 외부 주소에 /32 까지 더해주면 된다. 이 네트워크를 생성하는 것은 다행히 금방이다.
이제 컴퓨트 엔진 인스턴스에서 클라우드 SQL을 사용하도록 애플리케이션을 구성한다. SSH 편집을 해주고, 새 창에서 VM 인스턴스의 외부 주소로 들어가게 되면 데이터베이스 연결 실패 메시지가 뜨는 것을 볼 수 있다. 이는 위에서 내가 CLOUDSQLIP와 DB패스워드 부분을 수정해주지 않았기 때문이다. 여기에는 내가 위에서 알아둔 SQL 인스턴스의 공용 IP를 입력한다. 그리고 다시 VM 인스턴스의 외부 주소로 들어가게 되면, 드디어 데이터 연결이 성공적이라는 문구를 볼 수 있다. 실제 블로그에서는 데이터베이스 연결 상태를 블로그 방문자가 볼 수는 없다. 대신, 관리자만 그것을 보며 관리할 수 있다는 점을 알아두자.
이번 주차의 랩은 여기서 실습을 끝내며 5주차를 마무리하도록 한다.