【AWS】今年度学習したAWSサービスの特徴をまとめておく - AWS analytics services編

AWS

概要

インフラ系のクラウドエンジニアとして、日々自己研鑽に努めています。 本投稿は今年度の学習のまとめとして、今後も覚えておきたい情報を記載したものです。 AWS analytics servicesに含まれるサービスについて、要件に適したサービスや、調査・検証が必要な内容をすぐに探し出せるようになることを主な目的に、各サービスと関連技術の特徴と効果的に活用するためのTipsを記載しています。

記載内容は、AWS公式ドキュメントやインターネットから拾い集めた情報を個人的に解釈した結果を記載しています。実機確認等による裏付けがされた内容ではない点、ご留意ください。

Analytics

Athena

  • Prestoベースのクエリサービス。S3へのクエリ実行可能(Glacierはサポートしない)。
  • CSV,JSON,カラムナフォーマットであるParquet,ORCが利用可能

  • パフォーマンス向上のコツ

    1. パーティション分割：各クエリがスキャンするデータ量が制限され、パフォーマンス向上とコスト削減が期待できる。パーティション追加後は、カタログ内のメタデータ更新が必要（Hive互換の場合：MSCK REPAIR TABLEコマンド、Hive互換ではない場合：ALTER TABLE ADD PARTITIONコマンド）
    2. カラムナフォーマット(Parquet)を使用。コスト削減効果も。
    3. ファイルを圧縮する。(S3からのロードが早くなる) ※その他詳細はリンク先参照Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ

  • Workgroupsを使用することで、クエリ結果の分離(他のグループに参照させない)、格納先S3の分離、グループ毎に異なるコスト制約（クエリ毎にスキャン可能なデータ量、またはWG毎に一定期間の間スキャン可能なデータ量）を設けることが可能。Workgroupsのアクセス制限はIAMで行う。

  • Redshiftへのクエリ発行も可能。Athena(ペタバイト単位)とRedshift spectrum(エクサバイト単位)を比較する際、パフォーマンスを重視する場合はRedshift spectrumが優れている。(★Redshiftとの使い分けのポイント)
  • 失敗したクエリに対しては課金されない。
  • テーブル定義としてGlue データカタログを使用している。そのため、Glue分の料金が発生。

EMR

  • Hadoopエコシステムの集合体。分散処理・分析を行う。
    • Ambari:オーケストレーション
    • Presto：分散型SQL
    • Hue：GUI
    • Ganglia：モニタリング
    • Hive：分散処理。性能はHive>Pig。
    • Pig:分散処理。性能はHive>Pig。
    • Ranger:データに対するきめ細やかなアクセス制御
  • インスタンスフリート：ターゲット容量を指定する。EMRは事前設定されたターゲット容量を満たすようオンデマンドorスポットインスタンスをプロビジョニングする。Provisioning timeoutの設定では、指定時間以内にスポットインスタンスをプロビジョニングできない場合。クラスターを終了させるアクションまたはオンデマンドインスタンスで容量を補うというアクションを設定可能。スポットインスタンス終了等に伴うデータ破損を防ぎたい場合は、EMRFS(S3)にデータを格納する。
  • クラスタノードにSSHアクセス可能。
  • 二種類のオートスケーリングがある。
    • EMR managed scaling：主要なメトリクスをモニタリングするマネージドなアルゴリズムにオートスケール。
    • AutoScaling：カスタムメトリクスを使用し、利用者が設定。
  • EMR on EC2はマルチAZ非対応。EMR on EKSはマルチAZをサポート。
  • Spark DataFrame:PySparkのクラスで、高いパフォーマンスを実現可能なデータ構造
  • PrestoやSparkではS3 Select Pushdownを利用することで、EMRとS3間のデータ転送を削減し、パフォーマンスが向上する(効果の有無はクエリの特性に依存するため、使用有無は公式ドキュメントのガイドを参考にすること)。
  • Rangerを使用することにより、行レベルのアクセス制御が可能(★アクセス制御の単位は他のサービスとの使い分けのポイント)。
  • DataSyncにより、S3,EFS,FSx for Windows File ServerとHDFS間のデータ転送が可能。
  • 一定期間idle状態だった場合、自動終了するポリシーの設定が可能(以前はidleメトリクスを監視し、CloudWatchアラーム,SNS,Lambdaと連携するといった仕組みの構築が必要だった。)。
  • EMR notebookはGithub,Codecommit,GitBucketと統合している。
  • EMRクラスタを削除した場合、EBSも削除される。データ永続化にはS3を使うこと。
  • EMRマスターインスタンス、コアインスタンス、タスクインスタンスには異なるマネージドセキュリティグループが関連付けられている。
  • EMRのファイルシステム
  • EMRのインスタンスストアとEBSはLinux Unified Key Setup (LUKS)による暗号化が可能。ネイティブなEBS暗号化もサポート。
  • S3DistCp(OSSツール)：S3→HDFSに効率的(圧縮して)にデータをコピー。
  • EMRFSの暗号化

    Amazon S3 暗号化は、Amazon S3 との間で読み書きされた EMR ファイルシステム (EMRFS) オブジェクトで使用できます。Amazon S3 サーバー側での暗号化 (SSE) またはクライアント側の暗号化 (CSE) をデフォルトの暗号化モード保管時の暗号化を有効にする場合。オプションで、[Per bucket encryption overrides (バケットごとの暗号化オーバーライド)] を使用して、バケットごとに異なる暗号化方法を指定できます。Amazon S3 暗号化が有効であるかどうかにかかわらず、Transport Layer Security (TLS) は、EMR クラスターノードと Amazon S3 間で伝送中の EMRFS オブジェクトを暗号化します。 引用：暗号化オプション - Amazon EMR

