미리보기

[개요]

점점 늘어나는 반려인구들을 위한 sns, 유저의 펫 프로필을 통해 반려동물과 함께 소통할 수 있는 서비스를 제공

• 인원: 7명( BackEnd 4, Infra 1, FrontEnd 2)

• 팀장, Backend (알림 서비스, 알림신청(구독) 서비스, Auth(회원가입, 로그인))

• 기술 버전(BackEnd/담당 기술 버전): Java17, SpringBoot(3.2.10), MySQL(8.0.39), Redis(7.2.5), MongoDB(8.0.3)

[성과]

1. Apache Kafka를 메세지 기반 이벤트 스트리밍을 통해 분리된 18개 서비스간의 데이터 정합성 확보

*상세 설명

• 문제 상황: 서비스의 확장성 및 아키텍처의 장단점을 파악하기 위해 MSA(micro-service-architecture) 환 경을 채택하기로 결정했으나 개발환경에서 개별적인 데이터베이스 사용으로 인한 서비스 간 데이터 일관성 확보되

  지 않음

• 원인: 분리된 데이터베이스 사이에서 데이터의 일관성 유지를 위한 동기화 경험이 없음

• 분석 사항: 분리된 서비스 간 통신을 가능하도록 3가지(kafka, rabbitMQ, feign-client)의 통신 방법 비교 분

  석

• 적용 점

  • 서비스 의존도를 낮추고 분산 처리를 지원하며 실시간 전달에 강점을 가진 Apache Kafka 채택 후 연관된 서비스들에서 topic 생성하여 이벤트 브로커를 활용하는 EDA(event-driven-architecture) 구축

2. 불필요한 쿼리 실행을 방지하기 위해 Redis를 통한 동기화 + Caffeine 기반의 로컬 캐시를 결합한 이중 캐싱 전략 적용하여 조회속도 20배 향상 및 DB 통신 횟수 기존 요청 대비 최대 80% 감소

*상세 설명

• 문제 상황: kafka 기반의 이벤트 스트리밍 구조에서 값이 자주 바뀌지 않는 데이터에 대해 불필요한 쿼리 발생

• 원인: 메세지 처리 시 필요한 참조 데이터에 캐싱이 적용되지 않아 반복 조회 발생

• 분석 사항: 데이터 조회 시 db와의 네트워크 통신을 최소화하기 위해 캐싱 라이브러리 4가지 비교 분석

  (redis, memcached, caffeine, ehcache)

• 적용 점

  • 값에 대해 데이터가 추가/삭제가 필요하여 list 자료구조를 지원하는 Redis 채택

  • Spring Boot 환경에서 의존성 추가만으로 설정 및 사용이 가능한 Caffeine으로 로컬 캐싱 구성

3. 유저의 어플리케이션 상태에 맞는 알림을 제공하고자 FCM 푸시 알림과 SSE를 활용해 상황에 맞는 알림 방식(백 그라운드, 포그라운드, 종료 상황)을 제공하여 최대 6대의 다중 로그인 환경에서 서비스 내부 알림 수신

*상세 설명

• 문제 상황: 기존 FCM 알림은 푸시 알림용이라 백그라운드에서는 볼 수 있지만, 앱 사용 중에는 표시되지 않았으며 푸시 알림 발송 시 약간의 시간차 발생

• 원인: FCM은 알림 전송시 구글 서버를 거쳐가기에 약간의 시간 오차가 발생하며, 프론트엔드 측으로 알림에 대한

  세부 데이터 전송이 되지 않았음

• 분석 사항: FCM을 앱 내 알림을 위해 활용할 수 있는지와 서비스 내 알림 전송을 위한

  3가지 방안(SSE, websocket, Polling)의 특성 및 적절성 비교

• 적용 점: 특정 서버를 거치지 않으며, 클라이언트 측의 요청 없이 서버에서의 단방향 전송을 할 수 있는 SSE 채택(4개 기업에서 fcm + sse를 위 문제 해결 목적으로 사용하는 것을 확인)

4. Redis를 활용한 회원가입 우선권(예약 시스템) 부여를 통해 유저 피드백 100% 반영

