11초의 다운타임으로 PostgreSQL 데이터베이스를 마이그레이션 완료

• GOV.UK Notify는 PaaS 종료에 맞춰 400GB PostgreSQL 11 데이터베이스를 자체 AWS 계정의 PostgreSQL 15 RDS로 옮기면서 다운타임을 약 11초로 줄임
• 대상 DB에는 먼저 테이블만 만들고 DMS full load로 데이터를 복사한 뒤, 인덱스와 키 제약을 나중에 적용해 대규모 적재 시간을 줄임
• 원본 DB는 약 13억 행, 85개 테이블, 185개 인덱스, 120개 외래 키 규모였고, 평일에는 초당 약 1,000건의 삽입·수정과 비슷한 수의 읽기가 발생함
• 애플리케이션 재배포에 약 5분이 걸리는 제약 때문에, 같은 자격 증명과 Route53 DNS 가중치 전환을 미리 준비해 실제 전환 시간을 줄임
• DMS는 PaaS와 AWS 지원을 받기 쉬워 선택됐지만, PostgreSQL 간 이전에서는 pglogical 같은 대안이 더 단순했을 가능성이 남음

---

PaaS 종료에 맞춘 Notify 데이터베이스 이전

• GOV.UK Notify는 GOV.UK Platform as a Service에서 호스팅되고 있었고, PaaS 종료에 따라 모든 인프라를 자체 AWS 계정으로 옮겨야 했음
• Notify의 데이터베이스는 PaaS AWS 계정에 있는 AWS RDS PostgreSQL이며, 알림 전송 데이터부터 서비스 팀들이 쓰는 수십만 개 템플릿 내용까지 저장함
• 기존 데이터베이스는 source database, 새 데이터베이스는 target database로 구분해 이전을 진행함
• 핵심 과제는 새 PostgreSQL 데이터베이스를 만드는 일이 아니라, 모든 데이터를 옮기고 애플리케이션 접속 대상을 바꾸는 동안 다운타임을 최소화하는 것이었음

원본 데이터베이스 규모와 서비스 제약

• 원본 데이터베이스는 약 400GB 규모의 PostgreSQL 11이었음
  • 약 13억 행
  • 85개 테이블
  • 185개 인덱스
  • 120개 외래 키
• 일반적인 평일에는 초당 약 1,000건의 삽입 또는 수정이 발생하고, 비슷한 수의 읽기도 발생함
• GOV.UK Notify는 홍수 경보, 여권 신청 진행 상황 같은 중요하고 시의성 있는 알림을 매일 수백만 건 전송함
• 모든 알림 전송이 데이터베이스 접근을 필요로 하므로, 서비스 중단 시간을 짧게 유지해야 했음

DMS로 만든 초기 적재와 지속 복제 구조

• PaaS 팀은 AWS Database Migration Service를 이용한 데이터베이스 이전 방식을 제공함
• DMS는 원본 데이터베이스에서 대상 데이터베이스로 데이터를 옮기는 역할을 하며, 원본 또는 대상 AWS 계정에서 실행할 수 있음
• DMS 작업은 두 단계로 나뉨
  • full load: 특정 시점까지 존재하던 모든 데이터를 테이블 단위로 복사함
  • 지속 복제: 원본 데이터베이스의 새 트랜잭션을 대상 데이터베이스에 재생해 두 데이터베이스를 동기화함
• 애플리케이션이 원본 데이터베이스 대신 대상 데이터베이스를 쓰도록 전환하는 작업은 Notify 팀이 직접 맡음

대상 데이터베이스 준비와 full load

• DMS 인스턴스는 원본 AWS 계정에 생성됨
  • PaaS 팀이 이미 계정 안에 DMS 인스턴스를 설정해 둔 상태라 빠르게 준비할 수 있었음
  • DMS 인스턴스에는 원본과 대상 PostgreSQL 데이터베이스에 접속할 수 있는 자격 증명이 필요했음
