AWSについて

 ストレージ

AWSは、さまざまなストレージニーズに対応するオプションを提供しています。以下に主要なカテゴリを詳しく解説します。

ブロックストレージ

• Amazon Elastic Block Store (EBS): EC2インスタンスにアタッチされるブロックストレージで、ハードディスクのように使用可能です。EBSボリュームはインスタンス終了後もデータが保持されます。
• インスタンスストア: 一部のEC2インスタンスタイプに付属する一時的なストレージで、インスタンス停止時にデータが失われます。高速なI/Oが必要なワークロードに適しています。

ファイルストレージ

• Amazon Elastic File System (EFS): 完全に管理されたファイルシステムで、Linuxベースのワークロードに最適です。NFSv4プロトコルを使用し、自動的にスケーリングします。複数のAZにまたがる高可用性が特徴です。
• Amazon FSx: さまざまなファイルシステムをクラウドで管理可能にします。
  • FSx for Windows File Server: Windows環境向け、SMBプロトコル対応。
  • FSx for Lustre: 高性能コンピューティング（HPC）や機械学習に適し、大規模データ処理に最適。
  • FSx for NetApp ONTAP: NetAppの機能をクラウドで利用可能、NFS/SMB/iSCSI対応。
  • FSx for OpenZFS: OpenZFSのスナップショットやデータ整合性チェック機能を活用。

EFSとFSxの選択基準は、ワークロードのOSやパフォーマンス要件によります。例えば、LinuxベースのウェブアプリケーションではEFSが適し、Windowsベースのファイル共有が必要な場合はFSx for Windows File Serverを選ぶと良いでしょう。

オブジェクトストレージ

• Amazon Simple Storage Service (S3): 耐久性が高く（11ナイン、年間99.999999999%の耐久性）、スケーラブルなオブジェクトストレージです。バックアップ、データレイク、メディアストレーミング、静的ウェブサイト、アーカイブなどに利用されます。
• バケットとオブジェクト: バケットはオブジェクトを格納するコンテナで、オブジェクトはファイルとそのメタデータ（例：写真の撮影日時や場所）を含みます。
• アクセス制御: デフォルトはプライベート設定で、他のユーザーはアクセスできません。パブリック設定はセキュリティリスクが高いため非推奨で、バケットポリシーやアクセスポイントを活用することが推奨されます。例えば、バケットポリシーを使用して特定のIAMロールのみアクセスを許可する設定が可能です。
• 暗号化: SSE-S3（S3管理キー）やKMSキー、カスタマー提供キー（SSE-C）でデータを保護できます。KMSキーはキーのローテーションや監査が容易です。
• ストレージクラス:
  • S3 Standard: 高いアクセス頻度でミリ秒単位のアクセスが必要な場合。コストは高いがパフォーマンスが優れる。
  • S3 Standard-IA: アクセス頻度が低いデータで、コストを抑えたい場合。
  • S3 One Zone-IA: 1つのAZに保存され、コストがさらに低い。災害復旧には不向き。
  • S3 Glacier: 長期保存向けで、復元が必要な場合に使用。zipファイルのようなイメージで考えられます。
  • S3 Glacier Deep Archive: コストが最も低いが、復元に12時間かかり、復元コストが高い。
  • S3 Intelligent-Tiering: アクセスパターンに基づき自動的にクラスを変更。30日間アクセスがないと低頻度アクセス階層へ、90日間ないとアーカイブへ移行。
• バージョン管理: オブジェクトの複数のバージョンを保持し、誤削除や変更から保護。
• ライフサイクルポリシー: オブジェクトの保存日数に基づき、ストレージクラスを自動移行（例：ログデータの長期保存）。
• レプリケーション: 同一リージョン内やクロスリージョンでデータを複製可能。静的機能のため、手動設定が必要です。
• マルチパートアップロード: 大きなファイルを分割してアップロードし、効率化。
• 転送加速: 長距離データ転送を高速化し、エッジロケーションを利用。
• イベント通知: S3にオブジェクトがアップロードされた際にLambda関数やSNSトピックに通知可能。

ベストプラクティス

