AWS メモ

●インスタンスメタデータ
　実行中のインスタンスを構成または管理するために
　使用できるインスタンスに関するデータ

　インスタンスメタデータは、ホスト名・イベント
　及びセキュリティグループなどのカテゴリに割り当てられる

　これを利用してインスタンスの構成情報などの基本情報を
　取得するなどできるため自動化プロセス設定には利用されない

●T3インスタンス

　ベースラインレベルのCPUパフォーマンスを提供する
　次世代のバースト可能な汎用インスタンスタイプで
　いつでも必要な時間だけCPU利用率をバーストさせることが可能

　T3インスタンスはバランスのとれたコンピューティング、
　メモリ及びネットワークのリソースを提供し、
　使用中に一時的なスパイクが生じる中程度の
　CPU使用率を持つアプリケーション向けに設計されている

●G4インスタンス

　業界内で最も費用対効果の高いGPUインスタンス

　機械学習モデルの本番環境へのデプロイや
　グラフィックスを多用するアプリケーションに適している

　高機能だがT2及びT3インスタンスよりも高価なため
　コスト最適なインスタンスではなく、
　また機械学習やゲーミングで利用するインスタンスタイプである

●A1インスタンス

　包括的なArmエコシステムによりサポートされる
　スケールアウト型のArmベースのワークロードに
　最適で大幅なコスト削減を実現できる

　A1インスタンスはAWS Gravitonプロセッサで
　動作する初のEC2インスタンス

　このプロセッサには６４ビットのArm Neoverseコアと
　AWSが設計したカスタムシリコンタイプでありコスト最適化ではない

●M5インスタンス

　Intel Xeon_Platinum 8175Mプロセッサを搭載した
　最新世代の汎用インスタンス

　このファミリーはバランスのとれたコンピューティング、
　メモリ、及びネットワークのリソースを提供し多くのアプリケーションに適している

　T2及びT3インスタンスと異なり、バースト性能がないため
　CPU使用率の上昇に対しても一定のパフォーマンスを
　保証できるインスタンスタイプという要件には合致しない

●AWS Artifact

　AWSとの契約やコンプライアンスなどに関わる情報を
　一元管理することができるサービス

　ユーザーとの契約にかかる文章のほか、
　AWS独自のコンプライアンス対応に関するレポートが提供される

　AWS Artifactでは、AWSのセキュリティ及び
　コンプライアンスレポートと特定のオンライン契約にオンデマンドでアクセスできる

　Service Organization Control（SOC）、Payment Card Industry（PCI）レポート、
　AWSセキュリティ制御の実装と運用の有効性を検証する
　様々な地域やコンプライアンス垂直市場の認定機関からの認定が含まれる

　事業提携契約（BAA）と機密保持契約（NDA）を管理することができる

　AWSコンプライアンスレポートへの
　オンデマンドアクセス用のセルフサービスポータルである
　AWS Artificatを使用することにより
　PCI DSSコンプライアンス証明（AOC）及び責任概要を利用できる

●AWS Config

　AWSリソースの認定を評価・監査・審査できるサービス

　ConfigにはAWSリソースの設定が継続的にモニタリング及び記録され、
　望まれる設定に対する評価を自動的に実行できる

　Payment Card Industry(PCI）レポートに基づいた情報提供はされない

●Amazon Macie

　機械学習を使用しAWSの機密データを自動的に検出、
　分類、保護するセキュリティサービス

●SpilloverCount

　ELB上でEC2インスタンスにルーティングされている
　HTTPリスナーとTCPリスナーのリクエスト失敗状況を確認できる

●RequestCount

　指定された間隔（1分または5分）の間に完了した
　リクエスト数、または接続の数を取得する

　完了したリクエストでは失敗状況の判断はできない

●UnHealthyHostCount

　ロードバランサーに登録された異常なインスタンス数を取得する
　インスタンスはヘルスチェックに対して構成された
　異常な閾値を超えると異常な状態とみなしてくれる
　異常なインスタンスはヘルスチェックに設定されている状態の
　閾値を満たせば再び正常な状態とみなされる
　ヘルスチェック結果としての異常なインスタンスを検知することができるが、
　リクエストの失敗状況に関する情報を取得することができない

●SurgeQueueLength

　異常なインスタンスへのルーティングを
　保留中のリクエスト（HTTPリスナー）または接続（TCPリスナー）の合計数

●AWS Systems Manager Automation

　EC2インスタンス及び他のAWSリソースの
　一般的なメンテナンスとデプロイに関する運用タスクを自動化することが可能

　その際に自動化ワークフローを構築しインスタンス及びAWSリソースを設定する

　独自のカスタムワークフローを作成するかAWSの定義済みのワークフローを使用することが可能

●IDS / IPS

　不正侵入検知（IDS）、不正侵入制御（IPS）

●Palo Alto Networks

　全てのVPC上にある悪意のあるトラフィック通信を監視、フィルタリングする

●AWS Shield Advanced

　アプリケーションを標的とした攻撃に対する高レベルな保護に使用する

　Standard版は高度な保護には不十分

●Amazon GuardDuty

　AWSアカウントとワークロードを継続的にモニタリングし、
　悪意のあるアクティビティや不正なアクティビティから保護する

●AWS Systems Manager Patch Manager

　セキュリティ関連のアップデート及びその他のタイプのアップデートの両方に関して、
　インスタンスへのパッチ適用プロセスを自動化する

　Patch Managerを使用してオペレーティングシステムと
　アプリケーションの両方にパッチを適用することができる

　AWS Systems Manager Patch Managerを使用することで、
　EC2インスタンスのフリート全体のOSのセキュリティパッチの適用を
　スケジューリングして自動実行することが可能となる

●AWS Batch

　AWSクラウドでバッチコンピューティングワークロードを実行できる

　OSパッチの管理にはAWS Systems Manager Patch Managerを利用する

●EC2Rescue

　EC2のWindowsインスタンスへの接続に失敗した場合や、
　起動上のトラブルが発生した場合にトラブルの分析に利用するログ収集をなどを実施する

●AWS SAM（Serverless Application Model）

　サーバーレスアプリケーション構築用のオープンソースフレームワーク

　Lambda関数などのサーバーレスアプリケーションをデプロイする際に利用される

　その際の実行環境はCloudFormationに依存しており
　CloudFormationテンプレート内にSAMの設定を実施しデプロイを実行する

●AWSTrustedAdvisor

　AWSインフラストラクチャサービスを監視し、既知のベストプラクティスと
　比較し節約やシステムパフォーマンス、セキュリティの観点からチェックをしてくれるプログラム

　これを利用し、ユーザーが利用するAWSリソース構成のセキュリティ対応状況をベストプラクティスと比較してくれる

●TCO計算ツール

　AWS移行した際の利用コストを試算することができ、
　オンプレミス環境やその他の費用比較が可能となる

　また、総コスト計算ツールでは、ビジネスニーズを最適に
　満たすように家庭を変更することもできる

　あくまで見積もりツール

●AWS Health

　AWSのリソース、サービス、およびアカウントの状態をリアルタイムで可視化する

　このサービスでは、AWSで実行されるアプリケーションに影響を与えている
　リソースのパフォーマンスや可用性の問題の把握と修復のガイダンスを提供する

●Amazon CloudSearch

　AWSクラウドで完全に管理された検索サービス

　高速で非常に拡張性の高い検索機能をアプリケーションに容易に統合できる

●Amazon Inspector

　EC2インスタンスにおける通信の詳細、安全なチャンネルの使用、
　実行中のプロセスの詳細、実行中のネットワークトラフィックなどのデータを収集して評価レポートを作成することが可能

　自動化されたセキュリティ評価サービスで、AWSにデプロイしたアプリケーションの
　セキュリティとコンプライアンスを向上させることができる

　自動的にアプリケーションを評価し、露出、脆弱性、ベストプラクティスからの逸脱がないかどうかを確認できる

　評価結果は詳細なリストがAmazon Inspectorによって作成される

　この調査結果は直接確認することもできるがAmazon Inspectorコンソール
　またはAPIを介して入手可能な詳細な評価レポートで確認できる

●Amazon Cognito

　ウェブアプリケーションおよびモバイルアプリに素早く簡単にユーザーの
　サインアップ/サインインおよびアクセスコントロール機能を追加できる

　Amazon Cognitoは、数百万人のユーザーにスケールし、Facebook、Google、
　AmazonなどのソーシャルIDプロバイダー、およびSAML2.0による
　エンタープライズIDプロバイダーを使用したサインインをサポートする

　フェデレーションIDプロバイダー用の組み込みUIと簡単な設定を使用すれば
　数分でAmazon Cognitoを統合して、アプリケーションにサインイン、
　サインアップ、アクセスコントロール機能を追加できる

●AWS Config

　AWSリソースに対してカスタムまたは管理されたルールを評価して通知することができる

　これは、リソースが定義したカスタムルールに準拠していることを確認する場合にも利用できる

　さらに、AWS ConfigにSNSトピックを連携すればSNSを利用した通知設定が可能

　例えば、リソースが更新されるとメール通知が実施され、変更内容が表示できる

●cfn-signalヘルパースクリプト

　AWS CloudFormationに信号を送り、EC2インスタンスが正常に作成魔tは更新されたかどうかを示す

　つまり、cfn-signalヘルパースクリプトの信号を確認し、
　直前のタスクが終了したのを確認した上で、次のリソース設定を始めることが可能となる

●AWS::AutoScaling::AutoScalingGroupリソース

　UpdatePolicy属性を使用し、AWS CloudFormationスタックが
　更新されるときのAutoScalingグループリソースの更新方法を定義する

　UpdatePolicy属性が正しく設定されていない場合、ローリング更新によって
　予期しない結果が生成される可能性がある

　AWS CloudFormationがAutoScalingグループのローリング更新を処理する方法は
　AutoScalingRolingUpdateポリシーを使用して制御できる

　この共通的なアプローチでは同じAutoScalingグループを保持し、
　設定したパラメータに基づいて古いインスタンスの置き換えを行う

●AWS Systems Managerパラメータストア

　設定データ管理と機密管理のための安全な階層型ストレージを提供する

　パスワード、データベース文字列、ライセンスコードなどの
　データをパラメータ値として保存することができる

　値は、プレーンテキストまたは暗号テキストとして保存できる

　これをCloudFormationテンプレートのパラメーターストアセクションで設定することで
　Systems Managerのパブリックパラメータストアを参照して最新AMIを引っ張ってくることができる

　テンプレートやパラメータなど何も変更せずにCloudFormationスタックを更新するだけで
　リソースの要件に応じてその時点でサイン真のAMIIDに更新される

●set-load-balancer-listener-ssl-certificateコマンド

　証明書を設定する

●AWS Server Migration Service（SMS） 　数千のオンプレミスワークロードを従来よりも簡単に、かつ短時間でAWSに移行できるエージェントレスサービス 　AWS SMSではライブサーバーボリュームの増分レプリケーションの自動化、スケージュール設定、および追跡が可能なため大規模なサーバーの移行作業を簡単に調整できる

●認証情報レポート 　IAMユーザーが最後にAWSサービスにアクセスした日付と時刻を表示する機能を提供する 　アカウントの全てのユーザーとユーザーの各種認証情報（パスワード、アクセスキー、MFAデバイスなど）のステータスが表示された認証情報レポートを生成する

●AWS Picing Calculator 　アーキテクチャソリューションのコストを見積もるサービス

●パワーユーザー 　管理者権限以外のあらゆるAWSリソースに対する権限を有したユーザーのこと

●AWS X-Ray 　リクエスト動作の確認、アプリケーションの問題の検出、アプリケーションのパフォーマンスの向上

●パーティションプレイスメントグループ 　HDFS、HBase、Cassandraなどの大規模な分散および複製ワークロードを行うラック間ででプライスるために使用できる

●Oracle RAC（Real Application Clusters） 　複数のサーバーで１つのデータベースを構成するOracleのクラスタ環境構成 　アクティブ・アクティブで構成されるデータベース構成をとるため、サーバリソースを１００％活用できることができる 　RDS OracleデータベースエンジンではRAC構成を使用することができない

メモ
・ICMP（Internet Control Message Protocol)

