AWS 認定ソリューションアーキテクト – プロフェッショナル 合格への道#9

#はじめに

#学習
##5 mp
オンプレMYSQLからAWSへの移行を検討している。クライアントアプリの増加でDBのパフォーマンスが低下している。DBサイズは20TBですが将来的に毎年4TB増える見込み。二つ選べ

• ストレージとIO向けに高速化されたEC2インスタンスで稼働しているMYSQLを使用する。
  • DB on EC2はスケールがめんどくさい
  • auroraと比較して運用コストが高い
• Aurora MYSQL MultiAZ を使う
  • 正解
• RDS ORACLE MultiAZ を使う
  • oracleを選定する根拠がない
• AWS DMSを使用してデータを移行する
  • 正解
• mysqldumpユーティリティを使用してデータを移行する
  • 不正解

Amazon Aurora

クラウド向けに構築された、MySQL および PostgreSQL と互換性のあるリレーショナルデータベースです。商用データベースと同等のパフォーマンスと可用性を、10 分の 1 のコストで実現します。

利点

• 優れた性能と拡張性
  • 標準的な MySQL と比べて 5 倍のスループット、標準的な PostgreSQL と比べて 3 倍のスループットを実現しましょう。商業用データベースと同等のパフォーマンスを、10 分の 1 のコストで実現します。変更の必要に応じて、小さなインスタンスタイプから大きなインスタンスタイプに、データベースデプロイを簡単にスケールアップ/スケールダウンできます。
  • もしくは、Aurora Serverless が自動的に処理します。
    • Amazon Aurora (MySQL 互換エディションおよび PostgreSQL 互換エディション) のオンデマンド自動スケーリング設定
    • Aurora Serverlessが一般利用可能になったので試してみた
      • https://dev.classmethod.jp/articles/aurora-serverless-mysql-generally-available/
  • また、読み取りのキャパシティーとパフォーマンスをスケールするために、3 つのアベイラビリティーゾーン間でレイテンシーの低いリードレプリカを最大 15 個追加できます。Amazon Aurora のストレージは、必要に応じて、データベースインスタンスごとに最大 64 TB まで自動的にスケールされます
• 高可用性と耐久性
  • Amazon Aurora は 3 つのアベイラビリティーゾーンにわたってユーザーのデータを 6 個レプリケーションし、継続的に Amazon S3 にバックアップすることで、可用性が 99.99% を超えるように設計されています。物理ストレージの障害は透過的に復旧され、インスタンスのフェイルオーバーは通常 30 秒未満で完了します。また、数秒で過去のある時点にバックトラックして、ユーザーエラーから復旧することもできます。
  • Global Database を使用すれば、単一の Aurora データベースを複数の AWS リージョンで利用できるため、ローカルで高速な読み取りと迅速な災害復旧が可能になります。
    • [新機能] Aurora Global Database で複数のリージョンにレプリケーションが作成可能になりました
    • Aurora Global Database は、高速で性能への影響を最小限にDR環境を構築可能なAuroraのレプリケーション機能
    • 1つのプライマリリージョンと複数のセカンダリリージョンで作成が可能
    • Aurora（MySQL 5.7）- 2.07
• 高い安全性
  • Amazon Aurora では、データベースのために複数のレベルのセキュリティが用意されています。これらの機能には、Amazon VPC によるネットワーク分離、AWS Key Management Service (KMS) を介して作成および制御されるキーによる保管時の暗号化、移動中データの SSL による暗号化が含まれます。暗号化された Amazon Aurora インスタンスでは、基盤となるストレージが暗号化されます。さらに、同じクラスター内にある自動化バックアップ、スナップショット、およびレプリカも暗号化されます
• MySQL および PostgreSQL との互換性
  • Amazon Aurora のデータベースエンジンは、MySQL や PostgreSQL の既存のオープンソースデータベースと完全互換性があり、新しいリリースとの互換性も定期的に追加されています。このため、MySQL や PostgreSQL の標準的なインポート/エクスポートツールやスナップショットを使用して、MySQL データベースや PostgreSQL データベースを簡単に Aurora に移行
