1 minute read

애플리케이션은 시간이 지남에 따라 필연적으로 변화한다.

  • 새로운 제품이 출시되거나
  • 사용자 요구사항이 더 잘 이해되거나
  • 비즈니스 환경이 변화함에 따라 기능이 추가되거나 수정된다.

애플리케이션의 기능을 변경하려면 애플리케이션이 저장하는 데이터도 변경해야 한다. 새로운 필드 또는 레코드 유형을 캡처해야 하거나 기존 데이터를 새로운 방식으로 표시해야 할 수도 있다.

관계형 데이터베이스의 스키마는:

  • 일반적으로 데이터베이스의 모든 데이터가 하나의 스키마를 준수한다고 가정한다.
  • 스키마 마이그레이션을 통해 스키마를 변경할 수는 있지만, 어느 한 시점에는 정확히 하나의 스키마가 적용된다.

이와 대조적으로 스키마 온 리드(“스키마리스”) 데이터베이스의 스키마는:

  • 스키마를 적용하지 않으므로 서로 다른 시점에 작성된 이전 데이터 형식과 최신 데이터 형식이 혼합되어 있을 수 있다.
  • 데이터 형식 또는 스키마가 변경되면 애플리케이션 코드도 그에 따라 변경되어야 하는 경우가 많다.

그러나 대규모 애플리케이션에서는 코드 변경이 즉각적으로 이루어지지 않는 경우가 많다:

  • 서버 측 애플리케이션의 경우: 롤링 업그레이드를 수행한다.
    (롤링 업그레이드: 한 번에 몇 개의 노드에 새 버전을 배포하고 새 버전이 원활하게 실행되는지 확인한 후 점진적으로 모든 노드에 배포하는 방식)
    이렇게 하면 서비스 중단 시간 없이 새 버전을 배포할 수 있으므로 더 자주 릴리스하고 더 나은 진화 기능을 제공할 수 있다.

  • 클라이언트 측 애플리케이션의 경우: 브라우저나 앱 업데이트는 사용자에 달려 있다.

이전 버전과 새 버전의 코드, 이전 데이터 형식과 새 데이터 형식이 시스템에 동시에 공존할 수 있다. 시스템이 계속 원활하게 작동하려면 양방향 호환성을 유지해야 한다:

  • 하위 호환성: 최신 코드가 이전 코드에서 작성된 데이터를 읽을 수 있다.

  • 상위 호환성: 이전 코드가 최신 코드로 작성된 데이터를 읽을 수 있다.

이전 버전과의 호환을 지키는 하위 호환성은 일반적으로 달성하기 어렵지 않다.

하지만, 상위 호환성은 더 까다롭다. 이전 코드가 최신 버전의 코드가 추가한 내용을 무시해야 하기 때문이다.

데이터 인코딩과 관련하여 살펴볼 과제들

  • JSON, XML, 프로토콜 버퍼, Thrift, Avro 등 데이터를 인코딩하는 여러 형식
  • 데이터 인코딩이 스키마 변경을 처리하는 방법과 이전 데이터와 새 코드가 공존해야 하는 시스템을 지원하는 방법
  • 이러한 형식이 데이터 저장과 통신에 어떻게 사용되는지를 알아본다. 예를 들어, REST(Representational State Transfer), RPC(원격 프로시저 호출), 액터 및 메시지 큐와 같은 메시지 전달 시스템이 있다.