일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- GoogleCloudStorage
- gitActions
- github
- mono
- Algorithm
- 백업
- TaskExecutor
- 스왑메모리
- R2DBC
- JPA
- EC2
- ci/cd
- actions
- CompletableFuture
- programmers
- Java
- 파일업로드
- webflux
- mysql
- 백준
- 비동기
- GCS
- AWS
- Infra
- 백업스크립트
- @async
- 알고리즘
- swapmemory
- SUbmodule
- 프로그래머스
- Today
- Total
목록전체 글 (18)
쿵야지식떨이
자동 백업을 하기 위해서 매시간마다 백업 파일을 생성해 놓을 것이다.이번 글에서는 mysql 백업 파일 생성 스크립트와 crontab 작성을 해보려 한다. 🧐 mysql 백업 파일 생성 스크립트 작성❗저는 모든 과정을 'sudo su -'로 root 권한을 얻은 상태에서 진행하였습니다. 1. 백업 파일을 저장할 원하는 디렉터리 생성mkdir -p /var/backups/mysql 2. 디렉토리 권한 설정chmod 700 /var/backups/mysql여기서 700은 권한을 의미한다.디렉터리의 권한은 3자리의 숫자로 표현되며 각 자리는 소유자인 user, group, 다른 사용자(other)에 대한 권한을 나타낸다.각 숫자는 읽기, 쓰기, 실행 권한을 의미하며 각각의 권한들은 아래의 숫자와 같이 조..
나는 현재 게임 프로젝트의 서버를 담당 하고 있다. 게임 서버의 특성 상 항상 안정적으로 서버가 잘 돌아가야 하는데 어느샌가 부터 서버에 함께 올려둔 mysql이 주에 2~3회씩 Exited되는 상황이 벌어졌다... 즉각적인 해결을 위해 나는 자동 복구와 자동 백업 스크립트를 사용하기로 했다! 이번 글에서는 문제 상황과 원인을 정리해보려 한다.🧐문제 상황은?MySQL 서버가 주 평균 2~3회 잦은 중단 및 서비스 불가 상태MySQL 서버가 다운될 시 수동 복구로 인해 평균 30분의 긴 다운 타임 발생 → 서비스 가용성 저하 백업 및 복구 절차가 자동화되지 않아 중단 시 데이터 손실 위험 증가서버 다운 시 담당자가 알 수 없음위 상황들이 큰 문제였다. 🧐원인 분석은?1. 메모리 누수 및 프로세스 충돌..
팀 프로젝트에서 server를 담당하여 하나의 ec2에 프로젝트와 mysql을 올려 두었다.요즘 테스트를 진행할 때마다 갑자기 mysql이 내려간다던가, 강제 종료되는 상황이 자주 생겨서 원인을 알아보던 중 메모리 부족이라는 결론이 나왔다. 메모리 부족을 해결하기 위해 선택한 방법은 Swap Memory를 사용하기로 했다! 🧐나의 상황은?현재 사용 중인 ec2는 t3.small이고 t3.small은 2GiB(약 2GB)의 메모리를 사용할 수 있다. 사용 중인 ec2에 접속하여 free -h를 입력하면 현재 사용 중인 메모리 현황을 볼 수 있다. free -h total used free shared buff/cache availableM..
이번 글에서는 실제 프로젝트에 만든 GCS 프로젝트와 키를 사용하여 적용해 볼 것이다. 저번 글에서 만들었던 프로젝트와 키는 테스트용으로 만든 것이라 프로젝트에 적용된 것과 이름이 약간 다를 수 있다..!1. 프로젝트 설정 1. build.gradle// google cloud storage implementation group: 'com.google.cloud', name: 'spring-cloud-gcp-starter', version: '5.1.2' implementation group: 'com.google.cloud', name: 'spring-cloud-gcp-storage', version: '5.1.2'먼저 gcs 관련 코드를 작성하기 위해 gcs 의존성을 추가해줘야 한다. 현재 ..
이번 글에서는 Google Cloud Storage를 사용하기 위해 프로젝트, 버킷, IAM 계정, JSON 키 파일을 생성해 볼 것이다. 1. 프로젝트 생성 Google Cloud에 접속한다. (https://cloud.google.com/?hl=ko) 클라우드 컴퓨팅 서비스 | Google Cloud 데이터 관리, 하이브리드 및 멀티 클라우드, AI와 머신러닝 등 Google의 클라우드 컴퓨팅 서비스로 비즈니스 당면 과제를 해결하세요. cloud.google.com 'Console로 이동'을 클릭 후 아래의 이미지 순대로 클릭하여 프로젝트 생성을 시작한다. 프로젝트 이름을 입력 후 만들기를 클릭한다. 잠시 기다린 후 프로젝트 선택을 다시 눌러보면 아래와 같이 생성된 것을 확인할 수 있다. 방금 생성한..
팀 프로젝트를 진행하면서 비동기 처리를 하다가 기능 추가로 인해 파일 업로드 기능을 구현해야 해서 GCS 적용 글로 급하게 넘어오게 되었다^^..(실제 코드로 비동기 적용 글은 파일 업로드 기능이 끝나고 다시 올릴 거 같다!) 이미 서버는 EC2로 배포가 되어있는 상태라서 처음에는 AWS S3를 활용해서 파일 업로드를 구현하려 했지만 AWS 계정을 전에 다니던 아카데미의 공유 계정을 사용하고 있었기 때문에 제약 사항으로 걸린 부분이 너무 많아서 S3로는 진행할 수 없게 되었다. 여러 가지 방법을 찾아보던 도중 GCS라는 것을 알게 되었고 다양한 방법 중 현재 프로젝트에 적용하기에는 가장 좋은 방법이라 생각이 들어서 GCS(Google Cloud Storage)를 사용하기로 했다. 이번 글에서는 S3 적..
이전 글에서 정리한 것처럼 비동기 처리를 할 수 있는 방법은 다양하다. 이번 글에서는 내가 진행하고 있는 프로젝트에 어떤 비동기 처리 기법을 적용할 것인지, 이유는 무엇인지 정리해보려 한다. 고민했던 두 가지는 @Async와 WebFlux의 Mono였고 최종적으로 선택한 것은 @Async이다. 둘의 공통점과 차이점, 현재 진행하고 있는 프로젝트에 더 적합한 것을 선택하여 정리해보려 한다. @Async와 WebFlux Mono의 공통점과 차이점 @Async Mono 공통점 - 비동기 처리 - 블로킹하지 않고 비동기 작업의 결과를 반환할 수있다. 차이점 - 별도의 스레드에서 메서드 실행 - 일반적인 비동기 처리에 사용 - Future를 통해 비동기 작업의 결과를 가져온다. - 리액티브 스트림을 통해 데이터를..
동기와 비동기에 대해 정리를 하다 보면 Blocking과 Non-Blocking이라는 개념이 계속 나오게 된다. 맨 처음 글에서 정리했던 동기와 비동기를 간단하게 다시 보면서 Blocking과 Non-Blocking을 연관 지어 정리해보려 한다. 📚Blocking 자신의 작업을 진행하다가 다른 주체의 작업이 시작되면 다른 작업이 끝날 때까지 기다렸다가 자신의 작업을 시작하는 것. 특정 작업이 완료될 때까지 실행 스레드가 대기 상태에 머무르는 것이다. 보통 파일을 읽거나 데이터베이스 쿼리를 실행하는 등의 I/O 작업이 일반적으로 Blocking 작업이다. 📚Non-Blocking 다른 주체의 작업에 관련 없이 자신의 작업을 하는 것. 작업이 완료될 때까지 스레드가 대기 상태에 머무르지 않고 작업이 완료되면..