클론코딩주차..
포트폴리오 항목 예시)
1.SSL
2.CI/CD PIPELINE
3.백엔드 서버
4.데이터베이스
+++++보통 클론코딩 주차부터 포트폴리오에 많이들 넣으시기 때문에 관련해서 많이들 얻어 가시면 좋을 것 같아요~~
1.Trouble shooting
문제 발생원인, 원인파악, 해결과정(2~3가지), 기능을 사용한 이유,
2.Server tEST
TPS지표
성능개선지표
JPA->QueryDSL
REDIS CASHDB
이미지 첨부를 많이 해라..
WebRTC
유저사용량 모니터링.. 사용하는데 근거가 필요.
챌린지적 기술....
레디스, 웹소켓!
-+------------
인프라
1.무중단배포
2. 깃액션
3. 로드밸런서
객체지향적으로........
레디스를 깊게 파보자
java highquality
비동기가 요새 핫하다.
레스트템플릿(동기) vs 웹플럭스(비동기)
Test 빌드시 경로에 한글이 있으면 빌드가 안된다...
심화내용
jpa 락
트랜잭션 격리수준
네이티브 SQL, QueryDSL 차이
NGNIX(로드밸런서: 클라이언트 요청방향을 정해주는 아이) : 무중단배포에 사용한다!!
1대 서버로도 가능하다 + 여러대의 서버도 충분히 가능함^^
왜? JAVA jar 1, JAVA jar2로 나누어서
++ NGNIX 프록시서버다(모든 인프라구축에 필수다!!)
댓글 같이 자주변화하는 데이터는 캐시에 저장하지 말고 db에 불러온다.
그래서 레디스를 사용할때
1. 레디스가 먼지?
2. 왜 썻는지?
3. 어떤 성능개선??
4. 얼마나 성능개선??
->> 측정 툴 Jmeter
그래서 프로젝트 시작시 처음부터 레디스, 쿼리 DSL 사용하지말고
어느정도 만들었을 때 메소드쿼리 -> 쿼리DSL을 사용해서 성능개선을 이루기.
++ 레디스
findbyId 됨.
findbyNewId;; 되지 않음..
@slf4j 로그사용할때 어노테이션
프로메테우스?? -> 성능테스트를 해서 시각화..
1.Redis 연결할때 demonize yes 확인(백그라운드 열려잇는지)
2. 서버포트 0.0.0.0. (bind in) 변경
3.restart를 해야함..
https://hayden-archive.tistory.com/429
레디스 트러블 슈팅..
1. 자주변하는 값들은 캐시에 저장안함
News는 자주 안변함 >> 레디스에서 저장하고 불러옴
Comment는 자주 변함 >> 그냥 db에서 불러옴
-
레디스 CrudRepository 명령어 관련..
KEY값으로 Value를 찾을때
findbyId 됨.
findbyNewId 되지 않음.. -
권한설정 (EC2 서버)
- Redis 연결할때 demonize yes 확인(백그라운드 실행 관련)
- 서버ip포트설정 : bind in 0.0.0.0. 변경
- 레디스는 관계형 데이터 베이스가 아니기 때문에
ex) news.getmember.getusername은 되지 아니함.
그래서 레디스 엔티티에 연관관계 없이 데이터 변수를 기입..
레디스 캐싱전략
우선 읽기 전략만을 사용하였으며
<< 그림 >>
1.캐시를 우선적으로 확인한다.
2.있으면 해당 데이터를 읽어온다.
3.없다면 DB에 접근해 데이터를 가지고 온 뒤에 캐시에 저장하게 한다.( Lazy Loading)
불가피하게 작성자가 수정 및 삭제가 발생하면 레디스 캐시도 같이 삭제가 되게끔 구현..
HTTP, HTTPS 변환설정
1. 도메인에다가 aws 네임서버 기입하고 인증해야함
2. aws에 Rouest 53설정.
3. DNS 검증 기다려야함..
자바 한국시간 적용(ec2는 미국서버..라 시각이다륾)
java -Duser.timezone=GMT+9 -jar 프로그램
1조 CustomExpentionHandler 내용을 보자..
\
B.E
소프트 딜리트 / view에서만 삭제되고 서버단에서는 삭제안됨.. ( 신고 기능 )
1.잘한점
Domain안에 Dto를 잘넣었다.
(이후 DDD 를 설계하면 좋다)
2.아쉬운점
기능을 추가하면 ADD
수정하면 FIX
삭제하면 DELETE
글로벌 예외처리가 아쉽다.(제너릭을 사용)
ENUM을 대문자로 사용하자
@MappedSuperclass말고 @CreatedBy를 사용하면 좋다(연관관계를 끊을 수 있다.)
CI/CD 지속적 ( 깃헙 액션)
resttemplate동기 , springwebclient 비동기
네이티브 쿼리
Query DSL
JPQL
내가 배워야 할것들 !!
1. 예외처리
2. 테스트코드 목킹! <<<진짜 연습해야됨..-
3. 웹소켓...
from 휘림님말씀
돌아가는 쓰레기를 먼저 만들자~~
이후 수정해나가면서 개선한다 (포트폴리오에 개굳)
From 정영호 매니저님
원철님 아까 피드백 때 정리한내용을 못찾았어서 설명을 못드렸는데
레디스를 깊게 파본것같음 캐싱하려는 목적은 알겠으나, 용량이 작고 하므로 RDBMS가 무조건 안좋은것은 아니니 다음에는 간단한 키:밸류 형태만 저장할 수 있으면 좋을 것 같습니다.
레디스 관계형디비가 아니므로 모든 정보를 굳이 넣엇어야했나? 아이디같은건 굳이 저장했어야하는지 ? 하지만 이것도 경험이기에 레디스로 불러오는 응답속도랑, DB에서 불러오는 응답속도 차이를 포스트맨으로해서 따로 트러블슈팅이나 정리해두면 좋은 경험이 될듯 합니다
팀원 분들한테 나중에 공유하시면 좋을것 같네요
실전프로젝트 1주차..
내가 구현하고 싶은것! )
1.도커기반 Redis사용, 2.엘라스틱서치(Elasticsearch)
도커를 왜 사용하는지에 대해 오버엔지니어링이 되지 않도록..
오픈 api를 통해 ingredient db(재료),Recipe db(레시피)를 받아 왔지만 Data 전처리 과정이 필요하다. / 연결을 어떻게 할것인지 고민이 많음..
MySQL
해당 바이트보다 많이 들어갈때...
Error Message; Data truncation: Data too long for column
https://scshim.tistory.com/337
Github 특강
이슈를 등록해서 토의한다..
깃헙
readme.md가 중요하다..
예시)
https://github.com/siyoungoh/readme-template/tree/master/korean
여기에다가 추가적으로 +트러블슈팅, wiki작성,
마일스톤(표지석) / 이슈에 마일스톤을 붙여서..
항목들 README.md, Issue, PR(Pull Request), Project, Milestone, wiki
Issue 와 Project
https://devlog-wjdrbs96.tistory.com/227
wiki
https://velog.io/@movie/Github-Github-Wiki-%EC%93%B0%EA%B8%B0
Issue를 먼저 작성하고 PR을 한다..(안하면 노크안하고 문들어가는 느낌...)
GIT FLOW, GITHUB FLOW
ex)실전프로젝트 진행하면서 항해 특성상 긴급회의가 더 빨라서 issue 기능을 쓸 생각을 못했는데 최대한
사용해보면서 진행해보는게 좋을까요
-> 이슈와 pr을 관리하는 것에 대해 기록을 남겨야된다.
처음에 할때는
커밋에 이슈내용# 넣어서 해보자..
이후 이슈를 정리함..
PR단위로 이슈를적기도??
가장 중요한것은 통일성!!
Error : No EntityManager with actual transaction available for current thread
-> delete 하는 메소드에 @Transactional 어노테이션을 붙여줘야 한다고 한다.
D-day 구하기
Local Datetime 구하기..
LocalDate now = LocalDate.now();
Date outDay = new SimpleDateFormat("yyyy-MM-dd").parse(myIngredient.getExpDate());
Date nowDay = new SimpleDateFormat("yyyy-MM-dd").parse(nowString);
Long diffSec= (outDay.getTime()-nowDay.getTime())/1000; //밀리초로 나와서 1000을 나눠야지 초 차이로됨
Long diffDays = diffSec / (246060); // 일자수 차이
예외처리 시 응답 .. _
@RestControllerAdvice
CustomExceptionHandler에서 .......
-
(Query DSL 동적쿼리..) -> 김영한 인프런 강의
-
레디스(선택하는이유)
Redis vs Memcached -
도커를 사용하는이유
재료 및 레시피를 캐시서버에서 관리하면 좋을거같은데..아닌가?
통계시간합의
UTC VS ISO
도커.....
서버를 1대로 사용하는 것이 아니라 서버부하때문에 여러 서버를 운용해야함...
그러면 각각의 서버환경을 구성하는 어려움이 있음..
즉! 원하는 프로그램을 실행하는게 어렵다!!(서버운영의 복잡도가 증가)
그래서 도커가 어떻게 문제를 해결했는가??
각서버에 필요한 application들을 Docker image에 담아둔다.
해결해야하는 문제 1. 이미지 생성, 2. 이미지 공유, 3. 이미지 실행.
*도커의 구성요소
IMAGE : application 실행에 필요한 모든것
Container : Image를 실행한 것. 독립성,
Registry : Image를 등록하고 다운받음.
Docker daemon : Dockjer object를 관리하는 주체.
Git Rebase
1. Synk
2. 풀리퀘 날리기전에 dev에 Rebase를 해서.. 풀리퀘스트 보내기..
- 레시피 상세보기를 눌렀을때만 재료의 g가 표시되게끔 하면 좋겟다!
- 레시피에 들어가는 재료를 최대 3개까지만 디스플레이.. / 3개만 주면됨...
- 조리방법이랑, 음식종류에 따라 나누기. -> 프론트 일정봐야함..
- 이미지 리사이징 문제.. ( 이미지 따라 비율이 다르고, 화질도 다르다..)
- 레시피에서 재료이름과 재료량을 뽑는 파싱(ex 25g, 1마리)
-> 정규표현식 java regex 사용.. - 월요일 7시 통계창 주심.. / 저녁 9시에 마무리/ 이후 디자인 나오는대로 붙이기..
1.레시피 전체조회를 api를 2개 만듦.
조리방법분류, 음식에 대한 분류
2. 데이터 파싱, 레시피내에서 재료내용만 뽑는거랑, 재료함량만뽑기
이번주의 목표 ! 해당 API의 연결이후 성능개선을 위해 캐시 및 DB효율 개선해야함.
