AWSのデータ分析に関するベストプラクティスをまとめてみた

こんにちは！ 最近DASに合格したクロちゃんです！！
（※DAS：AWS Certified Data Analytics - Specialtyの略）
最近、勉強として「データ分析レンズ – AWS Well-Architected （2023年4月6日更新版）」を翻訳しながら読んでみました。
今回は、そこで紹介されているベストプラクティスの内容を、自分用に日本語でまとめたものを記事にしました。
現状、「データ分析レンズ – AWS Well-Architected」は日本語訳されたドキュメントはなく、読むなら他の言語で読む必要があります。
ですので、本記事が原文のドキュメントを読む上で、皆様の一助となれば幸いです。

本記事の注意点

本記事を執筆するにあたり、読みやすいように自分なりの工夫を施させて頂きました。
そこで、本記事をご利用頂くにあたり、以下の点をご了承頂きたいと思います。

• 当該記事は原文に即した形でデロイト トーマツグループのプロフェッショナルが独自に翻訳した内容です。内容に齟齬が発生した場合には、原文を優先します。
• 原文に対して、内容を省略していたり、意訳して解釈したものをベースに文章を書いていたりします
• 各章タイトルにある「【〇〇】」の部分は、「どのAWS Well-Architectedの柱に関する内容か」を表しています
• 各節タイトルにある括弧内の「必須」「強く推奨」「推奨」は、そのベストプラクティスの優先度を表しています
• 各ベストプラクティスには提案（Suggestion）も書かれている場合がありますが、今回は割愛しています

以上をご理解頂いた上で、あくまでも「データ分析レンズ – AWS Well-Architected」の原文を読む際の補助資料程度として本記事をご利用頂ければ幸いです。
原文を確認しやすいように、各節タイトルに原文のURLを貼っていますので、ご活用頂ければ幸いです。
前置きが長くなり大変恐縮ですが、何卒ご理解の程よろしくお願い致します。

【運用上の優秀性】1 – 分析アプリケーションのワークロードの健全性を監視する

BP 1.1（必須）– 分析用にデータを転送する前にソースシステムのデータ品質を検証する

低品質なデータ処理に対して多大なリソース投入を避けるために、
データパイプライン上でのデータ品質の変化を監視する必要があります。
データソース検証は、多くの場合最新のデータ範囲のサブセットに対して迅速に実行して、
データの欠陥（欠損値、異常なデータ、誤ったデータ型）を探します。

BP 1.2（必須）– ソースシステムから最近のデータが計画通りに到達しているか監視する

通常の運用では、ビジネスの期限に間に合うようにデータ処理の出力を生成します。
処理するデータが到達していなければ、期限に間に合わない可能性があります。

BP 1.3（必須）– 定期的な分析ジョブのスケジュールを定義し、測定する

スケジュールに従って実行される分析ジョブは、開始時間を定義します。
その定義された時間にジョブが開始されなかった場合、通知します。

BP 1.4（必須）– 分析ジョブの実行時間を定義し、測定する

分析ジョブの開始と終了を示すメトリクスを使用して実行時間を計算します。
その計算結果（実行時間）が予想される閾値を超えた場合、通知するように設定する。

【運用上の優秀性】2 – 分析ジョブとアプリケーションのデプロイをモダナイズする

BP 2.1（必須）– ジョブとアプリケーションの変更にバージョン管理を使用する

バージョン管理システムは変更の追跡をサポートしており、
意図しない結果が生じた場合には、以前のバージョンに戻すことが出来ます。
IaCとアプリケーションの両方で、コードリポジトリをバージョン管理する必要があります。

BP 2.2（必須）– テストデータの作成とステージング環境のプロビジョニング

テスト用の不変のデータセットを使用してテストすることで、その結果を以前のバージョンと比較できます。
テスト用のデータセットが実際のデータを正確に表していることを確認することで、
開発者は分析ジョブの結果を確認したり、以前のバージョンと結果を比較することができます。

ユーザアクセステストのためにステージング環境を使用する必要があります。
開発基準に応じて、論理的に分離されたAWSアカウント（開発環境用、テスト環境用、ステージング環境用、本番環境用）を作成する必要があります。

BP 2.3（必須）– 分析ジョブとアプリケーションのデプロイをテストし、検証する

