AWS Certified Data Engineer - Associate(DEA-C01)試験対策資料

内容

試験には次の内容ドメインと重み付けがあります。

  1. ドメイン 1: データの取り込みと変換 (34%)
  2. ドメイン 2: データ ストア管理 (26%)
  3. ドメイン 3: データの運⽤とサポート (22%)
  4. ドメイン 4: データ セキュリティとガバナンス (18%)

ドメイン 1: データの取り込みと変換

1.1: データの取り込みを実⾏

データを取り込むAWSサービスのスループットとレイテンシの特性

  • Kinesis Data Streams - TB/時のスループットで、数十万のソースから大量のデータを取り込むことができます。データは1秒以内に処理できるため、待ち時間が短くなります。KCLまたは Spark Streamingなどのフレームワークを使用したカスタムストリーム処理をサポートします。
  • Kinesis Data Firehose - 低レイテンシーでS3やRedshiftなどのAWSデータストアにストリーミング データを取り込むために使用されます。スループット要件に合わせて自動的にスケーリングします。

データ取り込みパターン(頻度やデータ履歴など)

  • バッチ取り込み - 大量のデータが時間ごと、日ごと、または週ごとのバッチのように定期的に取り込まれます。これにより、履歴データを分析用に処理できるようになります。
  • 継続的な取り込み - ストリーミング データは、生成時に継続的に取り込まれます。これによりリアルタイム処理が可能になりますが、順序付けとデータの一貫性に関する課題が伴います。
  • ハイブリッドアプローチ - バッチ処理とストリーム処理を組み合わせます。たとえば、ストリーミング データは、一括処理の前に、まず短いバッチで収集されます。これにより、低遅延のニーズとバッチ効率のバランスが取れます。

ストリーミングデータの取り込み

  • Kinesis Data Streamsは、数十万のデータソースから大規模なストリーミングデータを継続的に取り込んで処理できます。リアルタイムアプリケーションに低遅延のデータアクセスを提供します。
  • Kinesis Data Firehoseは、バッチ処理や分析のためにストリーミングデータをS3やRedshiftなどのデータストアに確実にロードできます。
  • MSK(Managed Streaming for Apache Kafka)を使用すると、Apache Kafkaプラットフォームを使用してスケーラブルなストリーミングデータパイプラインを簡単に構築できます。ストリーミング データの取り込みと処理において、高スループットと低遅延を実現します。
  • Managed Service for Apache Flink（旧Kinesis Data Analytics）は、Apache Flinkを使用してストリーミングデータをリアルタイムで変換および分析できます。複雑なイベント処理、時間枠での集計、長期にわたる状態の維持の機能を提供します。 

バッチデータ取り込み (スケジュールされた取り込み、イベント駆動型の取り込みなど)

  • スケジュールされた取り込み - データは、時間ごと、毎日、毎週などの定義されたスケジュールでソース システムからS3、Redshift などのAWSサービスに取り込まれます。これにより、分析用に大量の履歴データを処理できるようになります。LambdaとEventBridegeの活用はコスト効率が高い
  • イベント駆動型の取り込み - 取り込みは、S3バケットに配置されたファイルやデータベース テーブルに表示されたレコードなどのイベントによってトリガーされます。これにより、固定スケジュールなしで利用可能になったデータをバッチで取り込むことができます。

イベントトリガーの設定(例: S3 イベント通知、EventBridge)
S3イベント通知は、新しいファイルがアップロードされたときに、フィルタールールを使用してLambda関数のARNをイベント通知の宛先としてLambdaに即座にトリガーされるため、プロセスが効率的かつリアルタイムになります。

データ取り込みパイプラインの再生可能性
データ取り込みパイプラインの再生可能性とは、データ取り込みパイプラインを再実行して、以前に取り込まれたデータを取り込む機能を指します。これは、元の取り込みが失敗した場合や、後でさらにデータを追加する必要がある場合に便利です。
Step Functionsを使用して、取り込みワークフローの進行状況を調整および追跡します。Step Functionsは、パイプラインを再生可能にするのに役立つ再試行ポリシーや冪等性などの機能を提供します。

ステートフルおよびステートレスデータトランザクション

  • ステートフルトランザクションでは、アプリケーションはサーバー側で各ユーザーセッションまたはトランザクションに関する状態またはデータを維持する必要があります。これには、ショッピング カートの内容、ユーザー プロフィールなどが含まれる可能性があります。
  • ステートレストランザクションでは、アプリケーションはサーバーに状態を保存しません。状態を独立して維持するために、データベースやキャッシュなどの外部データ ストアに依存します。

