TxKxZxWx's blog

AWS SAA取得に向けて学習

AWS SAA取得に向けて 47日目 「Well Architected Framework」 セクション8:Well Architected Framework

セクション8:

Well Architected Framework
------------------------------------------

 

 

アソシエイト試験範囲:

  1. 回復性の高いアーキテクチャを設計する → 30%
  2. パフォーマンスに優れたアーキテクチャを定義する → 28%
  3. セキュアなアプリケーションおよびアーキテクチャを規定する → 24%
  4. コスト最適化アーキテクチャを設計する → 18%
  5. オペレーショナルエクセレンスを備えたアーキテクチャを定義する → 6%

※現在では5番は試験範囲から外れた。 

 

 

5つの設計原則

アソシエイト試験はWell-Architected Frameworkで提唱されている5つの設計原則に沿った試験範囲になっている。

 

 

 

 

Well-Architected Framework

Well-Architected Frameworkは次の3つの内容で構成される。

 

  1. Well-ArchitectedFramework ホワイトペーパー
    (5つの設計原則について説明したホワイトペーパー。)
    ※試験範囲で重要。


  2. AWSのSAまたは認定パートナーによる支援制度。
    SAとはAWS公認のサポーター社員、認定パートナーとはサポート企業。
    それらがWell-Architected Frameworkを支援する支援制度を行っている。
    コンサルティングのように、どのようにフレームワークを使って入れればいいかなどサポートしてくれる。


  3. セルフチェック向けのWell-Architected Tool
    このツールを使って、AWS設計がWell-Architected Frameworkに沿っているかどうかチェックできるものが提示されている。

 

 

ベストプラクティスを利用することで最適解や改善点を把握するということが目的。

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

 

  • 要件定義
    AWSを利用したシステム要件を検討する材料としてホワイトペーパーを確認して最適な要件検討に利用する。
    どういう要件定義の項目が必要なのか、ホワイトペーパーの枠を使って網羅性を担保することが出来る。

    ⬇︎

  • 設計
    設計においてホワイトペーパーを確認しながら、適切なアーキテクチャーや設計方式を検討する。

    ⬇︎

  • 構築
    リリース前にAWSのインフラ構成にリスクや改善点がないかホワイトペーパーに基づいて再度確認する。

    ⬇︎

  • 運用
    運用中に定期的にホワイトペーパーに沿ったレビューを実施し、リスクや改善点がないか確認する。

 

基本的にはAWSの使用中、Well-Architected Frameworkを常に意識してチェックしていくことが大事。

 

 

Reliability:信頼性

障害による中断・停止と障害復旧による影響を軽減するインフラストラクチャ-を構成する。

 

【設計事項】

  • インフラストラクチャサービスの障害復旧の自動化など軽減設計

  • 復旧手順が本番になった時に即時にできるのかテストし検証。
    BCPだけ作って特に検証を行わず、実際起こった時に即座に実行できなかったでは意味がないので、しっかりとテストし検証を行うことが重要。

  • 需要変化に応じた水平方向へのスケーラビリティによる高可用性の確保。
    オートスケーリングを使い、何らかの需要変化が起きても自動でスケールしていくことがクラウドの特徴であり、その特徴を活かし、スケーラビリティを常に高く持っておく設計が必要。

  • キャパシティの推測をやめる。
    どのぐらいのキャパか推測して決めるのではなく、自動で察知し、モニタリングをしっかり行い、クラウドの特徴を活かしオンデマンドで対処していく設計やモニタリングの方法が求められる。

  • モニタリングと自動化を進める。
    モニタリングと、いくつかある自動化オートメーションのサービスで、自動で復旧ができるようにし信頼性を高める設計が求められる。

 

 

信頼性の基本対応領域は基盤変更管理障害管理の3つ。

 

 

信頼性の主要サービス

  • 基盤
    IAM, VPC, Auto Scaling, ELB, Cloud Formation

    IAM→ちゃんとしたアカウント権限管理を行う。
    VPC→複数のVPCに分けたり、サブネットを分ける事により信頼性を高める。
    Auto Scaling, ELB→ヘルスチェックやスケーラビリティを自動化したり。
    Cloud Formation→環境構築を自動化する仕組み。自動で行ってくれるツールでセットアップが自動で回復する物を作ることも大切。

  • 変更管理
    CloudTrail, AWS Config

    CloudTrail, AWS Config→サービスやインフラの変更点をデータとして取るサービス。こういったモニタリングツールを使い変更管理をしっかり行う。

  • 障害管理
    Cloud Watch

    Cloud Watch→常にモニタリングする。

 

 

 

Performance Efficiency:パフォーマンス効率

システム要件のリソース最適化によるインフラの効率化

 

【設計事項】

  • システム要件を満たすためのコンピューティングリソースを効率化する。
  • システム要件やAWSサービスの進化に応じてAWSインフラの効率化を推進する。
    ・先端技術の一般化(AIなど)
    グローバル化を即座に達成
    ・サーバレスアーキテクチャの利用
    ・より頻繁な実験
    AWSのサービスはどんどん新しいものが出てくるので、それに応じてインフラを効率化し、再設計、アップデートしていく。

 

 

 

Performance Efficiency:パフォーマンス効率

パフォーマンス効率の基本対応領域はコンピューティングストレージデータベース容量と時間のトレードオフの4つ。

 

パフォーマンス効率の主要サービス

  • コンピューティング
    Auto Scaling, Lambda
    →パフォーマンスの良い、コストパフォーマンスの良いインフラアーキテクチャを作っていくことが求められる。

  • ストレージ
    EBS, S3, Glacier, EFS
    →ライフサイクル設定のように効率的にデータを保存する。

  • データベース
    RDS, Dynamo DB, Elastic search, Aurora, Redshift
    →用途に応じて最適な物をチョイスし使用する。

  • 容量と時間のトレードオフ
    Cloud Front, Elasti Cache
    →キャッシュサービスを使って素早くアクセスできるようにしたり、データ容量に左右されない高速アクセスできるものにする。

 

 

 

Security:セキュリティ

AWS内のデータ/システム/アセットの保護とモニタリングによりセキュリティを高める。

 

【設計事項】

  • 全てのレイヤーにおいてセキュリティを適用。
  • アクセス追跡・モニタリングの確実な実施。

  • 条件ドリブンのアラートをトリガーとしてセキュリティイベントへの応答を自動化。
    Cloud Watchなどでアラートを自動にトリガーにし、それをLambdaなどが自動で何かするというようにセキュリティ対応を自動化する。

  • AWS責任共有モデルに基づく対象範囲の保護に集中する。
  • セキュリティのベストプラクティスの自動化。
    ・ソフトウェアベースのセキュリティ設定を使用し、迅速でコスト効率の良いスケーリングを安全に実行する。
    ・仮想サーバーのカスタムベースラインイメージによる新サーバーへの適用自動化
    ・インフラストラクチャ全体のテンプレ化による管理。

 

 

セキュリティの基本対応領域はデータ保護権限管理インフラ保護検出制御の4つ

 

セキュリティの主要サービス

  • データ保護
    ELB, EBS, S3, RDS, KMS
    →EBSやS3で暗号化してデータを保存したり、KMSのようにセキュリティキーを上手く使用する。

  • 権限管理
    IAM, MFA

  • インフラ保護
    VPC
    →ネットワークをしっかりと構成して、サブネットやセキュリティグループ、ネットワークACLを使用して上手くコントロールしインフラを保護する。

  • 検出制御
    Cloud Trail, Cloud WatchAWS GuardDuty, Amazon Inspector
    →モニタリングし脅威を検出する。

 

 

 

Cost Optimization:コスト最適化

不必要なリソースの削減や最適な料金選択によりコストを削減

 

AWSには様々な料金プランがあり、それを上手く使用する事によりコストを抑えたり、EC2ではなくLambdaを使う構成にする事によりインスタンス、サーバー代をかけずにLambdaによるアクションベースの料金にする事により安く済ませるなどコスト最適化ができる。

 

【設計事項】

  • 不必要なリソース削減
  • 透明性のある費用賦課
  • マネージド型サービスの利用によるコスト削減
    マネージド型ではないサービスはユーザー側で冗長構成を取ったり、ある程度管理が必要なためなるべくマネージド型を使い運用負荷を下げる。

  • 固定の償却コストを変動コストへと転換
    オンプレの固定のコストから利用量に応じた変動コストに変えていく。

  • スケールによるコストメリット
    長期間や大量に使用する事により安くなるので、上手くスケールメリットを活かしコストが安くなるポイントを探していく。

  • データセンターへの投資不要化
    自社にデータセンターを作るなどをやめる。

 

コスト最適化の基本対応領域は需要と供給の一致コスト効率の高いリソース支出の認識継続した最適化の4つ

 

 

コスト最適化の主要サービス

  • 需要と供給の一致
    Auto Scaling

  • コスト効率の高いリソース
    EC2 購入方式, Trusted Advisor
    →EC2などreservedやspotなどいくつか購入方式があるものは上手く使い最安を狙う。
    Trusted Advisorはコスト効率や状況に対してアドバイスしてくれるサービス。
    (使いすぎですよ、ここいらないですよなど)

  • 支出の認識
    Cloud Watch, 見積もりツール
    モニタリングして支出をしっかり認識する。

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

 

 

Operational Excellence:運用上の優秀性

運用上の優秀性とは計画変更が起こった場合や予期せぬイベントの発生時において、自動化された運用実務及び文書化されテストされレビューされた手順があること。

 

【設計事項】

  • コードに基づく運用実施
    Cloud Formationなどでコードを使って運用方法をコーディングして自動化する。

  • ビジネス目的に沿った運用手順
    自社のビジネスの状況としっかりとマッチした運用手順を回していく。

  • 定期的かつ小規模で増加的な変更実施
  • 予期せぬイベントへの応答テスト
  • 運用イベントと障害からの学習
    どういう対応が必要だったのか。

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

 

 

運用上の優秀性の基本対応領域は準備運用進化の3つ。

 

 

運用上の優秀性の主要サービス

  • 準備
    Cloud Formation, Code シリーズ, Runbook Playbook
    環境設定を自動化して手間を取らせない仕組みを作る。

  • 運用
    System Manager, CloudTrail, Service Catalog, AWS Artifact, AWS GuardDuty
    Cloud WatchAWS Config, API Gateway
    モニタリングをし数値をとって可視化する。

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

 

 

5つの設計原則

AWS活用では5つの設計原則を常に念頭に置くことが重要。

 

  • Reliability(信頼性)
  • Performance Efficiency(パフォーマンス効率)
  • Security(安全性)
  • Cost Optimization(コスト最適化)
  • Operational Excellence(運用上の優秀性)