• (상황에 따라) 쓸모없는 DISTINCT 사용
• 쿼리가 1+1로 나감

근데 여기서 추가적으로, 다른 테이블의 JSON stringify된 데이터를 기준으로 orderBy를 정렬하려고 할 때도 이슈가 있다.

아래부턴 실제 사내에서 쓰이던 구조와 비슷하게 임의로 수정한 코드이기 때문에 휴먼에러가 존재할 수 있습니다. 또한 TypeORM 0.3.17버전을 기준으로 작성되었으며 버전에 따라 다른 결과를 보일 수 있습니다.

유저-포스트의 1:N(혹은 1:1) 관계가 있으며, 포스트의 meta_data라는 열에 여러 정보를 json으로 관리하고 있다. 이 중 subject라는 필드를 기준으로 정렬하려고 한다.

await this.createQueryBuilder('user')
      .leftJoinAndSelect('user.post', 'post')
      .select([
        'user.id',
        `JSON_EXTRACT(post.meta_data, '$.subject') AS post_subject`,
      ])
      .where(`${searchType} like :searchValue`, { searchValue: `%${searchValue}%` })
      .skip(skipCount)
      .take(showCount)
      .orderBy('post_subject', 'DESC')
      .getManyAndCount()

# 실제로 발생하는 쿼리
SELECT DISTINCT `distinctAlias`.`user_id` AS `ids_user_id`
FROM (
  SELECT `user`.`id` AS `user_id`, JSON_EXTRACT(`post`.`meta_data`, '$.subject') AS post_subject
  FROM `user` `user` LEFT JOIN `post` `post` ON `post`.`id`=`user`.`post_id`
  WHERE `user`.`name` like ?
) `distinctAlias`
ORDER BY post_subject DESC, `user_id` ASC LIMIT 10

# 실행 결과
[ERROR] Expression #1 of ORDER BY clause is not in SELECT list, references column 'distinctAlias.post_subject' which is not in SELECT list; this is incompatible with DISTINCT

성능 문제는 둘째치고 실행조차 되지 않게 된다. DISTINCT와 ORDER BY를 사용할 때 ORDER BY에서 참조하는 모든 걸럼은 SELECT 리스트에 포함되어야 한다고 한다. 실제로 존재하는 열에 대한 orderBy를 사용할 땐 SELECT DISTINCT에 추가되는 모습을 볼 수 있다.

await this.createQueryBuilder('user')
      .leftJoinAndSelect('user.post', 'post')
      .select([
        'user.id',
        `JSON_EXTRACT(post.meta_data, '$.subject') AS post_subject`,
          'user.create_date'
      ])
      .where(`${searchType} like :searchValue`, { searchValue: `%${searchValue}%` })
      .skip(skipCount)
      .take(showCount)
      .orderBy('user.create_date', 'DESC')
      .getManyAndCount()

# 실제로 발생하는 쿼리
SELECT DISTINCT `distinctAlias`.`user_id` AS `ids_user_id`, `distinctAlias`.`user_create_date`
FROM (
  SELECT `user`.`id` AS `user_id`, JSON_EXTRACT(`post`.`meta_data`, '$.subject') AS post_subject, `user`.`create_date` AS `user_create_date`
  FROM `user` `user` LEFT JOIN `post` `post` ON `post`.`id`=`user`.`post_id`
  WHERE `user`.`name` like ?
) `distinctAlias`
ORDER BY `distinctAlias`.`user_create_date` DESC, `user_id` ASC LIMIT 10

# 실행 결과
# ... id IN을 실행하는 select 한번, COUNT를 위한 select 한번

이를 보아 알 수 있는 점은 JSON_EXTRACT 등 가상의 컬럼을 이용한 OrderBy를 사용하고 싶어도 TypeORM에서 자동으로 DISTINCT의 SELECT에 넣어주지 못하기 때문에 불가능하다는 것이다.

그럼 이를 어떻게 해결해야할까? 하나의 방법으로는 위에 공유된 글처럼 innerJoin 서브쿼리를 이용하면 해결이 될 것 같다. (실제로도 이 방법이 옳을 것 같다) 하지만 필자는 해당 방법을 사용하지 않고 offset&limit을 사용했다. 이유는 굉장히 단순한데 실제 사내에서 발생한 조인 테이블의 관계가 One-To-One이었기 때문이다. Github의 관련 이슈 댓글에서도 언급되었듯이 One-To-One 관계에서는 DISTINCT가 전혀 필요하지 않으며, 마찬가지로 offset&limit을 사용했을 때 발생하는 중복 열 이슈도 발생되지 않는다.

라고 결론을 내렸고 일단 현재로서는 아무 문제도 발생하지 않았으나 예상하지 못한 부분에서 문제가 발생할지도 모른다. JSON_EXTRACT를 사용하는 비슷한 케이스에서의 OrderBy에 대해 고민하고 있을 때 참고해볼 수 있도록 작성하게 되었다.

0. 개요

사내에서 기존에 사용하던 웹 관련 프론트, 백엔드의 기술스택을 마이그레이션하게 됐다. 상세하게 프론트는 Angular에서 React로, 백엔드는 Flask에서 NestJS로 옮기게 됐다. 이런 선택을 하게된 이유는 아래와 같다.

• 기존 레거시 프로젝트(Angular, Flask)는 외주 업체에서 전달받았지만 아무 문서도 없었고 이쪽 회사에 맞춰서 개발이 된 상태도 아니었기 때문에 불필요한 코드도 굉장히 많았으며 아키텍처도 존재하지 않고 하나의 함수에서 라우팅, 비즈니스 로직, DB 제어, 응답을 모두 수행하는 등 유지보수가 굉장히 힘든 상태의 코드였다.
• 소수의 인원(1~2명)으로 웹 전반의 유지보수 + 요구사항 개발을 진행해야했지만 기술스택이 TypeScript(Angular) / Python(Flask)로 분리되어 있어 개발비용 측면에서 불리한 상황이었다.
• 모바일 프론트의 경우 React Native로 개발되고 있었으며 웹 프론트도 React로 변경하면 비슷한 프레임워크(라이브러리) 환경이기 때문에 좀 더 이점을 취할 수 있을 것이라 판단되었다.
• 같은 이유로 백엔드도 NestJS로 변경하면 웹 프론트 + 앱 프론트 + 백엔드 셋 다 TypeScript로 모든 서비스를 하나의 언어스택으로 구성할 수 있었다.

결정적으로 회사에서 서비스를 확장하려고 하는 단계였으며 DB, 서버, 프론트에 대규모 수정사항이 생길 구조적 변경 요구사항이 생기게 됐다. 현재 상태를 유지하면서 추가 개발을 진행하는 것은 장기적으로 고려해봤을때 결국은 기술부채를 계속해서 늘리기만 할 뿐이라 판단했으며 이에 마이그레이션 작업을 제안하여 진행하게 됐다.

1. 백엔드 서버

앞서 말했듯이 레거시 서버는 라우팅, 비즈니스 로직, DB 제어, 응답 등 모든 로직이 하나의 함수에서만 이루어져 있었으며 당연하게도 재사용성은 미비했고 중복 로직이 다수 존재했다. API 문서 또한 존재하지 않았기 때문에 처음에 분석하고 재설계하는 과정에서 굉장히 많이 고생했던 기억이 아직도 난다. DB 구조에서도 무분별한 인덱스 설정과 사용되지 않는 컬럼, 잘못 사용되는 컬럼 등 많은 문제점이 존재하는 것을 확인할 수 있었다.

같은 TypeScript로 구성할 수 있는 Express를 선택할 수도 있었겠지만 이미 위의 문제점들을 겪어본 입장에서 장기적으로도 아키텍처가 지켜질 수 있도록 프레임워크 차원에서 지원받고 싶어 NestJS를 선택했으며 어떻게 만들어야 유지보수, 추가 기능 개발에 용이할 수 있을지 찾아보았고 클린 아키텍처라는 것을 공부해 도입해보기로 결정했다.

1-1. 클린 아키텍처

각 레이어를 뚜렷하게 정의하여 나누고 분리된 의존성을 토대로 따로따로 개발하며 이를 이용한 이점으로 테스트 코드를 작성해보고.. 처음엔 모든 것이 좋은 느낌이었다. 하지만 얼마 안가 여러 고민들이 깊게 자리하게 됐으며 일주일 내내 구조만 계속 변경했던 시기도 있었다.

• 도메인(엔티티)레이어를 잘못 이해하고 사용하고 있었다. 그저 멤버 변수만 존재하는, 실질적으론 타입과 다름없는 도메인들만 생겨났다.
  • 사실 전체 서비스가 DB에서 단순 CRUD 작업만 진행하는 것이 70% 이상이었으며 비즈니스 도메인이 거의 없다는 점도 한몫 했었다. 어찌보면 이 아키텍처를 선택한 것부터 잘못됐던 걸까? 싶었다.
  • 그렇다보니 '진짜 비즈니스 로직' 이 있어도 유스케이스 레이어에서 작성하게 되는 일이 잦아졌고 이게 정말 도메인을 지키는, 도메인을 중심으로 사용하는 아키텍처가 맞나..? 싶어졌다.

