Just Do IT!

캠프가 끝난 뒤 계속 이어졌던 SODA 프로젝트가 어제로 끝이 났다.캠프가 5/16에 끝났고 어제가 6/19....거의 한 달 가량을 더 진행했다.사실 중간중간 개인 일정이 좀 있었어서 캠프 때처럼 풀로 진행하진 않았지만 그래도 유의미한 성과가 있어서 다행이다. 부하 테스트 진행 테스트 환경 ec2, RDS 세팅 → 더미데이터삽입 → 스크립트 작성 → 부하테스트 → 성능 개선(쿼리최적화/튜닝, 레디스 적용, 서버 scale-out 등) → 부하테스트 → 성능 개선 (반복) 이 순서대로 부하 테스트를 진행했다.사실 나는 이렇게 부하 테스드, 성능 개선하는 경험이 이번이 처음이 많이 배웠다. 테스트 하기 위해 새로운 서버를 세팅하고, 더미 데이터도 엄청나게 많이 넣었다. 테스트 환경 세팅과 더미 ..

성능 개선 전 로그 분석최근 질문 목록 조회 (/articles/my) API 실행 시 로그를 파악하면 아래의 기능들이 있었다.인증 및 사용자 정보 조회JWT 인증 후 auth_id 기반으로 Member 조회비교적 빠름질문 목록 조회특정 member_id가 작성한 삭제되지 않은 질문을 createdAt 기준으로 3개 가져옴article, stage, project 테이블 join쿼리 자체가 크게 느리지는 않음질문 전체 개수 조회member_id가 작성한 삭제되지 않은 질문 전체 개수 조회article, stage 테이블 join쿼리 자체가 크게 느리지는 않음⇒ 쿼리 실행 시간 외 다른 부분에서 시간이 소요되고 있음을 파악할 수 있었다.그래서 각 단계 별 실행 시간을 측정하여 병목지점을 찾으려고 로그를 추..

EXPLAIN이란?실행 계획DB 서버가 어떤 쿼리를 실행할 것인가 알고 싶을 때 사용하는 명령어DB에는 옵티마이저라는 엔진이 존재하는데, 가장 효율적인 방법으로 SQL을 수행할 최적의 처리 경로를 생성해주는 DBMS의 핵심 엔진이다.옵티마이저는 개발자가 SQL문을 작성하면 바로 쿼리문을 실행하는 것이 아닌, 쿼리문을 어떻게 실행시킬지에 대한 여러 실행 계획을 세운 뒤, 예상 비용을 고려해 가장 효율이 좋은 실행 계획으로 쿼리를 실행시키는 방식으로 수행된다.EXPLAIN은 옵티마이저의 실행 계획이다. 실행 코드는 매우 간단하다EXPLAIN [EXTENDED] SELECT ... FROM ... WHERE ... 이렇게 명령어를 입력해준 다음, 실행 결과를 분석하여 성능을 최적화할 수 있다. MYSQL E..

지난 주, 5월 16일에 끝났지만 이제서야 정신을 차리고 수료 후기를 작성해본다.원래는 지난주~이번주 합쳐서 SODA 프로젝트 회고글도 작성하려고 했는데 그건 내일 해야지. 아무튼!내가 지금까지 했던 부트캠프보다 짧았지만, 체감상 두 배는 힘들었던 KERNEL 360이 끝이 났다. 생각보다 짧은 최종 프로젝트 기간 이전에 KOSTA 에서 프로젝트를 6주간 진행했었는데 그것보다 더 긴 8주였음에도 프로젝트 기간이 짧다고 느껴졌다.물론 KOSTA에서 진행했떤 프로젝트는 내가 자바, 스프링을 처음 공부하고 적용해본 프로젝트라서 돌아가는 코드를 짜기에만 급급해서 더 그렇게 느꼈을 수도 있다. 이번에는 나름대로 리팩토링도 해보고, 팀원들 간 코드 리뷰도 해보고...그리고 캠프 끝난 지금 다시 만나서 자..

https://www.s0da.co.kr/ SODAB2B 프로젝트 관리는, SODA에서www.s0da.co.kr 이제 슬슬 끝나가니 회고글에도 슬쩍 추가해보는 우리 프로젝트 링크.자잘한 오류들 및 디자인만 수정하면 발표날이 될 듯 하다. 리팩토링 기간 월요일, 화요일은 연휴 기간이라 물 흐르듯 이틀이 사라졌다.회고글에도 작성했듯이 시간이 그렇게 많이 있지는 않아서 강의 내용 그대로 리팩토링하지는 않았고 우리 프로젝트에 맞춰서 리팩토링했다. validator는 application layer에 위치하도록.provider interface는 domain layer, proivderImpl 파일은 intrastructure layer에 만들면서 repository를 직접 참조하지 않도록 했다. 이..

