3주차 계획 회의

♻️ 금주 리팩토링 안건

• 유의미한 결과 보고서를 작성할 수 있도록 경험을 잘 정리해보자!

ex) ~~ 부분 리팩토링 해서 가독성이 좋아졌다. (x)
ex) ~~ 부분을 이렇게 리팩토링을 했는데, ~~ 한 근거로 장기적인 유지 보수, 관리 관점에서 좋아졌다. (O) (추상적인 결과일 경우 최소한 기대 효과를 작성하기)

• 1, 2주차에 개인 일정으로 해결하지 못 했던 테스크들을 빠르게 쳐내고, 3주차에 계획해뒀던 테스크들을 함께 처리할 수 있게 빠르게 일해봅시다!

BE

WAS, NGINX, Redis, MySQL 도커 사용

• Category: 관리성 개선

• 담당자: 조민석

• 추후 작업: 빨리 끝나면 블루,그린 전략으로 무중단 배포

• 작업 내용

  • 기존
    • CI/CD를 Github Actions에서 전부 수행
    • 개발 환경 구축을 하나 하나 직접 수행
    • 프론트엔드 기능 개발 시 메인 서버에 영향 끼침
    • CI/CD 수행 중 서버 다운 발생
  • 신규
    • Docker를 사용함으로 클라우드 환경 이전을 용이하게 변경
    • 블루 그린 전략으로 무중단 배포를 수행하도록 변경
    • 각자 로컬 개발 서버를 가짐으로써 메인 서버와 개발 환경을 분리

• 해결하고자 하는 문제

  • Docker 없이 수행하기에 환경 이전의 불편함
  • 프론트엔드 개발자들의 메인 서버에 기능 테스트 하는 문제
  • 개발 서버 운영 비용의 발생 예상
  • 무중단 배포가 안 되는 상황이기에 Merge시 서버 다운 되는 문제

• 해결했을 때 이점

  • 프론트엔드 개발 시 메인 서버 영향 최소화
  • 무중단 배포로 사용자 경험 향상
  • 개발 서버 운영 필요성 X (이론상 인프라 비용 2배 감소)
  • 클라우드 환경 변경시, 개발 환경 구축 용이성 증가
  • 로컬에서 자체 서비스 동작 가능

Private Instance 사양 ↔ Public Instance 사양 변경

• Category: 보안 / 가용성 개선

• 담당자: 안성윤

• 작업 내용

  • 기존

    • Public Instance (2 Core, 4GB RAM), Private Instance (1 Core, 1GB RAM),
    • Public Instance = NGINX, 정적 파일, WAS, Redis 배치
    • Private Instance = MySQL 배치

  • 신규

    • Public Instance (1 Core, 1GB RAM), Private Instance (2 Core, 4GB RAM),
    • Public Instance = NGINX, 정적 파일 배치
    • Private Instance = WAS, MySQL, Redis 배치

• 해결하고자 하는 문제

  • Public Instance에 WAS를 두기에 보안상 문제가 될 것이라 판단
  • 1 Core, 1GB RAM에서 MySQL 속도가 빠르지 않다.
  • WAS(Public Instance)와 MySQL(Private Instance) 사이 네트워크로 데이터 통신을 하기에 느리다.

• 해결했을 때 이점

  • WAS 보안 향상
  • DB 가용성 향상
  • WAS <-> DB 통신 속도 향상

Github-Actions 환경 변수 수정

• Category: 코드 관리성 개선

• 담당자: 박무성

• 작업 내용

  • 기존 환경 변수명: HOST, USER, PASSWORD
  • 신규 환경 변수명: DB_HOST, DB_USER, DB_PASSWORD

• 해결하고자 하는 문제

  • 환경 변수명이 추상적으로 되어 있어서, 코드 리딩시 github Flow 파일을 반드시 열어봐야 이해가 되는 문제

• 해결했을 때 이점

  • 환경 변수명만으로 어떤 목적이 있는 변수인지 확인이 가능해짐으로 코드 관리 용이

feed-crawler 테스트 작성

• Category: 소프트웨어 품질 관리

• 담당자: 박무성

• 작업 내용

  • feed crawler 테스트 커버리지 향상
  • 좀 더 많은 테스트 케이스를 이용하여 feed crawler 테스트 범위를 늘릴 예정

• 해결하고자 하는 문제

  • 현재 feed crawler의 테스트 커버리지가 상당히 낮음을 확인
  • 리팩토링 할 때, feed crawler 테스트 코드가 없어서 놓치는 부분이 발생

• 해결했을 때 이점

  • 많은 테스트 범위를 커버하여 feed crawler 안정성 향상
  • 리팩토링 할 때, 안전 장치가 생기기에 리팩토링 작업 속도 향상

테스트 코드 동기적으로 변경, DB 동시성 문제 해결

• Category: 테스트 환경 안전성 개선

• 담당자: 안성윤

