안녕하세요?

코딩하는 모주부 입니다!

점점 시리즈가 마지막을 향해 가고 있네요!

1. GCP 에서 내부 / 외부 부하 분산 선택하기

지난번 포스팅을 다 따라 하셨다면,

formicae.tistory.com/entry/GCPGoogle-cloud-platform%EB%A1%9C-%EB%82%98%EC%9D%98-%EC%84%9C%EB%B2%84Server-%EB%A7%8C%EB%93%A4%EA%B8%B0-4?category=815536

로드 밸런서 (부하 분산) 설정을 위해 네트워크 서비스로 들어갑시다

부하 분산(Load balancing) 이란,

간단하게 말해서 컴퓨터가 감당하기 힘들 정도의

요청이 들어오는 경우 (사용자가 CPU load % 설정 가능)

다른 컴퓨터로 요청을 나누어 처리하는 것을 말합니다.

우리는 http / https를 이용해 클라이언트에서 서버로 요청을 할 것이기 때문에 

HTTP(S) 부하 분산을 선택합시다!

아래와 같이 선택지가 나오면,

"인터넷 트래픽을 VM으로 분산" 을 선택합시다

이 두개의 차이는 외부 부하 분산이냐,

내부 부하 분산이냐의 차이입니다.

내부 / 외부 부하 분산의 차이점은 다음과 같습니다.

만약 비 관리형 인스턴스 그룹에서

특정 리전만을 사용하거나

여러개의 VM들의 역할이 명확하게 구분 되고

트래픽 분산에 대한 규칙이 있다면

"VM 사이에서만 분산"을 사용해도 되겠습니다.

(내부 부하 분산)

하지만, 인터넷에서 요청되는 트래픽들이

리전을 골라서 분배가 되어야 하거나,

트래픽 규모에 따라 인스턴스의 크기가 자동으로 변동되어

결정된 VM들 사이에서 부하가 분산되기를 원한다면

"인터넷 트래픽을 VM으로 분산"을 선택해야 합니다.

(외부 부하 분산) 

아래의 구글 공식 문서에 첨부되어 있는 그림을 참고하시기 바랍니다.

2. GCP에서 외부 부하 분산 생성하기

외부 부하 분산기를 선택하셨다면,

부하 분산을 구성하기 위해 다음의 작업을 수행해야 합니다. 

1. 백엔드 서비스 생성 및 연결

2. 호스트 및 경로 규칙 생성

3. 프런트엔드 연결

2.1 백엔드(Backend) 구성

백엔드란, 쉽게 말해서 서버와 관련되어있는 기술을 말합니다.

로드 밸런서가 외부의 트래픽을 Virtual machine에 나누어 주는데,

VM에서 받은 트래픽을 처리하기 위해서는 서버가 필요하겠죠?

데이터베이스와도 통신을 해서 정보를 가져오고,

인터넷에서 요청된 트래픽을 처리하는 등의 작업들을 통틀어 백엔드라고 부릅니다.

좀 더 넓은 의미의 백엔드는 프론트엔드가 아닌 모든 것을 의미하기도 합니다!

반대로 프론트 엔드란,

인간이 인터넷을 이용하기 위해 마주하는 화면 또는 UI에서

사용자가 사용할 수 있게끔 구현하는 기술을 말합니다.

주로 HTML이나 CSS, Javascript와 같은 프로그래밍 언어들이 사용됩니다.

백엔드를 새로 생성할 때, 주의해야 하는 사항이 있습니다.

이전 포스팅을 보면 방화벽에서 포트 3000번을 지정한 적이 있을 겁니다.

formicae.tistory.com/entry/GCPGoogle-cloud-platform%EB%A1%9C-%EB%82%98%EC%9D%98-%EC%84%9C%EB%B2%84Server-%EB%A7%8C%EB%93%A4%EA%B8%B0-2?category=815536

이는 제가 GitHub에 올려놓은 서버 코드(www.js)에서 아래와 같이

포트를 3000번으로 지정 해 놓았기 때문인데요,

var port = normalizePort(process.env.PORT || '3000');
app.set('port', port);

만약 이 번호를 다르게 지정 해 주었다면,

지정한 번호를 "새 백엔드" 에서 "포트 번호"에 입력하시면 됩니다.

만약 해당 포트를 설정하지 않으면,

로드밸런서와 인스턴스 그룹의 통신이 되지 않으니 주의하세요!

이전 포스팅에서 상태 확인(health check)을 만들어 놓았다면,

아래와 같이 리스트에 선택 가능한 상태 확인이 나타 날 것입니다.

만약 상태확인이 나타나지 않는다면,

이미 인스턴스 그룹 또한 정상 상태가 아닐 확률이 높으므로

이전 포스팅을 참조하시기 바랍니다.

