【AWS】 Well-Architectedについてのメモ

こんにちは。新卒3年以内に退職して世間的には白い目で見られているだろう駆け出しエンジニアです。

先日退職しまして、来週から新しい職場で働くのですが(どこいった有給)、正直勉強不足すぎて不安で一杯です。

不安はありますが、今年は1週間に１回はアウトプットを出すことが目標ですので今週もやります

すでに他の方が既出の`AWS`の記事ばっかりですが、車輪の再開開発という言葉に動じません。

メンタルだけが取り柄です。

まだまだ、次の業務で必要なスキルは身についていないですが、今年はGo言語も勉強していきたいです。

この記事で書くこと

• AWSのWell-Architeted Frameworkについて、Udemyと原文から学んだことを書きます。

• 学んだことを踏まえて、前回の記事で作成した構成をまともな構成にしていきたいと思います。

  • マルチAZ構成
  • RDSの利用

• Terraformの実装は次の記事に回しています。

文字が多くなってしまうので先にまとめ

• Well-Architectedフレームワークは大局的な設計、運用のベストプラクティス集

  • 絶対に従わないといけないというものではない。自分たちのシステムにどこが適用できるか。何が足りていないかを把握するための指標

• 継続的にWell-Architectedフレームワークに沿ったレビューを行い、適切なサービス選択とコスト最適化が必要になってくる

Well-Architectedフレームワークとは

原文はAWSの公式ページを参照してください 。

• 平たくいうと、AWSでインフラを構築するときはこれは意識して設計しないとねという設計や運用に関するベストプラクティス集
• 5つの柱で構成されていて、それぞれはトレードオフの関係となっている
• 今勉強しているAWSアソシエイトの試験範囲もこのフレームワークが試験の範囲となっている

5つの柱

あくまで個人の解釈です

名前	説明(すごいざっくりとしたイメージ)
運用上の優秀性	構成変更や予期せぬイベント(障害)発生時に対してもなるべく自動化とか社内でレビューされた手順を考えていきましょうよ
セキュリティ	言葉の通り。アクセス追跡やアクションの追跡など全てのレイヤーでセキュリティ保護できるようにしましょうよ
信頼性	障害による、中断・停止と障害復旧による影響を軽減するインフラ構成。なるべく早く復旧できるアーキテクチャにしましょうよ
パフォーマンス効率	せっかくクラウド利用するんだから、要求されるリソースを満たす最小限のものを利用しましょうよ
コスト最適化	無駄にコストを払わず、最小限のコストでサービスを提供しましょうよ

どんな時に使えるのよ??

そもそもWell-ArchitectedフレームワークはプロであるAmazon Web Serviceのエンジニアたちの長年の経験から得たベストプラクティスです。

フレームワークを活用することで、プロたちのノウハウを既存環境のレビューや新規システムの設計へのインプットに活用することができるとされています。

要件定義~運用まで全てに利用する必要があり、改善を続けることがWell-Architectedフレームワークの根本ではないかとど素人ながら思います。

つまり、継続的なレビュー&改善(PDCA?)が必要になってくるのはないでしょうか。

先ほど説明した5つの柱についてざっくりと説明していきます。

運用上の優秀性(Operational Excellence)

AWSの公式(日本語版)では下記のように説明されております。

運⽤上の優秀性の柱には、ビジネス価値を提供し、サポートのプロセスと⼿順を継続的に向上させるためにシステムを稼働およびモニタリングする能⼒ が含まれます。

設計原則は６つあります。

• 運用のコード化
  • IaC使っていこうぜ！！
• ドキュメントへの注釈
  • IaCで作詞したコードに注釈とか、リソースに対してタグをつけよう!!
• 高頻度で小規模は可逆的変更
  • 定期的に改善していこう!!
    • 結構無茶だろと思ったけど、IaC利用してコードのバージョン管理ができていれば実現可能なのではないでしょうか。
• 障害の予測
  • 障害を自分たちで気づけるようにモニタリングをしましょうよ!!
• 運用手順の頻繁な更新
• 運用上の失敗の改善
  • 何か起きた時に対処できる運用手順はみんなでレビューして都度改善していこうよ!!
    • 一番難しいのでは。属人化の排除ってすごい難しいですよね。。