• フルマネージド型
  • Amazon Aurora は Amazon Relational Database Service (RDS) を使った完全マネージド型サービスです。そのため、ハードウェアのプロビジョニング、ソフトウェアのパッチ適用、セットアップ、構成、バックアップといったデータベース管理タスクについて頭を悩ます必要がなくなります。Aurora では、自動的かつ継続的にデータベースがモニタリングされ、Amazon S3 にバックアップされるため、きめ細かいポイントインタイムリカバリを実行できます。データベースパフォーマンスのモニタリングは、Amazon CloudWatch や拡張モニタリングを使用して行うことができます
  • Performance Insights という、パフォーマンスの問題を簡単に検出するための使いやすいツールもあります。
    • データベースの負荷をすばやく評価し、いつどこに措置を講じたらよいかを判断するのに役立つサービス
    • Amazon RDSパフォーマンスインサイトの使用
    • https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PerfInsights.html
• 移行サポート
  • MySQL や PostgreSQL との互換性により、クラウドへのデータベース移行先として Amazon Aurora に注目が集まっています。MySQL や PostgreSQL からの移行を検討しておられる方は、移行に関するドキュメントでツールやオプションのリストをご覧ください。商業用データベースエンジンから移行する場合は、AWS Database Migration Service を使用すれば、ダウンタイムを最小限に抑えつつ安全に移行できます。
  • AWS Database Migration Service
  • https://aws.amazon.com/jp/dms/

AWS Database Migration Service

ユースケース

• 同種のデータベース間での移行
  • 同種のデータベース間での移行では、ソースとターゲットのデータベースエンジンが同じ、または Oracle から Amazon RDS for Oracle、MySQL から Amazon Aurora、MySQL から Amazon RDS for MySQL、Microsoft SQL Server から Amazon RDS for SQL Server のように互換性があります。スキーマ構造、データ型、およびデータベースコードが、ソースとターゲットのデータベース間で互換性があるため、この種の移行は 1 回の処理で行えます。
• データベースの異種間移行
  • データベースの異種間移行では、Oracle から Amazon Aurora、Oracle から PostgreSQL、または Microsoft SQL Server から MySQL といった場合のように、ソースとターゲットのデータベースのエンジンが異なります。この場合、スキーマ構造、データ型、およびソースデータベースとターゲットデータベースのコードが大きく異なっており、データ移行を開始する前にスキーマとコードの変換が必要となります。そのため、異種データベース間で移行するには、2 つのステップが必要です。まず、AWS Schema Conversion Tool を使用してソースのスキーマとコードをターゲットデータベースのスキーマとコードに適合するように変換し、その後、AWS Database Migration Service を使用してソースデータベースからターゲットデータベースにデータを移行
• 開発とテスト
  • AWS Database Migration Service を使用すると、開発を目的としたクラウド内外へのデータ移行を実施できます。これには、2 つの一般的なシナリオがあります。1 つ目は、開発、テスト、ステージング用のシステムを AWS にデプロイし、クラウドの拡張性と迅速なプロビジョニングを活用することです。この方法で、開発者とテスターは、実際の本番データのコピーを使用でき、更新した内容をオンプレミスの本番システムにコピーして戻すことができます。2 つ目のシナリオは、開発システムがオンプレミス (または個人のノート PC) にあり、このようなオンプレミスシステムに AWS クラウドのプロダクションデータベースの現在のコピーを 1 回または継続的に移行する場合
• データベースの統合
  • AWS Database Migration Service を使用して、複数のソースデータベースを単一のターゲットデータベースに統合できます。データベースの統合は、同種間および異種間の移行で利用可能で、またこの機能はサポートされているすべてのデータベースエンジンでご利用いただけます。ソースデータベースとして、AWS 外部のお客様の設備内に位置するデータベース、実行中の Amazon EC2 インスタンス内のデータベース、または Amazon RDS のデータベースを利用できます。ソースデータベースを異なる場所に分散することもできます。例えば、ソースデータベースの 1 つを AWS 外部にあるお客様の設備内に、2 つ目を Amazon EC2 内に、3 つ目を Amazon RDS database に配置できます。ターゲットは Amazon EC2 または Amazon RDS 内のデータベースにすることができます。