formicae.tistory.com/entry/GCPGoogle-cloud-platform%EB%A1%9C-%EB%82%98%EC%9D%98-%EC%84%9C%EB%B2%84Server-%EB%A7%8C%EB%93%A4%EA%B8%B0-4?category=815536

아래와 같이 백엔드가 다 만들어졌으면, 호스트 및 경로 규칙을 만들어 볼 차례입니다.

포스팅이 너무 길어지는 관계로,

이 내용은 다음 포스트에서 다루도록 하겠습니다!

안녕하세요?

코딩하는 모주부 입니다.

이번 시간에는 Cloud platform에서 많이 거론되는 VPC에 대해 알아볼 거에요

VPC는 글자의 의미에서 알 수 있듯이,

가상공간에서 이루어진 사설 클라우드 입니다.

VPN이랑 이름이 헷갈릴 수 있는데,

VPN에 대한 설명은 포스트 하단에 남겨놓도록 하겠습니다.

VPC를 사용하는 경우를 설명하기 위해서 

A, B, C, D, E, F 라는 인스턴스가 있다고 합시다.

클라우드 시스템에서 이 인스턴스들이 모두 동작을 하고,

상호 통신을 해야한다고 하면

A는 B, C, D, E, F와 연결되어야 하고

B는 A, C, D, E, F 와 연결되어야 하고, ... 등등

매우 많은 연결이 필요합니다.

이는 언뜻봐도 매우 비효율적이죠.

이를 해결할 수 있는 것이 바로 VPC 입니다.

A, B, C 를 Subnet1 로 묶어 서로 연결하고,

D, E, F 를 Subnet2로 묶은 다음 서로 연결을 하여

통신을 하게 됩니다.

GCP에는 VPC 네트워크를 커스터 마이징할 수 있는데요,

1. 특정 지역의 네트워크만을 사용하고 싶을 때

2. VM이 접근할 수 있는 영역을 제한하고, 나누고 싶을 때

사용하면 좋습니다.

예를 들어, 하나의 VPC 네트워크를 만들어서

그 안에 VM과 PostgreSQL과 같은 데이터베이스를 넣으면

VM <--> Database 간 통신은 내부 IP 로 통신을 하고,

Database는 외부로 유출 될 일이 없는 보안성이 우수한 구조가 되는 것입니다.

VPC 네트워크의 특성

> 하나 이상의 서브넷으로 구성.
> 리전에 연결되어 있지 않음.

아래 그림은 두 개의 리전에 3개의 서브넷이 있는 
VPC네트워크 구성도를 나타낸 것입니다.
Subnet 내부에도 zone이 존재하는데, 
이 zone은 서로 다른 subnet들에 중복으로 포함될 수 있습니다.
(us-east1-a) 

서브 넷(Sub net) 이란?

유용한 IP가 여러 개 모인 것을 의미 (생성 시 기본 IP 주소 범위 설정 필요)
각 서브넷은 리전에 연결됨.
유효한 범위가 존재함.

< 혼란 방지용 >
VPN (Virtual Private Network)이란?

회사들의 네트워크는 사설망으로 이루어져 있는 경우가 많습니다.
(누구나 접속할 수 있는 전화망이나 인터넷과 같은 공중망과 분리)
조직 내에서 인증된 사람만이 이용할 수 있도록 구성 해 놓은 것으로
보안이 뛰어난 것이 특징입니다.

하지만 재택근무를 하거나 원격으로
이 네트워크에 접속할 필요가 있는 경우,
실제로 사설 망과 연결되어 있지 않더라도
VPN을 이용하여 접속을 할 수 있는 것입니다.

따라서, VPN은 보안을 유지하면서도
특정 인원이 사설망에 연결될 수 있도록 하는
가상의 네트워크를 일컫는 것입니다.

여기까지 VPC에 관한 내용들이었습니다.

다음번에는 다른 내용으로 찾아오겠습니다.

오늘도 재미있는 코딩 하세요 :)

안녕하세요?

코딩하는 모주부 입니다!

이번에는 구독자님의 요청이 있어서

티스토리에서 글자(폰트) 크기를 조절하는 방법을 알아볼 거에요!

기본적으로, 티스토리에서 제공되는 글씨의 크기는

아래와 같이 총 6가지가 있는 것으로 보입니다.

또한, 제목의 글자 속성에는 다음 글자와의

상하 자간 길이도 포함되어 있는 것으로 보입니다.

> 실제 크기 <

제목1 [ABC]

제목2 [ABC]

제목3 [ABC]

본문1

본문2

본문3

티스토리 상단에서

기본모드 --> HTML로 변경했을 때,

위의 텍스트 들은 다음과 같이 정의되어 있습니다.

일단, "제목" 이라고 되어있는 항목들은 <h> tag,

"본문" 이라고 되어있는 항목들은 <p> tag로

이루어 진 것을 확인할 수 있습니다!

