データベースについて
データベースの基礎
データベースは関連したデータの形式を揃えて収集、整理して検索などの操作やデータ管理を実行するシステム データベースを実現したシステムをDBMS（データベースマネジメントシステム）という 基本的なデータベースはテーブルという形式でデータを格納している
データベースは追加・参照・更新・削除などのデータ操作を容易に実行するソフトウェアやデータモデルと一体
データベースとストレージ
ストレージはデータベースの記憶装置を構成する１つの要素
◾️ストレージ ・コンピュータの主要な構成要素の１つでデータを永続的に記憶する装置
◾️データベース ・データベース内のデータを保存する装置はストレージであるがデータベースそのものではない ・ストレージ＋データを管理、操作するデータベースソフトウェア
データベースの役割
データベースはデータ操作を異常なく実行でき、データを安全に保護しつつ、保存、操作ができる仕組みを提供している
【データ操作にかかる様々な課題】 ・システムがクラッシュした時にデータが消えないか ・データを誤って削除してしまった場合に対処できないか ・データ抽出に誤りが発生しないか ・２人が同時に同じデータにアクセスした際にどうするか ・大量のデータをうまく検索できないか
データベースの役割を支える仕組みを理解する ・トランザクション データベースをある一貫した状態から別の一貫した状態へ変更する１つの処理の束のこと
・データモデル 実世界におけるデータの集合を、DBMS上で利用可能な形に落とし込むためのモデル
トランザクション
データベースをある一貫した状態から別の一貫した状態へ変更する１つの処理の束のこと
・同時アクセスした場合にうまく処理する ・データ処理に失敗したら元に戻してくれる ・システムがクラッシュしてもデータを保護する
トランザクション：ACID
ACIDは信頼性のあるトランザクションシステムの持つべき性質のこと
◾️Atomicity（原子性） トランザクションが「全て実行される」か「１つも実行されない」のどちらかの状態になるという性質
◾️Consistency（整合性） トランザクションの前後でデータの整合性が保たれ、矛盾のない状態が継続される性質
◾️Isolation（独立性） トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質
◾️Durability（耐久性） トランザクションが完了したら、その結果は記録されクラッシュしても失われることがないという性質
トランザクション：耐久性
データを更新する際にCOMMITする更新が反映されるが、COMMITされないとデータがロールバックして保護する
トランザクション：整合性
同時に複数人がアクセスした場合などにデータ整合性を維持する必要がある 結果整合せや強い整合性など
データモデル
データベースには様々なデータモデルが存在し、利用目的に応じて使い分ける
・リレーショナルモデル ・グラフモデル ・キーバリューストア ・オブジェクト ・ドキュメント ・ワイドカラム ・階層型
データベースはリレーショナルDBか非リレーショナルDBかの大きく２種類ある これまでのDB：リレーショナルDB ビックデータ向けDB：NoSQL
リレーショナルDB
データベースの基本はリレーショナルDBシステム（RDBMS）
◾️概要 ・データ間の関係性が定義されたデータを取り扱う一般的なDBシステム ・列と行がいくつかのテーブルで定義されていて、テーブル間のリレーションが設計される ・データ操作にSQLを利用
◾️利用データ ・会計データ / 顧客データといった構造化データ
NoSQL
IoTと同様にビックデータ解析にはNoSQLDBを利用する
◾️概要 ・リレーショナルデータ構造を持たずSQLを利用しないDBの総称 ・ただし、現在は似たクエリ処理を適用したモデルもある
◾️利用データ ・構造化されていないKeyとValueのみ（ID番号に１列に全データを格納）のKVSデータ ・動画 / 画像 / ドキュメントなどの非構造化データ ・XML / JSONなどの半構造化データ
キーに対するデータ形式の格納方式の違いで様々なタイプのNoSQLが存在する
◾️キーバリューストア ・キーに対してバリュー（値）を入れる単純な構造 ・高速なパフォーマンスと分散型拡張に優れている ・データ読み込みが高速
◾️ドキュメントデータベース ・キーに対してバリューではなく、JSONやXMLなどのデータを格納 ・複雑なデータ構造を扱うアプリで生産性高く柔軟に開発する
◾️ワイドカラムストア ・列指向とも呼ばれキーを利用するがデータはカラム（列）で管理する ・非構造データを大規模に格納することを目的にしている ・行ごとに任意の名前のカラムを無数に格納できる
◾️グラフデータベース ・グラフ理論に基づき、データ同士の関係をグラフで相互に結びついた要素で構成される ・RDBと比較して高速横断検索が可能
ビックデータ活用
データの特徴に応じて利用するデータベースを選択する
◾️DWH（構造化データ） 売上分析 / 財務分析など目的に沿った業務データ分析
◾️アーカイブ（構造化アーカイブデータ） データウェアハウスだけでは不可能だった長期過去データを活用した業務データ分析
◾️半構造化DB（半構造化データ） IoTデータなどの膨大なビックデータを活用した分析 / 人工知能構築
◾️非構造化DB（非構造化データ） 非構造化データを利用したデータ分析 / 人工知能構築
リレーショナルDB（RDB）
業務システム向けのDBの基本はリレーショナルデータベース ◾️概要 ・業務システムなどで最も頻繁に利用されるオペレーション用のデータベース ・利用者はSQLなどのクエリ言語でデータ操作を実施
◾️アーキテクチャ ・テーブル間のリレーションが定義されたデータモデル ・行指向で１つの行をデータの塊として取り扱う
◾️利用データ ・会計データなどの業務系の構造化データ
データウェアハウス（DWH）
構造化データを利用した経営分析向けのデータベース
◾️概要 ・データの抽出、集約に特化したBIデータ分析用のデータベース ・読み込みデータ構造を予め設計して、加工してから利用分のデータを蓄積 ・レスポンス重視でデータ抽出、集計が早いが、更新、トランザクションは遅い
◾️アーキテクチャ ・データをパーティショニングして、複数ディスクから読み込む ・列指向でデータを格納
◾️利用データ ・会計データなどの業務系の構造化データを分析用に加工し、BIで利用 ・KPI測定 / 競合分析 / アクセス分析など
分散型DB / データレイク
ビックデータやIoTデータを蓄積して高速処理を可能にするDBとストレージの組み合わせ ◾️概要 ・データ抽出に特化したDB ・分散してデータを保存しており、ビックデータの高速処理向け
◾️アーキテクチャ ・SQLライクなクエリで操作可能 ・INSERT / UPDATE / DELETEはない ・トランザクションはない ・データ書き込みは一括ロードまたは全件削除のみ
◾️利用データ ・ビックデータ
KVS：キーバリュー型
シンプルなデータ構造にすることで高速処理を可能にしたDB
◾️概要 ・分散してシンプルなオペレーションを高速に実施できるDB
◾️アーキテクチャ ・強い整合性を犠牲にして結果的な整合性を採用 ・分散向けのデータモデル / クエリの採用 ・トランザクション / 集計 / JOINなど不可
◾️利用データ ・大規模WEBサイトのバックエンドデータ（ユーザーセッション / ユーザー属性 / 事前計算データのキャッシュ） ・メッセージングシステムのデータ ・大規模書き込みが必要なIoTセンターデータなど
ワイドカラム型
キーに対してカラムを大規模に登録できるのがワイドカラム型
◾️概要 ・分散してシンプルなオペレーションを高速に実施できるDB ・データ取得する際にデータ結合しなくても済むように可能な限り多くのデータを同じ行に保持
◾️アーキテクチャ ・結果整合性を採用 ・キースペース、カラムファミリ、ロウ（スーパーカラム）、カラムの入れ子構造 ・SQLライクなデータ操作が可能 ・データ操作は挿入、削除、参照のみでデータ更新は挿入による上書き
◾️利用データ ・Facebook / Twitterなどソーシャルデータの位置情報データストレージ / リアルタイム分析 / データマイニング処理
ドキュメントDB
キーに対してドキュメント指向でXMLなどのデータを格納する
◾️概要 ・ドキュメント指向データベースでは、様々なデータ構造のドキュメントを混在して保存することができる
◾️アーキテクチャ ・JSON / XMLをデータモデルに利用 ・小規模データの同期集計処理が可能だが、バッチは不向き ・SQLライクなデータ操作が可能でKVSよりもクエリが豊富なため操作しやすい ・Shardingによるデータベース分散化
◾️利用データ ・半構造化データ（XML / JSON） ・大規模WEBのログ保管など ・オンラインゲームデータ ・カタログ管理
インメモリデータグリッド
KVSの仕組みをメモリを利用してより高性能にしたDB
◾️概要 ・大量のデータを多数のサーバーのメモリ上で分散して管理する技術 ・ミリ秒単位の高速の応答処理が可能
◾️アーキテクチャ ・データをメモリ上に置くことで高速なデータアクセスを実現 ・データを多数のサーバーで分散して管理
◾️利用データ ・金融の取引処理データでミリ秒以下の応答時間を実現
全検索型エンジン×分散DB
データの全検索エンジンであるElasticsearchは分散データベースと連携してデータ全検索処理が可能
◾️概要 ・全検索型のデータ検索エンジンで分散データベースと連携して検索データベースを構築 ・検索条件との関係性 / 関連性が高いデータを抽出して返す
◾️アーキテクチャ ・Elasticsearchは全文検索用のライブラリApache Luceneを利用したデータストア ・分析の柔軟性や速度が高く、分析 / 蓄積 / 可視化環境を容易に構築可能
◾️利用データ ・半構造化データ（XML / JSON） ・高可用な全文検索エンジンn ・サイト内データの検索 ・デバイス登録状況、配信状況のリアルタイム可視化などリアルタイムの検索要件 / 検索行動の可視化
グラフDB
グラフ構造でデータ間のつながりを検索、可視化するDB
◾️概要 ・グラフ演算に特化したDBでデータ間のつながり方を検索、可視化に利用
◾️アーキテクチャ ・グラフデータ構造を取るためRDB以上にスケールアウトができない ・レコード数が増えると検索にかかる時間と難易度が増大 ・ACID特性が担保されており、オブジェクト間の関連付けを簡単に表現できる
◾️利用データ ・最短経路検索 ・金融取引の詐欺検出 ・ソーシャルネットワークによるリレーション計算
分散OLTP（RDB）
オンライントランザクション処理（Online Transaction Processing）を分散化する次世代DB
◾️概要 ・グローバルに分散され、今日整合性を備えたデータベース
◾️アーキテクチャ ・リレーショナルデータベースの構造と非リレーショナルデータベースの分散スケーラビリティを兼ね備える ・高い可用性、高性能のトランザクションと強整合性が実現
◾️利用データ ・大規模な業務データ処理
DynamoDB
完全マネージド型のNoSQLデータベースサービス
・ハイスケーラブルで無制限に性能を拡張できる ・負荷が高くなっても応答時間が低下しない低レイテンシー ・高可用性（SPOFなしでデータは３箇所のAZに保存） ・マネージド型のためメンテナンスフリー：CloudWatchで運用
・プロビジョニングスループット テーブルごとにReadとWriteに必要なスループットキャパシティを割り当てる 例：Read：１００ / Wirte：１０００
・ストレージの容量制限がない データ容量の増加に応じたディスクやノードの増設は一切不要
DynamoDBのできること
キーバリュー（ワイドカラム型）でデータを容易に操作することが主要な役割
◾️できること ・キーに対するバリュー（値）のCRUD操作 ・簡易なクエリやオーダー ・例えば、数万人以上が同時アクセスして処理が必要になるアプリケーションのデータ処理など
◾️できないこと ・JOIN / TRANSACTION / COMMIT / ROLLBACKは不可 ・詳細なクエリやオーたー（データの検索や結合処理などには向いていない） ・大量のデータ読み書きにはコストがかかる
DynamoDBの整合性モデル
デフォルトで結果整合性モデルであり、一部処理に強い整合性モデルを利用している
◾️Write 少なくとも２つのAZでの書き込み完了が確認取れた時点で完了
◾️Read ・デフォルト：結果整合性モデル 最新の書き込み結果が即時読み取り処理に反映されない可能性がある
・オプション：強い整合性モデル GetItem / Query / Scanでは強い整合性のある読み込みオプションが指定可能
パーティショニング
大量データを高速処理するためにパーティションニングによる分散処理を実施している
ユースケース
ビックデータ処理向けか大量データ処理が必要なアプリケーション向けに利用する
◾️ビックデータ ・大量のデータを収集、蓄積、分析するためのデータベースとして活用 ・Hadoopと連携してビックデータ処理が可能
◾️アプリケーション ・大規模サービスでのデータ高速処理が必要なアプリケーション向けに活用 ・多数のユーザーが一度にアクセスするようなアプリケーションのデータ処理など
例えば大量に発生しうるWEB行動データやログ管理など ◾️ユーザー行動データ管理 ユーザー情報やゲーム、広告などのユーザー行動データ向けDB ユーザーIDごとに複数の行動履歴管理
◾️バックエンドデータ処理 モバイルアプリのバックエンド / バッチ処理のロック管理 / フラッシュマーケティング / ストレージのインデックス
テーブル設計
DynamoDBはテーブル単位から利用が開始され、テーブル→項目→属性と設計する
◾️テーブル DynamoDBはテーブルはデータのコレクションのこと 他のDBと同様にテーブル単位にデータを保存する
◾️項目（アイテム） 各テーブルの中に項目を作ってデータを作成する 項目間で一意に識別可能な属性グループとなる Personalという項目を作成すれば、名前やIDなどが属性として付属する
◾️属性 各項目は１つ以上の属性で構成される 属性はそれ以上分割する必要がない最小のデータ単位 例えばPersonal項目には、妙名といった名前の属性を設定する
インデックス
DynamoDBは暗黙的に設定するKVSにおけるKeyに値するものと、明示的に設定するキーがインデックスとして利用できる
◾️暗黙的なキー データを一意に特定するために暗黙的にキー（ハッシュキーやレンジキー）として宣言して検索に利用するインデックスで、１テーブルに１つ宣言する
◾️明示的なキー ・ローカル、セカンダリ、インデックス（LSI）はプライマリキーのタイプがハッシュキーやレンジキーの場合に追加で別のレンジキーを増やすようなイメージ １テーブルに５つ作成可能 / テーブル作成時に作成 ・グローバル、セカンダリ、インデックス（GSI）は別のハッシュキーを設定することができる 全データに対してグローバルに付与 １テーブルに５つ作成可能 / テーブル作成後に作成
プライマリキー
DynamoDBはハッシュキーとレンジキーという２種類のプライマリキーを利用する ◾️ハッシュキー ・KVSにおけるキーに相当するデータを一意に特定するためのIDなどのこと ・テーブル作成時に１つの属性を選び、ハッシュキーとして宣言 ・ハッシュ関数によってパーティションを決定するためハッシュキーと呼ぶ ・ハッシュキーは単独での重複を許さない
◾️レンジキー ・ハッシュキーにレンジを加えたものをレンジキーまたは複合キーと呼ぶ ・テーブル作成時に２つの属性を選び、１つをハッシュキーと呼ばれるキーとして宣言 ・２つの値の組合せによって、１つの項目を特定 ・複合キーは、単独であれば重複が許される
明示的に利用するインデックス
ハッシュキーやレンジキーだけでは検索要件が満たせない場合にLSIとGSIを利用する
◾️Local Secondary Index（LSI） ・レンジキー以外で絞り込み検索を行うインデックスで複合キーテーブルに設定できる ・複合キーによって整理されている項目に対して、別の規則でのインデックスを可能にする
◾️Global Secondary Index（GSI） ・ハッシュキーの属性の代わりになる ・ハッシュキーテーブルおよび複合キーテーブルどちらにでも設定可能 ・ハッシュキーをまたいで自由に検索できるようにする
DynamoDB Streams
DynamoDBテーブルに保存された項目の追加、変更、削除の発生時のリレくをキャプチャできる機能
◾️データの保存 ・過去２４時間以内のデータ変更の履歴を保存し、２４時間を経過すると消去される ・データ容量はマネージド型で自動的に管理
◾️データ保存の順番 ・操作が実施された順番に応じてデータはシリアライズされる ・特定のハッシュキーに基づいた変更は正しい順番で保存されるが、ハッシュキーが異なる場合は受信した順番が前後される可能性がある
DynamoDB Streamsのユースケース
データ更新をトリガーとしたアプリケーション機能やレプリケーションに活用できる
◾️クロスリージョンレプリケーション ・ストリームによるキャプションをトリガーとしてクロスリージョンレプリケーションを実施することが可能
◾️データ更新をトリガーとしたアプリケーション機能 ・データ更新に応じた通知書りなどのアプリケーション処理の実行など
DynamoDB Accelerator（DAX）
DAXはDynamoDBにインメモリキャッシュ型の機能を付加する DynamoDBにおいて高速なインメモリパフォーマンスを可能に
・インメモリキャッシュとして１桁台のミリ秒単位からマイクロ秒単位まで結果整合性のある読み込みワークロードの応答時間を短縮 マルチAZDAXクラスターは１秒間に数100万件のリクエストを処理できる ・DAXはDynamoDBを使用するAPIと互換性をもつマネージド型サービスであり、運用上そしてアプリケーションの複雑性を減少させて容易に導入可能
・読み取りの多いワークロードや急激に増大するワークロードに対して、DAXはスループットを強化したり、読み込みキャパシティーユニットを必要以上にプロビジョニングしないよう設計することで運用コストの節約できる
グローバルテーブル
リージョン間で同期されるマルチマスターテーブル作成可能
・DynamoDBの性能のまま、世界中で複数のリージョンにエンドポイントを持つことができる
・読み書きのキャパシティに加えて、クロスリージョンレプリケーションのデータ転送料金に課金される
・オプションで実施できた強い整合性は不可
オンデマンドバックアップ
パフォーマンスに影響なく数百TBのバックアップを実行可能 ・任意のタイミングで利用可能な長時間データ保存用バックアップ
・従来はデータパイプラインを利用して取得したバックアップを容易に実施できるようになった
Read / Writeiキャパシティオンデマンド
キャパシティ設定不要でリクエストに応じた課金設定を選択できるようになった
・トラフィック量の予測が困難な場合にリクエストの実績数に応じて課金 ・オンデマンドでRead / Write処理に自動スケーリングを実施 ・プロビジョンドキャパシティ設定への変更は無制限 ・オンデマンドへの変更は１日１回まで
Auroraの概要
クラウド時代の新しい分散型のリレーショナルデータベースとして誕生
・Amazonがクラウド時代に適したリレーショナルDBを１から考えて構築された新RDB ・その特徴はNoSQL型の分散高速処理とRDBとしてのデータ操作性を両立させたこと
MySQLと２.５〜５倍の性能を商用データベースの１０分の１の価格で提供する高性能・低コストDB
Auroraの特徴
高い並列処理性能によって大量の読み書きをするのに適したDB
・高い並列処理によるストレージアクセスによってクエリを高速処理することが可能 ・Auroraは大量の書き込みや読み込みを同時に扱うことができる ・データベースの集約やスループット向上が見込まれる ・ただし、すべてが５倍高速という訳ではなく、適用すべき領域を見つけて利用する
MySQL / PostgreSQLと互換性があり、同じ操作方法とそのコミュニティを利用することが可能
分散型で耐障害性と自己回復性を備えたスケーラブルな新しいタイプのフルマネージド型RDB
◾️耐障害性 / 自己回復性 ・３つのAZに２つのコピーを設置可能で合計６つのコピーを保持 ・過去のデータがそのままS3に継続的にバックアップ ・リストアも差分適用がなく高速 ・９９．９９％の高可能性、高耐久性
◾️スケーラビリティ ・１０GBから最大６４TBを提供するSSDデータプレーンを利用してシームレスに拡張可能 ・Auto-Scalingなどのクラウド独自のスケーラブルが可能 ・最大１５のリードレプリカを利用した高速読み込みが可能
Auroraサーバレス
予測困難なアプリケーションワークロードに対応したAuroraのオンデマンド自動スケーリング構成 ・自動に起動 / シャットダウン ・自動でスケールアップ / スケールダウン
AuroraグローバルDB
他リージョンに対する高性能なリードレプリカ作成機能
・ログ転送ではなく、ストレージレベルのレプリケーション機能を利用してレプリケーションを実施 ・概ね１秒以下 / 最大でも５秒でレプリケーションを実行する低レイテンシーレプリケーションを実現
Auroraのユースケース
大規模なクエリ処理が発生するRDB環境などをAuroraへの移行を検討すべし
◾️大規模なクエリデータ処理 ・書き込みが多くでトランザクション量が多い ・クエリ並行度が高い、データサイズが大きいケースで効果を発揮する ・コネクション数やテーブル数が多いデータベース処理
◾️運用の容易さを活用する ・スケーラビリティの高さやデータ容量が無制限に拡張できる ・レプリケーションなどの性能の高さ
EFSの概要
EFS（Elastic File System） 複数のEC2インスタンスからアクセス可能な共有ストレージ
◾️S3 ・オブジェクトストレージでリージョンに設置 ・HTTPによるAPI経由でアクセス ・大容量のデータを長期保存するためのもの
◾️EBS ・ブロックストレージでAZに設置 ・EC2インスタンスのディスクボリュームとして利用する ・複数のEC2インスタンスにアタッチできない
◾️EFS ・NASに似たファイルストレージ ・ファイルシステムとして利用し、複数のEC2インスタンスでの共有アクセスが可能
その特徴はシンプルでスケーラブルで柔軟に利用できるファイルストレージであること
◾️シンプル ・フルマネージド型サービス ・ネットワークファイルシステムバージョン４（NFSv4）プロトコルを利用して、関連ツールや標準プロトコル / APIでアクセス可能
◾️スケーラブル ・ペタバイトまでスケーラブルにデータを蓄積 ・スループット / IOPS性能は自動的にスケーリングし、低レイテンシーを維持 ◾️柔軟性 ・ファイルの減少に合わせて自動で拡張、縮小 ・事前に容量を設定する必要なし ・使った分だけの従量課金
基本性能
何千もの同時アクセスが実現可能という性能が特徴的 ◾️基本性能 ・基本性能は１００MB（バースト込み） ・ファイル名は２５５バイト ・１ファイルの最大容量４８TB ・インスタンスあたり１２８ユーザーまでの同時オープンが可能 ・何千もの同時アクセスが実現可能
◾️制限 ・アカウントあたりのファイルシステム数：１０００ ・AZごとのファイルシステムあたりのマウントターゲット：１ ・ファイルシステムあたりのタグ：５０ ・マウントターゲットあたりのセキュリティグループ：５ ・ファイルシステムあたりのVPC数：１ ・各VPCのマウントターゲット数：４００
EFSのデータ保存
EFSのデータファイルは複数AZに分散して保存されている
マウントターゲット
EC2インスタンスからの接続先のマウントターゲットを設定
・VPC内のAZにある接続先 ・EC2インスタンスは同じAZ内にあるマウントターゲットから接続する ・固定のDNS名とIPアドレスを有している ・ファイルシステムDNS名を使用してマウントすることで自動でIPアドレスを付与
パフォーマンスモード
汎用モードと最大I/Oモードから選択 基本は汎用モード
◾️汎用モード ・一般的な用途を想定したモード ・デフォルトでは汎用モードとなり推奨されている ・レイテンシーが最も低い ・１秒あたりのファイルシステム操作を７０００に制限
◾️最大I/Oモード ・何十〜何千というクライアントからの同時アクセスが必要な大規模な構築に利用 ・合計スループットを優先してスケールする ・レイテンシーが多少長くなる
バースト機能
ファイルストレージの負荷に応じてバースト機能によってスケーラブルに対応
◾️バースト 一時的な大量トラフィックの発生やそれに伴いサーバなどの処理性能が一時的に向上する
◾️バーストスループットモード ファイルシステムが大きくなるに従ってAmazonEFSによってスループットが拡張
◾️クレジットシステム クレジットシステムによりファイルシステムがバーストできる時期を判断する 各ファイルシステムは時間の経過とともにクレジットを蓄積していき、データを読み書きするたびにクレジットを使用する
・容量に応じたバースト性能 １TB以上の容量に応じて性能が向上する 最大で１GBまでバースト
・容量に応じてクレジットの蓄積量とスループット性能も向上する
EFSクライアント
EFSをEC2インスタンスから操作する際に専用のクライアントソフトウェアを利用する Amazon-efs-utilsに含まれるEFSマウントヘルパー Linux NFSv4クライアント
プロビジョンドスループット
◾️バーストのスループット ・ピーク時にクレジットを消費してバーストを実行して一時的な性能を向上させる方式 ・最大スループットとバースト時間に制限がある ・スループット性能向上にはストレージ容量の増大が必要
◾️プロビジョンドスループット ・一貫したスループットを事前に設定する方式 ・API / AWS CLI / マネージメントコンソールにより制御 ・１日に１回だけスループット性能を減少できる
ユースケース
複数EC2インスタンスでデータ共有する際はEFSをファーストチョイスする
◾️利用方針 ・EBSではできない複数インスタンスからの同時アクセスが必要 ・数秒単位でのデータ追記が必要 ・フルマネージドで運用して簡易に利用していきたい
◾️利用シーン ・アプリケーションの共有ディレクトリとして利用 ・ビックデータなどの分散並列処理環境における共有データアクセスストレージとして利用 ・コンテンツの共有リポジトリとして利用
3つのファイルストレージ
EFS以外にもユースケースに応じてFSxタイプのファイルストレージが２タイプ利用可能
◾️EFS ・NASに似たファイルストレージ ・ファイルシステムとして利用し、複数のEC2インスタンスでの共有アクセスが可能 ・S3と異なりインターネットから直接アクセスできない
◾️Amazon FSx For Windouws File Server ・Windouws File Serverと互換性のあるストレージ ・Windouws上に構築され、Windouws AD、OSやソフトウェアとの連携が豊富に可能
◾️Amazon FSx For Lustre ・分散型ファイルストレージであるオープンソースLusterと互換性のある分散型の高速ストレージ ・機械学習などの高速コンピューティングのデータレイヤーに利用する一時保存用の処理用ストレージ
Amazon FSx For Windouws File Server
Amazon File ServerをAWSクラウド上で利用したい場合に利用するストレージ
◾️特徴・ユースケース ・Windouws File Serverのクラウド移行 ・Active Directory（AD）統合などの幅広い管理機能 ・SMBプロトコルによりAmazon EC2、VMware Cloud on AWS、Amazon WorkSpaces、Amazon AppStream２.０インスタンスなど幅広く接続可能 ・最大数千台のコンピューてイングインスタンスからアクセス可能
◾️アーキテクチャ構成 ・ENI経由でアクセス ・VPCセキュリティグループでの制御 ・単一AZの単一サブネットを指定して構成する ・複数インスタンスでの共有や他AZ内のインスタンスからのアクセスも可能 ・マルチAZ構成を実施することもできる
Amazon FSx For Lustre
高速コンピューティング処理を実現する分散・並列処理専用の超高性能ストレージを提供
◾️特徴・ユースケース ・多くのスーパーコンピュータに利用される分散ファイルシステム ・フルマネージド型で安全にLusterを利用 ・最適容量３６００GB ・最大数百GB / 秒のスループット ・数百万IOPSまでスケール可能
◾️アーキテクチャ構成 ・ENI / エンドポイント経由でアクセス ・セキュリティグループで制御 ・単一AZの単一サブネットを指定して構成する ・Amazon S3とシームレスな統合によりデータレイク型のビックデータ処理や解析ソリューションに組み込む
増大するデータ量への対応
IoT / ビックデータなどで絶えず増加するデータの保持の効率的に実施する
◾️関連する主要サービス ・S3、Kinesis、Glacier、Glue、Athena、EMR、QuickSight、Redshift
増大するデータ
WEBの発展によるビックデータ蓄積とIoTの発展によるIoTデータ蓄積によりデータ量が大きく増大
データ量への対応
効率的なデータ蓄積とIoTなどの大量のストリームデータ処理や解析の方法が必要不可欠となる
AWSは大量なデータ処理への各段階において必要なサービスが提供されている ①効率的なデータ蓄積 S3、Glacier、Glue
②ストリームデータ処理 Kinesis
③大量データの解析手法 Athena、EMR、QuickSight、Redshift
ビックデータに必要な技術
ビックデータに対応したデータ蓄積・処理技術が必要不可欠 ・大量のデータを効率的に蓄積可能なデータベース技術 ・多様な形式のデータを蓄積可能なデータベース技術 ・高速処理が可能なデータ処理ソフトウェア / ハードウェア
データレイクの活用
ビックデータ活用の中心はデータレイク型データベース
◾️データウェアハウス中心 利用用途に応じたデータをためて活用するデータウェアハウス
◾️データレイク中心 出来る限り生データをほぼ全データ保存するデータレイク
データレイクでは全データを生データのまま保存する
Apacheシリーズ
ビックデータ分散処理向けの代表的な仕組み（ミドルウェア）がApacheシリーズ
◾️ストリーミング処理向け Apache Spark
Kinesisの概要
ストリームデータを収集・処理するためのフルマネージド型サービスで主に３つのサービスで構成される
◾️Amazon Kinesis Data Streams ストリームデータを処理するアプリケーションを構築
◾️Amazon Kinesis Data Firehose ストリームデータをS3やRedshiftなどへ簡単に配信
◾️Amazon Kinesis Data Analytics ストリームデータを標準的なSQLクエリでリアルタイムに可視化・分析
Amazon Kinesis Data Streams
ストリームデータ処理用の分析システムやアプリケーションを構築するサービス
Iotデータ → Kinesis Streams → Spark Streaming → アプリケーション
ストリーミング処理をシャードに分けて分散させて実行するため高速処理が可能 Kinesis Streamsのデータ提供側（プロデューサー）とデータ利用側（コンシューマー）に様々なサービスが利用可能
Kinesis Streamsは次の関連機能を活用してストリーミング処理アプリケーションを構築する
◾️Amazon Kinesis Agent Kinesisサービスにデータを簡単に収集して取り込むOSSのスタンドアロンJavaアプリケーション
◾️Amazon Kinesis Producer Library（KPL） Kinesis Streamsにデータを送信するOSSの補助ライブラリ
◾️Fluent plugin for Amazon Generator（KDG） Kinesis Data Generator（KDG）を利用してKinesis StreamsまたはKinesis Firehoseにテストデータを簡単に送信する
◾️Amazon Kinesis Client Library（KCL） KCLを利用してKinesisアプリケーションを作成する OSSのクライアントライブラリでEC2インスタンスなどにデプロイして利用する
Amazon Kinesis Data Firehose
各種DBに配信・蓄積するためのストリーム処理を実施する Lambdaと連携するとETLとしても機能する
Amazon Kinesis Data Analytics
ストリームデータを標準的なSQLクエリでリアルタイムに分析
Redshiftの概要
高速でスケーラブルな費用対効果の高いマネージド型のDWH / データレイク分析サービス
・数百ギガバイトのデータから開始して、パタバイト以上まで拡張 ・１テラバイトあたり年間１,０００USD以下で利用可能 ・自動ワークロード管理など自動テーブルメンテナンスなど多くのメンテナンススタンスやデータ配置が自動化されているフルマネージド型 ・PostgreSQL互換の列指向データモデル ・複数ノードをまとめたクラスター構成 単一AZで起動し、マルチAZ構成は不可 ・RA3インスタンスで最大で他のクラウドデータウエアハウスの３倍に達するパフォーマンス ・AQUAによる分散キャッシュでRedshiftが他のクラウドデータウェアハウスに比べて最大１０倍の速度で動作
データウェアハウス（DWH）
構造化データを利用した経営分析向けのデータベース
◾️概要 ・データ抽出、集約に特化したBIデータ分析用のデータベース ・読み込みデータ構造をあらかじめ設計して、加工してから利用分のデータを蓄積 ・レスポンス重視でデータ抽出、集計が早いが更新、トランザクションは遅い
◾️アーキテクチャ ・データをパーティショニングして複数ディスクから読み込み ・列指向でデータを格納
◾️利用データ ・会計データなどの業務系の構造化データを分析用に加工し、BIで利用 ・KPI測定 / 競合分析 / アクセス分析など
インスタンスタイプ
利用するデータサイズと増加予測に応じて２つのインスタンスタイプから選択
◾️RA3インスタンス ・コンピューティング性能とマネージドストレージのスケーリングと支払いを独立させることで、データウェアハウスを最適化 ・データ量の増大が予測される場合は、RA3ノードのご利用を推奨 ・最低２ノード必要 ・最安で＄３.８３６ / ノード /時
◾️DC2インスタンス ・固定ローカルSSDストレージを使用してデータウェアハウス ・データのサイズ増加に対し、ノードを追加して、クラスターのストレージ容量を増強 ・未圧縮で１TB未満のデータセットではDC2ノードタイプの利用を推奨 ・最低１ノード必要 ・最安で＄０.３１４/ ノード / 時
Redshiftとは
列指向型のリレーショナルデータベースであり、データを分散・高速処理が可能な仕組みとなっている
◾️列指向のRDB ・列指向型ストレージにデータを格納するリレーショナルデータベースのデータモデルを採用 ・大容量のデータアクセスを容易にしてディスクI/O効率化
◾️データ圧縮 ・データ圧縮によって一度に読み込めるデータ量が多くなることで処理を高速化 ・分析ワークロードでブロック単位でデータを格納して、ディスクI/O効率化
◾️ソート ・データが格納されているブロックに対してメタデータを付与して検索値とする ・リーダーノードのインメモリ上にメタデータを格納 ・データのソート順をテーブルごとにソートキーとして指定
◾️データ分散 ・データ量とクエリ内容に応じてノードに対する分散処理を調整し、効率的で高速な処理を実現 ・キャッシュによる高速化
マテリアライズドビュー
頻繁に実行するクエリパターンを結合・フィルタ・集計・射影によって高速化する機能
運用の自動化
自動的なメンテナンス機能と詳細のモニタリングによる簡易な運用が可能
◾️CloudWatchとの連動 ・初期設定でCloudWatchメトリクス取得が自動で実施され、RedShiftコンソール内で確認可能
◾️自動バックアップ ・自動でバックアップを定期取得する ・メンテナンスウィンドウでバックアップ実施時間を指定可能 ・スナップショットを手動で取得することも可能
◾️自動メンテナンス ・パッチ適用も自動で実施 ・メンテナンスウィンドウでパッチ適用時間を指定可能
◾️スケジューリング機能 ・クラスターサイズの変更を設定 ・クラスターの一時停止と再開を設定
機械学習によるクエリ効率化
機械学習によってクエリ実行を調整し効率的な自動実行を補助してくれる
◾️テーブルメンテナンスの自動化 ・テーブル分散化スタイルの自動最適化 ・統計情報の自動更新 ・データの再編成の自動実行
◾️自動ワークロード管理 ・複数クエリの実行をワークロード管理で設定する際に、機械学習でクエリ実行の優先順位決めを自動化する
◾️ショートアクセスレーション ・機械学習アルゴリズムを使用して対象のクエリを１つ１つ分析し、クエリの実行時間を予測し実行時間が短いクエリを実行時間が長いクエリよりも優先して実行 ・WLMキューを削減可能
◾️設定のレコメンデーション ・自動でクラスターパフォーマンスなどを分析し、最適化やコスト削減に対するレコメンデーションを実施
ワークロード管理（WLM）
ワークロードに応じて複数のキューを設定し、クエリ割り当てルールに基づいてキューを設定し、優先順位を設定可能
クエリエディタ
マネジメントコンソール画面からRedShiftデータベース接続してクエリを実行可能
スケーリング
RedShiftはノードのタイプ変更、追加とクラスターの追加によってスケーリング可能
◾️ノードの追加 コンピューティングノードを追加することでパフォーマンスを向上
◾️クラスターの追加 ConcurrencyScalingにより急な同時実行リクエストに対応するために一時的なクラスタを自動的に数秒で追加し、一貫して高速なパフォーマンスを発揮（追加クラスターは１〜１０）
Redshift Spectrum
Redshift Spectrumにより、ユーザーが管理するS3バケットに対して直接データ解析を実行可能
データ連携（To Redshift）
Redshiftへとデータ移動させることでDWHとしての解析基盤を集約化することが重要
◾️S3 ・最も頻繁に使われるデータ連携先であり、S3からデータを取得してRedshiftで解析することも可能であるし、S3内部のデータ解析を直接実行することも可能
◾️Kinesis ・Kinesis data Firehoseを利用してストリーミングデータの格納先としてRedshiftを指定してデータを保存して、解析に利用することが可能
◾️RDS ・RDSとの直接接続はないが、AWS Data PipelineやDMSを利用してデータ移行を実施可能
◾️DynamoDB ・DynamoDBからRedshiftにデータコピーを実行可能
◾️Amazon EMR ・EMRからRedshiftにデータコピーを実行可能
データ連携（From Redshift）
RedshiftからはQuickSightを利用したデータ可視化に加え、S3へとデータ抽出も可能
◾️Amazon QuickSight ・Redshiftに接続して、データの可視化を実施可能
◾️S3 ・UNLOADコマンドを実行することで、ReshiftからS3へとデータを抽出することが可能
◾️Amazon Machine Learning ・Redshiftを機械学習の学習データとして設定して利用可能
◾️RDS ・直接に連携はできないが、PostgreSQLの機能を利用してデータをRedshiftからRDSと連携可能
Amazon QuickSight
データを可視化・解析するためのBIツール Redshiftデータを可視化可能
AWS Glue
データを抽出、変換、ロード（ETL）を行う完全マネージド型のサービス
AWS Lake Formation
本来なら複雑な設定が必要なデータレイクの構成を簡単に素早く実現するサービス
Amazon EMR
Apache Spark、Apache Hive、Prestoなどのビックデータフレームワークを使用して大量データを処理・分析する
Route53について
Route53の概要
DNS
DNSはインターネットにおける人向けのURLをシステム向けの住所となるIPアドレスに変換するための仕組み
企業サーバーに一時的にDNS情報を保持するキャッシュDNSサーバーと実際に名前解決機能がある権威DNSサーバーがある
Route53はAWSが提供する権威DNSサーバーでポート５３で動作することからRoute53と呼ばれる DNSレコードというIPアドレスとURLを紐付けた表を確認してルーティングする
Route53
権威DNSサーバーの機能をマネジメント型で簡単に利用できるサービス
・主要機能はドメイン登録 / DNSルーティング / ヘルスチェックの３つ ・ポリシーによるルーティング設定 トラフィックルーティング / ファイルオーバー / トラフィックフローに基づく様々な条件のルーティング設定が可能 ・AWS側で１００％可用性を保証するSLA ・マネージドサービスとして提供しており、ユーザー側で冗長性などを考慮する必要がない
ホストゾーン
ドメインとそのサブドメインのトラフィックのルーティングする方法についての情報を保持するコンテナ
◾️パブリックホストゾーン ・インターネット上に公開されたDNSドメインレコードを管理するコンテナ ・インターネットのDNSドメインに対するトラフィックのルーティング方法を定義
◾️プライベートホストゾーン ・VPCに閉じたプライベートネットワーク内のDNSドメインのレコードを管理するコンテナ ・VPC内のDNSドメインに対して、どのようにトラフィックをルーティングするかを定義 ・１つのプライベートホストゾーンで複数VPCに対応 ・VPCが相互アクセス可能であれば複数リージョンのVPCでも同じホストゾーンを利用可能
DNSレコード
ルーティング方法を設定するためにDNSレコードを作成し、各種レコードを設定する
・SOA ドメインのDNSサーバー / ドメイン管理者のメール、アドレス、シリアル番号などを保持してゾーン転送時に情報が更新されているかの判断に利用する
・A ホスト名とIPアドレスの関連付けを定義するレコード
・MX メール配送先（メールサーバー）のホスト名を定義するレコード
・CNAME 正規ホスト名に対する別名を定義するレコード 特定のホスト名を別のドメイン名に転送する時などに利用する
DNSレコード
ALIASレコードというRoute53固有の仮想リソースレコード
◾️ALIASレコード ・DNSクエリにAWSサービスのエンドポイントのIPアドレスを返答 ・静的ウェブサイトとして設定されたS3バケット ・CloudFront ・ELB ・ホストゾーン内のリソースレコードセット
◾️ALIASレコードのメリット ・DNSクエリに対するレスポンスが高速 ・CNAMEにマッピングできないZoneApex（ドメイン名そのもの）を設定可能 ・ALIASレコードに対するクエリが無料であり、Route53と連携したDNSLookupを高速化する ・CloudFrontでのクエリ回数を削減
トラフィックルーティンのタイプ
様々なルーティング方式を選択して設計することが可能
◾️シンプルルーティング ・レコードセットで事前に設定された値のみに基づいてDNSクエリに応答する ・静的なマッピングによりルーティングを決定
◾️加重ルーティング ・複数エンドポイント毎の重み設定によりDNSクエリに応答する ・重みつけの高いエンドポイントに多くルーティングする
◾️フェイルオーバールティング ・ヘルスチェックの結果に基づいて、利用可能なリソースをDNSクエリに応答する ・利用可能なリソースにのみルーティングされる
◾️複数値回答ルーティング ・ランダムに選ばれた最大８つの別々のレコードを使用してIPアドレスを設定して、複数の値を返答する ・IPアドレス単位でヘルスチェックを実施してルーティングすることで、正常なリソースの値を返す ELBに代わるものではないが、正常であることが確認できる複数のIPアドレスを返す機能により、DNSを使用してアベイラビリティーとロードバランシングを向上させることが可能
トラフィックルーティングのタイプ
様々なルーティング方式を選択して設計することが可能
◾️レイテンシールーティング（Latency） ・リージョンの遅延によりDNSクエリに応答する ・基本的にはユーザーの最寄りのリージョンに返答する ・リージョン間の遅延が少ない方へルーティングされる
◾️位置情報ルーティング（Geolocation） ・ユーザーのIPアドレスにより位置情報を特定して、地域毎に異なるレコードを返す ・ネットワーク構成に依拠しない、精度の高いレコードの区分けが可能
◾️地理的近接性ルーティング ・ユーザーとリソースの場所に基づいて地理的近接性ルールを作成して、トラフィックをルーティングする AWSリソースを使用している場合は、リソースを作成したAWSリージョン AWS以外のリソースを使用している場合は、リソースの緯度と経度 ・必要に応じてバイアスを設定し、特定のリソースにルーティングするトラフィックの量を変更できる ・トラフィックフローを利用する必要がある
トラフィックフロー
従来はALIASレコードを駆使して複雑なルーティングポリシーを作成していたが、トラフィックフローによる視覚的なフローでの複雑なポリシー設定が可能となった
Well-Architected Frameworkについて
Well-Architected Framework
AZの選択
１つのリージョンにつき２つのAZを利用してアーキテクチャーを設計することが基本（３つ以上はコスト効率が下がる）
VPC
◾️１つのVPC ・可用性が低下するため、アイデンティティ管理やハイパフォーマンスコンピューティングなどその用途は限られる ・１人などの小規模で利用する場合は２つ以上VPCを利用するのが面倒なケースもある
◾️２つ以上のVPC ・２つ以上のVPCで可用性を確保するのが適切なAWSアーキテクチャ設計となる
５つの設計原則
Reliability：信頼性
障害による中断、停止と障害復旧による影響を軽減するinfrastructureを構成する
【設計事項】 ・インフラストラクチャサービスの障害復旧の自動化など軽減設計 ・復旧手順のテストによる検証 ・需要変化に応じた水平方向へのスケーラビリティに高可用性の確保 ・キャパシティの推測をやめる ・モニタリングと自動化を進める
信頼性の主要サービス
◾️基盤 ・IAM、VPC、AutoScaling、ELB、CloudFormation
◾️変更管理 ・CloudTrail、AWSConfig
◾️障害管理 ・CloudWatch
Performance Efficiency：パフォーマンス効率
システム要件のリソース最適化によるインフラの効率化
【設計事項】 ・システム要件を満たすためのコンピューティングリソースを効率化する ・システム要件やAWSサービスの進化に応じてAWSインフラの効率化を推進する 先端技術の一般化 グローバル化を即座に達成 サーバレスアーキテクチャの利用 より頻繁な実験
パフォーマンス効率の主要サービス
◾️コンピューティング ・AutoScaling、Lambda
◾️ストレージ ・EBS、S3、Glacier、EFS
◾️データベース ・RDS、DynamoDB、Elastic serach、Aurora、Redshift
◾️容量と時間のトレードオフ ・CloudFront、ElasticCache
Security：セキュリティ
AWS内のデータ / システム / アセットの保護とモニタリングによりセキュリティを高める
【設計事項】 ・全てのレイヤーでのセキュリティを適用 ・アクセス追跡、モニタリングを確実な実施 ・条件ドリブンのアラートをトリガーとしてセキュリティイベントへの応答を自動化 ・AWS責任共有モデルに基づく対象範囲の保護に集中する ・セキュリティのベストプラクティスの自動化 ソフトウェアベースのセキュリティ設定を使用し、迅速でコスト効率のいいスケーリングを安全に実行する 仮想サーバーのカスタムベースラインイメージによる新サーバーへの適用自動化 インフラストラクチャ全体のテンプレ化による管理
セキュリティの主要サービス
◾️データ保護 ・ELB、EBS、S3、RDS、KMS
◾️権限管理 ・IAM、MFA
◾️インフラ保護 ・VPC
◾️検出制御 ・CloudTrail、CloudWatch、AWSGuardDuty、AmazonInspector
Cost Optimization：コスト最適化
不必要なリソースの削減や最適な料金選択によりコストを削減
【設計事項】 ・不必要なリソース削減 ・透明性のある費用ぶか ・マネージド型サービスの利用によるコスト削減 ・固定の償却コストを変動コストへと転換 ・スケールによるコストメリット ・データセンターへの投資不要化
コスト最適化の主要サービス
◾️需要と供給の一致 ・AutoScaling
◾️コスト効率の高いリソース ・EC2購入方式、Trusted Advisor
◾️支出の認識 ・Cloud Watch、見積もりツール
◾️継続した最適化 ・AWS最新情報、TrustedAdvisor
Operational Excellence：運用上の優秀性
運用上の優秀性とは計画変更が起こった場合や予期せぬイベントの発生時において、自動化された運用実務および文書化されテストされレビューされた手順があること
【設計事項】 ・コードに基づく運用実施 ・ビジネス目的に沿った運用手順 ・定期的かつ小規模で増加的な変更実施 ・予期せぬイベントへの応答テスト ・運用イベントと障害からの学習 ・運用手順を最新のものに保持すること
## 運用上の優秀性の主要サービス ◾️準備 ・CloudFormation、Codeシリーズ、RunbookPlaybook
◾️運用 ・SystemManager、ServiceCatalog、CloudTrail、AWSArtifact、AWSGuardDuty、CloudWatch、AWSConfig、APIGateway
◾️進化 ・継続的かつ段階的な改善のために時間とリソースを割り当て、運用の有効性と効率性を向上させる
AWSベストプラクティス
◾️スケーラビリティの確保 ◾️環境の自動化 ◾️使い捨てリソースの使用 ◾️コンポーネントの疎結合 ◾️サーバーではなくサービス ◾️最適なデータベース選択 ◾️増大するデータ量対応 ◾️単一障害点の排除 ◾️コスト最適化 ◾️キャッシュの利用 ◾️セキュリティの確保
①スケーラビリティの確保 需要の変化に対応できるアーキテクチャを設計する ・EC2 Auto Recovery、EC2 Auto Scaling、Cloud Watch、RDS、DynamoDB
②環境の自動化 システムの安定性、整合性及び組織の効率性を改善するため主要プロセスを自動化する ・CloudFormation、Codeシリーズ、ECS、ElasticBeanstalk、OpsWorks、CloudWatch
③使い捨てリソースの使用 サーバーなどのコンポーネントを一時的なリソースとして利用、設計する ・EC2、AutoScaling
④コンポーネントの疎結合 コンポーネント間の相互依存を減らした構成とすることで、１つのコンポーネント変更や障害の影響を削減する ・ELB、SNS、SQS
⑤サーバーではなくサービス（サーバレス） マネージド型サービスとサーバーレスアーキテクチャにより効率的な設計と運用を実現 ・Lambda、SNS、SQS、ELB、SES、DynamoDB、AmazonAPIGateway、AmazonCognito
⑥最適なデータベース選択 ワークロードに応じた最適なデータベース技術を利用する ・RedShift、RDS、DynamoDB、Aurora、ElasticSearch
⑦増大するデータ量対応 Iot / ビックデータなどで絶えず増加するデータの保持を効率的に実施する ・S3、Kinesis、Glacier
⑧単一障害点の排除 AWSのサービスの多くは高可用性が保証されているものが多いものの、以下の主要サービスはELBなどによる高可用性設計が必要 ・アーキテクチャで高可用性を実現すべきサービス EC2、DirectConnect、RDS
・利用する主要サービス ELB
⑨コスト最適化 リソースが最適なサイズから必要に応じたスケールアウト、スケールインの実施と最適な料金プランの選択 ◾️需要と供給の一致 ・AutoScaling
◾️コスト効率の高いリソース ・EC2購入方式、Trusted Advisor
◾️支出の認識 ・Cloud Watch、見積もりツール
◾️継続した最適化 ・AWS最新情報、TrustedAdvisor
⑩キャッシュの利用 繰り返し取り出すデータやコンテンツについてはキャッシュを利用する構成とする ・CloudFront、EastiCache
⑪セキュリティの確保 全てのレイヤー、境界、リソース内 / 外においてセキュリティを実装する ◾️データ保護 ・ELB、EBS、S3、RDS、KMS
◾️権限管理 ・IAM、MFA
◾️インフラ保護 ・VPC
◾️検出制御 ・CloudTrail、CloudWatch、AWSGuardDuty、AmazonInspector
S3について
S3の概要
AWSストレージサービス
AWSは３つの形式のストレージサービスを提供
◾️ブロックストレージ ・EC2にアタッチして活用するディスクサービス ・ブロック形式でデータを保存 ・高速、広帯域幅 ・EBS、インスタンスストア
◾️オブジェクトストレージ ・安価かつ高い耐久性をもつオンラインストレージ ・オブジェクト形式でデータを保存 ・S3、Glacier
◾️ファイルストレージ ・複数のEC2インスタンスから同時にアタッチ可能な共有ストレージサービス ・ファイル形式でデータを保存 ・EFS
Simple Storage Service（S3）
ユーザーがデータを容量制限なく保存可能なマネージド型で提供されるオブジェクト型ストレージ
◾️特徴 ・高い耐久性 ９９.９９９９９９９９９％
・安価なストレージ 容量単価：月額１GB / 約３円
・スケーラブルで安定した性能 データは冗長化されていて保存されデータ容量に依存しない性能がAWS側で保証される
・暗号化 転送中や保存時にデータを暗号化可能
◾️データ保存形式 ・バケット オブジェクトの保存場所 名前はグローバルでユニークな必要あり
・オブジェクト S3に格納されるファイルでURLが付与される バケット内オブジェクト数は無制限 ・データサイズ データサイズは０KBから５TBまで保存可能
S3のオブジェクト構成
・Key オブジェクトの名前であり、バケット内のオブジェクトは一意に識別する
・Value データそのものであり、バイト値で構成される
・バージョンID バージョン管理に用いる
・メタデータ オブジェクトに付随する属性の情報
・サブリソース バケット構成情報を保存および管理するためのサポートを提供 例：アクセス制御リスト（ACL）
S3の用途に応じてストレージタイプを選択する
◾️STANDARD ・複数箇所にデータを複製するため耐久性が非常に高い
◾️STANDARD-IA ・スタンダードに比べて安価 ・データの読み出し容量に応じた課金
◾️One Zone-IA ・アクセス頻度は低いが、必要に応じてすぐに取り出すデータむけ
◾️RRS ・Reduced Redundancy Storage低冗長化ストレージ ・Glacierから取り出したデータ配置など
◾️Amazon Glacier ・最安のアーカイブ用ストレージ ・データ抽出にコストと時間（３〜５時間）を要する ・ライフライクルマネジメントで指定 ・ボールロック機能でデータを保持
S3 Intelligent-Tiering
低頻度アクセスのオブジェクトを自動的に低頻度アクセス層に移動することでコストを削減する
S3の整合性モデル
S3は高い可用性を実現するため、データ更新・削除には結果整合性モデルを採用 同時書き込みはタイムスタンプ処理を実施
◾️新規登録 ・Consisitency Read ・登録後即時にデータが反映される
◾️更新 ・Eventual Consistency Read ・更新直後はデータ反映に時間がかかる
◾️削除 ・Eventual Consistency Read ・削除直後はデータ反映に時間がかかる
S3のアクセス管理
◾️IAMポリシー ・IAMユーザー / サービスに対してS3サービスへのアクセス権限を設定することができる ・一元的にユーザーへのアクセス権限を管理
◾️バケットポリシー ・バケットへのアクセス権をJSONで設定 ・他アカウントへの許可も可能 ・バケット単位の高度なアクセス管理向け
◾️ACL ・バケットと個々のオブジェクトへのアクセス権限をXMLで設定する ・他アカウントへの許可も可能 ・簡易的にアクセス管理向け
◾️著名付きURL ・AWS SDKで生成した著名付きURLでS3のオブジェクトへの一定時間アクセスを許可
S3の暗号化
◾️SSE-S3 ・S3の標準暗号化方式で簡易に利用可能 ・暗号化キーの作成、管理をS3側で自動で実施 ・ブロック暗号の１つである２５６ビットのAdvanced Encryption Standard(AES-256)を使用してデータを暗号化
◾️SSE-KMS ・AWS KMSに設定した暗号化キーを利用した暗号化を実施 ・ユーザー側でAWS KMSを利用して暗号化キーを作成、管理することが可能 ・クライアント独自の暗号キーを利用可能
◾️SSE-C ・ユーザーが指定したキーによるサーバー側の暗号化（SSE-C）を使用することが可能 ・利用設定や管理がになるのがデメリット
◾️クライアントサイド ・クライアント側の暗号化ではAmazon S3に送信する前にデータを暗号化する方式 ・AWS KMSなどを利用して暗号化キーを作成、実施 ・アプリケーション内に保存したマスターキーを使用
S3アクセスアナライザー
アクセスポリシーに沿っているかを確認し、不正なアクセスが発生していないかアクセスポリシーを監視する機能
・IAMアクセスアナライザーに連動したS3向けの機能 ・バケットポリシー / ACLのモニタリング ・パブリックまたは共有バケットアクセスを検出 ・バケットポリシー、バケットACL、またはその両方 バケットアクセスのソースを検索して確認する場合は、この列の情報をまず使用して迅速で正確な訂正措置を実行する ・全てのパブリックバケットと共有バケットの結果を表示する ・バケットの実際のアクセス状況を確認する
ライフサイクル管理
バケット内のオブジェクト単位でストレージクラスの変更や削除時期などを設定することで実行を自動化する
設定方法 ・バケット全体やPrefixに設定 ・オブジェクト更新日を基準にして日単位で指定し、毎日０：００UTCにキューを実行 ・最大１０００ルール ・IAに移動できるのは１２８KB以上のオブジェクト ・MFA Deleteが有効だと設定不可
レプリケーション
リージョン間を跨ぐクロスリージョンレプリケーションにより耐障害性を高める
◾️レプリケーションのトリガー ・バケットに対するオブジェクト作成、更新、削除をトリガーにレプリケーションを実行する
◾️設定 ・バージョニング機能を有効にする ・バケットは各別リージョンを指定 ・双方向レプリケーションも可能 ・データ転送費用が発生
バージョン管理
ユーザーによる誤操作でデータ削除などが発生してもバージョンから復元できる
設定 ・バケットをバージョン管理する ・バージョン保管されたオブジェクトを参照可能 ・ライフサイクル管理によって保存する期間の指定も可能 ・バケット削除時に古いバージョンの別途削除が必要
バックアップ
Glacierを利用してバックアップと復元が実施可能 ◾️アーカイブ ・複数リージョンでレプリケートすることが可能 ・S3オブジェクトデータをライフライクル設定によりGlacierに移動
◾️リストア ・バージョン管理機能によって削除されたデータを復元するのが基本
利用状況の確認
◾️S3の分析 ・データのアクセスパターンの簡易可視化 ・CSV形式で出力可能 ・バケット内の分析を実施 ・アクセス頻度の低いデータや保存期間を確認してライフライクルポリシー設定に活かしていく
◾️S3のイベント通知 ・バケット内イベントの発生をトリガーにして、SNS / SQS / Lamdbaに通知設定が可能 ・シームレスなシステム連携処理を実現
S3データの解析
◾️S3 Select（Glacier Select） ・S3の内部機能として有している検索機能でS3内で直接にクエリを実行し、データを取得できる ・GZIP圧縮データやCSVやJSONに対して実行可能
◾️Amazon Athena ・Amazon S3内のデータを直接、簡単に分析できるようにするインタラクティブなクエリサービス ・Athena SQLクエリでSageMaker機械学習モデルを呼び出し、機械学習による推論も実行可能
◾️Amazon Macie ・機械学習によりAmazon S3の機密データを検出、分類、保護する、フルマネージド型サービス ・機密データ検出や調査を実施する
◾️Amazon Redshift Spectrum ・Amazon S3の格納データに対して、Amazon Redshiftから直接クエリを実行できる機能 ・Redshiftクラスターが起動されている前提であるため、Redshiftを利用している場合にお勧め
CORS
クロスリージョンリソースシェアリング（CORS）により、特定のドメインにロードされたアプリケーションが異なるドメイン内のリソースと通信する方法を定義
マルチパートアップロード
大容量オブジェクトをいくつかに分けてアップロードする機能
バッチオペレーション
S3オブジェクトの大量データに対して一括処理を実行することが可能
◾️ジョブ ・ジョブはS3バッチオペレーションの機能の基本単位で、ジョブを作成することでバッチオペレーションを作成 ・ジョブにはオブジェクトのリストに対して指定された操作を実行するために必要な全ての情報を登録 ・S3バッチオペレーションにオブジェクトのリストを渡し、それらのオブジェクトに対して実行するアクションを指定
◾️マニフェスト ・マニフェストはAmazon S3が作用するオブジェクトキーをリストするAmazon S3オブジェクト
・マニフェストオブジェクトキー、ETag、およびオプションでバージョンIDを指定
・AmazonS3インベントリレポート / CSVファイルの２つの形式で設定
S3の用途
大量データを長期保存するという観点から用途を検討する
・コンテンツ配信 ・ログ、バッチの保管場所 ・バックアップ / ディザスタリカバリ ・webの静的ホスティング ・データレイク
S3外部接続
AWS Storage Gateway
標準的なストレージプロトコルを利用して外部システム環境とAWSのストレージサービスとを接続するサービス
利点
AWSが有する機能や性能を活用できることが大きな利点 ・標準的なストレージプロトコルを活用したシームレスな統合 ・キャッシュを活用した低レイテンシなアクセスが可能 ・AWSストレージサービスの堅牢性、低コスト、拡張性 ・効率的なデータ転送 ・AWSのモニタリング、管理、セキュリティとの統合
用途
データ移転や保存などAWSストレージを利用したい場合に用いる ・ビックデータ処理 / クラウドバースティング / システム移行のためにデータをAWSストレージに移動させたいケース ・バックアップ、アーカイブ、災害対策としてAWSにデータを保持 ・オンプレミス環境で容易にAWAストレージを活用
Storage Gatewayのタイプ
利用するデータタイプに応じて３つのゲートウェイを利用する
・ファイルゲートウェイ Amazon S3オブジェクトにStorage Gatewayを経由してファイルデータを格納
・ボリュームゲートウェイ AmazonS3およびEBSsnapshotsをバックエンドとしたブロックストレージ
・テープゲートウェイ Amazon S3とGlacierにデータを保管する仮想テープストレージとVTL管理
ファイルゲートウェイ
オンプレミスのファイルデータをAWS Storage Gateway経由でAmazon S3上のオブジェクトとして格納
・仮想アプライアンスでNFS v3 / V4.1のインターフェースを提供 ・更新データは非同期でAWSに転送 ・ファイルとオブジェクトのマッピングは１対１ ・S3のライフサイクルポリシー / バージョニング / クロスリージョンレプリケーションなどが利用可能
ボリュームゲートウェイ
オンプレミス環境のディスクデータをAWS Storage Gateway経由でSnapshotとしてAmazon S3上に取得し、AWS環境のDisaster Recoveryを実現
・iSCSIでブロックストレージとしてインターフェースを提供 ・オンプレミスのローカルディスクのバックアップを自動的にAWS側で実施 ・更新データは非同期でAWSに転送 ・オンプレミス側のStorage Gatewayへリストア ・AWS上でEBSディスクへのリストアも可能
テープゲートウェイ
Storage Gatewayを仮想テープライブラリとして利用することで堅牢性の高い外部保管バックアップストレージを実現
・VTL(Virtual Tape Library）対応バックアップソフトウェアを利用し、Storage Gatewayを経由してバックアップデータをS3およびGlacierに格納
・オンプレミスおよびAWSのEC2環境で利用可能
・バックアップソフトウェアによりテープ取り出しオペレーションを行うことで安価なアーカイブストレージ（S3 / Glacier）を利用
・主要なバックアップソフトウェアをサポート
S3 Transfer Acceleration
クライアントとS3バケット間で長距離に渡るファイル転送を高速、簡単、安全に実行
・中央のバケットに対して世界中のお客様からアップロードが行われる
・大陸間で定期的にギガバイトからテラバイト単位のデータを転送する
・AmazonS3へのアップロード時にインターネット経由で利用可能な帯域幅を十分に活用できない
Amazon S3 Glacierの概要
バックアップなど中長期保存用のS3よりも安価なストレージ
・S3と同じ耐久性で値段が安い ・データ取得などの迅速性がない
Glacierの特徴
バックアップなど中長期保存用のS3よりも安価なストレージ ・Amazon S3 Glacierではデータはアーカイブに保存される ・１つのアーカイブの最大サイズは４０TB ・保存可能なアーカイブ数とデータ量に制限なし ・各アーカイブには作成時に一意のアーカイブIDが割り当てられ、作成後はアーカイブを更新できない ・アーカイブを保存するためのコンテナとしてボールドを使用（１つのAWSアカウントでは最大１,０００個のボールドを使用） ・Advanced Encryption Standard(AES)２５６ビット対象鍵を使用してデフォルトで自動的に暗号化 ・S3と違って直接データをアップロード、取得という処理ができないため、S3ライフライクル管理からか、プログラム処理によるアップロード / ダウンロードsが必要 ・Glacierの最低保持期間は９０日
Glacierの仕組み
◾️ボールド ・ボールドはアーカイブを格納するコンテナ ・ボールドはリージョンに作成
◾️アーカイブ ・アーカイブは写真、動画、ドキュメントなどの任意のデータでS3 Glacierでのストレージの基本単位 ・各アーカイブは一意のアドレスを持つ
◾️ジョブ ・アーカイブにSELECTクエリを実行したりアーカイブを取得したり、ボールドのイベントリを取得したりする実行単位
◾️通知設定 ジョブの完了には時間がかかるため、ジョブの完了時にSNSと連携した通知設定が可能
Glacierの仕組み
アーカイブに一時的にデータをアーカイブ処理して、ボールドに長期保存するという仕組み
Glacierのデータ取り出しタイプ
◾️迅速 ・迅速取り出しでは、アーカイブのサブセットが迅速に必要になった場合に、データに素早くアクセスするモード 通常１〜５分以内で使用可能になる
◾️プロビジョニングキャパシティ ・プロビジョンドキャパシティは、迅速取り出しの取得容量を必要な時に利用できることを保証する仕組み ◾️標準 ・標準取り出しでは、数時間以内に全てのアーカイブにアクセスできるデフォルト設定 通常、標準取り出しには３〜５時間で完了
◾️大容量 大容量取り出しは、最も安価な取り出しオプションであり、大量のデータ（ペラバイトのデータを含む）を１日以内に低コストで取得できる 通常、大容量取り出しは５〜１２時間で完了
アクセス管理
◾️IAMポリシー ・IAMユーザーやリソースに対してS3サービスへのアクセス権限を設定する ・一元的にリソースへのアクセス権限を管理
◾️ボールドポリシー ・ボールドで直接アクセスポリシーを定義して、組織内のユーザーや社外ユーザーに対してもボールドへのアクセス権限を設定する
◾️データ取り出しポリシー ・データ取り出しに関する制限を定義 ・無料利用枠のみに制限 または無料利用枠を超える量を取り出したい場合は、最大取得率を指定すると、取り出し速度を制限して取り出しコストの上限を設定
◾️ボールトロックポリシー ・ロックによって変更を禁止することによりコンプライアンス管理を強力に実施することが可能
◾️著名 ・認証保護のために全リクエストに著名が必要
Amazon Glacier
バックアップなど中長期保存用のS3よりも安価なストレージ ◾️容量あたりの料金 ・GB / 月あたり０.００５USD（０.５円ほど） S3は標準で０.０２５USD / One zoneで０.０１５２USD / GB
◾️データ取り出し料金 ・迅速：０.０３３USD / GB ・標準：０.０１１USD / GB ・大容量：０．００２７５USD / GB
◾️データ取り出しリクエスト料金 ・迅速：１１．００USD / リクエスト１,０００件 ・標準：０.０５７１USD / リクエスト１,０００件 ・大容量：０.０２７５USD / リクエスト１,０００件
◾️プロビジョニングされた迅速取り出し １１０.００USD / プロビジョンド容量単位
◾️データ転送料金 ・データ転送（イン）は無料 ・インターネットへのデータ転送（アウト）は１GB / 月まで無料 それ以上は有料
Glacier Deep Archive
Glacierよりも値段が安くデータ保存が可能だが、データ取得はさらに遅くなる中長期保存用ストレージタイプ ・Glacierよりさらに値段がやすい ・Glacierよりさらにデータ取得が遅い
・基本的なデータモデル、管理はGlacierと同じ ・１GBあたりの月額料金０.０００９９USDから利用可能でAWSの最低価格 ・データは３つ以上のAWSアベイラビリティゾーンにまたがって保存され、S3と同様に９９.９９９９９９９９９％の耐久性を実現 ・標準取り出しでデータは１２時間以内に取り出すことが可能 ・大量取り出しで４８時間以内にデータを取り出す大容量取り出しをすることで取得コスト低減出来る
VPCについて
VPCの概要
Virtual Private Cloud(VPC) VPCはAWSクラウド内に論理的に分離されたセクションを作り、ユーザーが定義した仮想ネットワークを構築するサービス
・任意のIPアドレス範囲の選択して仮想ネットワークを構築 ・サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など仮想ネットワーキング環境を完全に制御可能 ・必要に応じてクラウド内外のネットワーク同士を接続することも可能 ・複数の接続オプションが利用可能 →インターネット経由 →VPN / 専用線（Direct Connect）
VPNとのDirect Connect
VPNの方が安く素早く利用できるが、信頼性や品質は専用線が勝る
◾️コスト ・VPN 安価なベストエフォート回線が利用可能
・専用線 キャリアの専用線サービス契約が必要となりVPNより割高
◾️リードタイム ・VPN クラウド上での接続設定で可能なため即時
・専用線 物理対応が必要なため数週間
・専用線 ポートあたり１G / １０Gbps
◾️品質 ・VPN インターネット経由のためネットワーク状態の影響を受ける
・専用線 キャリアにより高い品質が保証される
◾️障害切り分け ・VPN インターネットベースのため自社で保持している範囲以外の確認は難しい
・専用線 物理的に経路が確保されているため比較的容易
VPCエンドポイント
VPCエンドポイントはグローバルIPをもつAWSサービスに対して、VPC内から直接アクセスするための出口
Gateway型はサブネットに特殊なルーティングを設定し、VPC内部から直接外のサービスと通信する ◾️特徴 ・アクセス制御：エンドポイントポリシーを設定 ・料金：無料 ・冗長性：AWS側が対応
PrivateLink型はサブネットにエンドポイント用のプライベートIPアドレスを生成し、DNSが名前解決でルーティングする
◾️特徴 ・アクセス制御：セキュリティグループを設定 ・料金：有料 ・冗長性：マルチAZ設計
VPC Flow logs
VPC Flow Logsはネットワークトラフィックを取得しCloudWatchでモニタリングできるようにする機能
・ネットワークインターフェイスを送信元 / 送信先とするトラフィックが対象
・セキュリティグループとネットワークACLのルールでaccepted / rejectされたトラフィックログを取得
・キャプチャウインドウと言われる時間枠（約１０分間）で収集、プロセッシング、保存する
・RDS、Redshift、ElasticCache、WorkSpacesのネットワークインタフェーストラフィックも取得可能
・追加料金はなし
VPCの設定上限
VPCの各種設定においては上限数があるため、大規模に利用する場合は考慮する必要がある
・リージョンあたりのVPCの上限数 ５ ・VPCあたりのサブネットの上限数 ２００ ・AWSアカウントあたりの１リージョン内のElasticIP数 ５ ・ルートテーブルあたりのルート上限数 １００ ・VPCあたりのセキュリティグループの上限数 ５００ ・セキュリティグループあたりのルールの上限数 ５０
VPCを分割するケース
アプリサービスや組織構成などの用途に応じてVPCを分割する
・アプリケーションによる分割 ・監査のスコープによる分割 ・リスクレベルによる分割 ・本番、検証、開発フェーズによる分割 ・部署による分割、共通サービスの切り出し
VPC Peering
VPC Peeringにより２つのVPC間でのトラフィックルーティングが可能
・異なるAWSアカウント間のVPC間をピア接続可能 ・一部のリージョン間の異なるVPC間のピア接続も可能 ・単一障害点や帯域幅のボトルネックは存在しない
EC2について
EC2の概要
EC2とは
数分で利用可能となる従量課金で利用可能な仮想サーバー
・起動、ノード追加、削除、マシンスペック変更が数分で可能
・管理者権限で利用可能
・OSまでは提供されているタイプを選択することで自動設定され、OSより上のレイヤーを自由に利用可能
・独自のAmazon Machine ImageにOS設定を作成し、保存して再利用が可能
リザーブドインスタンス
利用期間を長期指定して利用する形式で、オンデマンドに比較して最大７５％割安になる
◾️利用期間 ・スタンダード １年（４０％割引） ３年（６０％割引）
・コンバーティブル １年（３１％割引） ３年（５４％割引）
◾️AZ / インスタンスサイズ / ネットワークタイプ変更可否 ・スタンダード 有
・コンバーティブル 有
◾️インスタンスファミリー / テナンシー / 支払オプションの変更可否 ・スタンダード なし
・コンバーティブル 有
◾️リザーブドインスタンスマーケットプレイスでの販売可否 ・スタンダード 可能
・コンバーティブル 今度可能となる予定
◾️ユースケース ・一定した状態または使用量が予測可能なワークロード ・災害対策などキャパシティ予約が可能なアプリケーション
スポットインスタンス
予備のコンピューティング容量を、オンデマンドインスタンスに比べて割引（最大９０％引き）で利用できるEC2インスタンス
・予備用を入札式で利用するためとても安い（最大９０％引き）
・起動に通常よりも少し時間がかかる
・予備用のため途中で削除される可能性がある →一時的な拡張などの用途で利用
Saving Plan
１〜３年の期間に一定の使用量を守ることによりAmazon EC2コストを削減する ・リザーブドインスタンスと同様に、１年または３年の期間に特定の量の処理能力（USD / 時間で測定）を使用する契約を結ぶことで適用される割引契約
・AWSコンピューティング使用料金を最大７２％節約できる
・Amazon EC2、AWS Fargate、AWS Lamdbaに適用可能
キャパシティの予約
特定のアベイラビリティーゾーンのEC2インスタンスに対して任意の期間キャパシティを予約する
◾️期間 ・キャパシティーの予約 コミットメントは不要で必要に応じて作成及びキャンセル可能
・リザーブドインスタンス 固定の１年または３年のコミットメントが必要
・Saving Plan 固定の１年または３年のコミットメントが必要
◾️キャパシティの利点 ・キャパシティーの予約 特定のAZで予約されるキャパシティー
・リザーブドインスタンス 特定のリージョンで予約されるキャパシティー
・Saving Plan なし
◾️請求割引 ・キャパシティーの予約 なし
・Saving Plan 有
◾️インスタンスの制約 ・キャパシティーの予約 リージョンごとのオンデマンドインスタンス制限に制限
・リザーブドインスタンス AZまたはリージョンあたり２０の制限 制限引き上げ申請可
・Saving Plan なし
物理対応可能なインスタンス
物理サーバーにインスタンスを起動して制御が可能なタイプのインスタンス
◾️ハードウェア専有インスタンス ・専有HWのVPCで実行されるEC2インスタンス ・ホストHWのレベルで、他のAWSアカウントに属するインスタンスから物理的に分離する ・同じAWSアカウントのインスタンスとはHWを共有する可能性がある
◾️Dedicated Host ・EC2インスタンス容量を完全にお客様専用として利用できる物理サーバー ・サーバーにバインドされた既存のソフトウェアライセンスを利用可能
◾️Bare Metal ・アプリケーションが基盤となるサーバーのプロセッサーとメモリーに直接アクセス可能なインスタンス ・AWSの各種サービスとの連携が可能でOSが直接下層のハードウェアにアクセス可能
ストレージ
EC2で直接利用するストレージは不可分なインスタンスストアと自分で設定するEBSの２つ
◾️インスタンスストア ・ホストコンピューターに内蔵されたディスクでEC2と不可分のブロックレベルの物理ストレージ ・EC2の一時的なデータが保持され、EC2の停止・終了と共にクリアされる ・無料
◾️Elastic Block Store（EBS） ・ネットワークで接続されたブロックレベルのストレージでEC2とは独立して管理される ・EC2をTerminateしてもEBSは保持可能でSnapshotをS3に保持可能 ・別途EBS料金が必要
EC2のバックアップ
EC2インスタンスは定期的にバックアップすることが重要
・定期的にバックアップをとる ・定期的にリカバリプロセスを確認する ・複数のAZに重要なアプリケーションをデプロイすること ・フェイルオーバー対応を準備すること ・イベントをモニタリングして対応できるようにすること ・インスタンス起動時に動的IPアドレス処理の設定を行うこと
EBS
EC2にアタッチされるブロックレベルのストレージサービス
◾️基本 ・OSやアプリケーション、データの置き場所など様々な用途で利用される ・実態はネットワーク接続型ストレージ ・９９.９９９％の可用性 ・サイズは１GB〜１６TB ・サイズと利用期間で課金
◾️特徴 ・ボリュームデータはAZ内で複数のHWにデフォルトでレプリケートされており、冗長化不要 ・セキュリティグループによる通信制御対象外で有り、全ポートを閉じてもEBSは利用可能 ・データは永続的に保存 ・EC2インスタンスは他のAZ内のEBSにはアクセスできない ・EC2インスタンスに複数のEBSを接続することはできるが、EBSを複数のインスタンスで共有することはできない ・他のインスタンスに付け替えできる
Snapshot
EBSはスナップショットを利用してバックアップを取得する
◾️特徴 ・Snapshotでバックアップ ・SnapshotからのEBSを復元する際は別AZにも可能 ・SnapshotはS3に保存される ・Snapshotの２世代目以降は増分データを保存する増分バックアップとなる（１世代目を削除しても復元は可能） ・Snapshot作成時にブロックレベルで圧縮して保管するため、圧縮後の容量に対して課金が行われる
Snapshot作成時はデータ整合性を保つため静止点の設定を推奨 ◾️Snapshot作成時はデータ整合性を保つため静止点の設定を推奨 ・ソフトウェアの機能を利用 ・ファイルシステムの機能を利用 ・バックアップソフトウェアの機能を利用 ・アプリケーションの停止 ・ファイルシステムのアンマウントなど
◾️保存期間や世代数は無制限 ◾️世代管理が必要な場合はAWSCLIやAPI等で自動化する
スナップショットとAMI
Amazon Machine ImageはOS設定のイメージで有り、Snapshotはストレージのバックアップとなる
◾️AMI ・EC2インスタンスのOS設定などをイメージとして保持して、新規インスタンス設定に転用するもの
◾️Snapshot ・ストレージ / EBSのその時点の断面のバックアップとして保持するもの ・ストレージの復元や複製に利用
EBSのボリュームタイプ
ユースケースに応じて性能やコストが異なる５種類のボリュームタイプから選択
◾️SSD ・汎用SSD →仮想ディスクトップ →低レイテンシーを要求するアプリ →小〜中規模のデータベース →開発環境
・プロビジョンドIOPS →高いI/O性能に依存するNoSQLやアプリ →１０,０００IOPSや１６０MB/s超のワークロード →大規模DB
◾️HDD ・スループット最適化HDD →ビックデータ処理 →DWH →大規模なETL処理やログ分析
・コールドHDD →ログデータなどアクセス頻度が低いデータ →バックアップやアーカイブ
◾️マグネティック →旧世代のボリュームで基本利用しない →データへのアクセス頻度が低いワークロード
IAMについて
IAM
IAMの概要
責任共有モデル
セキュリティに対してAWSとユーザーとで責任分界して対応する責任共有モデルとなっている。
ユーザー側の責任範囲
・IAMによるアカウント管理 ・セキュリティグループの設定 ・アプリケーションのロールベースのアクセス設定 ・ネットワーク / インスタンスオペレーションシステム（バッチ）などの設定 ・OS / ホストベースのファイアーウォール設置
IAMとは
AWS Identity and Access Management（IAM）は安全にAWS操作を実施するための認証・許可の仕組み
・AWS利用者認証の実施 ・アクセスポリシーの設定 ・ユーザー個人またはグループ毎に設定
ルートユーザー
最初に作成されるのがルートユーザーであり通常の管理には利用しないアカウント ・AWSアカウント作成時に作られるIDアカウント ・全てのAWSサービスとリソースを使用できる権限を有するユーザー ・日常的なタスクはルートユーザーを使用しないことが強く推奨される
IAMユーザー
・１アカウントで５０００ユーザーまで作成可能 ・所属グループは１０まで設定可能
IAMグループ
・１アカウントで３００グループまで作成可能
IAMポリシー
ユーザーなどへのアクセス権限を付与
◾️管理ポリシー ・AWS管理ポリシー AWSが作成及び管理する管理ポリシー
・カスタマー管理ポリシー AWSアカウントで作成、管理する管理ポリシー 同じポリシーを複数のIAMエンティティにアタッチできる
◾️インラインポリシー ・自身で作成及び管理するポリシー １つのプリンシパルエンティティ（ユーザー、グループ、またはロール）に埋め込まれた固有ポリシーで、プリンシパルエンティティにアタッチすることができる
IAMポリシーはJSON形式で設定
・Effect Allow→許可 Deny→拒否
・Action 対象のAWSサービス 例："s3:Get"
・Resource 対象のAWSリソース ARNで記述
・Condition アクセス制御が有効となる条件
ユーザーのアクティビティの記録
・Access AdvisorのService Last Accessed Data IAMエンティティ（ユーザー、グループ、ロール）が最後にAWSサービスにアクセスした日付と時刻を表示する機能
・Credential Report 利用日時などが記録されたIAM認証情報に係るレポートファイル
・AWS Config IAMのUser、Group、Role、Policyに関して変更履歴、構成変更を管理、確認することができる機能
・AWS Cloud Trail AWSインフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持することができる機能
アクセス権限の一時付与
・AWS Security Token Service(STS) 動的にIAMユーザーを作り、一時的に利用するトークンを発行するサービス
・Temporary Security Credentials AWSに対して一時的な認証情報を作成する仕組み
IAMの設計
IAM設計のベストプラクティス
１、アカウント設定などの必要な場合を除いて、ルートユーザーを利用しない
２、ルートアカウントなどの特権ユーザーに対して、MFAを有効化する
３、利用者ごとにIAMユーザーを作成する
４、組織利用の場合は、役割ごとのIAMグループを作成してグループで管理するのを基本とする
５、最小限の権限設定と不要な認証情報は削除を心がける
６、ユーザーのために強度の高いパスワードポリシーを設定する
７、EC2インスタンスで作動するアプリケーションなどプログラムから利用する場合はなるべくロールを使用する
８、モバイルやアプリケーションを含め、一時利用にはSTSなどで最小限の利用許可を与える
９、AWSアカウントのアクティビティを常に監視する
AWS 0rganizations
IAMのアクセス管理を大きな組織でも楽に実施できるようにするマネージド型サービス ・複数アカウントの一元管理 AWSアカウントをグループ化してポリシーを定期ようして一元的に管理する
・新規アカウント作成の自動化 コンソール / SDK / CLIでAWSアカウントを新規作成して、作成内容をログ管理できる
・一括請求 複数AWSアカウントの請求を一括化する
機能セットの選択
支払一括代行とアカウントの全体管理の２つの方式を選択する
・Consolidated Biling Only 支払一括代行のみを実施する場合に選択
・All Feature 支払一括代行も含めて、企業内の複数アカウントを統制したい場合に選択
メモ ・パワーユーザー 管理者権限以外の全ての権限を有している
・IAMエンティティ ユーザー、グループ、ロール
