image list

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort
  • k get nodes
  • k get pods --all-namespaces
  • pod이 어느 노드인지 : kubectl get pods -o wide
  • replicaset : k get rs

컨테이너 이미지 변경

kubectl patch rs new-replica-set --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"busybox"}]'
  • rs yaml 추출 : k get rs new-replica-set -o yaml
  • 리소스 강제 교체 : k replace --force -f sample.yaml
  • rs replicas 수 변경 : k scale --replicas=2 rs/new-replica-set
  • namespace list : kubectl get ns
  • k apply -f sample.yaml --namespace=finance
  • 도메인 명명 : 서비스. namespace. svc.cluster.local
  • imperative pod deploy : k run nginx-pod --image=nginx:alpine
  • 리소스 수정 : kubectl edit deployment frontend

--label 옵션 지원 종료

k run redis --image=redis:alpine
k label pod redis tier=db

서비스 명령형 생성

k expose pod redis --port=6379 --name=redis-service --type="ClusterIP"

  • 모든 라벨 : k get pod --show-labels
  • 특정 라벨 모든 리소스 : k get all -l env=prod
  • taint 걸기 : k taint node node01 spray=mortein:NoSchedule
    • 순서 : key=value:효과

yaml 파일 생성 (기본 토대)

  • k run nginx --image=nginx --dry-run=client -o yaml > nginx.yaml
  • dry-run 옵션을 통해 실제 리소스를 생성하지 않고 yaml만 생성

Node Affinity

required

  • kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml --dry-run=client -o yaml > require.yaml

prefered

  • kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml --dry-run=client -o yaml > prefer.yaml
  • daemonset describe : k describe daemonset kube-flannel-ds -n kube-system
  • static pod path 등 config 확인
    1. ps -aux | grep kubelet
    2. 결과 중 --config=/var/lib/kubelet/config.yaml 확인
    3. vi /var/lib/kubelet/config.yaml 중 static pod path 확인

multiple scheduler

  • leader-elect
  • 여러 개 secret 생성 : k create secret generic db-secret --from-literal=DB_Host=sql01 --from-literal=DB_User=root --from-literal=DB_Password=password123

유지보수 (drain)

  • k drain node01 --ignore-daemonsets
  • cordon과 차이는 SchedulingDisable된 노드의 Pod를 삭제하고 재생성
    • 이러한 특징으로 사용 가능한 node가 없을 때 drain 대신 cordon을 써야함
  • 오류 뜨면 --force 옵션 추가
  • 다시 스케줄링 추가 : k uncordon node01

Control Plane node 업그레이드

Kubeadm 업그레이드
  • k drain controlplane --ignoe-daemonsets으로 master node SchedulingDisable 한 이후
  • apt-get update && apt-get install -y --allow-change-held-packages kubeadm=1.20.0-00
  • kubeadm upgrade plan
  • kubeadm upgrade apply v1.20.0
    kubelet 업그레이드
  • apt install kubelet=1.20.0-00
  • kubelet 재시작
    • sudo systemctl daemon-reload
    • sudo systemctl restart kubelet

worker node 업그레이드

  • ssh node01
  • apt-get update && apt-get install -y --allow-change-held-packages kubeadm=1.20.0-00
  • kubeadm upgrade node
  • apt install kubelet=1.20.0-00
  • sudo systemctl restart kubelet
  • exit

Etcd snapshot

  • export ETCDCTL_API=3
  • ps -aux | grep -i etcd
etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \                                           
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /opt/snapshot-pre-boot.db

Etcd backup restore

  1. etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \

--cert=/etc/kubernetes/pki/etcd/server.crt
--key=/etc/kubernetes/pki/etcd/server.key
--data-dir=/var/lib/etcd_backup --initial-advertise-peer-urls=https://10.5.159.9:2380 --initial-cluster=controlplane=https://10.5.159.9:2380 --name=controlplane snapshot restore /opt/snapshot-pre-boot.db

  1. /etc/kubernetes/manifests의 hostPath 수정

name of CA

  • openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text

cluster 변경

  • k config use-context research --kubeconfig=/root/my-kube-config

Assign 된 Role

  • k describe rolebinding kube-proxy -n kube-system