(<h> tag는 head, <p> tag는 paragraph의 약어로써,

각각 제목과 본문을 의미한다고 보시면 됩니다.)

1. 제목 글자(폰트) 크기 변경

1.1 <h> tag 내부의 data-ke-size를 변경 해보자

h2-size26 [ABC]

h2-size24 [ABC]

h2-size20 [ABC]

h2-size16 [ABC]

h2-size12 [ABC]

h2-size4 [ABC]

▶ 폰트 크기의 유의미한 변화는 없습니다

h2 tag내부의 data-ke-size 는

HTML의 기본 attribute가 아닌,

티스토리에서 임의로 만든 것으로 보입니다.

이 때문에 임의로 size를 변경해도 변화가 없는 것 같아요.

1.2 다양한 <h> tag를 사용해 보자

h1-size26 [ABC]

h2-size26 [ABC]

h5-size26 [ABC]

h6-size26 [ABC]

▶ 크기의 변화가 있습니다!

HTML에서 <h> tag는

h1 부터 h6까지 있으므로

원하시는 크기를 선택해서 사용하시면 될 것 같습니다.

2. 본문 글자(폰트) 크기 변경

2.1 <p> tag 내부의 data-ke-size를 변경 해보자

size6-100% = 본문2

size8-100% =본문2

size10-100% = 본문2

size12-100% = 본문2

size14-100% = 본문3

size16-100% = 본문2

size18-100% = 본문1

size20-100% = 본문2

size22-100% = 본문2

size24-100% = 본문2

size 12/14/18 을 제외하고는,

모두 size와 관계없이 본문2와 같은 크기로

rendering되는 것을 확인 할 수 있습니다.

따라서 size를 변경해서는 원하는 크기를 얻을 수 없습니다.

2.2 <p> tag 내부의 style에서 font-size를 변경 해보자

size18-60%

size18-80%

size18-100% = 본문1

size18-150%

size18-200%

size18-250%

size18-300%

size18-400%

size12-60%

size12-80%

size12-100% = 본문2

size12-150%

size12-200%

size12-250%

size12-300%

size12-400%

size14-40%

size14-60%

size14-80%

size14-100% = 본문3

size14-150%

size14-200%

size14-250%

size14-300%

size14-400%

이런 식으로, 크기를 원하는대로 변경할 수 있습니다!

하지만, 티스토리에서 기본적으로 만들어지는 본문에서는

<p> tag 내부의 style에는 font-size 항목이 존재하지 않습니다.

따라서, <p> tag 안에 아래의 코드를 삽입 해 보시기 바랍니다.

style="font-size:200%"

유익한 시간이 되었나요?

한 줄에 서로 다른 크기의 글자를 섞는 방법은 다음 포스팅에서알아보아요!

그럼 즐거운 포스팅 되세요 :)

안녕하세요?

코딩하는 모주부입니다!

티스토리 PC버전에서 글을 작성하다 보면,

표(테이블) 와 코드 블럭을 삽입 하면 항상 왼쪽으로 정렬이 되어있습니다.

볼 때 마다 매우 거슬리는데, 

가운데 정렬하는 방법을 알려드리려고 합니다!

(코딩을 모르는 사람도 따라할수 있어요 ^-^)

티스토리 글쓰기는 default로 "기본모드" 로 되어 있습니다.

오른쪽 상단의 해당 글자를 클릭하면

"HTML" 이라고 되어있는 것이 있습니다.

이것을 클릭합시다.

이것을 누르면 매우 복잡한 코드들이 나와 있습니다.

사실 우리가 보는 모든 인터넷의 화면은

이 HTML (Hyper Text Markup Language)라는 규칙으로 이루어져 있습니다.

따로 티스토리에서 테이블의 정렬 기능을 구현하지 않고 있기 때문에,

HTML을 직접 변경할 필요가 있는 것이지요.

아래에 왼쪽 정렬되어 있는 Table 1 ,

가운데 정렬되어 있는 Table 2 를

예시로 보겠습니다.

Ctrl + F 를 눌러

"table" 을 입력해서 검색 해 봅시다.

아래와 같이 검색 결과가 노란색으로 표시 될 것입니다.

그런뒤, 아래의 코드를 복사해

<table ....> 코드 위에 삽입 해주시고,

(아래 코드 블럭도 중앙 정렬 된 것입니다)

<div align="center">

다음의 코드를 </table> 코드 아래에 삽입 해주세요

</div>

잘 입력 했다면, 아래 화면과 같이 되었는지 확인을 한 뒤,

다시 "기본모드" 로 돌아옵니다.

잘 입력 했다면, 저의 포스트와 같이 표(테이블)와 코드 블럭이

중앙에 위치 해 있을 겁니다!

여기까지 HTML를 수정하여 포스팅 내용을

가운데 정렬하는 방법을 알아보았습니다.

