이건 좀 며칠 전에 공부했던 거긴 하지만, 그래도 기록으로서 남겨놓고 싶은 마음이 있기에 한 번 적어보도록 한다!
AWS가 끝나고 새로 배운 클라우드는 바로 구글 클라우드였다! (두둥) google이야 너무 익숙한 플랫폼이고, 용어의 차이가 좀 있겠지만 근본은 비슷할거라 생각했는데 생각보다 헷갈리는 것들이 많았다. 작동하는 방식부터가 상상도 못한 방식(?)이어서 처음엔 이해도 안됐고, 그래도 내가 익숙하게 사용해왔던 게 aws라 그런지 얘를 기준에 두고 생각하다 보니 헷갈리고... 공식문서도... 어려움. 그리고 사용자 친화적 인터페이스라면서요 저에겐 친화적이지 않았어요 강사님은 잘 되어있다고 하셨지만 그냥 쉬운 공식 문서라는 것은 세상에 없는듯 ^^ 걍 공식 달고 나오는 것들 다 어려워... 작동 방식부터가 aws와 너무 다르고, 속도도 개느려서 답답했는데 그래서 관련해서 기본적인 개념들에 대해서 찾아보는 시간을 가졌었다.
☁️ 구글 클라우드
⚙️ 작동 원리
특이하게도?! 구글 클라우드는 API를 기반으로 움직이는 시스템을 가졌다. 비유하자면 구글 클라우드는 거대한 디지털 도서관이라고 할 수 있다. 도서관에는 수많은 책이 있다. (👉🏻 API 또는 라이브러리)
그래서 VPC 같은 서비스를 사용하려고 할 때 라이브러리 사용을 눌러서 허가를 받아야 했던 것이다.
🛠️ Google Cloud VS. AWS
차이점
- AWS가 더 광범위한 서비스를 제공한다. 하지만 구글 클라우드가 데이터 분석과 머신러닝 분야에서 더 강세를 보인다.
- AWS가 글로벌 인프라가 더 풍부하다. (더 많은 데이터 센터와 더 넓은 글로벌 인프라)
- 구글 클라우드의 인터페이스가 더 직관적이고 사용하기 쉽다는 평이 있다. (공감은 안됨)
각각의 장단점
구글 클라우드
- 😀 데이터 분석 및 AI/ML 기능이 우수하다. 사용자 친화적인 인터페이스를 갖고 있으며, 구글 서비스와의 통합이 쉽다.
- ☹️ 하지만 AWS에 비해서 서비스 다양성이 부족하며, 시장 점유율이 낮다.
AWS
- 😀 광범위한 서비스를 제공하며, 가장 높은 시장 점유율을 보이고 있을 뿐 아니라 글로벌 인프라가 넓게 포진되어 있다.
- ☹️ 복잡한 가격 구조를 가지고 있으며, 초보자에게는 학습 곡선이 가파를 수 있다.
언제 사용할까?
-
구글 클라우드
- 데이터 분석이나 머신 러닝 프로젝트 진행 시
- 구글의 다른 서비스들과 통합이 필요할 때
- 사용자 친화적인 인터페이스를 선호할 때
-
AWS
- 다양한 서비스가 필요한 복잡한 프로젝트를 진행할 때
- 글로벌 규모의 인프라가 필요할 때
- 기존 AWS 경험이 있거나 AWS의 광범위한 생태계를 활용하고 싶을 때
👉🏻 두 플랫폼 모두 강력한 클라우드 서비스를 제공한다. 때문에 각각의 장단점을 파악하고 적절한 클라우드 서비스를 이용하는 것이 좋을 것 같다.
🔀 로드 밸런싱
다른 건 그럭저럭 AWS에서 배웠던 지식을 바탕으로 이해를 하고 넘어갔는데 (크게 다르다고 느끼지 않았음) 로드 밸런싱에서는 띠용 🙄 ? 이해가 안 가는 부분들이 좀 많았는데... 그래서 이 글을 작성하게 된 것이었다. 한 번 차근차근 과정을 되짚어보며 이해를 해보자며... AWS와 비교했을 때 무엇이 다른지, 왜 내가 어렵게 느끼는 것인지를 한 번 생각해봤다.
☁️ AWS의 로드밸런싱과 Google Cloud의 로드 밸런싱
🌿 AWS
AWS의 로드 밸런싱 시스템은 대형 푸드코트와 같다.
- VPC = 푸드코트 전체 건물
- 서브넷 = 푸드코트 내의 각 구역 (ex. 한식, 양식, 중식, 일식 구역)
- 인스턴스 = 각 구역의 음식점
- 로드 밸런서 = 푸드코트 입구의 안내 데스크
- 타겟 그룹 = 특정 종류의 음식을 제공하는 음식점 목록
👉🏻 손님(트래픽)이 푸드코트에 들어오면 안내 데스크(로드 밸런서)에서 원하는 음식 종류를 확인하고, 해당 종류의 음식점 중에서 한가한 곳으로 안내한다. 이렇게 모든 음식점에 손님을 골고루 분산시킨다.
🌿 Google Cloud
구글 클라우드의 로드 밸런싱 시스템은 글로벌 체인 레스토랑과 유사하다.
- 전체 시스템 = 전 세계에 지점을 둔 대형 레스토랑 체인
- 각 지역의 서버 = 각 나라나 도시의 레스토랑 지점
- 로드 밸런서 = 중앙 예약 시스템
👉🏻 고객(트래픽)이 레스토랑을 이용하고자 할 때, 중앙 예약 시스템(로드 밸런서)에 연락한다. 이 시스템은 고객의 위치, 각 지점의 혼잡도, 특별 요구사항 등을 고려하여 가장 적합한 지점으로 안내한다.
구글 클라우드의 시스템이 좀 더 글로벌한 한 덩어리(?)로 운영되는 것처럼 느껴져서, 초반엔 aws랑 너무 다르니까 😫 이게 무슨 이야기인지 전혀 이해가 가지 않았다. 작동 기반부터가 다른 것...
차이점
| AWS | Google Cloud | |
|---|---|---|
| 작동 기반 | 리전 내에서 작동 | 글로벌 로드 밸런싱을 기본으로 제공 |
| IP 주소 할당 | 여러 IP 주소를 사용할 수 있음 | 단일 글로벌 IP 주소 사용 |
| 자동 확장성 | Auto Scaling 그룹을 별도 구성 | 자동 확장이 더 원활하게 통합되어 있음 |
| 구성의 유연성 | 더 세밀한 구성 가능 | 더 간단하고 자동화된 구성 제공 |
| 콘텐츠 기반 라우팅 | Application Load Balancer에서 제공 | HTTP(S) 로드 밸런서에서 더 강력한 기능 제공 |
그러니까, 처음엔 대충 같겠지 뭐~ 하고 생각하며 들어갔던 나의 생각과는 전혀 달랐던 것임!! 작동 기반부터가 다르고, 설정이 필요한 부분도 달랐던 것이다.
AWS의 시스템이 더 세밀한 제어를 제공하지만 그만큼 내가 관리할 포인트가 많아진다는 이야기겠고, 구글 클라우드의 시스템은 글로벌 스케일이라는 점과 훨씬 더 단순하게 진행이 된다는 것이 달랐다. 프로젝트에 따라서 다르게 사용하면 될 일인 것!
☁️ Google Cloud에서 로드 밸런싱 구성하기
1. 초기 설정
- Compute Engine API와 Cloud Load Balancing API를 활성화
API 활성화는 로드 밸런싱 서비스를 사용하기 위한 필수 단계이다!! 활성화를 시켜놔야 구글 클라우드에서 해당 서비스를 사용할 수 있다.
2. 백엔드 인프라 구축
- 가상 머신(VM) 인스턴스 생성 👉🏻 로드 밸런서의 백엔드 역할
* 실습에서 생성한 인스턴스 그룹 = 로드 밸런서의 백엔드로 사용되는, 실제 사용자의 요청을 처리할 서버들의 집합
* 궁금했던 점 - 왜 프론트엔드 인스턴스는 따로 구성하지 않는 걸까?
- Google Cloud Load Balancer 자체가 프론트 엔드 역할을 수행한다!
👉🏻 로드 밸런서 자체가 사용자의 요청을 받아 백엔드 인스턴스로 분배하는 프론트엔드 역할을 한다.- 로드 밸런서는 글로벌 프론트엔드 IP 주소를 제공하며, 이를 통해 트래픽을 분산시킨다.
- 백엔드 서비스가 실제 요청을 처리하고, 로드 밸런서는 이 백엔드 서비스로 트래픽을 분산시키는 역할을 한다.
⇨ 이는 구글 클라우드의 로드 밸런싱 아키텍처 자체의 특징! 관리를 쉽게 도와주고, 효율성을 높여준다.
- 필요한 소프트웨어와 설정으로 VM 인스턴스 구성
- 네트워크와 서브넷 생성하여 인스턴스 배포
- 방화벽 규칙을 구성하여 VM 인스턴스 간의 통신 허용
3. 로드 밸런서 구성
-
콘솔에서 "로드 밸런싱"으로 이동 후 "로드 밸런서 만들기"를 클릭
-
로드 밸런서 유형을 선택한다.
- HTTP(S) : 웹 애플리케이션용
- TCP/UDP : 비 HTTP 트래픽용
- 내부 로드 밸런싱: 비공개/내부서비스용
-
프론트엔드 구성
- 외부 IP 주소 할당 👉🏻 사용자가 접근할 수 있는 단일 진입점
- 프로토콜(HTTP/HTTPS) 선택 👉🏻 HTTP 프로토콜: 웹 트래픽을 처리하기 위한 기본 설정
- 포트 지정
-
백엔드 구성
- 백엔드 서비스 생성
- 인스턴스 그룹 또는 개별 VM 인스턴스 추가
- 트래픽 분산 알고리즘 선택 (ex. 라운드 로빈, 최소 연결)
-
상태 확인 설정 - 상태 확인 간격, 타임아웃, 실패 임계값 등 지정
* 실습에서의 헬스 체크(Health Check)가 바로 이 상태 확인!
- 백엔드 인스턴스가 트래픽을 적절하게 처리할 수 있는지 확인
- 주기적으로 인스턴스에 프로브(probe)를 보내 응답 확인
- HTTP 200 OK 응답을 받으면 해당 인스턴스를 '정상'으로 간주
👉🏻 이를 통해 로드 밸런서가 정상 작동 중인 인스턴스에만 트래픽을 전달할 수 있다
👉🏻 또한 미리 헬스 체크를 만들어두며 여러 개의 로드 밸런서에서 동일한 헬스 체크를 재사용할 수 있고, 미리 세밀하게 조정할 수도 있다
- 보안 설정 (HTTPS일 경우) - SSL 인증서 구성, SSL 정책 설정
4. URL 맵 및 라우팅 규칙 설정 (HTTP(S) 로드 밸런서의 경우)
- URL 맵을 생성하여 특정 URL 경로나 호스트 이름에 따라 트래픽을 다른 백엔드 서비스로 라우팅
5. 방화벽 규칙 구성
- 상태 확인 프로브가 백엔드에 도달할 수 있도록 인바운드 허용 방화벽 규칙 생성
* HTTP 트래픽 허용 규칙 추가
실습 할 때, 이 부분에서 막혀서 웹 서버가 열리지 않는 문제가 발생했었다 ^^ default 방화벽 규칙에 전부 포함이 되어있는 줄 알았는데? 아니었습니다? 로드 밸런서를 구성할 때 꼭 이 부분을 확인하고 넘어가는 것이 필요할 것 같다.
-
HTTP 트래픽 허용 규칙 추가
- 'default-allow-http' 라는 이름의 새로운 인그레스 방화벽 규칙을 만든다
- 소스 IP 범위를 '0.0.0.0/0'로 설정
- 프로토콜 및 포트에서 'tcp:80'을 지정
-
인스턴스 네트워크 태그 확인
- VM 인스턴스의 세부 정보 페이지에서 네트워크 태그 확인
- 필요하다면 'http-server' 태그 추가
-
웹 서버 실행 상태 확인
- SSH를 통해 VM 접속
sudo systemctl status nginx | apache2등의 명령어로 웹 서버가 실행 중인지 확인
-
외부 IP 주소 확인 - VM 인스턴스 목록에서 외부 IP 주소 올바른지 확인
-
브라우저 캐시 삭제
👉🏻 클라우드 환경에서는 보안을 위해 기본적으로 모든 포트를 차단하고 필요한 포트만 명시적으로 열어주는 방식을 사용한다. 때문에 웹 서버를 운영하기 위해서는 반드시 HTTP 트래픽(80 포트)를 허용하는 규칙을 추가해주어야 한다. 클라우드 환경에서 서비스를 제공할 때 반드시 확인해야 하는 중요한 설정이다!
👉🏻 tcp:80이 필요한 이유가 뭘까?! (왜 http:80이 아닌지?!)
TCP는 전송 계층 프로토콜이고, HTTP는 응용 계층 프로토콜이다. HTTP는 TCP 위에서 동작한다. TCP는 두 컴퓨터 간에 신뢰할 수 있는 연결을 설정하는 역할을 한다. HTTP는 이 연결을 사용해서 서버와 클라이언트 간에 데이터를 전송한다.
그런데! HTTP는 TCP 없이는 기능할 수 없다. TCP가 먼저 연결을 설정해야 HTTP가 그 위에서 동작할 수 있다.
때문에 80번 포트는 HTTP의 기본 포트이긴 하지만! 실제로는 TCP 연결을 통해서 사용된다. 그래서 방화벽 규칙에서도 http:80이 아니라 tcp:80포트를 열어주어야 HTTP 통신이 가능해진다.
6. 테스트 및 모니터링
- 로드 밸런서의 IP 주소로 트래픽을 보내 정상 작동하는지 확인
- Google Cloud 모니터링을 사용하여 로드 밸런서의 성능과 상태 모니터링
7. 최적화 및 스케일링
- 트래픽 패턴 분석하고, 필요에 따라 백엔드 인스턴스 수를 조정
- 자동 스케일링 정책을 구성하여 트래픽 변동에 자동으로 대응하도록 설정
느낀점
구글 클라우드... 편리한 점을 잘 모르겠다... 이걸 먼저 배웠다면 달랐을까...? 하지만 시장에서 많이 쓰이는 데에는 다 이유가 있는법 (끄덕)... 이런 생각만 든달까요 ^^~ 깔깔 아무튼 그래도 AWS를 배우고 나서 비교하면서 새로 알아가는 재미가 살짝(아주살짝)있는 것 같다. 정리해야지~정리해야지~ 미루다가 이제 함 ㅎㅎ 지금은 애져를 공부 중이다... 이제 수업 자체는 얼마 안남았는데 남은 시간 화이팅 하고! 프로젝트도 열심히 해야겠다~ 파이팅~
본 포스팅은 글로벌소프트웨어캠퍼스와 교보DTS가 함께 진행하는 챌린지입니다.
