땍땍 블로그

이번 사이드 프로젝트에서는 한정된 리소스 환경에서 서비스를 운영하며 발생한 성능 저하 문제와, 이를 해결하기 위해 로컬 캐시(Local Cache)를 도입한 과정을 정리한다.1. 배경 및 문제점현재 프로젝트는 0.5GB 메모리를 가진 서버 2대(Spring Boot 1대, DB 1대)만을 활용해 운영해야 하는 상황이었다.이러한 제약은 Spring Boot와 DB 모두에 상당한 부담을 주었고, 특정 데이터를 조회하고 가공하는 과정에서 초 단위의 지연 시간이 발생하는 것을 확인할 수 있었다.원인을 분석한 결과, 이는 쿼리 자체의 비효율성보다는 순수 DB에 접근하는 I/O 과정에서의 오버헤드가 가장 큰 문제인 것으로 확인되었다. 때문에 DB 접근 자체를 최소화하거나, 아예 DB를 사용하지 않고 최적화할 수 있..

경량화 K8s실무에서 Kubernetes(K8S) 도입에 앞서, 개인적으로 필요한 부분들을 먼저 학습하고 활용해두면 좋을 것다는 생각이 들었다.하지만, K8S 는 기본적으로 클러스터 환경을 전제로 설계된 만큼 제대로 테스트 하려면 여러 대의 서버가 필요했지만 개인 학습 환경에서는 온전한 K8S 를 구동하기에는 리소스가 너무 무거워 테스트 하기 버거운 문제가 발생하였다.그래서 경량화 K8S 로 눈을 돌렸고, 아래와 같은 대안들을 찾게 되었다.Minikube: 가장 대중적이고 레퍼런스가 많아 학습용으로 좋지만, VM/컨테이너 구조상 다른 경량화 툴에 비해 무거움.K3s: IoT/Edge를 위해 극한으로 경량화되어 가볍지만, 내부 구조(SQLite 등)가 표준과 달라 설정이 까다로울 수 있음.Microk8s:..

1. 기존 아키텍처 및 프로세스현재 서버는 메인 서버와 수집 서버로 분리 되어, 메인 서버에서 특정 유저에 대한 정보가 필요할 때, 수집 서버에서 필요한 정보를 조합해 메인 서버로 요청을 보내는 구조를 가지고 있다. 이때 요청 방식은 크게 HTTP 요청과 메세지 큐(Message Queue)를 통한 발행 두 가지로 뉘었고, 식별 및 로깅 처리를 위해 메인 서버와 수집 서버 모두 어떤 사용자에 대한 요청인지 요청에 포함된 인증 정보를 파악하고 처리해야만 했다. 2. 문제점기존에 HTTP 요청만 존재했을 때는 Filter 단에서 인증 정보를 추출하여 검증하면 간단히 해결되었다. 하지만 메세지 큐를 통해 들어오는 요청은 Filter를 거치지 않기 때문에, 동일한 로직으로는 유저 정보를 추출할 수 없는 문제가 ..

이번 프로젝트에서는 명확한 API 정의서나 가이드 조차 없는, 제약 사항이 많은 외부 API 를 활용하며 발생했던 동시성 이슈, DB 커넥션 고갈 문제, 그리고 이를 해결하기 위한 RabbitMQ → SQS 로 리펙토링 과정을 정리한다.1. 기존 아키텍처 및 프로세스시스템의 기본 구조는 메인 서버와 수집 서버가 메시지 큐를 사이에 두고 통신하는 형태다.[Architecture Flow]메인 서버는 수집에 필요한 정보를 담아 메시지를 발행한다.수집 서버는 해당 메시지를 수신하여 외부 API를 호출해 정보를 조회한다.조회 결과를 저장하고, 그 결과를 다시 메시지로 발행해 메인 서버에 반환한다.2. 문제점서비스를 운영하며 외부 API의 특성과 트래픽 증가로 인해 다음과 같은 문제들이 발생 하였다.2.1. 동시..

정의테이블, 행, 열의 정보를 구조화하는 관계형 데이터베이스와 다른 별도의 구조가 존재하지 않아 Key-Value 로 데이터를 저장하는 데이터베이스 유형왜 사용하는 걸까?RDB를 활용해 주문 시스템을 개발한다고 가정해보자.이를 위해서는 우선적으로 ERD 설계가 필요하다.매장 정보회원 정보주문 정보결제 정보등 요구 사항에 어떤 값이 필요한지 사전에 파악해 맞춰 테이블을 설계해야만 한다.그리고 이러한 테이블에 데이터를 저장하기 위해서는 하나의 요청을 각 테이블의 형식에 맞춰 쪼개는 과정이 필요하고, 최종적으로 주문을 완료해 영수증을 발급해야 할 때는 이러한 관련 테이블에 모두 접근해 데이터를 가져오는 과정이 필요하다.위와 같은 과정은 RDB 를 사용해 개발하기 위해서는 필수적인 과정이기에 불편함을 느낀적은 ..