本番環境に変更を加える前に、標準的で反復可能な自動テストを使用して、パフォーマンスと結果の正確さを検証します。

BP 2.4（必須）– デプロイ、テスト、ロールバック、バックフィルタスクの標準作業手順を作成する

デプロイ、テスト、ロールバック、バックフィルタスクの標準作業手順によって、
デプロイが迅速化され、本番環境でのエラー数が減少します。
標準的なアプローチを使用することで、意図しない結果が生じた場合の修復も容易となります。

【セキュリティ】3 – ガバナンスとコンプライアンスのためのデータプラットフォーム設計

BP 3.1（必須）– プライバシーバイデザイン

プライバシーバイデザインは、エンジニアリングプロセス全体にわたって、
プライバシーを考慮するシステムエンジニアリングのアプローチです。
特に、個人データを取得して処理するシステムまたはアプリケーションに焦点を当てています。

BP 3.2（必須）– データを分類して保護する

分析ワークロードはソースシステムからデータを取り込むため、ソースデータの所有者はデータの分類を定義する必要があります。
分析ワークロードの所有者は、ソースデータの分類を尊重し、組織のデータ保護ポリシーを実装をする必要があります。
データ分類をダウンストリームのデータコンシューマと共有して、それらの組織やポリシーでもデータ分類を尊重できるようにします。

BP 3.3（必須）– データ分類とその保護ポリシーを理解する

データ分類は、保存時及び転送時にどのようにデータを保護しなければならないかを決める上で鍵となります。
データ分類に基づいた保護戦略は、データの損失、盗難、破損を防止し、
悪意ある行為や意図しないアクセスの影響を最小限にするために役立ちます。

BP 3.4（必須）– ソースデータの所有者を特定し、データ分類を設定してもらう

ソースデータの所有者を特定し、分析ワークロード内のデータにどのレベルの保護が必要かを確認します。
データ分類は、分析ワークフロー全体でデータを追跡し、確実に保護されるようにします。
そして、データへのアクセスを許可するユーザとシステムを決定します。

BP 3.5（必須）– 分析ワークロードが理解できるように、データ分類をデータカタログに記録する

データを効果的に保護するためには、分析システムがビジネスニーズに応じてデータを管理できるように、ソースデータの分類を認識する必要があります。

BP 3.6（必須）– 暗号化ポリシーの実装

暗号化は多層防御戦略の重要な要素です。
したがって、復号化キーとデータのアクセスを分離してデータ保護を提供するような
暗号化及びキー管理システムを組織で実装することを強くお勧めします。

BP 3.7（必須）– 分析ワークロード内のデータクラスごとにデータ保持ポリシーを実装する

データ分類ポリシーは、分析ワークロードがデータを保持する期間とバックアップを保持する期間を決定します。
分析ワークロードは、データ分類ポリシーに従って、データ保持ポリシーとバックアップポリシーを実装する必要があります。

BP 3.8（推奨）–ダウンストリームシステムがデータ分類を尊重するように強制する

他のデータコンシューマシステムが、分析ワークロードの共有データにアクセスするため、
分析ワークロードにて必要なデータ分類ポリシーを実装するように、ダウンストリームシステムへ要求する必要があります。

例えば、分析ワークロードが、AWS KMSのカスタマーマネージドの秘密鍵を使用して
暗号化する必要があるデータを共有する場合、
ダウンストリームシステムでも同様のデータ保護ポリシーを実装する必要があります。

【セキュリティ】4 – データアクセス制御の実装

BP 4.1（必須）– データ所有者が、分析およびダウンストリームワークロードのデータにアクセスできるユーザーまたはシステムを決定できるようにする

データ所有者は、データ保護に対して責任を持つ人々です。
データ所有者は、分析ワークロードがルールを実装できるように、データアクセスルールを提供できる必要があります。

BP 4.2（必須）– 人とシステムを一意に識別するユーザーIDソリューションを構築する

データアクセスを効果的に制御するためには、分析ワークロードが人またはシステムを一意に識別できる必要があります。

BP 4.3（必須）– 必要なデータアクセス認可モデルを実装する

ユーザ認可は、ユーザがデータまたはリソースに対してどのような操作を実行できるかを決定します。
データ所有者は、必要に応じてデータを保護できる認可方法を利用できる必要があります。