・RDP（Remote Desktop Protocol）

・AWSでは第三者に一時的なアクセス権限を付与する際は、IAMロールを利用することが推奨されている 　IAMユーザーは一時的に利用するものではない

・RDSの自動バックアップを実施すると、S3にスナップショットを取ることでバックアップを迅速に復元しトランザクションログは5分ごとにS3に保存されるため、アプリケーションを15分というRPO以内の状態に復元することが可能

・EFSにはファイルロック機能はあるが、ファイルバージョン管理機能はない

・RAID１はRTO1分以内の回復が可能

・AWSリソースの更新状況を保持しておくサービスはAWS Config、CloudTrailはAWSリソースの更新状況は保持できない

・ELBにCloudWatchメトリクスを適用すると、読み取りリクエスト量と待ち時間などロードバランサーとターゲットのデータポイントに関する統計情報をメトリクスとして取得できる。これらのメトリクスを使用してシステムが正常に実行されていることを確認できる

・プロキシサーバーにより、クライアントからの要求をフィルターし製品の更新に関連する要求のみを許可して製品の更新以外の全ての要求をフィルタリングすることができる（ネットワークACLおよびセキュリティグループはURLに基づいてリクエストをフィルタリングすることができない）

・CloudWatch Eventのターゲットとして設定できるサービス 　EC2、Lambda関数、Kinesis Data Stream、Kinesis Data Firehoseの配信ストリーム、ECSタスク、Systems Manager Run Command、Systems Manager オートメーション、Batchジョブ、Step Functionステートマシン、CodePipelineの倍プライン、Code Buildプロジェクト、Inspectorの評価テンプレート、SNSのトピック、SQSキュー、EC2 CreateSnapshot API call、EC2 Rebootlnstances API call、EC2 StopInstances API call、およびEC2 TerminateInstances API Call、別のAWSアカウントのデフォルトのイベントパス

・アプリケーションエラーに関連するキーワードをCloudWatchログを調べることで確認し、そのキーワードに基づいてカスタムメトリックを作成できる。さらに、そのキーワードに関するイベントをトリガーとしてEC2インスタンスを再起動するアクションを作成し、そのアクションを呼び出すカスタムメトリクスのCloudWatchアラームを設定できる

・CloudWatchアラームアクションを使用し、EC2インスタンスを自動的に停止、終了、再起動または回復するアラームを作成できる 　このアラームを利用して、インスタンスを実行する必要がなくなった際に停止または終了アクションを使用できる

・CloudTrailログファイルの整合性の検証を使用することでCloudTrailによるログ配信後にそのログファイルが変更、削除、または変更されなかったどうかを判断することができる

・RedsiftはRDSと異なり、マルチAZ構成によるフェールオーバー機能がないため冗長性が低いデータベース 　シングルAZ構成しか実行できないため、Redshiftはスナップショットを利用しローカルおよびリモートの量リージョンでデータをセキュアにバックアップすることが最良のソリューション

・DHCP（Dynamic Host Configuration Protocol） 　TCP/IPネットワークのホストに設定情報を渡すための規格 　DHCPメッセージのoptionsフィールドの内容は設定パラメータ 　パラーメータにはドメイン名、ドメインネームサーバー、netbios-node-typeなどがある 　DHCPオプションセットでは、VPC上で利用できるDHCPオプションで必要なオプションのみ指定できる

・カスタムメトリクスを使用する場合はPutMetricData権限が必要 　PutMetricDataがカスタムメトリクスを呼び出すとアプリケーションの1分未満のアクティビティをより短期間に把握できる

・LDAPはActive Directoryとのデータ読み書きに使用される標準的な通信プロトコル

・CloudFormationテンプレートにおけるCreationPolicy属性のResourceSignalパラメーターで、30分のTimeoutプロパティを追加することで、前提条件となるAWSリソースが起動されるまでのタイムアウト時間を設定することができる

Go echo

go mod の作成

go mod というファイルでパッケージ管理（外部ライブラリの管理）を行う

go mod init プロジェクト名
go mod init $(basename `pwd`)

※basename pwdでカレントディレクトリの取得

echo

軽量なWebフレームワーク

package main

import (
  "net/http"
  
  "github.com/labstack/echo"
  "github.com/labstack/echo/middleware"
)

var e = createMux()

func main() {
  e.GET("/", articleIndex)
  e.Logger.Fatal(e.Start(":8080"))
}

func createMux() *echo.Echo {
  // Echoのインスタンス作成
  e := echo.New()

  // 各種ミドルウェアを設定
  e.Use(middleware.Recover())
  e.Use(middleware.Logger())
  e.Use(middleware.Gzip())

  return e
}

func articleIndex(c echo.Context) error {
  return c.String(http.StatusOK, "Hello, World!")
}

var e = createMax()

Goプログラム（パッケージ）を実行した際は、依存パッケージの読み込み > グローバル定数 > グローバル変数 > init() > main() の順に実行（判定）されてく そのため、main()とinit()よりも先に上記のグローバル変数の部分が処理され、createMux()関数が呼び出される 上記のソースコードはmainパッケージのグローバル変数であるeにcreateMux()関数の戻り値を格納している箇所

パッケージの依存関係の管理

外部パッケージであるechoを利用するため、プログラムを起動する際にはechoのソースコードも必要 こうした外部パッケージを管理する手段として、Goではgo modコマンドが準備されている

go mod tidy

上記のコマンドは、ソースコードを検査して、どのような外部パッケージを利用しているのかを判定する ソースコード内で利用されている外部パッケージはgo.modとgo.sumというファイルに書き出される 直接的に利用しているパッケージはgo.modに間接的に利用しているパッケージはgo.sumに記載される go mod tidyコマンドで依存パッケージの書き出しが完了した後、外部パッケージのソースコードをPCにダウンロード（キャッシュ）する

go mod download

ダウンロードされた外部パッケージのソースコードは$HOME/go/pkg/modに配置される

セキュリティと運用について

セキュリティの確保

Security：セキュリティ

AWS内のデータ/システム/アセットを保護しモニタリングによりセキュリティを高める

【設計事項】

◾️全てのレイヤーでのセキュリティを適用

◾️アクセス追跡、モニタリングの確実な実施

◾️条件ドリブンのアラートをトリガーとしてセキュリティイベントへの応答を自動化

◾️AWS責任共有モデルに基づく対象範囲の保護に集中する

◾️セキュリティのベストプラクティスの自動化

