Ubie Discovery 사내 서비스 검증 환경 dev-n

안녕하세요. Ubie Discovery에 입사한 지 5개월 됐습니다.스케줄러:참빠르구나.의료업계는 아무것도 모르는 상태지만 최근에는 역지식과 조직 주변을 조금씩 들여다보며 아랑곳하지 않고 일하고 있다.제품 개발 외에도 이전 사업에서 배양한 GCP와 쿠베르네츠의 노하우, 개발 환경의 인프라 주변 정비 등을 활용했다.
의사도 제가 있는 쓰레기팀에 참가했지만 공사 쪽에서 익숙하지 않은 부분도 있었고, 인프라 쪽 때문에 개발과 검증에 어려움을 겪는 장면도 있었다.적극적인 협조 아래 우리는'마이크로 서비스를 간단하게 테스트할 수 있는 개발 환경이 없다'는 것이 매우 큰 문제라는 것을 발견했다.Ubie Discovery는 이전부터 dev-n 환경이라는 것이 있었는데 그것을 재구성해 그 문제를 해결했으니 소개해 드리겠습니다.
또한 이 콘텐츠는 Ubie의 팟캐스트devchat.fm • A podcast on Anchor에도 발표되니 함께 기대해 주세요.
https://anchor.fm/devchat-fm/episodes/44-dev-n-with-shikajiro-e1dfc08
※ 이 글은 Kubernetes에 구축된 서비스 그룹을 가리키는 간단하고 알기 쉬운 마이크로 서비스로 표현되었습니다.

이른바 dev-n

Ubie 회사 내부에서 일컫는dev-n은'클라우드에서 n개의 마이크로 서비스의 개발 환경'을 가리킨다.더 나아가 말하자면 클라우드 위의 Kubbernetes에 펑펑 서비스를 구축하고 싶다는 것이다.당사는 클라우드 컴퓨팅에서 GCP를 도입하여 개발,qa,staging,production,4개의 GCP 프로젝트를 제작하여 개발,검증,정식으로 제공하여 GKE 클러스터에 각종 서비스를 제공합니다.dev-n은 이 개발자 환경의 GKE 클러스터 내에서 자유롭게 서비스를 구축해 개발자의 개발 효율을 높이는 구조다.
이전부터 GKE에 별도의 서비스를 구축하는 구조가 일치했지만, Ubie가 개발한 많은 마이크로 서비스의 일부를 함께 구축했다는 것이다.

개발의 문제점

dev-n이 완성되기 전에 다음과 같은 문제가 있습니다.

의사의 개발 환경 준비는 매우 고생스럽다

Ubie는 모두가 좋아하는 마이크로 서비스로 개발되었다.엔지니어는 주로 local에 코드를 톡톡 적어 조작 검증을 하고 개발했으며, 의사들은'마스터데이터'로 불리는 Ubie의 핵심 부분을 개발 중이어서 통합 마이크로서비스 확인이 필요하다.
이전에는 의사도 로컬에 도커컴포즈 등을 적용해 개발 환경을 구축했지만, 어떻게든 구축하기는 어려웠고, 고장 제거 시 엔지니어가 의사의 로컬환경에 노출되지 않아 해결할 수 없는 점 등이 의사 개발의 고민이었다.

마이크로 서비스와 결합된 개발과 검증 환경이 부족하다

개발자는local로 마이크로 서비스를 구축하여 일을 하게 한다고 썼지만, 각양각색의 서비스를 시작하면 기계가 점점 무거워지고 개발 효율이 떨어진다.또한local 환경에서 팀원들이 개발 도중의 물건을 보거나 만져서는 안 된다.엔지니어도 마이크로 서비스가 모두 운영되는 환경을 원한다고 느낀다.개발자 환경이 하나밖에 없기 때문에 줄을 서서 기다려야 하기 때문에 쉽게 사용할 수 없습니다.

PR 단계와 결합된 마이크로서비스의 검증 환경이 없음

여러 서비스를 동시에 개발할 때 PR 시 코드를 설계하고 검증하려는 경우도 있다.개발자 환경은 개발자 지점이 시작될 때 설계되기 때문에 사용할 수 없습니다.

대량의 개발 환경을 만드는 데 비용이 든다

GCP의 개발자 프로젝트를 많이 하면 해결됩니다.하지만 GKE 클러스터일 뿐이라면 괜찮은데, GCP 프로젝트에 리디스 등 그만큼 비용이 많이 드는 서비스를 활용했기 때문에 GCP 환경을 많이 만들면 비용도 별로가 된다.

dev-n의 구조