BP 4.4（推奨）– 管理者アクセスが必要なときに管理および使用されるように、緊急アクセスプロセスを確立する

緊急アクセスは、自動化されたプロセスまたはパイプラインで問題が発生した場合でも、
ワークロードへ迅速にアクセスできます。
これによって最小限の権限アクセスに依存しながら、必要な時に適切なアクセスレベルをユーザに提供できます。

BP 4.5（推奨）–データとデータベースの変更を追跡する

データ監査には、ユーザまたはプロセスのアクションを追跡するデータベースの監視と
データ変更の監査をすることが含まれています。

【セキュリティ】5 – ワークロードインフラストラクチャへのアクセスを制御する

BP 5.1（必須）– インフラストラクチャへの意図しないアクセスを防止する

インフラストラクチャへの不注意または意図しないアクセスを防止するために、
インフラストラクチャへの最小限の権限アクセスを許可します。

BP 5.2（必須）– ソースシステムとダウンストリームシステムに最小権限ポリシーを実装する

最小権限の原則は、システムがジョブを実行するために十分なアクセスのみを与えることで機能します。
再認証が定期的に実施されるように、一時的な権限に対して有効期限を設定します。
データに対するシステムのアクションによって権限を決定する必要があり、他のシステムへの権限付与は許可されるべきではありません。

BP 5.3（必須）– インフラストラクチャへの変更とユーザーアクティビティを監視します

変更が意図的に行われ、インフラストラクチャが保護され続けていることを保証するために、誰によって何が変更されたかを監視する必要があります。

BP 5.4（必須）– 分析インフラストラクチャ内の全データまたはリソースアクセスを記録する監査ログを保護する

監査ログはイベントが発生した際に記録し、不変である必要があります。
監査ログはアクションの証拠を提供し、不正利用の特定に役立ちます。
監査ログへのアクセス許可は特権ユーザーに制限する必要があります。
監査ログへの意図しないアクセスを特定するために、監査ログへのアクセスも記録します。

【信頼性】6 – 分析ワークロードの回復力を設計する

BP 6.1（必須）– データフローの依存関係図を作成する

ステークホルダーと協力して、データパイプラインの図を作成します。
各依存関係と相互作用するシステムを特定します。
図に示されていることが期待される主要なアーキテクチャーコンポーネントは、
データ取得、取り込み、データ変換、データ処理、データストレージ、データ消費量です。
全てのシステム依存関係には所有者が必要です。
組織内で誰がどの依存関係を所有するかについて合意します。

BP 6.2（必須）– 分析とETLジョブのビジネス要件を理解する

ソースシステムから対象のデータストアにデータを移動する場合、3つの一般的な設計パターンがあります。
1つ目はETL（Extract [抽出] → Transform [変換] → Load [書き出し] ）です。
2つ目はELT（Extract [抽出] → Load [書き出し] → Transform [変換] ）です。
3つ目はETLT（ETLとELTのハイブリット。Extract [抽出] → Transform [変換] → Load [書き出し] → Transform [変換] ）です。

BP 6.3（必須）– 分析システムを監視して分析またはETLジョブの障害を検出する

ジョブの障害をできるだけ早く検出します。
エラーが発生した箇所と状況を正確に特定することは、通知と修正措置を行うために非常に重要です。

BP 6.4（必須）– 分析またはETLジョブの障害についてステークホルダーに通知する

分析およびETLジョブの障害は、ダウンストリームの分析ワークロードに
時間通りにデータを配信するためのSLAへ影響を与える可能性があります。
また、データ品質やデータ整合性の問題も発生する可能性があります。

ジョブの障害について全ステークホルダーにできるだけ早く通知することは、
必要な修正措置をとるために重要です。

BP 6.5（推奨）– 分析およびETLジョブの障害回復を自動化する

ジョブ障害は、自動リカバリーソリューションを使用して回復できますが、手動の作業が必要な場合もあります。
自動リカバリーソリューションを設計して実装すると、ジョブの障害による影響を軽減し、IT運用を合理化できます。

BP 6.6（推奨）– 分析インフラストラクチャとデータの災害復旧(DR)計画を作成する

ステークホルダーと話し合い、目標復旧時点(RPO)と目標復旧時間(RTO)を確認します。

