요구사항 - 크레딧 서버 개발어느 날, 물건 판매 개발이 포함된 서비스의 개발자인 나에게 사용자의 크레딧을 관리할 수 있는 크레딧 서버의 개발 및 요청이 들어왔다.이 크레딧은 매일 자정에 30으로 초기화되며, 사용자들은 매일 이 30개의 크레딧을 통해 물건을 구매할 수 있다. 구현 편의성을 위해 이 서버는 물건 당 크레딧, 사용자 세부 정보 등의 정보는 다루지는 않는다고 가정한다.그리하여 이 크레딧 서버가 제공해야 하는 API는 2개이다.크레딧 차감사용자 아이디, 크레딧 사용량을 입력으로 받아 해당 사용자의 크레딧을 차감크레딧 조회사용자 아이디를 입력으로 받아 해당 사용자의 당일 잔여 크레딧을 반환지금부터 2가지 방식의 설계 하에 2가지 기능을 구현하고, 2개 설계의 성능을 비교해보고자 한다. 설계버전..
어느 날, 개발자 A가 실수로 개발자 B의 PR에 해당 PR의 커밋을 반영하지 않은 브랜치로 force push를 올려 원래 PR의 작업물 일부가 날아가버리는 사고가 발생했다.개발자 B는 자신의 로컬 브랜치를 찾아 다시 변경 사항을 반영하려 했으나, 로컬 브랜치를 이미 지워버린 뒤였다는 사실을 깨달았다…개발자 A와 B는 절망에 빠졌지만, git의 놀라운 기능들을 이용하면 이 작업물을 복구할 수 있다고 한다.지금부터 이 작업물을 복구하는 방법을 알아보자! 이 글의 예상 독자hard reset, 브랜치 삭제 등에 의해 커밋을 잃어버린 사람들 잃어버린 커밋을 되찾는 방법 3가지잃어버린 커밋을 되찾는 방법은 3가지가 있다.커밋 해시로 복구 브랜치 생성git reflog 명령을 이용git fsck 명령을 이용1..
최근에 처음으로 Kubernetes를 학습하게 되었다.기존부터 나는 Docker의 애용자였고, 서비스의 배포 및 관리를 위해 AWS ECS를 주로 사용하고 있었다.그러나 Kubernetes는 한 번도 다뤄본 적이 없었는데, 최근 처음으로 Kubernetes 기반으로 구축된 대규모의 시스템을 관리하게 되며 공식 문서와 Udemy 강의 등의 도움을 얻어 Kubernetes를 습득하고 있다.그런데… Kubernetes가 제공하는 기능들을 들으면 들을수록, 계속하여 드는 한 가지 생각이 있었다. 어? 이거 ECS로도 충분히 할 수 있는 건데?여러 개의 컨테이너를 띄우고, 각각의 상태를 체크하고, 원활한 서비스를 위해 개수를 자동으로 조정하는 일 등은 AWS ECS가 제공하는 기능들로도 충분히 할 수 있는 일이었..
본 글은 JWT의 정의를 알고 있고, JWT를 사용해본 적이 있는 사람들을 대상으로 작성되었습니다. 개요최근에는 개인이든 기업이든 사용자 인증을 위해 JWT를 사용하는 경우가 많다. JWT는 사용자 인증을 수행하는 아주 간단한 방법이며, 우리에게 친숙한 JSON이라는 형태로 인증 정보를 다룰 수 있어 아주 좋은 기법이다.그러나 JWT의 보안 취약점에 잘 대응하지 못하면, 사용자의 정보를 탈취당하거나 제3자가 사용자인 척 행동하는 것에 속수무책으로 당할 수 있다. 이러한 사고를 예방하기 위해서는 JWT를 안전하게 발급하고 검증하는 방법들을 숙지하는 것이 중요하다.따라서, 본 글에서는 JWT를 발급하고 검증하는 주체의 시각으로 JWT를 바라보며 JWT를 안전하게 다룰 수 있는 방법들을 소개해보고자 한다. ..
사이트에 연결할 수 없음 (DNS_PROBE_FINISIHED_NXDOMAIN)최근에 하나의 애플리케이션 서버를 구축하고 배포한 뒤 당당하게 도메인으로 접속했는데 아래 화면을 만난 적이 있다. 해당 화면은 잘못된 사이트에 접속하면 쉽게 만나볼 수 있는 화면이다.그렇다면 이 화면이 보여지는 이유는 뭘까? 하단의 오류명이 DNS로 시작하는 것을 보아하니, DNS와 관련이 있어 보인다.그래서 우선은, 브라우저의 URL 입력창에 접근하고자 하는 URL을 입력했을 때 무슨 일이 일어나는지를 먼저 되짚어봤다.브라우저는 먼저 URL을 분석하여 URL로부터 도메인을 추출한다.(https://admin.devpanpan.com → admin.devpanpan.com)도메인으로부터 IP 주소를 얻어내기 위해 DNS 서버에..
개요좋은 API 문서란백엔드 개발자에게 좋은 API를 설계하는 일은 매우 중요하다. 백엔드 개발자에게 있어서는 API의 사용자가 곧 고객이나 다름 없기 때문이다. 그렇기 때문에, 좋은 API를 설계하고 이를 더 빠르게, 저렴하게, 일관적이며 언제든 이용 가능하도록 제공하는 일은 백엔드 개발자의 중요한 사명이라고 할 수 있다.그러나 백엔드 개발자에게는 좋은 API를 설계하는 것만큼 중요한 일이 하나 더 있다. 바로 좋은 API 문서를 작성하는 일이다. API 문서는 API를 사용하기 위해 사용자가 알아야 할 필수적인 정보들로, (미래의 나를 포함한) 나와 협업하는 모든 동료들에게 중요한 정보 제공처가 된다.그렇다면 좋은 API 문서란 무엇일까? 각자가 생각하는 바가 다르겠지만, 나는 “신뢰 가능한” API..
Spring Data JPA란?Spring Data JPA란, JPA 기반의 데이터 접근 계층을 쉽게 구현하도록 돕는 프레임워크이다. Spring Data JPA는 단순히 JPA 스펙을 이용할 때 직접 엔티티 매니저를 획득하고 쿼리를 작성 및 실행하는 등의 로직을 반복 구현해주어야 하던 귀찮음을 대폭 감소시켜주었다.그러나 Spring Data JPA가 가져다주는 편리함의 이면에는 수많은 추상화가 숨어 있다. 이들은 반복 로직을 생략하여 코드를 간소화하는 것을 돕지만, 제대로 된 이해 없이 사용하면 의도하지 않은 동작을 야기할 수 있다.이번 글에서는 Spring Data JPA를 사용할 때 발생할 수 있는 4가지의 Side-Effect를 살펴보고 이들을 예방하기 위해 알아야 할 지식들에 대해 정리해보고자 ..