Redshift

  • PostgreSQL互換(PSQL等も使用可能)。DWHにクエリ機能も付いているイメージ。
  • 3つのインスタンスタイプがある。
    • 高密度コンピューティング DC2
    • 高密度ストレージ DS2
    • Redshift マネージドストレージを備えた RA3
  • マルチAZ非対応。大規模障害対策にはクロスリージョンスナップショットを使う。
  • ディメンジョンテーブル：マスタデータ/ファクトテーブル：動的データ
  • データベース接続とユーザーアクティビティ情報を監査ログとして記録可能。保存先はS3。
  • KMSと統合されているが、KMSでキーを管理せず、AWS CloudHSM または on-premises HSMで直接キーを管理することも可能。
  • 複数セッションやユーザが同時にクエリを実行している際、相互に影響を受けないようワークロード管理(WLM)を使ってキューを分けることが可能。自動WLMと手動WLMとがあるが、自動WLMは一貫した高速のクエリパフォーマンスで、事実上無制限の同時ユーザーと同時クエリをサポートするとのこと。
  • クラスターのサイズ変更
    • Elastic resize：既存クラスターにノード追加またはノード変更。10～15分で完了。リサイズ中クラスターは読み取り専用。
    • Classic resize：新しいクラスタを作成し、元のクラスターからデータをコピー。データ量によって数時間から数日要する。リサイズ中クラスターは読み取り専用。
  • MATERIALIZED VIEWを使用することで、コスト削減(クエリ処理の削減)が可能なケースがある。VIEWのデータを更新するにはREFRESH MATERIALIZED VIEWを実行する(dead tuplesを削除するためにさらにVACUUMをしたほうが良い。)。
  • 1 つ以上の列をソートキーとして定義可能（複合ソートキーとインターリーブソートキー）。インターリーブソートキーは複合ソートキーに比べて大幅なパフォーマンス向上が見込める。ただし、ID 列,日付,タイムスタンプなど、一定間隔で増加する属性を持つ列でのインターリーブソートキーの使用は非推奨。
  • パフォーマンスのため、カーディナリティは低く保ったほうが良い。
  • Athena(ペタバイト単位)とRedshift spectrum(エクサバイト単位)を比較する際、パフォーマンスを重視する場合はRedshift spectrumが優れている。(★Redshiftとの使い分けのポイント)
  • Redshift spectrumはRedshiftテーブルにデータをロードすることなく、クラスターに依存しない専用のAmazon Redshiftサーバー上でクエリ実行するため、Redshiftクラスターにほとんど負荷がかからない。
  • S3→Lambda(トラック管理はDynamoDB)→RedshiftのData転送アーキテクチャが公開されている。
  • 以前はRSをVPCに配置してもS3などのサービスに対してはIGW経由での通信が必要だったが、拡張ルーティング機能によりVPCのルーティングテーブルに従ってルーティング可能になった。
  • DBlinkを使ってPosrgreSQLと統合可能(PostgreSQLからRSに対してSQL実行可能)。
  • データをロードするためのベストプラクティス(データをロードするための Amazon Redshift のベストプラクティス - Amazon Redshift) 例：単一の COPY コマンドを使用した複数のファイルからのロード

    Amazon Redshift は、複数の圧縮データファイルからの並列的なデータロードを、自動的に実行します。ただし、複数の COPY コマンドを同時に使用して複数のファイルから 1 つのテーブルにデータをロードする場合には、Amazon Redshift はそれらの読み込みを直列的に実行します。この種類のロードはかなり低速で、テーブルにソート列が定義されている場合は、最後に VACUUM プロセスが必要になります。引用：単一の COPY コマンドを使用した複数のファイルからのロード - Amazon Redshift

