문제도커로 레디스를 띄울 때, 기존 데이터나 설정을 유지하고 싶었다. 해결 도커로 레디스를 띄울 때, 볼륨을 통해 저장 공간을 공유하고, redis.conf 라는 레디스 설정 파일도 공유하여 레디스 컨테이너를 띄울 때 데이터를 유지하도록 해결했다. 과정 우선 EC2 Ubuntu24.04 버전에 도커를 띄운 상황에서 설명하겠다. sudo docker volume create redis-data우선 redis-data 라고 하는 볼륨을 만들어준다. $ sudo docker volume inspect redis-data[ { "CreatedAt": "2024-08-05T20:43:25+09:00", "Driver": "local", "Labels": null, ..
전체 글
안녕하세요. PS풀이, 개발일지 및 일기, 소소한 이야기를 적어가는 윤재 입니다.주제 예전에 레디스 해킹을 당해놓고서 아직도 정신 못 차리고 비밀번호 설정을 귀찮아서 안 해두다가 이번에 제대로 알아두기로 했다. 우선 도커로 레디스 설치부터 암호 설정, 암호로 접속하는 방법까지 다뤄보기로. 레디스 도커 설치sudo docker run -d \ --name redis-ex \ -p 63790:6379 \ -e REDIS_ARGS="--requirepass 1234" \ redis/redis-stack-server위는 레디스 스택을 포함하는 redis-stack-server 이미지이고 sudo docker run -d \ --name redis-ex \ -p 63790:6379 \ redis --requirepass 1234위는 그냥 레디스일 때이다. 각각 비밀번호를 ..
문제강의 자료에 나온대로 포트포워딩을 진행했지만 실제로는 포트포워딩이 되지 않았다. 상황강의 자료에 나온 명령어는 다음과 같다. sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080 하지만 보안그룹 인바운드 규칙을 확인해봐도, 서버 내에 프로세스가 정상적으로 실행되었음을 확인해봐도 80포트로 접속이 되지 않았다. ubuntu@ip-172-31-41-183:~$ sudo iptables -t nat -L --line-numbersChain PREROUTING (policy ACCEPT)num target prot opt source destination1 REDI..
Amazon VPC AWS는 Amazon VPC라는 서비스로 가상의 네트워크를 구성할 수 있다. VPC 내의 최대 개수 제한VPC는 리전마다 독립적으로 구성되어 있으며, 하나의 리전당 5개의 VPC를 구성할 수 있다. (공식 문서 출처)또한 VPC당 200개의 서브넷이 최대이며 CIDR 블록은 IPv4와 IPv6 각각 5개가 최대이다. VPC를 만들 때는 IPv4 CIDR 블록을 지정해야 한다. VPC CIDR 허용 범위 공식 문서에서는 프라이빗 IP 주소 범위에 속하도록 권장하고 있지만, 허용된 블록의 크기는 /16 서브넷마스크부터 /28 서브넷마스크 까지다. 즉, IP주소는 65,536개부터 16개까지 제한할 수 있다. 사설 IP 범위 (출처 : RFC 1918)CIDR 블록 예시10.0.0.0 ~ ..
문제매번 EC2 인스턴스를 만들 때마다 패키지 목록 업데이트와, 시간대 설정과, 스왑 메모리 설정을 해주는 반복 작업이 귀찮다. 해결 AWS EC2 에서는 고급 설정에서 사용자 데이터 라는 항목을 통해 인스턴스 실행 시 지정한 스크립트를 실행해주는 기능을 제공하고 있다. 1. EC2 생성 예시를 들기 위해 EC2 생성 클릭 후 이름을 입력 해주고, Ubuntu 24.04 버전으로 선택 후, 왼쪽 아래 아키텍처를 t4g.micro 를 선택하기 위해 64비트(Arm) 을 선택해준다. 오른쪽 아래 변경 확인을 눌러주면 된다. 그리고 테스트를 위해 t4g.nano를 선택해준다. t4g.nano는 AWS Graviton 을 사용하는데, ARM 기반 프로세서라서 위에서 아키텍처로 Arm을 선택해주었다. ..
문제액세스 토큰과 리프레쉬 토큰을 어떤 응답 방식과 양식으로 담아야 하는지. 상황얼마 전 개인 프로젝트에서 인증 부분을 실제 서비스를 염두에 둔다면 어떤 식으로 처리를 할지 고민했던 적이 있다. JWT로 Access token, Refresh token을 이용해서 인증 방식을 택했고, 로그인 시액세스 토큰을 응답 헤더의 Access-Token 키에,리프레쉬 토큰을 HttpOnly 쿠키로 Refresh-Token 키에넣어서 보내주었다. 액세스 토큰을 헤더에, 리프레쉬 토큰을 쿠키에 넣은 이유는 아래와 같았다. 프론트에서는 액세스 토큰을 로컬스토리지에 저장하게 하고, 리프레쉬 토큰은 쿠키 저장소에 저장되어 저장소를 분리시켰다. 만약 한 저장소가 뚫려도 다른 저장소의 토큰은 안전하도록 의도를 담았다.리프레..
상황 개인적으로 하는 프로젝트에서 AOP를 썼었다. Refresh token을 쓰고 있었고, 이를 레디스에 저장하고 있었다. 토큰 속에는 닉네임을 subject 로 가지고 있었다. 문제는 닉네임을 수정하면 리프레쉬 토큰에는 변경이 되지 않아서 로그인이 안 되는 것. 그래서 레디스 속 리프레쉬 토큰을 변경해주어야 했고, 변경된 리프레쉬 토큰을 응답 쿠키에 담아주어야 했다. 또 유저 삭제 시에도 리프레쉬 토큰을 레디스에서 삭제하고, 응답 쿠키도 삭제해야했다. 이를 AOP로 구현한 코드는 아래와 같다. 간략하게 설명하면,@Pointcut 으로 각각 닉네임 수정 시점, 유저 삭제 시점 을 지정해주었고,@Around 로 수정 직후, 삭제 직후에 리프레쉬 토큰 처리를 해주었다. @Slf4j(topic = "..
https://www.acmicpc.net/problem/1520 설명처음에는 BFS로 풀었다. 근데 BFS로 노드를 지나가면서 방문 체크를 해두는데, 이미 방문한 노드에 대해서는 이후 다른 경로에서는 거치지 않기 때문에 경로가 딱 1개만 나왔다. 그렇다고 지나간 경로를 체크 안 하면 무한 루프에 빠져서 BFS는 버렸다. 그 다음에는 DFS로 풀었다. 답은 나왔는데, 시간 초과가 떴다. 그래서 곰곰이 생각하다가 DP로 풀었더니 풀렸다. 탑다운 방식으로 풀었다.범위를 벗어나는 좌표에서는 0을 리턴하고, 이미 계산한 좌표에서는 그대로 계산 값을 리턴하고, 아직 계산하지 않는 좌표에 대해서는 현재 좌표의 상하좌우의 높이를 비교해서 현재 높이보다 큰 인접 좌표에 대해서 재귀로 dp를 호출했다. stat..
https://www.acmicpc.net/problem/1202 맨 아래에 전체 코드 있다. 설명 처음에 배낭문제 인줄 알았는데 가방이 여러 개라 어떻게 풀지 고민하다가 가방에 1개의 보석만 담을 수 있어서 아닌 것 같았다(?) 일단 보석을 객체로 만들고, 가방 최대 무게 배열을 오름차순으로 정렬보석 리스트를 (1) 무게 오름차순, (2) 가격 내림차순 정렬 매 가방마다 보석 리스트 돌며 최대 무게 이하인 보석만 우선순위 큐에 넣기 (우선순위 큐는 2번과 같이 정렬됨)하나 poll 해와서 가격을 총 더하고, 더한 보석은 보석리스트에서 제거 출력 인줄 알았는데 시간 초과가 났다. 아무래도 보석과 가방 개수가 최대 30만개에, 이중 반복문이면 900억이어서.. 그래서 풀이 봤다! 근데 풀이 설명..