upgrade and develop

[Ubuntu] 08. 홈 서버 운영 - Unit Test와 Integration Test 분리

서버 배포와 백업까지 정리한 뒤에는 테스트가 신경 쓰이기 시작했다.처음에는 로컬에서 dotnet test가 통과하면 괜찮다고 생각했다. 그런데 Codex나 GitHub Actions 같은 환경에서 테스트를 돌리려고 하니 문제가 생겼다.오류는 대략 이런 식이었다.Cannot create an automatic instance.Unknown error처음에는 코드가 깨졌나 싶었는데, 자세히 보니 테스트 코드 자체의 실패가 아니라 LocalDB 자동 인스턴스를 만들지 못해서 생긴 문제였다.문제 상황현재 운영 DB는 Ubuntu 서버의 Docker MSSQL에 있다.Ubuntu Server ↓Docker ↓mssql-db ↓SurvivalGame DB하지만 테스트가 운영 DB에 직접 붙으면 안 ..

AI 모델을 학습시킬 때, 손실(loss)이 큰 데이터를 우선적으로 학습시키는 것은 상식적인 접근이다. 오답 노트처럼 틀린 문제를 다시 풀어보는 원리다. 하지만 오차가 가장 큰 데이터만 탐욕적으로(greedy) 고르면 부작용이 생긴다.첫째, 예전에 학습해둔 쉬운 영역의 데이터를 까먹는 망각 현상이 발생한다.둘째, 데이터 자체에 오류가 있거나 노이즈가 심한 경우, 오차가 영원히 줄어들지 않아 모델이 그 데이터에만 갇혀버린다.이 문제를 해결하려면 '현재 오차가 큰 영역(활용)'과 '최근에 확인하지 않은 영역(탐색)' 사이의 균형이 필요하다. 이를 수학적으로 제어하는 방법이 UCB(Upper Confidence Bound) 알고리즘이다.Max UCB의 개념전체 데이터를 여러 구역으로 나눈 뒤, 각 구역마다 U..

MSSQL 백업과 복구 테스트까지 끝내고 나니 다음으로 신경 쓰인 건 디스크였다.홈 서버는 클라우드 서버처럼 스토리지를 쉽게 늘릴 수 있는 환경이 아니다. 특히 Docker는 기본 설정으로 오래 운영하면 로그와 빌드 캐시가 생각보다 많이 쌓인다.처음에는 컨테이너만 잘 떠 있으면 된다고 생각했는데, 운영 쪽으로 넘어가니 “잘 실행되는 것”만큼 “계속 버틸 수 있는 것”도 중요했다.오늘 목표오늘 목표는 아래와 같았다.Docker 로그 사용량 확인 ↓컨테이너 로그 로테이션 설정 ↓기존 컨테이너에 설정 반영 ↓Docker 이미지 / 빌드 캐시 정리 정책 정리먼저 현재 로그 사용량 확인Docker 컨테이너 로그는 보통 아래 경로에 쌓인다./var/lib/docker/containers현재 사용량을..

자동 배포까지 끝나고 나니 다음으로 신경 쓰인 것은 DB였다.앱은 GitHub에 코드가 있고 Docker 이미지로 다시 만들 수 있다. 하지만 DB 데이터는 한 번 날아가면 코드처럼 다시 clone할 수 없다.이전에는 테스트 배포 단계라 DB를 지우고 다시 만들어도 괜찮았다. 하지만 실제 데이터가 쌓이기 시작하면 그런 식으로 작업하면 안 된다. 그래서 이번에는 MSSQL 백업과 복구 과정을 먼저 정리했다.오늘 목표오늘 목표는 네 가지였다.MSSQL 수동 백업 성공 ↓백업 파일을 호스트 서버에 저장 ↓자동 백업 스크립트 작성 ↓백업 파일로 실제 복구 테스트백업 파일이 생기는 것만 확인하고 끝내고 싶지는 않았다. 실제로 복구까지 해봐야 안심할 수 있다고 생각했다.현재 MSSQL 구조MSSQL..

소프트웨어에서 1.2.3과 같이 세 개의 숫자로 버전을 표시하는 방식을 유의적 버전 명세(Semantic Versioning)라고 한다. 일반적으로 줄여서 SemVer라고 부른다. SemVer는 소프트웨어와 라이브러리에서 널리 사용되는 버전 관리 규칙이다. 각 숫자는 왼쪽부터 Major, Minor, Patch를 의미한다.[ Major ] . [ Minor ] . [ Patch ] 1 2 3 처음에는 단순히 업데이트 횟수에 따라 숫자를 올리는 방식이라고 생각했다. 하지만 SemVer의 핵심은 변경된 코드의 양이 아니라, 이전 버전과의 호환성이 유지되는가에 있다.각 자리의 의미와 업데이트 기준첫 번째 자리: Major 버전Major 버전은 기존 버전과의 하위 호환..

