SY Storage

[Kubernetes] Ingress

얼은펭귄 — Mon, 30 Dec 2024 16:20:24 +0900

트래픽을 클러스터로 가져오는 라우터/프록시의 역할을 한다.
라우팅하는 규칙을 가지고 있다.
Ingress를 관리하기 위해 Ingress Controller가 필요하다.

Ingress Controller는 Ingress 리소스를 관리한다.
Ingress에는 rule이 포함되어 있고 Ingress Controller는 rule을 적용한다.

ingress Controller에는 많은 종류가 있지만 nginx로 진행한다

Nginx ingress Controller

기존 클러스터를 삭제하자

kind delete cluster --name dev-cluster

그 이후 새로운 클러스터를 생성한다.

# 01-cluster.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: dev-cluster
nodes:
- role: control-plane
  kubeadmConfigPatches:
    - |
      kind: InitConfiguration
      nodeRegistration:
        kubeletExtraArgs:
          node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
- role: worker
- role: worker


# metric-server 재설치

# 클러스터 생성
kind create cluster --config 01-cluster.yaml

이후 아래에서 ingress-nginx를 설치한다.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

Ingress demo

아래 2개의 파일을 생성하자

# 01-simple-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: nginx
          image: vinsdocker/nginx-gke
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80

# 02-simple-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80

두개 다 적용해보자

kubectl apply -f .

ingress는 kubectl get all로 가져와지지 않는다.
대신 아래 명령어를 통해서 가져오자

kubectl get ing

# 결과
NAME         CLASS    HOSTS   ADDRESS     PORTS   AGE
my-ingress   <none>   *       localhost   80      49s

요청을 보내보면 요청이 각각 다른 파드로 제대로 전달되는것을 확인할 수 있다.

 ~/k8s-edu/sec10-ingress curl localhost
<H1>Hello my-deploy-5db6877498-7pbt2 </H1>
 ~/k8s-edu/sec10-ingress curl localhost
<H1>Hello my-deploy-5db6877498-k4bp7 </H1>
 ~/k8s-edu/sec10-ingress    curl localhost
<H1>Hello my-deploy-5db6877498-sc8st </H1>
 ~/k8s-edu/sec10-ingress  curl localhost
<H1>Hello my-deploy-5db6877498-sc8st </H1>
 ~/k8s-edu/sec10-ingress  curl localhost
<H1>Hello my-deploy-5db6877498-7pbt2 </H1>

Path Based Routing

이전 예시에서는 하나의 deployment에 대해서 적용했었다
이번에는 3개 각각에 ingress를 적용해보자
4개의 파일을 생성하자

# 01-product.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: product-app
spec:
  selector:
    matchLabels:
      app: product-app
  replicas: 2
  template:
    metadata:
      labels:
        app: product-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: product
          image: vinsdocker/k8s-ingress-product
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: product-service
spec:
  selector:
    app: product-app
  ports:
    - port: 80
      targetPort: 80


# 02-user.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-app
spec:
  selector:
    matchLabels:
      app: user-app
  replicas: 2
  template:
    metadata:
      labels:
        app: user-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: user
          image: vinsdocker/k8s-ingress-user
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-app
  ports:
    - port: 80
      targetPort: 80


# 03-home.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: home-app
spec:
  selector:
    matchLabels:
      app: home-app
  replicas: 1
  template:
    metadata:
      labels:
        app: home-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: home
          image: vinsdocker/k8s-ingress-home
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: home-service
spec:
  selector:
    app: home-app
  ports:
    - port: 80
      targetPort: 80


# 04-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - http:
        paths:
          - path: /product
            pathType: Prefix
            backend:
              service:
                name: product-service
                port:
                  number: 80
          - path: /user
            pathType: Prefix
            backend:
              service:
                name: user-service
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: home-service
                port:
                  number: 80

폴더 전체를 적용하자

 kubectl apply -f 03-path-based-routing

이제 브라우저를 열어서 하나하나 들어가보자

localhost
localhost/product
localhost/user

각각의 파드에 도달하는 화면을 볼 수 있다.

Dev/Qa Deploy

폴더를 만들고 qa와 dev로 구분하자
이후 아래 파일들을 만들자

#dev
#deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 2
  template:
    metadata:
      labels:
        app: my-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: nginx
          image: vinsdocker/k8s-app:v2
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80


#ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80

#qa
#deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 2
  template:
    metadata:
      labels:
        app: my-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: nginx
          image: vinsdocker/k8s-app:v1
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80


#ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80

이제 2개의 namespace를 만들자

kubectl create ns dev
kubectl create ns qa

이후 생성한 파일들을 해당 네임스페이스에 적용해보자

kubectl apply -f 04-host-based-routing/dev-workload -n dev

kubectl apply -f 04-host-based-routing/qa-workload -n qa

# 결과
deployment.apps/my-deploy created
service/my-app created
Error from server (BadRequest): error when creating "04-host-based-routing/qa-workload/02-ingress.yaml": admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: host "_" and path "/" is already defined in ingress dev/my-ingress

dev는 생성된것을확인할 수 있다. 하지만 ingress는 에러가 난 것을 확인할 수 있다.

Dev/QA routing issue

왜 이런일이 생길까? (아래는 Nginx 컨트롤러에 한한다. 다른 컨트롤러는 다를수도 있다.)
Ingress controller는 cluster 수준의 리소스이다.
또한 ingress controller는 등록된 ingress의 rule들을 가져와서 컨트롤러에서 관리하는데 이미 경로가 등록되어있기 때문이다.
그럼 해결하려면 어떻게 해야할까?

Host & Path based routing

ingress 파일들을 host 따라서 routing 하게 변경해보자

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: "dev.myapp.com"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80



# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: "qa.myapp.com"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80

이제 다시 생성해보면 제대로 생성되는 것을 확인할 수 있다

kubectl apply -f 04-host-based-routing/dev-workload -n dev
kubectl apply -f 04-host-based-routing/qa-workload -n qa

모든 환경에서 host를 건드려서 임의로 테스트 할 수 있다.
하지만 여기에서는 테스트 하지 않는다

[Kubernetes] HPA - Horizontal Pod Autoscaler

얼은펭귄 — Mon, 30 Dec 2024 10:22:58 +0900

Metric server 설치

원래는 아래 github에서 CLI 한줄이면 설치가 가능하지만
이 글에서는 kind cluster로 학습하고 있기 때문에 설치가 불가능하다
https://github.com/kubernetes-sigs/metrics-server

전체파일로 설치하자

# metrics-server.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - nodes/metrics
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-insecure-tls
        - --kubelet-preferred-address-types=InternalIP
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        image: k8s.gcr.io/metrics-server/metrics-server:v0.6.2
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: https
            scheme: HTTPS
          periodSeconds: 10
        name: metrics-server
        ports:
        - containerPort: 4443
          name: https
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readyz
            port: https
            scheme: HTTPS
          initialDelaySeconds: 20
          periodSeconds: 10
        resources:
          requests:
            cpu: 100m
            memory: 200Mi
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
      - emptyDir: {}
        name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100

아래 명령어를 적용해서 설치한 후 확인하고 진행하자

kubectl apply -f metrics-server.yaml

kubectl get pod -n kube-system

# 결과
NAME                                                READY   STATUS    RESTARTS   AGE
coredns-7c65d6cfc9-j7xg8                            1/1     Running   0          2d17h
coredns-7c65d6cfc9-l76fn                            1/1     Running   0          2d17h
etcd-dev-cluster-control-plane                      1/1     Running   0          2d17h
kindnet-kqh8m                                       1/1     Running   0          2d17h
kindnet-rvdl9                                       1/1     Running   0          2d17h
kindnet-x9xlp                                       1/1     Running   0          2d17h
kube-apiserver-dev-cluster-control-plane            1/1     Running   0          2d17h
kube-controller-manager-dev-cluster-control-plane   1/1     Running   0          2d17h
kube-proxy-dpnls                                    1/1     Running   0          2d17h
kube-proxy-nsq78                                    1/1     Running   0          2d17h
kube-proxy-xk7vs                                    1/1     Running   0          2d17h
kube-scheduler-dev-cluster-control-plane            1/1     Running   0          2d17h
metrics-server-7b445dfdc-jhnv8                      0/1     Running   0          29s # 이 부분이 1/1 이 되어야 한다.

아래 명령어를 통해 memory와 cpu 사용량을 볼 수 있다.

# 파드 사용량 (현재는 pod가 없음)
kubectl top pod

# 결과
No resources found in default namespace.

# 노드에서의 사용량
kubectl top nodes

# 결과
NAME                        CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
dev-cluster-control-plane   206m         1%     848Mi           10%
dev-cluster-worker          28m          0%     265Mi           3%
dev-cluster-worker2         32m          0%     292Mi           3%

리소스의 단위는 아래와 같다.

Memory	1M, 50M, 1G	1Mi, 50Mi, 1Gi
CPU	1 (하나의 CPU), 100m (CPU 1/10), 500m (CPU 1/5) (실제로는 이렇지 않지만 이렇게 생각해도 무방하다.)

만약 컨테이너가 memory나 cpu가 한도를 초과하면 어떻게 될까?
memory의 경우 kubelet이 컨테이너를 죽이고 재시작한다.
CPU의 경우 컨테이너가 죽지 않고 쓰로틀링이 걸린다. (성능이 저하될 수 있다.)

Pod pending

# 01-deploy-cpu-memory_usage.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx
          resources:
            requests:
              cpu: 2
              memory: 100Mi
            limits:
              cpu: 2
              memory: 100Mi

파일을 만들고 실행한 후 top으로 확인해보자
위의 파일에서 request 보다 더 많은 리소스를 사용할 수 있도록 허용하고
limit은 limit 보다 더 많은 리소스를 사용할 수는 없다.

kubectl apply -f 01-deploy-cpu-memory_usage.yaml

kubectl top pods
# 15초 간격으로 확인하기 때문에 pod를 실행하고 조금 기다린 후 다시 실행하자
error: metrics not available yet

kubectl top pods

# 결과
NAME                         CPU(cores)   MEMORY(bytes)
my-deploy-6bcdc9d88f-chvvm   0m           15Mi
my-deploy-6bcdc9d88f-hwvw8   0m           15Mi
my-deploy-6bcdc9d88f-xsdh4   0m           15Mi

아래 파일처럼 CPU 수를 늘리고 replicaSet도 늘려서 적용해보자
이 숫자는 worker CPU에 따라서 변경이 가능하다
아래 예시는 CPU가 부족할때를 보기 위함이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 5
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx
          resources:
            requests:
              cpu: 10
              memory: 100Mi
            limits:
              cpu: 10
              memory: 100Mi

확인해보면 일부 pod가 pending 상태인걸 확인할 수 있다.
describe로 확인해보자

 kubectl describe pod/my-deploy-6598fd5d9-q5frf

# 결과
...
Events:
  Type     Reason            Age                  From               Message
  ----     ------            ----                 ----               -------
  Warning  FailedScheduling  111s (x4 over 2m1s)  default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 2 Insufficient cpu. preemption: 0/3 nodes are available: 1 Preemption is not helpful for scheduling, 2 No preemption victims found for incoming pod.

pod에 CPU를 할당해야하지만 모든 CPU가 사용중이라서 불가능하다.
해결방법은 실제로 노드를 늘리거나 pod를 줄이는 방법이다.

HPA template

2개의 파일을 만들자

# 02-deploy-for-hpa.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx
          startupProbe:
            httpGet:
              path: /
              port: 80
            periodSeconds: 1
            failureThreshold: 30
          readinessProbe:
            httpGet:
              path: /
              port: 80
            periodSeconds: 5
            failureThreshold: 3
          resources:
            requests:
              cpu: 50m
              memory: 10Mi
            limits:
              cpu: 50m
              memory: 10Mi
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: demo
      image: vinsdocker/util
      args:
        - "sleep"
        - "3600"

위의 파일은 deployment와 데모를 위한 pod 그리고 외부 접속을 위한 service이다.
nginx version에 따라서 cpu나 memory가 더 필요하면 pod가 켜지지 않을 수도 있다. 적당히 조절해주자

# 03-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deploy
  minReplicas: 1
  maxReplicas: 3
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 10
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 10

이 파일은 deployment를 감시하며 autoscaling을 할 HPA 파일이다
이제 적용해보자

kubectl apply -f 02-deploy-for-hpa.yaml
kubectl apply -f 03-hpa.yaml

이제 demo pod로 접속한 후 부하 테스트를 진행해서 pod가 auto scaling이 되는지 확인해보자

kubectl exec -it demo-pod -- bash

root@demo-pod:/# ab -n 20000 -c 5 http://nginx/

그러면 CPU가 더 사용됨에 따라 auto scaling이 되는것을 확인할 수 있다.

이 후 작업이 완료되면 다시 1개로 돌아온다

HPA - Without Probe

이전 2번에서 probe를 주석 처리 하자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx
#          startupProbe:
#            httpGet:
#              path: /
#              port: 80
#            periodSeconds: 1
#            failureThreshold: 30
#          readinessProbe:
#            httpGet:
#              path: /
#              port: 80
#            periodSeconds: 5
#            failureThreshold: 3
          resources:
            requests:
              cpu: 50m
              memory: 20Mi
            limits:
              cpu: 50m
              memory: 20Mi
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: demo
      image: vinsdocker/util
      args:
        - "sleep"
        - "3600"

이제 적용해보자

kubectl apply -f 02-deploy-for-hpa.yaml
kubectl apply -f 03-hpa.yaml

데모 파드로 접속한 후 요청을 보내보자

kubectl exec -it demo-pod -- bash

ab -n 20000 -c 5 http://nginx/

중간에 connection이 거절당하는 것을 확인할 수 있다.

Benchmarking nginx (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
apr_socket_recv: Connection refused (111)
Total of 12928 requests completed

왜 이런일이 발생할까?
오토스케일링은 발생한다. 하지만 Probe가 있으면 컨테이너가 준비 된 후에 요청을 받지만
Probe가 없으면 컨테이너가 준비되기 전에도 요청을 받기 때문에 연결이 거부되는 상황이 생긴다.

[Kubernetes] Persistent Volume & StatefulSet

얼은펭귄 — Mon, 30 Dec 2024 10:16:28 +0900

데이터베이스 같은 어플리케이션의 경우 스토리지가 필요하다.

PV라고도 부른다.
스토리지 추상화 또는 볼륨 플러그인이다.
스토리지를 제공한다.

Term	Description	example
Storage class	스토리지 타입	aws EBS SSD, AWS EBS disk based 등등
Persistent Volume Claim(PVC)	PV를 생성하라는 요청이다.	5GB의 GCP PD ssd를 app을 위해 생성하라고 요청한다.
Persistent Volume (PV)	영구 볼륨인 실제 스토리지 이다.

Storage Class

스토리지 클래스의 참조 문서
https://kubernetes.io/ko/docs/concepts/storage/storage-classes/

아래 명령어를 사용해서 모든 스토리지 클래스를 가져올수 있다.

kubectl get storageclass
kubectl get sc

Access Modes

ReadWriteOnce
ReadWriteOncePod
ReadOnlyMany
ReadWriteMany

Persistent Volume Claim

아래 파일을 생성하자

#01-simple-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5G


kubectl apply -f 01-simple-pvc.yaml

생성 후 아래 명령어를 통해 확인할 수 있다.

kubectl get pvc

#결과
NAME     STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
my-pvc   Pending                                      standard       <unset>                 25s

현재 상태가 pending인데 describe를 통해 확인해보자

kubectl describe pvc

# 결과
Name:          my-pvc
Namespace:     default
StorageClass:  standard
Status:        Pending
Volume:
Labels:        <none>
Annotations:   <none>
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Used By:       <none>
Events:
  Type    Reason                Age               From                         Message
  ----    ------                ----              ----                         -------
  Normal  WaitForFirstConsumer  4s (x6 over 74s)  persistentvolume-controller  waiting for first consumer to be created before binding

pod와 연결하지 않아서 아직 기다리고 있는것을 확인할 수 있다.
아래 파일을 생성하자

#02-pod-with-pvc.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  terminationGracePeriodSeconds: 1
  restartPolicy: Never
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: pod-volume
  volumes:
    - name: pod-volume
      persistentVolumeClaim:
        claimName: my-pvc



kubectl apply -f 02-pod-with-pvc.yaml

적용 후 확인해보자

kubectl get pvc

# 결과
NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
my-pvc   Bound    pvc-27af6678-3a6c-4059-9c53-8404d125af4d   5G         RWO            standard       <unset>                 9m45s



kubectl describe pvc

# 결과
Name:          my-pvc
Namespace:     default
StorageClass:  standard
Status:        Bound
Volume:        pvc-27af6678-3a6c-4059-9c53-8404d125af4d
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: rancher.io/local-path
               volume.kubernetes.io/selected-node: dev-cluster-worker
               volume.kubernetes.io/storage-provisioner: rancher.io/local-path
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      5G
Access Modes:  RWO
VolumeMode:    Filesystem
Used By:       my-pod
Events:
  Type    Reason                 Age                   From
         Message
  ----    ------                 ----                  ----
         -------
  Normal  WaitForFirstConsumer   3m48s (x26 over 10m)  persistentvolume-controller
         waiting for first consumer to be created before binding
  Normal  Provisioning           104s                  rancher.io/local-path_local-path-provisioner-57c5987fd4-2k8pk_20c2ba64-75fe-4e53-83b3-a9646cfc0d09  External provisioner is provisioning volume for claim "default/my-pvc"
  Normal  ProvisioningSucceeded  102s                  rancher.io/local-path_local-path-provisioner-57c5987fd4-2k8pk_20c2ba64-75fe-4e53-83b3-a9646cfc0d09  Successfully provisioned volume pvc-27af6678-3a6c-4059-9c53-8404d125af4d

실제 생성된 볼륨을 가져와보자

kubectl get pv
# 결과
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-27af6678-3a6c-4059-9c53-8404d125af4d   5G         RWO            Delete           Bound    default/my-pvc   standard       <unset>    2m27s


kubectl describe pv
# 결과
Name:              pvc-27af6678-3a6c-4059-9c53-8404d125af4d
Labels:            <none>
Annotations:       pv.kubernetes.io/provisioned-by: rancher.io/local-path
Finalizers:        [kubernetes.io/pv-protection]
StorageClass:      standard
Status:            Bound
Claim:             default/my-pvc
Reclaim Policy:    Delete
Access Modes:      RWO
VolumeMode:        Filesystem
Capacity:          5G
Node Affinity:
  Required Terms:
    Term 0:        kubernetes.io/hostname in [dev-cluster-worker]
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /var/local-path-provisioner/pvc-27af6678-3a6c-4059-9c53-8404d125af4d_default_my-pvc
    HostPathType:  DirectoryOrCreate
Events:            <none>

이제 실제 PV가 있는 도커 안으로 진입해서 확인해보자

# 진입할 worker는 위의 describe 결과로 확인하자
docker exec -it dev-cluster-worker bash
# 아래 경로는 위의 describe 경로를 확인하자
cd /var/local-path-provisioner/pvc-27af6678-3a6c-4059-9c53-8404d125af4d_default_my-pvc

# 파일을 생성한다
"Hello PVC" > index.html

#도커 진입 종료
exit

이제 port-forawd를 통해서 확인해보자

kubectl port-forward my-pod 8080:80

http://localhost:8080/ 으로 접근해보면 Hello PVC가 출력되는것을 확인할 수 있다.

이제 파드를 삭제후 무슨일이 일어나는지 확인해보자

kubectl delete -f 02-pod-with-pvc.yaml
kubectl get pvc
kubectl get pv

pod를 삭제 후에도 pvc와 pv는 살아있는것을 확인할수 있다. 다시 pod를 생성해보자

kubectl apply -f 02-pod-with-pvc.yaml
kubectl port-forward my-pod 8080:80

파드를 생성하고 port-forward를 적용하면 여전히 hello pvc가 나오는것을 확인할 수 있다.

Persistent Volume - Delete

파드와 PVC를 삭제하자

kubectl delete -f 02-pod-with-pvc.yaml
kubectl delete -f 01-simple-pvc.yaml

이제 확인해보자

kubectl get pv
kubectl get pvc

PVC를 지우면 PV는 자동으로 삭제되는걸 확인할 수 있다.

Deployment with PVC

deployment를 사용해서 3개의 replica가 동시에 pv안의 같은 파일에 쓰면 어떤일이 일어날까
아래 파일을 생성해보자

#03-deployment-with-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5G
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: nginx
        image: nginx
        startupProbe: # for demo
          exec:
            command:
              - "/bin/sh"
              - "-c"
              - 'echo "$(hostname)</br>" >> /usr/share/nginx/html/index.html'
        volumeMounts:
          - mountPath: /usr/share/nginx/html
            name: pod-volume
      volumes:
        - name: pod-volume
          persistentVolumeClaim:
            claimName: my-pvc



kubectl apply -f 03-deployment-with-pvc.yaml

아래 명령어를 확인해보면 pvc와 pv는 하나만 생성된걸 확인할 수있다.

kubectl get pvc
kubectl get pv

포트포워딩을 해서 확인해보자

kubectl port-forward deploy/my-deploy 8080:80

# localhost:8080접속
my-deploy-85dbd57976-49pdl
my-deploy-85dbd57976-8r9mh
my-deploy-85dbd57976-xc2jh

결과를 보면 한 파일에 3개의 pod가 write를 한 것을 확인할 수 있다.
원할때는 이렇게 사용하고 원하지 않는다면 조심해서 사용하자
각각의 Pod가 pv를 갖기 위해서는 statefulSet을 사용해야 한다.

StatefulSet

개념은 배포와 비슷하다.

# 04-simple-ss.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-ss
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.14



kubectl apply -f 04-simple-ss.yaml

파일을 생성하고 적용해서 확인해보면 순차적으로 pod가 생성되는것을 확인할수 있다.

watch -t -x kubectl get all

# 결과
NAME          READY   STATUS    RESTARTS   AGE
pod/my-ss-0   1/1     Running   0          116s
pod/my-ss-1   1/1     Running   0          109s
pod/my-ss-2   1/1     Running   0          102s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   3d22h

NAME                     READY   AGE
statefulset.apps/my-ss   3/3     116s

생성된 파드를 확인해보면 실제로 random한 이름으로 생성되지 않고 index이름이 끝에 붙어서 생성되는걸 확인할 수 있다.
또한 한번에 모든 pod가 생성되지 않고 순차적으로 생성된다.
pod를 하나 지워보자

kubectl delete pod/my-ss-1

# 결과
NAME          READY   STATUS    RESTARTS   AGE
pod/my-ss-0   1/1     Running   0          3m44s
pod/my-ss-1   1/1     Running   0          19s
pod/my-ss-2   1/1     Running   0          3m30s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   3d22h

NAME                     READY   AGE
statefulset.apps/my-ss   3/3     3m44s

파드를 지워도 랜덤한 이름으로 생성되지 않고 다시 그 이름으로 생성되는것을 확인할 수 있다.
replicaSet을 5개로 늘려서 적용 후 다시 2개로 변경한다음 적용해보자
pod가 index 끝부터 사라지는걸 확인할 수 있다.

NAME          READY   STATUS    RESTARTS   AGE
pod/my-ss-0   1/1     Running   0          5m13s
pod/my-ss-1   1/1     Running   0          108s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   3d22h

NAME                     READY   AGE
statefulset.apps/my-ss   2/2     5m13s

이번엔 이미지를 바꿔보자

...
    spec:
      containers:
        - name: nginx
          image: nginx

적용해보면 index 끝부터 바뀌는걸 확인할 수 있다.

StatefulSet with Service

#05-ss-svc.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-ss
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: nginx
          image: vinsdocker/nginx-gke
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: demo
      image: vinsdocker/util
      args:
        - "sleep"
        - "3600"


kubectl apply -f 05-ss-svc.yaml

이제 demo-pod에 접속해서 호출해보자

kubectl exec -it demo-pod -- bash

# 결과
root@demo-pod:/# curl nginx
<H1>Hello my-ss-1 </H1>
root@demo-pod:/# curl nginx
<H1>Hello my-ss-2 </H1>
root@demo-pod:/# curl nginx
<H1>Hello my-ss-1 </H1>
root@demo-pod:/# curl nginx
<H1>Hello my-ss-0 </H1>

이렇게 service가 load balancing을 해주는 것을알수 있다.
특정 pod에 접근하려면 어떻게 해야할까?

Headless Service

헤드리스 서비스는 IP가 없고 kube-proxy가 로드밸런싱을 하지 않는다.
대신에 <pod-name>.<svc-name> 형식으로 DNS가 생성된다.

# 06-ss-headless-svc.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-ss
spec:
  serviceName: nginx
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: nginx
          image: vinsdocker/nginx-gke
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: ClusterIP
  clusterIP: None # headless service
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: demo
      image: vinsdocker/util
      args:
        - "sleep"
        - "3600"



 kubectl apply -f 06-ss-headless-svc.yaml

이제 파드에 접속해서 살펴보자

kubectl exec -it demo-pod -- bash

# 결과
root@demo-pod:/# nslookup nginx
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   nginx.default.svc.cluster.local
Address: 10.244.2.10
Name:   nginx.default.svc.cluster.local
Address: 10.244.2.9
Name:   nginx.default.svc.cluster.local
Address: 10.244.1.19

# 특정 IP만 얻기
root@demo-pod:/# nslookup my-ss-0.nginx
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   my-ss-0.nginx.default.svc.cluster.local
Address: 10.244.2.9

이제 요청을 해보자

root@demo-pod:/# curl nginx
<H1>Hello my-ss-1 </H1>
root@demo-pod:/# curl nginx
<H1>Hello my-ss-1 </H1>
root@demo-pod:/# curl my-ss-0.nginx
<H1>Hello my-ss-0 </H1>
root@demo-pod:/# curl my-ss-0.nginx
<H1>Hello my-ss-0 </H1>

이렇게 특정 pod로만 요청을 보낼수 있다.

Dynamic Persistent Volume Claim

파일을 생성하고 적용해보자

# 07-ss-pvc.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-ss
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: nginx
        image: nginx
        startupProbe: # for demo
          exec:
            command:
              - "/bin/sh"
              - "-c"
              - 'echo "$(hostname)</br>" >> /usr/share/nginx/html/index.html'
        volumeMounts:
          - mountPath: /usr/share/nginx/html
            name: my-pvc
  volumeClaimTemplates:
    - metadata:
        name: my-pvc
      spec:
        storageClassName: standard
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1G



kubectl apply -f 07-ss-pvc.yaml

아래 명령어를 통해 각각 pvc와 pv가 확인된걸 확인할 수 있다.

kubectl get pvc
NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
my-pvc-my-ss-0   Bound    pvc-624f0b5a-89e2-40e4-9ab9-7f260e6d7436   1G         RWO            standard       <unset>                 39s
my-pvc-my-ss-1   Bound    pvc-cd5916e7-f20d-4414-a3c7-eadb6e6c466a   1G         RWO            standard       <unset>                 22s
my-pvc-my-ss-2   Bound    pvc-c31dd928-3f4d-4c65-9cc9-8606db0b23b4   1G         RWO            standard       <unset>                 6s

kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                        STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-624f0b5a-89e2-40e4-9ab9-7f260e6d7436   1G         RWO            Delete           Bound    default/my-pvc-my-deploy-0   standard       <unset>                          69s
pvc-c31dd928-3f4d-4c65-9cc9-8606db0b23b4   1G         RWO            Delete           Bound    default/my-pvc-my-deploy-2   standard       <unset>                          37s
pvc-cd5916e7-f20d-4414-a3c7-eadb6e6c466a   1G         RWO            Delete           Bound    default/my-pvc-my-deploy-1   standard       <unset>                          52s

포트포워딩을 통해 연결된 storage를 확인할 수 있다.

kubectl port-forward pod/my-ss-0 8080:80
# localhost:8080 접속
my-ss-0

kubectl port-forward pod/my-ss-1 8080:80
# localhost:8080 접속
my-ss-1

kubectl port-forward pod/my-ss-2 8080:80
# localhost:8080 접속
my-ss-2

파일을 지우고 다시 적용해보면 PVC가 새로 생성되지 않는다.
이미 존재하는 PVC를 사용한다.
다시 포트 포워딩을 해보면 2번 적혀있는것을 확인할 수 있다.

kubectl port-forward pod/my-ss-0 8080:80
# localhost:8080 접속
my-ss-0
my-ss-0

kubectl port-forward pod/my-ss-1 8080:80
# localhost:8080 접속
my-ss-1
my-ss-1

kubectl port-forward pod/my-ss-2 8080:80
# localhost:8080 접속
my-ss-2
my-ss-2

아래 명령어를 통해서 모든 pvc를 삭제할 수 있다.

kubectl delete pvc --all

[Kubernetes] Secret

얼은펭귄 — Thu, 19 Dec 2024 19:38:50 +0900

Configmap과 동일하지만 민감한 데이터이다.
value는 base64로 인코딩되어있다.
사용사례는 ssh key file, 자격증명, 사비스 계정 정보 등을 저장한다.

터미널에서 간단하게 생성할 수 도 있다.

kubectl create secret generic my-secret --from-literal=[key]=[value]
ex) kubectl create secret generic my-secret --from-literal=username=vinoth --from-liter
al=password=admin123

# secret 가져오기
kubectl get secret

# secret 상세정보
kubectl get secret -o yaml
apiVersion: v1
items:
- apiVersion: v1
  data:
    password: YWRtaW4xMjM=
    username: dmlub3Ro
  kind: Secret
  metadata:
    creationTimestamp: "2024-12-17T02:24:34Z"
    name: my-secret
    namespace: default
    resourceVersion: "1121"
    uid: b3034f27-42f0-41d6-b95a-d3f95a511b44
  type: Opaque
kind: List
metadata:
  resourceVersion: ""

파일을 작성해보자
리눅스 터미널에서 문자열을 base64로 인코딩해서 입력해야한다.

echo -n test | base64                                                                                                                                                                                                                                  
dGVzdA== 

echo -n admin123 | base64
YWRtaW4xMjM=

#04-simple-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
  username: dGVzdA== # test
  password: YWRtaW4xMjM= # admin123

이제 파드에 주입해보자

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
  username: dGVzdA== # test
  password: YWRtaW4xMjM= # admin123
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
      env:
        - name: "app_username"
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: username
        - name: "app_password"
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: password
      args:
        - env

실행하고 확인해보면 제대로 들어간것을 확인할 수 있다.

kubectl apply -f 04-simple-secret.yaml
kubectl get secret -o yaml

kubectl logs my-pod

# 결과
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=my-pod
app_password=admin123
app_username=test
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
HOME=/root

또한 전체 env도 가능하다.

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
  username: dGVzdA== # test
  password: YWRtaW4xMjM= # admin123
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
      envFrom:
      - secretRef:
          name: app-secret
      args:
        - env

Secret - 파일 삽입

01번 파일을 base64로 인코딩하고 입력하자

# 06-inject-secret-as-file.yaml
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
  app.key: |
    YXBpVmVyc2lvbjogdjENCmtpbmQ6IENvbmZpZ01hcA0KbWV0YWRhdGE6DQogIG5hbWU6IGFwcC1w
    cm9wZXJ0aWVzDQpkYXRhOg0KICBhcHBVcmw6ICJodHRwOi8vbXktYXBwLXNlcnZpY2UiDQogIHRp
    bWVvdXQ6ICIzMCINCi0tLQ0KYXBpVmVyc2lvbjogdjENCmtpbmQ6IFBvZA0KbWV0YWRhdGE6DQog
    IG5hbWU6IG15LXBvZA0Kc3BlYzoNCiAgcmVzdGFydFBvbGljeTogTmV2ZXINCiAgY29udGFpbmVy
    czoNCiAgICAtIG5hbWU6IHVidW50dQ0KICAgICAgaW1hZ2U6IHVidW50dQ0KICAgICAgZW52Og0K
    ICAgICAgICAtIG5hbWU6ICJyZXF1ZXN0LnRpbWVvdXQiDQogICAgICAgICAgdmFsdWVGcm9tOg0K
    ICAgICAgICAgICAgY29uZmlnTWFwS2V5UmVmOg0KICAgICAgICAgICAgICBuYW1lOiBhcHAtcHJv
    cGVydGllcw0KICAgICAgICAgICAgICBrZXk6IHRpbWVvdXQNCiAgICAgICAgLSBuYW1lOiAiYXBw
    bGljYXRpb24udXJsIg0KICAgICAgICAgIHZhbHVlRnJvbToNCiAgICAgICAgICAgIGNvbmZpZ01h
    cEtleVJlZjoNCiAgICAgICAgICAgICAgbmFtZTogYXBwLXByb3BlcnRpZXMNCiAgICAgICAgICAg
    ICAga2V5OiBhcHBVcmwNCiAgICAgIGFyZ3M6DQogICAgICAgIC0gZW52DQo=
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  terminationGracePeriodSeconds: 1
  restartPolicy: Never
  containers:
  - name: ubuntu
    image: ubuntu
    volumeMounts:
      - name: secret-volume
        mountPath: /usr/share/props
    args:
      - sleep
      - "3600"
  volumes:
  - name: secret-volume
    secret:
      secretName: app-secret

적용하고 파드에 접속해서 확인해보면 파일이 복사된걸 확인할 수 있다.

kubectl apply -f 06-inject-secret-as-file.yaml
kubectl exec -it my-pod -- bash
cd /usr/share/props/

# 파일 확인
cat app.key

# 결과
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-properties
data:
  appUrl: "http://my-app-service"
  timeout: "30"
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
      env:
        - name: "request.timeout"
          valueFrom:
            configMapKeyRef:
              name: app-properties
              key: timeout
        - name: "application.url"
          valueFrom:
            configMapKeyRef:
              name: app-properties
              key: appUrl
      args:
        - env

[Kubernetes] ConfigMap

얼은펭귄 — Thu, 19 Dec 2024 19:35:44 +0900

이 글에서는 구성 정보를 애플리케이션과 분리하는 방법을 소개한다.

ConfigMap 과 secret 을 통해서 애플리케이션과 환경 정보를 분리할 수 있다.
ConfigMap 은 민감하지 않은 데이터를 관리한다.
secret은 증명서같은 민감한 데이터를 관리한다.

ConfigMap

속성을 key/value 형식으로 가능하다.
속성으로 파일도 가능하다.
최대 1MB이다.

ConfigMap - Demo

#01-simple-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-properties
data:
  appUrl: "http://my-app-service"
  timeout: "30"



kubectl apply -f 01-simple-configmap.yaml

파일을 생성하고 적용하고 kubectl get all로 확인해도 아무것도 없는것을 볼 수 있다.
아래 명령어로 확인해보자

kubectl get configmap
# 위와 동일
kubectl get cm

# 결과
NAME               DATA   AGE
app-properties     2      60s
kube-root-ca.crt   1      3h9m

자세하게 보려면 아래처럼 할 수 있다.

kubectl describe cm app-properties

#결과
Name:         app-properties
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
appUrl:
----
http://my-app-service

timeout:
----
30


BinaryData
====

Events:  <none>

ConfigmMap - 환경변수 주입

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-properties
data:
  appUrl: "http://my-app-service"
  timeout: "30"
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
      env:
        - name: "request.timeout"
          valueFrom:
            configMapKeyRef:
              name: app-properties
              key: timeout
        - name: "application.url"
          valueFrom:
            configMapKeyRef:
              name: app-properties
              key: appUrl
      args:
        - env

위 파일을 생성하고 적용해보자
로그를 확인해보면 환경변수가 제대로 적용된걸 확인할 수 있다.

kubectl logs my-pod

# 결과
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=my-pod
request.timeout=30
application.url=http://my-app-service
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
HOME=/root

# 02-inject-cm-as-env.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-properties
data:
  appUrl: "http://my-app-service"
  timeout: "30"
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
      envFrom:
      - configMapRef:
          name: app-properties
      args:
        - env

새로운 파일 생성 후 이전 파일들을 지우고 로그를 확인해보자

# 기존 정보 삭제
kubectl delete  -f 01-simple-configmap.yaml
configmap "app-properties" deleted
pod "my-pod" deleted

# 새로 적용
kubectl apply -f 02-inject-cm-as-env.yaml
configmap/app-properties created
pod/my-pod created

# 로그확인
kubectl logs my-pod

#결과
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=my-pod
appUrl=http://my-app-service
timeout=30
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
HOME=/root

ConfigMap - 파일 삽입

이전 정보를 삭제하고 파일을 생성한 후 적용해보자

# 03-inject-cm-as-file.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-properties
data:
  application.properties: |
    appUrl=http://my-app-service
    timeout=30
    a.b.c=something
    username=sy



kubectl delete -f 02-inject-cm-as-env.yaml
kubectl apply -f 03-inject-cm-as-file.yaml

이제 확인해보면 잘 생성된것을 볼 수 있다.

kubectl get cm app-properties -o yaml

# 결과
apiVersion: v1
data:
  application.properties: |
    appUrl=http://my-app-service
    timeout=30
    a.b.c=something
    username=sy
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"application.properties":"appUrl=http://my-app-service\ntimeout=30\na.b.c=something\nusername=sy\n"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"app-properties","namespace":"default"}}
  creationTimestamp: "2024-12-16T07:54:03Z"
  name: app-properties
  namespace: default
  resourceVersion: "18713"
  uid: 7fbc03a8-8bc4-45d1-847c-be46a1e2878e

아래처럼 파일을 수정해보자

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-properties
data:
  application.properties: |
    appUrl=http://my-app-service
    timeout=30
    a.b.c=something
    username=sy
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  terminationGracePeriodSeconds: 1
  restartPolicy: Never
  containers:
  - name: ubuntu
    image: ubuntu
    volumeMounts:
      - name: config-volume
        mountPath: /user/share/props
    args:
      - sleep
      - "3600"
  volumes:
  - name: config-volume
    configMap:
      name: app-properties

적용하고 컨테이너에 진입해서 확인해보자

kubectl apply -f 03-inject-cm-as-file.yaml

# 결과
configmap/app-properties created
pod/my-pod created

# 컨테이너 접속
kubectl exec -it my-pod -- bash
root@my-pod:/# cd /usr/share/props
root@my-pod:/usr/share/props# ll

# 결과
drwxrwxrwx 3 root root 4096 Dec 16 08:03 ./
drwxr-xr-x 1 root root 4096 Dec 16 08:03 ../
drwxr-xr-x 2 root root 4096 Dec 16 08:03 ..2024_12_16_08_03_44.82811588/
lrwxrwxrwx 1 root root   30 Dec 16 08:03 ..data -> ..2024_12_16_08_03_44.82811588/
lrwxrwxrwx 1 root root   29 Dec 16 08:03 application.properties -> ..data/application.properties

# 확인
cat application.properties

# 결과
appUrl=http://my-app-service
timeout=30
a.b.c=something
username=sy

파일이 잘 들어간것을 확인할 수 있다.

[Kubernetes] Probes

얼은펭귄 — Thu, 19 Dec 2024 19:30:15 +0900

kubelet은 컨테이너가 시작되자마자 실제로 준비되지 않은 상황에서도 살아있고 준비된 상태라고 생각한다.
아직 활성화 되지 않은 부분이 활성화 된 것처럼 취급되면 안된다.

probe는 파드의 health 체크를 도와주는 도구일 뿐이다.
파드내 어플이 시작 되었는지, 살아있는지, 요청을 받을 준비가 되었는지를 확인한다

Probe Types

Terms

Live => 파드가 살아있는지?
Ready => 파드가 요청을 받을 준비가 되었는지?

Probes	Description	Action If Fails
startupProbe	컨테이너 내부 애플리케이션이 시작되었는지 확인	재시작
livenessProbe	애플리케이션이 여전히 살아 있는지 확인	재시작
readinessProbe	애플리케이션이 서비스로부터 요청을 처리할 준비가 되었는지 확인	서비스에서 제외

k8s는 위의 방법에 3가지 옵션을 제공한다.

exec: 아무 커맨드를 체크하기 위해 실행한다 ex) cat /tmp/app.log
httpGet: http 엔드포인트에 요청한다. ex) /health
tcpSocket: 앱이 특정 포트에서 수신 대기 중인지 확인한다.

어떤 프로브에 어떤 옵션을 사용하던 상관없다

프로브 속성은 아래와 같다.

Properties	Default Values
initialDelaySeconds	0
periodSeconds	10
timeoutSeconds	1
successThreshold	1
failureThreshold	3

Startup Probe - httpGet

실패하는 프로브를 생성하고 관찰해보자

#01-startup-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx
      startupProbe:
        httpGet:
          path: /dummy
          port: 80
        periodSeconds: 1
        failureThreshold: 3





kubectl apply -f .

kubectl describe pod

# 결과
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  27s                default-scheduler  Successfully assigned default/my-pod to dev-cluster-worker2
  Normal   Pulled     27s                kubelet            Successfully pulled image "nginx" in 1.579s (1.579s including waiting). Image size: 72099501 bytes.
  Normal   Pulled     22s                kubelet            Successfully pulled image "nginx" in 1.519s (1.519s including waiting). Image size: 72099501 bytes.
  Normal   Pulling    18s (x3 over 27s)  kubelet            Pulling image "nginx"
  Normal   Created    17s (x3 over 27s)  kubelet            Created container nginx
  Normal   Pulled     17s                kubelet            Successfully pulled image "nginx" in 1.542s (1.542s including waiting). Image size: 72099501 bytes.
  Normal   Started    16s (x3 over 27s)  kubelet            Started container nginx
  Warning  Unhealthy  14s (x9 over 26s)  kubelet            Startup probe failed: HTTP probe failed with statuscode: 404
  Normal   Killing    13s (x3 over 23s)  kubelet            Container nginx failed startup probe, will be restarted
  Warning  BackOff    13s                kubelet            Back-off restarting failed container nginx in pod my-pod_def

Startup probe가 실패한걸 확인할 수 있다.
아래 처럼 변경하고 다시 시작해보자

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx
      startupProbe:
        httpGet:
          path: /
          port: 80
        periodSeconds: 1
        failureThreshold: 3



kubectl apply -f .

Startup Probe - tcpSocket

마찬가지로 의도적으로 실패하는 코드를 만들어보자

# 02-startup-tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: mongo
      image: mongo
      startupProbe:
        tcpSocket:
          port: 27018
        periodSeconds: 1
        failureThreshold: 5

적용후 살펴보면 startup probe 가 실패한걸 확인할 수 있다.

kubectl apply -f 02-startup-tcpsocket.yaml
kubectl describe pod

# 결과
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  22s               default-scheduler  Successfully assigned default/my-pod to dev-cluster-worker2
  Normal   Pulled     11s               kubelet            Successfully pulled image "mongo" in 12.796s (12.796s including waiting). Image size: 274465658 bytes.
  Normal   Pulling    6s (x2 over 22s)  kubelet            Pulling image "mongo"
  Normal   Killing    6s                kubelet            Container mongo failed startup probe, will be restarted
  Normal   Created    4s (x2 over 11s)  kubelet            Created container mongo
  Normal   Started    4s (x2 over 11s)  kubelet            Started container mongo
  Normal   Pulled     4s                kubelet            Successfully pulled image "mongo" in 1.536s (1.536s including waiting). Image size: 274465658 bytes.
  Warning  Unhealthy  0s (x9 over 10s)  kubelet            Startup probe failed: dial tcp 10.244.1.7:27018: connect: connection refused

이 후 27017로 포트번호를 변경하고 적용하면 생성되는걸 확인할 수 있다.

Startup Probe - exec

#03-startup-exec.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx
      startupProbe:
        exec:
          command:
            - "cat"
            - "dummy.txt"
        periodSeconds: 1
        failureThreshold: 3

일반적으로 httpGet이나 tcpSocket을 더 선호하며 exec는 둘 다 안될 경우를 위한다.

kubectl apply -f 03-startup-exec.yaml
kubectl describe pod
# 결과
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  13s               default-scheduler  Successfully assigned default/my-pod to dev-cluster-worker2
  Normal   Pulled     12s               kubelet            Successfully pulled image "nginx" in 1.506s (1.506s including waiting). Image size: 72099501 bytes.
  Normal   Pulled     6s                kubelet            Successfully pulled image "nginx" in 1.618s (1.618s including waiting). Image size: 72099501 bytes.
  Normal   Pulling    3s (x3 over 13s)  kubelet            Pulling image "nginx"
  Normal   Killing    3s (x2 over 8s)   kubelet            Container nginx failed startup probe, will be restarted
  Normal   Created    2s (x3 over 12s)  kubelet            Created container nginx
  Normal   Pulled     2s                kubelet            Successfully pulled image "nginx" in 1.568s (1.568s including waiting). Image size: 72099501 bytes.
  Normal   Started    1s (x3 over 12s)  kubelet            Started container nginx
  Warning  Unhealthy  1s (x7 over 11s)  kubelet            Startup probe failed: cat: dummy.txt: No such file or directory

아래처럼 파일을 변경하고 삭제 후 재실행하면

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx
      startupProbe:
        exec:
          command:
            - "cat"
            - "/usr/share/nginx/html/index.html"
        periodSeconds: 1
        failureThreshold: 3

Liveness Probe

#04-liveness-probe.yaml
# 실제로는 nignx를 사용한다
# nginx가 10초 되에 시작될 것이다.
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: probe-demo
      image: vinsdocker/k8s-probe-demo
      startupProbe:
        httpGet:
          path: /
          port: 80
        periodSeconds: 1
        failureThreshold: 3

이렇게 실행하면 실제로 10초 뒤에 nginx가 실행되는 docker 이기 때문에 실패한다 failureThreshold를 30으로 바꿔주자

# 실제로는 nignx를 사용한다
# nginx가 10초 되에 시작될 것이다.
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: probe-demo
      image: vinsdocker/k8s-probe-demo
      startupProbe:
        httpGet:
          path: /
          port: 80
        periodSeconds: 1
        failureThreshold: 30
      livenessProbe:
        httpGet:
          path: /live.html
          port: 80
        periodSeconds: 1
        failureThreshold: 3

적용하고 컨테이너가 실행중인것을 확인한 후 파드로 들어가보자

kubectl apply -f 04-liveness-probe.yaml
kubectl exec -it my-pod -- bash
root@my-pod:/# cd /usr/share/nginx/html
root@my-pod:/usr/share/nginx/html# ls
50x.html  index.html  live.html  ready.html

이제 여기서 live.html을 지워보자

root@my-pod:/usr/share/nginx/html# rm live.html
root@my-pod:/usr/share/nginx/html# command terminated with exit code 137

liveness probe가 문제가 있다고 생각하고 파드를 재시작했다.

Readiness Probe

# 05-readiness-probe.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: probe-demo
      image: vinsdocker/k8s-probe-demo
      startupProbe:
        httpGet:
          path: /
          port: 80
        periodSeconds: 1
        failureThreshold: 30
      livenessProbe:
        httpGet:
          path: /live.html
          port: 80
        periodSeconds: 1
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /ready.html
          port: 80
        periodSeconds: 1
        failureThreshold: 1

파드를 준비하고 실행하자 그리고 내부로 접속해서 파일을 삭제해보자

kubectl exec -it my-pod -- bash
root@my-pod:/# cd /usr/share/nginx/html/
root@my-pod:/usr/share/nginx/html# ls
50x.html  index.html  live.html  ready.html
root@my-pod:/usr/share/nginx/html# rm ready.html

그럼 컨테이너에 문제가 없기 때문에 파드는 재실행되지 않고 Ready 상태가 0인걸 확인할 수 있다.
touch ready.html 을 통해 다시 파일을 만들어주면 ready 상태가 1/1 로 바뀐것을 확인할 수 있다.

Readiness Probe with service

#05-readiness-probe.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: probe-demo
      image: vinsdocker/k8s-probe-demo
      startupProbe:
        httpGet:
          path: /
          port: 80
        periodSeconds: 1
        failureThreshold: 30
      livenessProbe:
        httpGet:
          path: /live.html
          port: 80
        periodSeconds: 1
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /ready.html
          port: 80
        periodSeconds: 1
        failureThreshold: 1
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80

파일을 적용하고 살펴보자

#적용
kubectl apply -f 05-readiness-probe.yaml
#감시
watch -t -x kubectl describe svc my-app

ready.html 파일을 삭제하면 Endpoint가 사라지지만 k8s 1.31에서는 그런 현상은 일어나지 않는다.

[Kubernetes] Namespace

얼은펭귄 — Thu, 19 Dec 2024 19:20:21 +0900

K8S 클러스터는 가상 클러스터를 생성하거나 클러스터를 분할하는 기능을 제공한다.
기본적으로 클러스터내의 리소스 그룹을 격리한다.

아래 명령어를 통해서 namespace를 가져올 수 있다

# 둘 다 동일한 명령어
kubectl get namespace
kubectl get ns

# 결과 
NAME                 STATUS   AGE
default              Active   40m
kube-node-lease      Active   40m
kube-public          Active   40m
kube-system          Active   40m
local-path-storage   Active   40m

아래 명령어로 네임스페이스를 생성한다.

kubectl create ns [네임스페이스 이름]
ex) kubectl create ns dev
ex) kubectl create ns qa

kubectl get ns

# 결과
NAME                 STATUS   AGE
default              Active   44m
dev                  Active   12s
kube-node-lease      Active   44m
kube-public          Active   44m
kube-system          Active   44m
local-path-storage   Active   44m
qa                   Active   9s

아래 명령어로 네임스페이스를 삭제한다.

kubectl detete ns [네임스페이스 이름]
ex) kubectl detete ns dev

Namespace deploy demo

아래 파일을 생성한다 그리고 qa namespace에 배포한다.

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  selector:
    matchLabels:
      app: order-service
  replicas: 3
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: order-service
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: demo
      image: vinsdocker/util
      args:
        - "sleep"
        - "3600"



kubectl apply -f 06-rolling-update-demo.yaml -n qa

그리고 version을 2로 바꾼 후 dev에 배포한다.

kubectl apply -f 06-rolling-update-demo.yaml -n dev

결과확인을 해보자

kubectl get all -n qa

#결과
NAME                                            READY   STATUS    RESTARTS   AGE
pod/demo-pod                                    1/1     Running   0          94s
pod/order-service-deployment-56864789dc-fz9xw   1/1     Running   0          94s
pod/order-service-deployment-56864789dc-md5kt   1/1     Running   0          94s
pod/order-service-deployment-56864789dc-tsqrj   1/1     Running   0          94s

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/my-app   ClusterIP   10.96.199.164   <none>        80/TCP    94s

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/order-service-deployment   3/3     3            3           94s

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/order-service-deployment-56864789dc   3         3         3       94s

kubectl get all -n dev

# 결과
NAME                                           READY   STATUS    RESTARTS   AGE
pod/demo-pod                                   1/1     Running   0          47s
pod/order-service-deployment-d684fb7c6-4xvqh   1/1     Running   0          47s
pod/order-service-deployment-d684fb7c6-6zp6x   1/1     Running   0          47s
pod/order-service-deployment-d684fb7c6-wzzxn   1/1     Running   0          47s

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/my-app   ClusterIP   10.96.159.225   <none>        80/TCP    47s

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/order-service-deployment   3/3     3            3           47s

NAME                                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/order-service-deployment-d684fb7c6   3         3         3       47s

실제로 cluster-ip가 다른것을 확인할 수 있다.
포트포워딩을 사용해서 v1과 v2에 접근할수 있는지 확인해보자

# v1 화면을 볼 수 있다.
kubectl port-forward svc/my-app 8080:80 -n qa

# v2 화면을 볼 수 있다.
kubectl port-forward svc/my-app 8080:80 -n dev

namespace를 삭제하면 안의 모든 리소스들이 삭제된다.

yaml 파일에 metadata안의 namespace를 선언하면 -n 옵션 없이도 항상 해당 네임스페이스에서 생성한다.

[Kubernetes] Service

얼은펭귄 — Tue, 17 Dec 2024 15:02:39 +0900

파드 세트에 대한 논리적 추상화이다.
안정적인 단일 엔드포인트를 통해 노출한다.

Demo

sec04의 1번을 복사한다.

# 01-simple-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80

이후 service 파일을 생성한다.

# 02-simple-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80

kubectl apply -f .

적용 후 세부 사항을 살펴보자

kubectl describe svc nginx

#결과
Name:                     nginx
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=my-app
Type:                     ClusterIP
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.96.192.111
IPs:                      10.96.192.111
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
Endpoints:                10.244.1.9:80,10.244.2.10:80,10.244.1.10:80
Session Affinity:         None
Internal Traffic Policy:  Cluster
Events:                   <none>

올라가 있는 파드를 지우거나 늘리거나 변경되면 Endpoints가 즉시 업데이트 된다.

Load Balancing

#03-svc-load-balancing.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: nginx
          image: vinsdocker/nginx-gke
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: demo
      image: vinsdocker/util
      args:
        - "sleep"
        - "3600"



kubectl apply -f 03-svc-load-balancing.yaml.yaml

클러스터 내부에서 파드끼리 통신하기 위한 demo-app과 로드밸런싱을 위한 service, my-app을 만든다.
이후 pod 내부에 접속한다.

kubectl exec -it demo-pod -- bash

이 후 요청을 보내보면 매번 다른 pod 이름을 보여주는것을 확인할 수 있다.

# 반복
root@demo-pod:/# curl my-app

Service Types

타입	설명
ClusterIP	K8S 클러스터 내부에서 통신을 위한 타입이다. 클러스터 외부에서는 접근할 수 없다. 타입을 지정하지않으면 기본값이다.
NodePort	클러스터 외부에서 K8S 마스터/노드를 통해 특정 포트를 사용해서 접근할 수 있다.
LoadBalancer	외부에서 들어오는 트래픽을 수신하는데 사용된다. (AWS, GCP 같은 클라우드 업체에서 사용된다.)

* 클러스터 외부의 노출은 ingress를 사용하며 이는 나중에 학습한다.

Kind cluster with extra port mapping

기존 클러스터를 삭제하고 추가 포트매핑을 한 클러스터를 생성해보자

kind delete cluster --name dev-cluster

아래처럼 파일을 생성하고 클러스터를 생성하자

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: dev-cluster
nodes:
- role: control-plane
  extraPortMappings:
    - containerPort: 30001
      hostPort: 30001
      protocol: TCP
- role: worker
- role: worker


kind create cluster --config [yaml 파일]

아래 명령어를 통해 port 매핑을 확인할 수 있다.

docker ps -a 

# 결과
CONTAINER ID   IMAGE                  COMMAND                  CREATED          STATUS          PORTS
                              NAMES
6e4af28b723c   kindest/node:v1.31.2   "/usr/local/bin/entr…"   31 seconds ago   Up 28 seconds   0.0.0.0:30001->30001/tcp, 127.0.0.1:45971->6443/tcp   dev-cluster-control-plane
056d4e90bc99   kindest/node:v1.31.2   "/usr/local/bin/entr…"   31 seconds ago   Up 28 seconds
                              dev-cluster-worker
76da068e1786   kindest/node:v1.31.2   "/usr/local/bin/entr…"   31 seconds ago   Up 28 seconds
                              dev-cluster-worker2

Nodeport - Demo

# 05-nodeport-service.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      terminationGracePeriodSeconds: 1
      containers:
        - name: nginx
          image: vinsdocker/nginx-gke
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30001



kubectl apply -f 05-nodeport-service.yaml

watch 명령어로 확인해보면 NodePort가 있는것을 확인할 수 있고
아래 페이지로 들어가보면 접속이 되는것을 확인할 수 있다.
http://localhost:30001/

Rolling Update With Service

# 06-rolling-update-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  selector:
    matchLabels:
      app: order-service
  replicas: 3
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: order-service
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: demo
      image: vinsdocker/util
      args:
        - "sleep"
        - "3600"
        
        
kubectl apply -f 06-rolling-update-demo.yaml

위 파일을 생성하고 접속한다.

kubectl exec -it demo-pod -- bash

이후 아래 명령어를 쳐보면 V1이 나오는것을 확인할 수 있다.

for i in {1..1000}; do curl -s http://my-app | grep -o "<title>[^<]*" | tail -c+8; done

이때 빠르게 v2로 변경하고 적용하면 V1과 V2가 섞여서 나오는것을 확인할 수 있다.
그러다가 모두 V2로 변경되는것을 확인할 수 있다.

[Kubernetes] Deployment

얼은펭귄 — Mon, 16 Dec 2024 18:16:54 +0900

프로덕션에서 생성하고 사용할 것은 deployment이다.
deployment는 replicaSet을 매니징한다.
1 deployment 당 1서비스이다.

Demo

아래 파일을 생성 후 적용해보면 결과를 확인할 수 있다.

#01-simple-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx

kubectl create -f 01-simple-deploy.yaml

적용하면 deployment를 생성하고 해당 deployment가 replicaset을 생성하며 replicaset이 pod들을 생성하는걸 확인할 수 있다.

kubectl craete와 kubectl apply의 차이점

Command	Description
kubectl create -f [파일이름]	주어진 파일로 리소스를 생성한다.
kubectl create -f .	현재 디렉토리에서 모든 yaml파일을 기반으로 리소스를 생성한다.
kubectl create -f http://vinsguru.com/k8s.yaml	주어진 url로 리소스를 생성한다.

Command	Description
kubectl apply -f [파일이름]	주어진 파일로 리소스를 생성/업데이트한다.
kubectl apply -f .	현재 디렉토리에서 모든 yaml파일을 기반으로 리소스를 생성/업데이트한다.
kubectl apply -f http://vinsguru.com/k8s.yaml	주어진 url로 리소스를 생성/업데이트한다.

create는 없으면 생성 있으면 에러를 내지만
apply는 없으면 생성 있으면 변경사항을 적용하며, 변경사항이 없으면 무시된다.
위 01 파일이 실행된 삭제된 상태로 아래 명령어들을 차례로 실행해보면 결과를 알 수 있다.

# 정상적으로 생성
kubectl create -f 01-simple-deploy.yaml

# 다시 실행시 에러
kubectl create -f 01-simple-deploy.yaml
=> Error from server (AlreadyExists): error when creating "01-simple-deploy.yaml": deployments.apps "my-deploy" already exists

# 만들어진 deploy 삭제
kubectl delete -f 01-simple-deploy.yaml

# 새로 생성
kubectl apply -f 01-simple-deploy.yaml
=> deployment.apps/my-deploy created

# 변경 사항 적용 (없으면 무시) 몇번을 반복해도 같은 결과만 나온다
kubectl apply -f 01-simple-deploy.yaml
=> deployment.apps/my-deploy configured

Log & Port forward

kubectl get 관련 커맨드는 아래와 같다.

Command	Description
kubectl get [kind명]	특정 종류의 리소스를 나열한다.
kubectl get [kind명] [resource-name]	특정 리소스를 조회한다.
kubectl get [kind명] --show-labels	라벨을 표시한다.
kubectl get [kind명] -l app=my-app	리소스를 쿼리한다.
kubectl get [kind명] -o yaml	출력형식을 yaml형식으로 지정한다.

Command	Description
kubectl describe [kind] [resource-name]	리소스 설명하기
kubectl delete [kind] [resource-name]	리소스 삭제하기
kubectl logs [kind]/[resource-name]	로그 확인
kubectl exec -it [kind]/[resource-name] – bash	파드 컨테이너에 접근
kubectl port-forward [kind]/[resource-name] 8080:80	포트포워딩 설정

Deployment revisions

deploy는 서비스의 버전을 관리할 수 있다. 아래 예시를 통해 확인해보자

# 02-deploy-rs.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  selector:
    matchLabels:
      app: order-service
  replicas: 3
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80

kubectl apply -f 02-deploy-rs.yaml

생성된걸 확인후 아래 파일처럼 변경해보자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  selector:
    matchLabels:
      app: order-service
  replicas: 2
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80

kubectl apply -f 02-deploy-rs.yaml

이렇게 진행하면 레플리카셋을 2개로 변경한다 컨테이너 스펙을 변경 해야 새로운 변경으로 감지 한다.
이제 v2로 변경해보자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  selector:
    matchLabels:
      app: order-service
  replicas: 2
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v2
          ports:
            - name: "app-port"
              containerPort: 80

# 적용
kubectl apply -f 02-deploy-rs.yaml

명령어를 치고 확인해보면 새로운 레플리카셋이 생기고 기존 레플리카셋의 ready 갯수는 0인걸 확인할 수 있다.

이번에는 환경변수를 변경해보자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  selector:
    matchLabels:
      app: order-service
  replicas: 2
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v2
          env:
            - name: DUMMY
              value: "8"
          ports:
            - name: "app-port"
              containerPort: 80

# 적용
 kubectl apply -f 02-deploy-rs.yaml

변경 사항을 적용해보면 또 새로운 레플리카 셋이 생길 수 있다.
이로 인해 알 수 있는 사실은 컨테이너 동작에 새로운 변경 사항이 생기면 레플리카셋을 새로 생성하지만 레플리카셋의 갯수만 변경하면 단순히 pod의 갯수만 변경되는걸 확인할 수있다.

Rollout history

새로운 파일을 생성한 후 적용하고 포트 포워딩을 설정해주자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  selector:
    matchLabels:
      app: order-service
  replicas: 2
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80

# 적용
kubectl apply -f 03-deploy-rollout.yaml
# 포트포워딩
kubectl port-forward deploy/order-service-deployment 8080:80

이제 localhost:8080으로 접속해보면 V1 화면이 나오는 걸 확인할 수 있다.

이제 v2 로 버젼을 바꿔서 진행해보자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  selector:
    matchLabels:
      app: order-service
  replicas: 2
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v2
          ports:
            - name: "app-port"
              containerPort: 80


kubectl apply -f 03-deploy-rollout.yaml
kubectl port-forward deploy/order-service-deployment 8080:80

이 후 다시 브라우저로 들어간 후 새로고칭하면 V2 화면이 나오는 것을 확인할 수 있다.

이제 터미널에서 아래 명령어를 입력한다.

kubectl rollout history deploy

그럼 2가지 수정본이 나오는것을 확인할 수 있다.

그럼 이제 containers의 버전을 3로 바꾸고 다시 적용해보자

        # 생략
          image: vinsdocker/k8s-app:v3
        # 생략

 kubectl apply -f 03-deploy-rollout.yaml

다시 kubectl rollout history deploy로 확인해보면 3개의 버전이 있는것을 확인할 수 있다.

이제 port-forward를 한 후 localhost:8080으로 접속하면 V3 화면이 뜨는것을 확인할 수 있다.

이제 롤백을 진행해보자

# 이전 버전으로 돌아간다.
kubectl rollout undo deploy/order-service-deployment

다시 port-forward를 한 후 localhost:8080으로 접속하면 V2 화면이 뜨는것을 확인할 수 있다.

다시 history를 확인해보자

kubectl rollout history deploy
# 결과
deployment.apps/order-service-deployment
REVISION  CHANGE-CAUSE
1         <none>
3         <none>
4         <none>

다시 같은 명령을 실행한다

kubectl rollout undo deploy/order-service-deployment

포트포워딩 적용 후 확인해보면 version3로 돌아간것을 확인할 수 있다.

Rollback

이전 정의는 그대로 두고 새로 v1 부터 시작한다
또한 annotations을 추가하자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
  annotations:
    kubernetes.io/change-cause: "deploying v1"
spec:
  selector:
    matchLabels:
      app: order-service
  replicas: 2
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80

이제 이전 deploy를 삭제하고 적용해보자

kubectl apply -f 03-deploy-rollout.yaml

다시 히스토리를 확인해보면 CHANGE-CAUSE가 바뀐것을 확인할 수 있다.

kubectl rollout history deploy

# 결과
REVISION  CHANGE-CAUSE
1         deploying v1

이제 위 작업에서 컨테이너를 v2 로 변경하고 annotaions도 v2로 변경 후 다시 확인하면 아래와 같다

kubectl rollout history deploy

# 결과
REVISION  CHANGE-CAUSE
1         deploying v1
2         deploying v2

이제 위 작업에서 컨테이너를 v3 로 변경하고 annotaions도 v3로 변경 후 적용하자

#결과
REVISION  CHANGE-CAUSE
1         deploying v1
2         deploying v2
3         deploying v3

이전 섹션에서 3인 상태에서 undo를 실행하면 v2로 가고 v2에서 undo를 실행하면 v3로 돌아갔다.
1로 돌아가보자

kubectl rollout undo deploy/order-service-deployment --to-revision=1

kubectl rollout history deploy

# 결과
REVISION  CHANGE-CAUSE
2         deploying v2
3         deploying v3
4         deploying v1

Checking Rollout Changes

간단한 정보만 보면 헷갈릴수 있다.
아래 명령어를 통해 자세히 알 수 있다.

kubectl rollout history deploy --revision=[번호]
ex) kubectl rollout history deploy --revision=4

#결과
deployment.apps/order-service-deployment with revision #4
Pod Template:
  Labels:       app=order-service
        pod-template-hash=56864789dc
  Annotations:  kubernetes.io/change-cause: deploying v1
  Containers:
   order-service-container:
    Image:      vinsdocker/k8s-app:v1
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>
  Node-Selectors:       <none>
  Tolerations:  <none>

Min ready Seconds (최소 준비 시간)

실제로 애플리케이션이 실행되는데는 시간이 걸린다.
이 때 실제로 걸리는 시간을 deploy yaml 파일에 정의해 둘 수 있다.
원래는 heath check, Probe등으로 확인하며 이 방법은 하드 코딩해서 알려주는 방법이다.

# 04-min-ready-seconds.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  minReadySeconds: 10
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx

kubectl apply -f 04-min-ready-seconds.yaml

적용후 watch로 확인해보면 deploy의 AVAILABLE이 10초 뒤에 활성화 되는것을 확인 할 수 있다.

배포 전략

만약 version1에서 version2를 배포하고 싶다고 할 때 변경사항을 어떻게 적용할건지를 정의한다.

전략	설명
recreate	기존 파드를 종료하고 새로운 파드를 생성합니다.
rolling update	변경 사항을 점진적으로 배포합니다. 기존 파드와 새로운 파드가 일시적으로 혼합될 수 있습니다. 아래 속성 들은 0 또는 %가 될 수 있다.
	속성	설명
	maxSurge	생성할 수 있는 추가 파드의 최대 수
	maxUnavailable	종료할 수 있는 파드의 최대 수

recreate 전략

# 05-deploy-recreate.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
  annotations:
    kubernetes.io/change-cause: "deploying v1"
spec:
  minReadySeconds: 10
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: order-service
  replicas: 2
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80
              
              
# 적용
kubectl apply -f 05-deploy-recreate.yaml

위 파일을 정의 한 후 실행한다.

이 후 아래 파일처럼 변경하고 다시 apply 해보자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  minReadySeconds: 10
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: order-service
  replicas: 3
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v2
          ports:
            - name: "app-port"
              containerPort: 80

# 적용
kubectl apply -f 05-deploy-recreate.yaml

확인해보면 먼저 존재하던 모든 파드들이 삭제되고 새로운 파드들이 새로 한번에 생기는걸 확인할 수 있다.

Rolling update - maxSurge

아래 파일을 생성 후 실행해보자

# 06-deploy-max-surge.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  minReadySeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: "100%"
  selector:
    matchLabels:
      app: order-service
  replicas: 3
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80


kubectl apply -f 06-deploy-max-surge.yaml

pod 3개가 켜진것을 확인할 수 있다.
이제 이미지를 v2로 바꿔보자

...
image: vinsdocker/k8s-app:v2
...

이후 실행을 해보면 순간적으로 파드가 6개가 되는것을 확인할 수 있다.

이제 v3를 maxSurge 1 로 변경한 후 적용해보자

...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
...
image: vinsdocker/k8s-app:v3
...

이제 결과를 살펴보면 하나씩 파드가 교체되는 과정을 확인할 수 있다.

Rolling update - maxUnavailable

파일을 생성하고 실행해보자

# 07-deploy-max-unavailable.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-deployment
spec:
  minReadySeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  selector:
    matchLabels:
      app: order-service
  replicas: 3
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service-container
          image: vinsdocker/k8s-app:v1
          ports:
            - name: "app-port"
              containerPort: 80


kubectl apply -f 07-deploy-max-unavailable.yaml

v2로 변경한 후 실행해보면 하나씩 변경되는것을 확인할 수 있다

[Kubernetes] ReplicaSet

얼은펭귄 — Thu, 12 Dec 2024 09:45:43 +0900

ReplicaSet은 Pod를 매니징한다.
예를 들어 nginx pod가 3개 있어야 한다고 하면 3개의 nginx pod를 유지한다.
replicaSet의 restartPolicy는 always이며 바꿀수 없다.

예를들어 아래 그림에서 노드2가 갑자기 죽었을때 pod의 개수를 유지하기 위해 다른 노드에 pod를 띄운다.
직접적으로 생성하는건 프로덕션 레벨에서는 권장되지 않으며 Deployment가 ReplicaSet을 관리한다.
이 글에서는 무엇을 관리해야하는지 명확히 하기 위해 metadata.labels를 사용한다

ReplicaSet 생성

주요 레퍼런스는 아래 링크에서 참고할 수 있다.
https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/replica-set-v1/

# 01-simple-rs.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-rs
spec:
  selector:
    # 맞는 레이블을 찾는다 (여러개가 가능하다)
    matchLabels:
      app: my-app
  # pod를 몇개로 유지할 것인지
  replicas: 3
  # pod의 개수가 맞지 않으면 기본적으로 실행할 pod의 내용
  template:
    metadata:
      name: my-pod
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx

kubectl get replicaset 명령어를 통해 replicaset을 가져올 수 있다(kubectl get rs로도 가능)
kubectl get all 명령어를 통해 감시하자

watch -t -x kubectl get all

이제 아래 명령어를 실행해보면 pod가 3개 실행되는걸 볼 수 있다.

kubectl create -f 01-simple-rs.yaml

이 때 템플릿 쪽의 metadata에 정의한대로 name이 생성되지 않는것을 알 수 있다.

...
template:
    metadata:
      name: my-pod
...

이제 하나를 삭제해보면 컨테이너가 삭제되고 즉시 다른 컨테이너가 확인되는걸 확인할 수있다.
또는 모든 컨테이너를 삭제해도 모든 컨테이너가 다시 실행되는걸 확인할 수 있다.

kubectl delete pod --all

마지막으로 아래 명령어를 통해 replicaSet을 삭제하면 replicaSet 과 replicaSet이 관리하는 모든 pod들이 사라진다.

kubectl delete -f 01-simple-rs.yaml

기존에 존재하는 pod와 replicaSet

이미존재하는 pod에 replicaSet을 적용해보자

# 02-multiple-pods.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  labels:
    team: team-a
spec:
  containers:
    - name: nginx
      image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  labels:
    team: team-a
spec:
  containers:
    - name: nginx
      image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-3
  labels:
    team: team-a
spec:
  containers:
    - name: nginx
      image: nginx

# 03-existing-pod-manager.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-rs
spec:
  selector:
    matchLabels:
      team: team-a
  replicas: 2
  template:
    metadata:
      labels:
        team: team-a
    spec:
      containers:
        - name: nginx
          image: nginx

위 두 파일을 생성한 후 02 번을 실행한다.

kubectl create -f 02-multiple-pods.yaml

이제 pod가 3개 생성되었다.
이제 03번을 적용해보자

kubectl create -f 03-existing-pod-manager.yaml

이제 파드를 확인해보면 하나가 종료되고 2개만 남아있는것을 확인할 수 있다.

추가로 남은 파드중 하나를 지워보면 03번에 정의된 my-rs이름으로 pod가 새로 생성되는걸 확인 할 수 있다.

 kubectl delete pod/pod-2

Multiple ReplicaSet

# 04-multiple-rs.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-rs-1
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 2
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx
---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-rs-2
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 2
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx

---을 기준으로 아래를 전부 주석처리 한 후 실행해보자.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-rs-1
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 2
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx
#---
#apiVersion: apps/v1
#kind: ReplicaSet
#metadata:
#  name: my-rs-2
#spec:
#  selector:
#    matchLabels:
#      app: my-app
#  replicas: 2
#  template:
#    metadata:
#      labels:
#        app: my-app
#    spec:
#      containers:
#        - name: nginx
#          image: nginx

kubectl create -f 04-multiple-rs.yaml

그럼 이제 rs-1의 replicaset은 실행되어 있는 상태이다.

이제 주석을 해제하고 다시 실행해보자

kubectl create -f 04-multiple-rs.yaml

그럼 my-rs-1은 이미 존재해서 에러가 나고 my-rs-2는 추가로 생성되는것을 확인할 수 있다.

Describing replicaset

아래 명령어를 통해 replicaset에 대한 세부 정보를 볼 수 있다.

kubectl describe rs/[rs이름]
ex) kubectl describe rs/my-rs-1

ReplicaSet Match Expressions

아래와 같이도 가능하다. 하지만 실제 production level에서는 간단하게 사용하기 때문에 가능하다고 알아만 두자.

spec:
  selector:
    matchLabels:
    - key: "team"
      operator: In
      values: ["team-a", "team-b"]

[Kubernetes] Pod 기초 - 2

얼은펭귄 — Fri, 6 Dec 2024 16:00:45 +0900

Pod args - Exec Form

args 를 사용하면 docker container에 인수를 전달할 수 있다.

06-pod-args.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
#      이 방법도 가능하고 아래 방법도 가능하다
#      args: ["date"]
      args:
      - "date"

Pod container logs

kubectl logs [파드 이름]
ex) kubectl logs my-pod

Pod args - shell form

docker 내부에 bash로 진입해서 shell 명령어를 실행하는 방법을 pod 정의 yaml 파일에서 정의한다.

07-pod-shell-args.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
      args:
      - "/bin/sh"
      - "-c"
      - "echo This is my path: $PATH"

이후 파드를 실행하고 로그를 확인해보면 yaml에 정의한 쉘 명령어가 실행된것을 확인할 수 있다.

Termination Grace Period

Pod의 종료 과정에서 kubelet이 컨테이너에게 종료 명령을 보내서 안전한 종료를 유도한다.
하지만 때로는 pod가 실제로 반응하지 않는 절전 모드에 들어갈 수 있다.
그래서 k8s는 기본적으로 30초동안 기다린 후 pod 를 삭제한다.
이 값을 변경할 수 있다.

08-pod-termination-garce-period.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
      args:
      - "sleep"
      - "3600"

해당 pod를 정의하고 실행후 삭제해보면 Status가 Terminating으로 변경되고
30초 후에 해당 pod가 삭제되는걸 확인할 수 있다.
이 때 terminationGracePeriodSeconds 를 사용해서 종료되는 시간을 변경할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  # 이 부분을 추가한다.
  terminationGracePeriodSeconds: 1
  containers:
    - name: ubuntu
      image: ubuntu
      args:
      - "sleep"
      - "3600"

이후 pod 를실행하고 삭제해보면
1초 후 바로 pod가 삭제되는걸 확인할 수 있다.

Pod command

docker의 entrypoint가 정의되어있으면 기존 args로 명령을 내려도 반응이 없다.

09-pod-command.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: entrypoint
      image: vinsdocker/k8s-entrypoint
      args:
        - "date"

해당 pod를 정의하고 실행해서 로그를 확인해보자

date 명령어가 제대로 실행되지 않은것을 확인할 수 있다.
command를 사용해서 명령어를 재정의할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: entrypoint
      image: vinsdocker/k8s-entrypoint
      command:
        - "date"

yaml 파일을 변경하고 다시 실행해서 로그를 확인해보면 재정의가 된 것을 확인할 수 있다.

Environment variable

pod yaml을 통해 생성하는 docker 컨테이너에 환경 변수를 전달하는 방법을 알아보자
몇가지 방법이 더 있지만 가장 기본적인 방법을 소개한다.
env를 통해서 전달할 수 있다.

10-pod-env.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: ubuntu
      image: ubuntu
      env:
        - name: "request.timeout"
          value: "10ms"
        - name: "spring.profiles.active"
          value: "dev"
      args:
        - "env"

이제 pod를 실행하고 로그를 확인해보면
정상적으로 환경 변수들이 전달된 것을 확인할 수 있다.

Exploring Pod Container

원격 클러스터에서 실행중인 Pod에 접근하는 방법을 설명한다.

기존에 생성했던 01 pod 를 실행 시키고 내부로 접근해보자

# 파드 실행
 kubectl create -f 01-simple-pod.yaml
# 파드 내부 컨테이너에 bash 쉘로 접속
 kubectl exec -it my-pod -- bash

내부 쉘로 접근 후 아래 명령어를 통해 내부 컨테이너에 접속한 것을 확인할 수 있다.

# 폴더 구조 보기
ls
# nginx container 이므로 curl 명령어를 통해 확인
curl localhost

가가기 위해선 exit를 입력하면 된다.

Multi Container Pod - 1

지금까지는 yaml 파일을 생성해서 하나의 컨테이너만 생성을 했다.
이 부분에서는 여러개의 컨테이너를 생성해보자

11-multi-containers.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx-1
      image: nginx
    - name: nginx-2
      image: nginx

이처럼 입력하고 실행 후 확인해보면 2개의 컨테이너중 하나만 실행되고 에러가 난다.

describe를 통해 확인 해보자
이미지를 가져오는건 성공을 했고, 컨테이너 옆에서 nginx-2를 실행하는데 실패해서 재시작을 하는 것을 확인할 수 있다.

이제 문제는 nginx-2에서 발생하는 점을 확인했고
logs를 확인해보면 컨테이너가 2개이기 때문에 기본으로 nginx-1의 로그만 주는것을 확인할 수 있다.

이제 nginx-2의 대해서 로그를 확인 해보자

 kubectl logs my-pod -c nginx-2

로그를 확인 해보면 이미 포트가 사용 중이기 때문에 에러가 나는것을 확인할 수 있다.

Multi Container Pod - 2

아래와 같이 변경한다

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx-1
      image: nginx
    - name: util
      image: vinsdocker/util

log를 확인해보면 util은 ubuntu 기반의 이미지 이기 때문에 실행이 완료되고 죽기 때문에 무한히 반복되는것을 확인할 수있다.

아래처럼 파일을 변경해보자

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  terminationGracePeriodSeconds: 1
  containers:
    - name: nginx-1
      image: nginx
    - name: util
      image: vinsdocker/util
      args:
        - "sleep"
        - "3600"

다시 확인을 해보면 정상적으로 2개의 컨테이너가 잘 실행되고 있는것을 확인할 수 있다.

pod로 접속해보면 기본적으로 nginx-1 로 접근되는것을 확인할 수 있다.

kubectl exec -it my-pod -- bash

# 접근 후 뜨는 log
Defaulted container "nginx-1" out of: nginx-1, util

아래 명령어를 통해 특정 컨테이너로 접근할 수 있다.

kubectl exec -it [pod name] -c [container name] -- bash
ex) kubectl exec -it my-pod -c util -- bash

이제 util 컨테이너로 접근 후 curl localhost를 입력하면 nginx에 접근하는것을 볼 수 있다.
실제로 한 pod 에서 2개의 컨테이너가 떠있지만 같은 pod 안에서는 네트워크를 공유하기 때문에 요청이 가능하다.

그래서 서로 다른 컨테이너에 접속해서 hostname 을 확인해보면 같은 호스트 name을 응답하는것을 확인할 수 있다.

요약

pod

K8S에서 배포 가능한 가장 작은 단위이다.
pod는 하나이상의 컨테이너로 실행할 수 있다.
- 오직 하나의 컨테이너만 어플리케이션 컨테이너여야 한다.
- 나머지 컨테이너는 도우미여야 한다. (sidecar container)
파드의 모든 컨테이너는 하나의 노드에서 실행된다. (파드 하나에서 여러개의 컨테이너를 실행한 경우 노드 하나에서 모두 실행된다.)
실제로는 직접 yaml 파일을 생성하지 않는다.
파드는 VM과 비슷하고 컨테이너들은 프로세스와 비슷하다.

Pod status

Pending: 노드가 아직 할당되지 않았음
ContainerCreating: kubelet이 컨테이너 생성중
Running: kubelet이 컨테이너를 시작함
ErrImagePull / ImagePullBackOff : 이미지 pull 실패. kubelet이 약간의 지연후 재시도함
Completed: 컨테이너가 성공적으로 종료됨
Error: 컨테이너가 오류와 함께 종료됨
CrashLoopBackOff: 컨테이너를 실행하는데 문제가 있음. kubelet이 지연후 재시도함 (이미지 풀링에 문제가 없을 때)
Terminating: pod 삭제중

Pod Container Restart policy

Never: Completed / Error 어떤 상황도 다시 시작하지 않음
Always: Completed / Error 어떤 상황에서도 다시 시작함
OnFailure: Error 인 경우에만 다시 시작함.

Kubectl Commands

kubectl get nodes: 클러스터의 모든 노드 확인
kubectl create -f [파일이름]: yaml파일을 기준으로 리소스 생성
kubectl delete -f [파일 이름]: yaml파일을 기준으로 리소스 삭제
kubectl get pod: 모든 파드 목록을 보여줌
kubectl get pod --show-lables: 파드의 레이블들을 보여줌
kubectl get pod -l [레이블 이름]=[레이블 값]: label을 기준으로 쿼리해서 파드를 보여줌
kubectl get pod -l [레이블 이름]!=[레이블 값]: label을 기준으로 쿼리해서 파드를 보여줌
kubectl get pod [파드 이름] -o yaml: 파드 정보를 yaml 형식으로 보여줌
kubectl describe pod [파드 이름]: 파드의 세부 정보를 보여줌
kubectl delete pod [파드 이름]: 파드 이름을 기준으로 파드 삭제
kubectl delete pod --all: 모든 파드 삭제
kubectl logs [파드 이름]: 파드의 log 확인
kubectl logs [파드 이름] -c [컨테이너 이름]: 파드의 여러개의 컨테이너중 특정 컨테이너 로그 확인
kubectl exec -it [파드이름] -c [컨테이너 이름] --bash: 파드의 컨테이너안에 쉘로 접속
kubectl port-forward [파드 이름] [호스트 포트]:[컨테이너 포트]: 디버깅을 위해 API 접속을 위해 사용

[Kubernetes] Pod 기초 - 1

얼은펭귄 — Wed, 27 Nov 2024 11:49:37 +0900

워크로드는 K8S 클러스트 위에서 동작하는 애플리케이션이다.
파드는 워크로드를 생성하는 기본 구성 요소이다.
배포가능한 가장 작은 단위이다.
파드는 하나 이상의 컨테이너를 실행할수 있다.
오직 하나의 컨테이너만 어플리케이션 컨테이너이고
나머지 컨테이너는 도우미이다.
파드는 VM을 제공하고 컨테이너는 프로세스를 제공한다.

간단한 파드 생성

K8S 요소 yaml format은 아래와 같다.

apiVersion: [api Version]
kind: [K8S의 워크로드 타입]
metadata:
    [리소스 이름, 추가 레이블]
spec:
    [워크로드 타입에 따라서 달라진다. 공식문서를 참고하자]

참고할 공식문서
https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/

실습

실습전 cluster 생성을 해야한다.

터미널을 따로 하나 킨 후 아래 명령어를 입력하자.
아래 명령어는 2초마다 kubectl get pod 명령어의 결과를 보여준다.

watch -t -x kubectl get pod

pod 정의

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx

pod 생성

kubectl create -f 01-simple-pod.yaml

pod 삭제

kubectl delete -f 01-simple-pod.yaml

다시 pod를 생성한 후
kubectl describe pod 명령어를 통해 세부 사항을 볼 수 있다.
문제가 발생했을때 디버깅을 위해 필요하며 가장 중요한 파트는 아래 Events 섹션이다

describe 예시

Events 섹션

Pod 업데이트 방법

pod가 정의된 yaml을 create 한 후 변경 사항이 생겼을때 다시 kubectl create 을 하면 이미 존재한다는 에러가 발생한다

이 때 변경사항 적용을 위한 명령어는 아래와 같다.

kubectl apply -f [yaml file]
ex) kubectl apply -f 01-simple-pod.yaml

Image Pull Backoff

만약 존재하지 않는 이미지를 가져오려고 하면 에러가 발생한다.
pod가 정의된 yaml파일을 아래와같이 변경해보자

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx:ftgsedzfcvzx

파드를 생성하고 상태를 확인하면 에러가 난것을 볼 수 있다.

Pod error

kubectl describe pod 명령어를 통해 이벤트 섹션을 살펴보면 자세하게 알 수 있다.
존재하지 않는 이미지를 가져오려고 해서 에러가 난 것을 확인 할 수 있다.

로그를 살펴보면 이미지를 가져오지 못해서 바로 작업을 삭제하는것이 아니라 반복해서 이미지를 가져오려고 한다.

describe

Crash loop Backoff

아래 파일을 정의한다.
아래 파일은 실패하는 docker 이미지 이다.
02-failing-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: failing-container
      image: vinsdocker/k8s-failing-container

kubectl create -f 02-failing-pod.yaml 명령어를 통해 파일을 실행시키고
kubectl get pod 명령어를 통해 확인해보면 Restarts가 점점 증가하는것을 확인할 수 있다.
그 후 Status가 CrashLoopBackOff 으로 변경된다.

이제 kubectl describe pod 로 이벤트를 확인해보자.

노드를 성공적으로 할당하고,
이미지를 성공적으로 가져온 후,
컨테이너가 실패한 후의 로그들이 담겨있다.
기본적으로 컨테이너를 다시 실행시킨다.

Pod status

Ready에서 1/1 의 앞은 현재 실행되고 있는 컨테이너 수, 뒤는 실제로 실행되어야 하는 컨테이너의 수이다.

Running

Error

Pending	노드가 아직 할당되지 않았음
ContainerCreating	kubelet이 컨테이너 생성중
Running	kubelet이 컨테이너를 시작함
ErrImagePull / ImagePullBackOff	이미지 pull 실패. kubelet이 약간의 지연후 재시도함
Completed	컨테이너가 성공적으로 종료됨
Error	컨테이너가 오류와 함께 종료됨
CrashLoopBackOff	컨테이너 실행에 문제가 있음. kubelet이 지연후 재시도 (이미지 pull에 문제가 없을 때)
Terminating	pod 삭제중

Pod labels

한 파일로 여러개의 Pod를 정의하는 방법이다

label은 키와 값의 쌍이다. 원하는 값을 정의할 수 있다.
03-multiple-pods.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  labels:
    dept: dept-1
    team: team-a
spec:
  containers:
    - name: nginx
      image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  labels:
    dept: dept-1
    team: team-b
spec:
  containers:
    - name: nginx
      image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-3
  labels:
    dept: dept-2
    team: team-a
spec:
  containers:
    - name: nginx
      image: nginx

pod 생성

kubectl create -f 03-multiple-pods.yaml

pod 확인

kubectl describe pod 을 사용하면 모든 파드를 가져온다
아래 명령어를 사용하면 단일 pod에 대한 정보만 가져올 수 있다.

kubectl get pod [파드이름]
ex) kubectl get pod pod-1
kubectl describe pod [파드이름]
ex) kubectl describe pod pod-1

label확인

아래 명령어를 사용하면 모든 파드의 label을 가져올 수 있다.

kubectl get pod --show-labels

# 결과 예시
NAME    READY   STATUS    RESTARTS   AGE     LABELS
pod-1   1/1     Running   0          3m16s   dept=dept-1,team=team-a
pod-2   1/1     Running   0          3m16s   dept=dept-1,team=team-b
pod-3   1/1     Running   0          3m16s   dept=dept-2,team=team-a

파드의 레이블을 검색할 수 있다.

# label의 team이 team-a 인 pod만
kubectl get pod -l team=team-a

# 결과
NAME    READY   STATUS    RESTARTS   AGE
pod-1   1/1     Running   0          6m6s
pod-3   1/1     Running   0          6m6s

-------------------------------------------------------

# label의 team이 team-a 가 아닌 pod만
kubectl get pod -l team!=team-a

# 결과
NAME    READY   STATUS    RESTARTS   AGE
pod-2   1/1     Running   0          5m41s

-------------------------------------------------------

# label이 dept는 dept-1 이고 team은 team-a인 pod만
kubectl get pod -l dept=dept-1,team=team-a

# 결과
NAME    READY   STATUS    RESTARTS   AGE
pod-1   1/1     Running   0          7m22s

Formatting output

pod에 대한 정보를 좀 더 자세하게 제공한다.

kubectl get pod -o wide

# 결과
NAME    READY   STATUS    RESTARTS   AGE   IP           NODE                  NOMINATED NODE   READINESS GATES
pod-1   1/1     Running   0          20h   10.244.1.7   dev-cluster-worker    <none>           <none>
pod-2   1/1     Running   0          20h   10.244.2.5   dev-cluster-worker2   <none>           <none>
pod-3   1/1     Running   0          20h   10.244.1.8   dev-cluster-worker    <none>           <none>

yaml 형식 출력으로 볼수 있는 명령어는 아래와 같다.

kubectl get pod [pod이름] -o yaml
ex) kubectl get pod pod-1 -o yaml

Deleteing a pod

여러개의 파드를 생성하고 특정 파드만 지우고 싶은 상황이 있을 수 있다.

# pod 생성
kubectl create -f 03-multiple-pods.yaml
# pod-2 삭제
kubectl delete pod pod-2
# pod-3 삭제
kubectl delete pod/pod-3

Port Forward

쿠버네티스 클러스터의 node들은 네트워크를 통해 서로 연결이 되어있다. (노드 네트워킹)
node 컨테이너들은 자체 IP 주소가 있다.
쿠버네티스 API 서버에서 받는 요청을 컨테이너로 넘기기 위해서는 컨테이너의 포트를 열어 주어야 한다.

아래와 같은 yaml 파일 정의를 통해 port를 노출할 수 있다.

04-pod-port.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
      - name: "web-port"
        containerPort: 80

pod를 실행 시킨 이후 아래 명령어를 통해서 포트를 매핑한다.

kubectl port-forward [파드이름] [K8S 포트번호]:[docker port 번호]
ex) kubectl port-forward my-pod 8080:80

http://localhost:8080/ 으로 접속하면 nginx 화면을 확인할 수 있다.
이러한 방법은 디버깅에 유용하다

Restart policy

pod의 재시작 정책에 대해서 서술한다.

05-restart-policy.yaml 을 정의한다.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu

pod를 실행하면 실행해야 할 작업이 없기 때문에 성공적으로 작업이 종료되고 영원히 재시작을 반복한다.

kubectl get pod -o yaml 명령어를 통해 확인해보면 restartPolicy가 Always로 정의가 된것을 확인할 수있다.
pod spec에 정의가 되어있지 않으면 default이기 때문이다

yaml 파일을 아래와 같이 수정한다.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never # Always, Never(다시 시작하지 않음), OnFailure (실패했을 때만)
  containers:
    - name: ubuntu
      image: ubuntu

이제 다시 Pod 를 실행해보면 Status가 Completed 상태로 종료되고 restart가 이루어지지 않는것을 확인할 수 있다.

[Kubernetes] Cluster 학습

얼은펭귄 — Tue, 19 Nov 2024 14:28:29 +0900

클러스터는 네트워크에 연결된 물리적 or 가상 머신의 집합이며, 클러스터는 마스터와 노드로 구성된다.
일반적으로 프로덕션 환경의 경우 하나 이상의 마스터가 존재한다.

Master

마스터의 컴포넌트는 api-server, stcd, controller-manager, scheduler로 구성된다.
api-server: 클라이언트가 클러스터와 대화하고 워크로드를 생성할 수 있는 API-서버
etcd (et-c-d): 클러스터 데이터를 저장할 분산 키 값 저장소
controller-manager: 워크로드/노드 등을 지속적으로 모니터링하는 프로세스
scheduler: 워크로드 스케줄러

Node

노드의 컴포넌트는 kubelet, container runtime (docker), kube-proxy 로 구성된다.
kubelet: 컨테이너를 만들고 모니터링하는 에이전트
container runtime (docker): 컨테이너를 만들기 위해 컨테이너 런타임이 깔려있어야 한다. (docker)
kube-proxy: 클러스터 내 워크로드 간의 통신을 위해 노드의 네트워크 규칙을 유지

kubectl 설치

예시는 linux이다.

link: https://kubernetes.io/ko/docs/tasks/tools/install-kubectl-linux/

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

설치 확인

kubectl version --client --output=yaml

kind 설치

이 글에서는 kind를 사용해서 학습을 진행한다.

link: https://kind.sigs.k8s.io/docs/user/quick-start/

# For AMD64 / x86_64
[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.25.0/kind-linux-amd64
# For ARM64
[ $(uname -m) = aarch64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.25.0/kind-linux-arm64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

설치 확인

kind version

클러스터 생성

1. kind cluster 구성 파일 01-cluster.yaml 을 만든다.

# three node (two workers) cluster config
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: dev-cluster
nodes:
- role: control-plane
- role: worker
- role: worker

2. 클러스터 생성

kind create cluster --config 01-cluster.yaml

결과

3. 확인

docker ps -a

4. cat ~/.kube/config 를 쳐보면 구성파일을 확인해볼수 있다. server 를 보면 열려있는 포트를 확인할 수 있다.

5. kubectl version --client --output=yaml 명령어를 통해 서버의 version도 확인할 수 있다.

6. 노드 확인

kubectl get nodes

# 결과
NAME                        STATUS   ROLES           AGE    VERSION
dev-cluster-control-plane   Ready    control-plane   118m   v1.31.2
dev-cluster-worker          Ready    <none>          118m   v1.31.2
dev-cluster-worker2         Ready    <none>          118m   v1.31.2

클러스터 내부 확인

Master 확인

1. 마스터에 shell로 접속한다

docker exec -it [마스터 컴포넌트ID] /bin/bash

2. 설정 파일들이 저장되어 있는 곳으로 이동한다.

cd /etc/kubernetes/manifests/

3. yaml들이 있는걸 확인 할 수 있다.

ls -al

4. 이 yaml file들은 실제로 실행되고 있는 프로세스이다.

ps -aux

Node 확인

1. node에 shell로 접속한다.

docker exec -it [node 컴포넌트ID] /bin/bash

2. 마찬가지로 프로세스를 확인해보면 node에서 사용하는 프로세스들이 돌고 있는것을 확인할수 있다.

학습이 끝나면 자원확보를 위해 클러스터를 삭제해주자

kind delete cluster --name [클러스터 이름]

프로토콜 버퍼(protobuf)란?

얼은펭귄 — Fri, 8 Nov 2024 13:13:14 +0900

1. 소개

현대 애플리케이션에서 데이터 직렬화의 중요성

오늘날의 소프트웨어 개발에서는 다양한 시스템과 애플리케이션 간에 데이터를 효율적으로 교환하는 것이 매우 중요합니다. 특히 마이크로서비스 아키텍처의 확산과 모바일 및 IoT 기기의 증가로 인해 네트워크 상에서 주고받는 데이터의 양과 빈도가 폭발적으로 늘어나고 있습니다.

기존 직렬화 방식의 한계

전통적으로 데이터 교환에는 JSON이나 XML과 같은 텍스트 기반의 포맷이 많이 사용되어 왔습니다. 이러한 포맷은 사람이 읽기 쉽고 이해하기 편리하다는 장점이 있지만, 데이터 크기가 크고 파싱 속도가 느리며, 데이터 타입에 대한 명확한 정의가 부족하다는 단점이 있습니다.

프로토콜 버퍼의 등장 배경

구글은 내부 시스템에서 대용량의 데이터를 효율적으로 처리하기 위해 보다 빠르고 가벼운 직렬화 포맷이 필요했습니다. 그 결과로 개발된 것이 바로 프로토콜 버퍼(Protobuf)입니다. Protobuf는 바이너리 포맷을 사용하여 데이터 크기를 줄이고, 엄격한 스키마를 통해 데이터 무결성을 보장하며, 다양한 언어와 플랫폼에서 사용 가능하도록 설계되었습니다

2. Protobuf란 무엇인가?

정의 및 개념

프로토콜 버퍼(Protobuf)는 구글에서 개발한 언어 중립적, 플랫폼 중립적, 확장 가능한 직렬화 메커니즘입니다. 구조화된 데이터를 바이너리 형태로 직렬화하고 역직렬화하는 데 사용되며, 이는 데이터 전송과 저장을 효율적으로 만듭니다.

역사와 개발 배경

구글은 2001년부터 내부적으로 Protobuf를 사용해 왔으며, 2008년에 오픈 소스로 공개하였습니다. 그 이후로 많은 기업과 개발자들이 Protobuf를 채택하여 사용하고 있으며, 이는 효율성과 확장성 측면에서 큰 장점을 제공하기 때문입니다.

3. 왜 Protobuf를 사용해야 하는가?

성능 비교: Protobuf vs. JSON vs. XML

데이터 크기: Protobuf는 바이너리 포맷을 사용하므로 JSON이나 XML보다 데이터 크기가 훨씬 작습니다.
전송 속도: 데이터 크기가 작기 때문에 네트워크를 통한 전송 속도가 빠릅니다.
파싱 속도: 바이너리 포맷은 파싱이 빠르며, 이는 애플리케이션의 응답 시간을 개선합니다.

데이터 크기와 전송 속도

예를 들어, 동일한 데이터를 Protobuf와 JSON으로 직렬화했을 때 Protobuf는 JSON 대비 최대 10배까지 작은 크기를 가질 수 있습니다. 이는 특히 모바일 네트워크나 제한된 대역폭 환경에서 큰 이점을 제공합니다.

확장성과 호환성
Protobuf는 스키마를 사용하여 데이터 구조를 정의하기 때문에 새로운 필드를 추가하거나 기존 필드를 변경하더라도 하위 호환성을 유지할 수 있습니다. 이는 시스템 간의 통합과 업데이트를 용이하게 만듭니다.

4. Protobuf의 작동 원리

스키마 정의(.proto 파일)

Protobuf는 .proto 파일에서 데이터 구조를 정의합니다. 이 파일에서는 메시지 타입, 필드, 데이터 타입 등을 명시적으로 지정합니다.

프로토콜 컴파일러의 역할

프로토콜 컴파일러(protoc)는 .proto 파일을 읽고, 지정된 언어(Java, C++, Python 등)의 코드로 컴파일합니다. 이 코드는 직렬화 및 역직렬화 메서드를 포함하고 있습니다.

직렬화 및 역직렬화 과정

직렬화: 애플리케이션에서 생성된 객체를 Protobuf 메시지로 변환하고, 이를 바이너리 형태로 직렬화합니다.
역직렬화: 받은 바이너리 데이터를 Protobuf 메시지로 역직렬화하고, 이를 애플리케이션에서 사용할 수 있는 객체로 변환합니다.

5. Protobuf 메시지 정의하기

기본 문법과 규칙

.proto 파일은 특정한 문법을 따릅니다. 가장 먼저 Protobuf 버전을 지정해야 하며, 그 다음 메시지와 필드를 정의합니다.

syntax = "proto3";

message MessageName {
// 필드 정의
}

데이터 타입과 필드 번호의 중요성

각 필드는 데이터 타입, 이름, 태그 번호를 가집니다.

데이터 타입: int32, string, bool 등 다양한 기본 타입과 사용자 정의 메시지를 사용할 수 있습니다.
태그 번호: 각 필드는 고유한 태그 번호를 가지며, 이는 바이너리 포맷에서 필드를 식별하는 데 사용됩니다.

message User {
	int32 id = 1;
	string name = 2;
	string email = 3;
}

옵션 필드와 반복 필드

옵션 필드: 필드가 필수적이지 않으며, 값이 없을 수 있습니다.
반복 필드: 동일한 타입의 필드가 여러 개 있을 수 있으며, 이는 리스트로 취급됩니다.

message Group {
	repeated User members = 1;
   	optional string str_field = 2;
}

6. 프로토콜 컴파일러 사용하기

설치 및 설정 방법

프로토콜 컴파일러는 공식 홈페이지나 패키지 매니저를 통해 설치할 수 있습니다.

공식 홈페이지: https://grpc.io/docs/protoc-installation/

ex)
MacOS: brew install protobuf
Ubuntu: sudo apt-get install protobuf-compiler

다양한 언어로 코드 생성하기

.proto 파일을 컴파일하여 원하는 언어의 코드를 생성합니다.

7. 장점과 단점

Protobuf의 강점

효율성: 작은 데이터 크기와 빠른 직렬화/역직렬화 속도
엄격한 스키마: 데이터 구조의 명확한 정의로 인한 무결성 보장
다양한 언어 지원: 다수의 프로그래밍 언어에서 사용 가능
확장성: 필드 추가 및 변경에 대한 유연한 대처

고려해야 할 단점

가독성 부족: 바이너리 포맷이므로 디버깅이나 로깅 시 어려움
스키마 필요: 모든 통신 주체가 동일한 스키마를 공유해야 함
학습 곡선: 새로운 도구와 개념에 대한 학습 필요

사용 시 주의사항

스키마 관리에 신경 써야 하며, 버전 관리를 철저히 해야 합니다.
보안 측면에서 데이터 암호화나 인증을 추가로 고려해야 합니다.

8. 결론

Protobuf의 미래와 전망

프로토콜 버퍼는 고성능의 데이터 직렬화가 필요한 다양한 분야에서 널리 사용되고 있습니다. 특히 마이크로서비스, 모바일 앱, IoT 등 네트워크 효율이 중요한 영역에서 그 가치는 더욱 부각되고 있습니다.

최종 요약 및 추천

Protobuf는 데이터 전송의 효율성을 극대화하고, 시스템 간의 호환성과 확장성을 제공하는 강력한 도구입니다. 기존의 JSON이나 XML 기반의 통신에서 성능 이슈를 겪고 있다면, Protobuf를 도입하여 개선해 볼 것을 추천합니다.

[AI] ONNX란

얼은펭귄 — Tue, 5 Nov 2024 14:31:13 +0900

ONNX (Open Neural Network Exchange)는 다양한 딥러닝 및 머신러닝 프레임워크 간의 모델 호환성을 보장하는 오픈 소스 표준 형식입니다.
Microsoft와 Facebook이 주도하여 개발한 ONNX는 PyTorch, TensorFlow, scikit-learn 등에서 학습된 모델을 변환해, 다른 프레임워크나 하드웨어에서 효율적인 추론을 수행할 수 있도록 합니다.

ONNX의 필요성과 장점

1. 모델 호환성

ONNX는 다양한 프레임워크 간의 모델 변환을 간소화합니다. 예를 들어, PyTorch로 학습한 모델을 TensorFlow에서 실행하거나, ONNX Runtime을 통해 추론 성능을 가속화할 수 있습니다.

2. 고성능 추론

ONNX Runtime은 GPU, CPU뿐만 아니라 FPGA, TPU와 같은 다양한 하드웨어를 지원해, 효율적인 추론을 수행할 수 있도록 최적화됩니다.

3. 모델 배포의 유연성

ONNX는 클라우드 및 엣지 환경 모두에서 효율적인 AI 모델 배포를 지원하며, 메모리와 연산 성능이 제한된 장치에서도 유용합니다.

4. ONNX의 한계와 고려사항

최신 연산자 지원: ONNX는 프레임워크마다 **다른 연산자(operator)**를 지원하는데, 일부 최신 모델이나 복잡한 연산은 ONNX로 변환할 때 문제가 발생할 수 있습니다. 이러한 경우 모델의 호환성을 확인하고, 필요 시 맞춤형 최적화가 필요합니다
학습 작업 한계: ONNX는 주로 추론 작업에 최적화되어 있으며, 학습 작업에서는 제한적입니다. 따라서 추론 중심의 워크플로에 적합합니다

5. 결론

ONNX는 AI 모델의 호환성과 최적화를 지원하는 강력한 도구로, 다양한 프레임워크와 하드웨어에서 모델의 효율적인 배포와 추론 성능 향상을 가능하게 합니다.
이를 통해 모델 개발과 배포의 복잡성을 줄이고, 엣지 컴퓨팅 환경에서도 효율적으로 사용할 수 있습니다. ONNX는 특히 추론 작업의 최적화에 강점을 가지며, 다양한 플랫폼에서 일관된 성능을 제공하는 표준 형식으로 자리잡고 있습니다.

[Linux] E: Unable to locate package ~~

얼은펭귄 — Mon, 4 Nov 2024 17:29:41 +0900

파이썬 도커를 실행시키고 vim 패키지 설치중 아래와 같은 에러가 발생했다.
해결해보자.
unable to locate package vim

apt 패키지 관리자가 vim 패키지를 찾을 수 없어서 발생하는 문제이다.
패키지 목록을 업데이트하고 설치하면 해결된다.

1. 패키지 목록 업데이트

apt-get update

2. 패키지 설치

apt-get install vim

[Linux] ubuntu에서 Swap 메모리를 활용한 메모리 부족 문제 해결

얼은펭귄 — Mon, 4 Nov 2024 16:26:45 +0900

모델 변환 작업 진행중 서버 메모리가 부족해서 프로세스가 강제로 죽는 현상이 생겼습니다.
이를 해결하기 위해 진행했던 작업 및 공부 정리입니다.

Linux 서버나 시스템을 사용하다 보면, 메모리가 부족해지는 경우가 발생할 수 있습니다.
이러한 상황에서 성능 저하를 방지하거나 시스템이 멈추지 않도록 스왑(Swap) 메모리를 추가하는 것이 효과적인 해결 방법입니다.
이 글에서는 Swap 메모리의 개념과 설정 방법을 소개하고, 부족한 메모리를 관리하는 최적의 방안을 설명합니다.

Swap 메모리란?

스왑 메모리는 물리적인 RAM이 부족할 때 디스크 공간을 일시적인 가상 메모리로 사용하는 기능입니다.
메모리가 부족한 경우, 사용하지 않는 데이터를 RAM에서 스왑 공간으로 옮기고 필요한 프로세스를 실행하는 데 메모리를 할당합니다.
하지만 스왑 메모리는 디스크를 사용하기 때문에 속도가 느리다는 단점이 있다.
그럼에도 불구하고, 메모리 부족으로 인한 시스템 크래시나 성능 저하를 방지하는 중요한 역할을 한다.

# 현재 메모리 확인
free -h

메모리 정보

스왑 메모리 설정 방법

1. Swap 파일 생성하기

먼저, 스왑 파일을 생성하여 사용할 디스크 공간을 확보합니다. 아래 명령어를 통해 4GB 크기의 스왑 파일을 생성합니다.

sudo fallocate -l 4G /swapfile

fallocate 명령어는 빠르게 빈 파일을 생성합니다.
/swapfile 경로는 스왑 파일의 위치를 나타내며, 원하는 이름과 경로로 변경할 수 있습니다.

2. Swap 파일 권한 설정

보안 문제를 방지하기 위해 스왑 파일의 권한을 600으로 설정합니다. 이는 오직 관리자(root)만이 이 파일에 접근할 수 있도록 제한합니다.

sudo chmod 600 /swapfile

3. Swap 파일 초기화 및 활성화

이제 스왑 파일을 스왑 영역으로 사용하기 위해 초기화합니다.

sudo mkswap /swapfile

그 후, 스왑 메모리를 활성화합니다.

sudo swapon /swapfile

4. 스왑 메모리 확인

스왑 메모리가 제대로 활성화되었는지 확인하려면 다음 명령어를 사용합니다.

swapon --show

이 명령어는 현재 활성화된 스왑 영역의 정보를 보여줍니다.
free -h 로 스왑 메모리가 늘어난걸 확인할 수도 있습니다.

5. 부팅 시 스왑 메모리 자동 활성화

재부팅 후에도 스왑 메모리가 유지되도록 /etc/fstab 파일에 스왑 파일을 추가합니다. 다음 명령어로 파일을 열어 편집합니다.

sudo vim /etc/fstab

파일의 맨 아래에 다음 내용을 추가합니다.

/swapfile none swap sw 0 0

이제 저장하고 나가면 시스템이 재부팅될 때 자동으로 스왑 메모리를 활성화합니다.
재부팅 후 다시
free -h 로 확인 할 수 있습니다.

추가적인 메모리 최적화 방법

불필요한 프로세스 종료: 메모리를 많이 사용하는 프로세스를 확인하고 종료합니다.
캐시 정리: 디스크 캐시가 메모리를 차지하는 경우, 다음 명령어로 캐시를 정리할 수 있습니다.

sudo sync; sudo sysctl -w vm.drop_caches=3

메모리 업그레이드: 물리적인 RAM을 추가하는 것이 근본적인 해결책이 될 수 있습니다.

마무리

Linux 환경에서 메모리 부족 문제를 해결하는 데 있어 스왑 메모리 추가는 유용한 방법입니다.
스왑 파일을 생성하고 설정하는 과정은 간단하며, 시스템의 안정성을 높이는 데 큰 도움을 줍니다.
다만, 스왑 메모리는 속도가 느리기 때문에 RAM을 대체할 수는 없으며, 물리적인 메모리 추가도 함께 고려하는 것이 좋습니다.
스왑 메모리 설정은 메모리 부족 상황에서 중요한 역할을 하므로, 필요에 따라 적절히 설정하고 관리하는 습관을 가지는 것이 좋습니다.

추가) swap 메모리를 과도하게 사용하면 안되는 이유
https://systorage.tistory.com/entry/OS-%EA%B0%80%EC%83%81-%EB%A9%94%EB%AA%A8%EB%A6%ACswap-%EC%82%AC%EC%9A%A9-%EC%8B%9C-CPU-%EC%A0%90%EC%9C%A0%EC%9C%A8%EC%9D%B4-%ED%8F%AD%EC%A6%9D%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0

[OS] 가상 메모리(swap) 사용 시 CPU 점유율이 폭증하는 이유

연구팀을 위해 데이터를 뽑는 도중 큰 데이터를 뽑다가 서버를 터트렸다. 해당 원인에 대해서 공부했던 내용에 대해서 서술한다. 가상 메모리(swap)란? 가상 메모리는 물리적인 RAM이 부족할 때 디

systorage.tistory.com

[MSA] MSA란? MSA의 장 / 단점

얼은펭귄 — Sat, 12 Oct 2024 14:16:12 +0900

마이크로서비스 아키텍처(Microservice Architecture, MSA)

마이크로서비스 아키텍처(MSA)는 소프트웨어 시스템을 작은 독립적인 서비스로 분리하여 각 서비스가 독립적으로 개발, 배포, 확장 및 관리되도록 설계된 아키텍처입니다. 각 마이크로서비스는 특정 도메인이나 비즈니스 기능을 담당하며, 다른 서비스와는 API나 메시지 큐를 통해 통신합니다.

전통적인 모놀리식 아키텍처에서 모든 기능이 하나의 큰 시스템에 포함되는 것과 달리, MSA는 각 기능을 독립된 단위로 나누어 시스템의 유연성과 확장성을 극대화하는 데 초점을 둡니다.

MSA의 주요 특징

독립성: 각 마이크로서비스는 독립적으로 개발, 배포, 그리고 확장이 가능하며, 다른 서비스에 영향을 주지 않고 업데이트할 수 있습니다.
분산 시스템: 마이크로서비스는 분산 시스템의 형태를 띄고 있으며, 서비스 간 통신은 주로 REST API, gRPC, 메시지 큐 등을 통해 이루어집니다.
다양한 기술 스택: 각 마이크로서비스는 개별적으로 선택된 프로그래밍 언어, 데이터베이스, 프레임워크를 사용할 수 있어, 각 서비스에 최적화된 기술을 선택할 수 있습니다.
작은 규모: 마이크로서비스는 각각 작은 단위로 나뉘어 있으며, 하나의 서비스가 특정 기능만을 담당하는 구조입니다. 이는 코드베이스가 작아져 유지보수가 용이해집니다.

장점:

독립적 배포: 각 서비스가 독립적으로 배포 및 확장이 가능하여 빠른 개발과 배포가 가능합니다.
유연성: 다양한 기술 스택을 사용하여 각 서비스에 최적화된 기술을 선택할 수 있습니다.
탄력성: 한 서비스의 장애가 전체 시스템에 영향을 미치지 않도록 격리할 수 있습니다.

단점:

복잡성 증가: 서비스 간 통신, 데이터 일관성 유지 등이 복잡해질 수 있습니다.
배포 및 관리 어려움: 다수의 서비스가 존재하기 때문에 배포, 모니터링, 로깅 등이 어려워질 수 있습니다.
네트워크 지연: 서비스 간 통신이 네트워크를 통해 이루어지므로 지연이 발생할 수 있습니다.

Typescript Omit과 Partial 의 차이점

얼은펭귄 — Thu, 8 Aug 2024 17:14:35 +0900

TypeScript는 정적 타입을 지원하여 코드의 안정성과 유지보수성을 높이는 데 도움을 줍니다. 이 중에서도 Omit과 Partial은 매우 유용한 유틸리티 타입으로, 각각 객체 타입을 변형하는 데 사용됩니다. 이번 글에서는 Omit과 Partial의 차이점을 자세히 설명하겠습니다.

Partial<T>

Partial 유틸리티 타입은 주어진 타입 T의 모든 프로퍼티를 선택적으로 만듭니다. 즉, 모든 프로퍼티가 있어도 되고 없어도 되는 상태가 됩니다.

사용 예시

interface User {
    id: number;
    name: string;
    email: string;
}

type PartialUser = Partial<User>;

const user1: PartialUser = {};
const user2: PartialUser = { id: 1 };
const user3: PartialUser = { name: 'Alice', email: 'alice@example.com' };

특징

모든 프로퍼티가 선택적(Optional)으로 변환됩니다.
주로 객체의 일부 프로퍼티만 업데이트할 때 유용합니다.

Omit<T, K>

Omit 유틸리티 타입은 주어진 타입 T에서 특정 프로퍼티 K를 제거한 새로운 타입을 만듭니다.

사용 예시:

interface User {
    id: number;
    name: string;
    email: string;
}

type UserWithoutEmail = Omit<User, 'email'>;

const user: UserWithoutEmail = { id: 1, name: 'Alice' };

특징

주어진 타입에서 특정 프로퍼티를 제거하여 새로운 타입을 만듭니다.
주로 특정 프로퍼티를 제외한 나머지 프로퍼티만 필요할 때 유용합니다.

차이점 정리

변형 방식:
- Partial<T>: 모든 프로퍼티를 선택적으로 만듭니다.
- Omit<T, K>: 특정 프로퍼티를 제거하여 새로운 타입을 만듭니다.
사용 목적:
- Partial<T>: 객체의 일부만 업데이트하거나, 선택적인 프로퍼티를 가질 때 사용합니다.
- Omit<T, K>: 불필요한 프로퍼티를 제거하고 필요한 프로퍼티만 가지는 타입을 만들 때 사용합니다.
예시 적용 상황:
- Partial<T>: API 요청에서 선택적인 업데이트 데이터를 보낼 때.
- Omit<T, K>: 데이터베이스 엔터티에서 민감한 정보를 제외한 데이터를 반환할 때.

결론

Partial과 Omit은 TypeScript에서 객체 타입을 변형하는 데 매우 유용한 도구입니다. Partial은 모든 프로퍼티를 선택적으로 만들어 부분 업데이트나 선택적 프로퍼티를 다룰 때 유용하고, Omit은 특정 프로퍼티를 제거하여 필요한 데이터만 다룰 때 유용합니다. 각 유틸리티 타입의 특징과 사용 목적을 잘 이해하고 적절하게 활용하면 더욱 안정적이고 유지보수하기 쉬운 코드를 작성할 수 있습니다.

마이크로서비스 아키텍처(MSA)에서 모듈 간 통신 방법

얼은펭귄 — Thu, 8 Aug 2024 17:08:16 +0900

마이크로서비스 아키텍처(MSA)는 각각의 독립적인 서비스들이 서로 협력하여 전체 시스템을 구성하는 구조입니다. 이러한 서비스들 간의 통신은 MSA의 핵심 요소 중 하나이며, 이를 효율적으로 설계하는 것이 중요합니다. 이번 블로그 글에서는 MSA에서 각 모듈 간 통신 방법에 대해 자세히 설명하겠습니다.

1. 동기 통신 (Synchronous Communication)

1.1 HTTP/REST

가장 일반적인 통신 방법으로, RESTful API를 사용하여 서비스 간 HTTP 요청과 응답을 주고받습니다.

장점: 간단하고 이해하기 쉬움, 웹 표준 사용

단점: 높은 레이턴시, 네트워크 장애 시 서비스 중단 가능성

HTTP/REST는 대부분의 웹 애플리케이션에서 사용되는 방식으로, 서비스 간의 데이터를 주고받는 데 있어 가장 직관적이고 널리 사용됩니다. 특히 JSON 포맷을 주로 사용하여 데이터를 직렬화하며, 다양한 언어와 프레임워크에서 쉽게 구현할 수 있습니다.

1.2 gRPC

구글이 개발한 고성능 RPC 프레임워크로, HTTP/2를 사용하여 통신합니다.

장점: 성능이 좋고, 양방향 스트리밍 가능, 프로토콜 버퍼 사용으로 데이터 직렬화 효율성 높음

단점: 설정이 복잡하고, REST에 비해 상대적으로 덜 친숙함

gRPC는 서비스 간 통신에서 높은 성능과 효율성을 제공합니다. 특히, 큰 데이터 세트와 빈번한 호출이 필요한 경우 유리합니다. 또한, 프로토콜 버퍼(Protocol Buffers)를 사용하여 직렬화 효율성을 극대화합니다.

2. 비동기 통신 (Asynchronous Communication)

2.1 메시지 큐 (Message Queue)

RabbitMQ, Apache Kafka와 같은 메시지 큐 시스템을 사용하여 서비스 간 비동기적으로 메시지를 전달합니다.

장점: 높은 확장성, 비동기적 처리로 인해 서비스 독립성 향상, 메시지 손실 방지

단점: 복잡한 설정과 운영 관리, 메시지 지연 발생 가능성

메시지 큐를 사용하면 서비스 간의 강한 결합을 피하고, 각 서비스가 독립적으로 동작할 수 있습니다. 이는 서비스 장애가 다른 서비스에 영향을 미치지 않도록 하며, 높은 트래픽 상황에서도 안정적인 처리를 보장합니다.

2.2 이벤트 스트리밍 (Event Streaming)

Apache Kafka, Amazon Kinesis와 같은 시스템을 사용하여 이벤트 기반으로 데이터 스트림을 처리합니다.

장점: 실시간 데이터 처리, 높은 처리량, 데이터 복구 및 재처리 용이

단점: 설정과 운영의 복잡성, 데이터 일관성 관리 어려움

이벤트 스트리밍은 대용량의 실시간 데이터를 처리하는 데 적합하며, 이벤트 소싱(event sourcing) 패턴을 구현할 때 유용합니다. 각 이벤트는 시스템의 상태 변화를 나타내며, 이러한 이벤트들을 스트림 형태로 처리하여 실시간 분석 및 모니터링에 활용할 수 있습니다.

3. 서비스 디스커버리 (Service Discovery)

3.1 클라이언트 사이드 디스커버리 (Client-Side Discovery)

클라이언트가 직접 서비스 레지스트리를 조회하여 사용할 서비스의 위치를 결정하는 방식입니다. 예를 들어, Netflix의 Eureka가 대표적인 도구입니다.

장점: 간단한 구현, 클라이언트의 유연성 증가

단점: 클라이언트의 복잡성 증가, 클라이언트와 서비스 레지스트리 간의 통신 필요

3.2 서버 사이드 디스커버리 (Server-Side Discovery)

클라이언트 요청이 로드 밸런서를 거쳐 서비스 레지스트리를 조회하고, 적절한 서비스 인스턴스로 요청을 라우팅하는 방식입니다. 예를 들어, AWS의 Elastic Load Balancer가 대표적입니다.

장점: 클라이언트의 단순화, 중앙 집중식 로드 밸런싱

단점: 로드 밸런서의 복잡성 증가, 추가적인 네트워크 홉 발생

4. API Gateway API

게이트웨이는 모든 서비스 요청을 단일 진입점에서 처리하고, 각 서비스로 요청을 라우팅합니다.

장점: 중앙 집중식 인증 및 권한 관리, 로깅 및 모니터링 용이, CORS 처리 등 다양한 기능 제공

단점: 단일 장애 지점(Single Point of Failure) 가능성, 성능 병목 발생 가능

API Gateway는 마이크로서비스 아키텍처에서 매우 중요한 역할을 하며, 다양한 기능을 통해 서비스 간 통신을 효율적으로 관리하고 보안성을 높일 수 있습니다.

결론

MSA에서 각 모듈 간 통신은 시스템의 성능과 안정성에 큰 영향을 미칩니다. 동기 통신과 비동기 통신 방식, 서비스 디스커버리, API 게이트웨이 등 다양한 통신 방법을 적절히 조합하여 사용함으로써 마이크로서비스 간의 효율적인 협업을 구현할 수 있습니다. 각 통신 방법의 장단점을 이해하고, 시스템의 요구사항에 맞게 최적의 방식을 선택하는 것이 중요합니다.

서버로 파일을 전송하는 여러가지 방법

얼은펭귄 — Tue, 6 Aug 2024 12:55:29 +0900

파일 전송은 서버와 클라이언트 간의 중요한 기능 중 하나입니다. 다양한 방식으로 파일을 전송할 수 있으며, 각각의 방식은 특정한 요구 사항과 상황에 맞게 선택될 수 있습니다. 아래에서는 여러 가지 파일 전송 방법에 대해 자세히 설명합니다.

HTTP 파일 업로드

HTML Form과 multipart/form-data를 이용한 전송

HTML 폼을 사용하여 파일을 업로드하는 가장 일반적인 방법입니다. 이 방식은 multipart/form-data 인코딩 타입을 사용하여 파일을 전송합니다. 클라이언트는 파일을 포함한 폼 데이터를 서버로 전송하고, 서버는 이를 받아 처리합니다.

REST API와 파일 업로드 라이브러리 사용

REST API를 통해 파일을 업로드하는 방법입니다. 서버에서는 파일 업로드를 처리하기 위해 Multer와 같은 라이브러리를 사용합니다. 클라이언트는 multipart/form-data 형식으로 파일을 전송하며, 서버는 이를 받아 저장합니다.

WebSocket을 통한 파일 전송

WebSocket을 이용하면 양방향 실시간 데이터 전송이 가능합니다. 이는 실시간 파일 전송이 필요한 애플리케이션에 적합합니다. WebSocket은 지속적인 연결을 유지하여 데이터가 빠르게 전송될 수 있습니다.

FTP(File Transfer Protocol)

FTP는 파일 전송을 위한 전통적인 프로토콜입니다. FTP 서버를 설정하고, FTP 클라이언트를 통해 파일을 전송할 수 있습니다. FTP는 주로 대용량 파일 전송에 사용됩니다.

SFTP(Secure File Transfer Protocol)

SFTP는 SSH 기반의 보안 파일 전송 프로토콜입니다. FTP와 달리 암호화된 채널을 통해 파일을 전송하여 보안을 강화합니다. 주로 보안이 중요한 환경에서 사용됩니다.

Chunked File Upload

파일을 작은 청크로 나누어 부분적으로 전송한 후 서버에서 재조립하는 방법입니다. 이는 대용량 파일 전송 시 유용하며, 네트워크 상태가 불안정한 경우에도 효과적입니다.

Cloud Storage Services

AWS S3, Google Cloud Storage, Azure Blob Storage와 같은 클라우드 스토리지 서비스를 이용한 파일 업로드 방법입니다. 클라이언트는 클라우드 스토리지 서비스의 API를 사용하여 파일을 업로드합니다. 이는 높은 가용성과 확장성을 제공합니다.

RPC(Remote Procedure Call) 프로토콜

gRPC와 같은 RPC 프로토콜을 이용한 파일 전송 방법입니다. RPC는 함수 호출을 통해 원격 서버와 통신할 수 있게 해주며, 파일 전송 시에도 사용될 수 있습니다.

P2P(Peer-to-Peer) 파일 전송

WebRTC와 같은 P2P 기술을 이용하여 클라이언트 간 파일을 직접 전송한 후 서버에 전달하는 방법입니다. 이는 서버 부하를 줄이고, 빠른 파일 전송을 가능하게 합니다.

SMB(Server Message Block) 또는 NFS(Network File System)

네트워크 파일 시스템을 사용하여 파일을 공유하고 전송하는 방법입니다. 이는 주로 내부 네트워크에서 파일을 공유할 때 사용됩니다.

Command Line Tools

scp, rsync 등의 명령줄 도구를 이용한 파일 전송 방법입니다. 이는 주로 서버 관리자가 파일을 전송할 때 사용되며, 스크립트를 통해 자동화할 수도 있습니다.

이처럼 다양한 파일 전송 방법이 있으며, 각각의 방법은 특정한 요구 사항과 상황에 맞게 선택될 수 있습니다. 적절한 파일 전송 방식을 선택하여 효율적이고 안전한 파일 전송을 구현할 수 있습니다.

버블 정렬, 선택 정렬, 삽입 정렬 비교

얼은펭귄 — Fri, 19 Jul 2024 17:28:05 +0900

정렬 알고리즘의 Big O

알고리즘	시간 복잡도 (Best)	시간 복잡도 (Average)	시간 복잡도 (Worst)	공간 복잡도
버블 정렬	O(n)	O(n^2)	O(n^2)	O(1)
삽입 정렬	O(n)	O(n^2)	O(n^2)	O(1)
선택 정렬	O(n^2)	O(n^2)	O(n^2)	O(1)

보통 이 세 가지 정렬 알고리즘은 2차 정렬 알고리즘이라고 불립니다. 이는 시간 복잡도가 O(n^2) 이기 때문입니다.

버블 정렬, 삽입 정렬의 경우 정렬이 거의 다 되어있으면 시간 복잡도가 O(N) 입니다. (Best)
하지만 선택 정렬의 경우 최솟값을 찾기위해 끝까지 다 보기 때문에 모든 경우에서 O(n^2) 입니다. (Best)

요약

정렬은 기본입니다.
버블 정렬, 선택 정렬, 삽입 정렬은 모두 대략 비슷합니다.
모두 평균 시간 복잡도가 이차적입니다.
우리는 더 나은 방법을 찾을 수 있지만, 더 복잡한 알고리즘이 필요합니다.
데이터 셋이 매우 작을 때 효과적입니다.

결론

버블 정렬, 선택 정렬, 삽입 정렬은 모두 시간 복잡도가 O(n^2)인 기본적인 정렬 알고리즘입니다. 작은 데이터 셋에서는 효과적이지만, 큰 데이터 셋에서는 비효율적일 수 있습니다. 따라서 더 나은 성능을 위해서는 퀵 정렬, 병합 정렬 등의 복잡한 알고리즘을 고려해야 합니다. 이 글에서는 세 가지 기본 정렬 알고리즘의 작동 방식과 시간 복잡도를 비교하여 정리했습니다.

삽입 정렬 (Insertion Sort)

얼은펭귄 — Fri, 19 Jul 2024 16:52:53 +0900

삽입 정렬(Insertion Sort) 소개

삽입 정렬은 비교적 간단하고 직관적인 정렬 알고리즘입니다. 작은 데이터를 정렬할 때는 매우 효율적이지만, 데이터의 양이 많아지면 비효율적이 될 수 있습니다. 삽입 정렬의 기본 아이디어는 이미 정렬된 부분 배열을 확장해 나가면서 새로운 요소를 올바른 위치에 삽입하는 것입니다.

삽입 정렬의 의사 코드

배열에서 두 번째 요소를 선택하여 시작합니다.
두 번째 요소를 이전 요소와 비교하고 필요한 경우 스왑합니다.
다음 요소로 계속 진행하고, 잘못된 순서일 경우 정렬된 부분(즉, 왼쪽)을 반복하여 요소를 올바른 위치에 배치합니다.
배열이 정렬될 때까지 이 과정을 반복합니다.

삽입 정렬 구현

다음은 삽입 정렬을 JavaScript의 ES6 문법으로 구현한 예제입니다:

const insertionSort = (arr) => {
  for (let i = 1; i < arr.length; i++) {
    let currentVal = arr[i];
    let j;
    for (j = i - 1; j >= 0 && arr[j] > currentVal; j--) {
      arr[j + 1] = arr[j];
    }
    arr[j + 1] = currentVal;
  }
  return arr;
};

// 사용 예시
let array = [5, 2, 9, 1, 5, 6];
console.log(insertionSort(array)); // [1, 2, 5, 5, 6, 9]

이 코드에서는 insertionSort 함수가 주어진 배열을 삽입 정렬 방식으로 정렬합니다. for 루프를 통해 배열의 두 번째 요소부터 시작하여 각 요소를 이미 정렬된 부분 배열에 삽입합니다. 내부 for 루프는 현재 요소가 올바른 위치에 삽입될 때까지 이전 요소들과 비교하여 요소들을 한 칸씩 뒤로 이동시킵니다.

삽입 정렬 빅오(Big-O) 복잡도

삽입 정렬의 시간 복잡도는 다음과 같습니다:

최악의 경우: O(n^2)
배열이 역순으로 정렬되어 있는 경우가 최악의 경우입니다.
최선의 경우: O(n)
배열이 이미 정렬되어 있는 경우가 최선의 경우입니다.

삽입 정렬의 특징

안정성: 삽입 정렬은 안정 정렬 알고리즘입니다. 이는 같은 값의 요소들이 정렬 후에도 기존의 순서를 유지한다는 것을 의미합니다.
적응성: 거의 정렬된 배열에 대해 매우 효율적입니다. 이는 최선의 경우 시간 복잡도가 O(n)인 이유입니다.
간단함: 구현이 매우 간단하고 직관적입니다.

삽입 정렬의 장단점

장점

구현이 쉽고, 이해하기 쉽습니다.
적은 데이터나 거의 정렬된 데이터에 대해 효율적입니다.
안정 정렬 알고리즘입니다.

단점

데이터의 양이 많아질수록 비효율적입니다.
최악의 경우 시간 복잡도가 O(n^2)입니다.

결론

삽입 정렬은 그리 복잡하지 않으면서도 작동 방식이 매우 직관적입니다. 작은 데이터 세트나 이미 어느 정도 정렬된 데이터에 대해 효율적으로 사용할 수 있습니다. 그러나 큰 데이터 세트에 대해서는 다른 정렬 알고리즘(예: 퀵 정렬, 병합 정렬)보다 성능이 떨어질 수 있습니다. 따라서 상황에 맞게 적절한 정렬 알고리즘을 선택하는 것이 중요합니다.

이 글에서는 삽입 정렬의 기본 개념과 구현 방법, 그리고 시간 복잡도와 특징에 대해 알아보았습니다. 이를 통해 삽입 정렬의 작동 방식을 이해하고, 실제로 코드로 구현할 수 있을 것입니다.

선택 정렬 (Selection Sort)

얼은펭귄 — Mon, 15 Jul 2024 19:46:07 +0900

선택 정렬 소개

선택 정렬은 정렬 알고리즘 중 하나로, 버블 정렬과 비슷하지만 큰 값을 배열 끝에 위치시키는 대신 작은 값을 한 번에 하나씩 위치에 배열하는 방식입니다.

선택 정렬 동작 방식

첫 번째 요소를 가장 작은 값으로 저장합니다.
이 요소를 배열의 다음 요소와 비교하여 더 작은 수를 찾을 때까지 계속합니다.
더 작은 수를 찾으면, 그 작은 수를 새로운 "최소값"으로 지정하고 배열의 끝까지 계속합니다.
"최소값"이 처음 시작한 값(인덱스)이 아닌 경우, 두 값을 교환합니다.
배열이 정렬될 때까지 다음 요소로 이 과정을 반복합니다.

선택 정렬 의사 코드

{for i from 0 to n-1:
    minIndex = i
    for j from i+1 to n:
        if array[j] < array[minIndex]:
            minIndex = j
    if minIndex != i:
        swap(array[i], array[minIndex])}

선택 정렬 구현

다음은 ES2015(JavaScript) 버전의 선택 정렬 구현 예제입니다.

function selectionSort(arr) {
  const swap = (arr, idx1, idx2) =>
    ([arr[idx1], arr[idx2]] = [arr[idx2], arr[idx1]]);

  for (let i = 0; i < arr.length; i++) {
    let lowest = i;
    for (let j = i + 1; j < arr.length; j++) {
      if (arr[j] < arr[lowest]) {
        lowest = j;
      }
    }
    if (i !== lowest) {
      swap(arr, i, lowest);
    }
  }

  return arr;
}

선택 정렬 빅오 복잡도

선택 정렬의 시간 복잡도는 O(n^2)입니다. 이는 이중 for 루프를 사용하여 배열의 각 요소를 비교하기 때문입니다. 선택 정렬은 다음과 같은 점에서 버블 정렬보다 효율적입니다.

스왑 횟수: 선택 정렬은 각 반복이 끝날 때 한 번만 스왑을 수행합니다. 이는 불필요한 스왑을 줄여줍니다.
단순성: 구현이 간단하여 이해하기 쉽습니다.

공간 복잡도

선택 정렬은 추가적인 배열을 사용하지 않고 주어진 배열 내에서 정렬을 수행하기 때문에 공간 복잡도는 O(1)입니다.

선택 정렬의 장점과 단점

장점

구현이 간단하고 이해하기 쉽습니다.
데이터의 양이 적을 때는 효율적입니다.
주어진 배열 내에서 정렬을 수행하기 때문에 추가 메모리가 필요하지 않습니다.

단점

시간 복잡도가 O(n^2)이기 때문에 대량의 데이터에 대해서는 비효율적입니다.
안정 정렬이 아닙니다. (같은 값의 요소들이 정렬 후에도 입력 순서가 유지되지 않을 수 있습니다.)

선택 정렬의 활용

선택 정렬은 데이터의 양이 적고, 간단한 정렬을 필요로 하는 경우에 유용합니다.

선택 정렬은 단순하지만, 알고리즘의 기본 개념을 이해하는 데 도움이 됩니다. 더 복잡한 알고리즘을 배우기 전에 선택 정렬을 이해하고 구현해 보는 것이 좋습니다.

버블 정렬 (Bubble Sort) 정렬 알고리즘 소개

얼은펭귄 — Sun, 14 Jul 2024 22:42:22 +0900

정렬이란?

정렬이란 컬렉션(ex: 배열)의 항목을 재배열하는 과정을 의미합니다.

왜 배워야 하나?

정렬은 프로그래밍에서 매우 흔하게 사용됩니다.
데이터를 정렬할 수 있는 방법은 많고, 각각 장단점이 있습니다.
특정 상황에서 더 빠른 알고리즘이 있습니다.

목표

버블 정렬
선택 정렬
삽입 정렬

기본 내장 JS 정렬

array 내장 sort

MDN을 살펴보면 문자열은 A, B, C, D 순으로 나오지만 숫자는 오름차순이 아닌 것을 알 수 있습니다. 그 이유는 기본 정렬 순서가 문자열 유니코드에 따르기 때문입니다.

하지만 정렬 방식, 정렬의 기준이 되는 속성, 비교 대상을 실제로 지정할 수 있다면 다른 결과를 낼 수 있습니다.

버블 정렬 개요

버블 정렬의 개념은 예를 들어 배열을 오름차순으로 정렬한다면, 더 큰 숫자가 한 번에 하나씩 뒤로 이동한다는 것입니다.

예시:

[5, 3, 4, 1, 2]
[3, 5, 4, 1, 2]
[3, 4, 5, 1, 2]
[3, 4, 1, 5, 2]
[3, 4, 1, 2, 5]
...
[1, 2, 3, 4, 5]가 될 때까지 반복

반복을 거듭하면서 정렬해야 하는 항목의 수가 감소합니다. 교환을 해야 할 때 사용해야 하는 방법은 아래와 같습니다.

// ES5
function swap(arr, idx1, idx2) {
    var temp = arr[idx1];
    arr[idx1] = arr[idx2];
    arr[idx2] = temp;
}

// ES2015
const swap = (arr, idx1, idx2) => {
    [arr[idx1], arr[idx2]] = [arr[idx2], arr[idx1]];
}

버블 정렬은 단순한 구조로 인해 쉽게 이해할 수 있는 알고리즘입니다. 하지만 성능 면에서는 비효율적입니다. 특히 배열의 크기가 커질수록 성능이 급격히 저하됩니다. 버블 정렬은 안정 정렬(stable sort)로 동일한 값의 요소들이 원래의 순서를 유지한다는 장점이 있습니다. 또한, 내부 정렬(in-place sort)로 추가적인 메모리 공간을 거의 사용하지 않습니다.

버블 정렬 의사코드

i라는 변수를 사용하여 배열의 끝에서 시작하여 처음까지 반복합니다.
내부 반복문에서는 j라는 변수를 사용하여 처음부터 i-1까지 반복합니다.
만약 arr[j]가 arr[j+1]보다 크다면, 두 값을 서로 교환(swap)합니다.
정렬된 배열을 반환합니다.

버블 정렬 구현

function bubbleSort(arr) {
    for(let i = arr.length; i > 0; i--) {
        for(let j = 0; j < i - 1; j++) {
            if(arr[j] > arr[j+1]) {
                const temp = arr[j];
                arr[j] = arr[j+1];
                arr[j+1] = temp;
            }
        }
    }
    return arr;
}

버블 정렬을 구현한 위의 예시는 기본적인 구조를 보여줍니다. 배열의 끝에서부터 처음까지 반복하면서 각 요소를 비교하고 필요한 경우 교환합니다. 하지만 이렇게 구현된 버블 정렬은 이미 정렬이 완료된 경우에도 배열 끝까지 계속 탐색을 하며 비효율적입니다.

버블 정렬 최적화

버블 정렬의 성능을 향상시키기 위해 몇 가지 최적화 기법을 사용할 수 있습니다. 그 중 하나는 루프가 마지막으로 실행됐을 때 교환이 있었는지를 확인하는 것입니다. 만약 교환이 없었다면 배열은 이미 정렬된 상태이므로 반복을 중지할 수 있습니다.

function bubbleSort(arr) {
    let noSwaps;
    for(let i = arr.length; i > 0; i--) {
        noSwaps = true;
        for(let j = 0; j < i - 1; j++) {
            if(arr[j] > arr[j+1]) {
                const temp = arr[j];
                arr[j] = arr[j+1];
                arr[j+1] = temp;
                noSwaps = false;
            }
        }
        if(noSwaps) break;
    }
    return arr;
}

이 최적화된 버블 정렬 구현은 불필요한 반복을 줄여 성능을 향상시킵니다. 루프가 실행될 때 교환이 없었다면, 배열이 이미 정렬된 상태이므로 더 이상의 반복을 중지할 수 있습니다.

버블 정렬의 특성

버블 정렬은 간단하지만 비효율적인 정렬 알고리즘입니다. 실제 사용보다는 교육 목적으로 많이 사용됩니다. 이 알고리즘을 이해하면 더 복잡한 정렬 알고리즘을 배우는 데 도움이 됩니다. 또한, 안정 정렬 알고리즘으로 동일한 값의 순서가 유지됩니다.

안정 정렬 (Stable Sort)

버블 정렬은 안정 정렬 알고리즘입니다. 이는 동일한 값의 요소들이 원래의 순서를 유지한다는 것을 의미합니다. 예를 들어, 객체 배열을 특정 키로 정렬할 때, 같은 키 값을 가진 객체들이 버블 정렬을 통해서도 순서가 바뀌지 않습니다.

내부 정렬 (In-place Sort)

버블 정렬은 추가적인 메모리 공간을 거의 사용하지 않는 내부 정렬 알고리즘입니다. 배열 자체에서 직접 교환 작업을 수행하기 때문에, 메모리 사용량이 매우 적습니다.

단점

성능이 좋지 않습니다. 특히, 배열의 크기가 클수록 시간 복잡도 O(n^2)로 인해 성능이 급격히 저하됩니다.
큰 배열을 정렬하는 데 적합하지 않습니다.

버블 정렬의 실제 사용 사례

버블 정렬은 대부분의 경우 비효율적이지만, 간단한 구현과 이해하기 쉬운 알고리즘 구조로 인해 교육 목적으로 자주 사용됩니다. 예를 들어, 알고리즘과 자료 구조를 처음 배우는 학생들에게 버블 정렬은 기본적인 정렬 개념을 이해하는 데 큰 도움이 됩니다.

버블 정렬의 빅오 복잡도

평균 및 최악의 경우: O(n^2)
최상의 경우: O(n) (이미 정렬된 경우)

추가 리소스

Visualgo: 다양한 알고리즘을 시각적으로 볼 수 있는 사이트입니다.

검색 알고리즘

얼은펭귄 — Wed, 10 Jul 2024 23:20:09 +0900

검색 알고리즘은 컴퓨터 과학에서 필수적인 주제입니다. 데이터를 효율적으로 검색하는 방법을 이해하면 프로그램의 성능을 크게 향상시킬 수 있습니다. 이 글에서는 다양한 검색 알고리즘을 소개하고, 각각의 구현 방법과 시간 복잡도를 설명합니다.

목표

선형 검색
분류된 배열에서의 이진 검색
나이브 문자열 검색 알고리즘

선형 검색 소개

선형 검색은 가장 간단한 검색 방법 중 하나입니다. 이 방법은 배열의 각 요소를 순서대로 확인하여 값이 일치하는지 확인합니다. JavaScript에서는 indexOf, includes, find, findIndex와 같은 배열 함수를 사용하여 선형 검색을 수행할 수 있습니다.

한 번에 하나씩 검색하는 이 방법을 선형 검색이라고 합니다.

선형 검색 연습

배열과 값을 받아들이고 그 값이 배열 안에 존재하는 경우, 그 인덱스를 반환하는 linearSearch 함수를 작성합니다. 값이 배열 안에 존재하지 않으면 -1을 반환합니다. 이 함수를 구현할 때 indexOf를 사용하지 마세요!

    function linearSearch(index){
  
    }
    
    // linearSearch([10, 15, 20, 25, 30], 15) // 1
    // linearSearch([9, 8, 7, 6, 5, 4, 3, 2, 1, 0], 4) // 5
    // linearSearch([100], 100) // 0
    // linearSearch([1,2,3,4,5], 6) // -1
    // linearSearch([9, 8, 7, 6, 5, 4, 3, 2, 1, 0], 10) // -1
    // linearSearch([100], 200) // -1

정답

function linearSearch(arr, val) {
    for (let i = 0; i < arr.length; i++) {
        if (arr[i] === val) {
            return i;
        }
    }
    return -1;
}

// 예시 사용법
console.log(linearSearch([10, 15, 20, 25, 30], 15)); // 1
console.log(linearSearch([9, 8, 7, 6, 5, 4, 3, 2, 1, 0], 4)); // 5
console.log(linearSearch([100], 100)); // 0
console.log(linearSearch([1, 2, 3, 4, 5], 6)); // -1
console.log(linearSearch([9, 8, 7, 6, 5, 4, 3, 2, 1, 0], 10)); // -1
console.log(linearSearch([100], 200)); // -1

선형 검색 빅오 (Big O)

선형 검색의 시간복잡도는 다음과 같습니다:

최선의 경우: O(1) (첫 번째 요소에 있는 경우)
최악의 경우: O(n) (마지막 요소에 있는 경우)

따라서 일반적인 시간복잡도는 O(n)입니다. 데이터가 분류되지 않았을 때 사용하는 좋은 방법입니다.

이진 검색 소개

이진 검색은 정렬된 배열에서 더 빠른 검색 방법을 제공합니다. 이진 검색은 배열을 절반으로 나누어 검색 범위를 줄여나가는 분할 정복 알고리즘입니다. 이 방법은 정렬된 배열에서만 작동합니다.

이진 검색 연습

정렬된 배열과 값을 받아들이고 값이 존재하는 경우 그 인덱스를 반환하는 binarySearch 함수를 작성합니다. 값이 존재하지 않으면 -1을 반환합니다.

function binarySearch(arr, value){}
binarySearch([1,2,3,4,5],2) // 1
binarySearch([1,2,3,4,5],3) // 2
binarySearch([1,2,3,4,5],5) // 4
binarySearch([1,2,3,4,5],6) // -1
binarySearch([
  5, 6, 10, 13, 14, 18, 30, 34, 35, 37, 
  40, 44, 64, 79, 84, 86, 95, 96, 98, 99
], 10) // 2
binarySearch([
  5, 6, 10, 13, 14, 18, 30, 34, 35, 37, 
  40, 44, 64, 79, 84, 86, 95, 96, 98, 99
], 95) // 16
binarySearch([
  5, 6, 10, 13, 14, 18, 30, 34, 35, 37, 
  40, 44, 64, 79, 84, 86, 95, 96, 98, 99
], 100) // -1

정답

function binarySearch(arr, elem) {
  let start = 0;
  let end = arr.length - 1;
  let middle = Math.floor((start + end) / 2);
  while (arr[middle] !== elem && start <= end) {
    if (elem < arr[middle]) {
      end = middle - 1;
    } else {
      start = middle + 1;
    }
    middle = Math.floor((start + end) / 2);
  }
  return arr[middle] === elem ? middle : -1;
}

이진 검색 빅오 (Big O)

이진 검색의 시간복잡도는 다음과 같습니다:

최선의 경우: O(1) (첫 번째 비교에서 찾은 경우)
최악의 경우: O(log N) (반복적으로 반으로 나누는 경우)

따라서 일반적인 시간복잡도는 O(log N)입니다.

나이브 문자열 검색

나이브 문자열 검색은 문자열 안에서 부분 문자열을 찾는 간단한 방법입니다. 긴 문자열과 짧은 문자열을 비교하여 일치하는 경우를 찾습니다.

나이브 문자열 검색 구현

function naiveSearch(long, short) {
    let count = 0;
    for(let i = 0; i < long.length; i++) {
        for(let j = 0; j < short.length; j++) {
            if(short[j] !== long[i + j]) {
                console.log("Break");
                break;
            }
            if(j === short.length - 1) {
                count++;
            }
        }
    }
    return count;
}
naiveSearch("lorie loled", "lol"); // 1

(더 어려운) 재귀 연습 문제 1부

얼은펭귄 — Wed, 10 Jul 2024 18:36:54 +0900

문제1

문자열을 받아들이고 그 문자열의 역순인 문자열을 반환하는 reverse 함수를 작성합니다.

function reverse(string){
}

// reverse('awesome') // 'emosewa'
// reverse('rithmschool') // 'loohcsmhtir'

정답

function reverse(string) {
  if (string.length === 1) {
    return string;
  }
  return reverse(string.slice(1)) + string[0];
}

문제2

전달된 문자열이 팔린드롬(앞으로 읽으나 뒤로 읽으나 동일한 문자)인 경우 true 를 반환하는 isPalindrome이라는 재귀(recursive) 함수를 작성하시오. 팔린드롬이 아닐 경우 false 를 반환합니다.

// isPalindrome('awesome') // false
// isPalindrome('foobar') // false
// isPalindrome('tacocat') // true
// isPalindrome('amanaplanacanalpanama') // true
// isPalindrome('amanaplanacanalpandemonium') // false

function isPalindrome(str){

}

정답

// 내 정답
function isPalindrome(str){
    function helper(str2) {
        if (str2.length === 1) {
            return str2;
        }
        return helper(str2.slice(1)) + str2[0]
    }
    return str === helper(str) ? true : false;
}

// 정답지
function isPalindrome(str){
    if(str.length === 1) return true;
    if(str.length === 2) return str[0] === str[1];
    if(str[0] === str.slice(-1)) return isPalindrome(str.slice(1,-1))
    return false;
}

문제3

배열과 콜백을 받아들이는 someRecursive 라는 재귀(recursive) 함수를 작성하시오. 이 함수는 배열의 단일 값이 콜백에 전달될 때 true를 반환하면 true를 반환합니다. 그렇지 않으면 false를 반환합니다.

// SAMPLE INPUT / OUTPUT
// const isOdd = val => val % 2 !== 0;

// someRecursive([1,2,3,4], isOdd) // true
// someRecursive([4,6,8,9], isOdd) // true
// someRecursive([4,6,8], isOdd) // false
// someRecursive([4,6,8], val => val > 10); // false

function someRecursive(){
}

정답

// SAMPLE INPUT / OUTPUT
// const isOdd = val => val % 2 !== 0;

// someRecursive([1,2,3,4], isOdd) // true
// someRecursive([4,6,8,9], isOdd) // true
// someRecursive([4,6,8], isOdd) // false
// someRecursive([4,6,8], val => val > 10); // false

// 내 정답
function someRecursive(arr, func){
    if (arr.length === 0) {
     return false;   
    }
    if(func(arr.pop())) {
        return true
    }
    return someRecursive(arr, func)
}

// 정답지
function someRecursive(array, callback) {
    if (array.length === 0) return false;
    if (callback(array[0])) return true;
    return someRecursive(array.slice(1),callback);
}

문제4

배열의 배열을 받아들이고 모든 값이 평활화(flattened)된 새 배열을 반환하는 flatten이라는 재귀(recursive ) 함수를 작성합니다.

function flatten(){
    
}

// flatten([1, 2, 3, [4, 5] ]) // [1, 2, 3, 4, 5]
// flatten([1, [2, [3, 4], [[5]]]]) // [1, 2, 3, 4, 5]
// flatten([[1],[2],[3]]) // [1,2,3]
// flatten([[[[1], [[[2]]], [[[[[[[3]]]]]]]]]]) // [1,2,3

정답

function flatten(oldArr) {
  let newArr = [];
  for (let i = 0; i < oldArr.length; i++) {
    if (Array.isArray(oldArr[i])) {
      newArr = newArr.concat(flatten(oldArr[i]));
    } else {
      newArr.push(oldArr[i]);
    }
  }
  return newArr;
}

// flatten([1, 2, 3, [4, 5] ]) // [1, 2, 3, 4, 5]
// flatten([1, [2, [3, 4], [[5]]]]) // [1, 2, 3, 4, 5]
// flatten([[1],[2],[3]]) // [1,2,3]
// flatten([[[[1], [[[2]]], [[[[[[[3]]]]]]]]]]) // [1,2,3]

재귀 연습 문제

얼은펭귄 — Tue, 9 Jul 2024 17:40:28 +0900

문제 1

밑과 지수를 받아들이는 power라는 함수를 작성합니다. 이 함수는 밑의 거듭제곱을 지수로 반환해야 합니다. 이 함수는 Math.pow()의 기능을 모방해야 합니다. 음의 밑과 지수에 대해서는 신경쓰지 마세요.

// power(2,0) // 1
// power(2,2) // 4
// power(2,4) // 16

function power(){}

정답

// power(2,0) // 1
// power(2,2) // 4
// power(2,4) // 16

function power(num, pow){
    if(pow === 0) {
        return 1;
    }
    return num * power(num, pow - 1)
}

문제 2

숫자를 받아 해당 숫자의 계승(팩토리얼)을 반환하는 팩토리얼 함수를 작성하시오.

팩토리얼은 정수와 그 아래의 모든 정수의 곱입니다.

예를 들어, 4 팩토리얼 (4!)은 4 * 3 * 2 * 1 = 2입니다. 팩토리얼 0(0!)은 항상 1입니다.

//factorial(1) // 1
// factorial(2) // 2
// factorial(4) // 24
// factorial(7) // 5040

function factorial(){
   
}

정답

//factorial(1) // 1
// factorial(2) // 2
// factorial(4) // 24
// factorial(7) // 5040

function factorial(x){
   if (x < 0 ) {return 0;}
   if (x <= 1 ) {return 1;}
   return x * factorial(x-1);
}

문제3

숫자 배열을 받아 모든 숫자의 곱을 반환하는 productOfArray라는 함수를 작성하시오.

// productOfArray([1,2,3]) // 6
// productOfArray([1,2,3,10]) // 60

function productOfArray(arr) {}

정답

function productOfArray(arr) {
    if(arr.length === 0) {
        return 1;
    }
    return arr[0] * productOfArray(arr.slice(1));
}

문제4

숫자를 받으면 0부터 함수에 전달된 숫자까지의 모든 숫자를 더하는 recursiveRange라는 함수를 작성하시오.

// recursiveRange(6) // 21
// recursiveRange(10) // 55 

function recursiveRange(num){}

정답

function recursiveRange(x){
   if (x === 0 ) {return 0;}
   return x + recursiveRange(x-1);
}

문제5

숫자를 받아 피보나치 수열의 n번째 숫자를 반환하는 fib라는 재귀 함수를 작성하시오. 피보나치 수열은 1, 1로 시작하는 1, 1, 2, 3, 5, 8, ...의 정수의 수열이며, 모든 수는 이전 두 수의 합과 같다는 것을 명심하세요.

// fib(4) // 3
// fib(10) // 55
// fib(28) // 317811
// fib(35) // 9227465

function fib(num){}

정답

// fib(4) // 3
// fib(10) // 55
// fib(28) // 317811
// fib(35) // 9227465

function fib(num){
    if (num <= 2) {
        return 1;
    }
    return fib(num-1) + fib(num-2);
}

재귀 (Recursion)

얼은펭귄 — Mon, 8 Jul 2024 20:26:20 +0900

재귀의 기본 개념

재귀는 문제를 더 작은 부분으로 나누어, 종료점에 도달할 때까지 반복적으로 수행하는 방법입니다.

목표

재귀가 무엇인지, 어떻게 유용하게 사용할 수 있는지 이해하기
재귀 함수 작성의 두 가지 핵심 요소
호출 스택이 재귀와 어떤 관련이 있는지 이해하기
헬퍼 메소드 재귀와 순수 재귀의 차이점과 비교

재귀 함수를 사용하는 이유

재귀는 자기 자신을 호출하는 절차로, 많은 상황에서 유용하게 사용됩니다. 복잡한 데이터 구조나 알고리즘을 다룰 때 재귀가 큰 도움이 될 수 있습니다.

예를 들어:

JSON.parse / JSON.stringify
document.getElementById와 같은 DOM 탐색 알고리즘
객체 순회 (Object traversal)
복잡한 알고리즘에서 재귀로 작성하는 것이 더 깔끔하고 이해하기 쉬운 경우가 많습니다.

호출 스택과 재귀

거의 모든 프로그래밍 언어에는 함수 호출을 관리하는 보이지 않는 데이터 구조가 있습니다. 호출된 함수는 다른 함수가 반환될 때까지 기다리며, 이를 관리하는 것이 호출 스택입니다. JavaScript의 경우 호출 스택이 이 역할을 담당합니다.

첫 번째 재귀 함수

어떤 재귀 함수든 반드시 갖춰야 하는 두 가지 요소가 있습니다.

종료 조건 (Base Case)
서로 다른 입력값 (Different Input)

// 카운트다운을 재귀로 구현하는 경우
function countDown(num) {
// 종료 조건
    if(num <= 0) {
        console.log("All done!");
        return;
    }
    console.log(num);
    // 서로 다른 입력값을 위한 --
    num--;
    countDown(num);
}

두 번째 재귀 함수

function sumRange(num) {
    if(num === 1) {
        return 1;
    }
    return num + sumRange(num - 1);
}

sumRange(3)을 호출했을 때,

3 + sumRange(2)
2 + sumRange(1)
1

이 순서대로 실행되어 6이 반환됩니다.

반복문으로 팩토리얼 구현하기

function factorial(num) {
    let total = 1;
    for(let i = num; i > 1; i--) {
        total *= i;
    }
    return total;
}

재귀 호출로 팩토리얼 구현하기

function factorial(num) {
    if(num === 1) return 1;
    return num * factorial(num - 1);
}

재귀의 잠재적 위험

재귀 함수에는 몇 가지 잠재적 위험이 있습니다.

종료 조건이 없거나 잘못 설정된 경우
반환 값을 잊거나 잘못 반환하는 경우
Maximum call stack size exceeded 에러 발생 (스택 오버플로우)

헬퍼 메소드 재귀

재귀 함수를 다른 함수로 감싸서 처리하는 방법입니다.

function collectOddValues(arr){
// 외부에 변수를 선언해서 활용
    let result = []
    function helper(helperInput){
        if(helperInput.length === 0) {
            return;
        }
        if(helperInput[0] % 2 !== 0){
            result.push(helperInput[0])
        }
        helper(helperInput.slice(1))
    }
    helper(arr)
    return result;
}

순수 재귀

외부 데이터 구조를 사용하지 않고 필요한 모든 코드가 함수 자체에 포함됩니다.

function collectOddValues(arr) {
    let newArr = [];

    if(arr.length === 0) {
        return newArr;
    }
    if(arr[0] % 2 !== 0) {
        newArr.push(arr[0]);
    }

    newArr = newArr.concat(collectOddValues(arr.slice(1)));
    return newArr;
}

배열을 사용하고 헬퍼 메소드 없이 순수 재귀 솔루션을 작성할 때 배열을 복사하는 slice, spread 연산자, concat 등을 사용할 수 있습니다.
문자열은 변경할 수 없으므로 slice, substr, 또는 substring을 사용해서 복사해야 합니다.
객체의 경우 Object.assign이나 spread 연산자를 사용할 수 있습니다.

[TIL] 2023-07-05

얼은펭귄 — Fri, 5 Jul 2024 17:25:54 +0900

공부는 못하고 면접 준비만 주구장창...

면접 질문 정리 및 포트폴리오 추가
면접

문제 해결 패턴 연습 문제

얼은펭귄 — Mon, 1 Jul 2024 18:32:52 +0900

문제 1

sameFrequency 라는 함수를 작성하세요. 두 개의 양의 정수가 주어졌을 때, 두 숫자의 자릿수가 같은 빈도를 갖는지 구합니다.

여러분의 솔루션은 반드시 다음과 같은 복잡성을 가져야 합니다.

Time: O(N)

예시

sameFrequency(182, 281); // true
sameFrequency(34, 14); // false
sameFrequency(3589578, 5879385); // true
sameFrequency(22, 222); // false

정답

function sameFrequency(num1, num2) {
  // 빈도수를 담아둘 객체
  const frequency1 = {};
  const frequency2 = {};

  // string화
  const str1 = num1.toString();
  const str2 = num2.toString();

  const str1Length = str1.length;
  const str2Length = str2.length;

  // 길이가 같지 않다면 빈도수가 다름
  if (str1Length !== str2Length) {
    return false;
  }

  // 각 문자별로 객체에 빈도수를 저장
  for (let i = 0; i < str1Length; i++) {
    const s = str1[i];
    frequency1[s] = (frequency1[s] || 0) + 1;
  }
  for (let i = 0; i < str2Length; i++) {
    const s = str2[i];
    frequency2[s] = (frequency2[s] || 0) + 1;
  }

  for (let t in frequency1) {
    if (frequency2[t] !== frequency1[t]) {
      return false;
    }
  }

  return true;
}

문제 2

가변적인 수의 인수(a variable number of arguments)를 받아들이고 전달된 인자 중 중복이 있는지 확인하는 areThereDuplicates라는 함수를 구현합니다. 빈도 카운터 패턴 또는 다중 포인터 패턴을 사용하여 이 문제를 해결할 수 있습니다.

Time - O(n)

Space - O(n)

예시

areThereDuplicates(1, 2, 3); // false
areThereDuplicates(1, 2, 2); // true
areThereDuplicates('a', 'b', 'c', 'a'); // true

정답

function areThereDuplicates(...arr) {
  // 갯수를 담아둘 객체를 생성
  const obj = {};

  // 반복문을 돌면서 하나씩 저장
  for (let i = 0; i < arr.length; i++) {
    const current = arr[i];
    // 이미 객체가 있는 경우 return ture
    if (obj[current]) {
      return true;
    }
    obj[current] = (obj[current] || 0) + 1;
  }
  // 마지막에 도달한 경우 return false
  return false;
}

문제 3

averagePair라는 함수를 작성합니다. 정렬된 정수 배열과 목표 평균이 주어졌을 때, 배열에 쌍의 평균이 목표 평균과 같은 값의 쌍이 있는지 확인합니다. 목표 평균과 일치하는 쌍이 두 개 이상 있을 수 있습니다.

Time: O(N)

Space: O(1)

예시

averagePair([1,2,3],2.5) // true
averagePair([1,3,3,5,6,7,10,12,19],8) // true
averagePair([-1,0,3,4,5,6], 4.1) // false
averagePair([],4) // false

정답

function averagePair(arr, avg) {
  //   양쪽에 포인터를 하나씩 둠
  let left = 0;
  let right = arr.length - 1;
  //   평균의 값을 2배 한 값을 구함.
  const avg2 = avg * 2;
  // 포인터 왼쪽이 작아질때까지 반복문을 돔.
  while (left < right) {
    // 양 포인터의 값을 합함.
    const sum = arr[left] + arr[right];
    // 합이 같은 경우 정답
    if (sum === avg2) {
      return true;
    } else if (sum < avg2) {
      // 만약 포인터의 값을 합한게 2배 값보다 작다면 왼쪽 포인터를 늘림.
      left++;
    } else {
      // 만약 포인터의 값을 합한게 2배 값보다 크다면 오른쪽 포인터를 줄임.
      right--;
    }
  }
  // 전부 반복했는데 정답이 없는 경우
  return false;
}

문제 4

두 문자열을 받아 첫 번째 문자열의 문자가 두 번째 문자열의 문자의 일부에 포함되는지 확인하는 isSubsequence라는 함수를 작성합니다. 즉, 이 함수는 첫 번째 문자열의 문자가 순서가 바뀌지 않고 두 번째 문자열의 어딘가에 나타나는지 확인해야 합니다.

Time: O(N + M)

Space: O(1)

예시

isSubsequence('hello', 'hello world'); // true
isSubsequence('sing', 'sting'); // true
isSubsequence('abc', 'abracadabra'); // true
isSubsequence('abc', 'acb'); // false (order matters)

정답

function isSubsequence(str1, str2) {
  let i = 0;
  let j = 0;
  if (!str1) {
      return true
      
  };
  while (j < str2.length) {
    if (str2[j] === str1[i]) {
        i++
    };
    if (i === str1.length) {
        return true
        
    };
    j++;
  }
  return false;
}

문제 5

정수의 배열과 숫자가 주어졌을 때, 함수에 전달된 숫자의 길이를 가진 하위 배열의 최대 합을 구하는 maxSubarraySum이라는 함수를 작성하세요.

하위 배열은 원래 배열의 연속적인 요소로 구성되어야 한다는 점에 유의하세요. 아래 첫 번째 예제에서 [100, 200, 300]은 원래 배열의 하위 배열이지만 [100, 300]은 그렇지 않습니다.

Time: O(N)

Space: O(1)

예시

maxSubarraySum([100,200,300,400], 2) // 700
maxSubarraySum([1,4,2,10,23,3,1,0,20], 4)  // 39 
maxSubarraySum([-3,4,0,-2,6,-1], 2) // 5
maxSubarraySum([3,-2,7,-4,1,-1,4,-2,1],2) // 5
maxSubarraySum([2,3], 3) // null

정답

function maxSubarraySum(arr, num) {
  // 최대 합 선언
  let maxSum = 0;
  // 임시 합
  let tempSum = 0;
  // num보다 arr의 길이가 작으면  null return
  if (arr.length < num) {
    return null;
  }

  // 첫번째 임시 합을 구함
  for (let i = 0; i < num; i++) {
    tempSum += arr[i];
  }

  // 현재 최대 합은 첫번째 합
  maxSum = tempSum;

  for (let i = num; i < arr.length; i++) {
    // 반복문을 돌며 앞에 숫자를 빼고 뒤에 숫자를 더함.
    tempSum = tempSum - arr[i - num] + arr[i];
    // 둘 중 더 큰 값이 maxSum
    maxSum = Math.max(maxSum, tempSum);
  }

  return maxSum;
}

문제 6

양수 배열과 양수라는 두 개의 매개 변수를 받아들이는 minSubArrayLen이라는 함수를 작성하세요.

이 함수는 합이 함수에 전달된 정수보다 크거나 같은 인접한 하위 배열의 최소 길이를 반환해야 합니다. 값이 없는 경우 0을 반환합니다.

Time: O(n)

Space: O(1)

예시

minSubArrayLen([2,3,1,2,4,3], 7) // 2 -> because [4,3] is the smallest subarray
minSubArrayLen([2,1,6,5,4], 9) // 2 -> because [5,4] is the smallest subarray
minSubArrayLen([3,1,7,11,2,9,8,21,62,33,19], 52) // 1 -> because [62] is greater than 52
minSubArrayLen([1,4,16,22,5,7,8,9,10],39) // 3
minSubArrayLen([1,4,16,22,5,7,8,9,10],55) // 5
minSubArrayLen([4, 3, 3, 8, 1, 2, 3], 11) // 2
minSubArrayLen([1,4,16,22,5,7,8,9,10],95) // 0

정답

const minSubArrayLen = (nums, sum) => {
  // 전체값, 시작 인덱스 끝 인덱스, 최소 길이 변수 초기화
  let total = 0;
  let start = 0;
  let end = 0;
  let minLen = Infinity;

  // start가 배열의 길이보다 작은 동안 루프를 반복
  while (start < nums.length) {
    // 현재 윈도우의 합이 sum보다 작고 end가 배열의 끝에 도달하지 않은 경우
    // end를 증가시키면서 윈도우를 확장하고 total에 nums[end] 값을 더함
    if (total < sum && end < nums.length) {
      total += nums[end];
      end++;
    } else if (total >= sum) {
      // 현재 윈도우의 합이 sum보다 크거나 같은 경우, 최소 길이를 계산하여 minLen을 업데이트한다.
      // 그런 다음, start를 증가시키면서 윈도우를 축소하고 total에서 nums[start] 값을 뺀다.
      minLen = Math.min(minLen, end - start);
      total -= nums[start];
      start++;
    }
    // current total less than required total but we reach the end, need this or else we'll be in an infinite loop
    else {
      break;
    }
  }

  return minLen === Infinity ? 0 : minLen;
};

문제 7

문자열을 받아 모든 고유 문자가 포함된 가장 긴 하위 문자열의 길이를 반환하는 findLongestSubstring이라는 함수를 작성하세요.

Time: O(n)

예시

findLongestSubstring('') // 0
findLongestSubstring('rithmschool') // 7
findLongestSubstring('thisisawesome') // 6
findLongestSubstring('thecatinthehat') // 7
findLongestSubstring('bbbbbb') // 1
findLongestSubstring('longestsubstring') // 8
findLongestSubstring('thisishowwedoit') // 6

정답

function findLongestSubstring(str) {
  let longest = 0;
  let seen = {};
  let start = 0;
 
  for (let i = 0; i < str.length; i++) {
    let char = str[i];
    if (seen[char]) {
      start = Math.max(start, seen[char]);
    }
    longest = Math.max(longest, i - start + 1);
    seen[char] = i + 1;
  }
  return longest;
}

문제 해결 패턴

얼은펭귄 — Fri, 28 Jun 2024 15:46:00 +0900

문제 해결 패턴 소개

프로그래밍 문제를 효과적으로 해결하기 위해 다양한 문제 해결 패턴이 존재합니다. 이 글에서는 대표적인 문제 해결 패턴을 소개하고, 각 패턴에 대한 예시와 코드 리팩토링을 통해 성능을 개선하는 방법을 설명합니다.

빈도수 세기 패턴 (Frequency Counters)

빈도수 세기 패턴은 값의 빈도를 수집하기 위해 객체나 집합을 사용하는 방법입니다. 이를 통해 배열이나 문자열에서 중첩 루프(O(N^2))를 사용하지 않고 효율적으로 문제를 해결할 수 있습니다.

예시 문제

두 개의 배열을 입력으로 받는 same이라는 함수를 작성하세요.
이 함수는 첫 번째 배열의 모든 값이 두 번째 배열에서 제곱된 값과 일치하면 true를 반환해야 합니다.
값의 빈도수도 동일해야 합니다.

same([1,2,3], [4,1,9]) // true
same([1,2,3], [1,9]) // false
same([1,2,1], [4,4,1]) // false (빈도가 같아야 함.)

function same(arr1, arr2) {
    if (arr1.length !== arr2.length) {
        return false;
    }
    for (let i = 0; i < arr1.length; i++) {
        let correctIndex = arr2.indexOf(arr1[i] ** 2);
        if (correctIndex === -1) {
            return false;
        }
        arr2.splice(correctIndex, 1);
    }
    return true;
}

시간복잡도: O(N^2)

리팩토링 후

빈도수 세기 패턴을 적용한 리팩토링된 코드입니다.

function same(arr1, arr2) {
    if (arr1.length !== arr2.length) {
        return false;
    }
    let frequencyCounter1 = {};
    let frequencyCounter2 = {};
    for (let val of arr1) {
        frequencyCounter1[val] = (frequencyCounter1[val] || 0) + 1;
    }
    for (let val of arr2) {
        frequencyCounter2[val] = (frequencyCounter2[val] || 0) + 1;
    }
    for (let key in frequencyCounter1) {
        if (!(key ** 2 in frequencyCounter2)) {
            return false;
        }
        if (frequencyCounter2[key ** 2] !== frequencyCounter1[key]) {
            return false;
        }
    }
    return true;
}

시간 복잡도: O(N)

다중 포인터 패턴 (Multiple Pointers)

다중 포인터 패턴은 인덱스나 위치에 해당하는 포인터나 값을 만든 다음 사용하여 특정 조건에 따라 시작 지점이나 끝 지점을 이동시키며 문제를 해결하는 방법입니다. 최소한의 공간 복잡도로 문제를 해결하는 데 매우 효율적입니다.

예시 문제

정렬된 정수 배열을 입력으로 받아들이는 sumZero라는 함수를 작성하세요.
이 함수는 합이 0이 되는 첫 번째 쌍을 찾아야 합니다.
합이 0이 되는 두 값을 포함하는 배열을 반환하거나, 그런 쌍이 존재하지 않는 경우 undefined를 반환해야 합니다.

sumZero([-3,-2,-1,0,1,2,3]) // [-3,3] 
sumZero([-2,0,1,3]) // undefined
sumZero([1,2,3]) // undefined

function sumZero(arr) {
    for (let i = 0; i < arr.length; i++) {
        for (let j = i + 1; j < arr.length; j++) {
            if (arr[i] + arr[j] === 0) {
                return [arr[i], arr[j]];
            }
        }
    }
}

시간 복잡도: O(N^2)

리팩토링 후

다중 포인터 패턴을 적용한 리팩토링된 코드입니다.

function sumZero(arr){
    let left = 0;
    let right = arr.length - 1;
    while(left < right){
        let sum = arr[left] + arr[right];
        if(sum === 0){
            return [arr[left], arr[right]];
        } else if(sum > 0){
            right--;
        } else {
            left++;
        }
    }
}

시간 복잡도 O(N)
공간 복잡도 O(1)

슬라이딩 윈도우 패턴 (Sliding Window)

슬라이딩 윈도우 패턴은 배열이나 문자열 등의 데이터 부분 집합을 추적하는 데 매우 유용한 패턴입니다. 특정 조건에 따라 윈도우가 증가하거나 이동하며 문제를 해결합니다.

예시 문제

정수 배열과 n이라는 숫자를 입력으로 받아 n개의 연속된 요소들의 최대 합을 계산하는 maxSubarraySum 함수를 작성하세요.

maxSubarraySum([1,2,5,2,8,1,5],2) // 10
maxSubarraySum([1,2,5,2,8,1,5],4) // 17
maxSubarraySum([4,2,1,6],1) // 6
maxSubarraySum([4,2,1,6,2],4) // 13
maxSubarraySum([],4) // null

function maxSubarraySum(arr, num) {
  if ( num > arr.length){
    return null;
  }
  var max = -Infinity;
  for (let i = 0; i < arr.length - num + 1; i ++){
    temp = 0;
    for (let j = 0; j < num; j++){
      temp += arr[i + j];
    }
    if (temp > max) {
      max = temp;
    }
  }
  return max;
}

시간 복잡도: O(N^2)

리팩토링 후

슬라이딩 윈도우 패턴을 적용한 리팩토링된 코드입니다.

function maxSubarraySum(arr, num){
  let maxSum = 0;
  let tempSum = 0;
  if (arr.length < num) return null;
  for (let i = 0; i < num; i++) {
    maxSum += arr[i];
  }
  tempSum = maxSum;
  for (let i = num; i < arr.length; i++) {
    tempSum = tempSum - arr[i - num] + arr[i];
    maxSum = Math.max(maxSum, tempSum);
  }
  return maxSum;
}

시간 복잡도 O(N)

분할과 정복 패턴 (Divide and Conquer)

분할과 정복 패턴은 데이터 세트를 더 작은 조각으로 나누고, 그런 다음 데이터의 부분 집합에 대해 프로세스를 반복하는 방법입니다. 이를 통해 시간 복잡도를 크게 줄일 수 있습니다.

예시 문제

정렬된 정수 배열을 입력으로 받아 주어진 값을 찾아 그 값이 위치한 인덱스를 반환하는 search 함수를 작성하세요. 값이 발견되지 않으면 -1을 반환해야 합니다.

search([1,2,3,4,5,6],4) // 3
search([1,2,3,4,5,6],6) // 5
search([1,2,3,4,5,6],11) // -1

function search(arr, val){
    for(let i = 0; i < arr.length; i++){
        if(arr[i] === val){
            return i;
        }
    }
    return -1;
}

시간 복잡도: O(N)

리팩토링 후

분할과 정복 패턴을 적용한 리팩토링된 코드입니다.

function search(array, val) {

    let min = 0;
    let max = array.length - 1;

    while (min <= max) {
        let middle = Math.floor((min + max) / 2);
        let currentElement = array[middle];

        if (array[middle] < val) {
            min = middle + 1;
        }
        else if (array[middle] > val) {
            max = middle - 1;
        }
        else {
            return middle;
        }
    }

    return -1;
}

시간 복잡도: O(Log N)

문제 해결 접근법

얼은펭귄 — Thu, 27 Jun 2024 17:09:35 +0900

목표

알고리즘이 무엇인지 이해합니다.
알고리즘을 해결할 계획을 세웁니다.

알고리즘이란?

알고리즘은 특정 작업을 달성하기 위한 과정이나 일련의 단계를 의미합니다. 이는 컴퓨터 과학에서 매우 중요한 개념으로, 문제 해결의 기본입니다.

알고리즘을 알아야 하는 이유

프로그래밍에서 수행하는 거의 모든 작업에는 기본적이든 복잡하든 일종의 알고리즘이 포함됩니다. 문제를 효율적으로 해결하기 위해서는 알고리즘을 이해하고 활용하는 능력이 필요합니다.

문제 해결을 위한 계획을 수립하기

1단계: 문제를 이해하기

문제를 이해하는 것은 첫 번째 단계입니다. 다음 질문들을 통해 문제를 명확히 할 수 있습니다.

문제를 내 방식대로 생각할 수 있는가?
문제가 어떤 입력값을 가지고 있는가?
문제에 대한 해결책에서 나와야 하는 결과가 무엇인가?
입력값이 출력값을 결정할 수 있는가? (문제를 해결할 수 있는 충분한 정보를 가지고 있는가?)
문제의 일부인 데이터의 중요한 부분에 어떻게 레이블을 지정해야 하는가?

예제: 두 숫자의 합계를 반환하는 함수 작성하기

덧셈을 수행하는 함수
입력이 정수인지, 실수인지, 큰 숫자인지 확인
결과가 정수인지, 실수인지, 큰 숫자인지 확인
한 숫자만 입력한 경우 처리 방법 결정 (예: null, undefined, +0)
입력값과 결과값을 명확히 정의

2단계: 구체적 예시를 찾아보기

예시를 통해 문제를 더 잘 이해할 수 있습니다. 예시는 온전성 검사를 제공하므로 최종 해결책이 제대로 작동하는지 확인할 수 있습니다.

간단한 예시로 시작하기
좀 더 복잡한 예시로 진행하기
빈 입력값이 있는 예제 살펴보기
유효하지 않은 입력값이 있는 예제 살펴보기

3단계: 세부 분석

문제를 해결하기 위한 단계를 명확하게 작성합니다. 기본적인 구성 요소들을 정의합니다.

예시: 문자열을 입력받아 각 문자 개수를 반환하는 함수

function charCount(str) {
    // 반환할 객체 생성
    // 문자열을 순회하며, 각 문자에 대해...
        // 만약 문자가 숫자/문자이고 객체에 키가 있다면, 카운트를 하나 증가
        // 만약 문자가 숫자/문자이고 객체에 없으면, 객체에 추가하고 값을 1로 설정
        // 만약 문자가 다른 것(공백, 마침표 등)이면 아무 것도 하지 않음
    // 마지막에 객체 반환
}

4단계: 해결 또는 단순화

문제의 핵심 어려움을 찾으면 일시적으로 이를 무시하고, 단순화된 해결책을 작성한 후 어려움을 다시 통합합니다.

예시:

function charCount(str) {
    // 반환할 객체 생성
    const result = {};
    // 문자열을 순회하며, 각 문자에 대해...
    for(let i = 0; i < str.length; i++) {
        const char = str[i].toLowerCase()
        // 만약 문자가 숫자/문자이고 객체에 키가 있다면, 카운트를 하나 증가
        if(result[char] > 0) {
            result[char]++;
        }else{
        // 만약 문자가 숫자/문자이고 객체에 없으면, 객체에 추가하고 값을 1로 설정
            result[char] = 1;
        }
    }
        // 만약 문자가 다른 것(공백, 마침표 등)이면 아무 것도 하지 않음 (일단은 무시)
    // 마지막에 객체 반환
    return result;
}

5단계: 되돌아 보기와 리팩터링

리팩터링 질문:

결과를 확인할 수 있는가?
결과를 다른 방법으로 도출할 수 있는가?
한눈에 이해할 수 있는가?
다른 문제에 이 결과나 방법을 사용할 수 있는가?
해결책의 성능을 향상시킬 수 있는가?
다른 리팩터링 방법을 생각해볼 수 있는가?
다른 사람들은 이 문제를 어떻게 해결했는가?

function charCount(str) {
    const result = {};
    for(let i = 0; i < str.length; i++) {
        const char = str[i].toLowerCase();
        if(/[a-z0-9]/.test(char)) {
            if(result[char] > 0) {
                result[char]++;
            }else{
                result[char] = 1;
            }
        }
    }
    return result;
}

리팩터링 후

function charCount(str) {
    const result = {};
    for(let char of str) {
        char = char.toLowerCase();
        if(/[a-z0-9]/.test(char)) {
            result[char] = ++result[char] || 1;
        }   
    }
    return result;
}

더 리팩토링을 하면 charAt()을 사용하면 더 빠르다.

Javascript에서 배열과 오브젝트의 빅오 (Big - O)

얼은펭귄 — Wed, 26 Jun 2024 16:29:03 +0900

Javascript에서 배열과 객체는 자주 사용되는 데이터 구조입니다. 이 글에서는 배열과 객체의 성능을 빅오 표기법(Big O Notation)을 통해 비교하고, 배열의 시작 부분에 요소를 추가하는데 비용이 많이 드는 이유와 내장 메서드의 런타임 성능을 분석합니다.

객체의 빅오 표기법

객체는 정렬되지 않은 데이터 구조로, key-value 쌍으로 저장됩니다. 객체는 정렬이 필요 없을 때, 빠른 접근, 입력, 제거를 원할 때 유용합니다.

객체의 빅오

삽입: O(1)
삭제: O(1)
탐색: O(N)
접근: O(1)

내장 메서드의 빅오

Object.keys: O(N)
Object.values: O(N)
Object.entries: O(N)
hasOwnProperty: O(1)

배열의 빅오 표기법

배열은 정렬된 데이터 구조로, 특정 위치에 요소를 추가하거나 제거할 때 성능 차이가 발생합니다.

배열의 빅오

삽입:
- 끝에 추가하면 O(1)
- 앞에 추가하면 O(N) (모든 인덱스를 재정렬해야 하기 때문)
삭제:
- 끝에 추가하면 O(1)
- 앞을 삭제하면 O(N) (모든 인덱스를 재정렬해야 하기 때문)
탐색: O(N)
접근: O(1)

내장 메서드의 빅오

push: O(1)
pop: O(1)
shift: O(N)
unshift: O(N)
concat: O(N)
slice: O(N)
splice: O(N)
sort: O(N * log N)
forEach/map/filter/reduce: O(N)

배열의 시작 부분에 요소를 추가하거나 제거하는 작업은 배열의 모든 요소를 이동시켜야 하므로 O(N)의 시간이 소요됩니다. 반면, 배열의 끝에 요소를 추가하거나 제거하는 작업은 O(1)로 더 효율적입니다. 따라서, 비어있는 배열을 제외하고는 push()와 pop()이 shift()와 unshift()보다 항상 빠릅니다.

빅오 표기법 (Big-O Notation)

얼은펭귄 — Wed, 26 Jun 2024 15:34:22 +0900

목표

빅오 표기법의 필요성
빅오 표기법이 무엇인지
빅오 표기법의 간단한 표현법
시간복잡도와 공간복잡도의 정의
빅오 표기법을 이용한 알고리즘 표기법
로그(log)가 무엇인지

빅오 표기법의 필요성

어떤 문제를 해결하는 두 가지 방법이 있을 때, 하나는 루프를 사용하고, 다른 하나는 리스트나 문자열을 사용하는 방법일 수 있습니다. 무엇이 더 나은지 알기 위해서는 빅오 표기법이 필요합니다. 빅오 표기법을 사용하면 코드를 일반화하고 비교하며 성능을 평가할 수 있는 시스템을 제공합니다.

예시

1부터 N까지 모든 숫자를 더하는 함수를 예로 들어보겠습니다.

// 첫 번째 방법: 루프 사용
function addUpTo(n) {
  let total = 0;
  for (let i = 0; i <= n; i++) {
    total += i;
  }
  return total;
}

// 두 번째 방법: 수학적 공식 사용
function addUpTo(n) {
  return (n * (n + 1)) / 2;
}

어떤 방법이 더 나을까요?

어떤 것이 더 빠를까요?
어떤 것이 더 적은 메모리를 사용할까요?
어떤 것이 더 읽기 쉬울까요?

성능 평가 방법

우선, 코드가 얼마나 빠른지를 설명할 때는 아래와 같이 평가할 수 있습니다.

let t1 = performance.now();
addUpTo(100000000);
let t2 = performance.now();
console.log(`Time: ${(t2 - t1) / 1000} seconds`);

동일한 작업을 하지만 두 번째 코드가 훨씬 빠릅니다. 그러나 performance.now()로 두 시간을 단순히 빼는 것은 불확실하고 완전히 믿을 수 없습니다. 기계마다, 매번 실행할 때마다 결과가 달라질 수 있습니다.

그렇다면 코드 실행 시간을 재는 것보다 컴퓨터가 처리해야 하는 연산 갯수를 세면 됩니다.

예를 들어

function addUpTo(n) {
  return (n * (n + 1)) / 2;
}

위 코드는 * 연산 1번, + 연산 1번, / 연산 1번, 총 3번의 연산이 이루어집니다.

하지만

function addUpTo(n) {
  let total = 0;
  for (let i = 0; i <= n; i++) {
    total += i;
  }
  return total;
}

이 함수는 대충 5n + 2 만큼 연산이 일어납니다.

초기화(let total = 0): 1번
변수 선언(let i = 0): 1번
비교 연산(i <= n): n번 (루프가 n+1번 돌아가므로)
증가 연산(i++): n번 및 n번 선언
덧셈 연산(total += i): n번

이런식으로 연산을 모두 세는건 쉽지 않은 작업이다.

중요한 점은 N이 커질수록 연산의 갯수도 N만큼 늘어난다는 점입니다. 전체적인 추세가 중요합니다.

빅오는 대략적으로 연산의 수를 세는 것에 붙인 공식적인 표현입니다. 입력된 내용이 늘어날수록 알고리즘의 실행 시간이 어떻게 변하는지 설명하는 공식적인 방식입니다. 빅오는 입력 크기와 실행 시간의 관계를 나타냅니다. 일반적으로 가장 높은 실행 시간 값들을 나타냅니다.

빅오 표기법의 간단한 표현법

O(1): 상수 시간 (입력 크기에 관계없이 일정한 시간)
O(log n): 로그 시간 (입력 크기가 커질수록 시간이 느리게 증가)
O(n): 선형 시간 (입력 크기에 비례하여 시간 증가)
O(n log n): 로그 선형 시간 (예: 퀵 정렬)
O(n^2): 이차 시간 (입력 크기의 제곱에 비례하여 시간 증가)
O(2^n): 지수 시간 (입력 크기에 따라 시간 폭발적으로 증가)
O(n!): 팩토리얼 시간 (입력 크기에 따라 시간 급격히 증가)

시간복잡도 그래프

산술 연산은 상수입니다. N의 값에 관계없이 일정한 시간입니다. (예: 2 + 2, 1000000 + 2)
변수에 값을 저장하는 것은 별다른 시간 차이가 없습니다. (예: x = 100, x = 100000)
배열에서 인덱스를 사용하거나 객체에서 키를 사용해서 찾는 것은 상수 시간입니다.
루프가 있으면 복잡도가 루프의 길이와 안에 있는 연산의 곱이 됩니다. for문을 사용해서 배열을 처리할 경우 O(n)입니다.
루프 중첩이 있다면 O(n^2)입니다.

시간 복잡도와 공간 복잡도

지금까지는 시간과 관련된 부분을 걱정했습니다. 이를 시간 복잡도(Time Complexity)라고 합니다. 이제는 입력이 커질수록 알고리즘이 얼마나 많은 공간을 차지하는지에 대해서 얘기해보겠습니다. 이를 공간 복잡도(Space Complexity)라고 합니다.

공간 복잡도는 알고리즘이 사용하는 메모리의 양을 나타냅니다. 이는 주로 두 가지 요소로 구성됩니다:

고정 공간 (Fixed Space): 알고리즘이 사용하는 상수 공간입니다. 예: 함수 내에서 선언되는 변수들
가변 공간 (Variable Space): 알고리즘의 입력 크기에 따라 달라지는 공간입니다. 예: 동적으로 할당되는 배열이나 리스트

예시를 통해 공간 복잡도를 살펴보겠습니다.

// O(1) 공간 복잡도: 고정 공간만 사용
function addUpTo(n) {
  return (n * (n + 1)) / 2;
}

위 함수는 입력 크기와 상관없이 일정한 공간만을 사용합니다. 따라서 공간 복잡도는 O(1)입니다.

// O(n) 공간 복잡도: 가변 공간 사용
function createArray(n) {
  let arr = [];
  for (let i = 0; i < n; i++) {
    arr.push(i);
  }
  return arr;
}

위 함수는 입력 크기 n에 비례하여 배열을 생성합니다. 따라서 공간 복잡도는 O(n)입니다.

공간 복잡도는 알고리즘의 효율성을 평가하는 데 중요한 요소입니다. 입력 크기가 커질수록 알고리즘이 사용하는 메모리가 어떻게 변하는지 이해하면, 더 효율적인 알고리즘을 설계할 수 있습니다.

로그(log)란?

로그는 특정 숫자를 몇 번 곱해야 다른 숫자가 되는지를 나타내는 수학적 개념입니다. 예를 들어, log2(8) = 3은 2를 몇 번 곱해야 8이 되는지를 나타냅니다. 로그 시간 복잡도는 이와 같이 큰 문제를 작은 문제로 나누는 알고리즘에서 주로 나타납니다. 예: 이진 탐색은 로그 시간 복잡도를 가집니다.

[Ubuntu] Please install all available updates for your release before upgrading 문제 해결

얼은펭귄 — Wed, 10 Jan 2024 16:09:18 +0900

서버에 설치되어 있는 node.js 버전을 20으로 올리기 위해서 ubuntu 버전을 18 버전에서 20 버전으로 업그레이드하는 도중

"Please install all available updates for your release before upgrading" 라는 오류 메세지를 마주했다

이 글에서는 이 문제를 해결한 과정을 공유하고자 한다.

1. version 업데이트 전에 패키지 업데이트 및 업그레이드

sudo apt update
sudo apt upgrade

2. mognodb 관련 패키지들이 업데이트 되지않음

3. 현재 ubuntu 버전 확인 및 업데이트 진행

lsb_release -a // 현재 버전 확인
sudo do-release-upgrade // 업그레이드 가능한 ubuntu 버전으로 업그레이드

4. Please install all available updates for your release before upgrading 오류 발생

리서치 결과 해당 패키지들을 지우고 다시 삭제하는 방법이 있었지만 지우지 못하는 상황이였다.

그래서 개별적으로 패키지들을 업데이트 해줬다. 왜 인지는 잘 모르겠으나 위 1번 명령어로 전체 업데이트가 되지 않았다.

sudo apt install --only-upgrade 패키지명

sudo apt install --only-upgrade mongodb-org
sudo apt install --only-upgrade mongodb-org-database
sudo apt install --only-upgrade mongodb-org-mongos
sudo apt install --only-upgrade mongodb-org-server
sudo apt install --only-upgrade mongodb-org-shell
sudo apt install --only-upgrade mongodb-org-tools

5. 개별적인 업데이트 완료 후 버전 업그레이드

[기타] 역기획 이란?

얼은펭귄 — Fri, 15 Sep 2023 14:49:42 +0900

이 글에서는 제품과 서비스의 세계에서 굉장히 중요한 역할을 하는 "역기획"에 대해 이야기하려고 한다. 좋아하는 게임이나 사용하는 앱, 서비스가 어떻게 구성되었는지 궁금해하셨던 적이 있다면, 이런 호기심을 해결해 줄 도구가 바로 역기획입니다.

역기획이란?

역기획은 주로 게임, 소프트웨어, 서비스 등의 제품을 분석하여 그 제품의 기획 과정을 추정하거나 재구성하는 방법을 말한다. 제품이 어떻게 구성되었는지, 왜 그렇게 설계되었는지를 이해하는 것이 주 목적이다.

왜 역기획을 해야하는가?

경쟁 분석: 다른 회사의 제품을 분석하여 그 특징, 장단점을 파악하고, 자사의 제품과 비교하는데 사용될 수 있다.
학습 목적: 개발자나 디자이너들이 특정 기술이나 디자인 패턴을 배우기 위해 좋은 예시로 사용된다.
기능 개선 및 참고: 기존의 제품에서 어떤 부분이 잘 작동하는지, 어떤 부분이 개선되어야 하는지를 파악하여 참고하거나 기능 개선에 활용될 수 있다.

역기획의 절차

제품 사용: 먼저 해당 제품을 철저히 사용하여 기능과 사용자 경험을 파악한다.
문서화: 사용한 경험과 제품의 주요 기능, 구조, 디자인 패턴 등을 문서화한다.
분석: 문서화된 정보를 바탕으로 제품의 핵심 목표, 사용자 대상, 기술적인 구조 등을 분석한다.
결과 공유: 역기획의 결과를 팀 또는 관련된 사람들과 공유하며, 얻어진 통찰을 바탕으로 토론하고 향후 방향성을 결정한다.

역기획은 제품 개발에 깊은 통찰력을 제공하며, 다양한 측면에서의 제품 이해와 개선에 큰 도움이 된다.

[OS] 가상 메모리(swap) 사용 시 CPU 점유율이 폭증하는 이유

얼은펭귄 — Thu, 14 Sep 2023 14:40:25 +0900

연구팀을 위해 데이터를 뽑는 도중 큰 데이터를 뽑다가 서버를 터트렸다.

해당 원인에 대해서 공부했던 내용에 대해서 서술한다.

가상 메모리(swap)란?

가상 메모리는 물리적인 RAM이 부족할 때 디스크 공간의 일부를 RAM처럼 사용하는 시스템이다. 이는 임시 방편으로 RAM이 부족한 상황에서 프로세스를 계속 실행하게 해준다.

예를 들어, 사용자가 8GB RAM을 갖춘 컴퓨터에서 10GB의 메모리를 요구하는 대규모 응용 프로그램을 실행하려고 시도한다면, 실제 물리적인 RAM만으로는 충분하지 않다. 이때, 운영체제는 2GB의 데이터를 하드 디스크의 swap 영역에 저장하게 된다.

이로 인해 사용자는 마치 10GB의 RAM이 있는 것처럼 프로그램을 실행할 수 있다. 하지만, 디스크 I/O는 RAM보다 느리므로 swap을 사용할 때의 성능은 RAM을 직접 사용할 때보다 느릴 수 있다.

가상 메모리의 동작 원리

이 때 물리 메모리(RAM)가 부족하게 되면, 운영체제는 잘 사용하지 않는 메모리 페이지를 가상 메모리 영역으로 이동(swap out)시킨다. 반대로, 해당 페이지가 다시 필요하면 가상 메모리에서 물리 메모리로 다시 가져온다(swap in). 이 때 디스크 I/O를 사용한다.

CPU 점유율의 급증의 원인

I/O 연산: 디스크 I/O는 RAM에 비해 상당히 느리다. swap 영역에 데이터를 쓰거나 읽는 것은 RAM에서 직접 데이터를 처리하는 것에 비해 훨씬 오래 걸린다. 따라서, swap을 자주 사용하면 이로 인해 발생하는 I/O 연산이 CPU 부하를 증가시킨다.

페이지 폴트: 물리 메모리에서 페이지가 사라지고 swap 영역으로 이동하면, 해당 페이지에 접근할 때 페이지 폴트(page fault)가 발생한다. 페이지 폴트(page fault)는 프로세스가 접근하려고 하는 메모리 페이지가 물리적인 메모리(RAM)에 로드되어 있지 않을 때 발생하는 상황을 말한다. 페이지 폴트가 발생하면 운영체제는 해당 페이지를 물리 메모리에 로드해야 한다. 이런 페이지 폴트 처리도 CPU 부하를 증가시키는 원인 중 하나이다.

해결 방안

메모리 추가: 물리 메모리를 추가하여 RAM 용량을 늘리는 것이 가장 확실한 해결책이다.

코드 개선: 가상 메모리를 사용하지 않게 코드를 잘 짜자 (ex) 큰 데이터를 전부 메모리에 올리지 않는다)

가상 메모리는 물리 메모리가 부족할 때 임시로 사용하는 메모리로, 성능 문제의 주요 원인이 될 수 있다. 이를 효과적으로 관리하려면 시스템의 메모리 사용 패턴을 잘 이해하고, 적절한 최적화 방법을 적용해야 한다.

