๐Ÿ›ณ BE TIL Day 36 0502

JBยท2022๋…„ 5์›” 3์ผ
0

Backend02 Deploy

๋ชฉ๋ก ๋ณด๊ธฐ
2/5

โฌ‡๏ธ Main Note
https://docs.google.com/document/d/1xdJ0VVUDoXyaPY7ESq9DKnIpd8KiC2qjgZYxuffCaUU/edit


๐Ÿ‹ Google cloud SQL

4 vCPU, 265GB, 100GB => Recommended default settings
High Availability : ๊ณ ๊ฐ€์šฉ์„ฑ
โžค Two computers are operating. If one caught error, turn on the other computer so that the server doesn't stop

๐Ÿ”น Create Instance

Instance ID: my-database02
Password: root
Database version: MySQL 8.0
์˜์—ญ ๊ฐ€์šฉ์„ฑ: ๋‹จ์ผ ์˜์—ญ (์‹ค์ œ production์—์„œ๋Š” ์—ฌ๋Ÿฌ ์˜์—ญ์œผ๋กœ ํ•˜๊ธฐ)
โ†’ ์—ฌ๋Ÿฌ ์˜์—ญ์ด์€ ๋‹ค๋ฅธ ๋‘ ์ง€์—ญ์œผ๋กœ ์„ค์ •ํ•ด์•ผํ•จ (ํ•œ ์ง€์—ญ์— ์ง€์ง„๋‚˜๋ฉด ๋‹ค๋ฅธ ์ง€์—ญ์ปดํ“จํ„ฐ๋ฅผ ๋Œ๋ ค์•ผํ•จ)
Machine method: Standard 1 vCPU or 1 shared core
โ†’ (ํ•˜๋‚˜์˜ ์ปดํ“จํ„ฐ๋กœ ๋ฉ”๋ชจ๋ฆฌ๋ฅผ ์กฐ๊ธˆ์”ฉ ์—ฌ๋Ÿฌ๋ช…์ด ๋‚˜๋ˆ  ๊ฐ–๋Š” ๊ฒƒ)
์ €์žฅ์šฉ๋Ÿ‰ : 20GB
์ €์žฅ์šฉ๋Ÿ‰ ์ž๋™ ์ฆ๊ฐ€ ์‚ฌ์šฉ ์„ค์ • (๋‚˜์ค‘์— ์ค„์ผ ์ˆ˜ ์—†์Œ) ๋””์Šคํฌ๋ฅผ ๋Š˜๋ฆฐ๋‹ค๋Š”๊ฑด ํ•˜๋‚˜์”ฉ ๋” ์—ฐ๊ฒฐ์‹œํ‚จ๋‹ค๋Š”๊ฑฐ์ž„
โ†’ (์ž‘์€๊ฒƒ๋“ค์„ ๋Š˜๋ ค๋‚˜๊ฐ€๋Š” ํ˜•์‹)

๐Ÿ‹ Serverless Architecture

  • Serverless architecture is constructed with Cloud Function.
  • Frontend server is running without backend server, and API is operated with Cloud Function.
    โžค Relatively APIs that aren't really important are no need to open up a new server. So request is sent to Cloud Function and the source code inside the cloud function is being executed.
    โžค Backend can access to database, but the cloud function can also access to the database

๐Ÿ”น microservice

Let's suppose that our service became a microservice.
โžค Every single APIs are set to single services, and what kind of error occurs, the other APIs work normally and what we only have to do is fix that problometic API function and re-deploy.

Advantage
When user accesses to the server and requests an API, the computer turns on and inside that computer, the function is executed.
โžค Conservation of money (GCP ๋น„์šฉ ์ ˆ์•ฝ)
โžค The computer isn't on 24/7, but it's only on when the user requests for an API. After the API is used, computer is automatically shut down.

Disadvantage
There exists a delay time for the computer to turn on and execute the function.
โžค So when the user requests for the first time after the computer is off, it takes a long time for that person.
Cold start : The computer starts with off state.
For 4 to 5 seconds, the computer is live after it starts operating.
When the user sends during that time, that's warm start to that person.

โžค Cold Start to Wram Start
: Request once a 4 sec

  • Disadvantage: There's no big difference of cost as operating the computer for 24/7.
  • Advantage: Can have precisely distributed microservice

