답변.

다중 서비스 아키텍처에서는 각 서비스가 종종 자체 데이터베이스를 담당합니다. 데이터 스키마 마이그레이션 관리를 위해서는 전문화된 마이그레이션 도구(Liquibase, Flyway, Alembic)를 사용해야 하며, 이를 자동화 및 결과의 예측 가능성을 위해 CI/CD 파이프라인을 통해 실행해야 합니다.

좋은 실천은 각 마이그레이션이 버전 관리 및 아이도포턴시(동일한 변경 사항을 다시 실행해도 오류나 불일치를 초래하지 않음)를 갖춘 마이그레이션 스크립트로 준비되는 것입니다.

Python Alembic을 사용한 마이그레이션 예:

from alembic import op
import sqlalchemy as sa

def upgrade():
    op.add_column('user', sa.Column('status', sa.String(8)))

def downgrade():
    op.drop_column('user', 'status')

주요 특징:

• CI/CD 수준에서의 마이그레이션 자동화
• 아이도포턴시 — 구조에 손상을 주지 않고 반복적으로 적용할 수 있는 능력
• 데이터 스키마의 버전 관리 및 롤백

함정 질문들.

운영 환경에서 마이그레이션 없이 데이터베이스 스키마를 수동으로 변경할 수 있습니까(수동 DDL)?

이는 절대 권장되지 않습니다: 스키마 상태에 대한 제어를 잃게 되어 롤백/변경 사항 추적에 어려움이 생깁니다.

마이크로서비스 아키텍처에서는 모든 서비스에 대해 마이그레이션을 중앙 집중화해야 한다는 것이 사실입니까?

아니요, 각 팀/서비스는 자신의 스키마와 마이그레이션 파이프라인에 대한 책임이 있습니다. 중앙 집중화는 서비스의 독립성 원칙에 반합니다.

마이그레이션 롤백은 완전히 안전합니까?

아니요: 특히 데이터 구조나 형식이 변경된 경우(예: 필드가 삭제되고 데이터가 손실된 경우) 변경 사항을 항상 롤백할 수 있는 것은 아닙니다. 롤백을 고려하여 마이그레이션을 설계하는 것이 좋습니다.