1. 계정 생성

GCP에서 무료 크레딧을 주는 것과 유사하게 AWS에서는 프리티어가 있다. 1년간, 속도나 용량을 프리티어 기준에만 맞추면 계속 사용할 수 있다.

줄어드는 크레딧보고 조마조마하는 GCP보다 AWS가 사이드 프로젝트 용으로 합리적인 듯?

2. 지역 변경

우측 상단을 보면 지역을 변경할 수 있다.

처음에는 미국 오하이오로 설정이 되어있었는데, 굳이 미국 오하이오 컴퓨터를 빌려서 배포 할 이유가 없으니 서울로 변경.

3. 인스턴스 생성 (EC2)

좌측 상단 서비스 메뉴를 눌러서 EC2 탭으로 들어간다. GCP와 유사하게 인스턴스를 생성할 수 있다.

배포 할 컴퓨터를 한대 빌리는 것으로 생각하면 된다.

1) 인스턴스 시작

2) AMI (인스턴스의 소프트웨어 세팅)

이름을 정해주고, 어떤 운영체제를 사용할지 정한다. 익숙한 Ubuntu로 진행.

다만 하단의 이 부분은 프리 티어가 사용 가능한 것으로 골라야 한다.

인스턴스 유형도 프리티어 사용 가능한 것으로 설정.

3) 키페어 (인스턴스에 접근할 수 있는 권한을 가지는 파일)

키페어가 있어야만 인스턴스에 접속이 가능하다. 우리는 키페어가 없으니 일단 생성.

이름을 정해주고, RSA + .PEM파일 형식 그대로 생성 이 형식이 터미널에서 접속하기 편하더라.

키페어는 Desktop이나 찾기 좋은 위치에 두는게 좋다. 코드가 들어있는 폴더에는 두지 않는 것이 좋다. 혹시 Git에 올라가면 난리가 나기 때문.

4) 기타 설정

위 세팅은 손댈 것이 없다. 그대로 생성.

4. EC2 접속

시작을 누르면 이렇게 생성이 되어있다.

이 부분이 접속 가능한 도메인이 된다.

1) 연결

우측 상단에 연결을 누른다.

위와 같은 창이 뜨는데, 우리가 만든 키파일은 SSH 클라이언트 방식으로 접속이 가능하다.

** 이하는 맥북 기준

터미널을 열어서 위 부분을 붙여넣기 하면된다.

이런 에러가 뜬다면?

키파일이 있는 위치에 가서 다시 실행해야 한다. 이래서 키파일 위치가 중요하다.

위와 같이 뜬다면 잘 접속이 된 것.

5. Docker 설치 및 명령어

우선 배포 컴퓨터에 접속을 했는데, 아무것도 설치가 되어 있지 않다. 우리는 도커로 배포 예정이니, 설치를 진행한다.

sudo apt update : 패키지 업데이트

sudo apt install docker: 도커 설치 docker --version: 도커 버전 확인하여 설치 여부 체크 sudo usermod -aG docker ${USER}: 해당 명령어 사용하여 docker 사용 시 sudo없이 가능하도록 설정

sudo apt install git: git clone을 위해 git도 설치 git clone ~~~ : 배포 할 코드를 git clone을 통해 인스턴스에 설치

git clone 받은 파일로 들어가서 docker compose build + docker compose up 실행

이러면 아마 높은 확률로 에러가 뜬다. 내 경우에는 git ignore된 .env파일이 clone되지 않았기 때문이다.

바로 env파일 생성하기.

vi .env.docker : vi는 해당 폴더에 파일을 생성하거나 접근할 수 있다. i i를 누르면 insert로 모드가 변경되어 추가나 변경이 가능하다. 내 env파일을 복사 붙여넣기한 후 esc로 나간 후, :wq 를 통해 저장후 종료.

다시 docker compose up을 실행 ! 서버가 켜지는데 성공했다. swagger 페이지로 확인.

사실 아직 빼먹은 것이 있다. DB연결을 안했다.

AWS RDS서비스로 DB도 연결할 수 있는데, 너무 길어져서 그건 다음 게시글로 넘겨야겠다.

PIPE란? 클라이언트에서 요청을 보낼 때, 메소드 호출 직전에 올바른 요청인지 아닌지 걸러주는 단계

사용법 3가지

• Handler @UsePipes()를 사용하여 이하의 모든 파라미터에 적용시키기

• Parameter ParameterPipe는 파라미터 안에 들어가서 해당 파라미터에만 적용