バッチソースからのデータの読み取り (例: S3、Glue、EMR、DMS、Redshift、Lambda、AppFlow）
AppFlowを使用すると、フローは送信元と宛先の間でデータを転送します。最小限の運用オーバーヘッドでSaaSアプリケーションからS3、Redshiftなどにデータを継続的に送信できます。

データソースへの接続を許可するIPアドレスのホワイトリストを作成
セキュリティグループを使用して、DBインスタンスへのネットワークアクセスを制御します。特定のIPアドレスまたは範囲からデータベースポート(MySQLの3306など)への接続を許可する受信ルールを追加します。

スロットルの実装とレート制限の克服(DynamoDB、RDS、Kinesisなど)

  • 可能な場合は自動スケーリング機能を使用して、実際の使用パターンに基づいてスループットを動的に調整します。予期しないトラフィックの急増時のスロットリングを防ぐのに役立ちます。
  • 読み取り/書き込み操作をパーティション、シャード、またはAZ全体に均等に分散して、ホットスポットを防ぎます。分散が不均一であると、過負荷のユニットでスロットルが発生する可能性があります。
  • 再試行が有効になっているサービスの場合、構成されたタイムアウト以内に再試行が成功した場合、アクションは必要ありません。ただし、永続的なスロットルには容量の調整が必要です。
  • 同期ワークフローの場合、コード内で非同期/ノンブロッキングパターンとバックオフ/再試行ロジックを使用して、リクエストが失敗する代わりに時折発生するスロットルを適切に処理します。

KinesisからのLambda関数の呼び出し

  • 予想されるデータ量と処理要件に基づいて、より多くのメモリ割り当てを使用してLambda関数を構成します。メモリを増やすと、リソース不足によるスロットリングを回避できます。
  • 複数のLambda関数を使用し、Kinesisストリーム内の異なるシャードからそれらの関数をトリガーして処理を並列化します。これは、複数の機能間で負荷を分散するのに役立ちます。
  • Lambda関数コードに再試行ロジックを実装して、一時的なエラーと再試行を適切に処理します。たとえば、レコード処理を中止する前に数回再試行します。
  • 呼び出し時間、スロットル、遅延（IteratorAge）などのLambda関数のメトリクスを監視して、ボトルネックを特定します。必要に応じて処理を調整するために利用できるレコードなどのKinesisメトリクスも監視します。
  • 一度に1つのレコードを処理するのではなく、Kinesis Client Library（KCL）を使用してレコードをバッチ処理することにより、レコードごとのオーバーヘッドが削減され、スループットが向上します。
  • Lambda関数がKinesis Data Streamsからデータを受け取る際に、Lambda関数のトリガーであるKinesisイベントソースのバッチサイズとバッチウィンドウの設定を検討します。バッチサイズが小さすぎると遅延が発生し、大きすぎるとトリガーごとに処理されるデータの量が多くなります。

1.2: データの変換および処理

形式間でのデータの変換 (たとえば.csvからParquet)
データセットを行指向のCSV形式から列指向のParquet形式に変換すると、特定の列に頻繁にアクセスするGlueジョブのパフォーマンス効率が向上します。

パフォーマンスのニーズに合わせてコンテナの使⽤を最適化します(例: EKS、ECS)

  • EKSにアプリケーションをデプロイし、Kubernetesクラスター内のGPU高速化されたEC2インスタンスを活用します。
  • 水平ポッド自動スケーリングを使用して、リアルタイムのCPUとメモリ使用量に基づいてポッド数を動的に調整します。
  • パフォーマンスメトリックに基づいて自動スケールポリシーを実装し、必要に応じてリソースを動的にスケールアップまたはスケールダウンします。

様々なデータソースへの接続 (JDBC、ODBC)

  • JDBC（Java Database Connectivity）：JavaアプリケーションがRDBと対話できるようにするJavaベースのAPI

  • ODBC：データベースに接続するための標準インターフェイス。特定のプログラミング言語に限定されません。ドライバーマネージャーとドライバーを使用して、さまざまなデータベースに接続します。

中間データのステージング場所
中間データのステージングロケーションは、変換されたデータをターゲットデータベースまたはデータウェアハウスにロードする前に一時的に保存するために、パイプラインで一般的に使用されます。
ステージング領域の一般的なストレージオプション：S3、EFSファイルシステム、FSxファイルシステムなど

  • パフォーマンス - ステージング領域を使用すると、ターゲット データベースのパフォーマンスに影響を与えることなく、オフラインでデータを変換および準備できます。これにより、リソース使用量の急増が防止されます。
  • エラー処理 - データのロードプロセス中にエラーが発生した場合は、問題のあるデータをターゲットにロードする前に、ステージング領域でエラーを捕捉する方が安全です。ステージング領域により、データの検証とクレンジングが容易になります。
  • データの分離 - データをターゲットデータベースから分離してステージングすると、ETLプロセスが分離され、ロード中に問題が発生した場合でもターゲットデータが破損しないことが保証されます。

1.3: データパイプラインの調整

オーケストレーション サービスを使用してデータETLパイプラインのワークフローを構築する(例: Lambda、EventBridge、MWAA、Step Functions、Glueワークフロー)

  • Step Functionsを使用すると、ステートマシンを視覚的に作成して、Lambda、Glue、RedshiftなどのAWSサービス間のワークフローを調整できます。複数ステップのETLプロセスを調整するためのサーバーレスな方法が提供されます。

  • Glueワークフローを使用すると、ワークフローに連結できるPythonまたはScalaベースのETLジョブを構築できます。Glueは、基盤となるリソースのスケジューリング、監視、スケーリングを処理します。

  • LambdaとS3、DynamoDB、Kinesisなどのサービスを使用して、イベント駆動型のETLパイプラインを構築できます。たとえば、S3アップロードによってLambda関数をトリガーして、データを処理してRedshiftにロードできます。

  • これらのサービスからのCloudWatchメトリクスとアラートにより、ETLジョブのステータスとパフォーマンスを可視化できます。

スケジュールまたは依存関係に基づいてデータパイプライン用にAWSサービスを構成する方法

  • Step Functions - ワークフローは、EventBridgeルールを使用してスケジュールに従ってトリガーできます。
  • Glueワークフロー - ジョブ間の依存関係は、ワークフローの構築中に定義されます。
  • Data Pipeline - データを操作または生成するアクティビティを含むパイプラインを定義するために使用できます。パイプラインは定期的に実行するようにスケジュールできます。
  • イベントソースを備えたLambda - S3、DynamoDB、Kinesisなどのサービスからのイベントによってトリガーされ、イベント駆動型のデータパイプラインを構築できます。関数は完了に基づいて相互に呼び出すこともできます。

サーバーレスワークフローの実装と保守

  • Step Functionsを使用すると、ステートマシンを視覚的に作成して、サーバーレスアプリケーションのコンポーネントをオーケストレーションおよび調整できます。個々のステップでは、Lambda関数、DynamoDBなどのAWSサービスを呼び出すことができます。Step Functionsは、依存関係に基づいてステップが正しい順序で実行されることを保証します。
  • 失敗した場合は自動的に再試行され、エラーが処理されます。これにより、アプリケーションでのカスタムエラー処理コードの必要性が減ります。
  • Step Functionsのメトリクスとトレースにより、ワークフローの実行を可視化できます。これは、ワークフローの監視とトラブルシューティングに役立ちます。
  • Lambda、SQS、SNSなどのサービス上の独立した分離されたコンポーネントで構築されたサーバーレスアプリケーションは、Step Functionsを使用して統合できます。 

通知サービスを使⽤してアラートを送信する（SNS、SQS）
SNS通知をSQSキューに送信するには、SQSを指定してトピックをサブスクライブします。トランスポートとして使用し、エンドポイントとしてSQSキューARNを提供します。
メッセージを正常に配信するには、SQSキューの所有者がキューをSNSトピックにサブスクライブする必要があります。通知は自動的にSQSキューに配信されます。

1.4: プログラミングの概念

CI/CD（実装、データパイプラインのテストとデプロイ）

  • CodePipelineは、ビルド、テスト、デプロイなどの複数の段階を含むワークフローを調整するのに最適です。ソース管理のためにGitHubと統合でき、ビルドとテストのためにCodeBuildを組み込むことができます。
  • CodeBuild、CodePipeline、CodeDeployなどのAWSサービスは、AWSでのCI/CDパイプラインのセットアップと管理に役立ちます。コード変更の構築、テスト、展開のプロセスを自動化するため、組織は新機能をより迅速かつ確実にリリースできるようになります。

反復可能なデプロイメントのためのIaC

  • AWS SAM：AWSでサーバーレスアプリケーションを定義できるフレームワーク。SAMを使用すると、いくつかのコマンドを実行するだけで、Lambda 関数、API Gateway API、DynamoDBテーブルで構成されるアプリケーションを構築してデプロイできます。
  • 単一のSAMテンプレートを開発し、SAMの組み込みパラメータと環境変数設定を使用して、環境ごとに異なる設定を管理します。CodePipelineとCodeBuildを使用してデプロイプロセスを自動化し、デプロイ段階で環境固有のパラメータを統合します。
  • AWS CDKは、開発者がプログラミング言語（TypeScript、Python、Java、C#）を使用してクラウドインフラストラクチャを定義およびデプロイするためのフレームワークです。
  • CloudFormation：JSONまたはYAML形式のテンプレートを使用してAWSリソースを定義し、スタックとしてデプロイできるサービス

SQLクエリの最適化

  • パフォーマンスを向上させる可能性がある欠落しているインデックスがないか
  • 不要な結合や派生テーブルなどの非効率性がないか
  • テーブルに大量のデータが含まれている場合は、テーブルをパーティション分割して、特定の範囲の値でフィルター処理するクエリを最適化する
  • フィルタリングや結合で頻繁に使用される列にソートキーを実装する
  • 先頭文字と末尾文字を指定する正規表現
  • 複合キーの使い方
  • 述語に必要なデータブロックのみをフェッチすることで、I/Oコストが削減される

Lambda関数内からのストレージボリュームの使用とマウント

  • Lambda関数からEFSファイルシステムにアクセスできます。EFSファイルシステムを作成し、Lambda関数が設定されているのと同じVPCにターゲットをマウントします。
  • ファイルシステムIDとマウントポイントのパスを指定して、EFSファイルシステムに接続するようにLambda関数を設定します。これは、LambdaコンソールまたはAWS CLI/SDKを介して実行できます。
  • 設定が完了すると、Lambda関数コードは関数の実行中にEFSファイルシステムに保存されているファイルの読み取り・書き込み・変更ができるようになり、安全な方法でLambdaの同時呼び出し間でデータを共有できる

ドメイン 2: データストア管理

2.1: データストアの選択

データ保存形式(.csv、.txt、Parquetなど)

  • S3内のデータをParquetなどの効率的な列指向形式に変換すると、Athenaでのクエリのパフォーマンスが大幅に向上し、クエリのコストを削減できます。

  • AthenaでCTASを使用してETLタスクのSQLクエリを実行します。CREATE TABLE AS SELECT(CTAS)クエリは、別のクエリからのSELECTステートメントの結果から、Athenaで新しいテーブルを作成します。

CREATE TABLE new_table AS 
SELECT * 
FROM old_table 
WHERE condition;

  • Athenaワークグループにより、Sparkを使用してAthenaにアクセスできます。

  • Athenaでクエリを再実行する場合、オプションで最後に保存されたクエリ結果を再利用することを選択できます。このオプションにより、パフォーマンスが向上し、スキャンされるバイト数によりコストが削減されます。

データ移⾏またはリモート アクセス⽅法の実装

  • Redshiftフェデレーテッドクエリ - データを移動せずに運用データベース、データウェアハウス、データレイク全体でデータのクエリと分析を行います。

  • Redshiftマテリアライズドビュー - クエリの結果を保存し、基になるデータが変更されると自動的に更新されます。これにより、毎回複雑なクエリを再実行することなく、事前計算された結果にアクセスできるようになります。Lambdaユーザー定義関数(UDF)を使用して、マテリアライズドビューを更新できます。

  • Redshift Spectrum - 標準SQLを使用して、S3内の外部データをクエリします。 Redshiftはユーザーに代わってすべてのインフラストラクチャとクエリの実行を管理するため、データをデータウェアハウスに移動する必要はありません。

  • Redshiftデータ共有 - データをコピーせずに、Redshiftクラスターまたは読み取りアクセス用のアカウント全体でライブトランザクションデータを共有します。データベース、スキーマ、テーブルレベルなどできめ細かなアクセスを提供できます。

  • Redshift Data API：Redshiftに対してクエリを実行するためにJDBCまたはODBCドライバーを使用する代わりとなる軽量のHTTPSベースのAPI。アプリケーション内から直接SQLクエリを実行できるようになる

  • Redshiftの同時実行スケーリングにより、Redshiftクラスターはワークロードの需要に応じてコンピューティングリソースを自動的に追加および削除できます。機械学習を用いたWLM（ワークロード管理）キューレベルで同時実行スケーリングを有効にすると、クエリワークロードに基づいて同時実行スケーリングの恩恵を受けるキューを指定できます。

  • DMS - オンプレミスとAWSデータベース間の異種データベース移行には、DMSを使用します。 MySQL、Oracle、PostgreSQL、MongoDB、および Microsoft SQL Server を移行できます。ソースデータベースからのデータ転送が最も重要な要素であるため、移行元のリージョンにレプリケーションインスタンスを配置することが推奨

データへのアクセスを防ぐためにロックを管理する方法(Redshift、RDSなど)

  • Redshift - テーブルレベルのロックを使用して、DDLステートメント、COPY、INSERTなどの操作中のテーブルへのアクセスを制御します。ブロックの原因となる可能性のあるロックを保持しているセッションを特定し、それらのセッションを終了してロックの問題を解決します。
  • RDS - データベースエンジンでサポートされているロックメカニズムと、ロックの管理に関するベストプラクティスを理解します。MySQL、PostgreSQLなどの異なるデータベースは、行レベルまたはテーブルレベルで異なるロック戦略を使用します。

2.2: データカタログシステムの理解

データカタログを使用してデータソースからデータを消費する

  • データカタログは、すべてのデータ資産に関するメタデータの中央リポジトリとして機能します。これには、テーブル定義、物理的な場所、スキーマ、属性が含まれます。
  • ほとんどのソースでは、そこから読み取るジョブを作成する前に、テーブルがソースタイプに対応するデータカタログに存在する必要があります。テーブルスキーマは、データ構造に関する情報を提供します。
  • テーブルは、クローラー、Glueコンソール、またはAPIを使用してカタログに追加できます。S3バケットなどのデータソースをクロールすると、テーブル定義が自動的に生成されます。
  • テーブルが追加されると、メタデータはGlueなどのサービスのETLジョブでソースから読み取ることができるほか、AthenaやRedshift Spectrumなどのデータレイクでのクエリにも使用できるようになります。

データカタログの構築と参照(Glueデータカタログ、Apache Hiveメタストアなど)

スキーマを検出し、Glue クローラーを使用してデータカタログを設定する

  1. クローラーは、S3バケットやデータベーステーブルなどのデータソースをスキャンするように構成されています。
  2. CSV、JSONなどのさまざまな形式のファイルのスキーマと構造を推測する分類子を実行します。
  3. クローラーはデータソースに接続し、ファイルのメタデータとサンプルを読み取ります。
  4. 推論されたスキーマに基づいて、データ構造、場所、その他のメタデータの詳細を含む対応するテーブルがGlueデータカタログ内に作成されます。

パーティションとデータカタログの同期

  1. ETLプロセス中にデータから年、月、日などのパーティションキーを抽出します。
  2. ターゲットのGlueカタログテーブルにこれらのパーティションキー列を作成し、パーティションとしてマークします。
  3. ジョブ構成で、enableUpdateCatalogをTrueに設定してAdditionalOptionsパラメーターを追加します。また、AdditionalOptions[partitionKeys]にパーティションキーを指定することにより、新しいパーティションが作成されるとカタログを更新するようにGlueジョブに指示されます。
  4. クローラーを再実行するか、カタログにクエリを実行して、ETLジョブの実行から設定された新しいパーティションを確認できます。

2.3: データライフサイクルの管理

S3とRedshiftの間でデータを移動するためのロードおよびアンロード操作の実⾏
COPYコマンドを実行して、S3バケットからRedshiftテーブルにサンプルデータをロードします。次に、UNLOADコマンドを実行して、データをS3バケットにアンロードします。

S3 データのストレージ層を変更するためのS3ライフサイクルポリシーの管理

  • S3 Infrequent-Accessストレージクラスでは、AthenaでSQLを使用することで、コスト効率よくデータを不定期分析に利用できるようになる。
  • データをS3 Glacier Flexible Retrievalストレージクラスに移行するライフサイクルルールにより、データを12時間以内に利用できるようになる。
  • デフォルトのアクセス層でS3 Intelligent-Tiering(アクセス頻度に基づいてデータを最も費用対効果の高いアクセス階層に自動的に移動する)を使用することにより、ストレージコストの最適化に対する手動のアプローチが提供される。

S3バージョン管理とDynamoDB TTLの管理
S3バージョニングを有効にすると、意図しない削除または上書きから回復する手段が提供されます。これをライフサイクルと組み合わせるポリシーにより、定義された期間の経過後に古いバージョンのオブジェクトを自動的に削除できるため、ストレージコストを効果的に管理できます。
DynamoDBのTTL機能は、一定の期間を過ぎたアイテムを自動的に削除するため、テーブルのサイズとコストを制御できます。

2.4: データモデルとスキーマの進化を設計

データリネージを使用してデータの正確性と信頼性を確保する方法

  • Glueデータカタログを利用して、スキーマ、パーティション、データプロファイリング結果などのメタデータを保存します。これにより、データがパイプラインを通過する際にどのように関連し、変換されるかを可視化できます。
  • Glue DataBrewを使用すると、データ品質をプロファイリングし、問題を特定できます。加えられた変更はすべて追跡され、データ系統が維持されます。
  • ETLジョブの場合、Glueワークフローを使用してジョブ間の依存関係を追跡し、ソースとターゲットの間でデータがどのように流れるかを理解します。
  • Glueクローラーを利用して再クロールをスケジュールし、スキーマまたは構造の変更を検出します。これにより、系統グラフが常に最新の状態に保たれます。
  • SageMaker ML Lineage Trackingは、MLワークフローのステップに関する情報を作成して保存します。モデルのガバナンスと監査基準を確立できます。 データリネージ（Data Lineage）：利用されるデータがどこで登録され、どのシステムを経由し、なおかつどのように加工されて眼前に至っているのか、源泉から現在地点までのデータの変遷 

Redshift、DynamoDB、Lake Formationのスキーマの設計

  • DynamoDB - 関連データが複数のテーブルに分割されるのではなく、同じテーブルに一緒に保存される非正規化データモデルを使用⇨結合の必要がなくなり、パフォーマンスが向上します。

  • Lake Formation - 正しいデータ型とパーティション化キーを使用して明確に定義されたスキーマを用意⇨スキーマの適用、セキュリティ、クエリの最適化などの機能が有効になります。

  • Redshift - 列指向データストレージを活用して、大規模なデータセットに対する高性能分析を行うことができます。主キーと外部キーを使用して正規化された形式でテーブルを設計し、関係を表します。また、ファクトテーブルとディメンションテーブルに分けます。

スキーマ変換の実行(例: SCTおよびDMS Schema Conversionを使用)
SCTとDMSスキーマ変換は両方とも移行のために連携して機能します。SCTはスキーマをコピー/変換し、DMSはデータベース/データ ウェアハウス間で進行中のデータ レプリケーションを処理します。DMSでの変換により、移行中にスキーマ、テーブル、または列を変更できます。

スキーマ進化テクニック

  • スキーマ進化手法には、時間の経過に伴うデータ特性の変化にシームレスに対応するアプローチが含まれます。AWSサービスを使用したスキーマ管理は、Cloud Directory、Glue Schema Registryなどがあります。
  • ステージング領域があると、データの前処理が可能になり、Glueを使用して変換やスキーマを処理できます。

ドメイン 3: データの運⽤とサポート

3.1: AWS のサービスを使⽤してデータ処理を⾃動化

コードからAmazonの機能にアクセスするためのSDKの呼び出し

  • AWS SDK for Javaを使用すると、S3、EC2、LambdaなどのAWSサービスをJavaコードから呼び出すことができます。 SDKの依存関係をプロジェクトに追加し、サービスクライアントを呼び出すことができます。
  • Node.jsアプリケーションの場合は、AWS SDK for JavaScriptを使用してサービスに非同期的にアクセスします。必要なクライアントをインポートし、それらのメソッドを呼び出します。
  • Pythonの場合は、AWS SDK for Python(Boto3)を使用すると、PythonのコードからプログラムでAWSのサービスにアクセスできます。

データ処理のための API 呼び出し
API GatewayとLambdaを活用すると、自動スケーリングで変動する負荷を処理するのに最適なサーバーレスアーキテクチャが提供されます。

データパイプラインのオーケストレーション(MWAA、Step Functionsなど)

  • Step Functionsを使用すると、複数のAWSサービスをサーバーレスワークフローに調整できます。コンソールまたはSDKを使用して、ステートマシンを視覚的に設計できます。 ETLジョブなどの一般的なタスクは、Lambda、Glueなどを呼び出すステップに分割できます。Step Functionsはエラー、再試行を処理し、ステップが順番に実行されることを保証します。

  • MWAA(Amazon Managed Workflows for Apache Airflow)は、Apache Airflowワークフローの実行と管理を簡素化します。Airflow環境の展開、パッチ適用、スケーリングを処理します。使い慣れたAirflow UI/UXを使用してワークフローを開発し、さまざまな AWSサービスをタスクとして統合できます。

  • どちらのオプションでも、CloudWatchを通じてパイプラインの実行を可視化できます。 Step Functionsは線形ワークフローに最適ですが、条件付きロジックを備えた複雑なDAGベースのワークフローにはMWAAの方が適している場合があります。

3.2: AWSサービスを使⽤したデータ分析

プロビジョニングされたサービスとサーバーレスサービスの間のトレードオフ

  • プロビジョニングされたサービスでは、サーバーが使用中かアイドル状態かに関係なく、サーバーの料金を支払う必要があります。サーバーレスでは、実際の使用量と処理されたリクエストに基づいて支払います。サーバーレスは、予測不可能なワークロードや断続的なワークロードに対して、よりコスト効率が高い可能性があります。
  • 通常、サーバーレスサービスにはAuto Scalingが組み込まれているため、トラフィックの増減に応じてアプリケーションを動的にスケーリングできます。プロビジョニングされたサーバーでは、フリートを手動でスケールアップまたはスケールダウンする必要があります。
  • 年中無休のワークロードを伴う一部の複雑なアプリケーションでは、完全な制御のためにプロビジョニングされたインフラストラクチャが依然として必要な場合があります。ただし、サーバーレスは、ほとんどのイベント駆動型、断続的、または予測不可能なワークロードに適しています。

AWSサービスとツール(DataBrew、QuickSight、Glue など)を使⽤したデータの視覚化

  • Glue DataBrew：分析用にデータをクリーンアップ、正規化、変換するのに役立つ視覚的なデータ準備ツール。コードを記述することなく、対話型のプロファイリング、探索、高度な変換を提供します。

  • NEST_TO_MAP変換は、ユーザーが選択した列を、列名を表すキーと行の値を表す値を含むキーと値のペアに変換します。
    例）

    "RecipeAction": {
        "Operation": "NEST_TO_MAP",
        "Parameters": {
            "sourceColumns": "[\"age\",\"weight_kg\",\"height_cm\"]",
            "targetColumn": "columnName",
            "removeSourceColumns": "true"
        }
    }
  • QuickSight：大規模なインタラクティブなデータ視覚化のためのフルマネージド型ビジネスインテリジェンスサービス。ユーザーはさまざまなデータソースに接続し、ダッシュボードやレポートを構築して洞察を得ることができます。

データの検証とクリーニング (Lambda、Athena、QuickSight、Jupyter Notebooks、SageMaker Data Wranglerなど)

  • 15分未満の小規模なワークロードの場合は、Lambdaを使用して軽量のデータの準備とクリーニングを行います。Lambdaは小規模なジョブではコスト効率が高くなります。
  • Athenaは、S3などのオブジェクトストレージ内のデータに対するインタラクティブなクエリに使用でき、スキーマの検証や異常の検出に役立ちます。
  • SageMaker Data Wranglerは、機械学習用のデータの選択、クレンジング、探索、変換を支援するビジュアルインターフェイスを提供します。
  • 高度に安全なデータの場合は、AWSに移行する前に、Outpostsを使用してクレンジングと変換をオンプレミスで直接実行します。

Apache Sparkを使用するAthenaノートブックを使用してデータを探索する

  • Apache SparkでAthenaノートブックを使用すると、Athenaコンソールから直接Spark SQLおよびSpark DataFrame APIを使用してデータを探索および分析できます。S3、GlueデータカタログなどのさまざまなAWSデータ ソースのデータに、個別にロードすることなくアクセスできます。
  • Glueを使ってデータソースからデータを取り込み、Apache Sparkベースのデータ処理パイプラインでデータを加工・変換した上で、処理済みのデータをS3に出力する

3.3: データパイプラインを維持および監視

パフォーマンスの問題のトラブルシューティング

  • S3に保存されているGlueジョブログを分析して、スクリプトエラーやデータの不整合を正確に特定する可能性のあるエラーメッセージや警告を見つける。
  • CloudWatchでGlueジョブ実行メトリクスを検査し、データ処理時間の増加のパターンやディスクへの過剰なデータの流出のインスタンスがないか確認する。
  • ETLスクリプトをリファクタリングして、シャッフル操作を最小限に抑え、データパーティショニング戦略を強化し、特定されたオーバーヘッドに対処する。
  • コードに非効率な変換、不必要な結合、フィルターがないか確認する。
  • Athenaパーティション射影を使用することで、パーティション管理を自動化できます。Athenaがクエリ実行時にS3オブジェクトを効率的にグループ化できるようになります。
TBLPROPERTIES (
  'projection.enabled'='true',
  'projection.partition_date.type' = 'date',
  'projection.partition_date.range' = '2020/10/01,NOW',
  'projection.partition_date.format' = 'yyyy/MM/dd/HH',
  'projection.partition_date.interval' = '1',
  'projection.partition_date.interval.unit' = 'HOURS',
  'storage.location.template' = 's3://<S3バケットのパス>/${partition_date}'
)
  • STL_ALERT_EVENT_LOG は、クエリまたはユーザー定義のパフォーマンスしきい値に関連するアラート/通知を記録します。

AWSサービスを使用したログの分析(Athena、EMR、OpenSearch Service、CloudWatch Logs Insights、ビッグデータアプリケーション ログなど)

  • CloudWatch Logs Insights - CloudWatch Logsに保存されているログデータを対話的に検索および分析します。クエリを実行して、運用上の問題に対応できます。
  • OpenSearch Service - 一元化されたログソリューションを使用して、EC2 インスタンス、EKSクラスター、S3、syslogなどのさまざまなソースからログをOpenSearchに取り込みます。次に、SQLのようなクエリを使用してログを分析します。
  • EMR - Hadoop/Sparkを使用して、S3に保存されている大量のログデータを処理します。ログデータに対してMapReduceジョブまたはSparkアプリケーションを実行することで、洞察を抽出できます。大規模なETLはEMR、小規模はGlue
  • EMRクラスターにおけるHiveメタストアのシームレスな移行を実現する。 Hiveメタストア：Hiveで使用されるデータベースの構造、テーブル、パーティションなどのメタデータを格納する場所

3.4: データ品質の確保

データサンプリング⼿法

  • ランダムサンプリング - より大きなデータセットからデータ ポイントのサブセットをランダムに選択します。これにより、データ全体が公平に表現されます。
  • 層化（stratified）サンプリング - 母集団を同種のグループまたは層に分割し、各層から比例してサンプルをランダムに選択します。これにより、重要なサブグループが確実に表現されます。
  • 体系的（systematic）サンプリング - データセットから一定の間隔でデータ ポイントを選択します。
  • クラスターサンプリング - 母集団からクラスターをランダムに選択し、選択したクラスター全体からデータを収集します。
  • 多段階サンプリング - サンプリングが複数の段階で行われる層別設計。たとえば、都市をランダムに選択し、次に都市内の近隣地域を選択し、次に近隣地域内の世帯を選択します。

データスキューメカニズムを実装する⽅法

  • Glue Data Qualityを使用して、データ内の異常や異常なパターンを自動的に検出します。機械学習アルゴリズムを使用して、時間の経過とともにパターンを学習します。

  • Glue Studio内で、データ品質チェック変換を適用して、データパイプライン全体のデータ品質を評価します。これにより、ソース間でデータが移動する際のスキューを監視できます。

  • スキューが検出された場合にパイプラインを停止できるデータ品質ルールを定義し、不良データがデータレイクに取り込まれるのを防ぎます。
  • Glue ETLを使用すると、検出されたデータ品質の問題やスキューを簡単に修復し、クリーンなデータをデータレイクに取り込むことができます。
  • CloudWatchを使用してデータ品質のメトリクスとスコアを監視します。

データ検証(データの完全性、⼀貫性、正確性、完全性)
データの⼀貫性の調査(Glue DataBrewなど)
DataBrewの組み込みデータプロファイリング機能を使用して、欠落データや一貫性のないデータなどのデータ品質の問題を自動的に分析および特定します。

ドメイン 4: データセキュリティとガバナンス

4.1: 認証メカニズム

IAMグループ、ロール、エンドポイント、サービスの作成と更新
ユーザーロールごとにIAMグループを作成し、必要な権限をこれらのグループに付与します。（最小権限の原則）

4.2: 承認メカニズムの適⽤

Lake Formationによるアクセス許可の管理(Redshift、EMR、Athena、およびS3の場合)

  • データにアクセスするユーザーとアプリケーションに対して、データベース、テーブル、列、セルレベルでセキュリティポリシーベースのルールを定義し、データガバナンスとアクセス制御を実現します。
  • Lake Formationを使用すると、S3でのデータ アクセスのアクセス許可を管理できます。S3ロケーションをLake Formationに登録する場合、そのロケーションに対する既存の権限を確認することを選択できます。これにより、Lake Formationユーザーがアクセスしたときに既存のデータが安全に保たれるようになります。
  • Redshift - Lake Formationは各データ共有を対応するGlueデータカタログデータベースにマッピングします。その後、これらのフェデレーションデータベースを共有し、Lake Formation権限を使用してアクセスを制御できます。
  • EMR - Lake Formation統合により、Glueデータカタログオブジェクトにアクセスするための認可ポリシーを定義できます。これにより、インタラクティブなEMRジョブにポリシーが適用され、監査イベントがCloudTrailに送信されます。

データベース ユーザー、グループ、ロールにデータベースへのアクセスと権限を付与する(Redshiftなど)

  • データベースロールを作成し、システムレベルとオブジェクトレベルの権限を各ロールに割り当てます。
  • ロールを使用すると、GRANTおよびREVOKE権限を通じて、データベース、スキーマ、テーブル、列レベルでのきめ細かいアクセス制御が可能になります。個々のユーザーまたはグループがアクセスできるデータとアクションを制御できます。
  • 行レベルのセキュリティポリシーでは、さまざまなロールの行レベルでデータアクセスをさらにフィルタリングできます。

アプリケーションとデータベースの認証情報の保存(例: Secrets Manager、Systems Manager Parameter Store)

  • Secrets Managerはシークレット管理用に特別に設計されており、データベース パスワードの自動ローテーションのサポートが組み込まれています。
  • パラメーターストアはシークレットの保存にも使用できますが、自動ローテーションはサポートされていません。ただし、Secrets Managerに保存されているシークレットを参照できるため、ローテーションはSecrets Managerによって処理されます。
  • Secrets Managerに保存されているシークレットは、複数のリージョン、アカウント、サービスにわたって簡単に参照できますが、パラメーターストアのシークレットは単一リージョンのみに限定されます。
  • データベース資格情報や自動ローテーションが必要なその他のシークレットにはSecrets Managerを、非シークレット構成データや自動ローテーションを必要としないシークレットにはパラメータ ストアを使用します。

4.3: データの暗号化とマスキング

AWS分析サービスで利用可能なデータ暗号化オプション(Redshift、EMR、Glueなど)

  • Redshiftは、KMSキーを使用した静置中の暗号化をサポートしています。クラスター内のデータと自動または手動のスナップショットの両方を暗号化できます。
  • EMRは、EBSボリュームを暗号化して使用することができます。EMRクラスターを起動する際にEBSボリュームの暗号化を有効にできます。
  • Glueデータが格納されているS3バケットを暗号化することができます。これにはサーバーサイド暗号化（SSE）を使用し、SSE-S3、SSE-KMS、またはSSE-C（ユーザー提供のキー）を選択できます。
  • QuickSightは、データソースのデータの静置中の暗号化にKMSを使用します。データはS3に格納されている場合、S3サーバーサイド暗号化を使用できます。

クライアント側の暗号化とサーバー側の暗号化の違い

  • SSE-KMSによるサーバー側暗号化を使用することにより、AWS管理キーを使用して保存データが暗号化されます。
  • S3暗号化クライアントなどのクライアント側の暗号化ライブラリを活用することにより、顧客が提供したキーを使用してアップロードする前にデータが暗号化されます。

AWSアカウントの境界を越えた暗号化の構成

  • 暗号化にはAWS管理キーの代わりにカスタマー管理キー(CMK)を使用します。CMKはアカウント間で共有できますが、AWS管理キーは共有できません。
  • AWS Backupを使用したクロスアカウントバックアップをサポートするサービスでは、カスタマー管理キーとAWS管理キーの両方を使用できます。
  • EC2ボリュームなど、AWS Backupでクロスアカウントバックアップをサポートしていないサービスの場合は、AWS管理キーがサポートされていないため、CMKを使用する必要があります。

データの匿名化、マスキング、キーソルティング

  • Glueは、データを変換するときにマスキングや変換を適用することができます。これにより、データの一部を匿名化したり、個人情報をマスキングしたりできます。
  • Redshiftは、データを格納およびクエリする際にマスキングや変換を行うことができます。ビューを使用して必要なデータのみを公開し、機微な情報を保護することができます。

暗号化キーを使用してデータを暗号化または復号(例: AWS KMS)
KMS暗号化キーを使用してRDSインスタンスと関連するすべてのスナップショット、バックアップ、レプリカを暗号化できます。

4.4: 監査⽤のログを準備

CloudTrail Lakeを使用した一元的なロギングクエリ

  • CloudTrail Lakeを使用すると、AWS環境全体でCloudTrailによって記録されたすべてのアクションを1か所でクエリすることで、インシデント調査が簡素化されます。
  • CloudTrail Lakeは、構造化されたログ データの最適化された処理により、ログを分析するためのほぼリアルタイムのクエリ機能を提供し、インシデント対応に役立ちます。
  • 一元化されたアクセスログにより、組織のAWSリソース全体のログ管理、コンプライアンスレポート、監査が1つのシステムで可能になります。

4.5: データのプライバシーとガバナンスの理解

許可されていないリージョンへのデータのバックアップやレプリケーションを防ぐデータプライバシー戦略の実装

  • IAMポリシーを使用して、aws:RequestedRegion条件キーを使用して、許可されたリージョン外のアクションやサービスへのアクセスを拒否します。
  • AWS Organizations - SCPを作成して、リージョンに基づいて特定のAWSサービスまたはリソースへのアクセスを制限します。
  • AWS Control Towerの「リージョン拒否」を実装する組織単位レベルでガードレールを設定し、特定のIAMプリンシパルおよびサービスに対して選択されたリージョンへのアクセスを拒否します。
  • RDS - DBインスタンス作成時に、create-db-instance コマンドの --availability-zone パラメータを使用して、許可されたリージョン内のAZを指定します。これにより、バックアップとレプリカも同じリージョン内に作成されるようになります。
  • DynamoDB - CreateTable APIのRegionalパラメータを使用して、許可されたリージョンにのみテーブルを作成します。

データ共有のアクセス許可の付与(Redshiftのデータ共有など)
Redshiftでのデータ共有に関しては、通常、IAMとRedshift固有の権限を使用してアクセス許可を管理します。Redshiftでのデータ共有は、多くの場合、クロスアカウントアクセスを使用して、または同じAWSアカウント内で異なるRedshiftクラスター内で行われます。

PII識別の実装(例: Lake Formation)

  • 検出された機密データは、さらなる分析とガバナンスのためにLake Formationデータレイクに取り込まれます。Lake Formationは、この機密データの安全を確保するために、行レベルのセキュリティ、監査、アクセス制御などの機能を提供します。
  • Glueクローラー、DataBrew、Athenaなどのツールを使用すると、Lake Formationデータレイク内のデータをさらに分析し、データ品質を目的として重複または一致するPIIレコードを特定できます。

  • S3オブジェクトLambda関数内に編集ロジックを実装して、データにアクセスする各アプリケーションのニーズに基づいてPIIを動的に編集します。

  1. 組み込みのLambda関数を編集関数として使用し、S3 Object Lambdaアクセスポイントにアタッチします。
  2. アプリケーション(Analyticsアプリケーションなど)が標準S3 GETリクエストを送信する場合、S3 Object Lambdaアクセスポイントを介して行われたこれらのリクエストは、事前作成された編集用Lambda関数を呼び出し、サポートしているS3アクセスポイントを介してS3バケットから取得したPIIデータを検出して修正します。

  3. S3 Object Lambdaアクセスポイントは、編集された結果をアプリケーションに返します。

  • Glue StudioのDetect PII変換を使用してPIIを識別し、Glue Data Qualityでルールを作成してPIIを難読化します。 

FSx for NetApp ONTAPで階層的にクォーターを掛ける方法

技術検証

サービス概要

前回、[技術検証]FSx for ONTAPでドメイン参加できなかったのでCIFSサーバーを立ててドメイン参加⇨ファイル共有までしてみたで、FSx for ONTAPをドメイン参加させてファイル共有まで作成しました。
今回は、フォルダ階層構造でクォーター制限をしたいという要望があったため、その実現方法について検証します。

目的・やりたいこと

ファイルサーバーでONTAPを利用していて、各フォルダに対して容量制限をかける際、第二階層以降のフォルダに対しても容量制限をかけたい。
各フォルダに対して容量制限をかけたい場合、qtreeコマンドを利用してフォルダに対して容量制限を行う。だが、ONTAPの仕様上、qtreeでは第二階層以降には容量制限をかけることができず、

ボリューム内のqtreeの下にqtreeを階層的に作成できますか。
回答：ボリューム内のqtreeにqtreeを階層的に作成することはできません。

お客様の要望として、第二階層以降のフォルダに対して容量制限をかけたいというのがある。

対象者

ONTAPでサブフォルダに対してもクォーターを効かせたいONTAP運用技術者

対象となる技術

  • FSx for NetApp ONTAP
  • FlexVol
  • ジャンクションパス：ボリュームがマウントされるSVMの名前空間内の場所

条件（導入にあたっての前提事項）

  • ドメイン参加したFSx ONTAPが作成済みであるとします。

参考URL

ここで質問してみたところ、以下の回答が得られたので、実践すべくこれを検証します。

サブフォルダを flexvol として作成し、それらを名前空間に結合することができます。FlexVol のサイズは基本的にクォータになります。ただし、管理オーバーヘッドが追加されます。

ONTAP 9を起動しました。13.1ラボでこれをテストしたところ、動作しました。
System Manager を使用して次のことを実行しました(CLI を使用しても同じことができます) 。
1. 10TBボリュームを作成し、CIFS経由で共有しました(マウントパスは/DataVolume)
2. ボリューム内にQtreeを作成し、50MBクォータを適用しました(マウントパスは/DataVolume/Qtree1)
3. 10TB ボリュームを作成しましたが、最初はマウントしませんでした。
4. ボリュームマウントパスを編集し、/DataVolume/Qtree1/MySubFolder にマウントすることを選択します)
10TBのデータを\CIFSServer \DataVolume にコピーできます。
\CIFSServer\DataVolume\Qtree1 に最大50MBまでしかコピーできません。
\CIFSServer\DataVolume\Qtree1\MySubFolder に10TBのデータをコピーできます。
明らかに、別個のFlexVolであるため、通常どおりにスナップショットポリシーとスナップミラー保護を適用する必要があります。新しいflexvolは親ボリュームからこれらの設定を継承しないことに注意してください。

