찾아보니 Koa joi 의 stripUnKnown 같은 기능을 하는 whitelist 옵션이 있다는 것을 알게 되어 사용법과 사용 결과를 정리해본다.

whitelist 적용 방법

적용 방법은 매우 간단하다. ValidationPipe 의 옵션으로 넣어주면 된다.

매서드 단위로도 작성이 가능하지만 나는 글로벌로 적용했다.

  app.useGlobalPipes(new ValidationPipe({ whitelist: true }));

결과

• whitelist: false 일 경우 dto 에 정의하지 않은 test property 가 body params 로 함께 들어와버린 것을 확인할 수 있다.

• whitelist: true 일 경우

dto 에 정의하지 않은 test property 가 제거되어 body params 로 들어온다.

• 별도의 매핑을 지정하지 않았을 경우, 처음 인덱스를 생성하고 데이터를 입력하면 elasticsearch 가 자동으로 동적 매핑을 진행 → 동적 매핑의 경우 원하는대로 검색이 동작하지 않을 수도 있기 때문에 mapping 을 따로 지정해주는 것을 권장한다. (Explicit mapping)

• 동적 매핑 시 text 타입은 text 와 keyword 두 가지의 멀티 필드를 생성한다.멀티 필드를 지정할 경우, 필드 개수만큼 용량이 더 소모되므로 keyword 로만 관리할 필드는 keyword 필드, text 로만 관리할 필드는 text 필드로 하는 게 좋다.

참고

Explicit mapping

• 인덱스 생성 시 커스터마이징 해서 지정해주는 매핑

• 데이터가 들어있을 경우 매핑 변경은 불가능하기 때문에 인덱스를 지우고 새로 mapping 을 해야한다.

참고

특정 필드의 매핑 바꾸기

1. 인덱스를 만들고 데이터를 하나 넣어서 dynamic mapping 을 생성한다.
2. 해당 mapping 을 불러와서 가공한다.
3. 기존 인덱스를 지우고 다시 인덱스를 생성할 때, 시 가공한 mapping 을 넣어서 explicit mapping 으로 만든다. PUT http://localhost:1111/haulla-account

// body
{
  "mappings": {
    "properties": {
      "accountManagerId": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword",
            "ignore_above": 256
          }
        }
      },
      ...      
      "role": {
        "type": "keyword", // 타입을 text -> keyword 로 변경
        "fields": {
          "keyword": {
            "type": "keyword",
            "ignore_above": 256
          }
        }
      },
     ...
      "vertical": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword",
            "ignore_above": 256
          }
        }
      }
    }
  }
}

새로 만든 role 타입이 keyword 로 mapping 된 것을 확인할 수 있다.

리액트로 프론트엔드 화면 작업을 하던 중 위와 같은 에러를 만나게 되었다.

랜더링에 문제가 있다는 내용인 것 같아서 찾아보니 tsx 에 바로 오브젝트를 때려 넣어서 생긴 문제였다.

plan.collectedWastes 는 { wasteTypeIdx: number, amount: number }[] 타입의 Object 이기 때문에 바로 랜더링 하도록 적었더니 에러가 난 것이다.

정확하게 어떤 타입인지 랜더링으로 확인하려고 대충 넣은 거였는데 에러가 났다. ㅎ 해당 내용을 제거하니 정상적으로 랜더링이 되었다.

analyzer 구성

텍스트 분석 과정

• 애널라이저가 수행

• 캐릭터 필터링 → 토크나이징 → 토큰 필터링 순서로 진행

토크나이징은 특정 기준으로 분석을 실행해야 해서 1개만 지정 가능하다.

캐릭터 필터는 토크나이징이 진행되기전 캐릭터 전체에 대한 내용을 필터한다.

토큰 필터는 토크나이징이 되고난 후 토큰들에 대한 내용을 필터한다.

analyzer 를 이용해 tokens 확인하기

1. 로컬에서 elastic 실행

2. GET http://localhost:9200/_analyze 으로 원하는 text 와 analyzer 를 넣어서 요청하기

// body
{
  "text": ["genorator", "hauler"],
  "analyzer": "english"
}

tokenizer 를 이용해 tokens 확인하기

1. 로컬에서 elastic 실행

2. GET http://localhost:9200/_analyze 으로 원하는 text 와 tokenizer, filter 를 넣어서 요청하기

// body
{
  "text": ["genorator"],
  "tokenizer": "standard",
  "filter": [ "stemmer" ]
}

ref.

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html#indices-analyze

docker-compose 파일 작성하기