• DMS 인스턴스와 대상 데이터베이스는 서로 다른 VPC에 있었기 때문에, VPC peering을 설정해 PaaS VPC의 DMS 트래픽이 공용 인터넷을 거치지 않고 자체 VPC로 라우팅되게 함
• 대상 RDS 인스턴스는 자체 AWS 계정에 만들었고, PostgreSQL 11 지원 종료가 가까워지는 시점이어서 새 데이터베이스는 PostgreSQL 15로 구성함
• pg_dump로 원본 데이터베이스 스키마를 덤프해 스키마 재생성 SQL 파일을 만들고, 처음에는 테이블 선언만 대상 데이터베이스에 적용함
• 외래 키는 full load 시점에 적용하지 않음
  • DMS full load가 외래 키 제약 순서에 맞춰 데이터를 복사하지 않기 때문임
• 기본 키와 인덱스도 full load 전에 만들지 않음
  • 각 삽입마다 인덱스 갱신이 필요해져, 수십억 행을 넣을 때 전체 시간이 크게 늘어날 수 있음
  • 먼저 데이터를 모두 복사한 뒤 인덱스를 추가하는 방식이 더 빨랐음
• full load 작업은 시작 버튼을 누른 시점에 존재하던 데이터를 복사함
  • 그 이후 발생한 새 데이터나 갱신은 full load에 포함되지 않음
  • full load 완료에는 약 6시간이 걸림
• full load 이후 남은 스키마 파일을 적용해 인덱스와 키 제약을 추가했고, 이 작업에는 약 3시간이 걸림

10일간 복제를 유지한 뒤 트래픽 전환

• full load가 끝난 뒤 대상 데이터베이스는 full load 시작 시점의 원본 데이터와 일치했지만, 이후 원본에는 삽입·수정·삭제가 계속 발생함
• DMS의 지속 복제, 즉 change data capture 작업을 시작해 full load 시작 이후의 원본 데이터베이스 transaction log 트랜잭션을 대상 데이터베이스로 보냄
• 복제 프로세스가 따라잡는 데는 몇 시간이 걸렸고, 이후에는 DMS 복제 지연 시간을 모니터링하며 동기화 상태를 확인함
• DMS 복제는 약 10일 동안 백그라운드에서 실행됐고, 사용자에게 미리 공지한 트래픽 이전 시점까지 두 데이터베이스를 동기화함
• 트래픽 전환 절차는 미리 Python 스크립트로 작성함
  • 원본 데이터베이스로 가는 애플리케이션 트래픽을 중단함
  • 복제가 완전히 따라잡았는지 확인함
  • 애플리케이션이 대상 데이터베이스에 접속하도록 허용함
• 일부 애플리케이션은 원본 DB를, 나머지는 대상 DB를 쓰는 상태를 피해야 했음
  • 대상 DB에 생긴 변경은 원본 DB로 반영되지 않기 때문에 사용자에게 불일치한 데이터가 보일 수 있음
• 스크립트는 수동 작업보다 명시적이고 반복 가능하며 빠르게 실행되도록 만들었고, 사전 테스트와 연습에서 최소 40회 사용함
• 목표 다운타임은 5분 미만이었고, 마이그레이션 시간은 한밤중을 피하면서도 비교적 조용한 토요일 저녁으로 잡음

11초 다운타임을 만든 DNS 전환

• 원본 데이터베이스 트래픽 중단은 애플리케이션 연결에 pg_terminate_backend를 호출하는 방식으로 처리했고, 1초 미만이 걸림
• 애플리케이션이 원본 DB에 다시 연결하지 못하도록 PostgreSQL 사용자 비밀번호도 변경해 재연결 시 인증 오류가 나게 함
• DMS는 대상 데이터베이스에 복제 상태 테이블을 만들고 매분 갱신했으며, 마이그레이션 스크립트는 이 테이블로 원본과 대상 간 지연을 확인함
• 추가 안전장치로, 애플리케이션이 원본 DB 접근을 멈춘 뒤 스크립트가 원본 DB에 단일 레코드를 쓰고 대상 DB에 도착할 때까지 기다림
• 애플리케이션의 데이터베이스 연결 정보는 SQLALCHEMY_DATABASE_URI 환경 변수로 제공됨
  • 기존 형태는 사용자명, 비밀번호, RDS 위치가 포함된 postgresql://[e-mail]:5432 형식임
  • 데이터베이스 위치나 자격 증명을 바꾸려면 애플리케이션 재배포가 필요했고, 재배포에는 약 5분이 걸림
• 재배포로 인한 추가 다운타임을 피하기 위해 마이그레이션 전에 두 가지를 준비함
  • 원본과 대상 데이터베이스에 같은 사용자명과 비밀번호를 가진 사용자를 생성함
  • AWS Route53에 database.notifications.service.gov.uk DNS 레코드를 만들고 TTL을 1초로 설정함