\CIFSServer\DataVolume\Qtree1\MySubFolder にマウントしたFlexVolのサイズを制限することで、一種のことができます。FlexVolはクォータです。
\DataVolume = メインの FlexVol/FlexGroup (Qtreeが含まれる)
\Qtree = ツリー クォータが含まれる
Qtree\MySubFolder = このパスにマウントした1TB FlexVolなので、 FlexVolは本質的にクォータです。ユーザーは1TB(ストレージ効率によってはもう少し多くのことも可能)を超える量を書き込むことはできません。スナップショットリザーブに対応する最適なFlexVolサイズを割り出すには、少し計算する必要があります。最初のQtreeの下に別のQtreeを作成することはできないので、ボリュームにマウントするのが私のやり方です。

数百または数千のflexvolを管理することと何ら変わりはありません。また、パフォーマンス、データ保護、さらにはファブリックプールに対してさまざまなポリシーを使用できるという利点もあります。

フォルダーアイコンにはショートカットのような矢印がありますが、これは再解析ポイントまたはジャンクションを示し、クライアントが容量やサイズなどの独自の属性を持つ別のファイルシステムであることを理解できるようにするためです。

要するに、すべてのフォルダをFlexVolで作成し、その個々のFlexVolフォルダをジャンクションパスを使って名前空間で結合し、フォルダ階層のように見せるという手法があるようです。FlexVol一つ一つのクォータサイズがそのままフォルダ容量でありクォーター制限が適用されるので、顧客の要望を実現できそうです！