// dokcer-compose.yml
services:
 ma:
    build:
      context: ./my-api
      dockerfile: ../Dockerfile.ma
    environment:
      - NODE_ENV=development
      - PORT=9443
      - DB_NAME=database
      - DB_HOST=db
      - DB_PORT=3306
      - DB_USER=root
      - DB_PASSWORD=1234
      - ELASTICSEARCH_HOST=http://es:9200 # ELASTICSEARCH_HOST 추가
    ports:
      - "9443:9443"
    depends_on:
      - db
      - es

  es:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.4.3
    environment:
      - node.name=es
      - discovery.type=single-node # single-node 로 만든다.
      - discovery.seed_hosts=es
      - ELASTIC_PASSWORD=ecubelabs
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - xpack.security.http.ssl.enabled=false
      - xpack.security.http.ssl.verification_mode=certificate
      - xpack.security.transport.ssl.enabled=false
      - xpack.security.transport.ssl.verification_mode=certificate
      - xpack.license.self_generated.type=basic
    mem_limit: 1073741824
    ulimits:
      memlock:
        soft: -1
        hard: -1
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "curl -s --cacert config/certs/ca/ca.crt http://localhost:9200 | grep -q 'missing authentication credentials'",
        ]
      interval: 10s
      timeout: 10s
      retries: 120
    volumes:
      - es-data:/usr/share/es/data
      - certs:/usr/share/elasticsearch/config/certs
    ports:
      - 9200:9200
  kibana:
    image: docker.elastic.co/kibana/kibana:8.4.3
    environment:
      - ELASTICSEARCH_HOSTS=http://es:9200
    ports:
      - 5601:5601
    depends_on:
      - es

volumes:
  certs:
    driver: local
  es-data:
    driver: local

security?

로컬에서 실행할 것이기 때문에 security 관련 설정은 false 로 한다.

• xpack.security.enabled=false
• xpack.security.http.ssl.enabled=false
• xpack.security.transport.ssl.enabled=false

로컬에서 엘라스틱 서치 & 키바나 실행하기

1. docker compose up 명령어로 컨테이너 빌드하기

   docker compose up --build es kibana

   

2. elasticsearch : http://localhost:9200/ 으로 접속

3. kibana : http://localhost:5601/ 으로 접속

만약 이미 생성한 인덱스가 있는데 매핑 정보를 바꾸려 한다면 가장 좋은 방법은 해당 인덱스를 삭제하고 새로 생성하는 것이다. (혹시 모를 인덱스 매핑 오류를 막기 위해 인덱스를 밀고 새로 넣는 게 제일 좋다고 한다.)

• 인덱스에 이미 데이터가 들어있다면 매핑 정보를 수정할 수 없다.

포스트맨을 이용해 PUT http://es_url:port/생성할_인덱스_명칭 에 요청 보내기

• headers : 로컬이 아닌 경우 Authorization - ApiKey 를 함께 넣어서 요청한다.

• body

{
  "settings": {
    "analysis": {
      "filter": {
        "english_stop": {
          "type":       "stop",
          "stopwords":  "_english_" 
        },
        "english_stemmer": {
          "type":       "stemmer",
          "language":   "english"
        },
        "english_possessive_stemmer": {
          "type":       "stemmer",
          "language":   "possessive_english"
        }
      },
      "analyzer": {
        "default": {
          "tokenizer": "standard",
           "filter": [
            "english_possessive_stemmer",
            "lowercase",
            "english_stop",
            "english_stemmer"
          ],
          "char_filter": [
            "my_char_filter"
          ]
        }
      },
      "char_filter": {
        "my_char_filter": {
          "type": "pattern_replace",
          "pattern": "(\\d+)-(\\d+)-(\\d+)",
          "replacement": "$1$2$3"
        }
      }
    }
  }
}

english_analyzer 와 char_filter 를 이용해 커스텀 했다.

Language analyzers | Elasticsearch Guide [8.5] | Elastic

Mapping character filter | Elasticsearch Guide [8.5] | Elastic

인덱스에 데이터 bulk 하기

많은 양의 데이터를 한 번에 밀어 넣기 위해 bulk API 를 사용한다.

Bulk API | Elasticsearch Guide [8.5] | Elastic

이번엔 포스트맨이 아닌 스크립트를 이용해 API 를 호출한다. (인덱스에 저장할 id 를 따로 지정해줘야하기 때문에 스크립트를 사용했고, 그냥 한 개를 입력할 것이라면 포스트맨으로 보내도 된다.)

1. npm i @elastic/elasticsearch

2. list api 를 호출해서 받은 데이터를 list.json 으로 저장한다.

3. 스크립트에서 list.json 을 import 해서 bulk 데이터로 넣어준다.

4. 아래 스크립트를 만들고 실행한다.

// bulk.js
const accounts = require("./account.json");
const { Client } = require("@elastic/elasticsearch");

const client = new Client({
  node: "요청보낼 es url 입력하면 됩니다. (http, port 포함)",
  maxRetries: 3,
  auth: {
    apiKey: "security 가 설정되어 있다면 es api key 를 넣어주시면 됩니다.",
  },
});

const bulk = async (index, data) => {
  const operations = data.flatMap((doc) => [
    { index: { _index: index, _id: doc.id } },
    doc,
  ]);

  await client.bulk({ refresh: true, operations });
};

데이터 검색하기

위에서 bulk 한 데이터를 검색해보자.

포스트맨을 이용해 GET http://es_url:port/생성한_인덱스 에 요청 보내기

• headers : 로컬이 아닌 경우 Authorization - ApiKey 를 함께 넣어서 요청한다.

• body

 {
 "query": {
      "bool": {
        "must": [
          {
            "multi_match": {
              "query": "검색하고 싶은 내용",
              "type": "phrase_prefix"
            }
          }
        ]
      }
    }
 }

검색한 내용에 맞는 결과가 반환되면 성공 👏

• Apache Lucene(아파치 루씬) 기반의 java 오픈소스 분산 검색 엔진
• 방대한 양의 데이터를 신속하고 거의 실시간으로 저장, 검색, 분석 가능

장점

1. 오픈소스 검색 엔진이기 때문에 무료로 사용 가능하다.
2. 역색인을 이용해 방대한 양의 데이터를 신속하게 처리가 가능하다.

단점

1. 진입장벽이 있다.
2. Document 간의 조인을 수행할 수 없다. (두 번 쿼리로 해결은 가능)
3. 트렌잭션이 제공되지 않는다.
4. ‘실시간(Real Time)' 처리 불가능
5. 진정한 의미의 업데이트를 지원하지 않는다. (실제로는 delete → insert 과정으로 업데이트 됨)

Elasticsearch vs RDBMS

이 중에 우리가 중점적으로 보아야 하는 것은 index, document, mapping 정도이다.

Elasticsearch CRUD

왜 엘라스틱 서치가 더 빠를까?

• 데이터를 저장하고 있는 구조 자체가 다르다. (역색인 구조)

좌 : 색인 구조(문서에서 키워드를 찾아 보기 쉽도록 정렬 및 나열한 목록)

우 : 역색인 구조(키워드를 통해 문서를 찾아내는 방식)

그럼 엘라스틱 서치를 쓸 일이 뭐가 있을까?

1. 관계형 데이터베이스는 단순 텍스트 매칭에 대한 검색만을 제공
   • MySQL 최신 버전에서 n-gram 기반의 Full-text 검색을 지원하지만, 한글 검색의 경우에 아직 많이 빈약하다고 한다.
2. 텍스트를 여러 단어로 변형하거나 텍스트의 특질을 이용한 동의어나 유의어를 활용한 검색이 가능
3. 엘라스틱서치에서는 관계형 데이터베이스에서 불가능한 비정형 데이터의 색인과 검색이 가능
4. 엘라스틱서치에서는 형태소 분석을 통한 자연어 처리가 가능
   • 엘라스틱서치는 다양한 형태소 분석 플러그인을 제공
5. 역색인 지원으로 매우 빠른 검색이 가능

ref. https://velog.io/@jakeseo_me/%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-2-DB%EB%A7%8C-%EC%9E%88%EC%9C%BC%EB%A9%B4-%EB%90%98%EB%8A%94%EB%8D%B0-%EC%99%9C-%EA%B5%B3%EC%9D%B4-%EA%B2%80%EC%83%89%EC%97%94%EC%A7%84 https://choseongho93.tistory.com/231 https://sudarlife.tistory.com/entry/Elasticsearch-%EA%B0%84%EB%8B%A8-%EA%B0%9C%EB%85%90-%EC%9E%A5%EB%8B%A8

🚀 프론트앤드에서 유저의 디바이스 토큰을 보내준다는 가정하에 진행한다.

firebase 공식문서에 정리가 잘 되어있어서 한 번 그대로 진행해본다.

1. 프로젝트에서 SDK 초기화를 위한 서버 키 발급받기

firebase 콘솔에서 내 프로젝트 > 설정 > 프로젝트 설정으로 들어간다.

서비스 계정 > 새 비공개 키 생성 버튼 클릭

키 생성 버튼 클릭

그러면 내 로컬에 서버 키 파일.json 이 생긴다. 이 파일은 추후 재발급이 불가능하다고 하니 잘 보관해준다. (프로젝트에 넣을 예정)

2. firebase-admin SDK 설치하기

