[디지털파워온] 구글 클라우드 개괄(Google Cloud)

• 별도 비용 발생X
• 자기만의 클라우드를 운영하고 있는 센터들이 광케이블에 의해 연결됨
• 구글 클라우드는 네트워크 깡패야!
• 네트워크 관련된 부분은 구글이 독보적으로 구축하고 있다
• 클라우드는 독자적으로 운영되는 경우가 드물다

<AWS>

• VM 만들기 ⇒ EC2(instance) ⇒ 하나 만들기 위해서 함께 연결된 서비스 VPC, subnet, security group, instance type, EBS(storage service)
• 내부 인터넷과 연결 : 게이트웨이 필요, 공인IP 필요
• 공인 IP 획득 방법 : 유동IP, 고정IP
• application 배포 환경 : (CICD, Devops , agile 등) 도커, 쿠버네티스 환경 제공
• storage option : storage service(aws = S3)
• EBS VS S3 = block storage vs object storage(메타데이터, 데이터 같이 결합된 상태에서 저장)
• 윈도우, 리눅스 : 따로따로 저장
• object storage : 수정X (수정 = 삭제하고 다시 생성)
• 컴퓨터 엔진 : EC2
• DevOps : 핵심 인프라, 디자인, 설계
• VM instance
• cloud storage
• 저장하다 : 하드디스크, 데이터베이스 ⇒ cloud storage
• 👵2/24 : 클라우드 컨테이너👵
• qwiklabs : 시크릿 창 권장, core service 강의 클릭 → 메뉴
• 기초(핵심 인프라) - Google copute Engine(설계) - Kubernetes Engine 순서(필수적으로 포함되어야 한다)

—

1. 내용복습: 1주차

• 회사 내부 : LAN
• 회사 외부 : WAN(wide barrier network)
• 전용 회선 : ISP 업체, 서비스 provider
• VPN : 공개되어 있는 네트워크에서 프라이빗한 수준의 보안성 제공하는 서비스
• WAN이 모여서 연결됨 = 인터넷
• kt, lg, sk 등의 서비스 프로바이더 존재
• 5g 이슈
• 구글은 전 세계적으로 wan을 운영하고 있다. 다 가지고 있다. 34개의 리전이라는 단위를 가지고 있다.
•  

• https://cloud.google.com/about/locations?hl=ko
• 106개의 WAN
• 모든 WAN 자체적으로 가지고 있다
• 광케이블, 해저케이블 이용해서 다 연결해두었다
• 속도 : 엄청 빠름
• 클라우드 : 인터넷에 대한 국경이 없어져야 한다, 지리적 장점이 없어져야 한다. 어디서 접속을 하든지 간에 동일한 서비스를 제공받을 수 있어야 한다. 하지만 불가능하다. 왜냐하면 네트워크 속도가 지역마다 다 다르기 때문이다. 하지만! 구글 클라우드는 가능하다. 자체적으로 전세계적 네트워크를 구축해서 망을 가지고 있기 때문. 제약 조건 X.
• Region 안에 zone이 105개 있음(존들을 하나의 리전으로 묶어서 서비스 진행 중)
• zone(WAN=server cluster) 3-4개가 하나의 리전으로 묶여있음

---