一応使用実績もあるらしい。

私の顧客には、単一のFlexGroup内に10PiB近くのデータがあり、その単一クラスター上に合計20PiBを超えるデータがあります。qtreeを作成するだけで、スナップショットやスナップミラーについて心配する必要はありません。すでに処理されています。
しかし、さまざまなパフォーマンス要件や、異なるものを必要とするデータセットの階層化と保護ポリシーをどのように管理すればよいでしょうか? ユーザーに対して同じ名前空間を維持する必要があるでしょうか? FlexGroupsやQtreesのような機能ではこれを達成することはできません。それは、そのように設計されているものではありません。
すべての顧客が同じであるわけではなく、またその要件も同じではありません。あらゆる要件に合わせて機能させることができます。

私はこれを巨大なグリッドコンピューティング環境で行いました。トップレベルの1g flexvolを多数作成しました(例として開発製品テスト) 。次に、それぞれの下に作業中の項目を表す15個のflexvolの別セットを配置しました。その下には年が記載されたflexvolがありました。そのフレックスグループにはqtreeがありました。毎年の場合、最後に、その年のボリュームは読み取り専用として /mounted としてマークされ、それ以上のデータを排除するためにサイズが縮小されます。20億のファイルを含む4ノードのクラスター(2014年)を持っていました。