위와 같은 문제를 해결한dev-n의 구조는 "개발자 환경에서 활동하는 GKE 클러스터를 namespace로 구분하고, 개발·검증에 필요한 Image와 함께 설계된 k8s 파일군 및 자동화"였다.dev-n 창고를 제작하여 관리합니다.

(위의 이미지와 동일)

환경 자원을 공유하는 GKE 클러스터

위에서 말한 바와 같이 개발자 환경과 동등한 환경을 만들려면 비용이 든다.그래서 개발자 환경의 자원을 빌리기로 했습니다.리디스와 DB 실례 등을 공유합니다.GKE 클러스터dev-shikajiro에서처럼 난잡한 영역을 namespace로 구분하고 그곳에서 검증하고자 하는 Image를 설계한다.
이렇게 하면 최소한의 비용(GCE 실례비)으로 클라우드에서 개발 환경을 준비할 수 있다.

kustomize에서dev-n 환경에 따라 사용자 정의

k8s의 Deployment, 서비스, ConfigMap은 kustomize가 관리합니다.각namespace는 환경 변수와 이미지 tag 등을 관리하는 디렉터리를 만듭니다.

어느 정도 구축은 자동화된 것이다

상기 모든namespace의 디렉터리와kustoomize입니다.shellSctipt를 사용하여 yaml 처리 작업을 수행할 수 있습니다.kustomize.ImageTag 등을 그대로 두면 노화가 되는데, 이는 GCP의 API를 두드려 최신 ShellSctipt를 제작한 것이기 때문에 간단하게 업데이트할 수 있다.

PR에 댓글을 달아주시면 디자인이 가능합니다.

모든 서비스의 창고에 설명이 있으면 dev-n의 사전 처리를 할 수 있는GiithubAction입니다.

/deploy shikajiro

와 PR의 리뷰와 PR시의 Docker Build, GCR의 Push, dev-n 창고의 코드 변경과 PR을 병합하여 최종적으로 dev-shikajiro의 ImageTag 반영을 진행한다.

Argo CD를 통한 자동 구축

Argo CD는 dev-n 창고 코드를 GKE에 반영하는 역할을 감시하고 실행합니다.개발자들은 집단에 대한 디자인을 의식하지 못하고 Giithub의 코드에만 집중할 수밖에 없었다.여기 SRE 거 너무 예뻐요!

향후의 전망

telepresence를 사용하여 직접 개발

dev-n은 시종 검증 환경이므로 개발 환경으로 사용할 수 없습니다.그러나telepresence를 사용하면 클라우드에 있는 k8s급 사용자 deploy의 마이크로 서비스를 직접 개발할 수 있습니다.
메르칼리 씨는 이 메커니즘을 일찌감치 도입했기 때문에 참고 가치가 있으니 꼭 보십시오.마이크로 서비스의Telepresence 로컬 개발 환경이라면

압도적인 자동화!발행 단위별로 자동 구축, 발표 후 자동 삭제

DB의 초기화와 환경 신설 등을 엔지니어가 수동으로 관리하기도 한다.나는 천천히 지령으로 한꺼번에 모두 구축되고 갱신 작업도 자동화되어 엔지니어가 개입하지 않아도 운용할 수 있다고 생각한다.

총결산

간단하게 환경을 만들 수 있는 구조가 압도적인 개발 속도를 내고 있다

dev-n의 구조가 정말 잘 만들어졌어요.의사들의 개발 체험이 개선되어 모두들 기뻐했다.지금까지 엔지니어들은 의사가 만든 데이터에 따라 local로 조작 검증을 할 시간이 있었지만, 지금은 의사로만 완성됐다.
의외로 엔지니어들도 "흥미로운 기능이 추가됐으니 만져보고 의견을 들어보자"는 호평을 쏟아내며 홍보 단계에서 쉽게 해낼 수 있었다.해보자'는 아주 쉬워졌다.
아직 자동화가 완전하지 않거나 개발 환경으로 사용하기에는 부족한 부분이 있지만 앞으로도 계속 개선해 나가겠다.

한 사람이 해도 모양이 있으니, 모두 함께 모여 한층 더 개선하자

처음엔 혼자 여가 시간에 (그런 거 없이) 꾸준하게 하고 있었지만, 어느 정도 하고 싶은 일과 행동을 보여줄 수 있다면 "그래! 자동화에 맡기자!""아, 나도 추가 서비스를 하고 싶어서 협조하겠다"고 많은 사람이 모여 개선이 단숨에 이뤄졌다.여러 가지 이상형을 고려하며'있었으면 좋겠다'고 말하는 것보다 다른 사람이 만질 수 있도록 만드는 것이 중요하다.

어서 오너라

https://meety.net/matches/TdhKMdEUFyQx