• AWS : data center별로 zone 구분 & 구글 클라우드 : 서버 클러스터 단위로 묶어서 존으로
• 서버를 내가 몇 개까지 연결시켜두었는지에 따라 다르다
• 클러스터 : n개의 서버를 사용할 때 서버 하나 단위로 작업X n개 서버 묶어서 1개 서버처럼 사용하는 것
• 가용성
• 재해 발생 시 클러스터 또한 망가질 수 있음 → 서비스 중지됨. Region으로 묶인 것의 장점:
• 하나의 존이 문제가 되더라도 다른 존을 통해서 서비스를 제공할 수 있다.
• 하나 리전 안에는 여러 가지 존으로 묶여 있다.
• 리전 이용해서 프로젝트 만들어야 함 → VPC 만들기 (5개)
• 5개 네트워크가 전체 리전에 걸쳐서 생성되어지게 된다(리전마다 가서 VPC 만들 필요 없음)
• 기본적으로 5개 네트워크 생성할 수 있다. 5개에다가 필요하면 자원을 대체. 자원 대체할 때 리전 선택.
• AWS는 서울 리전과 미국 리전이 서로 통신하려면 인터넷을 공유해서 가거나, VPN 등을 이용해야 한다
• 구글은 같은 네트워크에 존재하고 있다면 서울, 미국 리전이 별도 연결 필요 없이 바로 통신할 수 있다. 자체적인 네트워크 망을 가지고 있다.
• 같은 네트워크에서 통신 = 거의 요금이 발생하지 않는다
• 리전별로 서브넷 만들어서 자신만의 네트워크 구성(Design)
• AWS를 사용하는 이유? : Google Cloud라는 서비스가 클라우드업계에선 돌연변이이기 때문이다. 모든 클라우드 사는 region별로 서비스를 제공하는 반면 구글 클라우드는 프로젝트 생성 후 모든 region을 대상으로 서비스를 제공하기 때문에 방식 자체가 다름
• 구글 클라우드가 돌연변이 식으로 취급이 되어지고 있다<클라우드 컴퓨팅 소개>
  • 주문형 셀프서비스 : 필요한 순간에 필요한 리소스를 확보할 수 있다
    • 회사에서 물리적으로 서버 구입하는 데 얼마나 걸릴까? 기안서 → 왜 필요한지 검증 → 승인 → 품위서 → 승인 → 견적서 → 승인 → 업체에 서버 요청 → 금액 조율 → 운영체제 및 서비스 설치… ⇒ 빠르면 2주, 늦어지면 3개월 why? 대표 승인이 늦어짐
    • 원가만 따졌을 때 : 오히려 클라우드가 더 비싸게 느껴질 수도 있다. 서버는 한 번 지불 후 추가 지불 없음. 클라우드는 지속적으로 특정 금액이 지출되어야 한다.
  • 광범위한 네트워크 액세스 : 글로벌하게 서비스하기 위해 필요한 형태
    • 글로벌한 서비스X = 굳이 클라우드를 쓸 필요는 없다. 이미 보유 서버 있으면 충분히 서비스 가능
    • 확장적 측면 : 클라우드 쓰는 것이 경제적
    • 글로벌 확장이 편하다
  • 리소스 풀링 : 리소스 걱정X
    • 클라우드 프로바이더에서 모니터링 중. 보유 리소스가 부족하다고 생각하면 미리 예상.
    • 규모의 경제 : 물거 하나 구입 vs 물건 100개 구입 ⇒ 많이 살수록 할인 받음. 단가 하락
    • 기업 자체적 서버 구매 vs 클라우드 벤더 사에서 클라우드 구매. 클라우드 업체의 대부분 수익은 시설 확장용으로 쓰고 있다.
    • 제공 서비스 비용이 낮아진다. → 클라우드 초반 서비스는 가격이 비싸다. 최근에 만들어진 서비스일수록 가격이 싸다. 더 저렴하게 장비를 구입했기 때문! 벌어들인 수익은 또 장비 증설용으로 사용한다. (순환)
  • 신속한 유연성 : 서비스 바로 가능
    • 클라우드의 가장 큰 혁신 : 우리 아이디어 바로 적용해서 서비스로 구현할 수 있다! 시간!
  • 측정형 서비스 : 사용한 만큼만 지불
  <기존의 노력 이후의 목표>
  • 물리적/코로케이션 : 관리, 유지보수 위해서 인력 필요. 인력 뽑아서 월급 주어야 함. 관리 필요 비용. 유지보수 필요 비용. 장비 고장났는지 모니터링할 수 있어야 한다. 관제! 관제 시스템도 갖추어져 있어야 한다. 관제 할 수 있는 인력 필요. 관제 중 오류 → 유지/보수 필요 or 서버 용량필요하면 증설. 해당 서버 벤더 사업과 게약도 만들어아 햔다.
  • 지속적 비용=고정비용 으로 발생!
  • 가상화 : 클라우드 나오기 전에는 가상화, 몇 1000개 서버들을 줄일 수 있는 방법 = 가상화! 2000→200대로 ( 가상화솔루션 이용해서)
  • 서버리스 : 클라우드에서 VM 사용? 서버리스! 애플리케이션 아래단에 있는 것들은 우리가 볼 필요가 없다. 우리가 더이상 서버라는 자원에 대해서 필요한 리소스에 신경쓰지 마! 실제로 서버가 없을 수는 없다. 하나 서비스 돌아가기 위해서는 그에 필요한 서버가 있기 때문. ⇒ 완전 자동화!
  • 리소스 부분에 신경쓸 필요 없음. 서비스, 품질 향상 위해서, 새로운 비즈니스 방향 개선하기 위해서 기존 데이터 분석!
  • chatGPT 할 수 있을만한 회사 : NAVER! → 지식인 검색엔진
  <Google Cloud 컴퓨팅 아키텍처>
  • compute engine(EC2)
  • google kubernetes engine : 컨테이너의 집합체. 오픈소스로 풀어버림. CNCF 기관에 투척.
  •  

---

• app engine : 이미 인프라 구축됨. 개발 플랫폼 제공. 원하는 개발 언어 선택+코드 올리기=테스트 가능
• cloud functions : serverless. lambda
• 관리형 서비스 : autoscale (서버 하나로 서비스, 접속자 많아짐, 서브넷 늘려야 함. 온프레미스 환경은 물리적, but cloud는 서버 사용자 로그인 중. 자동적으로 서버 증설) 서버 부하 분산 신경쓸 필요 없음. 알아서~ 관리적 부담 줄어든다. 서비스에 집중할 수 있는 환경 제공
  • 데이터 베이스 서버 : 리눅스, 윈도우에 데이터 베이스 설치 필요. 시스템 업그레이드 vs 동일 시스템 구입해서!
  • 알아서 자동으로 autoscale 서비스로 증설된다!
• 서비스 질, 서비스 향상에 얼만큼 신경써야 하는가?
• 열이 많다 = 공급되는 전력이 많다
• 저전력 반도체가 나왔다! 적은 전력으로도 똑같은 기능할 수 있게 되었다. 발생되는 열도 적어진다 → 노트북이 납작해졌다
• 전기자동차 유행 : 전기자동차의 표면 자체를 패널로 감싼다 → 아무데나 세워두어도 충전이 된다

<고객에게 부담 없는 가격 책정을 제시하는 구글>

• 분 단위 증가분 결제 : 내가 10초만 써도 1분으로 결제됨. 특정 os 이미지가 무엇이냐에 따라 초단위, 분단위 결정됨
• 지속 사용 할인 : 구글 클라우드 요금제 심플 (다양하지 못한 부분 존재) 구글은 오래 사용하면 할인율이 늘어난다. 지속적인 할인. 한 달에 5% 이상 쓰게 되면 자동으로 할인율 적용.
• 약정 사용 할인
• 선점형 사용 할인
• 커스텀 VM 인스턴스 유형
• 항상 클라우드 사용할 때 어떤 유형에 사용할 수 있는 서비스인지 식별! 요금제 선택해서 사용하는 것이 좋다

<고객에게 업체 선택을 맡기는 개방형 API 및 오픈소스>

• 개방형 API, 오픈소스 서비스와 호환 가능
• 다채로운 생태계를 위한 오픈소스 : 쿠버네티스, 텐서플로우
• 여러 공급업체에 적용할 수 있는 기술 : 운영, 구글 쿠버네티스 엔진

<google의 기술 인프라로 설계되는 보안>