Kinesis Data Analytics

  • Apache Flinkベースのリアルタイム分析サービス。
  • KDSとKDFを流れるデータに対してSQLベースのクエリが発行可能。クエリ結果はKDSやLambdaに転送。
  • 処理できないレコードはエラーストリームに転送することで後から解析可能。
  • マシンラーニング(Random Cut Forest)による異常検知が可能。
  • 1KPU=4GBメモリ。8KPUが上限。
  • ウィンドウクエリ
    • Stagger Windows: データが届くと開く、キー付けされた時間ベースのウィンドウを使用してデータを集計するクエリ。キーによって、複数の重なり合うウィンドウが可能になります。タンブリングウィンドウと比較すると、Stagger Windows は遅延データまたは順序通りでないデータを削減するため、これは、時間ベースのウィンドウを使用してデータを集約する方法として推奨されます。
    • タンブリングウィンドウ: 定期的に開閉する、個別の時間ベースのウィンドウを使用してデータを集計するクエリ。
    • スライディングウィンドウ: 固定時間または rowcount 間隔を使用して、データを継続的に集計するクエリ。引用：ウィンドウクエリ - Amazon Kinesis Data Analytics for SQL Applications 開発者ガイド
  • ETL処理も可能。
    例: 複数のデータ型の変換 - Amazon Kinesis Data Analytics for SQL Applications 開発者ガイド

Elasticsearch Service（OpenSearch）

  • OSSのElasticsearchベースのサービス。(Close APIは使用不可)
  • 3つのAZを使用したマルチAZモードでの起動が推奨構成。以下はESのクラスタの構造。
    • マスターノード：3つ。1つのマスターと2つのスレーブ
    • データノード：3つ。各々のノード内部に複数のシャードを持つ。プライマリシャードは一つ。2つはレプリカシャード。
  • クラスタのことをドメインと呼ぶ。複数のドメイン横断のクエリを実行可能(これはOSS版のESにはできないAWS版ESだけの独自機能)。
  • ドメインの作成時にパブリックドメイン or VPCドメインを選ぶ。
    • パブリックドメイン：パブリックにアクセス可能。
    • VPCドメイン：プライベートサブネット内にENIを作成し、それを経由することで他のAWSサービスとプライベートな通信が可能。
  • 標準では各ノードのインスタンスストアまたはEBSにデータを格納するが、高いパフォーマンスが必要ないデータについてはUltraWarmストレージ(S3)を使用可能。
  • ドメインに含まれるインスタンスタイプやボリュームサイズ等の変更を行った場合、内部的にBlue/Greenデプロイが行われる。
  • Kinesis Data Firehose(KDF)の出力先に指定可能。
  • CloudWatchLogsからのデータ取り込みはLambda等を経由する必要がある。
  • Kibanaダッシュボードはリフレッシュレートの設定により、定は的(15分毎,7日毎等)に更新が可能(★Quicksightとの使い分けのポイントの一つ)。
  • Kibanaのログイン認証にCognitoを使用可能。
  • リソースベースIAMをサポート。それとは別にKibanaの権限管理機能も利用可(作成時に有効化する必要がある)。
  • 自動BackupはS3に格納される。自動バックアップからは新しいESドメインの作成は不可。バックアップから新しいESドメインを作成したい場合は手動Snapshotを使用する必要がある。