　・ソフトウェアベースのセキュリティ設定を使用し、

　　迅速でコスト効率のいいスケーリングを安全に実行する

　・仮想サーバーのカスタムベースラインイメージによる新サーバーへの適用自動化

　・インフラストラクチャ全体のテンプレ化による管理

セキュリティの主要サービス

◾️データ保護 　ELB、EBS、S3、RDS、KMS

◾️権限管理 　IAM、MFA

◾️インフラ保護 　VPC

◾️検出制御 　Cloud Trail、CloudWatch、AWSGuardDuty、AmazonInspector

データ保護：暗号化

多くのDBサービスはKMSと統合されており、暗号化を容易に実施できる CloudHSMは不正使用防止策が取られている専用HWモジュール（HSM）により暗号キーを保護するサービス 厳しい暗号化要件に対応するために利用

S3はデータ保護のためにAWS認証情報によるアクセス制御と暗号化を実施 ◾️サーバーサイド暗号化 　・AWSのサーバーリソースを利用して格納データの暗号化を実施 　・暗号化タイプ：SSE-S3 / SSE-KMS / SSE-C

◾️クライアントサイド暗号化 　・暗号化プロセスをユーザー側で管理する 　・暗号化タイプ 　　AWS KMSで管理されたカスタマーキーで暗号化 　　クライアントが管理するマスターキーで暗号化

RDSはセキュリティグループによる制御とデータ接続の暗号化とリソースの暗号化を実施 ◾️セキュリティグループ 　・DBのSGでDBインスタンスへのアクセス制御 　・VPCのSGでVPC内のインスタンスへのアクセス制御 　・EC2のSGでEC2インスタンスへのアクセス制御

◾️データ接続の暗号化 　・SSL / TLSを用いてアプリケーションとDBインスタンス間のデータ接続を暗号化

◾️リソースの暗号化 　・暗号化オプションにより保管データを暗号化

責任共有モデル

セキュリティに対してAWSとユーザーとで責任分界して対応する責任共有モデルとなっている

ユーザー側の責任範囲 ・IAMによるアカウント管理 ・セキュリティグループの設定 ・アプリケーションのロールベースのアクセス設定 ・ネットワーク / インスタンスオペレーションシステム（バッチ）などの設定 ・OS / ホストベースのファイアーウォール設置

権限管理：AWS Directory Service

ディレクトリサービスとはユーザーに関わる各種情報を保管してユーザー認証を実現する仕組み

◾️管理するユーザー情報 　・ID、ユーザー名、名字氏名、部署、グループ、担当、電話番号、メールアドレス、パスワード

◾️実現する機能 　・IDとアクセス管理 　　運用効率の向上、コンプライアンス向上、セキュリティの強化など

　・アプリのアクセス制御 　　ファイル共有 　　パッチ管理など

AWSに新しいディレクトリを作成するか、既存のActiceDirectory認証を利用した制御を実現 ◾️Simple AD 　AWSに新規ディレクトリを作成

◾️AD Connector 　既存のディレクトリをAWSに接続

権限管理：Security Token Service（STS）

STSは限定的で一時的なセキュリティ認証情報を提供するサービス

権限管理：Amazon Cognito

シンプルでセキュアなユーザーのサインアップ、サインイン、およびアクセスコントロールをアプリケーションに実装

サブネットの分割

サブネットはインターネットアクセス範囲を定義するために利用する

◾️パブリックサブネット 　・インターネットと接続が必要なリソースを揃える 　・インターネットとのアクセス制御に利用する

◾️プライベートサブネット 　・インターネットから隔離することでセキュリティを高める

VPCアクセス制御

VPCはセキュリティグループとネットワークACLで制御する ◾️セキュリティグループ 　・インスタンス単位で制御 　・ステートフル

◾️ネットワークACL 　・サブネット単位 　・ステートレス

検出制御

監視やモニタリングを継続的に実施してセキュリティを高める

◾️CloudTrail 　AWSユーザーの行動ログを取得し、ガバナンス・コンプライアンス、および運用とリスクの監視を行えるように支援する

◾️CloudWatch 　AWSリソースとAWSで実行するアプリケーションに対して、様々なメトリクスやログを収集、追跡するモニタリングサービス

◾️AWSGuardDuty 　AWS上で悪意のある操作や不正な動作を継続的にモニタリングする脅威検出サービス

◾️Amazon Inspector 　自動的にアプリケーションを検証し、その露出・脆弱性・ベストプラクティスからの逸脱状況を確認し、セキュリティ評価を実施するサービス

監視やモニタリングを継続的に実施してセキュリティを高める ◾️AWS WAF 　可用性、セキュリティ侵害、リソースの過剰消費といった一般的なウェブの脆弱性からウェブアプリケーションまたはAPIを保護するウェブアプリケーションファイアウォール

◾️AWS Shield 　マネージド型の分散サービス妨害（DDoS）に対する保護サービス、AWS Shieldにはスタンダードとアドバンストの２つの階層があり、サポート範囲が異なる

◾️IAM Access Analyzer 　外部エンティティと共有されているAmazon S3バケットやIAMロールなど組織とアカウントのリソースを識別し、セキュリティ上のリスクであるリソースとデータへの意図しないアクセスを特定

◾️AWS Security Hub 　セキュリティアラートを一元的に表示して管理し、コンプライアンスチェックを自動化 　監査結果から修正すべき設定の数と現在のセキュリティ状態が把握する

AWS KMS

簡単にデータを暗号化するためのマネージド型暗号化サービス

・暗号鍵の作成、管理、運用を実施するマネージドサービスでAWSマネジメントコンソール、AWSSDKまたはCLIを使用してキーを作成、インポート、ローテーション、削除、管理する ・IAMと連携して鍵のアクセス管理を実施 ・カスタマーマスターキー（CMS）の無効化・有効化・削除を実施し、１年ごとの自動キーローテーションすることが可能 ・CMKを外部から持ち込んで管理することも可能 ・キーを保護するためにFIPS140-2の検証済みまたは検証段階のハードウェアセキュリティモジュールを使用 ・AWSCloudTrailと統合されており、全てのキーの使用ログを表示 ・RDSやS3などの多数のAWSサービスに適用可能 ・KMS SDKを利用することで、アプリケーションにおける暗号化も可能

AWS KMS

RDSでは保存されるデータ・リソースの暗号化と接続の暗号化を実施可能 ◾️カスタマーマスターキー 　・暗号化を実行する上で最初に作成されるマスターキー 　・暗号化キーを暗号化する 　・ローテーションされる

◾️カスタマーデータキー（暗号キー） 　・実際のデータの暗号化に利用するキー 　・KMSで生成されてCMKで暗号化される

◾️エンベローブ暗号化 　・マスターキーで暗号化をせずに、暗号化したデータキーを利用して暗号化する暗号化方式

エンベローブ暗号化

AWS KMSは簡単にデータを暗号化するためのマネージド型暗号化サービス ・データキーとマスターキーによる暗号化を実施 ・カスタマーマスタキー（CMK）を利用してデータキーを暗号化する

AWS Certificate Manage

Secure Sockets Layer / Transport Layer Sercurity（SSL / TLS）証明書のプロビジョニング、管理、デプロイを実施

コスト最適化

Cost Optimization：コスト最適化 不要なリソースを削減し、最適な料金選択によりコストを最適化すること

【設計事項】 ・不必要なリソース削減 ・透明性のある費用賊課 ・マネージド型サービスの利用によるコスト削減 ・スケールによるコストメリット ・データセンターへの投資不要化

コスト最適化主要サービス

◾️需要と供給の一致 　AutoScaling

◾️コスト効率の高いリソース 　EC2購入方式、TrustedAdvisor

◾️支出の認識 　CloudWatch、見積もりツール

◾️継続した最適化 　AWS最新情報、TrustedAdvisor

AWSを安く使う

最もシンプルで一番最初にやるべきコスト最適化は無料枠利用の最大利用と最適な料金オプションの選択

AWSの課金方式

AWSは利用料に応じた柔軟な価格設定となっている

◾️従量課金 　従量課金による利用料に応じた価格設定が基本

◾️予約による低価格 　EC2などの特定のサービスにはリザーブド価格（予約による低価格販売）が実施されている

◾️使うほど安い 　AWSではボリュームディスカウントを受けることができ、使用量が増えるほど節約できる

AWSの料金設定

他のクラウドサービスとの競争のために頻繁に料金改定がなされるため利用毎に料金表を確認することが基本

EC2の購入オプション

EC2の購入オプションは利用形態や利用期間などに応じて多岐にわたるため、コスト最適な選択をすることが重要 ◾️オンデマンドインスタンス ◾️スポットインスタンス ◾️リザーブドインスタンス ◾️ハードウェア専有インスタンス ◾️DedicatedHost ◾️ベアメタル

EC2のリサーブドインスタンス

利用期間を長期指定して利用する形式で、オンデマンドに比較して最大７５％割安になる ◾️利用期間 　・スタンダード 　　１年４０％割引 　　３年６０％割引

　・コンバーティブル 　　１年３１％割引 　　３年５４％割引

◾️AZ / インスタンスサイズ / ネットワークタイプ変更可否 　・スタンダード 　　有

　・コンバーティブル 　　有

◾️インスタンスファミリー / OS / テナンシー / 支払オプションの変更可否 　・スタンダード 　　なし