Role yaml

  • k create role developer --verb="*" --dry-run=client --resource=pod -o yaml > drole.yaml

RoleBinding yaml

  • k create rolebinding dev-user-binding --role=developer --user=dev-user --dry-run=client -o yaml > rb2.yaml

PV yaml

  • kubectl create -f https://k8s.io/examples/pods/storage/pv-volume.yaml --dry-run=client -o yaml > pv.yaml

'Docker & k8s' 카테고리의 다른 글

[K8S] 4. Cluster Networking  (0) 2022.02.03
[K8S] 3. Kubernetes Network Commands  (0) 2022.02.03
[K8S] 1. Kubernetes Core Component  (0) 2022.02.03
도커란? (Docker)  (0) 2020.12.17
쿠버네티스(k8s)는 무엇인가  (0) 2020.12.17

Cluster Architecture

  • worker node : 컨테이너를 로드할 수 있는 노드
    • pod(컨테이너의 집합-network 스택을 공유하여 localhost를 통해 서로에 도달 가능)를 호스팅
  • control plane : 노드에 대한 정보를 저장하고, 노드 내 컨테이너의 위치를 모니터링 하고 추적
    • 워크 노드와 클러스터 내 pod를 관리
    • 여러 인스턴스에 분산되어 실행되고, 클러스터는 여러 노드를 실행 -> 고가용성 및 내결함성

Control Plane Component

클러스터에 대해 스케줄링 등을 수행 & 클러스터 이벤트를 감지하고 반응

  1. kube-apiserver
    • 쿠버네티스 API를 제공하는 API 서버
  2. etcd
    • key-value 형태로 컨테이너가 어떤 노드에 위치하는지, 로드된 시간 등 모든 클러스터 데이터를 저장하는 DB
  3. kube-scheduler
    • Kubelet(클러스터의 각 노드에서 실행되는 agent)가 pod를 실행할수 있도록 pod가 노드에 적합한지 확인하는 것
    • 새로 생성된 pod를 실행할 노드를 선택하는 컴포넌트
    • 즉, scheduler는 pod가 어디로 갈 지만 결정하고, 실제 pod를 노드에 위치하는 건 kubelet의 역할

  1. kube-controller-manager
    • 스케줄러를 참고하여 정확한 수의 pod이 실행되게 하며, pod에 문제가 생겼을 시 감지하고 대응
    • 노드 컨트롤러 : 노드가 다운되었을 때 통지와 대응 (상태 감시 및 대응 조치)
    • replication 컨트롤러 : 알맞은 수의 pod를 유지하기 위함
    • endpoint 컨트롤러 : 서비스와 pod를 endpoint로 연결
    • service account & token 컨트롤러 : namespace(클러스터 안에서 논리적으로 분리 - ex:dev,stage,prod)에 대한 계정과 API 접근 토큰을 생성
  2. cloud-controller-manager
    • 클러스터를 CSP의 API에 연결하며, CSP, 클러스터와만 각각 상호작용하는 컴포넌트를 구분함
    • 노드 컨트롤러 : 노드가 응답을 멈춘 후, 클라우드에서 삭제되었는지 확인 요청
    • 라우트 컨트롤러 : 클라우드 인프라에 경로 구성
    • 서비스 컨트롤러 : CSP 로드밸런서를 생성, 업데이터, 삭제 요청

Node Component

  1. kubelet
    • 클러스터의 각 노드에서 실행되는 agent
    • kube-apiserver를 경유하여 node에 컨테이너를 배포하거나 파괴
  2. kube-proxy
    • worker node의 애플리케이션끼리 서로 통신이 가능하도록 함(ex:db<->server)
    • 노드의 네트워트 규칙을 관리
  3. container runtime
    • Docker, ContainerD, Rocket 등 런타임 엔진

'Docker & k8s' 카테고리의 다른 글

[K8S] 3. Kubernetes Network Commands  (0) 2022.02.03
[K8S] 2. Kubernetes Commands  (0) 2022.02.03
도커란? (Docker)  (0) 2020.12.17
쿠버네티스(k8s)는 무엇인가  (0) 2020.12.17
도커 컨테이너 한꺼번에 종료  (0) 2020.11.28

