NoSQL의 BASE속성으로 인한 단점은 단점이 아니다

블로그를 한번 쭉 보니 제가 데이터베이스 공부를 하면서 NoSQL을 굉장히 깊게 공부했는데 BASE에 대해서 다루지 않았더라구요. 

 

이번 포스팅에서는 RDBMS에 ACID가 있다면 NoSQL에는 BASE가 있다! BASE에 대해서 알아보겠습니다. 그리고 BASE에서 가장 중요한 Eventual Consistency에 대해서 깊이있게 알아보도록 하겠습니다. 

 

 

BASE

BASE는 ACID와 마찬가지로 NoSQL의 특징을 잘 알려주는 특징들의 앞글자를 따서 만든 단어입니다. 

 

BASE에 들어가기 앞서 ACID에 대해서 베이스 지식이 없으시면 아래의 링크에서 참고해주세요!

 

https://coding-review.tistory.com/296

트랜잭션과 ACID (자바에서 트랜잭션을 다루는 방법에 대한 관점으로)

 

BASE는 Basically Available, Soft State, Eventual Consistensy의 앞글자를 따서 만든 단어입니다. ACID와 다른 점이라면 역시 ACID는 RDBMS의 특징을 보여주는 단어였다면 BASE는 한 문장으로 표현이 가능하다는 점이 있겠습니다. 

 

BASE를 한 문장으로 정리해보자면 "기본적으로는 가용성을 유지하며 데이터가 결국 일관적이게 되는 소프트한 상태" 입니다. 

 

각각의 특징에 대해서 잠깐 정리하고 넘어가도록 하겠습니다. 

 

• Basically Available : 시스템은 장애가 나더라도 항상 작동해야 한다는 의미입니다. 클라이언트에 의해 요청이 들어오면 장애가 나는 한이 있더라도 응답을 해야한다는 의미이죠. 
• Soft State : Soft State는 데이터 소스가 반드시 항상 일관성을 유지할 필요는 없다는 특징입니다. 이는 뒤에 이어지는 Eventually Consistency와 일맥상통하는 이야기입니다. 
• Eventually Consistency : 간단하게 Eventually Consistency를 정리하자면 단어 그대로 결국 일관성을 유지하게 된다는 말입니다. 

이제 BASE에서 가장 중요한 특징인 Eventually Consistency에 대해서 알아보도록 하죠

 

 

Eventual Consistency

Eventual Consistency는 분산환경인 NoSQL에서 결국 모든 노드에 일관적으로 반영된다는 데이터 모델링 컨셉입니다. 이 말은 쿼리를 날렸을 때 시간이 좀 지난 다음 결과적으로는 일관성을 유지한다는 의미입니다. 

 

Eventual Consistency를 사용하는 이유에는 몇가지이유가 있는데 그 중에서 가장 핵심적인 이유는 5G 시대에 따라 네트워크 속도가 빨라졌는데 데이터를 운반하는 속도가 네트워크 속도에 비해 떨어지는 현상이 생겼기 때문에 높은 성능을 챙기기 위해서입니다. 

 

뭐 그건 그렇다 치는데 저는 처음에 이 개념을 접했을 때 '과연 이게 정상적으로 돌아갈까?' 를 먼저 생각했던 것 같습니다. 그러니까 결국 일관성이 맞는다는 얘기는 트랜잭션 중간에 데이터가 바뀌더라도 바뀐 것을 트랜잭션이 인지하지 못하고(일관성이 보장되지 않으니) 바뀌기 전 데이터로 가공할 수 있다는 얘기입니다. 

 

즉, 쉽게 말해서 Dirty Read 부정합 문제가 발생할 수 있다는 얘기이죠. 

 

그럼에도 불구하고 Eventual Consistency가 필요한 이유

NoSQL 데이터베이스는 RDBMS과 다르게 비정형 데이터들을 수용할 수 있습니다. 비정형 데이터를 담는다는 얘기는 개발자로 하여금 많은 프로그래밍적인 도전과제가 생긴 것입니다. 

 

왜냐하면 페이스북같은 애플리케이션에서는 ACID 표준이 필요가 없기 때문이죠. 때문에 페이스북은 Cassandra NoSQL 데이터베이스를 사용하기로 결정했습니다. 

 

페이스북 입장에서는 더 빠르고 더 역동적인 서비스가 필요했습니다. 때문에 기존 ACID 대신 Eventual Consistency를 받아들일 수 밖에 없던 것이죠. 

 

뭐가 그렇게 좋았길래 ACID특성을 버리고 Eventual Consistency를 선택했던걸까요? 이제 Eventual Consistency의 이점에 대해서 설명해보겠습니다. 

 

 

Eventual Consistency 장점