　・コンバーティブル 　　有

◾️リザーブドインスタンスマーケットプレイスでの販売可否 　・スタンダード 　　可能

　・コンバーティブル 　　今後となる可能

◾️ユースケース 　・一定した状態または使用量が予測可能なワークロード 　・災害対策などキャパシティ予約が可能なアプリケーション

EC2のスポットインスタンス

予備のコンピューティング容量を、オンデマンドインスタンスに比べて割引（最大９０％引）で利用できるEC2インスタンス

◾️予備用を入札式で利用するためとても安い（最大９０％引き） ◾️軌道に通常よりも少し時間がかかる ◾️予備用のため途中で削除される可能性がある 　→一時的な拡張などの用途で利用

物理的対応可能なインスタンス

物理サーバーにインスタンスを起動して制御が可能なタイプのインスタンス ◾️ハードウェア専有インスタンス 　・専用HWのVPCで実行されるEC2インスタンス 　・ホストHWのレベルで他のAWSアカウントに属するインスタンスから物理的に分離する 　・同じAWSアカウントのインスタンスとはHWを共有する可能性がある

◾️Dedicated Host 　・EC2インスタンス容量を完全にお客様専用として利用できる物理サーバー 　・サーバーにバインドされた既存のソフトウェアライセンスを利用可能

◾️Bare Metal 　・アプリケーションは基盤となるサーバーのプロセッサーとメモリーに直接アクセス可能なインスタンス 　・AWS各種サービスとの連携が可能でOSが直接下層のハードウェアにアクセス可能

AWS Organizationによる一括請求

AWSOrganizationsの一括請求で、メンバーアカウント間でリザーブドインスタンスを共有化したり、S3などの利用量に応じた課金がお得になる

◾️ボリュームディスカウント適用 　・S3などボリューム料金階層があるサービスの場合、多く利用するほど価格が低くなると 　　一括請求で複数アカウントをまとめてボリューム料金に統合することでコスト削減が可能

◾️リザーブドインスタンスの共有 　一定の条件においてメンバーアカウント間で購入したリザーブドインスタンスが共有される 　・AWS Organizationsで有効か 　・同じAZ内に購入する 　・同じインスタンスタイプである

Saving Plan

１〜３年の期間に一定の使用量を守ることによりコストを削減 ・リザーブドインスタンスと同様に１年または３年の期間に特定の量の処理能力（USD / 時間で測定）を使用する契約を結ぶことで適用される割引契約 ・AWSコンピューティング使用料金を最大７２％節約できる ・AmazonEC2、AWSFargate、AWSLambdaに適用可能

価格算定ツールを利用する

AWS公式ツールを利用して見積もりや価格比較を実施する ◾️簡易見積もりツール 　利用するAWSサービスに対する月額料金を見積もることができます

◾️TCO計算ツール 　AWS利用した場合とオンプレミス環境やコロケーション環境との価格比較ができます

◾️PricingCalCulator 　ビジネスや個人のニーズに沿った個別の予測コスト見積もりを実施することができます

コストの可視化

CloudWatchのbilling機能により請求額通知を可能とし、TrustedAdvisorからアドバイスをもらう

Trusted Advisor

コスト最適化とセキュリティと耐障害性とパフォーマンス向上についてアドバイスを提供するサービス ・コスト最適化 ・セキュリティ ・耐障害性 ・パフォーマンス向上

運用上の優秀性

Operational Excellecnce：運用上の優秀性 運用の優秀性とは計画変更が起こった場合や予期せぬイベントの発生時において、自動化された運用実務および文書化されテストされレビューされた手順があること

・コード化された運用実行（環境自動化） ・ビジネス目的に沿った運用手順 ・定期的かつ小規模で増加的な変更管理 ・予期せぬイベントへの対応テストの実施 ・モニタリングにより障害を予測する ・運用上の失敗やイベントから学習する ・運用手順を繰り返しアップデートする

運用上の優秀性の主要サービス

◾️準備 　CloudFormation、Codeシリーズ、RunbookPlaybook

◾️運用 　SystemManager、ServiceCatalog、CloudTrail、AWSArtifact、AWSGuardDuty、CloudWatch、AWSConfig、APIGateway

◾️進化 　継続的かつ段階的な改善のために時間とリソースを割り当て、運用の有効性と効率性を向上させる

AWS CloudTrail

AWSユーザーの操作（API操作やユーザーのサインインアクティビティ）をロギングするサービス

・ルートアカウント / IAMユーザーのオペレーションとトラッキング ・CloudTrailログファイルは暗号化されてS3に保存 ・KMSによる暗号化もサポート

AWS Config

AWSリソースのレポジトリ情報からリソース変更履歴や構成変更を管理するサービス ・定期的に構成情報のスナップショットをS3に保存 ・構成情報に基づきシステム構成があるべき状態担っているかを評価 ・評価基準にはAWSルールまたは独自ルールを適用

AWS Configには構成変更を管理するストリームと履歴管理するヒストリーと構成要素を保存するスナップショットがある ◾️ConfigraionStream 　・リソースが作成、変更、削除に対して作成され、構成ストリームに追加される 　・SNSトピック連携して通知設定が可能

◾️ConfigurationHistory 　・任意の期間における各リソースタイプの構成要素を履歴として蓄積 　・S3バケットに保存

◾️ConfigurationSnapshot 　・ある時点での構成要素の集合 　・自動で定期的あるいは変更トリガで作成 　・S3バケットに保存

AWS Service Catalog

AWSで承認されたITサービスのカタログを作成するおよび管理する支援サービス ◾️IT運用管理者 ・CloudFormationのテンプレートを利用して、管理されるAWSリソース定義や、これらの利用権限をカタログとして一元管理する構成を提供

◾️ユーザ部門 ・IT運用管理者が作成したカタログにより、権限がなくとも求める機能に応じたAWS環境を必要に応じて起動が可能になる

AWS Artifact

重要なコンプライアンス関連情報の頼りになる一元管理型のリソース ◾️AWS Artifact Reports 　世界各地にある監査機関の指定する基準や規制を遵守状況をテストおよび確認したコンプライアンスレポートを提供

◾️AWS Artifact Agreements 　AWSアカウントとの契約の確認、受託、管理を実施

AWS GuardDuty

VPCフローログ、CloudTrailログ、DNSログや悪意のあるIPやドメインリストなどを分析して処理する継続的なセキュリティモニタリングサービス

AWS Systems Manager

利用中のAWSサービスやリソースをモニタリングして、運用タスクを自動化するサービス ◾️問題検出の時間短縮 　EC2などのをリソースグループごとに運用データを確認できるため、アプリケーションに影響を与えうるリソースの問題を素早く特定可能

◾️運用の自動化 　EC2パッチ、更新、設定変更、削除、停止およびデプロイなどを自動化

◾️可視化と制御 　各リソースグループの最新状態を簡単に可視化して制御できる

◾️ハイブリット管理 　AWSサーバーとオンプレミスのサーバーとを１つのインターフェースで管理可能

CloudWatchの概要

AWSリソースとAWSで実行するアプリケーションのモニタリングサービスで、様々なログやメトリクスを監視できる ・モニタリング、監視の集約化、トラブルシューティング、ログ解析、自動アクション、運用状況の確認

◾️CloudWatch（メトリクス監視） 　AWS上で稼働するシステム監視サービスで、死活監視、性能監視、キャパシティ監視を実施

◾️CloudWatchLogs 　CloudWatchと連動したログ管理プラットフォームサービス 　EC2上のOS・アプリケーションのログやAWSマネージドサービスのログを取得する

◾️CloudWatchEvents 　CloudWatchはAWSリソースに対するイベントをトリガーにアクションを実行　 　オペレーションの変更に応答し、応答メッセージ送信、機能のアクティブ化、変更、状態情報収集による修正アクションを実行する

環境の自動化について

イノベーションノウハウ

テクノロジーの進化とビジネス変化のスピードに対応するため、柔軟で素早いサービス開発が求めれる

◾️テクノロジー×ビジネススピードへの対応 　１、テクノロジー進化のスピードが加速 　２、テクノロジーを活用したビジネスの展開スピードが加速 　３、これまでより短期に開発可能かつ変更に強いシステムの必要性

◾️多様な顧客ニーズへの対応 　１、多様な顧客ニーズに柔軟かつスピーディに対応する必要性 　２、デザイン思考 / リーンスタートアップなどの顧客中心手法が主流に 　３、本当に使うシステムだけを開発・運用する必要性

ビジネスに即応できる開発手法・技術の導入

AWSの環境自動化サービス

システムの安全性・整合性及び組織の効率性を改善するため主導プロセスを自動化する

・関連する主要サービス AutoScaling、CloudFormation、Codeシリーズ、ECS、ElasticBeanstalk、OpsWorks、EC2 Run Command

環境の自動化

環境を自動化することで開発速度を高めつつ、DevOpsとCI / CDによる開発を実現する

素早いサービス開発

リーンによる素早いサービス検討とCI / CDによる素早い開発をマイクロサービスに対して実施する

・Codeシリーズ 　開発コードのGit上のコミット・実行・デプロイを自動化する 　PipelineはCloudFormationとECSのデプロイ自動化にも利用可能

・Elastic Beanstalk 　ウェブアプリケーションやサービスを使いなれたサーバーでデプロイおよびスケーリングするためのサービス

