전체 글

인스타나 스레드를 하다보면, 어느순간 팔로워수가 줄어들면 기분이 나쁘지 않나요? 분명 맞팔이였던 상대가 나몰래 언팔로우를 하는걸 알때 배신감도 들고 짜증나기도 하죠. 만약 인스타 팔로잉수가 많다면 한명한명 찾고 언팔하려면 최소 몇시간에서 며칠동안 손수 작업해야 했습니다. 그렇다고 해서 인스타 언팔 확인앱이나 로그인 정보를 요구하는 사이트 들은 "절대" 사용해서는 안됩니다. 해커들의 가장 손쉬운 먹잇감이 되기 때문이죠. 그래서, 이번 포스팅에서 별도의 로그인필요 없이 크롬 확장 프로그램으로 100% 로컬에서 인스타 언팔을 확인하고 자동으로 정리해주는 프로그램을 소개드릴까 합니다. 크롬 확장 프로그램 스토어 설치 크롬 확장 프로그램 스토어에서 Instagram/Threads Safe Auto Unfo..

일반적으로 데이터를 주고받는 상황에서 Socket 은 클라이언트와 서버가 한번 연결해놓고 데이터를 전달받기 때문에 대규모 트래픽이 발생하는 상황에서 Polling 방식보다 유리하다고 알고 있습니다. 하지만 이 명제가 항상 옳지는 않습니다. 대규모 트래픽에 대해서는 Socket 보다는 Polling 방식이 더 안정적일 수 있는데, 그 이유에 대해 먼저 알아봅시다. 🎯 Socket의 내재된 위험성짧은 Polling 주기에 대해 가장 많이 걱정하는 부분이 바로 서버에 대한 과부하 입니다. 물론 맞는말입니다. Polling 주기를 짧게 설정해두고 실시간 데이터를 받는것보다는 SSE 또는 소켓으로 연결하는게 더 효율적이죠. 하지만, 100만명의 사용자가 있는 서비스는 100만명 모두의 소켓 연결을 유지해야 ..

🎯 ELB(Elastic Load Balancer) 란 ?트래픽을 여러 대상에 자동으로 분산시켜 안정적인 서버 운용을 도와주는 서비스 입니다. ELB 는 서로다른 EC2 인스턴스에 대한 하나의 엔드 포인트를 제공합니다. 그래서 사용자는 실제 요청이 처리되는 백엔드 인스턴스에 대한 고려 없이, 동일한 엔드포인트로 요청을 전송할 수 있다. 뿐만 아니라 부하 분산에 대한 헬스 체크, 고정 세션, SSL Offload, 헬스 체크를 통한 다운서버 제외등이 가능합니다. 로드 밸런싱은 크게 두가지 기능을 제공합니다. 부하 분산 처리와 엔드포인트 역할을 제공합니다. 각각 무엇을 의미하는지 알아봅시다. 부하 분산 처리 부하 분산이란 네트워크 기술의 일종으로 여러개의 중앙 처리 장치 또는 저장 장치와 같은 컴퓨터 자..

그동안 프로젝트를 진행하면서 가장 어렵고 다가가기 두려웠던게 바로 AWS 였습니다. 인프라쪽 작업을 할때면 블로그를 참고해 시키는것만 따라했지 보안그룹, VPC, 라우팅 테이블.. 어렵고 복잡한 개념으로 다가와 이번기회에 AWS 네트워크 설계부터 다양한 기능들을 이용해보려 합니다. AWS 네트워크 아키텍처 VPC 먼저, VPC 입니다. VPC 는 AWS 안에 만드는 독립적인 가상 네트워크 공간 입니다. VPC 는 다른 AWS 사용자의 리소스와 완전히 분리하고 IP 대역, 라우팅, 보안등을 직접 설계가 가능합니다. 뿐만 아니라 RDS, EC2 등을 만들때 반드시 필요합니다. 이때 인터넷 게이트 웨이(IGW) 를 VPC 에 연결해줘야 정상적으로 인터넷 -> VPC 또는 VPC -> 인터넷 으로 접속이 가..

