kubernetes 기본 개념정리와 구성 알아보기 (설치 포함)

IT 지식/Kubernetes|2019. 9. 10. 22:16

docker를 사용하면서 그 편리함을 느끼고 있었다. 그리고 요 근래 it회사에서 docker와 kubernets를 이용하여 인프라를 운영을 하는 것을 많이 들었다.

나는 그런 환경을 접해보지는 못했기 때문에 정확하게 kuberntes가 무엇인지 잘 모른다. 그래서 이번 기회에 kubernets(이하 쿠버네티스)에 대한 기본 개념을 정리하고 설치해서 공부를 위한 초석을 닦아보자.

 

쿠버네티스 (kubernetes)

쿠버네티스는 도커 컨테이너 운영을 자동화 하기위한 오케스트레이션 도구이다. 구글에서 만들었으며 컨테이너를 운영하고 다루기 위한 api와 cli등을 제공한다. 컨테이너 배포 이외에도 효율적인 컨테이너 배치 및 스케일링, 로드밸런싱, 헬스 체크, secure등의 기능을 제공한다.

AWS ECS 와 GClound에서 도커 관리 기능을 제공하면서 컨테이너를 사용한 애플리케이션 개발이 점차 보급 되었다.  기존에도 docker에 스웜(swarm)이라는 기능이 있었으나 사용해 봤을 때 불편한 점이 많았는데 쿠버네티스가 더 편리하게 이 점이 보완되었다. 

 

쿠버네티스 설치 (MacOs)

실습을 진행할 컴퓨터가 mac os이기 때문에 mac에서 설치하는 방법을 알아보자. 우선 docker에서 preference에 들어가면 kubernetes 탭이 존재한다. 여기서 아래와 같이 체크하고 Apply를 누르면 설정이 우선 완료된다.

그리고 cli로 쿠버네티스를 다루기 위한 도구인 kubectl을 설치한다.

curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
chmod +x kubectl
mv kubectl /usr/local/bin

위에 명령어를 통해 kubectl을 명령어로 등록해주는데 자세한 방법은 홈페이지에 잘 나와있다.

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

설치가 완료된 후 버전을 확인해보면 출력되면 정상적으로 설치가 된 것 이다.

 

단일 노드 쿠버네티스 클러스터 Minikube 설치

쿠버네티스 클러스터에는 여러 노드들이 존재하지만 실습을 위해서 단일 노드로 되어 있는 Minikube를 설치해서 사용한다. 맥 기준으로 brew로 설치하면 되고 자세한 방법은 아래를 참조하면 된다.

brew cask install minikube

https://kubernetes.io/ko/docs/tasks/tools/install-minikube/

 

쿠버네티스 구성요소

쿠버네티스로 실행되는 애플리케이션은 노드, 네임스페이스, 파드, 레플리카세트, 디플로이먼트 등 다양한 리소스가 함께 연동해 동작한다. 

그 구성 요소들에 대해 간단하게 정리해보자.

1. 노드

-> 노드는 쿠버네티스 클러스터의 관리 대상으로 등록된 도커 호스트로 컨테이너가 배치되는 대상이다. 노드는 마스터와 일반 노드들로 구성되는데 쿠버네티스 클러스터 전체를 관리하는 서버에는 마스터가 적어도 하나 이상 있어야 한다. 마스터는 클러스터를 상호 조정하는 장치이고 노드는 애플리케이션이 실제로 돌아가는 곳이다. 노드에는 여러 파드들이 위치할 수 있고 그 파드에는 컨테이너들이 존재한다.

구글 이미지 출처

또한 쿠버네티스는 노드의 리소스 사용 현황 및 배치 전략을 근거로 컨테이너를 적절하게 배치한다. 클러스터에 배치된 노드 수, 노드의 사양 등에 따라서 노드에 배치할 수 있는 컨테이너의 수를 결정한다. 클러스터의 처리 능력은 노드에 의해서 결정된다.

kubectl get nodes

 

 현재 노드는 아까 설치한 단일 노드 Minikubes가 마스터로 위치해 있는 걸 볼 수 있다.

 

2. 네임스페이스