• DNS 레코드는 처음에 가중치를 원본 100%, 대상 0%로 둠
• 애플리케이션 URI는 공통 사용자명·비밀번호와 새 도메인 이름을 쓰도록 미리 바꿈
• 실제 전환 시에는 스크립트가 AWS의 DNS 가중치를 대상 100%로 바꾸고 TTL 1초가 만료되기를 기다림
• 2023년 11월 4일 토요일 저녁 전환 시점에는 대상 데이터베이스와 원본 데이터베이스 사이의 지연이 몇 초 수준이었음
• 마이그레이션 스크립트 실행 결과, 애플리케이션은 원본 DB 접근을 멈추고 새 대상 DB를 사용하기 시작했으며 다운타임은 약 11초였음

DMS 선택에 대한 평가와 이후 작업

• DMS는 GOV.UK PaaS에서 잘 지원됐고 AWS 지원도 받을 수 있었기 때문에 선택됨
• 향후 PostgreSQL 간 데이터베이스 이전을 다시 한다면 pglogical 같은 대안 도구를 더 검토할 계획임
• DMS는 다른 도구보다 복잡성과 익숙하지 않은 복제 프로세스를 더했을 가능성이 있음
• 데이터베이스 이전 이후 다음 단계는 애플리케이션 이전임
• GOV.UK Notify 애플리케이션은 AWS Elastic Container Service로 옮길 예정이며, 진행 과정은 이후 공유될 예정임

[GN⁺]

Hacker News 의견들

• 우리도 비슷한 마이그레이션을 AWS RDS Blue-Green Deployments로 했고, 데이터베이스는 조금 더 컸지만 다운타임은 약 20초였고 작업량도 훨씬 적었음. 아직 이 스레드에서 언급되지 않은 게 의외임
  기본적으로 원하는 변경사항을 넣은 새 Blue/Green 배포를 띄우면, 기존 blue 구성이 트래픽을 계속 처리하는 동안 AWS가 논리 복제로 green 배포를 동기화해 줌
  green에는 쓰기만 하지 않으면 수정이나 테스트, 부하 테스트도 가능하고, 쓰기는 계속 live인 blue로 들어간 뒤 green으로 복제됨
  준비가 되면 switch 명령을 실행하고, AWS가 동기화 확인, 쓰기와 연결 중단, 복제 따라잡기 대기, 데이터베이스 이름 변경, 연결과 쓰기 재개를 처리함
  우리 기준 다운타임은 20초 미만이었고, primary와 여러 읽기 복제본까지 포함한 전체 구성이 문제 없이 전환됐음. AWS가 데이터베이스 URL도 바꿔주므로 설정을 바꿀 필요도 없었고, green이 blue가 되고 기존 blue는 old blue가 되며 나중에 삭제하면 됨
  강력 추천하지만 계정 간 이동 같은 경우에는 안 될 수 있는 등 제한은 있음: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-...

  • Blue/Green에 +1. 다만 이 사례는 계정 간 이동 때문에 못 썼을 것 같음. MySQL과 Postgres 모두에서 써봤고, MySQL은 본문보다 초당 쿼리 수가 두 자릿수 더 높았는데 둘 다 매끄러웠음
    문서, 특히 제한사항을 읽고 또 읽어야 함. 개발 환경에서 부하를 건 상태로 테스트 실행하고, 스테이징에서도 다시 해보는 게 좋음
    아니면 그냥 운영에 YOLO로 넣어도 아마 괜찮을지도 모름
  • MySQL 5.7에서 8.0으로 메이저 엔진 버전 업그레이드할 때 RDS Blue/Green 배포를 썼고, 다운타임 관점에서는 훌륭했음. API에서 관측된 다운타임은 13초 정도였던 것 같음
    다만 RDS Blue/Green이 임의의 변경에 쓸 수 있는 건 아니라는 걸 어렵게 배웠음. 우리 경우에는 엔진 버전을 올리는 데만 쓸 수 있고 내리는 데는 못 쓴다는 걸 알게 됨
    MySQL 8.0에서 저장 프로시저 하나가 아주 가끔 실패해서 5.7로 되돌리는 옵션을 검토했는데, 그건 불가능했음
  • 기존에 암호화되지 않은 RDS 스토리지를 Blue/Green으로 암호화해 본 사람이 있는지 궁금함
  • 데이터베이스에 접근하는 애플리케이션을 어떻게 중지하고 재시작했는지 궁금함. ECS에서 도는 작업이 여럿 있고, 내려가는 데 1분, 다시 올라오는 데 몇 분 걸릴 수 있음
  • Route53 Groups와 Blue/Green 구성에 +1. 우리도 PostgreSQL 업그레이드에서 비슷하게 했고, AWS R53 groups와 자체 Rails ActiveRecord 트랜잭션 패치로 진행 중 쿼리를 재시도해서 다운타임 없이 처리했음
    트레이드오프는 몇 초 동안 일부 요청이 느려졌다는 것임
    DNS Groups와 재시도 조합은 이런 작업에 꽤 쓸 만한 메커니즘임
    사용한 도구: https://github.com/shayonj/pg_easy_replicate

