개발놀이터

카프카에 대한 이론적인 내용은 아마 이게 끝일 것 같습니다. 아파치 카프카 카테고리는 개념, 심화, 응용을 마지막으로 이제 실습을 해볼 예정입니다.  이번 응용편에선 이렇게 진행됩니다.  Unclean Leader Election의 위험성과 사용 여부 판단Offset 관리 전략성능 최적화 및 튜닝카프카 스토리지와 OS 레벨 연계이렇게 네가지 섹션으로 이루어집니다. 한번 천천히 정리해보겠습니다.  Unclean Leader Election카프카는 장애시 ISR에서 리더 파티션을 새로 뽑아 장애 상황에 최적화된 움직임을 보여줍니다. 그런데 만약 ISR에 뽑을만한 리더 파티션이 없으면 어떻게 될까요?  이럴 때 개발자는 Unclean Leader 즉, ISR에 없는 파티션 중 리더로 선출할 수 있도록합니다. ..

요즘은 카프카와 NoSQL을 공부하고 있는데 카프카는 특히 공부하면 공부할수록 왜 개발자들이 많이 사용하는지 알 것 같습니다. 공부하면 공부할수록 왜 쓰는지 이해가 된달까요.. 이번 포스팅에선 카프카와 AWS SQS, SNS와 비교하면서 왜 카프카가 대용량 메세지 처리에 능하게 되었는지에 대해서 정리해봤습니다.  카프카 vs SQS, SNS왜 다른 메세지 큐도 아니고 SQS냐하면 RabbitMQ는 메세지를 소비할 곳을 세밀하게 조정하고 싶을 때 사용하는 것이 바람직하지 대용량으로 비동기 메세지 처리를 하는데 특화되어있지는 않습니다. 다른 메세지 큐인 Redis의 Pub/Sub 또한 대용량 비동기 메세지 처리에 특화되어있지 않기도 하구요.  그런 의미에서 SQS와 SNS를 조합한 메세지 큐잉 서비스는 완전..

이번 포스팅에서는 아파치 카프카에 대해서 개념만 잡았던 이전 포스팅에 이어 조금 딥한 내용을 공부해보고 정리해보았습니다. 처음엔 카프카의 구성 요소를 짧에 짚고 넘어가고 이후 카프카의 주요 개념에 대해서 알아보도록 하겠습니다.  아파치 카프카카프카의 구성요소로는 Broker, Topic, Partition, Producer, Consumer, Consumer Group이 있습니다. 하나씩 간단하게만 정리해보겠습니다.  브로커 : 브로커는 카프카가 설치되어있는 물리적인 서버에 해당합니다. 이런 브로커들이 모여서 카프카 클러스터가 되는데 이 브로커는 카프카 그 자체라고 볼 수도 있습니다. 토픽 : 메세지가 저장되어있는 "논리적인" 공간입니다. 메세지를 생산하는 프로듀서는 이 토픽을 바라보고 생산하고 컨슈머는..

마이크로 서비스와 메세지 브로커는 뗄 수 없는 사이입니다. 서로 다른 도메인이 여러개의 서버로 나눠져 있는 상황에서 모든 서버에 동일하게 데이터를 전달해야 하는 경우에 메세지 브로커만한게 없죠.  그렇기에 모놀리식에서는 메세지 브로커를 사용하는게 오버엔지니어링이 되기도 합니다.  이번 포스팅에서는 메세지 브로커의 근심과 걱정에 대한 내용을 공부해보고 정리해봤습니다.  메세지 브로커https://coding-review.tistory.com/504 아파치 카프카 (개념)저번 포스팅에서 파트2를 시작하면서 메세지 브로커의 장을 열었습니다. 메세지 브로커를 이용해서 서버간 통신을 조금 더 매끄럽게 진행할 수 있다는 것을 알았고 어떤 모델이 있는지 알았습coding-review.tistory.com메세지 브로커..

