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

올 한해는 생각보다 부지런하고, 능동적으로 살았다고 생각한다. 스스로 삶의 규칙을 정하고, 지속 가능함이 도대체 뭘까라는 생각을 계속 해보기도 했다. 기존에 있던 커뮤니티보다 더 넓은 환경에 지내보기도 했다. 보고 배운것도 많지만, 앞으로 뭘 해야할까도 생각해봐야겠다는 생각에서 (2주나) 늦었지만 정리를 해보았다. 부스트캠프 아무래도 제일 큰 변화였다고 생각한다. 대학교도 1년 늦게 가면서, 나는 최대한 빠르게 졸업해서 죽이되든 밥이되든 취업을 해야겠다! 라는 생각으로 학교를 다녔다. 군대 다녀와서 이제 뭐하지...하던 상황에서 나보고 코딩이나 해봐라 라던 동기(이 친구는 우테코를 다녀왔더라)의 말이 2022년 11월이었다(이제 2024년 1월인데..?!) 그때부터 재밌어보이는 건 다 공부해본 것 같다...

우리가 서비스를 운영하면서, 업데이트를 하거나 새롭게 버전을 올려야 할 때가 있다. 모바일 앱이나 프로그램같은 경우에는 이를 설치하면 끝이겠지...(넥슨이 매주 목요일에 불타는 이유...) 그렇다면 웹 서비스는 어떨까? 웹 서비스, 그 중에서 백엔드에서는 배포를 할 때 어떻게 동작하는지 생각해봐야 한다. 서버에서 단순히 프로젝트를 실행시킨다면, 해당 프로젝트를 끈 다음, 프로젝트를 업데이트시켜야 한다. 업데이트 후 프로젝트를 다시 실행시킨다. 도커를 이용한 배포를 한다면, 그나마 쪼오금 쉬워진다. 배포해야 할 버전의 도커 컨테이너를 클라우드에 올려준다. 올려둔 버전의 컨테이너를 서버가 다운로드받는다. 실행중인 컨테이너를 종료시켜준 후, 받아온 새로운 컨테이너를 실행시켜주면 된다. 이 때, 빈 시간이 존재..

사건의 발단은 곰터뷰에서 우리의 쿼리깎기와, 이전 멘토님의 코멘트중에 있었다. DB를 더 빠르게 할 수 없을까? 데이터베이스 서버가 꺼졌다면, 우리는 어떻게 대응해야할까? 상태확인만으로 괜찮을까? 당시에는 이걸 그냥 상태확인으로 넘기고, 다른 생각을 해보지 못했었다. 이번 기회에, 이걸 어떻게 해결하는게 좋은지 생각을 하려고 했다. 일단 현 상황부터 확인을 해야헀다. 우리의 DB는 단 하나의 서버로 동작한다. 해당 서버가 터져버리거나, 불의의 사고로 소실되었을 때, 우리는 대처할 수 없다. 그렇다면? 간단하게 데이터베이스를 여려 개 두어서 동기화를 시키거나, DB의 값들을 로컬에 따로 저장했다가, 로컬 스토리지의 데이터를 활용하는 방법 정도가 생각났다. 그런데, 로컬이라는 것도 결국에는 애플리케이션의 수..

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

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

12/15 : 부스트캠프 수료 12/16 : 네트워킹 데이 진행 12/15 6개월의 부스트캠프가 끝났다. 4주간의 챌린지, 8주간의 학습 스프린트, 6주간의 그룹 프로젝트였다. 생각보다 짧은 기간내에 때려넣은 지식이 많다보니 아카이빙에 생각보다 많은 시간을 써야겠다는 생각이 들었다. 최종 발표를 하면서 느낀건, 우리가 생각하지 못하는, 정말 다양한 서비스에서 개발자가 일할 자리가 있다는 것? 우리가 생각을 넓히면 충분히 '개발'이라는 분야는 발전할 수 있겠다는 안도감과, 앞으로 어떤 분야에 대해서 나는 '개발'이라는 단어를 가지고 다가갈까를 생각하게 되었다. 다른 팀원들의 발표를 들으면서, 어떤 고민을 했고 이것도 내가 해볼까? 라는 생각도 가지게 되었다. 전체적으로 백엔드로써 느끼는 것은, '서버의 스..

https://jangsarchive.tistory.com/147 [NestJS] 쿼리 헤치우기(1. 인덱스 넣기 & 쓸데없는 쿼리 줄이기) 부스트캠프에서 프로젝트를 진행하면서, 전체 테스트를 실행할 때 항상 13~16초의 시간이 걸렸다. 테스트가 약 260개정도였을 때 이 정도가 나온다고 했을 때, 초당 20개의 테스트가 돌아간다고 생 jangsarchive.tistory.com 기존 쿼리 최적화를 보고 오는 것도 추천한다. 이걸 하고 나서 그 다음에 처리한 과정이기 때문이다. 트랜잭션이란? 그리고 트랜잭션화의 필요성 데이터베이스를 사용할 때 트랜잭션이란 무엇일까? 정말 간단하게, 트랜잭션은 DB에 보내는 쿼리를 묶음이라고 생각하면 된다. 쿼리를 하나씩 계속 보내는 것이 아닌, 하나를 통째로 보내서 성..

부스트캠프 팀 프로젝트를 진행하면서, 서버의 상태를 확인하는 플로우를 만들어야 했다. 쉘스크립트를 crontab을 이용해서 slack에 서버 상태 메시지를 보내는 방법을 만들었지만, 이걸로는 부족했다. 내가 원하는 것은 일종의 서버실이었다. 서버 하나에서 DB, Main서버를 계속해서 확인하는 로직을 원했다. 로컬에서도 실행시켜 서버 상태를 계속 확인하고, 다른 서버에서 주기적으로 시그널링을 처리했으면 좋겠다는 생각을 했다. 그래서 어떻게 처리했을까? 크게 라이브러리 추가, 모듈 구현, 프로바이더 구현으로 나누어보았다. 라이브러리 추가 이 동작을 구현하기 위해서, 3가지 라이브러리를 추가했다. npm install @nestjs/terminus npm install @nestjs/schedule npm ..

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

간단하게 팀 NDD에 대해서 설명을 해...주진 않겠다. 궁금하면 팀 블로그를 보는 것도 방법이지!!! 왜 우리는 인코딩을 해서 클라우드 스토리지에 올리려는 계획을 세웠을까? 기존에는 클라이언트에서 녹화한 webm파일을 바로 클라우드 스토리지에 전송시키는 방식을 이용했다. 이 방식은 클라이언트가 백엔드에게 녹화한 면접 영상의 이름을 만들기 위한 데이터를 준다(우리는 질문 이름과 jwt토큰을 주었다) 백엔드에서는 해당 정보로 영상 이름(key : 회원이름_질문내용_uuidv4()을 url에 받을 수 있게 파싱했다)와, presigned-url(영상을 저장할 권한을 미리 담아둔 url)을 보내주었다. 클라이언트에서 presigned url로 영상 저장을 요청하면 저장한 영상의 주소가 나온다. 영상의 주소와 ..