강의 개요
| 섹션 | 제목강의 | 수 | 소요 시간 | 주요 내용 |
| 1 | 강의 소개 | 2개 | 14분 | 강의 개요 및 목표 소개 |
| 2 | GCP란? | 2개 | 15분 | GCP 개념, 클라우드 플랫폼 비교 |
| 3 | GCP 가입 및 활용 | 2개 | 8분 | GCP 가입, 기본 UI 소개 |
| 4 | IAM | 4개 | 23분 | 사용자/서비스 계정 관리, 권한 설정 |
| 5 | VPC | 3개 | 16분 | 네트워크 구성 및 Subnet 설정 |
| 6 | Architecture 작성 | 2개 | 12분 | 현재 구성 시각화 및 draw.io 활용 |
| 7 | Compute Engine | 8개 | 1시간 7분 | VM 생성, 애플리케이션 배포, 방화벽 설정 |
| 8 | Private Compute Engine | 8개 | 1시간 41분 | Private VM 구성, Bastion/IAP 접근 |
| 9 | Cloud SQL (PostgreSQL) | 4개 | 40분 | DB 생성, 연결 및 아키텍처 반영 |
| 10 | Cloud LoadBalancer | 7개 | 1시간 | 로드밸런싱 구성 및 반영 |
| 11 | Domain 구매 및 등록 | 5개 | 35분 | 도메인 구매, DNS 설정 |
| 12 | GCS (Google Cloud Storage) | 4개 | 17분 | 버킷 생성, 객체 저장 및 BigQuery 연계 |
| 13 | BigQuery | 3개 | 29분 | 데이터 분석, Looker Studio 시각화 |
| 14 | GKE (Kubernetes Engine) | 4개 | 30분 | Autopilot 클러스터 구성, Nginx 배포 |
| 15 | Cloud Monitoring | 2개 | 7분 | 모니터링 개요 및 콘솔 사용법 |
| 16 | Agent Builder | 2개 | 17분 | 대화형 AI 에이전트 구현 |
| 17 | 아키텍처 정리 | 1개 | 4분 | 전체 시스템 아키텍처 정리 |
| 18 | 기타 | 4개 | 41분 | 명명규칙, Billing, CLI 설치, 방화벽 추가 |
| 19 | 강의 정리 | 1개 | 6분 | 전체 과정 요약 및 마무리 |
[2-1] GCP란?
GCP는 Google Cloud Platform의 약자로, 구글에서 제공하는 클라우드 컴퓨팅 서비스입니다. GCP는 다양한 클라우드 서비스(예: 컴퓨팅, 스토리지, 데이터베이스, 머신러닝 등)를 제공하여 사용자가 애플리케이션을 개발, 배포 및 운영할 수 있도록 지원합니다. GCP를 사용하면 인프라를 직접 관리할 필요 없이 구글의 글로벌 인프라를 활용하여 확장 가능하고 안정적인 애플리케이션을 구축할 수 있습니다.
GCP의 장점 (AWS, Asure랑 동일)
- 확장성: GCP는 구글의 글로벌 인프라를 기반으로 하여 높은 확장성을 제공합니다. 필요에 따라 리소스를 쉽게 확장하거나 축소할 수 있습니다.
- 다양한 서비스: 컴퓨팅, 스토리지, 데이터베이스, 머신러닝 등 다양한 클라우드 서비스를 제공합니다.
- 보안: 구글의 보안 인프라를 통해 데이터와 애플리케이션을 보호할 수 있습니다.
- 비용 효율성: 사용한 만큼만 비용을 지불하는 유연한 가격 정책을 제공합니다.
- 고성능: 구글의 네트워크와 데이터 센터를 통해 높은 성능을 보장합니다.
- 통합 관리: GCP 콘솔을 통해 모든 서비스를 통합적으로 관리할 수 있습니다.
GCP의 단점
- 복잡성: 다양한 서비스와 기능이 있어 처음 사용하는 사용자에게는 다소 복잡할 수 있습니다.
- 비용 예측 어려움: 사용량에 따라 비용이 변동되기 때문에 정확한 비용 예측이 어려울 수 있습니다.
- 지역 제한: 일부 서비스는 특정 지역에서만 제공될 수 있습니다.
- 학습 곡선: GCP의 다양한 기능을 완전히 이해하고 활용하기 위해서는 학습이 필요합니다.
- 지원 비용: 고급 지원 서비스를 이용하려면 추가 비용이 발생할 수 있습니다.
[2-2] 주요 클라우드 플랫폼의 비교
주요 클라우드 플랫폼인 GCP(Google Cloud Platform), AWS(Amazon Web Services), Azure(Microsoft Azure)를 비교해보겠습니다.
1. GCP (Google Cloud Platform)
장점
Google의 강력한 데이터 분석 및 머신러닝 도구 제공 (BigQuery, TensorFlow 등)
Kubernetes의 창시자로서 강력한 컨테이너 관리 서비스 (GKE)
뛰어난 네트워크 성능 및 글로벌 네트워크 인프라
단점
AWS와 Azure에 비해 비교적 서비스 범위가 좁음
일부 지역에서의 지원 및 서비스 가용성 제한(아시아 지원 많이 되었음)
2. AWS (Amazon Web Services)
장점
가장 오래되고 성숙한 클라우드 플랫폼으로서 다양한 서비스 제공
글로벌 인프라 및 데이터 센터의 광범위한 분포
다양한 컴퓨팅, 스토리지, 데이터베이스 옵션
단점
복잡한 가격 구조
일부 서비스의 경우 초기 설정 및 관리가 복잡할 수 있음
3. Azure (Microsoft Azure)
장점
Microsoft 제품과의 높은 호환성 (Windows Server, Active Directory, SQL Server 등)
하이브리드 클라우드 솔루션 제공
강력한 개발자 도구 및 DevOps 지원 (Visual Studio, GitHub 통합 등)
단점
일부 서비스의 경우 성숙도가 AWS에 비해 낮음
복잡한 가격 구조
추가적인 고려사항 정리
1. 추가적인 비교 요소
커뮤니티 및 생태계
AWS: 가장 큰 커뮤니티를 보유하고 있으며, 다양한 오픈 소스 프로젝트와의 통합이 잘되어 있습니다.
Azure: Microsoft 개발자 커뮤니티를 기반으로 하며, .NET 개발자에게 유리한 환경을 제공합니다.
GCP: Google의 기술력을 바탕으로 빠르게 성장하는 커뮤니티를 가지고 있으며, 데이터 과학 및 머신러닝 분야에서 강력한 커뮤니티를 형성하고 있습니다.
가격
세 플랫폼 모두 사용량 기반으로 과금되지만, 서비스별, 지역별, 사용량에 따라 가격이 다르기 때문에, 각 프로젝트에 맞는 TCO(총 소유 비용)를 꼼꼼히 비교해야 합니다.
보안
세 플랫폼 모두 강력한 보안 기능을 제공하지만, 각 기업의 보안 정책 및 규정 준수 요구 사항에 따라 적합한 플랫폼을 선택해야 합니다.
2. 각 플랫폼의 추가적인 강점
GCP
- 서버리스 컴퓨팅: Google Cloud Functions, App Engine 등 서버리스 컴퓨팅 서비스를 통해 빠르고 효율적인 개발이 가능합니다.
- 데이터 엔지니어링: BigQuery, Dataflow 등 데이터 처리 및 분석 도구를 통해 대규모 데이터를 효과적으로 처리할 수 있습니다.
AWS
- 다양한 서비스: IaaS, PaaS, SaaS 등 다양한 서비스 모델을 제공하여, 다양한 워크로드에 맞는 솔루션을 선택할 수 있습니다.
- IoT: AWS IoT Core를 통해 IoT 기기를 연결하고 관리할 수 있는 포괄적인 플랫폼을 제공합니다.
Azure
- 하이브리드 클라우드: Azure Stack을 통해 온프레미스 환경과 클라우드 환경을 통합하여 관리할 수 있습니다.
- 컨테이너: Azure Kubernetes Service (AKS)를 통해 Kubernetes 클러스터를 쉽게 관리할 수 있습니다.
요약
GCP는 데이터 분석 및 머신러닝에 강점을 가지고 있으며, 네트워크 성능이 뛰어납니다.
AWS는 가장 다양한 서비스와 글로벌 인프라를 제공하며, 성숙한 클라우드 플랫폼입니다.
Azure는 Microsoft 제품과의 높은 호환성과 하이브리드 클라우드 솔루션에 강점을 가지고 있습니다.
각 클라우드 플랫폼은 특정 요구사항과 사용 사례에 따라 장단점이 다르므로, 프로젝트의 필요에 맞는 플랫폼을 선택하는 것이 중요합니다.
[3-1] Google Cloud 가입하기
- 구글 가입
- 구글 콘솔 접속
- "결제" 서비스에서 결제수단을 등록해야함
- 3개월 300달러 무료 체험판 제공됨(무료 체험판이 종료되고, 자동 결제 안됨)
- 새로운 서비스를 사용할 때, 해당 API 서비스 페이지에 접속하여, 활성화를 눌러주어야 함(다른 Cloud 회사와 다름)
[3-2] Google Cloud Platform 둘러보기
- AWS보다는 서비스는 적으나, AI 쪽에 강점이 있다.
- 콘솔이 편리한 편은 아니다.
- IAM = IAM
- Compute Engine = EC2 (VM 인스턴스 관리)
[4-1] GCP IAM 서비스 란?
GCP IAM(Identity and Access Management) 서비스는 Google Cloud Platform에서 리소스에 대한 액세스를 제어하고 관리하는 서비스입니다. IAM을 사용하면 사용자, 그룹, 서비스 계정 및 기타 엔터티에 대해 세밀한 권한을 설정할 수 있습니다. 주요 기능은 다음과 같습니다.
주요 기능
역할 기반 액세스 제어 (RBAC) -> 사용자/서비스계정에게 역할을 부여한다.
사용자에게 특정 역할을 부여하여 필요한 권한만 부여할 수 있습니다.
역할은 사전 정의된 역할(기본 역할)과 사용자 정의 역할로 나뉩니다.
정책 관리 -> 리소스에 정책을 부여한다.
IAM 정책을 통해 리소스에 대한 액세스를 제어할 수 있습니다.
정책은 특정 리소스에 대해 어떤 사용자가 어떤 작업을 수행할 수 있는지 정의합니다.
서비스 계정
애플리케이션이나 VM 인스턴스가 GCP 리소스에 액세스할 수 있도록 하는 특수한 계정입니다.
서비스 계정에 대한 키를 생성하여 애플리케이션에서 인증에 사용할 수 있습니다.
키의 용도란? 애플리케이션이나 VM 인스턴스가 GCP 리소스에 접근할 때 인증하기 위한 인증키 역할을 한다.
조직 정책
조직 수준에서 정책을 설정하여 하위 리소스에 대한 일관된 액세스 제어를 적용할 수 있습니다.
요약
GCP IAM 서비스는 GCP 리소스에 대한 액세스를 안전하고 효율적으로 관리할 수 있도록 도와주는 중요한 도구입니다. 이를 통해 조직 내에서 권한을 세밀하게 제어하고, 보안성을 높일 수 있습니다.
[4-2] GCP에서 Service Account 생성하기
<<실습 Start>>
Service Account 생성
- IAM 서비스 접속
- "서비스 계정" 메뉴 접속
- "서비스 계정 만들기" 버튼 클릭
- "서비스 계정명/설명" 입력
- "역할" 추가
(Compute Engine 검색 후, Agent 권한 선택)
- "정책" 건너뛰기
Service Account 키 만들기
- 생성된 Account 상세 화면 이동
- "키" 탭으로 이동
- "키 만들기" 클릭
- "json" 형태로 저장
<<실습 End>>
GCP IAM의 서비스 키는 주로 애플리케이션이나 서비스가 GCP 리소스에 접근할 수 있도록 인증하는 데 사용됩니다. 서비스 키는 서비스 계정과 연결되며, 이를 통해 애플리케이션이 안전하게 GCP API를 호출할 수 있습니다.
애플리케이션 인증
애플리케이션이 GCP 리소스에 접근할 때 서비스 키를 사용하여 인증합니다.
예를 들어, Google Cloud Storage에 파일을 업로드하거나 BigQuery에서 데이터를 쿼리할 때 사용됩니다.
자동화된 작업
CI/CD 파이프라인이나 스크립트에서 GCP 리소스에 접근할 때 서비스 키를 사용합니다.
예를 들어, Jenkins나 GitHub Actions에서 GCP 리소스를 관리할 때 사용됩니다.
서버리스 환경
Cloud Functions, Cloud Run 등 서버리스 환경에서 GCP 리소스에 접근할 때 서비스 키를 사용합니다.
예를 들어, Cloud Functions에서 Firestore에 데이터를 저장할 때 사용됩니다.
서비스 키는 JSON 형식으로 제공되며, 이를 애플리케이션의 환경 변수나 설정 파일에 저장하여 사용합니다. 서비스 키를 안전하게 관리하고, 필요하지 않은 경우 삭제하는 것이 중요합니다.
[4-3] IAM과 리소스 정리
GCP에서 모든 리소스에 접근할 때 IAM의 사용자 권한을 체크한 후 해당 리소스에 접근합니다.
예를 들어, Compute Engine, Cloud Storage, 그리고 Cloud SQL에 접근하는 과정을 설명하겠습니다.
1. IAM 계정 생성 및 권한 부여
- GCP 콘솔에서 IAM & Admin > IAM으로 이동합니다.
- "추가" 버튼을 클릭하여 새로운 사용자 계정을 추가합니다.
- 해당 계정에 필요한 권한을 부여합니다. 예를 들면 아래와 같습니다.
- Compute Engine 접근 권한: roles/compute.instanceAdmin.v1
- Cloud Storage 접근 권한: roles/storage.admin
- Cloud SQL 접근 권한: roles/cloudsql.admin
2. Compute Engine 접근
- 사용자가 Compute Engine 인스턴스에 접근하려고 할 때, GCP는 해당 사용자가
roles/compute.instanceAdmin.v1 권한을 가지고 있는지 확인합니다. - 권한이 있으면 사용자는 SSH 또는 RDP를 통해 인스턴스에 접근할 수 있습니다.
3. Cloud Storage 접근
- 사용자가 Cloud Storage 버킷에 접근하려고 할 때, GCP는 해당 사용자가 roles/storage.admin 권한을 가지고 있는지 확인합니다.
- 권한이 있으면 사용자는 gsutil 명령어를 사용하여 버킷에 접근할 수 있습니다.
gsutil ls gs://<your-bucket-name>4. Cloud SQL 접근:
- 사용자가 Cloud SQL 인스턴스에 접근하려고 할 때, GCP는 해당 사용자가 roles/cloudsql.admin 권한을 가지고 있는지 확인합니다.
- 권한이 있으면 사용자는 gcloud sql connect 명령어를 사용하여 데이터베이스에 접속할 수 있습니다.
gcloud sql connect <instance-id> --user=<username>이 과정을 통해 GCP는 사용자가 각 리소스에 접근할 때마다 IAM 권한을 체크하여 적절한 접근 권한이 있는지 확인합니다.
[4-4] 특정 사용자만 특정 리소스에 접근 하도록 설정하기
특정 사용자만 특정 리소스에 접근 하도록 설정하는 방법은 아래와 같다.
1. IAM에 메뉴에 접근한다.
2. 역할을 클릭 후 상단에 + 역할 만들기를 클릭하여 새로운 역할을 생성한다.
3. 역할 이름을 입력하고, 설명이 필요하면 설명을 입력한다.
4. ID 및 역할 실행 상태는 구성에 따라서 다르게 설정한다.
5. + 권한 추가를 클릭하여 추가할 권한을 선택 후 추가 버튼을 클릭하여 추가한다.
강의에서 부여한 권한 목록은 아래와 같다.
- compute.acceleratorTypes.list
- compute.disks.list
- compute.instances.create
- compute.instances.delete
- compute.instances.list
- compute.machineTypes.list
- compute.networks.get
- compute.projects.get
- compute.regions.list
- compute.subnetworks.get
- compute.zones.list
추가로 GCP 권한관련 레퍼런스 사이트 URL은 아래와 같다.
일단 Compute Engine의 IAM 권한 관련 내용을 제공하는 내용의 URL 이다.
URL : https://cloud.google.com/compute/docs/access/iam?hl=ko
나머지 다른 리소스들의 권한을 확인하는 방법은 구글에서 "GCP SQL IAM" 이런 형태로 검색을 하면,
관련 사이트들과 권한 관련 정보를 확인 할 수 있다.
IAM 메뉴에서, "프로젝트"가 정상적으로 선택되어 있는지 확인 후, "Grant Access" 메뉴로 새로운 이메일 사용자에게, "소유자"라는 기본 역할을 주면, 첫 프로젝트를 생성한 관리자와 유사하게 "초대" 요청이 가게 되고, 해당 프로젝트를 볼 수 있게 되고 권한에 따라 리소스에 접근 가능하게 된다. 사실상 모든 작업을 거의 할 수 있게 된다.
권한은 서비스 뿐만 아니라, 서비스 내부의 세부 기능별로도 세부 권한이 나누어져 있다.
콘솔에서 해당 "Access 권한 없음"이 뜨는 경우, IAM에서 해당 로그인 사용자에게, 리소스에 대한 권한을 가진 역할이 없기 때문이다.
1. GCP IAM의 주요 목적은 무엇인가요?
해설
IAM은 사용자, 그룹, 서비스 계정의 리소스 접근 권한을 세밀하게 제어하여 보안을 강화하는 핵심 서비스입니다. 다른 옵션들은 IAM의 직접적인 주요 목적이 아닙니다.
데이터 백업 및 복구 일까요?
네트워크 트래픽 관리 일까요?
GCP 리소스 액세스 제어 및 관리 일까요?
애플리케이션 배포 자동화 일까요?
2. GCP IAM의 주요 기능 중, 사용자에게 필요한 최소한의 권한만 부여하여 보안을 강화하는 방식은 무엇인가요?
해설
RBAC는 사용자에게 특정 역할을 부여하고, 역할에 필요한 최소 권한만 할당하여 효율적이고 안전한 권한 관리를 가능하게 합니다.
조직 정책 일까요?
서비스 계정 일까요?
역할 기반 액세스 제어(RBAC) 일까요?
서비스 키 관리 일까요?
3. GCP에서 애플리케이션이나 VM 인스턴스가 GCP 리소스에 접근할 때 사용하는 특별한 계정 유형은 무엇인가요?
해설
서비스 계정은 사람 사용자가 아닌 애플리케이션, 서비스 또는 VM 인스턴스가 GCP 리소스에 프로그램 방식으로 접근할 때 사용되는 특수 계정입니다.
사용자 계정 일까요?
그룹 계정 일까요?
서비스 계정 일까요?
관리자 계정 일까요?
4. 서비스 계정을 사용하여 애플리케이션이 GCP API를 호출할 때, 주로 어떤 것을 사용하여 인증을 수행하나요?
해설
서비스 계정 키는 서비스 계정을 대신하여 애플리케이션이 GCP API 호출 시 자신을 인증하는 데 사용되는 디지털 서명 파일입니다.
사용자 이름과 비밀번호 일까요?
서비스 키 일까요?
IP 주소 필터링 일까요?
다중 인증(MFA) 일까요?
5. 강의 내용에 따르면, 사용자가 GCP 리소스에 접근하려고 할 때 GCP가 가장 먼저 확인하는 것은 무엇인가요?
해설
GCP는 어떤 리소스에 접근하든 해당 작업을 수행할 수 있는 IAM 권한이 사용자에게 있는지 먼저 확인하여 접근을 허용하거나 거부합니다.
리소스의 종류 일까요?
사용자의 네트워크 위치 일까요?
사용자의 IAM 권한 일까요?
리소스의 현재 상태 일까요?
[5-1] GCP VPC 란?
GCP VPC(Virtual Private Cloud)는 Google Cloud Platform에서 제공하는 가상 네트워크 서비스로, 클라우드 리소스를 안전하게 연결하고 관리할 수 있도록 도와줍니다. VPC를 사용하면 네트워크를 세밀하게 제어하고, 트래픽을 관리하며, 보안을 강화할 수 있습니다.
주요 기능
서브넷
VPC 내에서 IP 주소 범위를 정의하고, 리소스를 논리적으로 분리할 수 있습니다.
리전별로 서브넷을 생성하여 리소스를 배포할 수 있습니다.
방화벽 규칙
인바운드 및 아웃바운드 트래픽을 제어하는 방화벽 규칙을 설정할 수 있습니다.
특정 IP 주소나 포트에 대한 접근을 허용하거나 차단할 수 있습니다.
AWS는 stateful하고, GCP는 unstateful하며, GCP는 인바운드 및 아웃바운드 규칙을 따로 설정하지만, AWS는 일괄 반영된다.
라우팅
VPC 내에서 트래픽이 흐르는 경로를 정의할 수 있습니다.
커스텀 라우팅을 통해 특정 트래픽을 특정 경로로 유도할 수 있습니다.
피어링
서로 다른 VPC 간에 네트워크를 연결하여 리소스를 공유할 수 있습니다.
동일한 프로젝트 내 또는 다른 프로젝트 간에도 피어링이 가능합니다.
VPN 및 인터커넥트
온프레미스 네트워크와 GCP VPC를 안전하게 연결할 수 있습니다.
VPN 게이트웨이 또는 전용 인터커넥트를 통해 고속 연결을 설정할 수 있습니다.
요약
GCP VPC는 클라우드 환경에서 네트워크를 유연하고 안전하게 관리할 수 있도록 도와주는 중요한 서비스입니다. 이를 통해 네트워크를 세밀하게 제어하고, 보안을 강화하며, 다양한 네트워크 구성 옵션을 활용할 수 있습니다.
추가
GCP의 방화벽 규칙은 스테이트리스(stateless)입니다. 이는 각 패킷이 독립적으로 평가되며, 이전 패킷의 상태를 고려하지 않는다는 것을 의미합니다. 방화벽 규칙은 인바운드 및 아웃바운드 트래픽에 대해 각각 별도로 설정되며, 트래픽의 상태를 추적하지 않습니다. 이는 AWS의 SG(Secutiry Group)와는 다른 개념입니다.
[5-2] GCP VPC 생성하기
<< 실습 Start >>
- VPC 네트워크 만들기 메뉴 탖아가기
- VPC 생성, 서브넷(리전, ipv4, 범위 : 10.0.0.0/24) 생성
<< 실습 End >>
Console로 리소스로 만들어보고, Terragform으로 리소스를 만들어보는 것이 좋다.
[5-3] GCP VPC에서 Subnet 추가하기
AWS 서브넷과 GCP의 서브넷의 차이점
GCP의 서브넷과 AWS의 서브넷은 모두 가상 네트워크 내에서 IP 주소 범위를 정의하고 리소스를 논리적으로 분리하는 데 사용됩니다. 그러나 두 클라우드 제공업체 간에는 몇 가지 차이점이 있습니다.
GCP 서브넷
리전 및 서브넷
GCP에서는 서브넷이 리전 단위로 생성됩니다. 즉, 서브넷은 특정 리전에 속하며, 해당 리전 내에서만 리소스를 배포할 수 있습니다.
자동 서브넷 생성
GCP는 기본적으로 자동 모드 VPC를 제공하며, 이 경우 각 리전에 기본 서브넷이 자동으로 생성됩니다. 사용자는 필요에 따라 커스텀 서브넷을 추가로 생성할 수 있습니다.
IP 주소 할당(동일)
GCP에서는 서브넷에 할당된 IP 주소 범위(CIDR 블록)를 변경할 수 없습니다. 서브넷을 생성할 때 CIDR 블록을 신중하게 선택해야 합니다.
AWS 서브넷
가용 영역 및 서브넷
AWS에서는 서브넷이 가용 영역(AZ) 단위로 생성됩니다. 즉, 서브넷은 특정 가용 영역에 속하며, 해당 가용 영역 내에서만 리소스를 배포할 수 있습니다.
서브넷 유형
AWS에서는 퍼블릭 서브넷과 프라이빗 서브넷을 구분합니다. 퍼블릭 서브넷은 인터넷 게이트웨이를 통해 인터넷에 접근할 수 있는 반면, 프라이빗 서브넷은 인터넷 접근이 제한됩니다.
IP 주소 할당(동일)
AWS에서는 서브넷에 할당된 IP 주소 범위(CIDR 블록)를 변경할 수 없습니다. 서브넷을 생성할 때 CIDR 블록을 신중하게 선택해야 합니다.
요약
GCP 서브넷은 리전 단위로 생성되며, 자동 모드 VPC에서 기본 서브넷이 자동으로 생성됩니다.
AWS 서브넷은 가용 영역 단위로 생성되며, 퍼블릭 서브넷과 프라이빗 서브넷으로 구분됩니다.
두 클라우드 제공업체 모두 서브넷 생성 시 CIDR 블록을 신중하게 선택해야 하며, 생성 후에는 변경할 수 없습니다.
[6-1] 클라우드 아키텍처가 중요한 이유?
클라우드 아키텍처는 클라우드 환경에서 애플리케이션과 서비스를 설계, 배포 및 관리하는 데 중요한 역할을 합니다.
확장성
클라우드 아키텍처는 애플리케이션이 증가하는 트래픽과 데이터 양을 처리할 수 있도록 확장성을 제공합니다. 이를 통해 비즈니스 성장에 따라 리소스를 유연하게 조정할 수 있습니다.
비용 효율성
클라우드 아키텍처는 필요한 리소스만 사용하고, 사용한 만큼만 비용을 지불하는 모델을 제공합니다. 이를 통해 불필요한 인프라 비용을 절감할 수 있습니다.
가용성 및 신뢰성
클라우드 아키텍처는 고가용성과 신뢰성을 보장하기 위해 여러 리전과 가용 영역에 걸쳐 리소스를 분산시킵니다. 이를 통해 장애 발생 시에도 서비스 중단을 최소화할 수 있습니다.
보안
클라우드 아키텍처는 데이터 보호와 접근 제어를 위한 다양한 보안 기능을 제공합니다. 이를 통해 민감한 데이터를 안전하게 보호할 수 있습니다.
유연성
클라우드 아키텍처는 다양한 서비스와 도구를 통합하여 애플리케이션을 유연하게 설계할 수 있도록 합니다. 이를 통해 비즈니스 요구사항에 맞게 애플리케이션을 빠르게 변경하고 배포할 수 있습니다.
자동화
클라우드 아키텍처는 인프라 관리와 애플리케이션 배포를 자동화할 수 있는 도구와 서비스를 제공합니다. 이를 통해 운영 효율성을 높이고, 인적 오류를 줄일 수 있습니다.
이와 같이 클라우드 아키텍처는 클라우드 환경에서 애플리케이션의 성능, 비용, 보안, 유연성 등을 최적화하는 데 중요한 역할을 합니다.
[6-2] 아키텍처 그리기 with draw.io
draw.io url : https://www.drawio.com/
[7-1] Compute Engine 이란?
Google Cloud Platform(GCP)의 Compute Engine은 고성능 가상 머신(VM)을 제공하는 서비스입니다. 이를 통해 사용자는 클라우드 환경에서 다양한 워크로드를 실행할 수 있습니다.
유연한 VM 구성
다양한 CPU, 메모리, 디스크 옵션을 선택하여 VM을 구성할 수 있습니다.
필요에 따라 VM의 크기를 조정할 수 있습니다.
자동 확장 및 부하 분산
자동 확장 기능을 통해 트래픽 증가에 따라 VM 인스턴스를 자동으로 추가할 수 있습니다.
부하 분산 기능을 통해 트래픽을 여러 VM 인스턴스에 분산시켜 성능을 최적화할 수 있습니다.
고가용성 및 내구성
여러 리전과 가용 영역에 VM을 배포하여 고가용성을 보장할 수 있습니다.
지속적인 데이터 백업과 복구 기능을 제공합니다.
보안
VM 인스턴스에 대한 네트워크 방화벽 규칙을 설정하여 보안을 강화할 수 있습니다.
데이터 암호화 및 IAM(Identity and Access Management)을 통해 접근 제어를 할 수 있습니다.
통합 관리
GCP 콘솔을 통해 VM 인스턴스를 쉽게 관리하고 모니터링할 수 있습니다.
API와 CLI를 통해 자동화된 관리 작업을 수행할 수 있습니다.
Compute Engine은 다양한 애플리케이션과 서비스의 요구사항을 충족할 수 있는 유연하고 확장 가능한 클라우드 컴퓨팅 환경을 제공합니다.
근간 서비스 EC2와 같이 VM을 제공해준다.
[7-2] Cloud Shell에 대한 설명
<<실습 Start >>
콘솔 우측 상단 코드 아이콘 선택, Compute Engine에서 VM의 우측 ...을 클릭하고 "gcloud 명령어 보기"
선택 시, Cloud Shell에서 바로 VM 접근 가능
<<실습 End>>
GCP 콘솔 화면에서 실행되는 Cloud Shell은 GCP 환경 내에서 실행되는 관리형 셸 환경입니다.
Cloud Shell의 주요 특징 및 장점을 간략히 정리하면 다음과 같습니다.
- GCP 환경 내 실행: 사용자의 로컬 환경이 아닌 GCP 인프라에서 실행되므로, 로컬 환경 설정에 대한 부담이 없습니다.
- 사전 설치된 도구: gcloud 명령줄 도구를 비롯한 다양한 개발 도구가 사전 설치되어 있어 별도의 설치 과정 없이 바로 사용할 수 있습니다.(java, git 등 왠만한 것은 모두 제공)
- 웹 브라우저 기반: 웹 브라우저만 있으면 어디서든 접속하여 사용할 수 있습니다.
- 편리한 파일 관리: Cloud Storage와 연동하여 파일을 업로드하거나 다운로드할 수 있습니다.
- 안전한 환경: GCP의 강력한 보안 기능을 통해 안전하게 작업할 수 있습니다.
Cloud Shell을 사용하는 이유
- 빠른 시작: 새로운 프로젝트를 시작하거나 빠르게 테스트를 진행할 때 유용합니다.
- 다양한 환경에서의 일관성: 어떤 컴퓨터에서든 동일한 환경으로 작업할 수 있습니다.
- 리소스 관리의 편의성: gcloud 명령어를 통해 GCP 리소스를 직접 관리할 수 있습니다.
결론적으로, Cloud Shell은 GCP를 효율적으로 사용하기 위한 필수적인 도구입니다. 특히, 다양한 환경에서 GCP를 사용해야 하는 개발자나 운영자에게 유용합니다.
Cloud Shell의 비용구조
Cloud Shell은 기본적으로 무료로 제공됩니다.
GCP의 다른 서비스와 달리 별도의 비용이 청구되지 않는 이유는 다음과 같습니다.
- 제한된 리소스: Cloud Shell은 일반적으로 제한된 CPU, 메모리, 저장 공간을 제공합니다.
이러한 제한된 리소스는 대규모 작업이나 장시간 실행되는 작업에는 적합하지 않도록 설계되었습니다. - 개발 및 테스트 환경: Cloud Shell은 주로 개발자나 운영자가 간단한 작업이나 테스트를 수행하는 데 사용됩니다. 이러한 용도에 맞춰 무료로 제공되어 개발자들이 GCP를 더 쉽게 접근하고 활용할 수 있도록 지원합니다.
- GCP 서비스 홍보: Cloud Shell을 무료로 제공함으로써 더 많은 개발자들이 GCP 서비스를 사용하고,
이를 통해 GCP 생태계를 확장하려는 목적이 있습니다.
하지만 다음과 같은 경우에는 추가 비용이 발생할 수 있습니다.
- Cloud Shell에서 실행하는 다른 서비스 이용: Cloud Shell에서 Cloud Storage, BigQuery 등 다른 GCP 서비스를 이용하면 해당 서비스에 대한 비용이 발생할 수 있습니다.
- 장시간 사용: Cloud Shell 세션을 장시간 유지하거나 과도한 리소스를 사용하는 경우에는 제한이 적용될 수 있습니다.
- 특별한 요구 사항: 특별한 요구 사항이 있는 경우 유료 서비스를 이용해야 할 수 있습니다.
결론적으로, Cloud Shell은 일반적인 개발 및 테스트 작업에 필요한 기본적인 기능을 무료로 제공합니다.
하지만 대규모 작업이나 특수한 요구 사항이 있는 경우에는 유료 서비스를 고려해야 합니다.
[7-3] Compute Engine 실행하기
<<실습 Start >>
Compute Engine 서비스에서, "인스턴스 만들기" 버튼으로 생성
VM명, 메모리 & cpu 선택, OS & 스토리지 선택, 네트워킹(HTTP 트래픽 허용, 네트워크 인터페이스 미리 생성해놓은 VPC, 서브넷 설정)
생성된 VM 확인 -> 접속을 시도해도 안되는 것은, 22,8080 포트를 허용하는 방화벽이 지정이 안되어 있음
<<실습 End>>
[7-4] 방화벽 규칙을 생성하고 적용하기
GCP에서 방화벽은 네트워크 트래픽을 제어하고 보호하기 위해 사용되는 보안 기능입니다. 방화벽 규칙을 통해 인바운드 및 아웃바운드 트래픽을 허용하거나 차단할 수 있습니다.
스테이트리스
GCP의 방화벽 규칙은 스테이트리스(stateless)입니다. 각 패킷이 독립적으로 평가되며, 이전 패킷의 상태를 고려하지 않습니다.
방화벽 규칙
방화벽 규칙은 네트워크 태그, IP 주소 범위, 프로토콜 및 포트를 기준으로 트래픽을 제어합니다.
규칙은 우선순위에 따라 평가되며, 가장 낮은 숫자의 우선순위가 먼저 적용됩니다.
인바운드 및 아웃바운드 트래픽
인바운드 규칙은 네트워크로 들어오는 트래픽을 제어하고, 아웃바운드 규칙은 네트워크에서 나가는 트래픽을 제어합니다.
기본 규칙
GCP는 기본적으로 몇 가지 방화벽 규칙을 제공하며, 사용자는 필요에 따라 커스텀 규칙을 추가할 수 있습니다.
로깅 및 모니터링
방화벽 규칙에 대한 로깅을 활성화하여 트래픽을 모니터링하고 분석할 수 있습니다.
GCP의 방화벽을 통해 네트워크 보안을 강화하고, 트래픽을 세밀하게 제어할 수 있습니다.
<<실습 Start >>
방화벽 정책 서비스에서, "방화벽 규칙 만들기" 버튼으로 생성
- "방화벽 규칙명" 지정
- "방향?"은 Ingress // 바깥에서 들어오는 네트워크 통신 규칙"
- "대상 태그" 항목은 "allow-ssh-8080" // 해당 태그명이 VM 등에서 사용됨
- "소스 IPv4 범위" 항목은 모든 출발비 IP에 대상으로 적용
- "지정된 프로토콜 및 포트" 항목 "22,8080" // 특정 포트만 적용
Compute Engine 서비스에서, 특정 VM 수정 후, "네트워크 태그" 항목에 지정 "allow-ssh-8080"
<<실습 End>>
[7-5] 예제 Spring boot 애플리케이션 설명 및 실행하기
예제 애플리케이션 GitHub URL : https://github.com/Nanninggu/my-app/tree/gcp-app
JDK Version : corretto-17
IDE : InteliJ, URL : https://www.jetbrains.com/ko-kr/idea/download/?section=windows
소스코드 Clone 하기
예제 애플리케이션 Git Clone : git clone -b gcp-app https://github.com/Nanninggu/my-app.git
예제 애플리케이션 ID와 Password는 아래와 같습니다.
ID : user
Password : test1234AA!!
생성한 VM에서 Spring boot Application을 실행하기 위해서, jar 파일로 build 하는 것이 필요하다.(로컬에서 빌드)
VM 내부에도 java가 설치되어 있어야 한다.(cloud shell 또는 ssh 접속 후 수행)
[7-6] 예제 애플리케이션 Build 및 GCP ComputeEngine에서 실행하기
<<실습 Start>>
cloudshell에서 접속 후, jar 파일 업로드하여, "gcloud compute" + "scp" 명령어로 jar 파일을 VM으로 복사
cloudshell로 VM 접속 후, "java -jar <jar명>" 명령어로 VM 내부에서, Spring Boot 프로그램 실행
VMIP:8080 으로 접속 하여, 정상적으로 확인 가능한지 확인
<<실습 End>>
scp 명령어 : gcloud compute scp demo-0.0.1-SNAPSHOT.jar vm-tester-01:/home/may9noy1 --zone=asia-northeast3-a
jar에 대한 설명
JAR(Java ARchive) 파일은 Java 애플리케이션 및 라이브러리를 배포하기 위해 사용되는 압축 파일 형식입니다. JAR 파일은 여러 개의 클래스 파일, 메타데이터 및 리소스를 하나의 파일로 묶어 배포할 수 있게 해줍니다.
압축 형식
JAR 파일은 ZIP 파일 형식을 기반으로 하며, 파일 크기를 줄이고 전송 속도를 높이기 위해 압축됩니다.
배포 용이성
여러 개의 파일을 하나의 JAR 파일로 묶어 배포함으로써 애플리케이션 배포가 간편해집니다.
클래스패스 설정
JAR 파일을 클래스패스에 추가하여 Java 애플리케이션이 해당 JAR 파일 내의 클래스를 참조할 수 있습니다.
메타데이터 포함
JAR 파일에는 META-INF/MANIFEST.MF 파일이 포함되어 있어, JAR 파일의 메타데이터(예: 메인 클래스, 버전 정보 등)를 정의할 수 있습니다.
실행 가능 JAR
MANIFEST.MF 파일에 메인 클래스를 지정하여, JAR 파일을 실행 가능하게 만들 수 있습니다.
이를 통해 java -jar 명령어로 JAR 파일을 실행할 수 있습니다.
[7-7] 지금까지의 작업을 정리하고 아키텍처 수정하기
GCP의 방화벽 정책과 관련한 내용은 아래와 같습니다.
GCP의 방화벽은 VPC(가상 사설 클라우드) 내부에 존재합니다.
GCP의 방화벽 규칙은 VPC 네트워크 내의 인스턴스 간 및 외부와의 트래픽을 제어하는 데 사용됩니다.
이를 통해 네트워크 보안을 강화하고, 허용된 트래픽만이 네트워크를 통해 흐를 수 있도록 설정할 수 있습니다.
[7-8] Compute Engine 생성 시 주의사항
GCP에서는 Compute Engine을 생성 시 AZ를 선택하여 VM 생성이 가능하다.
AZ를 생성하는 옵션은 아래와 같이 "모두 선택" 옵션과 특정 AZ만을 선택하는 옵션이 존재한다.
위의 옵션 중에서 모두를 선택 하는 것과 특정 AZ를 지정하여 선택하는 것의 차이를 알아보면 아래와 같다.
GCP에서 Compute Engine을 생성할 때 예를들어 리전을 asia-northeast3(서울)로 선택하고 영역(AZ)을 모두로 선택한 것과 하나의 AZ(예: asia-northeast3-a)를 선택하여 생성했을 때의 차이점은 다음과 같습니다.
가용성
모두 선택: 여러 AZ에 걸쳐 인스턴스를 배포할 수 있어, 특정 AZ에 장애가 발생하더라도 다른 AZ에서 서비스가 계속 운영될 수 있습니다. 이는 고가용성을 보장합니다.
하나의 AZ 선택: 특정 AZ에만 인스턴스를 배포하므로, 해당 AZ에 장애가 발생하면 서비스가 중단될 수 있습니다.
지연 시간
모두 선택: 인스턴스가 여러 AZ에 분산될 수 있어, AZ 간 통신 시 지연 시간이 발생할 수 있습니다.
하나의 AZ 선택: 모든 인스턴스가 동일한 AZ에 위치하므로, AZ 내 통신 시 지연 시간이 최소화됩니다.
비용
모두 선택: 여러 AZ에 인스턴스를 배포할 경우, 데이터 전송 비용이 추가될 수 있습니다.
하나의 AZ 선택: 동일한 AZ 내에서만 데이터 전송이 이루어지므로, 추가 비용이 발생하지 않습니다.
관리 편의성
모두 선택: 여러 AZ에 걸쳐 인스턴스를 관리해야 하므로, 관리가 복잡할 수 있습니다.
하나의 AZ 선택: 단일 AZ 내에서 인스턴스를 관리하므로, 관리가 상대적으로 간편합니다.
따라서, 고가용성이 중요한 경우에는 여러 AZ를 선택하는 것이 좋고, 지연 시간 최소화와 관리 편의성을 중시하는 경우에는 하나의 AZ를 선택하는 것이 좋습니다.
(운영 시에는 모두 선택, 개발 시에는 하나의 AZ 선택) 모두 선택 시에는 하나의 AZ 장애 시, fail over가 발생하면서 다른 AZ 인스턴스가 동작함
1. GCP Compute Engine의 주요 역할은 무엇일까요?
해설
GCE는 GCP에서 유연한 구성의 고성능 가상 머신을 제공하는 핵심 서비스입니다. 이를 통해 클라우드에서 다양한 워크로드를 실행할 수 있어요. 다른 옵션은 각각 Cloud Storage, Cloud Functions, BigQuery의 역할입니다.
객체 스토리지 저장
고성능 가상 머신 제공
서버리스 함수 실행
데이터 웨어하우스 구축
2. GCP Cloud Shell을 사용하는 주요 장점은 무엇일까요?
해설
Cloud Shell은 GCP 환경 내에서 실행되며 gcloud 등 도구가 사전 설치되어 있어 로컬 설정 없이 웹에서 바로 사용할 수 있는 편리한 도구입니다. 리소스는 제한적이며, 다른 GCP 서비스는 유료일 수 있어요.
무제한 CPU 및 메모리 제공
로컬 환경 설정 부담 없음
모든 GCP 서비스에 대한 무료 사용
오프라인 환경에서의 접속 지원
3. Compute Engine VM에 대한 방화벽 규칙을 구성하는 주된 목적은 무엇일까요?
해설
방화벽 규칙은 VM으로 들어오거나 나가는 네트워크 트래픽을 허용하거나 차단하여 VM의 보안을 강화하고 접근을 제어하는 데 사용됩니다. 모니터링이나 OS 업데이트는 다른 도구의 역할입니다.
VM의 CPU 사용량 모니터링
네트워크 트래픽 제어 및 보안 강화
VM 간 데이터 암호화 설정
VM의 운영체제 업데이트 관리
4. GCP에서 Compute Engine VM에 방화벽 규칙을 적용하는 일반적인 방법은 무엇일까요?
해설
GCP 방화벽 규칙은 네트워크 태그를 사용하여 특정 VM 또는 VM 그룹에 적용됩니다. VM에 지정된 태그와 일치하는 규칙이 해당 트래픽에 대해 평가되어 접근을 제어해요.
VM 이름에 규칙 직접 연결
스토리지 버킷 설정 변경
네트워크 태그를 사용하여 VM 그룹 지정
운영체제 내에서 방화벽 소프트웨어 설치
5. Compute Engine VM 생성 시, 여러 가용 영역(AZ)을 선택하면 어떤 이점을 얻을 수 있나요?
해설
여러 가용 영역에 VM을 분산 배포하면 특정 AZ에 장애가 발생해도 다른 AZ의 VM이 서비스를 지속하여 애플리케이션의 고가용성을 높일 수 있습니다. 단일 AZ는 지연 시간 최소화에 유리해요.
VM 성능 향상
네트워크 지연 시간 최소화
단일 AZ 장애 시 고가용성 유지
VM 관리 복잡성 감소
[8-1] Private Compute Engine 이란?
GCP의 Private Compute Engine은 퍼블릭 인터넷에 직접 노출되지 않는 가상 머신(VM) 인스턴스를 의미합니다.
이러한 인스턴스는 프라이빗 서브넷에 배치되어 외부에서 직접 접근할 수 없으며, 보안이 강화된 환경에서 운영됩니다.
Private Compute Engine을 사용하면 내부 네트워크를 통해서만 접근이 가능하며, 보통 Bastion Host나 VPN을 통해 접근합니다.
이를 통해 중요한 데이터와 애플리케이션을 외부 위협으로부터 보호할 수 있습니다.
기존까지는 VM이 EIP를 가지고 있어, 외부에서 바로 VM에 접근 가능했다.
GCP는 무조건 Private Subnet을 가지고 생성되지만, VM이 External IP를 가지고 있는 경우에만 접근 가능하다.
그러나 대부분 Private Network 환경에, VM과
외부에서 직접 접근이 불가능한 환경에 생성된 VM을 Private Compute Engine이라고 한다.
Bastion host란? 외부에서 사적인 네트워크에 접근할 수 있는 리소스가 필요한데, 보통 원리가 VPC 내부에서는 로컬 환경이라서, A라는 VM이 B라는 VM에 접근 가능한데, 외부에서는 Private 환경에 있는 B VM에 접근할 수 없어서, external ip가 있는 A VM에 접속 후, A를 통해 B VM에 접근하는 방식이다.
[8-2] GCP의 Subnet에 대한 추가 설명 (Public Subnet, Private Subnet)
GCP에서는 퍼블릭 서브넷과 프라이빗 서브넷을 명시적으로 구분하는 설정이 존재하지 않습니다.
대신, GCP는 VPC 네트워크를 기반으로 한 서브넷 구조를 사용하며, 퍼블릭 서브넷과 프라이빗 서브넷의 구분은 서브넷의 구성 및 리소스 설정에 따라 달라집니다.
GCP에서 퍼블릭 서브넷과 프라이빗 서브넷을 구분하는 방식
서브넷 자체는 VPC 내에서 동일
GCP에서 서브넷은 단순히 VPC 네트워크 내의 IP 범위로 정의됩니다.
즉, GCP에는 "퍼블릭 서브넷"이나 "프라이빗 서브넷"이라는 구체적인 개념이 없습니다. (중요!)
퍼블릭 vs. 프라이빗의 차이는 리소스 설정에 달려 있음
퍼블릭 서브넷: 외부 IP를 할당받은 VM들이 포함된 서브넷입니다. 이 VM들은 인터넷과 직접 연결됩니다.
프라이빗 서브넷: 외부 IP 없이, 인터넷과 연결되지 않은 VM들이 포함된 서브넷입니다.
이 VM들이 인터넷에 접근하려면 NAT 게이트웨이 또는 다른 방법을 사용해야 합니다.
구체적인 구분 방법
퍼블릭 서브넷
VM에 외부 IP 주소를 할당하여 인터넷에 직접 접근 가능하게 설정합니다.
인터넷 게이트웨이(IGW)를 통해 외부와 연결됩니다.
방화벽 규칙을 설정하여 외부에서 들어오는 트래픽을 허용합니다.
프라이빗 서브넷
VM에 외부 IP 주소를 할당하지 않으며, 인터넷과의 직접 연결 없이 내부적으로만 작동합니다.
인터넷에 접근할 필요가 있을 경우 NAT 게이트웨이를 통해 외부와 연결할 수 있습니다.
프라이빗 서브넷의 VM들은 인터넷과 직접 연결되지 않기 때문에 보안상 유리할 수 있습니다.
결론
따라서 GCP에서는 서브넷이 퍼블릭인지 프라이빗인지에 대한 명시적인 구분이 없으며,
해당 서브넷 내에서 사용하는 리소스나 설정에 따라 퍼블릭과 프라이빗을 구분하게 됩니다.
즉, 퍼블릭과 프라이빗 서브넷의 개념은 서브넷의 IP 주소 할당과 방화벽, NAT 설정에 따라 달라지며,
이를 통해 두 종류의 서브넷을 구분할 수 있습니다.
즉 GCP는 서브넷에 외부에 접근 가능한 리소스(VM?)를 모아 놓으면 AWS의 퍼블릭 서브넷이라고 불리는 것과 동일하다.
추가
퍼블릭 리소스와 프라이빗 리소스의 배치
퍼블릭과 프라이빗 리소스를 서브넷별로 구분하는 것이 바람직하며, 동일한 서브넷에 퍼블릭 및 프라이빗 리소스를 혼합하는 것은 보안과 관리 측면에서 좋지 않습니다.
서브넷을 나누어 각 서브넷에 적합한 리소스를 배치하고, 필요한 경우 NAT 게이트웨이 등을 통해 인터넷과의 연결을 관리하는 것이 GCP 환경에서 권장되는 방식입니다. (중요!)
[8-3] Private Network 흐름 설명하기
GCP에서 Private Compute Engine에 안전하게 접근하기 위한 일반적인 구성은 아래와 같습니다.
각 구성 요소의 역할과 전체적인 흐름을 간략하게 요약하면 다음과 같습니다.
- Bastion Host
- 퍼블릭 서브넷에 위치하여 외부에서 접근 가능한 지점입니다.
- SSH 또는 RDP와 같은 원격 접속 프로토콜을 통해 사용자의 연결을 받습니다.
- 보안 강화를 위해 최소한의 서비스만 실행하고, 강력한 액세스 제어를 적용해야 합니다.
- Cloud Router
- Bastion Host와 Private Compute Engine 사이의 트래픽을 라우팅하여 내부 네트워크 통신을 가능하게 합니다.
(동일한 VPC 내에서 퍼블릭 서브넷에 있는 VM과 프라이빗 서브넷에 있는 VM과 Router를 통해 통신한다) - 정적 라우팅 또는 동적 라우팅 프로토콜을 사용하여 라우팅 테이블을 관리합니다.
- Bastion Host와 Private Compute Engine 사이의 트래픽을 라우팅하여 내부 네트워크 통신을 가능하게 합니다.
- Cloud NAT
- Private Compute Engine이 외부 서비스에 접근해야 할 때 사용됩니다. (NAT는 Outbound를 처리한다.)
- Private IP를 가진 Private Compute Engine이 퍼블릭 IP로 변환되어 외부와 통신할 수 있도록 합니다.
- Bastion Host를 통해 들어오는 트래픽은 Cloud NAT를 거치지 않습니다.
- Private Compute Engine
- 실제 업무를 처리하는 인스턴스입니다.
- 퍼블릭 인터넷에 직접 노출되지 않아 보안성이 높습니다.
- Bastion Host를 통해 접속한 사용자의 요청을 처리합니다.
[8-4] Private Compute Engine을 생성 후 Bastion host를 통해서 접근하기
1. GCP 에서 Cloud Router와 Cloud NAT를 생성한다.
- Cloud Router 생성
- Cloud NAT 생성
2. Compute Engine 생성
- 외부 ip 없음으로 생성(프라이빗 서브냇과 동일)
- 방화벽 정책에 ssh 정책 추가
3. Bastion host전용 Compute Engine 생성
- 외부 ip 임시로 VM 생성
- Bastion host에 접근하여 ssh 명령어를 통해 Private Compute Engine에 접근하기 위해 ssh key를 생성한다. (ssh-keygen 명령어를 입력하여 새로운 ssh 키페어를 생성하고, cat 명령어를 통해 공개키를 확인한다.)
- bastion host에서 작업 : ssh-keygen
cat /home/{location}/.ssh/id_rsa.pub
4. Private Compute Engine에 SSH Key를 추가
- Edit > Security and access > SSH Keys > + ADD ITEM 을 눌러 위에서 확인한 공개키를 복사 후 붙여넣어 준 후 수정을 완료한다.
5. Private Compute Engine에 ssh로 접근
- bastion-host에서 ssh may9noy1@10.0.2.5 해당 명령어를 통해 private compute engine으로 접근
- ssh may9noy1@10.0.2.5 → ssh {사용자이름}@{private compute engine ip}
<< 실습 Start >>
클라우드 Router 생성
- 클라우드 라우터 생성 시, 퍼블릭 서브넷용으로 생성한 정보가 필요하다.
클라우드 Nat 생성
- 클라우드 라우터 정보가 필요하다.
Private VM 생성
- VM 기본 정보와 프라이빗 서브넷 설정과 외부 IP 주소 없음으로 생성
방화벽 규칙 생성
- ssh 접속 허용을 위한 방화벽을 생성함
Private VM 수정
- "네트워크 태그"로 생성한 방화벽 규칙 태그명을 지정
Bastion host용 VM 생성
- 외부 IP 주소 있음으로 생성(외부 IP를 가지고 있음)
- Bastion host VM 접속(Cloud Shell) 후, sshgen 명령어로 ssh key 생성 및 공개키 복사
Private VM 수정
- ssh 키 항목에서, 공개 키 추가
Bastion host용 VM 접속 및 Private VM ssh 접속 테스트
- Bastion host VM 접속(Cloud Shell) 후, ssh로 private vm ip를 입력하여, 접속
<< 실습 End >>
private vm에서 apt update 할 때, 업데이트 된다는 것은, Cloud Nat를 통해, 아웃바운드 요청이 나간다는 의미이다.
[8-5] Bastion-Host 대신 IAP(Identity-Aware Proxy)를 통해 Private Compute Engine에 접근하기
GCP에서 IAP 작동 방식 설명
IAP 터널링은 GCP에서 제공하는 기능으로, 외부에서 내부 네트워크에 있는 리소스에 안전하게 접근할 수 있도록 해주는 기술입니다.
작동 방식
- 사용자가 IAP 엔드포인트에 접속 요청을 합니다.
- IAP는 사용자의 인증 정보를 검증하고, 접근 권한이 있는 경우 암호화된 터널을 생성합니다.
- 생성된 터널을 통해 사용자의 요청이 내부 리소스에 전달되고, 응답은 다시 터널을 통해 사용자에게 전달됩니다. 😀
GCP에서 IAP (Identity-Aware Proxy) 설정하기
1. 방화벽 규칙 만들기 : allow-iap
2. 대상 : 네트워크의 모든 인스턴스
3. IP 범위 : 35.235.240.0/20 (구글에서 관리를 해주고 있는 IAP 대역 입니다.)
4. 지정된 프로토콜 및 포트 : 22 입력
5. IAP 권한부여 하기: IAM 서비스로 이동하여 생성한 계정의 권한 관리로 이동 합니다. (생성한 계정을 클릭)
may9noy1@gmail 계정에서 다른역할 추가를 클릭하여 IAP 보안 터널 사용자 권한을 부여 합니다.
그리고 옆에 IAM 조건추가를 클릭하여 조건의 이름은 iap라고 입력하고 조건 편집창에는 아래와 같은 내용을 입력합니다.
destination.port == 22
6. 권한 추가 : 그리고 다른역할 추가를 클릭하여 Compute 인스턴스 관리자(v1) 역할도 함께 추가 합니다.
7. Private Compute Engine 접근 : 퍼블릭 ip가 부여되지 않은 Compute Engine을 생성하고 해당 VM에 IAP로 접근 합니다.
(Private Compute Engine 방화벽 정책설정 등 별다른 작업 업이 외부 사용자가 IAP를 통해서
Private Compute Engine에 접근 가능 합니다.) 😀
IAP(Identity-Aware Proxy)에 대한 설명
Private Compute Engine에 접근하기 위해서는 외부에서 내부로 들어오는 경로가 필요합니다.
이때 Cloud Router와 Cloud NAT를 사용하여 네트워크 경로를 설정하고 외부 IP를 할당할 수도 있지만,
IAP는 애플리케이션 레벨에서 직접 접근을 제어하기 때문에 별도의 네트워크 구성이 필요 없습니다.
IAP를 사용하면 다음과 같은 이점이 있습니다.
- 간편한 설정: IAM 정책을 설정하는 것만으로 Private Compute Engine에 대한 접근을 제어할 수 있습니다.
- 높은 보안: IAM을 기반으로 강력한 인증 및 권한 부여 기능을 제공합니다.
- 유연성: 사용자, 그룹, 서비스 계정별로 세밀한 접근 권한을 부여할 수 있습니다.
따라서 Private Compute Engine에 대한 안전하고 편리한 접근이 필요한 경우 IAP를 적극 활용하는 것이 좋습니다. 😀
GCP에서 bastion-host 대신 IAP(Identity-Aware Proxy)를 통해 private compute engine에 접근할 때의 장점과 단점을 정리한 내용은 아래와 같습니다.
장점
보안 강화
IAP는 Google의 IAM(Identity and Access Management)과 통합되어 있어, 사용자 인증 및 권한 부여를 통해 접근을 제어할 수 있습니다.
SSH 키 관리가 필요 없으며, Google 계정을 통해 접근을 제어할 수 있습니다.
간편한 접근 관리
IAP를 사용하면 방화벽 규칙을 복잡하게 설정할 필요 없이, IAM 정책을 통해 접근 권한을 관리할 수 있습니다.
특정 사용자나 그룹에 대해 접근 권한을 쉽게 부여하거나 철회할 수 있습니다.
감사 및 모니터링
IAP는 접근 로그를 제공하여 누가 언제 어떤 리소스에 접근했는지 추적할 수 있습니다.
이를 통해 보안 감사 및 모니터링이 용이합니다.
VPN 불필요
IAP를 사용하면 VPN을 설정하지 않고도 안전하게 내부 리소스에 접근할 수 있습니다.
네트워크 설정이 간소화되고, VPN 관련 비용을 절감할 수 있습니다.
단점
초기 설정 복잡성
IAP를 설정하는 과정이 다소 복잡할 수 있으며, IAM 정책 및 방화벽 규칙을 올바르게 구성해야 합니다.
초기 설정에 대한 학습 곡선이 있을 수 있습니다.
비용
IAP 사용에는 추가 비용이 발생할 수 있습니다. 특히, 많은 사용자가 접근하는 경우 비용이 증가할 수 있습니다.
비용 구조를 잘 이해하고 예산을 관리해야 합니다.
의존성
IAP는 Google Cloud에 종속적이므로, 다른 클라우드 제공자나 온프레미스 환경에서는 사용할 수 없습니다.
특정 클라우드 제공자에 종속되는 것을 원하지 않는 경우 단점이 될 수 있습니다.
네트워크 지연
IAP를 통해 접근할 때 네트워크 지연이 발생할 수 있습니다. 이는 특히 실시간 응답이 중요한 애플리케이션에 영향을 미칠 수 있습니다.
네트워크 성능을 주기적으로 모니터링하고 최적화해야 합니다.
이와 같은 장단점을 고려하여, 특정 상황에 맞는 접근 방식을 선택하는 것이 중요합니다.
<<실습 Start>>
방화벽 규칙 서비스에서, "allow-iap"라는 방화벽 추가가 필요하다.
- 대상 : 네트워크의 모든 인스턴스, 소스IPv범위 : 35.235.240.0/20, 포트 : 22번
IAM에서 사용자에게, Compute Instance 관리자,IAP 보안 터널 사용자 Role(조건 추가로, destination.port == 22 추가 필요) 추가하기
Private VM Compute Engine 생성하기
- 외부 IP 없음
<<실습 End>>
[8-6] 지금까지의 작업을 반영하여 아키텍처 수정하기
현재 까지의 작업 내용을 정리한 아키텍처는 아래와 같습니다. 😀
지금까지의 아키텍처 정리
1. 방화벽을 통해, Public VM에 접근하는 구조
2. IAP(터널링)을 통해, IAM 접근 권한만으로, Private VM에 접근하는 구조
3. Public용 서브넷에 Public Bastion Host VM을 만들어, Cloud Router를 통해 Private VM을 향한 Inbound 처리를 하고, Cloud Nat를 통해, Outbound 처리를 하도록 하는 구조
[8-7] 아키텍처 업데이트 (IAP 방화벽 내용 추가)
IAP가 방화벽 정책을 활용해서 모든 인스턴스에 Proxy 서버나 bastion-host 없이 바로 Private Compute Engine에 접근 가능한 이유는 아래의 설정 때문에 가능합니다.
IAP이 대한 방화벽 정책을 생성할때 대상을 네트워크의 모든 인스턴스로 지정을 했습니다.
그러므로 GCP 콘솔 화면에서 IAP의 방화벽 정책을 보면 아래와 같은 모습을 확인 할 수 있습니다.
아래의 인스턴스 항목을 보게되면 모든 인스턴스의 리스트가 보이는것을 확인 할 수 있습니다.
이말은 즉슨 모든 인스턴스에 동일하게 적용 된다는 의미입니다. 😀
그러므로, 해당 IAP와 IAP가 적용된 방화벽 정책은 모든 인스턴스에 적용 된다고 볼 수 있습니다.
만약 방화벽 정책에 IAP와 관련된 규칙이 없다면 아래와 같이 접근 에러가 발생합니다.
그러므로 반드시 IAP에 대한 방화벽 규칙이 있어야 하고, IAM의 권한 설정도 함께 진행 되어야 합니다.
구성에 참고 해주시면 될거 같습니다. 😆
추가로, 트래픽 흐름에 대한 설명은 아래와 같습니다.
GCP에서 IAP(Identity-Aware Proxy)를 통해 Private Compute Engine에 접근할 때, IAP는 터널링을 통해 인바운드 트래픽을 처리하고, 아웃바운드 트래픽은 Cloud NAT(Network Address Translation)를 통해 처리됩니다.
IAP를 통한 인바운드 트래픽 처리
IAP는 사용자가 특정 애플리케이션에 접근할 때 인증 및 권한 부여를 수행합니다.
사용자가 IAP를 통해 Private Compute Engine 인스턴스에 접근하면, IAP는 터널링을 통해 인바운드 트래픽을 해당 인스턴스로 전달합니다.
이를 통해 VPC 내부의 리소스에 대한 접근을 안전하게 제어할 수 있습니다.
Cloud NAT를 통한 아웃바운드 트래픽 처리
Private Compute Engine 인스턴스가 외부 인터넷으로 아웃바운드 트래픽을 전송할 때, Cloud NAT를 사용하여 트래픽을 처리합니다.
Cloud NAT는 VPC 내부의 프라이빗 IP 주소를 퍼블릭 IP 주소로 변환하여 외부 인터넷과의 통신을 가능하게 합니다.
이를 통해 인스턴스는 외부와의 통신이 가능하지만, 외부에서 직접 인스턴스로의 접근은 차단됩니다.
이와 같이, IAP는 인바운드 트래픽을 안전하게 처리하고, Cloud NAT는 아웃바운드 트래픽을 처리하여 GCP의 Private Compute Engine 인스턴스를 보호하고 관리합니다.
더불어 IAP의 방화벽 규칙이 추가된 아키텍처는 아래와 같습니다.
1. GCP에서 Private Compute Engine은 무엇을 의미하나요?
해설
Private Compute Engine은 퍼블릭 인터넷에 직접 노출되지 않고 내부 네트워크로만 접근 가능한 VM이에요. 보안 강화를 위해 사용된답니다.
외부 IP가 할당된 VM
내부 네트워크로만 접근 가능한 VM
데이터베이스 전용으로 사용되는 VM
온프레미스 환경에 설치된 VM
2. GCP에서 서브넷 내 특정 Compute Engine 인스턴스가 '프라이빗'으로 구분되는 주된 기준은 무엇인가요?
해설
GCP는 서브넷 자체에 퍼블릭/프라이빗 구분이 없어요. VM에 외부 IP가 없으면 프라이빗 리소스로 간주되며, 해당 서브넷이 프라이빗 서브넷처럼 사용돼요.
서브넷 이름에 'private'이 포함된 경우
NAT 게이트웨이가 구성된 경우
외부 IP 주소가 할당되지 않은 경우
특정 리전(Region)에 위치한 경우
3. 외부 IP가 없는 Private Compute Engine 인스턴스가 인터넷으로 나가는 통신을 할 수 있도록 돕는 서비스는 무엇일까요?
해설
Cloud NAT는 Private IP를 퍼블릭 IP로 변환해 Private VM이 외부 인터넷에 안전하게 접근할 수 있게 해주는 아웃바운드용 서비스예요.
Bastion Host
Cloud Router
Cloud NAT
VPN
4. IAP(Identity-Aware Proxy)는 어떻게 Private Compute Engine 인스턴스 접근을 허용하나요?
해설
IAP는 사용자의 ID를 확인 후 암호화된 터널을 생성하여 내부 리소스로 직접 접근하게 해주는 방식이에요. 별도의 네트워크 구성이나 Bastion Host가 필요 없죠.
임시 외부 IP 할당
사용자 ID 기반 보안 터널 생성
VPN 연결 필수 요구
Bastion Host 통한 트래픽 전달
5. IAP로 Private Compute Engine에 접근할 때, 해당 인스턴스가 외부 인터넷으로 나가는 아웃바운드 연결은 어떤 서비스가 처리하나요?
해설
IAP는 인바운드 접근을 처리하지만, Private VM이 외부 인터넷에 접속하는 아웃바운드 트래픽은 Cloud NAT를 통해 처리됩니다. 역할이 분리되어 있죠.
IAP
Bastion Host
Cloud NAT
Cloud Router
'클라우드 & DevOps > 클라우드 서비스 ∕ GCP' 카테고리의 다른 글
| [GCP] 핵심 서비스 정리 (0) | 2025.05.28 |
|---|---|
| [GCP] GenAI 서비스 학습 Log (1) | 2025.05.27 |
| [GCP] 기본 GCP 강의 Log 2부 (0) | 2025.05.26 |
| [GCP] AI Agent Sample 실행 Log (1) | 2025.05.22 |
| [GCP] 핵심 서비스 내용 정리 - IAM (0) | 2025.05.22 |
최근댓글