90DaysOfDevOps (Day 23)

고태규·6일 전

devops

DevOps

목록 보기

22/25

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 23 - SQL Server 2022 on Linux Containers and Kubernetes from Zero to a Hero!

1. Docker 란?

Docker는 어플리케이션을 컨테이너라는 격리된 환경에 담아 실행하는 프로그램이며, 컨테이너를 위한 런타임을 제공한다.

1-1. Docker의 핵심 요소

이미지 (Image) :
- 어플리케이션을 실행하기 위한 읽기 전용 템플릿
- Dockerfile이라는 파일을 통해 필요한 파일 세트의 스냅샷 (Layer)를 순서대로 쌓아 만듦.
- Redhat이나 Window 같은 다른 베이스 이미지를 기반으로 하여 추가적인 커스터마이징을 통해 생성 가능
컨테이너 (Container) :
- Image라는 템플릿을 실행한 인스턴스
- 격리되어있으나, 외부와 통신이 가능하며, host의 모든 CPU와 메모리 리소스에 접근 가능
- Layer 구조 : 여러 개의 읽기 전용 이미지 레이어와 한 개의 쓰기 가능한 컨테이너 레이어로 구성
- 여러 Container가 동일한 이미지에서 실행될 경우, 읽기 전용 레이어는 서로 공유하여 효율성을 높임.
레지스트리 (Registry) :
- Docker Image를 저장하고 공유하는 중앙 저장소
- 자신만의 Image를 만들거나, 다른 사람이 레지스트리를 통해 게시한 이미지를 사용 가능함.

1-2. Docker와 데이터 영속성

Container는 '상태가 없는 (Stateless)' 특성을 가진다.
Container 내부의 프로세스가 종료되면 컨테이너는 멈추고, 데이터는 사라진다.

따라서, Container는 데이터를 영구적으로 보존해야 하는 DB 환경에는 적합하지 않다.
이러한 문제점을 해결하기 위해 Host 컴퓨터의 저장공간을 Container에 연결하는 Volume을 사용한다.

이를 통해 Container가 사라져도 데이터는 Host에 영속적으로 안전하게 보관된다.

DB 백업과 데이터 파일은 반드시 이처럼 Container 외부에 존재해야 한다.

2. SQL Server 컨테이너란?

SQL Server 컨테이너는 격리된 환경에서 실행되는 SQL Server 컨테이너 이미지의 인스턴스이다.

SQL Server 컨테이너 이미지는 리눅스 (레드햇, 우분투 등) OS 위에 SQL Server (Ver 17, 19, 22등) 가 사전 설치된 패키지를 의미한다.

해당 이미지에는 SQL Server의 핵심 엔진과 도구 등 실행에 필요한 최소한의 바이너리 (bin, lib)만 포함되어있다.

❓그렇다면 SQL Server Container를 사용하는 이유가 뭘까?

VM 환경과 비교하였을 때, 컨테이너가 제공하는 명확한 이점으로 인해 사용한다.

VM 환경에서는 VM 인스턴스의 리부트 시점과 영향에 대한 고민, 다른 개발자 환경에 영향을 끼칠 수 있다는 불안과 고민이 항상 존재한다.

하지만, Container는 모든 개발자가 각자 격리된 자신만의 Container를 사용하므로 이러한 고민과 문제들이 해결된다.

이식성 : Container가 지원되는 곳이라면 어떤 OS에서든 동일하게 실행됨.
일관성 : 모든 팀원이 동일한 SQL Server 이미지와 도구를 사용하므로 환경 차이로 인한 문제를 방지 가능
경량성 : OS 전체를 포함하는 VM과 달리 매우 가벼워 CPU와 메모리 사용량이 적음.
효율성 : 빠른 배포가 가능하고, OS 패치가 필요없어 서비스 중단 시간을 줄일 수 있음.

3. SQL Server를 사용해야 하는 이유