오늘도 재미있는 코딩 하세요!

인스턴스 그룹을 생성해보자 (feat. VPC 네트워크)

안녕하세요?

한끼 코딩입니다.

최근에 집들이가 너무 많아 코드 포스팅이 조금 늦어졌네요

그럼 이번에도 이어서 가볼까요?

1. GCP내의 인스턴스 그룹 종류

이번 시간에는 인스턴스 그룹을 만들어 볼 텐데요,

인스턴스 그룹은 말 그대로 인스턴스가 그룹을 이루고 있는 것입니다.

GCP에서는 그룹 인스턴스의 종류는 크게 2가지가 있습니다.

1. 관리형 인스턴스 그룹

2. 비 관리형 인스턴스 그룹

관리형과 비 관리형의 차이점은 아래와 같습니다.

관리형 인스턴스를 사용하는 가장 큰 이유는

Virtual machine의 CPU load를 감시하여

일정 수준 이상에 도달하였을 때,

인스턴스를 추가적으로 생성하여

외부의 request로 인한 load를 분배해 주기 때문입니다.

즉, 비 관리형 인스턴스 그룹을 사용하게 되면

갑작스러운 서버 폭주로 인해 다운이 될 확률이 높고

관리형 인스턴스는 서버의 규모를 늘리기 때문에 안정성이 높습니다.

이런 관리형 인스턴스에도 아래와 같이 2종류로 나누어집니다.

(MIG : managed instance group)

어떠한 인스턴스 그룹을 사용하는지는,

본인이 만들 애플리케이션의 기능과 규모를 따져서 결정해야 합니다.

이번에는 규모가 그리 크지 않고, 외부의 요청이 없지만

(비 관리형 인스턴스를 사용해도 문제가 없지만)

언젠가는 필요할..! 관리형 인스턴스 그룹을 만들어 보도록 하겠습니다.

2. 인스턴스 그룹 생성하기

이전 포스팅에서 만든 인스턴스 템플릿을 선택해 주시고,

자동 복구 - 상태확인에서 새로 생성하기를 눌러주세요.

formicae.tistory.com/entry/GCPGoogle-cloud-platform%EB%A1%9C-%EB%82%98%EC%9D%98-%EC%84%9C%EB%B2%84Server-%EB%A7%8C%EB%93%A4%EA%B8%B0-3?category=815536

GitHub 주소 :

github.com/formicae/gcp_example

현재 서버의 PORT가 3000번이고 HTTP 통신을 할 것이므로,

저의 GitHub 소스를 사용하시는 분들은 아래 그림과 같이 입력 해 주세요.

중요한 것은, 요청 경로에 반드시 다음의 문구를 입력 해야 합니다.

/health_check

이유는, 아래와 같이 제가 GitHub에 만들어 놓은 코드의

GET method 중 상태 체크용으로 만든 uri가 /health_check 이기 때문이에요

인스턴스 그룹을 만들었다면,

상태가 정상인지 확인해 주세요.

만약 정상이 아니라면, 그룹에 포함된 인스턴스에 문제가 있을 확률이 높답니다!

인스턴스 그룹의 생성은 간단하지만, 

목적에 맞게 선택하는 것이 중요하답니다.

인스턴스 그룹을 생성하고 난 뒤에도

인스턴스를 수정해도 괜찮습니다.

다만, 로드 밸런서의 연결이 되어있다면

해당 인스턴스의 부팅이 끝나는 시간과

로드 밸런서에서 health check 하는 시간 동안

서버로의 연결이 지연되므로

인스턴스 그룹의 상태가 녹색 체크가 아니신 분들은

여유롭게 3~5분 정도 기다려보시기 바랍니다.

만약 그래도 인스턴스가 정상 상태가 아니라면,

상태 체크(health check)에 실패 했을 확률이 매우 높습니다

이전 포스팅에서 만든 인스턴스 템플릿을 다시 한번 확인 해 보세요!!

그럼, 다음 포스팅에서 인스턴스 그룹을

로드 밸런서에 연결 해봅시다!

안녕하세요?

코딩하는 모주부 입니다!

오늘도 지난 포스팅에 이어 달려봅시다 ㅎㅎ

1. GCP에서 스냅샷 생성하기

이때까지 GCP로 가상머신을 빌리고,

서버를 올려 실행하는 것 까지 해보았습니다.

(아래 포스팅 참조)

https://formicae.tistory.com/entry/GCPGoogle-cloud-platform%EB%A1%9C-%EB%82%98%EC%9D%98-%EC%84%9C%EB%B2%84Server-%EB%A7%8C%EB%93%A4%EA%B8%B0-2?category=811869

하지만 테스트를 했던 서버의 규모  가 커지게 되면,

이 방법을 고수 할 때, 서버로 요청 이 많아질 경우