• バケットポリシーでアクセス制御を細かく設定し、パブリックアクセスを避ける。
• ライフサイクルポリシーでコスト最適化を図り、アクセス頻度が低いデータは安価なクラスに移行。
• バージョン管理を有効にして、データ損失リスクを低減。
• 暗号化を活用し、データ保護を強化。

共有ファイルシステム

共有ファイルシステムは、複数のインスタンスやユーザーが同時にアクセス可能なストレージを提供します。

• Amazon EFS:
  • Linuxベースのワークロード向けで、NFSv4プロトコルを使用。
  • 自動スケーリングで容量とパフォーマンスを調整可能。
  • 高可用性で、複数のAZにデータがレプリケート。
  • 利点: バーストスループットモードで使用量に応じたスケーリング、低頻度アクセスや1ゾーン選択でコスト削減可能。
• Amazon FSx:
  • オープンソースや一般的なファイルシステムをクラウドで提供。
  • FSx for Windows: Windows環境向け、SMBプロトコル対応。
  • FSx for Lustre: HPCや機械学習向け、高速データアクセス。
  • FSx for NetApp ONTAP: NetAppの機能をクラウドで利用。
  • FSx for OpenZFS: OpenZFSのスナップショット機能を利用。
  • 利点: ハードウェア管理やパッチ適用が不要で、バックアップも自動化。

選択基準

• EFSはLinuxベースの共有ストレージが必要な場合に最適。
• FSx for WindowsはWindowsワークロードやActive Directory統合が必要な場合。
• FSx for Lustreは大規模データ処理やHPCに適し、FSx for NetApp ONTAPはNetApp環境のクラウド移行に。

データ移行ツール

• AWS Storage Gateway: オンプレミスとクラウドのハイブリッド環境で使用。オブジェクト保存をクラウドに。
• AWS DataSync: オンプレミスとS3/EFS/FSx間で大量データ転送を効率化。
• AWS Snowファミリー: ネットワーク環境が限定的な場合に物理デバイスでデータ移行。SnowconeやSnowball Edgeでペタバイト規模の移行も可能。

データベース

AWSのデータベースサービスは、リレーショナルと非リレーショナルの両方をカバーし、さまざまなニーズに対応します。

リレーショナルデータベースと非リレーショナルの比較

• リレーショナル（SQL）データベース:
  • 行と列のテーブル形式で、厳格なスキーマルールが必要。
  • データ品質確保や複雑なクエリに適し、読み書き負荷が低い場合に有効。
  • 例: MySQL、PostgreSQL。
• 非リレーショナル（NoSQL）データベース:
  • キーと値、ドキュメント、グラフなど柔軟なモデル。
  • 水平スケーリングが必要な場合や、スキーマが変化するデータに適。
  • 高速な読み書きが必要な場合に有効。
  • 例: DynamoDB。

マネージドサービスとアンマネージドサービスの選択

• マネージドサービス: RDSやDynamoDBのように、AWSがバックアップやパッチ適用を管理。推奨される。
• アンマネージドサービス: EC2上でデータベースソフトウェアをインストールし、自力で管理。特定のバージョンが必要な場合に選択。

Amazon RDS

• サポートエンジン: Aurora、PostgreSQL、MySQL、MariaDB、Oracle、SQL Server。
• マルチAZ配置: 2つのAZに配置し、プライマリDB障害時に自動フェイルオーバー。
• リードレプリカ: 読み取り専用DBを用意し、読み込み負荷分散。
• 暗号化: KMSキーによるデータ保存時暗号化。

Amazon Aurora

• AWS独自のサービスで、MySQL/PostgreSQLと互換性あり。
• パフォーマンスはMySQLの5倍、PostgreSQLの3倍。
• Aurora Serverless: コンピューティング管理不要で、課金は呼び出し回数ベース。

Amazon DynamoDB

• NoSQLデータベースで、フルマネージド。
• 容量とスケーリング: オンデマンド（リクエストごと課金）またはプロビジョニング済み（RCU/WCU設定）。
• 整合性オプション: 強力な整合性（1RCU使用）や結果整合性（0.5RCU使用）。
• グローバルテーブル: リージョン間レプリケーション自動化。