【信頼性】7 – データとメタデータの変更を管理する

BP 7.1（必須）– メタデータの変更を保存、共有、追跡するための中央データカタログを構築する

組織全体でメタデータを保存、共有、管理するために、中央データカタログを構築することは、データガバナンスの必要不可欠な部分です。
中央データカタログの構築により、標準化と再利用が促進されます。
中央データカタログでメタデータの変更履歴を追跡することは、メタデータのバージョン変更を管理および制御するために役立ちます。
データカタログは、監査とコンプライアンスのために必要になることがよくあります。

BP 7.2（必須）– データ品質の異常を監視する

ダウンストリームのデータワークロードとデータコンシューマにとって、データ品質が良いことは非常に重要です。
しかしながら、データ品質が悪いと、分析の洞察やML予測の精度に影響を与える可能性があります。
データ品質を監視し、データの異常をできるだけ早く検出します。

BP 7.3（必須）– データリネージをトレースする

データがどこから来て、どのように変換され、どのようにアクセスでき、どのように使用されるのかを明確に理解することは、データのビジネス価値を高めるために重要です。
実現するためには、データリネージを追跡、管理、視覚化する必要があります。

【パフォーマンス効率】8 – 最高のパフォーマンスのコンピューティングソリューションを選択する

BP 8.1（推奨）– 技術的な課題に最適な分析ソリューションを特定する

AWSには、特定の目的のために構築された複数の分析処理サービスがあります。
データ分析プロセスの各ステップを、業務に適したツールを特定する機会として考慮する必要があります。

BP 8.2（推奨）– データストレージの場所にコンピューティングリソースをプロビジョニングする

データ分析ワークロードでは、データの取り込み、中間結果の処理、厳選されたデータセットの生成のいずれかのために、パイプラインを介してデータを移動する必要があります。
データ処理サービスのロケーションは、データが保存されている場所に近いものを選択する方が簡単かつ効率的です。
このアプローチは、データ処理のロケーションへ大量のデータを頻繁にコピーまたはストリーミングする場合に適しています。

BP 8.3（推奨）– コンピューティングパフォーマンスのメトリクスを定義し、測定する

プロセスの各ステップで、分析ソリューションのパフォーマンスを測定する方法を定義します。

BP 8.4（推奨）– パフォーマンスが低いコンポーネントを継続的に特定し、インフラストラクチャまたはアプリケーションロジックを微調整する

パフォーマンス測定を定義したら、どのインフラストラクチャコンポーネントまたはジョブが、パフォーマンス基準を下回って実行されているかを特定する必要があります。
パフォーマンスの微調整は、AWSのサービスごとに異なります。

【パフォーマンス効率】9 – 最高のパフォーマンスのストレージソリューションを選択する

BP 9.1（強く推奨）– ストレージワークロードに対する重要なパフォーマンス基準を特定する

データ分析では、データスループットが効率的なワークロード実行の制約要因となることがよくあります。
スループットは、ネットワーク、コンピューティング、ストレージ層を正常に移動した情報量によって測定されます。

BP 9.2（強く推奨）– コンピューティングソリューションで利用可能なストレージオプションを評価および確認する

多くのAWSデータ分析サービスでは、複数種類のストレージを利用できます。
各データ分析サービスに関して調査するときは、全てのストレージオプションを評価して、
ビジネス要件を満たす最もパフォーマンス効率の高いソリューションを決定します。

BP 9.3（推奨）– アクセスパターン、データ増加、パフォーマンスメトリクスに基づいて最適なストレージを選択する

データ分析用のストレージオプションは、アクセスパターンとデータサイズに基づいて、
パフォーマンスのトレードオフを発生させる可能性があります。
ワークロードのニーズと使用パターンを評価して、データの保存方法または場所によって
ソリューションの全体的な効率が向上するかどうかを判断します。

【パフォーマンス効率】10 – 最もパフォーマンスの高いファイル形式とパーティショニングを選択する

BP 10.1（推奨）– データの書き込み頻度とパターンに基づいてフォーマットを選択する

ストリーミングデータを取り込む際のデータストレージのアクセスパターンとパフォーマンス要件をレビューします。
多数の小さなデータファイルを個別に保存するのではなく、小さなファイルを定期的にまとめて1つの大きな圧縮ファイルにまとめます。