運用上の優秀性では３つのベストプラクティスの分野から成り立っています。

• 準備
  • Cloud Formationとか使って、開発環境~本番環境まで自動的に構築できようにしていく
  • Cloud Watchを使って、モニタリングできるようにしていく

• 運用

  • Cloud Watchとか使って、改善の指標となる値をモニタリングする
  • レビューされたランブック(運用手順書)とプレイブック(障害対応手順書)を準備する

• 進化

  • 運用フェーズで得られた指標から、継続的な改善を検討/実施していく
    • 障害発生から復旧までの時間とか
  • ランブックとプレイブックの再レビューを実施する

セキュリティ

AWS上に構築したシステムのリスク評価(何がリスクか？どれだけの影響を与えるか?)とリスク軽減(リスクが発生する可能性・影響を小さくする)という観点です。

設計原則は7つです。

• 強力な認証基盤の実装

  • 最小権限で、各リソース同士の通信には認証をかけましょう

• トレーサビリティの実現

  • ログ監視/保管して、モニタリングできるようにしましょう

• 全レイヤーへのセキュリティの適用

  • オンプレと同様に多層防御が必要ですよ

• セキュリティの自動化

  • アクセスコントロールとかをIaCとかでテンプレート化して、改善できるようにしていきましょう

• データ保護

  • データには暗号化をかけようね

• データに人の手を入れない

  • 保管されているデータに対して、人が手動で直接アクセスしたり編集したりする必要性を無くす

• セキュリティイベントへの備え

ベストプラクティスは５つの分野です。

オンプレと同様に、権限管理・アクセス管理・ログ監視・多層防御・データ保護(暗号化)・IRを考える必要があります。

• アイデンティティ管理とアクセス管理

  • IAMを利用して、AWSリソースにアクセスできるユーザおよびリソースを制限する
    • 権限はフルオープンにせず、アクセスが必要なリソースだけにPrincipalを使って最小限にする

• 発見的統制

  • セキュリティインシデントが発生した際に、すぐに検知・状況把握ができる構成が必要になる
  • Cloud TrailログでAWSリソースに対して実行された操作を記録する
  • Cloud WatchでAWSリソース自体のログを記録・可視化する
  • Amazon GuardDuty(脅威検出サービス)を利用して、悪意のある動作や不正な操作を検知できる仕組みを作る

• インフラストラクチャ保護

  • 多層防御の考え方を適用する
  • パブリックとプライベートの分離
  • WAFやIDS(マーケットプレイスでIDSがあるようです)の導入

• データ保護

  • データ暗号化(S3やRDSなど)をして、素のデータが開示されるリスクを減らす
  • KMSを利用して、暗号鍵の管理や定期的なロテートを実施する
  • S3にデータを保管して、データがなくなってしまうことを防ぐ

• インシデント対応

  • セキュリティインシデントに備えて、ファイルに対するアクセスや変更に対するログを記録する
  • インシデント訓練を実施して、インスタンスの隔離や自動化ができるか検証する
    • CloudWatchをトリガーとして、Lambdaを動作させるなど

信頼性

障害発生時に、中断・停止と障害復旧による影響を軽減するという観点です。

また、障害発生時にすぐに復旧できるかということも重要です。

可用性を高くすることは大事なのですが、何かあった時に適切に復旧できるかという考え方が必要なんですね。

設計原則は5つです。

• 復旧手順をテストする
  • クラウド環境なんだから、本番環境と同じ構成を複製して、障害を発生させてテストしよう
• 障害から自動的に復旧する
  • システムのKPIをモニタリングして、しきい値を超えた時にシステム側で自動的にアクションを起こせるようにしよう
• 水平方向へのスケール
  • 垂直方向(リソース拡張)ではなくて、複数の小規模リソースを配置して単一障害点を無くしましょう
• キャパシティーを予測しない
  • 需要(Webシステムで言えばアクセス)に対して、適切なスケーリングができるようにしましょう
• オートメーションで変更を管理する
  • IaCを使ってインフラ構成に発生した変更を管理できるようにしよう

