요구사항 - 크레딧 서버 개발어느 날, 물건 판매 개발이 포함된 서비스의 개발자인 나에게 사용자의 크레딧을 관리할 수 있는 크레딧 서버의 개발 및 요청이 들어왔다.이 크레딧은 매일 자정에 30으로 초기화되며, 사용자들은 매일 이 30개의 크레딧을 통해 물건을 구매할 수 있다. 구현 편의성을 위해 이 서버는 물건 당 크레딧, 사용자 세부 정보 등의 정보는 다루지는 않는다고 가정한다.그리하여 이 크레딧 서버가 제공해야 하는 API는 2개이다.크레딧 차감사용자 아이디, 크레딧 사용량을 입력으로 받아 해당 사용자의 크레딧을 차감크레딧 조회사용자 아이디를 입력으로 받아 해당 사용자의 당일 잔여 크레딧을 반환지금부터 2가지 방식의 설계 하에 2가지 기능을 구현하고, 2개 설계의 성능을 비교해보고자 한다. 설계버전..
본 글은 JWT의 정의를 알고 있고, JWT를 사용해본 적이 있는 사람들을 대상으로 작성되었습니다. 개요최근에는 개인이든 기업이든 사용자 인증을 위해 JWT를 사용하는 경우가 많다. JWT는 사용자 인증을 수행하는 아주 간단한 방법이며, 우리에게 친숙한 JSON이라는 형태로 인증 정보를 다룰 수 있어 아주 좋은 기법이다.그러나 JWT의 보안 취약점에 잘 대응하지 못하면, 사용자의 정보를 탈취당하거나 제3자가 사용자인 척 행동하는 것에 속수무책으로 당할 수 있다. 이러한 사고를 예방하기 위해서는 JWT를 안전하게 발급하고 검증하는 방법들을 숙지하는 것이 중요하다.따라서, 본 글에서는 JWT를 발급하고 검증하는 주체의 시각으로 JWT를 바라보며 JWT를 안전하게 다룰 수 있는 방법들을 소개해보고자 한다. ..
개요좋은 API 문서란백엔드 개발자에게 좋은 API를 설계하는 일은 매우 중요하다. 백엔드 개발자에게 있어서는 API의 사용자가 곧 고객이나 다름 없기 때문이다. 그렇기 때문에, 좋은 API를 설계하고 이를 더 빠르게, 저렴하게, 일관적이며 언제든 이용 가능하도록 제공하는 일은 백엔드 개발자의 중요한 사명이라고 할 수 있다.그러나 백엔드 개발자에게는 좋은 API를 설계하는 것만큼 중요한 일이 하나 더 있다. 바로 좋은 API 문서를 작성하는 일이다. API 문서는 API를 사용하기 위해 사용자가 알아야 할 필수적인 정보들로, (미래의 나를 포함한) 나와 협업하는 모든 동료들에게 중요한 정보 제공처가 된다.그렇다면 좋은 API 문서란 무엇일까? 각자가 생각하는 바가 다르겠지만, 나는 “신뢰 가능한” API..
Long-Running 작업이란? Long-Running 작업이란, 클라이언트에게 리소스를 제공하기 위해 아주 긴 시간을 요구하는 작업을 말합니다. 고비용 연산을 요구하는 AI 기반 서비스들이 늘어나는 최근에는 이러한 Long-Running 작업의 사례를 주변에서 쉽게 찾아볼 수 있죠. 대표적인 사례로, chat GPT의 이미지 생성 기능인 'Dall-E'가 있습니다. 이러한 Long-Running 작업을 사용자에게 제공하기 위해서는 많은 요소를 고려해야 하는데요. 오랜 시간을 요구하는 작업인 만큼 자칫하면 서버에 부하를 가져올 수 있고, 그로 인해 사용자가 서비스를 제공받기 위해 너무 오랜 시간을 기다리게 만들 수도 있기 때문입니다. 이번 글에서는 제가 Long-Running 작업을 포함한 API를 효..
이 글은 유데미 강의 ‘Docker & Kubernetes : 실전 가이드’의 쿠폰을 제공받아 수강하고 작성된 글입니다. 개요 개발을 해오면서 도커라는 도구를 아주 유용하게 쓰고 있다. 도커는 공식 문서와 참고 자료들이 아주 잘 정리되어 있고, 이들을 따라하는 것만으로도 쉽게 컨테이너를 생성해 운영할 수 있다. 하지만 그만큼 도커의 목적, 동작 원리 등에 대한 이해도를 갖추는 것에 소홀해지기 쉬운 것 같다고 느껴, 좋은 강의를 제공받은 김에 본 글에서는 도커의 동작 원리와 도커가 등장한 목적에 대해 살펴보고자 한다. 도커 도커란? 도커란, 컨테이너를 생성하고 관리하기 위한 도구다. 도커를 접해봤거나 사용해본 사람이라면 위와 같은 도커의 정의와 컨테이너란 단어가 익숙할 것이다. 하지만 여기서 의미하는 컨테..
필요한 HTTP Header 브라우저 캐싱을 도입하기 위해서는 아래의 헤더들이 설정되어야 한다. Cache-Control 브라우저의 캐싱 방법을 정하기 위해 서버/클라이언트가 사용하는 HTTP Header 캐시의 저장 여부, 유효 시간 등을 지정할 수 있음 자주 사용하는 디렉티브(directive) 목록 public/private: public은 이 리소스를 받는 모든 주체가 캐싱을 하도록 하고, private는 오직 end-user(마지막 수신자)만이 캐싱을 하도록 함 must-revalidate: 반드시 재검증을 거쳐 캐시된 리소스를 사용하도록 함 max-age=: 캐시가 유효하다고(최신 상태라고) 판단할 최대 시간 E-Tag 리소스를 식별하는 식별자 역할을 하는 HTTP Header response..