서버가 버티지 못하고 응답 불가 상태가 되어 버립니다.

쉬운 말로, 다운되어 버리는 것이지요.

이를 피하기 위해서는 서버로의 요청에 따라

VM(가상머신)을 여러개 늘려주고 ↑,

요청이 없을 때에는 줄여주는 ↓

관리형 인스턴스 그룹을 사용하기도 합니다.

이를 위해서 가장 먼저 해야할 일은,

이전 인스턴스를 토대로 스냅샷을 만드는 것입니다.

> 스냅샷 이란? <

특정 시간에 저장 장치의 상태를 순간적으로 캡쳐하여

보존하고, 백업 용도로 사용 하는 것을 말합니다.

쉽게 말해, 휴대폰에 있는 정보들을 기억하기 위해서

캡쳐하여 갤러리에 넣어놓는 것 처럼,

순간의 VM 상태를 남겨 놓는 것입니다.

캡쳐하는 속성이 있기 때문에, 매일 또는 특정 주기마다

스냅샷 생성을 하는 것도 가능하죠.

먼저, Compute Engine에서 스냅샷으로 들어가봅시다.

첫 화면은 아무것도 없을테니, 생성하기를 클릭해 봅시다.

소스 디스크에는 미리 만들어 놓은 VM을 선택힙니다.

리전을 결정할 때에는 신중하게 선택을 해야합니다.

내가 스냅샷 저장을 위해 빌리는 위치를 결정하는 것이지요.

리전을 결정하는 기준은 아래의 포스팅을 참조합시다!

formicae.tistory.com/entry/%EC%84%9C%EB%B2%84%EC%9D%98-%EC%9A%94%EC%B2%AD%EA%B3%BC-%EC%9D%91%EB%8B%B5%EC%9D%98-%EA%B4%80%EC%A0%90%EC%97%90%EC%84%9C-%EB%B3%B4%EB%8A%94-%EB%A6%AC%EC%A0%84Region-%EB%A9%80%ED%8B%B0-%EB%A6%AC%EC%A0%84

스냅샷을 생성했다면, 아래와 같이 녹색 체크표시가 뜰 것이다.

그렇다면 이제 이미지를 만들 차례입니다.

2. GCP에서 이미지 생성하기

> 이미지란 무엇인가? <

이미지는 디스크나 스냅샷을 템플릿화 한 것으로

VM에 바로 올려 서버 사용을 할 수 있도록 

임시 디스크와 같은 것입니다.

가족과 함께있는 시간을 기억하고 싶어서

사진을 찍어놓은 것이 스냅샷이고,

그 스냅샷을 가족들이 보고

동일한 기억을 떠올리는 것이 바로 이미지인 것이죠.

아래와 같이 이미지를 만들면 되는데, 

계열을 추가하게 되면 인스턴스 그룹 설정때 편리합니다.

또한, 키&값 Pair 설정이 필요한 경우 입력하되

필수가 아니므로 그냥 넘어가도 상관없습니다.

아래와 같이 여기까지 다 만들었다면,

인스턴스 템플릿을 만들어 볼 차례입니다.

3. GCP에서 인스턴스 템플릿 만들기

인스턴스 템플릿을 만드는 과정은

인스턴스를 만드는 과정과 비슷합니다!

다른 점이 있다면, 부팅 디스크 대신

위에서 미리 만들어 둔 이미지를 사용한다는 것입니다.

머신 구성은 필요한 성능을 고려하여 선택 해 줍시다.

성능이 높을수록 더 비쌉니다..ㅎㅎ

부팅 디스크에서 "변경"을 클릭하고,

"맞춤 이미지"를 눌러 만들어 놓은 이미지를 선택합시다.

그리고 인스턴스를 만들 때와 동일하게

액세스 범위와 방화벽을 설정합니다.

그리고 가장 중요한.. 시작 스크립트를 삽입 해 줄거에요

시작 스크립트란, 인스턴스 템플릿이

VM의 메모리에 로드되었을 때 처음으로 실행할 코드를 의미합니다.

예전 포스팅에서 SSH로 들어가 CentOS용 명령어를 입력한 것이 기억 나시나요?

formicae.tistory.com/entry/GCPGoogle-cloud-platform%EB%A1%9C-%EB%82%98%EC%9D%98-%EC%84%9C%EB%B2%84Server-%EB%A7%8C%EB%93%A4%EA%B8%B0-2?category=815536

파란색으로 "관리, 보안, 디스크, 네트워킹, 단독 임대" 라고 쓰여있는

접어두기 표시를 클릭하게 되면 아래와 같이 나옵니다.

시작 스크립트에 아래 코드를 입력해 줍시다.

screen 을 생성하여 my_server라는 이름을 부여하고,

gcp_example이라는 폴더로 이동해, 서버를 기동시키는 코드 입니다.

#!/bin/bash
cd gcp_example
screen -dmS my_server bash -c 'npm start'