쿠버네티스 클러스터 내부에는 여러개의 가상 클러스터를 만들 수 있는데 이 네임스페이스는 하나의 공간으로써 사람또는 상황에 따라서 나눠서 사용할 수 있다. 기본적으로는 default로 되어있다.

 

3. 파드 (pod)

 pod는 컨테이너가 모인 집합체로써 하나 이상의 컨테이너로 이루어 진다. nginx, was처럼 서로간의 연결고리가 있는 컨테이너들은 하나로 묶어 일괄배포한다. pod는 노드내에 배치되고 같은 파드는 여러 노드에 배치할 수도 있고 한 노드에 여러개 배치할 수도 있다. pod는 하나 또는 그 이상의 애플리케이션 컨테이너 그룹을 나타내는 쿠버네티스의 추상적 개념으로 컨테이너에 대해 서로 자원을 공유한다.

  • 볼륨과 같은 공유 스토리지
  • 클러스터 IP 주소와 같은 네트워킹
  • 컨테이너 이미지 버전 또는 사용할 특정포트와 같은 각 컨테이너가 동작하는 방식에 대한 정보

 

apiVersion: v1
kind: Pod
metadata:
  name: sample-echo
spec:
  containers:
  - name: nginx
    image: ddd/nginx:latest
    env:
    - name: BACKEND_HOST
      value: localhost:8080
    ports:
    - containerPort: 80
  - name: echo
    image: dd/echo:latest
    ports:
    - containerPort: 8080
    
 # 파드 yaml 예제

 

4. 레플리카 세트

파드를 하나만 사용하여 가동할 경우에 실제 가용성이 떨어지기 때문에 레플리카 세트를 만들어서 여러 파드를 함께 구성해준 것이다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: echo
  labels:
    app: echo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: echo
  template: # template하단은 pad.yaml과 같음

 

5. 서비스 (servce, svc)

서비스를 이용해서 각 Pod에 있는 애플리케이션을 외부에서 접근하게 할 수있다.

쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 대한 접근할 수 있는 정책을 정의하는 추상적인 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 도와준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 yaml로써 정의 할 수있다. 각 서비스가 되는 대상을 labelSelector를 통해 지정할 수 있다.

각 파드들이 고유의 IP를 갖고 있기는 하지만, 그 IP들은 서비스의 도움없이 클러스터의 외부로 노출될 수 없다. 서비스들은 애플리케이션들에 트래픽이 실릴 수 있도록 허용해준다. 서비스들은 ServiceSpec에서 type을 지정함으로써 다양한 방식들로 노출시킬 수 있다.

clusterIp(기본값) - 클러스터 내에서 내부 IP에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.

NodePort - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다.
<NodeIP>:<NodePort>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. CluserIP의 상위 집합이다.

LoadBalancer - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.

ExternalName - 이름으로 CNAME 레코드를 반환함으로써 임의의 이름(스펙에서 externalName으로 명시)을 이용하여 서비스를 노출시켜준다. 프록시는 사용되지 않는다. 이 방식은 kube-dns 버전 1.7 이상에서 지원 가능하다.

 

6. 디플로이먼트 (deployment)

서비스, 파드, 레플리카세트의 집합체로써 애플리케이션의 기초가 되는 단위이다. 디플로이먼트 내부에는 서비스, 파드, 레플리카세트 등을 한번에 구성하여 적용 시킬 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo
  labels:
    app: echo
spec:
  replicas: 3
  selector:
    matchLabels
      app: echo
  template: # template는 pod와 동일

 

서비스와 디플로이먼트에 차이는 서비스는 내부에 여러 pod들을 외부와 연결해주는 역할을 담당하고 디플로이먼트는 쿠버네티스에서 돌아가는 pod들의 상태를 확인하면서 재시작 등등을 진행하는 담당을 한다.

다음 시간에는 실제 애플리케이션 하나를 이미지로 빌드하고 그것을 minikube에 디플로이먼트를 통해 파드로 배포를 진행해본다. 그리고 스케일적용과 이미지 변경 시 자동으로 새로 배포되는 블루그린 배포도 적용해보자.

 

참고 싸이트

https://kubernetes.io/ko/docs/tasks/administer-cluster/highly-available-master/
https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/
https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/
https://devopscube.com/kubernetes-deployment-tutorial/