• 들어오는 Postgres 쿼리를 “일시정지”하는 방법은 여러 가지가 있고, 예를 들어 pgbouncer를 써서 실패시키지 않고 복제가 따라잡을 때까지 지연시킨 뒤 새 데이터베이스에서 계속 진행하게 할 수 있음
  뭔가 잘못돼서 복제가 따라잡지 못하면 일시정지를 풀고 그 쿼리들이 기존 데이터베이스에서 실행되게 하면 됨
  그러면 11초의 다운타임이 0~11초의 추가 페이지 로드 시간으로 바뀜. 더 중요하게는, 지금까지 쿼리 실패를 본 적 없는 수천 명의 데이터베이스 사용자 중 버그 있는 오류 처리 경로가 있거나 단 한 번의 실패 쿼리로 배치 작업 전체가 망가지는 경우에도 부수 피해가 훨씬 줄어듦

  • 쿼리를 멈추는 건 가능하겠지만, 이미 진행 중인 트랜잭션도 멈출 수 있는지 궁금함. 그건 어떻게 동작함?

• https://knock.app/blog/zero-downtime-postgres-upgrades와 비교해 보면 흥미로움. 관련 논의는 https://news.ycombinator.com/item?id=38616181에 있었음
  당시 논의 상당수는 “몇 분 다운타임을 피하려고 너무 복잡한 것 아니냐”로 귀결됐음. 이번 사례가 증명처럼 보이고, AWS Data Migration Service를 쓰고 DNS 항목을 바꿔 운영으로 넘긴 뒤 11초 다운타임을 감수하면 된다는 쪽으로 보임

  • 여기에는 “그냥”이 없음. 핵심 교훈은 “배운 점”에 들어 있음

    DMS를 선택한 이유는 GOV.UK PaaS에서 잘 지원됐고 AWS 지원도 받을 수 있었기 때문입니다. 앞으로 PostgreSQL에서 PostgreSQL로 데이터베이스를 마이그레이션한다면 pglogical 같은 대체 도구를 더 시간을 들여 검토할 것입니다. DMS는 다른 도구에서 겪었을 것보다 더 많은 복잡성과 익숙하지 않은 복제 과정을 추가했을 수 있습니다. 이는 AWS가 PostgreSQL 간 마이그레이션에 대해 직접 말하는 내용과도 맞습니다
    여기서 메시지는 “그냥 DMS를 써라”가 아님

  • https://cloud.google.com/database-migration/docs/postgres/qu...로 비슷한 작업을 해본 사람이 있는지 궁금함. AWS DMS와 비슷하게 동작함?
  • DMS는 내부적으로 pglogical을 쓰는 것처럼 보이지만 함정이 많음. 하드웨어 수준 복제가 아니라서 큰 행, 큰 열, 큰 테이블에서 문제가 생길 수 있고 외래 키도 제대로 다루지 못함
    일부 특수 데이터 타입은 아예 처리하지 못할 수도 있음. 마이그레이션 뒤에는 시퀀스도 갱신해야 하며, 안 그러면 중복 기본 키 오류가 날 수 있음
    적절한 기본 키가 없으면 항상 전체 행을 한 번에 복사하지 않기 때문에 문제가 생길 수도 있음
    데이터베이스가 같은 AWS 계정 안에 있고 4~5분 다운타임을 감수할 수 있다면, 글로벌 데이터베이스나 스냅샷을 이용한 하드웨어 수준 복제가 더 쉬울 가능성이 높음