*상세 설명

• 문제 상황: 회원가입을 시도하려는 A 유저가 먼저 회원가입을 진행했지만, 더 늦게 회원가입을 시도한 B유저가 같은 아이디로 더 빠른 가입을 완료하여 아쉬웠다는 피드백 제공

• 원인: 회원가입 과정 시 아이디 중복 체크를 RDB(MySql)의 가입된 유저정보와 비교하는 과정이 존재하지만 가입 시도를 먼저한 유저에 대한 우선권을 부여하는 처리는 되어있지 않았음

• 분석 사항: 비 영구적인 데이터 저장을 위해 2가지의 DB 분석(Redis, Memcached)

• 적용 점: TTL(time-to-live)기능 제공과 싱글 스레드인 redis를 채택하여 회원 가입 중 아이디에 대한 예약

  처리를 하여 동시성 문제를 보완

[아키텍처]

• 서비스들간의 독립성을 유지하고 확장성과 안정성을 위해

  MSA(마이크로서비스아키텍처)를 도입

• 데이터 통신을 위해 메세지 브로커인 Apache Kafka 의

  데이터 스트리밍을 통해 EDA(이벤트드리븐아키텍처) 구축

[역할]

• JWT 기반 로그인을 구현하여 보안 강화

• Redis의 메모리 기반, TTL을 활용한 로그인 동시성 문제 방지 및

  토큰/인증번호 등 임시 데이터를 처리

• 이벤트 체이닝 시 데이터 조회 효율성을 위한 caffeine 캐싱 처리 적용

• 서버에서 클라이언트 측으로의 단방향 통신을 위해 SSE(server sent event)를 이용한 알림 기능 구현

  • pwa(progressive web app)의 백그라운드 특성을 활용하여 FCM 을 이용한 푸시 알림 구현

  • 클라이언트 측 전송 시 발생한 직렬화 설정 문제에 대해 json 형변환을 통해 해결하여 이를 공유하여 타 인원들의 문제 재발 방지에 기여

• Google SMTP를 활용한 메일 전송 기능 개발

[인사이트]

• 서비스 간 분리로 인한 독립성과 확장성, 부하 분산을 고려한 설계의 중요성을 체감

• front-end 측과의 데이터 송수신시 직렬화/역직렬화의 중요성 파악

• 작업 및 트러블 슈팅 문서 59개를 작성하여 협업 효율성이 향상되고, 동일 문제의 재발을 방지하며 해결 시간 단축을 경험

• 로컬 환경에서는 문제가 없더라도, 배포 환경에서는 프론트엔드 설정과의 불일치나 인프라 접근 설정에 따른 예기치 못한 문제가 발생할 수 있다는 점 인지

[프로젝트 목적]

• 단순한 클론코딩의 목적이 아닌 이커머스 서비스의 이벤트 플로우를 파악하고 그 과정을 직접 구현해보며 특정 기능 을 위해 어떠한 처리를 해야하는지, 어떠한 라이브러리를 도입해야하는지 장단점을 파악하며, 개발자의 시선이 아닌 사 용자의 입장에서는 어떠한 기능이 필요한지 문제 해결의 관점을 키우기 위해 많은 유저를 보유한 인기 서비스 중 하나 인 스타벅스 온라인 스토어를 선정하여 리빌딩 진행

• 인원: 5명( BackEnd 2, Infra 1, FrontEnd 2)

• 팀장, Backend (상품 분류/장바구니/리뷰 등 상품 도메인에 관한 api 개발 )

• 기술 버전: Java17, SpringBoot(3.2.9), MySQL(8.0.39), Redis(7.2.5), QueryDSL

[성과]

1. Cursor 기반 페이징을 통한데이터 응답 속도 20배 향상 (200ms -> 20ms 데이터 5,000,000개 기준)

* 상세 설명

• 문제상황: 무한 스크롤을 구현하는도중, 기존의 적용하려던 페이지 이동 방식은 새로운 데이터 조회를 위해 일정 단위로

  유저의 특정 기능 조작이 필수적으로 요구되며 후반 데이터를 조회할수록 조회 속도가 조금씩 늦어지는 문제 발

  생