댓글()

elasticsearch 7.0 docker 설치 후 변경사항 확인

엘라스틱서치 7.0이 출시했다.

엘라스틱서치 7.0에는 kibana UI변경과 multi mapping type 제거 등의 이슈가 있다.

우선 달라진점을 확인하기 위해 docker에 설치해보자.

설치

elasticsearch

docker run --name elastic7.0 -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:7.0.0

 

kibana

docker run -d --rm --link elastic7.0:elastic-url -e "ELASTICSEARCH_HOSTS=http://elastic-url:9200" -p 5601:5601 --name kibana7.0 docker.elastic.co/kibana/kibana:7.0.0

설치가 끝나고 프로세스를 확인해보면 elastic과 kibana가 올라가 있는 것을 확인할 수있다.

 

kibana UI 확인

키바나에 접속해 보니 엄청 깨끗하다. 몬가 되게 플랫해진 요새 디자인을 하고 있다. 5부터 6까지 변할때도 몬가 키바나가 멋있어졌다고 느꼈는데 이번에 7버전은 더 멋진 것 같다.

그리고 더 대단한 건 요새 대세인 다크모드가 지원된다.

다크모드는 setting > kibana > advanced settings > dark mode 위치에 가면 다음과 같은 설정 하는 부분이 있다.

설정 후 새로고침을 하면 적용되는데 화면이 멋있다.

 

그리고 멀티 맵핑 타입이 제거되고 등등 다른 변경사항이 있는데 아래 링크를 확인하면 된다.

근데 릴리즈하면서 마지막 글에 보면 기존에 elastic을 6버전 이상 사용하고 있으면 굳이 업데이트 할 필요는 없다고 한다 ㅋㅋ

 

변경사항

https://www.elastic.co/blog/elastic-stack-7-0-0-released

댓글()

Docker Container에 Elasticsearch와 데이터 시각화 kibana 설치 및 연동

회사에서 사용하는 Elasticsearch 공부를 위해서 docker에 설치해보고 시각화에 도움주는 Kibana도 같이 설치해보자.

우선 Elasticsearch에 대한 기본 정보는 API 문서에서 확인할 수 있다.
https://www.elastic.co/guide/kr/elasticsearch/reference/current/gs-index-query.html


Elasticsearch 설치

해당 이미지에는 xpack도 포함되어있다. xpack은 보안, 알림, 모니터링, 보고, 그래프 기능을 설치하기 편리한 단일 패키지로 번들 구성한 Elastic Stack 확장 프로그램이다.


우선 이미지를 내려받는다.

1
docker pull docker.elastic.co/elasticsearch/elasticsearch-platinum:6.0.0
cs

그리고 내려받은 이미지를 이용하여 Elasticsearch를 conatiner에 올려서 실행시킨다.

1
docker run --9200:9200 -9300:9300 -"discovery.type=single-node" -"transport.host=127.0.0.1" ---name elastic docker.elastic.co/elasticsearch/elasticsearch-platinum:6.0.0 && sleep 20
cs

그리고 xpack 설치를 진행하기 위해서 우선 해당 컨테이너 bash 쉘을 실행시킨다.

1
2
// bash shell 열기
docker exec -it elastic /bin/bash
cs

그리고 xpack을 설치한다.

1
bin/elasticsearch-plugin install x-pack
cs


마지막으로 Elasticsearch에서 자동 색인 생성을 비활성화 해준경우에 xpack에서 다음 색인을 생성할 수 있도록 elasticsearch.yml에 설정해준다.

1
action.auto_create_index: .security,.monitoring*,.watches,.triggered_watches,.watcher-history*
cs


그러고 http://localhost:9200에 들어가면 정상적으로 설치된것을 확인할 수 있다. (계정입력하는 화면이 나오면 elastic / changeme 정보를 이용해서 사용한다.

Kibana 설치

Docker 이미지 다운

1
docker pull docker.elastic.co/kibana/kibana:6.0.0
cs

container에 이미지 올리기

1
docker run -d --rm --link dazzling_mayer:elastic-url -e "ELASTICSEARCH_URL=http://elastic-url:9200" -p 5601:5601 --name kibana docker.elastic.co/kibana/kibana:6.0.0 && sleep 20
cs