• Gloabal main.ts에 app.useGlobalPipes(GlobalPipes)를 삽입하여 모든 서비스에 적용가능

사용예시 

** pipe.ts
import { ArgumentMetadata, PipeTransform } from "@nestjs/common";

export class BoardStatusValidationPipe implements PipeTransform {
  transform(value: any, metadata: ArgumentMetadata) {
    return value;
  }
}


** controller.ts
 @Patch("/:id/status")
  updateBoardStatus(
    @Param("id") id: string,
    @Body("status", BoardStatusValidationPipe) status: BoardStatus
  ) {
    return this.updateBoardStatus(id, status);
  }
}

1. Nest.js 설치

npm install -g @nestjs/cli

||

yarn add @nestjs/cli

2. 프로젝트 생성

nest new 프로젝트명 (생성을 원하는 위치에서)

• Main.ts : 프로젝트의 시작점

3. 기본 처리 로직

1. 브라우저의 요청 (REQ), ex) localhost:3000
2. Controller에서 해당 앤드포인트를 받아서 Services에서 로직 실행 
3. Service에서 해당 로직 리턴값을 다시 Controller로
4. 브라우저에 반응 (RES)

4. Controller

** 들어오는 요청을 받아서 Service로 보내고 Service에서 받은 값을 반환한다.
REQ, RES 담당자로 보면 된다.
@Controller로 정의하여 사용

5. Service

** 비즈니스 로직을 작성하는 곳
@Injectable 을 통해 다른 곳에서도 사용 가능하게 함

start.spring.io 에서 프로젝트를 생성할 때, 필요한 라이브러리를 간편하게 불러올 수 있다.

내가 지금까지 이해한 바로는, node에서 라이브러리를 yarn add + import를 편리하게 하는 것과 같은 것으로 보인다.

흥미로운 사실은, 프로젝트 생성 시 내가 지정한 라이브러리에 의존관계 있는 라이브러리가 알아서 추가된다는 점이다. 아직 각 라이브러리가 뭔지 모르겠는데 일단 엄청 많다.

알아둘만한 라이브러리

spring-boot-starter

• tomcat : 톰캣, 스프링 서버
• webMVC : 기본 MVC 패턴 형태

MVC란? Model + View + Controller 로 프로젝트 구성 시 용도에 맞게 나눔

• spring-boot-starter-thymeleaf : html로 보여주는 라이브러리
• spring-core : 기본 필수 라이브러리
• spring-boot-starter-logging 의 logback + slf4j : 로그 관련 표준 라이브러리

spring-boot-starter-test (코트 테스트 관련)

• junit : 테스트 프레임 워크
• mockito
• assertj
• spring-test : 테스트 지원

2016년 1월 1일은 금요일입니다.
2016년 `a`월 `b`일은 무슨 요일일까요?

두 수 `a` ,`b`를 입력받아 2016년 `a`월 `b`일이 무슨 요일인지 리턴하는 함수, solution을 완성하세요.

요일의 이름은 일요일부터 토요일까지 각각 SUN,MON,TUE,WED,THU,FRI,SAT 입니다. 
예를 들어 a=5, b=24라면 5월 24일은 화요일이므로 문자열 "TUE"를 반환하세요.

2016년은 윤년입니다.
2016년 a월 b일은 실제로 있는 날입니다. (13월 26일이나 2월 45일같은 날짜는 주어지지 않습니다)

풀이

const month = {
    1: 31,
    2: 29,
    3: 31,
    4: 30,
    5: 31,
    6: 30,
    7: 31,
    8: 31,
    9: 30,
    10: 31,
    11: 30,
    12: 31
 } 

  let day = ["FRI", "SAT", "SUN", "MON", "TUE", "WED", "THU"] 
 //Month와 Day를 선언

  function solution(a, b) {
    let answer = 0;
    for (let i = 1; i<a; i++) {
        answer += month [i]}  // 위에 선언한 Month에서 해당 달까지 지난 달을 모두 담는다.
    answer += ( b - 1)         // 마지막 달의 일수 (b)를 더한다. 1일부터 시작하므로 1을 빼야됨
    answer = day[answer % 7] 
    // answer에 1월 1일부터 지난 모든 day의 합이 쌓인다. 7![](https://velog.velcdn.com/images/he_sham/post/cda6df56-e632-41fd-a7b1-fa10cf155d00/image.png)
로 나누어 요일을 구함.
    return answer    
}

문제

한 번만 등장한 문자

