여전히 valkey보다 redis가 더 익숙한 분들이 계실 겁니다. valkey는 Redis Inc.의 redis에 대한 라이센스 변경 및 독점적 지위 확보 시도에 대한 반발로 redis 7.2.4를 베이스로 추가 개발되고 있는 레디스 대체제입니다. 현재는 레디스보다도 먼저 8.0 버전을 출시하는 등 굉장히 활발하게 개발 및 유지보수 되고 있습니다.
당연한 이야기로 레디스의 포크인 만큼 레디스와 동일하게 다양한 곳에서 캐시로써 활용되고 있습니다. 이 글에서는 그 중 가장 보편적인 흐름 중 하나인 유저가 API 서버에 질의 후, API 서버는 캐시를 조회, 실패 시 RDB에서 조회하는 방식을 사용하는 패턴에서 효과적으로 밸키에 대한 읽기를 감소 시키는 방법을 소개하고자 합니다.
MSA는 개발 및 배포의 유연성, 기술 스택의 다양성, 확장성, 장애 격리 등 다양한 장점을 제공하지만, 그로 인해 트레이드 오프되는 단점들도 분명히 존재합니다. 그 대표적인 부분이 비즈니스 로직 오류, 사용자 경험 저하, 심각한 경우 금전적 손실까지 야기할 수 있는 중요한 문제인 잠재적인 데이터 불일치 문제일 겁니다. 이 문제는 다양한 이유로 발생할 수 있지만, 바로 생각나는 이유로는 다음과 같은 것들이 있을 겁니다.
결국 요지는 기존의 단일 데이터베이스에서 하던 트랜잭션을, 여러 서비스가 서로 다른 목적을 위해 각자의 데이터베이스에서 독립적으로 수행하다보니 연결이 느슨해지고, 그 틈새에서 발생할 수 있는 다양한 이슈로 인해 서비스 간 데이터 상태 동기화에 문제가 생길 수 있다는 것입니다.
서비스를 쭉 구성하다보니 이런 생각을 했습니다.
왜 굳이 2개를 중복으로 메시지 브로커에게 남겨야 하는가가 매우 큰 궁금증이었습니다.
기본적으로 어떤 메시지 브로커를 선택하든 간에, 아니 가장 대표적인 Kafka를 상정하고 얘기해도, 각 컨슈머 그룹에 따라 메시지를 복제해서 전달하고, 컨슈머 그룹 내에 여러 컨슈머가 있을 경우에 적절히 분배해주는 기능이 존재합니다.
MSA를 구성하든, MMA를 구성하든 간에 사실 필요한 로그를 누락 없이 받아서 처리할 수 있을 것입니다.
처리량이 많다고요? 노드를 늘리고, 스펙을 올리죠!
왜 사람들은 PGO(Profile Guided Optimization)을 적극적으로 사용하지 않을까?
저는 이 의문을 예전부터 품고 있었습니다. 생각해보니 프로파일을 저장하고, 가져오는 어떠한 표준화된 프로토콜이 없다는 게 이유로 보였습니다. 사실 쓸 사람들은 어떻게든 쓰고 있겠지만, 저도 처음 PGO를 적용할 때에 어떻게 저장하고 가져와야 할지 고민을 좀 했었습니다. 그래서 이번 글에선 해당 내용에 대한 공유를 하겠습니다.
PGO 특성 상, 프로파일을 주기적으로 생성하고 업로드하는 실제 서비스로 올라간 어플리케이션과, 해당 프로파일들을 받아서 하나로 합치고 빌드할 때 적용하는 빌드 어플리케이션이 있습니다. 두 과정이 철저하게 분리되어 있기에 동기적으로 사고할 필요가 없습니다. 그럼 가장 적합한 구조는 중간에 버퍼나 저장소를 두고 계속 데이터를 추가, 필요할 때 다운로드, 주기적으로 데이터를 삭제하는 과정만 있으면 됩니다.
대는 소를 포함한다는 말은 법률상으로 상위 개념과 하위 개념이 존재할 경우, 상위 개념에 대한 법을 하위 개념에도 적용하는 것입니다. 쉽게 이야기하면, 법률적으로는 자전거가 자동차의 하위 개념이니 자동차에 적용하는 다양한 법을 자전거에도 같이 적용하는 것입니다. 하지만 제가 법률 전문가도 아니고, 법과 관련된 이야기를 하고 싶은 건 아닙니다.
저희는 때때로 범용으로 무언가를 만들고, 전용으로 사용하는 방법을 취합니다. 대표적인 예로 postgres는 많은 데이터를 저장하고 쿼리할 수 있지만, 저희는 스키마를 한정해서 한정적인 데이터 형태를 저장하고 활용합니다. MongoDB같은 경우엔 그렇지 않다구요? 하지만 높은 확률로 로직이나 환경적으로 들어갈 자료, 해야할 쿼리는 정해져 있을 겁니다. 그게 정녕 비정형 JSON을 저장하기 위한 data lake라 할 지라도요. 그리고 그를 위한 별도 모듈이 존재할 것입니다.
NATS는 Go 언어로 작성된 메시지큐입니다. 그리고 제가 개인적으로 좋아하는 오픈소스 프로젝트이기도 합니다. 한때 NATS에서 서브스크립션이 메시지를 받는 방식이 단순 채널이 아닌 독특한 자료구조가 따로 있는 걸 봤었던 적이 있습니다. 이 자료구조는 연결리스트를 통해 특정 서브스크립션에 전달될 메시지를 저장합니다. 그리고 sync.Cond를 이용하여 별도의 대기 중인 서브스크립션을 위한 고루틴에게 알려줍니다.
sync.Cond의 Wait() 메서드를 통해 메시지가 추가되길 대기합니다.sync.Cond의 Signal() 메서드로 해당 고루틴을 깨웁니다.이 구조는 쓰는 주체가 가지는 상태와 읽는 주체가 가지는 상태가 별도로 존재한다는 것에 의의를 느꼈습니다. 물론 channel도 버퍼를 주게 되면 상태를 따로 가질 수 있습니다만, 기본적으로 내부에서 락을 가지는 구조이며 반쯤 동기식으로 동작하도록 코드가 작성됩니다. 그리고 무엇보다 채널은 팬아웃(fan out)에 적합한 구조가 아닙니다.
서비스가 되었든, 소프트웨어가 되었든, 어떤 프로젝트에 대해 보통 기업은 신기술에 밝거나, 손이 빠르거나, 임원의 말을 잘 듣는 사람에게 첫 스타트를 시키는 경우가 많습니다. 하지만 단순히 그렇게 되어서는 서비스나 소프트웨어의 수명이 줄어들어서, 유지보수 비용의 증가 뿐만 아니라 해당 프로젝트를 대체할 새로운 프로젝트를 해야할 수 있어, 큰 지출로 다시 돌아올 수 있습니다.
만약 아키텍트가 시작할 때, 어떠한 철학이나 체계 없이 주먹구구로 프로젝트를 진행하면 어떤 일이 벌어질까요?
이것 또한 최근 포스트와 마찬가지로, 최근에 진행했던 프로젝트의 회고입니다.
해당 프로젝트에는 개인적으로 몇가지 이해가 어려운 부분들이 좀 있었습니다. 그 중 R&R에 대해 제가 품은 의문과 그에 대한 제 나름의 해결 방법을 서술하고자 합니다.
설계 당시부터 지금까지 모든 서비스는 k8s에 pod로써 운영되고 있습니다. 대략적으로 네트워크 요청 트래픽은 ingress -> API GW -> each service로 흐릅니다. 이 중 API GW는 솔루션이 아니라 자사에서 내부적으로 만든 것입니다. 기능으론 일반적인 API GW와 유사하게 요청에 대해 특정 서비스로의 라우팅과 요청에 대한 인증 토큰 검증 등이 있습니다. 그리고 각 서비스는 특정 데이터를 다루는 서비스와 저장하는 DB를 세트로 구성됩니다. 제가 보는 문제는 이 구조로 인해 생성되는 gray zone이 있습니다.