개발자로 진로를 정한 후에 처음으로 내돈내산 한 코딩 관련 서적이다! (전공 서적, 선물 제외) 정말 유명한 도서들이 많지만 굳이 이 책을 고른 이유는 학습한 내용을 프로젝트에 적용하고 싶기 때문이다. 개발 서적을 구매하더라도 현재 진행중인 프로젝트와 맞지 않는 경우, 배운 내용을 곧바로 써먹기 힘들어 흥미가 떨어지고 학습 내용도 휘발된다. 하지만 코드 품질은 어느 프로젝트에나 적용할 수 있기 때문에 나의 수요와 딱 맞아 떨어졌다. 회사의 운명을 결정 짓는 코드 품질 이 책을 읽기 전까진 막연하게 유지보수의 용이성 때문이라고 생각했다. 하지만 코드 품질로 인해 한 기업이 망할 수도 있다. 고품질의 코드를 작성하기 위해서는 많은 노력이 필요하다. 코드 품질을 위해 꼼꼼히 개발하다가 다른 경쟁사의 제품이 먼..

서버 터뜨리는 경우의 수 다 해보기 😵‍💫 (예비 서버 개발자지만 서버를 터뜨려요)지난 번에는 health check를 안 해줘서 서버를 터뜨렸는데, 이번에는 도커 컴포즈에 오타를 내서 서버를 터뜨렸다!이번 포스팅에서는 배포 스크립트에서 발생할 수 있는 에러를 선별하고, 에러가 발생하면 곧바로 종료하여 잘 돌아가는 서버에 영향을 미치지 않도록 만들어 줄 것이다. 문제의 배포 스크립트echo "The $STOP_TARGET version is currently running on the server. Starting the $RUN_TARGET version." DOCKER_COMPOSE_FILE="compose.$RUN_TARGET-deploy.yml" sudo docker-compose -f "$DOC..

수정할 게 끝이 없네!! 🤪지난 포스팅에서 블루/그린 무중단 배포를 다뤘다. 하지만 무중단 배포임에도 불구하고 신규 어플리케이션에서 에러가 발생하면 중단된다!! (얼레벌레 무중단 배포,,)이번 포스팅에서는 죽은 어플리케이션으로 트래픽을 전환하지 않도록, 어플리케이션의 상태를 확인하는 과정을 넣어줄 것이다. health check🔗 지난 포스팅- [CD] 블루/그린 무중단 배포 구현하기 1편- [CD] 블루/그린 무중단 배포 구현하기 2편health check는 서비스가 올바르게 작동하는지 확인하는 프로세스다. 장애나 문제를 미리 감지하고 예방할 수 있어 안정성을 향상시킨다.health check의 이점조기 감지 및 대응 : API의 이상을 조기에 감지할 수 있어, 잠재적인 문제를 신속하게 대응할 수 ..

CORS 에러에 부딪히면 항상 origin에다 * 넣어서 해결했는데 드디어 CORS에 대해 공부해보기로 결심했다. CORSCORS란?CORS는 Cross-Origin* Resource Sharing의 약자다. Resource Sharing이 자원 공유인 건 알겠는데 Cross Origin은 뭘까? 크로스 오리진은 서로 다른 출처를 의미한다. 즉, CORS는 서로 다른 출처 간 자원 공유다.*origin : 자원에 접근하는 출처 (프로토콜 + 호스트 + 포트)SOP: Same-Origin Policy😈 origin에다 *를 넣으면 안되는 이유CORS 요청은 보안상의 이유로 Same-Origin Policy에 의해 제한된다. Same-Origin Policy는 다른 출처에서의 접근을 막아 자원을 보호한다. ..

passport로 인증/인가 구현하기 passport란? 직접 구현한 인증/인가 로직을 passport 라이브러리를 활용하여 대체할 것이다. passport는 node에서 사용하는 인증 라이브러리다. 이미 인증/인가를 구현했으면서 왜 passport를 도입했을까? 바로 passport가 표준화된 방식을 이용하고 있기 때문이다. passport의 이점 표준화된, 다양한 인증 전략 제공 : 직접 다 구현할 필요없이 다양한 전략을 간단하게 사용할 수 있다. 풍부한 생태계 : 많은 곳에서 활발하게 사용되고 있기 때문에 문제가 발생했을 때 도움을 얻기 쉽다. ... @Injectable() export class JwtAuthGuard implements CanActivate { constructor(privat..

이번엔 도커 컴포즈를 이용하여 멀티 컨테이너 어플리케이션을 만들 것이다. 멀티 컨테이너를 구축하면 서비스별로 컨테이너를 만들기 때문에 각 컨테이너가 한 가지 일만 수행하고, 서로의 리소스에 영향을 미치지 않는다는 장점이 있다. Docker Compose를 사용하는 이유 docker CLI의 단점 결론부터 말하면 도커 CLI는 단일 서비스에 최적화 되어있기 때문에 복잡한 멀티 컨테이너를 다루기엔 적합하지 않다. 도커 컨테이너는 격리된 환경을 가지므로 다른 컨테이너와 통신하기 위해서는 동일한 네트워크에 배치해줘야 한다. 이처럼 멀티 컨테이너를 위한 설정으로 인해 CLI 명령어가 길어지고 복잡해진다. docker CLI로 멀티 컨테이너를 띄울 때의 단점 복잡성 및 가독성 : 네트워크, 볼륨 등 멀티 컨테이너 ..

UX는 프론트엔드 담당이라고? 백엔드도 할 수 있어 😎 새로운 어플리케이션이 출시되는 등의 이유로 서버를 종료하는 상황을 가정해보자. 사용자의 요청을 처리하는 도중에 서버를 종료하면 어떻게 될까? 사용자는 서버로부터 유의미한 응답을 받을 수 없기 때문에 불편함을 느낄 것이다. 지금부터 모든 요청을 처리한 후에 종료하는 방법을 알아보자! graceful shutdown 난 사실 우아한 종료가 아닌, 우하하 종료를 구현했다 🤪 그레이스풀 종료는 서버가 모든 요청에 대해 응답하고, 더 이상 처리해야 하는 작업이 없을 때 종료하는 것을 의미한다. 혹시 SIGKILL을 보내고 있진 않나요? 그레이스풀 종료를 구현하기 위해서는 몇 가지 유의사항이 있다. 우선, 프로세스를 강제로 죽이면 안된다. (처음엔 SIGKIL..

서버 개발자를 노트북에서 잠시 해방시켜 주는 법이번에 프로젝트를 진행하면서 가장 많이 했던 말이 "서버 왜 죽었지"다. 이전까지는 배포를 제대로 해본 적이 없어서 (과제 발표할 동안만 돌아가면 되기 때문에,, 어차피 개발해도 나만 쓰는 일회성이기 때문에,,) 로깅과 모니터링의 중요성을 느끼지 못했다.🙋‍♀️ : 프론트 테스트 하려고 하는데 서버 내렸어? 🙋‍♂️ : 서비스 안 되는데 혹시 서버 터졌나요?하지만 이번 프로젝트에서 매주 업데이트 된 것을 배포하고, 사용자를 모으면서 로깅과 모니터링이 정말 중요하다는 걸 깨달았다.🤯: 엥? 서버 안 돌아가?!?! 🤯: 엇,, 잠시만요,, 확인해보겠습니다,, (노트북 주섬주섬,,)지금 나에게 필요한 건 딱 두 가지다.1. 서버가 죽는 원인 찾기 2. 서버가 곧 ..