• 최근 자체 호스팅하던 3TB PostgreSQL 데이터베이스를 12에서 16으로 옮기고, Ubuntu 18에서 Ubuntu 22로 전환했음. 동시에 여러 확장도 업그레이드해야 했고, 특히 Timescale은 모든 조합을 만족하는 호환 버전이 없었음
  읽기 전용 복제본을 업그레이드하는 방식으로 진행했음: 시작은 PG12, Ubuntu 18, TS2.9였고, 먼저 Ubuntu 22에서 PG12와 TS2.9를 유지한 읽기 전용 복제본을 만들었음
  이후 유지보수 모드로 들어가 모든 서비스를 멈추고, 읽기 전용 복제본을 분리한 뒤 Ubuntu 22에서 PG12를 PG15로 올리되 TS2.9는 유지했음
  다음으로 PG15와 TS2.9에서 TS2.13으로 올리고, 마지막으로 Ubuntu 22에서 PG15를 PG16으로 올리며 TS2.13을 유지했음
  끝으로 서비스를 새 데이터베이스 서버에 다시 연결하고 모든 서비스를 재개한 뒤 유지보수 모드를 종료함
  모든 데이터베이스 업그레이드 단계는 Ansible로 충분히 테스트하고 자동화했지만, 테스트 중에는 나오지 않았던 문제가 하나 발생해 다운타임이 약 30분으로 늘어났음. 우리 용도에서는 충분히 허용 가능한 수준이었음
  논리 복제를 썼다면 마지막 순간의 예기치 못한 문제를 줄일 수 있었을 것이고, 다음 업그레이드 주기에는 이 접근을 검토할 예정임

  • 우리도 거의 같은 업그레이드 경로를 최근 따랐음. 다만 당시에는 Timescale이 PG16을 아직 지원하지 않아서 PG15 + TS 2.12에서 멈췄음
    업그레이드 다운타임을 줄이려고 논리 복제도 검토했지만, 데이터베이스 스키마와 DDL 명령은 복제되지 않기 때문에 Timescale이 끼어 있으면 권장되지 않는 것 같았음
    Timescale이 내부에서 해야 하는 기반 스키마 변경은 대체로 하이퍼테이블 청크 크기와 들어오는 쓰기 패턴의 함수일 테니 계획하거나 타이밍을 맞출 수는 있겠지만, pg_upgrade가 끝나는 동안 짧은 유지보수 창을 잡는 쪽보다 잠재적 복잡성과 위험이 너무 크다고 봤음

• 이런 저다운타임·무중단 마이그레이션의 적은 오래 실행되는 쿼리임
  예를 들어 30분 걸리는 단일 update 쿼리가 있으면, 그 쿼리를 죽이고 롤백하거나 30분의 가용성 상실을 감수해야 함
  아는 한 현재 진행 중인 쿼리를 마이그레이션하는 방법은 없음

  • 소프트웨어 엔지니어링 프로젝트라면 트랜잭션 시간을 그보다 훨씬 짧게 제한하는 편이 좋음. statement_timeout 설정이 친구임
    극도로 긴 트랜잭션이 있다면 그게 실행되는 때를 피해서 전환할 수 있을 가능성이 높음. 무작위 발생이 아니라 예약 작업 같은 결과이길 바람
    트랜잭션 시간 제한과 장애 조치 구성, 예를 들어 기존 primary를 실패시키는 방식, 그리고 pgbouncer 같은 것을 조합하면 다운타임 대신 느려지는 시간을 꽤 정밀하게 제어할 수 있음
    솔직히 더 걱정되는 건 전체 스택과 의존하는 외부 캐시 DNS 서버가 DNS TTL을 제대로 지키는지임
    하지만 보통 앱에서 10여 초 다운타임을 피하는 게 치명적이지는 않으니, 자신에게 더 단순한 해법을 선택하는 게 맞음
  • 개인적으로는 30분짜리 update 쿼리가 극도로 비효율적으로 작성된 게 아니거나, 일회성 대규모 데이터 마이그레이션이 아닌 경우를 상상하기 어려움
    물론 전자는 실제로 많이 존재함. 분 단위나 시간 단위 작업을 밀리초 단위로 바꾸는 재미를 꽤 많이 봤음
  • 새로 배웠음. 30분 이상 걸리는 쓰기는 어떤 성격인지 궁금함
    어떤 데이터와 어떤 사람들이 그런 데이터베이스 쓰기를 다루기에, 상위 계층에서 큐로 더 잘게 쪼개지 않고 DB 엔진이 그렇게 오래 일하도록 의존해야 하는지 궁금함

