Microsoft Azure 기술 게시판

빅데이터만 분할이 필요한가? 

클라우드와 빅데이터 시대에서 데이터 샤딩이나 파티셔닝은 무조건 필요하다.  자 그러면 어떤 방식으로 어떤 부분에서 분할이 되어야 하며 왜 필요한가? 하드웨어의 한계점을 넘어가는 순간 때문에 여러개의 데이터를 나눠야만 속도를 유지할수 있으며 확장이 가능하다.  클라우드에서는 빠르고 싸게 설계 하려는 상황에서도 항상 " 확장" 과 "탄력성"과 "보안성"을 고려해야한다.

분할의 전략적 빌드오더?

빌드오더는 시작전부터 전략적으로 계획되어야 하며 탄력적으로 변할수 있다. 온프레미스 시대에도 물론 분할 샤딩이 필요했으며 이론적으로 샤딩은 수평적 분할이다. 그럼 수평적 분할, 수직적 분할, 기능적 분할 에 맞춰서 하는 시대는 이미 지났다. 이런것들은 이제 단순 이론에 불과하며 쓸수 있는 모든 것을 조합해서 최적의 아키텍쳐를 짜는 것이 가장 중요하다. 물론 장점만 있는것은 아니다. 왜냐면 복잡성이 증가하기 때문에 관리자의 능력과 기술이 중요하다.

분할에 고려해야할 사항 리스트는 무엇인가? 

저장장소의 크기, 쿼리의 양, 네트워크 대역폭, 지역적 특성, 실시간 복제,  샤딩키의 선택, 병목현상 제거, 제약 조건 이해 등등 수많은 고려사항이 있지만 가장 중요한 포인트는 무엇인가라는 고민은 항상해왔다. 최적의 솔루션을 찾기 위해서 항상 충분한 테스트와 함께 분석만이 가장 좋은 방법이라고 생각된다. 예를들어 설계 단계에서 이것이 답이다 라고 말할수없으며 최상의 솔루션을 만들수 없다. 그러나 최적의 솔루션을 찾아갈수는 있으며 그 과정은 인내심이 필요하며 그 결과를 숫자로 도출하여 이해 시키는 과정은 필요하다.

결론부터 말하자면 PaaS 형 데이터베이스가 무조건 좋지는 않지만 이것이 답이다.

PaaS 형 데이터베이스에 대한 여러가지 편리한 점은 항상 PaaS에 대한 제한 사항이 있다는 점을 고려해야한다. IaaS 방식으로 데이터베이스를 직접 구축하는것에 비해 빠르고 탄력적이고 가격이 싸지만 분명 문제점 이 있다. 일단 구동방식은 데이터 I/O 리소스 제한에 도달하면 쿼리를 큐에 대기시키고 대기중인 쿼리는 순서대로 적용이 된다. 물론 IaaS도 사용 가능한 모든 리소스를 활용하면 실행 중인 쿼리의 실행시간이 길어지는것은 당연하지만 PaaS 보다는 덜하다. 이때문에 많은 PaaS 유저들은 단순히 몃번의 쿼리만 실행해보고 PaaS 가 느리다고 결론지을수 있다. 또한 동시접속자 수의 제한도 있다.

자 클라우드에서 가장 장점은 신속성, 탄력적 구성이다. 물론 PaaS가 가격도 훨씬 싸다. 그러나 싼 만큼 제약이 있다는 점을 간과해서는 안된다.

일반 MSSQL에서 되지만 Azure PaaS에서 안되는 기능 모음 리스트 https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-features

위에 링크의 제약사항에서 Always On 가용성 그룹이 되지 않는다. 그러나 이부분은 활성 지역 복제로 커버될수 있다.  CLR(Common Language Runtime)은 지원되지 않는다. 생각보다 많은 부분에서지원되지 않으므로 꼭 확인해야한다.

그럼 어떻게 이 제약을 뛰어 넘어야 하는지 알아보자