지난 글까지는 ASP.NET Core 게임 서버를 Ubuntu 홈 서버에 직접 배포했고, EF Core Migration과 SQL Server 문제까지 정리했다.그때 배포는 이런 식이었다.cd ~/docker/game/git pulldocker build -t survivalgame:test .cd ~/docker/composedocker compose up -d --force-recreate survivalgame처음에는 이 방식도 나쁘지 않았다. 서버에 직접 들어가서 로그를 보고, 컨테이너 상태를 확인하면서 배포하니까 오히려 확실하다는 느낌도 있었다. 그런데 몇 번 반복해 보니 바로 단점이 보였다.코드를 조금 고칠 때마다 서버에 접속하고, git pull 하고, 이미지 빌드하고, Compose를 다시..

Concurrency Control (동시성 제어)여러 트랜잭션이 동시에 데이터에 접근할 때 데이터의 일관성을 유지하는 기법 목적데이터 무결성 유지트랜잭션 간 충돌 방지데이터베이스 일관성 보장발생 가능한 문제Lost Update두 트랜잭션이 같은 데이터를 수정하여 한쪽 결과가 사라짐T1 : A = A + 100T2 : A = A - 50 최종 결과가 잘못될 수 있음.Dirty Read아직 Commit되지 않은 데이터를 읽음T1 : UPDATET2 : READT1 : ROLLBACK T2는 잘못된 데이터를 읽게 됨.Non-Repeatable Read같은 데이터를 두 번 읽었는데 값이 달라짐T1 : SELECTT2 : UPDATE + COMMITT1 : SELECT 대표 기법Locking데이터 사용 전에 잠..

지난 글에서는 ASP.NET Core 게임 서버를 Ubuntu 홈 서버에 올리고, Nginx와 Cloudflare를 통해 으로 접속되도록 만드는 과정까지 정리했다.이번 글은 그 과정에서 따로 발생한 DB 관련 문제를 정리하려고 한다.처음에는 Docker 컨테이너만 잘 뜨면 앱이 바로 실행될 줄 알았다. 그런데 실제로는 방치되어있던 프로젝트를 그대로 가져오는 바람에 실제 애플리케이션이 실행되려면 DB 연결과 스키마 생성을 문제가 발생하고 나서야 해결해나갔다. 여기서 MSSQL 연결 문자열 문제, EF Core Migration 순서 문제, SQL Server의 외래키 제약 조건 문제가 이어졌다.처음에는 “서버에 앱만 올리면 되겠지” 정도로 생각했는데, 실제로는 애플리케이션 코드와 DB 스키마가 운영 환경에..

오늘은 기존에 GitHub에 있던 ASP.NET Core 게임 프로젝트를 홈 서버에 올려서 실제 도메인으로 접속되도록 만드는 작업을 했다. 처음에 Azure에서 배포했다가 무료 기간이 끝나고 연결이 풀렸었는데 바빠서 방치했다가 이제서야 홈 서버를 구축한 김에 옮기는 작업을 시도해봤다. 이전에 Ubuntu 서버 기본 보안 설정, Docker 설치, DB 컨테이너 구성, Nginx 기본 설정까지는 어느 정도 끝내둔 상태였다. 그래서 오늘은 실제 프로젝트를 서버에 올리고, 내가 가진 도메인으로 접속되는지 확인하는 것이 목표였다. 오늘 작업은 간단하게 Docker로 앱을 빌드하고 Nginx로 연결하고 금방 끝날 줄 알았다. 그런데 막상 해보니 앱 컨테이너, MSSQL 컨테이너, Nginx, Cloudflare ..

이번에는 Ubuntu 서버의 기본 보안 작업을 마무리했다.Cloudflare에서 도메인을 관리하고, SSH 공개키 인증을 적용하고, Root 로그인과 비밀번호 로그인을 막고, UFW와 Fail2Ban, 자동 보안 업데이트까지 설정하면서 운영체제 자체를 먼저 단단하게 만드는 데 집중했다.오늘은 그 위에 실제 개발 환경을 올리는 작업을 진행했다.목표는 단순히 Docker를 설치하는 것이 아니라, 앞으로 게임 서버, 자동화 프로젝트, 데이터베이스 연구, 개인 실험 등을 모두 이 서버 위에서 운영할 수 있는 기반을 만드는 것이다.오늘 목표오늘 진행한 목표는 다음과 같았다.Docker Compose 구조 정리PostgreSQL 컨테이너 구축SQL Server 컨테이너 구축Portainer 구축DB 포트를 외부에 ..