・OpsWorks 　ChefやPuppetのマネージド型インスタンスのサーバーの設定、デプロイ、管理を自動化できるようになる設定管理サービス

・CloudFormation 　クラウド環境内の全てのインフラストラクチャリソースを記述してプロビジョニングするためのテンプレート化されたプロビジョニングサービス

・Amazon ECS 　AWS上でDockerコンテナによる環境構築のテンプレート化を実現するサービス 　Dockerfileに環境イメージを設定しインフラ設定をコード化する

・CloudWatch 　EC2インスタンスやEBSボリューム、DBインスタンスまたはカスタムメトリクスなどのリソースを簡単にモニタリングできる

Codeシリーズ

開発コードのGitベースのリポジトリ上でのコミット・実行・デプロイを自動化する一連のサービス

Elastic Beanstalk

WEBアプリケーションの定番構成の構築・デプロイの自動化サービス ・早く簡単にアプリケーションをデプロイするサービス ・Java、PHP、Ruby、Python、Node.js、NET、Docker、Goに対応してWEBアプリケーションを展開できる ・Apache、Nginx、Passenger、IISなど使いなれたサーバーでデプロイおよびスケーリングが可能 ・コードをアップロードすればキャパシティのプロビジョニング、ロードバランシング、AutoScalingからアプリケーションのヘルスモニタリングまでデプロイを自動化できる

Elastic Beanstalkの構成要素

アプリケーションという単位にバージョン・環境設定がコードとして保持され、環境にバージョンが展開される

◾️アプリケーション 　・トップレベルの論理単位でバージョンや環境や環境設定が含まれている入れ物

◾️バージョン 　・デプロイ可能なコードでS3で管理する 　・異なる環境 / 異なるバージョンを展開可能 　・バージョンレポジトリーに保持する

◾️環境 　・各環境（ウェブサーバー / ワーカー）に応じて構築されるインフラ環境 　・バージョン（ソースコード）をデプロイ

◾️環境設定 　・その環境に関連するリソースの動作を定義する設定パラメータ 　・永続データの格納場所はS3やRDSなどの外部サービスを利用する

ユースケース

WEBアプリケーションのデプロイを容易にすることや、タスク時間の長いワークロードの展開に利用する

◾️ウェブサーバー環境 ・ELB＋Auto Scalingでスケーラブルな構成をコード化してバージョンとすることで、スケーラブルなウェブアプリケーションを実行できる ・単一コンテナのDockerコンテナを実行可能 ・複数コンテナはECSを使用した環境実行が可能

◾️ワーカー環境 ・SQS＋AutoScalingでスケーラブルなバッチ処理ワークを実現 ・定期的なタスク実行基盤の作成：毎日深夜１時に動作するバックアップ処理 ・ワーカーホスト内でWebアプリケーションを動作させ、ワークロードの時間がかかる処理を実行させる

OpsWorks

OpsWorksはChefまたはPuppetを使用してアプリケーションを設定および運用するための設定管理サービス

・OpsWorksスタック ・OpsWorks for Chef Automation ・OpsWorks for Puppet Enterprise

Chefは様々な形式のインフラへのサーバーやアプリケーションの展開を容易にする環境自動化フレームワーク

OpsWorksはこのChefやPuppetによるインフラ設定・運用の仕組みをAWS上でマネージド型サービスとして提供している

OpsWorks for Chef Automation

Chefサーバーを作成し、継続的デプロイメントおよびコンプライアンスチェックのための完全マネージド型サーバーサービス

・ChefAutomationとは、Chefのcookbookやレシピを利用してインフラ管理を自動化するサービス ・インフラおよびアプリの継続的なデリバリーパイプラインを構成することが可能 ・リソースはChefサーバーから構成内容のアップデートを取得する ・オペレーション / コンプライアンス / ワークフローイベントを可視化することが可能 ・AWSでChefサーバを構成することができ、Chef Automate APIやChef DKなどのツールを利用することができる

OpsWorks for Puppet Enterprise

フルマネージド型Puppetマスターにより、アプリケーションのテスト・展開・運用を自動化する

・Puppetマスターは、インフラ内のノードを管理し、ノード情報を保存し、Puppetモジュールの中央リポジトリとして機能する ・PuppetマスターはソフトウェアおよびOSの設定・パッケージのインストール、データベースの設定、変更管理、ポリシー適用、モニタリングおよび品質保証証等のタスクを処理する全スタックを自動化することができる ・モジュールはインフラストラクチャの設定方法に関する手順が格納されたPuppetコードの再利用および共有が可能とするユニット ・Puppetを使用してEC2インスタンスやオンプレミスデバイスにあるノードの設定、デプロイ、管理方法を自動化できる

OpsWorksスタック

スタックとアプリケーションの作成および管理のためのシンプルで柔軟な方法を提供するオリジナルサービス ・スタック / レイヤー / インスタンス / アプリケーションと呼ばれるコンポーネントによりモデル化を実施する ・コードで構成管理やオートスケーリングが可能 ・Linux / Windouwsサーバーをサポート ・ライフサイクルイベントによるタスクの自動化が可能 ・OpsWorksエージェントがChef Clientのローカルモードでレシピを実行する ・スタックがOpsWorksのトップエンティティである全インスタンスの構成情報をJSON形式で管理している ・AWSOpsWorksスタックではChefサーバーは不要

Elastic Beanstalk VS OpsWorks

WEBアプリのデプロイに特化したElastic Beanstalkに対してOpsWorksは様々なアプリケーションに対応する高度なインフラ環境構築が可能

◾️Elastic Beanstalk 　アプリケーションの自動デプロイ化 　　ウェブアプリケーションに置いてサービスを使いなれたサーバーにおいてデプロイとスケーリングするためのサービス

◾️OpsWorks 　インフラの設定自動化 　　ChefやPuppetのマネージド型インスタンスのサーバーの設定・デプロイ・管理を自動化できるようになるインフラの設定管理サービス

CloudFormation

AWSクラウド環境内の全インフラリソースを記述してテンプレート化して展開する環境自動設定サービス

・プロビジョニングされたリソースの変更、削除が可能 ・追加リソースへの通常課金のみで追加料金なし ・JSON / YAMLで記述する ・クロスリージョンとクロスアカウントで管理 ・直接サポートされていないリソースや機能を利用する場合はカスタムリソースでスタック作成の一部に独自ロジックを組み込むことが可能

コンテナ

コンテナはホストマシンのカーネルを利用し、プロセスやユーザーなどを隔離する仮想化方式

Docker

Dockerはコンテナ型の仮想環境を作成、配布、実行するためのプラットフォーム

Amazonのコンテナサービス

◾️レジストリ 　コンテナエンジンに実行されるイメージが保管される場所 　Amazon ECR

◾️コントロールプレーン 　コンテナを管理するサービス 　Amazon ECS 　Amazon EKS

◾️データプレーン 　コンテナが実行される環境 　AWS Fargate

Elastic Container Service（ECS）

Dockerコンテナをサポートする拡張性とパフォーマンスに優れたコンテナオーケストレーションサービス

・コンテナ化されたアプリをAWSにおいて簡単に実行およびスケールできる ・Fargateを利用することでコンテナのデプロイと管理にサーバーのプロビジョニングや管理は不要 ・あらゆる種類のコンテナ化されたアプリケーションを簡単に作成できる ・Dockerコンテナの数が数十であっても数秒で簡単に起動 ・ELB / VPC / IAM / ECR / CloudWatch / CloudTrailなどのAWSサービスを利用可能 ・VPCネットワークモードでTask毎にENIを自動割り当てSecurity GroupをTask毎に設定可能 　VPC内の他のリソースへPrivate IPで通信が可能 ・Fargate起動タイプとEC2起動タイプという２種類のモードがある

Elastic Container Registry（ECR）

フルマネージド型のレジストリサービスでDockerコンテナイメージを簡単に保管、管理、デプロイが可能

・ECSとDockerCLIに統合されており、開発から本番稼働までのワークフローを簡略化する ・IAMによる強力な認証管理機構 ・エンドポイントにアクセスできるならAWS外からでも利用可能 ・ライフサイクルポリシーでイメージの自動クリーンアップできる ・VPCネットワークモードでタスク毎にENIを自動割り当てして、さらにセキュリティグループをタスク毎に設定可能

Amazon Elastic Kubernetes Service（EKS）

コンテナ化されたアプリケーションのデプロイ、管理、スケールをオープンソースのkubernetesを使って実行するサービス

・Kubernetesは自動デプロイ、スケーリング、アプリ・コンテナの運用自動化のために設計されたオープンソースのプラットフォーム ・Kubernetesのパートナーやコミュニティが作成した既存のプラグインやツールを使用可能 ・マネージド型サービスでありコントロールプレーンの管理が不要 ・ワーカーノードとマネージドコントロールプレーンとの間に暗号化処理された安全な通信チャネルを自動的にセットアップする ・Kubernetes環境で管理されるアプリケーションとの安全な互換性がある

AWS Fargate

サーバーやクラスターの管理なしにコンテナを実行するECSに対応したコンピューティングエンジン

◾️EC2起動モード 　・ECSでEC2インスタンスを起動する 　・コンテナアプリケーションを実行するインフラストラクチャーに対して、サーバーレベルの詳細なコントロールを実行可能 　・サーバークラスターを管理し、サーバーでのコンテナ配置をスケジュール可能 　・サーバークラスターでのカスタマイズの幅広いオプションが利用できる