SQL Server는 단순한 DB가 아니라 '데이터 관리 시스템'이다.
컨테이너 환경의 이점과 SQL Server 자체가 가진 기능들을 통해 개발과 운영 환경에 사용한다.

지능형 쿼리 처리 :
- 쿼리를 자동으로 분석하는 튜닝하는 내장 인텔리전스를 갖추고 있음.
보안, 확장성, 가용성 :
- TDE (Transparent Data Encryption) : 데이터 파일을 투명하게 암호화하는 기능이 내장
  (PostgreSQL 등 다른 DB에는 기본 내장 기능이 아님)
- Active Directory 연동 : 사용자 인증을 위한 AD 연결이 기본적으로 내장
데이터 가상화 (PolyBase) :
- T-SQL 쿼리만으로 Oracle, MongoDB, PostgresSQL, 객체 스토리지 (S3등)와 같은 외부 데이터 소스를 로컬 테이블처럼 직접 조회하고 통합할 수 있음.
연결성 및 확장성 :
- 클라우드 환경과 원활하게 연결
- ODBC를 통해 다양한 데이터 소스와 연결이 가능
- T-SQL에 대한 확장된 지원과 함꼐 JSON 데이터 처리를 지원

4. 도커의 아키텍처와 에코시스템

도커는 클라이언트-서버 구조로 작동하는 어플리케이션이다.

4-1. Docker 아키텍쳐

도커 데몬 (Docker Daemon) : 서버
- 백그라운드에서 항상 실행되는 지속적인 프로세스
- API 요청을 수신하여 Image, Container, Volume과 같은 도커 객체를 관리하는 서버 역할
도커 클라이언트 (Docker Client) : CLI
- 사용자가 Docker와 상호작용하는 수단 (Commane Line Interface)
- 사용자가 명령어를 입력시, Docker Daemon으로 해당 명령을 전송하여 작업을 요청
도커 레지스트리 (Docker Registry)
- Docker Image를 저장하고 관리하는 중앙 저장소
- 대표적 공개 레지스트리는 'Docker Hub', 필요에 따라 Private 레지스트리 구축하여 사용 가능

4-2. 컨테이너의 기본 라이프사이클

Build (빌드): Dockerfile 설명서를 바탕으로 docker build 명령어를 실행하여 새로운 Container Image를 생성
Push (푸시): 생성된 Image를 docker push 명령으로 도커 레지스트리에 업로드하여 공유 및 백업
Pull (풀): 레지스트리에 있는 이미지를 docker pull 명령으로 로컬 서버에 다운로드
Run (런): 로컬에 받아진 이미지를 docker run 명령으로 실행하여 Container 실행

5. 윈도우 환경에서 Docker 설치와 WSL

5-1. 윈도우 환경에서 Docker

Docker는 현재 무료인 '커뮤니티 에디션 (CE)'과 유료 기술 지원이 포함된 '엔터프라이즈 에디션(EE)'으로 나뉜다.

특히, 윈도우 11 환경에서 Docker Desktop을 설치할 때 'WSL (Windows Subsystem for Linux)'를 백엔드로 사용하는 것이 권장된다.

WSL은 윈도우 내에서 가벼운 Linux VM을 생성하며, Docker Desktop은 해당 VM 내부에서 Docker Daemon을 실행하여 리눅스 Container를 관리한다.

하지만, Docker desktop의 직원 수 250명 이상의 기업에서 상업적 용도로 사용할 경우의 유료화로 인하여 '파드맨 (Podman)'이라는 플랫폼이 대안으로 제시되었다.

Podman은 레드햇에서 개발하였으며, 현재 윈도우용 파드맨 데스크톱은 무료로 사용할 수 있다.
또한, 백그라운드에서 항상 실행되는 데몬 (에이전트) 없이 작동하기 때문에 Docker보다 더 안전한 아키텍처로 평가받기도 한다.

5-2. WSL

