개발놀이터

카프카에 대한 이론적인 내용은 아마 이게 끝일 것 같습니다. 아파치 카프카 카테고리는 개념, 심화, 응용을 마지막으로 이제 실습을 해볼 예정입니다.  이번 응용편에선 이렇게 진행됩니다.  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를 조합한 메세지 큐잉 서비스는 완전..

이번 포스팅에서는 CAP정리를 간단하게 복기해보고 CP, AP 데이터베이스의 특징에 대해서 정리해보도록 하겠습니다.  CAP 정리CAP 정리는 2000년에 Brewer가 발표한 이론으로서 "분산 시스템에서 C, A, P를 모두 만족하는 데이터베이스는 없다" 라는 이론입니다. 이 이론에 대한 증명이 끝났기 때문에 더이상 이론이 아니라 정리라고 불러야하는 것이죠.  CAP 정리에 대해 포스팅한 것이 있어서 그걸 좀 가져와봤습니다.  https://coding-review.tistory.com/312 CAP 정리와 한계 PACELC 정리이번 포스팅에서는 Brewer (브루어)의 CAP정리에 대해서 알아보도록 하겠습니다. CAP정리가 20년도 더 된 정리이기 때문에 그걸 보완한 PACELC 정리에 대해서도 알아..

NoSQL 중에서 가장 인기있는 데이터베이스를 꼽아보라고 한다면 당연 MongoDB이지않을까 싶습니다. 저도 NoSQL에 대해서 공부하기 전에도 MongoDB는 알고 있었을 정도니까 말 다한것이죠.  오늘 포스팅에선 NoSQL 그 중에서 MongoDB가 어느 부분이 특별해서 이렇게 많은 개발자들에게 사랑받고 있는지 정리해봤습니다.  MongoDB의 구성 요소MongoDB의 구성요소는 RDBMS의 그것과 굉장히 닮아있습니다. 하나씩 살펴보겠습니다.  Collection : Collection은 RDBMS에서 테이블에 해당하는 개념으로 문서들의 집합체입니다. Collection은 스키마가 따로 존재하지 않아서 다양한 구조의 문서를 저장할 수 있습니다. Document : MongoDB의 데이터 저장 단위로 ..

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

최근에 공부를 쉬었다가 다시 시작하고 있다. 또 하고싶은 공부가 생기니까 이렇게 저렇게 하게되는게 신기하다. 공부는 3개월정도 쉬었는데 그동안 게임도 열심히 하고 공부생각 안하고 열심히 놀았던 것 같다. 오늘은 근황과 함께 현재 느끼고 있는 감정을 있는 그대로 써보려고한다.  최근 연봉협상을 진행했다. 만족스럽진 않지만 불황인 현재 상황을 보면 나름 나쁘지 않은 것 같다. 13퍼센트 연봉이 올랐는데 400만원이 올랐다. 기쁘면서도 조금 아쉽긴 하다. 내가 했던 성과들을 쭉 얘기하는데 대표가 그런건 아무나 다 할 수 있는거라면서 가스라이팅을 했다. 속으로 ㅅㅂ 그걸 아무나 할 수 있는거였으면 왜 지금까지 안했냐 라고 얘기하고 싶었지만 싸우자는 얘기로 들릴까봐 참았다.  잘했다고 한마디하고 그냥 가만히 있으..

작년 2월 14일에 취업하고 현재 회사에서 1년을 채운 뒤 오늘 연봉협상을 마쳐 본격적으로 2년차가 시작되었습니다. 회사에서 1년동안 했던 일들 회고해보도록 하겠습니다.  성능 개선회사에서는 WebRTC를 이용한 비대면 평가 시스템을 개발하고 있습니다. 제가 투입되었을 당시 오픈소스인 Openvidu를 이용해서 만들어져있었는데 Openvidu가 Kurento 미디어 서버를 기반으로 만들었기 때문에 WebRTC만 사용하는 저희 서비스 입장에선 썩 좋은 선택지는 아니었습니다.  이것도 추후에 포스팅을 하겠지만 WebRTC에 특화된 미디어 서버인 Mediasoup가 있어서 이를 이용해서 서비스를 마이그레이션 했습니다. 그러면서 기능도 추가로 개발하고 프로세스도 다듬으면서 기존 Openvidu에 비해 성능이 많..

안녕하세요, 이번 포스팅에선 스레드 풀의 존재 의의를 스레드 생성 비용의 관점에서 공부해보고 정리했습니다!  흔히 알기로 데이터베이스 커넥션, JVM의 스레드의 생성비용이 크기 때문에 커넥션 풀, 스레드 풀을 적극 사용한다고 알려져있습니다. 이런 내용의 포스팅은 많이 있지만 이 스레드의 생성 비용이 정확히 어느정도인지 알려주는 곳은 없더군요.  저와 같은 생각을 가지신 분이 "널널한 개발자" 유튜버분에게 질문을 올리시고 그에 대한 답변 영상에 영감을 얻어 공부했습니다.   운영체제가 관리하는 스레드스레드는 프로세스에 속해있는 실행 단위이죠. 보통 운영체제가 프로세스를 PID라는 것으로 관리하고 이 프로세스는 컴퓨터의 파일 (여기서 파일은 소켓이 될 수도 있고, 실제 파일이 될 수도 있고 다양합니다.) 을..

약 20일전에 "메세지 브로커의 근심과 걱정" 이라는 포스팅을 작성하였습니다.  https://coding-review.tistory.com/566 메세지 브로커의 근심과 걱정마이크로 서비스와 메세지 브로커는 뗄 수 없는 사이입니다. 서로 다른 도메인이 여러개의 서버로 나눠져 있는 상황에서 모든 서버에 동일하게 데이터를 전달해야 하는 경우에 메세지 브로커만coding-review.tistory.com 위의 포스팅에서는 데이터베이스의 트랜잭션과 메세지 브로커의 통합을 위해서 어떤 부분을 고려해야 하는지에 대한 내용이었습니다.  정상적인 상황에서는 문제 없지만 만약 예외 상황에서 트랜잭션 롤백이 되었을 때 메세지 브로커도 그에 맞춰서 메세지가 전송되지 않아야하는데 트랜잭션과 메세지 브로커를 통합하는 것은 또..

안녕하세요. 개발 블로그 작게 운영하는 폴폴입니다. 제가 쓴 회고글을 보다보니 회고다운 회고가 없네요 ㅎㅎ.. 뭔가 제 감정을 드러낸 것이 하나도 없어 좀 딱딱한 회고글들이 나온 것 같습니다.  이번엔 조금 이른 24년도 회고겸 일기처럼 편하게 써보려고합니다.  조금 쉬어도 괜찮지 않을까..?개발이라는 공부를 시작한지는 3년 반정도 되었네요. 정말 미친놈처럼 달리기만 했는데 그만큼 개발 공부가 재밌었습니다. 시간 가는 줄도 모르고 밤을 새가면서 공부할 때도 많았고 골머리 썩던 버그가 새벽에 해결됐을 땐 가족들 다 자고있는 집에서 소리없는 환호성을 지르기도 했습니다.  대학생 시절엔 평균 10시간씩 공부하고 올해 2월에 취직하고 나서 지금까지 평일엔 3~4시간 주말엔 10시간씩 공부했습니다. 쉬고싶어서 연..