프로젝트14

• 

  [기술적 선택] Spring Cloud Config & Spring Cloud Bus 개요 분산 시스템인 MSA 환경에서 구동되는 각 애플리케이션 서버(Spring Boot 기준)들의 설정 정보들은 application.yml에 기본적으로 세팅하게 된다. 만약, 이러한 설정 정보들을 변경하고 서버에 적용하기 위한 가장 간단한 방법은 서버를 다운시켰다가 재가동하면 된다. 쉽게 말하면, 인텔리제이를 활용하여 프로젝트를 많이 진행할텐데 application.yml 파일을 수정했을 때 해당 설정 정보들을 적용하기 위해서 인텔리제이의 우측 상단에 위치한 재생 버튼을 클릭하여 서버를 껐다가 다시 실행하면 된다는 것이다. 스프링 개발 경험이 있다면 남 얘기가 아니기 때문에 모두 경험해봤을 것이라고 생각한다. 필자 또한 프로젝트를 진행하면서 데이터베이스의 정보들이나 로깅 레벨을 설정하는 등 애플리케이션.. 프로젝트/기술적 선택 2023. 9. 9.

• 

  [기술적 선택] Spring Cloud Netflix Eureka & Spring Cloud Gateway 개요 프로젝트를 진행하면서 아쉬웠던 점은 조금 애매한 MSA 구조였다. 마이크로 서비스마다 서로 통신하는 것이 아니라 Front에서 A 서버로 요청을 진행하고 응답 데이터 반환 후 다시 Front에서 B 서버로 요청하면서 2번의 API 통신으로 비효율적으로 진행되었다. 즉, Front에서 A 서버의 요청 후 A 서버에서 B 서버로의 직접적인 통신은 없었다는 것이다. 또한, 프로젝트를 진행하면서 Nginx를 통해 로드밸런싱을 진행하였지만, upstream을 통한 라우팅 블록이 끝이였고, 구체적으로 어떠한 마이크로 서비스들로 로드 밸런싱을 할 것인지에 대한 구체적인 설계는 진행하지 않았다. 이번 포스팅은 이전에 진행했던 프로젝트를 다시 회고하면서 어떤 기술들을 도입하면 좀 더 유연한 아키텍처로 재탄생 시킬 .. 프로젝트/기술적 선택 2023. 9. 6.

• 

  [기술적 선택] 무중단 배포 아키텍처 개념 및 Blue-Green 도입한 이유 개요 필자는 로컬 프로젝트를 4~5번 정도 진행을 해봤고 서비스 배포 프로젝트는 3번을 진행해봤다. 그 중 2번은 인프라를 직접 담당하며 CI&CD의 역할을 하였다. 첫 인프라를 담당하였을 때 EC2 서버 안에서 도커 가상화 환경의 이해와 컨테이너의 포트 연결, Nginx, Jenkins 등 여러 학습이 필요한 상태라 시간이 많이 소요되었다. 특히, 첫 인프라를 담당하였을 때 아키텍처 설계 완료 후 새로운 프로젝트가 빌드 될 때 웹 어플리케이션 서버(컨테이너)가 다운되고 새로 만들어진 프로젝트 기반의 도커 이미지를 가지고 컨테이너를 생성하게 된다. 이때 기존의 서버는 다운되고 새로운 서버가 로딩되는 그 시점에 서비스는 중단된다. 이러한 문제는 지속적인 서비스가 중단되고 사용자에게 불편함을 끼칠 수 있는 .. 프로젝트/기술적 선택 2023. 7. 24.

