개발

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

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

이전글 [https://techforme.tistory.com/48] 이전글에서 서버를 이중화 하면서 authorization_request_not_found 오류가 나는 상황에 대한 해결책으로 ip hash 방식의 부하분산을 이야기 했었다. 이는 간단한 해결책이긴 했지만, 만약 부하 분산 방식을 round robin 으로 바꾸라는 요구사항이 생긴다면, 전혀 대응할 수 없는 미봉책이었다. (사실 Nginx 를 더 활용해 보고 싶어서 해봤다.) 근본적인 해결책이 필요했다. 이번 게시글에서는 OAuth Authorization 요청 정보를 서버 내부에 저장하지 않고 외부에 저장함으로써, Nginx 의 부하 분산 알고리즘과 상관없이 해당 문제를 해결할 수 있는 방법을 설명한다.1. 문제 상황 분석1) 문제 발..

이전에 지리데이터를 다루면서 "클러스터링" 이라는 단어를 잘 모르고 쓴 적이 있다. 개발 초기, 창고의 검색 방식에 대해 고민하다가 "위치 정보 데이터가 많아지면 대체 원하는 정보를 어떻게 조회해오지?" 라는 거의 공상에 가까운 생각을 했다. 일단은 어떤 한 점(위경도)에서 주어진 반경 내의 데이터를 조회한다고 했을 때, 가장 먼저 떠올릴 수 있는 방법은 모든 데이터와의 거리를 일일이 다 계산해서 주어진 반경 내에 있는지 판단하는 방식을 먼저 떠올렸다. (그때는 풀 스캔, 시퀀셜 스캔이라는 단어도 몰라서 내가 알고 있는 단어인 브루트 포스 단어로 이 방법을 지칭했다.) 그러다가 당근 마켓을 떠올렸고 비슷한 지역끼리 묶어서 그 근처 지역만 먼저 조회하면 되지 않나? 라는 생각에서 "클러스터링" 이라는 말을..

이전 포스팅에서 무중단 배포를 rolling 방식, blue-green 방식으로 구현했었다. 그렇게 해놓고 보니, 서버가 이중화 되었을 때도 기능들이 제대로 동작하는지 테스트 하고 싶어졌다. 단일 서버였다가 서버 개수가 두 개 이상으로 늘어나면 각각의 요청이 동일한 서버가 아닌 다른 서버로 연결 되기 때문에 예기치 않은 문제들이 생길 수 있다. 특히 서버 내부의 메모리로 관리하는 자료가 있다면 문제가 발생하기 쉽다.  이 경우 서버의 메모리마다 관리하는 정보가 각각 달라지는데 만약 요청을 서로 다른 서버가 처리하게 되면 동일한 결과가 나오지 않게 되기 때문이다. stateful 한 서버가 되는 것이다. 예를 들어 로그인 정보를 각각의 서버에서 저장하고 있게 되면 로그인 정보를 가지고 있지 않은 서버에 요..

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