개발

꼼삐에서 식물 검색을 할 때 실시간 인기 식물 순위가 노출되면 좋겠다는 요구사항이 있었다. 사실 복잡한 로직을 요하는 기능은 별로 개발해본 적이 없었어서, 요구사항을 듣고서 바로 구현방안이 떠오르지 않았다. 어떤 자료구조를 활용해서 어떻게 구현할 지 조금 고민하다가 금방 구현을 하긴 했다. 그런데 최근에 어떤 회사 채용 과정에서 관련 내용을 묻는 질문이 있었는데, 까먹어버려서 뭔가 뚜렷하게 답을 하지 못했다. 잊지 않도록 상세하게 구현 내용을 좀 적어두려고 한다.1. 기능 요구사항'인기 순위' 라는 기능을 개발하기 위해서는 생각보다 여러 조건들이 필요했다. 우선 '인기' 라는 것을 어떤 지표로 판단할 것인지를 정해야 했다. 직관적으로 떠올릴 수 있는 지표는 조회수, 관련 게시글 수(이 경우에는 관련 게시..

MongoDB 클러스터를 구축하려고 하는데, MongoDB 에서는 Replication 이 어떤식으로 동작하는지, 주의할 점이 어떤 게 있는지, 그리고 주요한 설정 값은 뭔지 정리해보았다. MongoDB 클러스터 구축시 적절하게 활용하고자 한다.  주로 서적으로 공부를 하는 편인데, MongoDB 는 최근 시장이 매우 커짐과 동시에 버전이 계속 업데이트 되어서 레퍼런스를 찾기가 쉽지 않았다. 국문 서적중에는 가장 최근에 나온 MongoDB 완벽가이드? 이게 4.x. 버전으로 글 작성 기준의 최신 버전인 8.0 버전과 비교해서 상당히 뒤떨어져 있기 때문에, 좀 아쉬울 것 같았다. (그래도 주문은 해놓았음...)  근데 MongoDB 의 공식 문서을 봤는데, 별도로 서적이 필요 없을 정도로 매우 정리가 잘되..

오늘은 Redis 를 운영 단계에서 사용할 때 안정성 있게 사용하기 위한 지표인 '가용성' 관련해서 공부한 내용을 정리한다. Redis 는 대부분의 서비스에서 중추적인 역할을 담당하기 때문에 장애 상황에 대한 대응책이 꼭 필요하다. 장애 상황을 빠르게 극복하고 정상화하여 최종적으로 서비스의 고 가용성을 확보하기 위해서는 Redundancy(Replication) 과 자동 Failover 가 확보되어야 할 것이다. 즉, Redis 서버를 여러개 복제해서 운용하고 있다가 Primary 노드에 장애가 생기면 Replica 노드가 장애가 발생한 Primary 노드를 대신해 서비스를 이어갈 수 있어야 한다는 것이다.  1. Replication (복제)Redis 도 다른 데이터베이스와 마찬가지로 DB 자체적으로 ..

gRedis 의 동작 방식을 공부했다. Redis 가 싱글 스레드임에도 비동기적으로 멀티플렉싱 IO 를 어쩌구 저쩌구 하는 설명을 여기저기서 많이 보았는데, 사실 이런 단어들은 나한테 별로 직관적으로 와닿는 설명이 아니라서... 좀 더 아랫단의 동작을 분석해서 Redis 가 어떻게 빠르게 동작할 수 있는지를 알고 싶었다. 코드 수준까지 분석하는 건 역시 힘들고 핵심적인 사항만 정리한다. 1. Redis 의 네트워크 I/O나는 지금까지 I/O 작업이라고 하면 디스크에 읽고 쓰는 것을 주로 생각해왔다. 그런데 Redis 에서 주로 거론되는 I/O 작업은 디스크의 입출력을 이야기 하는 것이 아니라 네트워크의 I/O 를 이야기한다. I/O 는 디스크에서만 일어나는 게 아니라 네트워크를 통해 들어온 요청, 응답을..

지금까지 Redis 는 주로 캐싱 용도로 많이 사용했고, 그외로 Pub/sub 처리, 실시간 인기순위 등에 사용했었다. 사실 실제 운영 환경에서 Redis 를 운용해본적은 없어서 조금 고민이 부족했던 부분이 많이 있었는데 실제 운영 환경에서는 어떤 고민들을 해야했고, 어떤 문제들이 발생하는지 공부한 내용을 정리한다.1. 메모리 관리Redis 는 태생적으로 메모리를 저장공간으로 사용하는 인메모리 데이터베이스로, 디스크를 이용하는 RDB 에 비해서 데이터 입출력 속도가 매우 빠르다. 그러나 성능이 좋은 만큼 비용은 훨씬 크다. 때문에 제한된 용량을 가지며 가격도 디스크에 비해 매우 비싸다.더보기기억 장치별 성능최근에는 보조기억장치로 SSD(Solid State Disk) 를 주로 사용하는데 이는 하드 디스크..

꼼삐 프로젝트를 시작하면서 인프라 구성 쪽을 가장 공부해보고 싶었다. 꼼삐를 시작하기 직전에 회사에서 했던 배달공제조합 프로젝트에서 쿠버네티스와 아르고 씨디를 사용했었는데, 그때는 다른 계열사 데브옵스 엔지니어가 인프라 관련 작업들을 다 해주기도 했고 워낙 개발일정이 빠듯했어서 인프라 구성 관련해서 제대로 공부할 수 없었다. 현업에서의 개발 환경은 확실히 다르긴 했다. 개발, 검증, 운영 세단계로 환경을 분리하여 운영하고 있었고, 보안 수준이나 리소스 수준도 다르고 배포과정도 다르고... (사실 구체적인 부분은 잘 모름) 사실 무엇보다 쿠버네티스와 아르고 cd 로 구성한 컨테이너 오케스트레이션이 잘 알지도 못하면서 좀 멋져보였다. 여튼 이런 이유에서 꼼삐에서는 가상화 인프라 구성(가상 머신, 컨테이너) ..

이전에 진행한 내잔고를 부탁해 프로젝트에서는 Redis 를 활용한 캐싱 처리를 제대로 사용하지 못한 느낌이 있었다. 그때는 어떤 데이터를 캐싱해야할지 잘 감이 안와서 그냥 남들 하는대로 Refresh 토큰을 저장해두는 정도로만 활용하였다. 대신 채팅 기능을 구현할 때 사용자의 구독 정보 관리와 서버간 메세지 브로커로 활용한 바 있다. 물론 대규모의 트래픽 처리를 하는 경우에는 메세지 브로커로 Kafka 를 쓰겠지만, 그래도 알차게 Redis 를 활용했다고 생각한다. 이번 프로젝트에서는 Redis 의 캐싱 기능을 더 야무지게 활용하여 api 응답 시간을 줄이고자 하였다. 사실 기술적으로 별 내용은 아닌데 나름 참고할만한 유즈케이스 같아서 기록해 둔다.1. 캐싱 데이터캐싱 처리는 데이터를 가지고 올때 DB ..

현재 comppi 는 dev 환경만 구축이 되어있는 상태인데, 이제 배포가 임박하여 prod 환경을 구축하고 배포하려고 한다. 지금은 컨트롤 플레인까지 총 4개의 노드에서 dev 어플리케이션을 구동하고 있는데, 이제 배포할 prod 는 dev 를 동일한 노드에서 운용해도 될 정도로 하드웨어 리소스가 충분하지도 않고, 가능한 개발 서버와 운영 서버의 환경을 분리하고 싶었다. 개발 PC 를 클러스터에 포함시켜서 별도로 3개 정도의 worker 노드를 추가하여 그쪽에 dev 환경을 구축/배포하고, 기존의 운영 서버에서는 운영 환경을 격리시켜 놓으려고 한다. 여튼 오늘 정리하려는 글은 쿠버네티스 클러스터에 개발 PC 를 추가하기 위해서 또다시 VM 을 올리고, 쿠버네티스 환경을 프로비저닝해줘야 했는데, 해당 과..

쿠버네티스에 cicd 파이프라인을 구축했다. 상당히 많이 헤맸다. 헤맸던 이유는 머리속에 cicd 가 이뤄지는 구조를 분명히 그리지 못해서 그런거 같다. cici 의 대상에 대해서 분명히 설정하고, 어떤 도구들이 어떤 대상을 바라보고 있는지 확실하게 인지하고 있었으면 조금 더 명쾌하게 해결이 되었을 것 같다. 사실 그렇게 복잡한 구조도 아닌데, 퇴근후에 지친 상태로 프로젝트를 진행하면 빨리 끝내고 쉬고 싶은 생각이 들고 머리도 잘 안돌아가서 바보 같이 대충대충 빨리 하게된다... 지금에서야 배포 파이프라인의 구조가 명확하게 머리속에서 그려지기 때문에 문제가 없는데 어쩐지 다른 공부를 계속하다보면 휘발될지도 모르겠다는 생각에 부랴부랴 구축 과정과 파이프라인 구조를 정리 해둔다.  1. Kubernetes ..

comppi 의 0.1.0 버전 개발(MVP) 이 어느정도 마무리가 되면서 드디어 미뤄왔던 운영 서버를 올리는 작업에 착수했다. 현재 생각은 24 시간 돌아가는 서버용 PC 에는 운영서버를, 개발할 때만 켜두는 개발PC 에 개발 서버를 올려서, 운영서버에는 부담이 가지 않도록 하는 것이다.  이런 경우 개발 PC에 별도의 쿠버네티스 클러스터를 만들어두고 운용하는 편이 좋을 것 같은데, 그렇게 되면 클러스터 외부에 로드밸런서를 달아야 한다. 왜냐면 난 공용 IP 가 하나이고 때문에 도메인에 따라서 어떤 클러스터로 보낼지 정해줘야 하기 때문이다. 물론 이렇게 할 수도 있지만, 일이 너무 커지는 것 같기도 하고 쿠버네티스의 여러가지 오브젝트를 다뤄보고 싶은 욕심도 있었어서, 두개의 PC 를 하나의 쿠버네티스 ..