1. 데이터베이스로 들어오는 Insert 요청수를 줄인다.


2. 조금 더 비싼 PaaS를 쓴다.


3. 쿼리를 최적화 하여 리소스 사용률을 줄인다.


4. 데이터베이스를 나눈다.


5. Radis Cache나 Memcached 와 같은 캐쉬를 사용하여 부하를 줄인다


6. 동시접속자 수를 줄인다.


7. 쿼리의 튜닝이 필요하다.

Azure의 경우 Query Performance InSight 를 사용하면 현재 사용하는 쿼리에 대한 모니터와 많이 사용되는 쿼리에 대한 통계를 직접적으로 보여주는데 이는 쿼리 튜닝에 많은 도움을 준다. https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-troubleshoot-performance

AWS 의 RDS의 제약사항 http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/CHAP_Limits.html

DB 샤딩이란?

관계형 데이터베이스에서 대량의 데이터를 처리하기 위해서 사용하는 방법이다. DBMS 차체에서 파티셔닝 기술을 제공하는 DBMS도 있지만 이는 데이터베이스 자체 분할방식이 아니다. 그러므로 어플리케이션 레벨에서 분할해야한다.  예를들어서 고객이 글로벌하게 있다면 글로벌하게 미국 서울 유럽 이런식으로 나누어야하며 시간에 따라 누적이 된다면 시간에 따라 나누어야한다. 이부분은 어플리케이션에 따라 달라질수 있다.

1. Vertical Partitioning  테이블이 수직적으로 분할하는 방식이다. 컨텐츠나 사용자 정보등으로 분리 할수 있다.


2. Range Based Partitioning 한개의 테이블이 개속 누적되어 개속 커지는 방식일때 고객에 따라 나누거나 시간에 따라 나누는 방식이다. 실제적으로 이방식은 관계형 DB가 아닌 NoSQL로 바꾼다면 좋은 결과를 볼수 있다.


3. Key or Hashing Partitioning 의 경우 엔티티를 해쉬함수에 넣어서 나오는 값을 이용하여 서버를 정하는 방식이다.


4. 하이브리드 구성 : 테이블에 따라 마이크로서비스처럼 전부 쪼개서 사용하는 방법으로 한가지 방식의 RDMS가 아닌 No-SQL등 다양한 데이터베이스로 전부 쪼개서 분산하는 방식이다.


5. https://docs.microsoft.com/en-us/azure/architecture/patterns/sharding

DB에 왜 샤딩이 필요한가?

IaaS에서도 DB는 샤딩이 필요하다 관계형 데이터베이스에서 대량의 데이터를 처리하기 위해서는 무조건 샤딩이 필요하다.

결론

실제적으로 대부분의 서비스는 PaaS로 가능하나 특별한 서비스나 레이턴시가 아주 많이 필요한 서비스는 PaaS로 쓸수 가 없다. 구조적으로 PaaS는 IaaS보다 퍼포먼스적으로는 아직 완전하지 않다. PaaS 의 많은 좋은 기능과 가격적 메이트가 있지만 쿼리가 튜닝 되지 않은 상태에서 대기시간은 IaaS 보다 느릴수 있으며 기본적인 데이터베이스의 Sharding 이나 Partitioning없이 Monolithic 구조의 데이터베이스를 사용하려면 그냥 IaaS를 써야한다. 

PaaS에 대한 퍼포먼스 측면의 기능은 앞으로 더 더욱 개선될것이며 PaaS에 맞게 분리가 된다면 앞으로  PaaS에 맞게 코딩이 되어야 한다고 생각되어 진다. 또한 PaaS의 탄력성과 관리적 편의성은 절대적으로 간과할 수 없다.

http://highscalability.com/unorthodox-approach-database-design-coming-shard

http://www.25hoursaday.com/weblog/2009/01/16/BuildingScalableDatabasesProsAndConsOfVariousDatabaseShardingSchemes.aspx