컨테이너화된 애플리케이션이 제공되는 클라우드 서비스 공급자(CSP)에서 현대적인 3계층 서버리스 애플리케이션을 생성하는 것은 많은 클라우드 엔지니어의 일반적인 작업입니다. 문제는 개발 노력을 가속화하고 비용과 복잡성을 줄이는 동시에 다양한 애플리케이션 계층에 대한 CSP의 광범위한 서비스를 효율적으로 활용할 수 있다는 것입니다. 이 문서에서는 배포 시간을 단축하는 동시에 비용과 복잡성을 줄이는 현대적인 3계층 서버리스 애플리케이션을 Google Cloud에 배포하기 위한 단계별 가이드와 이 구현에 사용되는 서비스에 대한 자세한 설명을 제공합니다.

프런트엔드(프레젠테이션 계층), 백엔드(애플리케이션 계층), Firestore 데이터베이스(데이터 계층)로 구성된 3계층 마이크로서비스 아키텍처를 사용하는 "Amazing Employees"라는 예제 애플리케이션을 사용하겠습니다. Angular를 사용하여 개발된 프런트엔드는 사용자와 상호 작용하고, Python Flask로 구축된 백엔드는 비즈니스 로직을 관리합니다. “Amazing Employees”는 단일 프런트엔드 및 백엔드 컨테이너로 구성됩니다. 그러나 마이크로서비스 아키텍처는 확장 가능합니다. 더 많은 컨테이너를 추가하면 더 많은 기능을 활용할 수 있습니다. 애플리케이션의 인프라는 Terraform을 통해 정의되며 Cloud Build는 애플리케이션의 빌드 및 배포를 관리합니다.

그림 1: Google Cloud 3계층 서버리스 아키텍처.

왜 서버리스인가?

서버리스 기술은 인프라 관리의 복잡한 작업 대부분을 CSP에 오프로드하여 개발자가 애플리케이션 코드 생성 및 배포에 집중할 수 있도록 합니다. 서버리스 제품은 다음을 포함하여 많은 이점을 제공합니다.

• 거의 무한한 자동 스케일링
• 고가용성
• 단순화된 인프라 관리
• 잠재적인 비용 절감(사용한 만큼만 비용 지불)
• 더 빠른 개발 주기

서버리스 기술은 마이크로서비스 아키텍처와 같이 확장성이 뛰어난 여러 아키텍처 유형을 지원하는 데 도움이 됩니다. 마이크로서비스는 애플리케이션을 독립적으로 배포할 수 있는 더 작은 단위로 나눕니다. 개별 마이크로서비스를 동적으로 확장하고 오류를 격리하는 기능을 통해 개발자는 응답성이 뛰어나고 비용 효율적인 솔루션을 만들 수 있습니다. 서버리스 기술은 마이크로서비스 애플리케이션을 생성하는 데 필요하지 않지만 관리 및 확장 측면을 크게 단순화하므로 리소스 활용도를 최적화하고 개발 노력을 간소화하려는 조직에 이상적인 선택입니다.

서버리스 애플리케이션의 또 다른 일반적인 아키텍처는 이벤트 중심 아키텍처입니다. 이 아키텍처에서는 애플리케이션이 사용자 작업, 데이터 변경, 외부 시스템 상호 작용 등 다양한 소스에 의해 트리거되는 이벤트에 동적으로 응답합니다. 이를 통해 개발자는 들어오는 이벤트에 따라 자동으로 확장되는 시스템을 설계하여 최대 부하 시 최적의 성능을 보장하고 조용한 기간 동안 비용 절감을 보장할 수 있습니다.

응용 서비스

'Amazing Employees' 애플리케이션의 프런트엔드와 백엔드를 위해 Google Cloud의 완전 관리형 서버리스 컨테이너 환경인 Cloud Run을 활용합니다. Cloud Run은 Google Cloud가 개척한 서버리스 컨테이너 기술인 Knative를 기반으로 합니다. Cloud Run은 인프라 계층을 추상화하고 기본 Kubernetes 클러스터를 관리할 필요가 없기 때문에 Google Kubernetes Engine(GKE)과 같은 다른 컨테이너 조정 서비스보다 사용하기 쉬운 경우가 많습니다. Cloud Run은 수신 트래픽을 기준으로 컨테이너를 자동으로 확장합니다. Google Cloud에서 서버리스 프런트엔드 또는 백엔드를 구축하는 데 널리 사용되는 또 다른 선택인 Cloud Functions의 최신 버전은 백그라운드에서 Cloud Run을 사용합니다.

물론 단순함을 통해 얻는 것은 통제력을 잃게 됩니다. 이는 클라우드의 모든 관리형 서비스에 해당됩니다. 사용 사례에서 컨테이너를 완전히 제어해야 하는 경우(세부적인 수준에서 네트워킹, 확장, 리소스 할당 구성 등) Cloud Run 대신 GKE를 사용해야 할 수도 있습니다. 가능하다면 Cloud Run과 같은 완전 관리형 서비스를 사용하는 것이 좋습니다. 간단히 말해 삶이 훨씬 편해지기 때문입니다.

API 게이트웨이는 프런트엔드와 백엔드 Cloud Run 인스턴스 간의 트래픽을 보호하는 데 사용됩니다. 일반적으로 API 게이트웨이를 사용하는 것은 복잡성을 줄이면서 보안, 성능 및 유연성을 향상시키기 때문에 마이크로서비스 아키텍처를 구축할 때 모범 사례입니다. Google Cloud의 API 게이트웨이에는 API, 게이트웨이, 구성이라는 세 가지 주요 구성요소가 있습니다. 구성은 OpenAPI 사양을 사용하며 infra 디렉터리에서 볼 수 있습니다. 두 가지 변수가 사용되므로 수동으로 변경하지 않고도 구성을 배포할 수 있습니다. 첫 번째 변수는 Variable.tf 에 제공되는 ${project\_id} 이고 , 두 번째 변수는 ${url} 입니다 . ${url} 변수 값은 백엔드 Cloud Run 인스턴스의 URL을 확인하고 이를 구성에 추가하는 Terraform 데이터 블록에서 제공됩니다. 두 경우 모두 변수 대체는 Terraform을 통해 수행되며 infra/api-gateway.tf 에서 볼 수 있습니다 .

애플리케이션 데이터베이스의 경우 서버리스 아키텍처에 원활하게 통합되는 Firestore가 자연스러운 선택이었습니다. Google Cloud Firebase 서비스의 NoSQL 데이터베이스인 Firestore는 주로 자동 확장, 강력한 쿼리 지원, 고급 보안 규칙 및 신뢰할 수 있는 애플리케이션 인증을 제공하는 기능 때문에 선택되었습니다. 우리 애플리케이션의 맥락에서 우리는 사용자 로그인에 Firebase 인증을 사용하고 직원 데이터 관리를 위해 기본 CRUD 데이터베이스 작업을 사용합니다.

인프라 및 배포

코드형 인프라의 경우 HashiCorp가 개발한 오픈 소스 도구인 Terraform을 사용합니다. Terraform을 사용하면 Google Cloud를 포함한 다양한 클라우드 제공업체 전반에 걸쳐 선언적 방식으로 인프라 리소스를 정의, 관리, 프로비저닝할 수 있습니다.

선택적으로 Cloud Storage를 사용하여 Terraform 상태를 저장할 수 있습니다. Cloud Storage는 파일, 미디어 등 구조화되지 않은 데이터를 저장할 수 있고 여러 스토리지 클래스에 걸쳐 방대한 양의 데이터를 관리할 수 있는 확장성을 제공하는 Google Cloud 내의 객체 스토리지 서비스입니다. Cloud Storage는 복제를 통해 데이터 내구성을 제공하고 짧은 지연 시간으로 접근성을 제공합니다. 액세스 제어 및 암호화와 같은 보안 기능; 버전 관리, 수명 주기 관리, 다른 Google Cloud 서비스와의 통합 등이 있습니다.

애플리케이션의 프런트엔드와 백엔드를 구축하기 위해 Google Cloud에서 빌드를 실행할 수 있는 Google Cloud의 서버리스 CI(지속적 통합) 및 CD(지속적 배포) 플랫폼인 Cloud Build를 사용합니다.

컨테이너 이미지를 저장하기 위해 우리는 Java, Node, Python용 패키지와 같은 소프트웨어 아티팩트에 대한 안전하고 확장 가능한 저장소를 제공하는 Google Cloud의 관리형 서비스인 Artifact Registry를 활용하지만, 이 경우에는 Docker 이미지를 저장하는 데 이를 사용하겠습니다.

다음은 Cloud Build 작업의 흐름을 보여주는 단계 및 개략적인 다이어그램에 대한 설명입니다.

1. 사용자가 Google Cloud 명령어를 사용하여 로컬 저장소에서 Cloud Build를 트리거합니다.
2. Docker 이미지는 현재 작업 디렉터리에서 빌드됩니다.
3. Docker 이미지가 Artifact Registry로 푸시됩니다.
4. Cloud Run 인스턴스는 Docker 이미지에서 배포됩니다.