AWS EFS

  • 관리형 파일 스토리지
  • 온프레미스의 NFS, NAS와 동일한 서비스
  • 수천대의 EC2 인스턴스간 파일 시스템 공유 가능. 병렬 접근이 가능하도록 설계되어 IOPS가 파일시스템이 커짐에 따라 탄력적으로 설정됨
    • 따라서 두 개 이상의 EC2로부터 하나의 공유된 스토리지 공간이 필요할 때 EFS 채택

EFS Architecture

  • EFS 생성 시 VPC 내 가용영역의 서브넷에 Mount Target 생성
  • Linux만 지원하며 Windows는 지원하지 않음 (필요하다면 Linux와 SAMBA 연동 필요)
  • Direct Connect와 VPN 연결을 통해 온프레미스 NFS, NAS와 연결이 용이하다.

Vs EBS

  • EFS는 EBS와 다르게 Multi-AZ 가능
  • 단일 EBS 볼륨의 최대 크기는 최대 16TB까지 될 수 있지만 EFS 볼륨 크기는 사실상 무제한이다. EFS에서 파일의 최대 크기는 47.9TB이다. EBS는 파일 크기 제한 없음.
  • EBS, EFS 모두 높은 내구성을 제공하지만, 확장성에서 차이가 있음. EFS 볼륨은 워크로드 수요의 급격한 증가를 수용하기 위해 빠르며 자동으로 수행되는 Scale-up/down이 가능함.
  • EFS는 S3와 비슷하게 lifecycle 관리를 통해 스토리지 클래스를 전환하여 비용을 절감할 수 있음
  • EBS는 디스크 지연 시간을 최소로 할 수 있음(프로비저닝된 IOPS). EFS는 충분히 빠르지만 EBS만큼의 낮은 디스크 지연시간은 확보할 수 없음. 반면에 분산 파일 저장 시스템이기 때문에, EFS는 EBS에 비해 초당 처리량은 높을 수 있다.
  • EFS 볼륨은 전사적 파일 서버, 백업 시스템, 빅 데이터 클러스터, 대규모 병렬 처리(MPP) 시스템, CDN 및 기타 대규모 사용 사례에 적합
  • EBS 볼륨은 관계형 및 NoSQL 데이터베이스, ERP 시스템, 메일 서버, 쉐어포인트, 웹 서버, 디렉터리 서버, DNS 서버 또는 미들웨어에 적합 (큰 클러스터에서 실행되지 않는 워크로드로 마운트되는 볼륨이 필요 없음)

EFS Backup 옵션

  1. DataSync
    • DataSync는 온프레미스 스토리지와 Amazon EFS 파일 시스템 간의 상시 연결을 유지하여 둘 사이에서 데이터를 쉽게 이동하도록 도움.
    • DataSync는 대량의 데이터를 정기적으로 가져오기 및 내보내기, 일회성 데이터 마이그레이션 또는 데이터 복제 및 복구에 사용할 수 있음.
    • 리전간 전송에도 AWS DataSync를 사용할 수 있음
  2. AWS Tranfer Family
    • SFTP, FTPS, FTP를 지원하는 완전관리형 파일 전송 서비스.
    • Amazon EFS 내부 및 외부 파일 전송을 가능하게 함.
    • AWS Transfer Family 엔드포인트는 EFS 파일 시스템과 동일한 리전에 있어야 함 (리전 간 전송 불가)
  3. AWS Backup
    • Amazon EFS의 백업 정책 및 예약을 자동화하고 추적함
  4. EFS-to-EFS backup
    • EFS 파일의 증분 백업을 자동으로 생성

Reference

'AWS' 카테고리의 다른 글

AWS 블로그 이전합니다.  (0) 2023.05.08
Amazon MemoryDB for Redis  (0) 2022.06.13
DynamoDB 특징에 대해 알아보자  (0) 2021.08.23
Amazon Aurora 알아보자  (0) 2021.08.23
AWS Pinpoint  (0) 2021.06.17

DynamoDB