문자열 `s`가 매개변수로 주어집니다. 
`s`에서 한 번만 등장하는 문자를 사전 순으로 정렬한 문자열을 return 하도록 
solution 함수를 완성해보세요. 
한 번만 등장하는 문자가 없을 경우 빈 문자열을 return 합니다.

풀이

function solution(s) {

    let answer = ''

    let arr = s.split('').sort() // 문자열을 배열로 바꿔서 알파벳 순으로 정렬

    for(let i = 0; i<arr.length; i++) {
        if(arr[i] != arr[i+1] && arr[i] != arr[i-1]) {
            answer = answer + String(arr[i]) }
      // 앞뒤로 같은 문자가 없을 경우에 answer에 String 변환하여 담기
    }
    return answer
}

흠...

for문 하나썼는데 풀이 시간이 굉장히 길다. 다른 사람의 풀이를 살펴보자

// 처음에 보고 이게 뭔 소리지? 생각이 들었다.
// 이 풀이를 사용하니 3.24ms 걸리던 테스트 1번이 0.08ms로 줄었다.

function solution(s) {

    let res = [];

    for (let c of s) 
    if (s.indexOf(c) === s.lastIndexOf(c)) res.push(c);

      // indexOf는 중복된 값이 있어도 가장 첫 index 번호를 가져온다.
      // lastIndexOf는 중복된 값이 있을 경우 가장 마지막 index 번호를 가져온다.
      // 그러므로 indexOf === lastIndexOf 일 경우는 중복된 값이 없다는 소리

    return res.sort().join('');
      // 중복되지 않은 값만 배열에 담아서 string 변환
}

프로그래머스 다른문제 풀이 최상단을 보면 항상 기상천외한 풀이가 있다. 정답만 통과하는게 아니라 효율적으로 풀도록 노력해야겠다.

문제

외과의사 머쓱이는 응급실에 온 환자의 응급도를 기준으로 진료 순서를 정하려고 합니다. 
정수 배열 `emergency` 가 매개변수로 주어질 때 
응급도가 높은 순서대로 진료 순서를 정한 배열을 return 하도록 solution 함수를 완성해주세요.

풀이

function solution(emergency) {
    let arr = emergency.slice().sort((a,b) => (b-a))  
    //응급 순서로 정렬
    // slice를 하지 않으면 원본이 변경된다.
    // slice()를 사용하면 원본은 별경하지 않고 얕은 복사 가능하다.
    let answer = emergency.map(e => arr.indexOf(e)+1)
    // map으로 arr의 index 값 + 1 을 부여
    return answer
}

문제

1부터 13까지의 수에서, 1은 1, 10, 11, 12, 13 이렇게 총 6번 등장합니다.
정수 i, j, k가 매개변수로 주어질 때, 
i부터 j까지 k가 몇 번 등장하는지 return 하도록 solution 함수를 완성해주세요.

풀이

function solution(i, j, k) {

    let arr = []
    let arr2 = []
    let answer = 0;

    for(let a=i; a<=j; a++) {                //i 와 j 사이의 수를 가져오기
            arr.push(String(a).split('')) // 문자로 변환 + 자릿수별로 쪼개서 가져오기
            arr2 = arr[arr.length-1]      // i와 j 사이의 모든 수는 배열의 마지막 값
              for(let b = 0; b<arr2.length; b++) { 
                                           // k와 같은 숫자 찾아서 answer에 담기
            if(arr2[b] === String(k)) answer ++
            }
    }
    return answer
}

흠..

시간이 너무 많이 걸리는 것 같아서 다른 사람의 풀이를 알아보자

function solution(i, j, k) {
    let a ='';
    for(i; i<=j; i++){a += i}
    return a.split(k).length-1;
}

Transaction 을 정의하는 4가지 속성

• A(Atomicity) : 원자성 → 안전성 보장을 위해 가져야 할 성질 중의 하나로 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력. 모두 성공할 것 아니면 모두 실패하게 만드는 것 (DB의 오염을 막기 위함).
• C(Consistency) : 일관성 → 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것. 똑같은 쿼리를 조회할 때마다 동일한 결과값이 나타나야하는 것. 수정과 삭제로 인해 결과값이 달라지는 것은 당연함.
• I(Isolation) : 격리성 → 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것. 사람의 요청을 처리하는 동안 B사람의 요청은 잠시 기다리는 것
• D(Durability) : 지속성 → 성공적으로 수행된 트랜잭션에 대한 로그가 남아야하는 성질로 런타임 오류나 시스템 오류가 발생하더라도, 해당 기록은 영구적이어야 하는 것. 성공하여 commit이 되었으면 서버를 다시 켜도 그 데이터는 그대로 유지가 되어야 되는 것.

