개발/인프라

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 로 구성한 컨테이너 오케스트레이션이 잘 알지도 못하면서 좀 멋져보였다. 여튼 이런 이유에서 꼼삐에서는 가상화 인프라 구성(가상 머신, 컨테이너) ..

현재 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 를 하나의 쿠버네티스 ..

기존에 VirtualBox 에서 VM 을 생성하여 쿠버네티스 클러스터를 구축·운영하였는데, Type1 Hypervisor 라는 개념을 알게되어 Type 1 Hypervisor 인 Proxmox 위에서 쿠버네티스 클러스터를 재구축하였다. 간단하게 Type1, Type2 하이퍼바이저의 차이와 Proxmox 클러스터 구축 과정, 추후 숙제를 정리해두려고 한다. 1. Hipervisor Type1/Type2 하이퍼바이저는 가상화를 제공하는 플랫폼 소프트웨어를 말한다. 내가 기존에 사용하던 VirtualBox(Oracle) 나 Vmware 같이 가상머신을 생성, 실행, 리소스 관리하는 기능을 수행한다. 쿠버네티스나 도커같이 컨테이너 관련 플랫폼도 가상화의 영역이긴 하지만, OS 수준에서 구현된 컨테이너 런타임에 ..

저번 포스팅에서 무중단 배포를 구현하면서 blue-green / rolling / develop 세가지 방식의 배포를 전부 구현했었는데, 그중에 develop  배포 방식은 기존 브랜치의 배포(8080, 8081 포트)를 중단하고 8082 포트에서 develop 브랜치를 배포 새롭게 배포를 하는 식으로 동작했었다. 이것도 무중단으로 동작하긴 하지만 사실 개발 단계의 서버를 그대로 노출하게 되므로 아무 의미가 없는 배포 방식이었다. 개발용 서버는 개발자나 QA 같은 특정 집단의 사람들만 이용할 수 있도록 하고, 기존 서비스는 그대로 유지해야 제대로 된 동작 방식이라는 생각이 들었다. 그래서 이렇게 바꿔봤다. 1. Nginx 설정1) 요청 식별특정 ip 만 특정 업스트림으로 보내도록 Nginx 설정을 수정했..