특징

  • 자동 이중화 : 서버 장애 또는 가용 영역 중단시 내결함성을 제공하기 위해 AWS 리전의 3개 시설에 자동으로 데이터 복제
  • SSD기반 NoSQL 서비스
  • 테이블 데이터는 json 형식으로 저장됨
  • 완전 관리형 NoSQL 데이터베이스 서비스
    • 클러스터링, 백업정책, 성능 상향, 다중리전 지원
  • 트랜잭션, JOIN과 같은 작업이 필요하다면 DBMS 사용이 더 적합 (DDB의 단점)
  • 규모가 커지더라도 PUT/GET이 항상 10ms 이내, 무제한으로 Scaling 가능.
  • Table + Item + Attribute
    • Table : item들의 집합. 리전당 생성할 수 있는 최대 개수 256개
      • 기본키 지정 필수
        • 단순 기본키 : Partition Key (Hash Key) (=, != 연산만 가능)
        • 복합 기본키 : Sort Key (Range Key) (범위연산 및 ~ 연산 가능)
  • 테이블 내 항목의 데이터 크기는 400KB를 초과할 수 없다.

인덱스

  • 단순 보조 인덱스 기본키 : Hash Key (기본키 이용하여 자동 생성)
  • 복합 보조 인덱스 기본키 : Hash Key + Range Key
  • Global 보조 인덱스(GSI) : 파티션키와 정렬키가 모두 다름 (모든 파티션에 접근 가능)
    • 생성, 삭제가 자유롭고 쿼리 용량에 제한 없음
  • Local 보조 인덱스 (LSI) : 파티션키는 같지만 정렬키가 다름 (특정 파티션에만 접근 가능)
    • 테이블 생성 시에만 생성 가능. 삭제 불가.
    • Hot Key 이슈를 막기 위하여 사용됨
    • 10GB 제한

Scaling

  • 전체 데이터를 골고루 분산시키기 위해 Partition Key 사용 (Scaling의 핵심이 Partition Key)
    • DynamoDB는 DB 트래픽이 늘어나면 자동으로 instance를 늘리는데, 그 기준은 파티션키를 hash 값.
    • 한 파티션 키에 해당하는 데이터는 10GB가 넘을 수 없다.
  • 로드가 적은 DDB의 테이블 사용시 한 서버로 처리
  • 로드가 많아지면 파티션 키의 hash 값으로 두 개의 서버로 쪼개지고, 그래도 부하가 크다면, 계속 쪼개지는 과정 반복.

Partition Key

  • Key-Value 저장소 용도일 때는 파티션키를 고려하지 않아도 크게 문제 없음.
  • Query 를 사용할 때 Partition Key + Sort Key 조합으로 Key를 설정해야 함
    • DDB의 Query 기능은 Partition Key에 속한 Sort Key에 조건을 걸어 데이터 조회하기 때문
    • Query를 사용하고 싶어도, 특정 Partition Key에만 데이터가 몰려서는 안되기 때문에, 파티션키 정하는 것이 어려운 것임 (Hot Key 이슈)

추가 기능

  1. DAX (DynamoDB Accelerator)
    • DDB와 동일한 인터페이스의 in-memory cache 서버.
    • 읽기 볼륨이 많거나 1ms 미만의 읽기 지연시간이 필요할 때 필요
  2. Stream + Lambda
    • DDB에 POST/PUT/DELETE 되는 데이터가 생길 때마다 Lambda를 실행할 수 있음
  3. Global Table
    • AWS가 지원하는 리전에 자동으로 동기화되는 데이터를 구성할 수 있음
    • 전세게에 DB 분산

백업

  1. 온디맨드 백업
    • 온디맨드 백업 생성 시 전체 테이블 데이터가 백업됨
  2. 특점 시점으로 복구(PITR)
    • 활성화 시 테이블 삭제하면 백업이 자동으로 생성되며 35일 동안 유지 (무료)

요금 계산

  • 모든 아이템을 KB 단위로 환산한 뒤에 소수점 이하를 올림하고 용량단위의 배수로 맞춰서 다시 올림 (1Byte만 사용해도 용량단위로 올림해서 계산)
  • 용량 단위
    • WCUs : 1KB
    • RCUs : 4KB, Strictly Consistent Read (Real Time)
    • RCus : 8KB, Eventually Consistent Read (Near Time)
  • 온디맨드 프로비저닝에 비해, 읽기 및 쓰기용량을 미리 예약하면 비용을 절감할 수 있다.

