서비스를 배포할 때 데이터베이스는 AWS RDS 서비스를 사용하여 배포중인데 스테이지 DB와 같이 값을 확인할 필요가 있는 예외적인 경우, 테스트 시점에서 데이터 베이스 내부에 접근하여 테이블에 원하는 값이 정상적으로 들어갔는지 확인할 필요가 있다. 문제는 AWS RDS 세팅 시, 보안 관련된 이슈로 해당 데이터 베이스 주소의 외부 접근을 ec2 인스턴스를 제외하고는 모두 막아둔 상태이다. 그래서 아래와 같이 로컬 pc의 Datagrip -> AWS EC2 인스턴스 -> AWS RDS 접근과 같은 절차를 통해 접근해야한다. Datagrip에서는 위와 같은 절차로 Amazon RDS에 SSH 터널링을 통해 접근이 가능하다. 1. SSH 설정 EC2 인스턴스에 접근하기 위해 ssh 정보 등록을 해야한다. 데..
데이터베이스(Database)는 구조화된 정보 또는 데이터의 조직화된 모음을 의미한다. 데이터베이스(Database)를 사용하다보면 종종 같은 데이터에 동시에 접근하는 경우가 발생한다. 동시 접근이 발생하는 경우, 예를 들어 선착순 100개의 한정판을 판매하는데 99개가 판매되었고, 잔여 수량이 1 개인데 구매하려는 유저는 20명이면 실제 구매 성공이 되야하는 유저는 1명인데 만약 20명의 유저 전부에게 정상적으로 구매가 진행되었다고 출력된다면 해당 데이터가 오염될 수 있다. 이러한 상황에서 데이터베이스를 관리(제어)하는 DBMS는 데이터의 무결성과 일관성을 지키기위해 Lock을 사용한다. Lock의 정의 Lock은 데이터베이스(Database)에서 트랜잭션(Transaction) 처리의 순차성을 보장하..
기존 인텔 맥에서 작성하던 이력서.io 레포가 jekyll을 사용하는 modern-resume-theme 템플릿을 사용하고 있는데 M1 계열 맥북으로 변경한 후, $ bundle exec jekyll serve를 했을 때 아래처럼 Dependency Error가 발생하였다. 해당 이슈가 ARM 아키텍쳐라 생긴 이슈인 줄 알았는데 github-pages가 의존성을 가지고 있는 faraday라는 HTTP/Rest API 클라이언트의 최신 버전이 github-pages와 호환되지 않아서 Dependency Error가 발생하였다. faraday | RubyGems.org | your community gem host rubygems.org Gemfile에 gem 'faraday', '~> 0' 으로 farad..
회사내에서 프로젝트를 진행할 때는 대부분 NestJS, TypeORM, RestAPI를 기본 스펙으로 잡고 진행하는데 외부에서 진행되던 프로젝트가 NestJS, TypeORM에 Liquibase 라는 처음 접하는 데이터베이스 버전 관리 툴을 사용하였는데 내부로 인수인계가 다 되진 않은 상태에서 local 환경에서 개발하다 $ npm run start:dev를 했는데 정상적인 상황이라면 아래처럼 서버가 실행되어야 정상이다. >>> liquibase update start 뒤에 liquibase가 실행된다는 로그가 남아있는 채로 update end 로그가 뜨지 않고, 3 ~ 4분 뒤에 Caused by: liquibase.exception.LockException: Could not acquire chang..
간혹 API 예외처리를 하다보면 어드민만 사용할 수 있어야하거나, 내 정보의 수정/삭제 같이 권한에 민감한 PATCH, DELETE 메소드 api들에 대한 예외가 발생 시 예외 상황에 맞는 HTTP 상태코드를 전달해야하는데 같은 예외 사항에 대해 가끔 403 Forbidden과 401 Unauthorized를 혼용하는 경우가 있었다. HTTP 401 Unauthorized 401 상태 코드는 해당 클라이언트가 인증되지 않았거나, 유효한 인증 자격 증명이 없기 때문에 요청이 거부되었음을 나타내는 상태이다. 해당 코드는 인증되지 않은 클라이언트가 요청을 전송하였기에 요청의 정상 처리가 불가함을 나타내는 것이다. 대표적으로 내 정보 조회/수정 같이 유저 민감 정보를 핸들링하는 경우와 같이 유저 인증이 필요한 ..
AWS Aurora RDS MySQL에서 AWS MySQL 8.0으로 마이그레이션을 진행 후, save 메소드를 사용하는 api를 호출할 때, TypeORM에서 id 값 관련된 쿼리 error가 발생하였다. TypeORMError: Cannot update entity because entity id is not set in the entity. 해당 에러가 발생하는 부분의 쿼리를 로깅해보면 정상적으로 쿼리가 생성되지만, 타겟 entity의 id가 entity에 세팅되지 않았다는 에러는 발생되므로 ORM이 아닌 DB가 이슈일 가능성이 있었다. INSERT INTO "tableName"("id", "createdAt", "updatedAt", "body") VALUES (DEFAULT, DEFAULT, D..
기존에 faker.js를 사용해서 Seeding용 API 엔드포인트를 구성하였었는데 해당 Faker 모듈이 관리가 안되는 이슈도 있고, request한 유저의 권한을 valid하긴 하지만, 데이터 베이스에 직접적으로 영향을 줄 수 있는 엔드포인트가 외부로 노출되어있는 점이 불안해서 typeorm seeding을 통해 ssh로 직접 서버에 접속해서 커맨드를 날리는 방향으로 변경하였다. Faker.js를 통한 Seed API 작성 백엔드를 개발하다보면 REST API의 GET 메소드에서 DB에서 데이터를 제대로 불러오는지 확인해야하는데 이럴 때 Seed API를 통해 테스트 용도의 fake DB를 구성하는 것이 매번 데이터를 직접 입력해넣 eight20.tistory.com NestJS와 관련된 Seedin..
기존 React Router에서 Route를 지정할 때, 안에 컴포넌트에서 path props으로 url을 지정하고 component props로 랜더링을 원하는 페이지 컴포넌트를 지정하였었다. // Route.tsx 한 페이지 안에 3개의 UX 뎁스로 구성되어있는 UI에서 3번째 뎁스 까지 도달했을 때, Add 혹은 EditPage로 넘어가게 하였다. 2번째 뎁스에서 id값을 props로 넘기는 것을 받아왔을 때, focus가 해당 페이지를 벗어나면 AddPage 혹은 EditPage가 언마운트되었디가 다시 마운트되면서 3번째 뎁스 안의 title, content등의 state가 모두 초기화되어 작성한 내용이 빈칸으로 되는 이슈가 발생하였다. 해당 이슈가 발생한 원인은 한 페이지 안에 여러 개로 뎁스가..
DB를 기존에 사용하던 PostgreSQL에서 MySQL로 변경하고 나서 동일한 Entity의 String 타입으로 지정된 칼럼의 문자열 길이가 공백 포함 255자 이상은 저장되지 않는 이슈가 생겼다. 기존 Entity는 Id, 생성 일시, 마지막 업데이트 일시, 제목, 설명, 썸네일, 링크로 구성되어 있는데 이슈가 발생한 부분은 description 부분이었다. TypeORM의 경우, string 타입으로 칼럼 타입을 지정하면 각 DB의 기본 문자열 저장 타입으로 변환하는데 따로 Character Type을 지정하지 않으면 PostgreSQL은 varchar, MySQL은 varchar(255)이다. // content.entity.ts @Entity() export class Content { @Pr..
리눅스 또는 맥을 사용하다보면 터미널을 쓸 수 밖에 없는데 간혹 Permission denied와 같이 파일 권한 이슈가 있는 경우가 있다. 터미널에서 ls 커맨드에 al 옵션을 붙여서 ls -al을 입력하면 파일명 이외에도 다른 정보들이 나오는 것을 볼 수 있다. 여기서 맨 앞의 drw~ 와 같이 알파벳과 하이픈을 합쳐 총 10자리가 파일 접근 권한을 표기한 것이다. 실질적으로는 d / rwx / r-x / r-x 와 같이 권한의 역할에 따라 4칸으로 구분된다. 첫 번째 칸은 파일의 타입, 두 번째 칸은 user의 권한, 세 번째 칸은 group의 권한, 네 번째 칸은 나머지(others), 게스트의 권한으로 분류된다. 첫 번째 칸의 형식 - 는 파일을 의미한다. d는 디렉토리를 의미한다. l은 다른 ..
개발/AWS 2022. 11. 14. 08:20
서비스를 배포할 때 데이터베이스는 AWS RDS 서비스를 사용하여 배포중인데 스테이지 DB와 같이 값을 확인할 필요가 있는 예외적인 경우, 테스트 시점에서 데이터 베이스 내부에 접근하여 테이블에 원하는 값이 정상적으로 들어갔는지 확인할 필요가 있다. 문제는 AWS RDS 세팅 시, 보안 관련된 이슈로 해당 데이터 베이스 주소의 외부 접근을 ec2 인스턴스를 제외하고는 모두 막아둔 상태이다. 그래서 아래와 같이 로컬 pc의 Datagrip -> AWS EC2 인스턴스 -> AWS RDS 접근과 같은 절차를 통해 접근해야한다. Datagrip에서는 위와 같은 절차로 Amazon RDS에 SSH 터널링을 통해 접근이 가능하다. 1. SSH 설정 EC2 인스턴스에 접근하기 위해 ssh 정보 등록을 해야한다. 데..
개발/Database 2022. 10. 23. 08:20
데이터베이스(Database)는 구조화된 정보 또는 데이터의 조직화된 모음을 의미한다. 데이터베이스(Database)를 사용하다보면 종종 같은 데이터에 동시에 접근하는 경우가 발생한다. 동시 접근이 발생하는 경우, 예를 들어 선착순 100개의 한정판을 판매하는데 99개가 판매되었고, 잔여 수량이 1 개인데 구매하려는 유저는 20명이면 실제 구매 성공이 되야하는 유저는 1명인데 만약 20명의 유저 전부에게 정상적으로 구매가 진행되었다고 출력된다면 해당 데이터가 오염될 수 있다. 이러한 상황에서 데이터베이스를 관리(제어)하는 DBMS는 데이터의 무결성과 일관성을 지키기위해 Lock을 사용한다. Lock의 정의 Lock은 데이터베이스(Database)에서 트랜잭션(Transaction) 처리의 순차성을 보장하..
개발 2022. 10. 3. 08:20
기존 인텔 맥에서 작성하던 이력서.io 레포가 jekyll을 사용하는 modern-resume-theme 템플릿을 사용하고 있는데 M1 계열 맥북으로 변경한 후, $ bundle exec jekyll serve를 했을 때 아래처럼 Dependency Error가 발생하였다. 해당 이슈가 ARM 아키텍쳐라 생긴 이슈인 줄 알았는데 github-pages가 의존성을 가지고 있는 faraday라는 HTTP/Rest API 클라이언트의 최신 버전이 github-pages와 호환되지 않아서 Dependency Error가 발생하였다. faraday | RubyGems.org | your community gem host rubygems.org Gemfile에 gem 'faraday', '~> 0' 으로 farad..
개발/NestJS 2022. 9. 29. 08:20
회사내에서 프로젝트를 진행할 때는 대부분 NestJS, TypeORM, RestAPI를 기본 스펙으로 잡고 진행하는데 외부에서 진행되던 프로젝트가 NestJS, TypeORM에 Liquibase 라는 처음 접하는 데이터베이스 버전 관리 툴을 사용하였는데 내부로 인수인계가 다 되진 않은 상태에서 local 환경에서 개발하다 $ npm run start:dev를 했는데 정상적인 상황이라면 아래처럼 서버가 실행되어야 정상이다. >>> liquibase update start 뒤에 liquibase가 실행된다는 로그가 남아있는 채로 update end 로그가 뜨지 않고, 3 ~ 4분 뒤에 Caused by: liquibase.exception.LockException: Could not acquire chang..
개발/CS 2022. 9. 13. 08:20
간혹 API 예외처리를 하다보면 어드민만 사용할 수 있어야하거나, 내 정보의 수정/삭제 같이 권한에 민감한 PATCH, DELETE 메소드 api들에 대한 예외가 발생 시 예외 상황에 맞는 HTTP 상태코드를 전달해야하는데 같은 예외 사항에 대해 가끔 403 Forbidden과 401 Unauthorized를 혼용하는 경우가 있었다. HTTP 401 Unauthorized 401 상태 코드는 해당 클라이언트가 인증되지 않았거나, 유효한 인증 자격 증명이 없기 때문에 요청이 거부되었음을 나타내는 상태이다. 해당 코드는 인증되지 않은 클라이언트가 요청을 전송하였기에 요청의 정상 처리가 불가함을 나타내는 것이다. 대표적으로 내 정보 조회/수정 같이 유저 민감 정보를 핸들링하는 경우와 같이 유저 인증이 필요한 ..
개발/MySQL 2022. 8. 25. 08:20
AWS Aurora RDS MySQL에서 AWS MySQL 8.0으로 마이그레이션을 진행 후, save 메소드를 사용하는 api를 호출할 때, TypeORM에서 id 값 관련된 쿼리 error가 발생하였다. TypeORMError: Cannot update entity because entity id is not set in the entity. 해당 에러가 발생하는 부분의 쿼리를 로깅해보면 정상적으로 쿼리가 생성되지만, 타겟 entity의 id가 entity에 세팅되지 않았다는 에러는 발생되므로 ORM이 아닌 DB가 이슈일 가능성이 있었다. INSERT INTO "tableName"("id", "createdAt", "updatedAt", "body") VALUES (DEFAULT, DEFAULT, D..
개발/TypeORM 2022. 8. 1. 08:20
기존에 faker.js를 사용해서 Seeding용 API 엔드포인트를 구성하였었는데 해당 Faker 모듈이 관리가 안되는 이슈도 있고, request한 유저의 권한을 valid하긴 하지만, 데이터 베이스에 직접적으로 영향을 줄 수 있는 엔드포인트가 외부로 노출되어있는 점이 불안해서 typeorm seeding을 통해 ssh로 직접 서버에 접속해서 커맨드를 날리는 방향으로 변경하였다. Faker.js를 통한 Seed API 작성 백엔드를 개발하다보면 REST API의 GET 메소드에서 DB에서 데이터를 제대로 불러오는지 확인해야하는데 이럴 때 Seed API를 통해 테스트 용도의 fake DB를 구성하는 것이 매번 데이터를 직접 입력해넣 eight20.tistory.com NestJS와 관련된 Seedin..
개발/ReactJS 2022. 7. 28. 08:20
기존 React Router에서 Route를 지정할 때, 안에 컴포넌트에서 path props으로 url을 지정하고 component props로 랜더링을 원하는 페이지 컴포넌트를 지정하였었다. // Route.tsx 한 페이지 안에 3개의 UX 뎁스로 구성되어있는 UI에서 3번째 뎁스 까지 도달했을 때, Add 혹은 EditPage로 넘어가게 하였다. 2번째 뎁스에서 id값을 props로 넘기는 것을 받아왔을 때, focus가 해당 페이지를 벗어나면 AddPage 혹은 EditPage가 언마운트되었디가 다시 마운트되면서 3번째 뎁스 안의 title, content등의 state가 모두 초기화되어 작성한 내용이 빈칸으로 되는 이슈가 발생하였다. 해당 이슈가 발생한 원인은 한 페이지 안에 여러 개로 뎁스가..
개발/TypeORM 2022. 7. 14. 08:20
DB를 기존에 사용하던 PostgreSQL에서 MySQL로 변경하고 나서 동일한 Entity의 String 타입으로 지정된 칼럼의 문자열 길이가 공백 포함 255자 이상은 저장되지 않는 이슈가 생겼다. 기존 Entity는 Id, 생성 일시, 마지막 업데이트 일시, 제목, 설명, 썸네일, 링크로 구성되어 있는데 이슈가 발생한 부분은 description 부분이었다. TypeORM의 경우, string 타입으로 칼럼 타입을 지정하면 각 DB의 기본 문자열 저장 타입으로 변환하는데 따로 Character Type을 지정하지 않으면 PostgreSQL은 varchar, MySQL은 varchar(255)이다. // content.entity.ts @Entity() export class Content { @Pr..
개발/Linux 2022. 6. 21. 08:20
리눅스 또는 맥을 사용하다보면 터미널을 쓸 수 밖에 없는데 간혹 Permission denied와 같이 파일 권한 이슈가 있는 경우가 있다. 터미널에서 ls 커맨드에 al 옵션을 붙여서 ls -al을 입력하면 파일명 이외에도 다른 정보들이 나오는 것을 볼 수 있다. 여기서 맨 앞의 drw~ 와 같이 알파벳과 하이픈을 합쳐 총 10자리가 파일 접근 권한을 표기한 것이다. 실질적으로는 d / rwx / r-x / r-x 와 같이 권한의 역할에 따라 4칸으로 구분된다. 첫 번째 칸은 파일의 타입, 두 번째 칸은 user의 권한, 세 번째 칸은 group의 권한, 네 번째 칸은 나머지(others), 게스트의 권한으로 분류된다. 첫 번째 칸의 형식 - 는 파일을 의미한다. d는 디렉토리를 의미한다. l은 다른 ..