CHAAANY ARCHIVE
551개의 기록을 주제별로 둘러보세요.
주문 목록을 최신순으로 보다가 배송 상태별로 다시 묶는다고 하자. 같은 상태의 주문은 어떤 순서로 보여야 할까? 최신순이 유지되길 기대할 수도 있고, 주문 번호순으로 보길 기대할 수도 있다. “정렬한다”는 말만으로는 답이 정해지지 않는다. 무엇을 기준으로 비교하고, 기준이 같을 때 어떤 순서를 남길지부터 정해야 한다.지난 글에서는 주문 수가 늘 때 검색 방법의 작업량이 어떻게 달라지는지 살펴봤다. 정렬에도 작업량이 들지만, 결과의 순서가 맞는지를 먼저 확인해야 한다. 빠르게 끝났더라도 같은 상태의 주문을 매번 다른 순서로 보여 준다면 원하는 정렬이 아닐 수 있다.무엇을 비교해야 할까정렬(sorting)은 여러 값에 순서를 정해 나열하는 작업이다. 숫자만 정렬할 때는 작은 값과 큰 값을 비교하면 된다. 주..
로그인 화면에서 비밀번호를 한 번 입력한 뒤에는 상품을 보고, 주문을 확인하고, 페이지를 새로 고쳐도 대개 로그인이 유지된다. 매 요청마다 비밀번호를 다시 보내는 게 아니라, 서버가 로그인 결과를 이어서 확인할 방법을 만들었기 때문이다.이 방법을 세션(session)이라고 한다. 세션은 여러 요청을 같은 로그인 상태와 연결하는 기록이다. 이 글에서는 서버가 상태를 보관하고 브라우저에는 식별자만 전달하는 방식을 예로 든다. 로그인 상태를 담는 방법은 서비스마다 다르므로 모든 웹사이트가 이 방식으로 구현됐다는 뜻은 아니다.비밀번호 확인과 이후 요청은 다른 일이다로그인할 때 서버는 계정 상태와 입력한 인증 수단을 확인한다. 인증(authentication)은 지금 요청한 사람이 그 계정의 정당한 사용자라는 근..
육아휴직 8주차.아기를 데리고 처음으로 장거리 운전을 해서 안동에 다녀왔다. 아기가 딱 백일 되는 날도 안동에서 맞았고, 아내와 오랜만에 같이 뛰고, 나는 처음으로 10km를 달렸다. 가족들과 함께 보내다 보니 일주일이 금방 지나갔다.아기와 첫 장거리 운전, 안동으로9월 21일 월요일은 안동으로 내려가는 날이었다. 전날부터 짐을 열심히 챙겼고, 아침 9시에는 대여했던 백일상을 반납했다. 남은 짐까지 차에 싣고 출발! 아기가 중간중간 쉬어가야 해서 전날 운전 코스도 미리 짜뒀다. 덕평휴게소와 단양휴게소를 들르면 대략 3분의 1, 3분의 2 지점에서 쉴 수 있었다.덕평휴게소에서 기저귀를 갈고 분유를 먹이는데 아내가 갑자기 “야!” 하고 소리쳤다. 무슨 일인가 했더니 아내의 절친과 그 어머님, 아기도 거기 있..
주문이 세 건일 때는 목록에서 번호 하나를 찾는 일이 금방 끝난다. 주문이 만 건이면 이야기가 달라진다. 지난 글에서 배열, 해시 테이블, 큐로 같은 주문을 다르게 다루는 이유를 살펴봤다. 이번에는 주문 수가 늘 때 확인해야 할 항목이 얼마나 늘어나는지 세어 보자.빅오(Big-O notation)는 입력 크기가 커질 때 작업량이 어떤 속도로 늘어나는지 나타내는 표기다. 실제 실행 시간을 초 단위로 약속하는 표기는 아니다. 컴퓨터의 속도, 데이터가 놓인 위치, 구현 방식이 달라도 입력이 늘 때 반복 횟수가 어떻게 변하는지 비교하는 데 쓴다.앞에서부터 찾으면 몇 건을 확인할까주문 번호를 배열 [17, 42, 23, 31, 55]에 접수 순서대로 담았다고 하자. 17번을 찾으면 첫 비교에서 끝난다. 55번은 ..
주문 버튼을 눌렀는데 화면에 시간 초과 오류가 뜬다. 다시 누르면 될까? 화면이 답을 받지 못했다는 사실과 주문이 만들어졌는지는 다른 문제다. 서버가 요청을 받기 전에 연결이 끊겼을 수도 있고, 주문을 저장한 뒤 응답만 돌아오지 않았을 수도 있다.시간 초과(timeout)는 기다리는 쪽이 정한 시간이 지났다는 뜻이다. 상대가 작업을 하지 않았다는 확인서는 아니다. 앞서 주소창에서 첫 화면까지 어떤 일이 일어나는지 따라갔다면, 이번에는 요청을 보낸 뒤 답이 오지 않는 구간을 살펴보자. 아래 주문과 시간은 동작을 설명하기 위한 예다.같은 오류 화면 뒤에 세 가지 상태가 있다클라이언트(client)는 서버에 요청을 보내는 프로그램이다. 여기서는 브라우저가 클라이언트다. 브라우저가 POST /orders 요청을..
주문 목록을 만든다고 생각해보자. 주문 번호로 한 건을 찾고, 최근 주문 20건을 화면에 보여주고, 접수된 순서대로 주문을 처리해야 한다. 주문이라는 데이터는 같지만 세 작업이 원하는 답은 다르다.자료구조(data structure)는 데이터를 저장하고 꺼내는 방법을 정해둔 형태다. 알고리즘(algorithm)은 저장된 데이터를 읽고 바꿔 원하는 답을 구하는 절차다. 어떤 자료구조를 쓰든 먼저 주문을 어떤 기준으로 찾고, 어떤 순서로 보여주고, 언제 변경하는지 알아야 한다.설명을 위해 주문 세 건이 차례로 들어왔다고 하자. 실제 주문 기록이 아니라 각 구조의 움직임을 보기 위한 예다.접수 순서 주문 번호 상태첫 번째 17 대기두 번째 42 대기..
주소를 입력하고 화면이 뜰 때까지 몇 초가 걸린다. 이 시간을 통째로 “서버가 느리다”고 말하기 쉽지만, 서버에 요청을 보내기 전에도 할 일이 있다. 주소를 찾고 연결해야 한다. 서버에서 문서를 받은 뒤에는 그 문서가 필요로 하는 파일을 더 가져오고 화면을 그린다.브라우저(browser)는 웹 주소로 문서를 요청하고 받은 내용을 화면에 보여 주는 프로그램이다. 한 페이지가 늦게 뜨는 이유를 알려면 이 과정에서 어디까지 끝났고 어디서 기다리는지 봐야 한다. 아래에서는 처음 방문한 상품 페이지 한 곳을 따라가 본다. 숫자와 주소는 흐름을 설명하기 위한 예다.주소를 나눠 읽는다웹 주소(Uniform Resource Locator, URL)는 가져올 자원의 위치와 접근 방법을 담는다. 다음 주소를 보자.http..
육아휴직 7주차.이번 주는 아내 생일상도 차리고, 주말에는 아기 백일상도 차렸다. 생일 준비는 마음처럼 잘 안 된 부분도 있었는데, 얘기하고 나니 조금씩 괜찮아졌다. 백일상은 생각보다 잘 돼서 아주 만족스러웠다 :)아내 생일상 차리느라 아침부터 바빴다9월 14일 월요일은 아내 생일이었다. 전날 조용히 잠든 뒤 아침부터 생일상을 차리느라 바빴다. 양지 소고기 미역국이랑 잡채를 하고, 반찬가게에서 안동찜닭이랑 제육볶음, 나물 네 가지를 주문했다. 출산 후 첫 생일상이었는데 아내가 맛있게 먹는 걸 보니 안도했다.아내가 산책을 간 뒤에는 아기를 보며 시간을 보냈다. 오후 3시쯤 아내랑 아기랑 백화점에 나가 카페에서 도란도란 얘기도 했다. 5시쯤 집에 와서 누워 쉬다가 6시 40분쯤 아기를 아기체육관에서 놀게 했..
사용자가 결제 버튼을 눌렀는데 5초 뒤 오류가 났다고 하자. 서버 로그 한 줄만 보면 예외 메시지는 찾을 수 있어도 언제부터 얼마나 많은 요청이 느려졌는지, 데이터베이스와 외부 결제 중 어디에서 시간이 쓰였는지 알기 어렵다.관측 가능성(observability: 시스템 밖으로 나온 신호를 이용해 내부 상태와 실패 원인을 추론할 수 있는 정도)은 데이터를 많이 쌓는 것과 다르다. 로그, 메트릭, 트레이스가 어떤 질문에 답하도록 설계됐는지가 중요하다.로그는 한 사건의 구체적인 맥락을 남긴다로그(log: 특정 시점에 애플리케이션이나 시스템에서 일어난 사건을 구조화해 남긴 기록)는 오류 메시지, 주문 식별자, 상태 전이, 재시도 횟수처럼 한 사건의 세부 정보를 담는다.time=10:01:03level=error..
세 서버가 같은 상태를 복제하고 있는데 기존 리더와의 연결이 끊겼다고 하자. 남은 서버는 새 리더를 뽑아야 한다. 하지만 기존 리더가 실제로 죽은 것이 아니라 네트워크만 갈라졌다면 양쪽에서 리더가 생길 수 있다.합의(consensus: 여러 서버가 장애와 메시지 지연이 있어도 하나의 값이나 작업 순서에 동의하도록 만드는 규칙)는 서버가 모두 같은 순간에 같은 화면을 보는 기능이 아니다. 어떤 제안을 확정된 것으로 인정할지와 새 리더가 이전 결정을 어떻게 이어 갈지를 정한다.실패와 지연을 완전히 구분할 수는 없다서버 A가 B의 응답을 받지 못했을 때 B가 죽었을 수도 있고 네트워크가 느릴 수도 있고 A 쪽 연결만 끊겼을 수도 있다.A ──?── B관찰 가능한 사실: 제한 시간 안에 응답이 없음알 수 없는 ..
서버가 초당 100건을 처리할 수 있는데 500건이 계속 들어오면 일시적인 버퍼만으로 해결할 수 없다. 요청을 모두 받아 쌓으면 메모리와 연결, 데이터베이스 풀이 차례로 가득 차고 결국 정상 요청까지 오래 기다리다 실패한다.백프레셔(backpressure: 뒤쪽 소비자가 처리할 수 있는 속도를 앞쪽 생산자에게 전달해 유입량을 조절하는 흐름 제어)는 과부하를 없애는 마법이 아니다. 시스템이 감당하지 못하는 일을 어디에서 기다리게 하고 언제 거절하며 무엇을 우선할지 정하는 규칙이다.처리율보다 유입률이 크면 대기열은 계속 늘어난다생산자(producer: 요청이나 작업을 만들어 다음 단계로 보내는 구성 요소)가 초당 500건을 보내고 소비자(consumer: 받은 요청이나 작업을 실제로 처리하는 구성 요소)가 ..
클라이언트가 주문 생성 요청을 보냈는데 응답을 받기 전에 연결이 끊겼다고 하자. 서버가 처리하지 않았을 수도 있고 처리는 끝났지만 응답만 사라졌을 수도 있다. 클라이언트는 실패인지 성공인지 알 수 없다.이때 재시도를 막으면 실제로 처리되지 않은 주문을 잃고 그대로 다시 보내면 주문이 두 개 생길 수 있다. 멱등성(idempotency: 같은 작업을 한 번 실행하든 여러 번 실행하든 최종 상태가 같게 되는 성질)은 이 불확실한 재시도를 안전한 상태 전이로 바꾸는 규칙이다.같은 요청과 같은 결과를 먼저 정의해야 한다사용자 7의 이메일을 x@example.com으로 설정은 여러 번 실행해도 최종 이메일이 같다. 반면 잔액에 10,000원을 더한다는 실행할 때마다 값이 바뀐다.설정: email = x@examp..