Reference

'AWS' 카테고리의 다른 글

Amazon MemoryDB for Redis  (0) 2022.06.13
AWS EFS  (0) 2021.09.08
Amazon Aurora 알아보자  (0) 2021.08.23
AWS Pinpoint  (0) 2021.06.17
AWS SAM (Serverless Application Model)  (0) 2021.04.29

Amazon Aurora

Amazon Aurora

  • MySQL PostgreSQL 오픈소스와 호환
    • MySQL의 5배, PostgreSQL의 3배 쓰루풋
    • 고가용성 보장 (단일 데이터 베이스가 여러 리전에 걸쳐있음)
      • RDS MySQL은 Multi-AZ 활성화 시 Active-Standby 모델
      • RDS Aurora는 Active-Active 모델로 단일 장애점(SPOF) 제거
    • 지역 전체 중단에도 RPO 1초, RTO 1분 미만
  • 1/10 비용으로 상용 데이터베이스 수준의 성능 & 가용성 제공
    • 하지만 RDS MySQL에 비해서는 20%~30% 정도 비쌈
  • Aurora Serverless
    Aurora Serverless
    • 데이터베이스를 shutdown 시켜놓았을 때 EC2에 대한 과금 X
    • 자동으로 용량 조절
    • 초당 지불 (최소 1분)
    • 자주 사용하지 않거나, 주기적인 워크로드에 적합
    • HTTP 기반 API 제공

Aurora 장애조치

자동으로 장애조치를 하며, 관리자의 개입없이도 장애조치가 작용된다.

  • Aurora는 DB 인스턴스의 CNAME이 정상적인 복제본을 가리키도록 변경하며, 해당 복제본은 승격되어 새로운 기본 복제본으로 지정된다. 이는 30초 이내에 수행됨.
  • 현재 AZ를 사용할 수 없는 경우, Aurora는 다른 AZ에서 DB 인스턴스를 자동으로 다시 생성함.
  • 복제본이 없는 경우, 원래 인스턴스와 동일한 AZ에 새 DB 인스턴스를 생성 시도함.
  • 여러 리전에 걸친 장애 복구는 수동 프로세스이며, 보조 리전을 승격시키는 조치가 필요함

Aurora Multi-Masters

Aurora Multi-masters

기존 aurora는 클러스터 내 읽기/쓰기가 가능한 마스터 노드는 1개만 구성하였고, 최대 15개의 읽기 복제본만 구성(읽기 성능만 확장)할 수 있었다.

Multi-Masters의 출시로 이제는 읽기/쓰기가 모두 가능한 마스터 노드를 2개 이상 구성할 수 있게 되어, 읽기/쓰기 성능 모두 확장 가능하게 되었다. (2019년에 정식버전으로 병합)

  • 마스터 노드 1개가 장애가 발생하더라도 다른 마스터노드가 쓰기 작업을 할 수 있게 되었다.
  • 샤딩 없이 쓰기 성능을 확장 가능
    • 샤딩 : 최대 성능의 데이터베이스 타입을 사용 중인데 성능이 부족하게 된다면, 같은 스키마를 가진 데이터를 다수의 db에 분산하여 저장하는 방법

따라서 고가용성과 성능을 보장할 수 있게됨

'AWS' 카테고리의 다른 글

AWS EFS  (0) 2021.09.08
DynamoDB 특징에 대해 알아보자  (0) 2021.08.23
AWS Pinpoint  (0) 2021.06.17
AWS SAM (Serverless Application Model)  (0) 2021.04.29
CloudEndure (서버 마이그레이션 툴), SMS  (0) 2021.03.29

Kafka & Confluent

