Well Architected Framework

  • AWSの提唱する設計原則

アーキテクチャの基礎

AZの選択

  • 1リージョン2つのAZを利用して設計することが基本

    • 3つ以上はコスト効率が低下する。

  • マルチAZでEC2やDBを冗長構成

  • S3でDBのバックアップを取得する。

VPC

  • 2つ以上のVPCが基本

    • 1つのVPCでは可用性が低下する。

      • HPCなどその用途は限られる。

    • 小規模な場合は1つでもOK。

  • VPCを組織やシステム単位で分割

    • 本番と開発で分割

  • VPC以外では、システム毎にアカウントを準備するマルチアカウント方式もありうる。

サブネット分割

  • CIDRで分割したネットワークセグメント。

  • publicとprivateに分割することが基本。

  • 基本的にはWebアクセスの要否が基準となる。

  • /24以上の大きいサブネットの使用を推奨。

  • 1つのAZにpublic, privateが一つずつ。これが2つ分のAZにあるのが望ましい。

  • privateに多くのIPを割り当てる。

    • 例: publicは/24、privateは/23など

VPC間接続

  • VPC peeringで設定

  • それぞれがPeering設定が必要。

Well-Architected Framework

設計原則

  • ６つの原則

    • 信頼性 Reliability

    • パフォーマンス Peformance Efficiency

    • 安全性 Security

    • コスト最適化Cost Optimization

    • 運用上の優秀性 Operational Excellence ※SAA範囲外

    • 持続可能性 Sustainability

WAFの３つの内容

  • WAFのホワイトペーパー

  • 認定パートナーによる支援制度

  • セルフチェック向けの Well-Architedted Tool

ベストプラクティス

  • ベストプラクティスを利用することで、最適解や改善点を把握する。

  • あくまで参考であり絶対というものではない。

  • 使い方

    • システム要件を検討する材料として要件検討に利用する。

    • 設計における適切な設計方式の検討

    • リリース前に構成に改善点がないか。

    • 運用中にWHに沿ったレビューを実施し、リスクや改善点がないか確認する。

Reliability

  • 障害による中断・停止と障害復旧の影響を軽減するインフラを構成する。

  • ポイント

    • 障害復旧の自動化

    • 復旧手順ののテストによる検証

    • 需要変化に応じた水平方向へのスケーラビリティ

      • AutoScalingの設定によるスケーリング自動化

    • キャパシティの推測をやめる

      • 自動で察知しモニタリングしてスケーリングさせる。

    • モニタリングと自動化を進める。

  • 3つのポイントと主要なサービス

    • 基盤(IAM, VPC, AutoScaling, ELB, Cloud Formation)

    • 変更管理(CloudTrail, AWS Config)

    • 障害管理(CloudWatch)

Performance Efficiency

  • リソース最適化によるインフラ効率化

  • システム要件を満たすためのコンピューティングしろーすを効率化する。

  • システム要件やAWSサービスの変化に応じてインフラの効率化を推進

    • 先端技術の一般化

    • グローバル化

    • サーバレスアーキテクチャの利用

    • より頻繁な実験

  • ポイントと主要なサービス

    • コンピューティング(AutoScaling, Lambda)

    • ストレージ(EBS, S3, Glacier, EFS)

    • データベース(RDS, DynamoDB, ElasticSearch, Aurora, Redshift)

    • 容量と時間のトレードオフ(CloudFront, ElastiCache)

Security

  • AWS内のデータ、システム、アセットの保護と監視によりセキュリティを高める。

  • すべてのレイヤーでセキュリティを適用

  • アクセス追跡、モニタリングを確実な実施

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

  • AWS責任共有モデルに基づき対象範囲の保護に集中する。

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

    • ソフトウェアベースのセキュリティ設定を使用し、迅速でコスト効率の良いスケーリングを安全に実行する。

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

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

      • CloudFormationやCodePipelineなど

  • ポイントと主要なサービス

    • データ保護(ELB, EBS, S3, RDS, KMS)

    • 権限管理(IAM, MFA)

    • インフラ保護(VPC)

    • 検出制御(CloudTrail, CloudWatch, AWS GuardDuty, Amazon Inspector)

Cost Optimization

  • 不必要なリソース削減、最適な料金選択

    • 不要なリソース削減

    • 透明性のある費用賦課

    • マネージド型サービスの利用

    • 固定のコストを変動コストへ変換

    • スケールによるコストメリット

    • データセンターへの投資不要化

  • ポイントと主要なサービス

    • 需要と供給の一致(AutoScaling)

    • コスト効率の高いリソース(EC2購入方式, Trusted Advisor)

    • 支出の認識(CloudWatch, 見積ツール)

    • 継続した最適化(AWS最新情報, Trusted Advisor)

