데이터 분할 전략 (Azure를 사용 하 여 실제 클라우드 앱 빌드)Data Partitioning Strategies (Building Real-World Cloud Apps with Azure)

사람, Mike Wasson, Rick Anderson, Tom Dykstraby Mike Wasson, Rick Anderson, Tom Dykstra

Fix It 프로젝트 다운로드 또는 전자 서적 다운로드Download Fix It Project or Download E-book

Azure e-learning을 사용 하 여 실제 클라우드 앱 빌드 는 Scott Guthrie에서 개발한 프레젠테이션을 기반으로 합니다.The Building Real World Cloud Apps with Azure e-book is based on a presentation developed by Scott Guthrie. 클라우드의 웹 앱을 성공적으로 개발 하는 데 도움이 되는 13 개의 패턴 및 사례에 대해 설명 합니다.It explains 13 patterns and practices that can help you be successful developing web apps for the cloud. 시리즈에 대 한 자세한 내용은 첫 번째 챕터를 참조 하세요.For information about the series, see the first chapter.

이전에는 웹 서버를 추가 및 제거 하 여 클라우드 응용 프로그램의 웹 계층을 확장 하는 것이 얼마나 쉬운지 알아보았습니다.Earlier we saw how easy it is to scale the web tier of a cloud application, by adding and removing web servers. 그러나 모두 동일한 데이터 저장소에 도달 하는 경우 응용 프로그램의 병목 상태가 프런트 엔드에서 백 엔드로 이동 하 고 데이터 계층은 크기를 조정 하는 것이 가장 좋습니다.But if they're all hitting the same data store, your application's bottleneck moves from the front-end to the back-end, and the data tier is the hardest to scale. 이 장에서는 데이터를 여러 관계형 데이터베이스로 분할 하거나 관계형 데이터베이스 저장소를 다른 데이터 저장소 옵션과 결합 하 여 데이터 계층을 확장 가능 하 게 만드는 방법을 살펴봅니다.In this chapter we look at how you can make your data tier scalable by partitioning data into multiple relational databases, or by combining relational database storage with other data storage options.

앞에서 설명한 것과 같은 이유로 파티션 구성표를 설정 하는 것이 가장 좋습니다. 앱이 프로덕션 환경에 있는 후에는 데이터 저장소 전략을 변경 하기가 매우 어렵습니다.Setting up a partitioning scheme is best done up front for the same reason mentioned earlier: it's very difficult to change your data storage strategy after an app is in production. 다른 방법에 대해 앞으로 생각 하는 경우 앱의 데이터 및 데이터 액세스 코드를 다시 구성 하는 동안 앱이 충돌 하거나 오랜 시간 동안 중단 될 때 "Twitter 순간"이 발생 하지 않도록 방지할 수 있습니다.If you think hard up front about different approaches, you can avoid having a "Twitter moment" when your app crashes or goes down for a long time while you reorganize your app's data and data access code.

데이터 저장소의 세 가지 VsThe three Vs of data storage

분할 전략이 필요한 지 여부를 확인 하기 위해 데이터에 대 한 세 가지 질문을 고려해 야 합니다.In order to determine whether you need a partitioning strategy and what it should be, consider three questions about your data:

  • 볼륨 – 궁극적으로 얼마나 많은 데이터를 저장할 수 있나요?Volume – How much data will you ultimately store? 몇 기가바이트 입니까?A couple gigabytes? 수백 기가바이트A couple hundred gigabytes? 테라바이트?Terabytes? 페타바이트?Petabytes?
  • 속도 – 데이터가 증가 하는 속도는 어떻습니까?Velocity – What is the rate at which your data will grow? 많은 양의 데이터를 생성 하지 않는 내부 앱 입니까?Is it an internal app that isn't generating a lot of data? 고객이 이미지 및 비디오를 업로드 하는 외부 앱은 무엇 인가요?An external app that customers will be uploading images and videos into?
  • 다양 한 내용 – 어떤 유형의 데이터를 저장 하나요?Variety – What type of data will you store? 관계형, 이미지, 키-값 쌍, 소셜 그래프?Relational, images, key-value pairs, social graphs?

많은 볼륨, 개발 속도 또는 다양 한 기능을 사용 하는 경우 앱이 증가 함에 따라 효율적이 고 효율적으로 확장할 수 있도록 하 고 병목 현상이 발생 하지 않도록 하는 데 가장 적합 한 파티션 구성표의 종류를 신중 하 게 고려해 야 합니다.If you think you're going to have a lot of volume, velocity, or variety, you have to carefully consider what kind of partitioning scheme will best enable your app to scale efficiently and effectively as it grows, and to ensure you don't run into any bottlenecks.