• 継続的なデータレプリケーション
  • AWS Database Migration Service を使用して、継続的なデータレプリケーションを実行できます。継続的なデータレプリケーションのユースケースとして、災害対策のためのインスタンス同期、データベースの地理的分散、および開発/テスト環境の同期などさまざまな用途が考えられます。DMS は、サポートされているすべてのデータベースエンジンについて、同種間と異種間両方のデータレプリケーションに使用できます。ソースデータベースや複製先データベースは、AWS 外部にあるお客様の設備内、実行中の Amazon EC2 インスタンス内、または Amazon RDS データベース内のデータベースに配置できます。単一のデータベースから 1 つ、または複数のターゲットデータベースにデータをレプリケートする、または複数のソースデータベースからのデータを統合して、それを 1 つ、または複数のターゲットデータベースにレプリケートすることが可能

【MySQL入門】データベースをdumpする！不測の事態に備えよう

6 ds 〇

ゲノム解析の計算をアプリケーションが実行している。各計算は独立しており、数時間程度。
アプリケーションはコストと相互関係依存を最小限にし独立した計算が平行に実行されるようにしたい。

• AWS Batchにジョブとして計算を登録。ジョブをECSのコンテナ内で実行
• 計算をAPIGatewayに送信する。Lammbdaで計算を実行
• 各計算をマスターEC2に送信。計算を適切な作業者EC2ノードに送信
• 計算をALBに送信。作業者ノードに各計算を振り分け。

AWS再入門ブログリレー AWS Batch編

• AWS Batchの特徴
  • フルマネージド型のサービス
  • 依存関係のあるジョブ実行が可能
  • ジョブキューに優先度を持たせ、利用リソースの最適化を図れる
• AWS Batchの基礎用語
  • ジョブ(Jobs)
    • 「マルチノードの並列ジョブ」と「配列ジョブ」
      • マルチノードの並列ジョブ: 複数のEC2インスタンスにまたがり(マルチノード)処理する 単一のジョブ
      • 配列ジョブ: 並列ジョブを大量に処理するのに有効な、実行時に依存関係が存在している 複数の子ジョブを持つジョブ
        • SEQUENTIALタイプの依存関係
  • ジョブ定義(Job Definitions)
    • 単一ジョブのジョブ定義作成に必要な要素
      • ジョブ定義名
      • コンテナイメージ(ジョブ実行に使用するDockerイメージ)
      • コンテナに渡すコマンド(コマンド形式/JSON形式)
      • コンテナ用に用意するvCPUの数
      • ジョブのコンテナに適用されるメモリのハード制限
    • マルチノードの並列ジョブのジョブ定義作成に必要な要素
      • ジョブ定義名
      • 複数ノード設定が必要なジョブ(要チェック)
        • ノード数(デフォルト: 1)
        • 主要ノードで使用するノードインデックス(デフォルト: 0)
      • 各ノードグループのプロパティ
        • コンテナイメージ(ジョブ実行に使用するDockerイメージ)
      • コンテナに渡すコマンド(コマンド形式/JSON形式)
      • コンテナ用に用意するvCPUの数
      • ジョブのコンテナに適用されるメモリのハード制限
  • ジョブキュー(Job Queues)
    • キューの名前
    • (同じコンピューティング環境と紐付いている)ジョブキューの優先度
    • ジョブキューの有効化(デフォルト: 有効化)
    • コンピューティング環境(後述)
  • コンピューティング環境(Compute Environments)
    • コンピューティング環境名
    • サービスロール(新規作成する時は必要ロールが自動作成されるので空欄で可)
    • インスタンスロール(新規作成する時は必要ロールが自動作成されるので空欄で可)
    • EC2キーペア(SSHを使用してインスタンスに接続したい場合)
    • コンピューティング環境の有効化(デフォルト: 有効化/変更不可)
    • プロビジョニングモデル
      • オンデマンド
      • スポット
        • スポットフリートロール(要事前作成)
    • インスタンスタイプの指定(デフォルト: optimal)
    • コンピューティング環境で維持するEC2 vCPUの最小数(デフォルト: 0)
    • コンピューティング環境の起動に必要なEC2 vCPUの数(デフォルト: 0)
    • コンピューティング環境でスケールアウトできるEC2 vCPUの最大数(デフォルト: 256)
    • EC2インスタンスを起動するVPCのID(デフォルト: デフォルトVPC)
    • EC2インスタンスを起動するサブネット(デフォルト: デフォルトVPCの全てのサブネット/最低1つは要指定)
    • EC2インスタンスに適用するセキュリティグループ(デフォルト: デフォルトVPCのデフォルトセキュリティグループ)