여기까지 만들었다면, 아래와 같은 화면이 나타날 거에요

그럼 다음 포스팅에서 그룹 인스턴스를 만들어 보겠습니다!

오늘도 재미있는 코딩 하세요 :)

안녕하세요?

코딩하는 모주부 입니다!

이번 시간에는, 서버의 요청과 응답이 어떤 식으로 이루어지는지 이해하고,

가상머신을 빌리거나, 스냅샷, 디스크를 생성할 때

결정하는 리전과 멀티리전을 알아 볼 거에요. 

1. 인터넷 검색을 할 때 일어나는 현상들

쉬운 예로, 우리가 구글창에 검색을 할 때

일어나는 현상들에 대해 순서대로 생각해 봅시다.

1. 우리가 구글에 "formicae" 라고 검색을 합니다.

2.  www.google.com이라는 도메인과 

연결된 서버에  "formicae"라는 문자로

검색을 해 달라는 요청이 보내집니다.

(www는 도메인과 연결된 서버의 위치를 알고있습니다.)

3. 구글의 서버에 해당 요청이 전달됩니다.

4. 구글의 서버에서 "formicae" 검색을 합니다.

5. 구글의 서버에서 검색 로직을 수행합니다.

6. 구글의 서버에서 로직이 종료되었을 때

수행되는 코드를 실행합니다.

7. 결과를 다시 사용자가 보는 html에 그려주기 위해 준비합니다.

8. 아래와 같은 url로 리다이렉션 되면서 결과가 나타납니다.
www.google.com/search?bih=914&biw=1569&hl=ko&sxsrf=ALeKk030NxYM5qTpzTeZYEGOtc9ueJ0JtQ%3A1602953536910&source=hp&ei=QCGLX_TdNIn7wAP0hZOgDw&q=formicae&oq=formicae&gs_lcp=CgZwc3ktYWIQAzICCAAyAggAMgIIADICCAAyAggAMgIIADIECAAQCjICCAAyAggAMgUIABDLAToFCAAQsQM6BwgAEBQQhwI6CAgAELEDEIMBOgQIIxAnOgcIIxDqAhAnOgQIABBDOgcIABCxAxBDUM4GWKEXYJMYaANwAHgAgAGCAYgBhgmSAQQwLjEwmAEAoAEBqgEHZ3dzLXdperABCg&sclient=psy-ab&ved=0ahUKEwj0_Z-hi7zsAhWJPXAKHfTCBPQQ4dUDCAc&uact=5

이게 다 무슨 말인가 싶겠지만, 우리가 인터넷을 사용하는

모든 행위들은 요청과 응답으로 이루어져 있고,

그 요청에 응답하는 서버들이 항상 존재해서,

결과물을 www(world wide web)를 통해 전달하여

html이라는 포맷을 통해 우리가 볼 수 있게

만들어 준다는것을 항상 명심합시다!

2. 리전과 멀티 리전

위의 예시와 같이 굳이 검색이 아니더라도,

인스턴스 끼리의 통신이나 데이터베이스와의 통신도

응답과 요청으로 이루어져 있습니다.

따라서, VM이나 데이터베이스등의 

위치를 결정할 때에는 신중하게 선택을 해야합니다.

구글에서 빌릴 수 있는

아시아, 북미의 서버는 대충 아래와 같이 분포합니다.

(남미, 유럽 서버도 있지만 생략합니다)

그렇다면 리전과 멀티리전이라는 것은 무엇일까요?

멀티 리전은, 대륙을 선택하면 지역을 분산하여 저장을 해줍니다.

예를들어, 아시아를 선택하면 아래와 같이

여러개의 리전에 분산되도록 저장을 해 줍니다.

< 멀티 리전 - Asia >

⊙ asia-east1-a

⊙ asia-northeast1-a

⊙ asia-northeast2-a

반대로, 일반 리전은 지역 하나에 분산하여 저장하는 것입니다.

예를 들어, asia-east1를 선택했다면 아래와 같이 저장 됩니다.

<리전 - Asia-east1 >

⊙ asia-east1-a

⊙ asia-east1-b

⊙ asia-east1-c

멀티 리전과 리전 중 어느 것을 선택하느냐에 따라,

지역에 따라 다르지만 응답 속도에 영향을 줄 수 있습니다.

응답 속도에 영향을 주는 것은 다음과 같은 요인들이 있습니다.

◆ 서버에 요청을 하는 클라이언트의 위치 (A)

◆ 응답을 하는 서버의 위치 (B)

◆ 서버와 통신하는 데이터 베이스의 위치 (C)

A 위치는 아시아, 북미, 유럽 다양할 수 있습니다.

B 위치는 이전 포스팅에서 만들었던 인스턴스의

위치로써, 한번 생성하면 고정이 되어있어요.

