예시

-118.625

1. 먼저 음수이므로 최상위 비트를 1로 설정합니다. (양수일 경우 0)

2. 절댓값 118.625를 이진법으로 변환합니다. 118.625 -> 1110 110.101

3. 소수점을 왼쪽으로 이동시켜 정수부가 한자리가 되도록 합니다. 1110 110.101 -> 1.1101 1010 1

4. 3번에서 이동시킨 자릿수(6)만큼을 2의 지수로 사용하여 곱해주고, 이 수를 정규화된 부동 소수점이라고 합니다. 1.1101 1010 1 x 2^6

5. 4번의 소수점 아래 부분(1101 1010 1)이 가수부(23bit)가 되도록 나머지 비트를 0으로 채웁니다. 1101 1010 1000 0000 0000 000 x 2^6

6. 위 23비트를 가수부로 설정합니다.

7. 32bit IEEE 754 형식엔 "Bias" 라는 고정된 값이 있습니다. 이는 127이며, bias를 2의 지수인 6에 더하고 이진수로 변환합니다. 6 + 127 = 133 -> 1000 0101 (8bit 지수부)

8. 위 8비트를 지수부로 설정합니다.

Floating Point 에러

컴퓨터는 부동소수점(floating-point) 숫자를 정확하게 표현할 수 없을 때가 있어, 더하기나 빼기 같은 연산 결과가 우리가 기대한 것과 미세하게 다를 수 있습니다.

이유: 2진법 표현의 한계: 대부분의 실수(예: 0.1, 0.2)는 2진법으로 정확히 표현할 수 없습니다.

예를 들어, 0.1은 2진법으로 무한히 반복되는 값(0.000110011...)이 되어 근사값으로 저장됩니다. 근사값 연산: 이런 근사값들로 계산하다 보니 결과에 오차가 생깁니다.

예: 0.1 + 0.2는 우리가 기대하는 0.3 대신 0.30000000000000004가 나올 수 있습니다.

파이썬에서 부동소수점 덧셈 오류를 잘 보여주는 간단한 예시를 살펴보겠습니다. 부동소수점 연산은 항상 정확한 결과를 보장하지 않기 때문에, 덧셈 연산 후 기대한 값과 실제 값이 약간 다를 수 있습니다.

뭐 이런 식으로 해결할 수 있다.

IP

아이피는 네트워크 ID + 호스트 ID 로 구성되어 진다.

아래 그림과 같은 식이다. Class는 CIDR 이전에 IP를 나누고 표현하는 방식이다. 예약된 주소들도 있다.

서브넷 마스크

서브넷 마스크는 IP 주소에서 네트워크와 호스트를 구분하는 역할을 하는 32비트 값이다.

서브넷 마스크는 연속된 1과 연속된 0으로 구성되어있다 11111111.11111111.11111100.00000000 => 이런 식의 값이다. 10011111.11011111.11110011.00000000 => 이런 식의 값은 갖을 수 없다.

그냥 어디까지가 네트워크 파트인지 표시해주는 것 뿐이다.

CIDR

CIDR의 full name은 (Classless Inter-Domain Routing) 으로 클래스 없는 도메인간 라우팅 기법이라는 뜻을 내포한다. 즉, 도메인간의 라우팅에 사용되는 인터넷 주소를 원래 IP주소 클래스 체계를 쓰는 것보다 더욱 능동적의로 할수 잇도록 할당하여 지정하는 방식중 하나 이다.

=> 그냥 IP를 나누고 할당하는 걸 잘 표현하기 위한 표기법이라고 생각하면 된다.

그냥 예시로 이해해보자.

192.168.10.70/26이라고 하면

이 아이피 표기법에서는 서브넷마스크의 1의 갯수가 26개 인걸 알 수 있다. 네번째 옥텟의 최상위 2개의 비트가 1이고, 나머지 6비트를 호스트ID로 할당하게 된다. 즉 호스트ID 부분이 .11000000 가 되며 10진법으로 192가 된다. 그러면 서브넷마스크는 255.255.255.192가 되게 된다.

32비트 중에 앞 26자리까지가 네트워크 비트가 되고 뒤 6자리를 호스트로 사용하게 된다. 256 - 192 = 64 (특수목적 IP - 2) = 62 이므로 62개의 호스트를 가질 수 있게 된다.

앞선 두 개의 게시물에서 완성한 gitlab-ci.yml과 helm manifest를 통해 CD를 만들어보자.

• ArgoCD 구축

환경 세팅

• kubectl create namespace argocd
• kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
• kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
• external ip를 domain에 A Record에 연결해주기(optional)
• argocd ip에 접속 후 settings => repositories => connect repo => gcp source repository 연결.

나 같은 경우엔 connection method로 gcloud 선택 후 repository url은 아래 포맷을 입력하고 올바른 GCP service account key를 입력하면 된다. https://source.developers.google.com/p/{project}/r/{repo}

• 그리고 Application을 만들면 된다. 그리고 sync가 잘 되는지 확인 후 gitlab-ci에서 sync가 잘 되는지도 확인하면 완료

명령어 모음

• argocd admin initial-password -n argocd
• kubectl edit configmap argocd-cm -n argocd argoCD api를 사용하려면 추가적인 권한이 필요하다. 아래 부분을 추가하면 된다.

  data:
      accounts.admin: apiKey, login

앞선 게시물에서 등장한 Helm chart manifest의 예시를 보면서 helm install로 배포할 수 있는 상태로 만드는 과정을 살펴보자. 최종적으는 다음 게시물에서 helm 명령어가 아니라 ArgoCD를 통해 sync를 통해 배포할 예정이다.

• Helm chart manifest를 작성해서 Backend 서비스를 GCP k8s engine에 배포할 수 있도록 한다.
• Domain에 HTTPS(SSL 인증서)까지 적용한다.
• Env variable을 사용하기 위해 GCP secret manager 서비스를 사용하도록 한다.
• gcp k8s에 배포하기 위한 helm, gcloud 명령어들

완성한 소스코드는 https://github.com/HoneyJung/helm-gcp-example에 있다.

파일 설명

exterenalSecret.yaml, externalSecretServiceAccount.yaml, secretStore는 아래에서 더 자세히 설명합니다.

├── Chart.yaml
├── templates
│   ├── backendConfig.yaml - timeout을 위한 것. 필수 아님
│   ├── deployment.yaml
│   ├── exterenalSecret.yaml
│   ├── externalSecretServiceAccount.yaml
│   ├── frontendConfig.yaml - http => https로 redirect하기 위함. 이것도 필수 아님.
│   ├── ingress.yaml
│   ├── managedCertificate.yaml => ssl 인증서를 다루기 위한 파일. 아래에서 더 자세히 설명 
│   ├── secretStore.yaml
│   └── service.yaml - 
├── values-dev.yaml - 환경 별로 사용되는 변수는 분리해서 다룬다.
└── values.yaml - 변수는 따로 저장한다.

Prerequisite

• GCP를 사용한다면 cluster를 만들 때 Workload Identity를 enable 해줘야한다. 이는 GCP의 service account(gsa)의 권한을 K8s service account(ksa)에게 부여하기 위해 쓰인다.
• external-secret을 사용하기 위한 일종의 라이브러리 설치라고 보면 된다.

gcloud container clusters update opuslab-be-dev \
    --update-addons ConfigConnector=ENABLED --zone us-central1-c

helm install external-secrets \
   external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace 

• gsa => ksa 권한 바인딩. 이 명령어를 사용하기 전에 gcp에서 gsa를 생성하고 아래 두 권한이 부여되어 있어야 한다.

  gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:lgair-aihub.svc.id.goog[opuslab-be-main/opuslab-be-main]" \
    external-secret@lgair-aihub.iam.gserviceaccount.com
  
  

gcloud iam service-accounts add-iam-policy-binding
--role roles/iam.serviceAccountTokenCreator
--member "serviceAccount:lgair-aihub.svc.id.goog[opuslab-be-main/opuslab-be-main]"
external-secret@lgair-aihub.iam.gserviceaccount.com