データベースキャッシング

• ElastiCache: MemcachedやRedisでキャッシュを管理。リレーショナルDBの前段に配置。
• DynamoDB Accelerator (DAX): DynamoDB向けキャッシュで、マイクロ秒応答時間を実現。

ベストプラクティス

• RDS vs DynamoDBの選択: トランザクションデータはRDS、キーバリュー型データはDynamoDB。
• キャッシングを活用し、DB負荷を軽減。

データベース移行ツール

• AWS Database Migration Service (DMS): 異種データベース間移行をサポート。継続的レプリケーションでダウンタイム最小化。
• Schema Conversion Tool (SCT): スキーマ変換を支援し、RDSやAuroraへの移行を容易にする。

モニタリング

モニタリングは、アプリケーションとインフラの健全性を維持するために不可欠です。

• Amazon CloudWatch:
  • メトリクス収集（EC2、RDSなど）し、ダッシュボードで可視化。
  • アラームを設定し、SNSで通知可能。
• CloudWatch Logs:
  • ログデータを収集・検索。リアルタイム分析にはコストが高いため、S3+Athenaでコスト最適化。
• Amazon CloudTrail:
  • APIコールの履歴をログ化し、セキュリティ監査に利用。ログは自動的にS3に保存。
• VPC Flow Logs:
  • VPC内のネットワークトラフィックをキャプチャし、S3やCloudWatchに収集。
• Amazon EventBridge:
  • イベント駆動型自動化を可能にし、SaaSやAWSサービス間の統合を簡素化。

ベストプラクティス

• CloudWatchアラームでクリティカルメトリクスの閾値監視。
• EventBridgeでスケジューリングやLambdaトリガー設定。

ロードバランシング

トラフィックを複数のターゲットに分散し、高可用性とパフォーマンスを確保。

• Elastic Load Balancing (ELB):
  • Application Load Balancer (ALB): HTTP/HTTPS（レイヤー7）でルーティング。
  • Network Load Balancer (NLB): TCP/UDP（レイヤー4）で高パフォーマンス。
  • Gateway Load Balancer (GLB): IP（レイヤー3）でVPC間トラフィック分散。
• コンポーネント: リスナー、ターゲットグループ、接続ドレーニング（障害時接続維持）。

ベストプラクティス

• アプリケーション特性に応じ、ALB（HTTP）やNLB（TCP）を選択。
• ヘルスチェックで健全なターゲットのみにトラフィックをルーティング。

オートスケーリング

需要に応じてリソースを自動調整し、パフォーマンスとコストを最適化。

• Amazon EC2 Auto Scaling:
  • 起動テンプレートでインスタンス設定定義。
  • オートスケーリンググループでインスタンス群管理。
  • スケーリングポリシーでCPU利用率などに基づきスケールイン/アウト。
• 特徴: 動的スケーリング（リアルタイム対応）、予測スケーリング（ML予測）、スケジュールスケーリング（定時対応）。

ベストプラクティス

• 適切なメトリクス（CPU利用率など）でスケーリングトリガー設定。
• CloudWatchでパフォーマンス監視し、ポリシー調整。

自動化

インフラ管理を効率化するツール群。

• Amazon CloudFormation:
  • IaCでJSON/YAMLテンプレートを使用。スタック単位でリソース管理。
  • 再利用性高く、ドリフト検知やロールバック可能。
• Elastic Beanstalk:
  • PaaSでアプリデプロイを簡素化。Java、.NETなど対応。
  • 自動スケーリングとバージョン管理をサポート。
• AWS CDK:
  • プログラミング言語（Pythonなど）でインフラ定義。if文やfor文使用可能。
• Amazon Systems Manager:
  • ハイブリッド環境のノード管理を一元化。パッチ管理やセッションマネージャー提供。
• Amazon Q:
  • AIアシスタントでコーディング支援や運用問題解決。無料枠あり。

ベストプラクティス

• CloudFormationでテンプレート再利用し、一貫性確保。
• Elastic Beanstalkでアプリデプロイを迅速化。