외주 작업을 진행하면서 항상 가장 중요시 여겼던 원칙중 하나는 생산성과 개발 속도 였습니다. 이 방법이 틀렸다고 생각하진 않습니다. 빠르게 개발하고 사용자 반응을 살피고 추후 필요한 기능을 덧붙이는 방법은 ROI 를 높인다 생각합니다. 하지만, 빠르게 시스템 규모가 커지고 정합성과 일관성을 고려해야 하는 상황은 점차 다가올거고 확장성을 고려한 시스템 설계도 어느정도 필요하다 생각했습니다. 그래서 이번 외주 프로젝트를 진행할때는 이벤트 기반 아키텍처의 뼈대를 만들고 확장성 있는 구조로 설계해봤고, 그 과정에서 배운 내용과 적용한 사례들에 대해 정리해볼까 합니다. (오버 엔지니어링이긴 한데.. 학습 목적으로 설계 해봤습니다) 이벤트 기반 아키텍처란 ?이벤트 기반 아키텍처를 설계하기 앞서 개념에 대해 간단히 ..

Outbox 패턴이란?DB 트랜잭션과 이벤트 발행(메시지 전송)을 하나의 일관된 흐름으로 보장하기 위한 시스템 설계 패턴 입니다. 메시징 시스템에서 DB update 와 메시지 발행은 일반적으로 원자성을 보장할 수 없습니다. 왜냐하면 메시지 발행은 DB 관련 작업이 아니기 때문에 하나의 DB 트랜잭션으로 묶을 수 없습니다. Message Event 를 발행하고, 수행하는 이벤트 아키텍처에서는 DB 업데이트와 메시지 발행이 불일치 하는 상황이 발생할 수 있습니다. 예를들어 결제 기능을 만들때 결제 정보에 대한 상태를 변경(DB Update) 하는 기능과 알림을 전송하는 기능을 만들어야 한다 생각해봅시다. 메시징 시스템을 이용해 구현한다면, 결제 상태는 변경됐지만 결제 완료 이벤트가 발행되지 않아 알림이..

🎯 이벤트 기반 아키텍처에 대해 알아보자프로그래밍에서 이벤트란, 애플리케이션 내에서 발생할 수 있는 사건입니다. 애플리케이션에는 어떠한 이벤트를 발생시키는 주체와, 정해진 이벤트의 발생을 탐지해 동작을 처리하는 주체가 필요합니다. 그렇다면 언제 이벤트를 발생시킬까? 만약 어떤 데이터를 저장하고 사용자에게 알림 보내는 기능을 만드는 과정을 생각해봅시다. 즉, 어떠한 동작(데이터 저장) 과는 별개로 추가적으로 수행해야 하는 외적인 동작(알림 보내기) 을 처리할때 유용하게 사용할 수 있습니다. 게시글을 저장하고 알림을 보내는 기능@Service@RequiredArgsConstructorpublic class PostService { private final PostRepository postRepo..

🎯 Spring MVC -> Spring WebFlux 로 입장 대기 기능 이전 티켓팅 서비스를 만들면서 발생한 문제는 Spring MVC 의 자원적 한계입니다. Spring MVC 에서 tomcat 은 사용자의 요청을 하나의 스레드가 완전히 처리하고 관리합니다. 하지만 이런 톰켓 스레드 개수를 조절하고, CPU 를 아무리 좋은걸 사용한다해도 수십, 수만건의 요청을 한번에 부담하기에 한계가 명확했습니다. 그래서 Spring WebFlux 도입을 결정했습니다. Spring MVC 와 달리 Spring WebFlux 는 사용자 요청을 논 블로킹 으로 처리해, 요청이 많아져도 서버의 리소스를 효율적으로 활용할 수 있습니다. 내부적으로 Netty 같은 논 블로킹 서버를 사용하며, 요청 하나당 스레드를 점유하는..