Help us understand the problem. What is going on with this article?

AWS Well-Architected Frameworkから学ぶクラウド設計のベストプラクティス

AWS Well-Architected Framework

AWSやGCP, Azureといったパブリッククラウドが浸透したことでクラウドを使ってシステムを設計することは当たり前の時代となりました。

AWS Well-Architected Frameworkにはクラウドで設計する上で意識すべきことやベストプラクティスがまとめられており、クラウドを扱うエンジニアは必読の内容になっています。

自分自身、非常に勉強になったので備忘録としてまとめてみます。

原文のwhitepaperは以下のリンクにあります。
https://aws.amazon.com/jp/architecture/well-architected/

5本の柱

クラウドを利用してシステムを設計する上で考えるべきことは、以下の5つです。

  • 運用上の優秀性
  • セキュリティー
  • 信頼性
  • パフォーマンス効率
  • コスト最適化

これら5つの項目について、それぞれのベストプラクティスを説明していきます。予算やリソースには限りがあるので、実際のシステム設計でこれら全てを完璧に満たすことは難しいかもしれませんが、5本の柱の中で特に重視すべきものを考えてみてください。

意識すべき柱が明確になった後に、以下にまとめるベストプラクティスを参照していただけると良いかなと思います。

運用上の優秀性

ビジネス価値を提供し続けるためには、継続的にシステムを改善しつつ、安定稼働させる必要があります。日々の運用を支えるための指針が運用上の優秀性として説明されています。

運用上の優秀性のベストプラクティス分野

  • 準備
  • 運用
  • 進化

準備

ビジネスを成功させる上ではシステムを安定稼働させるための準備が不可欠です。以下の項目を考えておきましょう。

  • 障害を予想する

AWSではインフラをコードとして管理することができるため、本番環境をコード化しておくことで、テスト用に同じ環境を容易に作成することができます。
これによって、障害に備えた高負荷テストなどの実験を容易に行うことができます。
また、コード化することにより、gitでバージョン管理ができるため、変更点を明確にできます。
コード化を実現する代表的なサービスはCloudFormationですが、最近はPythonやTypescriptなどで構成管理を記述可能なAWS CDKも登場しており、アプリ開発者も簡単にインフラをコード化できます。
当たり前ですが、オンプレではまず実現できない、クラウドを使う上での大きなメリットの一つでしょう。

  • システムの標準ルールを設定する

システムを構築する前に、ビジネスの要件を満たすためにシステムが準拠するべきルールを決めておくことが重要です。AWS Configを利用することで、ガイドラインを設定し、システムが準拠しているかどうかチェックできます。コンプライアンスやセキュリティーを担保するためにも、AWS Configは必ず設定しましょう。

運用

  • インフラのメトリクスやアプリケーション、顧客行動をモニタリングする

運用の成功はビジネスの成果をあげることやその成果を評価することです。また、コストを最適化したり、顧客満足度を高めるためにシステムのどの箇所を改善すべきか明確にすることも運用していく上で重要です。
AWSではCloudWatchでインフラのメトリクスを監視し、CloudTrailでAWSのリソースの変更履歴をモニタリングすることができ、CloudWatch LogsでAWSリソースのログを収集することができます。
これらのサービスを利用することで、システムの問題や改善点を特定、分析することが可能になります。

進化

  • 定期的にロールバック可能な小さな変更を適用する

ビジネスを成功させる上では継続的かつ高速にフィードバックループを回すことが重要です。
最近では当たり前になったCI/CDもこれを実現する技術の一つと言えます。
システムの変更は小規模な変更を定期的に行うことを意識します。
変更を小さくしておくことで、問題があってもすぐにロールバックして対応できるメリットもあります。
AWSではCodeBuildでCI, CodeDeployでCD, CodePipelineCodeStarでCI/CDフローを構築することができます。

運用上の優秀性に関して使用するAWSサービスまとめ

セキュリティー

セキュリティーのベストプラクティス分野

  • アイデンティティ管理とアクセス管理
  • 発見的統制
  • インフラストラクチャー保護
  • データ保護
  • インシデント対応

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