これは、単一のFlexGroup内に10PiBを備えた私の研究顧客に似ています(それはFlexgroup自体内の単なるデータです) 。FlexGroupのルート下には、全国の各研究プロジェクトのqtreeがあり、すべての作業データがこれに入力されます(これは、研究者が分類、分析して何を処理するかを決定する前にONTAPにダンプするだけの膨大なデータ ポイントです)。各qtree下には、さまざまな目的で にマウントされた多数のflexvolがあります。プロジェクトが終了し、研究グループによってデータが整理されると、前述のように、さまざまなflexvolが読み取り専用に変更されるか、ボリュームがよりパフォーマンスの低いストレージ層に移動されるか、またはFabricPoolで階層化されます。
すべてのデータは共通の構造下で編成され、アクセスされ、管理されますが、ボリュームはさまざまな場所からマウントされます。大規模な場合、データの膨大なサイズとファイル数を管理し、異なる保護、セキュリティ、および配置要件を持つデータセットを個別にターゲットにできる柔軟性を維持できる、当社と顧客にとって最良の方法であることがわかりました。

注意事項

  • フォルダ構造やフォルダ自体のメンテナス（設定、変更、削除、移動等）が若干手間かも

例えば、フォルダ名の変更はこのようにWindows上からはできず、FSxコンソールから変更する必要があります。

概要図

作業の流れ

検証手順

　　　B（20MB）
　　┏ーー┻ーー┓
C(100MB) 　D(200MB)
若干歪ですがこのようなフォルダ構成を作り、それぞれ既定のサイズ以上保存できないことを確認する。
やり方は、FlexVolをそれぞれのサイズで作り、ジャンクションパスでフォルダパスを指定する。

1．FlexVolの作成[ボリュームの作成]

2．ファイルシステムを以下のように設定

3．ボリュームの詳細を以下のように設定


元々のデフォルトボリュームをAという名前で作成してしまったため、ジャンクションパスは「/A/B」になっています。

4．残りのフォルダも同様に設定

5．フォルダが作成されていることを確認
この状態でマウントして見るとまずBフォルダが見える。

C:\Users\Administrator>net use Z: \\10.0.21.81\cifs-share
\\10.0.21.81\cifs-share のパスワードが無効です。

'10.0.21.81' のユーザー名を入力してください: Admin@nozaki.com
10.0.21.81 のパスワードを入力してください:
コマンドは正常に終了しました。

Bフォルダを潜るとちゃんとC,Dフォルダが作成されている。


若干気になるとしたら、ご覧のようにフォルダアイコンにショートカットのような矢印マークが付いてしまうことでしょうか。

6．クォータ制限の確認
10MBほどのテストファイルを用意し、B,C,Dそれぞれのフォルダにどこまで置けるかテストしてみたところ、それぞれちゃんと既定の20MB、100MB、200MB以上置けないようになっていたので、設定したクォーターサイズが効いていることが確認できました。

ちなみにフォルダ階層構造として
・第1階層「共有フォルダ」
・第2階層「Personal」
・第3階層：クォータ適用対象
っとなっているとして、容量制限を行いたい第3階層より上の階層全てをFlexVolで作成しなければならないかどうかというと、手動で作成することもできることを確認。
試しに第1階層で「Personal」を手動で作成し、その下にFlexVolでEを作成できました！

ここで新たな課題検討

クォータとしてのFlexVolの容量が動的に変更可能でないと厳しいだろうなと思ったので、変更できるか検証して見ることに。試しにDを200MB⇨50MBに変更してみる。

検証手順

1．ボリュームを選択した状態で[アクション] > [ボリュームを更新]

2．50MBに変更

ところが、当然と言えば当然だが以下の変更後のボリュームサイズが小さすぎるというエラーが


実際に収容できるサイズになるよう現状のファイルを削除しないとエラーになるということで、これはむしろ正しい。

3．そこでエクスプローラ上で50MB以下になるように実際のファイルを削除してみる。


ところがこれでも変わらずエラーが出続ける。

CLIでやっても同様。むしろこっちの方が適正サイズまで指摘してくれていて親切

FsxId0f542a58430378e5d::> volume show -volume D -fields size
vserver    volume size
---------- ------ -----
nozaki_SVM D      200MB

FsxId0f542a58430378e5d::> volume modify -volume D -size 50MB

Error: command failed: Unable to set volume attribute "size" for volume "D" on
       Vserver "nozaki_SVM". Reason: Selected volume size is too small to hold
       the current volume data. New volume size must be at least 188MB to hold
       the current volume data.