• infra as a service
• 온프라미스 환경에서 서비스를 하려고 한다면 우리는 하드웨어 인프라부터 운영 보안까지 우리가 다 관리해야 한다(구축&구성)
• 클라우드 서비스 사용하면 분야별로 맞는 보안 관련 부분을 제공하고 있다.
• 하드웨어 인프라 : 구글에서 인프라 구축, 구글 엔지니어들이 관리 중, 신경쓸 필요 없음
• 서비스 배포 : 모든 통신은 다 암호화돼서 통신이 이루어짐. 안전하게 데이터 주고받을 수 있음
• 사용자 id : 중앙에서 관리
• 스토리지 서비스 : 데이터 암호화. 스토리지에 저장 → 3개 복제본이 서로 다른 존에 복제가 돼서 저장이 되어지게 된다. 한쪽 존에 시스템 이상이 발생해서 접근할 수 없다면 다른 존에 있는 데이터 통해서 서비스가 이루어질 수 있게끔 제공, 데이터 안정성이 뛰어남
• 인터넷 통신 : 구글은 어마어마하게 방대한 네트워크 환경을 가지고 있다. 앵간한 공격으로는 네트워크에 피해가 가지 않는다. 모든 서비스가 다 분산되어 있기 때문에. 크게 지장을 주지 않는다.
• 운영 보안 : 보안성으로 제공되고 있다.
• 보안성, 안정성, 확장성이 뛰어난 인프라 : 생각할 필요 없이~ 서비스! 어플리케이션! 하고자 하는 서비스에 대해서만 신경쓸 수 있게끔 환경 제공!

<다양한 스토리지 서비스를 제공하는 구글 클라우드>

• cloud bigtable
• cloud storage
• cloud sql : 관계형 데이터베이스(mysql), 분산 데이터 서비스X
• cloud spanner
• firestore : 모바일 앱에 어떤 데이터베이스를 쓰는 것이 좋을까?

<데이터에서 가치를 찾아내는 서비스를 제공하는 구글 클라우드>

• 빅데이터
  • bigquery
  • pub
  • dataflow
  • dataproc
  • ai platform notebooks
• 머신러닝
  • ai platform
  • vision api
  • speech-to-text api
  • cloud translation api : 다양한 언어로 변환시킬 수 있다
  • autoML
• 구글 클라우드 장점 : 빅데이터, 머신러닝, 딥러닝 관련 부분에 강하다.

<예산과 알림을 통한 청구 제어 유지>

• 어느 정도 예산이 초과될 것 같다고 미리 알려줌
• 알림 트리거 기준 : 소요할 때마다 알려주기
• 온프레미스 환경 : 서버 구입하면 구입에 대한 비용은 어디서 관리되나 총무팀? 재무팀?에서! 보통 서버 하나 사게 되면 해마다 감가상각. 0가 됐을 때 서버 발생 부분이 이익으로 돌아온다. 엔지니어들이 신경쓸 필요가 없다~ 그러나 클라우드는 다르다!
  • 클라우드에서는 엔지니어, 개발자들도 요금적인 부분을 확인할 수 있어야 한다.
  • 불필요한 서비스에 의해서 요금이 발생되고 있지 않은지
  • 우리가 모르는 사이에 어떤 자원들이 활성화되어서 동작하고 있을 것이다..ㄷㄷ

<유용한 한도인 할당량>

• 리미트 존재 이유? 한 명의 사용자가 전체 리소스를 사용하는 것을 막기 위해서
• 아무리 많이 써도 그정도까지 쓰지 못하게끔 제약이 걸려 있다
• 더 많이 필요하다면 요청해야 한다. 어떤 이유에서 한계가 더 필요한지
• 계정을 통해서 인증
• 인증하기 위해서 계정 필요, 계정 통해서 적절한 권한 가지고 있어야 한다 → 클라우드 접근했을 때 여러 서비스를 이용할 수 있다.
• 운영체제 레벨도 우리가 관리할 필요가 없다. 구글 클라우드에서 다 관리해주기 때문.
• 완전관리형 서비스 : 서비스 레벨까지도 우리가 관리할 필요가 없다. 서비스에 포함되는 컨텐츠, 데이터에 대한 부분만 신경쓰면 된다.
• 문제 : infra as a service로 제공받고 있다.
• 방화벽 역할 : 외내부 접근 필터링
• 계정관리 : IAM을 통해서 계정 생성, 계정에 권한 부여 가능
• 리소스 계층 구조를 가지고 있다. 클라우드 서비스를 쓰는 사용자들이 일반적으로 크게 두 분류로 나눌 수 있다. 개인과 기업 사용자.
  • 개인 : 리소스 계층 구조 사용할 필요 없다. 혼자 쓰기 때문에 자기 프로젝트 내에서만 작업하면 된다. 굳이 리소스 계층 구조 가져갈 필요 없다.
  • 기업 : 여러 부서가 나누어져 있고, 여러 부서에서 다양한 프로젝트 발생. 부서 간 프로젝트 연결이 필요할 수도 있다.
  • 구글 클라우드 자체는 처음에 설계되었을 때부터 기업 구조 환경에서 클라우드 서비스를 효율적으로 사용할 수 있게끔 만들어져 있다.
• 부서의 신규 사업 발생 → 사업에 맞는 팀 구성 → 새로운 프로젝트 팀 만들어짐 → 팀별로 폴더 구분 → 팀 안에서 여러 가지 서비스들이 있음 → 서비스별로 폴더 관리 → 서비스 안에서 프로젝트 별로 생성해서 필요한 서비스, 기능들 개발
• 폴더 만들 필요 없고,조직 노드 바로 밑에다가 프로젝트 생성 가능 : 프로젝트가 많이 발생하는 경우에 사용한다

<사용하는 모든 구글 클라우드 서비스가 프로젝트와 연결됨>

• 얼만큼의 리소스를 할당한 것인가에 따라 관리
• 프로젝트별로 어떻게 사용되어지고 있는지
• 결제 관련 부분 따로 설정 가능
• 계정 여러 개 만들 수 있다.
• 조직 : 금액 관리 부서 따로 존재. 그 부서에 담당자를 두고 그 사람에게 결제 계정 권한 부여. 그 계정으로 들어와서 현재 프로젝트 별로 어떤 리소스가 사용되어지고 있는지 체크할 수 있다.
• 계정 추가 : 지메일 계정 이용해서, 기업 사용자 구글 워크스페이스 서비스 받을 수 있음. 가입 → 기업 도메인 등록 → 밑에 생성되는 계정은 구글 로그인에서 사용 가능하도록
• 메가존 회사 자체가 구글 클라우드에 가입되어져 있다
• aws는 vpc 단위로 격리되어 있다
• 구글 클라우드는 프로젝트 별로 격리되어져 있다