요즘 사이드 프로젝트 때문에 실습만 주구장창 했는데 오랜만에 이론 포스팅입니다. 쿠버네티스를 공부하다보면, 그리고 DevOps에 대해 공부하다보면 한번쯤은 보게 되는 논쟁 바로 "쿠버네티스 클러스터에 RDB배포? 시기상조다" VS "쿠버네티스 클러스터에 RDB배포 안해봤어? 겁나 편한데" 이 논쟁을 구글링하면 마땅한 답이 없습니다. 누가 시원하게 쓰면 좋아! 쓰면 나빠! 이걸 적어놓은걸 찾기 힘들었습니다. 그래서 GPT와 토론을 하면서 주장 -> 반박 -> 재반박 -> 반박에 반박 을 거듭하여 나름 정리해봤습니다.  우선 이 논쟁에 대해 짚어야 하는 부분은 크게 다섯가지입니다.  트랜잭션 롤백에 대한 관점마스터 슬레이브 노드 선출에 대한 관점네트워크 망분리로 인한 split-brain 상황에 대한 관점쿠..

이전 포스팅과 이어집니다! https://coding-review.tistory.com/560 AWS EKS 모니터링 환경 구축하기 (Prometheus, Grafana)이전 포스팅에서 이어집니다!  https://coding-review.tistory.com/559 AWS EKS HPA로 확장성 높이기저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/558 AWS EKS 스프링 + Nginx + SSL저번 포스coding-review.tistory.com 이전엔 프로메테우스 + 그라파나로 모니터링 환경을 구축해봤습니다. 이번 포스팅에선 이전 포스팅에다 슬랙을 추가해보도록 하겠습니다.  이전 포스팅 내용은 담지 않았습니다! helm repo add pro..

이전 포스팅에서 이어집니다!  https://coding-review.tistory.com/559 AWS EKS HPA로 확장성 높이기저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/558 AWS EKS 스프링 + Nginx + SSL저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/557 AWS EKS 스프링 프로젝트에 Ncoding-review.tistory.com 이전 포스팅에선 HPA와 CA로 파드와 노드를 동적으로 늘리는 실습을 했습니다. 이번엔 모니터링 환경을 구축해보도록 하겠습니다! 이전 포스팅에서 다뤘던 내용은 다루지 않겠습니다! 모니터링 환경 구축프로메테우스 설치우선 프로메테우스 yaml..

저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/558 AWS EKS 스프링 + Nginx + SSL저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/557 AWS EKS 스프링 프로젝트에 NGINX 붙이기이번 포스팅은 이전 포스팅과 어느정도 이어집니다. 이전에 스프링 프로젝트를 간단coding-review.tistory.com 저번 포스팅에선 Nginx Ingress Controller 에 letsencrypt로 발급한 키로 secret을 만들어서 SSL을 연결했습니다. 이번 포스팅에선 HPA와 CA를 이용해서 파드에 무리가 가면 파드를 늘리고 파드를 늘리는 과정에서 노드의 자원이 부족하면 노드까지 늘..

저번 포스팅에서 이어지는 내용입니다!  https://coding-review.tistory.com/557 AWS EKS 스프링 프로젝트에 NGINX 붙이기이번 포스팅은 이전 포스팅과 어느정도 이어집니다. 이전에 스프링 프로젝트를 간단하게 배포했는데 저는 추후 HTTPS를 붙여서 실제 도메인을 붙여볼 예정이기 때문에 Nginx에 스프링 프로젝트를coding-review.tistory.com 저번 포스팅에선 Nginx를 설치하고 스프링 프로젝트를 붙여서 로드밸런서를 이용해서 외부에서 접속해봤습니다.  이번엔 Nginx에 SSL을 붙여서 HTTPS를 적용시켜봤습니다. 거의 4일내내 이거만 한거같네요. 본격적으로 시작해보겠습니다! Nginx와 SSL 근데 이제 Kubernetes를 곁들인저도 Nginx에 SS..

이번 포스팅은 이전 포스팅과 어느정도 이어집니다. 이전에 스프링 프로젝트를 간단하게 배포했는데 저는 추후 HTTPS를 붙여서 실제 도메인을 붙여볼 예정이기 때문에 Nginx에 스프링 프로젝트를 붙여야했습니다.  이번 포스팅에선 Nginx를 붙이기만 하고 다음 포스팅에선 HTTPS를 적용해보겠습니다.  바로 시작해보겠습니다! 스프링에 Nginx 붙이기kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.7.0/deploy/static/provider/aws/deploy.yaml 우선 Ingress Controller를 설치해줍니다.  위의 명령어를 쓰면 namespace, Service Account..