C 위치 또한 데이터 베이스를 생성할 때 결정하므로

고정이 되어있는 것이죠.

특정 사람이 "formicae"라고 검색하여

검색 엔진과 같은 로직이 실행 될 때,

서버에서 데이터 베이스를 참고해야 한다면

A -> B -> C 방향으로 요청이 이루어지고,

C -> B -> A 방향으로 응답이 이루어집니다.

따라서 A, B, C간의 거리는 가까운 것이 좋으므로

리전을 선택할 때 본인이 만들 서비스가

주로 어디에서 사용이 될 것인지를 잘 파악하는 것이 중요합니다!

TIP.

비용적인 측면을 고려하면

여러 리전에 저장하는 리소스가 드는 만큼

멀티리전이 리전보다 더 비쌀 수 밖에 없습니다.

여기까지 리전과 멀티리전에 대한 내용이었습니다.

다음 포스팅에서 또 만나요 :)

SSH(Secure Shell) 을 통해 VM(Virtual Machine)에 나만의 코드를 넣어 보자

1. 외부 IP 주소 고정 예약하기

VM 인스턴스 세부정보에 있는 직렬 포트1(콘솔) 에 들어가면

해당 인스턴스가 어떤 식으로 빌드되었는지 상세한 내용이 나옵니다.

만약 인스턴스가 제대로 생성되었지만, 원하는대로 동작하지 않는다면

콘솔에 들어가서 힌트를 얻을 수 있어요!

외부 주소 설정을 위해 네트워킹 - VPC 네트워크 - 외부 IP주소로 들어가 봅시다.

위에서 instance-1의 내부 IP와 더불어 외부 주소가 나타나 있는 것을 볼 수 있어요.

하지만 최초 VM을 생성하게 되면, 해당 외부 주소는 임시로 설정 되어 있습니다.

즉, 테스트를 하는 동안 이 임시 주소가 사라질 수도 있는 겁니다.

만약 동일한 IP를 유지시키고 싶다면 고정으로 바꾸는 것도 좋은 방법이에요.

하지만 https 인증을 하지 않은 http를 사용하고 있다면, 외부 해킹에 취약하다는 것을 기억합시다.

이번 시리즈에서는 이것을 고정으로 변경해서 사용해 볼 거에요.

2. SSH 에서 CentOs 패키지 설치

다시, VM 인스턴스로 돌아가서 연결 - SSH를 클릭 해봅시다.

생성 직후에는 아무런 파일도 존재하지 않아요.

먼저, 아래의 명령어를 터미널에 차례차례로 입력해봅시다.

sudo -s
yum install -y
yum install npm
yum install git
yum install screen

이로 인해 터미널에서 권한 (최상위 권한)을 획득하고,

yum이라는 centos에서 사용하는 패키지 설치 명령어를 사용할 수 있어요.

또한, yum을 통해 npm과 screen 과 git 이라는 패키지를 설치했습니다.

> npm 이란? <

(Node Package Manager)

Javascript 코드들을 실행하기 위해 Node JS를 사용하는데,

이 Node JS에서 사용할 수 있는 패키지들을 관장하는 도구입니다.

npm install xx 를 통해 Node JS에서 사용할 라이브러리들을

외부에서 다운로드하여 사용 할 수 있어요!

> screen 이란 ? <

단순히 말하자면, 여러 개의 창을 만들 수 있게 해주는 패키지.

터미널에서 추가적인 창을 만들어, 터미널을 종료하더라도

코드가 계속해서 실행될 수 있도록 하기 위해서 사용합니다.

> Git 이란? <

GitHub에 올려놓은 본인의 코드나 오픈소스들을

불러오거나 업데이트 할 수 있는 패키지.

3. GitHub의 코드를 가져와 설치하기

GitHub 등에 본인의 코드가 있는 사람들은 clone으로 불러옵시다.

만약 GitHub의 사용이 처음이라면, 일단 회원가입부터 해야해요.

코드가 없는 사람들은, 터미널에 아래의 명령어를 입력해봅시다.

git clone https://github.com/formicae/gcp_example.git
ls
cd gcp_example

여기까지 완료되었다면, 아래의 명령어를 터미널에 입력해봅시다

screen
screen -ls

screen을 통해서 또 하나의 창을 생성했습니다.

그 뒤, 총 활성화된 screen을 확인하는 명령어를 입력하면

아래와 같은 결과를 볼 수 있을 거에요.

마지막으로, 아래의 명령어를 입력해 코드를 서버에서 구동시켜 봅시다!

npm start

위 그림의 문구가 나오면, 제대로 실행이 되고 있다는 뜻입니다.

이제 SSH 터미널을 끕시다.

만약, Screen을 사용하지 않는다면 SSH 터미널을 끄는 순간

서버에 올린 코드는 그대로 끊겨버립니다.