4．スナップショットの削除
そこで、以下を参考にスナップショットも削除して見ることに
System Manager - ONTAP 9.7 以前を使用して Snapshot コピーを削除します

ディスクスペースを節約したり解放したりする場合、 ONTAP System Manager クラシック（ ONTAP 9.7 以前で使用可能）を使用して Snapshot コピーを削除できます。

FsxId0f542a58430378e5d::> snap delete -vserver nozaki_SVM -volume D -snapshot *

Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure
         you want to delete Snapshot copy "hourly.2024-03-16_1105" for volume "D" in Vserver "nozaki_SVM" ?
          {y|n}: y

Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure
         you want to delete Snapshot copy "hourly.2024-03-16_1205" for volume "D" in Vserver "nozaki_SVM" ?
          {y|n}: y

Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure
         you want to delete Snapshot copy "hourly.2024-03-16_1305" for volume "D" in Vserver "nozaki_SVM" ?
          {y|n}: y

Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure
         you want to delete Snapshot copy "hourly.2024-03-16_1405" for volume "D" in Vserver "nozaki_SVM" ?
          {y|n}: y
4 entries were acted on.

FsxId0f542a58430378e5d::> df -h D
Filesystem               total       used      avail capacity  Mounted on                 Vserver
/vol/D/                  185MB       39MB      145MB      13%  /A/B/D                     nozaki_SVM
/vol/D/.snapshot          15MB         0B       15MB       0%  /A/B/D/.snapshot           nozaki_SVM
2 entries were displayed.

FsxId0f542a58430378e5d::> volume show -volume D -fields size
vserver    volume size
---------- ------ ----
nozaki_SVM D      50MB

スナップショットを削除するコマンドも必要で若干クセがありましたが、50MBに変更できました。
ただし、マネジメントコンソールからクオーターサイズが50MBになっているのを確認するのにタイムラグがあるようで、この表示がされるまで時間かかりました。

この辺りドメイン参加と同様、GUIから操作してもそれが反映されず、CLIで操作してようやく実現されるという仕様があるっぽいのでFSx ONTAPは要注意

懸念事項

  • スナップショットとAWS backupがボリューム単位で設定が必要で300ぐらいのボリュームを個別で設定して、管理しなければならない。300ぐらいのボリュームを同じ時間帯にバックアップ取るのってサーバー負荷大丈夫？

スナップショットに関しては、ONTAPスナップショットはミリ秒単位で作成され、多くの場合それより高速です。
300のボリュームが同時にヒットしないように、スナップショットを数分間にずらした方がいいでしょう。
1つのHAペアに500以上のボリュームがある環境を構築したことがあるが、問題なくすべて同時にスナップショットされました。

  • 管理オーバーヘッドはある？

管理オーバーヘッドは、1つのFlexグループに対して1つのボリュームとして扱われることです。つまり、スナップショットポリシーは1つです。レプリケートする場合は、1つのsnapmirror関係になります。どのアグリゲートまたはボリュームでデータをホストするかを決定する必要はなく、Flexgroupを構成する基本的なコンポーネントがその決定を行います（Flexgroupを作成または拡張するときにのみ決定する必要があります）。新しいデータセットがあれば、qtreeを作成し、CIFSであれば新しい共有を作成し、デフォルトのファイルレベルパーミッションを設定すれば完了です。
すべてのデータセットがそれ自身のFlexvolである場合、（どのアグリゲート、どのノード、どのLIF経由で接続するのが最適か、どのsnap-reserveを使用するかなど）いくつか決定しなければならないことが増えます。使用するスナップショットポリシー、マウントパス、エクスポー トポリシー、新しいsnapmirror関係の作成、使用するポリシーなどです。データセットごとに異なるポリシ ーを設定できる柔軟性は、大きなメリットになる場合があります。

所要時間

2時間

S3 File Gatewayでのファイル閲覧をADでアクセス制御できるか

技術検証

目的・やりたいこと

要件
1. AD参加のユーザーを Storage Gateway（SGW）にアクセスさせる
2. SGWに用意したフォルダごとにWindowsの共有設定を用いて、閲覧権限を設定したい（AD参加ユーザーが見れる/見れないフォルダを制御）
3. AD参加ユーザーのクライアントからは、Windows エクスプローラーのネットワーク欄からSGWのディレクトリが見れるようにしたい（NASのような使い方）

・オンプレクライアントPCからDRサーバを経由してSGWのフォルダ/ファイルにアクセスしたい
・その際にADの情報を使って閲覧/書き込みの権限制御をしたい
→AD参加はできている
→権限の制御がうまくいっていない
→ファイルリスト自体は見れるが、ファイルのプロパティを見ても権限不足と表示されて何も権限が見れない
→SGW側の問題もあるかもしれない
→別途SGWを使う話も顧客から相談が来ている

対象となる技術

条件（導入にあたっての前提事項）

  • File Gateway on EC2を利用
  • ファイル共有プロトコルはSMBを利用
  • 通信要件についてはクリア
  • File Gateway構築手順は省略

参考URL

注意事項

https://docs.aws.amazon.com/ja_jp/filegateway/latest/files3/smb-acl.html#acl-limits

  • Windows ACLは、Windows SMBクライアントを使用してファイル共有にアクセスするときに、ADが有効化されているファイル共有のみでサポート
  • ファイルゲートウェイは、任意アクセスコントロールリスト(DACL)エントリである AllowエントリおよびDenyエントリをサポート
  • SMBファイル共有のルートACL設定はゲートウェイのみであり、この設定はゲートウェイの更新と再起動後にも維持される

概要図

作業の流れ

手順概要

  1. S3ファイルゲートウェイをADドメイン参加
  2. ファイル共有の作成
  3. ADユーザーでマウント確認
  4. testフォルダをAdminだけが見れるように設定
  5. testユーザーでtestフォルダが表示されないことを確認

検証手順

1．ゲートウェイのアクション > SMB設定の編集 > Active Directory設定

2．以下のように設定

3．と、ここで結合失敗 (ネットワークエラー)が

4．それもそのはず。S3 FileGatewayのDNS設定を変更していなかった。
そこで、S3 FileGatewayのEC2インスタンスにSSHログイン

% ssh admin@18.183.82.242 -i nozaki.pem

5．まずは現在のDNS設定を確認

#

    AWS Storage Gateway - Configuration

    #######################################################################
    ##  Currently connected network adapters:
    ##
    ##  eth0: 10.0.7.150    
    #######################################################################

    1: HTTP/SOCKS Proxy Configuration
    2: Network Configuration
    3: Test Network Connectivity
    4: Test S3 Connectivity
    5: View System Resource Check (0 Errors)
    6: License Information
    7: Command Prompt

    Press "x" to exit session

        Enter command: 2

    AWS Storage Gateway - Network Configuration

    1: Edit DNS Configuration
    2: View DNS Configuration
    3: Configure Hostname
    4: View Hostname Configuration

    Press "x" to exit

    Enter command: 2

    DNS Configuration


    Available adapters: eth0
    Enter network adapter: eth0

    Source: Assigned by DHCP
    DNS: 10.0.0.2
    Domain search list: ap-northeast-1.compute.internal

10.0.0.2とものの見事にデフォルトになっていた。

6．そこで下のADのIPに書き換える。

    AWS Storage Gateway - Network Configuration

    1: Edit DNS Configuration
    2: View DNS Configuration
    3: Configure Hostname
    4: View Hostname Configuration

    Press "x" to exit

    Enter command: 1

    DNS Configuration:


    Available adapters: eth0
    Enter network adapter: eth0

    Assign by DHCP [y/N]: N

    Enter primary DNS [10.0.0.2]: 10.0.10.237
    Enter secondary DNS [10.0.0.2]: 10.0.35.136

    Apply config [y/N]: y

 AWS Storage Gateway - Network Configuration

    1: Edit DNS Configuration
    2: View DNS Configuration
    3: Configure Hostname
    4: View Hostname Configuration

    Press "x" to complete your network configuration and exit

    Enter command: x

    Restarting networking...

    Restarting network (via systemctl):                [  OK  ]

    You must restart your gateway to complete the network configuration.

    Restart gateway now [y/N]: y
    Restarting...SUCCESS
    Press return to continue

7．気を取り直して再度AD参加に挑戦。今度は成功

8．ファイル共有の設定もADでユーザー認証する

Windows アクセスコントロールリストが選択されていることも確認

9．Windows踏み台にログイン後、ADユーザーでマウントできることを確認

'10.0.7.150' のユーザー名を入力してください: Admin@nozaki.com
10.0.7.150 のパスワードを入力してください:
コマンドは正常に終了しました。)

10．まずはtestフォルダをAdminだけが見れるようにする。そのためにデフォルトで設定されているEveryoneを削除するため、継承を無効化する


これでAdminだけが見れる状態に

11．一度セッションを切断して、今度はnozakiユーザーでマウント

>Net Use * /delete
これらのリモート接続が存在します:

    D:              \\10.0.36.58\cifs-share
    E:              \\10.0.7.150\nozaki-codedeploybucket
    S:              \\aaa.nozaki.com\share
    X:              \\10.0.7.150\nozaki-codedeploybucket
    Z:              \\10.0.13.3\cifs-share
                    \\TSCLIENT\Desktop
続行すると、接続は取り消されます。

この操作を続行しますか? (Y/N) [N]: Y
X: との接続にオープン ファイルや未実行のディレクトリ検索があります。

切断を続行し、強制的に閉じますか? (Y/N) [N]: Y
コマンドは正常に終了しました。

>net use X: \\10.0.7.150\nozaki-codedeploybucket
'10.0.7.150' のユーザー名を入力してください: nozaki@nozaki.com
10.0.7.150 のパスワードを入力してください:
コマンドは正常に終了しました。

12．検証の結果、フォルダにアクセスできないようにはできるが、フォルダ自体は表示されてしまうことがわかりました。
このフォルダ自体すらも見えなくする方法がないかを模索。

果たしてそんなの方法あるのだろうかと思って見つけたこのサイトが詳しい。
Windows Server上のアクセス権がない共有フォルダーを見えなくする方法
なんでもABE(Access-based Enumeration) ＝ アクセス ベースの列挙を有効にすればよいらしい。

（参考）アクセス権のない共有フォルダをユーザーから隠したい

・セキュリティ上考慮が必要なフォルダやファイルがあることさえ，ユーザーに知られなくなるため，ファイルサーバーとしてのセキュリティレベルが向上する
・アクセス権の無いフォルダやファイルを隠すことで表示が整理される。ユーザーは、多数のフォルダやファイルが存在するディレクトリ内にあっても、容易に自分が必要なフォルダ（ファイル）を見つけられます。