BP 10.2（推奨）– データアクセスパターンに基づいてデータ形式を選択する

ワークロードをサポートするために使用できるデータ型は多数ありますが、
間違ったデータ型を選択すると、分析ワークロードのパフォーマンスに重大な影響を与える可能性があります。

BP 10.3（推奨）– ファイル圧縮をしてファイル数を減らし、ファイル I/O 効率を向上させる

データを圧縮形式で保存して、基盤となるストレージホストとネットワークの負担を軽減します。
このアプローチを実装する前に、非圧縮データセットと圧縮データセットの両方で
パフォーマンスとストレージのオーバーヘッドをテストして、最適なものを判断することをお勧めします。

BP 10.4（推奨）– 不必要なファイルの読み込みを避けるためにデータを分割する

構造化されたパーティションにデータを保存すると、クエリに関連するデータの部分のみの場所を特定できるようになります。
最も頻繁に使用されるクエリパラメータを決定し、データ取得のニーズに適した場所へデータを保存します。

【コスト最適化】11 – ワークロードの使用パターンに基づいて、費用対効果の高いコンピューティングおよびストレージソリューションを選択する

BP 11.1（推奨）– ストレージをコンピューティングから切り離す

データ資産が年々指数関数的に増加するのは一般的です。
ですが、コンピューティングのニーズは同じ速度で増加しないかもしれません。
ストレージをコンピューティングから切り離すことで、ストレージとコンピューティングのコストを別々に管理し、異なるコスト最適化を実装してコストを最小化することができます。

BP 11.2（推奨）– 予測可能なワークロード使用量を計画し、プロビジョニングする

明確に定義されたワークロードの場合、平均的な使用パターンに基づいて容量を事前に計画することで、リソースの使用率が向上し、過剰なプロビジョニングを回避できます。
急変するようなワークロードの場合、ユーザーとワークロードの要求を満たすように自動スケーリングを設定します。

BP 11.3（推奨）– 予測できないワークロード使用量にオンデマンドインスタンスの容量を使用する

サーバーレスソリューションは、処理されるデータの量または使用されるコンピューティングリソースに応じて課金されますが、これはワークロードがアクティブに実行されている場合に限ります。

【コスト最適化】12 – データとワークロードの使用に対する財務責任モデルを構築する

BP 12.1（推奨）– ワークロードのユーザーごとにデータストレージと処理コストを測定する

データ分析ワークロードには、定期的な安定したコスト（比較的に静的なデータストレージ料金）と使用する度に掛かるコスト（定期的に発生する予測不能な処理のランタイム料金）がかかります。
分析システムの実行時にデータストレージとワークロードの使用量を把握する財務帰属の仕組みを確立する必要があります。

BP 12.2（推奨）– ダウンストリームシステムが分析ジョブに独自のリソースを使用できるようにする

必要な俊敏性、チームのスキルセット、一元化された分析プラットフォームのニーズのバランスを考慮して、ローカル分析リソースを構築します。
そのリソースから、いつチームが恩恵を受けるかを決定します。

BP 12.3（推奨）– 共通の共有処理システムを構築し、分析ジョブごとのコストを測定する

個々のチームがデータ分析のリクエストを送信できる共有処理システムを使用する方が効率的です。
各チームのリクエストのコストを把握できるように、チーム毎のリクエスト数を測定する必要があります。

BP 12.4（推奨）– 分析ワークロードの使用量に対する内部チャージバック モデルを構築する

チームの消費量を測定して関連付けるベストプラクティスを確立した後、内部チャージバックモデルを構築する必要があります。
これは、各チームが使用する分析データに対する財務的責任を示します。

BP 12.5（推奨）–AWS Identity and Access Management (IAM) を使用して、リソース割り当て権限を制限および記録する

特定のIAMロールを作成して、特定のリソースをプロビジョニングするための承認を提供します。

【コスト最適化】13 – 長期にわたるコストを管理する

BP 13.1（推奨）– 使用されていないデータとインフラストラクチャを削除する

保存期間を過ぎたデータや不要になったデータを削除します。
ビジネスに影響を与えずに削除できる中間処理データを削除します。
分析ジョブの出力が誰にも使用されていない場合、リソースを無駄にしないために、
そのようなジョブを削除することを検討します。

