tioon's Devlog

기존의 로드밸런서만을 사용하던 프로젝트에서 docker를 이용한 무중단 배포를 적용을 해야했습니다.이때, 추가적으로 Nginx를 도입하면서 했던 생각들과 여기서 어떤 방식이 제일 효율적이며 안정적인가 고민을 하면서 도입을 했는데 이번에 이를 정리해보려 합니다. 기존 프로젝트에선 로드밸런서에 ACM과 Route53을 통해 https를 적용하고 뒷단의 서버는 ci-cd로 중단 배포가 적용되었습니다. 이를 그림으로 간단하게 보면 다음과 같습니다. AWS ELB가 앞단에 존재하고, 요청을 받게 되면 뒤에 있는 EC2로 요청을 전달하는 과정으로 통신이 진행됩니다.이때, ELB에는 Route53을 통해 기존에 저희가 사두었던 도메인이 적용되어 있으며, ACM을 통해 SSL 인증서가 적용되어 앞단의 ELB는 443포..

프로젝트 소개 👐🏻 플리빗은 세상과 SNS로 대화하는 현세대의 소통 방법을 개선하고자 하는 Q&A 플랫폼입니다.궁금증을 질문하고 답변을 통해 자신을 표현하여, 소통 과정에서 느끼는 니즈를 충족시키고 어려움을 해결합니다.  저희 프로젝트의 서비스 소개글은 아니니 이 부분은 빠르게 스킵하도록 하겠습니다!!더 자세한 내용을 보시고 싶으시면 아래 링크에 들어와주세요!https://github.com/Team-baebaehttps://www.flipit.co.kr/   프로젝트 설계 이번 프로젝트를 설계하면서 정말 많은 고민을 했습니다. 어떻게 하면 좀 더 안정적이고 확장성 있는 설계를 할 수 있는지 정말 많은 자료를 찾아보고 네이버 클라우드 공식문서도 많이 봤던거 같아요. 기본적으로 Q&A 플랫폼을 기반으로..

이번에 진행한 프로젝트에서 실시간 푸시 메세지가 꼭 필요한 기능이였습니다. 따라서 푸시메세지를 구현하기 위해 FCM을 사용했으며, 이를 사용할때 마주했던 문제들과 이를 해결했던 방법들을 공유해보고자 합니다.우선, 실시간 푸시 메세지를 구현할 수 있는 방법은 다양한데, 대표적인 기술들을 알아 보도록 하겠습니다.     실시간 푸시 메세지 구현 기술 종류WebSocket클라이언트와 서버간 지속적인 연결을 통해 양방향 통신을 할 수 있음.이 지속적인 연결을 통해 실시간 푸시메세지를 구현할 수 있음.하지만, 웹소켓 구현이 복잡하며 실시간 푸시메세지 구현을 위해 WebSocket을 쓰는게 알맞지 않음 Message Queue(Pub/Sub)Redis, Kafka 등의 메세지 큐를 통해 메세지 게시 및 구독을 할 ..

프로젝트 소개 👐🏻 플리빗은 세상과 SNS로 대화하는 현세대의 소통 방법을 개선하고자 하는 Q&A 플랫폼입니다.궁금증을 질문하고 답변을 통해 자신을 표현하여, 소통 과정에서 느끼는 니즈를 충족시키고 어려움을 해결합니다.  저희 프로젝트의 서비스 소개글은 아니니 이 부분은 빠르게 스킵하도록 하겠습니다!!더 자세한 내용을 보시고 싶으시면 아래 링크에 들어와주세요!https://github.com/Team-baebae/29th_Semi_README/tree/main/TeamC_Flipit    프로젝트 설계 이번 프로젝트를 설계하면서 정말 많은 고민을 했습니다. 어떻게 하면 좀 더 안정적이고 확장성 있는 설계를 할 수 있는지 정말 많은 자료를 찾아보고 네이버 클라우드 공식문서도 많이 봤던거 같아요. 기본적..

이번에 미니 사이드 프로젝트로, 실시간 채팅기능을 구현하게 되었는데 이 과정을 한번 정리를 해보려합니다. 우선 저희의 요구사항은 다음과 같았습니다. 사용자간의 실시간 채팅이 구현되어야함. 방이름을 기반으로 채팅방이 구분되어야함. 전에 했던 채팅 기능이 저장이 되어야함. scale-out시에 채팅기능에 문제가 생기지 않아야함. 크게 이렇게 4가지가 있었는데요. 이 요구사항을 지키기위해서 갖은 삽질과 버그가 있었습니다. 이 미니 사이드 프로젝트는 Spring, 타임리프, Redis, mongoDB로 구현되어있으며, 중간에 발생한 문제점으로 인해 Kafka로 마이그레이션을 시도했습니다만.... 시간이 부족해 실패했습니다 이과정에 대해선 아래에서 자세히 설명드리겠습니다. 일단 먼저 스프링 WebSokcet과 M..

아파치 카프카에서 Producer와 Consumer의 내부 동작원리 및 특징에 대해서 알아보도록 하겠습니다. 아파치 카프카의 전체구조 우선 카프카의 전체 구조를 다시한번 보고 가겠습니다. 카프카의 전체 구조는 다음과 같습니다. Producer에서 Key-Value 형태로 메세지를 send하면, 브로커의 한 토픽을 기준으로 key로 파티션을 나누어 브로커에 저장이 됩니다. (여기서 메세지 send를 할때, key값은 partition을 나누는 것이지, topic을 나누는것이 아닙니다!!) (key가 아니라 partition으로도 나눌 수 있습니다. 다만, Key를 활용하는 방식이 유연성이 높습니다.) 해당 브로커에선 Queue 형태로 데이터들을 저장하며, 이를 기반으로 카프카가 동작을 하게 됩니다. 이제 ..

이번장에서는 아파치 카프카 CLI 명령어를 알아보도록 하겠습니다. 직접 아파치 카프카를 도커 컨테이너로 실행하여 CLI 명령어를 실행해볼 것이며, 아파치 카프카를 실행시키기 위해 도커와 아파치 카프카 오픈소스 깃 clone 과정이 필요합니다. 도커 설치 로컬 컴퓨터에 도커를 설치해 주시면됩니다..! 이 과정은 인터넷에 너무 많으니 패스하도록 하겠습니다. 저는 윈도우용의 도커를 설치했습니다. 아파치 카프카 오픈소스 설치 이제 도커를 설치했다면, 도커 컨테이너에 올릴 아파치 카프카 오픈소스가 필요합니다. 저는 conductor라는 오픈소스를 깃으로 clone을 해와서 가져올 것이며, 링크는 아래에 있습니다. conduktor/kafka-stack-docker-compose: docker compose fil..