7

アプリケーションをデータセンタからAWSへ移行する。アプリケーションは現在サードパーティーへのアクセスをするAPIキーをローカルに保存している。AWSにデプロイするとアプリケーションはEC2に配置される。以降の一環としてAPIキーは厳重に保管したい。
要件：

• 各環境には独自のAPIキーが必要
• 監査目的のためすべてのAPIキーのアクセスログを保管したい
• apiキーはカスタマーマネージドキーを使って保存時に暗号化される
• アクセス権限はガチでやりたい(開発は本番環境のapiキーにアクセスできないなど)

---

• apiキーについてシステムパラメータストアでSECURE STRINGを作成する。CMKでSSを暗号化する。CMKについてはkms:decrypt,SSについてはssm:getparmeterに権限を持つIAMユーザを環境に配置。そのユーザのアクセスキーをEC2資格情報ストアに配置
• apiキーについてシステムパラメータストアでSECURE STRINGを作成する。CMKでSSを暗号化する。CMKについてはkms:decrypt,SSについてはssm:getparmeterに権限を持つIAMユーザを環境に配置。適切なIAMロールでEC2を実行。
• CMKで暗号化されたDynamoDBテーブルを作成する。環境のキーをアイテムとして保管。CMKについてはkms:decrypt,DB
  についてはDynamoDB:getitemに権限を持つIAMユーザを環境に配置。適切なIAMロールでEC2を実行。
• ユーザデータを利用してAPIキーを渡す。CMKについてはkms:decrypt,SSについてはssm:getparmeterに権限を持つIAMユーザを環境に配置。適切なIAMロールでEC2を実行。
  • ユーザデータはアウト

↑本来はこうあるべきだと思います。

AWS Systems Manager パラメータストア

AWS Systems Manager パラメータストア は､設定データ管理と機密管理のための安全な階層型ストレージを提供します。パスワード、データベース文字列、EC2 インスタンス ID、Amazon マシンイメージ (AMI) ID、ライセンスコードなどのデータをパラメータ値として保存できます。値はプレーンテキストまたは暗号化されたデータとして保存できます。パラメータの作成時に指定した一意の名前を使用して、スクリプト、コマンド、SSM ドキュメント、設定および自動化ワークフローの Systems Manager パラメータを参照できます。

パラメータのタイプと例

パラメータストア パラメータとは、テキストのブロック、名前のリスト、パスワード、Amazon マシンイメージ (AMI) ID、ライセンスキーなど、パラメータストア に保存されるデータのことです。スクリプト、コマンド、SSM ドキュメントで、このデータを一元的かつ安全に参照

パラメータタイプ

• 文字列
• StringList
• SecureString
  • SecureString パラメータタイプは、パスワード、アプリケーションシークレット、機密設定データ、保護する必要があるその他のタイプのデータなど、暗号化するテキストデータに使用できます。SecureString データは、AWS Key Management Service (KMS) キーを使用して暗号化および復号化されます。AWS が提供するデフォルトの KMS キーを使用するか、独自のカスタマーマスターキー (CMK) を作成して使用することができます。

SecureString パラメータ

SecureString パラメータは、セキュアな方法で保存および参照する必要がある機密データです。パスワードやライセンスキーなど、ユーザーがプレーンテキストで変更または参照しないデータがある場合は、SecureString データ型を使用してこれらのパラメータを作成します。

