brunch

브런치북 한국의 마틴 파울러가 되기 19화

라이킷 7 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 안영회 습작 Oct 13. 2023

분산 환경 무결성 문제와 상태도 연결하기

한국의 마틴 파울러가 되기

일민 형은 대전에서 일할 때부터 나에게 인터넷을 통해 공부를 자극하는 사람이었습니다. 예전에는 내 블로그 댓글을 통해서 자극을 주었는데, 지금은 가끔 보는 그의 페이스북 글에서 자극을 받습니다. 이 글도 그의 짧은 글에서 자극을 받아 씁니다.

-1을 처음 보는데?

일단 -1이란 배지 숫자는 처음 보기에 놀람 표기를 남겼습니다.

어떻게 -1이 나온 것일까요? 일단, CRUD에 익숙한 분이라면 RDBMS를 쓰지 않아서 그렇다고 생각할 수 있습니다. 정확하게 말하면 DBMS가 제공하는 트랜젝션 관리 기능을 쓰지 않은 것이죠. 일민 형의 글에 등장하는 '분산 환경이라'에 힌트가 있는데, 불특정 다수의 접속을 준비해야 한다면 갑자기 요청이 늘었을 때 낭패가 생기는 것을 막는 방식을 택할 수 있습니다.

2년 전에 <트레이드오프와 아키텍트 그리고 개발자의 소통 문제>에서 상충관계(trade-off)에 대해 쓴 적이 있는데, 시스템 구성에 대한 결정을 내리다 보면 마치 거래하듯이 하나를 얻고 하나를 잃는 식으로 생각해야 하는 부분들이 있습니다.

-1이 등장하는 예를 제 멋대로 상상해 보면, 알림은 거의 모든 사용자에게 최대한 자주 줘야 합니다. 왜냐? 사업적으로 보면 인터넷 공간에서는 사용자 접속이 바로 손님의 발길이고, 돈을 벌 기회를 뜻합니다. 그러니 새로운 일이 있을 때마다 소식을 알려서 사용자의 클릭을 유발해야 합니다. 그런데, 1,000명 정도가 동시에 왔더니 시스템이 다운되면 곤란하겠죠. 이를 막는 보편적인 장치는 일종의 시스템 Lock을 만드는 DBMS의 트랜젝션 기능을 쓰지 않는 것입니다.

Eventual Consistency 혹은 최종 일관성

찾아보니 6년 전에 Eventual Consistency에 대해 언급한 제 글이 있었습니다. 거기 보면 DBMS에 '무결성을 완전 위임하지 않기'라고 설명을 붙였습니다.

앞서 말씀드린 페북 글에서 '동시성은 신경 쓰지 않은 건가. 최종 일관성으로라도 어찌하지'라는 표현과 일맥상통하는 추정입니다.

지난여름에 Kent Beck이 쓴 <Eventual Business Consistency>를 비롯하여 Eventual Consistency를 다루는 방법은 여러 가지가 있습니다. 한동안 저는 거기에 대해 관심이 많기도 했습니다. 개발을 그만두고 경영을 업으로 하면서 서비스 기획이나 시스템 설계까지만 개입을 했기 때문에 베터코드에서 동료로 일해 온 영모님에게 아이디어를 주고 대부분 그가 구현했는데, 고맙게도 일부는 글로도 흔적이 남아 있습니다.

5년 전에 DZone에서 본 아이디어가 흥미로워 영모님에게 전했더니 그가 쓴 네 편의 연재가 있습니다. 제목이 <REST 기반의 간단한 분산 트랜잭션 구현>이네요. 그리고, 다른 사람이 만든 미들웨어(메시지 큐)를 이용해서 무결성을 보장하는 식으로 확장한 <MSA에서 메시징 트랜잭션 처리하기>라는 글도 있네요. 비교적 최근의 글은 golang 사례를 다룬 <Golang에서 카프카 컨슈머 그룹과 재시도로 결과적 일관성 구현하기>입니다. 우리 회사 메인 언어가 golang인 탓이죠.

잊고 있었는데 3년 전에 <결과적 일관성인가? 최종적 일관성인가?>이란 글을 쓸 때 영모님에 저에게도 의견을 물었던 기억이 얼핏 떠올랐습니다. 찾아보니 기억하지 못하는 이유가 있었습니다.[1]

무결성이 깨진 엔티티는 신뢰를 얻을 수 없다

여기까지 쓰고 끝내려다가 최근 동료를 도와 상태도를 활용하는 경험과 연결하기로 마음먹었습니다. 마침 이전 두레이 기록 검색 과정에서 발견한 글도 자극이 되었습니다.

엔티티(Entity) 성격의 데이터[2]는 거래(Transcation) 이력에 준하는 기록이어야 생명력을 가집니다. 우리가 물건을 산 후에 환불을 받을 때, 카드 영수증이 있어야 하는 이유는 무엇인가요? 환불을 요구하는 손님의 주장이나 기억이 무결성을 부여하기 위함입니다. 일종의 공증과도 유사한 수단입니다. 소프트웨어는 우리의 아이디어나 알고리듬을 전자적으로 작동하도록 구현하는 수단입니다. 이에 따라 엔티티를 구현할 때는 반드시 무결성을 정체성으로 삼아야 합니다. 무결성이 깨지만 존재 이유가 부정 받을 수 있으니까요.

상태도 경험과 연결하기

다시 상태도와 연결하도록 하겠습니다. 오라클이 전 세계적으로 큰돈을 벌게 해 준 데에는 이러한 무결성을 간단한 조치만으로 보장해 주는 기술을 제공했기 때문입니다. RDBMS의 강력함은 바로 그 기능과 오랜 개선에 있습니다. 하지만, 어떤 이유에서건 이를 쓸 수 없게 된다면 별도의 조치가 필요합니다.

제 경우도 16년 컨설턴트 겸 소프트웨어 설계자 경험 중에서 딱 두 번 그러한 시도를 한 적이 있었습니다. 한 번은 다수의 규모가 다른 시스템이 함께 작동해야 하는 경우라서 당연하게도 RDBMS 범위를 훌쩍 넘는 일이라 그랬습니다. 두 번째도 역시 다수의 시스템의 상호 작용이 필요했지만 그보다는 사람과 배치 프로그램이 일정한 규칙에 따라 함께 상호 작용해야 했기 때문에 상태도를 써서 그 규칙을 명확하게 표현한 후에야 프로그램으로 구현할 수 있었습니다.

2012년 정도로 기억하는데 REST 도입을 위해서 Eventual Consistency 개념과 구현법을 공부할 때는 알지 못했던 지식과 경험을 지금은 갖고 있습니다. 당시는 특정 기술만 보니까 알지 못했던 관점이 보입니다. 결국 소프트웨어는 인간의 편익을 위한 아이디어와 알고리듬을 구현하는 도구일 뿐이란 사실을 명확하게 알면, 상태도가 바로 Eventual Consistency 구현을 위한 완벽한 pseudocode[3]란 사실을 깨닫게 됩니다.