LINE Messaging API + EventBridge + Lambda(Python 3.9)で作るLINE bot

●要件

・LINEで気温に応じた適切な服装を通知。

・朝7:30にLINE通知を飛ばす。

●技術選定

LINE Messaging API + EventBridge + Lambda(Python 3.9)

Lambdaのスケジュール実行はCloudWatch Eventsでやると思ったが、AWSがEventBridgeを推奨しているため選択

※イベントを管理するには、Amazon EventBridge が好ましい方法です。 CloudWatch Events と EventBridge は同じ基盤となるサービスと API ですが、 EventBridge はより多くの機能を提供します。

●開発

・天気予報API

OpenWeatherMapを使用

アカウントを作成してAPI Keysを取得してAPIが叩ける。メソッドはGET。

参考:https://auto-worker.com/blog/?p=1612

・LINE Messaging API

チャンネル(bot)を作成してuser IDとChannel access tokenを取得してAPIが叩ける。

curl -v -X POST https://api.line.me/v2/bot/message/push \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer {channel access token}' \
-d '{
    "to": "{user ID}",
    "messages":[
        {
            "type":"text",
            "text":"curl から"
        }
    ]
}'

メッセージ送信に関して参考: https://developers.line.biz/ja/reference/messaging-api/#send-push-message

・Lambda

コードは以下の通り

import json
import urllib.request

def lambda_handler(event, context):
    
   weather_url="http://api.openweathermap.org/data/2.5/weather?q=Tokyo,JP&appid={API Keys}&lang=ja&units=metric"
   weather_req = urllib.request.Request(weather_url)
   with urllib.request.urlopen(weather_url) as res:
    body = json.loads(res.read())
    
    weather_description = body["weather"][0]['description']#天気
    weather_temperature = body['main']['feels_like']#気温

    if weather_temperature >= 20:
      clothes = "半袖"
    elif weather_temperature >= 13:
      clothes = "ライトアウター"
    else:
      clothes = "アウター"
     
    line_UserId="{user ID}"
    line_AccessToken="{Channel access token}"
    line_url = 'https://api.line.me/v2/bot/message/push'
    line_data = {
        "to": line_UserId,
        "messages":[
            {
                "type":"text",
                "text": f"天気は{weather_description} 服装は{clothes}"
            }
        ]
    }
    line_headers = {
        'Content-Type': 'application/json',
        'Authorization': 'Bearer {'+line_AccessToken+'}',
    }
    line_req = urllib.request.Request(line_url, json.dumps(line_data).encode(), line_headers)
    urllib.request.urlopen(line_req)

LambdaでテストするとLINEが来る。

・EventBridge

スケジュールを選択 スケジュールパターン

JST(Japan Standard Time) 時間で時差を考慮する。

日本標準時JST)はUTCに比べて9時間早いため、

日本時間でイベント日時を設定する場合はその9時間前で設定する。

●ゴール

S3 , S3 Glacier

容量無制限(1ファイルにつき5TBまでという制限)のオブジェクトストレージサービス

 

●概要

バケット=オブジェクトの保存場所。名前はグローバ ルでユニークな必要あり

・オブジェクト=S3に格納されるファイルでURLが付与される。バケット内オブジェクト数は無制限 

・バージョンID=バージョン管理に用いるID 

メタデータ=オブジェクトに付随する属性の情報 

S3はグローバルサービスですが、データはリージョンに保存

複数のリージョンに保存されるは誤りで、複数のアベイラビリティゾーンに保存されるになります。

バケットのMFA認証が可能。削除行為には毎回MFA認証設定が可能

 

●料金

保存データ容量、データ取得リクエスト、データ転送アウトに応じて課金される。

データインは無料。

 

●書き込み/読み込みの性能

プレフィックス=ファイルの名前

保存されているデータはプレフィックスごとに分散されて保存されているので,

プレフィックスを意識しデータを保存することで書き込み/読み込みの性能を改善出来る

プレフィックス分散することで書き込み読み込み性能が向上する。

もし10個のプレフィックス分散すると並列化して10倍の性能を発揮する。

☆日付ベースでアップロードを分散すること

プレフィックスをランダム化する設定はしなくていい。

 

● S3は強い整合性。

S3は強い整合性。

・新規登録

登録後即時にデータが反映される

・更新

齟齬は発生しない

・削除

齟齬は発生しない

 

●イベント通知

・オブジェクトの作成イベント

・オブジェクト削除イベント

・オブジェクト復元イベント

・低冗長化ストレージ (RRS) オブジェクト消失イベント

レプリケーションイベント

をトリガーに通知できる。

SNS

SQS

Lambdaのみが可能。

 

●ライフサイクル管理、バージョニング機能

https://dev.classmethod.jp/articles/3minutes-s3-versioning-lifecycle/

・ライフサイクル管理

データ利用頻度に合わせてストレージクラスを変更するオプション

有効期限切れオプションで削除も可能。

・バージョニング

過去の更新前のデータが必要になったり誤ってオブジェクトを削除してしまった場合でも、

オブジェクトを復元することができる。

同じファイルならバージョニングを有効にすれば変更ログもとれるし、更新もファイルを上げるだけでOK。

 

クロスリージョンレプリケーション

異なる AWS リージョンにある2つのバケット間で、オブジェクトを自動的に非同期にコピーする機能です。

バケットに対するオブジェクト作成・更新・削除などのデータ処理のイベントをトリガーとしてレプリ ケーションが実行。

クロスリージョンレプリケーションは同じ AWS アカウントが所有するバケットにも、異なるアカウントが所有するバケットにも設定できます。

レプリケート元とレプリケート先の両方のバケットで、バージョニングを有効にする必要があります。

両方向でのクロスリージョン設定で双方向でのクロスリージョン設定が可能

 

●S3 署名付きURLとは

S3のオブジェクトに対して権限によらずURLさえ知りえれば誰でもダウンロードできる機能

 

●オブジェクトロック

オブジェクトが絶対に削除されないようにする。

設定すると永続的にロックされる。

ロックする期間を設定することができる

Write Once Read Many (WORM) モデルで一度書き込んだら削除不可。

(WORM) モデル

書き込みは一度だけだが読み込みは何度でも可能。

 

●S3のデータ構造

ストレージクラス分析が存在する。

最小キャパシティ=格納するファイルが128KB未満のファイルでも128KB分の容量を使用しているとみなす

最小ストレージ期間=30日未満の保管でも30日分の保管としてみなす

 

・STANDARD

デフォルトストレージ

レイテンシーに高スループット

耐久性 99.999999999% 、可用性 99.99%

 

・STANDARD-IA

低頻度アクセス用 スタンダードに比べて安価

参照頻度が低いデータ向けに設定されたストレージクラス

最小オブジェクトサイズと最小ストレージ期間が設置されている。

ユースケース:高速なアクセスが必要だがそれほど頻繁にアクセスしない時