WSL은 Docker의 기반 기술일 뿐만 아니라, 그 자체의 플랫폼으로도 개발 환경을 제공한다.

wsl --install

해당 명령어로 간단히 설치할 수 있으며, WSL 내에 직접 MySQL, PostgresSQL, SQL Server 등을 설치하여 Docker의 대안으로 활용할 수도 있다.

추가적으로, Windows 환경에서 WSL (Windows Subsystem for Linux)를 백엔드로 사용하는 Docker Desktop의 경우, 이미지와 데이터는 Windows 파일 탐색기에서 직접 접근할 수 없는 특별한 위치에 저장된다.

Image와 Volume 데이터는 C:\Users\<사용자>\AppData\Local\Docker\wsl 경로 아래의 data와 distro 폴더 내에 저장
해당 폴더들은 Windows의 NTFS가 아닌, 리눅스의 ext4 FileSystem으로 포맷되어 있기 때문에 Windows 파일 탐색기에서 내용을 확인할 수 없음. ( \\wsl.localhost\ 경로를 통해 접근해야함)

5-3. Docker 시스템 정보 확인 (docker info)

docker info 명령어는 도커 엔진의 버전, 스토리지 드라이버 (overlay2 등), 컨테이너 수 등 시스템 전반의 정보를 보여준다.

Windows에서 이 명령을 실행하면 종종 warning: no swap support 라는 경고 메시지가 나타날 수 있다.

하지만, 해당 경고는 WSL 백엔드를 사용하는 환경에서는 파일 마운팅과 관련된 것으로, 실제 운영에 영향을 주지 않는 중요하지 않은 경고이므로 걱정할 필요가 없다고 한다.

6. Docker 사용법

6-1. 이미지 검색 및 관리

이미지 검색: Docker Hub에서 이미지를 검색 할 수 있음.

docker search <이미지 이름>

Tag 확인: '마이크로소프트 컨테이너 레지스트리 (MCR)'에서 특정 버전의 이미지 태그만 필터링하고 싶을 때, PowerShell 스크립트와 AI 툴을 활용하여 효율적으로 원하는 정보를 추출할 수 있음.

# 전체 태그 목록을 변수에 저장
PS C:\Users\<사용자명>> $allTags = Invoke-WebRequest -Uri 'https://mcr.microsoft.com/v2/mssql/server/tags/list' | ConvertFrom-Json
# 저장된 목록에서 '22'가 포함된 태그만 필터링
PS C:\Users\<사용자명>> $allTags.tags | Where-Object { $_ -like '*22*' }

이미지 목록: 로컬에 저장된 이미지의 저장소 (Repository), 태그, 이미지ID, 생성 날짜, 크기를 확인할 수 있음.

Docker Images

이미지 삭제:

docker rmi <이미지 ID 또는 이름>

6-2. 컨테이너 실행 및 관리

컨테이너 목록:

# 현재 실행 중인 Container 조회
docker ps
# 중지된 컨테이너까지 모두 조회
docker ps -a

컨테이너 중지 및 삭제:

실행 중인 Container 중지

docker stop <컨테이너 ID 또는 이름>

중지된 Container 삭제

docker rm <컨테이너 ID 또는 이름>

6-3. 모든 컨테이너/이미지 한번에 정리하기

이미지 검색:

docker stop $(docker ps -aq)

Tag 확인:

docker rm $(docker ps -aq)

이미지 목록:

docker rmi $(docker images -q)

이미지 삭제:

docker volume prune

7. Image 심층 분석

7-1. docker inspect

docker inspect <이미지 ID>