Operational Excellence

  • 計画変更や予期せぬイベントが発生した際に、自動化された運用実務および文書化されレビューされた手順があること。

    • コードに基づく運用実施

    • ビジネス目的に沿った運用手順

    • 定期的かつ小規模で増加的な変更実施

    • 予期せぬイベントへの応答テスト

    • イベントと障害からの学習

    • 運用手順を最新のものに保持すること

  • ポイントと主要なサービス

    • 準備(CloudFormation, Codeシリーズ, Runbook, Playbook)

    • 運用(System Manager, Service Catalog, CloudTrail, AWS Artifact, AWS GUardDuty, CloudWatch, AWS config, API Gateway)

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

Sustainability

  • 追加の原則。今後試験範囲になる可能性がある。

  • 環境負荷のないクラウドサービスの活用

  • 責任共有モデルにより、ユーザーとAWS側の連携によって推進される

  • AWS側のおもな対応

    • サーバーの使用率

    • 電力と冷却の効率化

    • カスタムデータセンターの設計

    • 2025年までに100%再生可能エネルギーでAWSを運用

  • ユーザー側の主な対応

    • 効率的なストレージ技術の使用

    • コード効率化

    • 効率的なインフラのデプロイとスケーリング

    • 効率的なアプリケーションデザイン

    • データの効率的なデザイン活用

  • 設計原則

    • 影響を把握する

    • サスティナビリティ目標の設定

    • 使用率の最大化

    • 効率的な新しいHWとSWの提供を予測して、採用する

    • マネージドサービスの使用

    • クラウドワークロードのダウンストリームの影響を軽減

  • サスティナビリティのベストプラクティス

    • ユーザーの所在地に合わせてワークロードの地理的配置を最適化

    • 時間やリソースを最も多くコード領域を最適化

    • ユーザのデバイスへの影響を最適化。

    • データ分類ポリシーを実装

    • ライフサイクルポリシーを使用して不要なデータを削除

    • ネットワーク間でのデータ移動を最小化

    • GPU使用の最適化

    • 潜在的なサステナビリティの改善を迅速に導入できる開発方法とテスト方法の採用

    • ビルド環境の使用率を向上。

AWSベストプラクティス

  • 11の原則を定義している

    • スケーラビリティの確保

    • 環境の自動化

    • 使い捨てリソースの使用

    • コンポーネントの疎結合

    • サーバーではなくサービス（サーバレス）

    • 最適なデータベース選択

    • 増大するデータ量対応

    • 単一障害点の排除

    • コスト最適化

    • キャッシュの利用

    • セキュリティの確保

スケーラビリティ

  • 需要の変化に対応できるアーキテクチャを設計する。

  • 主要サービス

    • EC2 Auto Recovery, EC2 Auto Scailing, CloudWatch, RDS, DynamoDB

環境の自動化

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

  • 主要サービス

    • Cloud Formation, Codeシリーズ(CodeBuild, CodeTest, CodePipeline), ECS, ElasticBeanstalk, OpsWorks, CloudWatch

使い捨てリソースの仕様

  • 一時的なリソースを使用して構築する。

  • 主要サービス

    • EC2, AutoScaling

コンポーネント疎結合

  • コンポーネントの相互依存を減らし、変更や障害の影響を削減する。

  • 主要サービス

    • ELB, SNS, SQS

サーバーではなくサービス(サーバレス)

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

  • 主要サービス

    • Lambda, SNS, SQS, SES, ELB, DynamoDB, API Gateway, Cognito

最適なデータベース選択

  • ワークロードや目的に応じた最適なデータベース技術を利用する。

  • 主要サービス

    • RedShift, RDS, DynamoDB, Aurora, Elastic Search

増大するデータ量対応

  • IoT,ビッグデータで絶えず増加するデータの保持を効率的に実施

  • 主要なサービス

    • S3, Kinesis, Glacier

単一障害点の排除

  • 高可用性が保証されているものもあるが、ELBによる高可用性設計が必要。

  • 高可用性を考慮すべきサービス

    • EC2(ELBなどによる設計), DirectConnect, RDS

コスト最適化

  • 需要と供給の一致

    • AutoScaling

  • コスト効率の高いリソース

    • EC2購入方式, Trusted Advisor

  • 支出の認識

    • CloudWatch, SNS

  • 継続的な最適化

    • AWS最新情報, Trusted Advisor

キャッシュの利用

  • 繰り返し取り出すデータ、コンテンツはキャッシュを利用する。

  • 主要なサービス

    • CloudFront, Elasti Cache

セキュリティの確保

  • データ保護

    • ELB, EBS, S3, RDS, KMS

  • 権限管理

    • IAM, MFA

  • インフラ保護

    • VPC

  • 検出制御

    • CloudTrail, CloudWatch, AWS GuardDuty, Amazon Inspector

ケーススタディ

PreviousS3NextReliability

Last updated