耐久性 99.999999999% 、可用性 99.9%

最小オブジェクトサイズ(128 KB)

最小ストレージ期間(30日間)

 

・One Zone-IA

性能はSTANDARDと同じだが、単一AZのみでデータを複製するストレージ

高い耐久性だが、AZ障害時データ復元ができない。

使用例:バックアップのコピーや再作成可能なデータ

耐久性 99.999999999% 、可用性 99.5%

 

・Intelligent-Tiering

特にアクセスパターンが変化するワークロードにおいて有効なものです。

STANDARDとSTANDARD-IAの2段階で構成されている。

低頻度アクセスのオブジェクトを自動的に低頻度アクセス層に 移動することでコストを削減する。

30日間アクセスがないと高頻度アクセス層は低頻度アクセス層へ移動する。

ライフサイクル管理を自動化できる反面、頻繁に階層の移動が発生する場合はコスト高となる。

耐久性 99.999999999% 、可用性 99.9%

 

・RRS

現在非推奨。

冗長化ストレージ 

Glacierから取り出したデータ配置等

耐久性 99.99% 可用性 99.99%

 

・Glacier Flexible Retrieval(Glacier)

ほとんど参照されないアーカイブ目的のデータを保存するストレージ

データの取り出しには3-5時間がかかる。

ユースケース:長期間保存しアクセス頻度も低く取り出しにある程度時間がかかっても構わないデータ保存

耐久性 99.999999999% 、可用性 N/A

最小オブジェクトサイズ(40 KB)

最小ストレージ期間(90日間)

 

・S3 Glacier Instant Retrieval

アクセスされることがほとんどなく、ミリ秒単位の取得が必要な、

長期間有効なデータ用に最低コストのストレージを提供する新しいアーカイブストレージクラスです。

S3 Glacier Instant Retrieval を使用すると、四半期に一度データにアクセスする場合、

☆STANDARD-IAを使用する場合と比較して、ストレージコストを最大 68% 節約できます。

 

・Glacier Deep Archive

取り出しに12時間

年に1~2回しかアクセスされないようなデータを対象にしたストレージクラス。

最小オブジェクトサイズ(40 KB)

最小ストレージ期間(180日間)

 

●暗号化 

○SSE(Server Side Encryption)

サーバーサイド暗号化

サーバー側で暗号化を行う。

☆サーバ側の際はデータがストレージに読み込まれる際に暗号化さえて読み出される時に復号。

バケットポリシーが評価された後にバケットの暗号化が実施される。

そのため暗号化がされない場合はバケットポリシーを疑う。

 

・SSE-S3

☆デフォルトでS3バケットはSSE-S3暗号化が実施されている。

S3の標準暗号化方式で簡易に利用可能 

SSE-S3は暗号化と復号化をS3が自動で実施してくれるため、最も管理に手間がかからない暗号化方式

すべてのs3バケットで共通の鍵を使い鍵に対する個別のアクセス制御は不可能。

アメリカで標準とされているAES-256暗号化タイプを使用

AES(先進的暗号化標準)

256(ビット数)

 

・SSE-C

ユーザーが指定したキーによるサーバー側の暗号化 (SSE-C) を使用することが可能

利用設定や管理が煩雑になるのがデメリット 

HTTPSのみサポート

 

・SSE-KMS 

AWS KMSに設定した暗号化キーを利用した暗号化を実施 

ユーザー側でAWS KMSを利用して暗号化キーを作成・管理 することが可能
クライアント独自の暗号キーを利用可能 

CloudTrallにログが残る。

 

CSE(Client Side Encryption)

クライアント側で暗号化を行う。

クライアント側はAWS SDK(開発ツール)を使用してS3に送信される前に暗号化する。

暗号化したオブジェクトをS3に登録しますので、

暗号化されたオブジェクトはクライアント以外に復号化が不可能

 

●S3のアクセス管理

○IAMポリシー

IAMユーザー/サービスに対してS3サービス『への』アクセス権限を設定

バケットポリシー

バケット単位のアクセス権の設定

バケット及び、外部のユーザーも含めたアクセス管理

IPなどで制限したい場合はバケットポリシー

ACL

アクセスするユーザーへのアクセス管理

バケットも可能だが、オブジェクト単位で公開、非公開を制御も可能。

 

ACL

・4つの付与対象者と5つのアクセス権で制御する。バケットも可能だが、オブジェクト単位で公開

バケット作成時にACLを無効化すると、編集が押せない。

デフォルトではアカウント管理者のみアクセス可能

設定はアクセス権を付与される人とアクセス権に分かれており設定が可能。

○アクセス権を付与される人

バケット所有者 (AWS アカウント)

全員 (パブリックアクセス)

AWS アカウントを持つすべてのユーザー

アクセスログの書き込み権限

○アクセス権

READ、WRITE、READ_ACP、WRITE_ACP、FULL_CONTROLの5つ

ACPはACLへの権限。

WRITE_ACPだとACLへ書き込むことが可能。

 

●ブロックパブリックアクセス

デフォルトは全てブロック。

4つの設定が存在する。

1.新しいACL を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする

既存のACLの設定は評価される。

だが既存のACLの設定を変更して、パブリックアクセスが可能な状態にすることはできない。

また、新規にバケットを作成する際、もしくは新規にオブジェクトをバケットにアップロードする際に

パブリックアクセスが可能な状態で設定されることを防ぐ。

 

2.任意のACL を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする

既存のACLでパブリックアクセスが可能となっている設定を無視して、

すべてのバケット、またオブジェクトに対して、パブリックアクセスができないようにします。

 

3.新しいパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする

1.のバケットポリシー版

 

4.任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックする

2.バケットポリシー版

 

●アクセスポイント

バケットごとのバケットポリシーの肥大化を抑える。

独自のARNに独自のポリシーを割り当てることでバケットポリシーのコードの肥大化を抑える。

個別のアクセスポイントを作成することで大規模なバケット管理が簡単となる。

アクセスポイントポリシーを設定することでポリシーを設定することが可能

個別に複数のアクセスを制御したい場合はこちらを使用する。

インターネット経由からアクセスするのか、VPCからアクセスするのか選択できる。

ユーザーとかIAMロールとか設定が可能

○できること

・アクセス制限設定

特定のIPアドレスウェブサービスにアクセスを限定するアクセス制限を設定

VPCアクセス制限設定 

VPCに対して特定のS3 バケットへのアクセス制限を設定する

 

バケットポリシーとアクセスポイントとアクセスコントロールリストの違い

バケットポリシーの場合、バケット単位でのルールを作成する。

アクセスポイントはアプリやユーザー単位でアクセス許可を変える。

アクセスコントロールリストはオブジェクト単位で設定。

 

●S3アクセスアナライザー

アクセスポリシーに沿っているかを確認し、不正なアクセスが発生していないか、アクセスポリシーを監視する機能

IAM アクセスアナライザーに連動したS3向けの機能 

・アクセス履歴をCSV形式でダウンロードできる。

いつだれがどのバケットにどういった操作をしたのかを出力できる。

 

●WEBサイトホスティング

ブロックパブリックアクセスを無効化してバケットポリシーで読取許可をして公開

route53を使用する際の注意点として、ホスティングする際はバケット名とドメイン名の一致させないといけない。

S3の前段にクラウドフロントを配置する場合はバケット名とドメイン名の一致させる必要はない。

 

●S3 アクセスログ

サーバーアクセスログにはバケットに対するリクエストの詳細が入ってる

有効にするとサーバーアクセスのログをとれる。

暗号化はS3を暗号化した時点でS3も暗号化される。

 

●S3 Transfer Acceleration

海外リージョンなど、送信元から遠く離れたS3へのデータ転送を
CloudFrontのエッジロケーションとネットワークプロトコルの最適で高速化するサービスです。

ユースケース

世界中からアップロードが行われるケース

大陸間で定期的にGBからTBのデータを転送するケース

 

●マルチロードアップロード

アップロードはPOSTかPUT

大容量オブジェクトをいくつかに分けてアップロードする機能

ユースケースとして5GB以上で5TB以下のファイルをアップロードする。

SDKCLIからは最大5GBまでしかアップロードが不可能のため使用する。

マネジメントコンソールからは160Gまで

【失敗した場合】 

・アップロードを中止すると一部のパートのみ残る

・ライフサイクル管理でクリーンアップ設定が可能

 

●バッチオペレーション

S3 オブジェクトの大量データに対して一括処理を実行することが可能

○ジョブ

・ジョブはS3 バッチオペレーション の機能の基本単位で、 ジョブを作成することでバッチオペレーションを作成 

・ジョブにはオブジェクトのリストに対して指定された操作を 実行するために必要なすべての情報を登録 

・S3バッチオペレーション にオブジェクトのリストを渡し、そ れらのオブジェクトに対して実行するアクションを指定

○マニュフェスト

ジョブを実行するオブジェクト

マニフェストとは、Amazon S3 が作用するオブジェクト キーをリストする Amazon S3 オブジェクト 

マニフェストオブジェクトキー、ETag、およびオプションで バージョン ID を指定 

Amazon S3 インベントリレポート/CSVファイルの2つの形式で設定

 

●S3データの解析 

○S3 Select (Glacier Select)

・データを検索、選択するためのAPI

・S3の内部機能として有している検索機能で、S3内で直接にクエリを実行し、データを取得できる 

GZIP圧縮データやCSVJSONに対して実行可能

ユースケースAWS Lambdaで構築されたサーバーレスアプリケーションに適用し、パフォーマンス向上

Amazon Athena

Amazon S3 内のデータを直接、簡単に分析できるようにするクエリマネージド型サービス

・AthenaはS3 Selectよりも高度な分析に利用すること

・Athena SQL クエリで SageMaker 機械学習モデルを呼び出し、機械学習による推論も実行可能

ユースケースウェブログに対してすばやくクエリを実行し、

サイトのパフォーマンス問題のトラブルシューティングのみを行う場合

Amazon Macie 

機密データを取り扱う。

機械学習にS3 の機密データを検出、分類、保護する、フルマネージド型サービス 

・機密データ検出や調査を実施する

Amazon Redshift

Amazon S3の格納データに対して、Amazon Redshiftから 直接クエリを実行出来る機能 

・ Redshiftクラスターが起動されている前提であるため、 Redshiftを利用している場合にお勧め 

 

●S3 Glacier

・バルク取り出しによる大量データの取り出しは5-12時間

・標準取り出しは3−5時間

・迅速読取を利用することで1分~5分

Glacierのデータ保存はAPIによる操作かライフサイクル管理機能によって行う。

☆Glacierに直接データをいれた場合はライフサイクル機能が使えない。

データの暗号化はデフォルト

・ボールト

アーカイブを保存しているための領域 でS3バケットに相当する。

ボールドはリージョンおよびアカウントで一意である必要がある。

アーカイブ

データ。

S3のオブジェクトに相当する。

一意なアーカイブIDが割り当てられる。

・イベントリ

各ボールドに保存されているアーカイブの情報を収集する。

1日に一回更新

・ジョブ

アーカイブに SELECT クエリを実行したり、

アーカ イブを取得したり、ボールトのインベントリを取得したりする実行単位

 

●Glacier Select

アーカイブデータに対して直接SQLを発行する。

1、必要なデータのSQLを発行

2、Glacierが条件に一致したデータをS3に出力する

3、ユーザーは抽出したデータを参照する

 

●ボールトロック

S3 Glacierに格納されているアーカイブデータに対して、書き込み処理ができないように

ロックをかけるオプションがボールトロックです
S3 Glacierに格納されているデータはその性質上、

改ざんされないようにプロテクトする必要があるケースが多い

Redshift

●概要

ペタバイト規模のフルマネージド型データウェアハウスサービス

数百ギガバイトのデータから始めて、ペタバイト以上に拡張可能

単一AZで起動し、マルチAZ構成は不可

PostgreSQL互換の列指向データモデル

コンソール画面からRedshiftDBに直接クエリを実行できる。

・バックアップ ⇒S3 への自動/手動スナップショット

クロスリージョンスナップショットにも対応しており別リージョンにも保存はできるがデータ転送コストがかかる。

・リストア ⇒ スナップショットからの復元

・監視 (システム/ワークロード) ⇒コンソールや CLI 経由で状況を確認

☆アクセス監査 ⇒アクセスログを S3 上に自動取得

・バージョンアップグレード⇒定期的な自動アップグレード

パッチ適用も自動で実施

・キャパシティ管理⇒厳密な管理は必ずしも必要ではない(マネージドストレージで自動スケール)

クラスターサイズの変更を設定

 

●料金とインスタンスタイプ

1時間あたりでの課金。リザーブドノードも対応可能

・RA3インスタンス(高い)

データ量の増大が予想される場合は、 RA3 ノードのご利用を推奨

最低2ノード必要

・DC2インスタンス(安い)

固定ローカル SSD ストレージを使用 してデータウェアハウス

最低1ノード必要

・DS2(レガシー)

1番安い

 

機械学習によるクエリ効率化

○テーブルメンテナンス の自動化 

・テーブルの分散スタイルの自動最適化 

・統計情報の自動更新 

・データの再編成の自動実行 

○自動ワークロード管理 

・クエリ実行の優先順位決めを自動化する 

○ショートアクセル レーション 

・対象のクエリを 1つ1 つ分析し、クエリの実行時間を予測し、

実行時間が短いク エリを、実行時間が長いクエリよりも優先して実行 

・WLMキューを削減可能 

○設定の レコメンデーション 

・自動でクラスターパフォーマンスなどを分析し、最適化やコスト削減に対するレコメンデーションを実施

 

●マテリアライズドビュー

※select文につけたあだ名がビュー

頻繁に実行するクエリパターンを結合・フィルタ・集計・射影 によって高速化する機能

ビュー定義のクエリ実効結果を保持する。

CPUやIOの負荷が抑えられる。素早く結果が得られる。

 

●WLM(ワークロード管理)

Redshiftは5クエリまでしか対応していないため、ロングクエリーがボトルネックとなる。

そのため、クエリのワークロード管理を実施してさまざまな種類、用途に対応できる。

ルールに基づいてキューを設定して優先順位を設定可能してワークロード管理を実施する。

ユースケース

日中はBIツールにリソースを優先的に割り当て、

夜間はバッチ処理用といった異なるワークロードに対応

 

●S3との連携

S3はデータレイクとしてデータ活用のハブとして利用できる

構造化されているデータをRedshiftに入れて

半構造化データをS3に入れる。

 

●スケーリング

ノードの追加とクラスターの追加で性能向上

・Concurrency Scaling(並行性のスケーリング)

設定するとクエリに待ちが発生した場合にクラスターが自動で追加される。

追加クラスターは1~10

 

●拡張 VPC ルーティング

スタンダードなVPC機能の実施。

クラスターとデータリポジトリ間のすべての COPY(ロード) と UNLOAD(アンロード) トラフィックを強制。
VPC エンドポイント

全てのトラフィックVPCを経由するように強制される。

S3にはエンドポイント経由でプライベートな接続が可能。

トラフィックのログをとりたい場合などがユースケース
・NAT ゲートウェイ

別リージョンのS3、他のリソースにアクセスする場合に設定する
・インターネットゲートウェイ

AWS外のリソースにアクセスする場合に設定する

 

クラスターセキュリティーグループ

接続を許可するIPを設定する。

デフォルトはリストが空であるため,アクセスを一切受け付けない。

 

●構成

複数ノードによる分散並列実行が大きな特徴

複数ノードの固まりをRedshiftクラスタと呼ぶ。

クラスタには1つのリーダノードと複数のコンピュートノードから構成されている。

・リーダノード

SQLクライアントやBIツールからの実行クエリを受け付けて、クエリの解析や実行プランを作成する。

コンピュートノードの数に応じて最適な分散処理が実行される。

コンピュートノードからの処理結果を受けてレスポンスを返す役割を担います。

リーダノードはクラスタに1台。

・コンピュートノード

リーダノードからの実行クエリを処理するノード

各コンピュートノードはストレージとセットになっている。

コンピュートノードを追加することでクラスタのパフォーマンスが向上する。

・ノードスライス

Redshiftが分散並列処理をする最小の単位

コンピュートノードの中にさらにリソースを分割してスライスという単位を構成する。

・ゾーンマップ

ブロックという単位でデータが収納されているその最小値と最大値を保存する。

この仕組みを活用することでデータ検索条件に該当する値の有無を効率的に判断できる。

 

●Redshift Spectrum

・S3に置かれたデータを外部テーブルとして定義できる。

・Redshift Spectrum上に保存されているデータに対してRedshiftと同様に分析を行うことができ、

これまで連携していたBIツールの利用も既存のRedshift同様に使用できます。

・RedshiftとS3を組み合わせたクエリも可能

・アクセス頻度が低いデータをS3に置くことも可能。

・Redshift×S3の場合のみ使用

 

●データ連携

○Redshift「へと」データを移動させるサービス

・S3 

最も頻繁に使われるデータ連携先であり、S3からデータ を取得してRedshiftで解析することも可能であるし、S3 内部のデータ解析を直接実行することも可能 

Kinesis 

Kinesis data Firehoseを利用してストリーミングデータ の格納先としてRedshiftを指定してデータを保存して、解析に利用することが可能

・RDS 

RDSとの直接接続はないが、AWS Data PipelineやDMS を利用してデータ移行を実施可能 

・DynamoDB 

DynamoDBからRedshiftにデータコピーを実行可能 

・EMR 

EMRからRedshiftにデータコピーを実行可能

 

○Redshift「から」はQuickSightを利用したデータ可視化に加え、S3 へとデータ抽出も可能

Amazon QuickSight 

Redshiftに接続して、データの可視化を実施可能 

・S3 

UNLOADコマンドを実行することで、RedshiftからS3へ とデータを抽出することが可能 

Amazon Machine Learning 

RedShiftを機械学習の学習データとして設定して利用可能 

・RDS 

直接に連携はできないが、PostgreSQLの機能を利用して データをRedShiftからRDSと連携可能

 

●用語

○データレイク

あらゆるデータをそのままの形で保存しておくデータの格納庫

変換しないで生データを保存

事前に目的を定義せず、ユーザー がデータ群から新たな価値を抽出 しデータを解釈・活用・収集

・データレイク型のデータ処理基盤

データ形式/ 様々な種類の データを蓄積してあとから加工しBIツールで可視化する

 

○データウェアハウス(DWH)

利用用途に応じたデータを溜めて活用する。

利用者がデータ分析/レポート内 容などの利用目的を事前に特定し 構築、収集

データの抽出・集約に特化したBIデータ 分析用のデータベース

レスポンス重視でデータ抽出・集計が速 いが、更新・トランザクションは遅い

・データウェアハウス型のデータ処理基盤

データをETLしてDWHに保存してBIツールで可視化する。

 

○並列処理

一つのタスクをより小さなサブタスクに細分化し、

複数のプロセッサを用いてこれらを並列に処理することによって全体の処理効率向上を図る手法です。

DynamoDB

●概要

完全マネージド型リージョンサービスのNoSQLデータベースサービス

高可用性(単一障害点を持たない構成でデータを 3箇所のAZに保存)

キーバリュー型でデータを簡易に操作することができる。

ストレージ無制限。

☆デフォルト設定でAuto Scaling を有効にした状態で書き込み容量ユニットと読み込み容量ユニットを増減させるもの

コスト面で常に高スループットにする必要がないのもメリット

aws backupを使用してのバックアップ設定も可能

 

●料金

キャパシティーユニット+ストレージ容量+データ転送量

・オンデマンドキャパシティー

DynamoDBに対してデータを読み書きした回数に対して料金が発生するプランです。

データを読み書きする回数を予測して、請求オプションを指定する必要がないため、

データを読み書きする回数が予測できない場合におすすめです。

・プロビジョニング済みキャパシティー

DynamoDBに対する1秒あたりのデータ読み書き回数を指定し、

指定した回数を元に料金が算出されるプランです。

リザーブキャパシティー

1年間もしくは3年間で選択可能

 

●キャパシティユニット

☆dynamoDBはストレージタイプの対応でスペックを向上されるのではなく、キャパシティの変更で操作する。

必要なスプープットを設定できる。

☆ダウンタイム無く変更可能

DynamoDBでは読み込みと書き込みのキャパシティをそれぞれユニットと呼ばれる単位で設定できる。

1ユニットの性能は以下である。

・書き込み(WCU):1秒間に最大1KBのデータを1回書き込むことが可能

・読み込み(RCU):1秒間に最大4KBのデータを2回読み込むことが可能

なお、強い整合性の読み込みを利用すると、 2回が1回に半減する。

 

TTL機能

・該当するデータが有効期限を過ぎると、キャパシティユニットを消費せずに自動でデータが消える。

・データは48時間以内に削除される。

・データの読み込みまたは書き込みのトラフィックに影響を与えない

 

●出来ること、出来ないこと

・出来る事

キーに対するバリュー(値)の CRUD操作

簡易なクエリやオーダー

例えば数万人以上が同時アクセスして処理が必要になるアプリケーションのセッションデータ処理など

・出来ない事/向いていない事

JOIN/TRANSACTION/ COMMIT/ROLLBACKは不可

詳細なクエリやオーダー(データの検索や結合処理などには向いていない) 

大量のデータ読み書きにはコストがかかる。

 

●整合性モデル

デフォルトで結果整合性モデルであり、一部処理に強い整合性モデルを利用している

・Write

少なくとも2つのAZでの書き込み完了が確認とれた時点で完了

・Read

デフォルト:結果整合性モデル 

最新の書き込み結果が即時読み取り 

処理に反映されない可能性がある 

オプション:強い整合性モデル 

GetItem/Query/Scan

では強い整合性のある読み込みオプションが指定可能

 

●パーティショニング

大量データを高速処理するために分散処理を実施している

ひとつのテーブルを読み込むのに3つのAZにパーティションを使用する。

3つを並列で行うため、高速な処理が可能。

 

ユースケース 

ビッグデータ処理向けか大量データ処理が必要なアプリケーション

トランザクションがいらないゲームのDBに利用する

☆できることできないことから考える。

ビッグデータ

大量のデータを収集・蓄積・分析するための データベースとして活用 

Hadoopと連携してビッグデータ処理が可能

・アプリケーション

大規模サービスでのデータ高速処理が必要なアプリケーション向けに活用 

多数のユーザーが一度にアクセスするようなア プリケーションのデータ処理

☆理由はパーニショニングで高速処理が可能だから。

・ユーザー行動 データ管理

ユーザー情報やゲーム、広告などのユーザー行動 

データ向けDB ユーザーIDごとに複数の行動履歴管理

・バッグエンド データ処理

モバイルアプリのバックエンド/バッチ処理の ロック管理/

フラッシュマーケティング/スト レージのインデックス

 

●データベースの選択基準

JOIN,TRANSACTION,COMMIT,ROLLBACK,検索,大量読み書き

がその案件で起きるか、起きたらどのぐらい起きるのか

それを考えてDB選択する。

 

●DynamoDBのベストプラクティス(AWS推奨)

・アイテムのサイズを小さくする。
・DynamoDBにシリアルデータを格納し、

データ/時間に基づいたアクションが必要な場合は、日、週、月で別々のテーブルを使用する。
・アクセス頻度の高いデータと低いデータを別々のテーブルに格納する。
・可能であれば、より大きな属性値を圧縮する。
・400KB以上のオブジェクトはS3に格納し、DynamoDBではポインタ(S3 Object ID)を使用する。

 

●テーブル設計

DynamoDBはテーブル単位から利用が開始され、テーブル(table)→項目(item)→属性(attribute)と設計する。

テーブルを作成する→その中に項目を作成しその中に属性が存在する

テーブルの中にJSONが入っているイメージ。

{

"Id": 101,

"ProductName": "Book 101 Title",

"ISBN": "111-1111111111",

"Authors": [ "Author 1", "Author 2" ]

}

 

●キー・インデックスについて

◯プライマリーキー

2種類のプライマリキーが存在する。

・プライマリーキー単体

・複合キーテーブル

パーティションキー+ソートキーで組み合わせが構成されたもの

パーティションキーはRDSでいうID

ソートキーを登録することで検索しやすくなる。

それだけでは高度な検索要件を満たせないのでグローバルセカンダリインデックスとローカルセカンダリインデックスが存在する。

・グローバルセカンダリインデックス

テーブルに定義されているパーティションキーとソートキーとは別のパーティションキーとソートキーを定義して別テーブルを作成する。

・ローカルセカンダリインデックス

パーティションキーはそのままに別のソートキーを定義して別テーブルを作成する。

参考: https://moyamoya.space/tech/aws/424/

 

●テーブル操作

・GetItem:ハッシュキーを条件に一定の項目 (アイテム)を取得 

・PutItem:1件のアイテムを書き込む 

・Update:1件のアイテムを更新 Delete 1件のアイテムを削除 

・Query:ハッシュキーとレンジキーにマッ チする項目を取得(最大1MB) 

Scan テーブルを全件検索する(最大1 MB) 

・BatchGet:複数のプライマリーキーに対して マッチする項目を取得

 

●DynamoDB Streams

DynamoDBで行われた直近24時間の追加、更新、削除の変更履歴を保持する機能。

24時間経過で消される。

☆変更をトリガーに処理を実行することが可能。

クロスリージョンレプリケーションもここでする

 

DAX

DAXはDynamoDBにインメモリキャッシュ型の機能を付加して高速化を実現。

DynamoDBへの直接的な操作が減るためコストの削減に繋がる。

IAMでのアクセス制御が可能。

VPCで操作。

3 つのノードの DAX クラスターで開始し、その後ノードを追加することによってキャパシティーを追加できる。

 

●グローバルテーブル

リージョン間で同期されるマルチマスターテーブルを作成可能 

・DynamoDBの性能のまま、世界中で複数のリージョンにエンドポイントを持 つことができる 

・読み書きのキャパシティに加えて、クロスリージョンレプリケーションの データ転送料金に課金される 

・オプションで実施できた強い整合性は不可

 

●用語

○KVS (キーバリュー型)

シンプルなデータ構造にすることで高速処理を可能にしたDB

分散して、シンプルなオペレーションを 高速に実施できる

高速に処理することに特化したDB

SQS

●SQS

タスクのトリガーとなるキューを複数管理することで、ワーク ロードの並列実行を実現するキューイングサービス

☆キューによってシステム処理を分散させて負荷分散を可能

AWSリソースの水平方向のスケーリングに役立つ。

VPCエンドポイントを使用してオンプレとの接続も可能。

 

●料金

100万リクエストあたり0.40USD(標準)

 

●SQSキューの特徴 

○メーセージの制約

☆メッセージ数は無制限に利用可能 

・メッセージサイズは最大256KB 

・ただし、拡張クライアントライブラリーを利用すると2GBまで のメッセージのやり取りが可能となる。 

・コンシューマー側では一度に10件までメッセージを受信可能 

・発行したメッセージは取り消し不可 

・配信ポリシーによるキューの送信の再試行を実施する

○メーセージの保持期間

・ SQSのキューメッセージは保持期間の間は保存される。 

・デフォルト4日間(最小60秒~最大14日で設定可能) 

・メッセージ保持期間の間はメッセージを保持するが、超過する とメッセージを削除する。 

・アプリケーション上でメッセージを削除する処理を実施しないと、期間を超過するまでキューが滞留してしまう。

・DeleteMessageAPIを使ってメッセージを削除しない限り、保持期間中のメッセージは処理後も保持される。

 

●標準キューとFIFO

○標準キュー

・メッセージが少なくとも1回配信される方式であり、キューには重複が発生する可能性がある。 

・1秒あたりのトランザクション数はほぼ無制限 

ユースケース:アプリケーションが1回以上に順序が正確ではなくても配信されれば良いケースで利用する

FIFO

・高スループットモードが存在する。(メッセージグループごとで処理をする。)

・配信順番を守る。 

☆メッセージが1回だけ配信され、コンシューマがプロセスを処理して削除するまで使用可能なキューの状態を保つため、 キューに重複がない。 

・1秒あたり300トランザクションに制限 (標準より低い)

ユースケース:操作やイベントの順序が重要である場合や、 重複を許容できないユースケースに利用する。

 

○ロングポーリングとショートポーリング

・ショートポーリング

リクエストを受けるとメッセージの有無に関わらず即レスポンスを返す。

・ロングポーリング

メッセージがない場合設定されたタイムアウトぎりぎりまでレスポンスを返さない。

メッセージ受信待機時間は0秒から20秒で設定

 

○可視性タイムアウト

メッセージの設定

処理中のメッセージを他のコンシューマーから見えない状態にして、重複処理を避けるための設定。

 

●キュータイプ

○遅延キュー

キューへの新しいメッセージの配信を数秒間「遅延」させることができる機能(0秒から15分で設定) 

可視性タイムアウトとの違いは、キューが発行された直後から 見えなくなるということ。

またキュー全体に効果がある。 

○優先度付きキュー

キューの処理順序に優先度をつけることができる。

 これにより、優先対応があるタスクを最初に処理するように ワークフローを設定できる。

○デッドレターキュー

このキューは、正常に処理 (消費) できないメッセージを別の キューへと移動させる。 

処理不能なキューが蓄積されるのを防ぎつつ、処理できなかっ た理由を後で解析できる。

 

●SQSの識別子

○キューURL 

キューに割り当てられるURL

○メッセージID 

メッセージに対して割り当てられたID

○メッセージグループ ID(FIFOのみ)

特定のメッセージグループに属するメッセージID

同じメッセージグループに属するメッセージは、メッセージ グループに相対的な厳密な順序で1つずつ処理される、 

 

●メッセージグループIDによるグループ化(FIFOのサービス)

FIFOキューはキューを順番通り流す。

A1,C1,A2,C2,A3,C3→コンシューマー

それをグループ化する

A1,A2,A3→コンシューマー1へ

C1,C2,C3→コンシューマー2へ

グループに分けて順番通りに処理をする。

 

●キューの詳細設定

○メッセージ 重複排除ID(FIFOのみ)

・送信されたメッセージの重複排除に使用するトーク 

・同一の重複排除IDが設定されたメッセージをキューへ送っても5分間の間は受付けられないように設定できる。 

・個別のメッセージグループではなくキュー全体に適用される。

○暗号化

KMSを使用して、 暗号化 送信データを暗号化する。

○メッセージタイマー

個々のメッセージの遅延を設定できる。

個々のメッセージのメッセージタイマー設定はキュー全体よりも優先される。

デフォルト (最小) 遅延は 0 秒です。最大値は 15 分。

・遅延キューとの比較

遅延キューはキューの遅延

メッセージタイマーはメッセージの遅延

 

●アクセス管理

○IAMポリシー

・一般的なIAMポリシーによるSQSリソースへのアクセス許可 を設定する。 

• SQSサービスへのアクセスを制御する。

○SQSポリシー

• 他のアカウントとSQSキューを共有する許可が可能 

• 他のサービスがSQSキューにメッセージを送信することを許可するなどの設定が可能

 

●SQSのバッチアクション

バッチアクションは1 回のアクションで複数のメッセージを操作するなどのバッチ処理が設定可能

 

●用語

・プロデューサー

キューにメッセージをプロデュース(提供)する側のアプリケーション

・コンシューマー

キューに溜まったメッセージをコンシューム(消費)する側のアプリケーション

・Pub/Subメッセージング

パブリッシャー(プロデューサー)がメッセージを発行・送信し

サブクライバー(コンシューマー)がメッセージを受信するシステムのことをいいます。

サブクライバー(コンシューマー)は複数を紐づけることも可能です。

VPC

VPCの料金

無料。NATはかかる。

 

●ネットワークASLとセキュリティグループ

○ネットワーク ACL 

☆サブネットに適用され、初期設定がインバウンド、アウトバウンド全て許可。

☆ルールは番号で評価されており、『小さい順』から評価されていく。

100番が全てのトラフィックを許可。

どの許可ルールにもマッチしない場合は✳︎DENYが存在して拒否される。

外部からパブリックサブネットに攻撃を受けている時にサブネット単位でブロックする。

インバウンド、アウトバウンドで設定ができるためステートレス

 

○セキュリティグループ

 EC2 、ELB、RDS等のインスタンスにセットされ、

☆初期設定ではインバウンドが全て拒否、アウトバウンドが全て許可。

SSHの設定を2つしたのならより広い範囲の設定が反映される。

通信をアウトバウンドで許可したならインバウンドも許可される。

CIDRでのアクセス制御が可能

インバウンドもアウトバウンドも同じ設定となるためステートフル

 

○セキュリティグループのソースにセキュリティグループ

プロコトル指定後、ソースを指定してCIDRブロックが記載できるほかに、

「セキュリティグループそのもの」を送信元として記載できます。

ENIにセキュリティグループが関連付いているため、

☆送信元セキュリティグループに関連付けられたネットワークインターフェイスからのトラフィックが許可される。

そのためそのセキュリティグループを設定されているインスタンスからのみ設定が可能。

パブリックIP(EIPは固定)は可変である。

auto scaling時に手動で設定などはしていては話にならないため、この設定を行う。

 

○使い分けのベストプラクティス

EC2インスタンス間のトラフィック制御にはセキュリティグループが適しています。

セキュリティグループで対策していって大きなところはネットワークACLを使用する。

 

VPCDNS

DNS Hostname

有効にすると起動されるインスタンスにパブリックDNSホスト名が付与される。

Route 53 Resolver サーバーが名前解決してくれるためDnsSupportもオンにする。

・DnsSupport

Route 53 Resolver サーバー

 (パブリック DNS ホスト名を IP アドレスに解決します) が有効になる。

 

● Direct Connect

※APN=AWS Partner Network(AWSが契約している企業)

オンプレ環境から専用線を返してDirect Connectロケーション(ユーザが契約したキャリアとAWSが接続する場所)に接続してAWSへプライベートに接続するサービス

これはAWSへの申請と設定などが必要不可欠

ポートあたり1G/10Gbps

 

○接続方法

・Direct Connectロケーションに自身で機器を設置する場合

ハウジングでルーターなどの機器を設置する
・Direct ConnectロケーションからAPNパートナーの専用線で接続する場合(これが多い)
・APNパートナーの閉域網(IP-VPN網、モバイル網等)経由で接続する場合です。

複数拠点からAWSクラウドに接続することができます。

 

○Direct Connect gateway

Direct Connectを契約してDirect Connect GatewayをいずれかのAWSリージョンに作成すると、

AWSの全リージョン に複製され、相互接続できる。

AWSのプライベートネットワークを経由するので、高速でセキュア

☆同一リージョン内に複数の VPC がある場合は Transit Gatewayを選択

☆ひとつのDirect Connectロケーションを指定して複数のリージョンにアクセスする

参考:

https://dev.classmethod.jp/articles/direct-connect-gateway/

 

○VIF

物理接続の中に、AWSリソースにアクセスするための論理インターフェイスをひく必要があり、これをVIF

Public VIF=AWSのパブリックサービスへパブリックIPを介した接続を提供する

Private VIF=VPCへプライベートアドレスを介した接続を提供する

Transit VIF=Direct Connect Gateway経由でTransit Gateway への接続を提供する

 

○耐障害性の高いソリューション

複数のDirect Connectロケーションを使い、1つのロケーションに問題があった場合の対策が可能。

 

VPNとDirect Connectの比較

VPNの方が安く素早く利用できるが、信頼性や品質は専用線が勝る

 

全体参考:

https://dev.classmethod.jp/articles/re-introduction-2020-direct-connect/

 

VPCエンドポイント

グローバルIPを持つAWSサービスに対して、VPC内から直接アクセスするための出口

Gateway

ルートテーブル(ルーティング設定)を書き換えてのゲートウェイ経由でサービスへアクセスする。

アクセス制御はアクセスポリシーで行う

S3とDynamoDBのみ

・PrivateLink型(インターフェイス型)

PrivateLink の実体はVPC内のENI(Elastic Network Interface) になります。

PrivateLink自体がIPアドレスを持ってVPCの中にエンドポイントが出来ます。

アクセス制御はセキュリティーグループで行う

S3・DynamoDB『以外』のAWSプリンシパルサービスや独自サービスにアクセス可能

 

VPC Peering

異なるVPCを接続することが出来ます。

☆異なるAWSアカウント間のVPC間を接続可能

一部のリージョン間の異なるVPC間の接続も可能

VPC内でのEC2アクセス間での通信が可能

VPC-B   VPC-C

  ↓    ↑

            VPC-A

上記のピアリング接続が存在したとして、B-C間の接続はできない。

オンプレ、AWSサービスでも同様。

 

VPC フローログ

ネットワークトラフィックをキャプチャし、データをCloudWatch Logs、S3でモニタリングできるサービス

・リアルタイムのログストリームはキャプチャされません。

・ネットワークインタフェースを送信元/送信先とするトラフィックが対象

VPC、サブネット、あるいはネットワークインターフェイス(ENI)のいずれかに作成します

・他の AWS のサービスによって作成されたENIのフローログを作成可能

☆異なるAZまたは異なるアカウントでログを管理する際に使う。複数のvpcフローログを1つのs3バケットへ集約する。

 