기본적으로 분할에는 세 가지 방법이 있습니다.There are basically three approaches to partitioning:

  • 수직 분할Vertical partitioning
  • 행 분할Horizontal partitioning
  • 하이브리드 분할Hybrid partitioning

수직 분할Vertical partitioning

수직 portioning는 열을 기준으로 테이블을 분할 하는 것과 같습니다. 한 열 집합은 하나의 데이터 저장소로 이동 하 고 다른 열 집합은 다른 데이터 저장소로 이동 합니다.Vertical portioning is like splitting up a table by columns: one set of columns goes into one data store, and another set of columns goes into a different data store.

예를 들어 내 앱에서 이미지를 포함 하 여 사용자에 대 한 데이터를 저장 한다고 가정 합니다.For example, suppose my app stores data about people, including images:

데이터 테이블

이 데이터를 테이블로 표시 하 고 다른 종류의 데이터를 살펴보면 왼쪽에 있는 세 개의 열에는 관계형 데이터베이스에서 효율적으로 저장할 수 있는 문자열 데이터가 있고, 오른쪽에 있는 두 열은 기본적으로 바이트 배열 이라는 것을 알 수 있습니다. 이미지 파일에서 ome 합니다.When you represent this data as a table and look at the different varieties of data, you can see that the three columns on the left have string data that can be efficiently stored by a relational database, while the two columns on the right are essentially byte arrays that come from image files. 이미지 파일 데이터를 관계형 데이터베이스에 저장할 수 있으며, 많은 사람들이 데이터를 파일 시스템에 저장 하지 않기 때문에이 작업을 수행 합니다.It's possible to store image file data in a relational database, and a lot of people do that because they don't want to save the data to the file system. 필요한 데이터 볼륨을 저장할 수 있는 파일 시스템이 없거나 별도의 백업 및 복원 시스템을 관리 하지 않으려고 할 수 있습니다.They might not have a file system capable of storing the required volumes of data or they might not want to manage a separate back-up and restore system. 이 방법은 온-프레미스 데이터베이스 및 클라우드 데이터베이스에서 소량의 데이터에 적합 합니다.This approach works well for on-premises databases and for small amounts of data in cloud databases. 온-프레미스 환경에서는 DBA가 모든 작업을 처리 하는 것이 더 쉬울 수 있습니다.In the on-premises environment, it might be easier to just let the DBA take care of everything.

그러나 클라우드 데이터베이스에서 저장소는 상대적으로 비용이 많이 들고, 많은 이미지를 사용 하는 경우 데이터베이스가 효율적으로 작동할 수 있는 한도를 초과 하 여 데이터베이스 크기가 증가할 수 있습니다.But in a cloud database, storage is relatively expensive, and a high volume of images could make the size of the database grow beyond the limits at which it can operate efficiently. 데이터를 세로로 분할 하 여 이러한 문제를 해결할 수 있습니다. 즉, 데이터 테이블의 각 열에 가장 적합 한 데이터 저장소를 선택 합니다.You can address these problems by partitioning the data vertically, which means you choose the most appropriate data store for each column in your table of data. 이 예에서는 문자열 데이터를 관계형 데이터베이스에 저장 하 고 이미지는 Blob 저장소에 저장 하는 것이 가장 적합 합니다.What might work best for this example is to put the string data in a relational database and the images in Blob storage.

수직 분할 된 데이터 테이블

데이터베이스 대신 Blob 저장소에 이미지를 저장 하는 작업은 파일 서버를 설정 하거나 관계형 데이터베이스 외부에 저장 된 데이터의 백업 및 복원을 관리할 필요가 없기 때문에 온-프레미스 환경 보다 클라우드에서 더 실용적입니다. Blob storage 서비스에서 자동으로 처리 됩니다.Storing images in Blob storage instead of a database is more practical in the cloud than in an on-premises environment because you don't have to worry about setting up file servers or managing back-up and restore of data stored outside of the relational database: all that is handled for you automatically by the Blob storage service.