클린 아키텍처로 구성했다는 많은 깃 레포, 블로그 자료 등을 참조해보며 생각해본 결과 이런 의문들이 계속 생겨나는 근본적인 이유는 '이미 DB가 완성되어 있었으며 사실상 DB 스키마에 의존하여 단순한 CRUD만 진행하는 서비스'였기 때문에 더더욱 그런쪽으로 밖에 생각하지 못하게 됐던 것 같았다. 이를 교정하기 위해 '만들면서 배우는 헥사고날 아키텍처 설계와 구현' 이라는 책을 많이 참고했었으며 덕분에 클린 아키텍처를 온전하게 사용하는 법을 터득했다.

• DTO를 어떻게 구성하고 어디서 선언한 뒤 어떻게 넘겨줘야 할지 굉장히 심하게 고민했었다.
  • 처음엔 인터페이스로만 선언한 뒤 객체 리터럴로 반환, 전달을 진행했었지만 런타임 시점에서 사라지는 타입으로 DTO를 전달하고 사용하는 것이 옳은걸까..? 타입에 대한 유효성 검증을 아예 진행하지 않는 것이 과연 올바른걸까...? 라는 고민이 생겨났다.
  • 위 고민 끝에 클래스 형식으로 DTO를 대부분 바꾸던 중 클래스로 만들어 사용하는 것도 깔끔하고 납득되는 해답이 아니었기 때문에 더 혼란스러웠다. 정의상 DTO는 아무 로직도, 함수도 포함하지 않아야 된다는데 그렇다면 더더욱 클래스일 이유가 없는게 아닐까? 멤버변수만 있는 클래스가 인터페이스(타입)과 도대체 뭐가 다른걸까?

결국 해당 프로젝트 안에서 DTO를 어떻게 만들고 사용할지에 대한 컨벤션을 정했으며 명확한 기준을 나눠서 인터페이스와 클래스를 적절히 섞어서 사용하게 되었다. 통일성 관점에서도 별로 좋진 않은 것 같고 클래스에 static 메서드(안쪽 레이어의 DTO로 변환하는 함수)가 포함되어 있었기 때문에 DTO의 정의랑도 잘 맞지 않는 거 같았지만 DTO 관련 논쟁은 우리 뿐만이 아니라 다른 사람들도 많이 겪는 문제인 것으로 보아 확실하게 구분지어 정의할 순 없는 영역이라 생각했고 여러 시행착오 끝에 도달한 그나마 납득 가능한 정의들이었다. 해당 방식은 pvarentsov/typescript-clean-architecture 레포지터리에서 참조했다.

클린 아키텍처를 효과적으로 사용하기 위해선 고려해봐야 되는 점이 생각보다도 굉장히 많았으며 이런 개념이 생겨난 이유가 많이 와닿았다. 역시 최우선적으로 지켜야 될것은 '의존성의 흐름, 방향과 제어' 라고 생각해 그것을 중점으로 뒀으며 결과적으로 나름 납득 가능한 선에서의 아키텍처를 정의해냈고 이로 인해 유닛 테스트를 작성하는데에 많은 이점을 가져올 수 있었다.

1-2. TypeORM..........

보통 NestJS로 프로젝트를 구성할 때 TypeORM을 많이 사용하며 공식문서에서도 이를 기반으로 설명하고 있다. 실제로 프로젝트를 구성했을 단계에서 여러 ORM을 비교해봤을 때 TypeORM이 여러면에서 적합하다고 판단되어 도입했지만 정말. 정말... 여러 문제가 많았다........

• 타입스크립트를 사용하는데도 타입에 안전하지 않다.
  • select 옵션으로 특정 컬럼들을 지정하는 순간 TypeORM 엔티티와 결과 값의 타입은 완전히 달라지게 된다. undefined.....
  • 쿼리빌더를 사용할 때 해당 엔티티에 대한 타입을 자동완성으로 지원해주지 않는다. 사실상 생 쿼리와 다름없는 매직 스트링을 입력하게 되며 이 경우 ORM을 사용하는 이점이 소실되며 오히려 생 쿼리를 쿼리빌더 문법으로 사용하기 위해 찾아내는 작업을 해야해서 일을 두번씩 하는 느낌이었다. (특히 andWhere 안에서 orWhere를 사용하는 복잡한 조건에서 'Brackets' 라는 객체를 생성해 사용해야 했는데 이 경험이 굉장히 좋지 않았다.)
• 굉장히 많은 버그가 존재했다. 정말 많이 존재했다.
  • 거의 항상 이슈에서 검색해봤던 거 같다. 제일 기억에 남는 것은 join이 들어가는 where 쿼리에서 inner join이 기본 값으로 적용되는 점이었다. 해당 문제는 12월 4일 0.3.11버전으로 업데이트되면서 해결됐지만 이런 비슷한 문제들을 굉장히 많이 겪어 지쳐갔다.
  • 클린(레이어드) 아키텍처에서 사용할 때 트랜잭션 처리에 관해서 곤란했다.
• 여러 모듈이 엮여 있는 트랜잭션 작업을 수행하기 위해선 유스케이스 레이어에서 트랜잭션을 알아야 했으며 이를 알게되는 순간 유스케이스 레이어가 인프라 레이어의 세부사항을 알게되는 문제점을 갖고 있다.
• 이를 해결하기 위한 typeorm-transactional-cls-hooked 등 라이브러리가 존재하긴 했으나 어떤 선택지도 적절하진 않았다. (사실 이 문제는 TypeORM만의 문제점은 아닌 것 같긴 하다.)

프로젝트의 중반부터는 정말 하루에도 몇번씩이나 TypeORM... 또 TypeORM 너야..... 라는 생각을 달고 살았던 것 같다. 이쯤부터 Prisma를 잠깐씩 공부해보고 있었는데 물론 프리즈마도 깊게 파고 들어가면서 프로젝트를 진행해보면 문제점이 생기긴 하겠지만 그래도... 정말 TypeORM에 비해서는 천사처럼 느껴질 정도로 사용 경험이 굉장히 좋았다.

개인적으로 TypeORM은 결국 스프링 JPA의 엄청난 하위호환일 뿐이라는 느낌을 굉장히 많이 들게했으며 이걸 사용할 바에는 차라리 스프링으로, JPA를 사용해서 구현하는게 낫겠다 싶었다.. 그에 비해 Prisma는 확실하게 독자적인 방식을 채택하며 좀 더 TypeScript, NodeJS스럽다 라는 느낌을 많이 받을 수 있어 만족스러웠다. 비록 NestJS도 TypeORM도 스프링 환경을 참조해서 만들었다곤 해도 결국 독자적인 방향을 추구하지 않는다면 '그거 쓸바엔 그냥 스프링 쓰면 되는 거 아냐? 어차피 스프링에 비해서 기능도 굉장히 빈약하고 불안정하던데' 에 그치지 않을까 라고 생각한다.

2. 인프라/데브옵스

입사 후 3~4주차. 아직도 그때의 괴로운 기억이 선명하게 남아있었다. 레거시 프로젝트의 배포 프로세스를 로컬에서 테스트해보고 실제 배포를 진행했던 날이었는데 정말 끔찍한 경험이었다.

• 배포에 필요한 모든 프로세스를 개발자가 '매번 수동으로' 직접 구성해야 했다.
  • 로컬에서 빌드를 진행하고, 새 버전의 이미지를 생성해 ECR에 업로드하고, ECS에 새로운 Task를 개정하고, Service를 업데이트 하는데 인스턴스의 가용 자원, 고정되어있는 포트 등의 문제도 발생했다.
  • 하나의 ECS 클러스터, 하나의 서비스, 심지어 하나의 태스크에 모든 컨테이너(서버, 프론트, traefik, Worker, 심지어 레디스까지!)에 대한 정의가 구성되어 있었으며 당연하게도 하나의 수정사항이 생기면 엮여있던 모든 서비스들이 다운됐다. 실제로.....

덕분에 정말 이것만은 개선을 꼭 해내야겠다 라고 마음을 먹었었으며 결과는 아래와 같다.

배포 프로세스

• 그림에는 없지만 PR이 올라오면 Github Action에서 빌드, 테스트, 린트 등 CI 파이프라인을 거치도록 구축했다.
• CodePipeline을 활용해서 ECS Blue/Green 무중단 배포 CD 파이프라인을 구축했다.
  • 당연히 이전과는 다르게 클러스터와 서비스, 태스크를 나눠 각각의 수정사항이 다른 서비스에 영향을 미치지 않도록 구성했다.

AWS의 여러 기능들을 처음 써보게 되었으며 보름 가까이 코드와는 멀어져 공부만 했던 것 같다. 인프라, 데브옵스 관련 정보글들은 찾아보면 항상 추상적으로 설명만 하고 구체적인 설정 예제가 없어 굉장히 막막하기도 했고 제대로 구축하고 있는게 맞을까 잘못되면 어떡하지 하는 걱정에 겁이나서 하루종일 손도 못댔던 기억이 난다. 더군다나 AWS 콘솔 환경이 신버전으로 업그레이드하고 있는 중이었으며 구버전과 신버전을 번갈아가면서 특정 기능이 존재하는지 찾아봐야 했다...... 그래도 결국 공식문서에는 모든 답이 있었고(그렇게 친절하진 않았지만) 결국은 완전히 구축을 해내 실제 배포가 진행되고 수정사항이 생겼을 때도 main 브랜치에 push가 되는 순간 파이프라인이 돌고 n분 뒤에 새 버전으로 배포가 성공적으로 진행되는 것을 확인했을 때의 성취감은 정말... 직접 구축하고 나니 그 수많은 정보글들이 왜 추상적으로만 알려줬는지 이해가 됐었다.