• 원인: 페이지의 마지막 상품 정보를 보고 넘김 버튼을 눌러야만 다음 데이터 조회가 되고, Offset 기반의 페이징

  처리를 적용 했기에 후반 데이터를 조회할수록 불필요한 DB 스캔이 발생하여 조회 시간이 증가

• 조사사항: 3가지의 페이징 방식 비교 후 이전 데이터의 스캔 없이 쿼리 결과가 일정한 속도인 Cursor를 채택 및 페이징 처리를 위한 조건들이 동적으로 변할 수 있기 때문에, 이를 효율적으로 처리할 수 있는 방법으로 Query

  DSL을 도입하는 것이 필요함을 인지

• 적용점

  • Cursor 기반 페이징 도입으로 일정한 속도의 데이터 조회를 가능하도록 처리

  • QueryDSL을 사용하여 동적 조건을 처리하는 쿼리 구현

2. QueryDSL 활용한 동적쿼리 처리로 유지보수성 최대 3배 향상

* 상세 설명

• 문제 상황: 하위 카테고리의 쿼리가 대해 상위 카테고리 요청 코드와 대부분 유사하게 작성되어 중복으로 인한 가독성 저하

• 원인: 하위 카테고리 조회는 상위 카테고리 조회 코드에서 하위 카테고리 조건만 추가

• 동적쿼리 처리할 수 있는 3가지 방안 조사 후 직관적이며, BooleanBuilder를 활용한 조건부 쿼리

  작성이 용이한 QueryDS 채택

3. Redis TTL을 활용한 저장 공간 효율적 관리

• 최근 본 데이터는 영구 저장이 불필요하다고 판단하여 Redis TTL로 관리, 자동 만료를 통해 저장 공간을 절약

[아키텍처]

• 타 서비스와의 연결이 용이한 장점을 가지고, 빠른 개발 진행과 버전 통일을 위해
  모놀리식 아키텍처를 사용

[역할]

• Redis 메모리 기반, 분산 환경 지원 특성을 이용하여 비회원과 회원의 최근 본 상품 관리 및
  TTL 설정을 통한 효율적인 데이터 처리 구현

• QueryDSL의 동적 쿼리 생성 기능을 활용하여 필터링 조건과 조인을 포함한 상품 검색 및
  카테고리 분류

• 데이터 저장량에 자유로운 AWS S3를 활용하여 이미지 업로드 및 처리

[인사이트]

• GitHub Issue를 통해 진행할 작업에 대해 명확히 정의하고, 팀과의 효과적인 커뮤니케이션을
  통해 필요한 기능을 구체화

• 프론트엔드와 협업하며 내가 구현한 기능이 어떻게 전달되는지 확인하고, 알맞고 낭비되지 않는
  데이터를 전달해야 한다는 중요성을 인지

• 성과

  • 자료구조 이해를 통해 웹 개발 시 API 응답 및 리스트 데이터 처리에 유연성 향상

  • 다양한 유형의 알고리즘 문제 풀이를 통해 문제 해결 전략 선택 능력 향상

• 활동 기간

  • 2024.08 ~ 2024.11

• Java 기반 웹 개발 역량 강화를 위해 알고리즘·자료구조 학습 목적의 스터디 운영 (5인 팀, 팀장)

• 성과

  • 과제를 통해 Java의 자료구조 활용 능력 향상

  • 입력 검증 및 예외 처리 로직 구현을 통해 오류 대응 능력의 중요성을 체감

• 활동 기간

  • 2023.10 ~ 2023.11

• 활동 기간

  • 2022.01 ~ 2022.06

• python 알고리즘 스터디(4인) 참여, 진행 방식 개선을 주도하여 기존보다 약 3배 많은 문제 풀이 경험 달성
  (문제 풀이 방식 -> 발표 후 질의응답 방식)

• 활동 기간

  • 2021.07 ~ 2021.08

• 언어 실력 증진을 위한 비대면 자율 학습 및 1일 1회고를 통한 추후 개선점 파악

• 방학 기간 프로그래밍 언어를 추가로 학습하며, 개발자로서 필요한 자기주도적 학습 역량을 강화