• 작업 내용

  • InMemory DB(이미 수행) + Redis Mock → Docker 임시 컨테이너로 변경
  • 테스트 옵션 --runInBand or max worker: 1로 설정하여 순차 수행
  • 테스트마다 DB 테이블 초기화

• 해결하고자 하는 문제

  • DB 종류에 종속적인 기능이 없을 줄 알았지만, 추후에 추가가 되어 SQLITE에서 테스트하지 못 하는 기능은 테스트를 할 수 없었음
  • InMemory DB를 사용했을 때, 테스트 파일마다 InMemory DB를 1개씩 생성했기에 메모리 사용량이 많았음

• 해결했을 때 이점

  • 검색 API 테스트 가능
  • 추후 DB 종류에 종속적인 기능이 생겨도 테스트 가능
  • 테스트시 메모리 사용량 감소

API 서버 다중 프로세스로 바꿔서 부하 분산

• Category: 가용성 테스트

• 담당자: 박무성

• 현재: 초당 170명, 1분 요청에 대해서는 버티는 상황. 200명부터 Failed가 발생

• 목표: 부하 테스트 시 최대 서버 가용성 10% 개선

• 작업 내용

  • PM2를 이용하여 프로세스 증축
  • 부하 테스트 시나리오
    1. 싱글 프로세스일 때
    2. 멀티 프로세스일 때

채팅서버 다중 프로세스 부하 분산

• Category: 가용성 테스트

• 담당자: 안성윤

• 목표: 최대 웹소켓 커넥션 개수 10% 개선

• 현재: 최대 웹소켓 커넥션 개수 250개

• 작업 내용

  • 부하 테스트 시나리오
    1. 웹소켓 커넥션 (싱글 프로세스)
    2. 웹소켓 커넥션 (다중 프로세스)

채팅 서버 분리하고 웹소켓 연결이 API에 주는 영향 확인

• Category: 효율성 + 가용성 테스트

• 담당자: 조민석

• 목표: API 응답 속도 5% 개선

• 현재: API 서버와 웹소켓 서버가 하나의 APP으로 구현

• 작업 내용

  • 채팅 서버와 웹소켓 서버 분리하기
  • 부하 테스트 시나리오
    1. API + 웹소켓 커넥션 (싱글 프로세스)
    2. API (싱글 프로세스)

불필요한 DB 액세스 횟수 줄이기

• Category: 효율성 테스트

• 담당자: ???

• 목표: 해당 API 응답속도 5% 개선

• 작업 내용

  • 코드 개선으로 DB 접속 횟수 줄이기 (ex. SELECT + INSERT -> INSERT)
  • 부하 테스트 시나리오
  1. DB 액세스 횟수 줄이기 전 시간 측정
  2. DB 액세스 횟수 줄인 후 시간 측정

FE

단위 테스트 커버리지 높이기: 소프트웨어 테스팅(코드 커버리지 메트릭)

• Category: 소프트웨어 품질 관리

• 담당자: 채준혁

• 작업 내용

  • admin 페이지 테스트 커버리지 올리기

• 해결하고자 하는 문제

  • 현재 프론트엔드 테스트 코드가 적음을 확인

• 해결했을 때 이점

  • 리팩토링시 작업을 훨씬 수월하게 가능
  • 서버가 다운 되어도 테스트 가능

E2E 테스트: 시스템 통합 테스트, 소프트웨어 아키텍처

• Category: 소프트웨어 품질 관리

• 담당자: 채준혁

• 작업 내용

  • E2E 시나리오 작성
  • 테스트 코드 작성

• 해결하고자 하는 문제

  • 현재 프론트엔드 테스트 코드가 적음을 확인

• 해결했을 때 이점

  • 리팩토링시 작업을 훨씬 수월하게 가능
  • 서버가 다운 되어도 테스트 가능

예외 처리

• Category: 소프트웨어 품질 관리

• 담당자: 정명기

• 작업 내용

  • API 요청시 네트워크 에러 처리
  • 에러처리 UI구현

• 해결하고자 하는 문제

  • API 요청 오류를 클라이언트에게 알려주지 않기에 UX적으로 불편한 부분을 확인
  • API 요청 오류로 인해 전체 서비스가 멈추는 문제 확인

• 해결했을 때 이점

  • API 요청 오류 발생 시 문제가 발생한 컴포넌트의 렌더링만 중단하여 전체 서비스의 가용성 유지
  • 재시도 버튼을 통해 오류 발생 시 데이터를 다시 요청할 수 있어 UX 개선

반응형

• Category: 소프트웨어 품질 관리

• 담당자: 정명기

• 작업 내용

  • 최신포스트 포스트 카드
  • 차트 페이지 반응형

• 해결하고자 하는 문제

  • 모바일 환경에서 웹 페이지 디자인이 부족하여 사용자 경험 저하

• 해결했을 때 이점

  • 모바일 및 다양한 화면 크기에서도 수용 가능한 서비스를 제공하여 접근성 강화
  • 접근성 강화를 통해 SEO 점수 향상, 검색 엔진 노출 가능성 증가