퍼시스턴트

앞서 모두 완성했던 버전이, release2로 변경되었다. 

(내용은, 차량의 위치와 경로 파악) 

 

해당 방법은, 간단하게 img의 release를 2로 변경하면 된다. 

 

차랑의 위치와 경로 정보는, msa구조의 pod 내부의 application 메모리 내부에 저장된다.

 

*이 방식은 문제가 발생한다. 모든 정보를 application 내부 메모리에 저장하기 때문에 

메모리 부족이 반드시 발생한다.

 

*Node가 충돌할 수 있음에 주의하자.

 

차량의 이동기록을 저장하고, 이동 경로를 계산하는 역할을 가진 '위치 추적 ' ms가

2개의 역할을 하기 때문에 문제가 발생한다. 

기록을 저장하는 micro service를 별도로 생성해야 한다. 

 

<DB(MONGODB)를 활용하자>

 

현재까지의 목표로 , 위치추적 MS가 확인할 수 있는 DB를 확인해야한다.

(오직, 위치추적 MS에서만 사용하는 DB이다) (통합이 아님이 포인트이다)

MONGO DB를 사용한 이유는, 최대한 간단한 형태만 필요하기 때문이다. 

 

docker에서 제공하는 mongodb의 img를 받아 container를 형성하자 

 

 

 

현재까지는, pod가 존재하지만, service를 가지지 않기 때문에 dns 시스템에서 확인되지 않는다.

(그말은 ,곧 연결되지 않았다는 의미이다) 

(이전 마이크로서비스 중 service가 없는 서비스도 존재했지만, 해당 마이크로서비스는 

service로 관리되는 queue에 data를 전송하는 역할만 진행하기 때문에 문제가 없었다)

(허나 mongodb로는, 연결이 되어야 한다.)

 

<DNS와 연결>

MICROSERVICE는 도메인 이름을 DB의 HOST 이름으로 사용한다. 

 

EX) spring.data.mongodb.host=fleetman-mongodb.default.svc.cluster.local

이와 같이,(fleetman-mongodb)는 Service의 name이 된다.

 

mongo-db의 pod의 연결을 기다리는 port number를 확인했다. 

 

그렇다면, 해당 port를 내부적 port로 연결해줘야한다. 

 

CLUSTER내부에서만 적용하면 되기 때문에, CLUSTERIP로 설정하면 된다. 

 

 

service까지 설정 완료

 

 

그러나.. 성능 저하가 발생했다. 

 

<성능 해결>

minikube는 로컬 개발용이고, 제작 시스템 용이 아니다. 

또한 ram 부족 등의 문제가 존재할 수 있다. 

 

이럴떄는 minikube의 할당 gigabyte를 키우자. -> minikube를 실행할 떄 

minikube start —memory 4096 로 해결할 수도 있다. 

 

별도의 MONGO DB에 저장되기 때문에, (위치추적의 APPLICATION에서 이 DB를 참조한다)

POD가 재시작하여도 해당 정보를 다시 받아올 수 있다. 

 

다만, 필연적으로 만약 MONGO DB POD가 DELETE된다면 현재까지의 기록을 잃는 문제가 발생한다.

어떻게 이를 해결할 수 있을까? 

 

<Persistent Volume>

 굉장히 복잡한 개념이며, 대략적으론 컨테이너 외부의 로컬 폴더에 data를 저장하는 것을 의미한다.

 cloud platform으로 동작할때는, 더 복잡한 형태가 필요할 것이다. 현재는 클라우드의 드라이브 EBS를 사용하도록 하겠다.

 

Mongodb는, 기본적으로 컨테이너 내부의 /data/db에 data를 저장한다. 

이것을 컨테이너 외부에 저장하게 변경해보자. (이것은 yaml안에서 조정하지 않는다)

(그 이유는, 외부 파일을 변경할때마다 모둔 설정을 변경하는 것이 되기 때문이다.)

 

(hostpath tag는, vm위의 폴더에 지정해야함을 기억하자)

 

 

즉 volumes로 저장할 db를 이동할 수 있음을 기억하자. 

그 위치를 local인 hostpath, persitentVolumeClaim(분리된 설정) or aws등등 설정할 수 있다. 

 

 

persistenetvolume claim용으로 변경하였다. 이제 이후에 pv와 pvc를 통해 저장 위치를 정의할 것. 

stoarge.yaml을 통해 저장소의 설정을 진행할 수도 있다. 

 

Volume 설정, 2gi를 할당하고, readwriteonce로 할당해달라(accessmode)

해당 경로와 type은 밑에 작성하였다. 

 

 

storageClassName은, 다른 저장소의 클래스를 설정하도록 한다. 

kubectl get pv를 통해 

storage의 형태를 알 수 있다. 

 

(주의! 용량(capacity가 pvc에서 요청한 만큼 pv에서 존재해야한다. 

pvc는 저장소에 대한 설명, pv는 실제 저장소(local일수도, cloud상일 수도있다)