AWSでの権限管理はIAMで行います。
AWSを利用する上で、最も重要なサービスがIAMといっても過言ではなく、IAMを使って、ユーザーごとに適切な最小権限を与え、役割分担を徹底することがセキュリティーを担保する上で極めて重要です。
AWSを扱う人は必ずIAMを学んでおきましょう。
IAMのベストプラクティスについては、AWSに関する書籍を多く執筆されている佐々木拓郎さんの書籍がおすすめです。https://booth.pm/ja/items/1563844

発見的統制

品質の担保やコンプライアンス義務を果たすために、セキュリティーの潜在的な脅威やインシデントを特定しておくことが大切です。
AWSではCloudTrailによって、AWSアカウントのアクティビィティやリソース変更の追跡、CloudWatchによって、メトリクスの監視、AWS Configによってリソース設定履歴をモニタリングし、セキュリティー的な脅威を事前に検知することができます。また、AWS GuardDutyは不正操作をモニタリングしてくれるマネジメントサービスで、取り敢えず有効にしておくことをお勧めします。クラスメソッドさんの記事でも、全てのAWSユーザーが利用すべきサービスとして取り上げられています。

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

堅牢性の高いインフラを構築するためには、複数レイヤーでのセキュリティー対策が重要です。VPC, サブネット、ロードバランサー、インスタンス、OS、アプリケーションの全てのレイヤーでセキュリティー対策を行うことを徹底しましょう。

データ保護

データの暗号化やバージョニングによって、データを安全に保管できるようにしましょう。
S3を使うことでデータのバージョニングが可能になります。また、S3は99.999999999%の耐久性を担保するために、保存されたデータを三箇所以上のアベイラビリティーゾーンで自動的に複製されています。
また、S3はデフォルトでは以下の暗号化オプションが提供されています。

  • S3で管理されたキーによる暗号化
  • KMSで管理されたキーによる暗号化 一つ目のオプションではAWSがキーの管理をし、二つ目のKMSによる暗号化を利用すると、暗号化キーに対する権限制御や証跡をCloudTrailで追跡できるようになる利点があります。 また、ELBSSL Terminationを使用することで、クライアントとELB間の通信をSSL通信を有効化し、ELBとインスタンス間の通信をHTTP通信とすることで、インスタンス全てのSSL証明書を管理する必要がなくなり、ELBで証明書を一括で管理できます。

インシデント対応

セキュリティー的な対策や発見的統制などの予防的な実装が十分されていても、実際にアクシデントが発生したときの運用手順や復旧操作を準備しておくことは重要です。
以下の対策を行いましょう。

  • メトリクスやリソースのログを収集しておき、インシデントの原因の特定とその対策を考えられるようにする。
  • 自動化処理によって、インシデント発生時に自動的にアクションがトリガーされるようにする。
  • CloudFormationAWS CDKを使って、安全で隔離された環境に本番環境と同じシステムを構築して高負荷対策を行ったり、インシデントのシミュレーションを行うこと。

セキュリティーに関して使用するAWSサービスまとめ

信頼性

インフラやサービスの中断から復旧し、需要に適したリソースを動的に獲得して、安定的にサービスを稼働させたり、アクシデントの際に素早く復旧させることが重要です。

信頼性のベストプラクティス分野

  • 基盤
  • 変更管理
  • 障害の管理

基盤

設計する段階で、信頼性を担保する基本的な要件を満たしておく必要があります。(ネットワーク性能やコンピューティング性能など)
オンプレでは事前に必要なリソースを準備しておく必要があるのに対し、クラウドでは基本的に制限を持たないように設計しておくことが重要です。
ネットワーク性能などの基本的な要件はAWSが担保してくれているので、ユーザーはAWSリソースの割り当てを適切に行い、基盤を構築することを意識しましょう。

変更管理

変更がシステムに与える影響を、監視、モニタリングします。AWS CloudTrailでリソースの変更を管理したり、IAMでシステムを変更できるユーザーを制限しましょう。

障害の管理

どんなシステムでも障害が発生する確率は0%ではありません。
そのため、障害を検出して、再発を防止することが重要です。
具体的にはAWS CloudWatchでリソースのメトリクスを管理し、SNSを使用して、AWS lambdaのアクションをトリガーすることで、自動的に復旧アクションを行うこともできます。
ELBのヘルスチェックとAutoScalingを組み合わせることで、自動的にインスタンスを復旧することもできます。

信頼性に関するAWSサービスまとめ