kafka : 데이터를 전송해주는 메시징 플랫폼. 동시에 데이터를 실시간으로 처리하는 플랫폼

  • 분산 트랜잭션 로그로 구성된 확장 가능한 Pub/Sub 메시지 큐에 저장 기능이 포함된 것.
  • pub/sub 데이터 모델
    kafka
    • producer : kafka에 데이터를 입력하는 클라이언트
      • producer는 broker 중 하나의 topic만을 대상으로 데이터 입력
      • topic의 파티션에 메시지를 송신할 때 프로듀서의 메모리를 사용하여 버퍼처럼 모아서 송신함
      • 동일한 파티션에 보내기 위해서는? 메시지의 key-value 구조를 활용함. 동일한 key값을 가진 메시지를 동일한 id를 가진 파티션에 송신한다. 메시지 key를 지정하지 않는다면 메시지 송신은 Round-Robin 방식으로 수행됨
    • broker cluster : topic이라고 불리는 데이터 관리 유닛을 임의 개수만큼 호스팅하는 클러스터
      • partition : 브로커 상의 데이터를 읽고 쓰는 단위
      • 서버 인스턴스 하나당 하나의 데몬 프로세스로 동작. 여러 대의 클러스터로 구성함으로써 throughput 향상 및 scaling이 가능해짐
      • 브로커가 받은 데이터는 모두 디스크로 내보내져야 함(영속화) -> 디스크의 총 용량에 따라 데이터 보존 기간이 정해짐
    • consumer : kafka에서 데이터를 가져오는 클라이언트
      • consumer group : 컨슈머 하나는 하나의 consumer group에 속함.
        • 수신한 메시지는 consumer group 내의 하나의 consumer가 수신받으며, 이후 consumer 사이에서 분산되어 전달됨.
        • 메시지 매핑은 partition과 consumer group을 매핑하여 가능함.
        • 메시지 분산 수신을 위해서는 (파티션 수 > 컨슈머 그룹 내 컨슈머)가 되어야 하며, 만족되지 않을 경우 파티션이 할당되지 않은 consumer가 발생할 수 있음
          message mapping
      • 데이터를 가져올 topic을 지정한 후 해당 topic에서 데이터를 가져옴
      • 하나의 topic에 여러 개의 consumer가 각각 다른 목적으로 존재
      • topic에 입력된 데이터는 여러 consumer가 서로 다른 처리를 위해 여러 번 가져올 수 있음
    • message : kafka에서 다루는 데이터의 최소 단위. key-value를 가지며 메시지 전송시 파티셔닝에 이용됨
    • topic : 메시지를 종류별로 관리하는 스토리지. broker에 배치되어 관리된다. 단일 카프카 클러스터에서 여러 종류의 메시지를 중계함

kafka 요청 처리 방식

  • kafka가 요청을 처리할 때 두 개의 스레드 레이어를 사용
    • 네트워크 스레드 : 클라이언트와의 이벤트 기반 비동기 I/O 처리를 수행
    • 요청 핸들러 스레드 : 네트워크 스레드가 가져온 요청을 내용을 처리해서 필요한 응답 객체를 네트워크 스레드에 반환

디스크 영속화

  • 카프카는 디스크 영속화를 하면서도 높은 처리량을 제공
  • 데이터를 받아들이면서 장기 보존을 목적으로 영속화
  • 메시지를 잃지 않는 전달 보증으로 ACK와 Offset Commit 개념이 도입됨
    • ACK : 브로커가 메시지를 수신하였을 때 프로듀서에게 수신 완료했다는 응답
    • Offset Commit : 컨슈머가 브로커로부터 메시지를 받을 때 컨슈머가 어디까지 받았는지 관리
  • 카프카만 가지고는 데이터 유통만 가능.
  • 각종 애플리케이션을 붙이기 위한 커넥터, proxy, 실시간 테이블 처리을 위한 ksqlDB 등을 지원하는 Confluent
  • Confluent는 Apache Kafka에 대한 commit의 80% 이상을 담당

Confluent

  • Confluent는 Kafka의 창시자가 설립
  • 설치형 서비스 및 SaaS 서비스 제공
  • 실시간 모니터링 툴 제공

마이크로서비스

  • 대표적인 것이 넷플릭스 아키텍처: 각 서비스간 연결이 중요하지만, 많아질수록 복잡해짐
    Neflix
  • 이벤트 기반 마이크로서비스에서 중요한 것이 event bus인데, confluent가 해당 역할을 함
    event bus msa

Reference

'BigData' 카테고리의 다른 글

엘라스틱서치 (ElasticSearch)  (0) 2021.03.08

+ Recent posts