でもS3 file Gatewayって阿部さんに対応してたっけ？と思ったら、Q&Aでは対応しているとのこと

Q: Simple Storage Service (Amazon S3) ファイルゲートウェイは、SMB ファイル共有のアクセスベースの列挙をサポートしていますか?

はい。SMB ファイル共有のアクセスベースの列挙を構成して、アクセス許可上、開くことができないフォルダやファイルがユーザーに表示されないようにすることができます。また、Simple Storage Service (Amazon S3) ファイルゲートウェイ上のファイル共有をユーザーが閲覧できるかどうかを制御することもできます。

13．で、よく見たらファイル共有設定の編集のファイルアクセス設定で「ファイルとディレクトリのアクセス権ベースの列挙」というのがあるではないか！ということでこれを有効に

14．改めて踏み台で12.に戻り、フォルダ表示を更新。するとtestフォルダが見えなくなっているので、検証成功！

所要時間

1時間

ユースケース

S3のファイルのアクセス制御をWindows ACLで行いたい場合

Storage Gatewayを必要な時だけ起動させて利用料を削減する検証

技術検証

サービス概要

Storage Gatewayとは、オンプレミスやEC2をAWSストレージと接続するサービスです。Storage Gatewayの実態は、Storage Gateway用にAWSが準備したAMIイメージをもつEC2インスタンスで、マウント元のEC2インスタンスとS3とを標準マウントプロトコルで仲介します。
今回はマウントプロトコルとしてSMBを使用します。
Windowsクライアント：SMB ファイルシステムのバージョン 2 および 3 のプロトコル

目的・やりたいこと

お客様からStorage Gatewayの利用料を削減したいという要望が来ており、調査・検証を行う。
検証目的：Storage Gatewayの利用料の削減案の検討
Storage Gatewayを利用しない時間だけ停止させて、必要な時だけ起動させて利用料を削減できないか
→停止・起動の手順
→停止起動後の再マウントの要否
→削減額の試算

対象となる技術

概要図

作業の流れ

事前作業

1．以下の構成でS3ファイルゲートウェイを作成。ホストプラットフォームはEC2

2．ゲートウェイはパブリックに置く。

3．ファイル共有の作成。今回は踏み台がWindowsサーバーなのでプロトコルはSMBを選択

4．この状態で踏み台Winowsからマウントできるか確認

C:\Users\Administrator\Desktop>net use E: \\10.0.7.150\nozaki-codedeploybucket /user:sgw-55F5333C\smbguest
'10.0.7.150' に接続するための 'sgw-55F5333C\smbguest' のパスワードを入力してください:
コマンドは正常に終了しました。

S3のファイルが見れることを確認

検証手順

1．ここで該当EC2を停止。やがてFile Gatewayもオフラインに

2．するとファイル共有も使用不可能に

C:\Users\Administrator\Desktop>net use F: \\10.0.7.150\nozaki-codedeploybucket /user:sgw-55F5333C\smbguest
システム エラー 53 が発生しました。

ネットワーク パスが見つかりません。

3．再び該当EC2を起動。やがてFile Gatewayも実行中に

4．するとWindowsの方でも、再マウントすることなくそのままファイル共有が自動的に使用可能になることを確認できた。

5．ファイルも置けることを確認

削減効果

  • Storage GatewayのEC2（m5.xlarge、230GB）を1ヶ月フルに使用した場合

1 instances x 0.248 USD On Demand hourly cost x 730 hours in a month = 181USD
730 total EC2 hours / 730 hours in a month = 1.00 instance months
230 GB x 1.00 instance months x 0.096 USD = 22.08 USD (EBS Storage Cost)
合計203.12 USD

  • 半分だけ起動させた場合

1 instances x 0.248 USD On Demand hourly cost x 365 hours in a month = 90USD
365 total EC2 hours / 730 hours in a month = 0.50 instance months
230 GB x 0.50 instance months x 0.096 USD = 11.04 USD (EBS Storage Cost)
合計101.56 USD

つまり、起動時間を半減すればコストも半額になる計算。101.56USD＝14,636円浮く計算になる。
https://calculator.aws/#/estimate?id=836b62bea98513d384756a5ae7203f3dc7abab4b

まとめ

  • Storage Gatewayを停止するには、単純に実体のEC2を停止すればよい
  • Storage Gatewayを停止⇨起動させると、マウントは自動マウントされる
  • 削減額の試算は、EC2（m5.xlarge、230GB）の稼働時間を半減させた場合、101.56USD＝14,636円浮く

Glueでパーティションキーを設定してパーティション化する

技術検証

目的・やりたいこと

前回、[技術検証]S3に保存された監査ログをGlueで可読性を上げてAtenaで抽出する検証では、ネスト化されたログをフラット化するところまでやりました。
しかし前回のS3のログ配置では、Hive形式になっておらず、パーティションが使えないという課題がありました。

 

そこで今回の検証では、Glueジョブでパーティションキーを設定してパーティション化し、Hive形式でS3に保存されるまでを扱います。

対象者

ログをS3に保存し、それをAtenaでパーティションキーを指定して情報を抽出したい中級レベルのデータ分析技術者

対象となる技術

  • Glue
  • Athena

条件（導入にあたっての前提事項）

  • 前回までの検証の環境が構築できていること

注意

今回のパーティションの設定方法は完全に我流のやり方なので、もしかしたら本来の方法より非効率かもしれません。もっといい方法あるよという方いましたら教えてください。

参考URL

概要図

作業の流れ

設定手順

まずはGlueジョブを使ってtimeフィールド「2024-01-16 01:30:11.0」から情報をそれぞれ年、月、日の単位で抽出し、それをパーティションキーに設定するフローを作ります。

1．Visual ETLをクリック

2．SourceにS3、TransformにまずTo Timestamp関数を選択し、timeをiso形式に変換

3．今度はFormat Timestamp関数を使って、yyyyというフォーマットでyearという列を作成

4．同様にFormat Timestamp関数を使って、MMというフォーマットでmonthという列を作成

5．同様にFormat Timestamp関数を使って、ddというフォーマットでdayという列を作成

6．最後にカタログテーブルでパーティション（年、月、日）を設定

これをスクリプト化したのが次の内容です。

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import gs_format_timestamp
import gs_to_timestamp

args = getResolvedOptions(sys.argv, ["JOB_NAME"])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args["JOB_NAME"], args)

# Script generated for node Amazon S3
AmazonS3_node1705548592182 = glueContext.create_dynamic_frame.from_options(
    format_options={"multiline": False},
    connection_type="s3",
    format="json",
    connection_options={
        "paths": ["s3://csi-se007-infra-system-logs/glue_log/run_part_r_00000/"],
        "recurse": True,
    },
    transformation_ctx="AmazonS3_node1705548592182",
)

# Script generated for node To Timestamp
ToTimestamp_node1704956271806 = AmazonS3_node1705548592182.gs_to_timestamp(
    colName="time", colType="iso"
)

# Script generated for node Format Timestamp
FormatTimestamp_node1704956383134 = ToTimestamp_node1704956271806.gs_format_timestamp(
    colName="time", dateFormat="yyyy", newColName="year"
)

# Script generated for node Format Timestamp
FormatTimestamp_node1704958713540 = (
    FormatTimestamp_node1704956383134.gs_format_timestamp(
        colName="time", dateFormat="MM", newColName="month"
    )
)

# Script generated for node Format Timestamp
FormatTimestamp_node1705024506944 = (
    FormatTimestamp_node1704958713540.gs_format_timestamp(
        colName="time", dateFormat="dd", newColName="day"
    )
)

additionalOptions = {"enableUpdateCatalog": True}
additionalOptions["partitionKeys"] = ["year", "month", "day"]

# Script generated for node AWS Glue Data Catalog
AWSGlueDataCatalog_node1705548604536 = glueContext.write_dynamic_frame.from_catalog(
    frame=FormatTimestamp_node1705024506944,
    database="se007-app-db",
    table_name="se007-app-table",
    transformation_ctx="AWSGlueDataCatalog_node1705548604536",
    additional_options=additionalOptions,
)

job.commit()

ここでポイントとなるのが次の2行

additionalOptions = {"enableUpdateCatalog": True}
additionalOptions["partitionKeys"] = ["year", "month", "day"]

これはここの方式1の内容をそのまま記載
次に

sink = glueContext.write_dynamic_frame_from_catalog(frame=last_transform, database=<target_db_name>,
                                                    table_name=<target_table_name>, transformation_ctx="write_sink",
                                                    additional_options=additionalOptions)

の部分は、「additional_options=additionalOptions」だけを最後のデータカタログ作成コードの中に組み入れればOK

検証

1．まずこの状態でGlueジョブを実行

2．該当のカタログテーブルのスキーマにパーティションキー、パーティションが設定されていることを確認

3．S3にHive形式で出力されていることを確認

4．最後にAtenaでパーティションキーを指定して検索できることを確認

所要時間

1時間

S3に保存された監査ログをGlueで可読性を上げてAtenaで抽出する検証

技術検証

サービス概要

Glueとは、ETL（抽出、変換、ロード）プロセスの検出、準備、統合、近代化を容易にするサーバーレスデータ統合サービスです。ちなみにglueは「接着剤」という意味の英単語
Atenaとは、S3に格納されているデータを、SQLを使用して直接分析でき、簡単に操作できるサービスです。

目的・やりたいこと

前回、[技術検証]OktaのシステムログをS3に掃き出す検証では、Oktaのシステム監査ログを、EventBrideとKinesis FIrehoseと連携してS3に掃き出すところまでやりました。
しかし前回のS3のログをそのままAtenaで抽出すると、このようにdetailフィールドがstruct構造でネスト化されたまま出力され、可読性に欠けるという課題がありました。

今回の検証では、S3に保存されているネスト化されたログをフラット化してデータカタログに保存し、Atenaからクエリして出力するまでを扱います。

対象者

Oktaのシステムログを監査目的でS3に保存し、それをAtenaで条件を変えて情報を抽出したい中級レベルのデータ分析技術者

今回新たに対象となる技術

  • Glue
  • Athena

条件（導入にあたっての前提事項）

  • 前回までの検証の環境が構築できていること

     

  • 必要なロール

・csi-se007-infra-glue-role

・csi-se007-infra-glue-s3read-policy

{
    "Statement": [
        {
            "Action": "s3:*",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::aws-glue-*/scripts/*",
                "arn:aws:s3:::aws-glue-*/temporary/*",
                "arn:aws:s3:::aws-glue-studio-transforms-*/*",
                "arn:aws:s3:::csi-se007-infra-system-logs/*"
            ],
            "Sid": "ReadS3Policy"
        }
    ],
    "Version": "2012-10-17"
}