ベストプラクティスは３つの分野に別れています。

• 基盤

  • オンプレで考慮点となるNW帯域やコンピューティング性能(物理レベルの性能)はAWS側の責任範囲
  • リソースに必要なストレージのサイズやリソースのサイズ(割り当てるCPUやメモリ)を適切に選択する

• 変更管理

  • 需要の変化に応じて、リソースが自動的に追加や削除される対応ができているか
  • ログとリソースのモニタリングを実施して、KPIの設定やしきい値を超えた時のアクションを自動化する
  • 変更管理をログとして記録する

• 障害の管理

  • 障害を検出して、自動的に復旧できているか
    • Cloud Watch
  • バックアップデータの保存先に耐久性の高いS3を利用する

パフォーマンス効率

システム要件を満たすためのコンピューティングリソースを効率化するという観点です。

AWSサービスの進化(新サービス)を柔軟に取り入れて、インフラの効率化が必要とのことです。

５つの設計原則があります。

• 最新テクノロジーの標準化
  • 最新技術を簡単に取り入れるようにAWS側が頑張るから、積極的に取り入れてみてよ
• 数分でグローバルに展開
  • 世界中にリージョンがあるから、システムを複数のリージョンに置けるよ
• サーバレスアーキテクチャを利用
  • 自分たちでサーバリソースをなるべく持たない構成にしようよ
• より頻繁に実験可能
  • 簡単にリソースを作ったり、消したりできるから比較テストを実施しよう
• システムを深く理解
  • NoSQLとかストレージを使ってもいいけど、根本的な技術の理解は必要よ

そして４つのベストプラクティス

• 選択

  • １つのAWSサービスではなく複数のAWSサービスを利用する
  • 検討すべきリソースタイプは４つ
    • コンピューティング
      • EC2のリソースタイプ
      • Lambda
      • コンテナの利用
    • ストレージ
      • アクセス方式や参照/更新頻度から選択する
      • EBS
      • S3
      • Glacier
      • EFS
    • データベース
      • システムに対して適切なデータベースを選択する
      • RDS
      • Aurora
      • DynamoDB
      • Elastic Service

• レビュー

  • AWSの新機能を取りれているか

• モニタリング

  • パフォーマンスをモニタリングできるようにする
  • SQSやLambdaを通じて、自動的にアクションを起こせるようにする

• トレードオフ

  • どの部分を重視するのか
  • 整合性か耐久性か
  • レイテンシーか容量か
  • インメモリキャッシュElastiCacheやCDNCloudFrontの利用を検討する

コスト最適化

不必要なリソースを削減したり、適切な料金選択を行って、需要対して最適なコストでサービスを続けましょうという観点

５つの設計原則があります。

• 消費モデルを導入する

  • ビジネス要件に応じて使用するリソースの量を削減する
    • 例えば、会社の稼働日だけテスト環境と開発環境を構築して休日中には、リソースを削除する

• 全体的な効率を測定する

  • ビジネスから得た利益とコストの差異を検証する
  • ROIを得れていないリソースの継続検討

• DC運用のための費用を排除する

  • クラウドシフトしていって、DCの固定コストを排除していく

• 費用を分析し、帰結させる

  • システムの利用状況とコストを分析してROIを透明化する

• マネージドサービスの利用を検討する

４つのベストプラクティスの分野があります。

• 費用認識

  • AWS Cost ExplorerやAWS Budgetsを利用して、各リソースの利用状況とコストをモニタリングする

• 費用対効果の高いリソース

  • Trusted Advisorを利用して、支払い過ぎているリソースがないか定期的にレビューする

• 需要と供給を一致させる

  • Auto Scallingを利用して、需要(アクセス)に対して、リソースを増加したり削除したりする

• 長期的な最適化

  • 新しいAWSサービスをウォッチして、既存のアーキテクチャのコストが下がらないかレビューする

最後に

自分の忘備録的に書いているものなので、長々と書いているメモになってしまいました。

(資料の座学だったのでとてもしんどかった)

解釈が誤っている部分もあるかと思いますが、そこは悪しからず。

次回は前回作成したリソースを、改善していきたいと思います。