Quicksight(QS)

  • データの可視化サービス。様々なグラフが予め用意されている。データに対して適切なグラフが不明な場合、AutoGraph機能を使うと、QSが自動判定してくれる。(Excelのグラフ機能をリッチにしたイメージ)
  • データを更新した際、接続プロパティとデータの格納場所に応じて処理が異なる。QSがダイレクトクエリを使用してデータに接続する場合、ダッシュボードを開くたびに自動更新される。ダイレクトクエリの代わりに、SPICE(インメモリデータストア)にデータをインポートすることも可能。SPICEのデータは定期更新可能(毎時(Enterpriseのみ),日次,週次,月次)(★Kibanaとの使い分けのポイントの一つ)。
  • 主なデータソース：リレーショナルデータ(Athena,S3,Redshift,PostgreSQL,等)やファイル(CSV,TSV,ELF,CLF,JSON,Excel)やSaaS(ServiceNow等)など多様。※DynamoDBやGlueデータカタログは公式ドキュメント上データソースとして記載なし。
  • Standard EditionとEnterprise Editionがある。Enterpriseの特徴は以下の通り。
    • データセットの行レベルでのアクセス制御が可能(★アクセス制御の単位は他のサービスとの使い分けのポイント)。
    • 1時間毎のSPICEの定期更新が可能
  • プライベートサブネット内にENIを作成し、それを経由することで他のAWSサービスとプライベートな通信が可能。QS用セキュリティグループという特殊なSGを介して通信を制御する。
  • マシンラーニング(Random Cut Forest)による異常検知が可能。

Data movement

Glue

  • Apache SparkベースのETLサービス。
  • PythonとScalaに対応している。既存のコードをS3に格納し、呼び出すことも可能。
  • AWS GlueクローラとジョブはCron式(最短5分)で定期的なスケジュールで実行可能(複数ジョブ同時実行可)。これにより、カタログを最新の状態に保つことができる。
  • DynamoDBからデータのロードが可能(DynamoDBへのunloadは不可)。

  • S3から小さなファイルを大量に読み込む際、groupFilesの設定を有効にし(さらにまとめて読み込むサイズを指定し)、まとめて読み込むと効果的。ただし、入力ファイル数が50,000を超える場合には自動的に有効になる。また、以下の点に注意。

    groupFiles は、csv、Ion、grokLog、json、および xml のデータ形式から作成された DynamicFrames でサポートされています。このオプションは、avro、parquet、orc ではサポートされていません。 引用：大きなグループの入力ファイルの読み取り - AWS Glue

  • DynamicFrames:AWSによるPySparkの拡張の一つ。Spark DataFrameに似ており、高いパフォーマンスを実現可能なデータ構造

  • リソースベースポリシーをサポート。アクセス制御の単位はデータカタログのARN粒度に依存すると思われる。(★アクセス制御の単位は他のサービスとの使い分けのポイント)。
  • AWS Glue Schema Registryにより、スキーマ(データレコードの構造と形式)のバージョン管理が可能。現状JSONとApache Avro形式をサポート。Kinesis Data Streams(KPL,KCL)やMSKとも統合している。
  • DataBrew：コードを書くことなくデータのクリーニングや正規化が可能な視覚的なツール。クレジットカードの番号を下４桁にするといった機密情報を削除する処理も可能。

Managed Streaming for Apache Kafka (MSK)

  • Apache Kafka ACLでアクセス制限が可能。MSKにPush可能なProducerの制限等に利用可。
  • 容量管理やスケーリングの管理をしたくない場合、MSK Serverlessを使用可能。ただし、クォータの制限が多い点に注意。例：最大メッセージサイズ8MB(★メッセージサイズの上限は、SQSやKinesisとの使い分けのポイントの一つ)ServerlessではないMSKのメッセージサイズに関する記載はAWS公式ドキュメント上見当たらなかった。
  • ストレージのAuto Scalingが可能
  • コンポーネント