• 

  [기술적 선택] Top-10 인기 검색어 구현을 위한 레디스 도입 이유 필자가 진행한 프로젝트에서 Top-10 인기 검색어 서비스를 구현하기 위해서 어떠한 방식을 사용할지 고민을 했다. 사실 해당 서비스를 구현하기 위해 레디스에 대한 개념이 잡혀있지 않아서 데이터베이스에 접근을 해서 매번 카운팅 업데이트 쿼리문을 날려야 하는건가 생각을 했었다. 왜냐하면 지금까지 프로젝트를 진행하면서 여러 기술들을 사용해봤지만 메모리 기반의 분산 저장소를 직접 활용해본 경험이 없었기 때문이다. "Top-10 인기 검색어" 서비스는 개발자 커뮤니티에서 사용자가 요청한 검색 키워드를 이용해 타사용자들에게 실시간으로 인기 검색어를 시각적으로 제공해준다. 그렇다면 매번 사용자가 검색할 때마다 디스크에 접근하여 해당 키워드에 대한 카운팅 작업으로 갱신한다면 리소스 낭비가 매우 심할 것이라고 생각했다... 프로젝트/기술적 선택 2023. 7. 23.

• 

  [기술적 선택] 카프카의 도입 이유와 ELK-Stack과 결합한 시스템 설계 프로젝트를 진행하면서 서비스의 API 기능을 구현하는 것뿐만이 아니라 '성능 개선', '트래픽 처리'를 주제로 어떤 기술을 도입을 할지 고민을 하는 시점이 있었다. 그때 당시 ELK-Stack을 활용한 로그 수집과 프로젝트 전체 인프라 구축 및 Top-10 인기 검색어 서비스와 알림 서버 구현 등 필자가 맡은 역할은 모두 완료한 상태였다. 어떠한 기술을 도입할 지 고민하고 있을 때 많은 기업 공채에서 'kafka를 적용해본 경험이 있는 분' 이라는 글을 상당히 많이 봤었다. 그게 대체 뭐길래? 기업들이 찾는건지 그때 당시에는 정확히 알지 못했다. 모놀리식 아키텍처가 아닌 MSA 환경의 아키텍처 설계를 현재 수많은 기업들이 채택하고 활용하고 있다. 카프카는 MSA 구조에서 상당히 효율적으로 활용할 수 있는.. 프로젝트/기술적 선택 2023. 7. 23.

• 

  [기술적 선택] ELK-Stack 도입 이유 및 개념 협업 프로젝트를 하다보면 정해진 목표와 과제가 매일 주어지면서 각자 맡은 역할을 충실히 하는 것이 제일 중요하다. 특히나 프로젝트의 목표물을 만들기 위해 기본적인 API를 작성하고 로직을 설계하고 테스트를 하다보면 시간이 무척 빨리 지나간다. 프로젝트는 시간이 한정적이라 서비스를 만드는 것이 급급한 나머지 성능을 개선한다거나 새로운 기술에 도전하는 것은 상당히 힘든일이다. 필자는 그 시간을 쪼개고 쪼개서 새로운 기술 "ELK-Stack"을 활용한 로그 수집가로서 활동을 하게 되었다. 도입 이유 지금까지 프로젝트를 진행하면서 로그를 활용했던 경험은 단순히 데이터를 출력하기 위함이였다. 즉, 스프링 환경에서 로깅 레벨을 INFO로 설정하여 DTO의 값이 제대로 전달되었는지에 대한 확인차 체크하는 용도였던 것.. 프로젝트/기술적 선택 2023. 7. 22.

• 

  [기술적 선택] Webflux의 적용한 이유와 동작 흐름 필자는 알림 서버를 활용하기 위해 WebFlux라는 웹 프레임워크를 활용하였다. 우리가 진행한 프로젝트는 개발자 커뮤니티 서비스를 만드는 것이였고, 내부적으로 여러 서비스를 제공한다. 해당 프로젝트는 옛 싸이월드 감성으로 제작된 프로젝트였기 때문에 일촌 신청, 방명록, 댓글, 일촌 수락 등 사용자의 커뮤니티를 활성화하기 위한 서비스가 주목적이다. 따라서 다른 사용자들이 요청한, 또는 작성한 컨텐츠들과 관련된 사람들에게 알림 서비스를 제공한다. 즉, 여러 클라이언트들이 동시다발적으로 컨텐츠 요청이 들어올 경우 이를 처리하기 위해선 동기적인 방식이 아닌 새로운 방식을 고민해봐야했다. 고민 끝에 blocking 방식보다는 적은 리소스로 동시성을 다루는 non blocking 방식을 생각하게 되었고, 일반적으로.. 프로젝트/기술적 선택 2023. 7. 22.