이는 Fix It 앱에서 구현 된 분할 방식 이며 Blob storage 챕터의 코드를 살펴보겠습니다.This is the partitioning approach we implemented in the Fix It app, and we'll look at the code for that in the Blob storage chapter. 이 파티션 구성표를 사용 하지 않고 평균 이미지 크기를 3mb로 가정할 경우 Fix It 앱은 150 기가바이트의 최대 데이터베이스 크기에 도달 하기 전에 약 4만 작업을 저장할 수 있습니다.Without this partitioning scheme, and assuming an average image size of 3 megabytes, the Fix It app would only be able to store about 40,000 tasks before hitting the maximum database size of 150 gigabytes. 이미지를 제거한 후에는 데이터베이스에 여러 태스크를 10 배 저장할 수 있습니다. 행 분할 구성표를 구현 하는 방법에 대해 생각해 야 하기 전에 훨씬 더 오랜 시간이 걸릴 수 있습니다.After removing the images, the database can store 10 times as many tasks; you can go much longer before you have to think about implementing a horizontal partitioning scheme. 앱이 확장 됨에 따라 대량의 저장소 요구가 매우 저렴 한 Blob storage로 이동 하기 때문에 비용이 더 느리게 증가 합니다.And as the app scales, your expenses grow more slowly because the bulk of your storage needs are going into very inexpensive Blob storage.

행 분할(분할)Horizontal partitioning (sharding)

수평 portioning는 테이블을 행으로 분할 하는 것과 같습니다. 한 행 집합은 하나의 데이터 저장소로 이동 하 고 다른 행 집합은 다른 데이터 저장소로 이동 합니다.Horizontal portioning is like splitting up a table by rows: one set of rows goes into one data store, and another set of rows goes into a different data store.

동일한 데이터 집합을 지정 하는 경우 다른 옵션은 다양 한 범위의 고객 이름을 다른 데이터베이스에 저장 하는 것입니다.Given the same set of data, another option would be to store different ranges of customer names in different databases.

행 분할 된 데이터 테이블

핫 스폿을 방지 하기 위해 데이터가 균등 하 게 분산 되도록 분할 체계에 대해 매우 주의를 기울여야 합니다.You want to be very careful about your sharding scheme to make sure that data is evenly distributed in order to avoid hot spots. 많은 사람들이 특정 공통 문자로 시작 하는 성을 사용 하기 때문에 성의 첫 글자를 사용 하는이 간단한 예제는이 요구 사항을 충족 하지 않습니다.This simple example using the first letter of the last name doesn't meet that requirement, because a lot of people have last names that start with certain common letters. 대부분의 경우에는 약간의 작은 데이터베이스를 사용할 수 있기 때문에 이전에는 테이블 크기 제한에 도달 하는 것이 좋습니다.You'd hit table size limitations earlier than you might expect because some databases would get very large while most would remain small.

수평 분할의 한 쪽은 모든 데이터에 대해 쿼리를 수행 하기 어려울 수 있습니다.A down side of horizontal partitioning is that it might be hard to do queries across all of the data. 이 예제에서 쿼리는 앱에 저장 된 모든 데이터를 가져오기 위해 최대 26 개의 다른 데이터베이스를 그려야 합니다.In this example, a query would have to draw from up to 26 different databases to get all of the data stored by the app.

하이브리드 분할Hybrid partitioning

수직 분할과 수평 분할을 결합할 수 있습니다.You can combine vertical and horizontal partitioning. 예를 들어 예제 데이터에서 이미지를 Blob 저장소에 저장 하 고 문자열 데이터를 수평으로 분할할 수 있습니다.For example, in the example data you could store the images in Blob storage and horizontally partition the string data.

데이터 테이블 하이브리드 분할

프로덕션 응용 프로그램 분할Partitioning a production application

개념적으로 파티션 구성표의 작동 방식을 쉽게 확인할 수 있지만, 모든 분할 체계를 사용 하면 코드 복잡성이 증가 하 고 처리 해야 하는 여러 가지 새로운 문제가 발생 합니다.Conceptually it's easy to see how a partitioning scheme would work, but any partitioning scheme does increase code complexity and introduces many new complications that you have to deal with. Blob 저장소로 이미지를 이동 하는 경우 저장소 서비스가 다운 될 때 어떻게 해야 하나요?If you're moving images to blob storage, what do you do when the storage service is down? Blob 보안을 처리 하는 방법How do you handle blob security? 데이터베이스와 blob 저장소가 동기화 되지 않으면 어떻게 되나요?What happens if the database and blob storage get out of sync? 분할 하는 경우 모든 데이터베이스에서 쿼리를 처리 하는 방법은 무엇 인가요?If you're sharding, how will you handle querying across all of the databases?

