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..
서버가 클라이언트를 식별하는 방법 HTTP는 기본적으로 stateless다. HTTP 요청에 포함되는 정보들은 현재 요청을 처리하기 위한 정보들만을 제공할 뿐, 그 이전 또는 이후의 요청에 대한 정보는 제공하지 않는다. 그러나 이러한 정보만으로는 적절한 응답을 내려주기 어려운 요청들이 있다. 대표적인 예시로 사용자의 인증(로그인된 사용자인가?) 여부에 따라 허용을 달리하는 API로의 요청이 있다. 이러한 API를 호출하기 위해, 통상적으로 두 가지 방법이 사용된다. 하나는 서버가 부가적인 정보를 소유하는 세션 방법이고, 다른 하나는 클라이언트가 부가적인 정보를 소유하는 토큰 방법이다. 두 가지 모두 활발하게 사용되고 있고, 나름의 장단점을 가진다. 본 글에서는 두 가지의 특징을 분석하고 어떤 상황에서 어..
HTTP (HyperText Transfer Protocol) 정의 하이퍼텍스트(HyperText)를 주고받기 위해 사용되는 프로토콜 하이퍼텍스트란, 한 문서에서 다른 문서로 접근할 수 있는 텍스트(현대에는 이를 주로 하이퍼링크라고 부름)이다. 문제점 HTTP만을 이용하여 통신하면 데이터를 평문으로 주고받기 때문에 누군가가 이를 가로채 데이터 유출이 일어날 수 있다. 이러한 보안 취약점을 해결하기 위해 도입된 것이 HTTPS 프로토콜이다. HTTPS (HyperText Transfer Protocol Secure Socket) 정의 기본 형식이나 사용 목적은 HTTP와 유사하지만, HTTP의 보안 취약점 해결을 위해 데이터를 암호화하여 주고받는다. HTTPS는 암호화를 위해 대칭키 암호화 방식과 공개키 ..
정의 사용자들이 제3자 서비스의 계정을 통해 인증을 수행할 수 있도록 접근 위임을 제공하는 공통 표준(open standard) 인증방식 여기서 제3자 서비스란 Google, Facebook, Github 등을 포함한다. 장점 (문제 해결) 기존에는 제3자 서비스의 계정을 이용하기 위해 본 서비스와 제3자 서비스에 모두 사용자의 아이디/비밀번호를 제공해야 했으며, 이는 사용자 입장에서는 보안 취약점으로 다가왔다. (하나 털리면 다 털림!) Auth를 이용하면 사용자가 입력한 사용자의 개인 정보가 아닌 임의로 생성되는 값인 accessToken을 이용해 인증을 수행하기 때문에, 두 개 서비스 모두에 개인 정보를 제공할 필요가 없다. 기존에는 제3자 서비스의 아이디/비밀번호를 제공하는 형식에서는 본 서비스가..