먼저 ECS Service는 다음 3가지 배포가 가능합니다. (공식문서)

1. ECS (Rolling Update)
   • ECS에서 기본적으로 서비스 생성시 사용
2. CODE_DEPLOY (Blue/Green Update)
   • AWS CodeDeploy 서비스를 통해 배포시 사용
3. EXTERNAL
   • third-party deployment controller 로 배포시 사용

이중 기본 Rolling Update 배포하면

• 새로운 Deployment를 생성하고,
• 해당 Deployment 파라미터 설정에 따라 새로운 Task가 상이하게 배포됩니다.

따라서 각 파라미터를 정확하게 이해해야 ECS에서 효과적인 인프라 운영이 가능합니다.

크게 Deployment 파라미터 3개가 존재합니다.

1. deploymentCircuitBreaker: "너 만약에 배포 실패하면 어떻게 할래?"
2. maximumPercent: "배포할 때 task 얼마나 늘릴까?"
3. minimumHealthyPercent: "아니 적어도 task가 이정도는 있어야지"

각 파라미터의 자세한 설명과, 설정 방법에 대해서는 아래에 순차적으로 작성했습니다.

deploymentCircuitBreaker

"너 만약에 배포 실패하면 어떻게 할래?"

• 배포가 정상적으로 이뤄지지 않고 있을 때, 신규 배포를 중단하고, 선택적으로 롤백할 수 있는 기능입니다.

역할

1. 다음 리소스에 대한 health check를 수행합니다.

   • Elastic Load Balancing load balancers
   • AWS Cloud Map service
   • Amazon ECS container health checks

2. 실패시 threshold 동안 재시작하고, Deployment 를 FAILED 상태로 전환합니다.

   • ECS Service에 정의된 desired-count 에 따라 Failure threshold 을 자동으로 계산 (문서)
     • 최소 3 - 최대 200
   • 만약 CircuitBreaker 가 설정되어 있지 않다면 Failure threshold 설정되지 않아 계속 배포를 진행할 수 있습니다.

3. Rollback

   • Deployment 가 FAILED 일 때 가장 최근 성공한 Deployment로 롤백 가능
   • 하지만 최근에 성공한 배포가 없다면 배포가 중단됩니다.

설정 방법

ECS 서비스 생성 시, "Deployment failure detection" 란에서 설정이 가능합니다.

또한 기존 서비스는 다음과 같은 CLI 명령어를 통해 설정 정보를 확인할 수 있습니다.

$ aws ecs describe-services --cluster <CLUSTER NAME> --services <SERVICE NAME>

"DeploymentConfiguration": { 
    "DeploymentCircuitBreaker": { 
        "Enable": "true",   ### !!!
        "Rollback": "false"  ### !!!
         }, 
    ...
 }, 

설정이 완료된 후, CircuitBreaker 에 의해 배포가 차단되면 다음과 같은 오류가 발생됩니다.

Error occurred during operation 'ECS Deployment Circuit Breaker was triggered ...

maximumPercent, minimumHealthyPercent

maximumPercent: "배포할 때 task 얼마나 늘릴까?" minimumHealthyPercent: "아니 적어도 task가 이정도는 있어야지"

공식문서를 확인해 보면 더욱 정확한 정의를 확인할 수 있다.

• maximumPercent
  • 배포 중 RUNNING , PENDING or STOPPING 상태 최대 task 개수 (반내림, default는 200%)
• minimumHealthyPercent
  • 배포 중 RUNNING 상태로 남아 있어야 하는 최소 task 개수 (반올림, default는 200%)

적용 예시 1 (무중단 배포 성공)

• desiredCount: 4
• maximumPercent: 200%
  • 최대 8개의 task 가 허용됨
• minimumHealthyPercent: 100%
  • 최소 4개의 task는 running 중이여야 함

적용 예시 2 (무중단 배포 성공)

• desiredCount: 4
• maximumPercent: 100%
  • 최대 4개의 task 가 허용됨
• minimumHealthyPercent: 50%
  • 최소 2개의 task는 running 중이여야 함

적용 예시 3 (무중단 배포 실패!)

• desiredCount: 1
• maximumPercent: 100%
  • 최대 1개의 task 가 허용됨
• minimumHealthyPercent: 50%
  • 최소 1개의 task는 running 중이여야 함 (반올림 적용)

=> 배포중 최대 task 수가 1개이기 때문에, 무중단 배포가 불가능한 것을 확인할 수 있습니다.

설정 방법

ECS 생성 시 "Deployment options" 에서 설정합니다. (Rolling update 만 커스텀 설정 가능, Blue/Green는 기본설정으로 적용됨)

또한 기존 서비스는 다음과 같은 CLI 명령어를 통해 설정 정보를 확인할 수 있습니다.

$ aws ecs describe-services --cluster <CLUSTER NAME> --services <SERVICE NAME>

... 
"DeploymentConfiguration": { 
    "MaximumPercent": "200", 
    "MinimumHealthyPercent": "100", 
    ...
 }, 
...

결론

ECS 무중단 배포를 위한 배포 설정에 대하여 알아보았습니다.

1. CircuitBreaker 을 설정하여 운영상의 이슈가 있는 리소스를 처리하는 로직을 추가합니다.
2. 서비스의 desired count 을 고려하여 배포중 서비스 중단이 일어나지 않도록 적절한 maximumPercent, minimumHealthyPercent 를 설정합니다.

Reference

1. ECS | Amazon ECS 서비스 정의 파라미터 https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service_definition_parameters.html
2. ECS | DeploymentConfiguration https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/APIReference/API_DeploymentConfiguration.html

업데이트 시, 노드에서 Pods를 드레이닝합니다. Pods가 15분 이내에 노드를 떠나지 않고 force 플래그가 없으면 PodEvictionFailure 오류와 함께 업그레이드 단계가 실패합니다.

이때 PDB 설정이 과도하게 잡혀있을 경우 pod가 노드에 evict되지 못하는 경우가 발생합니다. 따라서 이러한 문제를 해결하는 방법에 대해서 알아보겠습니다.

과도한 PDB

다음 오류는 PodEvictionFailure로 인해 업그레이드가 차단됨을 나타냅니다. "Error message : Reached max retries while trying to evict pods from nodes in node group."

Disruptions

• PDB에 대해 이해하기 전에 Pod의 Disruptions에 대한 이해가 선수되어야 합니다.
• Pod는 기본적으로는 누군가(사람 Or 컨트롤러)가 파기하거나 불가피한 오류가 발생할 때까지 disappear되지 않습니다.
• 어떻게 종료되었느냐에 따라 Disruptions 종류가 나뉘게 됩니다.
  • Voluntary disruptions -> 의도적 종료
    • Draining a node - 수리 또는 업그레이드를 위해
    • Draining a node - 클러스터 Autoscaler에 의한 동작
    • Using PriorityClasses
      • Involuntary disruptions -> 불가피한 오류
      • 노드를 지원하는 물리적 시스템의 하드웨어 오류
      • 클러스터 관리자가 실수로 VM(인스턴스)을 삭제
      • 노드의 리소스 부족

PDB (Pod disruption budgets)

PDB란?

• PDB는 Voluntary disruptions으로 인해 동시에 다운 가능한 포드의 replica 수를 제한하는 기능입니다
  • Voluntary disruptions이 빈번하게 일어나는 경우 고가용성 애플리케이션을 실행하는 데 도움을 줄 수 있습니다.
  • Involuntary disruptions은 PDB로 방지할 수 없습니다.
  • 예시
    • .spec.replicas: 5가 있는 배포에는 언제든지 5개의 Pod가 있어야 합니다.
    • PDB가 최소 4개의 파드를 유지하도록 설정되어 있는 경우, Eviction API는 한 번에 하나 포드의 Voluntary disruptions을 허용합니다.

PDB 설정

• minAvailable :

  • Integer로 입력하면 파드 수를 의미합니다.
  • 예를 들어 minAvailable을 10으로 설정하면 중단 중에도 항상 10개의 Pod를 사용할 수 있어야 합니다.
  • Percentage의 문자열 표현으로("50%") 입력하면 전체 Pod의 백분율을 의미합니다.
  • 예를 들어 minAvailable을 "50%"로 설정하면 중단 중에도 Pod의 50% 이상이 계속 사용 가능한 상태로 유지됩니다.
  • 또한 pod가 7개라면 Kubernetes는 가장 가까운 정수로 반올림하므로 이 경우 4개의 Pod를 사용할 수 있어야 합니다.

• maxUnavailable :

  • maxUnavailable 값을 백분율로 지정하면 Kubernetes는 중단될 수 있는 Pod 수를 반올림합니다.

• 예시 yaml ``` apiVersion: v1 items:

• apiVersion: policy/v1 kind: PodDisruptionBudget metadata: creationTimestamp: "2024-05-22T00:12:07Z" generation: 1 labels:

  eks.amazonaws.com/component: coredns
  k8s-app: kube-dns

  name: coredns namespace: kube-system spec: maxUnavailable: 1 selector:

  matchLabels:
    eks.amazonaws.com/component: coredns
    k8s-app: kube-dns

Control Plane Log 확인

• EKS를 사용하는 경우 감사 로깅이 활성화 되었다면 아래 쿼리를 통해 로그를 확인할 수 있다.

    fields @timestamp, @message| filter @logStream like "kube-apiserver-audit"
    | filter ispresent(requestURI)
    | filter objectRef.subresource = "eviction"
    | display @logStream, requestURI, responseObject.message
    | stats count(*) as retry by requestURI, responseObject.message

PDB 이슈 해결 방법

1. pod 강제종료

PDB는 Node Drain 시 Pod Eviction에 영향을 미칠 뿐 Pod의 강제 종료를 방지하지는 못한다. 따라서 Pod를 강제 종료하여 스케쥴링이 가능한 다른 Node에 배치하고, eviction이 완료되지 않았던 Node를 다시 Drain을 시도할 수 있다.

2. PDB 동작 변경

PDB 조회시 Allowed Disruptions이라는 요소가 있는데 수치가 "0"일 경우 eviction 가능한 pod가 없음을 의미한다. 따라서 Min Available 혹은 Max Unavailable의 차이를 계산하여 Allowed Disruptions을 조절하여 eviction이 가능한 상태로 만들고, Drain을 시도하면 파드가 정상적으로 evict될 것이다.

References:

• https://repost.aws/ko/knowledge-center/eks-node-group-update-failures
• https://kubernetes.io/docs/concepts/workloads/pods/disruptions/

회사에서 IOT 데이터를 스트리밍하기 위하여 Kafka를 사용하고 있다. DevOps Engineer로서 운영 관점에서 Kafka를 잘 사용하는 방법을 공부하고자 카프카 시리즈를 시작한다!

첫 게시물이니 카프카의 아주 아주 기본적인 개념들을 정리해 보고자 한다!🙂

프로듀서, 컨슈머, 브로커, 주키퍼

• 프로듀서 :
  • 카프카에서 메세지를 생성하고, 해당 메세지를 카프카 클러스터에 전송하는 클라이언트
  • 한 개, 혹은 여러개의 토픽으로 메세지를 보낼 수 있다.
• 컨슈머 :
  • 카프카에서 메세지를 읽는 클라이언트
  • 한 개, 혹은 여러개의 토픽에서 메세지를 가져올 수 있다.
  • 파티션마다 한 컨슈머만 데이터를 가져갈 수 있다.
• 브로커 :
  • 카프카 애플리케이션이 설치된 서버를 의미한다.
• 주키퍼 :
  • 브로커 health check 등 카프카 클러스터의 상태를 관리한다.

토픽, 파티션, 오프셋

• 토픽 :
  • 카프카는 토픽(topic)이라는 곳에 데이터를 저장한다.
  • 비유하자면 이메일 주소와 비슷함
  • 토픽의 이름은 카프카 내에서 고유하다.
• 파티션 :
  • 토픽의 병렬처리를 위해 여러개의 파티션(partition)이라는 단위로 나뉜다.
  • 카프카에서는 파티셔닝을 통해 단 하나의 토픽이라도 높은 처리량을 수행할 수 있다.
  • 파티션 번호는 0부터 시작

토픽을 생성할 때 파티션 수를 설정하는데, 초기 생성 후 얼마든지 늘릴 수 있지만 절대로 줄일 수 없다.

따라서 생성할 때 최대한 작게 생성한 후, 메세지 처리량이나 컨슈머의 LAG 등을 모니터링하면서 조금씩 늘려가는 방법이 가장 좋다.

컨슈머의 LAG : 프로듀서가 보낸 메세지 수(카프카에 남아 있는 메세지 수) - 컨슈머가 가져간 메세지 수

따라서 LAG이라는 지표를 통해 컨슈머에 지연이 없는지 확인할 수 있다.

• 오프셋 :
  • 파티션의 메세지가 저장되는 위치
  • 순차적으로 증가하는 숫자(64비트의 정수)형태이다.
• 위 그림에서 1개의 토픽이 3개의 파티션에 나눠져있다.
• 프로듀서로부터 전송되는 메세지들의 쓰기 동작이 각 파티션별로 이뤄진다.
• 파티션마다 순차적으로 증가하는 숫자들이 바로 오프셋이다.
• 카프카에서는 오프셋을 통하여 메세지의 순서를 보장하고 컨슈머에서는 마지막으로 읽은 위치도 기억할 수 있다.

세그먼트

• 세그먼트 :

  • 프로듀서에 의해 브로커로 전송된 메세지는 토픽의 파티션에 저장되며, 각 메세지는 세그먼트(segment)라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장된다.
  • 카프카에 모든 메세지를 단일 파일로 저장하는 것이 아니라, 세그먼트라는 단위로 나뉘어서 저장된다.

• 프로듀서는 항상 활성 세그먼트(active segment)에 write를 한다.

• 세그먼트 사이즈 limit에 도달하면 새로운 세그먼트 파일이 활성화된다.

• 세그먼트 파일의 이름은 첫번째 메세지의 파일 이름을 사용하여 생성된다.

• 위 그림을 살펴보면 세그먼트0에는 오프셋 0~2의 메세지가 있고,
• 현재 활성 세그먼트는 6으로, 첫번째 메세지의 오프셋이 6이다.

리플리케이션

• 리플리케이션 :
  • 카프카에서는 가용성을 위해 리플리케이션(Replication)이라는 기능을 제공한다.
  • 각 메세지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에게 분산시키는 동작을 의미한다.

• 위 그림은 test라는 토픽에 파티션이 3개고 리플리케이션이 1개일 때의 예시이다.

• 위 그림은 리플리케이션을 3으로 설정했을 때의 그림이다.
• 파티션이 3개씩 리플리케이션 되었다.

리플리케이션을 설정할 때 아래와 같은 trade-offs를 고려해야 한다.

• 장점 : 데이터 가용성이 훨씬 증가한다.
• 단점 : 각 복제본마다 추가 저장 용량이 필요하므로 네트워크 트래픽과 데이터 디스크 사용량이 증가될 수 있다.

상황에 따라서 복제에 대한 오버헤드를 줄여 최대한 브로커를 효율적으로 사용하는 것이 권장된다.

• 테스트 환경 : 리플리케이션 팩터의 수 1로 설정
• 운영 환경(로그성 메세지, 약간의 유실 허용) : 리플리케이션 팩터의 수 2로 설정
• 운영 환경(유실을 허용하지 않음) : 리플리케이션 팩터의 수 3로 설정

출처 :

• 책 : 실전 카프카 개발부터 운영까지
• https://www.cloudkarafka.com/blog/part1-kafka-for-beginners-what-is-apache-kafka.html
• https://dattell.com/data-architecture-blog/what-is-a-kafka-topic/
• https://www.freblogg.com/kafka-storage-internals
• https://damdam-kim.tistory.com/17

*MongoDB Helm Repo : * https://github.com/bitnami/charts/tree/master/bitnami/mongodb

실습 환경 :

• AWS CentOS 인스턴스
• minikube 클러스터

⭐️ MongoDB 설치

1. Namespace 생성

kubectl create ns mongo

2. mongo Repo 추가

helm repo add bitnami https://charts.bitnami.com/bitnami

3. value 파일 작성

values-mongo.yaml

mage:
  registry: docker.io
  repository: bitnami/mongodb
  tag: 4.4.4-debian-10-r41
  pullPolicy: IfNotPresent

architecture: standalone

useStatefulSet: true

## MongoDB(R) Authentication parameters
auth:
  enabled: true
  rootPassword: "yourpasswd"
  username: admin
  password: yourpasswd
  database: sample

##
persistence:
  enabled: true
  storageClass: "nfs-standard"
  accessModes:
    - ReadWriteOnce
  size: 2Gi

service:
  type: NodePort
  port: 27017
  portName: mongodb

저는 인증 정보, 볼륨, 서비스(노드포트)에 대해 정의해주었습니다. 자세한 파라미터 정보는 파라미터 정리 표, values.yaml을 참고해주세요.

4. Helm install

helm install mongodb-tset bitnami/mongodb-sharded --namespace mongo --values values-mongo.yaml

NAME: mongodb-tset
LAST DEPLOYED: Tue Apr 26 15:58:06 2022
NAMESPACE: mongo
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: mongodb-sharded
CHART VERSION: 4.0.21
APP VERSION: 4.4.13

** Please be patient while the chart is being deployed **

The MongoDB® Sharded cluster can be accessed via the Mongos instances in port 27017 on the following DNS name from within your cluster:

    mongodb-tset-mongodb-sharded.mongo.svc.cluster.local

To get the root password run:

    export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace mongo mongodb-tset-mongodb-sharded -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)

To connect to your database run the following command:

    kubectl run --namespace mongo mongodb-tset-mongodb-sharded-client --rm --tty -i --restart='Never' --image docker.io/bitnami/mongodb-sharded:4.4.13-debian-10-r50 --command -- mongo admin --host mongodb-tset-mongodb-sharded

To connect to your database from outside the cluster execute the following commands:

    export NODE_IP=$(kubectl get nodes --namespace mongo -o jsonpath="{.items[0].status.addresses[0].address}")
    export NODE_PORT=$(kubectl get --namespace mongo -o jsonpath="{.spec.ports[0].nodePort}" services mongodb-tset-mongodb-sharded)
    mongo --host $NODE_IP --port $NODE_PORT --authenticationDatabase admin -p $MONGODB_ROOT_PASSWORD

kubernetes에 배포가 완료되면 mongoDB 접속과 관련된 몇가지 명령어를 알려준다.

• ** To get the root password run:** secret에 저장되어 있는 root password를 복호한 값을 가져온다

• To connect to your database run the following command: kubectl로 데이터베이스에 직접 접속한다.

• To connect to your database from outside the cluster execute the following commands: 쿠버네티스 클러스터 외부에서 접속할 수 있는 IP주소와 포트 번호를 알려준다.

5. 배포된 리소스 확인

kubectl get all -n mongo

NAME                                                       READY   STATUS    RESTARTS      AGE
pod/mongodb-tset-mongodb-sharded-configsvr-0               1/1     Running   0             95m
pod/mongodb-tset-mongodb-sharded-mongos-6cccfd844b-7dd7l   1/1     Running   0             95m
pod/mongodb-tset-mongodb-sharded-shard0-data-0             1/1     Running   1 (92m ago)   95m
pod/mongodb-tset-mongodb-sharded-shard1-data-0             1/1     Running   0             95m

NAME                                            TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)           AGE
service/mongodb-tset-mongodb-sharded            NodePort    10.96.8.157   <none>        27017:30631/TCP   95m
service/mongodb-tset-mongodb-sharded-headless   ClusterIP   None          <none>        27017/TCP         95m

NAME                                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mongodb-tset-mongodb-sharded-mongos   1/1     1            1           95m

NAME                                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/mongodb-tset-mongodb-sharded-mongos-6cccfd844b   1         1         1       95m

NAME                                                        READY   AGE
statefulset.apps/mongodb-tset-mongodb-sharded-configsvr     1/1     95m
statefulset.apps/mongodb-tset-mongodb-sharded-shard0-data   1/1     95m
statefulset.apps/mongodb-tset-mongodb-sharded-shard1-data   1/1     95m

파드도 정상적으로 배포되었고, 서비스도 NodePort로 배포되었다~!

⭐️ Mongo DB 접속

이제 DB에 접속해보자!

[방법1] kubectl로 MongoDB 접속

kubectl run --namespace mongo mongodb-tset-mongodb-sharded-client --rm --tty -i --restart='Never' --image docker.io/bitnami/mongodb-sharded:4.4.13-debian-10-r50 --command -- mongo admin --host mongodb-tset-mongodb-sharded

If you don't see a command prompt, try pressing enter.
mongos>

[방법2] 클러스터 외부에서 MongoDB 접속

다음 명령을 사용하여 Node application의 URL을 가져온다.

    export NODE_IP=$(kubectl get nodes --namespace mongo -o jsonpath="{.items[0].status.addresses[0].address}")
    export NODE_PORT=$(kubectl get --namespace mongo -o jsonpath="{.spec.ports[0].nodePort}" services mongodb-tset-mongodb-sharded)
    mongo --host $NODE_IP --port $NODE_PORT --authenticationDatabase admin -p $MONGODB_ROOT_PASSWORD

따라서 minikube가 설치된 호스트에서 mongoDB에 접속할 수 있다.

mongo --host $NODE_IP --port $NODE_PORT --authenticationDatabase admin -p $MONGODB_ROOT_PASSWORD

MongoDB shell version v5.0.8
connecting to: mongodb://192.168.49.2:30631/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("a808d91d-18f1-472f-8717-824c3f190b40") }
MongoDB server version: 4.4.13
WARNING: shell and server versions do not match
================
Warning: the "mongo" shell has been superseded by "mongosh",
which delivers improved usability and compatibility.The "mongo" shell has been deprecated and will be removed in
an upcoming release.
For installation instructions, see
https://docs.mongodb.com/mongodb-shell/install/
================
mongos>

[방법3] Public IP로 접속하기

현재 실습환경이 minikube이기 때문에 서비스에 로드밸런서를 붙일 수 없다. 따라서 Public IP로 접속이 불가하다💦

하지만 EKS, GKE와 같은 환경에서 서비스 타입을 로드밸런서로 지정하면 외부에서 접속할 수 있는 퍼블릭한(External) IP를 얻을 수 있다.

export SERVICE_IP=$(kubectl get svc --namespace default my-todo-app-mean -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo http://$SERVICE_IP/

터미널? 정확하게 터미널이 의미하는 것이 무엇이지? 하는 의문이 들었다. 터미널 명령에 대해 알아보기 전 '터미널'에 대한 정확한 개념을 정리해보자!

리눅스 터미널의 유래

과거 컴퓨터는 대학과 기업이 소유한 거대한 다중 사용자 시스템이였다. 기계 자체는 일반 사용자가 방문하지 않는 안전한 방에 있었다. 대신 위 사진과 같이 저렴한 텔레타이프(TTY)를 터미널로 사용했다.

텔레타이프(TTY)는 주로 전신에서 타이핑된 메시지를 주고받는 데 사용되었지만, 정보를 컴퓨터에 입력하고 컴퓨터에서 정보를 가져오는 데에도 사용할 수 있다.

많은 텔레타이프가 하나의 Unix 컴퓨터에 연결됐다. 모든 사용자는 자신의 텔레타이프 앞에 앉아 자신의 사용자 이름과 비밀번호로 Unix에 로그인했다.

따라서 Unix는 최초의 다중 사용자 운영 체제가 되었고 ASR33은 최초의 Unix 터미널이 되었다. 이러한 유래로 TTY라는 약어는 일반적으로 Unix/Linux에서 터미널을 나타내는 데 사용된다고 한다.

현재 터미널의 의미는?

오늘날의 터미널은 GUI에서 실행되는 이전 물리적 터미널의 소프트웨어 표현이다. 사용자가 명령을 입력하고 텍스트를 인쇄할 수 있는 인터페이스를 제공한다.

Linux 서버에 SSH로 연결할 때 로컬 컴퓨터에서 실행하고 명령을 입력하는 프로그램은 터미널이다.

쉘이란?

터미널은 정보를 전송하는 메커니즘일 뿐이다. 운영 체제가 정보를 이해하기 위해 터미널은 shell을 기본적으로 사용하고 있다.

정리하자면 Linux의 셸은 터미널 창에 입력한 명령을 해석하여 운영 체제에서 사용자가 원하는 작업을 이해할 수 있도록 하는 프로그램입니다.

hell은 기본적으로 bash, tcsh등이 사용되며 window에서는 cmd를 기반으로 사용되고있다.

커맨드라인 인터페이스란(CLI)?

사용자가 텍스트로 명령어를 입력하고 다시 텍스트로 결과를 화면에 출력해주는 인터페이스를 가진 컴퓨팅 인터페이스를 의미합니다.

커맨드라인 인터페이스는 구체적인 프로그램을 가리키는 단어는 아니며, 특정 방식의 애플리케이션 인터페이스에 대한 통칭이다.

터미널 관련 명령어

tty

터미널에서 tty라는 명령어를 실행해보면 현재 커널과 연결된 가상 터미널 장치 이름을 확인할 수 있다.

w 명령어로 로그인한 유저의 모든 유저에 대한 TTY 정보를 확인할 수도 있다.

stty

stty 명령어로 터미널 설정을 출력, 변경할수 있다.

a 옵션을 이용하면 각 키값들에 대한 설정을 볼 수 있다.

setterm

터미널의 설정값을 변경할 때 사용하는 명령이다.

다음을 입력하면 터미널에서 커서 모양이 보이지 않고, on으로 다시 설정하면 커서 모양이 나타난다.

setterm -cursor off

tset

터미널 설정을 초기화 하고, 터미널 타입을 출력하는 명령어이다.

이 외에도 setserial, getty, agetty, mesg, wall, write와 같은 다양한 명령어가 있다.

더 궁금한 명령어는 man 명령어를 사용하여 맨페이지를 읽어보면서 공부해보자!

참고

• https://www.linuxbabe.com/command-line/linux-terminal
• https://www.linuxbabe.com/command-line/linux-terminal
• https://www.44bits.io/ko/keyword/command-line-interface-cli-shell-and-terminal#%ED%84%B0%EB%AF%B8%EB%84%90terminal%EC%9D%B4%EB%9E%80

쿠버네티스, 왜 필요할까 🤔

모놀리스 애플리케이션에서 마이크로 서비스로 전환

• 모놀리스 애플리케이션
  • 전체가 하나의 운영체제 프로세스로 실행되기 때문에 하나의 개체로 개발, 배포, 관리된다.
  • 하나의 변경 사항을 적용하기 위해 전체를 다시 빌드/테스트/배포 해야한다.
  • 애플리케이션 확장이 어렵다.

이러한 문제로 모놀리스 애플리케이션을 마이크로 서비스라는 독립적으로 배포할 수 있는 작은 구성 요소로 분할했다.

• *마이크로 서비스 *
  • 각 마이크로 서비스는 독립적인 프로세스로 실행되며 api로 또 다른 마이크로 서비스와 통신한다.
  • 새로 추가되거나 변경 사항이 있는 서비스만 빠르게 빌드/테스트/배포가 가능하다.
  • 리소스가 더 필요한 서비스만 별도로 확장 가능하다.

[문제 상황 1] 마이크로 서비스의 단점 : 종속성의 충돌

마이크로 서비스 아키텍쳐의 구성 요소는 독립적인 방식으로 개발된다.

각 구성 요소를 개발하는 별도의 팀이 있는 것이 일반적인데 각각의 개발자가 자신의 노트북으로 애플리케이션은 개발 중인 상황을 떠올려보자.

각각의 어플리케이션은 서로 다른 라이브러리, 종속성 및 파일에 의존하고 있으며, 동시에 회사는 자체 설정과 지원 파일 세트에 준하여 표준화된 개발 및 프로덕션 환경을 갖추고 있다.

이때, 서버 환경을 재구축하는 부가적인 작업 없이 가능한 한 로컬에서 이러한 환경을 에뮬레이션하려고 한다. 그렇다면 이러한 환경 전체에서 애플리케이션이 작동되게 하고, 품질 검사를 통과하고, 큰 문제나 수정 없이 애플리케이션을 배포할 수 있을까?

동일한 호스트에 배포해야하는 구성 요소 수가 많을 수록 모든 종속성을 관리하기 매우 어려워진다.

[문제 상황 2] 일관된 환경의 중요성 : 개발, 프로덕션 환경

개발, 배포하는 구성 요소의 수에 상관없이, 개발팀과 운영팀이 해결해야 하는 큰 문제가 있다. 애플리케이션을 실행하는 환경이 매번 다르다는 것이다.

개발자의 로컬 환경에서는 잘 운영되던 코드가 운영팀이 운영하는 프로덕션 환경에서는 오류가 생길 수도 있다.

프로덕션 환경에서만 나타나는 문제를 줄이기 위해 애플리케이션 개발과 프로덕션이 정확히 동일한 환경에서 실행돼 운영체제, 라이브러리, 시스템 구성, 네트워킹 환경 등 모든 것이 동일한 환경으로 만들어야 한다.

[문제 상황 3] 개발자와 시스템 관리자의 동상이몽

• 개발자와 시스템 관리자의 공통 목표 고객이 성공적으로 실행할 수 있는 애플리케이션을 제공하는 것

• 개발자는 새로운 기능을 만들고 사용자 경험 향상에 중요도를 둔다.

• 시스템 운영자는 개발자에게 우선순위가 낮은 시스템 보안, 사용률과 같은 측면에 중요도를 둔다.

해답은 쿠버네티스

앞서 언급한 문제 상황을 쿠버네티스가 어떻게 해결해주는지 살펴보자!🔍

컨테이너 소개 📦

컨테이너의 개요

[문제 상황 1] 마이크로 서비스의 단점! 에서 한 호스트에 마이크로 서비스 애플리케이션을 개발한다고 가정할 때, 구성 요소의 구성(라이브러리 버전 등)은 다를 수 있다는 종속성 차이에 대해 언급했다.

이에 대한 답은 바로 '컨테이너'를 사용하는 것이다.

애플리케이션을 실행하는 컨테이너는 각각의 필수 라이브러리, 종속 요소와 파일을 사용하므로 문제없이 원활하게 애플리케이션을 프로덕션으로 진행할 수 있다.

뿐만 아니라 이식성, 구성 가능성, 격리가 필요한 경우 리눅스 컨테이너를 다양한 문제에 적용할 수 있다.

컨테이너는** 동일한 호스트 시스템에서 동시에 서로 다른 환경을 만들어주어 가상머신과 유사하게 격리한다. 하지만 가상머신보다 **오버헤드가 훨씬 적은 기술이다.

컨테이너와 가상머신 비교

컨테이너 격리를 가능하게 하는 매커니즘

컨테이너는 동일한 호스트의 OS를 공유하고 있는데, 어떤 매커니즘으로 격리를 제공하고 있을까?

⑴ namespace

각 프로세스가 시스템(파일, 프로세스, 네트워크 인터페이스, 호스트 이름 등)에 대한 독립적인 뷰만 볼 수 있도록 한다. 현재 리눅스 커널에서는 다음 6가지 namespace를 지원하고 있다:

• mnt (파일시스템 마운트): 호스트 파일시스템에 구애받지 않고 독립적으로 파일시스템을 마운트하거나 언마운트 가능
• pid (프로세스): 독립적인 프로세스 공간을 할당
• net (네트워크): namespace간에 network 충돌 방지 (중복 포트 바인딩 등)
• ipc (SystemV IPC): 프로세스간의 독립적인 통신통로 할당
• uts (hostname): 독립적인 hostname 할당
• user (UID): 독립적인 사용자 할당

기본적으로 리눅스 시스템에 하나의 네임스페이스가 있다. 그러나 추가 네임 스페이스를 생성하고 구성할 수 있다.

프로세스를 실행할 때 네임스페이스 중 하나에서 프로세스를 실행한다. (프로세스는 하나의 네임스페이스에만 속하는 것이 아니라 여러 네임스페이스에 속할 수도 있다.)

⑵ cgroups

프로세스가 사용할 수 있는 리소스의 양을 제한하게 해주는 리눅스의 기능이다. cgroups는 다음 리소스를 제어할 수 있다:

• 메모리
• CPU
• I/O
• 네트워크
• device 노드(/dev/)

프로세스는 설정된 양 이상의 리소스를 사용할 수 없다. 이런 방식으로 프로세스는 다른 프로세스 용으로 설정된(예약해 놓은) 리소스를 사용할 수 없으며 이는 프로세스가 별도의 시스템에서 실행될 때와 비슷하다.

Docker

도커는 애플리케이션을 패키징, 배포, 실행하기 위한 플랫폼이다.

애플리케이션에 필요한 전체 환경을 패키지화 하여, 중앙 저장소로 전송할 수 있으며, 도커를 실행하는 모든 컴퓨터에서 사용할 수 있다.

이러한 도커의 세가지 주요 개념은 다음과 같다.

• 이미지 : 애플리케이션과 해당 환경을 패키지화 한 것이다.
• 레지스트리 : 이미지를 저장하고, 공유할 수 있는 저장소이다.
• 컨테이너 : 도커 기반 컨테이너 이미지에서 생성된 리눅스 컨테이너로, 호스트에서 실행되는 프로세스이지만 격리돼 있다. 프로세스는 cgroups로 리소스 양이 제한되어 있으므로 할당된 양만 사용 가능하다.

쿠버네티스 소개 ⚙️

결론적으로 쿠버네티스가 해결해주는것은 무엇일까?

• [문제 상황 3] 개발자와 시스템 관리자의 동상이몽 개발자는 기능 개발을, 시스템 관리자는 보안과 같은사용률과 같은 측면에 중요도를 둔다고 했었다.

• 쿠버네티스를 이용하면 개발자는 특정 인프라 관련 서비스를 애플리케이션에 구현하지 않아도 된다. 따라서 실제 기능을 개발하는 것에만 집중할 수 있다.

• 또한 시스템 관리자는 쿠버네티스가 애플리케이션을 재배치하고 조합함으로 리소스를 훨씬 더 효율적으로 이용할 수 있게 된다. 뿐만아니라 고장 난 노드를 자동으로 처리하도록 함으로써 따라서 운영팀은 더 편하게 잠을 잘 수 있다...ㅎ

  
  
  ### 쿠버네티스 핵심 우선 쿠버네티스의 핵심적인 구조와 워크 플로우에 대해서만 정리했다.

쿠버네티스는 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템이다.

다음 그림은 쿠버네티스의 구조이다. 크게 마스터 노드와 워커노드로 구성된다.

• 마스터 노드 : 전체 쿠버네티스 시스템을** 제어하고 **관리하는 쿠버네티스 컨트롤 플레인을 실행
• ** 워커 노드** : 실제 배포되는 컨테이너 애플리케이션을 실행

큰 워크 플로우는 개발자가 애플리케이션 매니페스트를 작성 ➡️ 매니페스트를 마스터 노드에 배포 ➡️ 쿠버네티는 해당 애플리케이션을 워커 노드 클러스터에 배포한다.

구조를 더 자세히 살펴 보자.

컨트롤 플레인

• 마스터 노드가 실행시킨다.
• 클러스터를 제어하고 작동시킨다.
• 구성요소
  • kube-apiserver : K8S API를 노출하는 컨트롤 플레인의 프론트엔드
    • etcd : 클러스터의 모든 데이터를 보관하는 일관성, 고가용성을 보장하는 키-값 저장소 어떤 노드가 존재하고 클러스터에 어떤 리소스가 존재하는지와 같은 정보
  • kube-scheduler : 새로운 POD 생성을 감지하고, 실행시킬 워커 노드를 선택하는 역할
  • kube-controller-manager : 디플로이먼트 같은 리소스 컨트롤러를 관리. API 서버를 통해 클러스터의 공유된 상태를 감지하고, 현재 상태를 원하는 상태로 이행하는 컨트롤 루프를 관리
  • cloud-controller-manager : 클라우드 업체와 연동하여 로드 밸런서나 디스크 볼륨 같은 자원을 관리

이 컨트롤 플레인의 구성요소는 클러 스터 상태를 유지하고 제어하지만 애플리케이션을 실행시키지는 않는다.

노드

워커 노드는 컨테이너화 된 애플리케이션을 실행하는 시스템이다.

• kubelet : 각 노드에서 실행되는 에이전트, 컨테이너 런타임을 관리하고 상태를 모니터링, POD에서 컨테이너가 확실하게 동작하도록 관리
• ** kube-proxy** : 각 노드에서 실행되는 네트워크 프록시. Service 개념의 구현부. 서로 다른 노드에 있는 POD 간 통신이나 POD와 인터넷 사이의 네트워크 트래픽을 라우팅
• 컨테이너 런타임 : 테이너를 시작하고, 중지. 대표적으로 Docker

출처

• 책 - Kubernetes in action
• https://velog.io/@cclare/%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4
• https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/
• https://www.redhat.com/ko/topics/containers/whats-a-linux-container
• https://tech.ssut.me/what-even-is-a-container/
• https://bcho.tistory.com/1256

CSAP의 평가 종류는 다음과 같다.

1. 최초평가
2. 사후평가
3. 갱신평가

사후 평가는 SaaS 간편은 2회, 나머지는 4회를 수행해야 한다.

why? ** 인증 종류마다 **유효기간이 상이하기 때문이다. aaS, SaaS 표준(5년) >>>>>> SaaS 간편(3년)

전반적인 절차

• 최초 평가를 기준으로한 절차이다. 1년 단위로 실시하는 사후 절차에서는 준비단계 없이 평가 단계로 넘어간다.
• 크게** 준비단계, 평가단계, 인증단계**로 구성되어 있다.

세부 절차

① 준비단계

• 시스템 및 서비스 구축
  • 신청기관은 서비스 유형을 고려하여 클라우드 시스템 구축해야 한다.
    • IaaS: 인프라 제공과 관련하여 구축
    • SaaS/PaaS: 보안인증을 받은 IaaS 사업자가 제공하는 가상환경 위에 구축 + 데이터 논리적으로 분리하여 구축
    • DaaS: 인프라 영역에 DaaS 필수 요소(가상PC OS, 가상화 관리 솔루션 등) 추가하여 구축
    • DaaS 필수 보안 sw인 백신, 망연계 솔루션, 유해사이트 차단 솔루션 등도 추가
      
• 사전 컨설팅
  • 원활한 평가 진행을 위해 평가, 인증에 필요한 자료 구비 유무, 시스템 구축 및 운영 형태를 확인하여 컨설팅을 제공하는 것이다.
    
• 평가/인증 신청 및 접수
  • 다음 서류를 준비하여 평가, 인증기관에 제출한다.
• 평가/인증 계약 체결
  • 평가/인증 진행이 결정된 이후 평가 / 인증기간을 평가, 평가/인증 수수료 등을 협의하고 계약 체결한다.
    

② 평가단계

• 서면 / 현장평가

  • 클라우드서비스가 보안 평가, 인증기준에 맞게 적절하게 구축, 운영되고 있는지 확인한다.

• 취약점 점검

  • 평가팀은 평가, 인증 범위에 포함된 자산에 대해 점검도구, 수동점검, 인터뷰 등을 통해 취약점 점검 수행한다.

• 모의침투테스트

  • 신청기관 / 클라우드서비스 모델, 구축 유형 등을 고려하여 모의침투 계획 및 시나리오 수립 후 모의침투 수행한다.

• 보완조치 요청

  • 평가팀은 종료회의를 통해 신청기관 담당자에게 결과 설명한다.
  • 보완조치요청서를 통해 부적합 사항 및 취약점에 대한 보완조치를 요청한다.

• 보완조치 및 조치결과 제출

  • 신청기관은 보완조치 요청을 받은 날로부터 30일 이내 보완조치 완료하고 보완조치 내역서를 작성하여 제출한다.

• 보완조치 확인(이행점검)

  • 평가팀장은 보완조치 내역서의 적절성을 판단한다.
  • 이행 점검을 통해 실제 이행 여부를 현장에서 확인하여 보완조치 여부 판단한다.

③ 인증단계

• 인증위원회 개최
  • 위원장은 인증위원회 심의의견을 취합하여 클라우드서비스 보안 평가 / 인증 심의 결과서를 작성한다.
  • 인증위원회에서는 심의 결과에 따라 추가 보완조치를 요구할 수 있다.
• 인증서 발급 및 취득
  • 인증기관의 장은 인증위원회 심의 / 의결 결과를 신청기관에 통보한다.
  • 인증기관의 장은 평가 / 인증기준에 적합한 경우 인증서 발급한다.
  • 인증서 수령 후 보안인증 표시 사용할 수 있다.
    
    
    

사후관리 절차

① 사후 평가

• 인증취득기관이 지속적으로 클라우드서비스 보안 평가 / 인증기준의 준수 여부를 확인하기 위해 인증 유효기관 중 매년 1회 이상 시행하는 평가 / 인증을 말한다.

② 갱신 평가

• 클라우드서비스 보안인증의 유효기간은 3~5년이며, 갱신평가는 인증 유효기관이 만료될 때 유효기간 연장을 목적으로 시행하는 평가 / 인증을 말한다.

아래와 같이 인증제도는 각기 다양한 목적과 범위가 있고, 이번 시간은 한국의 클라우드 보안인증제인 CSAP에 대해서 알아보려고 한다!✨

출처 : NHN

소개

CSAP는 『클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률』 제23조 2항에 따라

• 『클라우드컴퓨팅 법』 제23조 2항 과학기술정보통신부장관은 클라우드컴퓨팅서비스의 품질ㆍ성능에 관한 기준 및 정보보호에 관한 기준(관리적ㆍ물리적ㆍ기술적 보호조치를 포함한다)을 정하여 고시하고, 클라우드컴퓨팅서비스 제공자에게** 그 기준을 지킬 것을 권고**할 수 있다.

CSP의 정보보호 기준 준수여부 확인을 인증 기관에 요청하는 경우, 인증 기관이 이용자들이 안심하고 클라우드 서비스를 이용할 수 있도록 지원하는 제도입니다.

또한 ⭐️** 공공기관에** 안전성 및 신뢰성이** 검증된 민간 클라우드 서비스 공급**을 하기 위한 목적을 갖고 있고, ⭐️ 객관적이고 공정한 클라우드 서비스 보안인증을 실시하여 이용자의 보안 우려를 해소하고, ⭐️ 클라우드 서비스 경쟁력 확보할 수 있습니다.

인증 종류

CSAP의 인증 종류 (총 4가지)

• IaaS
• DaaS
• SaaS 표준등급
• SaaS 간편등급

아래 표와 같이 각 인증마다 인증항목 개수, 유효기간이 상이하다. 정리해보면

• 인증항목 개수 IaaS(117개) > DaaS(110개) >>> SaaS 표준(78개) >>> SaaS 간편(30개)
• 유효기간 IaaS, DaaS, SaaS 표준(5년) >>>>>> SaaS 간편(3년)

한눈에도 IaaS 인증이 항목이 제일 많아서 빡세다는 것을 파악할 수 있다. 또한 SaaS 간편 인증 같은 경우 유효기간이 3년으로 짧다는 특징이 있다.

아래 표는 인증 종류별로 준수해야할 통제항목이다.

Tip

어려운 써져있는 법령과 공식 문서를 읽으며 인증제도를 이해하는 것은 쉽지 않다. 입문자들은 어려운 문서를 읽기 전 기업에서 제공하고 있는 정보보호 인증 설명 문서를 읽어보는 것을 추천한다. 이 문서들은 기업들이 어떻게 인증제도를 준수하고 있는지 "클라우드 서비스 이용자"를 대상으로 설명하고 있기 때문에 읽기 편하다!

• 네이버 클라우드 https://www.ncloud.com/certificate
• NHN https://www.nhn.com/ko/company/secureCertification.nhn
• 가비아 https://library.gabia.com/contents/infrahosting/7944/

CSP 3사(AWS, Azure, GCP)는 CSAP를 준수하고 있지 않기 때문에 위 목록에서 제외했다. 3사 또한 자신들이 준수하고 있는 컴플라이언스에 대해서 굉장히 자세하게 설명하고 있다. 개인적인 의견이지만 난 Azure 문서가 좋더라!

VPC로 네트워크를 구성하고 EC2를 띄웠다.

그런데 갑자기 SSH 연결이 안되는 이슈가 발생됐다. 인바운드 규칙을 봐야하는데 보안그룹..? NACL...? 어떤걸 봐야지?

보안그룹과 NACL은 항상 헷갈렸던 개념이였다. 이번 기회로 2개의 VPC 방화벽 서비스에 대해서 정리해보려고 한다!

보안 그룹

보안 그룹 생성

보안그룹은 인스턴스 레벨에서 운영한다. 따라서 EC2 > 보안그룹 메뉴에서 보안그룹을 생성할 수 있다.

• 이름, 설명
• VPC
• 인바운드, 아웃바운드 규칙

를 입력하여 보안그룹을 생성할 수 있다.

보안 그룹 규칙

• 기본적으로 보안 그룹은 모든 아웃바운드 트래픽(송신)을 허용한다.
• 보안그룹 규칙은 허용 규칙만 생성 가능하다.
• 거부 규칙은 생성 불가능하다.

예시

소스, 프로토콜, 포트 범위를 설정하여 구체적으로 트래픽 허용 규칙을 설정할 수 있다. DB 서버의 보안그룹 ID를 주소로 입력하면 해당 DB에 대한 액세스 허용도 가능하다.

네트워크 ACL

네트워크 ACL 생성

네트워크 ACL은 서브넷 레벨에서 운영한다. 따라서 VPC > 네트워크 ACL 메뉴에서 생성할 수 있다.

• 이름
• VPC

을 입력하여 네트워크 ACL을 생성할 수 있다.

생성한 네트워크 ACL을 VPC에 있는 서브넷과 연결해야 한다. 만약 서브넷이 네트워크 ACL을 명시적으로 연결하지 않을 경우, 기본 네트워크 ACL에 자동적으로 연결된다.

네트워크 ACL 규칙

• 기본적으로 사용자가 생성한 네트워크 ACL은 규칙을 추가하기 전에는 모든 인바운드 및 아웃바운드 트래픽을 거부한다.
• 각 규칙에는 규칙 번호가 매겨지고, 가장 낮은 번호가 지정된 규칙부터 시작하여 트래픽이 네트워크 ACL과 연결된 서브넷의 내부 또는 외부로 전달되도록 허용되는지 결정된다.
• 규칙에 사용할 수 있는 가장 높은 번호는 32766이다. 나중에 필요한 곳에 새 규칙을 삽입할 수 있도록, 처음 시작할 때는 증분 방식으로(예: 10 또는 100 단위씩 증분) 규칙을 생성하는 것을 추천한다.
• 보안 그룹과와 달리 허용/거부 여부를 설정할 수 있다.

예시

다음 규칙

• 인바운드 규칙
• 아웃바운드 규칙

참고 레퍼런스 https://www.youtube.com/watch?v=uZssEvTg79s https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_SecurityGroups.html#DefaultSecurityGroup https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html

• Data Store의 경우
• 크롤러를 정의하여 메타데이터 테이블 정의로 AWS Glue Data Catalog*를 채운다. 크롤러를 데이터 스토어로 지정하면 크롤러는 데이터 카탈로그에 테이블 정의를 생성한다. 테이블 정의에 관련해 AWS Glue Data Catalog는 다른 필수 메타데이터를 포함하여 ETL 작업을 정의한다.
• 스크립트를 생성하여 데이터를 변환(Transform)할 수 있다. 스크립트를 AWS Glue 콘솔이나 API에 제공한다.

AWS Glue는 완전 관리형 ETL(추출, 변환 및 로드) 서비스로, 간단하게 여러 데이터 스토어 및 스트림 간에 원하는 데이터를 분류, 정리, 보강, 이동한다.

AWS Glue는 서버리스이므로 설정하거나 관리할 인프라가 없다.

Glue 관련 용어

data store

데이터를 지속적으로 저장하기 위한 저장소(Amazon S3 버킷 및 관계형 데이터베이스)

data store

프로세스 또는 변환에 대한 입력(input)으로 사용되는 데이터 저장소

data target

프로세스 또는 변환이 쓰는(write) 데이터 저장소

크롤러(Crawle)

데이터 스토어(소스 또는 대상)에 연결하는 프로그램은 Classifier의 우선 순위 지정 목록을 통해 데이터의 스키마를 결정한 다음 AWS Glue Data Catalog에 메타데이터 테이블을 생성한다.

분류자(Classifier)

데이터 스키마를 결정 일반 파일 형식(CSV, JSON, AVRO, XML 등)에 대한 분류자(Classifier)

Glue Data Catalog

Glue의 영구적 메타데이터 스토어 테이블 정의, 작업 정의 및 기타 관리 정보를 포함하여 AWS Glue 환경을 관리합니다.

Job

ETL 작업을 수행하는 데 필요한 비즈니스 로직 변환 스크립트(Trasform Script), data sources, and data targets으로 구성

Script

소스에서 데이터를 추출하고 변환하여 대상에 로드하는 코드 PySpark or Scala

Table

Glue는 언제 사용하죠?

AWS Glue를 사용하여 데이터 웨어하우스 또는 데이터 레이크의 스토리지를 조직하고 정리하고 인증한다.

• AWS 클라우드 데이터를 데이터 스토어로 변환하고 이동할 수 있다.
• 정기 보고 및 분석을 위해 데이터를 개별 정적 또는 스트리밍 데이터 원본에서 데이터 웨어하우스 또는 데이터 레이크로 로드할 수 있다.
• 데이터 웨어하우스 또는 데이터 레이크에 데이터를 저장하면 비즈니스의 여러 다른 부분에서 비롯된 정보를 통합하고 의사 결정을 위한 일반 소스를 제공할 수 있다.
  

참고할 자습서

1. aws 공식 홈페이지에 제공하는 Glue 실습 https://docs.aws.amazon.com/ko_kr/glue/latest/ug/tutorial-create-job.html

참고 자료

• https://docs.aws.amazon.com/ko_kr/glue/latest/dg/what-is-glue.html
• https://www.youtube.com/watch?v=LkkgtNtuEoU
• https://docs.aws.amazon.com/ko_kr/glue/latest/dg/components-key-concepts.html

운영체제 3대 구성 요소

1. Scheduler 프로세스를 실행시키기 위한 모든 자원을 관리

2. API 어플리케이션 개발할 때 쓰는 함수

3. File System 디스크에 저장된 실행 파일을 메모리에 올려 실행가능한 프로세스 심볼로 바꿈

오픈스택(클라우드 OS) 내부 구조

오픈스택은 VM을 실행/관리하기 위한 운영체제이다.

오픈 스택 내부 구조 분석

주요프로젝트

1. NOVA
2. NEUTRON
3. SWIFT
4. GLANCE
5. KEYSTONE
6. CINDER
   

1. NOVA

• 오픈스택의 전체적인 VM인스턴스를 스케줄링하는 "스케줄러"역할을 한다.
• 컴퓨터 자원의 풀을 관리하고 자동화 하도록 설계되어 있다.
• 여러 가상화 기술들과 함께 동적할 수 있음.
  • 하이퍼바이저로 KVM, VMware, Xen 중 선택 가능하다
  • 리눅스 컨테이너 사용가능
• 기존 레거시 시스템들과 써드파티 기술들과 연동하는 기능을 제공한다.
• 기업으로 확산되면서 오픈스택의 성능을 모니터링하는 것이 매우 중요해진다.
  • 특히 Nova 성능을 모니터링하는 것이 매우 중요함
    ### 2. Neutron
• 오픈스택의 게이트웨이/스위치 역할을 한다.
• 네트워크와 IP 주소들을 관리한다.
• 사용자는 자신의 네트워크를 만들고 트래픽을 통제하며 서버와 장치들을 하나 이상의 네트워크에 연결할 수 있다.
• 관리자들은 OpenFlowdhk SDN 기술을 이용하여 높은 수준의 멀티 테넌시와 막중한 규모를 지원할 수 있다.
• 침입탐지시스템, 부하 분산, 방화벽, VPN과 같은 추가 서비스들을 배치, 관리할 수 있는 확장 프레임워크를 제공한다.
  ### 3. Cinder
• 오픈스택의 하드 디스크(볼륨 스토리지) 역할을 한다.
• 오픈스택의 인스턴스에서 사용할 블록 스토리지 장치를 제공한다.
• 스냅샷 관리를 통해 블록 스토리지 볼륨에 저장된 데이터를 백업하는 기능도 있다.
  

4. Swift

각종 스토리지 노드들을 관리한다.

하이퍼바이저

• 하나의 물리적인 서버에 여러개의 운영체제를 독립적으로 동시에 실행가능하도록 도와줌
• 서버 전체를 가상화할 때 유리
• 어플리케이션을 실행할때 걸리는 부담이 큼

리눅스 컨테이너

• 하나의 운영체제에 여러개의 컨테이너를 실행 가능하도록 도와줌
• 어플리케이션을 실행할때 걸리는 부담이 작음(가볍고 빠르다)
• 하나의 운영체제에 컨테이너 여러대를 두는 것이기 때문에 컨테이너에 올라가는 어플리케이션은 동일한 운영체제용(리눅스 기반) 어플리케이션이여야 한다.(종속적이라는 단점)

서비스를 제공하는 입장에서는 하나의 서버가 여러개의 서버가 있는 것 같은 기능이 있는 것이 유리하다!(가용성) 이때 사용되는 기술이 하이퍼바이저이다.

이번 시간엔 하나의 운영체제에서 서로 다른 어플리케이션 환경을 격리시킬 수 있는 리눅스 컨테이너에 대해 알아본다.

OS 가상화에서 App가상화로

• OS 전체를 가상화 하면 어플리케이션까지 가는 소프트웨어 스택 레이어가 굉장히 많아져서 무겁고 느리다.

• OS의 일부를 가상화하는 KVM, Xen 등이 있다. 이들은 OS일부를 가상화하지만(가벼워짐), 전체를 가상화하는 효과를 주기 때문에 클라우드 컴퓨팅에 기반이되었다.(openstack 등)

• 여기서 한단계 더 나아가 어짜피 클라우드 컴퓨팅은 거의 리눅스를 쓰니 리눅스 기반에 위에올라가는 App의 커널기술들과 기능들을 직접적으로 지원받을 수 있도록 한 것이 컨테이너이다. 컨테이너는 앱가상화, 즉 프로세스를 격리켜서 더 빠르고 가볍게 운영할 수 있다.

• 이와같이 최근에는 어플리케이션 가상화로 옮겨가는 중이다.
  
  
  

리눅스 컨테이너

왜 요즘 뜨는 기술인가?

리눅스 커널 레벨에서 컨테이너 기능을 지원하기 시작했기 때문이다.

커널 모드에서 작동한다는건? 운영체제에 프리빌리지드 모드라는 것이 있다.

일반 어플리케이션이 실행될 때 : 유저모드 커널이 실행될 때 : 프리빌리지드 모드(특권모드)

프리빌리지 모드로 실행하면 일반 유저모드에서는 접근할 수 없는 특정 메모리에 접근가능하다.

Cgroups

컨테이너에 사용할 자원들이 할당되는 기능

Name Spaces

컨테이너를 다른 컨테이너와 완전히 분리시키는 isolation 기능

왜 Isolation이 중요할까?

시스템 커널에서 문제가 생기면 시스템이 다운된다. 리눅스 컨테이너는 커널 서비스를 제공받기 때문에 컨테이너가 잘못되면 시스템이 영향을 받을 수 있다. 때문에 해당되는 영역, 자원을 "격리"시켜주는 것이 가장 중요하다.

이 격리를 지원해주는 것이 Name Spaces이다.

LXC & Docker

LXC

컨테이너를 관리하는 명령어 툴

LXD

LXC를 보다 더 편리하게 관리하는 일종의 manager

• LXC는 무조건 프리빌리지 컨테이너만 제공하는데, 보안을 위해 언프리빌리지 모드가 필요할때가 있다. LXD는 언프리빌리지 모드를 제공한다.
• 각각의 리소스를 보다 더 편리하게 관리한다.

Docker

• 도커는 이미지 기반이다.
• 이미지는 컨테이너 실행에 필요한 파일과 설정 값등을 고정화 시킨 것(변경할 수 없음)
• 컨테이너에서 추가되고 변경된 값들은 컨테이너에 저장
• 컨테이너가 삭제되더라도 이미지는 그대로
  

LXC vs Docker

LXC는 하나의 컨테이너에 여러가지 App을 넣을 수 있지만. 도커는 하나의 컨테이너에 하나의 App만 가능!

가상화 가능한 분야

1. 데이터 가상화
2. 네트워크 기능 가상화 : NFV
3. 서버 가상화 : 하이퍼 바이저
4. 운영체제 가상화 : 컨테이너

가상화 기술

• 가상머신 : 물리적 하드웨어 시스템에 구축되어 자체 CPU, 메모리, 네트워크 인터페이스 및 스토리지를 갖추고 가상 컴퓨터 시스템으로 작동하는 가상 환경입니다.

• 하이퍼 바이저 : 가상 머신(Virtual Machine, VM)을 생성하고 구동하는 소프트웨어

아파치 카프카는 링크드인에서 처음 개발되었고, 대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼이다. 데이터 파이프라인을 구축할 때 가장 많이 고려되는 시스템 중 하나이다.

Netflix, Airbnb, 카카오, 네이버 등의 주요 기업들에서 사용하고 있다.

카프카의 탄생 배경

카프카의 탄생배경을 알면 카프카를 한번에 이해할 수 있다.

위 그림은 카프카가 개발되기 전 링크드인의 과거 데이터 시스템 구성도이다. 자세히 보지 않더라도 복잡해 보인다.

수년간 이러한 구조가 무분별한 확산되어 어려움을 겪은 후 2010년 데이터 스트림 모델링에 초점을 맞춘 시스템 구축을 위해 카프카 프로젝트가 시작된다.

위 그림은 카프카를 이용한 링크드인의 데이터 처리 시스템이다.

카프카를 적용한 결과, 서비스 아키텍처가 예전과는 비교할 수 없을정도로 깔끔해진 것을 확인할 수 있다.

사내에서 발생하는 모든 이벤트/데이터 흐름을 중앙에서 관리하고 있다.

이와같이 새로운 데이터 처리 시스템에서는, 링크드인 사용자가 프로필을 업데이트하면이 정보가 바로 카프카로 전달된다.

카프카의 도입과 함께 링크드인은 놀랄만한 규모로 성장했고, 오늘날 약 1조개 이상의 메세지를 하루에 처리하고 있다.

카프카의 동작 방식

메세징 시스템

카프카는 기본적으로 메세징 서버로 동작한다. 따라서 카프카의 동작 방식을 알기 위해서는 메세징 시스템에 대한 이해가 필요하다.

하나 이상의 데이터 소스로부터 데이터를 받는 애플리케이션을 떠올려보자. 이 경우 메세징 시스템은 서로 다른 프로그램끼리 정보를 교환하기 위한 통합 채널로 활용이 가능하다.

애플리케이션메세징 시스템을 설계하는 경우 유념해야 할 원칙이 있다.

1. 느슨한 경계 어느쪽에서 변경사항이 생기더라도 다른 프로그램에서는 영향을 받지 않아야한다. 상호간에 의존성을 최소화 해야한다는 것이다.

2. 공용 인터페이스 정의 애플리케이션 간에 데이터 교환을 위해 공용으로 규정된 데이터 형식을 보장한다.

3. 응답 속도 메세지 전송 -> 수신에 소요되는 시간 심각한 지연은 메세지 손실을 발생시킬 수 있다.

4. 신뢰성 일시적인 가용성 문제가 발생해도 정보를 교환하는 관련 애플리케이션에 영향을 주지 않는 것을 말한다.

Publish/Subscribe (펍/섭) 시스템

메세지라고 불리는 데이터 단위를 Publisher(보내는측)에서 카프카에 토픽이라고 불리는 데이터 저장소에 저장하면, Subscriber(가져가는 측)이 원하는 토픽에서 데이터를 가져갑니다.

중앙에 메세징 시스템 서버(카프카)를 두고 메세지를 보내고(publish) 받는(subscribe) 형태의 통신을 펍/섭 모델이라고 한다.

펍/섭 시스템을 쉽게 설명한 블로그 게시물!

멀티 프로듀서, 멀티 컨슈머

카프카는 하나의 토픽에 여러 프로듀서 혹은 컨슈머들이 접근 가능한 구조이다.

카프카의 구조

데이터 모델

• 토픽 : 메세지를 받을 수 있도록 논리적으로 묶은 개념
• 파티션 : 토픽을 구성하는 데이터 저장소, 수평 확장이 가능한 단위
  

카프카 논리적 구조

• 토픽의 모든 메세지는 바이트의 집합(배열)이다.

• 프로듀서는 카프카 큐에 정보를 저장, 로그 선행 기입 파일 마지막에 메세지를 추가한다.

• 컨슈머는 토픽 파티션에 있는 로그 파일에서 메세지를 가져온다.

• 카프카 클러스터는 기본적으로 하나이상의 서버 노드(node)로 구성된다.
  
  

카프카 물리적 구조

• 위 그림은 노드로 구성된 카프카 클러스터이다.

• 카프카 클러스터는 다중 브로커로 구성된다. 각 브로커는 stateless하지만 주키퍼를 사용해 상태 정보를 유지한다.

• 토픽 파티션에는 리더 브로커가 하나씩 있고, 0개 이상의 팔로워가 있다. 리더는 해당하는 파티션의 읽기, 쓰기 요청을 관리한다.

참고 링크

• https://www.confluent.io/blog/event-streaming-platform-1/

하드웨어 인프라 분석

하드웨어 인프라 범위

1. Compute 연산을 하는 서버

2. Block Storage 스토리지를 제공하는 서버

3. Network 네트워크 기능을 제공하는 서버

3가지 종류의 서버들을 클라우드 컴퓨팅 인프라라고 한다 데이터 센터에서 위 서버를 제공, 관리 한다.

데이터 센터 구성 요소

1. 데이터 센터(건물)
2. 서버 랙
3. 서버(하드웨어)

데이터 센터의 오픈소스, OCP 최근에 facebook부터 시작해 데이터 센터를 오픈소스화 하자는 운동이 일어나고 있다.

서버 내부 구조

서버 구성요소

• HDD, SSD
• 이더넷 포트 (네트워크 단자들)
• 전원 단자
• 팬
• CPU 2개 1) intel cpu 3) BMC (서버 원격 관리)
• 마더보드

서버 원격 관리, BMC

Baseboard Management Controller 서버에 os가 부팅되기도 전에 서버의 온도상태, fan상태, 혹은 os자체를 업그레이드하는 등을 담당한다.

이것을 원격으로 관리하려면 당연히 이더넷 포트가 있어야한다. 서버 뒷편에 IPMI(intel이 만든 원격관리를 위한 프로토콜)라는 원격관리 전용 이더넷 포트가 있다.

이 포트를 통해서 BMC기능을 하고 있는 ARM cpu칩에 접속하여 관리하고, 여기에 올라가는 운영체제도 임베디드 리눅스라고 불리는 리눅스이다.

클라우드 컴퓨팅 시대에는 서버에 컴퓨터가 워낙에 많다. 사람이 수동적으로 관리할 수 있는 범위를 벗어나기 때문에 프로그래밍을 통해서 자동화해야한다.

하지만 안타깝게도 BMC 소프트웨어를 전세계에서 다루는 기업이 몇군데 없기 때문에 10년전과 비교했을 때 크게 바뀐 것이 없다.

CCCR 강의를 참고해 작성한 게시물 입니다. https://www.cccr-edu.or.kr/classroom/index.jsp?cuid=1498823

한마디로

언제든지 필요한 데이터를 가져와 꺼내 쓸 수 있도록 데이터를 계속 쌓아두는 파이프를 만드는 것이라고 보면된다.

데이터 파이프라인 사용 예시

파이프를 한 번 만들고 나면(배수관 파이프를 생각해보자, 여기서 데이터는 배수관 안으로 흐르는 물이라고 생각하면 된다) 큰 문제가 없는 한 데이터가 계속 들어와 쌓일 것이다.

어떻게 해야 적은 수고를 들이고 효율적으로 필요한 데이터를 모을 수 있을까? 데이터를 가져오는 과정에서 정제나 전처리가 쉽도록, 데이터 형태도 고쳐주고 필요없는 데이터는 제거하고 함께 보는게 좋은 데이터들은 합쳐서 저장하면 좋을 것 같다.

이러한 목적으로 만드는 것이 데이터 파이프라인이라고 보면 된다.

데이터 파이프라인이 하는 일

• Data extracting: 데이터 추출
• Data transforming: 데이터 변경
• Data combining: 데이터 결합
• Data validating: 데이터 검증
• Data loading: 데이터 적재

  이 중 데이터 추출, 변환, 적재를 묶어 ETL이라고 한다. ETL은 데이터 파이프라인 하위 개념으로, 하나의 시스템에서 데이터를 추출해 변환하여 데이터 베이스 or 데이터 웨어하우스에 차곡차곡 쌓아둔다.

데이터 파이프라인 구축을 위해서 무엇이 필요한가?

1) 분산 처리 프레임워크

• Hadoop, Spark
• 대규모의 데이터 셋을 효율적으로 처리하기 위해 사용한다. 하나의 대형 컴퓨터를 사용해서 데이터를 처리&저장 하는 대신에, 분산 처리 프레임워크를 사용하면 상용 하드웨어를 함께 클러스터링하여 대량의 데이터 세트를 병렬로 분석할 수 있다.
  

2) 데이터 레이크

• S3, HDFS
• 모든 데이터를 그대로 저장하고, 나중에 필요한 것만 꺼내서 사용하는 스토리지
  

3) Workflow 관리시스템

• Airflow, Oozie, Dagster, Argo
• 여러가지 태스크들(데이터셋 생성, 모델 학습 등)을 일련의 그래프로 연결하고 스케줄링, 모니터링 등 파이프라인을 관리할 수 있다.

  Airflow에서 사용하는 DAG이란? Directed Acyclic Graph, 즉 방향이 있지만 순환하지는 않는 그래프이다.
  라면 끓이는 work flow를 생각해보면 물끓이기 -> 스프 넣기 -> 면 넣기 -> 계란 넣기 task마다 방향은 있지만 다시 자기 자신으로는 돌아오지 않는다. 순환하지 않는 이러한 그래프를 코드로 나타낸다.

4) 데이터 웨어하우스

• BigQuery etc
• 대량의 데이터를 분석하기 좋게 체계적으로 보관해놓는 데이터 창고이다.
• 가공되지 않은 데이터를 모아 놓은 창고는 데이터 레이크이다.

  데이터 웨어하우스의 주요 특징 4가지
  

  1. 주체 지향 : 업무 중심이 아니라 주제 중심으로 데이터를 조직화 한다.(고객 거래처, 상품, 활동 등)
  2. 통합 : 데이터를 활용하기 좋은 형태로 변환하기 위해 표준화 기준으로 설정, 적용함으로 데이터를 통합해야 한다.
  3. 시계열 : 시간 별로 데이터 버전들을 저장한다.(데이터를 시간에 따라 수시로 갱신하거나 변경x)
  4. 비휘발성 : 데이터 웨어하우스의 데이터로 수행할 수 있는 작업은 데이터 로딩, 데이터 엑세스 뿐이다.(데이터의 변경, 삭제는 이뤄지지 않는다)

데이터 파이프라인 실습

우선은 데이터 파이프라인을 한번 경험해보는 것이 좋을 것 같아서 정리된 실습 강의를 찾아왔다.

1) T academy "빅데이터 파이프라인 기술의 이해 및 적정도구의 선정"

• 빅데이터 파이프라인 기술을 이해하고, 여기에 사용되는 주요 클라우드 플랫폼 및 다양한 도구들의 장단점, 유스케이스에 맞는 도구를 선택하는 방법을 알아봅니다.
• 220분
• https://tacademy.skplanet.com/live/player/onlineLectureDetail.action?seq=116

2) T academy "소셜 데이터 분석을 위한 데이터 파이프라인 구성 실습"

• 트위터와 같은 소셜 빅데이터 분석을 위한 데이터 파이프라인 구성의 전체 flow를 간단하게 실습하여 경험할 수 있습니다.
• 200분
• https://tacademy.skplanet.com/live/player/onlineLectureDetail.action?seq=117

참고 링크

• https://st-soul.tistory.com/120
• https://eehoeskrap.tistory.com/219
• https://hengbokhan.tistory.com/164
• https://seoyoungh.github.io/data-science/data-pipeline-detail/

전체 일정은 2번째 공지를 참고해주세요.

모임 시간은 주차별로 조절할 예정입니다

🌧 이번주 팀별 회의 내용

🔍 1팀 박진희, 강채희, 이지연

• 주제: 데이터 파이프라인 구축
• 자료 조사: 박진희(블로그 링크), 이지연(블로그 링크), 강채희(word)
• 과제 1) 강의 1편 들어오기 2) 주제 1~2개 생각해오기

🔍 2팀 오송아, 정지인, 허지호

• 주제: 도커와 CI환경구축
• 과제: 1) 강의 들으면서 용어 정리 해오기 2) 실습 강의 진행 3) 기획할 주제 생각해오기
• 참고레퍼런스 https://www.inflearn.com/course/%EB%94%B0%EB%9D%BC%ED%95%98%EB%A9%B0-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%8F%84%EC%BB%A4-ci#curriculum

다음 모임은 6/22(화) 입니다.

• 주제/기획 정하기(1/2)
• 팀별로 과제(or 실습) 정해서 2주동안 진행해보기(공부 or 실습)

🌧 이번주 팀별 회의 내용

🔍 1팀 박진희, 강채희, 이지연

• 큰 틀: 빅데이터 관련 주제
• 참고 레퍼런스
• 22일까지 데이터 파이프라인 구축편 읽고 모르는 용어정리 해오기
• 관련 실습 찾아오기

🔍 2팀 허지호, 오송아, 정지인

• 큰 틀: 서버리스 기반 웹 어플리케이션 구축 + 도커파일로 웹 호스팅
• 주제: 송아님 주제랑 지연님이 올려준 주제인 핀테크에 현재 관심이 있음 자세한 주제/기획은 22일날 정하기
• 22일날 앱 구축 실습 진행해보기 시작(과제)
• 도커 공부도 함께 할 예정

🌧 Todo

시험공부 화이팅!!

API (Application Programming Interface)

API Gateway란?

• API를 만들고 운영하고 모니터링 가능
• Back-end 서비스(웹 어플리케이션, EC2)에 들어있는 데이터 접근 허용

🐤 Code Commit & Deploy & Pipeline

CI/CD

• CI : Continuous Integration (지속적인 통합)

• CD : Continuous Deployment (지속적인 배포)

• CI/CD 장점 자동화 시스템 - 테스트 Incremental Change

Code Commit

• 파일들을 보관하는 저장장소(Repository) - Github과 매우 유사
• 동시에 많은 사람들이 저장 장소 접근 및 업데이트 가능
• 버전 컨트롤 기능 제공 (언제 어떻게 누가 저장장소 내용을 변경했는지)

Code Deploy

• Code Deploy 장점 새로운 기능들의 빠른 배포, 소프트웨어 & 서버 다운 타임 X Manual 에러 X

• Rolling 배포 이전 버전으로 돌아가기 어렵다, 대신 쉽다

• Blue/Green 배포 이전, 최신 버전과의 스위치가 편하다

CD 실습 순서

IAM에서 유저 생성 로컬 환경에서 개발 s3 버킷으로 파일을 업로드 code Deploy가 배포를 하게해주는 파이프라인을 구축

Code Pipeline

• Code Pipeline이 하는 일은? 빌드, 테스트, 배포 과정을 관리 소프트웨어 어플리케이션 출시 자동화 가능

🐤 느낀점

• AWS에서는 코드 저장장소로 Code Commit을 사용다는 것을 깨달았다.

• AWS 입문자 강의를 모두 수강했다는 것이 일단 뿌듯했다. 이번 수업을 통하여 aws 주요 서비스를 하나하나 실습해보며 조금은 친숙해진 것 같다.

• 이제 곧 1학기가 끝나는데 소학회원들과 AWS 아키텍쳐 자격증도 같이 준비해야겠다는 생각이 들었다.

• 다음 모임은 6/1(화) 입니다
• 줌 모임*이고, 바로 논문 준비가 시작됩니다!

🌧 Todo

✅ 블로그에 피드백 댓글 남기기!

<클라우드 관련 논문 주제, 레퍼런스 찾아오기 과제> 해오시느라 너무 고생하셨습니다👏

과제로 블로그에 정리해온 내용을 모두 읽어보고 피드백 댓글을 남기는 것이 과제입니다!

자신을 제외한 총 5개의 게시물에 댓글을 달아주세요.

궁금한 점, 느낀 점, 덧붙이고 싶은 내용 등 부담없이! 편하게! 댓글 남겨주시면 됩니다!

단, 내용은 꼼꼼히 읽어보셨으면 좋겠습니다😊

aws입문자 강의를 모두 수강하느라 수고했습니다! 클클 홧팅❤️