◾️Fargate起動モード 　・ECSで設置できる専用のコンピューティングエンジン 　・EC2インスタンスのクラスターを管理する必要がない 　・インスタンスタイプの選択、クラスタースケジューリングの管理、クラスター使用の最適化は不要 　・CPU、メモリなどのアプリ要件を定義すると必要なスケーリングやインフラはFargateが管理する 　・秒で数万個のコンテナを起動

CodePipeline × CloudFormation

CloudFormationで設定したAWS環境に対してCodePipelineを使うことでテンプレートの変更・実行・展開を自動化する

CodePipeline × ECS

ECSで設定したDocker環境に対してCodePiplineを使うことでテンプレートの変更・実行・展開を自動化する

CloudFormationの概要

AWSクラウド環境内の全インフラリソースを記述してテンプレート化して展開する環境自動設定サービス ・プロビジョンニングされたリソースの変更、削除が可能 ・JSON / YAMLで記述する ・クロスリージョンとクロスアカウントで管理 ・直接サポートされていないリソースや機能を利用する場合はカスタムリソースでスタック作成の一部に独自ロジックを組み込むことが可能

環境構築を正確に実施しかつ効率的に展開したい時にCloudFormationを活用できる

・AWSリソースの構築を効率化したい ・開発、テスト、本番環境で利用するインフラを標準化したい ・毎回同じリソースやプロビジョンニング設定を正確に利用したい ・ソフトウェアと同じように環境構成を管理したい

CloudFormationの構成

テンプレートで定義された内容を読み込んでAWSリソースの集合であるスタックを作成する

CloudFormationの機能

CloudFormationテンプレート自体を管理・便利に使うための機能を提供

◾️変更セット 　スタックの更新を行う時の概要が変更セットで変更による影響度を確認するためのスタック 　スタック変更は直接更新と変更セットの実行で可能

◾️ドリフト 　テンプレートによって展開したAWSリソースを展開後に変更した場合に、元テンプレートとの差分を検出するチェック機能

◾️スタックセット 　複数のAWSアカウントと複数のリージョンに対してスタックを作成できる機能

◾️スタック間のリソース参照機能 　被参照テンプレートの参照値をエクスポートして値を抽出し、その後参照先のテンプレートのインポートによりリソース参照を行うことで連携したインフラ展開が可能になる機能

サーバーレスについて

疎結合化の追求

コンポーネントの疎結合

コンポーネント間の疎結合依存を減らした構成とすることで１つのコンポーネント変更や障害の影響を削減する

・関連する主要サービス Lambda、SQS、ELB、SNS

密結合の問題

密結合したアーキテクチャは障害や修正に弱く、不具合が発生しやすい

【密結合はデメリットが多い】 ・１インスタンスの障害の影響が全体に及びやすい ・１つの修正対応で穂可能インスタンスへの影響を多く考慮しなければならない ・負荷対応やスケーリングなども容易にできない ・システム構成の追加、変更が難しい

疎結合化のメリット

ELBやAPIなどを利用して結合点を削減したりメッセージ結合にすることで影響を減らすことができる

【疎結合化のメリット】 ・耐障害性が強まる ・負荷対応やスケーリングなどが容易 ・システム構成の追加、変更が容易

疎結合化向けサービス

サーバーレス化をするサービスやメッセージング処理をするサービスを利用して疎結合化する

◾️ELB 　サーバー間のトラフィック調整と連携をELBを起点に結ぶことで疎結合化を実現

◾️SQS 　SQSのキューイングによる通信でインスタンス関連携を結ぶことで疎結合化を実現

◾️SNS 　SNSのアプリケーション間通信でインスタンス間連携を結ぶことで疎結合化を実現

◾️Lambda 　サーバーインスタンスではなくLambdaによるトリガー処理で連携することで疎結合化を実現

通信系サービスによる疎結合

サーバー間の連携を直接結んで連携すると密結合となってしまう

疎結合設計

疎結合設計にはサーバーレス / キューイング通信 / マネージド型サービスの利用などを駆使した設計を行う

◾️密結合タイプの設計パターン 　・ユーザー認証、管理をバックエンドサーバーで処理 　・通常のEC2インスタンスでアプリケーションを構成 　・アプリケーション間では直接通信 　・静的ウェブシステムをEC2インスタンスEBSに保存

◾️疎結合化向けの設計パターン 　・ユーザー認証、管理をIAMなどのマネージド型サービスを利用 　・なるべくLambdaなどサーバレスでアプリケーションを構成 　・アプリケーション間ではSQSなどMQ通信で連携 　・静的ウェブシステムをVPC外部のS3に保存

SQSの概要

Amazon Simple Queue Service（SQS） プロセス間通信などのスレッド間通信に使われるコンポーネントで制御やデータを伝達するポーリング型キューサービス

ポーリングとは

複数のプログラム間通信に対し、一定のタイミングの問い合わせがあった場合に送受信処理を行う通信方式 直接通信だと受信側がBusyな場合に処理が滞る可能性がある

一旦中継所に通信内容をためておいて受信側のタイミングがいい時に通信を行う

SQSはキューをため込んでポーリング処理を実施するサービス

RequestキューとResponseキューにより送受信をキューイングすることができる

SQSの特徴

フルマネージド型で提供され、高可用性・高スケーラビリティ・高スループット・低コストを実現

・複数のサーバー / データセンターにメッセージを保持する高可用性構成 ・多数の送信者と受信者に対応可能なスケーラビリティの確保 ・メッセージが増加しても高スループットを維持できる ・無料枠と従量課金による低コスト

基本的には２５６KBまでの軽いデータしか利用できず、６０秒か１４日間メッセージを保持する ◾️メッセージサイズ 　メッセージの最大サイズは２５６KB 　Extended Client Libraryを利用すると２GBまでのメッセージの送受信が可能

◾️メッセージ保持期間 　削除されないメッセージはデフォルトで４日間保持 　保持期間は６０秒から１４日間で変更可能

◾️InFlightメッセージ 　１つのキューごとに最大１２０,０００In Flight（受信されたメッセージ＆Visibility Timeout内）メッセージ

キューのタイプ

SQSのキューメッセージ処理順序は２つの方式から選択する

・標準キュー ・FIFO（First in First out）キュー

標準キュー

順番通りに処理と１回だけのメッセージングをなるべく実施する処理

FIFOキュー

その名の通り最初に入ったキューを最初に処理する順番を守るキューイングを実施

SQSの機能

追加機能を利用することでキューイング処理を工夫することができる

◾️Short Poling 　キューが空でも即時にリターンする

◾️Long Poling 　キューが空の場合はタイムアウトまで待つ

◾️デッドレターキュー 　ずっと残ったメッセージを別キューに移動し、正常に処理できなかったメッセージを隔離する

◾️Visibility timeout 　新しいメッセージを指定時間見えなくする

Visibility timeout

Visibility timeoutを設定することで優先的に処理してほしい受信インスタンスを指定することが可能

SNSの概要

Amazon Simple Notification Service（SNS） Amazon SNSはフルマネージド型のプッシュ型通知サービスで他のサービスとの非同期通信を可能にする

送信側がトピックを作成して受信側をポリシー指定することで制御された非同期通信を実現する

SNSの特徴

AWSの様々なサービスと連携して通知可能で、疎結合アーキテクチャに利用できる

・単一発行メッセージ ・メッセージ通信順番は保証されない ・取り消し不可 ・配信ポリシーによる再試行を実施 ・メッセージサイズは最大２５６KB

・Amazon CloudWatch：Billing Alertの通知 ・Amazon SES：Bounce / Complaintのフィードバック通知 ・AmazonS3：ファイルがアップロードされた時の通知 ・Amazon Elastic Transcoder：動画変換処理完了 / 失敗時の通知

SNSとSQS

SNSとSQSはその処理方式が異なるため利用シーンに応じて使い分ける

◾️SNS 　・メッセージは永続ではない 　・プッシュ型配信方式 　・プロデューサーが発行 　・コンシューマーがサブスクライブ

◾️SQS 　・メッセージは永続性あり 　・ポーリング型配信方式 　・プロデューサーが送受信 　・コンシューマーが送受信

SESの概要

Amazon Sinple Email Service（SES） フルマネージド型 / サーバレス型のコスト効率に優れたEメールサービス

・スケーラブルな構成で信頼性が高いマネージド型 ・メール送信：トランザクションメールなどの高品質なコンテンツを顧客に送信可能 ・メール受信：受信したメールをトリガーにS3やLambdaなどを起動可能 ・バウンス処理：メールが送れなかった場合の処理を規定

SESのメール送信方法

単なるメールサーバーとして利用するだけでなく、アプリ自動でメール送信や連携処理に利用可能

◾️HTTP REST API ・SendEmail API：From / To / Subject / Bodyだけ用意すればSES側でメッセージを生成して送信する ・SendRawEmail API：メッセージ全体をアプリケーション側で生成して送信する ・認証：AWSアクセスキーとシークレットアクセスキーを使用

