아장아장거리면서 주책부리는 블로그

스왑 메모리에 대한 딥 다이빙을 할 때 생긴 궁금증들을 정리해보려고 한다. 1. HDD에서 SSD로 바꿨을 때 스왑메모리는 더 빠른가? 이 호기심의 근원은 여자친구의 컴퓨터 세팅에서 시작되었다. 건축 설계 일을 하는 여자친구는 생각보다 고사양의 그래픽 작업이 따라온다. 이를 위한 데스크탑 컨설팅(컴퓨터 좋아하시는 분들은 껌뻑 죽지만 나는 2020년 이후로 맥만 잡아왔다. 게임도 안한다)을 했었다. 이 때 나온 이야기가 다시 머리속에 상기되며, 스왑 메모리와 같이 합쳐졌다. 하드디스크가 HDD보다 SSD가 성능이 더 좋다는데? 이게 왜 좋을까를 찾아봤을 때, SSD가 더 빠르다고 했었다. 그런데 왜 빠를까? 그리고 스왑메모리도 SSD에 등록하면 빨라질까? 라는 호기심이었다. 둘다 하드디스크인데, 스왑 메모..

서론 스왑메모리은 영상 인코딩을 하다가 서버가 부하를 버티지 못하는 문제로 사용해야겠다는 생각이 들었다. 이전에 사용을 위해서 스왑메모리라는 것이 단순하게 서버가 가지는 저장공간(하드디스크)를 메모리로 치환해서 부족한 메모리를 보충해준다는 것을 알았다. 하지만, 부스트캠프 네트워킹 데이때 커피챗에서 스왑 메모리라는 단어 대신에, 내가 어떻게 풀어서 설명할 수 있어야 한다는 현업자분의 멘토링을 통해 한번 딥 다이빙을 해봐야겠다는 생각이 들었다. 그러면 뭐? 스왑메모리란? 우리의 RAM으로 받는 메모리 외에도, 하드 디스크 공간을 할당하여 RAM이상의 수요를 처리하기 위해 사용하는 가상 메모리이다. 즉, 우리의 저장장치인 하드디스크(누군가에겐 HDD, 다른 사람에겐 SSD)를 가상 메모리화시키는 것이다. 특..

도커로 프로젝트를 올렸다. 근데 계속 터졌다. 분명 잘 됐는데? 분명 문제 없었는데? 분명 컴파일하고 실행하는데 에러가 없는데 왜 꺼질까? 실행시키고 온갖 요청을 할 때 docker logs ${container}로 로그를 보았지만 아무런 에러가 없었다. 도커 전체 로그를 봤지만 문제가 없었다. 하하하 너무 즐겁다. 원인 분석을 위해 3단계로 디버깅 스텝(?)을 만들어보았다. nestjs 서버가 문제일까? 도커가 문제일까? 아니면 서버 자체의 문제일까? 서버가 문제라면 분명 이전의 docker logs로 확인이 되어야 한다. 하지만 문제가 없었다. 그래서 도커 로그를 확인해보았다. cat /var/log/docker.log 근데 이것도 아무런 문제가 없었다. 에러가 명시된 적이 없었다. 이제 서버를 건드..

이전에 git clone을 통해 프로젝트를 받는 방식을 알아보았다. 이 방식의 문제가 무엇일까? 직접 npm install을 해주어야 한다. nestjs : npm run start, java : java -jar의 방식으로 프로젝트를 실행시켜야 한다. 하지만 실제 실행시에는, nestjs : js로 컴파일 후 dist를 실행, java : class 컴파일 후 실행을 한다. 이런 문제를 해결하기 위한 방법은 무엇일까? nestjs : dist디렉토리를 옮겨서 실행시키기 spring : build 디렉토리를 옮겨서 실행시키기 하지만 이런 방식은, 실제 프로젝트에서 일부 부분들을 매 순간마다 만들어서 ec2서버로 올린 후, 이를 실행시켜줘야 한다. 근데, 이건... 겁나 귀찮다 너무 귀찮다...이 짓을 맨..

이제부터가 시작이다. 일단, git과 필요한 것들을 설치해야 한다. sudo apt update // 기본적으로 apt를 업데이트 한다. sudo apt install git // git 설치 sudo apt install openjdk-11-jdk // jdk설치 sudo apt install npm // npm && nodejs 설치 이렇게 nodejs, jdk를 모두 설치할 것이다. 왜? 테스트용으로 nodejs와 spring을 실행시킬꺼거든! 근데 git clone떠서! 이렇게 버전을 확인했다. 이제 git을 사용하기 위한 준비를 마저 해보자. git은 추가적으로 할 일이 있다. ssh키를 만든 다음, 해당 키를 github에 등록시켜주어야 한다. cd ~/.ssh // ssh키를 담을 디렉토리로..

기존에 ec2서버를 이용한 백엔드 배포를 몇 번 해보았지만, 이번엔 문서화를 해보면서 해봐야겠다는 생각이 들었다. 일단 나는 이미 인스턴스가 있다. 그래도 새롭게 만드는 과정부터 보여줘야 할 것 같다는 생각이 든다. 그러므로 인스턴스 시작을 해보겠다. 나는 ubuntu 22.0.4를 이용한 배포를 할 계획이다. 이 때 64비트의 아키텍쳐를 사용하는 것을 추천한다. 아래에 인스턴스 유형은 t2.micro를 이용할 꺼시다. 왜냐고? 이후에 아래에서 키 페어를 생성해주어야 한다. 이렇게 해서 키 페어를 생성한다. 그러면 이렇게 키 페어를 받게 되는데, 이는 후에 사용해야하니 가지고 있도록 한다. 아래의 네트워크 설정이 있다. 이 부분은 방화벽을 설정하고, 이에 따른 보안 그룹을 설정할 수 있다. 하지만, 후에..