パフォーマンス効率

システム要件を満たしつつ、効率的にリソースを使用することや、要件の変化やテクノロジーの進化に対応しつつも、効率的にシステムを運用することはビジネスを成功させる上で重要です。

パフォーマンス効率のベストプラクティス分野

  • 選択
  • レビュー
  • モニタリング
  • トレードオフ

選択

システムの要件に対して、最適なAWSリソースを選択することが重要です。
例えば、セッション管理はRDSよりも、Elastic Cacheを使用する方が効率的ですし、EC2を使用するよりも、AWS Lambdaを使用して、イベントが発生したときのみ処理を行う方が、効率的なケースもあります。
AWSリソースを選択する上では、以下の4つの項目を意識しましょう。

コンピューティング

様々な種類のEC2インスタンスが用意されており、どれが最適か検討しましょう。(SSD, GPUなど)また、ECSAWS Fargateなどのコンテナ技術が適しているケースもあります。また画像処理やログ処理などはイベント駆動型のAWS Lambdaがコスト効率が良いです。

ストレージ

S3には以下のようにデータの種類やアクセス頻度に応じて、最適なオプションが用意されています。

  • S3 標準
    アクセス頻度の高いデータ向けのストレージクラスでデフォルトではこれが選択されます。
  • S3 Intelligent-Tiering
    アクセス頻度を自動的に判別し、最もコスト効率の良いストレージクラスに自動的に移動させます。
  • S3 低頻度アクセス
    アクセス頻度が低いデータですが、必要になった時にすぐに取り出す必要のあるデータに最適なストレージクラスです。S3標準と同じ機能を安く利用することができますが、データを取り出す際に料金が発生するのが特徴です。
  • S3 1 ゾーン – 低頻度アクセス (S3 1 ゾーン – IA)
    S3 低頻度アクセスと同様にアクセス頻度の低いデータに向いていますが、データが一つのアベイラビリティーゾーンにのみ保存されます。そのため、可用性は低下しますが、料金はS3 低頻度アクセスよりも20%抑えることができます。
  • S3 Glacier
    アーカイブ目的のデータに適しているストレージクラスです。取り出す際には、数分から数時間かかりますが、コストは圧倒的に安く済ませることができます。
  • S3 Glacier Deep Archive
    一年のうち一回か二回しかアクセスされないデータを対象としています。容量あたりのコストは最も低いストレージクラスです。

データベース

データの使用目的に応じて最適なデータベースを使用することがコスト最適化につながります。
- RDS
フルマネージドのリレーショナルデータベースです。
- DynamoDB
Key-ValueストアのNoSQL。データ容量に制限がなく、テーブルを自動的にスケーリングすることができます。RDSより高速にデータの格納と取得ができるため、ゲームやアドテクなど、短いレイテンシーが要求されるケースに使用されます。
- Redshift
列指向型のデータベースで巨大なデータを使用する分析に適しています。
- ElasticCache
データ容量に制限がある一方で、高速にアクセスできるため、セッション管理などに使用されます。
シンプルなデータ構造向きのMemcachedと暗号化や高可用性、複雑なデータ構造にも対応しているRedisがあります。

ネットワーク

レイテンシーやI/O機能の要件を満たすために最適なサービスを使用することが重要です。

  • EBS最適化インスタンス
    デフォルトではEC2インスタンスとEBS間の帯域はEBSへのI/O以外に他のインスタンスへの通信にも使用されます。より優れたI/O性能を求める場合は、EC2とEBSの間に専用の帯域を設定することでより高いパフォーマンスを得ることができます。このオプションのことをEBS最適化インスタンスと呼びます。
  • CloudFront
    ユーザーからのリクエストを最寄りのエッジサーバーに誘導し、高速にコンテンツ配信を行うことができます。
  • S3 Transfer Acceleration
    クライアントとS3バケット間の通信を高速化することができます。内部ではCloudFrontが使用されているようです。
  • Route53
    Route53は単純な名前解決だけでなく、動的に転送先を決定するルーティングポリシーになっています。 以下の種類があるので、要件によって使い分けるようにしましょう。
シンプルルーティング

通常のDNSと同じ、単純な名前解決

フェイルオーバールーティング

ヘルスチェックの結果に基づいて、使用可能なインスタンスにのみルーティングを行う。

