안녕하세요. Seller & SD Engineering 팀 박명훈입니다. 지난번의 전략편에 이어 이번에는 실제 서비스 전략에 대해서 이야기하려고 합니다. 실제 서비스를 배포하며 사용했던 전략, 그리고 그 과정에 대해서 이번 글에 서술합니다. 달리는 인증 서비스의 NoSQL을 바꾸자. - 전략편달리는 인증 서비스의 NoSQL을 바꾸자. - 실전편 배포 전략과 설계지난 전략편에서 이야기했듯이 서비스에 이슈가 없이 배포하기 위해서 여러 스텝으로 작업을 분리했습니다. 이를 도식화시키면 다음과 같습니다.배포 전략 및 순서1차 배포1차적으로는 도식에서의 1 ~ 3번까지의 작업입니다.배포 서버판매자 페이지관리자 페이지배포 사항Couchbase의 데이터를 MongoDB, MSSQL로 마이그레이션 합니다.기존에 Couchbase 에서만 저장하는 로직에서 Couchbase, MongoDB, MSSQL 모두룰 저장하는 로직으로 변경되게 됩니다. (기존) Couchbase에 단건으로 저장하고 수정하였습니다.(신규) Couchbase, MongoDB, MSSQL 에 동시에 쓰도록 합니다.기존에 Couchbase 에서 조회하는 구조에서 MongoDB, MSSQL를 조회하는 구조로 바뀌게 됩니다. (기존) Couchbase에서 단건, 복수건, 복잡한 조건 검색 등을 진행합니다.(신규) 무거운 작업인 경우, mssql에서 쿼리를 통한 조회를 하고, 간단한 단건 조회의 경우 mongodb를 조회합니다.배포 영향API 호출하는 사용자 입장에서는 전혀 영향이 없습니다. (즉, 인증 Gateway는 이슈가 없습니다.)일부 데이터의 싱크가 안 맞는 경우가 발생할 수 있습니다.이를 위해 주기적으로 마이그레이션 배치를 돌려줍니다.배포 이후관리자 페이지에서 사용자 조회 시, 빠른 속도로 사용자가 조회될 것으로 예상됩니다. 2차 배포2차 배포는 도식에서의 4 ~ 5번까지의 작업입니다. (6번은 그 후의 작업으로 보면 편합니다.)배포 서버Gateway 서비스배포 사항Couchbase 에서 보던 사용자 데이터를 MongoDB 로 조회하게 됩니다.배포 영향Gateway 서비스 장애 포인트가 발생할 수 있습니다.그러나 이런 이슈가 없도록 개발에서 테스트 이후, 이슈 없이 진행합니다.배포 이후.Gateway에서 Couchbase 를 조회하지 않고 MongoDB 로 전환하여 서비스의 안정성이 늘어납니다. 계획과 현실은 다릅니다. 그러나앞에서 이러한 계획을 세우고 진행을 해도, 여러 가지 문제가 발생하게 됩니다. 그러나 최대한 그런 계획과 틀어지지 않게 하는 것이 좋은 설계의 역할이라고 생각합니다. 작업의 다른 키워드는 작업을 진행하면서도 가성비(적은 리소스와 높은 성과) 있게 진행하는 것입니다. 그러한 가성비 전략은 다음과 같습니다. 전략 1. migration을 위한 배치 대신, 공통된 api를 사용합니다.배치 서비스를 만들면 서비스 적으로 안정감이 더 있을 수 있겠지만 단순히 초반에 데이터를 맞춰줄 때만 사용할 예정이기에 가성비가 안 좋은 상황이었습니다. 그래서 코드 퀄리티나, 제대로 된