인스턴스 만들기 : VM인스턴스를 만들고, 설정하고, 생성이 되는 것까지가클라우드의 기능

<resource manager를 사용하여 google cloud에서 프로그래매틱 방식으로 프로젝트 관리하기>

• 프로그램을 통해 여러 resource를 제어 및 사용할 수 있다는 것
• 새로운 프로젝트 생성, 기존 프로젝트 업데이트

<프로젝트에 사용되는 3가지 식별 속성>

• 프로젝트 ID
• 프로젝트 이름
• 프로젝트 번호
• 프로젝트 ID : 외부에서 식별, 유니크한 번호
• 프로젝트 번호, ID 변경 불가능 → 지우고 다시 생성
• 프로젝트 이름 변경 가능 : 유니크 ID 값 존재하기 때문에 상관 없다
• 프로젝트 ID: 전역에서 고유, Google cloud에서 할당하기에 생성 중 변경 가능 but 생성 후에는 변경 불가
• 프로젝트 이름: 고유할 필요도 없고 변경 가능
• 프로젝트 번호: 전역에서 고유하고, Google Cloud에서 할당하기에 변경 불가능. 변경하고 싶으면 플젝 지우고 다시 생성해야 함
• 기업 계정으로 접근해서 사용하면 사용자가 삭제해도 프로젝트는 그대로 남아있다

<유연한 관리를 제공하는 폴더>

• 폴더를 회사 내에서 프로젝트 그룹화시키기 위해 사용
• 부서별로 나눠져 있다.
• 부서가 없어서 나눌 수 없으면 개발, 프로덕트, 테스트로 구분해서 관리할 수 있다
• 다양한 형태로 관리할 수 있어서 it depends on my design
• 제품1(폴더)에 권한 주면→그 권한 밑에 있는 리소스에게 상속된다.
• 리눅스에서 폴더 만들었다 → 파일 추가하면 폴더가 가지고 있는 권한을 파일이 상속받음
• A user : R

A user에게 R 권한만 부여하려면 해당 사용자를 폴더 또는 프로젝트에 추가하고, 해당 리소스에 대한 권한을 R로 설정하면 됩니다. 

• 프로젝트가 수십 개 → 어떤 프로젝트에 어떤 권한을 줬지? 찾는 것도 하나의 일이 되어버린다. 그래서 가능하면 체계적으로 관리할 수 있게끔 하기 위해서 프로젝트 많이 생성된다면 폴더 활용하자!

<프로젝트를 구성하는 조직 노드>

• 조직 노드는 기업 사용자에게만 보인다
• 조직 노드 레벨에서 권한 줄 수 있고, 프로젝트 레벨에서 권한 줄 수 있다.
• bob은 조직 관리자. 모든 권한을 다 가지고 있다. 운영체제로 따지면 윈도우의 administrator
• 조직 관리자 구성할 때 신중할 필요가 있다. 너무 막강한 권한을 함부로 할당하게 되면 그 사용자가 밑에 있는 모든 프로젝트 권한을 가져가기 때문에 주의할 필요가 있다. 가능한 프로젝트 별로 권한 생성 아니면 폴더 만들어서 관리!

<Cloud Identity and Access Management>

• 구글 계정을 그룹화시킬 수 있다. 클라우드 아이디를 이용해서 접근 가능

<무엇을 : IAM 역할 - 관련된 권한 모음>

• 퍼미션을 리소스에 직접 할당할 수 없다 = 권한 주지 않고 역할 줌
• 역할 자체를 계정에게 할당
• 총 3가지 방법으로 할당
  • 기본
  • 사전 정의(built in) : 가장 많이 사용, 구글이 새로운 서비스기 위해서 접근 사용자들이 어떤 권한이 필요하겠구나 생각 → 서비스 만들어지면서 구글 자체적으로 이미 역할을 만들어둔다 → 그 역할을 사용할 수 있다
  • 커스텀
  **이 문서는 구글 클라우드(Google Cloud)에 대한 개인과 기업 사용자의 차이점, 프로젝트와 폴더의 관리 방법, 프로젝트 ID, 이름, 번호의 차이점, 그리고 Cloud Identity and Access Management 등에 대해 설명합니다.**← 이것도 AI가 썼어요…ㅠㅠㅠㅠ 대박대박…ㅠㅠㅠ 나울어…ㅠㅠ

<세분화되지 않은 고정된 액세스 수준을 제공하는 IAM 기본 역할>

• 뷰어 : 읽기 전용
• 편집자 : 편집적인 기능을 가지고 있다. 코드 수정. 서비스 구성, 뷰어 기능 가지고 있다.
• 소유자 : 프로젝트 만들고 삭제할 수 있는 권한 가지고 있음. 구성원 초대, 구성원 삭제, 편집자 기능, 뷰어 기능 가지고 있음.
• 서비스가 많이 없어서 권한 나눌 필요 없었음 그래서 3가지 방법 사용

<프로젝트의 모든 구글 클라우드 서비스에 적용되는 IAM 사전 정의 역할>

• 컴퓨터 엔진 리소스에 무엇을 할 것인지 역할 줄 수 있다.
• 프로젝트 모든 리소스!!!!
• 내가 원하는 권한만 이용해서 역할을 만들고 싶어~ 생성/삭제 권한을 묶어서 주고 싶어~ 사전정의된 역할가지고는 안되겠어~ —> 커스텀!

<IAM 커스텀 역할을 통해 권한 집합을 정확하게 정의>

• 프로젝트에 할당 하거나 그룹에 할당 하거나…
• Instance Operator - compute.instances.get 등