Isolation-level

Transaction의 격리 수준

READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE (*아래 단계로 내려갈수록 안전해지는 반면 성능이 느려짐)

Dirty Read : 트랜잭션이 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있게 되는 현상 NON REPEATABLE READ : 동일한 결과값이 나타나지 않을 때 나타나는 현상

• 한 트랜잭션 내에서 같은 쿼리를 두번 수행할 때, 그 사이에 다른 트랜잭션이 값을 수정 또는 삭제함으로써 두 쿼리가 상이하게 나타나는 현상 => 동일한 쿼리를 요청하면 매번 동일한 결과값이 나타나야 함.

1단계 : READ UNCOMMITTED

각 트랜잭션에서의 변경 내용이 COMMIT이나 ROLLBACK 여부에 상관 없이 다른 트랜잭션에서 값을 읽을 수 있음 => commit 되지 않는 데이터들을 조회할 수 있으나, 정합성에 문제가 많은 격리 수준이기 때문에 사용하지 않는 것을 권장!

2단계 : READ COMMITTED

RDB(관계형 데이터베이스)에서 대부분 기본적으로 사용되고 있는 격리 수준 Dirty Read 발생 X 실제 테이블 값을 가져오는 것이 아니라 Undo 영역에 백업된 레코드에서 값을 가져옴

3단계 : REPEATABLE READ

RDB(관계형 데이터베이스)에서 대부분 기본적으로 사용되고 있는 격리 수준

MySQL에서는 트랜잭션마다 트랜잭션 ID를 부여하여 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게됨

Undo 공간에 백업해두고 실제 레코드 값을 변경

백업된 데이터는 불필요하다고 판단하는 시점에 주기적으로 삭제 Undo에 백업된 레코드가 많아지면 MySQL 서버의 처리 성능이 떨어질 수 있음 => 이러한 변경방식은 MVCC(Multi Version Concurrency Control)라고 부름

PHANTOM READ : 종종 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보였다가 하는 현상

4단계 : SERIALIZABLE