◾️SMTPエンドポイント ・生成済みEmailメッセージを受け取ってSESのSMTPエンドポイントを経由してメールを送信する 　SMTPを前提としてプログラムから直接利用する場合などに利用 ・利用ポート 　ー２５ 　ー４６５（SMTP over SSL） 　ー５８７（Message Submission） ・TLS（Transport Layer Security）が必要 ・認証：専用IAMユーザーを作成してそのクレデンシャルを使用

SESのメール受信

SESのメール通知を利用してS3やLambdaなどと連携が可能

SES利用準備

ドメイン登録やAWS上で利用できるメールとするための利用申請を事前にする必要がある

◾️ドメインを登録 ◾️メールの事前申請

サーバーレスによるサービス化

マネージド型サービスとサーバーレスアーキテクチャにより効率的な設計と運用を実現

・関連する主要サービス Lambda、SNS、SQS、ELB、SES、DynamoDB、AmazonAPIGateway、AmazonCognito

サーバレス化

サーバー（EC2インスタンス）ではなく、Lambdaなどのコンピュートサービスによるシステム構成をできる限り利用する

サーバレス化からサービス化へ

サーバレス設計によって疎結合設計が加速し、疎結合化によってマイクロサービス化されたアプリケーションが構築できる

サービス化

昔ながらのSOA方式から、より小さなプロセス単位のサービスをAPIで連携したマイクロサービスで設計する

◾️サービス指向アーキテクチャ（SOA） 　・一通りの機能が揃った大きなサービス単位でコンポーネントを分割する設計方式 　・アプリケーションをコンポーネント化して通信プロトコルによる連携で他のコンポーネントにサービスを提供するアーキテクチャ設計 　・ex.年金システムであれば給付サービス、徴収サービス、適用サービスなど

◾️マイクロサービス 　・SOAよりも小さな機能単位のプロセスでサービス化した構成 　・各プロセスでは１つの小さなタスクをサービスとして提供し、プロセス間通信はAPIを用いる

疎結合化とマイクロサービス化は表裏一体の関係となる

マイクロサービス化

大きなサービスを１つの作業が終了するコンテキスト単位に分割する

◾️SOAサービス 　・保険料徴収サービス 　・記録管理サービス 　・年金適用サービス 　・年金給付サービス

◾️マイクロサービス化 　・給付対象者決定業務 　・支払額算定業務 　・支払い決済業務

API活用

マイクロサービスはAPI通信によりコンポーネント間を疎結合化して利用される

サーバレス化のポイント

利用しているインスタンスが本当に必要か設計を見直す

Lambdaの概要

インフラを機にすることなくアプリケーションコードで実行できるデータ処理サービス

クライアントからのアクセスに対してデータを登録する単純な処理をEC2インスタンスに実行されていれば Lambdaに置き換えてサーバレスに実行処理することが可能

Lambdaの特徴

サーバレスによりEC2インスタンスの代わりコードを実行することで効率的なアーキテクチャを実現する

・実行基盤は全てAWSが管理 ・AWSサービスと連携させることで簡単にイベントドリブンなアプリケーションを実装可能 ・Node.js / Javaで書かれたコードを実行 ・１００ミリ単位でコード実行時間に対しての課金でありコスト効率が非常に高い ・オートスケール

Lambdaの仕組み

利用方法もシンプルでWEBアプリやモバイルアプリから簡単に利用可能

・Lambdaファンクションを用意する ・アプリからLambdaを呼び出す

イベント発生後に数ミリ秒以内にLambdaコードが実行される

・画像のアップロードをトリガーとして ・アプリケーション内の実行処理をトリガーとして ・ウェブサイトのクリックをトリガーとして ・接続デバイスからの出力をトリガーとして

Lambdaの起動

LambdaはPushモデルとPullモデルによって実行される

◾️Pushモデル S3 / Cognito / SNSなどのAWSサービスとカスタムイベントが直接実行することにより起動するLambdaファンクション 　・サービスもしくはアプリが直接実行する 　・順不同 　・３回までリトライ

◾️Pullモデル DynamoDBとKinesisなどのデータ処理はLambdaに対して直接的にイベント発行を行わないためLambdaがそれらへポーリングを行い自らイベントを取得 　・ストリームに入ってきた順に処理される 　・イベントソースとして登録したストリームに対してLambdaが自動的にデータ取得などのファンクションを実行する 　・イベントごとに複数レコードを取得可能 　・データが期限切れになるまでリトライ

Lambdaの起動：Pullモデル

Lambda自らがPullしてKinesisストリーム処理データのデータ項目を取得する

Lambdaの処理タイミング

他のAWSサービスやSDKを利用したモバイルもしくはWebアプリからの呼び出しが可能

◾️非同期実行 　リクエストが正常に受け付けられたというレスポンス内容が返ってくる

◾️同期実行 　実行完了時にLambdaファンクション内でセットしたレスポンスが返ってくる

Lambdaのパーミッション

Lambdaファンクション作成時にLambda側で自動で作成したり、クロスアカウントアクセスも設定可能

◾️Execution 　・LambdaファンクションがAWSリソースにどういったアクションを実施させるかを決定する 　・指定されたIAMロールにそってAWSのリソースへのアクセスが許可される

◾️Invocation 　・Lambdaファンクションをどのリソースが実行できるかを決定する

Lambdaの連携

様々なAWSサービスをトリガーとして起動するなどの連携処理が可能 ・Amazon S3、Kinesis、DynamoDB Stream 、Cognito（Sync）、SNS、Skills Kit、SWF

Lambdaの設定

１、コードをアップロードする 　直接エディタ記述 / S3インポート / Zip形式でアップロード ２、関数を設定 　スケジュール関数は実行頻度を指定 　イベント駆動型関数はイベントソースを指定 ３、必要なメモリ容量を指定する ４、タイムアウト時間を指定する ５、VPCアクセス用にVPCを指定する ６、関数を起動する

ブループリント

Lambdaファンクションをコーディングする際にサンプルコード集を利用することが可能

スケジュール機能

特定時刻をトリガーにしてLambdaファンクションを実行する

バージョニング

バージョンニング機能でのファンクションの一時点を記録管理することが可能

◾️バージョンの発行方法 ・Lambdaファンクションの作成や更新時にpublishパラメーターによりバージョンが発行される ・Publish Versionにより明示的にバージョンを発行することが可能

◾️バージョンの特徴 ・一度発行すると変更不可 ・単純にバージョン番号が増加する ・エイリアス（特定バージョンに対するポインタ）を設定して特定時点にマークすることが可能 ・エイリアスを作成することでバージョン番号を把握していなくても指定バージョンを呼び出せる

VPCアクセス

インターネットを経由せずにVPC内のAWSリソースへとアクセス可能になる

◾️VPC内のリソースへのアクセス 　・AWSの全てのVPC内リソースなどへインタネットを経由せずにアクセスが可能 　・Elastic Network Interface（ENI）を利用して実現 　　ENIには指定したサブネットのIPがDHCPで動的に割り当てられる

◾️アクセス制御 　・VPC内リソースにアクセスさせたいLamdbaファンクションに対してVPCサブネットおよびセキュリティグループを指定 　・ファンクションに割り当てるIAM RoleにAWSLambdaVPCAccessExecutionRoleというポリシーをアタッチしておくこと

ロードバランサー機能

ALBのバックエンドにLambdaを呼び出すことが可能になり、WEBアプリにLambdaファンクションを組み込みやすくなった

Lambdaユースケース

Amazon Echoの音声処理をトリガーとしてAlexaスキルを呼び出す

S3内のCloudTrailのログ分析により異常を検知した場合に、Lambdaを起動してメール通知する

Lambda起動のスケーリング

Lambdaファンクションでストリーミングデータの傾向に応じてスケーリングのトリガーとなる

Lambdaモバイルアプリ

モバイルからの写真管理をLambdaを通じて実施するなどモバイル連携も容易

Lambdaエッジ

Lambdaの機能とCloudFrontのエッジロケーション処理の機能を合わせたサービス CloudFrontにLambda機能を連携し、世界中でインフラをユーザーに近いロケーションでコードを実行が可能になる

イベントに関連づけられてLambdaファンクションがエッジロケーションで実行されて実行結果を返答する

API Gatewayの概要

API（Application programming interface）はシステムとシステムをつなぐ連結器

APIを通じてリクエストとレスポンスにより、他サービスの機能やデータを呼び出すことができる

◾️専門的には ・APIはアプリケーションソフトウェア開発に利用される標準的なインターフェース群のこと ・中でもWEB APIはWEB上で他のサービスを呼び出す方式や取り決め

APIの活用

自社アプリ、サービスをAPI化して連携を目指す方法と、API化された他社アプリ、サービスを活用する方法がある

◾️自社アプリ・サービスのAPI公開 　自社アプリ・サービスをAPI化して自社サービスとの連携してサービスを展開する

◾️他社アプリ・サービスのAPI活用 　他社APIサービスを活用して自社事業と組み合わせたアプリやサービスを展開する

APIエコノミー

APIエコノミーと自社サービスやデータをAPI化して社内外連携を促進し、ビジネス領域・価値を拡大させるビジネス活動

API利用の必要事項

APIの活用のためにはAPIを効率的に構築・運用・保守が十分にできる必要がある

・APIの作成、API利用状況の監視、APIのバージョン管理、APIの認証・アクセス管理

API Gateway

API作成 / 管理をフルマネージド型サービスで提供