• 

  [기술적 선택] SSE 웹 기술을 활용한 이유 (알림 기능) HTTP 프로토콜은 기본적으로 클라이언트가 요청을 보내고 서버에서 응답을 보내주면 연결을 끊어버린다. 채팅과 같은 서비스에서 계속 연결을 유지하고 응답 데이터가 지속적으로 이루어져야한다면? 서버가 전송하고 싶어도 연결이 되어있지 않기 때문에 보낼 수 없는 상황이 발생할 것이다. 그래서 이러한 문제점을 해결하기 위해 폴링, 긴 폴링, 소켓, SSE의 방식이 도입이 된 것이다. Polling 클라이언트가 주기적으로 서버에게 요청을 보내는 방식을 폴링이라고 한다. 즉, 일정시간마다 클라이언트가 서버에게 데이터가 새로 생겼는지 확인하고 새로운 데이터가 있으면 응답을 받는 것이다. 정말 단순한 방식이다. 하지만 단순한만큼 계속 요청을 한다는 점에서 리소스 낭비가 발생한다. 필자의 생각은 알림이 발생하지 않는 상황.. 프로젝트/기술적 선택 2023. 7. 22.

• 

  [기술적 선택] Elasticsearch 데이터 구조와 설계 방안 엘라스틱 서치를 활용하여 로그 수집과 게시글 키워드 검색 기능을 구축하면서 의아한 부분이 있었다. 역색인 구조인 것은 알겠지만, 어떻게 데이터가 저장이 되고 데이터 다중화는 어떤식으로 진행이 되는지, 가용성은 어떻게 되는지 등이 개념이 잡히지 않았다. 이번 포스팅에서는 Elasticsearch의 데이터 구조가 어떤식으로 잡혀있는지 살펴보려고 한다. 개념 정리 위의 그림을 보면 클러스터, 노드, 샤드, 인덱스로 구성되어 있는 것이 보인다. 하나씩 살펴보자. 1. 클러스터 노드들의 묶음이라고 보면 된다. 클러스터로 묶인 노드들은 노드간 데이터 교환을 위해 http 포트 (9200-9299), tcp 포트 (9300-9399)를 열어둔다. 그러므로 노드 1로 입력된 데이터를 노드 2에서 읽을 수도 있고, 그 .. 프로젝트/기술적 선택 2023. 7. 22.

• 

  [기술적 선택] JPA - Optimistic Lock 도입 이유 및 적용 방법 '바꾸바꾸' 프로젝트는 Voda, HelloWorld 이전에 싸피에서 진행한 공통 프로젝트이다. 해당 프로젝트에서 담당했던 역할 중에 다음과 같은 문제가 발생하였다. 바꾸바꾸 프로젝트(물건 교환 플랫폼)에서 물건 교환 신청을 요청할 때 하나의 아이템은 최대 10명의 사용자가 요청이 가능하다. 만약 하나의 아이템의 요청 상태가 7명일 때 5명의 사용자가 동시 요청을 하게 된다면, 그 중 3명의 사용자는 요청이 완료돼야하고 2명의 사용자는 요청이 취소돼야한다. 하지만 프로젝트 코드에서는 이러한 동시성 이슈 문제를 해결할 수 있는 로직이 구현되어있지않았다. 즉, 하나의 아이템에 12명의 사용자가 요청 완료가 처리된다. 왜 이러한 문제가 발생했는지, 그리고 이를 해결하기 위해 어떠한 기술을 도입했는지에 대한 회.. 프로젝트/기술적 선택 2023. 6. 6.