프로덕션으로 이동 하기 전에 계획 하는 경우에는 이러한 문제를 관리할 수 있습니다.The complications are manageable so long as you're planning for them before you go to production. 이러한 작업을 수행 하지 않은 많은 사람들이 나중에 수행 했습니다.Many people who didn't do that wish they had later. 평균적으로 고객 자문 팀 (CAT) 팀은 앱이 매우 큰 방식으로 진행 중인 고객 으로부터 한 달에 한 번 당황한 전화 통화를 하 고이 계획을 수행 하지 않았습니다.On average our Customer Advisory Team (CAT) team gets panicked phone calls about once a month from customers whose apps are taking off in a really big way, and they didn't do this planning. 예를 들면 다음과 같습니다. "Help!And they say something like: "Help! 단일 데이터 저장소에 모든 항목을 저장 하 고 45 일 후에 공간이 부족 합니다. "I put everything in a single data store, and in 45 days I'm going to run out of space on it!" 데이터 저장소에 액세스 하는 방법에 많은 비즈니스 논리를 구축 하 고 사용자가 앱을 사용 하는 고객을 보유 하 고 있는 경우 마이그레이션 중 하루 종일 다운 하는 것은 좋지 않습니다.And if you have a lot of business logic built into how you access your data store and you have customers who are using your app, there's no good time to go down for a day while you migrate. Herculean 노력을 통해 고객은 중단 시간 없이 즉시 데이터를 분할할 수 있습니다.We end up going through herculean efforts to help the customer partition their data on the fly with no down time. 이를 방지할 수 있는 경우에는 매우 흥미롭고 매우 유용 하며 참여 하지 않을 것입니다.It's very exciting and very scary, and not something you want to be involved in if you can avoid it! 이에 대 한 최신 정보를 고려 하 여 앱에 통합 하면 앱이 나중에 성장 하는 경우 훨씬 더 쉽게 사용할 수 있습니다.Thinking about this up front and integrating it into your app will make your life a lot easier if the app grows later.


효과적인 분할 체계를 사용 하면 클라우드 앱에서 병목 현상이 발생 하지 않고 클라우드의 데이터를 페타바이트 확장할 수 있습니다.An effective partitioning scheme can enable your cloud app to scale to petabytes of data in the cloud without bottlenecks. 그리고 온-프레미스 데이터 센터에서 앱을 실행 하는 경우 처럼 대규모 컴퓨터 또는 광범위 한 인프라에 대해 앞으로 지불할 필요가 없습니다.And you don't have to pay up front for massive machines or extensive infrastructure as you might if you were running the app in an on-premises data center. 클라우드에서는 필요에 따라 용량을 점진적으로 추가할 수 있으며, 사용할 때 사용 하는 만큼만 요금을 지불 하 게 됩니다.In the cloud you can incrementally add capacity as you need it, and you're only paying for as much as you're using when you use it.

다음 장에서 는 Fix It 앱이 Blob storage에 이미지를 저장 하 여 수직 분할을 구현 하는 방법을 알아봅니다.In the next chapter we'll see how the Fix It app implements vertical partitioning by storing images in Blob storage.


분할 전략에 대 한 자세한 내용은 다음 리소스를 참조 하세요.For more information about partitioning strategies, see the following resources.



  • 안전 하지 않음: 확장 가능 하 고 복원 가능한 Cloud Services 빌드FailSafe: Building Scalable, Resilient Cloud Services. Ulrich HoMarc Mercuri 및 Mark Simm에서 9 부분으로 된 시리즈.Nine-part series by Ulrich Homann, Marc Mercuri, and Mark Simms. Microsoft의 Microsoft CAT (고객 자문 팀) 경험을 통해 실제 고객과 함께 제공 되는 스토리를 통해 매우 편리 하 게 액세스할 수 있고 흥미로운 방식으로 높은 수준의 개념 및 아키텍처 원칙을 제공 합니다.Presents high-level concepts and architectural principles in a very accessible and interesting way, with stories drawn from Microsoft Customer Advisory Team (CAT) experience with actual customers. 에피소드 7의 분할 논의를 참조 하세요.See the partitioning discussion in episode 7.
  • 대규모 빌드: Windows Azure 고객 으로부터 얻은 교훈-파트 I. 19:49에서 시작 하 여 분할 전략, 분할를 구현 하는 방법 및 SQL Database 페더레이션을 설명 합니다.Building Big: Lessons learned from Windows Azure customers - Part I. Mark Simms discusses partitioning schemes, sharding strategies, how to implement sharding, and SQL Database Federations, starting at 19:49. 안전 계열과 유사 하지만 자세한 방법에 대해 자세히 설명 합니다.Similar to the Failsafe series but goes into more how-to details.

샘플 코드:Sample code: