AWS Lake Formation
# AWS Lake Formation
https://d1.awsstatic.com/webinars/jp/pdf/services/20191001_BlackBelt_LakeFormation_A.pdf
## データレイクとは
- データから価値を見出す業務が増え、データは年々増えていく
- データにアクセスする人々も増えている
- 分析対象のデータに対する要件も増えている
- データレイクとは
- 全ての構造化データと日構造化データを保存できる一元化されたリポジトリ
- データをそのままの形で保存できるため、データを構造化しておく必要がない
- ダッシュボードや可視化、ビッグデータ処理、リアルタイム分析、機械学習など様々なタイプの分析を実行できる
- 分析の結果、意思決定を行える
- なぜデータレイクが必要か
## AWS Lake Formation 登場の背景
- データレイクを構築するには（数ヶ月単位の準備が必要）
- ストレージのセットアップ
- データの取り込み
- クレンジング、整形、データのカタログ化
- セキュリティの設定と適用
- 分析にデータを活用できるようにする
- AWS Lake Formation の概要
- データの取り込みと構造化（ブループリント）
- データ管理のテンプレートを提供
- Glue のトリガー、ワークフロー（一連のETL処理を行う）、クローラー、ジョブを自動で作成
- 自動的にデータ取り込み
- データベースからのバルクロード
- ログをインクリメンタルロード
- 整形、暗号化
- S3バケットに保存＆アクセス（IAM）
- アクセスを行う対象のS3パス（Data Lake Location）
- Data Lake Location に登録したパスに対するアクセス許可（Data Location）
- データベースやテーブルの作成ができるようになる
- 以前は様々なサービスに対して設定を行わなければならず、辛かった
- セキュリティ＆コントロール（パーミッション）
- ユーザーはAWSサービス（Amazon Athena, AWS Glue, Amazon Redshift, Amazon EMR）を通してアクセス。管理者はLake Formation 上でユーザーのアクセス制御を設定
- SQLライクなGrant / Revoke でシンプルなアクセス制御を実現
- 適切なユーザ、グループに正しいデータへのアクセス制御を定義
- データベース、表、列の単位の粒度で制御可能
- パーミッションの種類
- 協調＆利用（データカタログ）
- メタデータカタログを利用した検索と定義確認
- 全てのアクセスはIAMポリシーによりチェック
- 新しいデータが取り込まれたり、ツールが変更されてもポリシーにより保護可能
- アクセス時の連携
- 監視＆監査（ロギング）
- アクセス要求や発生したポリシー例外を記録
- アクティビティ履歴で変更ログやログデータの入手経路をレビュー
- CloudTrail
- Lake Formation とAWS Glue の関係
- Glue はETL(抽出・変換・ロード）を行うジョブとデータカタログを持つマネージドサービス
- Lake Formation はAWS Glue の拡張版とも言える
- Lake Formation はGlueとデータカタログを共有している
- Lake Formation のジョブとクローラーはGlue のジョブとクローラを呼び出している
- セキュリティ強化やブループリントによるデータ取り込みなどでより便利にGlueの機能を使えるようになっている
- AWS Glue からLake Formation への移行
- AWS Glue ではアクセスの権限管理をIAMを介して行なっている
- 対してLake Formation では自身で権限管理をしている
- 移行の際にはアクセス許可モデルの移行が必要になる
- IAMAllowedPrincipals という平行稼働時の運用をサポートするツール（移行後はOFFにすることを推奨）
## 雑感
後ろでAWS Glue を利用しているが、より一連の操作を行いやすくし、AWSでデータレイクを構築・運用するためのマネージドサービス。データのETL処理や権限管理をメインで行ってくれる。利用料金自体はかからず、分析サービスやデータストアの料金のみがかかる。シンプルになるのであればAWS Glue を利用すればいいが、そうではない場合はAWS Lake Formation を利用する感じだと思う。
一番のメリットは散らばりやすいIAMの管理がLake Formation にまとめられ、管理がしやすくなることだと思う（もしGlueをすでに利用している場合でも移行パスは提示されている）。また、ブループリントによりETL処理が楽になる部分があるかと思うが、（これ自体はGlueで提供されている機能かもしれないので）確認してみる。
テーブルレベルではなく、行単位で権限管理ができるのはすごいと思った。分析者に見てはいけないデータを見させないためのモノであるとは思うが、ちょっと権限管理が面倒になるかな、とも思った。
公式（モヒカン）漫画もあった。
Amazon Managed Streaming for Kafka
# Amazon Managed Streaming for Kafka
https://d1.awsstatic.com/webinars/jp/pdf/services/20191120_AWS-BlackBelt_AmazonMSK.pdf
## Amazon Managed Streamingfor Apache Kafka(MSK)とは
- フルマネージドで可用性が高く、セキュアなApache Kafka
- 他のデータソースからデータを一時的にキューイングして他のサービスへ連携する
- 分散データストリーミング・プラットフォーム
## Apache Kafka とは
- 全体像
- Kafka のクライアントとして、プロデューサーとコンシューマーが存在する
- Pub: プロデューサー
- トピックと値を指定してキューに値を送る
- リーダーレプリカのみに書き込みを行う
- Sub: コンシューマー
- Kafka は複数のサーバーでクラスターを構成しており、スケーラビリティと可用性を確保している
- コンポーネント
- ブローカー
- クラスターとして動作し、データの受配信を担う
- トピック
- メッセージを種別で管理する
- パーティション
- ブローカー上に分散配置され、トピックのメッセージが格納される
- 冗長性確保のためにブローカー間でコピーされた複数のセプリカを構成する（リーダーレプリカと複数のフォロワーレプリカ）
- リーダーレプリカに対して書き込みが行われる
- フォロワーレプリカはリーダーレプリカに書き込まれた内容を複製する（リーダーは同期が取れているかを把握している）
- コンシューマーのメッセージ読み込みもリーダーレプリカのみから行われる
- オフセット
- メッセージがパーティションに入れられた際に付与されるシーケンシャルな番号
- パーティション単位で最初に取得したメッセージをZooKeeper もしくはKafkaが覚えていてくれる
- どこまで読み出したかを管理することができる
- ハイウォーターマーク
- レプリカによる複製が完了済みのオフセット
- コンシューマーはハイウォーターマークのデータのみ取得可能（＝レプリカに複製済みのキューだけサブスクライバは取得できる）
## Amazon MSKの機能
- Amazon MSK はコントロールプレーンの操作を提供
- データプレーンの操作はApache Kafka のAPIをそのまま使用可能
- トピックの作成や管理
- プロデューサーからのデータの入力
- コンシューマからのデータの取得
- アーキテクチャ
- Amazon MSK
- Broker node
- Zookeeper
Kafka on EC2 と Amazon MSK を利用した場合の違い
- Kafka on EC2
- Amazon MKS
## 運用
- 構成管理
- ブローカー・トピック・ZooKeeper のデフォルト構成を提供している
- カスタム構成を作成することも可能
- カスタム構成で既存のクラスタを更新することも可能
- スケーリング
- ストレージの拡張
- ブローカー数の拡張
- クラスタの耐障害性
https://aws.amazon.com/jp/blogs/news/best-practices-for-running-apache-kafka-on-aws/
- クラスタを適切なサイズに設定する
- ディスク容量を監視する
- ディスクフルを防ぐ
- Kafka の Data Retention パラメータを指定する
- ディスクの空き容量を定期的に解放する
- MSKの管理外にあるブローカーを追加しない
- データ通信の暗号化を有効にする
- パーティションの再割り当てを行う
## ユースケース
- Amazon Kinesis との使い分け
- Amazon MSK
- Apache Kafka 互換
- クラスタをプロビジョニング
- シームレスなスケーリングが困難
- オンプレミスからの移行が容易
- Kafka MirrorMaker を利用してオンプレのKafka のデータをMSKにミラーできる
- Kafka Connect を利用してKafka 周辺のシステムを接続できる
- Schema Registry
- Amazon Kinesis Data Streams
- Apache Kafkaのユースケース
- メッセージング
- ActiveMQなどの代わりとして
- ウェブサイトのアクティビティ追跡
- メトリクス
- 分散したアプリケーションから運用監視データを集約して集計や統計処理を実施
- ログの集約
- ログのイベントデータをメッセージのストリームとして利用
- ストリーム処理
- イベントソーシング
- コミットログ
- Amazon MSK のユースケース
## 雑感
基本的にはKinesis Data Streams を使うのが良さそう。ただ、既存のApache Kafka クラスタがあり、それを移行したい場合などにはAmazon MSK という選択肢が出てくる。
MSK自体はマネージドではあるが裏側にM5系のインスタンスがあるのでスケールやキャパシティやスケーリングに制限があるので最終的にはKinesis Data Streams に置き換えることを目指すのが良さそう。
Amazon EMR
# Amazon EMR
https://d1.awsstatic.com/webinars/jp/pdf/services/20191023_AWS-Blackbelt_EMR.pdf
## なぜAmazon EMR を利用するのか
- 何が求められているか
- 新たな非リレーショナルデータをペタバイト以上のスケールでリアルタイムにキャプチャして保存
- バッチレポートだけではなく、リアルタイム、予測、音声、画像認識を組み込む新しいタイプの分析をする必要がある
- 安全かつ管理された方法でデータへのアクセスを民主化する
- 従来までの分析方法
- Amazon EMRとは
- マネージドなHadoop と Spark
- 最新のHadoop および Spark エコシステムのリリースをデプロイ
- 任意のサイズに拡張可能
- 高い可用性と耐久性
- オートヒーリング
- 高い安全性
- 暗号化
- 保管時の暗号化
- 転送時の暗号化
- Amazon Macie によるセキュリティ
- VPCを利用したネットワーク分離
- S3 をPrivate Link で接続してよりセキュアに
- パブリックアクセスをブロックするオプション(Block Public Access)
- IAMポリシーとの連携
- AWS CloudTrail
- Kerberos サポートによるAD認証
- Hadoop エコシステム機能による認証認可
- RIを利用可能
- 必要に応じてスケールさせることができ、コスト最適化を図れる
- データはS3へ、コンピューティング部分と分けることで、用途に合わせたクラスタを立てることができる
- 他のAWSサービスとの連携
- Kinesis Connector
- DynamoDB-connector for Hive
- S3
- Redshift-spark connector
## Amazon EMR で何ができるのか
## どうやって利用するのか
- クラスタを作成後でも、ソフトウエア設定を再構成して、実行中のクラスタ内の各インスタンスグループに設定を追加・更新することができる
- Job 実行時の処理のステップを追加することが可能
- 複数のtask グループを設定することが可能（task グループによってインスタンスファミリーを変更するなど）
- オートスケーリングの設定
- ロギング
- デフォルトでマスターノードに書き込まれるログをS3に出力することもできる
- デバッグオプション
- EMRFS Consistent View
- S3は結果生合成を持つので、一貫性がない場合に処理を再実行させることができる
- DynamoDB をファイルレジストリとして使用し、矛盾の検出と処理の再実行を行う
- カスタムAMI
- ゴールデンイメージとして運用
- 起動時の処理の追加
- EC2キーペアを設定することでマスターノードにSSHできる
- IAMの設定
- 暗号化とセキュリティグループ
- EMRノートブック
## Amazon EMR とその他のサービスとの使い分け
- Amazon Athena
- AWS Glue
- 以下のケースに当てはまるなら Apache Spark on Amazon EMR を利用するのが良い
- ETL 処理にSpotインスタンスを利用したい
- 単一のノードのスペックを高くしたい
- ETL 処理にSpark 以外のアプリを使いたい
- Amazon Kinesis Data Analytics for SQL/Java App
- Amazon DynamoDB
まとめると以下の場合にはAmazon EMRを利用するのが良い
- Hadoop と各種アプリを柔軟にカスタマイズしたい
- オンプレのHadoop クラスタをシンプルに移行したい
- マネージドサービスの制限を回避したい
- できるだけ新しいバージョンを利用したい
- アプリケーションのバージョンを固定したい
- 複数種類のアプリケーションを同一クラスタ上に稼働させて連携させたい
## 雑感
Amazon のマネージド MapReduce。大量のデータを処理するための分散処理基盤であるHadoop / Spark のマネージドサービス。分析するAWSのサービスは他にAmazon Athena や Amazon Redshift があるが、これらはS3をデータソースとして分析するだけにとどまっているので比較的制限がある。それに対してAmazon EMR はより柔軟に大規模なデータを扱うのに適している。Amazon EMR で最初に処理を行った後にS3にストアしたデータを利用してAthena や Redshift を利用するという組み合わせで処理を組むことも可能。
インターネットに露出しない仕組みや、IAM やHadoop そのもののセキュリティの仕組みを利用してセキュアに利用することもできる。
Q. Redshift とEMR の使い分け
https://aws.amazon.com/jp/redshift/faqs/
Q. ビッグデータサービス（Athena, EMR, Redshift）との比較
Amazon Elasticsearch Service, Amazon CloudSearch
# Amazon Elasticsearch Service, Amazon CloudSearch
https://d1.awsstatic.com/webinars/jp/pdf/services/20200623_aws_blackbelt_amazon_es.pdf
https://d1.awsstatic.com/webinars/jp/pdf/services/20160323_AWS-BlackBelt-CloudSearch_AmazonES.pdf
## 全文検索とは
## Elasticsearch とは
- ログ分析や検索に関する様々なスースケースで利用できる、分散型RESTful 検索/分析エンジン
- コンポーネント
- 可視化
- Kibana
- 分析/検索
- Elasticsearch
- 収集
- Log stash
- beats
- データ挿入から活用までの流れ
- データの持ち方
- 論理的なデータの持ち方
- Index の中にDocument を持つ。Documentの中にフィールドとしてアイテムが格納される
- 物理的なデータの持ち方
- マスターノードとデータノードに分かれる
- データノードではプライマリーシャードとレプリカシャードが作成され、可用性を向上させている
## Amazon CloudSearch 概要(2011-)
- 自動拡張するフルマネージド検索サービス
- Auto Scaling
- Auto Partitioning
- Apache Solr のマネージドサービス
- Indexing
- 全ての喉にELB経由で均等にアップロード
- ファイルをS3に保存
- メタデータはDynamoDBに保存
## Amazon Elasticsearch Service の概要
- 概要
- Elasticsearch と Kibanaを簡単にデプロイ・管理・スケールさせることが可能なフルマネージドサービス
- エンタープライズグレードのセキュリティ、アラート、SQLなどにより強化されたElasticsearch のディストリビューションであるOpen Distro を採用
- 利点
- フルマネージド
- 柔軟性
- コスト効率
- RIも選択できる
- 高可用性
- セルフヒーリング
- モニタリング
- マルチAZ
- 自動バックアップ
- スケーラブル
- スケール
- バージョンアップ
- パッチ適用
- セキュア
- VPC内へのデプロイ
- Cognito によるログイン
- API
- サポートするインスタンスサイズ
- インスタンスサイズによって最大EBSサイズやHTTPリクエストペイロードの最大値がことなる
- 世代が古いと古いESバージョンが利用できるが、データ暗号化や詳細アクセスコントロールが設定できないなど制約も多い
- 推奨アーキテクチャ
## ログ分析
- データ投入
- ログ分析の場合、Kinesis Data Firehose 経由でストリームデータを直接ESに入れるのが定番（別アカウントからのインプットにも対応）
- CloudWatch Logs サブスクリプションにより、Lambdaを経由したストリームデータ投入も行える
- Lambda等からElasticsearch のBulk API を叩いてS3のデータを定期的にインポートするといったことも可能
- SQLインターフェースのサポート
- Ultrawarm ノード
- 大規模ログ分析を低コストで実現するためのノードタイプ
- S3に保持したデータに対してクエリを実行
- 読み取り専用
- クラスタ横断でのクエリ実行
## 検索
- 日本語全文検索用のプラグイン
- ユーザ辞書ルールによるカスタム辞書の使用
- Kuromoji で形態素解析をする時にユーザ登録の固有名詞を教えておく場合に利用
- カスタムパッケージによるファイルベース辞書の使用
- kNNによる最近傍探索
## 管理
- Indes State Management(ISM) でインデックス管理の自動化
- ISM機能により、日・週・月単位で新しく作られるインデックスの管理を自動化、従来Curator で行う必要があったものをAmazon ES 側で設定可能に
- Kibana 上でインデックス管理ポリシーを設定・管理
- _template API と併用することで新しいインデックスうにポリシーを自動で反映
- ロギング
- Elasticsearch API のログ
- 以下をCloudWatchに出力
- インデックススローログ（ドキュメントの追加・削除・更新）
- 検索スローログ（検索クエリ）
- エラーログ
- デフォルトでは無効になっている
- 設定APIのログ
- APIコールのログをCloudTrailに出力
- 検索APIベースのアラート
- Elasticsearch のクエリを指定して、一定の閾値を超えた場合にアラートをあげることが可能
- Slack 等に通知を飛ばす
- Anomary Detection をトリガーにしたアラートの実行
- Random Cut Forest アルゴリズムを用いた時系列の異常検知機能
- 設定変更
- ドメイン変更時にはBlue/Green デプロイによって行われる
- 一時的に倍のノードになりデータノードとマスターノードに負担がかかる
- 深夜帯に行うことを推奨
- スナップショット
- クラスターのバックアップ
- 自動スナップショット
- バックアップ
- １時間ごと14日間作成
- 手動スナップショット
- バックアップ / データ移行
- S3にデータを保存するため料金に入れる
運用のベストプラクティス
## セキュリティ
- 認証と認可
- IAMベースのAmazon ESドメインに対するアクセスポリシー
- Logstash のAWSプラグインを利用することでAWSのクレデンシャルを利用してデータ投入できる
- Open Distro ベースのドメインないサブリソースに対する詳細なアクセス権限管理
- ユーザー
- ES内部で管理
- Cognito 連携
- 詳細な権限管理
- インデックスレベル
- ドキュメントレベル
- フィールドレベル
- Kibanaのマルチテナンシー
- 暗号化
- VPC からAmazon ES にプライベート接続
## Amazon CloudSearch と Amazon ES の比較
- CloudSearch
- 検索エンジン
- Solr
- CloudSearch API を利用して検索
- AutoScaling でスケールする
- インスタンスストアにデータを保持するため大量データ保存は厳しい
- ログの可視化はできない
- リアルタイムデータ取り込みは制限がある
- Amazon ES
http://dev.classmethod.jp/cloud/elasticsearch-service-vs-cloudsearch/
- 決まった仕様のCloudSearch か 高いカスタマイズ性のElasticsearch
- 1対多のデータ構造対応ならElasticsearch
- 運用で楽がしたい場合はCloudSearch
## 雑感
AWS のマネージドElasticsearch。IAMによる制御に加え、OSS自体についている認証・認可の仕組みを利用して、ドメイン・ドキュメント・インデックスレベルで細かく制御をすることができる。
料金がノード間の転送料金はかからないが、Amazon ES からのin/out がかかるのでアプリの仕組みによってはお金がかかるようにも思える。
そもそも運用コストがElasticsearch が高いので、Amazon ESを利用することで運用コストをかなり減らすことができると思う。
それよりも仕様が決まっていて、運用で楽がしたいのであればCloudSearch を利用することが選択肢となると思う。
Amazon Kinesis
https://d1.awsstatic.com/webinars/jp/pdf/services/20180110_AWS-BlackBelt-Kinesis.pdf
- 概要
- ストリームデータを収集・処理するためのフルマネージドサービス群
- 利用場面
- 広告/マーケティング
- IoT
- ゲーム
- コンシューマー向け
- 運用/セキュリティ
- ストリーミングデータの利用シナリオ
- データの収集とETL
- 配信や入札データの収集
- 顧客行動データの収集
- 運用のシステムメトリクスの収集
- 継続的なメトリクス計算
- コンバージョンレート/収益/カバレッジの計算
- クリックレートの計算
- PVの計算
- システムログ分析
- リアルタイム分析と応答
- ユーザ行動に応じた配信・入札エンジンの最適化
- 稼働状態予測あアラート・通知の発行
- レコメンデーションエンジンの最適化
- 異常検知
### Kinesis Streams
ストリームデータを処理するためのアプリケーションを独自に構築
- アーキテクチャ
- input
- 認証・認可を経てデータをInput
- たくさんのストリームデータがKinesis Streams へ
- 3AZでの強い生合成でデータを複製
- 順序つきのイベントストリームとして複数のアプリケーションから同時アクセス可能
- Output
- コンセプト
- データの種類や用途に応じてストリームを作成。ストリームは１つ以上のシャードで構成
- 保存されるデータの単位を「データレコード」と呼ぶ
- 保存期間はデフォルトで24時間。最長7日
- １データレコードの最大サイズは1MB
- ストリーム内のシャード数を増減することでスループットをコントロール
- データレコードの分散
- データ入力時に指定するパーティションキーで保存先のシャードが決定
- 分散して処理が可能に
- 全てのデータレコードにはシーケンス番号（シャード内でユニーク）がアサインされ、順序が保証される
- サポートするプロデューサー・コンシューマー
- プロデューサー（送信側）
- AWS SDK
- Kinesis Producer Library (KPL)
- Amazon Kinesis Streams にデータを送信するOSSの補助ライブラリ
- Aggregation
- 複数件のデータを１データレコードに集約して送信可能
- Collection
- 複数レコードをバッファリングして送信
- Kinesis Agent
- Amazon Kinesis サービスにデータを簡単に収集して取り込むスタンドアロンJavaアプリケーション
- ファイルのローテート処理、失敗時の再試行、フォーマットの変換やログのパースなどの前処理をしてくれる
- Cloudwatch へメトリクスを送信
- Kinesis Streams / Kinesis Firehose のどちらへも送信可能
- AWS IoT
- Kinesis Log4j Appender
- Fluentd
- CloudWatch Events/Logs
- Amazon Kinesis Data generator(KDG)
- コンシューマー（データ処理側）
### Kinesis Firehose
ストリームデータをAmazon S3, Amazon Redshift, Amazon ESへ簡単に配信
データストアとダイレクトに統合
サーバレスETL
- コンセプト
- 配信先に応じて「配信ストリーム」を作成
- シャードの作成やパーティションキーの指定は不要
- 制限なしにスケール
- １データレコードの最大サイズは1MB
- 連携
### Kinesis Analytics
ストリームデータを標準的なSQLクエリでリアルタイムに分析
- コンセプト
- 分析単位に「アプリケーション」を作成し、入出力となる「ストリーミングソース/ディスティネーション」を設定
- SQLクエリ実行の前処理としてLambda 関数を指定可能
- クエリの複雑さとデータのスループットに応じてKPU(Kinesis Processing Units) を設定
- Kinesis Streams / Firehose -> 入力ストリーム -> Lambda -> SQL -> 出力ストリーム -> Kinesis Streams / Firehose
- 様々なタイムスタンプを利用して処理
- タンブリングウィンドウ/ スライディングウィンドウ を指定して問い合わせ
- CloudWatch によるアラート
- 参照テーブルの結合
- ユースケース1
- Data producer から Kinesis Firehose にデータを送り込む
- ユースケース2
- Lambdaを利用したスピード優先の処理
- Redshift やEMRを利用したBatch 処理での分析
- ユースケース3
- IoTと組み合わせたセンサーデータの収集と前処理
## 雑感
ストリームデータの受け取り、Lambda と連携した処理、データ受け取り後に他のサービスに流す処理を行うサービス。大量のデータを受け取り、分析がしやすい状態に加工して、本職のサービスが利用しやすい状態にすることがメインになる。
大量なデータを受け取ってもフルマネージドで無制限のスケールなので心配する必要がない。
Kinesis Data Streams とSQSの違いは
SQSはシンプルにキューイングしてコンシューマーはそれを取り出してキューから削除するが、Kinesis は大規模なストリーミングをリアルタイムに処理したり、レコードを数時間後に同じ順序で提供したい場合などで利用される。これはTTL時間の差やレコードのサイズの差にも表れている。
Amazon Athena
# Amazon Athena
https://d1.awsstatic.com/webinars/jp/pdf/services/20200617_BlackBelt_Amazon_Athena.pdf
## Athena とは
Amazon S3 にあるデータ（または様々なデータソース）に対してSQLを使用して簡単に分析可能とするインタラクティブなクエリサービス
- 特徴
- ユースケース
- シンプルにS3に対してクエリを発行して分析
- ログ分析
- S3に出力される様々なAWSサービスのログや収集データに対してクエリ
- ETL (Extract/Transform/Load)パイプラインをAthena で構築
## Athena の使い方
- データをS3に保存する
- Database Migration Service
- Kinesis Data Firehose
- Kinesis Data Streams
- S3
- Storage Gateway
- Snowball / Snowball Edge / Snowmobile
- DataSync
- AWS Transfer Family
- テーブルを定義する
- Athena ではクエリのためにテーブル定義が必要
- デフォルトでAWS Glue Data Catalog 状のテーブル定義を使用
- HiveQL形式でDDLを記述
- データソース
- データを記述するデータカタログとデータを合わせてデータソースと呼ぶ
- デフォルトのデータソースはAWS Glue Data Catalog
- すでに既存の仕組みがあり、Hive Metastore を持っている場合にはこれに対してAthena を接続できる
- クエリを実行する
## Athena の様々なクエリ
- CTAS(Create Table As Select)
- クエリ結果をもとに新しいテーブルを作成
- ETL処理をAthena で実行可能
- データを圧縮フォーマットに変換
- データを複雑に加工整形するための多段クエリ
- パーティショニングとバケッティング
- INSERT INTO
- クエリ結果をもとに、既存のテーブルにデータを追加
- 実行のたびに新しいファイルが生成されるため、少量データでの実行を繰り返すことで、大量の小さなファイルが生成されクエリパフォーマンスに影響
- パーティション追加
- VIEW
- クエリ自体を仮想的なテーブルとして登録
- 活用シーン
- データのサブセットをクエリする
- 複数のテーブルを１つのクエリに結合する
- 既存の基本クエリの複雑性を解消して、ユーザーによるクエリの実行を単純化する
- クエリ問い合わせのインターフェースとして利用し、クエリ仕様変更に対する影響を最小限にする
- 地理空間データ分析
- 変数（SELECT $path, WHERE $path)
- LIKE 句やWhere 句で利用
- Amazon Athena Federated Query
- 様々なデータソースに対してSQLクエリを実行可能
- AWS Lambda で動作するコネクタを利用して実行
- 標準コネクタ
- Amazon DynamoDB
- Amazon Redshift
- Apache HBase
- MySQL
- PostgreSQL
- Athena Query Federation SDK を利用して、独自コネクタを実装可能
- User Defined Function(UDF)
- ユーザ独自のスカラー関数をUDFとして定義してSQLクエリで呼び出すことが可能
- データの圧縮・解答、機密データの編集、カスタマイズされた復号の適用など独自の処理を実行可能
- Java で実装し、Lambda関数としてAthena から呼び出される
- Machine Learning(ML) with Amazon Athena
- Athena SQL クエリでSageMake MLモデルを呼び出し、推論を実行可能
## パフォマンスチューニング
### データ最適化
- 列指向フォーマットにする
- Online Analytical Processing 向き
- 特定の列をまとめて保持
- 特定の列だけを扱う処理では、ファイル全体を読む必要がない
- メリット
- OLAP 系の分析クエリを効率的に実行できる
- 単純な統計データならメタデータで完結する
- IOの効率が上がる
- データ圧縮
- 最低限分割可能な圧縮形式を利用しておくことで分散処理をすることが可能
### データレイアウトの最適化
- パーティションを利用する
- S3 オブジェクトのキーを構成をCREATE TABLE に反映
- Where句で絞った時に LOCATION でS3のパスを指定し該当ディレクトリだけを読み込む
- Partition Projection
- 概要
- 非常に多くのパーレィションがあるテーブルにたいするクエリ処理を高速化し、パーティション管理を自動化することが可能
- パーティションプルーニングでメタデータを利用して、クエリに適用されるパーティションにだけ処理を実行することで高速化を図れる。
- しかし、テーブルに非常に多くのパーティションがある場合AWS Glue Data Catalog に対するパーティション取得APIの呼び出しがクエリパフォーマンスに影響する可能性が生じる
- Partition Projection を利用するとパーティション情報をAthenaが計算できるようになるため(AWS Glue Data Catalog を経由しないため）クエリ高速化の恩恵を享受できる
- ユースケース
### クエリの最適化
- LIMIT を利用してORDER BY を最適化
- JOINの順番を工夫する
- GROUP BYの工夫
- LIKE演算子を利用する際にはregex に置き換えて実行する
- （多少の誤差を許容できる場合）近似関数を利用する
- 必要なカラムだけを読み込む
## Athena の運用管理
- Workgroups を利用した利用量・コストの管理
- EventBridge を利用したクエリ監視
- CloudWatch メトリクスの利用
- CloudTrail を利用した利用状況のロギング
## Athena のセキュリティ
- 保管時の暗号化
- 転送時の暗号化
- AWS Lake Formation によるFine Grained Access Control
- シンプルな権限のGrant / Revoke
- データカタログのデータベース・テーブル・列に対して権限を指定可能
- 全てのデータアクセスを一箇所で監査
- AWS Glue Data Catalog のリソースベースポリシー
- IAM との連携
- AWS Glue Data Catalog
- S3
- VPC エンドポイント
## 雑感
Athena と Redshift はSQLを発行できる、列指向（がメイン）として利用されるので競合に当たるものだと思う。Athena はフルマネージド、Redshift はマネージドだがクラスタを用意しないといけない点で異なる。イメージとしてはアドホックに利用したい場合や既存のあるデータが対応している場合に利用してみるかという感じ、Redshift はそもそもデータから何かを生み出すように設計して運用される場合に利用されるイメージ。
AWS WAF
# AWS WAF
https://d1.awsstatic.com/webinars/jp/pdf/services/20200324_AWS_BlackBelt_AWS_WAF_Update.pdf
## WAFとは
Web Application Firewall
ウェブアプリケーションの通信内容を検査し、不正なアクセスを遮断するルールセットを持つセキュリティ対策
## WAF の対応する範囲
- 攻撃手法
- DDos
- CloudFront
- ELB
- AWS Shield
- Application Attacks
- <- WAFはここ
- Targeted attackes
- WAFがしていること
- WAFは悪用する能力を制限するもの
- 様々なHTTPのリクエストパターンを検証
- 攻撃の変化に対応するためにルール構成を迅速に変更する機能
## WAF の機能
- 機能
## WAFの変更点
- 2019.11 でWAFはv2になり、v1 はWAF classic となった
- ルールの記述タイプが統一
- より柔軟に表現も可能に
- WAF Capacity Unit が上限
- それぞれのルールの中身に応じて処理コストを計上、その合計がWeb ACL のCapacity を超えない範囲でルールを登録可能
- 上限は1500
- ビルトインのマネージドルール
- AWS WAF Full logs の拡張
## WAF の詳細
- WAF のコンポーネント
## WAF を利用した多段防御
User - AWS Shield - Route53 - (WAF - CloudFront) - WAF - ELB - EC2
というように複数箇所の前段にWAFを置くアーキテクチャ
## ログとモニタリング
- モニタリング
- AWS WAF Full logs
- Elasticsearch と Kibana によるログ分析
- カスタムエラーページ
- CloudFront と連携させて設定可能
- パートナーマネージドルール
## WAF 利用のための考慮事項
- ルールポリシー
- ブラックリスト型
- デフォルトのアクションは許可
- ルールに合致した不正なリクエストをブロック
- ホワイトリスト型
- デフォルトのアクションはブロック
- ルールに合致したリクエストを許可
- 限られた利用者がアクセスするケース
- ルールの運用
- セルフサービス
- テンプレートなどを利用してルールを構築
- ログの分析やルールのアップデートを継続実施
- 誤検知が発生した場合はルールの見直しを自身で実施
- マネージド
- 導入ステップ
- Count モード
- 開発環境等でテスト
- 誤検知が発生していないかサンプルリクエストレポートで確認
- CloudWatch メトリクスでルールを評価
- Full Logを確認
- Block モード
- 連携
## 雑感
AWS のマネージドWeb Application Firewall。構成のところで確認したが、アーキテクチャの一番前段にはAWS Shield が入り、その後ろで多段で利用されるイメージ。
どのトラフィックを通すのか、どのくらいの連続したトラフィックを悪意のあるトラフィックとして遮断するかを柔軟にWCUの範囲内で設定することができる。
JSONで設定を管理することができるのでVCSで管理を用意にしやすいし、APIで管理できるので運用にも乗せやすそう。1ルールあたり1$かかるので、効率的にルールを決めて悪意のある攻撃を遮断できるように設計する必要がある。