많은 회사들이 기존 ACID를 버리고 NoSQL을 선택함으로써 더높은 가용성, 더높은 성능, 더높은 확장성을 가질 수 있게 되었습니다. 

 

가용성부터 설명해볼까요? 

 

기존 CAP 정리에서 C를 버리고 A를 선택한 AP 데이터베이스가 높은 가용성을 가진다는 것은 잘 알고 계실겁니다. 하지만 Eventual Consistency가 데이터 정합성을 버린 것은 아닙니다. 말 그대로 결국 정합성이 맞게 되니까요. 

 

CAP 정리에 대한 베이스 지식이 없으신 분들은 아래의 링크를 참고해주세요!

 

https://coding-review.tistory.com/312

CAP 정리, PACELC 정리

 

그러니 Eventual Consistency는 높은 가용성과 일관성을 모두 챙기게 된 것입니다. 

 

성능적으로는 어떨까요? NoSQL은 RDBMS에 비해 분산환경에 적합한 데이터베이스입니다. 분산환경에서 사용할 수 있는 데이터베이스 튜닝 방식으로는 클러스터링, 레플리케이션, 샤딩이 있었죠? 

 

NoSQL은 데이터베이스를 분산시켜 성능적으로 그리고 서버의 오버헤드 부분에서도 큰 성능적인 이점을 가지고 있습니다. 

 

데이터베이스 튜닝 방식인 클러스터링, 레플리케이션, 샤딩에 대해서 궁금하신 분들은 아래의 링크를 참고해주세요!

 

https://coding-review.tistory.com/309

데이터베이스 튜닝 방법 (Clustering, Replication, Sharding)

 

확장성은 어떨까요? 

 

확장성은 기존의 RDBMS보다 NoSQL이 더 잘 확장하기로는 잘 알려진 사실입니다. 몇몇 논문에서는 NoSQL이 RDBMS보다 확장성에서 우위를 가져가게 된 요인으로 느슨한 ACID를 채택하였기 떄문이라고 말합니다. 

 

기존 RDBMS는 Atomatic과 Consistency를 엄격하게 지켜야 했기 때문에 데이터 확장에 큰 제약이 있었다고 설명하죠. 

 

 

자 이렇게 Eventual Consistency의 장점에 대해서 알아봤습니다. 하지만 장점이 있다면 단점도 있겠죠? 마냥 좋은 기술은 아닙니다. 

 

Eventual Consistency의 단점

Eventual Consistency의 단점은 크게 레이턴시, 일관성, 낮은 신뢰성을 들 수 있습니다. 각각에 대해서 설명해보죠. 

 

• 너무 긴 응답속도 : Eventual Consistency 모델에서는 다른 서버에 저장된 여러개의 데이터들이 노드를 타고 전파하여 결국 일관성을 유지합니다. 하지만 이 전파되는 시간동안은 일관성을 보장되지 않기 때문에 결과적으로 데이터 정합성이 모두 갖춰진 상황이 되려면 오랜 시간이 걸리게 됩니다. 5G 시대에서는 이러한 응답속도는 부정적인 유저 경험으로 이어질 수도 있습니다. 
• 현재 데이터에 대한 보장이 없음 : Eventual Consistency를 채택한 애플리케이션은 항상 일정한 데이터를 보여줄 수 없습니다. 이는 뒤에 말할 낮은 신뢰성과도 연결되는 문제인데 그렇기 때문에 유저는 이 데이터가 일관적이라는 보장을 받을 수 없습니다. 결과적으로 유저는 이미 지나버린 데이터를 볼 가능성이 매우 농후합니다. 
• 낮은 신뢰성 : 이 문제는 앞서 설명한 문제와 연결되는 문제인데, 현재 데이터에 대한 보장이 없으니 신뢰성이 낮아지는 것은 당연합니다. 현재의 Eventual Consistency의 모델에서는 데이터를 입력했을 때 새로운 데이터가 51% 정도만 전파되고 바로 응답해버리는 문제 때문에 신뢰성을 보장할 수 없습니다. 

 

자 Eventual Consistency에 대한 단점에 대해서 설명해봤는데요. 이거... 온라인뱅킹이나 SMTP 프로토콜 이런데 쓸 수 있을까요? 절대 못쓰겠죠 일관성이 중요한 서비스에서 NoSQL은 그래서 절대 못씁니다. 

 

어떻게 보면 이건 아주 큰 문제인데요. 근데 이게 정말 큰 문제일까요? 

 

생각의 전환

제가 NoSQL에 대해서 포스팅할 때도 말씀드렸지만 RDBMS와 NoSQL은 서로가 서로를 대체할 수 있는 대안책이 아닙니다. RESTful API와 GraphQL같은 관계가 아니라는 말이죠. 

 