位置情報ルーティング

クライアントの位置情報に基づいてルーティングされる。

地理的近接性ルーティング

ユーザーとリソースの地理的情報に基づいてルーティングされる。

レイテンシーに基づくルーティング

複数リージョンにリソースが存在する時に、最もレイテンシーの少ないリージョンにルーティングする。

複数値回答ルーティング

DNSクエリに対して、複数の値を返すように設定する

加重ルーティング

単一のドメインに複数のリソースを紐付けて、重みづけに基づいてトラフィックを分散させることができるルーティング

  • VPCエンドポイント
    VPCにエンドポイントを付けることで、本来はインターネットからしかアクセスできないリソースにVPC内部からアクセスできるようになります。」
  • AWS DirectConnect
    オンプレミスからAWSに専用の回線を設けることができるサービス

レビュー

AWSサービスは日々新しいものが追加されていますので、常に最新の情報をキャッチアップし、有効なテクノロジーは活用しましょう。
クラスメソッドさんのサイトでは、AWSで新しいサービスが追加されるとすぐに解説記事が追加されるので、いつも参考にさせていただいてます。
もちろん公式サイトも日々チェックしましょう。

モニタリング

アーキテクチャが完成した後は、そのパフォーマンスをモニタリングしておき、メトリクスが閾値を超えた時に、アラームを発生させるようにします。
AWS CloudWatchでメトリクスを監視し、SQSAWS Lambdaで自動的にアクションをトリガーしてパフォーマンスの問題を回避できるようにしておきましょう。

トレードオフ

パフォーマンスの中でも、どの項目を重要視するのか決めておきましょう。
例えば、データの整合性や耐久性を一番に考えるのか、レイテンシーや応答速度を重視するのかなど、トレードオフを考えてアーキテクチャを設計しましょう。

パフォーマンス効率に関するAWSサービス

コスト最適化

当たり前のことですが、ビジネスを行う上で、低価格でシステムを運用することは重要です。

コスト最適化のベストプラクティス分野

  • 費用認識
  • 費用対効果の高いリソース
  • 需要と供給を一致させる
  • 長期的な最適化

費用認識

AWS CostExplorerを使用して費用の内訳を把握しておきましょう。また、AWS Budgetsを使用して予想よりも多くの費用が発生した時にアラートを通知することができます。設定ミスなどで多額の費用が発生するケースがあるので、必ず設定しておきましょう。

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

要件に応じて、最適なリソースを使用しましょう。
例えば、EC2インスタンスの場合は種類によって、かなり費用を削減できる場合があります。

  • リザーブドインスタンス
    1年間または3年間でEC2インスタンスを予約して使用することで割引が受けられます。
  • スポットインスタンス
    AWSがEC2インスタンスの使用量を時価で提供し、ユーザーが設定した価格よりもAWSの提示した価格の方が低い場合は、インスタンスを使用できます。EMRを使用してビッグデータを処理するときなど、途中でインスタンスが停止しても支障がない場合に使用することで、大幅に安くEC2インスタンスを使用できます。
  • ハードウェア占有インスタンス
    通常はEC2インスタンスは他のユーザーと共有したホストコンピュータを使用しますが、このオプションにすると、専用のホストコンピュータにEC2インスタンスを割り当てることができます。ただし、どのホストコンピュータは指定することができません。
  • Dedicated Hosts
    ハードウェア占有インスタンスと同様に、専用のホストコンピュータを使用でき、インスタンスが配置されるホストコンピュータも指定することができます。 ### 需要と供給を一致させる 高負荷のアクセスに備えてプロビジョニングする時間を設定するなど、リソースを最適に配分します。 AutoScalingを使用すると、需要ベース、バッファーベース、時間ベースのアプローチで必要に応じたリソースの追加や削除が可能になります。

長期的な最適化

日々AWSのサービスはアップデートされるため、最適なサービスを日々取り入れるようにしましょう。例えば、新しいマネージドサービスが発表されるとそれまで、EC2インスタンスにミドルウェアをインストールして運用する場合と比較して、コストを節約できる場合があります。

コスト最適化に関するAWSサービス

まとめ

クラウド技術を使って、安定した効率的なシステムを構築するために5本の柱を意識して設計し、それぞれのベストプラクティスを遵守しましょう。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした