search

skarltjr / Memory_Write_Record

나의 모든 학습 기록
0 stars 0 forks source link

클라우드 자문자답 #105

Open skarltjr opened 2 years ago

skarltjr commented 2 years ago

말로 설명해보자

  1. 클라우드 컴퓨팅이란 무엇인가? 
    
클라우드 컴퓨팅이란 : 
물리적으로 자원을 연결하여 활용하는것이아닌 보이지 않는 어딘가에 위치한 자원을 인터넷을 통해 접근 및 활용하는것
이를 가능하게 하는것이 바로 가상화

가상화란 : 하나의 자원을 쪼개거나 여러 자원을 묶어 마치 하나의 자원으로 사용하는것 가령 클라우드 서비스에서 vm을 사용해본 경험이 있을텐데 클라우드 서비스 사업자는 대규모의 cpu,memory,storage등의 자원을 갖추고 이를 작고 큰 단위로 쪼개어 사용자 요구에 맞게 묶어 하나의 가상 컴퓨터를 제공한다.

2. 스케일 아웃(Scale-out)과 스케일 업(Scale-up)의 차이를 설명하라.

스케일 아웃 : 수평적 확장으로 자원의 성능을 늘리는것이 아닌 동일한 성능의 서버 개수를 늘리는 수평적 확장

스케일 업 : 하나의 서버의 성능자체를 올리는것 분명한 한계가 있다 따라서 내가 생각하기에 좋은 서비스의 방향은 성능에 의존이 아닌 언제든지 확장할 수 있는 확장성을 고려한 서비스라고 생각

3. MSA(Micro service Architecture)의 개념을 설명하라.4. 
4. MSA의 장점은 무엇인가? 기존 방식에 비해 어떤 Benefit을 가져올 수 있는가? 그리고 그에 따른 단점이나 리스크가 있는가?

기존의 모놀리틱 구조의 단점 극복을 위해 등장한 아키텍쳐

  1. 기존 모놀리틱 아키텍쳐의 단점

    • 여러 서비스가 단일 애플리케이션에 구성되어있기 때문에 상호 의존적으로 a의 장애는 전체 서비스 장애로 이어진다
    • 모든 서비스가 하나의 애플리케이션에 구성되어있기 때문에 배포시간이 굉장히 길어진다.
    • 서비스마다의 선택적인 기술 활용이 어렵고 확장에 불편

  2. MSA

    • 하나의 애플리케이션을 서비스, 컴포넌트별로 쪼개어 작은 여러 서비스가 하나의 큰 서비스를 이루는구조
    • 단일 장애의 전파력을 낮출 수 있다.
    • 작은 서비스 단위로 배포가 가능하며 확장에 용이
    • 서비스별 활용 기술을 달리할 수 있다.

  3. MSA의 단점

    • 관리가 어렵다. ex) 서비스가 분산되어 있어 테스트가 어렵고 트랜잭션 관리가 어렵다
    • 데이터 관리가 어렵다

  4. 컨테이너란 무엇인지 설명하라.

    
컨테이너란 : 
애플리케이션을 위한 "컴퓨팅 환경"이 아닌 "실행 환경"을 구축
호스트OS상에 논리적인 구역(컨테이너)을 만들고 애플리케이션 실행을 위한 라이브러리등을 모아 마치 별도의 서버처럼 동작

VM과 비교하여 별도의 Guest Os가 없기 때문에 이를 위한 자원 소모가 없으며 hostOS 커널을 공유함으로써 vm에서 guest host os 커널 두 번을 거치기위한 변환작업의 오버헤드도 감소

6. 컨테이너를 위한 운영 환경에는 어떠한 것들이 있는가? 가장 많이 사용되는 것은 무엇인가?
7. 쿠버네티스가 가장 선호되는 이유가 무엇이라고 생각하는가?

쿠버네티스.

기존에도 로드밸런싱, 서비스 discovery 등의 기능을 수행하는 오픈스택과 같은 오케스트레이션 툴은 존재했다. 중요한것은 쿠버네티스는 이 행위들을 컨테이너를 대상으로하는 컨테이너 오케스트레이션 툴이라는점


8. 쿠버네티스 클러스터의 기본 아키텍처에 대해 설명하라.

클러스터란 : 노드의 집합체 노드 : 컨테이너화된 애플리케이션을 실행하는 서버 워커 노드 : 실질적으로 컨테이너를 실행시키는 서버 마스터 노드(컨트롤 플레인) : 워커노드와 클러스터를 관리

컨트롤 플레인 : API 서버 : 쿠버네티스 컨트롤 플레인의 프론트엔드로 외부의 요청을 클러스터 구성 요소에게 전달하는 매개체 etcd : 클러스터의 모든 정보를 담고 있는 저장소 스케쥴러 : 파드를 새로 생성하는 역할을 담당. 파드를 어떤 노드에 생성하는게 가장 적절한지 선택 컨트롤러 매니저 : 기생성된 파드를 관리. 쿠버네티스는 선언적 구성. 즉 이거 레플리카 5개로 유지할거야!라고 선언하면 제어루프를 통해 지속적으로 감시하면서 만약 삭제되거나 추가되면 5개의 개수를 맞춘다.

워커 노드 : kubelet : 컨테이너가 동작하도록 관리. 쿠버네티스 클러스터와 워커노드의 cpu/mem/disk 연결

kube-proxy : 쿠버네티스 service에 맞게 커널의 netfilter등을 관리

컨테이너 런타임 : 실제로 컨테이너를 실행하는 소프트웨어로 도커가 대표적

9. 쿠버네티스에서 Auto Scaling의 원리에 대해 설명하라.

쿠버네티스에선 필요한 경우 자동으로 가변적인 수평적 스케일링이 가능한데 이것이 오토 스케일링 기생성된 파드를 관리하는 컨트롤 플레인의 컨트롤러 매니저가 루프를 돌면서 request값과 현재 확인되는 매트릭값을 비교하여 파드 개수 확장 및 축소를 수행

동작 방식 : Horizontal Pod Autoscaler 컨트롤러는 원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로 작동 ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )] 예를 들어 현재 메트릭 값이 200m이고 request 값이 100m인 경우 200.0 / 100.0 == 2.0이므로 복제본 수가 두 배가 된다 반대로 현재 메트릭 값이 50m 이면, 50.0 / 100.0 == 0.5 이므로 복제본 수를 반으로 줄일 것

resources에 request가 우리가 요청한 원하는 값

ex) apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 1 template: metadata: labels: run: php-apache spec: containers:

apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: kubernetes-simple-app-hpa namespace: default spec: maxReplicas: 10 minReplicas: 1 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: php-apache targetCPUUtilizationPercentage: 30

만약 아래처럼 적용한경우는 cpu활용량이 50퍼를 넘어가면 최대 10개까지 파드를 추가 생성하여 감당할 수 있다 kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10