次のシナリオでは SecureString パラメータを使用することをお勧め

• コマンド、関数、エージェントログ、または AWS CloudTrail ログに値をプレーンテキストとして公開せずに、すべての AWS のサービスでデータ/パラメータを使用する。
• 機密データへのユーザーのアクセスを制御する。
• 機密データへのアクセスを監査する (AWS CloudTrail)。
• 機密データの暗号化と独自の暗号化キーがアクセスの管理に必要である。

ユースケースとベストプラクティス

• パラメータストア を使用して AWS Key Management Service で秘密情報を暗号化および管理
  • secure string パラメータを作成して､機密データを管理することができます。Parameter Store は、AWS KMS カスタマーマスターキー (CMK) を使用して、secure string パラメータを作成または変更する際にそのパラメータ値を暗号化します。また、アクセス時に CMK を使用してパラメータ値を復号化します。Parameter Store がアカウント用に作成する AWS 管理の CMK を使用するか、独自のカスタマー管理 CMK を指定することができます。
    • Parameter Store は、対称 CMK のみをサポートします。非対称 CMK を使用してパラメータを暗号化することはできません。
  • パラメータ値を暗号化および復号するためのアクセス許可の設定
    • ユーザーが標準 secure string パラメータの値を暗号化するには、kms:Encrypt アクセス許可が必要です。ユーザーがアドバンスト secure string パラメータの値を暗号化するには、kms:GenerateDataKey アクセス許可が必要です。ユーザーがいずれかのタイプの secure string パラメータの値を復号化するには、kms:Decrypt アクセス許可が必要です。
    • IAM ポリシーを使用し、ユーザーに対して Systems Manager PutParameter および GetParameter オペレーションを呼び出すためのアクセス許可を許可または拒否できます。
• パラメータストア パラメータから AWS Secrets Manager シークレットを参照

8　dc ×

オンプレからデータをS3に定期的に転送している。セキュリティポリシー上、転送中と保管中は暗号化される必要がある。またパブリックインターネッツを通過していけない。S3バケットとそのコンテンツにはオンプレからとピアリングされているVPCからしか接続は許可されない。会社にはすでにプライベート仮想インタフェースを持ったDXがあり、S3バケットは暗号化されている。

• パブリック仮想インタフェースを追加。S3ポリシーにセキュアな転送を使わないリクエストを拒否するポリシーを追加する。バケットポリシーに会社のIPからトラフィックを許可するよう追加
  • S3への経路がパブリックネットワークを通過する
• DX上にVPN接続を確立する。S3VPCエンドポイントを作成。セキュアな転送を義務付けるようにバケットポリシーを変更。EC2でトラフィックをオンプレからS3VPCエンドポイントにプロキシする。
  • EC2を介する根拠
• S3VPCエンドポイントを作成。セキュアな転送を義務付けるようにバケットポリシーを変更。EC2でトラフィックをオンプレからS3VPCエンドポイントにプロキシする。
  • DX上の通信が暗号化されていないためアウト
• パブリック仮想インターフェースを追加してDX上にVPN接続を追加。S3VPCエンドポイントを作成。セキュアな転送を義務付けるようにバケットポリシーを変更。
  • 正解

DX BL

AWS Direct Connect 接続で AWS VPN を確立する方法を教えてください。

DX 接続で VPC への AWS VPC 接続を確立すると、インターネット経由の VPC よりも速くて安全です。DX 接続の AWS VPN 接続では、一貫性のあるスループットレベルを確保し、データを保護する暗号化アルゴリズムを実現します。

AWS Direct Connect とは

仮想インターフェイス

AWS のサービスへのアクセスを有効にするには、仮想インターフェイスを作成します。パブリック仮想インターフェイスにより、Amazon S3 などパブリックサービスへのアクセスが有効になります。プライベート仮想インターフェイスは、VPC へのアクセスを有効にします。

プライベートネットワーク経由でAWS S3にアクセスする7つのアーキテクチャの紹介

↓これ好き