firebase-admin 패키지를 설치해준다.

npm i firebase-admin

3. SDK 초기화

먼저 다운받은 서버 키를 프로젝트 안에 넣어준다. 나는 configs 폴더 안에 firebase-admin.json 이라는 이름으로 넣었다.

import admin from 'firebase-admin';

const serviceAccount = require('./configs/firebase-admin.json');

admin.initializeApp({
  credential: admin.credential.cert(serviceAccount),
});

새 비공개 키를 만들 때 적혀있던 코드 스니펫을 이용하여 서버 키를 import 해주고 서버 키를 이용해 credential 설정을 해준다.

4. 푸시알림 생성하기

 async sendPushNoti(email: string) {
    const targetMember = await this.memberService.findMemberByEmail(email);

    const message = {
      notification: {
        title: '테스트 제목입니다.', 
        body: '푸시알림 내용입니다.',
      },
      token: targetMember.fcmToken, // user 의 device token 을 넣어준다.
    };

    admin
      .messaging()
      .send(message)
      .then(function (response) {
        console.log('Successfully sent message: : ', response)
      })
      .catch(function (err) {
        console.log('Error Sending message!!! : ', err)
      })
  }

유저 email 으로 DB 에 저장되어있는 유저의 디바이스 토큰을 이용해 푸시 알림을 생성한다.

5. 테스트 결과

ios 기준 정상적으로 푸시 알림이 뜨는 것을 확인할 수 있다.

참고

해당 내용은 앱이 화면에 떠있지 않은 상태, 즉 백그라운드 상태일 때만 heads up 알림이 생성된다. 앱이 실행 중일 때(포그라운드) 알림을 뜨게 하려면 공식 문서에 적힌 것처럼 data 라는 key 에 정보를 담아서 프론트에 보내주고 콜백으로 해당 메세지를 받아야한다.

typeORM 버전을 0.2.x -> 0.3.x 로 업그레이드 하면서 발생한 에러이다. 버전이 바뀌면서 DB connection 에 관한 방법이 변경되었는데, initialize() 로 DB connection pool 을 오픈하지 않아서 발생한 에러였다. 😅

typeORM 0.2.x version

 const conn = await createConnection({
        ...ormconfig,
        entities,
    });

    await Promise.all([conn.connect()]);

typeORM 0.3.x version

    const conn = new DataSource({
        ...ormconfig,
        entities,
    });

    await Promise.all([conn.initialize()]); // opens connection pool to the database

ref. https://typeorm.biunav.com/en/data-source-api.html#datasource-api

로컬에서 S3 에 파일 업로드를 테스트 하던 중, localStack 을 사용하면 된다고 해서 알아보고 직접 적용해본 내용을 정리했다.

공식문서

https://github.com/localstack/localstack

What is Localstack ?

• AWS API 를 시뮬레이션 해주는 프레임워크
• 도커 컨테이너 형태로 제공되며, AWS REST API 스펙에 맞는 모킹 http 서버를 실행한다.

Localstack 지원하는 서비스

Localstack은 유료 버전과 무료 버전으로 나눠져 있으며 무료로 제공하는 서비스는 아래와 같다.

