翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 一般的なスケーリングの課題
<a name="common-scaling-challenges"></a>

データレイクは、最初のデプロイ後にデータが大きくなると、いくつかの段階を経ます。スケーラブルアーキテクチャを使用してデータレイクを設計しなかった場合、組織は課題に遭遇し、データレイクの成長によって不利になる可能性があります。

以下のセクションでは、一般的なデータレイクの成長がスケーリングの課題を引き起こす方法について説明します。

## 初期データレイクデプロイ
<a name="initial-deployment"></a>

次の図は、基幹業務 A による最初のデプロイ後のデータレイクのアーキテクチャを示しています。

![事業部門 A による最初のデプロイ後のデータレイクのアーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/data-lake-for-growth-scale/images/datalakescaling-diagram-1.png)


この図は、次のコンポーネントを示しています。
+ データプロデューサーアカウントは、データを収集して処理し、処理されたデータを保存して、消費に備えます。
+ データプロデューサーアカウントのデータは、複数のデータレイヤーを持つことができる [Amazon Simple Storage Service (Amazon S3) ](https://docs.aws.amazon.com//AmazonS3/latest/userguide/Welcome.html)バケットに保存されます。
+ データ処理に AWS サービス ( [AWS Glue](https://docs.aws.amazon.com//glue/latest/dg/what-is-glue.html)や [Amazon EMR](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-what-is-emr.html) など) を使用できます。
+ データプロデューサーは、データレイクでデータを生成して保存するだけでなく、データコンシューマーと共有するデータとその共有方法を決定する必要があります。 は、データプロデューサーからデータコンシューマーへのクロスアカウントデータ共有を管理するだけでなく、データプロデューサーアカウントでデータレイク AWS Lake Formation を管理します。
+ データコンシューマーアカウントは、特定のビジネスユースケースのためにデータプロデューサーアカウントの共有データを消費します。

## データコンシューマーの増加
<a name="data-consumer-growth"></a>

次の図は、基幹業務 A のデータが増加すると、より多くのデータがデータレイクに取り込まれることを示しています。その後、データレイクはより多くのデータコンシューマーを惹きつけ、データを活用してデータから価値を得ます。

![データレイクのデータプロデューサーがデータを増やすと、データコンシューマーの数も増えます。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/data-lake-for-growth-scale/images/datalakescaling-diagram-2.png)


この図は、組織が既存のデータアセットからほぼ継続的な値を生成する方法と、より多くのデータコンシューマーを引き付ける方法を示しています。ただし、データコンシューマーが増加すると、データプロデューサーにはこの増加に対応するための次の 2 つのオプションしかありません。
+ 個々のデータコンシューマーによるデータ共有とアクセスを手動で管理しますが、これはスケーラブルなアプローチではありません。
+ データ共有とデータアクセスの管理のための自動または半自動プロセスを開発します。これはスケーラブルなオプションかもしれませんが、内部データコンシューマーと外部データコンシューマーのセキュリティ制御要件が異なるため、設計と構築には多大な時間と労力が必要です。今後、ソリューションの改善には追加の時間と労力も必要になります。

## データプロデューサーの増加
<a name="data-producer-growth"></a>

次の図は、複数の事業部門がデータプロデューサーとして参加する場合のデータレイクアーキテクチャを示しています。

![複数の事業部門がデータプロデューサーとして参加する場合のデータレイクのアーキテクチャ。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/data-lake-for-growth-scale/images/datalakescaling-diagram-3.png)


データレイクのアーキテクチャは、3 つのデータプロデューサーと 3 つのデータコンシューマーだけでも、ますます複雑になります。

各データプロデューサーは、複数のデータコンシューマーのデータ共有とデータアクセス管理を処理する必要があります。すべてのデータプロデューサーがデータ共有とデータアクセス管理のための自動または半自動プロセスを開発することは現実的ではありません。一部のデータプロデューサーは、データを共有しないことを選択するため、コストがかからない管理オーバーヘッドを回避できます。同様に、各データコンシューマーは、さまざまなデータ消費プロセスを理解するために、複数のデータプロデューサーとやり取りする必要があります。つまり、個々のデータコンシューマーは、さまざまなデータ共有パターンを処理するための管理オーバーヘッドが増加します。

多くの組織では、このデータレイクはボトルネックを引き起こし、成長やスケールができません。これは、ボトルネックを取り除くために組織がデータレイクを再設計および再構築する必要があることを意味する場合があり、これには多大な時間、リソース、コストがかかる可能性があります。