위의 단점들을 살펴봤는데 만약 저기 위의 단점이 모두 신경쓰지 않아도 되는 애플리케이션에서는 어떨까요? 즉, 응답속도도 낮아도 되고, 현재 데이터를 보장받지 않아도 되며, 낮은 신뢰성을 가져도 상관없는 애플리케이션이라면요? 

 

사진, 영상, 음성과 같은 비정형 데이터가 많이 저장되는 애플리케이션이고 높은 성능, 높은 확장성, 높은 가용성이 필요한 애플리케이션이라면요? 

 

그런 애플리케이션이 우리 주변에는 많습니다. 페이스북, 인스타그램, 트위터와 같은 SNS는 위의 특징이 모두 부합합니다. 비정형 데이터가 많고, 높은 성능, 높은 확장성, 높은 가용성이 요구되면서 Eventual Consistency의 단점이 모두 해당되지 않는 애플리케이션이죠. 

 

그럼 저 단점이 의미가 있을까요? 

 

단점이 있는데... 단점이 의미없는 경우가 생겨버립니다. 그래도 온라인 뱅킹이나 SMTP에서는 못쓰잖아! 그럼요 당연하죠 그런 높은 신뢰성, 높은 일관성이 필요한 애플리케이션에서는 절대 못씁니다. 하지만 그게 뭐가 문제가 되나요? 그런 애플리케이션은 NoSQL말고 RDBMS 쓰면 되잖아요. 

 

그러니 앞서 말했듯이 이 둘은 서로의 대안책이 아니라 상호보완하는 관계입니다. 반대로 생각해보면 비정형 데이터를 담을 수 없는 RDBMS는 SNS에서는 절대 못쓰는 데이터베이스입니다. 

 

즉, 어떤 데이터베이스던 사용할 수 있는 곳이 따로 존재한다는 의미입니다. 

 

 

자 이렇게 NoSQL의 특징인 BASE와 그 중 핵심인 Eventual Consistency에 대해서 알아봤습니다. 어떠신가요? 

 

저는 공부를 하면 할수록 각각의 단점을 보기 보다는 그 기술이 가지고 있는 장점에 점점 더 신경을 쓰기 시작하게 된 것 같습니다. 이게 제 모토와도 일치하거든요. 제 모토는 "단점을 보완하지 말고 장점을 극대화 시켜서 단점을 무마시켜라" 인데 이것이 마치 RDBMS와 NoSQL 같지않나요? 

 

여기까지 글 마쳐보도록 하고 다음에도 더 좋은 포스팅으로 찾아뵙도록 하겠습니다. 오늘도 즐거운 하루 되시고 다음에 또 봬요~

 

 

출처

https://www.voltactivedata.com/blog/2022/09/what-is-eventual-consistency/

What is Eventual Consistency?

https://www.freecodecamp.org/news/nosql-databases-5f6639ed9574/

The basics of NoSQL databases — and why we need them

 

"NoSQL Database : New Era of Databases for Big data Analyties - Classification, Characteristics and Comparison"
저자 : A B M Moniruzzaman, Syed Akhter Hossain
링크 : https://arxiv.org/ftp/arxiv/papers/1307/1307.0191.pdf
-> 확장성을 늘릴 수 있었던 기술적인 부분을 서술 page 3~4 (CAP 정리와 ACID를 인용하여 설명했음)

 

"Database Management Systems : A NoSQL Analysis"
저자 : Innocent Mapanga, Prudence Kadebu
링크 : https://d1wqtxts1xzle7.cloudfront.net/32373170/Database_Management_System_A_NoSQL_Analysis-libre.pdf?1391610082=&response-content-disposition=inline%3B+filename%3DDatabase_Management_Systems_A_NoSQL_Anal.pdf&Expires=1679015563&Signature=ANQwxCQtKCXg9NYGakJbSYJEh1pYTBamZLdRHYWdl4M8CwRxBztFLL-0FaaMVdKXDfnXGlozOBPgjBgEUet-Znf6xX2gNlPPN5qAKvrzMDDG972O1QzK8tLKsfwKrVbI9CndLAnEg1D7j1mAQM2nSUYQmMx0KnzHScmrmkuy~WgcuQBAl6qU1bPRRXEliN96ocCnqlGX~aVgbJi-fFjhl3D-BAmXAleKXKNNUkGNWNUyXrk9cSIz9ZaiT3wHkxE6jinhbn0kKEuVcwa39NRJaAor7xWq5Wm4fZApO8NmHrhydwf2JeRFGFmGWcaeQFPUH6LhZWTOENx2AmPE8SlGQg__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA 
-> Database Sharding의 관점에서 RDBMS보다 수평적 확장을 더 쉽게 할 수 있다고 서술 page 2