전체 서비스 아키텍처 (간략)

배포 환경에서의 아키텍처도 일부 수정된 부분이 있었는데 원래 레거시 구조에선 컨테이너로 띄워져있던 traefik이 로드밸런싱을 담당하고 있었으며 라우팅은 가비아를 사용했었다. 여기서 컨테이너들이 고정된 포트를 사용했기 때문에 당연히 오토스케일링이나 무중단 배포는 사실상 불가능한 구조였다.

이를 해결하기 위해 AWS의 여러 기능들을 검토해서 적극적으로 사용해 개선했으며 현재 서비스는 언제든 확장이 편리하게 가능한 상태로 개선해냈다.

setup

yarn add typeorm@0.2.45 @nestjs/typeorm pg

의존성 패키지들을 설치한 뒤 package.json을 설정해준다.

// package.json
  "scripts": {
    // 이 부분의 --config 중요!!
    "typeorm": "node --require ts-node/register ./node_modules/typeorm/cli.js --config src/ormconfig.ts",
    "make:migrations": "yarn typeorm migration:generate -n",
    "make:migrate": "yarn typeorm migration:run",
    "make:rollback": "yarn typeorm migration:revert"
  }

TypeOrm 모듈에 설정 파일을 전달하기 위한 방법으로 ormconfig.ts를 넣어주는 방법을 사용한다.

# .env
DB_HOST=
DB_PORT=
DB_USER=
DB_PASSWORD=
DB_NAME=

// src/ormconfig.ts
import { TypeOrmModuleOptions } from '@nestjs/typeorm'
import * as dotenv from 'dotenv'

dotenv.config()

const ormconfig: TypeOrmModuleOptions = {
  type: 'postgres',
  host: process.env.DB_HOST,
  port: process.env.DB_PORT,
  username: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
  logging: true,
  entities: [__dirname + '/**/*.entity{.ts,.js}'],

  // TypeOrm 자동 동기화, migration 작업을 위해 중지
  synchronize: false,

  // dist/migrations에 있는 파일들을 실행
  migrations: [__dirname + '/migrations/**/*{.ts,.js}'],
  // migrate run 자동 실행
  // migrationsRun: true,
  cli: {
    // entitiesDir: 'src/entities',
    // src/migrations에 있는 파일들을 dist/migrations에 생성
    migrationsDir: 'src/migrations',
  },
}

export default ormconfig

// src/app.module.ts
import ormconfig from './ormconfig'