```

• gcp console에서 secret manager에서 secret을 만들고 값을 넣어준다.

  명령어 모음

• helm install app-name . -n namespace-name -f values.yaml -f values-dev.yaml
• helm uninstall app-name -n namespace-name
• helm upgrade --install app-name . -n namespace-name

Secret

주의할 점

• DNS에 도메인을 구매하고 subdomain을 만드는 건 따로 해야한다.
• helm install하면 고정 ip가 하나 생긴다. 이를 subdomain의 A 레코드에 등록한다.
• helm install하면 managed certificate도 생긴다. 시간이 좀 소요된다. dns에 ip를 등록해야 validate된다.

• GCP에 있는 K8S 서비스의 CI/CD를 구축해본다.
• 기술 스택은 Gilab-ci, helm chart, argoCD
• 최종 결과의 Flow는 gitlab에 소스코드를 푸시하면 gitlab ci가 소스 코드를 빌드하고 Docker Registry에 푸시한다. Helm chart manifest(이 프로젝트에서는 GCP Source repository라는 서비스를 사용했다. 특별한 서비스는 아니고 gcp에 있는 git이다. 회사 네트워크 보안 때문에 이를 사용하게 됐다.)의 태그를 바꿔주고 argoCD가 Helm manifest를 참조해서 알맞는 Docker image를 가져와 k8s에 서비스를 배포하게 되는 구조다.

구축하기에 순서는 helm, argoCD, gitlab-ci가 맞는 것 같은데 정리는 가장 쉬운 Gitlab-ci부터 해보자 일단 stage라는 걸 나누게 되는데 나는 아래와 같이 stage를 나눴고. 추후에 테스트 코드 작성 후에 test라는 stage는 추가해야겠다.

• build: 소스 코드를 빌드 후 Docker Registry(GCP Artifact Registry)에 푸시. 태그는 date를 사용했다.
• bake: Helm manifest가 있는 Repository(GCP Source Repository)에 variable 중 tag를 위에서 사용한 tag로 수정해준다.
• migration: DB migration 해주는 부분. Database를 사용하지 않는 서비스라면 필요하지 않는 stage
• deploy: 구축된 argoCD 서버에 sync 명령을 날려주는 stage. argoCD가 먼저 구축되어 있어야하고, auto sync만 사용해도 괜찮은 경우도 있을 듯하다.

코드도 어렵지 않고 읽어보면 쉽게 이해할 수 있을 것 같다. 지피티와 함께라면..

stages:
  - build
  - bake
  - migration
  - deploy
variables:
  DEV_VALUES_FILE: "values-dev.yaml"

build:
  stage: build
  image: docker:24.0.5
  tags:
    - shared
  only:
    - dev
  environment:
    name: dev
  services:
    - docker:24.0.5-dind
  script:
    - export TAG=$(date +'t%Y%m%d%H%M%S')
    - echo "TAG=$TAG" >> build.env
    - apk update
    - apk --no-cache add git curl tar python3 ca-certificates
    - curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-cli-457.0.0-linux-x86_64.tar.gz
    - tar -xf google-cloud-cli-457.0.0-linux-x86_64.tar.gz
    - ./google-cloud-sdk/install.sh --quiet
    - ./google-cloud-sdk/bin/gcloud init --console-only
    - ./google-cloud-sdk/bin/gcloud auth activate-service-account --key-file $SERVICE_ACCOUNT_SECRET --project $PROJECT_ID
    - ./google-cloud-sdk/bin/gcloud auth configure-docker $REGION
    - cat $SERVICE_ACCOUNT_SECRET | docker login -u _json_key --password-stdin https://$REGION
    - docker build -t $IMAGE_NAME:latest -f Dockerfile .
    - docker tag $IMAGE_NAME:latest $DOCKER_REGISTRY/$IMAGE_NAME:$TAG
    - docker push $DOCKER_REGISTRY/$IMAGE_NAME:$TAG
    - docker rmi $IMAGE_NAME:latest
  artifacts:
    reports:
      dotenv: build.env

bake_dev_manifest:
  stage: bake
  image: google/cloud-sdk:alpine
  tags:
    - shared
  environment:
    name: dev
  only:
    - dev
  dependencies:
    - build
  script:
    - gcloud init --console-only
    - gcloud auth activate-service-account --key-file $SERVICE_ACCOUNT_SECRET --project $PROJECT_ID
    - gcloud --version
    - gcloud auth configure-docker $REGION
    - docker login -u _json_key --password-stdin https://$REGION < "$SERVICE_ACCOUNT_SECRET"
    - gcloud source repos clone $MANIFEST_REPOSITORY
    - echo "Modifying manifest file!"
    - ls
    - cd $MANIFEST_REPOSITORY
    - sed -i "s|tag:.*|tag:\ $TAG|" $DEV_VALUES_FILE
    - git config user.email "argo-cd@xxxxxx.iam.gserviceaccount.com"
    - git config user.name "argo-cd"
    - git add $DEV_VALUES_FILE
    - git commit -m "Modify docker tag $TAG"
    - export MANIFEST_COMMIT_HASH=$(git rev-parse HEAD)
    - git push origin HEAD
    - cd ..
    - echo "MANIFEST_COMMIT_HASH=$MANIFEST_COMMIT_HASH" >> build.env
  artifacts:
    reports:
      dotenv: build.env

migration_dev:
  stage: migration
  image: node:18
  tags:
    - shared
  environment:
    name: dev
  only:
    - dev
  dependencies:
    - bake_dev_manifest
  script:
    - npm install @nestjs/typeorm typeorm pg
    - npm run typeorm:migration:run

deploy_dev:
  stage: deploy
  image: alpine:latest
  tags:
    - shared
  environment:
    name: dev
  only:
    - dev
  dependencies:
    - migration_dev
  script:
    - apk add --no-cache wget
    - >
      wget --no-check-certificate \
        --method POST \
        --header "Authorization: Bearer $ARGOCD_API_KEY" \
        --header "Content-Type: application/json" \
        --body-data '{
          "appNamespace": "argocd",
          "revision": "HEAD",
          "prune": false,
          "dryRun": false,
          "strategy": { "hook": { "force": false } },
          "resources": null,
          "syncOptions": { "items": [] }
        }' \
        "$ARGOCD_API_SERVER/api/v1/applications/xxxxxxx/sync"
  artifacts:
    reports:
      dotenv: build.env

Gitlab UI에서 요런걸 볼 수 있게 된다. 언제 파이프라인을 돌릴 지 브랜치 정책과 관련해서 잘 결정하면 된다.

• K8S에 ES + kibana를 배포해보자.
• RestAPI를 통해 테스트해보고 예상한대로 작동하는지 확인해보자.
• Kibana를 통해 데이터를 확인해보자.

Directory Structure

elasticsearch
├── LICENSE
├── README.md
├── elasticsearch
│   ├── elasticsearch.yml
│   ├── jvm.options
│   └── log4j2.properties
├── kustomization.yaml
└── resources
    ├── client.yaml
    ├── data.yaml
    ├── loadbalancer.yaml
    └── master.yaml
kibana
├── LICENSE
├── README.md
├── kibana
│   └── kibana.yml
├── kustomization.yaml
└── resources
    ├── deployment.yaml
    └── loadbalancer.yaml

Code

https://github.com/HoneyJung/k8s-elasticsearch-kibana es.zip

Cluster 구성

1. kubectl apply -k elasticsearch
2. kubectl apply -k kibana
3. kubectl get all 결과

insert하고 search 해보자

1. Create Index

1. Insert data (똑같은 방식으로 데이터를 하나 더 넣었음)

    curl -XPOST "http://34.28.75.67/test_index/_doc" -H 'Content-Type: application/json' -d'
    {
      "name": "정재헌",
      "message": "Backend 개발자"           
    }'

2. search 해보기

   1. search all

       curl -X GET "http://34.28.75.67/test_index/_search" -H 'Content-Type: application/json' -d'
       {
         "query": {
           "match_all": {}
         }
       }'

2. search

    ```jsx
    curl -X GET "http://34.28.75.67/test_index/_search" -H 'Content-Type: application/json' -d'
    {
      "query": {
        "match": {"name": "정재헌"}
      }
    }'
    ```

    ![Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/9b8f058a-d127-430c-8d68-e58c356b1e38/70965475-3f45-4a6c-b468-262787a1d1f1/Untitled.png)

3. Kibana에서 데이터 확인하기

잘 들어가 있다.

Node, Shard, Replica

p ⇒ primary, r ⇒ replica라는 뜻이다.

1개의 primary shard가 1번 노드에 저장되어 있고 1개의 replica가 0번 노드에 저장되어 있다는 것을 알 수 있다. primary shard와 replica 모두 2개의 데이터와 8.8kb 크기인 것을 확인할 수 있다.

데이터를 좀 더 넣어보자.

10개가 됐다. 근데 뭔가 이상하다. 데이터 노드가 3개로 설정되어 있는데 왜 정작 사용되는건 2개이다.

Primary shard와 replica 수의 default 값이 1이다. 현재 클러스터에서 test_index만 운영한다고 했을 때는 이 default 값은 효율적이지 않다. 설정 값을 바꿔보자. 근데 es는 기본적으로 존재하는 index의 primary 수를 바꿀 수 없다. 바꾸는 방법이 있긴 하다. 궁금하면 이곳을 참고하자. 지금은 그냥 새롭게 index를 만들어 보자.

• 생성

• 데이터 insert

response가 달라졌다. shard 수가 3으로 나온다. 3의 의미는 primary shard + replica 2개를 의미한다.

  curl -X GET "http://34.28.75.67/_cat/shards"

  Reponse Info
  index shard prirep state docs storage ip node

  index: 인덱스의 이름
  shard: 샤드의 번호
  prirep: primary 또는 replica 샤드인지를 나타냄 (p: primary, r: replica)
  state: 샤드의 상태 (STARTED, UNASSIGNED 등)
  docs: 샤드에 속한 문서의 수
  storage: 샤드가 차지하는 디스크 공간 크기
  ip: 샤드가 위치한 노드의 IP 주소
  node: 샤드가 위치한 노드의 이름

총 10개를 넣었는데 분산되고 replica도 잘 작동하는 듯 하다.

NRT(Near Realtime)

사실 insert 후에 shard 상태를 보는 작업을 할 때, insert 했음에도 shard 상태에 변화가 없는 경우를 확인할 수 있다. es는 batch 형태로 refresh 되기 때문이다. 그런 경우에 refresh api를 사용하면 된다.

curl -X GET "http://34.28.75.67/test_index/_refresh"

목표

• ElasticSearch가 무엇인지 안다.
• ElasticSearch의 특징과 핵심 용어들을 안다.
• ElasticSearch를 실무적으로 사용하기 위해 최소한의 내부 동작 원리를 파악한다.

ElasticSearch의 특징

• Scale out, Availability - 분산 시스템이기 때문에 수평적으로 확장 가능하다. Replica를 사용하기 때문에 안정성이 높다.
• Restful - Data의 CRUD 작업이 HTTP Restful API를 통해 수행된다.
• 오픈소스
• NRT(Near Realtime) - 새로운 문서를 indexing할 때부터 검색 가능한 대기 시간이 1초 정도 걸림.
• schema X, Json으로 문서를 다룸.

단점

• Learning Curve, 진입 장벽
• Join X
• Transaction and Rollback X
• 데이터 변경에 효율적이지 않음.

ELK

ELK stack이란 elasticsearch를 포함해서 자주 함께 쓰이는 기술 stack들이다. Elasticsearch Logstash Kibana 세가지 오픈소스 프로젝트의 이니셜을 합쳐 만든 말이다. 최근 Beats가 새롭게 포함된다.

• Beats - Beats는 로그 혹은 메트릭이 발생하는 서버에 에이전트로 설치되어 데이터를 수집하고, 이 데이터를 Logstash로 전송한다. 위 다이어그램에는 Beats와 Logstash 사이에 메시지 큐가 위치하는 것을 확인할 수 있는데, 이는 안정성 또는 확장성 등을 위함이다.
• Logstash - 데이터 처리 파이프라인 도구. Logstash는 데이터를 적절히 필터링, 가공하여 Elastic Search로 전달한다.
• ElasticSearch - 검색
• Kibana - REST API를 통해 Elastic Search로부터 데이터를 가져와 유저에게 시각화와 간편한 데이터 검색 기능 등을 제공한다.

검색은 어떤 과정을 통해서 이뤄질까?

유사도 알고리즘

TF/IDF

ES 5.0 버전부터 default 알고리즘이 TF/IDF에서 BM25로 변경되었다. BM25는 TF/IDF의 variation이면서 좀 더 복잡하기 때문에 여기서는 TF/IDF로 만족하자.

TF = Term Frequency, 문서 내 특정 단어의 등장 빈도를 의미한다.

IDF = Inverse Document Frequency, 얼마나 특이한 단어인지를 의미한다. 특성 없는 단어들보다 중요한 단어에 가중치를 주기 위함이다.

검색을 위해서는 키워드와 문서들의 TF/IDF와 같은 Metric을 계산하게 된다.

대용량 텍스트 데이터가 있고 검색어와 문서들과의 TF/IDF를 계산한다고 가정해보자. RDB에 데이터가 있다고 가정하면 모든 문서를 돌면서 단어의 등장 여부를 count 해야 한다. ES는 어떻게 이걸 빨리 할 수 있을까?

Apache Lucene

Apache Lucene은 검색 엔진 라이브러리이다. ES가 대용량 텍스트 데이터 검색을 빠른 속도로 할 수 있는 것은 Lucene을 사용하기 때문이다. 위에서 말했듯이 Lucene이 ElasticSearch의 코어이기 때문에 Lucene의 내부동작을 알면 ElasticSearch의 내부동작의 상당 부분 이해할 수 있다.

Inverted Index

ES가 RDB보다 더 효과적인 텍스트 검색이 가능한 이유가 뭘까

ES는 Inverted Index를 사용한다. 이는 책 젤 뒤에 있는 찾아보기와 유사하며 단어사전이라도 부른다. 키워드를 키로 하고 키워드가 등장하는 위치를 기록하는 방식이다.

RDB에 있는 책 데이터에서 “과적합”(키워드)가 등장하는 문서를 검색한다고 가정해보자. like %과적합%와 같은 쿼리를 사용하게 될텐데 이는 인덱스를 타지 못하며 대용량 데이터에서 매우 느리다.

반면, Inverted Index를 사용한다고 할 때는 “과적합”이 등장하는 문서를 검색한다고 하면, Inverted Index에서 과적합의 value인 077, 099, 105, 108, 111, 126임을 매우 빠르게 알 수 있다.

사실 Inverted Index를 만드는 것이 이렇게 간단하지는 않고 실제로는 많은 복잡한 처리가 수행된다.

• term 단위로 쪼갠다(tokenizing) token이 항상 단어가 되는 것은 아니다(whitespace tokenizer)
• 대소문자 처리
• 동의어 처리
• a, the 같은 불용어 처리
• 형태소 분석을 통한 ~s, ~ing 처리
• 유사어 사전 제작 등

여기까지 어떻게 ES가 검색을 빨리할 수 있는지에 대해 큰 그림은 이해할 수 있었다.

Architecture와 용어

아래의 설명들은 분산 시스템에 익숙한 분들에겐 익숙한 개념일테니 빠르게 넘어가셔도 좋습니다.

클러스터(cluseter)

• 가장 큰 시스템 단위로, 최소 하나 이상의 노드로 이루어진 노드들의 집합
• 서로 다른 클러스터는 데이터의 접근, 교환을 할 수 없는 독립적인 시스템으로 유지됨
• 여러 대의 서버가 하나의 클러스터를 구성할 수 있고, 한 서버에 여러 개의 클러스터가 존재할 수도 있음

노드(node)

• Elasticsearch를 구성하는 하나의 단위 프로세스
• 역할에 따라 Master-eligible, Data, Ingest, Tribe 노드로 구분
• master-eligible node : 클러스터를 제어하는 마스터로 선택할 수 있는 노드
• master-eligible node 역할 : 인덱스 생성, 삭제 / 클러스터 노드들의 추적, 관리 / 데이터 입력 시 어느 샤드에 할당할 것인지 결정
• Data node : 데이터와 관련된 CRUD 작업과 관련있는 노드 / CPU, 메모리 등 자원을 많이 소모하므로 모니터링이 필요 / master 노드와 분리되는 것이 좋음
• Ingest node: 데이터를 변환하는 등 사전 처리 파이프라인을 실행하는 역할
• Coordination only node : data node와 master-eligible node의 일을 대신하는 노드 / 대규모 클러스터에서 큰 이점이 있음 / 로드밸런서와 비슷한 역할

인덱스(Index)

• RDBMS에서 database와 대응하는 개념.
• shard와 replica는 Elasticsearch에만 존재하는 개념이 아니라, 분산 데이터베이스 시스템에도 존재하는 개념.

샤드(Shard)

• 데이터를 분산해서 저장하는 방법.
• Elasticsearch에서 스케일 아웃을 위해 index를 여러 shard로 쪼갠 것.
• 기본적으로 1개가 존재하며, 검색 성능 향상을 위해 클러스터의 샤드 갯수를 조정하는 튜닝을 하기도 함.

복제(Replica)

• 또 다른 형태의 shard라고 할 수 있음
• 노드를 손실했을 경우 데이터의 신뢰성을 위해 샤드들을 복제하는 것
• 따라서 replica는 서로 다른 노드에 존재할 것을 권장
• 아래 사진에서 보는 바와 같이 Replica1은 Node2에 존재하는 것을 확인할 수 있음

Index, Shard, Replica 개념 링크

새로운 데이터가 들어오면 어떤 일이 일어날까

Segment

Segment : 실제 데이터가 담겨있는 조각. 실제 document와 Inverted Index가 모두 포함되어 있다. 각 노드에는 다수의 segment가 있을 수 있고 검색이 발생하면 모든 segment를 차례로 검색하고 결과를 합치게 된다.

segment의 수가 많으면 당연하게도 성능이 떨어지기 때문에 Lucene은 background에서 주기적으로 segment 파일들을 merge한다. 더 이상 추가 색인이 없이 일정 시간이 지나면 결과적으로 1개의 큰 segment만 남게된다.

새로운 document가 insert 되면 벌어지는 일

• 인메모리 버퍼에 쌓인다.
• 정책에 따라 내부 버퍼(큐)에 일정 크기 이상의 데이터가 쌓이거나 일정 시간이 흐를 경우 버퍼에 쌓은 데이터를 한꺼번에 모아 처리한다. (ElasticSearch가 NRT인 이유)
• 모인 데이터를 indexing하고 새로운 하나의 segment를 추가한다.
• fsync가 아닌 write로 Disk가 아닌 메모리에만 쓴다. (Disk 쓰는 작업이 cost가 크기 때문에)
• 일정 주기마다 Disk로 flush해준다.

Segment의 불변성

루씬에선 세그먼트가 주기적인 merge 작업에 의해 통합되기 전까지 수정을 허용하지 않는 불변성 (Immutability) 을 지님.

그렇기 때문에 update 연산은 기존 데이터 삭제 후 다시 생성하게 된다.

Delete 연산이 발생하면 flag만 up해서 검색 대상에서 제외를 시키지만 바로 삭제하진 않는다. 실제로 삭제되는 시점은 주기적으로 진행되는 segment merge 시점.

이로 인해 얻을 수 있는 것

• 동시성 문제 회피 가능
• Cache 활용성
• 만약 불변성을 정책이 없다면, 수정이 발생하면 inverted index 다시 전면 수정해야함.

Reference

https://amazoneberea.tistory.com/41 https://m.blog.naver.com/occidere/222855273511 https://amazoneberea.tistory.com/41 https://loosie.tistory.com/833 https://jaemunbro.medium.com/elastic-search-기초-스터디-ff01870094f0 https://velog.io/@soyeon207/이론-Elasticsearch-란 https://velog.io/@mayhan/Elasticsearch-유사도-알고리즘 https://wikidocs.net/31698 https://blog.naver.com/occidere/222855568900 https://hudi.blog/elk-stack-overview/ https://icarus8050.tistory.com/52 https://ksk-developer.tistory.com/24

내 첫 정직원 회사인 바비디를 떠나게 됐다. 바비디를 떠나기로 마음 먹었던 이유

• 바비디에서 에너지를 쏟아냈기 때문에 바비디에서의 남은 에너지가 고갈되었음을 느꼈다.

• 기술적으로 더욱 다양한 challenge들을 경험하고 싶었다. 바비디에서는 서비스를 빠르게 기획하고 만드는 것이 중요했다. 개발자들도 기획과 user research까지 할 정도로 product의 처음부터 끝까지를 경험할 수 있다는 장점이 있었다. 동시에 기술적인 challenge한 상황이 생길 정도로 고도화된 제품을 경험하지 못한다는 단점이 있었다.
• "한 살이라도 어릴 때 큰 회사를 경험해보자!". 스스로를 스타트업을 선호하는 사람이라고 생각해왔는데 "정말 그럴까?"라는 생각이 들었다. 물론 대기업에서 주는 안락함(?)도 부러웠고 겪어보고 싶었다.

이직은 정말 너무 힘든 일인 것 같다. 힘든 것도 힘든거지만 너무 에너지 소모가 큰 일이다. 다니고 있는 회사에서 일은 일대로 하면서 이직 준비를 해야하기 때문이다. 회사도 알아보고 지원해야하며 이력서를 작성해야하고 면접 준비도 해야한다. 그래도 성공적으로 이직한 나 아주 칭찬한다.

떠나게 됐지만 좋은 추억들이 많고 많이 배웠던 바비디, 같이 재밌고 열심히 일했던 동료들, 나를 신뢰해주시고 격려해주신 대표님들에게 감사함을 전하고 싶다.

여행

이직은 너무 힘들고 스트레스를 유발하는 일이다. 그럼에도 이직의 장점 중 하나는 이직 사이 텀에 가는 쉴 수 있는 시간이 아닐까 싶다. 여행을 좋아하는 나에게는 긴 기간 동안 여행을 갈 수 있는 최고의 기회가 아닐까 싶다.

사하라의 로망

내가 가장 좋아하는 책은 생택쥐베리의 "어린왕자"다. 최근에 재밌게 읽은 책은 "연금술사". 문학이 아닌 책 중 가장 재밌게 읽은 책은 "나는 세계일주로 경제를 배웠다".

이 세 책의 공통점은 사하라 사막이 등장한다는 것이다. 그렇다. 난 사하라 사막에 대한 로망이 있었다. 특히 어린왕자를 읽고 상상해왔다. 쏟아질 듯한 별들 아래서 모닥불을 피워놓고 어린왕자와 대화할 수 있는 곳. 귀여운 사막 여우가 있는 곳. 숨겨진 보물이 있는 곳. 나에게 사하라 사막이란 낭만 있는 곳이었다.

모로코를 선택했다. 모로코는 신비한 곳이다. 아프리카이면서 중동과 유럽이 섞여있다. 무슬림이면서 프랑스어를 공용어로 사용한다. (프랑스와 사이가 좋지 않고 베르베르어와 아랍어도 많이 사용하지만) 사실, 무슬림에 대한 막연한 두려움이 있었다. 하지만 거기서 느낀 것은 매우 착하고 친절한 사람들이다. 위협적인 상황은 전혀 없었다.

사하라 사막의 밤하늘이 정말 아름다웠다. 사하라 사막 투어를 어떤 가족과 함께 했는데 가족끼리 밤하늘을 보고 감상하는 모습이 부럽고 좋아보였다. 다음에는 내가 사랑하는 사람과 사막의 밤하늘을 감상해보고 싶다.

사하라에 대한 감상

사하라 사막의 낮은 당연하게도 너무 너무 덥다. 계속 물을 마시게 되고 정말 숨이 턱턱 막히는 더위와 햇빛이다. 낮 투어가 끝나고 어둠이 찾아오자 리터럴리 언제 그랬냐는 듯 사막은 차갑게 식었다. 마치 생동감 있던 영화가 갑자기 갑자기 흑백 사진으로 바뀐 것 같았다.

의외로 내가 느낀 감정은 슬픔이었다. 지금 나한테 있는 어떠한 것도 언젠가 그렇게 될 것이라는 생각이 들었다. 예를 들면, 지금은 나름 건강하고 에너지 넘치는 나의 생명도 한순간에 언제 그랬냐는 듯이 사라져버릴 것 같은 느낌이었다. 사실은 매우 자연스러운 일이지만 너무 적나라하게 느껴졌다.

식중독

음식은 나와 맞지 않았다. 그나마 꼬치 같은 음식을 먹을 수 있었는데 막바지에 먹은 음식이 문제가 있었나 보다. 아무래도 위생이 좋지 않다 보니 그랬나보다. 모로코를 떠나서 런던에 도착하자 마자 정말 심각한 식중독에 걸린다...

6대주 정복

무슨 의미가 있겠냐만은 지구의 6개의 대륙에 다 가보게 됐다. 뿌듯하다. "태어난 김에 세계일주"라는 프로그램처럼 태어난 김에 더 열심히 여행다녀야겠다.

손흥민

흥민이형의 나이가 어느덧 만 31살이 되었다. 토트넘의 주장이 됐고 여전히 절정의 기량을 펼치고 있다. 하지만 언제 에이징 커브가 와도 이상하지 않은 나이가 됐다. 개인적으로 대한민국에서 손흥민 같은 선수는 내가 죽을 때까지 나오기 힘들다고 생각한다. 손흥민 국가대표 경기는 본 적이 있지만 소속팀 경기를 직관을 해본적이 없었다. 따라서 이번에 무조건 봐야겠다는 생각이었다. 이번 여행의 가장 큰 목표였다. 그래서 축구 경기 일정에 맞추다 보니, 원래 모로코와 포르투갈이 가까워서 묶어서 가곤 하는데 경로가 이렇게 비효율적이게 됐다. 그만큼 축구가 중요했다.

런던에 도착하자마자 끔찍한 식중독 증상이 왔다. 원래도 축구에만 관심 있었기 때문에 관광지에 대해서는 깊게 생각하지 않았다. 하지만 정말 몸이 너무 아팠고 설사도 너무 심했다. 그래서 아무것도 못하고 숙소에만 있었다...일주일 넘게...축구만 겨우 봤다. 특히 토트넘 대 첼시는 경기 보면서 화장실도 많이 갔고, 경기 중에도 너무 아팠다. 또 얼마나 춥던지...돌아오는 길에 진짜 춥고 아파서 너무 고통스러웠다. 정신력으로 악으로 깡으로 다녀왔다. 근데 결과도 충격적이었다. 무패로 1등을 달리던 토트넘이 핵심 선수 2명 퇴장에 핵심 선수 반더벤의 부상까지 대패했다. 2명이 부족한 상황에서도 라인을 올리는 낭만 있는 경기를 펼쳤치긴 했지만. 결과적으로 완패했다. 인상적인 경기이긴 했다.

2번째 경기인 울버햄튼 경기는 1타 2피 경기였다. 울버햄튼에 황희찬도 있기 때문이다. 울버햄튼이란 도시는 축구팀 빼고는 생소한 도시였는데 너무 예쁘고 평화로운 도시였다. 토트넘 경기 좌석이 경기를 보기 가장 좋은 좌석(60만원)이었다면, 이번 경기는 응원이 가장 격한 곳이었다. 코너 플레그 바로 앞이고(15만원) 바로 옆에 어웨이 팬들이 있다. 애초에 스탠딩 좌석이라고 쓰여있는 곳이다. 현지 분위기를 느끼기에는 이런 좌석을 추천한다. 정말 미친 응원의 열기를 느낄 수 있다. 어웨이 팬들을 향한 욕과 조롱은 덤. 울버햄튼 같은 팀의 특성이기도 하다. 빅클럽이 아니기 때문에 팬들이 더 열성적이고 찐팬들이 많다. 토트넘은 런던 연고이기도 하고 빅클럽이기 때문에 "한번 구경 온" 느낌의 팬들이 많다. 경기장도 비교가 많이 됐다. 토트넘 구장은 EPL에서 가장 최신 구장인만큼 깨끗하고 신식이다. 반면, 울버햄튼 경기장은 비교적 작고 구식이다. 복도가 좁고 화장실도 작아서 하프타임에 화장실 가려다 돌아왔다...이 경기도 레전드 경기였다. 두 코리안 리거가 별다른 활약은 없었지만 울버햄튼이 극적인 역전승을 거뒀다. 미쳐버린 울버햄튼 로컬 팬들의 모습이 아직도 눈에 선하고 그 속에 내가 있었다는게 추억이 된 것 같다. 한 가지 아쉬운 점은 이 경기 이후에 바로 A매치 경기가 있었기 때문에 선수들을 만나지 못했다. 애꿏은 극적인 결승골 주인공 사라비아 선수만 한국 사람들(나 포함)한테 싸인을 해주고 있었다.

현지 할머니가 "영어 할 줄 알아요?"라는 말과 함께 나에게 다가왔다. 이후 조금 스몰톡을 나눴는데 엄청난 한국인 인파를 보고 신기했던 모양이다. 저들은 누구이며 어디에서 왔으며 심지어 티켓은 어디서 났냐며 질문 폭탄을 날렸다. 울버햄튼 시골에 저렇게 많은 한국인들을 본 것이 아마 처음이었나보다. 할머니의 표정이 너무 재밌었다.

포르투

저번에 가족 스페인 여행에서 나만 일정상 포르투갈을 가지 못했다. 그 중 가장 가고 싶었던 도시는 포르투였다. 조용하고 아기자기한 도시. 아쉬웠기 때문에 이번에 가게 됐다.

날씨가 안좋았고 흐렸던 것이 아쉬웠지만 도시가 아기자기하고 낭만 가득했다. 여행 마지막에 좀 편하게 쉬는 것이 계획이었고 식중독이 거의 회복하고 왔기 때문에 나름 잘 쉬었던 것 같다.

강도를 만나다

멘탈을 잘 회복하던 중 내 멘탈은 다시 박살난다. 동행과 걸어가다 소매치기를 만난다. 동행이 도와달라고 소리쳤다. 북아프리카계 사람 둘이 있었고 그 중 한명을 붙잡고 있었다. 자신의 여권을 가방에서 빼갔다고 했고 도망치려고 하자 도와달라고 한거였다. 나도 달려들어 거들었다. 거의 제압하자 소매치기는 주머니에서 칼을 빼들었다. 우린 혼비백산해서 도망쳤다. 난 길을 건너 도망치다 영화처럼 차에 치일 뻔 했다.(끼이이익!) 그 동행은 도망치다 넘어져서 칼에 찔릴뻔 했다.(비오는 날이었다) 다행히 착한 현지인들이 도와줬다. 아찔했다. 충격적인건 경찰서가 바로 옆이었는데 아무 도움이 안됐다는 것이다. 계속 도움을 요청했지만 나와보지도 않았다. 참...

격투기를 좋아하기도 하고 MBTI가 극 N인 나는 칼든 괴한을 만나는 상상을 살면서 수천번은 했던 것 같다. 칼을 보자마자 아무 생각도 안들고 도망쳐야겠다는 생각이 들었다. 무력감을 느꼈다. 만약 동행이 아니라 내 가족이었다면 어땠을까?라는 생각이 들었다. 격투기를 제대로 배워볼까...많은 감정을 느끼게 됐다.

Hello LG AI Research

대학교 동기들이 다니고 있기도 해서 일찍이 관심이 있던 회사였다. 동기의 추천을 받기도 했다. 입사가 더 맛있게 느껴졌던 것은 채용 시장이 얼어붙은 시기이기도 하고 면접 날짜가 밀리는 등 채용 과정이 너무 길어져서 애를 태웠기 때문이다.

LG AI Research에 출근한지 얼마 안됐지만 참 오묘한 곳이다. 대기업스럽기도 하고 스타트업스럽기도 하다. LG의 계열사이지만 생긴지 얼마 안됐기도 하고 보다 자유로운 분위기를 추구하는 것 같다. 확실한 건 LG에서 가장 빵빵한 지원을 받는 곳인만큼(현 시점..) 근무 환경이 좋다.

팀 분들이 매우 친절하게 대해준다. 가족같은 분위기가 있고 온화하다. 이게 입사하고 알게된 LG의 "인화사상"인가 싶다. 거친 토론(?)에 익숙해져있는 나에게 좀 생소한 분위기이다.

같은 날 입사한 동료도 있고 며칠 뒤에 입사하신 분도 있어서 한결 수월하게 적응하고 있는 것 같다. 팀에 친구가 있는 것도 역시 큰 도움이 된다. 감사하게 생각한다.

반성 & 다짐

걱정, 적응, 성장

새로운 회사에 잘 적응하기. 열심히 잘 해보고 싶은 마음이 크다. 이곳에선 MLOps를 많이 하는 것 같은데 나에게는 생소한 분야다. 러닝 커브가 걱정되기도 하지만 그만큼 많이 배울 수 있을 것 같다. 열심히 공부해서 빨리 퍼포먼스를 내고싶다. 기술적으로도 잘 성장하고 싶고 내 커리어에 대해서도 잘 생각해보고 준비하고 싶다.

사실 LG AI Research는 지금까지 경력직들만 뽑아왔다. 나도 경력직으로 오긴 했지만 내 경력은 해봐야 2년이다. 그래서 더욱 걱정되고 긴장이 된다. 비슷한 시기에 입사한 2명도 나보다 훨씬 긴 경력을 보유하고 있다. 걱정되지만 몸으로 떼워야지 싶다. 압박감이 있는 만큼 빠르게 성장할 수 있길 기대한다.

체력과 게으름

늘 생각하지만 난 게으르다. 여젼히 잠이 너무나 많고 게으름 피우는 걸 좋아한다. 그런 내 모습을 좋아하지 않다. 그리고 그렇게 살수록 체력이 좋지 않게됨을 느끼기도 한다. 체력은 정말 중요하다. 내년에는 체력적으로 강한 사람이 되고 싶다. 강한 체력과 더불어 시간을 더 효율적으로 쓸 수 있는 사람이 되고 싶다.

LLM, Generative AI, semantic search 등을 포함하는 기술이 발전하면서 Vector DB의 중요성도 커졌다. AI는 벡터로 Data를 이해한다. 여기서 말하는 vector는 간단하게는 다차원 공간에서 존재하는 한 점 혹은 좌표라고 상상하면 된다.

그래서 Vector DB가 뭐냐? vector를 다루는데에 특화된 Database이다. 대표적으로는 일반적인 RDB나 NoSQL에서 제공하지 않는 vector embeddings의 search나 retrieval을 효과적으로 수행할 수 있는 알고리즘 및 시스템을 제공한다.

Vector Index

Vector Index랑 Vector DB가 혼용돼서 쓰이곤 하는데, Vector Index는 Vector DB의 핵심 기능이자 포함되는 기능이다.

대표적인 Vector Index는 FAISS(Facebook AI Similarity Search).

FAISS는 facebook research에서 개발한, dense vector들의 클러스터링과 유사도를 구할때 사용하는 Standalone vector index 라이브러리이다. C++로 작성되었으며 python에서 지원된다. 그리고 GPU 상에서도 효율적으로 동작하도록 개발 되었다. 구체적인 알고리즘은 뒤에서 살펴보자.

어쨌든 Vector Index에 추가로 일반적인 Database이 하는 다음과 같은 일들도 해준다.

• Data management : CRUD와 같은 기능들.
• Metadata storage and filtering : vector 뿐만 아니라 일반적인 형태의 데이터(meta data)들도 함께 다룰 수 있다.
• Scalability : Support for distributed and parallel processing.
• Backup, 다른 tool들과 integration, Security, Access control

In short, a vector database provides a superior solution for handling vector embeddings by addressing the limitations of standalone vector indices, such as scalability challenges, cumbersome integration processes, and the absence of real-time updates and built-in security measures, ensuring a more effective and streamlined data management experience.

How does vector DB work?

Vector DB가 잘 해야하는 일은 Approximate Nearest Neighbor(ANN) search이다. 이를 위해서 Hashing, quantization, graph-based search 등의 기법을 사용한다. 때로는 조합해서!

일반적인 Flow

1. Indexing: The vector database indexes vectors using an algorithm such as PQ, LSH, or HNSW (more on these below). This step maps the vectors to a data structure that will enable faster searching.

2. Querying: The vector database compares the indexed query vector to the indexed vectors in the dataset to find the nearest neighbors (applying a similarity metric used by that index)

3. Post Processing: In some cases, the vector database retrieves the final nearest neighbors from the dataset and post-processes them to return the final results. This step can include re-ranking the nearest neighbors using a different similarity measure.

Algorithms

Prerequisite

K-means algorithm

데이터를 k개의 cluster로 묶는 알고리즘.

Random Projection

가장 간단한 알고리즘. 기본 아이디어는 Random Projection Matrix을 사용하여 고차원 벡터를 저차원 공간으로 투영하는 것입니다. 우리는 random number로 matrix를 만든다. 행렬의 크기는 원하는 저차원 공간의 크기로 한다. 그런 다음 입력 벡터와 행렬의 Dot product을 계산하고, 그 결과 원래 벡터보다 더 적은 차원을 가지지만 여전히 유사성을 유지할 것이라고 기대한다.

쿼리가 들어오면 마찬가지로 쿼리도 같은 Projection Matrix을 사용해서 저차원 벡터로 projection하고 저차원 vector를 기반으로 nearest neighbors를 찾는다. 차원을 줄였기 때문에 Search process의 속도를 개선할 수 있다.

이미 느껴졌을테지만, Random Projection은 Approximate method이다. 그리고 참고로 matrix가 random할수록 성능이 좋다고 한다.

Product Quantization(PQ)

PQ는 제품 고차원 벡터에 대한 Lossy Compression 기술이다. 원본 벡터를 작은 청크들로 나누고 각 청크에 대한 대표 "코드"를 만들어 각 청크의 표현을 단순화한 다음 유사성 작업에 필수적인 정보를 잃지 않고 모든 청크를 다시 결합합니다.

1. Splitting -The vectors are broken into segments.

2. Training - we build a “codebook” for each segment. Simply put - the algorithm generates a pool of potential “codes” that could be assigned to a vector. In practice - this “codebook” is made up of the center points of clusters created by performing k-means clustering on each of the vector’s segments. We would have the same number of values in the segment codebook as the value we use for the k-means clustering.

3. Encoding - The algorithm assigns a specific code to each segment. In practice, we find the nearest value in the codebook to each vector segment after the training is complete. Our PQ code for the segment will be the identifier for the corresponding value in the codebook. We could use as many PQ codes as we’d like, meaning we can pick multiple values from the codebook to represent each segment.

4. Querying - When we query, the algorithm breaks down the vectors into sub-vectors and quantizes them using the same codebook. Then, it uses the indexed codes to find the nearest vectors to the query vector.

PQ알고리즘도 결국 Approximate하는 방식이다. 따라서 K-means 알고리즘에 쓰인 K의 값에 따라 accuracy와 latency의 trade-off가 발생한다.

Locality-sensitive hashing(LSH)

요거도 비슷하다. vector들을 Locality를 보존하는 hash function을 사용해 bucketdㅡ로 분류하여 저장한다. 그리고 쿼리 또한 같은 hash function으로 해당하는 bucket을 찾는다. 그리고 그 버킷 안에 있는 벡터들과 거리를 계산한다. 버킷을 통해 한번 걸러서 비교해야할 벡터들의 모수를 줄이는 방식.

Hierarchical Navigable Small World (HNSW)

https://towardsdatascience.com/similarity-search-part-4-hierarchical-navigable-small-world-hnsw-2aad4fe87d37 https://www.pinecone.io/learn/series/faiss/hnsw/

Vector DB 종류 비교

https://objectbox.io/2023_06_13_vector-databases.htm

Benchmark

gist-960-euclidean dataset, which consists of 1 million vectors. client machine 4cores 8G DB engine machine 16Cores 32G Ram

참고 https://medium.com/@richard_50832/benchmarking-epsilla-with-some-of-the-top-vector-databases-543e2b7708e5

https://jina.ai/news/benchmark-vector-search-databases-with-one-million-data/

References

https://mccormickml.com/2017/10/13/product-quantizer-tutorial-part-1/ https://www.pinecone.io/learn/vector-database/ https://www.youtube.com/watch?v=PNVJvZEkuXo https://www.pinecone.io/learn/series/faiss/product-quantization/

RAG(Retrieval Augmented Generation)는 미리 학습된 LLM(대규모 언어 모델) 및 자체 데이터를 사용하여 응답을 생성하는 패턴이다.

왜 필요한가

현재 널리 쓰이고 있는 Chatgpt와 같은 LLM은 수많은 범용적인 데이터로 그리고 특정 시점 데이터로(과거 어떤 시점) 학습되었습니다. 그러나 때로는 범용적이지 않고 자신만이 갖고 있는 데이터나 최신 데이터로 작업해야 하는 경우도 있습니다.

해당 경우에 LLM을 활용할 수 있는 두 가지 방식이 있다.

1. 새로운 데이터로 모델을 Fine tuning한다.
2. RAG를 활용한다.

Fine tuning은 좋은 해결책이 될 수 있지만 값이 비싸다는 단점이 있어서 RAG가 효율적인 방법이 될 수 있다.

추가적으로 RAG를 잘 사용하면 LLM의 고질적인 문제인 Hallucination도 어느 정도 줄일 수 있다는 장점도 있다.

그래서 어떻게 동작하는건데

Flow는 다음과 같다.

1. Data를 chunk로 쪼갠다.
2. 쪼갠 chunk를 embedding model로 vector화한다.
3. Vector들을 Vector DB에 저장한다. 다음 글에서 Vector DB에 대해 다룰거라서 간단하게만 이야기하자면, 아래 그림의 파란색 부분처럼 Vector Space에 벡터들을 두고 벡터들간의 유사도를 계산할 수 있는 상태.

4. 유저가 질문한다.(Query)
5. 유저의 query도 embedding model로 vector화한다.
6. 유저의 query와 가장 유사도가 높은 N개의 vector를 retrieval한다.
7. 벡터들에 해당하는 원본 데이터들을 가져온다.
8. 그 데이터들(A)을 Prompt(B)와 조합해 LLM에게 "A라는 정보에서 B라는 질문 대답해줘"라는 식의 명령을 내리고 결과를 유저에게 전달한다.

Vector Embedding(참고)

Memo

최근 엄청난 성능을 보이는 LLM들을 보면서 신기함을 느꼈지만 활용에 있어서, 특히 비지니스적으로 애매한 부분이 있었다고 생각하는데 RAG가 좋은 Use case? Framework?이 될 수 있을 것 같당.

What is Nest Loop Join

줄여서 NL JOIN이라고도 불리는 NESTED LOOP JOIN은 2개 이상의 테이블에서 하나의 집합을 기준으로 순차적으로 상대방 Row를 결합하여 원하는 결과를 조합하는 조인 방식입니다. 조인해야 할 데이터가 많지 않은 경우에 유용하게 사용됩니다. NESTED LOOP JOIN은 드라이빙 테이블로 한 테이블을 선정하고 이 테이블로부터 where절에 정의된 검색 조건을 만족하는 데이터들을 걸러낸 후, 이 값을 가지고 조인 대상 테이블을 반복적으로 검색하면서 조인 조건을 만족하는 최종 결과값을 얻어냅니다.

Cost Analysis

이 Nested Loop Join은 멍청하다. 아래 그림에서 볼 수 있듯이 drving table의 튜플마다 Driven table을 full scan하기 때문이다. 참고로 Cost: M + (m*N)에서 M은 table R을 page 단위로 가져오기 때문에 그 비용이다. 뭔가 더 최적화할 수 있을 것이라 생각한다면 당신은 짱! 하지만 일단 차근차근 보자.

수식을 보면 알아차릴 수 있듯이 어떤 테이블이 Driving, Driven table인지에 따라서 Cost가 달라진다. 작은 테이블이 Driving하면 이득.

Block Nested Loop Join

Disk Access에 관해 조금 더 최적화된 버전의 Nested Loop Join이 있다. 그게 바로 Block Nested Loop Join이다. 아래 Pseudo 코드를 보자.

Cost Analysis

마찬가지로 작은 테이블이 Driving table일 때 더 이득이다.

근데 위에서 본 Block Nested Loop Join은 2개 block 크기의 메모리를 사용한다. 근데 만약 B개의 block을 사용한다면?

지금까지는 index가 설정되어 있지 않다는 가정이 있었다. 이번엔 Index와 연관지어 생각해보자.

Index Nested Loop Join

먼저 Index에 대해 복습 ! https://velog.io/@nice-one-roy/Database-Index

• Key Takeaways → Pick the smaller table as the outer table. → Buffer as much of the outer table in memory as possible. → Loop over the inner table (or use an index).
• Algorithms → Simple / Stupid → Block → Index

참고자료 CMU database lecture note https://15445.courses.cs.cmu.edu/fall2022/slides/11-joins.pdf

관계형 데이터베이스에서 테이블을 정규화하여 불필요한 정보의 반복을 방지합니다. 그런 다음 조인 연산자를 사용하여 정보 손실 없이 두 개 이상의 테이블로 나누었던 데이터를 조합할 수 있다.

성능

optimizer

optimizer는 query에 대해 최적의 실행방법을 결정하는 역할을 하는 녀석이다. 즉 query를 실제로 어떻게 실행시킬지 Excution Plan을 짠다.

Cost Metric for Analysis: # of IOs to compute join

Assume: → M pages in table R, m tuples in R → N pages in table S, n tuples in S

There are many algorithms for reducing join cost, but no algorithm works well in all scenarios.

=> 늘 그렇듯 Silver bullet은 없고 다양한 알고리즘이 있고 상황에 따라 알맞는 알고리즘이 사용되야한다.

유명한 알고리즘들을 순서대로 정리해보자. 첫번째로 Nested Loop !!

동기 & SetTimeout

1

첫번째로 기본적인 동기 함수와 SetTimeout의 콜백 함수가 어떤 방식으로 실행되는지 보자.

const foo = () => console.log('First');
const bar = () => setTimeout(() => console.log('Second'), 500);
const baz = () => console.log('Third');

bar();
foo();
baz();

정답 : Frist -> Third -> Second

1. bar 함수를 Call Stack에 넣었다.
2. setTimeout이 있으므로 Web API에 집어넣고 bar 함수는 Call Stack에서 제거된다.
3. Web API에서 타이머가 실행되는 동안 foo가 호출되어 Call Stack에 쌓였다. console을 찍는다.
4. baz가 호출되었고 console을 찍고 제거된다.
5. 그 동안 Web API에서는 Task Queue에 setTimeout에 있던 콜백을 집어넣는다.
6. Event Loop는 Call Stack에서 아무것도 없음을 확인한 후 Task Queue에 있던 콜백을 Call Stack에 넣는다. 그리고 실행.

이런 식으로 Event Loop는 실행할 함수를 관리하는 역할로 Call Stack과 Task Queue의 함수를 계속 확인한다. 이렇게 반복되는 매 순회(iteration)를 tick 이라고 부른다.

SetTimeout같은 콜백 함수는 Task Queue로 들어가게 되고 Task Queue에 있는 task들은 Call Stack이 비어 있어야지만 실행된다.

2

function delay() {
  for (var i = 0; i < 100000; i++);
}
function foo() {
  delay();
  bar();
  console.log('foo!'); // (3)
}
function bar() {
  delay();
  console.log('bar!'); // (2)
}
function baz() {
  console.log('baz!'); // (4)
}

setTimeout(baz, 10); // (1)
foo();

출력은 어떤 순서로 될까? delay 함수는 10만의 연산을 해야하므로, 꽤 올래 걸리기 때문에 baz가 가장 먼저 찍힐까? 아니다. setTimout이 Task Queue에 넣은 후, Call Stack이 비어있을 경우 Event Loop가 Task Queue에 있는 baz를 Call Stack으로 넘겨줄 것이기 때문에 baz가 가장 나중에 찍힌다. setTimeout의 두번째 인자인 10 은 10ms 라는 의미를 가진다. 즉, 0.01초다. 그럼에도 불구하고 10ms 보다 더 늦게 실행될 것이다. 즉, 자바스크립트의 타이머는 정확한 타이밍을 보장해주지 않는다.

Promise

1

setTimeout(function () {
  // (A)
  console.log('A');
}, 0);
Promise.resolve()
  .then(function () {
    // (B)
    console.log('B');
  })
  .then(function () {
    // (C)
    console.log('C');
  });

Promise도 비동기로 실행되니까 Task Queue에 추가되어 순서대로 A -> B -> C로 찍힐까? 아니다 답은, B -> C -> A다. 이유는 바로 Promise가 MicroTask Queue를 사용하기 때문이다.

MicroTask Queue는 일반 Task Queue보다 더 높은 우선순위를 갖는 태스크다. Task Queue에 대기중인 태스크가 있더라도 MicroTask Queue가 먼저 실행된다. setTimeout은 콜백 A를 Task Queue에 추가하고 Promise의 then() 메서드는 콜백 B를 Task Queue가 아닌 MicroTask Queue에 추가한다. 콜백 B가 실행되고 나면 두번째 then() 메서드가 콜백 C를 MicroTask Queue에 추가한다. Event Loop는 다시 MicroTask Queue를 확인하고, 큐에 있는 콜백 C를 실행한다.

이후에 MicroTask Queuerk 비었음을 확인한 다음 Task Queue에서 콜백 A를 꺼내와 실행한다. 즉, MicroTask Queue에는 Promise가 담기며 Event Loop가 Task Queue 보다 먼저 실행한 후, 다시 then 절이 있는지 확인하고 다시 MicroTask Queue에 집어넣었다.

MicroTask Queue에는 Promise뿐 아니라, Observer API, Node.js의 process.nextTick 등이 그 대상이 된다.

📍 마이크로 태스크 vs 매크로 태스크

• Queue는 Macro Queue와 MicroQueue가 있다. Micro Queue가 우선순위가 더 높다.

마이크로 태스크들은 실행하면서 새로운 마이크로 태스크를 큐에 추가할 수도 있다. 새롭게 추가된 마이크로 태스크도 큐가 빌 때까지 계속해서 실행된다.

반대로, 이벤트 루프는 매크로 태스크 큐에 있는 것을 실행시키기 시작할 때 있는 매크로 태스크만 실행시킨다. 매크로 태스크가 추가한 매크로 태스크는 다음 이벤트 루프가 실행될 때까지 실행되지 않는다.

2

console.log('Start!');

setTimeout(() => {
  console.log('Timeout!');
}, 0);

Promise.resolve('Promise!').then(res => console.log(res));

console.log('End!');

정답 : Start => End => Promise! => TimeOut!

Promise는 Macro Queue, Timeout!은 Micro Queue에 들어가고 Call stack이 빌때까지 기다렸다 Micro Queue부터 실행되기 때문이다.

Async/Await

비동기 함수가 Promise를 반환하는데 await 키워드를 비동기 함수 앞에 붙여주면 비동기 함수가 Promise를 반환할 때까지 코드를 일시 중지 할 수 있다. 다음 코드가 어떻게 실행되는지 살펴보자.

const one = () => Promise.resolve('One!');

async function myFunc() {
  console.log('In function!');
  const res = await one();
  console.log(res);
}

console.log('Before function!');
myFunc();
console.log('After function!');

• Before function!
• In function!
• After function!
• One!

Before function!이 실행되었고, myFunc 함수 내부의 In function!이 먼저 찍혔다.

이 과정으로 Promise.then 과 async 함수의 차이점을 알 수 있다.

async 함수에서는 await 를 만나면 함수가 중단되고 MicroTask Queue로 들어간다. Promise는 곧바로 MicroTask Queue에 들어간다.

마지막 문제

function a() {
  console.log('a1');
  b();
  console.log('a2');
}

function b() {
  console.log('b1');
  c();
  console.log('b2');
}

async function c() {
  console.log('c1');
  setTimeout(() => console.log('setTimeout'), 0);
  await d();
  console.log('c2');
}

function d() {
  return new Promise(resolve => {
    console.log('d1');
    resolve();
    console.log('d2');
  }).then(() => console.log('then!'));
}

a();

1. a 함수 호출, console.log 실행, 출력 → a1
2. b 함수 호출, console.log 실행, 출력 → b1
3. c 함수 호출, console.log 실행, 출력 → c1
4. setTimeout이 Task Queue에 쌓임.
5. d 함수 호출, 첫 번째 console.log 실행, 출력 → d1 (비동기X)
6. 두 번째 console.log 실행, 출력 → d2 (비동기X)
7. .then 콜백은 백그라운드를 거쳐 마이크로 태스크 큐에 쌓임
8. d 함수 호출 완료 후 await를 만나고 async 함수 c는 중단 async 함수의 나머지는 마이크로 태스크 큐에 쌓임
9. c 함수를 호출한 실행 컨텍스트(b함수)로 돌아가서 console.log 실행, 출력 → b2
10. b 함수를 호출한 실행 컨텍스트(a함수)로 돌아가서 console.log 실행, 출력 → a2
11. Call Stack이 모두 비워지고, Event Loop가 MicroTask Queue를 확인. then 콜백, async 함수가 쌓여있음.
12. .then 콜백 실행, console.log 출력 → then!
13. async 함수 중단된 곳부터 이후로 실행, console.log 출력 → c2
14. 또다시 Event Loop가 Task Queue를 확인, setTimeout의 콜백이 쌓여있음. setTimeout의 콜백을 Call Stack으로 옮겨 실행 및 출력 → setTimeout

정답

a1
b1
c1
d1
d2
b2
a2
then!
c2
setTimeout

참고 https://joshua1988.github.io/web-development/translation/javascript/how-js-works-inside-engine/ https://hmk1022.tistory.com/entry/task-queue-micro-task-queue https://pozafly.github.io/javascript/event-loop-and-async/ https://velog.io/@devstone/%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EB%A3%A8%ED%94%84-%EA%B8%B0%EB%B0%98%EC%9C%BC%EB%A1%9C-%EB%B9%84%EB%8F%99%EA%B8%B0-%EC%B2%98%EB%A6%AC-%EB%9C%AF%EC%96%B4%EB%B3%B4%EA%B8%B0

자바스크립트 엔진의 대표적인 예는 Google V8 엔진이다. Chrome 브라우저, NodeJS 런타임 등에서 사용되고 있다. V8 은 Chrome과 Node.js에서 사용합니다. 아래는 엔진의 구조도를 간단히 나타낸 그림입니다.

1) Memory Heap : 메모리 할당이 일어나는 곳(객체, 배열, 함수 등) 2) Call Stack : 코드 실행에 따라 호출 스택이 쌓이는 곳

호출 스택(Call Stack)

자바스크립트는 기본적으로 싱글 쓰레드 기반 언어입니다. 호출 스택이 하나라는 소리죠. 따라서 한 번에 한 작업만 처리할 수 있습니다.

호출 스택은 기본적으로 우리가 프로그램 상에서 어디에 있는지를 기록하는 자료구조입니다. 만약 함수를 실행하면(실행 커서가 함수 안에 있으면), 해당 함수는 호출 스택의 가장 상단에 위치하는 거죠. 함수의 실행이 끝날 때(리턴 값을 돌려줄 때), 해당 함수를 호출 스택에서 제거합니다. 그게 스택의 역할입니다.

아래 예제 코드를 살펴볼까요.

function multiply(x, y) {
    return x * y;
}
function printSquare(x) {
    var s = multiply(x, x);
    console.log(s);
}
printSquare(5);

처음 엔진이 이 코드를 실행하는 시점에는 호출 스택이 비어있습니다. 하지만 코드가 실행되면서 호출 스택은 아래와 같이 변합니다.

Javascript Runtime Environment

JavaScript는 싱글 스레드 언어다. 한 번에 하나의 작업만 실행할 수 있다. JavaScript로 30초가 걸리는 작업을 해야한다고 가정해보자. 이 작업을 시작하면 유저는 30초 동안 ui에서 할 수 있는 일이 없다. 단지 기다려야 할 뿐이다. 이를 블로킹이라고 한다.

하지만, 웹 어플리케이션에서는 동시에 다른 무언가를 할 수있다. 예를 들면, 브라우저에서는 파일을 다운로드 받고 있으면서 다른 링크로 이동한다던지, Node.js에서는 HTTP 요청을 처리하기도 한다. V8과 같은 JavaScript 엔진은 단일 호출 스택(Call Stack)을 사용하며, 요청이 들어올 때마다 해당 요청을 순차적으로 Call Stack에 담아 처리할 뿐이다.

JavaScript 언어 자체에는 Multi Threading을 할 수 없지만, JavaScript가 동작하고 있는 ’브라우저‘(브라우저라는 프로그램)에서는 여러 스레드를 활용할 수 있다. 브라우저에서 지원하는 Web API를 사용하는 것이다. Web API는 JavaScript엔진 자체가 제공하지 않는, 브라우저에서 제공하는 API다. DOM API, setTimeout, HTTP 요청 등이 여기에 포함된다. JavaScript Runtime Environment(브라우저 or Node.js)에는 Event Loop가 있다. 이 Event Loop를 통해 여러 처리를 동시에 할 수 있는 것이다. 브라우저 환경을 그림으로 표현하면 다음과 같다.

비동기 호출을 위해 사용하는 setTimeout, fetch 같은 함수는 자바스크립트 엔진이 아니라 Web APIs 영역에 따로 정의 되어 있다. 또한 Event Loop나 Task Queue 같은 장치도 자바스크립트 엔진 외부에 구현되어 있다. 아래 사진은 Node.js 환경이다.

이 그림에서도 브라우저 환경과 비슷하다. Node.js는 비동기 IO를 지원하기 위해 libuv 라이브러리를 사용하고, libuv에서 Event Loop를 제공한다. 자바스크립트 엔진은 비동기 작업을 위해 Node.js API를 호출하고, 이때 넘겨진 콜백은 libuv의 Event Loop를 통해 스케줄되고 실행된다.

확실한 것은, 자바스크립트가 ‘단일 스레드’ 기반의 언어라는 것은, ‘자바스크립트 엔진이 단일 Call Stack을 사용한다’는 관점에서만 사실이다. 실제 자바스크립트가 실행되는 환경(브라우저, Node.js)에서는 주로 여러 개의 스레드가 사용되고, 이런 구동 환경이 Call Stack을 사용하는 자바스크립트 엔진과 상호 연동하기 위해 사용하는 장치가 ‘이벤트 루프’인 것이다. 즉, 브라우저, Node.js환경은 자바스크립트 엔진의 Wrapper 역할을 하고 있다.

비동기 코드(non blocking)는 코드의 실행이 완료되지 않아도 다음 코드를 실행하는 것을 말한다. Event loop이 있어 javascript 자체는 싱글스레드임에도 불구하고 비동기 코드를 다룰 수 있고 multi threads처럼 보일 수 있다.

다음 글에서 Event loop과 관련해서 코드 실행 순서에 대해 자세히 알아보자

UUID

UUID는 128 bit, 32자리의 16진수로 이루어진 아래 그림과 같은 모습의 숫자이다. (종류가 몇 가지 있긴 하다) 랜덤한 숫자로 볼 수 있고 실질적으로 유일하기 때문에 primary key로 사용한다. 실질적으로 유일하다는 말은 매우 큰 수를 랜덤하게 발생시키기 때문에 중복할 확률이 극히 낮다는 뜻이다. (2^128)

Pros

• Globally unique.
• Stateless, it can be generated on the fly.
• Secure since malicious user can't guess the ID.
• Version 1 UUID stores timestamp info, could be useful sometimes.

Cons

Not readable. For database like MySQL, Oracle, which uses clustered primary key, version 4 randomly generated UUID will hurt insertion performance if used as the primary key. This is because it requires reordering the rows in order to place the newly inserted row at the right position inside the clustered index. On the other hand, PostgreSQL uses heap instead of clustered primary key, thus using UUID as the PK won't impact PostgreSQL's insertion performance.

Auto Increment Integer/Sequence

Pros

• Readable. This is especially valuable if we would expose it externally. Thinking of issue id, obviously, issue-123 is much more readable than issue-b1e92c3b-a44a-4856-9fe3-925444ac4c23.

Cons

• It can't be used in the distirbuted system since it's quite likely that different hosts could produce exactly the same number.
• It can't be generated on the fly. Instead, we must consult the database to figure out the next available PK.
• Some business data can be exposed, since the latest ID could represent the total number of inventory. Attackers can also scan the integer range to -- explore leakage (though it shouldn't happen if ACL is implemented correctly).

동적 타입 변수의 타입이 런타임 시 정해진다. 대표적으로 Python이다. 코딩하는 입장에서 type에 크게 신경쓰지 않아도 돌아가는 코드를 만들 수 있다. python이 간단한 script를 짜는 데에 생산성이 좋은 이유 중 하나다. 하지만 복잡성이 증가하면 type 관련 에러가 발생할 수 밖에 없다. 이를 막기 위해서는 validation code들이 늘어나는 등의 어려움이 생겨 오히려 생산성이 떨어질 수 있다.

정적 타입 변수의 타입이 컴파일 시점에 정해진다. type 관련 오류가 있을 때 compile이 되지 않는다. 덕분에 잠재적인 에러를 미리 잡아낼 수 있기에 안정성이 뛰어나다. Type을 엄격하게 code level에서 다루기 때문에 간단한 script에는 귀찮게 느껴질 수 있다. 하지만 복잡한 프로그램을 만들 때는 안정성과 생산성이 향상된다.

정적타입 언어 리스트: Ada, C, C++, C#, JADE, Java, Fortran, Haskell, ML, Pascal, Scala 동적타입 언어 리스트: Groovy, JavaScript, Lisp, Lua, Objective-C, PHP, Prolog, Python, Ruby, Smalltalk, Tcl

정도만 알고는 application level에서 index를 제대로 활용하기 힘들다. 무엇이든 그렇지만 index를 잘 활용하기 위해서는 index의 원리를 이해해야 한다. 기본적인 원리를 정리해보자.

index scan vs full scan

index가 아닌 column으로 select 쿼리를 날리면 무지성으로 Disk에 있는 해당 테이블을 뒤진다. 이것을 full scan이라고 한다. 반면 index가 설정된 column이라면 Tree로 된 index table을 통해 데이터가 있는 위치를 알아내서 찾아가게 된다. Tree로 B tree 계열의 자료구조가 많이 사용되지만 DB마다 혹은 데이터의 특성마다 다른 자료구조를 사용한다. 이에 대한 자세한 것은 다음에 다뤄보도록 하자. 아무튼 Tree 구조를 통해 위치를 알아내기 때문에 일반적으로 더 빠르다.

(참고) 아래 그림처럼 항상 더 빠른 것은 아니다. 데이터가 많지 않다면 Tree 자료구조에서 얻는 시간적인 효율보다 (tree를 가져오고 => tree를 뒤지고) 이 overhead가 커질 수도 있다.

Clustered index vs Non clustered index

index는 clustered index와 non clustered index로 나누어진다.

clustered index는 한 테이블 당 하나만 존재할 수 있다. 대부분의 db에서 default로 primary key로 설정되어 있다. 물론 use case에 따라 변경할 수 있다. table마다 하나밖에 존재할 수 없는 이유는 cluster key 기준으로 실제로(물리적으로) 데이터가 정렬되어 있기 때문이다.

반면 non clustered index는 한 테이블에도 여러 개를 지정할 수 있다. 하지만 clustered index보다는 성능 향상을 더 끌어내지 못한다.

왜 그런지 이해해보자

Clustered index

• Clustered index column을 key로 하는 table(tree)이 있다. 가장 끝에 있는 Leaf node는 실제 데이터가 있는 page이다. 이 데이터 page에는 data가 index column 기준으로 정렬되어 있다. 이것이 non clustered index와의 가장 큰 차이점이다.

Non clustered index

• Clustered index와는 다르게 각 데이터는 clustered index key를 갖고 있다. non clustered index table을 통해 clustered index를 찾는 것이다. clustered index를 통해 cluster index를 찾고 clustered index table을 뒤져 데이터를 찾는 것이다. 어쨌든 clustered index를 통해 찾기 떄문에 당연히 clustered index보다 느리다.
• 그림을 보면 included columns라는 것도 있는데 이는 설정하기에 따라 clustered index table을 뒤져 찾는 과정을 생략하기 위해 특정 컬럼들을 non clustered table에 함께 저장하는 것이다.

참고

https://matthewmcgiffen.com/2017/06/12/what-is-an-index/ https://logicalread.com/dont-drink-kool-aid/

JWT(Json Web Token)란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다.

flow

구성

JWT는 세 개의 점으로 구분된 문자열로 표현되며, 세 가지 부분으로 구성됩니다: Header (헤더), Payload (페이로드), Signature (서명). 각 부분은 Base64 인코딩되어 표현되며, 각 부분은 점(.)으로 구분됩니다.

Header 에는 JWT 에서 사용할 타입과 해시 알고리즘의 종류가 담겨있으며, Payload 는 서버에서 첨부한 사용자 권한 정보와 데이터가 담겨있다. 마지막으로 Signature는 Header, Payload에 서버의 secret key와 Header에 명시된 해시함수를 서명해서 만든다.

주의할 점

payload는 인코딩 되어 있을 뿐 암호화가 되어있지 않다. 그러므로 민감한 정보는 넣으면 안된다.

Flow

• 사용자가 ID, PW를 입력하여 서버에 로그인 인증을 요청한다.
• 서버에서 클라이언트로부터 인증 요청을 받으면, Header, PayLoad를 만들고 위에서 설명한 방식으로Signature를 생성한다.
• Hedaer, PayLoad, Signature를 각각 Base64로 인코딩하여 JWT를 생성하고 이를 쿠키에 담아 클라이언트에게 발급한다.
• 클라이언트는 서버로부터 받은 JWT를 로컬 스토리지에 저장한다. (쿠키나 다른 곳에 저장할 수도 있음) API를 서버에 요청할때 Authorization header에 Access Token을 담아서 보낸다.
• 서버가 할 일은 클라이언트가 Header에 담아서 보낸 JWT의 Header와 Payload를 만들었던 방식 그대로 사용해서 Signature를 만들어본다. Header에 담겨온 Signature와 비교해서 일치 여부를 본다.
• 클라이언트가 서버에 요청을 했는데, 만일 액세스 토큰의 시간이 만료되면 클라이언트는 리프래시 토큰을 이용해서 서버로부터 새로운 엑세스 토큰을 발급 받는다.

토큰이 인증 신뢰성을 갖는 이유

유저 JWT: A(Header) + B(Payload) + C(Signature) 일 때 (만일 임의의 유저가 B를 수정했다고 하면 B'로 표시한다.)

1. 다른 유저가 B를 임의로 수정 -> 유저 JWT: A + B' + C 수정한 토큰을 서버에 요청을 보내면 서버는 유효성 검사 시행

2. 유저 JWT: A + B' + C 서버에서 검증 후 생성한 JWT: A + B' + C' => (signature) 불일치

3. 대조 결과가 일치하지 않아 유저의 정보가 임의로 조작되었음을 알 수 있다.

정리하자면, 서버는 토큰 안에 들어있는 정보가 무엇인지 아는게 중요한 것이 아니라 해당 토큰이 유효한 토큰인지 확인하는 것이 중요하기 때문에, 클라이언트로부터 받은 JWT의 헤더, 페이로드를 서버의 key값을 이용해 시그니처를 다시 만들고 이를 비교하며 일치했을 경우 인증을 통과시킨다.

Expire time

expire time이 커지면 login timeout이 발생할 가능성이 낮아진다. 하지만 공격자가 탈취했을 때 무언가(?)를 할 시간이 많아진다. expire time이 작아지면 보안에는 좋지만 login timeout이 빈번하게 일어날 것이다.

Refresh Token

처음에 JWT를 접했을 때 Refresh Token이 왜 있는건지 이해가 가지 않았다. Access token의 expire time을 짧게 가져가기 위해서라고 했다. 하지만 로그인했을 때 어차피 Access token과 Refresh token을 동시에 발급해주는거라면 access token과 마찬가지로 refresh token도 탈취당하는 것 아닌가?라는 생각이 있었다.

token이 위험한 경우는 위에서 말한대로 token이 공격자에게 탈취당했을 때이다. 그 탈취는 주로 web상에서 공격자가 intercept해서 발생하다. 그리고 expire time이 짧은 access token이 주로 request에 쓰이며 돌아다니게 하고 expire time이 긴 refresh token은 client의 local storage에 꽁꽁 숨겨두려고 하는 의도이다. expire time 자체를 짧게 가져가는 것도 하나의 방법이 되겠지만 위에서 말한대로 login timeout과 trade off가 있다.

인증

인증이란 클라이언트가 서비스에 접근할 수 있는 권한이 있는 사용자인지 인증하는 과정이다. 보통 서버가 클라이언트를 인증하는 방식은 대표적으로 쿠키, 세션, 토큰 3가지 방식이 있다. 세 가지에 대해 간단하게 살펴보고 다음 글에서 가장 많이 사용되는 JWT에 대해 살펴보자. (난 이걸 졸맛탱이라고 부른다)

Cookie

쿠키는 Key-Value 형식의 문자열 덩어리이다.

클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일이다. 각 사용자마다의 브라우저에 정보를 저장하니 고유 정보 식별이 가능한 것이다.

과정

• 브라우저(클라이언트)가 서버에 요청(접속)을 보낸다.
• 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다.
• 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.
• 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별하거나 정보를 바탕으로 추천 광고를 띄우거나 한다.

단점

• 가장 큰 단점은 보안에 취약하다는 점이다. 요청 시 쿠키의 값을 그대로 보내기 때문에 유출 및 조작 당할 위험이 존재한다.
• 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없다.
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능하다.
• 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다.

Session

이러한 쿠키의 보안적인 이슈 때문에, 세션은 비밀번호 등 클라이언트의 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리한다. 서버의 메모리에 저장하기도 하고, 서버의 로컬 파일이나 데이터베이스에 저장하기도 한다. (Stateful)

핵심 골자는 민감한 정보는 클라이언트에 보내지말고 서버에서 모두 관리한다는 점이다.

과정

• 유저가 웹사이트에서 로그인하면 세션이 서버 메모리(혹은 데이터베이스) 상에 저장된다. 이때, 세션을 식별하기 위한 Session Id를 기준으로 정보를 저장한다.
• 서버에서 브라우저에 쿠키에다가 Session Id를 저장한다.
• 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송한다.
• 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id를 비교하여 인증을 수행한다.

단점

• 쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 않는다. 그러나 해커가 세션 ID 자체를 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재한다. (이는 서버에서 IP특정을 통해 해결 할 수 있긴 하다)
• 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.

Token

Stateless한 방식이다. 토큰 기반 인증 시스템은 클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여한다. 이 토큰은 유일하며 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 심어서 보낸다. 그러면 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다.

기존의 세션기반 인증은 서버가 파일이나 데이터베이스에 세션정보를 가지고 있어야 하고 이를 조회하는 과정이 필요하기 때문에 많은 오버헤드가 발생한다. 하지만 토큰은 세션과는 달리 서버가 아닌 클라이언트에 저장되기 때문에 메모리나 스토리지 등을 통해 세션을 관리했던 서버의 부담을 덜 수 있다. 토큰 자체에 데이터가 들어있기 때문에 클라이언트에서 받아 위조되었는지 판별만 하면 되기 떄문이다.

토큰은 앱과 서버가 통신 및 인증할때 가장 많이 사용된다. 왜냐하면 웹에는 쿠키와 세션이 있지만 앱에서는 없기 때문이다.

과정

• 사용자가 아이디와 비밀번호로 로그인을 한다.
• 서버 측에서 사용자(클라이언트)에게 유일한 토큰을 발급한다.
• 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해 두고, 서버에 요청을 할 때마다 해당 토큰을 서HTTP 요청 헤더에 포함시켜 전달한다.
• 서버는 전달받은 토큰을 검증하고 요청에 응답한다. 토큰에는 요청한 사람의 정보가 담겨있기에 서버는 DB를 조회하지 않고 누가 요청하는지 알 수 있다.

단점

• 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해질수 있다.
• Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
• 토큰을 탈취당하면 대처하기 어렵다. (따라서 사용 기간 제한을 설정하는 식으로 극복한다)

참고 : https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

Alt + Enter : Jetbrain의 제안보기

⌘ + B : 심볼의 선언으로 이동. 혹은 이 심볼이 사용된 곳들을 보여준다.

shift 연속 두번 : 파일 찾기, 클레스 찾기, symbol 찾기 등 ⌘ + Shift + F : 코드 찾기

F6 : 코드, class 등 다른 곳으로 옮기기

Shift + F6 : Rename 한번에 하기

⌘ + Option + M : method로 추출하기 ⌘ + Option + N : 인라인 하기

⌘ + Delete : 한줄 지우기 ⌘ + d : 문장 복사해서 바로 아래에 duplicate

⌘ + <- Or -> : 커서 라인 젤 끝으로 이동

⌘ + E : 최근 연 파일 목록

⌘ + shift [ or ] : 탭 이동 ⌘ + E : 탭 닫기

다중커서 Option+Option 누른채로 위아래