async findAll() { const queryRunner = await this.connection.createQueryRunner(); await queryRunner.connect(); await queryRunner.startTransaction('SERIALIZABLE'); try { // 조회시 락을 걸고 조회함으로써, 다른 쿼리에서 조회 못하게 막음(대기시킴) => Select ~ For Update const payment = await queryRunner.manager.find(Payment, { //PHANTOM READ 가 발생하지 않기 위해서 lock을 걸어줌 lock: { mode: 'pessimistic_write' }, }); console.log(payment);

여기서 더 나아가서 dev 브랜치에서 기능별로 feature 브랜치를 빼서 개발하고 기능 개발이 완료되면 dev 브랜치에 합칩니다.

• hotfix 브랜치 hot-fix 브랜치는 말 그래도 긴급하게 에러를 고치기 위해 만드는 브랜치입니다. 이 브랜치는 master 브랜치에서 바로 만들어서 프로덕션에서 생긴 이슈를 고치고 master 브랜치로 합쳐서 배포할 수 있도록 합니다.

• release 브랜치 release 브랜치는 dev 브랜치에서 생성합니다. dev 브랜치에서 feature 브랜치들을 만들어서 기능들을 모두 개발하고 합칩니다. 그 다음에 dev 브랜치에서 release 브랜치를 생성하고, 프로덕션을 출시하기 위해서 필요한 코드들만 덧붙이도록 합니다. 그후 master 브랜치에 합칩니다. 또한 dev 브랜치에서는 release 브랜치를 합쳐서 최신 버전으로 유지합니다.

• Git Fork Workflow - Forking Repository 위의 브랜치를 이용한 과정들은 한 개의 저장소에서 이루어지는 것입니다. Git Fork Workflow는 저장소를 fork(복제) 해서 협업하는 작업 과정을 말합니다.

29세의 (만나이) 8주 부트캠프 회고

1. 올해 8월 회사를 관뒀다. 여러가지 이유가 있지만, 적성에 맞지 않는 것 같다는 생각이 있었다. 본인만 열심히하면 무한히 자기 발전이 가능한 개발자가 해보고 싶었다.

   어? 근데 지금와서 생각해보면 열심히 해서 발전안하는 직업이있나?

   
   

2. 쿨하게 사표를 낼때만 해도 나는 내가 똑똑한줄 알았다. 사실 '나는 이과형 머리가 아닐까?' 이런 자신감을 갖고 있었다.

3. 아니더라 베이스캠프가 열리자마자 나는 그냥 문과형머리였다. 아래는 실제로 내가 베이스캠프 1주차때 작성한 if문이다.

   같은 조 동료가 들여쓰기 저딴식으로 하지 말라고 말했는데도 똥고집을 부렸다.

   "제가 보기엔 이게 더 가시성이 좋은데요?"

if
(a>2000)
{return true}

4. 베이스캠프 3주차 js 강의를 듣다가 벽을 느꼈다. 선생님이 우다다다 로직을 세우는데 이해가 하나도 가지 않았다.

   "지난주 css 도형 옮기기는 재밌었는데.. 프엔할걸 그랬나?" _ - 프론트엔드가 도형만 옮기는 줄 알았던 사람_

5. 오프라인 부트캠프가 개강했다. 전반적인 정규 수업을 듣는 내 느낌은 이랬다.

   1교시 = 사칙연산 2교시 = 사칙연산 3교시 = 사칙연산을 이용하여 자동차 만들기 과제 = 수업시간에 배운것을 바탕으로 로켓발사하기

6. 평생 접하지 않은 내용이 너무 많아서 쉽지가 않았다. 매일 머리 싸매고 과제를 했고, 주변 도움을 받지 않으려고 했으나 아무리 검색해도 혼자 해결하는게 쉽지가 않더라.

   주변 도움을 많이 받았다. 같은 반 사람들은 다 좋은 사람들이었다. 꼭 도와줘서 좋은건 아니고 사람들이 다 순둥순둥했다.

7. 8주간 캠프 생활을 하면서 과제만 겨우겨우 따라가다보니 사실 내가 성장하고 있다는 느낌을 받지 못했다. 수업을 들을때는 다 이해가가는데 막상 내 코드를 치려고 하면 막막했다.

8. 실력이 느는건지 가물가물하던 와중에 놀랍게도 나는 성장하고 있었다. 어느날 알고리즘 테스트에서 무려 4개중 2개를 맞았다.

   반타작하고 호들갑이라고 할 수 있지만, 과거에 들여쓰기도 못하던 내가 문제를 해결하는게 대견했다

   꼭 못하는 애들이 더 유난인 것처럼, 1개맞은사람 0개맞은사람을 놀렸다.

   
   

9. 수업 강의도 계속 돌려보니, 수업시간에 따라치느라 듣지 못했던 내용이 많더라.

   반복해서 완두쌤의 강의를 들으니 로직이 어느정도 이해가 가기 시작했다. 내가 치는 코드가 무슨 의미인지, 어떻게 로직을 짜야하는지 희미하지만 개념이 잡히는 느낌이 들었다. (아직 응용하라고 하면 머릿속 하얘짐)

   
   

10. 8주차를 보내며 내가 만든 사이트도 배포했고, 사실 아무 기능 없는 graphql 사이트지만 가끔씩 yogiya.shop을 들어가서, 내가 낳은 API들을 보면 기분이 좋아진다.

11. 다음주에는 팀프로젝트가 시작된다. 걱정이 많다. 모든 조에 백앤드가 3명씩 들어가 있는데, 우리조에는 나를 포함하여 2명이다. (왜?) 다른 한명도 똑똑이가 아니기 때문에, 큰 고난이 예상된다.

    하지만 기회가 아닐까? 잘하는 사람 등에 업혀서 가는 것보다, 영차영차 머리깨지면서 기어가면 실력이 늘 것이라고 생각하고 있다.

    프론트에서 요청하는 것은 밤을 새서라도 들어줄 심산이다.

아직은 블로그 제목처럼 우당탕탕 굴러가고 있으나, 돌이켜보면 성장하고 있다. 팀프로젝트 잘 끝내고 다시 회고 작성하러 오겠다.

암호기반 프로토콜이며, SSL이 적용된 웹사이트는 URL이 HTTP 에서 HTTPS로 변경이 된다. (추가된 S는 보안의 Secure을 뜻한다.)

SSL 작동원리?

• 기본적으로 웹에서 전송되는 데이터를 자동으로 암호화하여, 해커가 데이터를 가로채더라도 해독이 불가능한 암호를 보도록 만든다.

• 추가로 "핸드셰이크(악수)"라는 기능을 통한 인증프로세스로 두 장치의 ID를 확인한다

핸드셰이크

통신을하는 브라우저와 웹서버 사이에서 암호화 통신을 하도록, 신분을 확인하고 필요한 정보를 주고 받는 과정이다. 흡사 악수와 비슷하여 핸드셰이크라는 이름이 붙게 되었다.

SSL / TLS 사용 이유?

SSL은 TLS의 전신이다. 1999년에 이름이 업데이트 되었으며, 동일한 개념임.

신용카드 정보나, 개인정보가 수없이 오고 가는 웹 사이트 상에서 보안의 필요성은 당연히 대두 되었으며, 해커들이 정보를 빼가도 고객의 정보가 유출되지 않도록 SSL/TLS 암호화를 사용하게 되었다.

HTTP & HTTPS

HTTP의 개념은 아래와 같다

HTTP (Hyper Text Transfer Protocol)

웹 사이트와 서버 사이에서 주고받는 언어(HTML)로 작성된 프로토콜

• 프로토콜 : 인터넷상에서의 통신을 주고받을때 적용되는 규약
• HTML: 웹 사이트의 기본이 되는 언어로, 브라우저를 통해 읽을 수 있음.
• Request를 보낼 때마다 Response를 받는 원리이다.
• 이 이유로 기존의 요청은 기억하지 못하는 stateless 개념이다.
• 위 문제를 해결하기 위해, 세션/DB 등으로 상태를 저장하게 되었다.

위 개념에 S(Secure, 보안)이 추가 된 것으로, 말그대로 SSL인증을 추가한 HTTP이며 더욱 보안이 철저한 프로토콜이라고 볼 수 있다.

개발과 배포를 자동으로 진행해주는 서비스이다.

CI/CD를 정확히 나누면 아래와 같으며, CI = Continuous Integration (통합) CD = Continous Deployment (배포)

CI/CD에 대표적인 서비스는 아래와 같다.

• Jenkins (서비스 규모가 클 경우 사용) ( + 추가라이브 많음)
• GithubActions (서비스 규모가 작을 경우 용이)
• AWS (CodePipeline) - AWS로 통일하고 싶을 경우
• GCP (CloudBuild) - GCP로 통일하고 싶을 경우

GCP - CloudBuild

GCP에서 제공하는 cloud build 서비스 로직은 아래와 같다.

1. Vscode 상에서 cloudbuild.yaml 파일을 만들어서 git에 push!
2. Github에 설정을 해두고, 자동으로 GCP로 넘어가도록 설정하기.
3. GCP 컴퓨터 안에서 소스코드 실행 및 docker build, push 등등
4. 구글 레지스토리에 이미지 자동 업데이트 + 자동 업데이트 배포

서버리스는 말 그대로 서버가 없다는 뜻이다. Cloud를 통해 API 단위로 배포를 진행한다.

서버리스를 왜 쓰나요?

실제로 서버를 구입하면 24시간동안 서버가 돌아가므로, 비용이 발생한다.

하지만 서버리스 서비스는 함수가 실행될때만 비용이 부과되고, 초기 비용이 적으므로 비용 절감에 큰 효과가 있다.

아니 그렇게 좋은데 왜 안쓰나요?

서버리스 서비스에는 고질적인 문제가 있는데, Cold Start라는 문제이다. 서버리스는 요청이 들어올때만 서버가 돌아가기 때문에, 컴퓨터를 구동하는데 약 5초정도의 시간이 걸린다. 서버에 지속적으로 요청하지 않으면, 다시 서버가 off 되므로 이용하는 사용자들은 계속 Cold Start를 통한 지연을 겪게된다.

불이 번지지 않도록 내리는 벽이기도하고 PC에 바이러스가 들어오지 않도록 방화벽을 설정하기도 했다.

방화벽은 정확히 무엇일까?

위키에서의 정의는 아래와 같다.

방화벽은 미리 정의된 보안 규칙에 기반한, 들어오고 나가는 네트워크 트래픽을 모니터링하고 제어하는 네트워크 보안 시스템이다. 방화벽은 일반적으로 신뢰할 수 있는 내부 네트워크, 신뢰할 수 없는 외부 네트워크(예: 인터넷) 간의 장벽을 구성한다.

다른 네트워크에서, 신뢰가 가지않는 네트워크에서 오는 접근을 차단하는 역할을 한다.

말만 들어보면 방화벽은 항상 유지하는게 좋아보이지만, 배포시에 방화벽이 설정되어 있으면 내 사이트에 접근이 차단되므로 해제하는 작업도 필요하다.

GCP로 배포를 진행하고 방화벽을 해재하고 내가 열어둔 3000번 포트를 연결하여 주었다.

VPC

Virtual Private Cloud 의 약자.

가상의 네트워크 클라우드를 사용한다는 소리이다.

GCP에서 아래와 같이 설정하여 docker를 올려보았다.

0.0.0.0/0은 모든 IP를 허용한다는 뜻

그 뒤 GCP-SQL에서 IP를 얻은 뒤,

app.module의 호스트에 연결해주고 다시 배포를 진행하면 DB로도 접근이 가능하였다.

위키에는 아래와 같이 TDD를 정의하고 있다.

테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다.

말만 들으면 테스트코드를 짜놓고 코드를 짜맞추는거 같아서 이상하게 들릴 수 있으나,

현실적으로 개발을 하다보면 시간이 부족하여 테스트를 미처 끝내지 못하고 배포하는 경우가 많다고한다.

이에 테스트 코드를 미리 짜놓고 개발하는 것이 현실적으로 안전하다고도 볼 수 있다.

TDD의 장단점

장점

• 테스트 코드를 짜다보면 설계를 구체적으로 할 수 있다.
• 배포 전 오류 검사가 용이하며, 디버깅 시간을 단축시킨다.
• 코드를 읽을 때, 테스트 코드에는 모든 기능이 모여있어,

   해당 코드를 읽고 서비스를 쉽게 이해할 수 있다.

단점

• 테스트 코드 작성에 너무 많은 시간을 소모할 수 있다.
• 서비스 개발 전에 테스트 코드를 짜기 때문에, 테스트 코드가 완벽하지 않을 수 있다.

회사를 들어가면 내규에 맞게 개발을 따라가게 될 것이지만, 개인적으로는 서비스의 구체성이 자주 변하는 스타트업의 경우에는 TDD개발이 부적합하다고 느껴진다.

정규표현식은 기본적으로 / / 안에 작성한다.

• \w : 모든 문자를 1개를 칭한다.

• 2개가 하고싶다면? \w{2}
• 1개 이상이 하고 싶다면? \w+
• 0개 이상이 하고 싶다면? \w*

이메일 양식을 정규 표현식으로 표현한다면?

/\w+@\w+.\w+/ 하지만 위와 같이 작성하면 온점(.) 자리에 콤마(,)가 들어와도 true를 반환한다. 왜냐? 정규표현식에서 온점(.)은 "모든 것"을 의미한다.

*/\w+@\w+.\w+/ * 위와 같이 작성하면 온점 본연의 성질을 잃어버리고 text로 변경됨.

숫자의 경우 아래와 같이 표현한다.

\d : 모든 숫자 1개 \d{3} : 모든 숫자 3개 \d{3,4) : 모든 숫자 3개 혹은 4개

위를 이용하여 핸드폰 번호를 표현한다면?

/^\d{3}-\d{3,4}-\d{4}$/

정규 표현식은 시작(^)과 끝($)을 표현해줘야 초과된 값을 제외하여 true를 반환한다.

이미지 업로드

이미지를 웹에 업로드하는 기본적인 로직은 아래와 같다.

1. 브라우저에서 사용자가 업로드할 이미지 파일을 선택합니다.
2. 브라우저에서 선택된 파일을 변수에 저장합니다. 변수에 담긴 내용을 파일 객체라고 하며 파일 사이즈 등 파일에 대한 정보를 담고 있습니다.
3. 이제 브라우저에서는 파일 객체를 백엔드 서버에 업로드 요청을 합니다. 이를 위해 백엔드 서버에서는 파일 업로드를 하는 API를 제작 및 구현 해놓아야 한다.
4. 백엔드 서버에서는 API를 통해 받은 파일을 DB에 저장 시 BLOB타입으로 저장

구현한 코드는 아래와 같다.

**Service
@Injectable()
export class FilesService {
  async upload({ files }: IFilesServiceUpload): Promise<string[]> {
    const waitedFiles = await Promise.all(files);

    // 1. 파일을 클라우드 스토리지에 저장하는 로직

    // 1-1) 스토리지 셋팅하기
    const bucket = 'yoyoyo';
    const storage = new Storage({
      projectId: 'polar-scene-370203',
      keyFilename: 'gcp-file-storage.json',
    }).bucket(bucket);

    // 1-2) 스토리지에 파일 올리기
    const results = await Promise.all(
      waitedFiles.map(
        (el) =>
          new Promise<string>((resolve, reject) => {
            const fname = `${getToday()}/${uuidv4}/origin/${el.filename}`;

            el.createReadStream()
              .pipe(storage.file(el.filename).createWriteStream())
              .on('finish', () => resolve(`${bucket}/${fname}`))
              .on('error', () => reject('실패'));
          }),
      ),
    );

    // 2. 다운로드URL 브라우저에 돌려주기
    return results;
  }
}

콘솔로 받아오는 값을 찍어서 지정된 규칙대로 GCP 상에 저장하였다.

브라우저에서는 보안을 이유로 cross-origin HTTP 요청을 제한한다. 그래서 HTTP- HTTPS 사이에서 cross-origin 요청을 하려면 서버의 동의가 필요하다. 만약 서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절합니다. 이 매커니즘을 CORS 라고 부른다.

CORS 동작 원리

다른 출처의 리소스를 요청할 때 HTTP 프로토콜을 사용하여 요청을 보내게 되는데, 이때 브라우저는 요청헤더에 Origin이라는 필드에 요청을 보내는 출처를 함께 담아서 보낸다.

하지만 동작 원리를 조금 더 깊게 들어가면 CORS 요청은 다음과 같이 세 가지 유형으로 나눠서 생각해볼 수 있다.

Simple Request MDN에서 "단순요청"은 아래와 같이 정의한다.

단순요청은 예비 요청(Prefilght)을 보내지 않고 바로 서버에 본 요청을 한 후, 서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin과 같은 같을 보내주면 브라우저가 CORS정책 위반여부를 검사하는 방식이다.

단순요청은 아래의 조건을 만족해야 된다.

• 요청의 메소드는 GET, HEAD, POST 중 하나여야 한다.

• 유저 에이전트가 자동으로 설정한 헤더외에, 수동으로 설정할 수 있는 헤더는 Fetch 명세에서 "CORS-safelisted request-header"로 정의한 헤더만 사용할 수 있다.

위와 같은 조건을 만족하는 단순 요청은 안전한 요청으로 취급되며, 프리플라이트 요청이 필요 없이 단 한 번의 요청만을 전송한다.

Prefilght Request

프리플라이트 요청의 특징은 다음과 같다.

• 메소드로 OPTIONS를 사용한다.

• Origin 헤더에 자신의 Origin을 설정한다.
• Access-Control-Request-Method 헤더에 실제 요청에 사용할 메소드를 설정한다.
• Access-Control-Request-Headers 헤더에 실제 요청에 사용할 헤더들을 설정한다.

서버는 이러한 프리플라이트 요청에 대해 다음과 같은 특징을 가진 응답을 제공해야 한다.

• Access-Control-Allow-Origin 헤더에 허용되는 Origin들의 목록 혹은 와일드카드(*)를 설정한다.

• Access-Control-Allow-Methods 헤더에 허용되는 메소드들의 목록 혹은 와일드카드(*)를 설정한다.
• Access-Control-Allow-Headers 헤더에 허용되는 헤더들의 목록 혹은 와일드카드(*)를 설정한다.
• Access-Control-Max-Age 헤더에 해당 프리플라이트 요청이 브라우저에 캐시 될 수 있는 시간을 초 단위로 설정한다.

이러한 응답을 받고 나면 브라우저는 이 응답의 정보를 자신이 전송한 요청의 정보와 비교하여 실제 요청의 안전성을 검사한다. 만약 이 안전성 검사에 통과하게 된다면, 그때서야 실제 요청을 서버에게 보낸다.

스키마란

데이터베이스 어떻게 설계할지에 대한 계획 구조와 제약 조건을 정하는 것이다.

DB 스키마

당연히 DB 스키마는 데이터베이스에서 자료의 구조, 자료의 표현 방법, 자료 간의 관계를 형식 언어로 정의한 구조이다.

스키마는 기본적으로 3가지의 종류로 나뉘는데, 아래와 같다.

• 외부 스키마(External Schema) : 프로그래머나 사용자의 입장에서 데이터베이스의 모습으로 조직의 일부분을 정의한 것

• 개념 스키마(Conceptual Schema) : 모든 응용 시스템과 사용자들이 필요로하는 데이터를 통합한 조직 전체의 데이터베이스 구조를 논리적으로 정의한 것

• 내부 스키마(Internal Schema) : 전체 데이터베이스의 물리적 저장 형태를 기술하는 것

ERD

테이블간의 관계를 설명해주는 다이어그램이다. 이를 통해 프로젝트에서 사용되는 DB 의 구조를 한눈에 파악할 수 있으며, API를 효율적으로 작성하기 위한 그림이므로, 프로젝트 작업시, 선행적으로 작성해야 하는 부분이다.

아래와 같이 각 그룹들을 연결하여 관계를 표현한다. 내가 첫 프로젝트로 작성한 ERD 예시는 아래와 같다.