・最大数十万個のAPI同時呼び出し、受付が可能 ・アクセス制御の管理 ・DDoS攻撃対応やスロットリングによるバックエンド保護 ・EC2 / Lambda / 任意のウェブアプリケーションのワークロード処理を実行する ・Lambdaと密接に統合されている ・WebSocketを利用したリアルタイムかつ双方向通信のAPIも処理可能

ユースケース

API Gatewayを連携口として外部アプリとの連携を実現する

ElastiCacheについて

ElastiCacheの概要

キャッシュの利用 繰り返し取り出すデータやコンテンツについてはキャッシュを利用する構成とする 関連する主要サービス ・CloudFront、ElastiCache、S3

インメモリキャッシュ

ElastiCacheはメモリ＋キャッシュというデータベース

データを保持するHW

PCなどの機器でデータを保存するためのHWはメモリとHDDなどのディスクがある

メモリ型DB

データをメモリ上で動作させるとディスク上で動作をさせる場合と比較して大幅に高速に処理が可能 つまりメモリDBをうまく利用することでデータの高速処理を実現できる

キャッシュとは

一度アクセスしたデータを保存して次回アクセス時に酵素きうにアクセスできるようにする仕組み

インメモリキャッシュとは

メモリを活用して高速にキャッシュへのアクセスを可能にしたデータベースの仕組み

ElastCache

分散インメモリキャッシュサービスの構築、管理およびスケーリングを容易に実施することができるサービス

・キャッシュクラスタを数クリックで起動 ・フルマネージド型でモニタリング、自動障害検出、復旧、拡張、パッチ適用、バックアップに対応し高可用性を実現

・広く利用されている２種類のエンジンmemcached、 /redisから選択可能

オープンソースのRedisとMemcachedを利用可能で汎用性あり ◾️Redis 　・高速に値をRead/Writeできるインメモリキャッシュ型DB 　・シングルスレッドで動作するインメモリキャッシュDBで全てのデータ操作は排他的 　・スナップショット機能がある 　・データを永続かできる

◾️Memcached 　・高速に値をRead / Writeできるインメモリキャッシュ型DB 　・マルチスレッドで動作するインメモリキャッシュDB 　・スナップショット機能がない 　・データを永続化できない 　・フェイルオーバーや復元ができない

シンプルに利用する場合はMemcachedを利用するが、それ以外はRedisを利用する場合が多い

◾️Redis 　・複雑なデータ型が必要である 　・インメモリデータセットをソートまたはランクつけする必要がある 　・読み込み処理の負荷に対して、リードレプリカにレプリケートする必要がある 　・pub / sub機能が必要 　・自動的なフェイルオーバーが必要 　・キーストアの永続性が必要 　・バックアップと復元の機能が必要 　・複数のデータベースをサポートする必要がある

◾️Memcached 　・シンプルなデータ型が必要 　・複数のコアまたはスレッドを持つ大きなノードを実行する必要がある 　・システムでの需要の増減に応じてノードを追加または削除するスケールアウトおよびスケールイン機能が必要 　・データベースなどのオブジェクトをキャッシュする必要がある 　・キーストアの永続性は必要ない 　・バックアップ復元の機能が必要でにあ 　・複数のデータベースを利用できない

ElastiCache with Redis

その他に位置情報クエリ / Luaスクリプトによる操作やpub / subモデルを活用可能

◾️Luaスクリプト 　・移植性が高く、高速な実行速度などの特徴を持っているスクリプト言語

◾️位置情報クエリ 　・経度、緯度などの位置情報をクエリ処理することが可能 　・検索距離や検索範囲の指定可能

◾️pub / subモデルの利用 　・イベントを起こす側とイベント処理を行う側を分離するのがpub / subモデル 　・メッセージ処理やイベント処理で活用

ユースケース

データアクセスを高速にしたいケースがあればキャッシュの活用を検討する ・セッション管理 ・IOT処理とストリーム分析 ・メタデータ蓄積 ・ソーシャルメディアのデータ処理 / 分析 ・Pub / Sub処理 ・DBキャッシュ処理

キャッシュすべきデータを特定して、他のDBと合わせて利用するのが標準的な構成方法 ◾️キャッシュ未使用パターン 　DBアクセス負荷が増大すると処理能力が低下し可用性が低下する

◾️インメモリキャッシュ利用パターン 　アクセス頻度の高いデータをキャッシュに配置して可用性を高める

ユースケース

アプリケーションでデータの即時反映が必要なケースなどに活用する

・ユーザーのマッチング処理 ・レコメンデーションの結果処理 ・画像データの高速表示 ・ゲームイベント終了時のランキング表示

CloudFrontの概要

AWSが提供するCDN（Content Delivery Network）サービス CDNはWEBコンテンツ配信処理を高速化するためのサービス

大規模なアクセスも世界中にエッジのあるキャパシティを活用して効率的かつ高速にコンテンツ配信が可能なサービス

・２１０以上のエッジロケーションによる高性能な分散配信 ・高いパフォーマンス ・AWS WAF / AWS Certificate Managerとの連携やDDoS対策によるセキュリティ機能 ・オリジンに対してHeader / Cookie / Query Stringsによるフォワード指定で、動的なページ配信が可能

Distribution設定

CloudFrontの配信設定を実施して各ドメインにて利用する

・各配信先となるドメインに割り当てるCloudFrontを設定する ・マネジメントコンソールやAPIより作成する ・WEB DistributionとRTMP Distributionを選択する ・使用量が最大４０Gbps / 10万RPS超は上限緩和申請を実施する ・独自ドメインを指定可能

・コンテンツオリジン設定：CloudFrontの配信ファイルの取得先の設定 ・アクセス設定：ファイルアクセスの許可設定 ・セキュリティ設定：アクセスにHTTPSを利用するかの設定 ・Cookieまたはクエリ文字列転送の設定：オリジンへのCookie / クエリ文字列の転送要否を設定 ・地域制限：特定の国のユーザーからアクセス拒否設定 ・アクセスログ設定：アクセスログを作成要否の設定

Adobeメディアを利用する場合は、RTMPディストリビュージョンを利用するが、通常はWEBディストリビュージョンを利用

◾️WEB Distribution 　・通常のHTTPプロトコルを利用したWEB配信をする際に利用 　・HTTP1.0 / HTTP1.1 / HTTP2に対応 　・オリジンはS3バケット / MediaPackageチャネル / HTTPサーバーを設定 　・HTTPやHTTPSを使用した静的および動的なダウンロードコンテンツ配信 　・Apple HTTP Live Streaming(HLS）やMicrosoft Smooth Streamingなど様々な形式のビデオオンデマンド

◾️RTMP Distribution 　・RTMP形式配信の際に利用 　・Adobe Media ServerとAdobe Real-Time Messaging Protocol（RTMP）を使用してメディアファイルをストリーミング 　・S3バケットをオリジン設定 　・クライアントはメディアファイル / メディアプレイヤー（JW Player、Flowplayer、Adobe Flash）を利用

Gzip圧縮機能

エッジ側でコンテンツをGZIP圧縮してより高速に配信可能

キャッシュコントロール機能

キャッシュコントロールによりキャッシュヒット率を上昇させて効果的なキャッシュ活用を可能にする

◾️パラメーター値の完全一致 　・URLとフォワードオプション機能（head / Cookie / Query Strings）のパラメーター値の完全一致でキャッシュが指定される仕組み 　・単一ファイルのキャッシュは最大２０GB 　・GET / HEAD / OPTIONリクエストを対象

◾️キャッシュ無効化 　・キャッシュが期限切れになる前に無効化することが可能 　・必要のないキャッシュを無効化することで効果的な利用を可能にする 　・コンテンツごとに最大３０００個まで無効化パスを指定できる 　・ワイルドカードを利用して最大１５個まで無効化パスリクエストが指定可能

セキュリティ機能

様々なセキュリティ設定によるセキュアなコンテンツ配信

・SSL配信書を設定して、コンテンツ配信時のHTTPS対応しており、ビューワーアクセスとオリジン配信時の暗号化通信が可能 ・オリジンカスタムヘッダーによる通信制御が可能 ・AWS WAFによるファイアーウォールと連携し、ディストリビューションに対するウェブリクエストを許可、ブロックが可能 　また、Referrer制限によるリンク参照禁止も可能 ・AmazonS3バケットからの配信の際にOAIとCloudFrontを指すカスタムドメインによってアクセス制限 ・AWS ShieldによるDDoS対応 ・著名付きURL / Cookieによる有効期限指定 ・GEOリストリクションによる地域情報でアクセス判定

CloudFrontの利用設計

キャッシュ対象を決定した上で、キャッシュ時間やセキュリティ制御を設計する

◾️キャッシュ対象設定 　・コンテンツ利用データ分析などを実施して静的コンテンツ / 動的コンテンツへのキャッシュ対象URLを設定する

◾️TTLの設定 　・変更が反映されるまでの時間も考慮してキャッシュ時間（TTL）を決定する

◾️その他の設定 　・セキュリティ対応等のその他の設定事項の要否を決定（SSL認証の有無 / HTTPSの有無）

データベースについて

データベースの基礎

データベースは関連したデータの形式を揃えて収集、整理して検索などの操作やデータ管理を実行するシステム データベースを実現したシステムを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 Hadoop

◾️ストリーミング処理向け 　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などのビックデータフレームワークを使用して大量データを処理・分析する