●ENI(ネットワークインターフェイス

インスタンスがネットワークにアクセスするための情報が記載されている。

紐付いているVPC、サブネットなどが表示されている。

セキュリティグループもここに付与されている。

☆ネットワークインターフェイスにIPが付与されている。

そのためENIを2つインスタンスにアタッチするとプライベートIPが二つになる。

アタッチの呼び名

・実行中のアタッチ=ホットアタッチ

・停止中のアタッチ(ウォームアタッチ)

インスタンスが起動中のアタッチ(コールドアタッチ)

 

●Transit Gateway

https://recipe.kc-cloud.jp/archives/16886

Transit Gatewayは複数のVPCと複数のオンプレミス環境同士の連結を束ねる

中央ネットワークハブのような役割を果たしています。

 

●NAT Gateway

NATは1対1にプライベートIPをプライベートIPに変換している

NTAグローバルなIPをもつ必要が存在する。

NATは外部と通信するため0.0.0.0に構成する。

0.0.0.0/0はすべてのIPアドレスからの接続を許可する。

☆プライベートサブネットからインターネットへ接続(アウトバウンド接続)できますが、

インターネットからサブネットへのインバウンド接続はできません。

NATはパブリックサブネットにつける。

プライベートサブネットのアウトバウンド通信を制御するものなのでパブリックサブネットにつける。

パブリックモードの場合はElasticIPを割りあてることが可能

☆プライベートモードは他のVPCやオンプレ環境に届ける役割で使用される。

 

●Virtual Private GatewayとCustomer Gateway

 

・Virtual Private Gateway

AWS側のVPCの出入り口

☆Direct Connectと組み合わせて使用することで、Direct Connect回線を通過するすべてのデータを暗号化することができます.

Virtual Private GatewayVPCにアタッチしてルートテーブルにアタッチする。

 

・Customer Gateway

☆オンプレ側のゲートウェイ

☆オンプレミス環境のルーターのIPやAS番号、暗号化のための証明書を記入する画面が出てくる。

AWSで設定する。

 

ゲートウェイ参考資料

https://blog.serverworks.co.jp/aws-gateways-1

 

●ElasticIP

・料金が発生しない場合

起動しているEC2インスタンスで、EIPを1つだけ使用している場合は料金が発生しない。

☆ 1つ目のEIPのみが無料、2つ目以降は有料となる。

関連付けたEC2が動作中は無料、動作していなければ有料。

EC2に割り当てしなくても料金は発生する。

最大5個まで取得可能。

・IPフローティング

パブリックIPの付け替えを自動で行う機能

数秒のダウンタイムが起きる。

AZを超えて設定可能

EIP付け替えはAPIで行えるため、これか監視ソフトと組みあわせて、自動化を行うこともできる。

 

●IPの基礎(復習)

IPアドレスは重複の許されない32ビットデータ

IPの利用範囲は0.0.0.0〜255.255.255.255

10進数で明記

255の理由は8桁2進数のMAX値

2進数32ビット 4*8

 

サブネットマスク(CIDR)

AWSVPC内で設定できるCIDR範囲として、/16(65536個)から/28(16個)までが利用可能

☆外部のIPを指定する場合は/32を指定して一意のものとする

サブネットではネットワーク部を変える。プライベートIPをEC2等に振り分ける。

○概要

IPアドレス(10.0.0.0)+サブネットマスク(/16)がIPの範囲を決める。

10.0.1.0/16と10.0.1.0/24はサブネットが違うためネットワークの範囲が違う。

・10.0.1.0/8の場合

10.のIPアドレス部のロックして他の数だけプライベートIPをロック

・10.0.1.255/24の場合、

10.0.1. までロックされているため、256のプライベートIPが使用可能

10.0.1.    までがサブネットマスクに固定されているネットワーク部

          . 255が利用可能なホスト部

 

●用語

フォールトトレランス=問題が発生した時も常に動く仕組みを構成すること

静的IPアドレス=常に変化しないIPアドレス

EBS

●概要

基本は1対1でEC2にアタッチする。

他のAZのEBSにはアタッチできない。他のインスタンスへ付け替えは可能。

1つのebsに複数のec2は使えないが、プロビジョンドIOPSのみマルチアタッチ機能が存在して、同時アタッチも可能ではあるが制約が多く限定的な用途に留まる。

・拡張

ボリュームタイプの変更が可能。

プロビジョンドIOPSへの変更は最大24時間のダウンタイムが存在する。

☆容量は拡張はできるが縮小はできない。

 

●料金

プロビジョニング(用意)した容量 (GB/月) で決まり、お客様がそのストレージを解放するまで毎月料金が発生

 

●EBSボリュームをアタッチする流れ

ボリュームを作成してボリュームをアタッチする。

ファイルシステム(記憶装置に保存されたデータを管理)の作成してマウントをする。

 

●ボリュームステータスチェック

 5 分ごとに自動的に試行され、成功または失敗のステータスを返します。

ボリュームのデータが潜在的に不整合であると Amazon EBS が判断した場合、

デフォルトでは、アタッチされたすべての EC2 インスタンスからそのボリュームへの I/O が無効になります。

・impairedg

チェック『が』失敗

・insufficient-data

ボリュームチェックがまだ実行中

・warning

ボリュームのパフォーマンスが想定を下回っている

 

インスタンスストアとEBSの違い

インスタンスストアボリューム

EC2に直接アタッチされたブロックデバイスストレージの形式

☆EC2の一時的なデータが保持され、EC2の停止・終了と共にデータがクリアされる 

無料

・Elastic Block Store (EBS) 

EC2インスタンスにアタッチして利用できるブロックレベルのストレージ

ネットワークで接続されたブロックレベルのストレージでEC2とは独立管理 

EC2を終了してもEBSデータは保持可能 

SnapshotをS3に保持可能

別途EBS料金がかかる。

 

●EBSのバックアップ方法

EBSはスナップショットでバックアップが可能

普段はS3standardに保存されているがアーカイブに保存することで安く保存が可能

☆保存方法は最初に完全バックアップをしてその後増分をバックアップする

定期的なスナップショットをDLMで取得できる

スナップショットショット自体はリージョンに保管されるので他のリージョンで使用したい場合は、

スナップショットをコピーする。

 

・DLM

スナップショットの自動化が可能。

Amazon EBS ボリュームをバックアップする為のSnapshotの生成 → 保存 → 削除の

ライフサイクルを自動化

時間単位でのスナップショットを取得できる。

 

●EBSの削除

・DeleteOnTermination 属性 

EC2削除時にEBSを存続させるべきか、削除すべきかを判断する。

デフォルトでは、有効化で「削除」される。

 

●EBSの暗号化

以下が暗号化される。

・EBSに保存されるデータ
・EBSとEC2のインスタンスの間で移動するデータ
・EBSから作成されるスナップショット
・暗号化されたスナップショットから作成されたEBS

KMSを使用することで可能

◯やり方

・KMSキーの作成

・EBSのスナップショットの取得

・スナップショットの暗号化を行う

暗号されたスナップショットから新規EBSボリュームを作成

・暗号化されたEBSをES2にアタッチ

 

ミラーリング

2つ以上のEBSボリューム間でミラーリングすることで

回復性が高いデータ冗長化を達成することが可能

 

●RAID0 RAID1

・RAID0

それぞれのハードディスクに別の内容を書き込むやり方

書き込み速度2倍

・RAID1

それぞれのハードディスクに同じ内容を書き込むやり方

安全性2倍

 

インスタンスストア

EBSより高IOPS、高スループット、低レイテンシーのため、高いI/Oパフォーマンスが必要な一時ストレージに最適

・NVMe SSD

サイズ 50GB~60TB

最大IO性能 数百万のIPOS

・HDD

サイズ ~48TB

最大IO性能 非常に高いスループット

 

●ボリュームタイプの種類

○汎用SSD(gb2 gb3)

最も一般的なSSDボリュームタイプ

レイテンシーを要求するアプリ

ユースケース:小規模ー中規模のDB 開発環境

 

○gb2(高い)(SAAでは指定がない場合デフォルトとする。)

・100GBにおける値

IOPS ベース300IPOS 最大(バースト時)3000IPOS

スループット128MiB 秒

・最大値

サイズ 1GB~16TB

最大IO性能 16,000IPOS

最大スループット 250MiB 秒 

 

○gb3(安い)

・100GBにおける値

IOPS ベース3000IPOS

スループット128MiB 秒

・最大値

サイズ 1GB~16TB

最大IO性能 16,000IPOS

最大スループット 1000MiB 秒 

 

○プロビジョンド IOPS (io1 io2 io2Block Express)

最も高性能なSSDボリュームタイプ

IOPS負荷が高い、高スループットのが必要な場合のユースケース

プロビジョンド IOPS のみベースラインとバースト性能は指定することが可能。

コスト最適よりも性能が優先される場合には、このボリュームタイプを選択

io1 io2 io2Block Expressが存在

ユースケース:I/O負荷の高いデータベースのデータ領域

・io1 io2

サイズ 4GB~16TB

最大IO性能 64,000IOPS

最大スループット 1,000MiB 秒

・io2Block Express

サイズ 4GB~64 TB

最大IO性能 256,000IOPS

最大スループット 4,000MiB 秒

 

スループット最適化

スループット重視のHDDボリュームタイプ

ルートボリュームには使用不可

ユースケースビッグデータ処理、ログ解析、バッチ処理用大容量インプットファイル

サイズ 500GB~16TB

最大IO性能 500IOPS

最大スループット 500MiB 秒

 

○コールドHDD

最も低コストなボリュームタイプ。

ルートボリュームには使用不可

ユースケース:アクセス頻度の低いデータのアーカイブ

シーケンシャルワークロード(連続した領域に読み書きすること)

サイズ 500GB~16TB

最大IO性能 250IOPS

最大スループット 250MiB 秒

 

●用語

I/O=Input/Outputの略で「入出力」

IOPS=1秒間のストレージ書きこみ読みこみ性能

スループット=一定時間でどれだけデータを転送できたか。

ルートデバイスボリューム=インスタンスを起動し実行するためのOSが割り当てられている

ルートデバイスボリュームがEBSなどという言い回し