[Shebang] Shebang(#!)이란?

얼은펭귄 — Fri, 8 Sep 2023 15:24:31 +0900

개발자라면 한번쯤 파일 최상단에 #!로 시작하는 "#! /bin/bash" 또는 "#!/usr/bin/env node" 이런 형식의 문자열을 본적이 있을것이다.

이 글에서는 프로그래밍 스크립트에서 자주 볼 수 있는 ‘Shebang’이라는 특수한 기호에 대해 알아보자.

Shebang이란?

Shebang은 스크립트의 가장 윗부분에 위치하는 #!로 시작하는 라인을 말한다. 주로 Unix와 유사한 운영체제에서 사용되며, 이 라인은 스크립트를 실행할 때 어떤 인터프리터를 사용할 것인지 시스템에게 알려준다.

예시

#!/bin/bash
echo "Hello, World!"

위 스크립트에서 #!/bin/bash는 이 스크립트를 bash 쉘로 실행하라는 것을 나타낸다.

#!/usr/bin/env node
console.log("Hello from Node.js!");

이 스크립트는 Node.js 환경에서 실행된다.

왜 Shebang이 필요할까?

스크립트는 여러가지 프로그래밍 언어로 작성될 수 있다. 예를 들어, Python, Perl, Ruby, Node.js 등 다양한 언어가 있다. Shebang은 스크립트를 실행할 때 적절한 인터프리터를 자동으로 선택해서 사용하게 도와준다.

#!/usr/bin/env의 의미

대부분의 시스템에서는 특정 인터프리터의 절대 경로를 shebang에 직접 지정한다. 그러나 #!/usr/bin/env를 사용하면 환경변수 $PATH에서 해당 인터프리터를 검색하여 사용한다. 이 방식은 스크립트가 여러 시스템에서 동작할 때 인터프리터의 위치가 다를 수 있으므로 유용하다.

주의할 점

Shebang은 반드시 파일의 첫 줄에 있어야 한다.
Shebang 뒤에 오는 경로는 인터프리터의 절대 경로여야 한다. 예: #!/usr/bin/python3

마무리

Shebang은 스크립트를 작성하고 실행할 때 꼭 알아두면 좋은 지식 중 하나이다. Shebang을 보게 되면, 그 의미와 용도를 정확히 이해할 수 있을 것이다.

[암호화 기법] 봉투 암호화 (Envelope encryption)

얼은펭귄 — Fri, 25 Aug 2023 14:03:42 +0900

데이터 보안은 현대 디지털 환경에서 가장 중요한 주제 중 하나입니다. 봉투 암호화는 이 보안 전략의 핵심적인 부분으로 자리 잡았습니다. 이 기법을 통해 기업들은 중요한 정보를 안전하게 보호하면서도 효율적인 키 관리를 유지할 수 있습니다. 이 글에서는 봉투 암호화의 근본적인 원리부터 구체적인 작동 방식까지 한층 더 깊게 알아보겠습니다.

1. 봉투 암호화의 기본 원리

봉투 암호화는 이름에서 알 수 있듯이 '봉투'의 개념을 기반으로 합니다. 여기서 '봉투'는 마스터 키에 의해 암호화된 데이터 키를 의미하며, 이 데이터 키는 실제 데이터의 암호화와 복호화에 사용됩니다.

2. 봉투 암호화의 주요 구성요소

두 가지 주요 키로 구성됩니다.

데이터 키(Data Key): 이 키는 실제 데이터를 암호화하거나 복호화하는 데 사용됩니다. 각 데이터 세트 또는 세션마다 새로운 데이터 키가 생성될 수 있습니다.
마스터 키(Master Key): 데이터 키를 암호화하고 복호화하는 데 사용됩니다. 이 키는 안전하게 보관되어야 하며, 키 관리의 중심이 됩니다.

3. 암호화 과정의 세부 사항

봉투 암호화의 암호화 과정은 다음과 같이 진행됩니다.

1. 데이터 키 생성: 먼저, 유니크한 데이터 키가 생성됩니다.
2. 실제 데이터 암호화: 생성된 데이터 키를 사용하여 원본 데이터를 암호화합니다.
3. 데이터 키 암호화: 마스터 키를 사용하여 데이터 키를 암호화합니다.

4. 복호화 과정의 세부 사항

데이터를 안전하게 복호화하려면 다음 과정을 따릅니다.

1. 데이터 키 복호화: 마스터 키를 사용하여 암호화된 데이터 키를 복호화합니다.
2. 실제 데이터 복호화: 복호화된 데이터 키를 사용하여 암호화된 데이터를 복호화하여 원본 데이터를 얻습니다.

5. 봉투 암호화의 장점

봉투 암호화는 중앙화된 키 관리 시스템을 통해 기업이 키 관리의 복잡성을 크게 줄일 수 있도록 해줍니다. 또한, 각 데이터나 세션마다 다른 데이터 키를 생성할 수 있기 때문에 데이터 별로 고유한 보안 레벨을 제공합니다.

6. 실제 활용 사례: 클라우드 서비스

AWS의 KMS(Key Management Service)와 같은 클라우드 기반의 키 관리 서비스는 봉투 암호화를 활용하여 사용자의 데이터를 효과적으로 보호합니다. 이를 통해 클라우드 환경에서도 데이터의 보안을 철저히 유지할 수 있습니다.

봉투 암호화는 현대 디지털 보안 전략의 핵심 부분으로, 데이터의 보호와 효율적인 키 관리를 동시에 가능하게 합니다. 이러한 이해를 바탕으로 기업과 개인은 더욱 강력한 보안 환경을 구축할 수 있을 것입니다.

[Javascript] async 함수를 사용할때 return이 없어도 되는가?

얼은펭귄 — Wed, 16 Aug 2023 14:02:21 +0900

비동기 프로그래밍에는 많은 난관이 있다. JavaScript에서는 이를 간단하게 만들어 주는 async/await 패턴이 있다. 하지만 이 패턴 내에서도 종종 개발자들이 혼란스러워하는 부분이 있다. 그 중 하나가 바로 async 함수 내부의 return에 관한 것이다.

기본적인 함수와 반환 값

일반적인 함수에서 값을 반환하지 않으면, 해당 함수는 undefined를 반환합니다. 그렇다면 async 함수에서는 어떻게 될까

function normalFunction() {
  console.log("This is a normal function");
}

const result = normalFunction();
console.log(result);  // undefined

async 함수의 기본 동작 방식

async 함수는 항상 Promise 객체를 반환한다. 만약 함수 내에서 명시적으로 값을 반환하지 않는다면, 그 함수는 undefined 값을 resolve하는 Promise를 반환한다.

const asyncFunction = async () => {
  await SomethingPromise();
  console.log("This is an async function");
}

const asyncResult = await asyncFunction();
console.log(asyncResult);  // undefined

왜 async 함수는 이렇게 동작하는가?

JavaScript의 async/await 패턴의 주 목적은 비동기 코드를 마치 동기 코드처럼 쓰게 만드는 것이다. async 함수가 Promise를 반환함으로써, await 은 해당 Promise가 resolve되거나 reject될 때까지 기다릴 수 있다.

따라서, async 함수 내에서 반환된 값이 없더라도, 함수 자체가 끝나면 해당 Promise는 resolve 상태가 되어 await 다음의 코드가 실행될 수 있게 됩니다.

실제 개발 과정에서, async 함수 내에서 항상 값을 반환할 필요는 없다. 종종 데이터를 가져오거나 다른 비동기 작업을 수행한 후에, 그 결과를 반환하지 않고 다른 작업을 진행하는 경우도 많다. 이러한 패턴을 이해하면, 비동기 코드의 흐름과 동작 방식을 더욱 잘 이해하고 활용할 수 있다.

JavaScript의 async/await는 비동기 로직을 쉽게 이해하고 구현할 수 있도록 도와준다. 함수의 종료와 Promise의 resolve 시점을 명확하게 파악하는 것은 이 패턴을 효과적으로 활용하기 위한 중요한 핵심입니다.

[Mongodb] explain을 활용한 mongodb 쿼리 최적화

얼은펭귄 — Wed, 2 Aug 2023 15:31:24 +0900

MongoDB, 대용량 데이터를 처리하고 저장하는 데 있어서 매우 효과적인 NoSQL 데이터베이스라는 사실은 이미 잘 알려져 있다. 하지만 대량의 데이터를 다루다 보면 쿼리의 효율성은 중요한 이슈가 된다. 그래서 MongoDB는 사용자들이 쿼리 성능을 향상시킬 수 있도록 explain() 메소드를 제공한다. 나의 경우 쿼리가 인덱스를 타는지 여부를 확인하기 위해 사용했다.

explain() 메소드는 MongoDB 쿼리가 어떻게 동작하며 어떻게 최적화될 수 있는지에 대한 정보를 제공한다. 이 메소드의 사용법은 간단하다. 작성한 쿼리에 .explain()을 추가하면 된다.

db.getCollection("test").find({test: "Test"}).explain()

MongoDB는 .explain()에 대해 세 가지 모드를 제공한다. "queryPlanner", "executionStats", "allPlansExecution"이 그것이다. 이들 모드는 각각 쿼리의 최적화 계획, 실제 실행 통계, 그리고 MongoDB 쿼리 최적화기가 고려한 모든 계획에 대한 통계를 제공한다.

.explain() 메소드를 실행하면, 반환되는 정보는 복잡한 JSON 객체 형태이다. 이 객체는 여러 중요한 정보를 포함하고 있다.

queryPlanner: MongoDB 쿼리 플래너가 쿼리를 어떻게 해석했는지, 어떤 인덱스가 사용되었는지 등의 정보를 제공한다.
executionStats: 쿼리 실행에 관한 상세 통계를 제공한다. 여기에는 쿼리 실행 시간, 검토된 문서의 수, 반환된 문서의 수 등의 정보가 포함되어 있다.
serverInfo: 쿼리를 실행한 서버에 대한 정보를 제공한다.

이 중에서 winningPlan과 executionStats 섹션은 특히 중요하다. winningPlan 섹션은 쿼리 최적화기가 선택한 최적의 쿼리 실행 계획을 보여주며, 이 정보를 통해 인덱스가 올바르게 사용되었는지, 스캔된 문서의 수가 적절한지 등을 판단할 수 있다. executionStats 섹션은 쿼리 실행에 관한 상세 통계를 제공하며, nReturned, executionTimeMillis, totalKeysExamined, totalDocsExamined 등의 필드를 통해 쿼리의 효율성을 평가할 수 있다.

하지만 .explain() 메소드는 시스템에 부하를 줄 수 있으므로, 실제 서비스 환경에서는 주의해서 사용해야 한다. 대신, 개발 환경이나 별도의 테스트 환경에서 사용하는 것이 바람직하다. 이 포스트가 MongoDB 쿼리 최적화에 있어서 도움이 되길 바란다.

Contact

얼은펭귄 — Mon, 26 Jun 2023 17:28:55 +0900

gangsuyun6@gmail.com

github

https://github.com/rkdden

[Error] 갑자기 도메인 접속이 안될때 해결방법

얼은펭귄 — Fri, 23 Jun 2023 13:27:14 +0900

최근 팀에서 특이한 문제를 경험했다. 서비스 중인 도메인에 대해서 가끔 접속이 가능했다가 안되는 상황이 반복되었다. 해당 원인을 찾은 과정과 해결 방법에 대해 소개한다.

이 문제를 해결하기 위해서 여러가지 방법으로 문제를 확인했다.

예시에서 설명을 위해 접속이 안되는 도메인은 example.com 으로 가정한다.

해당 서버의 IP는 0.0.0.0으로 가정한다.

네트워크 구조가 단순하게 설명하면

Cloudflare -- Load balancer -- Server

구조로 되어 있었다.

서버의 IP로 직접 접근

이 방법은 성공했다. IP 주소를 통해서 직접 접근이 가능한 것은 서버 자체에는 문제가 없다는 것을 의미했다.

로드밸런서로 접근

이 방법역시 성공했다. 로드밸런서를 통해서 접근이 가능했던것은 마찬가지로 로드밸런서 자체에는 문제가 없다는 것을 의미했다.

네임서버로 접근

여기서 문제가 발생했다. 네임서버를 통해서 접근할 수 없다는 것은 DNS에 문제가 있다는 것을 나타냈다.

하지만 네임서버 자체는 정상적으로 작동하고 있었고, example.com에 대해서만 조회가 되었다 안되었다 했었다.

nslookup, dig, ping 을 사용한 네트워크 상태 확인

이 또한 마찬가지로 서버, 로드밸런서, 네임서버 자체에는 문제가 없었으나

해당 "도메인(example.com)"에서만 문제가 발생했다.

모든 원인을 파악해도 원인을 찾을수가 없었다. 일시적으로 통신사쪽 문제라고 결론을 짓고 다음날까지 기다려보아도 문제가 해결되지 않았다.

Whois 조회

위의 검사결과를 바탕으로 원인을 줄여나간 결과, 결과적으로 도메인 자체에 문제가 있을수 있다는 생각이 들었다.

Whois에서 example.com을 조회후 정보를 확인한 결과 해당 도메인이 "clientHold" 상태인것을 확인했다.

clientHold는 도메인이 일시적으로 사용 중지된 상태를 나타내는데, 이는 보통 도메인 소유자가 도메인을 삭제하거나 결제 실패등 다양한 이유로 발생할 수 있었다.

결과

결과적으로는 팀중 한명이 실수로 도메인을 삭제해서 일어난 현상이였다.

그렇다면 어떻게 도메인 접속이 되었다가 안 되었다가 하는 현상이 일어났을까?

이 부분은 DNS의 작동 방식과 관련이 있다.

DNS는 인터넷의 전화번호부와 같다. 사용자가 웹사이트의 도메인 이름을 입력하면, DNS는 이 이름을 해당 웹사이트의 IP 주소로 변환한다. 그런데 이 변환 정보가 저장되는 네임서버에 변경사항이 생기면, 그 정보가 모든 네임서버에 전파되는 데는 시간이 걸린다.

도메인이 삭제되면, 해당 도메인에 대한 정보가 네임서버에서 제거된다. 하지만 이 정보가 모든 네임서버에 즉시 반영되지는 않는다. 따라서, 어떤 네임서버는 아직 도메인 정보를 가지고 있을 수 있고, 어떤 네임서버는 도메인 정보를 이미 제거했을 수 있다.

이런 상황에서 사용자가 웹사이트에 접속하려고 하면, 사용자의 장치(핸드폰, 노트북 등)는 DNS 쿼리를 통해 도메인 이름을 IP 주소로 변환하려고 시도한다. 만약 DNS 쿼리가 도메인 정보를 아직 가지고 있는 네임서버로 전달되면, 웹사이트 접속이 성공적으로 이루어진다. 그러나 도메인 정보를 이미 제거한 네임서버로 전달되면, 웹사이트 접속이 실패하게 된다.

이렇게 해서, 도메인 삭제 후 도메인 접속이 되었다 안 되었다하는 현상이 발생하게 된 것이다.

이렇게 팀에서 도메인 문제를 찾아내고 해결할 수 있었다.

[Github Actions] GitHub Actions을 이용한 Slack 알림 설정하기

얼은펭귄 — Fri, 16 Jun 2023 15:40:45 +0900

GitHub Actions는 CI/CD를 위한 강력한 도구이다. 소프트웨어 개발 과정에서 다양한 작업들을 자동화할 수 있는데, 그 중 하나가 빌드나 테스트의 성공 및 실패를 Slack으로 알림 보내는 것이다. 이 글에서는 GitHub Actions과 Slack을 연동하는 방법에 대해 설명한다.

슬랙 앱 생성

먼저, Slack 알림을 받기 위해서는 Slack 앱이 필요하다.

1. Slack API 사이트에 접속
2. "Create an App" 버튼을 클릭한다.

3. "From scratch" 옵션을 선택하고 앱 이름과 워크스페이스를 설정한 후, "Create App"을 클릭한다.

4. 왼쪽 메뉴에서 "Incoming Webhooks"을 클릭하고, 페이지 상단의 "Activate Incoming Webhooks" 스위치를 켠다.
5. "Add New Webhook to Workspace"를 클릭하여 새 웹훅을 추가한다.

6. 알림을 받고 싶은 채널을 선택하고, "허용" 버튼을 누른다.

7. 생성된 웹훅 URL을 복사 한다. 이 URL은 GitHub Actions 설정에서 사용된다.

GitHub Actions 설정

이제 GitHub Actions를 설정하여 빌드나 테스트 결과를 Slack으로 보낼 수 있도록 한다.

1. GitHub 저장소로 이동하여 ".github/workflows" 디렉토리를 생성한다. 여기에 워크플로우 파일을 생성한다. (예: "main.yml") (이미 있다면 생략해도 괜찮다.)
2. 워크플로우 파일에 steps 마지막에 다음과 같이 작성하여 Slack 성공또는 실패 알림을 보낼 수 있도록 설정한다.

성공한 경우에만 보내는 알림

- name: Notify Slack on Success
  if: success() # 이 step은 job이 성공한 경우에만 실행된다.
  id: slack-success
  uses: slackapi/slack-github-action@v1.24.0
  with:
    payload: |
      {
        "channel": "채널 ID",
        "attachments": [
          {
            "color": "#36a64f", # 성공시 연두색
            "title": "${{ github.repository }}", # 제목은 깃헙 레포지토리
            "title_link": "https://github.com/${{github.repository}}", # 제목 클릭시 레포지토리로 이동
            "text": "GitHub Action 성공",
            "fields": [
              {
                "title": "Repository",
                "value": "${{ github.repository }}",
                "short": true
              },
              {
                "title": "Tag",
                "value": "${{ github.ref_name }}",
                "short": true
              }
            ]      
          }
        ]
      }
  env:
    SLACK_WEBHOOK_URL: "위에서 설정한 WEBHOOK URL"
    SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK

성공시

실패한 경우에만 보내는 알림

- name: Notify Slack on Failure
  if: failure() # 이 step은 job이 실패한 경우에만 실행됩니다.
  id: slack-failure
  uses: slackapi/slack-github-action@v1.24.0
  with:
    payload: |
      {
        "channel": "채널 ID",
        "attachments": [
          {
            "color": "#ff0000", # 실패시 빨간색
            "title": "${{ github.repository }}", # 제목은 깃헙 레포지토리
            "title_link": "https://github.com/${{github.repository}}", # 제목 클릭시 레포지토리로 이동
            "text": "GitHub Action 실패 :x:",
            "fields": [
              {
                "title": "Repository",
                "value": "${{ github.repository }}",
                "short": true
              },
              {
                "title": "Tag",
                "value": "${{ github.ref_name }}",
                "short": true
              }
            ]      
          }
        ]
      }
  env:
    SLACK_WEBHOOK_URL: "위에서 설정한 WEBHOOK URL"
    SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK

실패 시

성공 실패 여부 관계없이 알림을 보내고 싶다면 두개 다 추가하면 된다.

결과

이 글을 통해 GitHub Actions과 Slack을 연동하는 방법에 대해 알아보았다. 이제 빌드나 테스트의 성공, 실패 여부에 따라 자동으로 Slack 알림을 받을 수 있다. CI/CD 프로세스를 더욱 효율적으로 관리할 수 있게 되었습니다. 이 외에도 GitHub Actions은 다양한 자동화 작업을 수행할 수 있으니, 더 많은 활용 방법을 찾아보시기 바란다.

[MongoDB] MongoDB 검색 성능 극대화 방법: 인덱스와 컴파운드 인덱스의 활용

얼은펭귄 — Tue, 13 Jun 2023 10:20:44 +0900

이번 글에서는 MongoDB에서 데이터 검색 성능을 최대한 높이기 위한 방법을 소개한다. 이 방법의 핵심은 '인덱스'와 '컴파운드 인덱스'라는 두 개념을 이해하고 활용하는 것이다.

1. 인덱스

인덱스는 MongoDB에서 데이터를 효율적으로 찾기 위한 데이터 구조다. 인덱스가 없을 경우, MongoDB는 쿼리에 맞는 문서를 찾기 위해 컬렉션의 모든 문서를 검색해야 한다. 하지만 인덱스가 있을 경우, MongoDB는 인덱스를 활용하여 필요한 문서를 더 빠르게 찾을 수 있다. 예를 들어, MongoDB에서 'username'이라는 필드에 인덱스를 추가하는 방법은 다음과 같다.

db.users.createIndex({ username: 1 });

2. 컴파운드 인덱스

컴파운드 인덱스는 두 개 이상의 필드를 결합한 인덱스를 말한다. 이 인덱스는 필드의 순서에 따라 정렬되며, 이 순서는 쿼리 성능에 큰 영향을 미친다. 예를 들어, MongoDB에서 'username' 필드와 'email' 필드에 컴파운드 인덱스를 추가하는 방법은 다음과 같다.

db.users.createIndex({ username: 1, email: 1 });

3. 인덱스와 컴파운드 인덱스의 차이점 및 사용 시기

인덱스와 컴파운드 인덱스의 차이점을 이해했으니, 각각 언제 사용해야 하는지를 알아볼 필요가 있다. 인덱스는 단일 필드에 대한 빠른 조회를 가능하게 해주며, 컴파운드 인덱스는 여러 필드를 결합하여 빠른 조회를 가능하게 해준다. 따라서, 단일 필드를 자주 쿼리하는 경우에는 인덱스를, 여러 필드를 동시에 쿼리하는 경우에는 컴파운드 인덱스를 사용하는 것이 좋다. 그러나 인덱스 생성 및 유지에도 비용이 발생하므로, 필요한 만큼만 인덱스를 생성하고 유지하는 것이 중요하다. 인덱스가 검색 성능을 향상시키지만, 과도하게 생성하면 오히려 성능 저하를 일으킬 수 있다.

이를 통해 MongoDB의 검색 성능을 극대화하는 방법을 이해하였다. 적절한 인덱스와 컴파운드 인덱스의 활용을 통해 MongoDB에서 데이터를 더 효율적으로 검색할 수 있다는 것을 기억하자.

[Elasticsearch] Elasticsearch에서 발생한 데이터 타입 변경 문제와 해결

얼은펭귄 — Tue, 23 May 2023 18:26:00 +0900

Elasticsearch 환경에서 로그 데이터의 특정 프로퍼티를 string 타입에서 object 타입으로 변경하는 과정에서 문제가 발생하였다. 데이터 타입을 변경한 후 해당 로그가 더 이상 기록되지 않았다. 해당 문제의 원인 파악과 해결 방법을 알아보자.

원인

Elasticsearch는 스키마가 유연한 문서 기반 데이터베이스로서, 데이터의 구조를 미리 정의하지 않고도 데이터를 저장할 수 있다. 하지만 데이터를 한 번 특정 형식으로 인덱싱하면, 이후 해당 인덱스의 맵핑을 변경할 수 없다.

나의 경우, 문자열(string)로 인덱싱된 특정 필드를 나중에 객체(object)로 변경하려고 하면 문제가 발생했다. Elasticsearch는 새로운 데이터를 기존 인덱스에 맞게 강제로 변환하려고 시도하며, 이 과정에서 에러가 발생하게 된다.

해결법

이 문제를 해결하기 위해 주로 다음 두 가지 방법이 사용된다.

1. 새로운 인덱스를 만들고, 새로운 맵핑을 정의한 후 데이터를 재인덱싱한다. 이를 통해 데이터 구조의 변경을 수용할 수 있다.

2. 필드 이름을 변경하여 새로운 필드로 취급하게 만든다. 이 경우, 기존 데이터와 새로운 데이터가 동일한 인덱스 내에 다른 필드로 존재하게 된다.

이 문제를 방지하기 위한 핵심 전략은 데이터의 구조를 미리 잘 계획하고, 필요한 경우 적절한 맵핑을 사용하는 것이다.

이미 데이터가 저장된 경우 input type을 마음대로 바꾸지말자..

[Node.js] assert.doesNotThrow와 assert.doesNotReject의 차이점

얼은펭귄 — Sun, 14 May 2023 16:36:35 +0900

Node.js에서는 코드의 동작을 검증하기 위해 다양한 단언(assertion) 함수들을 제공하고 있다. 이 중 assert.doesNotThrow()와 assert.doesNotReject() 함수는 코드 블록이 에러를 발생시키지 않는다는 것을 확인하는데 사용된다. 그러나 이 두 함수는 각각 다른 유형의 코드에 적용되므로 그 차이점을 이해하는 것이 중요하다.

1. assert.doesNotThrow(block[, error][, message]): 이 함수는 동기 코드 블록이 주어진 에러를 발생시키지 않는지 확인한다. 만약 코드 블록이 에러를 발생시키면, 그 에러는 무시되고 대신 AssertionError가 발생한다. 선택적으로 error 인자를 제공하여 특정 타입의 에러만 검사할 수 있다. 아래는 예시이다.

const assert = require('assert');

function doesNotError() {
  if (Math.random() < 0.5) {
    throw new Error('Random error!');
  }
}

try {
  assert.doesNotThrow(
    doesNotError,
    Error,
    'The function doesNotError has thrown an exception'
  );
  console.log('The function doesNotError has not thrown an exception');
} catch (err) {
  console.error(err);
}

2. assert.doesNotReject(block[, error][, message]): 이 함수는 비동기 코드 블록이 주어진 에러를 발생시키지 않는지 확인한다. block은 Promise를 반환해야 한다. 만약 Promise가 거부되면, 그 거부 값은 무시되고 대신 AssertionError가 발생한다. 아래는 예시이다.

const assert = require('assert');

async function doesNotReject() {
  if (Math.random() < 0.5) {
    throw new Error('Random error!');
  }
}

assert.doesNotReject(
  doesNotReject(),
  Error,
  'The function doesNotReject has thrown an exception'
)
.then(() => console.log('The function doesNotReject has not thrown an exception'))
.catch((err) => console.error(err));

결국, assert.doesNotThrow()는 동기 코드를, assert.doesNotReject()는 Promise를 반환하는 비동기 코드를 검사하는데 사용된다. 이들 함수를 이해하고 적절히 사용함으로써, 코드가 예상대로 동작하는지 확신할 수 있고, 그렇지 않다면 어디서 문제가 발생하는지를 식별할 수 있다.

[Typescript] TypeScript의 모듈 파일과 전역 모듈의 차이점 및 예제

얼은펭귄 — Sun, 7 May 2023 23:55:26 +0900

TypeScript는 자바스크립트에 정적 타입을 도입하여 코드의 안정성과 가독성을 높이게 된다. TypeScript를 사용하면 코드 구조화가 중요한데, 이에 관련하여 모듈 파일과 전역 모듈에 대해 설명하고자 한다. 예제 코드를 통해 이를 이해해보자.

1. 전역 모듈과 모듈 파일의 정의

TypeScript에서 파일은 기본적으로 다음 두 가지로 구분된다.

전역 모듈: 파일에 아무런 import나 export 문이 없는 경우, 해당 파일은 전역 모듈로 간주된다.
모듈 파일: 파일에 import나 export 문이 하나라도 있는 경우, 해당 파일은 모듈 파일로 간주된다.

2. 전역 모듈의 특징 및 예제

전역 모듈에서 정의된 요소들은 전역 범위에서 사용할 수 있다. 이 경우, 다른 파일에서 정의된 요소들을 명시적으로 가져올 필요가 없다. 그러나 이 방식은 TypeScript 컴파일 과정에서는 오류가 발생하지 않지만, 실행 시간에 오류가 발생할 수 있다.

예를 들어, 다음과 같은 전역 모듈 파일이 있다고 가정해보자.

// globalModule.ts
class GlobalClass {
  public sayHello() {
    console.log("Hello from GlobalClass");
  }
}

다른 파일에서 GlobalClass를 사용하려면, 아무런 import 문 없이 사용할 수 있다. 그러나 런타임에서는 오류가 발생된다.

// main.ts 
const instance = new GlobalClass();
instance.sayHello(); // 출력: Hello from GlobalClass

그러나 전역 모듈을 사용하면 코드 관리가 어려워지고, 이름 충돌이 발생할 가능성이 높아진다. 따라서 권장되지 않는다.

3. 모듈 파일의 특징 및 예제

모듈 파일에서 정의된 요소들은 기본적으로 해당 파일 범위 내에서만 사용할 수 있다. 다른 파일에서 이 요소들을 사용하려면, 명시적으로 export해야 하고, 다른 파일에서 이 요소들을 사용하려면 import를 통해 가져와야 한다.

예를 들어, 다음과 같은 모듈 파일이 있다고 가정해보자.

// moduleFile.ts
export class ModuleClass {
	public sayHello() {
		console.log("Hello from ModuleClass"); 
    }
}

다른 파일에서 ModuleClass를 사용하려면, import를 통해 명시적으로 가져와야 한다.

// main.ts
import { ModuleClass } from "./moduleFile";
const instance = new ModuleClass();
instance.sayHello(); // 출력: Hello from ModuleClass

4. 아무 import 문이 없을 때 동작하지 않는 이유

아무 import 문이 없는 경우, 해당 파일은 전역 모듈로 간주되어 해당 파일에서 정의된 요소들이 전역 범위에서 사용 가능하다.

반면에, 파일에 import 문이 있는 경우 해당 파일은 모듈 파일로 간주되어 해당 파일에서 정의된 요소들이 다른 파일에서 사용되지 않게 된다. 이 경우, 다른 파일에서 사용하려면 해당 요소를 export하고 사용하려는 파일에서 import하여야 한다.

이러한 이유로, 아무 import 문이 없는 파일에서는 동작하지만 import 문이 있는 경우 동작하지 않는 상황이 발생할 수 있다.

예를 들어, 다음과 같은 전역 모듈과 모듈 파일이 있다고 가정해보자.

// globalModule.ts
class GlobalClass {
  public sayHello() {
    console.log("Hello from GlobalClass");
  }
}

// moduleFile.ts
export class ModuleClass {
  public sayHello() {
    console.log("Hello from ModuleClass");
  }
}

main.ts 파일에서 아래와 같이 import 문이 없으면, GlobalClass는 사용 가능하지만 ModuleClass는 사용할 수 없다.

// main.ts
const globalInstance = new GlobalClass();
globalInstance.sayHello(); // 런타임 오류: GlobalClass is not defined

const moduleInstance = new ModuleClass(); // 오류: ModuleClass를 찾을 수 없음
moduleInstance.sayHello();

main.ts 파일에서 아래와 같이 ModuleClass를 import하면, 이제 ModuleClass도 사용할 수 있다.

// main.ts
import { ModuleClass } from "./moduleFile";

const globalInstance = new GlobalClass();
globalInstance.sayHello(); // 출력: Hello from GlobalClass

const moduleInstance = new ModuleClass();
moduleInstance.sayHello(); // 출력: Hello from ModuleClass

주의사항

TypeScript는 자바스크립트와 호환성을 유지하기 때문에, 자바스크립트의 모듈 시스템이 동작하는 방식에 따라 결과가 다를 수 있다. 실제 프로젝트에서 코드를 작성할 때는 모듈 시스템을 고려하고, 해당 프로젝트의 설정과 환경에 맞게 코드를 작성해야 한다.

이게 무슨 소리냐면 typescript 컴파일러는 오류가 아니라고 인식하는데 실제로 컴파일되서 나온 파일을 실행하면 에러가 난다.

5. 결론

TypeScript에서는 전역 모듈보다 모듈 파일을 사용하여 코드를 구조화하는 것이 좋다. 모듈 파일은 코드의 구조화와 이름 충돌 방지, 재사용 가능한 코드 작성에 도움이 된다.

전역 모듈을 사용할 때 발생할 수 있는 문제를 피하려면, 각 요소를 명시적으로 export하고 import하여 사용하는 모듈 파일을 활용하는 것이 좋다.

[Node.js] 자주 발생하는 TypeError 해결하기: 'Cannot read property of undefined'

얼은펭귄 — Tue, 2 May 2023 15:15:27 +0900

Node.js를 이용한 개발이 점점 인기를 얻고 있다. 그러나 개발 과정에서 발생할 수 있는 다양한 오류들로 인해, 개발자들이 진행에 어려움을 겪을 때가 많다. 이번 글에서는 Node.js 개발 중 자주 마주치는 오류 중 하나인 "TypeError: Cannot read property 'x' of undefined"에 대해 알아보자.

"TypeError: Cannot read property 'x' of undefined" 오류는 객체가 정의되지 않았을 때 발생한다.

객체의 속성이나 메서드에 접근하려고 시도하면 이 오류가 발생한다.

이러한 오류의 일반적인 원인들은 다음과 같다.

1. 변수 또는 객체 초기화 누락 가장 일반적인 원인은 변수 또는 객체를 선언했지만 초기화하지 않은 경우

이 경우 해당 변수는 기본적으로 undefined 값을 가지게 되며, 이 변수의 속성에 접근하려고 하면 오류가 발생한다.

let user;
console.log(user.name); // TypeError: Cannot read property 'name' of undefined

해결법은 다음과 같다.

변수 또는 객체를 초기화하거나, 속성 접근 전에 해당 변수 또는 객체가 정의되었는지 확인한다.

let user = {};
console.log(user.name); // undefined (오류 발생하지 않음)

2. 비동기 작업에서의 동기화 문제

Node.js에서 비동기 작업을 처리하는 동안 데이터를 가져오거나 처리하는 과정에서 오류가 발생할 수 있다. 비동기 작업이 완료되기 전에 속성에 접근하려고 하면 오류가 발생한다.

let user;
fs.readFile('user.json', 'utf8', (err, data) => {
	user = JSON.parse(data); 
}); 

console.log(user.name); // TypeError: Cannot read property 'name' of undefined

해결법은 다음과 같다.

비동기 작업이 완료되었음을 확인하거나, 콜백 함수, Promise, async/await 등의 비동기 작업 처리 방법을 사용하여 동기화 문제를 해결한다.

fs.readFile('user.json', 'utf8', (err, data) => {
	const user = JSON.parse(data); console.log(user.name); // 오류 발생하지 않음 
});

결론

Node.js 개발 중 "TypeError: Cannot read property 'x' of undefined" 오류는 변수 초기화 누락 또는 비동기 작업 동기화 문제로 인해 발생할 수 있다. 오류를 해결하기 위해서는 변수 초기화를 확인하고, 비동기 작업을 올바르게 처리해야 한다. 이렇게 하면 이러한 오류를 효과적으로 방지하고 Node.js 개발 경험을 개선할 수 있다.