데이터센터프로그래밍17

17-Microservices and Katakoda

🟢 쿠버네티스란?

• docker swarm도 오케스트레이터이지만, 쿠버네티스가 docker swarm보다 훨씬 더 많은 기능, 훨씬 큰 규모의 컨테이너 네트워크 등 더 나은 서비스를 제공함

🟢 오늘의 학업 목표

• Microservices가 무엇인지?
• Microservices가 왜 중요한지?
• Katakoda를 사용하는 방법

🟢 Microservices

• Product "group of independent service"
• 과거에는 큰 프로그램을 짜서 여러개의 복사본을 띄웠었음
• Microservices는 서로 독립적인 프로그램들인데, 하나로 만들어서 여러개를 띄우기 보단, independent service를 통해 각 개별적으로 연결함

🟢 Monolithic vs. Microservices

• 왼쪽은 Monolithic의 아키텍처, 오른쪽은 Microservices의 아키텍처임
• ✏Monolithic 운영체제의 kernel에서 많이 사용하는 용어인데, 하나에 모든것을 포함시키는 것을 의미함(여러개가 묶여 하나로 되어있음)
• ex. 사용자가 접근하는 user interface(UI)가 있고, 입력을 받아 작업과 출력하는 logic, 데이터가 있는 interface가 있음
  : docker container에서 front-end가 UI, back-end가 logic, data-base가 있음
• 🙂 즉, UI & logic & data-base 3가지의 융합으로 실행되어 하나의 어플리케이션을 구현할 수 있음
• ✏ Microservices(작은서비스들)는 하나의 어플리케이션을 구현하기 위해서 3개의 기능일 필요한 것이므로, 물리적으로 하나의 실행파일에 포함시킬 이유는 없음(각각 띄어내는 것을 의미)
• ex. 3개(UI & logic & data-base)를 각각의 실행파일로 생성하여 실행함
• 🙂 즉, 독립적인 실행파일로 실행함으로써, 3개(UI & logic & data-base)가 서로 정보를 주고 받으면 원하는 어플리케이션이 실행됨
  🦜 정리
• Monolithic의 구조적인 특징 : 어플리케이션을 구성하는 3개를 모두 묶어서 하나의 실행파일로 만들었음
• Microservices의 특징 : 하나의 어플리케이션을 구성하는 요소들을 각각 독립적으로 동작시킴
  

🟢 Example Monolithic Architecture

• Browser를 통해서 Apache서버에 접근을 하면, logic을 돌리는 프로그램이 있고, 필요한 경우에 data-base를 불러서 사용하기도 함
• Apache는 웹을 띄어주는 역할을 하기 때문에 tomcat 안에 있는 것들은 개발자들이 만듭니다. 이를 모두 하나의 어플리케이션에 포함시킴
• ex. 그림을 보면, tomcat 안에는 온라인 쇼핑몰을 구현한 것인데, 하나의 어플리케이션 안에서 모든 기능이 구현이 되는 것을 Monolithic Architecture라고 할 수 있음
• 만약에, 사용자의 요구가 늘어남으로써 한대의 컴퓨터로 어려운 상황일 때, 용량을 늘려야 하는데, 용량을 늘리기 위해서는 1) 한대의 컴퓨터로 수행하고자 하는 경우: 성능이 좋은 컴퓨터로 실행하는 것 2) 실행되는 컴퓨터 옆에 새로운 컴퓨터를 구매후 동일한 프로그램을 실행시킴 (각자 따로 실행하고 있음)
  

🟢 Deploying a Single Monolithic Application

• e-commerce application : 사용자가 접근을 하여 물건들을 구경 ➡ 주문을 하게 되면 inventory(물건재고)가 있는지를 확인 ➡ 결제가 가능한지 확인 ➡ 물건을 보냄
• 필요한 다양한 구성요소를 StoreFrontUI(user interface; UI)에 포함시킴
• credit, maintaining inventory & shipping orders들을 모두 다 하나의 프로그램에서 수행함
• 🙂 즉, 하나의 프로그램이 주문, 재고관리, 결제관리 등의 복잡한 프로그램(작업)을 실행하는 것
• 상품이 대박이 났을 경우... application & application 관리하는 개발자도 커짐
• 🙄 이때, 어떻게 대응을 해야할까? 이를 해결하기 위해 Microservices가 등장함(Microservices를 사용하는 이유 & 장점)
• 그렇다고, Monolithic Architecture가 별로라는 의미는 아님... 학교 학생들을 관리하는 경우는 수가 많이 늘어날 이유가 없으므로, 이런 경우에는 Monolithic Architecture를 사용하는것이 적합함

🟢 Microservices 사용하는 이유?

• (1) 프로그램이 커질 경우를 감안해야 할 때 (용량이 클때)
  ✅ 적재적소에 맞춰 필요한 용량에 해당하는 만큼 제공함으로 효율적임