Index 추가


처음 접속하면 elasticsearch에서 사용하는 index의 이름을 입력하라고 한다. 패턴을 입력하면 되는데 만약 날짜마다 인덱스가 생성되는 구조면 밑에 TimeFilter를 설정을 같이해주고 그게 아니라면 customer* 이런식으로만 지정해줘도 된다.


댓글()

Docker에 MongoDB 설치 후 Studio 3T로 접속해서 쿼리 사용해보기

데이터베이스/Nosql|2018. 10. 4. 00:26

Docker에 MongoDB를 설치하고 무료 접속 툴인 Studio 3T를 이용해서 접속해보고 쿼리를 사용해보자.

1. Docker에 MongoDB 설치

Docker에서 MongoDB 설치를 위해 필요한 내용을 docker-compose.yml 파일을 만든다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
version: '3'
 
services:
  mongodb:
    image: mongo:latest
    container_name: "mongodb"
    environment:
      - MONGO_DATA_DIR=/data/db
      - MONGO_LOG_DIR=/dev/null
    ports:
      - 27017:27017
    volumes:
      - /Users/wedul/Documents/docker/datafile/mongodb/:/data/db
 
cs

그리고 작성한 명령어를 통해 mongoDB가 담긴 컨테이너를 설치한다.

1
docker-compose up -d
cs

2. 클라이언트 툴 Studio 3T 설치

https://studio3t.com/ 에서 프로그램을 다운로드 한다.


3. 접속하여 쿼리 날려보기

host에 localhost port에 docker-compose.yml에 기재한 포트를 기입하고 접속하면 접속이 된다.
그리고 Query랑 Projection, Sort, Limit등등 사용해서 결과를 확인할 수 있다.



댓글()

Windows Subsystem for Linux (ubuntu)에 Docker 설치

IT 지식/Docker|2018. 7. 22. 14:06

맥에서는 docker 설치와 운용이 쉬웠는데, 맥북이 망가지고 윈도우 컴퓨터를 사용하고 있으니 Docker 사용이 생각보다 쉽지 않았다.

그래서 저번에 Windows Subsystem for linux (ubuntu)를 설치하고 여기에 docker를 올려보면 어떨까 싶어서 도전해 보았다. 

우선 docker engine는 WSL에서 실행되지 않아서 호스트 컴퓨터에 Windows용 Docker를 설치해야한다. 그리고 나서 Linux(ubuntu)에서 실행되는 Docker 클라이언트(WSL)가  Windows에 설치된 Docker Engine 데몬으로 명령어를 보내서 운용할 수 있다.

우선 Ubuntu에 Docker를 설치해보자.

1. 우선 패키지를 업데이트 한다.

1
sudo apt-get update
cs


2. 그리고 apt에서 https를 통해 저장소를 사용할 수 있도록 패키지들을 설치한다.

1
sudo apt-get install apt-transport-https ca-certificates curl software-properties-common
cs


3. Docker의 공식 GPG키를 추가한다.

1
2
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add 
$ sudo apt-key fingerprint 0EBFCD88
cs


4. Docker를 설치한다.

1
2
$ sudo apt-get update
$ sudo apt-get install docker-ce
cs

이렇게 하면 Linux에 설치가 완료되나 Docker Engine은 WSL에서 실행되지 않으므로 윈도우와 연결해야한다.

먼저 Docker 호스트가 있는 Docker 클라이언트에게 알려주어야 하므로 다음 명령어를 사용한다.

1
2
3
4
5
$ 도커 -H localhost : 2375 이미지
 
// 매번 하기 귀찮으면 환경변수에 등록
$ export DOCKER_HOST = localhost : 2375
$ echo "export DOCKER_HOST = localhost : 2375">> ~ / .bash_profile
cs


그리고 Windows에서 데몬을 공개해주어야 정상적으로 동작한다.


이미지를 다운받아보고 docker 명령어를 사용해보면 정상적으로 연결이 되는 것을 확인할 수 있다.



https://medium.com/@sebagomez/installing-the-docker-client-on-ubuntus-windows-subsystem-for-linux-612b392a44c4

댓글()

Mac OS에 Docker 설치하기

IT 지식/Docker|2018. 6. 30. 00:23

Mac OS에 Docker 설치는 매우 간단하다.

하단 링크로 들어가서 Docker.dmg파일을 다운받고 설치를 우선 진행한다. 

Docker 설치링크

 

DMG파일을 실행하면 다음과 같은 창이 출력되고 드래그 하여 Application으로 옮겨주면 된다.

 그 다음 도커를 실행하면 작업표시줄에 출력되고 클릭하면 자세한 상태와 기본 내용이 출력된다.

이제 시작해보자.  도커 시작!

 

 

댓글()

Docker 기본 개념 정리

IT 지식/Docker|2018. 6. 30. 00:13


 

 

마이크로서비스를 사용하고 배포를 자동화하고 하면서 유동적인 컨테이너인 Docker가 많은 인기를 얻고 여기저기 회사에서 많이 사용되고 있다. 실제로 백엔드 개발자에게는 거의 필수로 알고 가야하는 툴중에 하나가 되어버렸다.

 

Docker란 무엇인가?

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼 이라고 한다. 여기서 컨테이너는 다양한 프로그램, 실행환경을 컨터이너에  동일한 인터페이스로 제공하여 여러 프로그램의 배포와 관리를 단순하게 해준다.

 

컨테이너 (Container)

컨테이너는 OS 와 격리된 공간으로서 별도의 프로세스가 동작하는곳을 말한다. 그러면 기존에 OS에서 VM을 설치하여 사용하던 방식과 무엇이 다른지 알아보자.

 


VM과 Docker의 차이


기존의 VMware는 HostOS에 GuestOS가 올라가는 방식으로 추가로 OS 파일이 올라가야 하기 때문에 부담이 된다. 하지만 컨테이너에 경우 별도의 OS를 또 올릴 필요없이 프로세스를 격리하는 방식으로 이러어져있다. 그렇기 때문에 훨씬 가볍고 빠르며 CPU, 메모리 프로세스가 필요한 만큼 추가할 수 있다.

그리고 서로 다른 컨테이너는 서로 영향을 주지 않고 각각의 컨터이너에 접속하여 명령어도 별도로 사용할 수 있고 여러개의 프로세스를 백그라운드로 실행할 수도 있다.

컨터이너에는 보안적인 문제가 있다. 컨테이너는 host와 커널을 서로 공유하기 때문에 container가 뚫리게 되면 host 커널에도 영향이 갈 수있다. 또한 다른 컨터이너도 같이 공유하고 있기 때문에 문제가 될 수있다.

그렇다면 이런 컨터이너에 실행되는 파일과 설정값을 가지고 있는것이 무엇인가? 바로 이미지(Image)이다. 

 


이미지 (Image)


이미지는 컨터이너에 실행에 필요한 파일과 설정등이 다 들어있다. 컨테이너는 이미지를 실행한 상태라고 볼 수 있고, 추가되거나 변하는 값은 컨터이너에 저장된다. 같은 이미지에서 여러 컨테이너를 생성하더라도 수정, 삭제 하더라도 이미지의 값이 바뀌지는 않는다. 이미지는 Docker hub에 이미 등록되어 있고 추가적으로 등록할수도 있다. 개인의 Docker Registry 저장소를 직접 만들어 관리할 수 있다.

 

 


이미지 경로는 다음과 같이 되어있는데 모두 사용할 필요없이 간단하게 ubuntu:14.04와 같이 사용할 수 있다.

 



레이어 저장방식



도커 이미지는 실행하는 정보를 가지고 있기 때문에 용량이 크다. 그래서 이미지에 파일이 추가되었다고 파일 하나를 다시 받는다면 문제가 된다. 그래서 도커는 레이어라는 개념을 사용하였다. 기본적인 레이어는 동일하게 유지하며(읽기모드) 나머지 부분에 대해서만 쓰기 레이어를 만들어 사용한다. 그렇기 때문에 이미지 레이어는 그대로 사용되고 실행중에 생성하는 파일, 변경된 내용은 읽기/쓰기 레이어에 저장되므로 여러 컨터이너를 생성해도 최소한에 용량만 사용된다.

 