해당 명령어를 사용하여 이미지의 Label, 환경 변수 등 상세한 내부 정보를 JSON 형식으로 확인할 수 있다. (ex. SQL Server Image의 정확한 버전 정보를 레이블 섹션에서 찾아낼 수 있음.

7-2. 이미지 무결성 검증 : 콘텐츠 다이제스트

Image를 pull 할때 '콘텐츠 다이제스트 (Content Digest)'라는 고유한 해시 (hash) 값이 함께 제공된다.

docker inspect 결과의 RepoDigests 필드에서 해당 값을 확인할 수 있으며, 이를 통해 User가 다운로드한 Image가 레지스트리에 있는 원본과 정확히 동일하고 변조되지 않았음을 보장받을 수 있다.

7-3. 이미지 매니페스트 (Image Manifest)

이미지 매니페스트는 이미지의 구성 요소 (Layer, 아키텍처 등)을 설명하는 명세서와 같은 파일이다.

팻 매니페스트 (Fat Manifest):
- 하나의 이미지 이름 아래에 여러 다른 CPU 아키텍처 (X86_64, ARM64 등)을 위한 이미지 정보를 모두 담고 있는 매니페스트
- 사용자가 docker pull을 실행하면, Docker Daemon이 현재 시스템의 아키텍처를 확인하고, 팻 매니페스트를 참조하여 그에 맞는 Image를 자동으로 다운로드

7-4. 오프라인 환경에 Image 저장/로드

docker save : 로컬 이미지를 .tar 압축 파일로 저장
docker load : .tar 파일로부터 이미지를 로드

해당 기능은 인터넷 연결이 없는 폐쇄망 환경에서 이미지를 옮겨야 할 때 유용한 기능이다.

8. 유니온 파일 시스템과 Copy-on-Write

Docker Container의 File System은 '유니온 파일 시스템 (Union File System)'이라는 방식으로 동작한다.

Union File System이란, 여러 개의 다른 디렉토리를 하나의 디렉토리처럼 보이도록 통합 (Union) 하고 겹쳐서 보여주는 기술이다.

이는 Image의 효율적인 관리와 Container의 빠른 생성을 가능하게 한다.

8-1. Layer 구조

docker pull 시 여러 개의 Pull complete 메세지를 확인할 수 있는데, 여러 개의 Layer를 다운로드 하는 과정이다.

읽기 전용 이미지 레이어 (Read-only Image Layers):
- Docker Image는 단일 파일이 아니라 OS -> 의존성 -> SQL 엔진 -> 어플리케이션 순서로 쌓아올린 여러 개의 '읽기 전용 Layer'로 구성됨.
- 해당 Layer들은 한 번 만들어지면 절대 변하지 않으며, 여러 Container가 해당 Layer들을 공유하여 디스크 공간을 효율적으로 사용함.
쓰기 가능 컨테이너 레이어 (Writable Container Layer):
- Container가 실행되면, 읽기 전용 이미지 Layer들 맨 위에 각 Container마다 고유한 '쓰기 가능 Layer'가 하나 추가됨.
- Container 내에서 발생하는 모든 변경사항 (파일 생성, 수정, 삭제)은 최상위 쓰기 가능 레이어에만 기록
- Container가 삭제되면 쓰기 가능 layer만 사라짐.

8-2. Copy-on-Write (CoW)

Copy-on-Write(CoW)는 "쓸 때 복사한다"는 의미로, 읽기 전용인 이미지 레이어의 파일을 컨테이너가 어떻게 수정할 수 있는지 설명하는 메커니즘이다.

쓰기 요청 발생: 컨테이너 내부의 프로세스가 특정 파일 (ex. 설정 파일)을 수정하려고 함.
(해당 파일은 현재 읽기 전용 이미지 레이어에 존재)
파일 위치 확인: Docker는 먼저 최상위의 쓰기 가능 레이어에 해당 파일이 있는지 확인함.
(처음에는 파일이 없음)
파일 복사 (Copy): Docker는 하위의 읽기 전용 레이어에서 원본 파일을 찾아, 그 파일의 복사본을 만들어 최상위의 쓰기 가능 레이어로 가져옴. (Copy 과정)
복사본 수정 (Write): 컨테이너는 쓰기 가능 레이어에 있는 복사본 파일에 변경 사항을 기록함. (원본 파일은 그대로 보존된 채, 컨테이너는 수정된 버전을 사용하게 됨)

8-3. DB 환경에서의 비효율성

앞서 설명한 CoW 방식은 File 단위로 동작하기 때문에 RDBMS와 같은 환경에서는 비효율적이다.

예를 들어, 10GB짜리 거대한 DB 파일이 있다고 가정시, UPDATE 쿼리로 몇 KB의 데이터만 변경되어도 CoW 메커니즘은 10GB 파일 전체를 쓰기 가능 레이어로 복사하는 작업을 수행해야 하여 매우 비효율적이다.

이러한 이유로, DB의 데이터 파일처럼 크고, 쓰기 작업이 빈번한 파일들은 CoW의 영향을 받지 않는 '도커 볼륨 (Docker Volume)'에 저장하여 관리하는 것이 필수적이다.

9. SQL Server 컨테이너 실행 및 설정

9-1. 컨테이너 실행 명령어

SQL Server 컨테이너를 실행 데모를 위한 깨끗한 환경을 위해 기존 컨테이너와 볼륨을 삭제하는 과정을 거친 후,

docker run --env "ACCEPT_EULA=Y" --env "SA_PASSWORD=<YourStrong!Passw0rd>" --memory 2048m -p 1433:1433 --name sql2022-latest --hostname sql2022-latest --restart unless-stopped -d --mount source=sqlvolume,target=/var/opt/mssql mcr.microsoft.com/mssql/server:2022-latest

해당 명령어를 이용하여 SQL Server 2022 컨테이너를 실행한다.

컨테이너 실행 후에는 Windows Defender 방화벽에서 액세스를 허용할지 묻는 창이 나타나며, '액세스 허용'을 선택해야 한다.

9-2. 명령어 옵션 상세 분석

-e (환경 변수):
- 컨테이너 내부에서 사용될 환경변수 지정
- SQL Server Image에는 다양한 환경변수가 존재하지만,
  ACCEP_EULA=Y (라이선스 동의) 와 SA_PASSWORD (관리자 비밀번호 설정)은 최소한의 필수 조건
- MSSQL_PID로 에디션 지정 가능
- --env-file 옵션으로 환경 변수들을 파일로 관리 가능
-p (포트 매핑):
- -p 1433:1433 -> 호스트 PC의 1433번 포트와 Container의 1433번 포트를 매핑
- 여러 개의 SQL Server Container를 실행하기 위해서는 호스트 포트를 반드시 다르게 지정하여 충돌을 피해야함 (ex. -p 1401:1433 or -p 1402:1433)
--name 및 --hostname:
- Container에 고유한 이름 (--name)을 부여하고, 컨테이너 내부에서 SELECT @@SERVERNAME 실행시, 표시될 호스트 이름 (--hostname)을 지정하여 관리를 용이하게 함.
- --name과 --hostname을 동일하게 맞추는 것이 편리
--restart unless-stopped:
- 사용자가 직접 docker stop 명령으로 중지하지 않는 이상, Docker Daemon이 시작되거나 재시작될 때 Container를 자동으로 재시작시키는 정책
- 서버 재부팅 시에도 SQL Server Container가 자동으로 실행되도록 보장
-d (Detached):
- Container를 백그라운드에서 실행
- 명령 실행 후 바로 Terminal을 계속 사용할 수 있음.
--mount (볼륨 연결):
- Host PC의 sqlvolume이라는 볼륨을 Container의 데이터 경로 (/var/opt/mssql)에 연결하여 데이터를 영구적으로 보존
- 데이터베이스 운영의 핵심 포인트
- source (출발지), target (목적지) 구문을 사용

10. 실행 중인 컨테이너 관리 및 상호작용

10-1. 컨테이너 내부 접속 및 탐색

docker exec -it <컨테이너이름> bash: 실행 중인 컨테이너 내부에 접속하여 상호작용이 가능한(interactive terminal, -it) bash 셸을 사용함.
내부에서 ps -ef 명령을 실행하면, SQL Server와 관련된 최소한의 프로세스만 실행되는 것을 통해 컨테이너의 완벽한 격리성을 확인할 수 있음.
ls /var/opt/mssql 명령으로 데이터, 로그, 인증서 폴더 등 SQL Server의 실제 파일 구조를 탐색할 수 있음.

10-2. 리소스 동적 관리

Container는 기본적으로 Host의 모든 리소스를 사용하려고 시도한다.

docker update 명령어를 사용하게 되면, 이미 실행중인 Container의 리소스 제한을 동적으로 변경할 수 있다.

docker stats: 현재 컨테이너의 CPU, 메모리 등 리소스 사용량을 실시간으로 모니터링함.
docker update --cpus=2 --memory=1g <컨테이너이름>: 해당 컨테이너를 CPU 코어를 최대 2개까지, 메모리를 최대 1GB까지만 사용하도록 즉시 제한함. (docker stats로 확인하면 제한 적용 확인 가능)

10-3. 볼륨 공유 정책

두 개의 SQL Server 컨테이너는 동일한 볼륨을 공유할 수 없다.

만약 시도할 경우, 두 번째 컨테이너는 이미 사용 중인 데이터베이스 파일에 접근하려다 잠금 문제로 인해 오류(17113)를 발생시키며 시작되지 않는다.

각 SQL Server 인스턴스는 고유한 데이터베이스 파일 세트와 볼륨을 가져야한다.

11. 백업 및 복원

백업 파일 복사:
docker cp <로컬경로/파일.bak> <컨테이너이름>:<컨테이너경로> 명령어로 로컬 PC의 백업 파일을 컨테이너 내부로 복사
파일 소유권 변경 :
SQL Server 2019 이상 버전의 컨테이너는 보안 강화를 위해 시스템 최고 권한 root가 아닌, 권한이 제한된 mssql 사용자로 실행된다.

로컬에서 복사된 파일은 기본적으로 root 소유이므로, mssql 사용자가 이 파일을 읽을 수 없으므로, docker exec <컨테이너이름> chown mssql:mssql <파일경로> 명령어를 사용하여 파일 소유권을 반드시 변경해야 한다.
데이터베이스 복원:
SSMS (SQL Server Management Studio)를 사용해 localhost로 컨테이너에 접속한 뒤, 권한 문제가 해결된 백업 파일을 이용해 GUI로 데이터베이스를 복원한다.

복원 후 ALTER DATABASE ... SET COMPATIBILITY_LEVEL = 160과 같은 명령으로 호환성 수준을 최신으로 맞출 수 있다.
파일 복사 (컨테이너 → 로컬):
docker cp <컨테이너이름>:<컨테이너경로/파일> <로컬경로> 명령어를 사용하여 컨테이너 내부의 에러 로그 파일 등을 로컬 PC로 가져올 수 있다.

12. 문제 해결 및 네트워킹

12-1. 로그 확인

SQL Server 내부 로그 : 전통적인 DBA 방식대로 SSMS에서 sp_readerrorlog를 실행하여 로그를 확인할 수 있음.
Docker 로그 : docker logs <컨테이너이름> 명령어가 훨씬 편리하고 강력하다.
특히 -f 옵션을 추가하면 로그를 실시간으로 스트리밍할 수 있어, 로그인 실패나 비밀번호 복잡성 정책 위반으로 인해 컨테이너가 시작되지 않는 등의 문제를 즉시 파악하고 해결하는 데 매우 유용함.

12-2. 네트워킹

Docker는 기본적으로 bridge 라는 가상 네트워크를 사용한다.

하나의 Host에서 여러 개의 SQL Server Container를 실행하려면, docker run 시 -p 옵션의 Host Port를 다르게 지정해야 한다.

첫 번째 컨테이너: -p 1433:1433
두 번째 컨테이너: -p 1401:1433

또한, docker network inspect bridge 명령을 실행하면, bridge 네트워크의 게이트웨이 IP와, 여기에 연결된 각 컨테이너에 할당된 내부 IP 주소 등 상세한 네트워크 구성을 확인할 수 있다.

13. 컨테이너를 활용한 무중단 업그레이드

Container의 가장 강력한 장점 중 하나로, 데이터 손실이나 긴 Downtime 없이 버전을 업그레이드 하는 방법이다.

예시

구버전 (예: mcr.microsoft.com/mssql/server:2022-CU8-ubuntu-20.04) 컨테이너를 영속성 볼륨 (sqlvolume)과 함께 실행하고, SSMS로 접속하여 테스트 데이터베이스 (testDB)를 생성
해당 컨테이너를 중지하고 삭제. 컨테이너는 사라졌지만, testDB의 데이터 파일은 sqlvolume에 존재함.
최신 버전 (latest)의 SQL Server 이미지를 사용하여 '동일한 볼륨(sqlvolume)'에 연결하여 새 컨테이너를 실행
결과적으로, SQL Server가 시작되면서 볼륨에 저장된 구버전 데이터 파일들을 감지하고, 자동으로 최신 버전으로 업그레이드를 진행.
이 시간 동안 잠시 접속이 안 될 수 있으며, 에러 로그에는 'master' is upgrading...과 같은 메시지가 기록됨. 잠시 후 SELECT @@VERSION으로 버전을 확인하면 최신 버전으로 올라간 것을 볼 수 있고, testDB 역시 그대로 존재하며 정상적으로 접근 가능함.

이러한 방식은 데이터의 영속성을 보장하면서도 애플리케이션만 손쉽게 교체할 수 있는 컨테이너의 핵심 철학을 명확히 보여준다.

덕분에 DBA는 복잡한 마이그레이션 절차 없이, 단 몇 개의 명령만으로 다운타임을 최소화하며 안전하게 시스템을 최신 상태로 유지할 수 있다.

14. 결론

강연자는 자신의 경험을 바탕으로 고가용성이 필요한 프로덕션 환경의 SQL Server 구성에는 쿠버네티스보다 '윈도우 서버 장애 조치 클러스터 (Windows Server Failover Cluster, WSFC)'가 더 실용적이고 안정적인 선택이라고 주장한다.

쿠버네티스는 DBA가 배우고 운영하기에 매우 복잡하며 학습 곡선이 가파름.
성능 문제 발생 시 추상화된 여러 계층 때문에 원인을 찾기가 매우 어려움.
Active Directory 등 윈도우 기반 기술과의 자동 통합이 부족함.

DBA입장에서 쿠버네티스의 단점에 비해, WSFC는 수십 년간 SQL Server를 위해 검증된 기술이며, 설치가 매우 쉽고 비용 효율적이다.

따라서, Docker는 개발, 테스트, CI/CD 파이프라인에서 격리된 환경을 신속하게 구축하고 복제하는 데 매우 유용하므로 적극적으로 사용해야 한다고 한다.

다만, 프로덕션 환경의 고가용성이 필요할 때는 WSFC를 우선적으로 고려하는 것이 좋다고 한다.

추가적으로, Docker의 대안으로 Podman이 최근에 큰 주목을 받고 있으며, 백그라운드에서 항상 실행되는 데몬 (에이전트) 없이 작동하기 때문에 Docker보다 더 안전한 아키텍처로 주목받고 있음을 강조한다.

결론: 해당 프레젠테이션은 DBA가 자신의 업무 환경에 맞게 컨테이너 기술을 어떻게 사용해야 하는지에 대한 실용적인 가이드이다.

고태규

이전 포스트

90DaysOfDevOps (Day 22)

다음 포스트