• (2) 개발팀이 인원과 팀 자체가 여러개로 나뉠 때(front-end/서버관리 등)
  ✅ ex. user interface(UI)팀은 릴리즈를 1일에 2번, data-base팀은 한달에 1번함으로써, 최적화된 릴리즈 일정에 맞춰 진행할 수 있음
  ✅ API만 준수하면 되므로 각각의 팀이 따로 동작을 함 (직원을 채용할 때도 그 분야에 최적화된 사람 채용할 수 있음 + 코드를 자신의 part만 공부하면 되기에 교육과 시간이 절약됨)

🟢 Deploying a Microservices Application

• Monolithic의 한계를 극복하기 위해 큰 컴퓨터를 사용해야 하는데, 큰 컴퓨터 또한 용량의 한계를 가질 수 밖에 없음
• Monolithic의 경우는 여러개의 컴퓨터를 실행하는 것밖에 할 수 없어서 문제들이 발생함
• Traditional Approach는 컴퓨터에 복사를 통해 실행하였지만, Microservices Approach는 개별적으로 띄우는 것을 의미
• Microservices Approach를 개별적으로 띄울 때 중요한 점은 다음과 같음 (ex. 4개의 modual(storeFrontUI, Accounting Service, Inventory Service, Shipping Service)용량이 늘어난다고 할 때, 모두 동일하게 증가하는 경우는 거의 없음)
• 🔔Microservices는 개별적으로 구성되어 있기 때문에 필요한 SW(필요한 Microservices)에 대해서만 용량을 증가시킬 수 있음
• 🙂 즉, 용량증가를 Microservices 단위의 필요한 만큼 조절할 수 있음
• 각각 개별적으로 구성되어 있어서 API로 주고 받을 수 있음 (API만 준수하면, component끼리 관여하지 않음)
• 🙂 즉, 자신이 만든 SW가 개선 & 기능확장이 되더라도 component끼리 관여하지 않으니, 일처리가 빨라짐

🟢 Why Microservices Architecture (1)

• (1) Scalability (확장성=용량)
  : 일회용량이었는데, n으로 늘어났을 때, Monolithic은 여러대의 컴퓨터를 추가하여 똑같이 다시 구성해야 하지만, Microservices의 경우에는 component가 나눠져있으므로, 그 중 어떤 part가 용량을 늘려야하는지를 확인하고, 필요한 만큼 독립적으로(independent) 자원을 늘릴수 있어 효율적임
• (2) Availability (유효성=장애발생시, 서비스가 가용하게 동작하는지)
  : Microservices의 경우에는 component가 나눠져있으므로, 문제가 발생한 part(일부)는 죽을 수 있지만(사용자에게 약간의 불편함, 시간지연이 발생할 수 있음), 전체에 영향을 주지는 않음
• (3) Fault Tolerance (결함 허용=장애에 대한 대응)
  : 전체가 아닌, small part에 대한 부분이 죽는 것이므로, 전체가 망가질 것이라는 걱정은 하지 않아도 됨
  🧙 개발과 유지 보수적인 부분
• (4) Agility (민첩=시장에 맞춰 릴리즈의 빈도가 빠름)
  : 시장의 상황을 보면서 즉시 개선함, Monolithic의 경우는 한꺼번에 움직임으로 묵직하지만, Microservices의 경우에는 독립적이기 때문에 각각 최적화된 시장대응과 본인의 릴리즈 날짜에 맞춰 서비스를 제공할 수 있음
  : ex. 네이버, 다음과 같은 웹서비스의 경우: user interface(UI)를 하루에 1-2번 서비스를 릴리즈함
• (5) Polyglot Persistence (다중언어 지속성)
  : 목적에 맞는 도구를 최적화하여 사용할 수 있음
  : database의 경우 SQL(tabel 방식) or NoSQL을 사용할 때, Monolithic은 하나의 어플리케이션으로 나와야하기 때문에 manager languge를 정해야하고, 부분별 연동을 해야함으로 다른 languge를 interworking함 but, 중요한점은 manager languge와 database가 각각 정해짐
  : 🙂 따라서, 4개의 modual(storeFrontUI, Accounting Service, Inventory Service, Shipping Service)에서 3개는 MySQL이 좋다고 하였는데, 다른 1개는 SQL(tabel 방식)을 선호하더라도 MySQL로 정해지면 이대로 가야함
  : but, Microservices에서는 독립된 프로그램이기 때문에 각각의 도구 & 언어 & database를 사용하면 됨
  ➡ 🙂 독립된 프로그램이기에 개발방법은 각자 선택해도 됨
• (6) Maintainability (유지보수성)
  : Microservices의 경우에는 독립적인 프로그램을 사용할 것이므로 유지보수할 code의 양, test에 대한 부하가 줄어듦

🟢 Example Polyglot Persistence

• E-commerce platform이 있을 때, 배송하는 것(Shopping cart & session data), 물건을 보여주는 것(Inventory & Item Price), 고객관리(Customer Social graph), 결제완료(Completed Orders)가 각각 서로다른 tool, 언어, 프레임워크를 사용해도 문제 없음
• 🙂 따라서, 각각에 최적화된 방법으로 개발된다고 할 수 있음 (단, aizare 정신에 맞는 엔지니어들이 모여야 가능함)
  

🟢 Why Microservices Architecture (2)

• (1) Software Stack agnostic
  : 독립적인 SW에 최적화되어 있음 (언어, 운영체제, 프레임워크, database 선택 가능)
  : 🙂 따라서, 통일할 필요없이 최적화된 개발 도구 & 방법을 적용할 수 있음
• (2) Fasrer Development
  : 덩치크게 움직일 필요가 없다는 의미로, 각각의 Microservices가 주고 받는 API만 합의를 보았다면, SW의 설계개발 & 릴리즈에 대한 부분을 각각의 Microservices가 역할에 맞게 움직임
• (3) Clear Separation of Business Concerns
  : Monolithic의 단점인 잘못되면 전체가 무너질 수 있다는 걱정을 줄 수 있음
• 🔔 Microservices Architecture의 장/단점은?
• 🔔 Microservices Architecture의 장/단점을 갖는 프로젝트가 무엇인지?

🟢 Katakoda 실습

• 참고: https://www.katacoda.com/
• (1) 사이트에 접속 후 : Kubernetes Introduction 클릭
  
• (2) Launch A Single Node Cluster 클릭
• 아래와 같은 문구가 있다
• "Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day."
  : 문구에 대한 설명을 보면, Minikube는 Kubernetes를 컴퓨터 1대에서 설치하는 것임
  : Kubernetes가 다양한 컴퓨터 위의 수많은 container를 다루는 것이므로, Minikube를 설치하면, 본인 컴퓨터 1대에서 실행가능(=가상 머신(Virtual Machine, VM))
  

🟢 Katakoda 실습 (1) : Start Minikube

$ minikube version
minikube version: v1.8.1
commit: cbda04cf6bbe65e987ae52bb393c10099ab62014
$ minikube start --wait=false
* minikube v1.8.1 on Ubuntu 18.04
* Using the none driver based on user configuration
* Running on localhost (CPUs=2, Memory=2460MB, Disk=145651MB) ...
* OS release is Ubuntu 18.04.4 LTS
* Preparing Kubernetes v1.17.3 on Docker 19.03.6 ...
  - kubelet.resolv-conf=/run/systemd/resolve/resolv.conf
* Launching Kubernetes ... 
* Enabling addons: default-storageclass, storage-provisioner
* Configuring local host environment ...
* Done! kubectl is now configured to use "minikube"

🟢 Katakoda 실습 (2) : Cluster Info

$ kubectl cluster-info
Kubernetes master is running at https://10.0.0.26:8443
KubeDNS is running at https://10.0.0.26:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
$ kubectl get nodes
NAME       STATUS   ROLES    AGE     VERSION
minikube   Ready    master   6m34s   v1.17.3

🟢 Katakoda 실습 (3) : Deploy Containers

$ kubectl create deployment first-deployment --image=katacoda/docker-http-server
deployment.apps/first-deployment created
$ kubectl get pods
No resources found in default namespace.
$ kubectl expose deployment first-deployment --port=80 --type=NodePort
service/first-deployment exposed
$ export PORT=$(kubectl get svc first-deployment -o go-template='{{range.spec.ports}}{{if .nodePort}}{{.nodePort}}{{"\n"}}{{end}}{{end}}')
$ echo "Accessing host01:$PORT"
Accessing host01:31650
$ curl host01:$PORT

🟢 Katakoda 실습 (4-1) : Dashboard

$ minikube addons enable dashboard
* The 'dashboard' addon is enabled
$ kubectl apply -f /opt/kubernetes-dashboard.yaml
namespace/kubernetes-dashboard configured
service/kubernetes-dashboard-katacoda created
$ kubectl get pods -n kubernetes-dashboard -w
NAME                                   READY   STATUS    RESTARTS   AGE
kubernetes-dashboard-79d9cd965-htzq9   0/1     Pending   0          0s
dashboard-metrics-scraper-7b64584c5c-txcm4   0/1     Pending   0          0s
kubernetes-dashboard-79d9cd965-htzq9         0/1     Pending   0          0s
dashboard-metrics-scraper-7b64584c5c-txcm4   0/1     Pending   0          0s
dashboard-metrics-scraper-7b64584c5c-txcm4   0/1     Pending   0          7s
kubernetes-dashboard-79d9cd965-htzq9         0/1     Pending   0          7s
dashboard-metrics-scraper-7b64584c5c-txcm4   0/1     ContainerCreating   0          9s
kubernetes-dashboard-79d9cd965-htzq9         0/1     ContainerCreating   0          9s
kubernetes-dashboard-79d9cd965-htzq9         1/1     Running             0          11s
dashboard-metrics-scraper-7b64584c5c-txcm4   1/1     Running             0          11s

🟢 Katakoda 실습 (4-2) : Dashboard 확인

🤩 VScode를 통해 docker 개발이 용이함

• 참고사이트: https://code.visualstudio.com/docs/remote/containers

🤩 Theia

• 참고사이트 : https://theia-ide.org/