<어느 리소스에 : 계층 구조의 특정 항목에 대한 역할을 부여받는 사용자>

• 프로젝트 레벨? 리소스 레벨? 적절하게 권한을 주실 필요가 있다~

<서버 간 상호작용을 제어하는 서비스 계정>

• 권한 주기 위해서는 기본적으로 사용자 계정이 있어야 했다. 보통 사용자 계정은 누구에게 할당하나? 나에게~ 내가 구글 클라우드 접근할 때 계정 필요하고, 권한 줘서 서비스 할 수 있게끔 해주는 것!
• 내가 권한을 주고자 하는 대상이 vm instace다! 나는 이 리소스에 권한을 주고 싶다 → 리소스는 일반 사람이 아니다 사용자가 아니다. → 리소스도 계정이 필요하다 → 그 때 필요한 것이 서비스 계정!!

File → VM instance로 업로드 → Cloud Storage

웹 서버가 어딘가에는 파일을 저장해야 하는데 그 저장소가 바로 Cloud Storage

VM Instance : apache + php(auth) 권한 부여

• service-service 간 통신을 해야 하는 경우 두 서비스가 어떠한 권한을 갖고 통신할 수 있게끔 제어해 줘야 함 : 그 과정에서도 apache가 사용될 수 있다.

리소스 간 권한을 상속하는 폴더를 활용하면 프로젝트마다 권한을 할당하는 일이 줄어들어 유연하게 프로젝트를 관리할 수 있습니다. 프로젝트가 많아지면 어떤 프로젝트에 어떤 권한을 주었는지 찾는 것도 어려워집니다. 이때, 프로젝트를 폴더로 그룹화시켜 체계적으로 관리할 수 있습니다. 또한, IAM 역할을 통해 권한 집합을 정확하게 정의할 수 있고, 서비스 계정을 사용하여 서버 간 상호작용을 제어할 수 있습니다. -AI-

<google cloud 관리 사용자를 관리하는 데 사용할 수 있는 것>

• 서비스 계정 통해서 접근 가능. 계정 별 권한? 그룹 권한? 새로운 사용자가 포함됐을 때 그룹에 포함시키기만 하면 된다!

<이미 다른 기업 디렉터리가 있는 경우>

• 인증 서비스 안에 계정이 등록되어 있다
• active directory : 디렉토리 서비스 중에 가장 유명! 계정 정보를 구글 클라우드에게 동기화시켜주는 작업을 클라우드 아이디 서비스 이용해서 회사에 있는 계정을 구글 클라우드에서 사용할 수 있도록 동기화시켜준다 그럼 별도로 계정을 만들지 않아도 된다
• directory service : 파일
• 디렉토리별로 나누는 이유는 프로젝트마다 권한을 할당하는 일이 줄어들고 유연하게 프로젝트를 관리할 수 있기 때문입니다. 프로젝트가 많아지면 어떤 프로젝트에 어떤 권한을 주었는지 찾는 것도 어려워집니다. 이때, 프로젝트를 폴더로 그룹화시켜 체계적으로 관리할 수 있습니다. 내가 편하게 사용할 수 있게끔 하기 위해서!
• 중견기업 이상의 기업들, 2-3000명 기업들 : 어떤 it적 리소스?

<구글 클라우드와 상호작용하는 4가지 방법>

• 구글 클라우드 콘솔
• 클라우드 SDK 및 클라우드 shell
•  

• 사용할 수 있게끔 할 것인지 선택할 수 있다

<클라우드 콘솔 모바일 앱>

• 그닥…
• 큰 아이패드 굿, 휴대폰 권장X, 간단한 상태 정보 정도는 가능

마켓플레이스에 이미 설치되어 있는 이미지가 있다.

손쉽게 작업 환경을 만들 수 있다.

<솔루션에 빠르게 액세스할 수 있도록 하는 클라우드 마켓플레이스>

• 윈도우를 깔고 싶어 → 윈도우는 제공 된다 → l4switch, 방화벽, 특정 제품은 클라우드가 제공하지 않음 → 마켓플레이스 서드파트에서 제공하는 이미지 있음 → 모든 장비들은 클라우드에 이미지 제공하고 있음 → 없는 게 없다 → 필요하면 이미지 만들 수도 있다
• 리눅스 라이선스 비용X(red hat 제외)
• 라이선스에 따라 비용 부과 → 마켓플레이스에서 이미지 선택 → 비용이 부과된다 → 라이선스 있는 이미지도 없는 이미지도 있다

<Virtual Private Cloud 네트워킹>

• 클라우드 처음 등장했을 때는 클라우드가 없었다.
• VPC(Virtual Private Cloud)는 구글 클라우드에서 제공하는 가상 프라이빗 클라우드 서비스입니다. VPC를 사용하면 사용자는 클라우드 내에서 가상 네트워크를 구성할 수 있으며, 이를 통해 클라우드 내에서 논리적으로 격리된 네트워크 환경을 구성할 수 있습니다. 이를 통해 보안성을 높이고, 서로 다른 리소스 간에 안전하게 통신할 수 있습니다.
• 기존에 있던 회사들이 자기 네트워크를 그대로 클라우드로 이전하려고 하는데 그게 되지 않는다.
• 격리시킬 수 있는 환경이 필요하지만 불가능 → vpc 등장!
• 클라우드라고 하는 가상의 공간에 여러분들만의 영역을 만들어주겠다! 우리들만의 리소스 배치할 수 있는 영역!

<전역 리소스인 google cloud vpc 네트워크와 리전 리소스인 서브넷>

• Compute Engine: 관리형 가상머신 제공/부담없는 가격 책정
• • 고성능 CPU, 대용량메모리, 표준 및 공유 코어머신 유형이며 영구적이다.
• 표준/로컬 SSD 두 종류가 있다
• 시작 스크립트를 통해 작업을 설정할 수 있다.
• 기본적으로 가격은 초단위로 책정된다.

<compute engine을 통한 수평 확장 또는 수직 확장>

