[Microservice Programming] L16.Kubernetes

• toc {:toc}

Kubernetes Overview

• Kubernetes : 컨테이너화된 App을 자동으로 배포, 자원 할당, 운영을 하는 구글이 제작한 오픈소스 시스템이다.
• 쿠버네티스에게 운영자는 본인이 원하는 desired state를 제공하면 쿠버네티스는 desired state를 만족시키는 쪽으로 조정한다.
• 운영자의 최소 단위는 pod 단위이다. 너무 작은 단위가 아니라, 서비스 입장에서의 최소 단위
• cattle 모델을 사용하여 문제가 생기면 죽이고 다시 만드는 것이고 이를 ip 주소로 받아 파악하려 하면 힘들다. 때문에 DNS를 이용한 이름을 사용하여 동작시킨다.

Monolithic vs Microservice

• 값이 싼 인텔 CPU에 리눅스를 올리고 한 대에서 해야할 일을 쪼개 여러 개의 컴퓨터에서 네트워킹을 해서 작동시키면 비용을 아낄 수 있지 않을까?

• 필요할 때 필요한 만큼 CPU, Disk, Network를 빌려 쓰고 사용한 만큼 비용을 지불한다. - Cloud Computing

• 쪼갤 수 있다면 매우 작은 단위로 쪼갠다.

• 쪼갠 것을 띄워야 하기 때문에 OS로 인해 CPU를 많이 잡아 먹는 가상머신이 아닌 필요할 때 필요한 만큼 사용할 수 있는 컨테이너 기술을 사용한다.

• 전통적 방식

  • 모두 통일된 방식으로 사용해야 한다.
  • Main Frame : 보수적이기 때문에 고수한다.

• 마이크로서비스

  • Monolithic 아키텍쳐에서 커다란 하나의 서비스로 사용하던 것을 100개의 기능이라고 하면 각각을 찢어 독립된 것으로 분리하는 기술
  • 서비스에 따라 필요한 경우 필요한 기술, 더 괜찮은 기술을 사용하면 된다. 각 프로그램들의 특성에 맞게 알맞는 기술을 사용한다.
  • 정형화된, 통일된 형태를 가질 필요 없다.

• 프로그램이 점점 커지고 팀이 커지면 어떻게 되는가?

  • 전통적 방식
    • 하나의 프로그램으로 통합하거나 2~3개로 나누어 기능을 분할하는 형식
    • 하나의 통일된 언어로 개발
    • 개발 능력이 안 되면 개발 능력을 길러야 했다.
  • 마이크로서비스
    • 서로 정보를 주고 받으면 되기 때문에 아래와 같은 장점을 갖는다.

Microservice Architecture

• Scalablility

  • 각 마이크로서비스는 다른 마이크로서비스의 영향없이 독립적으로 용량을 가질 수 있다.
  • 특정 기능의 용량을 늘리고 싶을 때 Monolithic은 분리하지 못해 다른 기능도 scale up 되어야 한다. 하지만 마이크로서비스는 다른 서비스의 영향없이 용량을 늘릴 수 있다.

• Availability

  • 한 서비스에 문제가 발생하더라도 다른 마이크로서비스들에 미치는 영향이 크지 않다.
  • 문제가 생긴 마이크로서비스는 매우 빠르게 되살릴 수 있다.
  • 100개 중 1개의 기능이 오동작을 하는 경우에 Monolithic은 다른 기능이 모두 문제가 발생한다. 마이크로서비스는 독립적으로 되어 있어 다른 서비스에 미치는 영향이 크지 않다.

• Fault Tolerance

  • 다른 서비스들이 잘 작동하기 때문에 전체 App이 다운되는 것 대신에 작은 부분만 영향 받는다.

• Agility

  • 빠른 배포 과정이 agile 환경을 의미하는 변화하는 요구를 위한 적합한 아키텍처를 만들 수 있도록 한다.
  • 100개의 기능을 1000명이 만들었다고 한다면 1개의 기능을 10명이 제작. Monolithic은 모두가 같은 제한 시간까지 기능 제작을 완료해야 빌드, 배포를 할 수 있다. 하지만 마이크로서비스는 각 기능마다 따로 빌드, 배포를 할 수 있다. 빠른 빌드, 배포 가능

• Polyglot Persistence

  • Polyglot : 다양한 언어를 사용할 수 있는 경우 즉, 올바른 사례에 알맞는 올바른 도구를 선택한다.
  • Application stack은 특정 데이터베이스에 묶여있지 않는다.

• Maintainability

  • 기능들을 분리했기 때문에 감소된 코드 양으로 인해 유지 보수하기 편리하다.

• MS Word / Office / Game → Monolithic → 빠르게 변경하지 못한다.

왜 Microservice Architecture 인가?

• Software Stack agnostic
  • 하나의 소프트웨어 스택으로 묶인 것이 아니라 나누어져 있기 때문에 각 마이크로서비스에 알맞는 다양한 소프트웨어 스택이 사용될 수 있다.
• Faster Development
  • 빠르게 요구사항에 알맞는 변경을 할 수 있다.
• Clear Separation of Business Concerns
  • 비즈니스의 문제에 대한 명확한 분리가 되는 점. 문제가 발생할 경우 빠르게 소통하고 움직이고 해결할 수 있다.