Note: localstack 0.11.0 부터는 모든 APIs 단위 포인트(http://localhost:4566)로 연결을 됨API Gateway at http://localhost:4567
Kinesis at http://localhost:4568
DynamoDB at http://localhost:4569
DynamoDB Streams at http://localhost:4570
S3 at http://localhost:4572
Firehose at http://localhost:4573
Lambda at http://localhost:4574
SNS at http://localhost:4575
SQS at http://localhost:4576
Redshift at http://localhost:4577
Elasticsearch Service at http://localhost:4578
SES at http://localhost:4579
Route53 at http://localhost:4580
CloudFormation at http://localhost:4581
CloudWatch at http://localhost:4582
SSM at http://localhost:4583
SecretsManager at http://localhost:4584
StepFunctions at http://localhost:4585
CloudWatch Logs at http://localhost:4586
EventBridge (CloudWatch Events) at http://localhost:4587
STS at http://localhost:4592
IAM at http://localhost:4593
EC2 at http://localhost:4597
KMS at http://localhost:4599
ACM at http://localhost:4619

왜 쓰나요?

• 실제 aws s3 와 연동하지 않고도 로컬에서 aws 서비스를 테스트 할 수 있다.
• AWS 서비스를 사용하는 인프라 로직의 통합테스트를 작성하기 위해 사용한다.

localstack 을 실행하는 방법

1. Testcontainers
2. docker compose

→ docker compose 를 사용하는 방법으로 테스트해보겠다.

docker compose 로 localstack 실행하기

• docker-compose.yml

  aws:
    image: localstack/localstack
    environment:
      - SERVICES=s3 // 사용할 서비스 , 를 이용해 나열
      - DEBUG=1
    volumes:
      - "./test/docker-entrypoint-initaws.d:/docker-entrypoint-initaws.d"

• 사용할 서비스는 SERVICES=ses,s3... 처럼 나열이 가능하다.

• ./test/docker-entrypoint-initaws.d 경로에 있는 파일에 s3 버킷을 만들 수 있다.

• ./test/docker-entrypoint-initaws.d

  #!/bin/sh
  

awslocal s3 mb s3://test

- awslocal 명령어를 이용해 test 버킷을 만들었다.

<br>

docker compose up 명령어를 이용해 빌드 후 실행 시켜준다.
![test](https://velog.velcdn.com/images/yoon-bomi/post/3fa6daac-3b09-4d73-bb54-3c5e3e8a9b01/image.png)

make bucket test 가 제대로 뜬다면 성공 🚀

<br>

str: build: context: ./storage-api dockerfile: ../Dockerfile.str environment: - NODE_ENV=development - DB_HOST=db - DB_PORT=3306 - DB_USER=root - DB_PASSWORD=1234 - PORT=3030 - AWS_ENDPOINT=http://aws:4566 # see https://github.com/localstack/localstack - AWS_ACCESS_KEY_ID=aws # 아무 값이나 환경변수로 지정하기만 하면 ok - AWS_SECRET_ACCESS_KEY=aws # 아무 값이나 환경변수로 지정하기만 하면 ok depends_on: - db ports: - "3030:3030"

```

• 사용하고자 하는 도커에서 AWS_ENDPOINT=http://aws:4566 로 엔드포인트를 설정해준다. (그래야 localstack 으로 요청이 간다.)
• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 는 아무 값이나 넣어준다.

storage API 를 이용한 localstack POST 요청 테스트 (파일 업로드)

특정 프로젝트에서 파일 서버를 통해 S3로 파일이 업로드 되는 과정을 테스트한다. 실제 S3와 연결하지 않고 localstack 을 이용해 보았다.

• 포스트맨

• localstack docker

• 결과 : 성공적으로 업로드 된 것을 확인할 수 있다.

ref.

https://tech.inflab.com/202202-integration-test-with-localstack/ https://medium.com/@dudwls96/localstack-%ED%99%9C%EC%9A%A9%ED%95%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%84%B1%ED%95%98%EA%B8%B0-9b81ec51749c

💡 [[NHN FORWARD 2021] Redis 야무지게 사용하기] (https://www.youtube.com/watch?v=92NizoBL4uA) 를 시청하며 정리한 내용입니다.

What is Redis?

전세계에서 가장 유명한 Caching 솔루션 대부분 cache 용도로 Redis 를 사용한다.

• Redis 좀 더 알아보기 Remote dictionary server (외부 HashMap 서버) Single Thread 서버이다. → 시간 복잡도 고려 필요 (O(N) X)

1. Redis 를 cache 로 사용하는 방법

cache ?

• cache 란 사용자의 입장에서 데이터의 원래 소스보다 더 빠르고 효율적으로 엑세스 할 수 있는 임시 데이터 저장소를 뜻한다.
• 대부분의 어플리케이션에서 속도 향상을 위해 cache 를 사용한다. 따라서 cache 에 접근하는 것이 원본에 접근하는 것보다 쉽고 빨라야 한다.

Q. cache 는 언제 사용하는 것이 좋을까?

A. 동일한 데이터에 대해 반복적으로 액세스 하는 상황이 많을 때 !

의미있는 cache

1. 데이터의 재사용 횟수가 한 번 이상일 경우
2. 잘 변하지 않는 데이터일수록 cache 를 사용할 때 더 효율적

Redis as a cache

• 단순한 key-value 구조 : 사용이 간편하고 데이터 저장이 쉽다.

• in-memory 데이터 저장소 (RAM)

  • 빠른 성능 : 평균 작업 속도 < 1 ms, 초당 수백만 건의 작업 가능

캐싱 전략(Caching Strategies)

데이터의 유형과 해당 데이터에 대한 액세스 패턴을 잘 고려해서 선택해야 한다.

1. look-aside

데이터를 읽는 작업이 많을 때 사용한다. (가장 일반적으로 사용하는 방법)

1️⃣ 어플리케이션이 데이터를 찾을 때 cache 에 먼저 확인한다.

2️⃣ cache 에 데이터가 있을 경우, cache 에서 데이터를 가지고 오는 작업을 반복한다.

3️⃣ 만약 redis 에 찾는 키가 없다면 어플리케이션은 DB 에 접근해서 데이터를 가져온 뒤 다시 redis 에 저장하는 과정을 거친다.

⇒ cache 는 찾는 데이터가 없을 때에만 입력되기 때문에 Lazy Loading (지연로딩) 이라고도 부른다.

⇒ DB 에서 cache 로 데이터를 밀어 넣어주는 작업 : Cache Warming 을 통해 방지 가능

ex) 티켓링크에서 상품 오픈 전 상품의 정보를 미리 DB 에서 cache 로 올려주는 작업을 매번 한다.

2. write-around

DB 에만 데이터를 저장한다.

1️⃣ 모든 데이터를 DB 에 저장한다.

2️⃣ 캐시 미스가 발생한 경우에만 DB 에서 데이터를 꺼내 cache 로 끌어 온다.

3. write-through

DB 에 데이터를 저장할 때, cache 에도 함께 저장한다.

expire time ? 몇 분, 혹은 몇 시간동안만 데이터를 보관하겠다는 의미

2. Redis 데이터 타입

• Strings : set 커맨드를 이용해 저장된 데이터는 모두 String 형태로 들어간다.
• Bitmaps : string 의 변형, bit 단위의 연산이 가능하다.
• Lists : 데이터를 순서대로 저장 == 큐로 사용하기 적절하다.
• Hashes : 하나의 키 안에 또다시 여러 개의 필드와 벨류 쌍으로 데이터를 저장한다.
• Sets : 중복되지 않은 문자열의 집합
• Sorted Sets : set 처럼 중복되지 않은 모든 값을 score 라는 숫자 값으로 저장한다. 저장될 때부터 score 순으로 정렬되며, score 가 같을 때에는 사전순으로 정렬된다.
• HyperLogLogs : 굉장히 많은 데이터를 다룰 때 주로 쓰며 중복되지 않는 값의 개수를 카운트할 때 사용한다. → 먼소리임?
• Streams : log 를 저장하기 가장 좋은 자료구조이다.

Best Practice - Counting

Best Practice - Messaging

ex) 인스타, 페이스북, 트위터에는 유저별로 타임라인이 존재하고, 그 타임라인에는 내가 팔로우한 사람들의 데이터가 뜬다. 트위터에서는 각 유저의 타임라인에 보일 트윗을 캐싱하기 위해 redis 의 list 를 사용하는데, 이 때 RPUSHX 커맨드를 사용한다. 이를 이용해 트위터를 자주 이용하던 유저의 타임라인에만 새로운 데이터를 미리 캐시해 놓을 수 있으며 자주 사용하지 않는 유저는 caching key 자체가 존재하지 않기 때문에 이 유저들을 위한 데이터를 미리 쌓아두는 것과 같은 비효율적인 작업을 방지할 수 있게 된다.

3. Redis 에서 데이터를 영구 저장하기(RDB vs AOF)

Redis 는 in-memory 데이터 스토어

• 모든 데이터가 메모리에 저장되어있기 때문에, 서버나 redis 인스턴스가 재시작되면 모든 데이터 유실
• 복제 구조로 되어있어도 데이터 유실에서 안전하지 않다.

Redis Persistence Option

1. AOF (Append Only File)

• 데이터를 변경하는 커멘드가 들어오면 커맨드를 그대로 모두 저장한다. (redis 프로토콜 형태로 저장)
• 데이터가 추가되기만 해서 대부분 RDB 파일보다 사이즈가 커진다. → 주기적으로 압축해서 재작성되는 과정을 거쳐야 한다.

2. RDB

• 스냅샷 방식으로 동작 → 저장 당시의 메모리에 있는 데이터를 그대로 스냅샷으로 찍어서 저장한다. (바이너리 파일 형태로 저장)

AOF 와 RDB 모두 커맨드를 이용해 직접 파일을 생성하거나 원하는 시점에 자동으로 파일이 생성되도록 할 수 있다.

AOF vs RDB 선택 기준

• 우선 redis 를 캐시로만 사용한다면, 둘 다 쓸 필요가 없다.

1. 백업은 필요하지만 어느 정도의 데이터 손실이 발생해도 괜찮은 경우

• RDB 단독 사용
• redis.conf 파일에서 SAVE 옵션을 적절히 사용 ex) SAVE 900 1 → 900 초 동안 한 개 이상의 키가 변경되었을 때 RDB 파일을 재작성해라.

2. 장애 상황 직전까지의 모든 데이터가 보장되어야 할 경우

• AOF 사용
• APPENDFSYNC 옵션이 everysec 인 경우 최대 1초 사이의 데이터 유실 가능(기본 설정)

3. 제일 강력한 내구성이 필요한 경우

• RDB & AOF 동시 사용

4. Redis 아키텍처

1. Replication 구성

• 단순한 복제 연결
• 모든 redis 의 구조에서 복제는 비동기식으로 동작한다. → 마스터에서 복제본에 데이터가 잘 전달됐는지 매번 확인하고 기다리지 않는다.
• 이 구조는 HA (High Availability) 기능이 없기 때문에 마스터에 장애가 발생하면 수동으로 변경해줘야 하는 작업들이 많다. (리플리카 노드에 직접 접속해서 복제를 끊어야 하고, 어플리케이션에서도 연결 설정을 변경하여 배포하는 작업이 필요하다.)

• HA (High Availability) 기능 ? 자동 페일오버(장애 극복 기능)

2. Sentienl 구성

• 자동 페일오버 가능한 HA 구성(High Availability)
• 센티널 노드는 일반적인 다른 노드를 계속 모니터링 → 마스터가 죽으면 자동으로 페일오버를 발생시켜 기존의 리플리카 노드가 마스터가 된다. 이때 어플리케이션에서는 연결 정보를 변경할 필요가 없다. 어플리케이션은 센티널 노드만 알고 있으면 되고, 센티널이 변경된 마스터 정보로 바로 연결시켜 준다.
• 이 구조를 사용하기 위해서는 센티널 프로세스를 추가로 띄워야 하는데, 센티널은 항상 세대 이상의 홀수로 존재해야 한다.

3. Cluster 구성

• 스케일 아웃과 HA 구성 (High Availability)
• 데이터가 여러 마스터 노드에 자동으로 분할되어 저장되는 샤딩 기능(스케일 아웃)을 제공한다.
• 모든 노드가 서로 감시하고 있다가 마스터가 비정상 상태일 때 자동으로 페일오버를 진행한다.
• 최소 세대 이상의 마스터 노드가 필요하고, 리플리카 노드를 하나씩 추가하는 게 일반적인 구조이다.

5. Redis 운영 팁과 장애 포인트

redis 는 싱글 스레드로 동작한다.

한 사용자가 오래 걸리는 커맨드를 실행한다면 병목현상이 발생할 수 있다.

사용하면 안되는 커맨드

• keys → scan 으로 대체
• Hash 나 Sorted Set 등 자료구조
  • hgetall → hscan
  • del → unlink

변경하면 장애를 막을 수 있는 기본 설정값

• STOP-WRITES-ON-BGSAVE-ERROR = NO

  • RDB 파일 저장 실패 시 redis 로의 모든 write 불가능

• MAXMEMORY-POLICY = ALLKEYS-LRU

  • redis 를 캐시로 사용할 때 expire time 설정 권장
  • 메모리가 가득 찼을 때 MAXMEMORY-POLICY 정책에 의해 키 관리 : ALLKEYS-LRU → 모든 key 에 대해 lru 방식(가장 최근에 사용하지 않았던 key 부터 삭제한다)으로 key 를 삭제하겠다는 것을 의미

ref. https://www.youtube.com/watch?v=92NizoBL4uA

isNaN() 함수는 어떤 값이 NaN인지 판별합니다. isNaN 함수는 몇몇 혼란스러운 케이스을 가지고 있으므로, ECMAScript 2015에서 추가한 Number.isNaN()으로 바꾸는 편이 좋을 수도 있습니다.

isNaN() 과 Nember.isNaN() 는 어떻게 다를까? 🤔

isNaN() vs Nember.isNaN()

아래 간단한 예시를 보자.

isNaN("blabla") // true
Nuber.isNaN("blabla") // false

isNaN(NaN) // true
Nuber.isNaN(NaN) // true

분명 같은 string 값을 넣었는데 다른 결과가 도출된다.

why?

isNaN 을 직역하면 이 값이 NaN 이니? 이다.

하지만 isNaN() 은 매개변수의 값을 강제로 Number 로 캐스팅 하기 때문에 Numer("blabla") = NaN 이 되고, isNaN(NaN) = true 라는 값이 도출 되는 것이다.

isNaN("blabla") = isNaN(Number("blabla")); // 강제로 Number 캐스팅
Number("blabla") = NaN

isNaN("blabla") // true

"blabla" !== NaN 임에도 불구하고 isNaN("blabla") = true 라는 결과가 도출되기 때문에, 사이드 이펙트가 발생할 수도 있어서 온전히 NaN 일 때만 true 를 반환하는 Number.isNaN() 을 사용하라는 의미인 것으로 추측된다. (내 생각)

Number.isNaN("blabla") // false
Number.isNaN("1234") // false
Number.isNaN("1234ABC") // fasle
Number.isNaN(1234) // false

Number.isNaN(NaN) // true

typescript 에서 isNaN() 을 사용할 때 문제점

공식 문서에서도 isNaN() 이 아닌 Number.isNaN() 사용을 권장하고 있다. 자바스크립트는 타입에 대한 정의가 없어서 에러가 나지 않지만 타입스크립트에서 isNaN() 의 매개변수로 number 타입만 받을 수 있어서, string 타입을 넣을 경우 타입 에러가 발생한다.

하지만 Number.isNaN() 는 매개변수를 unknown 타입으로 받기 때문에 string 타입이 들어가도 타입 에러가 발생하지 않는다.

 // Argument of type 'string' is not assignable to parameter of type 'number'. ts(2345)
  if (isNaN('string')) { // type error 발생
    console.log('value is NaN 😕');
  }


  if (Number.isNaN('string')) { // false
    console.log('value is NaN 😕');
  }

결론

isNaN = function(value) {
    Number.isNaN(Number(value));
}

특별한 이유가 없다면 정확한 판단을 위해 isNaN(value) 대신 Number.isNaN(value) 를 사용하자!

ref. 공식 문서 https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN

/^(19|20)\d\d-(0[1-9]|1[012])-([012]\d|3[01])/

• yyyy-mm-dd hh:mm:ss 형식의 regex

/^(19|20)\d\d-(0[1-9]|1[012])-([012]\d|3[01]) (2[0-3]|[01][0-9]):[0-5][0-9]:[0-5][0-9]/

• 두 형식 모두를 받으려면 ? 와일드 카드(*) 사용

/^(19|20)\d\d-(0[1-9]|1[012])-([012]\d|3[01]).*/

.env 파일에서 AWS_CONFIG_FILE 는 사용하지 않지만 AWS_SDK_LOAD_CONFIG=1 를 적어놨었는데 이 환경변수 때문에 에러가 발생한 것 같다. 해당 환경변수를 제거하니까 정상 동작,, 버킷에도 잘 들어간다.

• 도커 Mysql DB 컨테이너 내부의 용량 부족으로 추정(?)

에러 로그

Resolve

docker system prune --volumes

• 해당 명령어를 이용해 현재 run 중인 도커를 제외한 모든 컨테이너 및 볼륨을 제거 후 재빌드

ref.

• 님 디스크 꽉참 : https://stackoverflow.com/questions/51252263/mysql-wont-restart-on-ubuntu-server-16-04
• 도커 용량 확보하셈 : https://stackoverflow.com/questions/66686724/docker-compose-volume-question-and-error-initialize-specified-but-the-data-dir

설정 → Resources 에서 용량을 늘려주어야 한다.

주기적으로 불필요한 리소스들을 제거 or 줄이고 잘 돌아가더라도 컨테이너들을 새로 빌드해줄 필요가 있다.

(해당 에러 발생 시 Disk image size 를 59 → 64 기가로 늘렸음)

타입스크립트를 쓰다보면 종종 타입스크립트가 타입 추론을 제대로 못하거나, (절대 내가 코딩을 이상하게 해서가 아니라 그냥 타입스크립트가 바보인 경우가 종종 있..) 다른 이유로 인해 타입 에러를 무시해야할 경우가 있다.

필자는 타입스크립트 에러를 무시하기 위해 @ts-ignore 를 더 자주 사용했지만, @ts-expect-error 도 있다는 것을 알게 되어 정리를 해보려 한다.

@ts-expect-error 와 @ts-ignore 의 공통점

둘 다 타입스크립트 에러를 무시하기 위해 사용한다.

@ts-expect-error 와 @ts-ignore 의 차이점

@ts-expect-error : typescript 3.9 버전에서 추가되었다.

1. 타입스크립트 에러가 발생할 것은 알지만 어쩔 수 없이 에러를 무시해야 할 때 사용 한다.

   delete() {
        // @ts-expect-error NOTE: 타입이 복잡해지지 않도록 ts-expect-error 를 사용한다.
        this.groupIdx = null;
        this.publishEvent(new UserDeletedEvent(this.id, this.groupIdxs));
    }

   이 예시에서 groupIdx 의 타입은 number 로 되어있고, 실제 DB 에는 number | null 로 값이 들어갈 수 있다. 하지만 groupIdx 를 number | null 타입으로 지정할 경우, 타입 추론이 너무 복잡해지기 때문에 @ts-expect-error 를 이용해 타입을 단순화했다.

2. 런타임 에러가 발생하면 안된다. 진짜 타입 에러인 경우에만 사용한다.

@ts-ignore

• '아몰랑 일단 넘어가자..' 할 때 사용한다.