BP 13.2（推奨）– インフラストラクチャの過剰なプロビジョニングを削減する

特にデータの増加やプロセス最適化が行われた後、
ワークロードのリソース使用率は、時間経過によって変化する可能性があります。
リソースの使用パターンをレビューし、ビジネス目標を達成するために同様のインフラストラクチャのフットプリントが必要かどうかを判断する必要があります。

BP 13.3（推奨）– ビジネス価値のない繰り返し分析ジョブを削減する

分析ジョブの実行頻度は、そのビジネス価値を考慮する必要があります。
データを頻繁に使用しない場合は、データを繰り返し更新する必要はありません。

BP 13.4（推奨）– 費用対効果の高い新しいソリューションを評価し、採用する

AWSが新しいサービスや機能をリリースする際、既存のアーキテクチャ上の決定をレビューして、費用対効果が維持されていることを確認することがベストプラクティスです。

【コスト最適化】14 – インフラストラクチャの使用パターンに基づいて最適な価格設定モデルを使用する

BP 14.1（推奨）– インフラストラクチャの使用パターンを評価し、それに応じて支払いオプションを選択する

定期的なワークロードのリソース使用量の分析を実行します。
コスト最適化の機会を逃さず、割引を最大限に活用するために、最適な価格設定モデルを選択してください。

BP 14.2（推奨）– 財務チームと相談し、最適な支払いモデルを決定します

様々なコスト要因に関して、情報に基づいた意思決定を行います。
これらには、予約する容量、予約期間の長さ、対応する割引率の前払いの選択が含まれます。
財務チームは、最適な長期および予約容量の価格設定オプションを決定する際にチームを支援する必要があります。

【持続可能性】15 – 持続可能性実装ガイダンス

BP 15.1（推奨）– 組織の持続可能性向上のベースラインを設定する

組織として、持続可能性の目標に向けた進捗状況を追跡する必要があります。

BP 15.2（推奨）– データカルチャーのカーボントレーディングを奨励する

持続可能性とは、組織のデータを削除することではありません。
組織はデータを削除するのではなく、組織のデータ資産の可用性を考慮します。
組織は、レポート、更新頻度、コンテンツごとのKPIをレビューして、
必須事項を決定し、持続可能性のコストが何かを理解する必要があります。

BP 15.3（推奨）– データ最小化の文化を奨励し、組織のデータへの影響を軽減する

保存および処理されるデータの量を最小限に抑えると、分析環境へ良い影響を与える可能性があります。
開発チームにデータの最小化または必要十分なデータにするマインドセットを奨励して、
処理されるデータの全体量を削減し、エネルギー使用量を削減します。

BP 15.4（推奨）– データ保持プロセスを実装して、分析環境から冗長なデータを削除する

データを目的もなく無期限に保存すると、ストレージと処理のオーバーヘッド増加の原因となり、分析環境へ影響を与える可能性があります。

BP 15.5（推奨）– 効率的なデータ検索のためにデータモデリングとデータストレージを最適化する

データストア、データベース、ファイルシステムのデータ構成は、データの保存、処理、分析に必要なリソースの量に影響を与える可能性があります。

BP 15.6（推奨）– システムとアプリケーション間の不必要なデータ移動を防止する

データを移動するためには、コンピューティング、ネットワーク、ストレージのリソースが必要となるため、非常にコストがかかる可能性があります。
企業が組織内でデータを移動すると、重複データが作成されるリスクが高まり、ストレージリソースに影響を与える可能性があります。

BP 15.7（推奨）– 分析インフラストラクチャを効率的に管理して、十分に活用されていないリソースを削減する

予測できないピークに備えて十分なリソースを確保するための一般的なアプローチは、リソースを過剰にプロビジョニングすることです。
しかし、このアプローチでは一般的にリソースが十分に活用されず、不必要なときにエネルギーを消費します。

最後に

改めて振り返ると、データ分析に関するお仕事をする際に把握しておきたい話が、
非常に網羅的に詰まっていて、とても勉強になるドキュメントでした。
また他のWell-Architectedのドキュメントも読んで、よりAWSに対する理解度を高めていきたいと思います！！

kurochan