• 컴퓨터 리소스가 부족하면? 장비 업그레이드! 기존 버리고 새 장비 구입 or 기존 장비 업그레이드! scale up &down ↔ scale in&out : 동일한 성능 장비를 더 구입해서 들어오는 요청을 분산시켜서 처리할 수 있게끔
• scale in&out : 수평 확장
• 인스턴스 성능 부족 → 인스턴스 하나 업그레이드 or 여러 인스턴스 만들어내거나

<VPC 네트워크의 토폴로지 직접 제어>

• vpc 간 1대1로 연결하는 방식 중에는 vpc 피어링도 있다. 다이렉트로 연결하는 방식!

<전역 cloud balancing으로 전 세계에 단일 프런트엔드로 제공되는 애플리케이션>

• 나는 특정 리전에만 만들고 싶어! → 가능!
• 각각의 리전별로 서비스 배치, 서비스를 글로벌 로드 발란스로!
• 전역 Cloud Load Balancing : 구글 클라우드 같은 경우 프로젝트를 만들 때 모든 region에 걸친 가상 세계를 생성
• 글로벌 서버 로드 발란서 global server load balancer GSLB
• 부하 분산 옵션 제품군 제공하는 Google VPC - 전역 HTTP(S), 전역 SSL 프록시, 전역 TCP 프록시, 리전(network slb), 리전 내부. 특히 리전 내부(VPC 내 트래픽의 부하 분산 장비)의 경우 무료이다!
• CDN(Cache) 오리진 사이트에 정보 복제. www.net.ac 정보 존재

이 문서는 구글 클라우드의 기능과 사용 방법에 대해 설명하고 있습니다. 구글 클라우드는 기업들을 위한 클라우드 서비스로, 기업들은 구글 클라우드를 사용하여 IT 리소스를 효율적으로 관리할 수 있습니다. 구글 클라우드는 기업들이 클라우드를 이용해 비즈니스 프로젝트를 성공적으로 진행할 수 있도록 다양한 기능을 제공합니다.

첫째, 구글 클라우드를 사용하면 프로젝트를 폴더로 그룹화하고 권한을 할당할 수 있습니다. 이는 프로젝트가 많아지면 어떤 프로젝트에 어떤 권한을 주었는지 찾는 것이 어려워지기 때문입니다. 이때, 프로젝트를 폴더로 그룹화시켜 체계적으로 관리할 수 있습니다. 내가 편하게 사용할 수 있게끔 하기 위해서입니다.

둘째, IAM 역할과 서비스 계정을 사용하여 권한을 정확하게 정의하고 서버 간 상호작용을 제어하는 것이 가능합니다. 이러한 기능을 활용하면, 프로젝트에 대한 접근 권한을 정확하게 설정하여 보안성을 강화할 수 있습니다. 또한, 서비스 계정을 사용하면 자동화된 작업을 수행할 수 있습니다.

셋째, VPC를 사용하여 가상 네트워크를 구성하고 전 세계에 단일 프런트엔드로 제공되는 애플리케이션을 만들 수 있습니다. VPC를 사용하면 사용자는 클라우드 내에서 가상 네트워크를 구성할 수 있으며, 이를 통해 클라우드 내에서 논리적으로 격리된 네트워크 환경을 구성할 수 있습니다. 이를 통해 보안성을 높이고, 서로 다른 리소스 간에 안전하게 통신할 수 있습니다.

넷째, 구글 클라우드는 다양한 방식으로 플랫폼과 상호작용할 수 있도록 지원합니다. 구글 클라우드 콘솔, 클라우드 SDK 및 클라우드 셸, 모바일 앱을 통해 구글 클라우드와 상호작용할 수 있습니다. 또한, 클라우드 마켓플레이스에서는 제휴 업체의 솔루션에 빠르게 액세스할 수 있습니다.

다섯째, Compute Engine은 관리형 가상 머신을 제공하며, 고성능 CPU, 대용량 메모리, 표준 및 공유 코어머신 유형이며 영구적입니다. 이외에도, 표준/로컬 SSD 두 종류가 있습니다. 시작 스크립트를 통해 작업을 설정할 수 있으며, 기본적으로 가격은 초단위로 책정됩니다. Compute Engine을 통한 수평 확장 또는 수직 확장도 가능합니다.

여섯째, 구글 클라우드는 범용적인 로드 밸런싱 옵션과 CDN caching을 제공합니다. 따라서, 전 세계 어디에서나 빠르고 안정적인 서비스를 제공할 수 있습니다.

구글 클라우드는 기업들에게 다양한 기능과 가능성을 제공하는 강력한 플랫폼입니다. 이러한 기능들을 통해 기업들은 비즈니스 프로젝트를 성공적으로 진행할 수 있으며, 빠르고 안정적인 서비스를 제공할 수 있습니다.

• 가장 유명한 CDN 업체? → 아카마이

---

<다양한 상호연결 옵션을 제공하는 google cloud>

• 다이렉트 피어링 : 구글 회사 네트워크에 연결할 때 사용하는 것
• 연결해서 쓰는 경우 : 유튜브, 구글 자체적 서비스, 우리 회사가 무언가를 하고 있어, 빠른 정보 주고 받아야 할 것 같다 → 다이렉트 피어링
• 구글, 우리회사 다이렉트 연결한 회선
• 이동통신사, 이미 구글과 연결되어 있다. 우리는 이동통신사하고만 연결하면 된다!
• IPsec VPN 터널, 다이렉트 피어링, 이동통신사 피어링, dedicated interconnect, partner interconnect
• Google Cloud 중 다양한 상호연결 옵션을 제공 - IPsec VPN 터널, 다이렉트 피어링, 이동통신사 피어링, Dedicated Interconnect, Partner Interconnect 등

1. block storage
   • Local HDD Disk(DAS)
   • SAN(storage area network)
2. file storage
   • NAS - NFS, CIFS : 공유폴더
3. object storage
   • AWS S3
   • GCP cloud storage
   • 그냥 백지 ,무수히 많은 서버들이 연결되어있다
   •  

클라우드 스토리지가 data lake 용도로 사용되어짐

<Cloud Storage DataLake>

• 대용량 데이터 저장(용량을 관리할 필요 없음)
  • 2000년 초반에 GFS(Google File System)
  • 2010년 초반에 Colossus, Cloud Storage, BigQuery, BigTable, Spanner
• 다양한 type 데이터
• 보안
• 언제든지 접근 가능

<바이너리 대형 객체(BLOB) 스토리지인 Cloud Storage>

• 데이터 암호화 제공
• 인터넷 연결 상관 없이 가져오기 서비스 통해서 파일 올리기 내리기 가능

<버킷으로 구성되는 cloud storage 파일>

• 버킷 : c drive, d drive
• 버킷 안에 오브젝트라고 하는 단위를 저장하게 되는데, 버킷 안에 폴더를 만들 수 있나? 원래 오브젝트 스토리지는 폴더 단위가 없다. 그러나 파일 시스템에 익숙해져 있다. 비슷한 환경이 필요하다. 그래서 폴더 개념이 나왔지만 실제 폴더가 아니다.
• 버킷 만들 때 주의할 점 : 고유 이름, 중복되면 만들어지지 않음(다른 회사와 이름이 겹치지 않게끔)
• 여러가지 스토리지 클래스를 가지고 있다. 기업에서 데이터를 구분할 때 어떤 식으로 구분할까? 가장 일반적인 구분 방법은 얼마나 데이터가 자주 사용되어지는가? → 자주 사용=hot! 자주 읽어올 수 있는 스토리지 공간에 저장해야 한다. 1년에 1-2번만 읽어들인다면? → 실시간으로 데이터 가져와야 하는 공간에 저장하면 공간 용량, 비용 낭비
• 데이터의 가치에 따라서 우리는 저장 등급을 나눌 수 있다.
• 내가 얼마나 데이터가 중요하냐에 따라서 하나의 리전에만 저장할건지, 두 개의 리전에 저장을 할건지
• 데이터 회사가 지상에 건설되어 있다. 홍수가 나면 데이터 센터도 잠긴다. 내부적인 스프링클러 이상 발생으로 데이터 센터 잠기는 경우도 있다. 그 안에 있는 데이터 다 날라간다. 중요 데이터는 리전을 2개 쓰자! 진짜 중요한 데이터!!!!!!는 멀티리전 사용 ex. 중권회사 고객들의 정보는 돈!
• 버킷 접근 사용자를 제어할 수 있다.
  • IAM 정책
  • 엑세스 제어 목록(ACL) : access control list
• snap shot 기술 : 지금 현재 상태 그대로 저장하는 기술
• 실제로 클라우드 모든 리소스는 오브젝트. 오브젝트에 대한 상태 정보를 그대로 기억하고 있으면 언제든지 다시 되돌릴 수 있다.
• 안에 있는 정보를 버전 관리한다 = 파일 수정X, 오브젝트 스토리지 복구 불가능 → 실수 만회할 수 있게끔 하기 위해 오브젝트 버전 관리가 들어감
• 블록 스토리지 - 메타와 데이터 나눠짐(오브젝트 스토리지는 나눠지지 않음)
• 중요 데이터는 영원히 중요할까? 그렇지는 않다.
• 모니터링 하고 있다가 오브젝트가 외부에서 읽어들이는 횟수를 체크. 1년에 한 번이라면? 핫한 데이터가 아니다. 비즈니스적으로 중요하지 않다→다른 등급으로 내림
• 협력 관계 회사에게 어떠한 오브젝트를 share해야한다면 일시적으로 ACL 사용해서 제어. 버킷 사용해서 설정하는 것을 권장함

<Cloud Storage 클래스 선택하기>

• 저장할 때 저장된 데이터를 필요에 의해 읽을 때, 읽는 비용 발생
• 멀티 리전을 쓰게 되면 그만큼 데이터를 안전하게 관리할 수 있다.
• 얼마나 데이터가 중요하냐에 따라 싱글, 멀티 정할 수 있다
• 리전이 많이 배치되어 있는 국가들이 서비스를 사용할 수 있다

<모든 스토리지 클래스에 적용되는 특성>

• 짧은 지연 시간 : 올리고 내리는 데 있어서 많은 지연 시간이 걸리지 않는다
• 굉장히 안전하게 데이터가 관리되어지고 있다
• 하나의 리전에 문제가 생겼을 때 다른 리전을 통해서 정보를 사용할 수 있다

<데이터를 cloud storage로 가져오는 여러 가지 방법>

• 압축해서 파일 올리는 것 등은 용량이 얼마 되지 않을 때 가능
• 몇 테라가 넘어가게 되면 전송이 비효율적일 수 있다 → 스토리지 트렌스퍼 서비스 통해서 일정 기간마다 네트워크 통해서 데이터 이전할 수 있다 🎃전용회선 써야 안전하다🎃 → 안되면 구글 클라우드에 요청
• transfer appliance : 외장하드를 택배로 보내줌. 안전하게. 외장하드에 데이터 넣는다. 그 데이터는 암호화되어 있다.

<관리형 NoSQL인 Cloud Bigtable>

• 모든 서비스들은 대부분 구글에서 만들어졌다
• 오픈소스 쓰게 되면 저비용으로 서비스 제공받을 수 있다
• NoSQL : 스토리지와 비슷한 맥락
• 관계형 데이터베이스는 한정적이다.
• 데이터를 일관성있게 저장하기가 불가능
• 구글 검색 엔진에서도 빅테이블을 사용해서 우리들이 검색한 내용을 찾아서 출력해준다!

<bigtable 액세스 패턴>

• 일괄처리 방식
  • 하둡, dataflow streaming
• 스트리밍 처리 방식
  • dataflow streaming
  • 스트림데이터, 배치데이터 둘 다 처리 가능
• 빅테이블 활용도 높다!

<관리형 RDBMS인 Cloud SQL>

• 같은 리전에 마스터 slave 만들어두면 다른 가용 영역을 통해서 서비스를 제공받을 수 있게끔 만들 수 있다
• mysql은 외부에서 직접적인 연결이 불가능하다
• 구글 보안 적용 : 실제로 구글 클라우드 내에서만 접근할 수 있다. 외부에서 접근하려면 할 수는 있지만 권장하지는 않는다.
• VM Instance에 Public ID 주고 공개할 경우 → 랜섬웨어 공격이 바로 이뤄진다(암호화를 권장하는 이유)
• Cloud SQL를 표준 드라이버, Compute Engine 인스턴스 등의 다른 Google cloud service와 사용 가능

<수평으로 확장 가능한 RDBMS인 Cloud Spanner>

• 관계형 데이터베이스 문제 해결
• 스패너는 정형, 비정형 데이터 모두 처리 가능
• 목적 자체가 분산 환경에서 사용할 수 있게끔 만들어졌다
• Fireestore: NoSQL 클라우드 데이터베이스로서 데이터를 저장하고 동기화하는 데 사용된다. 트랜잭션이 가능하고, 쿼리가 복잡하지 않음 !
•  

cloud storage : 웹서버로 사용 가능 static web page

<IaaS와 PaaS>

• 인스턴스를 활용하는 부분에서 구글 쿠버네티스 엔진이 등장하게 된다
• server : VM instance
• master는 구글 클라우드에서 제공해줌
• slave or worker mode
• app engine
  • computer engine
  • google kubernetes engine
• IaaS : 관리 high 비용 low

<IaaS를 통해 하드웨어를 가상화하여 리소스 공유 가능>

• 하이퍼바이저 : vmware, kvm, zen, 조종 역할
• language, library, version 문제로 충돌 발생 가능성 존재 + security 문제 발생 가능성 존재

<유연성이 뛰어난 대신 부팅 시간과 리소스가 소요됨>

• 물리적 리소스 추가 :전원 켜진 상태에서는 cpu 등 변경 불가
• 앱을 올리기 위해서는 os가 부팅되어야 한다
• 리소스 낭비가 심하다. 한 개 앱을 올리기 위해서는 os 깔아야 하는데, 어느 정도 리소스를 잡아먹음. 앱 구동하는데의 리소스까지 하게되면 많은 리소스 소모됨

<프로그래밍 서비스에 대한 액세스르 제공하는 app engine>

• 컨테이너 기반 구동
• 빠른 시간 안에 작은 리소스 가지고 구동할 수 있게끔 = 컨테이너 기술
• PaaS에 대한 App Engine 기능 제공해준다
• 수요에 맞춰 확장하는 플랫폼. ‘확장’에서 알수 있듯 앱 사용자 수가 폭발적으로 증가하면, 추가적으로 하이퍼바이저와 OS를 만들어 올려야 한다. 그리고 여기서 앱을 복제해 오기까지 하려면 시간이 엄청 걸리기에 ‘확장’ 기능을 사용하려는 것! (컨테이너를 원하는 만큼 만들어서 사용)

<IaaS의 유연성과 PaaS의 확장성을 제공하는 컨테이너>

• 아파트가 생기면 동일 면적 주택 수가 많아진다
• 컨테이너는 집어넣을 수 있다. 무엇을 집어넣어서 외부와 격리시킨다. 격리된 공간 제공. 리소스 격리!
• 리소스 : CPU memory storage network
• 앱이 돌아가도록! 앱에 필요한 라이브러리 제공
• os 탑재 이유는? 개발자마다 동일한 환경 구성할 수 있다. 앱이 밑에 있는 하드웨어를 쓰게끔 하기 위해서!
• 커널 오픈 os는 리눅스뿐! 컨테이너가 리눅스베이스에서만 동작을 하게 된다

<구성 가능하고 이동성이 뛰어난 독립 실행형 컨테이너>

• 이미지 셰어링 사이트 = 도커 허브
• https://hub.docker.com/
• docker official image : 신뢰성!
• 도커 허브의 또다른 특징 : 하루에 무료 계정은 하루 호출 이미지 갯수가 제한적
• 만약 회사가 팀프로젝트 할 때 도커 허브 사용 해야 한다면 pro or team 중 선택
• 어느 위치에 있던지 간에 도커가 설치되어있다면 어디가서든지 동일한 환경에서 개발환경을 가져갈 수 있다
• https://kubernetes.io/

<여러 호스트의 많은 컨테이너를 쉽게 조정할 수 있게 해주는 kubernetes>

• 배들이 어떠한 항구에 가서 컨테이너를 내리고 올려야 한다
• 이런 컨테이너를 이동할 수 있는 기반 시설 필요
• 버전 관리! 버전 업데이트 해야 하는데 도커 사용하면 일일이 컨테이너에 가서 하나하나 업그레이드를 시켜줘야 한다
• 또는 지금 현재 동작하고 있는 컨테이너가 있는 서버에 유지보수 차원에서 작업해야한다면 그 위에 올라가있는 컨테이너들은 수동으로 다 넘겨줘야 한다
• 그리고 나서 서버에 유지보수 후에 다른 쪽으로 옮겨야 하거나… 여러 가지 복잡한 상황들이 발생하게 된다 이러한 것들을 효율적으로 관리할 수 있는 오케스트레이션 툴이 필요하게 됐다. 이 툴이 바로 쿠버네티스!
• 표준화될 것 같았는데 갑자기 쿠버네티스 투척 → 엄청난 컨테이너를 쿠버네티스 통해서 쉽고 빠르게 관리할 수 있게 됐다. → 쿠버네티스가 표준처럼 자리잡음
• 이미 사람들이 이 쿠버네티스에 대해서 많이 사용하기 시작했다. 그리고 검증되어있는 솔루션! 구글 클라우드가 몇 천개 컨테이너로 이루어져 있다.
• 모든 클라우드 밴더사들이 쿠버네티스 이용해서 자신 클라우드 환경에 맞게 변형해서 서비스 제공 중