꾸준함이 성장을 도모한다! 꾸준함이 성장을 도모한다!

예외처리에 대한 비용 문제를 공부하다가 기존에는 exception을 custom해서 사용했기에 성능쪽에서 괜찮겠지라는 생각했습니다. 내가 해논 예외 처리를 보니까 세분화 되어 있지도 않으며, 중복 코드도 있고 예외 비용이 낭비가 되고 있다는 것을 알게되었습니다. 아래와 같은 글을 읽으며 caching을 적용해 향상 시켜야겠다는 생각을 했습니다. stackTrace를 가지지 않도록 오버라이딩한 Exception이라면 static final로 선언하여 일종의 상수 값 형태로 예외를 캐싱하고 쓰는 것이 매번 같은 종류의 예외를 new로 생성하는 것보다 효율적입니다. https://moonsiri.tistory.com/174 기존 코드 [ GlobalExceptionHandler ] @ExceptionHandl..

개념 정리 orElse(), orElseGet() 2가지 모두 optional을 통해 NPE를 해결하는데 있어서 Null의 값이 출력될 때 default 값을 넣어주는 역할을 합니다. 차이점 public T orElse(T other) public T orElseGet(Supplier

기존에는 트레이너 프로필 조회하는 기능을 offset을 통한 페이징 처리를 하였습니다. 하지만 데이터 양이 많을때 offset 방식의 문제점은 아래와 같이 존재 하였습니다 - 맨뒤의 페이지는 모든 데이터를 조회한 후에 마지막 페이지를 조회하기 때문에 뒤로 갈수록 조회가 느려집니다. thalals님의 자료를 보면 특정 페이지의 데이터를 읽을 때와 맨 뒤의 페이지를 읽을 때 성능 차이를 알 수 있습니다. offset 방식 [ 7만건의 데이터 중 ] - 첫번째 페이지를 읽을 때 : 0.738 - 마지막 페이지를 읽을 때 : 2785.614 -> 0.984 [ 모든 데이터 조회 -> 특정 페이지 조회 ] no offset 방식 [ 7만건의 데이터 중 ] - 첫번째 페이지를 읽을 때 : 0.032 - 마지막 페이..

현재 상황 프로젝트를 진행하는 도중에 ec2 인스턴스가 다운이 되는 문제가 생겼다. 아래와 같이 AWS의 ec2 인스턴스의 모니터링 부분을 보았다 cpu의 사용량이 99% 찍은 날 ec2가 다운되는 상황을 마주했었는데, 해당 ec2 로그들을 찍어보고 해결하기 위해서 우리는 aws의 cloud watch를 사용해보기로 결정했다. EC2에 CloudWatch를 붙이는 방법 IAM 역할 설정하기 먼저 ec2에 cloudwatch에 대한 엑세스 권한 설정하기 1. AWS에서 IAM 부분으로 접속 2. 역할 > 역할 만들기 역할을 누른다음에 오른쪽 상단에 있는 역할 생성 버튼 누르기 3. 신뢰할 수 있는 엔터티 선택 4. 권한 추가 - 권한 정책 아래에 CloudWatchAgent라고 검색하면 아래에 CloudW..

기존에는 프로젝트 빌드 명령어를 아래와 같이 작성했어서 해당 관련 오류를 몰랐습니다. 해당 명령어에서 -x 는 test 를 하지않고 빌드하기에 성공은 했지만, 우리는 테스트를 제외할 수는 없었습니다. 위와 같이 작성하면 코드 변경이 적용되지 않고 기존 코드가 빌드에 성공함을 경험했습니다. 저는 jasypt를 활용해서 프로젝트를 빌드하고 있기에 아래와 같이 작성을 해줘야 test 진행 상황이 나옵니다! run: ./gradlew clean build -Pjasypt.encryptor.password=${{ secrets.JASYPT_ENCRYPTOR_PASSWORD }} 빌드 중 만난 문제 상황 1) redis connection timeout 발생 저는 main.yml 에 script 안에서 redis ..

문제 상황 현재 aws ec2와 docker등을 연결하는 중에 발생하는 에러 입니다. 여러 블로그를 구글링 했었다. 여러 시도 방법중 aws ec2 연결시 timeout도 넣어보고, https://github.com/marketplace/actions/ssh-remote-commands SSH Remote Commands - GitHub Marketplace Executing remote ssh commands github.com 위의 문서를 찾아보면서 password 대신에 key로 넣어 보고 했다. 방법은 맞았다 password 대신에 pem key를 사용하면 되는거 였는데, github setting 부분에서 나의 경우에는 pem키를 잘 못 넣었다. ---begin --- 부터 --- end ---..

문제 상황 github action까지 성공을 하고 서버에 연동이 안되길래 s3에 저장된 zip 파일을 열어서 확인하려고 했더니 zip 파일이 열리지 않았다. 처음에는 버킷의 access가 제한되어 있어서 그런가 싶어서 엑세스 권한 설정을 변경했는데, 해당 문제로는 해결이 되지 않았었다. [ zip 파일을 열어보는 방법은 버킷안으로 들어가서 속성을 보면 객체 URL 부분이 있는데 그 zip url을 열어 보면 됩니다 ] 그래서 버킷 안에 있는 권한 부분에서 버킷 정책을 봤더니 나느 비워져 있었다.. 해당 부분에 있어서 s3에 대한 delete, put, get action을 주고, 버킷 ARN ( amazon resource name )은 버킷의 속성부분에 보면 있습니다!. 이와 같이 버킷 정책을 추가해..

다른 블로그를 따라하면서 EC2, S3, Code deploy를 하는 중에 아래 사진들과 같이 action은 성공을 하는데, 계속 code deploy 배포중에 오류가 생겼다. [ action 성공 사진 ] [ code deploy 배포 실패 사진 ] 해당 배포 ID 를 들어가면 위의 에러를 블로그에서 찾아보니까 s3 연동 문제이거나 main.yml 파일이 문제라고 하는데, 저 같은 경우는 아래 사진과 같이 s3에 zip 파일도 잘생겨서 해당 문제가 아니더라고요 ㅠ 그래서 code deploy에 배포 ID를 눌러보면 아래 배포 수명 주기 이벤트 부분에서 View events를 눌러보면 좀 더 자세한 에러 사항이 나옵니다. 저같은 경우는 아래 사진과 같은 에러가 나왔어요! 위와 같은 에러는 log를 찍어봐..