๐Ÿ‹ Database Connection

-------- New database should be made --------
Database access address: IP Address(from SQL)
1. SQL โ†’ database โ†’ create database โ†’ name: myserver02 
2. SQL Connection ๋“ค์–ด๊ฐ€์„œ 0.0.0.0/0 network ์ถ”๊ฐ€ํ•˜๊ธฐ
3. Go to DBeaver
์ƒˆ๋กœ MySQL ์—ฐ๊ฒฐํ•ด์„œ server์ฃผ์†Œ๋ฅผ ์ž…๋ ฅํ•ด์ฃผ๋Š”๋ฐ ์ด๋•Œ ์ฃผ์†Œ๋Š” 
SQL Overview โ†’ connection test โ†’ IP Address 
โ†’ If private IP Address, ์™ธ๋ถ€์— ์ ‘์† ๋ถˆ๊ฐ€๋Šฅ (๋‚ด๋ถ€๋งŒ ์ ‘์† ๊ฐ€๋Šฅ)
โ†’ If Public IP Address, ์™ธ๋ถ€์— ์ ‘์† ๊ฐ€๋Šฅ

// docker.compose.prod.yaml --> prod doesn't need my-database docker anymore.
// โžค app.module --> host and database should be changed

๐Ÿ”น Public IP vs. Private IP

If the IP is set as public, it has high possibility of being hacked.
โžค So the database should be in private mode.
SQL Connection โ†’ Private IP , Network: default(VPC)

VPC : Virtual Private Cloud (๋‚ด๋ถ€ ์•„์ดํ”ผ ์‚ฌ์šฉ)
โžค VPC ์•ˆ์— ์—ฌ๋Ÿฌ ์ปดํ“จํ„ฐ๋“ค์ด ์žˆ๋Š”๋ฐ ๊ทธ ์ปดํ“จํ„ฐ๋“ค์ด ์‚ฌ์šฉํ•˜๋Š” IP๋Š” ๋‚ด๋ถ€IP์ž„
โžค ์ด ์ปดํ“จํ„ฐ๋“ค์€ ๊ฐ๊ฐ์˜ ๋ฐฉํ™”๋ฒฝ์„ ๊ฐ€์ง€๊ณ  ์žˆ์Œ
๊ทผ๋ฐ ๋‚ด๋ถ€์—์„œ ๋‚ด๋ถ€๋กœ ์ ‘์†ํ•˜๋Š”๊ฑด ์ผ๋ฐ˜์ ์œผ๋กœ ํ’€์–ด์ ธ์žˆ์Œ (๊ทธ๋ž˜์„œ ๋ชจ๋‘๊ฐ€ ์‰ฝ๊ฒŒ ํ†ต์‹  ๊ฐ€๋Šฅ)
์™ธ๋ถ€์—์„œ ๋“ค์–ด์˜ค๋Š” ์ ‘์†์€ ๋ง‰๊ณ  ์žˆ๋Š”๊ฑฐ์ž„ (์•ˆ์ „์„ ์œ„ํ•ด)

๊ทธ๋ž˜์„œ ๋”์ด์ƒ ์™ธ๋ถ€์—์„œ ์ด ๋‚ด๋ถ€ ์•„์ดํ”ผ๋กœ ์ ‘์†์„ ํ•  ์ˆ˜ ์—†๊ฒŒ ๋จ
๊ธฐ๋ณธ์ ์œผ๋กœ ๋งŒ๋“ค์–ด์ง€๋Š” VPC : default VPC (์ด ๊ฐ™์€ default VPC๋ฅผ ์„ค์ •์ด ๋˜์–ด์žˆ๋Š” ์ปดํ“จํ„ฐ์— ํ•œ์—์„œ๋Š” ์„œ๋กœ์„œ๋กœ ๋ฐฉํ™”๋ฒฝ ์—†์ด ์ ‘๊ทผ์ด ๊ฐ€๋Šฅํ•จ) ์ด๋•Œ ์‚ฌ์šฉ๋˜๋Š” IP๊ฐ€ ๋‚ด๋ถ€ ์•„์ดํ”ผ
๋ฐ–์—์„œ ๋“ค์–ด์˜ฌ๋•Œ ์“ฐ๋Š” IP๊ฐ€ ์™ธ๋ถ€ ์•„์ดํ”ผ (๊ณต๊ฐœIP)