参考URL

概要図

作業の流れ

手順

まずはGlueを使ってネストされた Struct のフィールドをフラット化し、最上位のフィールドにします。それにはGlue jobを作成する必要があります。

1．Visual ETLをクリック

2．SourceにS3、TransformにFlatten、TargetにData Catalogを選択

3．さらに、極力重複したレコードを排除するため、Flattenの後にTransformsのDrop Duplicatesという関数も挟みます。

さらに、配列（Array）化したレコードをフラットにするため、Transformsの最後にArray To Columnsという関数も挟みます。
例えば、detail.targetというフィールドは標準ではこのように配列化されています。

これを次のようにdetail.target1,detail.target2,detail.target3と3つのレコードに分けます。

さらに重複削除を最初に実行するように配置転換し、最終的には以下のフローにしました。

4．SoruceのS3 URL、Data format、IAM Roleをこのように選択

5．Transformは特にいじらずそのままでOK

6．TargetのDatabase、Tableをこのように選択

7．（Terraform化する場合）このようにScriptが出来上がっているため、この内容をコピーしてどこかローカルのテキストファイルに貼り付ける

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import gs_flatten
from awsglue.dynamicframe import DynamicFrame
import gs_array_to_cols
from pyspark.sql import functions as SqlFuncs

args = getResolvedOptions(sys.argv, ["JOB_NAME"])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args["JOB_NAME"], args)

# Script generated for node Amazon S3
AmazonS3_node1701850192247 = glueContext.create_dynamic_frame.from_options(
    format_options={"multiline": False},
    connection_type="s3",
    format="json",
    connection_options={
        "paths": ["s3://csi-se007-infra-system-logs/amazonloginlog/"],
        "recurse": True,
    },
    transformation_ctx="AmazonS3_node1701850192247",
)

# Script generated for node Drop Duplicates
DropDuplicates_node1701851055624 = DynamicFrame.fromDF(
    AmazonS3_node1701850192247.toDF().dropDuplicates(),
    glueContext,
    "DropDuplicates_node1701851055624",
)

# Script generated for node Flatten
Flatten_node1701851065629 = DropDuplicates_node1701851055624.gs_flatten(maxLevels=0)

# Script generated for node Array To Columns
ArrayToColumns_node1701851069244 = Flatten_node1701851065629.gs_array_to_cols(
    colName="`detail.target`", colList="detail.target1,detail.target2,detail.target3"
)

# Script generated for node AWS Glue Data Catalog
AWSGlueDataCatalog_node1701851073854 = glueContext.write_dynamic_frame.from_catalog(
    frame=ArrayToColumns_node1701851069244,
    database="nozaki-systemlogcrawler-db",
    table_name="run_part_r_00000",
    transformation_ctx="AWSGlueDataCatalog_node1701851073854",
)

job.commit()

8．[Job details]で、Job bookmarkを「Enable」に変更し、それ以外はデフォルトのままSaveしてJobを保存


ここでジョブブックマークとは、古いデータを再処理しないために最後の処理を覚えさせておく機能です。
ジョブのブックマークを使用した処理済みデータの追跡

ここでブックマークが本当に効いているか有効性を検証

  • ブックマークを有効にしている場合

1．Atenaで検索すると、38件抽出

2．Okta経由でAmazonにログインし、システムログを1件増やす。

3．Glue jobを実行

4．Atenaで再度検索すると、1件だけ増えて39件抽出

  • ブックマークを無効にした場合

5．今度はブックマークを無効にして、Glue jobを再実行

6．Atenaで再度抽出


58件なので、20件増えている。
内訳を見ると、


完全に同じものを見に行ってるのが20件ある。

以上により、ブックマークの有効性が検証されました。

テーブルのロケーションがシステムログと同じフォルダ内にあるためか、Glueがどうしても重複してS3からシステムログを取りに行くため、テーブルのロケーションを別フォルダに移動することにした。
ALTER TABLE SET LOCATIONを参考にし、以下のALTER TABLE文を実行

ALTER TABLE run_awsgluedatacatalog_node1701299803092_11_part_r_00000 SET LOCATION 's3://csi-se007-infra-system-logs/'

これで確かにLocationがs3://csi-se007-infra-system-logs/glue_log/に変わったが、以降Atenaのクエリでエラーが


どうやらS3バケットアクセスが403Deniedになってるらしい。
それと同時にGlue jobも失敗するようになった。

これらは単純にLocationを変更したらその場所に該当フォルダ「run-AWSGlueDataCatalog_node1701299803092-11-part-r-00000/」がないだけだったので、手動で作ったら直った。そらそうだ
ちなみにS3のブロックパブリックアクセスをオンにしててもアクセスできたので、公開にしなくてもいいらしい。
今度こそ正しいLocationに変更

9．7.で保存したファイル名をn.pyとし、このS3の指定の場所にアップロード

10．Atenaでクエリ

select *
from run_part_r_00000

detail.〜がこのようにフラットに格納されている。

detail.targetはこのように複数のフィールドに分割

所要時間

3時間

OktaのシステムログをS3に掃き出す検証

技術検証

サービス概要

Oktaとは、IDやパスワードの管理、認証を行うIDaaSサービスです。

目的・やりたいこと

Oktaのシステム監査ログを、AWSと連携してS3に掃き出す。

対象者

OktaのシステムログをS3に保管したい運用管理者

対象となる技術

  • Okta
  • EventBridge
  • Kinesis Data Firehose
  • S3

条件（導入にあたっての前提事項）

  • EventBridgeルールがターゲットにアクセスするときのロール「csi-se007-infra-kinesis-firehose-role」には、Firehoseへのフルアクセスポリシーと以下の信頼関係を付与
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "events.amazonaws.com",
                    "firehose.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
  • Kinesis Firehoseを作成するときのサービスアクセスのロールには、念のためS3のフルアクセスを付与

参考URL

  1. An Automated Approach to Convert Okta System Logs into Open Cybersecurity Schema Framework (OCSF) Schema
  2. AWS EventBridgeログストリームを追加する
  3. https://github.com/okta/okta-ocsf-syslog/
  4. Terraform で Kinesis Firehose のエラーを CloudWatch Logs に送る

注意事項

  • OktaのWorkforce Identity Cloudは、無料期間限定で使用できるフリートライアル版では、[ログストリーミング]のメニューが現れないため、必ず商用版を使用してください。

概要図


（https://www.okta.com/sites/default/files/styles/1640w_scaled/public/media/image/2023-05/Screenshot%202023-05-03%20at%203.32.39%20PM.png?itok=DiNjPyO0 より）

上記の構成図が理想ですが、検証では簡略化のため、Lambda、Glue、Security Lakeの三つを省いて以下の構成にしています。
Okta⇨Event Bus⇨EventBridge⇨Kinesis Firehose⇨S3

作業の流れ

事前作業

事前作業では、大きくOktaでの事前登録、AWS側での設定の二つに分かれます。

Oktaでの事前登録

1．[レポート] > [ログストリーミング]から[ログストリームを追加]

2．AWS EventBridgeを選択して[次へ]

3．例えば次のように入力して[保存]


これで該当のAWSアカウント側とOktaが連携する準備が整いました。

AWS側での設定

  • EventBridgeの設定

1．EventBridgeで[🔻統合] > [パートナーイベントソース]で表示されるため、選択して[イベントバスと関連づける]

2．[🔻バス] > [イベントバス]でカスタムイベントバスが表示されることを確認

3．[ルール]で2.のイベントバスを選択し、[ルールを作成]

4．適当に名前を入力し、[次へ]

5．[イベントソース]はその他、[イベントパターン]は今回OktaのRSAアプリだけを抽出するため、以下のターゲットIDとタイプを指定する

{
  "source": [{
    "prefix": "aws.partner/"
  }, {
    "anything-but": {
      "prefix": "aws."
    }
  }],
  "detail.target.id": ["0oaaxhrubefY4WRbP1d7"],
  "detail.target.type": ["AppInstance"]
}

6．ターゲットは次のように指定して[次へ]


この際設定するロールについては、前提条件参照

7．あとはデフォルトのまま[ルールの作成]

 

1．[Data Firehose] > [配信ストリームの作成]

2．送信先はS3

3．S3バケットは適当なものを設定、/systemlog配下に吐き出して、[配信ストリームを作成]


ちなみに詳細設定の[CloudWatch エラーのログ記録]はデフォルトのまま有効にしておきましょう。

検証手順

ここでは、OktaのRSAアプリを起動させてその際のログがS3に出力されることを確認します。

1．OktaのRSAアプリをクリック

2．すると以下のページが表示される

3．RSAに関するシステムログが残ることを確認

4．EventBridgeルールの[モニタリング]タブで、該当時間にInvocations、TriggeredRulesが無事記録されており、FailedInvocationsの出力がないことを確認

5．Kinesis Firehoseの[モニタリング]タブで、該当時間に「Amazon S3 への配信が成功しました」DeliveryToS3.Succsessが記録されていることを確認

6．S3の当該バケットに当該時間帯のログがあることを確認

7．念のためダウンロードして中身を確認
そのままだと見にくいので、json整形ツールで変換
以下のように無事target.id=0oaaxhrubefY4WRbP1d7の物だけを含んだログが表示されることを確認

〜略〜
        "target" : [
            {
                "id" : "0oaaxhrubefY4WRbP1d7",
                "type" : "AppInstance",
                "alternateId" : "RSA SAML Test Service Provider",
                "displayName" : "RSA SAML Test Service Provider",
                "detailEntry" : {
                    "signOnModeType" : "SAML_2_0",
                    "signOnModeEvaluationResult" : "AUTHENTICATED"
                }
            },
            {
                "id" : "rulanyibaeNdyPYQZ1d7",
                "type" : "Rule",
                "alternateId" : "unknown",
                "displayName" : "Rule for External_OktaAuth",
                "detailEntry" : null
            }
        ]
 〜略〜

所要時間

2時間

カスタマイズ

以下のEventBrideルールのイベントパターン条件で、Amazonアプリによるサインインまたはポリシー評価サインオンのログだけを発行することに成功

{
  "detail.eventType": ["user.authentication.sso", "policy.evaluate_sign_on"],
  "detail.target.id": ["0oab9aw8yaouf1TFr1d7"],
  "detail.target.type": ["AppInstance"],
  "source": [{
    "prefix": "aws.partner/"
  }, {
    "anything-but": {
      "prefix": "aws."
    }
  }]
}