이 때문에 Screen을 사용하여 코드를 동작시키는 것입니다.

4. 방화벽 설정하기

마지막으로 서버의 동작을 확인하기 전에, 방화벽을 손봐 주어야 합니다.

아래 그림과 같이 방화벽에서, http에 해당하는 방화벽을 수정합시다.

PORT 3000을 추가하는 이유는, Node JS 코드에서

접속 할 수 있는 PORT를 3000으로 제한했기 때문입니다.

PORT를 사용하는 목적은 다양한데, 추후에 다뤄 볼게요.

이제 마지막으로, 아까전에 고정시킨 외부 IP에서

PORT 번호 3000번을 추가하여 웹에서 요청을 보내봅시다.

서버에서 Screen을 통해 Node JS 코드가 동작하고 있으므로,

GET method 를 통해 아래와 같은 문구가 나타날 거에요.

여기까지 기본적인 VM 서버 생성이 완료되었습니다!

참고) 글쓴이의 서버비용을 위해 위의 외부IP는 막아놓은 상태이므로

해당 IP에서 응답이 왜 없는지에 대한 고민은 하지 않아도 된답니다! ㅎㅎ

안녕하세요?

코딩하는 모주부 입니다!

1. 클라우드 플랫폼의 선택

이 시리즈를 시작하게 된 목적은 아래와 같습니다.

1. 구글 클라우드 플랫폼을 사용, 플랫폼의 장점 익히기

2. 자기 컴퓨터가 아닌, 서버를 빌려 서비스 만들기

3. 서버에 자신이 만든 코드 올리기 & 수정하기

4. Load balancer를 이용하여 요청 분산시키기

간단한 웹 크롤링과 같이 지속적이지 않고, 리소스를 많이 필요로 하지 않는 코드들은

가급적 본인 컴퓨터로 실행시키는 것이 효율적입니다.

하지만 항시 특정 작업을 기다리거나 목적물을 Watching해야 하는 기능들을 사용하려면 어떻게 해야 할까요?

이때 아래의 클라우드 플랫폼을 이용하는 것이 편리합니다.

> Google - GCP (Google Cloud Platform)

> Amazon - AWS (Amazon Web Service)

> Microsoft - AZURE

클라우드 플랫폼 사용의 장점과 단점은 다음과 같아요.

이중에서도 구글 클라우드를 선택한 이유는,

사용할 Database인 Firebase / PostgreSQL 과의 연동성이 뛰어났고

플랫폼을 사용 할 당시 외주를 진행하고 있었기 때문입니다.

또, 서버 안정성에 대한 책임을 구글에 떠넘길 수 있어서

귀책사유로부터 자유롭다는 것도 매력적인 포인트가 있었죠.

구글 클라우드 플랫폼에서 서버를 만드는 방법은 크게 2가지가 있습니다.

▶ Virtual Machine을 생성하여 서버 만들기

▶App Engine을 이용하여 서버 만들기

이 둘중 어떤 것을 선택하여 만들까요?

라고 고민한다면 아래의 특징을 참고합시다.

저는 수정과 배포를 많이 해야 했고,

PostgreSQL을 내부통신만 허용하여

외부에서 아예 접근을 못하도록 하는 구조를 설계했습니다.

내부통신만 하는 이유는,

보안상으로 가장 강건하고 구조가 깔끔하기 때문이에요.

2. Compute engine에서 Virtual Machine 생성하기

먼저, 구글 클라우드 플랫폼 콘솔을 열게 되면,

아래와 같이 프로젝트 정보가 나옵니다.

여기에서 왼쪽의 햄버거 버튼을 눌러 Compute engine으로 갑시다.

만약 API 액세스를 기본 액세스만 허용해 둔다면,

나중에 PostgreSQL이나 Firebase를 사용함에 있어서 예기치 못한 에러들을 만날 수 있습니다.

구글의 Database를 연동하더라도 기본적으로는 통신으로 액세스 하는 것이므로

API 자체가 막혀있다면 연결하여 사용할 수 없습니다!!

이와 비슷한 맥락으로, Virtual machine을 최종적으로 외부 IP와 연결하게 될 것인데,

http, https 트래픽을 열어놓지 않는다면

터미널 이외에서는 접근하지 못하는 상황이 발생할 수 있으므로

반드시 방화벽 메뉴에서 트래픽 허용을 체크해 둡시다.

만약 본인이 VPC를 임의로 생성하였고, 그것을 내부적으로 연결하고 싶다면,

네트워킹 메뉴에서 해당 VPC를 선택하여 연결을 해 주어야 합니다.

하지만 이번 시리즈에서는 따로 VPC를 만들 계획이 없으므로 그냥 default로 놔두면 됩니다.

여기까지 완료했다면, Virtual machine의 기본적인 생성이 끝났습니다!

다음 포스팅에서 뵐게요 :)