안녕하세요. Seller & SD Engineering 팀 박명훈입니다. 최근 개발자로서 직접 기안한 프로젝트를 완료했습니다. 팀에서는 Couchbase를 통해 인증 서비스의 데이터를 제공하고 있었는데, 낮은 사용성 이슈와 비즈니스 정책, 서비스 관리의 여러 이유로 인해 불편함이 많았고, 이로 인해 기획자들이 업무를 진행할 때 성능 이슈로 인해 거의 사용이 불가능할 정도로 문제가 많았습니다. 대표적인 예시로 검색을 하면 5분씩 걸렸습니다. Couchbase는 MongoDB와 같이 Key-Document 구조를 가진 NoSQL 입니다. 이번 기회에 개선을 진행하며 기존의 문제를 해결하고, 성능적으로나 서비스적으로 아쉬웠던 부분을 개선했습니다. 그 과정과 결과에 대해서는 내용이 많아 크게 전략편과 실전 편으로 나눠서 서술할려고 합니다. 달리는 인증 서비스의 NoSQL을 바꾸자. - 전략편달리는 인증 서비스의 NoSQL을 바꾸자. - 실전편 간략하게 서비스를 소개하면 저희 팀에서는 Couchbase를 통해, 외부에 제공하는 사내 API의 Gateway 인증 서비스를 관리하고 개발하고 있습니다. 이 서비스를 통해 인증된 외부에서 개발자들의 지마켓이나 옥션 등의 상품, 주문, 배송, 클레임, 정산 등의 API를 사용할 수 있게 됩니다. 즉, API 사용자가 인가된 사용자인지를 확인해 주는 인증 서버입니다. 인증 서비스의 간략한 구조 기존 서비스의 문제.기존의 서비스에서는 여러 문제가 있었습니다. 특히 가장 큰 문제는 사용자 입장에서가 아닌 관리자 측면에서는 설계가 부족했던 부분이었습니다. 과거에서는 문제가 안되었을 수 있으나, 데이터가 많아지면서 점점 더 드러난 문제입니다. 문제 1. 관리자 입장에서 최악의 구조관리자 입장에서 특정 기준의 데이터를 조회해야 할 때 모든 document를 뒤져봐야 하는 단점이 있었습니다. couchbase에서도 indexing 을 지원하나, 저희 구조에서는 임시방편이라고 느끼기도 했고, 뒤에 나올 여러 가지 이유로 인해 비효율적이라고 판단했습니다. document 접근 구조의 문제 해당 서비스는 사용자 입장에서 설게 된 서비스이고, 관리자 측면에 미흡하게 구성된 부분이 있습니다. 각 document는 판매자 id를 기반으로 돌아갑니다. 그러나 관리자가 사용을 할 때는 아이디 값보다는 상태 값을 기반으로 id를 찾는 경우가 더 많습니다. 대표적인 예시로 특정 계정들이 API를 사용할 수 있도록 승인해 주는 기능을 관리자에서 수행할 때, 성능이슈가 크게 발생했습니다. 따라서 이를 고려하면 다음과 같은 성능 차이가 있게 됩니다. 유저 기준 : T(n) = O(1)관리자 기준 : T(n) = O(n)그리고 특정 document의 값 자체를 히스토리로 저장함으로써 불필요한 공간을 차지하고 있었습니다. 관리자 측면에서의 설계 이슈와 불필요한 document의 데이터 적재로 인해 날이 가면 갈수록 큰 성능 저하가 발생했습니다. 문제 2. Couchbase에 대한 인프라 이슈성능 이슈와 함께 이 작업을 진행하게 된 가장 큰 이슈

따라서 테스트의 분포는 아래와 같은 육각형 형태가 된다.하지만 외부 dependency가 커짐에 따라 integration 테스트의 양은 증가한다.마이크로 서비스는 몇개의 단위테스트 만으로도 전체 어플리케이션의 로직을 커버할 수 있을 만큼 단위가 작다(이론적으로).단위테스트가 제일 많고, integraion, integrated 순으로 분포된다.모노리스에서는 아래와 같은 삼각형 형태의 테스트 분포가 일반적이다.모노리스 아키텍처에서 마이크로 서비스로 마이그레이션이 많아짐에 따라 테스트에 대한 내용도 달라지고 있다.Testcontainers 와 Docker 덕분에 유래없이 통합테스트를 쉽게 구현할 수 있다.Testcontainers를 이용하면 프로그래밍을 통해 통합테스트에 필요한 외부 dependencies를 마련할 수 있다.Mocks를 이용한 테스트도 좋지만, 실제로 통합테스트를 하기 전까지는 코드가 실제로 작동하는지 알 수 없다.Microservice 아키텍처로 인해 통합테스트의 비율이 커지고 있다.pom.xml에 dependency들을 추가한다.데모에 사용되는 어플리케이션은 GameApp으로 wallet 정보는 postgres에, user와 items는 couchbase에 저장한다.Test 클래스에 "@Testcontainers" 어노테이션을 추가한다."@Container" 어노테이션은 테스트 첫 실행시 postgres와 couchbase 컨테이너를 생성하고, 해당 저장소는 모든 테스트들이 공유한다."@DynamicPropertySource"를 통해 properties를 정의할 수 있다. Testcontainers는 random port를 할당하기 때문에, port 설정은 신경쓰지 않는다.테스트 실행시 아래와 같이 postgres와 couchbase container가 생성되고, 테스트가 끝나면 사라진다.하나의 microservice에 postgres와 couchbase 두개의 database를 사용한 것은 microservice에 어울리지 않는다.두개의 microservice로 나누어 보자. 하나는 wallet를 저장하는 postgres를 사용하고, 다른 하나는 couchbase를 이용해 game user를 저장한다.소스를 분리하고, wallet microservice의 도커 이미지를 만들어, dockerhub의 denisros/wallet_mciroservice 레포지토리에 푸쉬하였다.테스트에서는 game user를 만들고, wallet microservice를 호출하여 해당 user의 wallet를 생성한다.wallet microservice 와 postgres 사이에 통신이 가능해야 하므로, network 를 생성한다.wallet microservice를 GenericContainer를 이용해 생성하고, 연결할 postgres의 DATASOURCE_URL를 postgres container의 network alias를 이용해 설정한다. 같은 network를 통해 직접 접근하므로, 5432 디폴트 postgres포트를 이용한다.w