그림 2: Cloud Build 실행 흐름.

비용에 대한 참고 사항

이 문서는 Google Cloud의 서버리스 제품을 살펴보고 싶어하는 클라우드 엔지니어를 위해 작성되었습니다. 따라서 비상업적 사용을 위한 일반적인 애플리케이션 배포에는 Google Cloud 무료 프로그램이 적용되어야 합니다. 자세히 알아보려면 Google Cloud 무료 등급 제품 페이지 (https://cloud.google.com/free) 를 방문하세요 . 다음은 이 튜토리얼에 사용할 서비스 및 관련 비용(2023년 9월 기준)입니다.

• Cloud Run 무료 등급은 월간 요청 200만 개, 메모리 360,000GB-초, 컴퓨팅 시간 180,000vCPU-초, 네트워크 송신 1GB(북미만 해당)를 제공합니다.
• Firestore 무료 등급은 프로젝트당 1GB의 스토리지와 프로젝트당 일일 읽기 50,000회, 쓰기 20,000회, 삭제 20,000회를 제공합니다.
• API 게이트웨이는 무료 계층 서비스에 포함되지 않지만 청구 계정당 매월 최대 200만 개의 API 호출을 무료로 제공합니다.
• Cloud Build 무료 등급은 하루 120분의 빌드 시간을 제공합니다.
• Artifact Registry 무료 등급은 매월 0.5GB의 저장용량을 제공합니다.

여기서는 서버리스 3계층 웹 애플리케이션에 대한 비용 추정의 한 가지 예를 예시 번호와 함께 살펴보겠습니다. 실제 비용은 사용량에 따라 달라집니다.

비용 추정을 위해 다음 가정을 사용합니다.

• Cloud Run은 서비스로 사용되며 실행 시에만 CPU가 할당됩니다.
• Cloud Run 인스턴스에는 vCPU 1개와 메모리 512MB가 있습니다.
• 월간 사용자는 10,000명입니다.
• 각 사용자는 매월 평균 400건의 요청을 받습니다.
• 각 요청을 완료하는 데 1,000밀리초가 걸립니다.
• 요청의 60%는 데이터베이스 읽기입니다.
• 요청의 40%는 데이터베이스 쓰기입니다.
• Firestore의 데이터 용량은 15GB 미만입니다.
• 모든 리소스는 동일한 지역에 배포됩니다.

API 게이트웨이:

월간 요청 200만~10억 건 = 3.00 USD

Firestore:

15GB 스토리지 = 월 $2.52

Document reads:

50,000

문서 100,000개당 $0.036

Document writes:

20,000

문서 100,000개당 $0.108

사용자 100명 * 월별 요청 40,000개 = 월별 요청 400만 개 ⇒ 월별 읽기 240만 개 및 쓰기 160만 개

읽기 비용: 읽기 240만 개 / 일일 요청 30 ➡ 80,000개 — 무료 요청 50,000개 = 일일 유료 요청 30,000개 = 읽기 요청의 경우 하루 $0.036 * 30 = 월 $1.08

쓰기 비용: 쓰기 160만 개 / 일일 요청 30 ➡ 54,000개 — 무료 요청 20,000개 = 일일 유료 요청 34,000개 = 쓰기 요청의 경우 일일 0.216 USD * 30 = 월 6.48 USD

Egress:

동일한 지역 내 = $0.00

Cloud Run:

CPU 할당 시간: 200,000 vCPU-초 = $0.48

메모리 할당 시간: 100,000GiB-초 = $0.00

요청 수: 4,000,000 = $0.80

Cloud Run 총액: $1.28 * 인스턴스 2개 = 월 $2.56

Monthly costs:

API 게이트웨이: $3.00

소방서: $10.08

송신: $0.00

클라우드 런: $2.56

총액 = 월 $15.64

단계별 가이드

Google Cloud 프로젝트 설정​

Google Cloud에서 리소스를 관리하고 구성하려면 프로젝트가 필요합니다. 이 튜토리얼에서는 새 프로젝트를 생성하는 것이 좋습니다. 이 가이드에서는 관리자(소유자) 액세스 권한이 있는 Google Cloud 프로젝트가 있고 nano 또는 vim과 같은 명령줄 편집기에 대한 지식이 있거나 Cloud Shell 편집기에 대한 액세스 권한이 있는 Google Cloud Shell에 액세스할 수 있다고 가정합니다. Cloud Shell 편집기는 Cloud Shell에 바로 내장된 텍스트 편집기이며 명령줄 편집기에 익숙하지 않은 경우 유용한 옵션입니다.

Google Cloud 콘솔에서 프로젝트에 액세스하려면 Google Cloud 콘솔 로 이동하여 로그인(또는 계정 생성)하고 프로젝트를 선택하세요. 아직 Google Cloud 프로젝트가 없다면 메뉴 > IAM 및 관리자 > 프로젝트 만들기 로 이동하여 콘솔의 메시지를 따릅니다.

초기 설정​

단순화를 위해 단일 저장소를 사용하여 모든 애플리케이션, 인프라 및 파이프라인 코드를 보관합니다. 초기 설정을 위해 프로젝트의 Google Cloud 콘솔에서 Cloud Shell 세션을 엽니다. Cloud Shell은 개발 및 운영 작업을 위한 인터넷 기반 플랫폼을 나타내며 웹 브라우저를 통해 편리하게 접근할 수 있습니다. Google Cloud는 이 서비스를 무료로 제공합니다. 이 플랫폼 내에서 다양한 도구를 갖춘 온라인 터미널을 사용하여 자산을 감독할 수 있습니다. 사전 설치된 도구에 대해 자세히 알아보려면 https://cloud.google.com/shell/docs/how-cloud-shell-works#tools 를 참조하세요 .

https://console.cloud.google.com/?cloudshell=true를 방문하여 새 Cloud Shell 세션을 열 수 있습니다 .

아직 업데이트하지 않은 경우 Google Cloud Shell 콘솔을 업데이트하여 프로젝트를 사용하세요.

gcloud config set project [YOUR GOOGLE CLOUD PROJECT]

gcloud config list

1단계: GitHub 저장소 복제

Cloud Shell 세션에서 참조 애플리케이션을 git clone합니다. 이 저장소를 복제하여 시작할 수 있습니다. 그러나 리포지토리를 포크하고 포크된 리포지토리를 복제하는 것이 좋습니다. 이 단계별 가이드의 일부로 Google 프로젝트에 3계층 서버리스 애플리케이션을 배포하기 위해 코드를 변경하는 방법에 대한 지침을 제공합니다.

git clone [original https://github.com/maksoodmohiuddin/google-cloud-serverless-app-pattern.git or forked repo] cd google-cloud-serverless-app-pattern

여기에서 '편집기 열기'를 선택하여 Cloud Shell 편집기를 시작할 수 있습니다.

2단계: Google 프로젝트 ID 및 지역 업데이트

다음으로, 사용 중인 Google Cloud 프로젝트와 이 애플리케이션을 배포하려는 대상 Google Cloud 지역(예: 'us-west2')으로 project_id 및 위치를 업데이트하겠습니다 . 우리의 예에서는 nano를 편집기로 보여줍니다. 그러나 원하는 다른 사용 가능한 편집기를 사용하도록 선택할 수 있습니다.

cd infra
nano variables.tf

variable "project_id" {
  description = "Project ID of the GCP project where resources will be deployed"
  type        = string
  default     = "PLEASE UPDATE WITH YOUR GOOGLE PROJECT ID"
}

variable "location" {
  description = "Location (region) where resources will be deployed"
  type        = string
  default     = "PLEASE UPDATE YOUR GOOGLE CLOUD REGION"
}

Cloud Build, Cloud Run, Firebase, API Gateway, Artifact Registry를 지원하는 지역을 선택하세요. 개인 계정의 경우 Cloud Build는 특정 지역으로 제한됩니다. 따라서 개인 계정을 사용하는 경우 아래 지역 중 하나를 사용하는 것이 좋습니다.

• 미국 서부 2
• 아시아-동부1
• 호주-남동부1

Google Cloud 지역 및 이 앱 서비스가 지원되는 지역에 대해 자세히 알아보려면 다음을 방문하세요.

• 일반 지역 선택기: https://cloud.withgoogle.com/region-picker/
• Firestore를 지원하는 지역: https://cloud.google.com/firestore/docs/locations
• Cloud Build를 지원하는 지역: https://cloud.google.com/build/docs/locations
• Cloud Run을 지원하는 지역: https://cloud.google.com/run/docs/locations
• Artifact Registry를 지원하는 지역: https://cloud.google.com/artifact-registry/docs/repositories/repo-locations
• API 게이트웨이를 지원하는 지역: https://cloud.google.com/api-gateway/docs/deployment-model

초기 인프라 배포​

이 섹션에서는 Terraform을 사용하여 초기 인프라를 배포합니다. Terraform에 알려지지 않은 종속성 매핑으로 인해 특정 리소스를 대상으로 하고 애플리케이션을 순차적으로 설정해야 합니다. 기본적으로 Terraform은 terraform.tfstate

라는 파일에 상태를 로컬로 저장합니다 . 이 튜토리얼에서는 로컬 상태를 사용할 수 있습니다. 그러나 원하는 경우 Google Cloud Storage를 사용하여 상태를 원격 상태로 저장할 수 있습니다. 개발자가 여러 명인 프로젝트에서는 원격 상태가 항상 선호됩니다. Terraform에 특히 능숙하다면 Terraform 로컬 상태로 버킷을 만든 다음 해당 상태를 버킷으로 마이그레이션하는 것이 더 쉬울 수 있습니다. 자세한 내용은 Google Cloud 문서를 참조하세요.

1단계: Terraform 초기화

terraform init

2단계: Terraform 계획 검증

terraform plan

Cloud Shell을 승인하라는 메시지가 표시되면 '수락'을 선택하여 계속하세요. 이는 Cloud Shell이 ​​Google Cloud 명령어에 사용자 인증 정보를 사용하려면 권한이 필요하고 '승인'을 클릭하면 이 호출과 향후 호출에 대한 권한이 부여되기 때문입니다.

출력은 다음과 같아야 합니다.

계획: 추가 18개, 변경 0개, 파괴 0개

3단계: 초기 리소스에 Terraform 적용

terraform apply

메시지가 표시되면 "yes"를 입력하여 리소스를 배포합니다. 계획과 일치해야 합니다.

백엔드, API 게이트웨이, 프런트엔드 배포​

1단계: Google 프로젝트를 사용하도록 백엔드 Python Flask 애플리케이션 코드 업데이트

백엔드 폴더로 이동하여 firestore.py 파일을 엽니다.

cd ../app/backend/ nano -l firestore.py

사용 중인 Google Cloud 프로젝트로 10행 클라이언트를 업데이트합니다.

client = firestore.Client(project="PLEASE_UPDATE_PROJECT_ID")

2단계: Cloud Build를 트리거하여 백엔드 배포

먼저 Cloud Build 파일을 검토하고 Google Cloud 명령줄을 사용하여 Cloud Build 파일을 기반으로 백엔드 Cloud Run을 배포할 수 있습니다.

cat backend-cloudbuild.yaml gcloud builds submit --region=[YOUR GOOGLE CLOUD REGION] --config backend-cloudbuild.yaml e.g. gcloud builds submit --region=us-west2 --config backend-cloudbuild.yaml

Cloud Build 실행을 완료하는 데 몇 분 정도 걸릴 수 있습니다. 이것은 예상됩니다. 이 Cloud Build 파일은 백엔드 서비스용 Docker 이미지를 빌드하여 Artifact Registry에 푸시한 후 Artifact Registry의 이미지를 Cloud Run 인스턴스에 배포합니다.

3단계: Swagger 사양 검토

OpenAPI Swagger 사양과 함께 API 게이트웨이를 사용하여 백엔드 Cloud Run을 API 게이트웨이에 연결하고 API 게이트웨이 구성을 설정합니다. infra 폴더 아래의 api-gateway--espv2-definition.yml.tmpl 파일을 검토합니다 .

먼저 cd를 사용하여 infra 디렉터리로 돌아가서 활성화 _api_gateway 플래그를 true로 활성화합니다.

cd ../../infra cat api-gateway--espv2-definition.yml.tmpl

다음을 방문하면 API Gateway 인증으로서 API Gateway, Swagger 및 Firebase용 OpenAPI 사양에 대해 자세히 알아볼 수 있습니다.

https://cloud.google.com/api-gateway/docs/openapi-overview

https://swagger.io

https://cloud.google.com/api-gateway/docs/authenticating-users-firebase

4단계: API 게이트웨이 배포

인프라 디렉터리에 있는 동안 활성화 _api_gateway 플래그를 true로 활성화합니다.

nano variables.tf

variable "enable_api_gateway" { description = "Feature flag to enable/disable API Gateway. Leverage this to deploy infra sequentially." type = bool default = true }

Terraform 계획을 실행한 후 적용합니다.

terraform plan

terraform apply

메시지가 표시되면 "yes"를 입력하여 리소스를 배포합니다. 세 가지 리소스를 배포해야 합니다. API 게이트웨이는 일반적으로 다른 리소스보다 배포하는 데 시간이 더 오래 걸립니다. 이것은 정상입니다.

5단계: Firebase 콘솔을 통해 Firestore 데이터베이스 구성

https://console.firebase.google.com/ 으로 이동하여 프로젝트 생성/추가 > 드롭다운에서 Google Cloud 프로젝트 선택 > 약관 동의 > 계속 > 계획 확인 > Google Analytics 활성화 여부 선택 > 계속을 선택합니다 .

Firebase 프로젝트의 방문 페이지에서 앱을 Firebase에 웹 앱으로 추가합니다.

또는 프로젝트 개요 에서 톱니바퀴 아이콘을 클릭하고 프로젝트 설정 으로 이동한 후 앱을 Firebase에 웹 앱으로 등록하세요.

선택한 이름으로 앱을 등록합니다(예: Google 프로젝트 이름을 사용할 수 있음).

앱이 등록되면 SDK 설정 및 구성 섹션(구성 섹션으로 전환 가능)에서 const firebaseConfig 값을 복사 하고 해당 값을 app/frontend/src/environments/environments.ts 에 붙여넣습니다 .

경고: Enviroment.ts 값 은 민감한 정보이므로 git 저장소에 체크인하지 마세요 .

cd ../app/frontend/src/environments/ nano -l environment.ts

export const environment = { firebase: { apiKey: "PLEASE UPDATE", authDomain: "PLEASE UPDATE", projectId: "PLEASE UPDATE", storageBucket: "PLEASE UPDATE", messagingSenderId: "PLEASE UPDATE", appId: "PLEASE UPDATE", measurementId: "PLEASE UPDATE" // if measurement is enabled }, production: false };

Firebase 콘솔에서 모든 제품 > 인증 > 시작하기 > Google > 활성화 > 지원 이메일 추가 > 저장 단계에 따라 Google을 Firebase용 인증 공급자로 활성화합니다.

6단계: 프런트엔드 API 게이트웨이 구성 설정

먼저 다음 명령을 실행하여 api-gateway 구성을 가져옵니다.

gcloud api-gateway gateways describe employee-gateway --location LOCATION --project PROJECT_ID --format 'value(defaultHostname)'

출력은 다음과 같습니다: Employee-gateway-#.#.gateway.dev

그런 다음 app/frontend/src/employee/services/firestore.service.ts 에서 세 개의 URL(13~15행)을 업데이트합니다 . 경로(예: 직원)를 그대로 유지합니다.

cd ../employee/services

nano -l firestore.service.ts

addEmployeeUrl = 'https://employee-gateway-#.#.gateway.dev/employee'; employeesUrl = 'https://employee-gateway-#.#.gateway.dev/employees'; deleteEmployeeUrl = 'https://employee-gateway-#.ue.gateway.dev/employee';

7단계: Cloud Build를 트리거하여 프런트엔드 배포

프런트엔드 폴더로 이동하여 Cloud Build 파일을 검토하고 Google Cloud CLI를 사용하여 백엔드 클라우드 인스턴스를 배포합니다.

cd ../../.. cat frontend-cloudbuild.yaml gcloud builds submit --region=[YOUR GOOGLE CLOUD REGION]] --config frontend-cloudbuild.yaml e.g. gcloud builds submit --region=us-west2 --config frontend-cloudbuild.yaml

8단계: 프런트엔드 Cloud Run URL로 Firebase 승인 도메인 업데이트

Firebase 앱에서 OAuth 작업을 수행하려면 프런트엔드 Cloud Run URL을 승인해야 합니다.

Google Cloud를 사용하여 Cloud Run URL을 가져올 수 있습니다.

gcloud run services describe SERVICE --region REGION --format 'value(status.url)'

e.g. gcloud run services describe amazing-employees-frontend-service --region us-west2 --format 'value(status.url)'

출력은 다음과 같아야 합니다. https://amazing-employees-frontend-service-###.a.run.app

해당 URL을 복사하고 Firebase 콘솔의 OAuth 리디렉션 도메인 목록에 추가하세요.

https://console.firebase.google.com/ 으로 이동하여 프로젝트를 선택합니다.

인증 > 설정 탭 > 승인된 도메인 > 도메인 추가를 클릭 하고 프런트엔드 Cloud Run URL을 붙여넣습니다.

마지막 단계: 엔드투엔드 앱 검증​

프런트엔드 Cloud Run URL(https://amazing-employees-frontend-service-###.a.run.app)로 이동하고 Google 계정을 사용하여 앱에 로그인합니다. Google Cloud 서버리스 애플리케이션 패턴은 다음을 사용합니다. Cloud Run, API 게이트웨이, Firebase가 실행 중입니다.

정리하다​

API 게이트웨이 구성 종속성으로 인해 여기서는 Terraform 삭제를 실행할 수 없습니다.

이 튜토리얼에서 사용한 리소스 비용이 GCP 계정에 청구되지 않도록 하려면 프로젝트를 삭제하면 됩니다.

프로젝트를 삭제하면 다음과 같은 결과가 발생합니다.

• 기존 프로젝트를 사용한 경우 해당 프로젝트에서 수행한 다른 작업도 모두 삭제됩니다.
• 삭제된 프로젝트의 프로젝트 ID는 재사용할 수 없습니다. 나중에 사용하려는 맞춤 프로젝트 ID를 만든 경우 대신 프로젝트 내의 리소스를 삭제하세요. 이렇게 하면 appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 계속 사용할 수 있습니다.

프로젝트를 삭제하려면 다음을 수행하세요.

• Cloud 콘솔에서 프로젝트 페이지(https://console.cloud.google.com/iam-admin/projects)로 이동합니다.
• 프로젝트 목록에서 삭제하려는 프로젝트를 선택하고 '삭제'를 클릭하세요.
• 대화 상자에서 프로젝트 ID를 입력하고 "종료"를 클릭하여 프로젝트를 삭제하세요.

요약

이 문서에서는 Google Cloud에 서버리스 3계층 애플리케이션을 배포하는 방법을 살펴보았습니다. 우리는 데이터베이스 요구사항에 Firestore를 활용하면서 Angular 컨테이너화된 프런트엔드와 Python Flask 컨테이너화된 백엔드 모두에 Cloud Run을 사용하는 방법을 살펴보았습니다. 효율적인 인프라 설정 및 배포를 위해 Terraform과 Cloud Build가 강조되었습니다. 실습을 원하는 분들을 위해 배포의 각 단계를 복제하고 이해할 수 있도록 자세한 단계별 가이드를 제공했습니다.

이러한 주요 구성요소와 기술을 이해함으로써 독자는 Google Cloud에서 서버리스 프로젝트를 처리할 수 있는 더 나은 준비를 갖추게 될 것입니다.

소프트웨어 아키텍처를 마스터하는 길은 끝이 없는 여정입니다. 

해당 주제에 관해 샅샅이 뒤지다 보면 방대한 양의 자료에 압도당하게 됩니다.

더욱이, 소프트웨어 아키텍처에 관한 콘텐츠의 대부분은 여러분과 같은 사람들이 자신만의 방식으로 이 여정을 이해하려고 노력하면서 게시한 것이기 때문에 여러분이 발견한 것 중 대부분은 품질이 다양합니다.

소프트웨어 아키텍처 주제에 관한 수많은 비디오, 블로그, 튜토리얼, 서적, 강좌 및 기타 유형의 콘텐츠가 있지만 모두 동일하게 만들어지는 것은 아닙니다. 일부는 훌륭하고 다른 일부는 어느 정도 장점이 있는 반면, 수많은 다른 리소스는 오해의 소지가 있고 완전히 잘못되었습니다.

그래서 제가 아래에서 한 일은 소프트웨어 아키텍처 주제에 대해 엄선된 고품질 리소스 목록을 모아 숙련된 소프트웨어 설계자뿐만 아니라 야심 찬 사람들도 쉽게 사용할 수 있도록 하는 것입니다. 이것이 소프트웨어 아키텍처 숙달을 향한 올바른 길을 설정하는 데 도움이 되기를 바랍니다.

무료 및 유료 리소스 모두 소프트웨어 아키텍처의 다양한 측면과 업계에서 소프트웨어 아키텍처의 역할에 대해 설명합니다.

이 컬렉션의 목표는 소프트웨어 엔지니어가 소프트웨어 아키텍트가 되거나 현재 소프트웨어 아키텍트가 자신의 역할을 더 잘 수행할 수 있도록 일종의 로드맵 역할을 하는 것입니다. 경험이 풍부한 소프트웨어 설계자라도 이러한 리소스를 사용하여 격차를 줄이고 명확성을 찾거나 사물에 대한 새로운 시각을 얻을 가능성이 높습니다.

제가 이 로드맵을 위에서 아래로 구성한 방식은 각 단계가 이전 단계를 기반으로 구축되도록 논리적 순서로 되어 있습니다. 물론 이것은 궁극적으로 관련 없는 리소스의 모음이므로 내가 정리한 순서가 의미가 있기를 바랍니다.

아래의 각 항목에 대해 무료인지 유료인지 식별하고 있습니다. 또한 해당 항목이 다루는 내용과 그것이 소프트웨어 아키텍트(또는 더 훌륭하고 성공하며 번창하는 소프트웨어 아키텍트)가 되는 여정에 정확히 얼마나 도움이 되는지에 대한 분석도 볼 수 있습니다.

더 이상 고민하지 마세요 — 소프트웨어 설계자 리소스 — 성공을 위한 로드맵! 🚀

👉 모든 개발자가 소프트웨어 아키텍처에 대해 알아야 할 5가지 • Simon Brown • GOTO 2020

이것이 유용한 이유: 소프트웨어 개발자가 소프트웨어 아키텍처에 대해 알아야 할 주요 항목에 대한 명확하고 간단한 설명입니다.

📺 유형 : 비디오

💰무료 : 예

👉 소프트웨어 아키텍처는 어떤 모습이어야 할까요?

이것이 유용한 이유: 적절한 소프트웨어 아키텍처의 기본 사항에 대한 더 많은 통찰력.

📺 유형 : 비디오

💰무료 : 예

👉 “Good Enough” 아키텍처 • Stefan Tilkov • GOTO 2019

이것이 유용한 이유: 소프트웨어 아키텍처가 목적을 달성하는 방법을 다룹니다. "완벽한 아키텍처"를 추구하면 그것을 무너뜨릴 수 있습니다.

📺 유형 : 비디오

💰무료 : 예

👉 최소 실행 가능 아키텍처 • Randy Shoup • YOW! 2022년

이것이 유용한 이유: 최소 실행 가능 아키텍처(또는 MVA)의 개념은 최소 실행 가능 제품(MVP)만큼 자주 논의되지 않습니다. 그러나 소프트웨어 설계자로서 우리가 하는 모든 일, 특히 비즈니스와 기술의 연계에 있어 이것이 얼마나 중요한지 이해하는 것이 중요합니다. 이 개념은 위의 “Good Enough Architecture” 개념과 관련이 있습니다.

📺 유형 : 비디오

💰무료 : 예

👉 소프트웨어 아키텍처 팁 더 빨리 알았으면 좋았을 텐데요

이것이 유용한 이유: 이전 개념을 바탕으로 소프트웨어 아키텍처 및 일반 응용 프로그램에 대한 몇 가지 빠른 팁을 제공합니다.

📺 유형 : 비디오

💰무료 : 예

👉 훌륭한 소프트웨어 설계자가 되는 방법 • Eberhard Wolff • GOTO 2019

이것이 유용한 이유: 이것은 오래된 비디오입니다. 그러나 여기서 말하는 개념은 "충분히 좋은 아키텍처"인 MVA의 개념과 일반적으로 소프트웨어 아키텍처 측면에서 소프트웨어 설계자가 집중해야 하는 개념과 밀접하게 연관되어 있습니다.

📺 유형 : 비디오

💰무료 : 예

👉 AWS re:Invent 2022 — 건축가 엘리베이터: 회의실과 IT 연결(ENT218)

이것이 유용한 이유: Gregor Hohpe의 저서 "The Software Architect Elevator"와 조직에서 소프트웨어 설계자의 주요 기능을 요약한 버전입니다.

📺 유형 : 비디오

💰무료 : 예

👉 소프트웨어 아키텍처의 기초(O'Reilly Press)

이것이 유용한 이유: 이는 소프트웨어 아키텍처가 무엇인지, 무엇에 중점을 두고 있는지에 대한 많은 중요한 부분을 식별하는 훌륭한 요약입니다. 이는 야심 찬 소프트웨어 설계자와 숙련된 소프트웨어 설계자 모두에게 지식과 이해의 많은 격차를 메울 것입니다.

📘 종류 : 도서

💰무료 : 아니요

소프트웨어 아키텍처에 대한 심층 분석 - 확대

👉 리액티브 선언문

이것이 유용한 이유 : Reactive 선언문은 Reactive 시스템을 구축하는 방법과 이유에 대해 설명합니다. 이는 소프트웨어 아키텍처 내의 틈새 시장이지만, 그 중 많은 부분이 확장 가능하고 탄력적이며 현대적인 아키텍처 구축의 기초이므로 해당 개념을 이해하는 것이 유용합니다.

🌐 유형 : 사이트

💰 무료 : 예

👉 소프트웨어 아키텍처 가이드(Martin Fowler 작성)

이것이 유용한 이유: Martin Fowler는 소프트웨어 개발 및 아키텍처 분야에서 소개가 필요 없는 또 다른 이름입니다. 그의 사이트에는 소프트웨어 아키텍처의 다양한 측면과 설계자의 역할에 대한 확실한 이해를 구축할 수 있을 만큼 자세하고 전체적인 풍부한 정보가 있습니다.

🌐 유형: 사이트

💰 무료: 예

👉 소프트웨어 아키텍처: 어려운 부분

이것이 유용한 이유: 업계 최고의 전문가가 쓴 또 다른 훌륭한 책입니다. 앞서 언급한 "소프트웨어 아키텍처의 기초"와 마찬가지로 소프트웨어 아키텍처의 기초와 고급 개념에 대해 설명합니다. 그러나 여기서 초점은 소프트웨어 설계자가 매일 처리하는 과제, 즉 어려운 부분에 있습니다.

📘 유형: 책

💰 무료: 아니요

👉 마크 리차드의 채널

이것이 유용한 이유: Mark는 소프트웨어 아키텍처 세계에서 잘 알려진 인물입니다. O'Reilly의 인기 작가이자 독립 컨설턴트이자 해당 주제에 대한 놀라운 비디오 모음집을 발행한 사람입니다. 그의 방대한 비디오는 소프트웨어 아키텍처 분야의 다양한 주제를 다루고 있습니다. Mark의 채널은 풍부한 정보를 제공합니다.

📺 유형 : 유튜브 채널

💰무료 : 예

전문성 구축 - 더욱 확대

👉 실제 소프트웨어 아키텍처, 4판

이 책이 유용한 이유: 이 책은 이미 언급된 다른 책들과 일부 겹치는 부분이 있습니다. 그러나 이는 다소 다른 관점을 제공하며 이를 통해 소프트웨어 엔지니어링과 아키텍처 간의 격차를 더 많이 해소합니다.

📘 종류 : 도서

💰무료 : 아니요

👉 데이터 집약적인 애플리케이션 설계

이 책이 유용한 이유: 이 책은 고전입니다. 데이터 처리에 중점을 두고 대규모 시스템을 구축하는 데 중점을 둡니다. 대부분의 최신 엔터프라이즈 시스템은 대규모 데이터 처리 및 관리에 의존합니다. 이 책은 그러한 시스템을 구축하는 데 필요한 과제, 방법 및 전략을 설명합니다.

📘 종류 : 도서

💰무료 : 아니요

👉 혁신적인 아키텍처 구축, 2판

이것이 유용한 이유: 소프트웨어 아키텍처는 대체로 시간이 지남에 따라 발전할 수 있는 시스템을 구축하는 것입니다. 완벽한 아키텍처는 존재하지 않으며, 이를 추구하면 실제 문제를 해결하고 비즈니스에 서비스를 제공하며 가치를 제공하는 시스템을 구축하는 능력을 잃게 됩니다. 이 책은 업계에서 가장 잘 알려진 사람들의 전체적인 개요입니다. 시간이 지남에 따라 진화하고 시간의 시험을 견디는 건축물 구축이라는 주제를 훌륭하게 마무리합니다.

📘 종류 : 도서

💰무료 : 아니요

👉 마이크로서비스.io

이것이 유용한 이유: Microservices.io는 소프트웨어 아키텍처 회로의 또 다른 잘 알려진 인물인 Chris Richardson의 프로젝트입니다. Chris는 마이크로서비스 아키텍처, 소프트웨어 제공 및 아키텍처 패턴에 관해 글을 쓰고 강연합니다. 그의 작업은 아키텍처 스타일로서의 마이크로서비스에 초점을 맞추고 있지만 그가 말하는 패턴과 방법론은 다양한 방식으로 보편적으로 적용 가능합니다. 안정적이고 확장 가능하며 현대적인 시스템을 구축하려면 이러한 개념을 숙지하고 이해하는 것이 중요합니다.

🌐 유형 : 사이트

💰무료 : 예

클라우드 공급업체 Well-Architected 아키텍처 프레임워크​

이것이 유용한 이유: 세 가지 주요 클라우드 공급업체는 각각 아키텍처 및 시스템 설계 모범 사례에 대한 강력한 지침 및 표준 세트를 보유하고 있습니다. 이들은 "잘 설계된" 프레임워크로 훌륭하게 패키지되어 있습니다. 각 공급업체에는 개념을 설명하는 고유한 접근 방식과 방법이 있습니다. 그러나 이들 모두의 기본에는 거의 동일한 여러 기둥이 있습니다.

이 세 공급업체는 분명히 자사의 클라우드 서비스를 강조하지만 그들이 말하는 개념은 보편적으로 적용 가능합니다. 세 가지 프레임워크는 모두 중요하며 완료하는 데 시간이 걸립니다. 다음은 이러한 문제를 해결하는 방법에 대한 몇 가지 팁입니다. 그럼에도 불구하고 해당 프레임워크 중 하나를 검토하고 이해한다는 것은 다른 프레임워크의 90%도 이해했다는 의미입니다. 세 가지를 모두 살펴보고 더 직관적으로 느껴지는 것을 선택하는 것이 좋습니다. 그렇지 않다면 가장 직관적이고 따라하기 쉬운 GCP부터 시작하겠습니다.

🌐 유형: 사이트

💰무료 : 예

👉 Google Cloud 아키텍처 프레임워크

GCP 아키텍처 프레임워크는 사용자 친화적이고 탐색하기 쉽습니다. 목차를 살펴보는 것은 잘 정리된 안내서를 살펴보는 것과 같습니다. 그들이 아키텍처 원칙을 논의하는 방식은 대부분 불가지론적이고 실제 GCP 서비스와 독립적입니다.

👉 AWS Well-Architected 프레임워크

Amazon Web Services에는 클라우드에서 애플리케이션을 설계하고 설계하는 것과 유사한 가이드도 있습니다. GCP에서 제공하는 것과 유사하며 상호 참조하고 공백을 메우는 데 사용할 수 있습니다.

👉 Azure Well Architected 프레임워크

Azure Well-Architected 프레임워크는 탐색하기 다소 덜 직관적일 수 있지만 최신 클라우드 기반, 확장 가능하고 탄력적인 애플리케이션을 설계하는 데 대한 풍부한 정보도 포함합니다. 또한 업계 모범 사례에 중점을 두고 특정 Azure 기술을 학습할 수 있는 무료 과정과 "경로"를 제공합니다.

10,000피트 뷰 - 축소

👉 소프트웨어 아키텍트 엘리베이터

이것이 유용한 이유: Software Architect Elevator는 훌륭한 읽기 자료이자 모든 소프트웨어 설계자에게 꼭 필요한 책입니다. 이 책에서 Gregor Hohpe는 소프트웨어 설계자가 업계에 제공하는 가장 중요한 가치, 이와 관련된 장점, 함정 및 미묘한 차이에 대해 이야기합니다. 이 책은 소프트웨어 아키텍트 역할에 대한 이해를 돕기 위한 좋은 책입니다.

📘 유형: 책

💰무료 : 아니요

👉 기술 레이더 — 오늘날의 기술 환경에 대한 독보적인 가이드

이것이 유용한 이유: Thoughtworks는 소프트웨어 아키텍처 및 일반적인 기술 상태에 대한 가장 중요한 콘텐츠 중 일부를 생산하므로 따라갈 가치가 있는 회사입니다. Technology Radar는 업계 전반의 추세, 문제 및 기술 예측에 대해 설명하는 종합 가이드로 매년 발표됩니다.

🌐 유형: 사이트 및 디지털 가이드

💰무료 : 예

지속적인 학습과 소프트웨어 설계자로서의 레벨업을 위한 리소스

👉 https://www.deararchitects.xyz/

“Dear Architects” 뉴스레터는 소프트웨어 아키텍처 분야에서 주목할 만한 또 다른 유명인 Luca Mezarilla의 프로젝트입니다. 이 뉴스레터는 소프트웨어 아키텍처 세계의 모든 분야에서 훌륭한 통찰력, 사용 사례 및 정보를 제공합니다.

👉 https://dzone.com/

소프트웨어 엔지니어링, 아키텍처 및 기술에 대한 인기 있는 리소스입니다. 여기에서 추세 보고서, 참조 카드 및 풍부한 정보를 찾을 수 있습니다.

👉 https://www.infoq.com/

위의 Dzone과 마찬가지로 이는 소프트웨어 아키텍처, 엔지니어링 및 기술 콘텐츠 측면에서 업계의 거대 기업입니다.

👉 https://www.gartner.com/en/insights

Gartner의 통찰력 및 동향 보고서와 기사는 사실상의 표준이며 대부분의 CTO 및 기술 리더 읽기 목록의 필수 항목입니다. Gartner는 대규모 설문 조사를 진행하고 사고 리더십, 기술 상태 및 업계 동향에 대한 깊은 통찰력을 제공하는 기관입니다. Gartner 보고서를 따르는 이유는 반드시 심층적인 기술 지식을 갖추기 위한 것이 아니라 산업 기술 환경 전반에 대한 지식과 인식을 구축하기 위한 것입니다.

👉 GOTO 컨퍼런스

GOTO 컨퍼런스는 소프트웨어 엔지니어링 및 아키텍처 분야에서 최고의 컨퍼런스 중 하나입니다. 채널을 팔로우하고 최신 콘텐츠를 유지하는 것은 가치 있는 일입니다.

Angular 애플리케이션을 배포하기 위해 GCP 저장소 버킷을 빠르게 만드는 방법을 보여 드리겠습니다.

내 Angular 프로젝트를 저장하기 위해 스토리지 버킷을 생성해야 합니다.

그런 다음 Application Load Balancer는 트래픽을 URL 또는 IP에서 스토리지 버킷의 콘텐츠로 리디렉션합니다.

세부 사항을 살펴 보겠습니다.

프런트엔드 준비​

우선 Storage Bucket에 업로드할 파일을 준비해야 합니다.

해당 파일은 프로젝트 파일이 아니지만 프로젝트의 컴파일된 버전을 얻으려면 Angular 프로젝트를 빌드해야 합니다.

컴파일을 통해 전체 프로젝트가 포함된 5~7개의 파일 세트가 생성됩니다.

이는 프로젝트의 모든 JavaScript, HTML 및 CSS 콘텐츠를 단일 파일로 압축한 것입니다.

해당 파일을 얻으려면 package.json 파일을 살펴보거나 다음 명령을 실행하면 됩니다.

결과 파일은 dist 폴더 에 있습니다 . 그 안에는 프로젝트 이름이 적힌 또 다른 폴더가 표시됩니다. 그리고 이 폴더 안에는 생성된 모든 파일이 있습니다.

GCP 저장소 버킷 구성​

이제 컴파일된 파일을 업로드하기 위해 스토리지 버킷을 생성하고 구성해야 합니다. 로드 밸런서를 통해 URL을 통해 액세스할 수 있도록 이 버킷을 구성해야 합니다.

모든 정보는 이 링크 에서 찾을 수 있습니다 .

먼저 모든 콘텐츠를 저장할 버킷을 만들어 보겠습니다. 기본 옵션과 프라이빗 버킷을 선택합니다.

GCP 저장소 버킷 만들기

Angular 프로젝트의 파일을 저장할 버킷이 있으면 이제 URL 요청을 index.html 파일로 리디렉션하는 로드 밸런서를 생성할 차례입니다.

네트워크 설정으로 이동하여 Application Load Balancer인 Load Balancer를 생성합니다.

Application Load Balancer 생성

Application Load Balancer를 구성할 때 프런트엔드와 백엔드를 설정해야 합니다.

프런트엔드의 경우 기본값을 그대로 둡니다. 프런트엔드 구성은 Load Balancer, 포트, 프로토콜 등에 액세스하는 방법을 정의합니다.

그리고 백엔드의 경우 Load Balancer 뒤에 무엇이 있는지 정의합니다. 로드 밸런서 뒤에 스토리지 버킷을 두고 싶습니다. 이제 백엔드 로드 밸런서를 버킷으로 구성해 보겠습니다.

Application Load Balancer 백엔드 버킷 구성

마지막으로 프런트엔드 및 백엔드 구성을 표시하는 요약 창이 있습니다. 생성 버튼을 클릭하면 로드 밸런서가 생성됩니다.

로드 밸런서 요약

Load Balancer가 생성되면 요청할 IP를 얻기 위한 세부 정보를 확인할 수 있습니다.

로드 밸런서 세부정보 보기

나중에 IP를 복사합니다.

콘텐츠 업로드​

GCP의 모든 아키텍처가 생성되었습니다. 이제 Angular 프로젝트를 내 스토리지 버킷에 업로드할 차례입니다.

내 프로젝트를 업로드하려면 터미널에서 다음 GCP 명령을 실행해야 합니다.

이렇게 하면 dist/frontend 폴더 의 콘텐츠 (내 프로젝트 이름이 frontend 인 경우)가 my-bucket 이라는 스토리지 버킷에 업로드됩니다 .

귀하의 콘텐츠에 접근하세요​

이제 브라우저에서 로드 밸런서의 IP 주소에 액세스할 수 있습니다. 그러면 브라우저에 내 스토리지 버킷의 콘텐츠가 표시됩니다.

더 나아가서 HTTPS 프로토콜을 사용하여 Angular 프로젝트로 이동하도록 로드 밸런서에서 SSL 인증서를 구성할 수 있습니다.

또한 접근성이 높고 빠른 액세스가 가능하도록 CDN(Content Delivery Network)을 구성하여 전 세계 여러 지역에 프런트엔드 파일을 분산시킬 수 있습니다.

마지막으로 IP 주소 대신 DNS 레코드를 생성하여 로드 밸런서에 도메인 이름을 연결할 수 있습니다. 이렇게 하면 IP 주소 대신 맞춤 URL을 갖게 됩니다.

서비스를 운영하다 보면 사이버 보안에 민감해지고 필요성을 느끼게 된다.

이전 서비스에서 사이버 보안을 위해 구글 클라우드에서 제공하는 Cloud Armor를 활용했었고 좋은 경험이었다.

끊임없는 사이버 위협의 시대에 디지털 인프라를 보호하는 것이 그 어느 때보다 중요해졌고 Google Cloud Armor는 끊임없이 진화하는 사이버 공격 환경을 방어할 수 있는데 유용했다.

DDoS 공격부터 정교한 웹 애플리케이션 취약점까지 사이버 위협은 많은 기업들에 상당한 위험을 초래하고 있고 공격들은 점점 더 정교한 기술을 사용하면서 포괄적이고 적응 가능한 보안 조치의 필요성이 중요해졌다.

사이버 공격의 유형

사이버 공격의 가장 일반적인 유형은 아래와 같다.

- 악성 코드: 데이터를 훔치거나 시스템을 손상시키거나 인질로 잡는 데 사용할 수 있는 악성 소프트웨어.

- 피싱(Phishing): 이메일, 문자 메시지 또는 웹사이트를 사용하여 사용자를 속여 개인 정보를 공개하거나 악의적인 링크를 클릭하도록 하는 일종의 사회 공학 공격.

- 랜섬웨어(Ransomware): 피해자의 파일을 암호화하고 이를 해독하기 위해 몸값을 요구하는 악성 코드 유형.

- DDoS 공격: 이러한 공격에는 대상 서버를 사용할 수 없도록 하기 위해 트래픽을 너무 많이 보내는 공격.

- SQL INJECTION(SQLi): SQL 데이터베이스의 취약점을 악용하여 데이터를 훔치거나 악성 코드를 실행하는 공격.

Google Cloud Armor의 WAF(웹 애플리케이션 방화벽)는 애플리케이션 계층 공격을 차단하고 SQL INJECTION, XSS(교차 사이트 스크립팅) 및 기타 일반적인 취약점으로 인한 위험을 완화한다.

또한 광범위한 사이버 공격으로부터 조직을 보호하는 데 도움이 된다.

아래 기능들을 보면 이렇습니다.

• Web application firewall (WAF): WAF는 악성 트래픽을 차단하고 웹 애플리케이션에 대한 보안 정책을 시행합니다.
• Intrusion detection and prevention system (IDS/IPS): IDS/IPS는 악성 네트워크 트래픽을 탐지하고 차단합니다.
• DDoS protection: 대규모 공격도 완화하는 데 도움이 되는 강력한 DDoS 보호 기능을 제공합니다.
• Security insights: 조직의 보안 상태에 대한 통찰력을 제공하여 잠재적인 취약점을 식별하고 해결하는 데 도움이 됩니다.

Cloud Armor 사용방법

Cloud Armor를 사용한 계기가 클라우드에 대한 경험이 적어 익숙치 않던 시절에 활용하게 됐었는데 몇 분 안에 배포할 수 있을 정도로 아주 간단하고 쉽게 사용할 수 있기 때문이었다.

우선 보안 정책을 만들고, 생성한 보안 정책을 보안을 적용하고 싶은 서버나 로드밸런서에 연결하면 끝!

보안 정책에서 아래와 같이 들어오는 요청에 대해 정책을 만들고 우선순위도 정할 수 있다.

보안 정책을 사용하면 애플리케이션이 Google Cloud, 하이브리드 배포 또는 다중 배포 환경에 배포되는지 관계없이 DDoS 및 기타 웹 기반 공격으로부터 서비스를 보호할 수 있다. Google Cloud Armor에는 다양한 사용 사례를 포괄하는 사전 구성된 보안 정책도 포함되어 있으니 자세한 내용은 링크를 참조하세요! Google Cloud Armor security policy overview.

PreConfigured WAF Rules

사전 구성된 웹 애플리케이션 방화벽(WAF) 규칙을 제공하는데, 이러한 규칙은 이미 만들어져 있고 업계 표준에서 가져온 수십 개의 공격 탐지 서명을 포함한다. 각 서명은 규칙 세트 내의 특정 공격 탐지 규칙에 해당한다. 이러한 사전 구성된 규칙을 사용하면 각 서명을 개별적으로 정의하는 수고가 줄어 다양한 트래픽 패턴을 간단히 평가할 수 있다.

Google Cloud Armor Managed Protection

Managed Protection은 DDoS 공격 및 기타 인터넷 위협으로부터 웹 애플리케이션과 서비스를 보호하는 데 도움이 되는 관리형 애플리케이션 보호 서비스이다. 로드 밸런서에 대한 상시 보호 기능을 제공하며 WAF 규칙에 대한 액세스를 제공다.

Threat Intelligence

Threat Intelligence를 사용하면 여러 카테고리의 위협 인텔리전스 데이터를 기반으로 전역 외부 Application Load Balancer 및 기본 Application Load Balancer 에 대한 트래픽을 허용하거나 차단하여 트래픽을 보호할 수 있다.

Cloud Armor 추가 팁

• 보안 정책을 최신 상태로 유지하는 것이 좋다. 새로운 위협이 등장하면 보안 정책을 최신 상태로 유지하는 것이 중요하기 때문에 Cloud Armor는 서명 데이터베이스를 정기적으로 업데이트해 최신 위협으로부터 사용자를 보호한다.
• 보안 로그 모니터링: Cloud Armor는 잠재적인 공격을 식별하고 조사하는 데 도움이 되는 보안 로그를 제공한다.

이러한 단계를 수행하면 보안이 강화되고 공격의 성공을 어렵게 만들 수 있다.

결론!

사이버 공격은 심각한 위협이지만 올바른 조치를 취하면 이러한 공격으로부터 보호할 수 있다. Cloud Armor는 광범위한 위협으로부터 웹 애플리케이션과 웹 서버를 보호하는 데 도움이 되는 강력한 도구로서 활용할 수 있고 초보자들도 사용할 수 있을만큼 쉽다.

갑자기 회사에서 워드프레스를 우리 클라우드에서 호스팅하고 이를 마켓팅팀에서 이용하고 싶다 하여 급 워드프레스 구성을 시작하게 됐습니다.
그래서 GCP(구글 클라우드 플랫폼)에 워드프레스를 설치하고 운영하는 방법에 대해 확인해 봤습니다.

GCP에 워드프레스 설치하기​

우선 GCP 가입을 합니다.
그런 뒤 상단 검색창에 wordpress를 검색한 뒤 MARKETPLACE 및 API 분류에서 WordPress 를 클릭해 배포를 클릭합니다!

이미 배포를 진행했기 때문에 배포보기로 보이지만 원래는 배포 버튼이 보입니다. 그리고 배포 이후에는 배포보기를 눌러 이미 배포한 내용도 확인할 수 있습니다.
배포를 누르면 여러가지 옵션들이 있는데 원한다면 instance의 위치와 컴퓨터 사양도 조정할 수 있습니다. 나머지는 조정하지 않아도 됩니다.
배포 보기를 누르면 배포된 목록들이 보이는데 처음 배포했으면 1개가 있을 겁니다.
그걸 클릭하면 Deployment Manager가 나옵니다.

처음 배포를 하면 Site Address, Admin URL에 자동으로 ip 가 할당됩니다.
예를 들어 32.34.108.231 ip가 할당됐다고 하면, Site Address: https://32.34.108.231, Admin URL: https://32.34.108.231/wp-admin 이렇게 싸이트와 싸이트 어드민 주소가 생깁니다.
나중에 설명할 Admin 로그인을 위해 WordPress Admin user, WordPress Admin password를 저장해둡니다.

여기서 wordpress 배포 시 phpadmin enable을 해두었다면 이를 활용해 wordpress 데이터베이스에 wordpress mysql user, password를 이용하면 잘못된 셋팅을 한 경우 wp-admin 페이지에 접속하지 못하게 될 때 데이터베이스로 접속해 셋팅 내용을 변경할 수도 있으니 enable 해 두는 것이 좋습니다.

위에서 말했던 것처럼 https://32.34.108.231 로 바로 접속이 가능하지만 https 설정을 위한 ssl 인증서 설정이 되어 있지 않고 도메인도 설정되어 있지 않습니다. 그래서 싸이트에 접속하면 안전하지 않은 페이지로 이동하겠다는 클릭을 하며 접속해야 하는 불편함이 있습니다. 그래서 인증서와 도메인 설정이 필요합니다.

SSL 인증서 및 도메인 설정하기​

GCP의 WordPress 페이지에서 SSH 버튼을 클릭하면 VM으로 간단히 접속할 수 있습니다.
접속 후 무료 ssl 인증서 설정을 위해 certbot 홈페이지로 이동합니다.

어떤 웹싸이트를 운영중인지에 따라 instruction이 달라지니 이를 체크하기 위해 아래 명령을 입력해 확인합니다.

cat /etc/*release

위의 명령을 입력하면 아래와 같이 서버의 정보를 볼 수 있습니다.

그런 뒤 소프트웨어를 선택해 주는데 저는 Apache를 선택했습니다.

근데 여기서 문제가 발생하는데 시스템에 debian 11 이 없습니다.

그래서 당황했습니다. 물론 운영중인 서버에 따라 지시사항이 달라지지만 이런 경우 방법을 알 수 없어 debian 11일 때 설치 방법에 대해 찾아본 뒤 적용했습니다.

아래와 같이 터미널에서 명령어를 입력합니다.

# 우선 업데이트를 진행해 주고
$ sudo apt update
# snapd를 설치합니다.
$ sudo apt install snapd
# snap을 이용해 core를 설치해 주고
$ sudo snap install core
# snap 동작을 간단히 확인하기 위해 hello-world를 설치합니다.
$ sudo snap install hello-world
# Hellow World!가 출력되면 정상 설치된 것을 확인할 수 있습니다.
$ hello-world
# snapd가 최종버전으로 업데이트 되었는지 다시 체크하고
$ sudo snap install core; sudo snap refresh core
# snapd를 이용해 certbot을 설치합니다.
$ sudo snap install --classic certbot
# certbot 명령을 user 명령어에 링크해 주고
$ sudo ln -s /snap/bin/certbot /usr/bin/certbot
# 이제 certbot을 설정해 줍니다!
# 명령어를 입력하면 이메일을 중간에 입력하라 나오고 입력해 준 뒤 이용약관 동의 내용도 나오면 Y 해줍니다.
# ssl 인증서와 연결할 도메인 주소를 입력해 줍니다.(example.com www.example.com 이런 식) 
# 이렇게 이메일을 입력하면 그 다음으로 아래와 같이 나오는데
# Deploying certificate
#
# We were unable to find a vhost with a ServerName or Address of grablo.co.
# Which virtual host would you like to choose?
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# 1: 000-default.conf               |                       |       | Enabled
# 2: wordpress-https.conf           |                       | HTTPS | Enabled
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# 위에서 HTTPS 인증서만 등록하므로 각각의 도메인마다 HTTPS 2번을 선택해 등록하면 됩니다.
$ sudo certbot --apache
# 인증서 갱신이 가능한지를 테스트 해 갱신이 가능한지 확인합니다.
$ sudo certbot renew --dry-run
# 이 후 인증서 갱신 기한이 되면 아래 명령어를 입력해 진짜 인증서 갱신을 실행하면 됩니다.
$ sudo certbot renew
# 인증서 갱신을 잘 마쳤는지 인증서를 확인하려면 아래 명령어를 입력합니다.
$ sudo certbot certificates

이제 certbot을 이용한 ssl 인증서 발급 및 도메인 맵핑 설정이 완료됐으니 진짜 도메인 설정을 위해 터미널을 끄고 검색창에 CloudDNS를 검색합니다.
우선 example.com으로 도메인을 발급 받았다고 가정합니다.
dns 이름이 example.com 도메인 유형 A인 레코드 세트를 추가하고 여기에 32.34.108.231 (서버ip)주소를 입력해 줍니다. 그럼 32.34.108.231 이 ip 주소와 ssl 인증서가 연결되고 또한 도메인도 맵핑된 상태가 됩니다.
그럼 이제 example.com에 접속하면 왼쪽 상단 url 창에 있는 자물쇠 표시를 클릭해 인증서가 정상적인지 체크할 수 있고 안전하지 않음 옵션 없이 바로 인증된 싸이트에 도메인으로 접속할 수 있는 상태가 됩니다!!

이제부터는 나만의 워드프레스 싸이트가 생겼으니 example.com/wp-admin 에 접속해 싸이트 운영을 시작하시면 됩니다 🚀

At the core of infrastructure as code (IaC) lies the concept of automating infrastructure management through code. Terraform, an open-source IaC tool, has gained immense popularity over the years due to its versatile capabilities, large provider ecosystem, and robust community support. But with the growing need for more efficient and flexible IaC tools, a new player has emerged in the field: Multy.

In this article, I will introduce Multy, discuss its features and advantages, and provide a comprehensive comparison with Terraform to help you decide which tool is best suited for your infrastructure management needs.

What is Multy and Why was it Created?​

Multy is an open-source IaC tool that was created to provide a more flexible and efficient way of managing cloud infrastructure. It was designed to address some of the limitations of other popular IaC tools, such as Terraform. One of the main features of Multy is its ability to handle multiple cloud providers, such as AWS, Azure, and GCP, simultaneously. This means that users can manage cloud infrastructure across multiple providers using a single tool, which is a significant advantage over other tools that are limited to a single cloud provider.

Features of Multy​

Multy has several unique features that make it a powerful IaC tool. Here are some of its key features:

1. Multi-Cloud Support - Multy can handle infrastructure across multiple cloud providers, which is a significant advantage over other tools that are limited to a single cloud provider.
2. Plugin System - Multy has a plugin system that allows users to extend its functionality and customize it to meet their specific needs.
3. Modular Design - Multy has a modular design, which makes it easy to manage infrastructure across multiple environments.
4. Powerful Syntax - Multy's syntax is powerful and easy to use, which makes it easy to write and manage complex infrastructure code.
5. Terraform Compatibility - Multy is compatible with Terraform, which means that users can use existing Terraform modules with Multy.
6. Native Kubernetes Support - Multy has native support for Kubernetes, making it easier for users to manage their Kubernetes clusters and associated resources.
7. Secure Remote State Management - Multy provides secure remote state management out of the box, ensuring that your infrastructure code is always up to date and secure.

Pros and Cons of Multy Compared to Terraform​

Multy and Terraform are both powerful IaC tools, and each has its advantages and disadvantages. Here are some of the pros and cons of Multy compared to Terraform:

Pros of Multy​

1. Multi-Cloud Support - Multy can handle infrastructure across multiple cloud providers, which is a significant advantage over Terraform.
2. Plugin System - Multy has a plugin system that allows users to extend its functionality and customize it to meet their specific needs.
3. Modular Design - Multy has a modular design, which makes it easy to manage infrastructure across multiple environments.
4. Powerful Syntax - Multy's syntax is powerful and easy to use, which makes it easy to write and manage complex infrastructure code.

Cons of Multy​

1. Limited Community Support - Multy is a relatively new tool, which means that it has a smaller community than Terraform, which can make it harder to find resources and support.
2. Learning Curve - Multy's syntax and features can be challenging to learn, especially for beginners.
3. Terraform Compatibility - While Multy is compatible with Terraform, there may be some differences in syntax and functionality between the two tools.

How to Use Multy​

Using Multy is straightforward. Here's a step-by-step guide to get started with Multy:

1. Install Multy: The first step is to install Multy on your local machine or server. You can find detailed instructions on how to install Multy in the official documentation.
2. Create Your Multy Project: Once you have installed Multy, you can create your Multy project. A Multy project is a set of infrastructure resources that you want to manage using Multy. You can create a new project by running the following command:
3. multy init
4. Define Your Infrastructure Resources: After creating your Multy project, you need to define your infrastructure resources using the Multy DSL. Multy DSL is a simple language that enables you to define your infrastructure resources in a cloud-agnostic way.
5. Apply Your Infrastructure Changes: Once you have defined your infrastructure resources, you can apply your changes to your infrastructure using the following command:
6. multy apply

Conclusion​

Multy is a promising alternative to Terraform that offers several unique features, including multi-cloud provider support, native Kubernetes support, and secure remote state management. While it has some limitations, it's worth exploring if you are looking for a cloud-agnostic IaC tool that can help you manage your infrastructure across multiple cloud providers.

As the world moves towards the cloud, managing infrastructure has become increasingly complex. Whether you're working with AWS, GCP, or Azure, the sheer number of services available can be overwhelming. Infrastructure management is no longer just about keeping the lights on; it's about keeping your applications running smoothly while keeping costs under control. Enter Terraform - an open-source infrastructure-as-code tool that simplifies infrastructure management.

What is Terraform?​

Terraform is a tool that allows you to define your infrastructure as code. This means that instead of configuring your infrastructure manually, you can write code that describes the desired state of your infrastructure. Terraform then takes care of creating, updating, or deleting resources to make sure that your infrastructure matches the code you've written.

Why do you need Terraform?​

Terraform offers many benefits over manual infrastructure management. Firstly, it simplifies the process of defining your infrastructure. Instead of manually creating and configuring resources, you can use code to define your infrastructure. This makes it easier to create repeatable, predictable infrastructure that can be easily tested and modified.

Secondly, Terraform allows you to manage your infrastructure in a modular way. Instead of having to manage a monolithic infrastructure, you can break it down into smaller, more manageable components. This makes it easier to understand and modify your infrastructure.

Finally, Terraform makes it easier to manage infrastructure at scale. With Terraform, you can define your infrastructure in a way that makes it easy to replicate across multiple environments. This makes it easier to manage infrastructure across different regions, data centers, or cloud providers.

How to Install Terraform​

Terraform can be installed on Windows, Mac, and Linux. The installation process is straightforward and can be completed in a few simple steps. To install Terraform, follow the instructions provided in the official Terraform documentation for your specific operating system.

Linux Installation​

For Linux users, the easiest way to install Terraform is by using a package manager such as apt or yum. Here is an example of how to install Terraform on Ubuntu using apt.

sudo apt-get update
sudo apt-get install terraform

MacOS Installation​

On MacOS, you can install Terraform using the popular package manager Homebrew

brew install terraform

Windows Installation​

For Windows users, Terraform can be installed by downloading the appropriate executable file from the official Terraform website. Once downloaded, unzip the file and add the binary to your system's path.

Connecting to AWS, GCP, and Azure​

Once Terraform is installed, you'll need to configure it to work with your cloud provider. This involves setting up credentials and configuring the provider settings. Again, the official Terraform documentation provides detailed instructions for each cloud provider.

AWS Connection​

To connect to AWS, you need to have an AWS account and create an access key and secret key. Once you have those, add the following code to your Terraform configuration file:

provider "aws" {
  region     = "us-west-2"
  access_key = "YOUR_ACCESS_KEY"
  secret_key = "YOUR_SECRET_KEY"
}

Make sure to replace YOUR_ACCESS_KEY and YOUR_SECRET_KEY with your actual access key and secret key.

GCP Connection​

To connect to GCP, you need to have a GCP account and create a service account key. Once you have that, add the following code to your Terraform configuration file:

provider "google" {
  credentials = file("path/to/your/credentials.json")
  project     = "your-project-id"
  region      = "us-west1"
}

Make sure to replace path/to/your/credentials.json and your-project-id with the path to your credentials file and your actual GCP project ID.

Azure Connection​

To connect to Azure, you need to have an Azure account and create a service principal. Once you have that, add the following code to your Terraform configuration file:

provider "azurerm" {
  subscription_id = "YOUR_SUBSCRIPTION_ID"
  client_id       = "YOUR_CLIENT_ID"
  client_secret   = "YOUR_CLIENT_SECRET"
  tenant_id       = "YOUR_TENANT_ID"
}

Make sure to replace YOUR_SUBSCRIPTION_ID, YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, and YOUR_TENANT_ID with your actual Azure subscription ID, client ID, client secret, and tenant ID.

Managing Infrastructure with Terraform​

Now that you have Terraform installed and connected to your cloud provider, you can start managing infrastructure as code. Here are some examples of how to add, update, change, or remove real infrastructure using Terraform.

Adding, Updating, Changing, or Removing Real Infrastructure with Terraform​

Let's look at how you can use Terraform to manage your infrastructure. In this example, I'll use AWS as our cloud provider.

1. Define your infrastructure The first step is to define the infrastructure you want to create. In this example, I'll create an EC2 instance and an S3 bucket.

provider "aws" {
  region = "us-west-2"
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
}

2. Initialize Terraform Next, I need to initialize Terraform by running the terraform init command. This will download the necessary providers and modules.

3. Plan the changes I can now use the terraform plan command to preview the changes that Terraform will make to our infrastructure.

4. Apply the changes Finally, I can apply the changes by running the terraform apply command. This will apply the Terraform configuration and creates the resources defined in the configuration.

5. Update the Configuration If you want to change the configuration, you can update the Terraform configuration file and run terraform apply again. Terraform will automatically detect the changes and update the resources accordingly.

6. Remove Resources If you want to remove the resources defined in the configuration, you can run terraform destroy. This will remove all resources defined in the Terraform configuration.

Conclusion​

Infrastructure as code has become an essential part of modern software development, and Terraform is one of the most popular tools for managing infrastructure as code.

With Terraform, you can manage infrastructure across multiple cloud providers, define infrastructure in a declarative language, and version control your infrastructure. If you're not already using Terraform, I highly recommend that you give it a try.

In the next blog post, I will introduce Multy, a powerful tool for managing multiple Terraform workspaces. Stay tuned!