32장 작은 자료실 서비스를 끝까지 설계해 보기

마지막으로 책 전체의 내용을 하나의 가상 서비스에 묶어 보자. 작은 팀이 직원용 자료실을 만들려고 한다. 사용자는 책 목록을 검색하고 대여를 신청하며 담당자는 반납을 처리한다. 회원 수는 처음에는 많지 않고, 검색은 자주 하지만 대여 변경은 비교적 적다. 외부 결제와 추천 시스템은 첫 버전에 필요 없다. 이 조건부터 적는 것이 기술 선택보다 먼저다.

처음 설계는 단순하게 시작할 수 있다. HTTPS 입구, 응용 서버, 관계형 데이터베이스, 표지 이미지 저장소가 기본이다. 계정은 조직의 기존 신원 체계와 연동할 수 있는지 검토한다. 캐시와 큐, 컨테이너 플랫폼은 필요가 확인될 때 추가한다. 미래에 필요할지도 모르는 모든 기술을 첫 구성에 넣으면 작은 서비스의 장점을 잃는다.

데이터와 권한부터

책과 개별 소장본을 구분하자. 같은 제목의 책이 세 권 있으면 대여 상태는 제목 하나가 아니라 소장본별로 관리해야 한다. 회원, 소장본, 대여 기록의 관계를 정하고 한 소장본에 유효한 대여가 중복되지 않도록 제약과 트랜잭션을 설계한다. 화면에서 버튼을 비활성화하는 것만으로 동시에 들어온 두 요청을 막을 수 없다.

일반 회원은 자신의 내역만 보고 담당자는 업무에 필요한 범위에서 대여를 관리한다. 계정 관리 권한과 책 편집 권한을 무조건 같은 관리자 역할로 묶지 않는다. 누가 누구의 기록을 변경했는지 남기고, 불필요한 개인정보는 수집하지 않는다. 오래된 대여 이력을 언제까지 보관할지는 조직의 실제 정책과 관련 요구를 확인해 정한다.

요청의 길을 한 번 따라간다

사용자가 대여 버튼을 누르면 브라우저는 HTTPS 요청을 보낸다. 입구는 허용된 크기와 경로를 확인하고 응용 서버로 전달한다. 응용 서버는 인증과 소장본 상태를 검사한 뒤 트랜잭션으로 대여 기록을 저장한다. 응답에는 결과와 요청 식별자를 담는다. 사용자가 다시 눌러도 같은 대여 의도가 중복 기록으로 이어지지 않도록 설계한다.

Employee browser
    |
    | HTTPS
    v
Service entry / reverse proxy
    |
    v
Application
    |-- authentication and authorization
    |-- validation and request identity
    |
    v
Database transaction
    |-- check the copy's availability
    |-- write the loan record
    |-- enforce the consistency rules
    |
    v
Confirmed response + traceable request ID

메일 알림은 대여 기록과 같은 완료 조건인가. 메일 제공자가 잠시 느리다고 대여 자체를 실패시키고 싶지 않다면 기록과 알림을 분리할 수 있다. 이때 알림 작업의 상태와 재시도, 중복 방지를 관리한다. 작은 초기 버전에서는 단순한 작업 테이블이 충분할 수도 있다. 별도의 메시지 브로커가 반드시 첫 선택은 아니다.

공개할 것과 숨길 것

직원용 자료실이라면 인터넷 공개가 필요한지부터 결정한다. 원격 사용을 위해 공개하더라도 로그인과 권한, 관리 경로 보호가 필요하다. 데이터베이스 포트를 일반 인터넷에 열 이유는 대개 없다. 응용 서버가 필요한 연결만 할 수 있도록 구성하고, 운영자 접속은 별도의 인증된 경로로 관리한다. 주소를 모를 것이라는 기대에 의존하지 않는다.

표지 이미지는 공개 자료인지 내부 자료인지 구분해 캐시와 저장소 권한을 정한다. 사용자별 대여 이력은 공유 캐시에 들어가지 않도록 한다. 로그에는 검색어와 회원 정보가 어디까지 남는지 검토한다. 작은 서비스일수록 기본 로그 설정을 그대로 두기 쉬운데, 그 기본값이 데이터 정책과 맞는지 확인해야 한다.

첫 운영 목표

처음부터 거창한 가용성 숫자를 선언하기보다 근무 시간의 중요한 기능과 복구 목표를 정한다. 검색과 대여의 성공률, 응답 시간, 데이터베이스 백업 성공, 실제 복원 가능성을 관찰한다. 장애가 나면 누구에게 연락하고 수기 기록으로 임시 운영할 수 있는지까지 준비한다. 기술 시스템의 복구를 기다리는 동안 업무가 어떻게 이어지는지도 중요하다.

배포는 소스 버전과 산출물을 연결하고 시험 환경에서 대여·반납·권한 거부를 확인한 뒤 수행한다. 데이터베이스 변경은 이전 버전과 호환되는 단계로 나눈다. 첫 사용자가 들어온 뒤에도 어느 버전이 실행 중인지 쉽게 확인할 수 있어야 한다. 개발자가 기억하는 코드와 운영에서 도는 코드가 달라지는 순간을 줄인다.

언제 확장할 것인가

검색이 느려지면 먼저 질의와 인덱스, 결과 크기를 측정한다. 동시 요청이 늘면 연결 풀과 데이터베이스 부하를 함께 본다. 반복 조회가 많고 낡은 값을 허용할 수 있는 부분에 캐시를 적용한다. 이미지 처리처럼 오래 걸리는 작업이 사용자 요청을 붙잡으면 비동기 처리를 검토한다. 새 구성 요소는 관찰한 문제에 대한 답으로 들어와야 한다.

이 설계에는 모든 최신 기술이 등장하지 않는다. 대신 데이터의 규칙, 사용자의 권한, 요청의 경로, 실패와 복구, 성장의 조건이 들어 있다. 이것만으로도 충분히 진지한 시스템 설계다. 기술을 많이 안다는 것은 언제나 많이 사용하는 것이 아니라 필요한 곳과 필요하지 않은 곳을 구분할 수 있다는 뜻이다. 작은 서비스를 끝까지 책임져 보는 경험은 그 구분을 배우는 좋은 출발점이다.