Athena
・クエリのためにはテーブル定義が必要
→デフォルトではGlue Data Catalog上のテーブル定義を使用。
・クエリ結果はクエリ結果とメタ情報データを指定したS3バケットに自動的に保存する
→この保存をオフにすることはできない
・クエリパフォーマンス改善のためには、
○スキャンデータ量を減らす
①parquetなどの列指向フォーマットの利用
②gzipなどによるデータ圧縮
③データのパーティショニング
○スキャンファイルを一定サイズ(128MB)以上にする
→小さいファイルばっかりにしちゃダメ
紙切れファイル問題に対してS3 DistCPを使用することで、小さなファイル群を大きなオブジェクトにまとめることができる。
○スキャンするファイルを分割可能な形式にする
○S3と同じリージョンにする
・サービス制限と料金
最大同時クエリ実行数：20
クエリタイムアウト時間：30分
クエリ実行単位の課金
・Glacierに移行されるとクエリ実行できない
→GlacierはAthenaの対象外
・別リージョンのS3バケットに対してもクエリできない
Glueカタログを介すと可能になる
・Amazon Athena Federated Query
→lambdaを経由してAthenaから様々なデータソース(DynamoDB,Redshift,HBase ,Aurora等)にSQLクエリが実行可能
・暗号化
→クエリ結果を暗号化してS3に保存することも可能
→AthenaとS3間の転送時のデータにはTLS暗号化を使用
Athenaで実行できるクエリ
・CTAS(Create Table As Select)
クエリ結果をもとにテーブルを新規作成。ETL処理をAthenaで実施
・INSERT
テーブルにデータ追加
・VIEW
クエリ結果自体を仮想的なテーブル(VIEW)として登録、サブセット作成や結合時
機能
・Partition Projection
テーブルに多くのパーティションがある場合、クエリ処理が遅くなる。
そんなテーブルに対してPartition Projectionを用いることで、パーティション情報をAthena自身が計算するのでクエリ高速化が実現でき、パーティション管理が自動化できる。
→テーブル作成時に設定をオンにしておくと、パーティションが存在する場所をAthenaに通知することができる。
・Workgroups
使用する目的は利用量・コストの管理。
ワークグループ毎に、クエリワークロードの分離、クエリメトリクスの分離、クエリ毎のスキャン量の上限設定→アラーム発報が可能。
クエリごと、ワークグループごとにコスト制約を強制できたり、ワークグループのクエリごとにCloudWatchメトリクスを設定できる。
クエリごとのコスト制約の場合超えるとキャンセル、ワークグループごとの制約の場合超えるとSNSに通知を飛ばせる。
※クエリグループではないワークグループ！
ワークグループを構成することで、CTAS 機能を使用して生成されたテーブルを具体的に含む環境をセットアップできる
Redshift
サービスポイント
・列指向ストレージ
→行指向と異なり全てのデータにアクセスする必要がない
・データ圧縮
→CREATE TABLE時に圧縮のエンコード(合計13種類)を選択して、列の圧縮ができる(未設定の場合は自動割り当て)
ANALYZE COMPRESSIONコマンドを使えば、既存テーブルに対して最適な圧縮方法を確認できる
・ソートキー
→頻繁に使用される項目をソートキーに設定することでディスクI/Oを削減できる
データ分散
→データを各スライスに分散して、処理性能を向上させる
処理改善
・Elastic Resize
→既存のクラスター上にノードを追加して、クエリの高速化を実現する。
スケジュール設定が可能。
コンピューティングノードで使用。
・concurrency scaling(同時実行スケーリング)
→大量の同時ユーザーやクエリに対して、高速のクエリパフォーマンスを実現する。
日/週/月単位で使用上限を設定して、コストコントロールが可能。
※この2つの違いとして、前者は新規作成前のクラスタは削除するのに対して、後者は一時的に大量リクエストを扱って、事象が解決した際に自動的にクラスタを削除することが挙げられる。
また、同時実行スケーリングは複数ユーザーの同時アクセス過多などの予測が難しいタイミングでのスケーリング、Elastic Resizeは予測が月末月初や夜間バッチなどの予測がしやすいタイミングに計画的に行うのが良い。(語呂合わせ：計画たてるのはえらい)
⇨サーバレス版ではよしなにやってくれているので考慮しなくて良い
・Redshiftはデータの更新が行われる度に自動的にS3にスナップショットを作成する。
・各ユーザーに対してテーブル、データベース、また列レベルでのアクセスコントロールが可能(GRANTやREVOKEコマンドにて)
・テーブルメンテナンス、ワークロード管理、パッチ適用、分散スタイルなど自動で実施してくれる。
※ワークロード…システムに関わる処理の負荷の大きさで、CPU使用率やメモリ使用率などの総称。
・Data Sharing
→クラスター間でセキュアで簡単にデータ共有することができる機能。
従来は間にS3を挟んでunloadとcopyを行っていたが、この処理が不要になる。
・Redshift Spectrum
→Redshift向けのクエリをS3向けにもできますよというサービス。
Redshift上のテーブルとS3上のデータを結合してクエリを実行できる。
⏩Redshiftと結合できるので、アクセス頻度の低いデータをS3に移動させておくことができる。
ETLツールとして利用できる。(ex:CSV→Parquet)
・copyコマンド
→NOLOADパラメーターを設定することでテーブルにデータをロードすることなく、うまくいくかの整合性を事前にチェックすることができる
→単一のCOPYコマンドを使用することでデータを平行してロードできるため、この方法で実施する(複数のCOPYコマンドだと直列化させて遅くなる)
→ファイル数を分割して小さいサイズにする。(1MB~1GBに圧縮する。)なお、このファイル数はクラスター内のスライス数の倍数にする。
・分散スタイル
○分散キーによる分散
・結合や集計が頻繁にある時
・ノード間トラフィックを減らす必要がある時
○EVEN分散
・テーブルが結合に関与していない時
・KEY分散とALL分散のどちらを選択すれば良いか明確でない時
○ALL分散
・更新頻度が低いテーブル
・更新範囲が狭いテーブル
・データ転送を排除する必要がある時
大きなファクトテーブルと小さなディメンションテーブルの場合、大きなテーブルにAUTO または EVEN 分散を使用し、小さなテーブルに ALL 分散を使用すると、より効果的になる
・同時実行スケーリング
redshirtの同時実行スケーリングを有効にすることで、自動的に新しいクラスター容量を追加して、読み取りクエリの増加に対応できる。(一時的に対応できる)
WLMキューを設定することでどのクエリを同時実行スケーリングクラスターに送信するかを管理できる。
このクラスターが実行されている時間分課金される。
・HSMによる暗号化
→Redshiftは既存クラスターの暗号化を許可していないため、HSM間に信頼接続を確立してから、HSMで暗号化された新しいクラスターを作成してデータを移行させる必要がある
※HSM(ハードウェアセキュリティモジュール)：暗号鍵を守るための物理的なハードウェア。金庫みたいな見た目と役割。
→redshirtがオンプレのHSMを使用するためにはVPN接続を使えば構成できる。(こっちの方が費用対効果が高い)
・COPYコマンド
→NOALOADパラメータを指定することで実際に処理は実施せずにロードエラーが発生した際に検出できる
→クラスター内のスライス数の倍数になるようにファイルサイズを分割して、並列でコピーする。
ファイル圧縮も同様ではあるが、並列>圧縮。
→redshiftテーブルコピーにおける再実行時の重複を無くすために、ステージングテーブルに登録して、それをターゲットのテーブルと結合させるようにする。
upsertができないため、この形をとる。
⏩今の案件もこの形。
ワークロード管理におけるクエリモニタリング
→クエリモニタリングルールには、一意のルール名、1つ以上の述語(条件)、アクションが必要
アクションにはログ記録、優先度の変更、中断、ホップ(次のキューに移す)がある。
・自動テーブル最適化(ATO)
→独自のAIによってワークロードを分析して、段階的に最適化していく。そのためすぐに改善されるわけではない。
・マテリアライズドビュー
→データの実体を持ったビューで、通常のビューと異なりリフレッシュが必要となる。SQLクエリによって必要な項目を抜き出すなどして作成される。
→予測可能で何度も繰り返されるクエリに特に効果を発揮する
→マテビューの更新はオプションで自動更新（AUTO REFRESH）も可能
・ショートクエリアクセラレーション(SQA)
→機械学習を使用して、クエリの実行時間を予測し、実行時間の短いクエリを、より高速に処理するためにショートクエリ用のWLMキューに移動して実行する機能。(実行時間が長いクエリより優先させる)
長いクエリの後にショートクエリを実行すると待機させられていたが、この機能によってショートクエリの応答時間の改善が期待できる。
※この機能はデフォルトで有効のため、ユーザー側で別途設定は不要
Redshiftは大量のデータ分析に適した設計となっているため、大量のセンサーデータを短時間に取り込むことは向いていないのでDynamoDBなどにさせる方が良い
・AZ障害時はマネージドストレージを使用して自動復旧させる。
データロスなしにリカバリー、別AZにオンデマンドでクラスター作成、スナップショットからのリストア不要。
・アドバイザー機能
→ワークロードを自動分析してパフォーマンス向上やコスト削減につながる推奨事項を表示する機能
推奨事項の例)COPYコマンド実行時のファイル圧縮や分割、未使用クラスターの停止
S3
アクセス管理
S3へのアクセスは以下の3つのやり方がある。
・ユーザーポリシー
→IAMユーザーのポリシー設定で制御する。このユーザーは何ができるのかをS3に限らず定義する。
・バケットポリシー
→S3バケットポリシーに定義する、クロスアカウントでのアクセス権を付与する場合などに利用。
このS3には誰がアクセスできるのか定義する。
・アクセスコントロールリスト(ACL)
→バケット単位とオブジェクト単位でのアクセスをAWSアカウントやS3グループに付与する。
それぞれバケットとオブジェクトにアタッチする。
⏩ACLはアカウント単位での権限付与しかできないので、IAMユーザーやロール等の制御が可能なバケットポリシーの方を使うようにする
・バージョニング
→同じ名前のオブジェクトがputされた時や今のバージョンのオブジェクトが削除された時にバージョンが記録される。
パフォーマンス
・マルチパートアップロード
→目安100MB以上のファイルをアップロードする際に1ファイルを複数に分割して並列にすることでスループットを向上させる。
分割されたファイルが全てアップロードされるとS3の方で結合する。
最大で5TBまで格納可能。
・Transfer Acceleration
→世界中のAWSのエッジネットワークから最適化されたネットワークを経由してデータ転送を高速化する。 (CloudFrontを利用する)
エッジロケーションの数はリージョンの数より多いため、高速化が実現できる。
・S3 Select
→S3に格納されているオブジェクトに対して、一部分のみ抽出(select)できる機能。(フィルタリングする。)
・S3バケットはグローバルサービスではあるが、リージョン毎に作成される。
暗号化
・SSE-S3
→AWSによって管理・所有されている暗号キーを使用する。(キーの管理者はS3)
→オブジェクトはAWSによってサーバー側で暗号化される。
→暗号化の流れとしてはS3に連携された時点でAWS管理の暗号化キーによって暗号化されてその状態でバケットに格納される。
・SSE-KMS
→暗号化キーはユーザー側でコントロールできる。(KMSの使用なので)
→CloudTrail経由で使用状況を追える。=監査機能を提供できる。
→暗号化の流れはSSE-S3と同じ。
・SSE-C
→暗号化キーはAWSの外部で管理され、S3は暗号化キーを保持しない。(キーの管理者はクライアント)
→暗号化の流れは、S3に対してファイル+暗号化キーでS3に連携して格納する。
→使用するにはCLIもしくはSDK、S3のREST APIを利用する必要がある。
→下のクライアントサイド暗号化との違いは暗号化・複合の場所がサーバー側であること。
→データの整合性に ETag は利⽤できないので、additional checksum 機能を利⽤する
・クライアントサイド暗号化
→クライアント側で管理、送信を実施する。
→暗号化の流れはクライアント側で全ての暗号化がされたファイルがS3に連携されるので、AWS側はそれを格納するだけになる。
・KMSはリージョンに固有
・クライアント側の暗号化はコンソールやCLIを使用したオブジェクトへのアクセスは許可していない
・サーバーアクセスログの送信先にはSSE-S3を設定したバケットじゃないと設定できない
・キープロバイダをDynamoDBにすることはできない
・EMRはSSE-Cをサポートしていない
・KMSへのリクエストが多い場合S3バケットキーを使用することで解決できる
・デフォルトの暗号化設定をしていてもオブジェクトアップロード時にデフォルトとは違う暗号化を選択したその選択した暗号化で実行される
・アクセスポイント
→あるバケットの複数のフォルダに複数のユーザーからアクセスがある場合、S3のバケットポリシーでアクセス制御するのは管理が大変になる。
そこで各フォルダごとにアクセスポイントを作成して、そこへのアクセスを定義したポリシーをユーザーにアタッチすることで管理が容易になる。
・S3オブジェクトLambda
→1つのS3バケットから様々なデータを生み出して、連携する。
例えば分析チーム向けにLambdaで編集する、マーケティングチーム向けにエンリッチしたデータをLambdaで作成するなど。
→Glueのような処理をS3+Lambdaで実行、これを新しいバケットを作成せずに1つのバケットだけで実現する。
→S3バケット⇨S3アクセスポイント⇨Lambda⇨Lambdaアクセスポイント⇨連携先という流れ。
・ボールトロックポリシー
→Glacierで出てくるボールトはS3で言うオブジェクト
ボールトロックポリシーとはボールトへのアクセスを読み込みのみにしたり、登録から1年経過しないと削除できないなどのポリシー
S3アクセスログは監査機能を提供できる。
→別途CloudTrailを見る必要がない。
・glacier select
→S3 selectと同じことがglacierでもできる。
ただし対象ファイルが圧縮されていると不可。
・CORS(クロスオリジンリソース共有)
→ブラウザで閲覧しているページとは違うドメインからのリソースの取得を許可する仕組み。
Webアプリケーションが他のドメインのリソースにアクセスする必要があるときに使用。
・オブジェクトロック
→バージョニングされたバケットのみに適⽤できる Write Once Read Many（WORM）機能で、削除/上書きを⼀定期間/無期限に防⽌できる
・Intelligent-Tiering
Amazon S3 Intelligent-Tiering は、パフォーマンスへの影響や運用上のオーバーヘッドなしに、最もコスト効率の高いアクセス層にデータを自動的に移動することでコストを最適化するように設計されたストレージ クラス
Dynamo DB
・テーブル作成時にPrimary Keyを必ず決定させる必要がある。
→Primary Keyには、パーティションキーのみとパーティションキー+ソートキーの2種類ある。
後者の場合はソートキーが一意である必要があり、パーティションキーは同じ値になっても良い。
例：ソートキー→購入者、パーテションキー→商品(購入者は様々な商品を買える)
→データ分散を最適化するキー選択が重要となる。
行ごとに一意になることが重要。(多様性を持たせること、データに偏りが生じないことが大切)
・各項目の最大サイズは400KBまで。
・RDSと違って新規の項目を追加しようとするとエラーにならず追加できる。
パーティションキーに設定した項目がnullで無ければ何でも追加、投入することができる。
・アンチパターン
→結合や複雑なトランザクション処理を要するもの
→サイズが大きいもの
・容量モード
→オンデマンドとプロビジョニングモードの2つがある。
プロビジョニングは自分でサイズを決定させる。
オンデマンドは自動で実行してくれるがコストが高くなってしまう可能性があるので、データサイズが不明だったり不規則な際に使用する。
インデックス
ローカルセカンダリーインデックス
・テーブル作成時のパーティションキーは変えずに、ソートキーを別の項目に設定できる。
・テーブル作成時にしか付与できない。
・パーティションキーとソートキー以外をクエリ対象にしたい際に付与する。
・メインテーブルのWCU(Write Capacity Unit)とRCU(Read Capacity Unit)を使用する。
・結果整合性と強い整合性をサポート(GSIは結果整合性のみ)
・使用は無料(GSIは有料)
グローバルセカンダリーインデックス
・テーブル作成時のキーとは別のキー指定ができる。
・プライマリーキーを代替してテーブル作成してクエリ高速化を目指す。
・メインテーブルが正常でもグローバルセカンダリーインデックスを付与したテーブルがスロットルを起こした場合全体でスロットル扱いとなる。
→WCU(Write Capacity Unit)の選択を注意しなければならない。
GSI
元々XXな条件でYYを絞るという形だったが、設計上ZZの条件でAAの結果も出す必要がある場合に活用。
LSI
元々XXな条件でYYを絞っていたが、ZZな条件でYYの結果も出す必要がある場合に使用。
・PartiQL
→DynamoDB上でSQL実行できる機能。
→エディターからselect,update,deleteなどが実行できる。
→またGlueでもPartiQLを実行することはでき、JSON形式のデータに対してクエリを実行できる
・DynamDB Accelerator(DAX)
→ホットキーや特定のアイテムに対してアクセスが集中してレイテンシーが生じる際にアプリケーションロジックを修正することなく、改善できる機能。
→何度も呼び出される際にキャッシュを保持してそこから応答することで、フルスロットルを避ける。
→操作自体はDAXクラスターを作成するだけで完了する。
→有料のサービス。
※ホットキーとは特定のサーバーにアクセス(読み込み)が集中してしまうこと
→DAXはポート8111で動作するため、DAX クラスターとの通信を有効にするためにはSGで8111を許可する必要がある
・DynamoDBストリーム
→テーブル内のデータ項目の変更情報を最大で24時間ログに保持している。
→ユースケースとしてはテーブルのデータに変更があった際にその情報をリアルタイムで処理したい際に使用する。
送信先としてKinesis Data StreamやLambdaなどがある。
・Time To Live(TTL)
→TTLを設定すると、設定した時間に応じてデータが削除される。
→削除されたデータはDynamoDBストリームに移動される。
・大きなデータを保持したい場合
→例えば画像ファイルなどが含まれている場合は、画像ファイル自体はS3に保存して、DynamoDBにはメタデータを保存するというアーキテクトを取ることができる。
・バーストキャパシティー
→利用されなかったキャパシティを過去300秒分保持していて、プロビジョン分を超えたバーストトラフィックの処理に充てられる。
・スロットリングの原因調査
スロットリングになっている際はホットキーが発生している可能性が高いので、以下2点を確認する
・消費されたスループット容量とプロビジョニングされた書き込み容量を示すCloudWatchデータ
・テーブルに定義されている全てのローカルセカンダリインデックス右LSIはプライマリテーブルへの書き込みに対してWCUを消費する
OpenSearch(旧ElasticSearch)
・ElasticSearchとkibanaを簡単にデプロイ、管理してスケールすることができるサービス。
→ElasticSearchとkibanaそれぞれの知識が必要となる。
・インデックス
→ドキュメントの格納先で、一般的なデータベースのテーブルに相当
・監査ログ
→OpenSearch 上のデータに対するアクセスログを取得
OpenSearch 上のデータに対するアクセスログを取得できる
・ OpenSearchは複数ファイルから特定の文字列を検索するサービス。
→商品検索やソースコード検索といったドキュメント検索、セキュリティログ監視やインシデント検知といった異常検知ができる。
→検索結果として、ヒットした件数やそのキーワードに付随する情報(インデックスに付与されているJSON情報)が返される。
・OpenSearchのクラスターのことをドメインと呼ぶ。
・ログ分析の場合、Firehorseからストリートデータを直接OpenSearchに入れるのが標準的な構成。
→別アカウントのfirehorseからもデータ投入可能。
・OpenSearchのみでKinesis Data AnalyticsとQuickSigntの機能を低いコストと低いオーバーヘッドで実行できる。
・logstash
→様々なフォーマットのデータを変換して一元化して収集することができるElastic社が開発したサービス。
収集したデータはElasticsearchなどで使用されることが想定されている。
例えばtwitterやgihubから収集したデータをcsvにしたり、Elasticsearchで分析できるようにしたり等。
・JVMメモリ負荷
→メモリ負荷エラーはノード間でのシャード割り当てが不均衡か、クラスター内のシャードが多すぎる可能性がある。
よって古い、もしくは使用していないインデックスを削除してシャード数を減らすことことで解決することがある。
S3オブジェクトの場所をメタデータとしてインデックス化することで、ユーザーが直接ファイルをダウンロードすることができる。
kinesis DataStream
・DataStream
→プロデューサーは、Kinesis Agent,AWS SDK,Kinesis Producer Library(KPL)の3つ。
コンシューマーは、Kinesis Data Analytics,Data Firehorse,Kinesis Client Library(KCL),Lambda
→立上時にシャードの数を指定して、データはパーティションキーによって送り先のシャードが決まる。
→モード設定は「プロビジョンドモード」と「オンデマンドモード」がある。使用容量が不明な時なオンデマンドを、明確な場合はプロビジョンドモードを選択する。
→オンデマンドだと自動スケールできる。
プロデューサーの特徴
・プロデューサーにSDKを指定するケース
→レイテンシーの速度がさほど求められない、シンプルなAPI、Lambda
・プロデューサーにKPL(Kinesis Producer Library)を指定するケース
→高性能かつ長期にわたるプロデューサーを構築したい、自動で再実行して欲しい
→1レコードあたりのサイズが小さいと複数レコードを集約して送信できる。⇒1回のAPI(Put Records)呼び出しだけで済む。
・Kinesis Agent
→ログやメトリクスを監視してそれをKinesis Data StreamやFirehorseに送る。
・スループット超過する際の対処法
→例えばIPhoneからだと共通のシャードにデータ送信されてしまい、データ量が多くなってしまいスループット超過を起こしてしまう。
この対処法としては、「バックオフにて再実施する」、「シャード数を増やす」、「適切なパーティションキー設定をする(適切な分散をする)」
・拡張ファンアウト機能
→Data Streamでは通常2MB/秒以上の出力をサポートしていないので、これを対応させるオプション機能。
コンシューマー側をData Streamに登録して、プロビジョニングされた拡張スループットを持つようになる。
コンシューマー側が少なくコストを抑えたい場合は標準で良いが、同じストリームを使用する複数のアプリケーションが存在してレイテンシー要件がある場合は拡張ファンアウト機能を採用する。
→プロデューサーからデータが送信されたがDataStreamからの応答がタイムアウト等でプロデューサーに伝わらなかった場合、プロデューサーは同じデータを再送するため重複したデータをData Streamで保持することになる。(別のシーケンスNoが割り当てられる)
この場合は後続処理で対処することが推奨されている。 ex)Glueでエラーにする。
・ログ収集
→CloudWatch Logsに蓄積されたログは、Data StreamとFirehorse、Lambdaの3つを送信先にできる。
・SQSとの違い
→複数のアプリケーションに配信できる
→リアルタイム処理が可能
→ビッグデータを扱える
→保持能力(365日間)
・KCLを使用していてメッセージ処理のレイテンシーが発生している場合、スロットリングが発生しており、対処法としてはチェックポイントテーブルのDynamoDBのスループットを増加させる。
・プロビジョニングやメンテナンスの必要があるため、firehoseに比べたら運用上のオーバーヘッドは伴う
・保持期間
→データの保持期間はデフォルトでは24時間、設定によって365日まで延長可能。
・データサイズ
→扱えるデータサイズの最大は1MiB(複数のデータをまとめて送信できるPutRecords APIだと5MiBまで送信可能)
・SequenceNumberForOrdering オプションによるシャード内の厳密な順序保証をサポート(PutRecord API)
・サーバー側の暗号化をサポートしており、データ保存時に暗号化できる。
ストレージから取得された後で複合される。
・デフォルトのKMSキーはキーローテーションできないので、一度KMSを作成してエイリアスを割り当てて使用する必要がある。
・対策
低レイテンシー対策→伝達遅延の時間をデフォルト(1秒)から短くする
扱うデータ量を増やす(高スループット化)→シャード数を増やす
処理速度や量を上げる(高スループット化)→拡張ファンアウト
・データが重複するケース
プロデューサーにネットワーク関連のタイムアウトが発生している→再試行する
シャードがマージされたり分割されている→再試行する
ワーカーが予期せず終了する→再試行する
ワーカーのインスタンスが削除、追加される→再試行する
アプリケーションがデプロイされる→再試行する
⇨Kinesis Datastreamにレコードが複数回配信される時はプロデューサーの再試行とコンシューマーの再試行がある
Kinesis Firehorse
・収集したデータをwriteのバッチを使ってコンシューマーに渡すため、ニアリアルタイムのサービスとなる。Data Streamはリアルタイム。
・Data Streamとの違いは自動スケーリングがある。またDataStreamはカスタムコード書く必要があるがFirehorseはない。あとはData Streamは最大365日データを保持できるが、Firehorseは流すだけなので保持はできない。
→Firehorseはフルマネージドサービス！
・Lambdaを用いてファイルフォーマットを変換したりファイル圧縮したりできる。
・送信先はS3,OpenSearch,Redshift、Splunkが主となる。(他にはDataDog等の3rdパーティ系)
※Splunk（スプランク）は、あらゆるアプリケーション、サーバ、ネットワーク機器のデータにインデックスをつけるソフトウェアで、自在に全てのITインフラの膨大な数のイベントを、リアルタイムで検索・分析できる。
・ソースや配信失敗の情報をS3に格納することができる。
・毎秒データを配信するようなことはできない。(最小のインターバル間隔が60秒)
Kinesis Data Analytics
・Kinesis Data Analyticsで分析されたデータをLambdaに出力できる
→別形式に変換したりエンリッチ、暗号化が可能になる
→またLambda経由にすることで更なる配信先に送ることができる(SNS,Aurora,DynamoDB,CloudWatchなどなど)
・RANDOM_CUT_FOREST
→設定した異常値範囲のデータが送信された場合検知して、後続サービス(SNSなど)に通知できる
・入力はKinesis DataStreamとfirehorseから取得できる
・S3にファイル保存すればデータソースにできる
→例えば今のSQLに追加してマッピングファイルをS3に保存すれば結合させて処理させることができるようになる
DMS(Database Migration Service)
・EC2の中にDMSが入っていることが前提となっている。(例：送信元DB→DMS(EC2)→ターゲットDB)
・異なるDB同士の場合、DMSのSCT(Schema Conversion Tool)という変換機能を用いる。同じ場合は使用しない。
→Oracle to MySQLはSCTを用いる。
マイグレーションしている間、ソースのDBは使用できる。
Snow Family
・通常のデータ転送では帯域幅や接続が制限されたり、ネットワーク利用料金が発生したりする。
→Snow Familyはオフラインデバイスのため、上記の問題が解消される。
・使用の流れは、デバイス取り寄せを申請する→届いたデバイスにデータを入れる→AWSに返送する→AWSの方でS3にデータ移行させる
・Ops Hub
→Snowballデバイスを管理・モニタリングするインターフェイス。
・SnowCone
→snow familyの中で最小で8TB
・AWS Snowball Edge
→80TB
・SnowMobile
→トレーラーを使う、100PB
MSK(Managed Streaming for Apache Kafka)
・Kafkaとは？
→大規模のストリームデータを扱うことができる分散メッセージシステム。よくKinesisと比較される。
Kinesis vs MSK
| KINESIS | MSK |
|---|---|
| 最大1MBのメッセージサイズ | デフォルトは1MBだが拡張可能 |
| シャードを分けたり、結合できる。→スケーリングが楽 | パーティションの追加のみ。→スケーリングが難しい |
| 認証：IAMのみ | 認証：Mutual TLS+Kafka ACLsやSASL+Kafka ACLsも使える |
| SDKサポート：Java, Android, .NET, Go | SDKサポート：Java |
| データ保持期間：7日間(課金すれば365日) | データ保持期間：ユーザーが自由に設定できる |
| スケーリング重視だったり学習コスト重視ならKinesis | メッセージサイズが大きい場合や認証に幅を持たせたい場合はMSK |
EMR
・クラスター
→EMRのクラスターには3つのノードが存在する。
①マスターノード：クラスターの状態監視等クラスターの管理をする。
②コアノード：タスクを実行するソフトウェアがあり、 HDFSにデータを格納する。
③タスクノード：スポットインスタンス的に使用し、HDFS等にデータを保持しないのでデータ消失のリスクがない。
そのためコスト効率よく容量を増やしたい場合などに用いられる。
・容量追加のためタスクサイズを変更する場合、タスクノードの追加や削除をするのがベストとなる。
→これによりストレージは問題ないが処理性能が一時的に追いつかない場合などにも対応できる。
→コアノードを削除するHDFSストレージも削除することになるので注意する。
ジョブの完了時間を短くするために(パフォーマンス向上)
→同時マッパータスク数の変更
→MapReduceジョブ設定で入力分割サイズを変更
⏩Glueと似た考えと感じた
→データサイズによってデータファイルの圧縮を行う
例)GZIP圧縮だと1GBまでが推奨なので、1GB以上の場合bzip2やSnappyのような圧縮の方が向いている
また大量データを高速にクエリする必要があるなど、クエリ性能が求められる場合は圧縮/解凍速度が早い圧縮方法の方が良い。
※公式のBlackBeltによるとSNAPPYも分割可能、速度を求める時はSnappyやLZOを使うのが良いとのこと
EMRファイルシステム
→EMRがS3と直接読み書きのやり取りができるようになるサービス
これによって可用性が心配なデータをS3に保存できたりする
・ブートストラップアクション
→EMRのノード起動時に任意の処理を追加実行できる機能。
例えばS3にスクリプトファイルを置いておけば起動時にその処理を実行できるし、カスタムAMIの設定によって立ち上げることができる
※ブートストラップアクションにてルートデバイスのボリュームを暗号化することはできないため、この場合カスタムAMIを使用する。
⏩ブートストラップアクションが許可する以上の高度なクラスター及びノード設定をしたい時はカスタムAMIを使用する。
・インスタンスグループ/インスタンスフリート
→インスタンスフリートはCloudWatachメトリクスによる自動スケーリングをサポートしていない。インスタンスグループはサポートしている。
インスタンスフリートは同一のフリート内でインスタンスタイプや購入オプションを組み合わせることができる。
・ルートボリュームの暗号化
→既に立ち上がっているEMRクラスターのルートボリュームを暗号化するためには、ローカルディスクを暗号化して、クラスターを再作成する。
・透過的暗号化
→透過的なデータ暗号化によってデータの転送中と保存中の暗号化設定ができて、Apache Rangerを使用して承認できる
・Apache Ranger
→Hadoopプラットフォーム全体で包括的なデータセキュリティを有効化、監視、及び管理するためのフレームワーク、
Hadoopコンポーネントにおけるきめ細やかな承認や中央監査が含まれる。
emrにおいて、複数のマスターノードを複数のazでホストすることはできない。
単一のazに複数のマスターノードにする。
立ち上げ時にパブリックアクセスブロックの設定で構成することができる。
これによってEMRクラスターがパブリックインターネットに公開されなくなる。
・永続的でない一時的なクラスターにする際
KeepJobFlowAliveWhenNoStepsをfalseにして、終了保護フラグを無効にすることで実行中のジョブがなくなればクラスターを破棄することができる。
EMRFSの整合性のあるビューを有効化することでデータが薄な割れることを防ぐ
・S3 DistCp
→S3からHDFSに大量のデータを効率的にコピーできる。HDFSからS3へのデータコピーも可能。
EMRは容量の90%が利用開始となった時点で課金を開始する。
クラスターの効率化
・S3をEMRのデータレイクとして使用する→EMR上のHDFSより低コストのため
・Gravitonインスタンスを使用する→従来の x86 ベースのインスタンスに比べて価格性能比が優れていて、コスト削減を実現するように設計されており、パフォーマンスが最適化されているため、コストが最適化され、パフォーマンスが重視されるビッグデータワークロードを EMR で実行するのに適しているため
Glue
DataBrew
・PIIデータ(個人を特定できる情報)の検出を自動的にして、コード記述することなく置き換え、ハッシュ、暗号化、複合などのマスキング処理が可能
・Parquet、エクセル(xlsとかxml)、CSV、JSONの各ファイル形式をサポートしている
・Glueトリガー
通常は Glue ジョブを直接トリガーするために使用されますが、Glue ジョブの実行前または実行後に Lambda 関数を呼び出すトリガーを設定することもできる
Lambda→Glueの実行順で、最小限の管理労力で管理したい場合はGlueトリガーを使用する
・データカタログ
Amazon EMR と統合された永続的なメタデータストアを提供し、Apache Hive と互換性のある完全に管理された Hive メタストアとして機能する
EMR+Glueデータカタログの構成にできる
・FLEX実行クラス(FlEXジョブ)
スポットインスタンスを利用して低コストでジョブを実行する、開始時間、実行時間はバラバラ。
正確なタイミングが問題にならない場合は、「FLEX」オプションを使用すると、Glue は AWS クラウドの空き容量を利用してジョブの実行を最適化できるため、オンデマンドインスタンスに比べてコスト効率が高くなる。
優先度の低いジョブ実行、一度だけ実行したいワークロード、開発環境での実行に向いている。
・MSCK REPAIR TABLEコマンド
データカタログを S3 バケット内の新しいパーティションと同期するために使用する
クエリ
VACUUMコマンド(VACUUM FULL)
データが更新または削除されたテーブル内のスペースを再利用し、行を並べ替えるために使用
インターリーブ ソート キーを使用する場合にVACUUMによるデータの再ソートは重要
その他
・Managed Workflows for Apache Airflow (MWAA)
カスタマイズ可能なスケジュール設定、監視、依存関係の管理など複雑なETLワークフローを作成する必要がある際に使用する
StepFunctionsより複雑で柔軟性が求められる場合。
・DataSync
オンプレミスのストレージシステムと AWS ストレージサービス間のデータの移動を簡素化、自動化、高速化するオンラインデータ転送サービス
インターネットまたはAWS Direct Connect経由で大規模なデータ転送を処理できるため、ダウンタイムを最小限に抑え、進行中のものを中断しない
スケジュール機能を使用してオンプレミスのファイルサーバーと Amazon S3 間のデータ転送を自動化できる
データ検証の機能も要している
・SSE-KMSとSSE-S3の違い
AWS KMS 管理キー (SSE-KMS) を使用してサーバー側の暗号化を実装すると、企業は、誰がキーを使用してデータを復号化できるかについてきめ細かい権限を定義できる、SSE-S3だとできない
またKMSキーの場合はキーローテーションも可能
・Lambdaレイヤー
複数の Lambda 関数間で共有されるコードとライブラリを一元的に管理する方法
レイヤーが更新されると、それを参照するすべての関数が自動的に最新バージョンにアクセスできるようになる
・CloudTrail Lake
複数の AWS アカウントとサービスにわたる監査ログの集約、管理、分析専用に設計
AWS CloudTrail ログを 1 か所に統合できるようにする集中型ソリューションを提供
・Amazon MemoryDB for Redis
読み取りおよび書き込み操作にマイクロ秒単位のレイテンシーを必要とするクラウドアプリケーション向けに構築された、Redis 互換の完全マネージド型インメモリ データベース サービス
セッション管理とプレイヤー リーダーボード用の高速なインメモリ データ ストアを持っている
・(用語)データメッシュ
データは必ずしも一箇所に集めなくても良いよ、事業部などの各組織でちゃんと管理してくれればデータはどこにあってもOKよ」という考え方
よくあるデータを一か所に統合して管理しようという考えと真逆になる
・ECS系
Fargate を使用して Amazon ECS で実行されているコンテナに永続的なストレージを提供する際はEFSを使用する(S3ではない)
・Lambda
サブネット内で実行可能。
プライベートサブネット内に存在するDBと通信を行う場合はSGの許可と同じプライベートサブネット内に配置して実行することでインターネットに出ることなく実行できる
S3オブジェクトLambda
S3から取得したデータをアプリケーションに返す前に処理するカスタム コードを追加できる
・CloudWatch Logs Insights
Amazon CloudWatch Logs に保存されているログデータを効果的にリアルタイムで分析およびクエリできる
→AthenaはCloudWatch Logsにはアクセスできない(S3だけ)
・Macie
機械学習とパターンマッチングを使用して Amazon S3 内の機密データを検出し、分類するデータ セキュリティ サービス
PII などの機密データを識別して保護するように特別に設計されている
・StepFunctionsのMAPとparallel
mapは全く同じタスクを繰り返し実行する際に使用する、タスクの順次実行というシナリオには合致しない→例えば、同じ手順を異なるデータに対して繰り返し実行したいときに便利
⇒家の中で複数の部屋がありますよね？それぞれの部屋をきれいにするために、同じ掃除の手順を各部屋に対して行います。Step Functionsの Map は、このように同じ「掃除の手順」を複数の「部屋」に対して自動的に実行することができます。
parallelは複数のタスクを同時に並行して実行する際に使用する
⇒学校でグループでプロジェクトをするとき、いろいろな作業がありますよね？例えば、調査する人、プレゼンを準備する人、ポスターを作る人などがいるかもしれません。Step Functionsの Parallel は、それぞれの作業を同時に進めることができます。つまり、調査とプレゼンの準備とポスター作成を同時に進めることができるんです。
・VPCエンドポイント
例えばGlueジョブとS3が上手く接続できないときはVPCエンドポイントポリシーがGlueからのトラフィックを許可しているか確認する
・DMS
継続的なレプリケーションが可能。
オンプレのデータ移行時にDataSyncと比較されるが、DataSyncはデータベースの移行に特化しているわけではなく、データベース スキーマの変換やその他のデータベース固有のタスクは処理しない
・Data Exchange
クラウド内のサードパーティデータを簡単に検索、サブスクライブ、使用できる
一度サブスクライブすると、AWS Data Exchange を設定して様々なデータセットを Amazon S3 に自動的にインポートし、最小限の手動介入でデータレイクを定期的に更新できるようになる
サードパーティという言葉で登場すればこのサービスで良いのではないか
・RDS拡張モニタリング
50 を超える CPU、メモリ、ファイルシステム、ディスク I/O メトリクスのセットにリアルタイムでアクセスできるようになる
CloudWatch によって提供される基本メトリクスよりも詳細なため、データベース管理者が RDS インスタンスのパフォーマンスを分析および最適化するのに最適
・EBSのボリュームタイプ変更
mazon EBS では、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を使用して、ダウンタイムなしで既存のボリュームのボリュームタイプを変更できる