• database.notifications.service.gov.uk에 1초 TTL을 가진 AWS Route53 DNS 레코드를 만들고, 마이그레이션 스크립트가 AWS의 DNS 가중치를 대상 데이터베이스 위치로 100% 보내도록 바꾼 뒤 TTL 만료까지 1초 기다렸다는 부분이 이상함
  그러면 앱이 다음에 데이터베이스에 쿼리하려 할 때 대상 데이터베이스를 쿼리하게 된다고 했는데, 이 말은 그들의 ORM이나 Python 기본 동작이 매 쿼리마다 DNS 조회를 하면서 막힌다는 뜻임?
  해석된 주소를 어느 정도 시간 동안 캐시하지도 않고, 연결 풀링이나 재사용도 하지 않는다는 건가?

  • 아마 OS의 getaddrinfo나 gethostname이 이 동작을 할 것임. Python은 시스템 수준 호출을 거의 재구현하지 않으므로 시스템 설정에 의존함
    TTL 1초가 지켜졌다면 1초 동안 캐시됐겠지만, DNS 조회 라이브러리와 특히 캐싱 DNS 서버가 TTL을 완전히 지키지 않는 것도 드물지 않음. 솔직히 그게 관측된 다운타임 일부를 설명할 수도 있음

• 좋음. 우리는 방금 RDS에서 약 2TB 데이터, 8개 데이터베이스가 들어 있는 Postgres 클러스터 3개를 Postgres 14에서 16으로 마이그레이션했음. 00:00부터 04:00까지 내려갔음
  먼저 Cloudflare Workers에서 도는 아주 가벼운 대체 사이트인 “유지보수 모드”를 켰고, Terraform으로 DB를 쓰는 모든 앱을 0으로 스케일다운했음
  AWS 웹 UI에서 업그레이드 버튼을 눌러 pg_upgrade로 14→15를 수행하고 완료를 기다린 뒤, 다시 눌러 15→16을 진행했음
  데이터베이스가 연결을 받기 시작할 때까지 기다렸는데, ready로 표시되기 전에도 연결은 받는 것 같았고 AWS가 pg_upgrade 외에 더 하는 일이 있는 듯했음
  이후 VACUUM ANALYZE; REINDEX DATABASE CONCURRENTLY를 시작했음. 버전 간 성능 이슈를 피하고 새 버전의 성능 개선을 활용하려는 의도였음
  앱들을 다시 띄우기 시작했고, 모든 앱에 컨테이너가 몇 개씩 떠 있는 걸 기다린 뒤 트래픽을 받기 시작하고 유지보수 사이트를 껐고, 잠자리에 들었음
  REINDEX CONCURRENTLY는 가장 큰 DB에서 18시간 더 돌아갔지만 아무것도 막지 않았음
  다음에는 다운타임을 피하려고 AWS Blue/Green 배포를 쓸 예정임. 이번에는 Blue/Green이 지원하는 14의 최소 마이너 버전인 14.9가 아니어서 못 썼음
  내가 직접 한다면 AWS 비용을 내지 않고, 논리 복제와 로드 밸런서로 Blue/Green을 직접 구성할 것임

  • 나라면 제자리 업그레이드에 pg_upgrade --hardlinks를 쓰겠음
    자체 온프레미스 Postgres 인스턴스에서 2TB DB도 1분 미만에 처리해 봤음

• GOV.UK Notify는 GDS가 영국 공공기관에 제공하는 서비스 묶음의 일부임. GOV.UK Pay와 GOV.UK PaaS도 함께 있고, 원래는 Government As A Platform으로 알려져 있었음

• DMS는 형편없는 마이그레이션 도구임. 여러 마이그레이션 문제와 거의 한 달 싸우다가 포기했음
  text와 json 타입을 마이그레이션하지 못했고, AWS 지원도 해결책을 제시하지 못했음
  AWS Blue/Green을 초기 테스트 단계에서 써봤고, 그 덕분에 거의 무중단 업그레이드가 현실이 됨

  • DMS가 나쁜 마이그레이션 도구라고 생각한다면, 외부 대상으로 지속 복제에 써보면 됨
    완전히 망가져 있음