최적의 Couchbase 운영 프로세스 수립하기안녕하세요. 무신사 인프라보안팀 DBA(Database Administrator)파트에서 AWS 기반 데이터베이스 구축과 운영을 담당하는 주경호입니다.지난 1편에서는 무신사가 오픈소스 기반의 NoSQL 데이터베이스를 구축하게 된 배경과 Couchbase를 선택하게 된 과정을 공유 드렸습니다. 이번 2편에서는 Couchbase를 안정적으로 운영하기 위해 방법을 고민하고, 찾아나가는 과정을 공유해 드리겠습니다.어떻게 운영할까?지난 글에서 이전할 데이터베이스를 결정하기 위해 성능 테스트와 가용성 테스트를 진행했고, 모든 테스트를 통과한 Couchbase를 선택했습니다. 성능, 가용성 못지않게 중요한 것이 안정적인 운영입니다. 데이터베이스를 대체하는 데 있어 실제 운영 시 고려해야 할 사항이 한둘이 아니기 때문입니다.기존에 사용하던 DocumentDB는 관리형 서비스로 구성/운영/모니터링/백업/복구 모두 GUI(Graphical User Interface)로 간단히 할 수 있습니다. 반면, 오픈소스 기반의 데이터베이스는 모든 업무를 하나부터 열까지 직접 알아서 해야 합니다.하여 저희는 운영기준을 수립하기로 했고, 기존 DocumentDB 운영 경험과 같은 수준으로 운영하기 위해서 필요한 부분은 무엇인지, 부족한 부분이 있다면 어떻게 대안을 만들지 고민해 보았습니다.Couchbase는 AWS DocumentDB 수준의 단일화된 GUI(Graphic User Interface)로 제어하는 것은 불가능하지만, 설치 시 자동으로 제공되는 웹 기반 관리툴로 기본적인 모니터링과 관리를 할 수 있습니다만 매 단계마다 사람의 개입이 필요합니다. 이를 자동화하려면 다양한 환경의 운영을 최대한 많이 경험하고, 그 과정에서 운영 노하우를 체득하여 적용하는 노력이 필요합니다.SLA라는 큰 벽SLA(Service Level Agreement)는 서비스 수준 계약이라고 하여, 서비스를 측정하는 지표입니다. 해당 서비스에 대해 어느 수준의 가용성을 가질 것인지를 정의하고 그 수준에 맞게 운영하는 것을 의미합니다. 주로 서비스 이용자와 제공자간의 계약에서 서비스 가용성 수준을 정의하는 데 사용되는데요. 내부 시스템을 운영하는 경우에도 가용성을 최소 어느 수준으로 할지 정의할 때 사용됩니다.DocumentDB SLAAWS DocumentDB의 SLA는 위와 같이 99.9%를 목표하고 있습니다. SLA가 특정 수준 이하가 될 경우 고객에게 어느 수준으로 배상을 하는지 기록되어 있는데요. 내부 시스템을 운영하는 경우에는 배상이 아닌 안정적인 서비스 운영이 중요하므로, 어느 수준의 다운타임 이상으로 운영할지 기준이 필요합니다. 이때 SLA을 활용해 개별 서비스별로 지표를 적용해 운영할 수 있습니다.SLA 수준 별로 어느정도의 가용성을 가져야 하는지는 아래 표와 같습니다.이러한 지표를 기준으로 서비스 혹은 제품에 대해 어느 수준 이상을 유지할지 목표를 정의하면 됩니다.Couchbase 도입을 결정한 것은 DocumentDB의 고비용을