Docker 란?컨테이너를 활용해 동일한 운영체제 위에서도 각 컨테이너 별 독립적인 환경을 제공하며, 어떤 환경에서나 동일한 서비스를 실행하고 배포할 수 있도록 도와주는 플랫폼어떻게?도커 이미지 내에 서비스 구동에 필요한 소스 코드, 라이브러리, 환경 설정, 디펜던시 등을 모두 저장하고 이를 활용하기에 어떠한 환경에서도 동일한 서비스를 제공하고,이를 도커 컨테이너를 활용하여 독립적인 환경을 제공할 수 있음.즉, 도커 이미지는 서비스 실행을 위한 파일, 도커 컨테이너는 도커 이미지를 기반으로 독립된 환경으로 실행 시켜주는 역할 VM 과 차이는 ? VM 는 운영체제 위에서, 컨테이너는 운영체제를 포함하지 않고 도커 엔진 위에서 작동→ 때문에 VM과 비교했을 때 가벼움또한, 도커 엔진의 컨테이너는 호스트 OS..

이전 Docker Swarm 을 활용함에 있어 불가피하게 서로 다른 EC2 간 통신이 필요하게 되었다.당시에는 빠른 구성을 위해 서로 간 Public IP 를 통해 통신을 하도록 하였으나 이는 불필요한 통신 비용과, 보안적 이슈가 발생할 수 있기에 VPC 구성을 통해 동일한 네트워크에서 내부적으로 통신을 하도록 구성하고자 한다.우선, VPC 메뉴에 진입해 VPC 생성 버튼을 누른다 원래는 해당 페이지에서 VPC 구성에 필요한 가용영역, 서브넷 등을 한 번에 구성할 수도 있지만, 이번 글에서는 별도로 설정하고자 하기에 생성할 리소스는 VPC 만을 선택하고 넘어가준다.이후, IPv4 CIDR 을 지정해주면 되는데 이는 쉽게 말해 사용할 네트워크의 대역대이다.보통 이러한 대역대는 실제 인터넷 트래픽과 충돌하지..

운영 서버를 구축하던 중, 다중 서버를 구동해야만 하는 상황이 발생하엿다.기존 모놀리식 서비스를 분리해 MSA 형태로 변경하면서 기존 부담이 컸던 특정 서버만 다중 서버로 구동해야 하는 상황이 되었다.이러한 다중 서버를 별도로 관리하는 것이 불가능할 정도는 아니었지만 이후 확장성과 효율성을 고려해 오케스트레이션 툴을 사용하기로 하였다.하지만, 당장 감당하지 못 할 정도의 서버를 구동하는 것도 아니며 서버의 자원이 여유로운 것도 아니었기에 Kubernetes 를 활용하지 않고 Docker Swarm 을 도입하기로 결정하였다. Docker Swarm 을 활용하기 위해서는, 모든 서버에 아래와 같은 포트를 허용해주어야만 한다.2377 : 클러스터 매니지먼트 활용7946 : 노드 간 통신4789 : 오버레이 네..

객체 지향 SOLID 원칙 (객체 지향 5원칙)SRP (단일 책임 원칙)하나의 클래스는 하나의 책임만 가져야 한다.OCP (개방-폐쇄 원칙)확장에는 열려 있고, 수정에는 닫혀 있어야 한다.LSP (리스코프 치환 원칙)상위 타입 객체를 하위 타입 객체로 대체해도 정상 동작해야 한다.ISP (인터페이스 분리 원칙)클라이언트는 필요한 메서드만 의존해야 한다.DIP (의존 역전 원칙)클래스는 상위(추상) 요소에 의존해야 한다. 객체 지향 특징추상화 : 공통적인 특성을 묶어 표현상속 : 부모의 기능을 자식 클래스가 활용다형성 : 동일한 메서드를 다양한 방식으로 구현캡슐화 : 상태와 행동을 묶고, 외부에서 직접 접근 제한 Spring Framework 특징DI (Dependency Injection, 의존성 주입)..

📕 코루틴(Coroutine)코루틴은 비동기 프로그래밍과 동시성(concurrency) 처리를 지원하는 프로그래밍 구조로,함수 실행을 일시 중단(suspend) 했다가 필요할 때 재개(resume) 할 수 있다. 🔍 스레드(Thread) vs 코루틴(Coroutine)구분 스레드(Thread) 코루틴(Coroutine)관계OS가 관리하는 실행 단위스레드 위에서 동작하는 더 작은 실행 단위생성/관리 비용무겁고 비용이 큼 (스택, OS 자원 필요)가볍고 저렴 (메모리 오버헤드 적음)Context Switching커널 모드 전환이 필요해 오버헤드 발생Continuation 객체로 관리, 오버헤드 최소화병행성/병렬성CPU 코어 수에 따라 실제 병렬 실행 가능단일 스레드에서도 병행 실행 가능 (협력적 실행)..