Kinesis Data Streams(KDS)

  • リアルタイムにデータを転送。プログラム間(KPL/Kinesis Agent→KCL,Lambda等)へデータ転送するイメージ。Sparkからの読み書きも可能。AutoScaling機能はない。(★KDFとの使い分けのポイント)
  • プロデューサ：Kinesis Producer Library,Kinesis Agent。Agentは1MB/sまたは1000回/s転送可、KPLはパフォーマンスが高い。KPLに圧縮機能はない。
  • コンシューマ：Kinesis Client Library(純正),Kinesis Connector Library(3rdParty製)
  • ポーリング間隔の推奨は各シャード毎に1秒に一回。
    Kinesis Client Libraryのデフォルトもそれに従っているが、idleTimeBetweenReadsInMillisでチューニング可能。
  • APIの上限とペイロード毎の制限は分けて考える。例：GetRecordsのAPIコールの上限は5TPSで、呼び出し毎に最大10,000レコードまたは最大10 MB返却可能。※上限を超えるAPIコールはスルーされる。
  • レコードサイズは最大1000KB(★メッセージサイズの上限は、SQSやMSKとの使い分けのポイントの一つ)。
  • 拡張ファンアウト：コンシューマが1シャードを占有し、最大で2MB/sの送信が可能。これにより、コンシューマに対して70ms以内の配信が可能となる。
  • サーバーサイド暗号化：KMSの"CMK"を使用して自動的にデータを暗号化。
  • Glueと統合されている。

Kinesis Data Firehose(KDF)

  • ニアリアルタイムにデータを転送(最短60s)。サービス間(S3,cloudwatch,Redshift,ES,splunk等)でデータ転送するイメージ。Sparkからの読み書きは不可。AutoScaling機能がある。(★KDSとの使い分けのポイント)
  • KDFにデータを追加する方法は、Kinesis AgentとAPIの二種類ある。さらに、APIにはPutRecord(1API毎に1レコード)とPutRecordBatch(1APIで複数レコード)がある。Kinesis AgentはOS上のログやイベントをKDS,KDF,CloudWatch,CloudWatchLogsへ転送する(リトライ機構も具備)。
  • レコードサイズは最大1000KB(★メッセージサイズの上限は、SQSやMSKとの使い分けのポイントの一つ)。

Data lake

S3

Predictive analytics and machine learning

Machine Learning

  • コーディングなしでMLを利用可能(★SageMakerとの使い分けのポイント)
  • トレーニングデータのデフォルトの上限は100GB(サポートリクエストで調整可能)(★SageMakerとの使い分けのポイント)
  • MLタイプは三つ。
    • バイナリ：二者択一。例：ネコか？犬か？
    • マルチクラス：複数選択。例：ネコ？トラ？ライオン？
    • 回帰：将来予測。

SageMaker

  • トレーニングデータに特に上限はない。(★MLとの使い分けのポイント)
  • SageMaker NEO：特定デバイスに最適化(高速化)するようモデルをコンパイル。

Othres

Lambda

  • vCPUの上限は6/メモリの上限は10GB
  • RedshiftへのクエリはData APIを使用
  • 最長15分でタイムアウト

Simple Queue Service

  • 最大メッセージサイズは256KB。Amazon SQS Extended Client Library for Javaにより、ペイロードをS3から参照することが可能で、最大2GBのメッセージに拡張可能(★メッセージサイズの上限は、MSKやKinesisとの使い分けのポイントの一つ)。

DataSync

  • DataSync Agentを介して、on premisesからS3やEFSにデータを移行可能。データ転送中はTLS1.2により暗号化され、データ整合性チェックも実施される。
  • S3,EFS,FSx for Windows File ServerとHDFS間のデータ転送が可能。

Database Migration Service

  • DBのデータ移行に使用するサービス
  • SSL/TLSで通信は暗号化

DynamoDB

  • プライマリーキーのタイプは二つ。パーティションキー単一で構成するタイプと、パーティションキーとソートキーの複合キーとするタイプ。
  • 1レコード400KBまで。
  • RCU：最大4KBの項目の読み込みについて、強い整合性の場合は1回/s、結果整合性の場合は2回/sの可能。※割り切れない数に注意。5KBの項目は強い整合性で2RCU,結果整合性で1RCU必要。5KBのファイルが4つ、合計20KBの場合は強い整合性で8RCU,結果整合性で4RCU。
  • WCU:最大1KBの書き込みについて、1回/s可能。
  • IAM認証可能。
  • DynamoDBは暗号化可能(DynamoDB Streamsも含めて)。

Key Management Service (KMS)

  • KMSのAPIで暗号化可能なデータサイズは4MBまで。
  • エンベロープ暗号化：プレーンテキストとデータキーを別のキーで暗号化する機能。

一般的なETLのナレッジ

  • ETLでは、ターゲットテーブルを変更 (更新、挿入含む) する前に、ステージングテーブルにデータを一時的に保持するということが行われる。GlueやRedshiftのAWS公式ドキュメントにもその手法に関について記載されている。