セキュリティと運用について
セキュリティの確保
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も処理可能
ユースケース
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を設定する
データベースについて
データベースの基礎
データベースは関連したデータの形式を揃えて収集、整理して検索などの操作やデータ管理を実行するシステム データベースを実現したシステムを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