• 흥미롭지만 정부가 애초에 왜 AWS를 쓰는지 모르겠음. 이건 제품-시장 적합성을 찾으려고 해킹하는 스타트업도 아니고, 마케팅 주도 트래픽 급증을 예측 못 해 대응하는 상황도 아님
  이런 서비스가 장기적으로 필요하다는 걸 알고 있고, 사용 패턴도 꽤 잘 예측할 수 있음
  공공부문 클라우드를 만들거나 합리적인 온프레미스 접근을 채택할 수 있음. 자금, 조율, 기술 리더십이 필요하지만 장기적으로 납세자에게 막대한 비용을 절감해 줄 것임
  공공부문 IT는 대체로 엉망이지만, 그 안에서 일하는 좋은 엔지니어들도 있다는 건 알고 있음

  • 스타트업으로서 “클라우드”, 즉 PaaS를 쓰는 이유는 트래픽 급증을 잡기 위해서가 아니라 집중 때문임
    하드디스크와 드라이버, 또는 그 클라우드 버전인 스토리지와 Ansible 같은 것을 들고 뛰어다니는 1시간은 고객에게 필요한 것을 만드는 데 쓰지 못하는 1시간임
    정부라고 왜 달라야 함?
    정부가 자동차를 직접 만들 거라고 기대하지 않고, Volkswagen이나 Renault에서 사기를 기대함. 정부에 운송 수요가 분명히 있어도 그렇다. 그런데 왜 IT 인프라는 직접 만들라고 고집하는지 모르겠음
  • 정부의 필요와 수요가 예측 가능하다고 생각한다면 정치를, 특히 지난 10년간의 영국 정치를 따라보지 않은 것임
    그리고 팬데믹처럼 완전히 예상 밖에서 튀어나오는 일도 있음. 팬데믹 동안 수요에 맞춰 확장할 수 있었던 점은 공공부문이 상용 퍼블릭 클라우드를 써야 한다는 핵심 시연 사례 중 하나였음
  • 영국 정부 전체는 주요 퍼블릭 클라우드와 일부 온프레미스·코로케이션을 함께 운영함
    Gov.UK의 여러 반복과 클라우드 간 마이그레이션을 다룬 9월 발표 https://youtube.com/watch?v=mpY1lxkikqM&pp=ygUOUmljaGFyZCB0b...를 보는 걸 추천함
    적어도 영국 정부에서는 조달 요구사항 때문에 몇 년마다 사용량 기준 견적을 시장에 다시 내야 함
    예를 들어 Oracle Cloud가 가격이 10분의 1이면 그쪽이 계약을 따낼 가능성이 높고, 그러면 계약 기간 동안 Oracle로 마이그레이션해야 하며, 이후 더 싼 다른 클라우드가 나오면 다시 옮겨야 할 수도 있음
  • EU의 많은 나라가 공공 클라우드를 만들었을 것임. 크로아티아에서는 직접 겪었고, 거기에 배포해야 했던 개발자 중 하나였음
    인생에서 본 것 중 최악이었음. VB.NET, Web Forms, 오래된 SharePoint, Basic, 심지어 앱 전체가 거대한 저장 프로시저 덩어리인 레거시도 많이 다뤄봤는데도 그랬음
    AWS, Azure, Google Cloud는 적어도 최종 사용자, 즉 개발자를 염두에 두고 만들어졌음. 반면 정부 클라우드는 비용을 가능한 모든 곳에서 깎는 게 첫 목표인 최저가 입찰자가 설계하고 구축했음
  • 영국은 모르겠지만, 미국에서는 AWS가 오래전부터 GovCloud를 제공해 왔고, 솔직히 거기서 본 많은 인프라와 비교하면 축복에 가까움
    반대로 독일 정부 의료기관의 사내 데이터센터를 운영하던 정말 훌륭한 인프라·운영 담당자들도 만난 적이 있음. 그곳의 문제는 기술도 사람도 아니라, 인프라 팀과 엔지니어링 팀 사이의 모든 상호작용에서 병목이 되려는 관리진과 프로세스가 100%였음