3.1スケーラビリティと弾力性

回復力の第一歩は需要に追従する弾力性です。Auto Scaling と ELB で、負荷に応じて自動的に容量を増減します。

3.1.1Auto Scaling とスケーリングポリシー

• ターゲット追跡：指標（例: CPU 50%）を維持するよう自動増減。最も手軽。
• ステップスケーリング：閾値ごとに段階的に増減量を変える。
• スケジュール/予測：既知のピーク時刻やML 予測に合わせて事前に増設。
• ライフサイクルフック：起動/終了時に初期化やドレインを挟む。ヘルスチェック失敗は自動置換。

DOP-C02 では「需要パターンに最適なスケーリングをどう自動化するか」が問われます。ターゲット追跡は CloudWatch 指標（CPU・ALB のリクエスト数/ターゲット など）を目標値に保つよう増減し、設定が最も簡単で多くのケースの既定解です。ステップスケーリングはアラームの逸脱幅に応じて段階的に台数を変え、急激な負荷変動に強い制御を与えます。スケジュールは決まった時刻（営業開始・キャンペーン）に、予測スケーリングは過去の周期から ML で先回りして容量を確保します。ライフサイクルフックは Pending:Wait/Terminating:Wait 状態で処理を差し込み、起動時の構成（State Manager や user data でブートストラップ）や終了時のコネクションドレイン・ログ退避を確実にします。ウォームプールを使えば、事前に初期化済みのインスタンスを停止状態で保持し、スケールアウトの遅延を縮められます。インスタンスの定義は 起動テンプレート（Launch Template）で行い、混合インスタンスポリシーで On-Demand と Spot を組み合わせてコストと可用性を両立します。ECS ならサービスオートスケーリング、Lambda ならプロビジョンド/予約済み同時実行が対応概念です。スケールの健全性は ELB ヘルスチェックを ASG のヘルスチェックタイプに採用することで、アプリ層の異常まで検知して置換できます。

3.1.2Compute Optimizer — 適正サイズ推奨

Compute Optimizer は EC2 インスタンス・Auto Scaling グループ・Lambda 関数・EBS ボリュームの実際の使用状況を機械学習で分析し、過剰スペック（コスト増）や過少スペック（性能劣化）を検知して適正なリソースタイプ・サイズを推奨します。推奨は CloudWatch メトリック（CPU・メモリ・スループット等）の過去 14 日（最大 3 か月）を元に生成され、現構成との比較でコスト削減率と性能リスクが明示されます。DevOps 文脈での役割は「弾力性の前提を整える」こと——適正サイズのインスタンスでスケーリングすることで、オーバープロビジョニングのムダを排除しつつ必要な時だけ増やすコスト最適化を実現します。スケーリングポリシーを決める前に Compute Optimizer の推奨を確認し、ベースラインを正しく設定することが DOP-C02 で問われる実践的アプローチです。

3.1.3FSx ファミリー — ワークロード別共有ファイルストレージ

Amazon FSx は 4 種類のマネージドファイルシステムを提供します。FSx for Windows File Server は SMB プロトコルと Active Directory 統合を備え、Windows アプリや .NET ワークロードが共有ドライブとして使います。FSx for Lustre は 高性能並列ファイルシステムで HPC・機械学習・動画処理など I/O 集約のバッチに適し、S3 とシームレスに連携（S3 バケットをデータリポジトリとして参照/書き戻し）できます。FSx for NetApp ONTAP は NetApp の ONTAP 機能（スナップショット・重複排除・圧縮・マルチプロトコル NFS/SMB/iSCSI）をマネージドで提供し、オンプレの ONTAP ワークロードの lift-and-shift に適します。FSx for OpenZFS は OpenZFS ベースで、低レイテンシの NFS ファイルサーバーをシンプルに置き換えるユースケースに向きます。いずれも Multi-AZ または Single-AZ 配置を選べ、マネージドのためファイルサーバー OS の管理が不要です。

3.1.4データ層 — スケーラブルなデータベース選択

スケーラビリティと弾力性の文脈では、データ層の選択が重要です。Aurora Serverless v2 は Aurora (MySQL/PostgreSQL 互換) の自動スケール版で、0.5 ACU 単位で需要に応じてシームレスにスケールアップ/ダウンします。ピーク負荷が予測しにくい変動ワークロードに向き、アイドル時のコストを最小化できます。DocumentDB は MongoDB 互換のドキュメントデータベースで、ネストした JSON ドキュメントを扱うアプリの移行・構築に使います。Amazon MemoryDB（旧 MemoryDB for Redis。現在は Redis OSS / Valkey 互換）は インメモリデータベースで、ElastiCache との大きな違いはすべての書き込みをマルチ AZ のトランザクションログに永続化する点——ElastiCache はキャッシュ層（主記憶はほかにある前提）ですが、MemoryDB はプライマリ DB として使えるほどの耐久性を持ちます。Redshift は 列指向の DWH（データウェアハウス）で、大量の構造化データに対する分析クエリを並列処理し、S3 上の外部テーブルも直接クエリできます（Redshift Spectrum）。

3.1.5EKS Distro — 一貫した Kubernetes を自己管理環境で

EKS Distro は Amazon EKS が使用するのと同じ Kubernetes ディストリビューション（コンポーネントバイナリ・コンテナイメージ） をオープンソースで提供します。オンプレミスや他クラウドなど自己管理の環境でも、AWS 本番 EKS と同一のバージョン・セキュリティパッチ・コンポーネントで Kubernetes を運用できるため、マルチクラウド/ハイブリッド構成での Kubernetes バージョン統一に役立ちます。EKS Distro 自体のコントロールプレーン管理は利用者が行いますが、AWS から提供されるパッチサイクルに追従できます。

フルマネージドな Kubernetes プラットフォームを使いたい場合は ROSA（Red Hat OpenShift Service on AWS）が選択肢です。AWS と Red Hat が共同提供するマネージド OpenShiftで、OpenShift のエコシステム（開発者向けの CI/CD・ビルダー・Operator）と運用体験をそのまま AWS 上で使え、コントロールプレーンの運用は任せられます。既存の OpenShift ワークロードを AWS へ移行したい、または OpenShift 標準で社内を統一したい組織が、EKS（純正 Kubernetes）の代わりに選びます。

3.1.6データベース移行（Database Migration Service）

Database Migration Service（AWS DMS）は、データベースを最小限のダウンタイムで移行するサービスです。ソース（オンプレ/他クラウド/RDS 等）から RDS・Aurora・Redshift・DynamoDB・S3 などへデータを継続的にレプリケートし、CDC（変更データキャプチャ）で移行中の差分も追従するため、本番を止めずに切り替えられます。異種エンジン間（例: Oracle→Aurora PostgreSQL）の移行ではスキーマ変換ツール（SCT/DMS Schema Conversion）と併用します。DevOps 文脈では、移行や DR のデータ同期をパイプラインから自動化し、繰り返し可能な移行手順として組み込めます。

3.1.7この節のまとめ

• 弾力性＝Auto Scaling＋ELB
• ポリシー＝ターゲット追跡/ステップ/スケジュール/予測
• 適正サイズ＝Compute Optimizer（スケーリング前のベースライン確認）
• ファイルストレージ＝FSx 4 種（Windows/Lustre/ONTAP/OpenZFS）
• データ層＝Aurora Serverless v2/DocumentDB/MemoryDB/Redshift／移行＝DMS
• K8s＝EKS Distro（ハイブリッド）/ROSA（マネージド OpenShift）