다음시간에는 Mac에 Docker를 설치해보자.


 출처 : https://subicura.com/2017/01/19/docker-guide-for-beginners-1.html

댓글()

스프링 마이크로서비스 (MSA) 소개

web/마이크로서비스|2018. 5. 27. 00:35

많은 회사에서 마이크로서비스를 주목하고 있고 도입하고있다.

그 이유가 무엇인지 궁금했고, 알아보기 위해서 마이크로 서비스관련 책을 하나 구입하였다.



생각보다 책이 두껍지만 외국 저서 같지 않게 설명이 자세하게 되어있다. (사례도 많다.)


그럼 이제 마이크로 서비스가 무엇인지 알아보자.

아래 사진을 보자.






우리회사도 그렇고 기존에 웹 애플리케이션은 왼쪽의 사진처럼 하나의 구조로 이루어져있어 war 형태로 배포된다.

모든 서비스가 하나의 애플리케이션으로 구성되어있을 경우에는 새로운 기능을 추가하거나, 성능을 위해 시스템을 나누기 위하는 작업 등등이 너무 어렵다.

그래서 요새 대형 서비스에서는 서비스를 새로 추가하기도 쉽고, 더 많이 사용하는 서비스에 물리적인 자원을 더 할당할 수 있도록 마이크로서비스를 지원한다.

마이크로서비스에 대해 본격적으로 공부에 들어가기 전에 정리부터 해봤다.

[마이크로 서비스 특징]
- 서비스를 잘게 쪼개서 만드는 서비스
- 하나의 아키텍쳐에 서비스를 올리는 방식을 지나 서비스별로 모듈을 나누는 마이크로 서비스가 유행이다.
- 빠르게 개발하고 서비스 하기 위해서 스프링 부트를 많이 사용한다.
- 각 서비스가 Rest API 뒤에 숨어있기 때문에 어떤 개발언어, db등을 사용해도 무관하게 서비스가 가능하다.
- 마이크로서비스는 일체형 애플리케이션을 여러 개의 작은 서비스로 분리하기 때문에 빌드, 테스트, 배포, 확장 까지 모두 자동화해서 진행한다.
-> git, travis, jenkins등의 형상관리 툴을 사용하여 자동화한다.

- 가장 큰 장점은 서비스를 분리할 수 있다.
-> 로그를 기록하는 서비스의 경우 하둡 파일 시스템을 사용하고 실제 동작을 진행하는 서비스는 관계형 데이터베이스를 사용한다고 하였을 때, 두 서비스를 분리함으로써 다른 방법으로 개발을 진행할 수 있어서 효율적이다.

- 결국 위와 같은 이유 때문에 캡슐화가 굉장히 잘 되어있게된다.
- 모듈 자체 구현내용은 은닉되어있고, 앞에 정보 요청에 대한 API만을 공개하게 되며 새로운 기능을 넣고 빼는데 거리낌이 없는 서비스가 될 수 있어서 좋다.
- 또한 기술이 오래된 경우 변경하도록 할 떄, 교체하는 비용과 주기가 줄어든다. (모듈별로 바꿀 수 있다. 점진적 진행 가능)
- 각 모듈별로 버전을 달리할 수 있다. (우리회사만 해도 모두 하나의 apache-tomcat에 올라가기 때문에 자바 버전이나 이런 것에 굉장히 예민하다. 그래서 아직 자바 1.8를 사용하지 못했다. 하지만 이렇게 서로 다른 모듈로서 관리할 수 있으면 버전에 상관없이 서비스를 진행할 수 있다.)

[결론]
물론 단일 애플리케이션의 단점만 존재하는 것은 아니다. 그렇게 많은 서비스를 지원하지 않고 단조로운 서비스에 경우에는 오히려 단일 애플리케이션 구조가 더욱 유지보수가 효울적이다. 하지만 시대가 변하고 많은 서비스를 빠르게 지원하고 관리해야하는 상황에서 마이크로서비스는 많은 잠점을 가지고 있는 것 같다. 넷플릭스, 구글 등등 외국에서 뿐만아니라 한국에서도 배달의민족, 카카오 등등 많은 곳에서 사용하고 있다. 재밌는 공부가 될 것 같다.


댓글()