๊ทธ๋ž˜์„œ ์ด์   VPC์•ˆ์— ์žˆ๋Š” ์ปดํ“จํ„ฐ๋ฐ–์— DB์— ์ ‘์†์„ ๋ชปํ•จ (๊ฐ™์€ VPC ์† ๋ฐฑ์—”๋“œ๊ฐ€ ์ ‘์† ํ•  ์ˆ˜ ์žˆ๋‹ค๋Š”๊ฒƒ)
๊ทผ๋ฐ ์ด์   ์šฐ๋ฆฌ๊ฐ€ DBeaver๋กœ ์ ‘์†์„ ๋ชปํ•จ (VPCํ•ด์„œ ๋“ฑ๋กํ•œ ๊ฐ™์€ ๋ฐฑ์—”๋“œ ์ปดํ“จํ„ฐ๋Š” DB์— ์ ‘์† ๊ฐ€๋Šฅ)

Compute Engine - VM Instance ๋“ค์–ด๊ฐ€์„œ Network ๋ณด๋ฉด default VPC๋กœ ๋˜์–ด์žˆ์Œ
(default๋ผ๋Š” ์ด๋ฆ„์˜ VPC์ž„)
๊ทธ๋ž˜์„œ ์ •๋ฆฌ๋ฅผ ํ•˜์ž๋ฉด ์šฐ๋ฆฌ backend๋Š” default VPC, ๊ทธ๋ฆฌ๊ณ  SQL๋กœ ๋งŒ๋“  database๋Š” ๋‹ค๋ฅธ VPC์— ์†ํ•ด ์žˆ์Œ
์„œ๋กœ VPC๊ฐ€ ๋‹ค๋ฅด๋ฉด ๋‚ด๋ถ€์•„์ดํ”ผ๋กœ ์—ฐ๊ฒฐ์ด ์•ˆ๋จ! ๊ทธ๋ž˜์„œ ๋‘๊ฐœ๋ฅผ ํ•˜๋‚˜๋กœ ํ•ฉ์ณ์•ผํ•จ
โžค VPC-peering
Default VPC์•ˆ์œผ๋กœ ์ด database๊ฐ€ ๋“ค์–ด์˜ค๊ฒŒ ๋จ
๊ทธ๋ž˜์„œ backend์™€ database๊ฐ€ ์—ฐ๊ฒฐ๋จ (์ด๊ฑด ์ž๋™์œผ๋กœ ํด๋ฆญ ํ•œ๋ฐฉ์— ์ง„ํ–‰๋˜๋Š” ๊ณผ์ •์ž„)
โžค so now on, able to connect with inner IP. (๊ทธ๋ฆฌ๊ณ  ๋‹ค๋ฅธ ํฌํŠธ๋Š” ๋ง‰ํ˜€์žˆ๊ณ  3000๋ฒˆ ํฌํŠธ๋งŒ ์ ‘์† ๊ฐ€๋Šฅ)


๐Ÿ‹ Load Balancer

https: secured server
To secure the server, there should be an authentication about the server.
And that authentication is set inside load balancer.

Main purpose of load balancer is literally load balancing the request that is sent to itself. (์š”์ฒญ ๋ถ„๋ฐฐ)
โžค There exists diverse kinds of algorithms for load balancing: round-robin, least connection, etc...
Round-Robin : 1 goes to A, 2 goes to B, 3 goes to C, 4 goes to A, 5 goes to B, 6 goes to C, 7 goes to A...
Least Connection : Users are sent to the least-traffic server.

According to load balancer,
โžค Frontend : Incoming request
โžค Backend : outgoing respond

reverse-proxy = load balancer receiving the request instead
Http, https can be manipulated in the middle of the process
So instance group should be created on the base of instance template.


๐Ÿ‹ Health Checker

Health checker is attached to load balancer.
โžค Health checker literally checks the status of computers inside the instance group. So if there is an unhealth computer or a dead computer, the health checker tells the load balancer not to load balance to that computer.

How health checking works
When the health checker sends requests to the computers, those computers who responded are normal.
If the request is sent multiple times but there aren't any responses, then that computer is considered dead.

profile
๋‘๋น„๋‘๋ฐฅ๋ฐฅ

0๊ฐœ์˜ ๋Œ“๊ธ€