@Module({
  imports: {
    ...
    TypeOrmModule.forRoot(ormconfig),
    ...
  ],
  ...

run

yarn make:migrations (이름)
yarn make:migrate
yarn make:rollback

yarn make:migrations {이름} 실행 시

1. DB 상태와 현재 Entity파일의 차이를 찾아낸다.
2. src/migrations 폴더에 ....-{이름}.ts를 생성한다.
3. dist/migrations 폴더에 ....-{이름}.js로 컨버팅된다.

yarn make:migrate / rollback은 각각 up, down (마이그레이션 실행, 되돌리기) 역할을 수행한다.

known error

'TypeOrmModuleOptions' 형식에 할당할 수 없습니다.

'{ type: "postgres"; host: string; port: number; username: string; password: string; database: string; logging: true; entities: string[]; synchronize: true; migrations: string[]; cli: { migrationsDir: string; }; }' 형식은 'TypeOrmModuleOptions' 형식에 할당할 수 없습니다. 개체 리터럴은 알려진 속성만 지정할 수 있으며 '{ retryAttempts?: number | undefined; retryDelay?: number | undefined; toRetry?: ((err: any) => boolean) | undefined; autoLoadEntities?: boolean | undefined; keepConnectionAlive?: boolean | undefined; verboseRetryLog?: boolean | undefined; } & Partial<...>' 형식에 'cli'이(가) 없습니다.ts(2322)

이 에러가 뜨는 이유는 TypeORM 신버전(0.3.x)에서 TypeOrmModuleOptions에 type으로 PostgreSQL을 설정했을때 cli 속성이 사라졌기 때문이다. 레퍼런스를 찾아본 결과 해당 옵션 없이도 해결할 수 있는 방법이 있긴 한 거 같지만 굳이 최신버전이어야 될 이유도 없고 굉장히 번거로웠기 때문에 다운그레이드로 해결했다.

// package.json
  "dependencies": {
    ...
    "typeorm": "^0.2.45",
    ...
  }

MissingDriverError: Wrong driver: "undefined" given. Supported drivers are: "aurora-data-api", "...".

[Nest] 23260 - 2022. 10. 27. 오전 11:15:58 ERROR [ExceptionHandler] Wrong driver: "undefined" given. Supported drivers are: "aurora-data-api", "aurora-data-api-pg", "better-sqlite3", "capacitor", "cockroachdb", "cordova", "expo", "mariadb", "mongodb", "mssql", "mysql", "nativescript", "oracle", "postgres", "react-native", "sap", "sqlite", "sqljs". MissingDriverError: Wrong driver: "undefined" given. Supported drivers are: "aurora-data-api", "aurora-data-api-pg", "better-sqlite3", "capacitor", "cockroachdb", "cordova", "expo", "mariadb", "mongodb", "mssql", "mysql", "nativescript", "oracle", "postgres", "react-native", "sap", "sqlite", "sqljs".

nestjs에서 typeorm은 TypeOrmModule.forRoot()에 아무 인수도 제공하지 않고도 ormconfig.json을 자동으로 인식할 수 있지만 타입 관련해서 제대로 잡지 못해서 나타나는 에러였다. 원인은 아마 실행되는 순서일 것이라 생각되어 ormconfig을 ts파일로 만들어 타입을 부여해주는 것으로 해결했다.

// src/ormconfig.ts
import { TypeOrmModuleOptions } from '@nestjs/typeorm'

const ormconfig: TypeOrmModuleOptions = {
  type: 'postgres',
  ...
}

export default ormconfig

TypeORMError: No connection options were found in any orm configuration files.

이 에러는 typeorm 명령어를 사용할 때 config로 아무 파일도 전해지지 않았기 때문이다. 위의 에러와 마찬가지로 typeorm은 ormconfig.json은 자동으로 인식하지만 위의 과정으로 인해 ormconfig.ts로 변경했기 때문에 찾지 못해 발생한 에러였다. 명령어의 뒤에 --config 옵션으로 ormconfig.ts파일을 지정해준다.

// package.json
  "scripts": {
    ...
    "typeorm": "node --require ts-node/register ./node_modules/typeorm/cli.js --config src/ormconfig.ts",
    ...
  }

No migrations are pending

query: SELECT * FROM current_schema() query: SHOW server_version; query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = 'public' AND "table_name" = 'migrations' query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = 'public' AND "table_name" = 'typeorm_metadata' query: SELECT * FROM "migrations" "migrations" ORDER BY "id" DESC No migrations are pending ✨ Done in 1.67s.

typeorm migration:generate 명령도 제대로 동작했고 migrations폴더에 마이그레이션에 관한 코드도 제대로 생성됐는데 migrations 파일을 찾을 수 없다는 에러가 발생했다. ts파일을 js로 컨버팅하고 dist로 옮겨졌을 때 위치를 제대로 잡아주지 못해서 나타나는 에러였다. ormconfig에서 migrations랑 migrationsDir에 적절한 위치를 잡아주면 해결된다.

// src/ormconfig.ts
const ormconfig: TypeOrmModuleOptions = {
  ...
  // migration:run 명령어에서 사용하는 위치
  // 컨버팅 이후의 __dirname: dist, dist/migrations에 있는 파일들을 실행
  migrations: [__dirname + '/migrations/**/*{.ts,.js}'],
  cli: {
    // migration:generate 명령어에서 사용하는 위치
    // 실제 프로젝트에서 migrations 폴더를 어디에 만들 것인지 지정한다.
    // src/migrations에 생성된 파일들은 tsc를 거쳐 dist/migrations에 생성된다.
    migrationsDir: 'src/migrations',
  },

migration 파일들은 src/migrations에 생성할 것이기 때문에 migrationsDir은 이렇게 지정한다. 이후 tsc를 거쳐 컨버팅된 파일들은 dist/migrations에 생성된다. (src -> dist) ormconfig 파일도 마찬가지로 컨버팅되어 dist로 전달되고 dist에서 실행되며 이 시점의 경로를 migrations에 잡아줘야 해결된다. 'src/migrations'나 '/migrations/'이면 에러가 발생하며 __dirname을 사용해 제대로 dist 위치를 잡아주는 것으로 해결했다.

Error: EACCES: permission denied, scandir '/Library/Application Support/Apple/AssetCache/Data'

[Nest] 24076 - 2022. 10. 27. 오전 11:47:53 ERROR [TypeOrmModule] Unable to connect to the database. Retrying (1)... Error: EACCES: permission denied, scandir '/Library/Application Support/Apple/AssetCache/Data'

이 에러 메시지 자체는 아마도 Mac에서만 발생할 것으로 예상되지만 발생 조건으론 위와 같이 경로를 잘못 지정했을 때 발생한다. 해당 에러가 발생했을 때의 상황은 ormconfig 파일을 따로 service로 만들어 주입받게해 TypeOrmModule로 집어넣는 방식을 선택했을 때였다.

// src/config/database/postgres-config.service./ts
@Injectable()
export class PostgresConfigService implements TypeOrmOptionsFactory {
  constructor(private configService: ConfigService) {}

  createTypeOrmOptions(): TypeOrmModuleOptions {
    return {
      entities: ['/**/*.entity{.ts,.js}'],

에러 메시지로는 권한이 없다고 하는데 에러의 원인은 entities필드의 경로가 잘못되었을 때 발생했으며 경로를 제대로 잡아주면 해결된다.

entities: [__dirname + '../../../**/*.entity{.ts,.js}'],

하지만 어차피 이 방법으론 typeorm 명령어에서 config를 넘겨주지 못했기 때문에 다른 방법을 선택하기로 했다.

이 과정중 굉장히 많은 에러가 발생했고 각 에러 하나하나를 해결하는데 꽤 많은 시간을 소모했으며 여기저기 검색해봐도 프로젝트마다 다른 ormconfig, package.json의 설정을 사용해 해결하기 어려웠다. 결국 해결한 결과도 ormconfig.ts가 typeorm에서 읽히게 하기 위해서 nest에 의존하지 않아야 했기 때문에 configService를 사용하지 못했고 dotenv.config()를 사용했다는 점이 찜찜하긴 했지만 ormconfig에 대한 내용을 중복해서 작성하기도 싫어 이쯤에서 타협하기로 했다. 이후에도 새 프로젝트를 처음 설정할 때 발생할 문제였기 때문에 기록으로 남긴다.

R2에서의 S3 API는 현재 구현중이며 아직 지원하지 않는 부분이 굉장히 많았는데 특히 이쪽 서비스에서 필요한 업로드 진행도를 뽑아내는데에 고생했다. 특히 aws-sdk-js-v3을 사용했을 때 제대로 동작하지 않는 부분이 많았으며 R2에서는 v2를 사용하기로 했다.

시나리오는 S3 버킷 내의 모든 파일들의 키를 뽑고, 키로 파일을 찾아와 R2에 업로드한다. 우선 의존 라이브러리를 설치한다.

yarn add aws-sdk @aws-sdk/client-s3

S3 관련은 v3(@aws-sdk/client-s3)을 사용하고 R2에 업로드 하는 것은 v2(aws-sdk)를 사용할 것이다.

! 아래 코드는 글을 작성했을 당시(돌아가는 로직) 기준이며 최신 코드는 Github을 참조해주세요. https://github.com/Luna-Runa/s3-to-r2

S3

// ./s3Client.ts
import { S3Client } from '@aws-sdk/client-s3';

export const s3Client = new S3Client({
  region: 'ap-northeast-2', // your region
  endpoint: `https://s3.ap-northeast-2.amazonaws.com`, // your endpoint
  credentials: {
    accessKeyId: {accessKeyId},
    secretAccessKey: {secretAccessKey},
  },
});

export const S3_BUCKET = {bucketName} as const;

// ./index.ts
import { ListObjectsCommand } from '@aws-sdk/client-s3';
import { s3Client, S3_BUCKET } from './s3Client.js';

export const getKeysByBucket = async () => {
  try {
    const files = await s3Client.send(
      new ListObjectsCommand({ Bucket: S3_BUCKET }),
    );

    const keys = files.Contents.map((item) => item.Key);

    return keys; // ['key1', 'key2', 'key3']
  } catch (err) {
    console.log('Error', err);
  }
};

export const getFileByKey = async (getBucketParams: GetObjectCommandInput) => {
  try {
    const data = await s3Client.send(new GetObjectCommand(getBucketParams));

    return data;
  } catch (err) {
    console.log('getFileByKey Error : ', err);
  }
};

getKeysByBucket으로 버킷 내의 모든 키를 불러온 뒤 getFileByKey에 하나씩 넣어주면 된다.

R2

// ./r2Client.ts
import { S3Client } from '@aws-sdk/client-s3';
import S3 from 'aws-sdk/clients/s3.js';

export const r2ClientV2 = new S3({
  endpoint: `https://{accountId}.r2.cloudflarestorage.com`,
  accessKeyId: {accessKeyId},
  secretAccessKey: {secretAccessKey},
  signatureVersion: 'v4',
});

export const r2ClientV3 = new S3Client({
  region: 'auto',
  endpoint: `https://{accountId}.r2.cloudflarestorage.com`,
  credentials: {
    accessKeyId: {accessKeyId},
    secretAccessKey: {secretAccessKey},
  },
});

export const R2_BUCKET = {bucketName} as const;

// ./index.ts
import { r2ClientV2, r2ClientV3, R2_BUCKET } from './r2Client.js';

// R2의 버킷 CORS는 대쉬보드에서 설정이 불가능하기 때문에 여기서 설정해줘야된다.
export const putBucketCors = async () => {
  try {
    const data = await r2ClientV3.send(
      new PutBucketCorsCommand({
        Bucket: R2_BUCKET,
        CORSConfiguration: {
          CORSRules: [
            {
              AllowedHeaders: ['*'],
              AllowedMethods: ['HEAD', 'GET', 'PUT', 'POST', 'DELETE'],
              AllowedOrigins: ['*'],
              ExposeHeaders: ['ETag'],
            },
          ],
        },
      }),
    );
  } catch (err) {
    console.log('putBucketCors Error : ', err);
  }
};

await putBucketCors();

let i = 1;

export const uploadFile = async (uploadBucketParams: PutObjectRequest) => {
  try {
    const fileName =
      uploadBucketParams.ContentDisposition.split('filename=')[1];

    const upload = r2ClientV2.upload(uploadBucketParams, (err, data) => {
      console.log(`${i} / ${keys.length} Complete!`);
      fs.appendFileSync(
        'log.txt',
        `${fileName.padEnd(50, ' ')} ${i++} / ${keys.length} Complete!\n`,
      );
    });

    // file upload progress, progress.total is not working
    upload.on('httpUploadProgress', (progress) => {
      console.log(
        `${fileName.padEnd(50, ' ')} progress : ${
          (progress.loaded / uploadBucketParams.ContentLength) * 100
        }`,
      );
    });
  } catch (err) {
    console.log('uploadFile Error : ', err);
  }
};

먼저 Bucket의 CORS 설정을 해주기 위한 putBucketCors를 실행시킨다. S3는 대쉬보드에서 만들면서 설정 가능하지만 R2에서는 API를 이용해서 설정해야한다. 여기선 굳이 v2를 사용할 이유는 없으니 v3를 사용했다.

uploadFile 함수로 PutObjectRequest를 받아 실제 업로드를 처리한다.

이쪽 시나리오에서는 버킷에 저장하는 파일의 키는 uuid로 저장하고 ContentDisposition에 filename= 뒤에 원본 파일 이름이 들어있었기 때문에 fileName을 저렇게 설정했다.

업로드 진행도를 확인하기 위해 AWS.S3.upload (v2)를 사용했다. upload 함수의 콜백으로 어떤 파일이 완료되었고 n개중 i번째인지를 로그 파일로 추출한다. 만약 파일 이름을 버킷에 들어가는 파일 키 그 자체로 지정하고 있다면 fileName 대신에 이 함수의 콜백 인자에서 data.Key를 이용해 추출하면 된다.

upload.on을 이용해 progress를 추출한다. 는 progress.loaded는 다행히 정상적으로 제공해주지만 progress.total은 undefined로 넘어오기 때문에 param으로 줬던 ContentLength를 사용한다.

이제 필요한 함수는 모두 구현했다.

전체 코드

// ./index.ts
import {
  GetObjectCommand,
  GetObjectCommandInput,
  ListObjectsCommand,
  PutBucketCorsCommand,
} from '@aws-sdk/client-s3';
import { s3Client, S3_BUCKET } from './s3Client.js';
import { PutObjectRequest } from 'aws-sdk/clients/s3.js';
import { r2ClientV2, r2ClientV3, R2_BUCKET } from './r2Client.js';
import fs from 'fs';

// run this once
// export const putBucketCors = async () => {
//   try {
//     const data = await r2ClientV3.send(
//       new PutBucketCorsCommand({
//         Bucket: R2_BUCKET,
//         CORSConfiguration: {
//           CORSRules: [
//             {
//               AllowedHeaders: ['*'],
//               AllowedMethods: ['HEAD', 'GET', 'PUT', 'POST', 'DELETE'],
//               AllowedOrigins: ['*'],
//               ExposeHeaders: ['ETag'],
//             },
//           ],
//         },
//       }),
//     );
//   } catch (err) {
//     console.log('Error', err);
//   }
// };

// putBucketCors();

export const getKeysByBucket = async () => {
  try {
    const files = await s3Client.send(
      new ListObjectsCommand({ Bucket: S3_BUCKET }),
    );

    const keys = files.Contents.map((item) => item.Key);

    return keys;
  } catch (err) {
    console.log('getKeysByBucket Error : ', err);
  }
};

export const getFileByKey = async (getBucketParams: GetObjectCommandInput) => {
  try {
    const data = await s3Client.send(new GetObjectCommand(getBucketParams));

    return data;
  } catch (err) {
    console.log('getFileByKey Error : ', err);
  }
};

export const uploadFile = async (uploadBucketParams: PutObjectRequest) => {
  try {
    const fileName =
      uploadBucketParams.ContentDisposition.split('filename=')[1];

    const upload = r2ClientV2.upload(uploadBucketParams, (err, data) => {
      console.log(`${i} / ${keys.length} Complete!`);
      fs.appendFileSync(
        'log.txt',
        `${fileName.padEnd(50, ' ')} ${i++} / ${keys.length} Complete!\n`,
      );
    });

    // file upload progress, progress.total is not working
    upload.on('httpUploadProgress', (progress) => {
      console.log(
        `${fileName.padEnd(50, ' ')} progress : ${
          (progress.loaded / uploadBucketParams.ContentLength) * 100
        }`,
      );
    });
  } catch (err) {
    console.log('uploadFile Error : ', err);
  }
};

const keys = await getKeysByBucket();

let i = 1;

keys.forEach(async (Key) => {
  const getBucketParams = {
    Bucket: S3_BUCKET,
    Key,
  };

  const { ContentLength, ContentDisposition, Body, ContentType } =
    await getFileByKey(getBucketParams);

  const uploadBucketParams: PutObjectRequest = {
    Bucket: R2_BUCKET,
    Key,
    ContentLength,
    ContentDisposition,
    Body,
    ContentType,
  };

  uploadFile(uploadBucketParams);
});

알려진 에러

A client error (RequestTimeTooSkewed) occurred when calling the ListObjects operation: The difference between the request time and the current time is too large.

50개의 파일을 병렬로 업로드하던 중 이 에러가 발생했으며 원인은 적혀있듯이 요청을 보낸 시간과 현재 시간의 차이가 15분(900000ms)보다 커지면 발생한다. 50개의 업로드 요청을 한번에 병렬로 보냈지만 인터넷 문제, 최대 업로드 처리가 가능한 파일 수 문제 등이 원인일 것이라 예상했으며 병렬처리로 보낼 파일의 갯수를 적당히 조절하는 것으로 해결했다.

MalformedXML: The XML you provided was not well formed or did not validate against our published schema.

사실 업로드 자체는 v3의 putObjectCommand를 사용하면 말끔히 할 수 있지만 이쪽 시나리오에서는 업로드 진행도를 클라이언트에게 보내야했고 R2에서 v3의 upload는 요청이 제대로 이루어지지 않아 400코드를 뱉으며 업로드에 실패했다. R2에선 아직 S3 API를 전부 완벽히 구현해내지 못했으며 특히 v3의 upload는 작동을 아예 안했고 v2의 upload에선 upload.on에서 주는 progress.total이 작동하지 않았다. 추후엔 사라질 문제일 것이라고 생각되지만 현시점의 해결 방법을 기록하기 위해 이 글을 작성했다.

import { Logger } from '@nestjs/common'
import { MessageBody, SubscribeMessage, WebSocketGateway, WebSocketServer, WsResponse } from '@nestjs/websockets'
import { Server } from 'socket.io'

interface loginMessage {
  user: string
}

interface roomMessage extends loginMessage {
  message: string
}

@WebSocketGateway(8080, { transports: ['websocket'] })
export class EventGateway {
  @WebSocketServer()
  server: Server
  logger = new Logger()

  @SubscribeMessage('ClientToServer')
  handleClientToServer(@MessageBody() { user }: loginMessage) {
    this.logger.log(`Login: ${user}`)
    this.server.emit('ServerToClient', `로그인 환영: ${user}`)
  }

  @SubscribeMessage('Room1')
  handleRoom1(@MessageBody() { user, message }: roomMessage): WsResponse {
    this.logger.log(`Client: ${user} Message: ${message}`)
    this.server.emit(`${user}'s AlertHandle`, 'new!')
    // this.server.emit('Room1', `${user}: ${message}`) // Room1을 구독하고 있는 전체에게 emit (broadcast)
    // return `${user}: ${message}` // Room1으로 요청을 보낸 특정 클라이언트에게만 Room1으로 emit
    return { event: 'Room1All', data: `${user}: ${message}` } // event로 emit
  }
}

서버측에서 클라이언트로 다시 메시지를 전송하는 방법으로 3가지가 있다.

1. this.server.emit('event', data)

Socket.io에서 기본적으로 제공해주는 방식으로 event로 emit을 날려 event를 Listen(on) 하고있는 모든 클라이언트에게 메시지를 보낸다. 정상적으로 해당 방에 존재하는(on 하고 있는) 모든 사람에게 메시지를 전송했다.

2. return data

NestJS에서 Gateway로 만든 함수에선 return을 이용해서도 메시지를 전송할 수 있었다. 여기서 return으로 처리가 가능하려면 Client측에서도 콜백함수를 열어줘야한다.

// client code
                                        //이쪽으로 return이 넘어오는거!!
socket.emit('events', { name: 'Nest' }, (data) => console.log(data));

그저 클라이언트 측에서 보낸 emit에 대한 응답을 전송하며 이 응답은 클라이언트에서 사용한 emit의 콜백 함수로 return된다. 따로 특정 이벤트에 emit을 날리진 않았다.

3. return { event, data } (Multiple Responses?)

뭔가 return으로도 특정 이벤트에 대한 응답을 보낼 수 있도록 Nestjs쪽에서 제공해주지 않을까? 하고 찾아다니다 공식 문서에 있는 Multiple Responses를 찾게 된다.

특정 event를 따로 지정할 수 있다는 점으로 2번과는 다르긴 하다. 하지만 결국 이 방법도 모든 클라이언트에게 emit을 보내진 않았고 요청을 보낸 클라이언트에게만 emit이 전송되는 것을 확인했다. 공식 문서의 설명을 봤을땐 뭔가를 Multiple하게 보낸다는 것 같은데... 달라지는 점은 event를 재정의해서 보낼 수 있다는 점 밖에 찾지 못했다. 전혀 All이 아닌 모습... 분명 Multiple Responses라고 적은 것에는 이유가 있을 것 같은데 뭔지 찾지 못했다..

결론은 return을 쓰는게 아니라 server.emit(boradcast)을 사용해서 Socket.io 객체의 메소드를 사용하는 방법으로 채팅방에 있는 모두에게 메시지를 전송시키도록 구현하게 될 것 같다.

return을 사용하는 방식은 event를 다시 적지 않아도 되고 간편하고 return type도 확인할 수 있었지만 요청을 보내왔던 클라이언트에게만 emit을 보내기 때문에 1:1 통신 시나리오에서만 사용할 수 있을 것 같다. 분명 다른 방법이 있을 것만 같지만 찾지 못했다... Multiple Response라고 명명한 의미를 잘 찾지 못해 아쉬웠다. 콜백에 대한 응답 + 특정 이벤트에 대한 응답을 보낼 수 있는 것을 두고 Multiple이라고 칭한 것일까..?

어쩌다보니 입사 초기부터 사내에 있던 Angular/Flask 웹 사이트를 React/Nestjs로 마이그레이션 하는 작업을 맡게되었다. 이유는 프론트/백 언어 통합(TS)으로 한가지 언어만으로도 둘 다 관리할 수 있도록 접근성 향상과 비용 절감도 있었지만 역시 제일 큰 이유론 레거시 코드가 정말 정말 정말 엉망이었다... 의존성도 다 꼬여있으며 뷰 로직과 핵심 비즈니스 로직, 라우팅, DB와 통신/조작 등 수많은 로직을 하나의 함수에서 모조리 처리하고 있었다....

나름 코딩은 어렸을 때부터 했다고 생각했지만 실무에 들어오고보니 4달 전까지도 웹개발 프레임워크/라이브러리를 "Hello World!" 수준밖에 하지 못했던 것 같다.

지금은 React로 재사용성을 고려하며 컴포넌트를 만드는 법을 알게 되었고 지겹도록 배웠던 OOP가 왜 존재하게 되었고 이걸 지키는게 왜 중요한지 뼈저리게 느끼게 되었다.

내가 입사하면서부터 시작하게 된 사내 스터디로 클린 코드/아키텍처를 공부하고 반면교사로 레거시 코드를 보며 왜 다른 사람들이 보기 쉽게 코딩을 해야하는지 깨달고 직접 체험하면서 '여태 나는 반도 못지켰구나. 내가 짠 코드들은 유지보수가 불가능했구나.' 라는 사실을 새삼 깨달았다. 나름대로 가독성 좋게, 다른 사람도 이해할 수 있게 짰다고 생각했지만 현실은 너무나도 달랐던 것이었다. 그리고 다양한 아키텍처, 디자인 패턴을 공부하며 제대로 지키지 못했을 때 오는 문제점들을 스스로 겪으면서 반성도 많이 하게됐다.. 그저 구현만 잘 하면 되지 라고 생각했었는데 실무는 너무나도 달랐고 진짜 개발자는 뭔지, 좋은 설계는 어떤건지 많이 고민하고 배워가고 있는 것 같다.

3개월만에 굉장히 많은 경험들을 하게 되었고 작업을 위해 알고 있었어야 할, 앞으로도 더 잘 알아야 할 지식들이 굉장히 많아졌다.

2주 전에 겨우 React 마이그레이션 작업이 1차적으로 완료되었고 이번주는 레거시 백 코드를 읽으며 어떤 기능들을 가져갈지 정리하며 DB 설계를 들어갔다. 백엔드에선 정말 제일 밑바닥 설계부터 들어가야되니 기대 반 걱정 반이다. 클린 아키텍처를 기반으로 한 설계를 진행할 것이며 가능한 테스트도 작성해보고 CD/CI도 구현해 볼 것 같다. 기간 내로 다 할 수 있을지 모르겠지만 정말 다양한 부분들을 실무로 접해볼 수 있을 것 같아 기대가 크다.

'SubmitHandler' 형식의 인수는 'SubmitHandler' 형식의 매개 변수에 할당될 수 없습니다. 'CommonTable' 형식은 'T' 형식에 할당할 수 없습니다. 'CommonTable'은(는) 'T' 형식의 제약 조건에 할당할 수 있지만, 'T'은(는) 'CommonTable' 제약 조건의 다른 하위 형식으로 인스턴스화할 수 있습니다. ts(2345)

여기서 T는 extends CommonTable을 했기 때문에 들어갈 수 있다고 생각할 수도 있다. CommonTable과 완전히 일치한다면 들어갈 수 있겠지만 확장인 경우 CommonTable에 속하지 않아 들어갈 수 없다.

MUI & RTK

기본 뼈대가 되는 UI작업을 MUI을 사용해서 하기로 했다.

 <Dialog open={open} onClose={onClose}>
     ...
                  <TextField label="이름" value={name} />
                  <FormControlLabel
                    label="접근 제어"
                    control={<Checkbox checked={!!accessControl} onChange={handleCheck} />}
                  />

              <Button sx={{ width: 100 }} color="primary" variant="contained">
                {Strings.contents.TEXT_CONTENTS_REGISTRY_BUTTON}
              </Button>
     ...
 </Dialog>

여기서 실제 데이터인 name과 accessControl은 Redux store를 사용해 관리하고 있다. (useSelector) handleCheck로 accessControl을 관리한다. (useDispatch)

이제 이 폼에서 버튼을 누르면 TextField와 Checkbox에 있는 값을 불러와 원래 값에 dispatch를 해야하는데 이를 처리하는 것을 RHF을 사용해 하려한다.

MUI & RTK + RHF

RHF는 기본적으로 직접 제어되지 않는 요소에 사용되지만 직접 제어를 하는 외부 UI 라이브러리와 같이 사용하기 위해선 Controller를 사용하면 된다. 라고 써있지만 실제로 찾아보면 이걸 도대체 어떻게 써야하는지 감이 잘 안오고 어떻게 써보더라도 값이 제대로 넘겨지거나 수정되지 않는 현상을 볼 수 있다.

  const dispatch = useDispatch<AppDispatch>()
  const categoryDetail = useSelector((state: RootState) => state.categoryDetail.data)
  const categoriesViewList = useSelector((state: RootState) => state.categoryView.data)
  const [open, setOpen] = useState(false)
  const { control, handleSubmit, reset } = useForm<Tables>()

  useEffect(() => {
    if (categoryDetail.id !== UNSET) {
      setOpen(true)
    }
  }, [categoryDetail, categoriesViewList])

  //중요!!!
  useEffect(() => {
    reset(categoryDetail)
  }, [categoryDetail])

  const onClose = () => {
    setOpen(false)
    dispatch(setCategory(initialState.data))
  }

  const onSubmit: SubmitHandler<Tables> = data => {
    ...
    //Controller의 name=""부분
    const { name, accessControl } = data
    ...
  }

여기서 useEffect()에 있는 reset(data) 부분에 (RTK에서 받아온)실제 데이터를 넣어줘야 RHF에서도 해당 데이터를 사용할 수 있다. RHF 내부에서 사용하는 상태에 Redux 값을 복사해주는 핵심 부분이며 Redux의 값이 변할때마다 다시 초기화해줘야 하니 의존성에도 잊지말고 넣어주자. 사실 이부분을 넣어주지 않아서 계속 리덕스 스토어에 있는 값과 RHF에 있는 값이 따로놀아서 n시간동안 문제였다...

1. useForm 안에 따로 저장소가 있으며 useForm() 안에 인수로 기본값 처리 가능.
2. reset(데이터)로 RHF의 저장소에 직접 저장 가능.
3. render의 콜백에서 받아온 field.value 안에 해당 데이터가 존재하며 접근 가능.
4. render 안에서 field.onChange를 사용하면 field.value의 값 변경 이벤트를 지정할 수 있으며 기본적으로 제공되는 이벤트가 존재(이건 MUI쪽에서 받아오는 거 같은데 정확하진 않다.)

<Dialog open={open} onClose={onClose}>
      ...
                  <Controller
                    name="name"
                    control={control}
                    defaultValue={name}
                    render={({ field }) => <TextField {...field} />}
                  />
                  <Controller
                    name="accessControl"
                    control={control}
                    render={() => (
                      <FormControlLabel
                        control={<Checkbox checked={!!accessControl} onChange={handleCheck} />}
                        label="접근 제어"
                      />
                    )}
                  />

              <Button
                type="submit"
                sx={{ width: 100 }}
                color="primary"
                variant="contained"
                onClick={handleSubmit(onSubmit)}
              >
               ...
</Dialog>

<Controller
  name="name"
  control={control}
  defaultValue={name}
  render={({ field }) => <TextField {...field} />}
  />

위와 같이 Controller에서 RHF의 onSubmit 함수에서 인수로 받아와 처리할 변수 이름을 name=에 집어넣고 control=에 useForm에서 받아온 control을 넣어준다.

render={({ field }) => <TextField {...field} />}

TextField의 경우 dispatch를 사용하지 않으니 체인지 이벤트에 관해서 기본적으로 제공해주는 onChange 이벤트(handleCheck)로 값을 수정하면 된다.

render={() => (
  <FormControlLabel
    control={<Checkbox checked={!!accessControl} onChange={handleCheck} />}
    label="접근 제어"
    />
)}

하지만 Checkbox의 경우 눌렀을때 값이 변하는 이벤트를 dispatch로 보내줘야 했기 때문에 onChange에 dispatch 이벤트를 넣어줘야 한다.

MUI에서도 기본적인 컨트롤을 제공해주고 RHF에서도 따로 컨트롤이 있었으며 Redux에 저장되어있는 값으로 기본값을 넘겨줘야 했기 때문에 여러 라이브러리의 공식문서를 다 참고해야 했다. 사실 크게 어려운부분도 아니었던 거 같은데 라이브러리가 어떻게 동작하는지, 어떻게 사용해야하는지 몰라서 시간을 굉장히 잡아먹었던 거 같다. 아직도 완전히 알진 못하는 거 같고 역시 외부라이브러리를 사용하는데엔 장점과 단점이 있는 거 같다.

나중에 다시 보니 정말 개판이다... 리덕스에서 받아온 값은 useForm의 초기에만 기본값으로 사용하기 위해 넘겨주면 되며 이후 변경사항은 submit을 성공적으로 수행하면 서버에 데이터가 실제로 변했을 것이기 때문에 다시 서버에서 업데이트를 받으면 됐을 것 같다.

'onPageChange' PropType is defined but prop is never used eslint(react/no-unused-prop-types)

export interface TableFooterProps {
  tableList: CategoryView[]
  page: number
  rowsPerPage: number
  //이하 세개의 함수에서 에러
  onPageChange: (page: number) => void
  onRowsPerPageChange: (page: number) => void
  setEmptyRows: (page: number) => void
}

export default function TableListFooter(props: TableFooterProps) {
  const { tableList, page, rowsPerPage } = props
  const {
    TablePaginationActionsComponent,
    handleChangePage,
    handleChangeRowsPerPage,
  } = useTableFooter({ ...props, count: tableList.length })

  return (
    ...
  )
}

React-TS 컴포넌트에서 프롭스로 받아오는 함수를 사용하지 않으면 해당 에러가 발생한다. 이 코드에선 프롭스로 넘겨받은 함수를 또다시 다른 함수에 프롭스로 넘겨주는데 구조 분해 할당을 사용해서 넘겨줬더니 현재 함수에선 한번도 사용하지 않았다고 불평하는 것이었다. 이를 해결하기 위한 방법으론 여러가지가 있었다.

props를 직접 하나하나 할당해주기

export default function TableListFooter({
  tableList,
  page,
  rowsPerPage,
  onPageChange,
  onRowsPerPageChange,
  setEmptyRows,
}: TableFooterProps) {
  const {
    TablePaginationActionsComponent,
    handleChangePage,
    handleChangeRowsPerPage,
  } = useTableFooter(
    tableList,
    page,
    rowsPerPage,
    onPageChange,
    onRowsPerPageChange,
    setEmptyRows,
  )

이렇게 하나하나 직접 명시해주면 어찌됐든 사용은 했기때문에 위의 에러도 사라지고 올바르게 동작할 수 있다. 하지만 코드가 매우 길어지고 더러워진다. 사실 원래 코드의 상태는 이와 같았으며 이런 현상을 막기 위해서 props를 일일이 푸는 대신에 묶어서 일부분만 사용하는 방법을 찾는 중이었고 그렇기때문에 이 방법으로 돌아가고 싶진 않았다.

eslint 설정에서 끄기

...
"rules": {
  ...
  "react/no-unused-prop-types": ["off"],
  ...
}
...

제일 간단한 해결방법이지만 잠재적 문제점이 발생할 수도 있다고 생각했기 때문에 내키지 않았다.

✅ 사용하지 않는 함수를 할당만 하고 넘기기

export default function TableListFooter(props: TableFooterProps) {
  const { tableList, page, rowsPerPage, ..._ } = props
  const {
    TablePaginationActionsComponent,
    handleChangePage,
    handleChangeRowsPerPage,
  } = useTableFooter(props)

현재는 이 방법을 선택했다. Go 등의 언어에선 사용하지 않는 변수를 _로 처리하기도 하고 이 방법 외엔 가독성이나 안정성면에서 깔끔하지 못하다고 생각했다. (지역변수) _가 선언되었지만 사용하지 않았다는 워닝이 발생하긴 하지만 이 선에서 타협하기로 했다.

구현만 하는 것보다 코드를 얼마나 보기 좋게 만드냐를 고민하는 시간이 훨씬 더 많아졌으며 이런 일을 줄이기 위해 처음부터 설계나 규칙을 얼마나 잘 맞춰야 하는지 깨달았다.

vi ~/.zshrc ~/.bashrc에서 값을 가져와 bashrc -> zshrc 해줬다.

if [ -f /etc/zshrc ]; then
        . /etc/zshrc
fi

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

source ~/.zshrc 후 정상적으로 npm이 작동되는 것을 확인했다.

로컬

큰 순서 틀

• db 올리기 (DB 접속하기 : psql -U 유저이름 -d DB이름)

• init 올리고 컨테이너 들어가서 Flask CLI로 DB 설정해주기 (Readme.md)

  • flask manager add (유저이름) (패스워드) = 로그인페이지 admin

• 프론트 백 Traefik 설정해주고 올리기

  • docker-compose.yaml 수정

    labels:
        - traefik.frontend.rule=Host:요청을 받을 url (CNAME)
        - traefik.port=요청 url에 대한 포트
        - traefik.enable=true
        - traefik.frontend.entryPoints=http (여기선 http)
        #- traefik.backend=~~ 없어도 동작. 이름 명명

  • traefik.toml 수정

    logLevel = "INFO"
    [api]
      entryPoint = "dashboard"
      dashboard = true
      debug = true
    

  [entryPoints]

  [entryPoints.http]
      address = ":80"
  [entryPoint.dashboard]
      address = ":8080"

  [docker]

  endpoint = "unix:///var/run/docker.sock"
  exposedByDefault = true
  usebindportip = true
  domain = 메인 도메인 (A)

AWS

• db 올리기 -> RDS 설정

  • dev.toml

    ...
    [database]
    connector = 'postgresql'
    host = '' #RDS 호스트
    port = 5432
    user = '' #RDS에서 적은거
    password = '' #RDS에서 적은거
    name = ''
    ...

  • Postgres DB 리커버리

    recovery.sh

    #!/bin/bash
    

  cd dbcommand

  USER= PASSWORD= HOST_URL= DB= DB_HOST=postgresql://${USER}:${PASSWORD}@${HOST_URL}/${DB} BACKUP_FILE=~.sql psql -f ${BACKUP_FILE} ${DB_HOST}

  cd .. ```

• init 올리고 컨테이너 들어가서 Flask CLI로 DB 설정해주기 (Readme.md)

  • flask db upgrade, flask manager add '' '' 까지만 (위에 리커버리에서 나머지 수행)

• S3 & cloudfront 설정

  • environment에 APIHost/cloudfront 설정, angular.json에 추가
  • dev.toml

    ...
    [asset]
    host = '' #cloudfront
    ...

• 프론트 백 Traefik 설정해주고 이미지 빌드하기 -> ECR 생성하고 ECS에 올리기

  • 프론트 prod 빌드 (./front-build build-prod)

    #!/bin/bash
    

  cd cms-front

  if [ "${1}" == "build-prod" ] then

  ng build -c ...-prod;

  elif [ "${1}" == "build-dev" ] then

  ng build -c ...-develop;

  elif [ "${1}" == "serve" ] then

  ng serve -c ...-develop;

  fi

  cd ..

  - ECR 생성
    - AWS CLI 설치 : https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html
    - AWS CLI configure 설정하기
    - .env 수정하기

  ECR_HOST= REPOSITORY_PREFIX= FRONT=front:1.0.1 BACK=back:1.0.0 REGION=ap-northeast-2

  - docker-compose.yaml 수정
    - traefik, depends_on 설정 제거 (ECS에서 추가)
    - redis, worker 등 로컬에서 빌드가 필요하지 않은 부분 제거 (ECS에서 추가)
    ``` yaml
    version: '3.2'
  
    volumes:
      media-persist: {}
      redis-persist: {}
  
    services:
      cms-back:
        image: ${ECR_HOST}/${REPOSITORY_PREFIX}${BACK}
        build: ./cms-back
        container_name: cms-back
        volumes:
          - media-persist:/tmp
          - ./config:/etc/app:ro 
        ports:
          - "5000:5000"
        environment:
          - FLASK_APP=application/bootstrap.py
          - FLASK_ENV=development
          - CONFIG_FILE=/etc/app/service.toml
  
      cms-front:
        image: ${ECR_HOST}/${REPOSITORY_PREFIX}${FRONT}
        build: ./cms-front
        container_name: cms-front
        ports:
          - "8001:80"

  • ECR에 이미지 푸시 ECRPush.sh (호스트에서 AWS CLI을 사용해 docker-compose push)

      #!/bin/bash
    source .env;
    
    if [ "${1}" == "init" ]
    then 
        docker-compose -f docker-compose-init.yaml up --build
    
    elif [ "${1}" == "push" ]
    then
        docker-compose --env-file=.env build; 
        aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin "$ECR_HOST"
        docker-compose push
    fi

  • ECS로 이미지 실행하기

    • ECS 클러스터 만들기
    • ECS 컨테이너 인스턴스 생성
    • 가비아 DNS 설정 (A, CNAME:cms, manager)
    • 컨테이너 인스턴스에서 DB(RDS) 연결 확인 (EC2에 로그인해서 RDS에 접근이 되는지)
    • CONFIG FILE 전달 (fileReceive.sh -> scp 명령어)

      #!/bin/bash
      

    cd config

    SERVICE_CONFIG=service.toml TRAEFIK_CONFIG=traefik.toml GUNICORN_CONFIG=gunicorn-config.py CELERY_CONFIG=celeryconfig.py EC2_HOST=~~

    scp -i .pem ${GUNICORN_CONFIG} ${SERVICE_CONFIG} ${TRAEFIK_CONFIG} ${CELERY_CONFIG} ${EC2_HOST}:

    cd ..

    - CONFIG FILE 경로 수정 (pdf 참고)
    - 작업 생성, ECS 서비스 생성, 작업 실행 (이전 성공한 서비스 참고해서 설정하기)
    

이슈 트래커

No space left on device 에러

도커 시스템 캐시가 꽉 차서 실행이 안되는 에러였다.

docker system prune #해결
docker volume prune

#To see all volumes
docker volume ls

#To show docker disk usage
docker system df

참고 : https://blockchainstudy.tistory.com/59

https 관련 접속 불가

traefik에서 자동으로 생성해주는 ssl이 가끔 깨진다고 한다. /opt/letsencrypt/acme.json 확인

백엔드 꺼지는 503, Worker ~ 에러

werkzeug.exceptions.ServiceUnavailable: 503 Service Unavailable: The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

{/usr/src/app/application/controllers/registry.py:46} ERROR - /registry: base data not found. run flask init device

docker-compose-init.yaml 작업을 안했을 때 발생하는 에러였다. Readme에 적혀있는 작업을 꼭 하자...

메모장

업데이트 했을 때 확인해야 하는 것:

front 빌드 (front-build build-prod) .env 버전 태그 바꾸기 이미지 푸시 (. command.sh push) 작업에서 이미지 버전 태그 수정한 새 작업 등록 서비스 업데이트 기존 작업 중지

.sh파일 실행파일로 변환하기

mv a.sh a (이름 바꾸기) chmod 755 a 실행: ./a

갑자기 한번에 Traefik, ECS, ECR, RDS, S3, Cloudfront 등등 많은 기술들을 접하게 됐지만 하나하나 따라가보니 신기하고 재밌었다. 하지만 베이스 지식은 튼튼히 해야겠다.

version: "3.8"
services:
  postgres:
    container_name: postgres
    image: "postgres:14.3"
    volumes:
      - postgres:/var/lib/postgres
    ports:
      - 5432:5432
    environment:
      - POSTGRES_USER=postgres #psql -U 유저
      - POSTGRES_PASSWORD=test #pgAdmin password
      - TZ=Asia/Seoul

  pgadmin:
    container_name: pgadmin
    image: dpage/pgadmin4
    ports:
      - 8088:80
    environment:
      - PGADMIN_DEFAULT_EMAIL=test@test.com #address:8088 인덱스페이지 로그인
      - PGADMIN_DEFAULT_PASSWORD=test #address:8088 인덱스페이지 로그인
      - TZ=Asia/Seoul
    depends_on:
      - postgres

volumes:
  postgres:

docker.env

FLASK_APP=server.py
FLASK_ENV=development
FLASK_DEBUG=True
FLASK_HOST=localhost
FLASK_PORT=4000

SECRET_KEY=secret

PG_HOST=postgres #DB 주소. 여기선 도커에서 생기는 postgres를 지정 (위에서 postgres: 부분)
PG_PORT=5432
PG_DB=postgres
PG_USER=postgres
PG_PASSWORD=test

docker-compose-flask.yaml

version: "3.8"
services:
  flask:
    container_name: flask
    env_file:
      - ./docker.env
    build:
      context: ./src
    ports:
      - 4000:4000
    volumes:
      - ./:/app

/src/Dockerfile

FROM python:3.10.5

WORKDIR /app

COPY requirements.txt requirements.txt

RUN pip install -r requirements.txt

COPY . .

WORKDIR /app/src
#위 과정중 도커 내부에도 똑같이 /src 폴더가 생김

CMD ["python", "-m", "flask", "run", "--host=0.0.0.0", "--port=4000"]
#이 앱은 도커 내부의 localhost에서 실행되기 때문에 컨테이너 외부에서 서비스를 사용하기 위해

한시간 정도를 날려먹고나서야 확실하게 이해하고 넘어가야 한다는 것을 다시금 깨달았다..

rtps-simple-server의 Makefile :

define DOCKERFILE_RUN
FROM $(BASE_IMAGE)
RUN apk add --no-cache ffmpeg
WORKDIR /s
COPY go.mod go.sum ./
RUN go mod download
COPY . ./
RUN go build -o /out .
WORKDIR /
ARG CONFIG_RUN
RUN echo "$$CONFIG_RUN" > rtsp-simple-server.yml
endef
export DOCKERFILE_RUN

define CONFIG_RUN
#rtspAddress: :8555
#rtpAddress: :8002
#rtcpAddress: :8003
#metrics: yes
#pprof: yes

paths:
  all:
    runOnDemand: ffmpeg -re -stream_loop -1 -i ./public/WS.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream

#  proxied:
#    source: rtsp://192.168.2.198:554/stream
#    sourceProtocol: tcp
#    sourceOnDemand: yes
#    runOnDemand: ffmpeg -i rtsp://192.168.2.198:554/stream -c copy -f rtsp rtsp://localhost:$$RTSP_PORT/proxied2

#  original:
#    runOnReady: ffmpeg -i rtsp://localhost:554/original -b:a 64k -c:v libx264 -preset ultrafast -b:v 500k -max_muxing_queue_size 1024 -f rtsp rtsp://localhost:8554/compressed

endef
export CONFIG_RUN

run:
    echo "$$DOCKERFILE_RUN" | docker build -q . -f - -t temp \
    --build-arg CONFIG_RUN="$$CONFIG_RUN"
    docker run --rm -it \
    --network=host \
    -v /home/ec2-user/rtsp-simple-server/public:/public \
    temp \
    sh -c "/out"

DOCKERFILE_RUN 에서 Dockerfile 추출 : RUN echo "$$CONFIG_RUN" > rtsp-simple-server.yml을 쉽게 하기위해 CONFIG_RUN 부분을 따로 rtsp-simple-server-temp.yml로 분리한다

FROM golang:1.18-alpine3.15

RUN apk add --no-cache ffmpeg

WORKDIR /s

COPY go.mod go.sum ./

RUN go mod download

COPY . ./

RUN go build -o /out .

WORKDIR /

COPY ./rtsp-simple-server-temp.yml ./rtsp-simple-server.yml

CMD ["sh", "-c", "/out"]

docker-compose.yaml

version: "3.8"
services:
  rtsp-simple-server:
    build: .
    volumes:
      - ./public:/public
    ports:
      - "8554:8554"

public 폴더에 재생시킬 동영상 넣기.

//rtsp-simple-server.yml
...
path:
  all:
    runOnDemand: ffmpeg -re -stream_loop -1 -i ./public/WS.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream
...
run:
  ...
  -v /home/ec2-user/rtsp-simple-server/public:/public \
  ...

하지만 완성적으로 실행하기까지 많은 시행착오를 겪었으며 이를 정리해보려한다.

runOnDemand에서 localhost에 ffmpeg 스트리밍을 진행하지 못하는 문제

이 문제는 git clone을 하기 전에 rtsp-simple-server 공식 문서(README)에 적혀있는대로 docker run --rm -it --network=host aler9/rtsp-simple-server 로 도커허브에 있는 이미지를 사용했을 때 나타났다. 원인은 yml파일을 -v 옵션으로 복사했을 때 localhost를 변환된 주소로 짚어주지 않고 로컬(EC2)주소를 사용했기 때문이라고 생각했다. git clone을 사용해 코드를 불러와 Makefile로 직접 도커 이미지를 생성하는 과정에 yml파일을 설정해줌으로 해결했다. ps. Makefile에서 yml을 직접 echo를 이용해 집어넣어 주는 방식인 거 같다.

연결은 되지만 ffmpeg이 즉시 꺼지는 문제

이 문제는 ffmpeg 스트리밍 실행시 400에러와 함께 rtsp서버에 올라가지도 않는 현상과 같이 일어났는데 아마 rtsp-simple-server 내부의 어떤 파일이 깨지거나 했을 문제였을거라 생각한다. 다시 git clone을 진행해 해결했다.

make run 빌드중 계속 실패하는 문제

Makefile로 인해 docker 처리를 하던 도중 에러가 발생했고 그 에러를 해결했음에도 make run을 입력하면 같은 에러로 계속 실패했었다. 이는 이미 빌드 중에 docker image나 container, volume이 생성되었고 이들을 캐시했으므로 발생하는 오류였다. 해결하기 위해 캐싱된 이미지와 컨테이너, 볼륨을 강제로 삭제했다. (사실 도커 기본 지식이 있었다면 쉽게 해결했을 일이었다.)

적고나니 생각보다 적은 문제들이 자잘하게 일어난 것처럼 보이지만 실제론 에러가 에러를 낳고 한 문제들마다 많은 시간을 소모했다. 앞으로 똑같은 문제에 다시 당하고 싶지 않아 글을 남긴다.

모든 중지된 컨테이너 삭제 docker rm $(docker ps -a -q)

모든 이미지 삭제하기 docker rmi $(docker images -q)

모든 매핑되지 않은 볼륨 삭제하기 docker volume rm $(docker volume ls -f dangling=true -q)

컨테이너 로그 확인 (최근 10개) docker logs --tail 10 (컨테이너 이름)

rtsp 서버를 열어서 android에서 접속해보는 과제를 진행중이었는데 rtsp UDP로 접속한 영상이 별로 큰 사이즈도 아닌데 계속 끊기면서 패킷 누락, Audio Sync 에러가 발생했다. 이 문제가 발생한 원인으로 여러가지를 생각해보며 테스트해봤다.

• MAC M1이라서 발생하는 문제? 아마 이 이유가 없지는 않았겠지만 핵심적인 문제점은 아니었다. 실제로 윈도우에서 돌린 서버와 M1에서 돌린 서버를 비교했을 때 심각한 차이를 확인하진 못했다.
• 라우터의 문제? 사내 라우터를 거쳐가며 생기는 문제일 수도 있다고 생각했었으나 이것 또한 치명적인 문제점은 아니었다. 끊기는 파일은 여전히 끊겼다.
• 영상파일 자체의 문제? 결국 이 문제임이 밝혀졌으며 인터넷에서 아무거나 막 주워온 영상이라서 인코더 정보도 들어있지 않았으며 해당 파일에서만 이 문제가 심각하게 발생하는 것을 확인했다...

이 외에 인터넷 or M1의 문제라고 생각되어서 AWS EC2에 rtsp 서버를 띄워서 테스트도 해봤으나 문제의 그 파일로 띄웠을 때 아예 영상이 20초에 한번쯤밖에 받지 못하는 절망적인 결과도 확인했었다......

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash . ~/.nvm/nvm.sh nvm install 14.18.1 (노드 버전)

sudo yum install docker sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod 666 /var/run/docker.sock (도커 컴포즈 권한문제)

or

sudo amazon-linux-extras install docker

sudo systemctl start docker

sudo 없이 도커 명령어 sudo usermod -aG docker ec2-user

source (name).sh

pyenv install -list = pyenv로 설치할 수 있는 목록 표시 pyenv versions = 설치되어있는 모든 버전, 가상환경 목록과 현재 선택되어있는 상태 *표시 pyenv virtualenv (이름) = 가상환경 생성 pyenv shell (이름) = 버전(가상환경) 선택