시간 진짜 빠르다.처음에 프로젝트 시작할때 3월이었던 것 같은데 벌써 5월이라니... 이번주는 이슈 테스트가 있어서 그 전에 기능 완성하기 위해 노력했고 드디어 기다리던 리팩토링을 시작한 주간이엇다.연휴가 껴있어서 하루 늦은 7주차 회고 시작 프로젝트 생성 추이 기능 구현 지난 회고글 에도 적혀있는데, 프로젝트 생성 추이 통계를 위헤 ProjectDailyStats 테이블을 생성했다.혼자서 구현하는 걸 고민했을 때는 스프링 배치를 적용할까, 고민이었는데 팀원들과 회의를 한 결과 별다른 이유 없이 배치를 적용하는 건 아니라는 결론을 내렸다. 그래서 혼자 적용했던 것들을 삭제하고 비동기 이벤트 처리로 변경했다. https://daydream-sy.tistory.com/399 스프링 이벤트를 활용한..

비동기 처리를 적용하는 배경 SODA 프로젝트 진행 중, 프로젝트 생성 횟수 추이를 그래프로 보여주기 위해 API를 만들어야 했었다.이 기능을 구현하기 위해 두 가지를 고민했었다.실제 DB에서 전체 조회해서 생성일에 맞춰서 카운트해서 조회하기스프링배치를 이용해 통계 테이블을 따로 생성해서 거기에 하루에 한번씩 카운트 저장하기첫 번째 방법은 너무 비효율적이라 생각만 하고 바로 지워버렸고 두번째가 적합하다고 생각했었다.왜냐면 규모가 커진다면, 하루에 프로젝트를 생성하는 횟수가 많아질 거라고 생각했고 생성할때마다 매번 통계 테이블에 저장하는 것보다는스프링 배치를 적용헤 일정한 시간에 한 번에 저장하는 게 더 나을 것이라고 생각했기 때문이다. 실제로 주말 내내 스프링 배치를 적용해서 테스트해보면서 잘 적용되는 ..

이번주도 정신없이 빙글빙글 돌아가는 일주일이였다.그냥 정신없다는 의미 = 해야할게 많다는 의미그래도 30일 이슈 테스트 전까지 얼추 기능은 완성이 될것 같아서 다행이다. 새로운 기능 구현 멘토링에서 일단 feature issue를 모두 만들어 놓고 진행하라는 조언을 들었다.어차피 나중에 가면갈수록 더 생길 수 있으니까 생각나는대로 잘게 쪼개서 이슈를 만들어놓고 작업하는 게 훨씬 편할 수 있다고.근데 그게 맞는 말이었다. 처음에는 이슈가 너무 많아서 언제 다하지, 했는데 빠르게 작업하다보니 그래도 얼추 끝났다. 그리고 월요일부터 내가 맡았던 기능은 게시글의 옵션 기능인 투표 기능. 사실 투표 기능이라고 하기엔 조금 애매한데, 카카오톡 게시판 투표하기 기능을 모티브로 구현한 기능이니까 투표라고 했..

중간 발표 끝나고 피드백들도 많이 받으면서 예상치 못한 일들이 많았던 일주일이었다.상당히 정신없는...주간이었다 ㅋㅋㅋㅋㅋ 기획을 다시 해봅시다 중간발표 이후 각 팀마다 디렉터님 면담이 예정되어있었다. 우리 팀은 매는 먼저 맞는게 낫다는 마인드로 첫번째로 고.그리고 나서 받은 피드백들로 개선하기 위해 하루를 거의 다 보냈다. 일단, 디자인 별로.누가봐도 개발자가 만든 프로젝트 같음.처음부터 끝까지 흐름을 생각해봤으면 좋겠다 등..받은 피드백들로 월요일은 순식간에 지나갔다.강의실에 있는 화이트보드로 아예 처음부터 끝까지 사용자 입장에서 어떤 디자인이 좋을지 고민해보는 등... 사실은 기획 주간에 했어야 하나, 싶지만 뭐 이미 지나간걸 어쩌겠어.걍 쿨하게 다시 프론트 디자인도 했다. 사용자 친화적..

벌서 4주차인거 실화냐고 이러다 다음달에 최종 발표 할듯.시간이 흘러 흘러 4주차...회고 시작.       프론트 배포 그동안 배포를 하지 않아서 몰랐던 사실.이제 vercel 에서는 organization 내부 repository 인 경우에는 무료로 배포할 수가 없다...!이번에 프론트 배포하려고 오랜만에 들어갔다가 알게 된 사실이다. 하기야 이해 가능하지만 무료라서 배포하려고 했는데...aws로 배포해야 하나 잠깐 고민하가 구글링해보니 개인 repository에 fork 해서 우회해서 배포하는 게 있길래 따라했다.그리고 캠프 내 다른 팀들도 그렇게 배포하길래 나도... (원래는 정정당당하게 해야 하지만 뭐...) https://daydream-sy.tistory.com/395 Vercel로 GitH..