User Migration ISSUE Report

개요

24일 오전 캐치 1.0에서 사용자가 저장한 주소를 불러오지 못하여 주문을 하지 못하는 에러가 발생했다.

원인은  전날 23일 오후 4시경에 진행했던 데이터 마이그레이션이 원인이다.

원인

• 2.0 회원 데이터 마이그레이션 중 1.0에서 사용중인 테이블에 잘못된 데이터를 덮어썼다.
• 1.0의 배송지의 경우 2.0의 데이터 베이스를 사용중이었다. 구체적으로 어떤 테이블이 어떤 서비스에서 사용되는 지 파악하지 못한채 같은 이름의 테이블을 그대로 덮어쓰게 되어 문제가 발생했다. 해당 테이블의 내용은 사용자 고유 id와 제3자 암복호화를 진행할 때 필요한 키를 가진 단순한 구조의 테이블이었다.

경위

• 우선은 GCP-SQL에 1.0 prd에서 사용하는 실제 데이터의 일부분이 존재하고 있었다. 배송지 정보와 사용자 암호화 키 데이터 였다. 해당 데이터는 GCP KMS에서 암호화의 결과물, 복호화의 대상 그리고 암복호화의 키였다.
• leopard-crypto의 api를 호출하면 다시 사용자 아이디와 서버 공용의 키를 가지고 암복호화를 하는데 내가 생성했던 데이터가 공용키가 달랐던 것이다. 
• 암복호화에 필요한 전달인자는 사용자 키, 서버공용키, 대상 데이터 였는데 내가 마이그레이션에서 생성 할때 사용한 서버 공용키가 A라면 운영 서버에서 사용하는 키는 B였던 것이다. 
• 결국 운영서버에서 복호화를 요청하면 암호화에서 사용한 키와 다른 값으로 복호화를 요청했기 때문에 500 에러를 반환하고 더이상 결제를 진행하지 못한것이다. 
• 데이터 마이그레이션을 진행한 것은 4시30분경 문제가 해결된 것은 12시 정도 였으니 거의 8시간 정도 주문이 먹통이 이었던 것이다.

조치

• 기존에 운영중인 데이터 베이스에다가 마이그레이션을 할 수 없다. 지금 처럼 운영에 지장을 줄 수도 있고 오픈전까지 데이터를 반복적으로 생성해야하는 데 그때 마다 이런일이 얼마든지 발생할 수 있다.
• leopard-crypto 서버를 두개로 분리하여 사용한다. 다만 암호화에 필요한 공용키를 같은 값을 사용하여 일치된 데이터로 암복호화 할 수 있도록 한다. 오픈 후에 안정화 되었다고 판단이 되면 개발서버의 공용 키를 분리하여 사용한다.
  
  • 굳이라는 생각이 든다. 어차피 두개의 키를 사용하여 다시 키를 생성하는 것 뿐인데 어차피 공통 프로퍼티에 하드코딩해놓고 쓰는데 다가 추측이 어려운 값도 아니다. 서버를 두개띄우지 말고 하나의 api만 사용하게 하는 것이 나은것 아닌가 하고 생각했다.

결론

• 나의 첫번째 사고. 입사후에 계속 2.0만 관여했기 때문에 운영중인 서비스에 영향을 줄일이 없었다. 그런데 DB테이블을 공유하고 있었다니 놀랍다. CTO님 말씀처럼 새하얀 도화지인줄 알았는데 그게 아니였던 것이다. 시스템 구조적으로 그런 문제가 있었다. 나 자신도 crypto service에서 두개의 키로 데이터를 생성하는 것을 전혀 모르고 있었다. 역시 데이터 베이스 관련 작업을 하면 신중 또 신중해야한다.
• 문제가 발생했던 금요일 당일은 물론이고 주말내내 자책감이 들었다. 상급자의 사소한 행동조차 곱씹으며 나를 차별 혹은 무시하는 것 처럼 받아드려지고 명치가 쓰려왔다. 적성에 대한 고민도 덩달아 찾아왔다. 시간이 흐른 것에 비해 나의 역량이 부족한 것이 아닌가 하는 의구심이 샘솟았다. 
• 오늘 아무런 생각없이 주어진 스펙대로 상품 api를 작성했다. 그러면서 이만하면 나쁘지 않다는 자기효용감을 많이 느끼고 식사시간에 다같이 모여 앉아 스몰토크를 주도하며 에너지를 많이 회복했다.
• 결국 모든 것은 마음먹기에 달렸다. 잘하는 데 가장 중요한 것은 잘하려는 마음이다. 나자신을 믿고 지금 주어진 일에 충실하자.