Overivew

• 최종프로젝트 doguin의 중간 발표 회고록입니다

PPT

• https://drive.google.com/file/d/1Ae9dgA13veLjcw_Ub7DQiIeKwiC4hYxP/view?usp=sharing

튜터님 피드백

방선희 튜터님

• 고민이 많았던 만큼 흔적이 기록으로 잘 남아서 발표 좋았음.
• 특히 트러블 슈팅 과정에서 잘 해결해나간 흔적들이 인상 깊었음.
• 레디스를 활용한 조회수 문제 해결한 부분에서 레디스가 캐시로서에 장점은 있지만 수정이 잦은 데이터로써 저장소는 적합하지 않은 특성을 가지고 있는데, 그럼에도 레디스를 먼저 1차적인 저장소로 사용한 이유.

김수정 튜터님

• 기술적 의사 결정에서 캐싱으로 레디스를 사용한 이유에 대해 대중성을 얘기 해주셨는데, 사실은 아무래도 포트폴리오라는 점에서 대중성을 이유로 선택한게 아닌가 싶음. 의사 결정을 할 때 다른 기업에서 사용하고 있기 때문에, 본인의 프로젝트에 도메인이라던지 기술이 어떤식으로 로직이 있는지랑은 상관없이 대중성이 첫번째 이유인 것은 부적절 한 것 같음. 순서를 바꾸던지 하는게 좋을 것 같음
• 트러블 슈팅에서 s3 비동기 파일 첨부 관련해서는 수치가 있었는데, 캐싱을 사용했을 때 줄어든 테스트 결과가 있는지.

현석훈 튜터님

• 이후 개선해야 할 점에 나온 내용에서 프라이빗 서브넷과 퍼블릭 서브넷을 구분한다고 했는데, 어플리케이션 서버를 퍼블릭 서브맷에 넣는다고 되어 있는데 이 부분이 다른 몇가지 서비스를 이용하면 어플리케이션 서버도 프라이빗 안으로도 충분히 넣을 수 잇을 것 같은데 추가적으로 고민해본 내용은 없는지, 다른 서비스를 찾아본 것은 있는지.
• 지금은 단일 서버 형태로만 구성하겠다는 계획이라서 로드 밸런서를 크게 중점으로 생각하지 않은 것 같은데, 나중에 라우트 내에서 로드 밸런서로 직접 보낼 수 있는 형태로 구성. 도메인을 구매하고 나면 라우트 53에서 로드 밸런서 키를 받아와서 입력을 해주면 로드 밸런서를 앞에 마치 웹 서버처럼 두고 로드 밸런서에서 프라이빗 안에 들어가 있는 앱 서비스를 타겟으로 잡아서 처리를 해주면 보안성이 높을 듯.

나의 회고

1. Redis를 사용할떄의 장점으로 InMemory,클러스,분산서버 캐싱 특징이 공통되는 3가지 캐싱 도구인
   Redis,Apache ignite, Memcached가 있었지만 우리는 대중성이라는 이유로 Redis를 채택하였지만
   이는 타당한 이유가 아니라는 점을 듣고 회고 하게 되었습니다

2. 성능 개선에 대한 이미지가 더 있었으면 좋았겠다라는 생각이 들었습니다

3. 일반 퍼블릭 서브넷 연결되는것이 아닌, private 서브넷 위치에 두고, 로드밸런서로 연결시키는 과정을 생각해보아도 좋을것같습니다

앞으로 해야 할 일

• 공통사항
  • 서버 늘리기 ?
• 개인별
  • 유태이
    • 프론트 (Thymeleaf)
    • 몽고 DB, Redis 어떤식으로 적용시킬지?
  • 김경민
    • ELB + 오토스케일링 적용하기
    • Redis 이중화 (Master - Slave)
    • 아키텍처 끝장나는거 그려오기
    • CI/CD 빌드 시간 단축 (멀티 스테이지 빌드)
    • CI/CD 무중단 배포로 변환 (롤링?, 그린/블루?)
  • 김창민
    • DB 이중화 [Mysql](Master - Slave)
    • 성능 체크 도구 배우고 인덱스/캐시 방식 정확하게 적용하기
    • 비동기 @Async 적용 이외에 방법에 대해 추가적인 최적화 방안을 고려
    • java stream paralled 방식 알아보기
  • 최욱연
    • 채팅기능 프론트 구현해보기
    • 서버를 이용할때 발생할 시나리오 생각해서 비동기 적용하기
    • 토론 검색 시 쿼리 인덱싱

끝!