병원 관계자와 비 관계자 간의 소통 및 정보 공유를 위한 커뮤니티 구축을 목표로 삼아 쿠버네티스와 MSA 아키텍쳐를 사용하여 안정적이고 확장성있는 서비스를 구현한다.
지인이 근무하는 병원의 원장님께서 그 지역에서 유명한 의사이지만, 실제로는 돈을 벌기 위해 효과 없는 치료도 감행하고 있다고 들었다. 따라서 관계자만이 알 수 있는 정보를 소비자와 나누는 투명성 있는 의료 커뮤니티가 필요하다고 생각했다.
- 병원이나 의료 정보를 알고 싶은 비 관계자
- 의료 커뮤니티가 필요하거나 병원의 정보를 알려주고/알고 싶은 관계자
사용자를 관계자와 비 관계자로 나눈다. 관계자는 회원가입 절차를 통해 본 서비스를 이용할 수 있고 비 관계자는 정보 조회에 한해서, 회원가입 없이도 서비스를 이용할 수 있다. 본 서비스는 자유게시판, 병원 정보 및 리뷰 기능을 담고 있다.
- 자유게시판은 관계자와 비 관계자 모두 게시글을 조회할 수 있으며 회원가입을 한 사용자에 한해 질의응답 또는 커뮤니티 등이 가능하다.
- 병원 정보 및 리뷰는 병원에 대한 정보를 제공하며 관계자들이 이용할 수 있는 공간이다.
관계자는 병원과 관련된 리뷰 조회/쓰기가 가능하며 비 관계자는 리뷰 조회만 가능하다.
관계자와 비 관계자들은 정보를 공유하고 소통하며 더 나은 의료 서비스를 제공하는 데 도움이 될 것이다. 또한, 모두가 익명을 사용해 자유롭고 투명한 제보가 가능해 비관계자가 더 나은 병원을 선택할 수 있는 기회를 제공한다.
회원가입 절차에 대해 까다롭게 진행하기가 어려웠다. 보유한 병원의 정보가 한계가 있고 그 병원에 직접 근무하는 관계자인지, 병원에 확인하기 어렵다는 제약 사항이 있다.
관계자와 달리, 관계자는 글 또는 병원 리뷰를 작성할 수 없고 조회만 가능하다. 따라서 작성하기 버튼이 보이지 않는다.
- 로그인, 게시판, 병원 평가, 웹 프론트 서버로 나누어 서비스를 개발한다.
- 깃허브로 의사소통하며 개발을 하며, Github Webhook과 Jenkins를 이용해 CI/CD를 구축한다. - 쿠버네티스 서버는 마스터노드 서버 1개와 워커노드 서버 2개로 구성한다.
- 마이크로 서비스 아키텍처 설계를 통해 단일 장애 지점 문제를 최소화시켜 서버 안정성을 향상시키면서, 각 서버의 필요 리소스에 맞게 스케일링 한다.
- 각 서버별로 다른 종류의 DB를 사용하여 데이터 가용성을 지킬 수 있다.
- 각 DB별로 독립적인 PV(PersistentVolume), PVC(PersistentVolumeClaim)을 생성해 Pod가 종료되어도 데이터를 영구적으로 저장할 수 있다.
- 쿠버네티스의 Self-healing을 이용해 비정상적인 컨테이너를 자체적으로 교체하여 안정적인 서비스를 유지하도록 한다.
- 쿠버네티스의 Rolling Update 기능을 이용해 새로운 버전으로 배포 시 서비스가 중단되지 않는 무중단 배포를 구현한다.
- 쿠버네티스의 Auto-Scaling 기능을 이용해 HPA(HorizontalPodAutosacler)로 CPU 사용량에 따라 레플리카 셋 개수를 조절한다.
- Jmeter와 chrome의 lighthouse를 이용해 반응 속도와 서비스 성능을 측정 한다.
|
|
프로젝트의 구조는 React 애플리케이션인 cc-front-server와 Spring Boot 애플리케이션인 cc-auth-server, cc-board-server, cc-company-server로 이루어져있고, mysql, maria, postgreSQL 데이터베이스를 사용하고 있다. |
쿠버네티스의 Auto-healing 기능을 설정하여 사용하기 위해 먼저 각각의 파드에 livenessProbe 설정을 추가해주었다.
livenessProbe 설정은 컨테이너의 상태를 주기적으로 체크해 주는 기능을 한다. 우리의 서비스는 웹 서비스이기 때문에 httpGet에 설정되어있는 경로로 주기적으로 요청을 보내 컨테이너가 동작 가능한 상태 인지를 파악한다.
파드가 생성되고 정상인 기능이 동작하는데에 약간의 시간이 소요되므로, initialDelaySeconds를 통해 파드가 시작되고 생성되고 나서 몇초를 기다릴지 설정을 해주었고, healthCheck 를 너무 자주하는 것을 방지하기 위해 15번씩 요청을 보내도록 설정했다. 또한, QoE를 만족시키기 위해 timeoutSeconds를 설정해 1초안에 200 응답이 오지 않을 경우 실패로 간주했다.
마지막으로, 단 한번의 실패로 파드가 내려갔다 올라가는 것을 방지하기 위해 failureThreshold를 3으로 설정해 3번 연속으로 실패가 발생하면, 파드를 재시동해주도록 설정했다.
오토 스케일링 기능을 추가하기 위해 Deployment에 HPA라고 불리는 HorizontalPodAutoscaler를 추가하였다. minReplicas를 3으로 설정해 평소에는 파드 개수를 3개로 설정해두고, maxReplicas를 10으로 설정해 설정한 기준보다 높은 트래픽이 몰리는 경우 10개까지 파드의 개수가 늘어나도록 설정했다.
파드가 늘어나는 기준은 CPU의 사용량이 50% 이상일 경우 스케일 아웃이 되도록 설정했다.
위 사진은 Apache Jmeter를 통해 초당 300개의 요청을 보냈을때의 상황에서 레플리카 개수의 변화를 살펴보았다. 부하가 걸리면서 CPU의 사용률이 증가하여 50%를 넘자 부하를 분산시키기 위해 레플리카가 기존 3개에서 6개까지 늘어난 모습을 확인할 수 있다.
이 프로젝트는 총 3개의 서버로 구성되어 있고, 마스터 노드 1개와 워커 노드 2개로 구성되어 있다. 쿠버네티스에서 파드는 일회성 자원이다. 즉, 파드가 올라갔다 내려가는 동시에 파드의 모든 내용은 초기화된다. 이러한 특성은 데이터베이스를 파드로 띄울 때 파드가 재생성될 때 기존의 데이터가 초기화되는 현상을 초래할 수 있다. 이를 해결하기 위해 볼륨 마운트라는 기술을 통해 데이터 초기화를 방지할 수 있다. 하지만, 일반적인 쿠버네티스의 볼륨 마운트는 파드가 실행되는 워커노드와 연결되기 때문에 위와 같이 워커노드가 2개 이상 존재하는 상황에서 파드가 기존에 연결되어있던 워커노드 서버와 다른 서버에서 다시 파드가 생성될 경우 다시 새로운 워커노드에서 볼륨이 마운트되는 현상이 발생한다. 이를 해결하기 위해 퍼시스턴트 볼륨을 사용하였다.
퍼시스턴트 볼륨의 데이터는 마스터노드에 생성되어 관리되기 때문에, 파드가 어느 서버에 생성되던지 간에 볼륨 마운트를 할 수 있다. 각각의 데이터베이스마다 퍼시스턴트 볼륨을 생성해 퍼시스턴트 볼륨 클레임과 연결해주고, 연결한 클레임을 볼륨 마운트를 통해 파드와 연결해주었다.
데이터베이스 파드 설정에서는 환경변수를 통해 데이터베이스 컨테이너가 생성될 때 초기 생성할 스키마와 계정 정보, 사용 포트 등을 정의했다. 마지막으로, Cluster IP 서비스 타입을 사용해 해당 데이터베이스를 쿠버네티스 내부에서 사용할 수 있도록 설정했다.
이를 통해 데이터베이스 서버가 중단되거나 재생성 되는 경우에도 데이터를 유지할 수 있었다.
쿠버네티스에서 부하 분산을 위한 로드밸런싱 기능을 사용하기 위해 Service와 Deployment를 이용하였다. 먼저 Deployment에 파드를 정의하고 Replicas 개수를 설정해 원하는 숫자의 ReplicaSet을 생성한다. 그 후 Deployment와 Service를 연결시켜 외부로부터 Service에 접근할 때 쿠버네티스에 설정된 알고리즘에 따라 부하가 균등하게 각각의 Replica로 분산시켰다.
목표치는 아래와 같다.
| 평가 항목 | 정량적 목표 | 평가 방법 |
| 초당 접속자 수 | 총 300명이 자유게시판, 병원 정보 및 리뷰에 동시 접속할 수 있다. | 프로메테우스를 이용해서 실시간 CPU 로드율 및 메모리 사용량, HTTP 요청 수, HTTP 응답 시간을 확인한다. |
| First Contentful Paint | 총 300명이 자유게시판, 병원 정보 및 리뷰에 동시 접속하더라도 응답 시간은 FCP 기준 800ms 이내를 보장한다. | Lighthouse를 사용해서 FCP를 측정한다. |
| Time To Interactive | 총 300명이 자유게시판, 병원 정보 및 리뷰에 동시 접속하더라도 응답 시간은 TTI 기준 1000ms 이내를 보장한다. | Lighthouse를 사용해서 TTI를 측정한다. |
| Max Potential First Input Delay | 총 300명이 자유게시판, 병원 정보 및 리뷰에 동시 접속하더라도 응답 시간은 FID는 기준 800ms 이내를 보장한다. | Lighthouse를 사용해서 FID를 측정한다. |
| Max Potential First Input Delay | 총 300명이 자유게시판, 병원 정보 및 리뷰에 동시 접속하더라도 응답 시간은 TBT는 기준 800ms 이내를 보장한다. | Lighthouse를 사용해서 TBT를 측정한다. |
실제 결과는 아래와 같다.
정량적 평가 기준을 정할때 5분동안 300명의 사용자가 동시에 접속하는 상황을 가정했다. 따라서 Jmeter를 사용해서 동일한 부하 상황을 갖추고 1초에 한번씩 웹사이트에 요청을 보내는 상황을 구성한다. 테스트 조건에 맞는 부하가 걸린 상황에서 전체적인 성능은 98점으로 실제 서비스에서 사용자가 만족스럽게 사용할 수 있을것으로 예상된다.
실제 수치 결과를 보면 위와 같다.
| 목표 | 결과 |
| 총 300명이 자유게시판, 병원 정보 및 리뷰에 동시 접속하더라도 응답 시간은 FCP 기준 800ms 이내를 보장한다. | 목표 조건에서 실제 측정된 FCP는 500ms로 FCP 목표를 달성한것을 확인할 수 있다. |
| 총 300명이 자유게시판, 병원 정보 및 리뷰에 동시 접속하더라도 응답 시간은 FID,TBT 기준 800ms 이내를 보장한다. | FID와 TBT는 같은 계산지표를 공유한다. 목표 조건에서 실제 측정된 TBT는 0ms로 FID와 TBT 목표를 달성한것을 확인할 수 있다. |
| 총 300명이 자유게시판, 병원 정보 및 리뷰에 동시 접속하더라도 응답 시간은 TTI 기준 1000ms 이내를 보장한다. | 아래 그래프를 보면 대부분의 요청에 대해서 1000ms 안에 요청에 응답하고 있으나 과부하가 걸림에 따라 일부 요청은 목표 응답시간을 초과하는 것을 볼 수 있다. 이는 운영중인 서버의 성능이 부족이 원인으로 생각된다. 그러나 목표 조건에서 요청에 대해서 평균적으로 1000ms 안에 응답한다고 볼 수 있다. |