AWS Well-Architected アーキテクチャの持続可能性を分析する #要件定義

はじめに

Well-Architected アーキテクチャのベストプラクティスを簡潔にまとめてみました。全体像を整理する過程で、持続可能性を実現するためには、効率の高いサービスの選択、リソースの最適化を行う事が重要です。とはいえ、有効なツールを知っているのと知らないのとでは、随分、対応が変わってくるのではないでしょうか？そこで、今回は、AWSブログを用いて、持続可能性を実現する方法を模索してみました。

公式ブログで理解する

持続可能性（Sustainability）

適切なメンテナンスを実施する事が該当します。

これの理解が少し、難しいので、詳しく解説します。

オブジェクトストレージの使用状況とアクティビティを組織全体で可視化 することで、組織全体のストレージ容量や最も急速に成長しているバケットなどの要約されたインサイトを生成できます。また、コスト最適化やデータ保護のベストプラクティスに向けた推奨事項も提供されます。例えば、S3ライフサイクルルールがないバケットを特定して、7日以上経過した未完了のマルチパートアップロードを有効期限切れにできます。
https://aws.amazon.com/jp/blogs/news/s3-storage-lens/

Amazon EC2 Auto Scaling のインスタンス メンテナンスポリシーを導入 できます。この機能は、EC2 インスタンスの置き換えプロセスをより細かく制御できるようにし、Amazon EC2 のコストを最小限に抑えながら、パフォーマンスの優先順位と運用に合った方法でインスタンスを置き換えられるようにする事ができます。
https://aws.amazon.com/jp/blogs/news/introducing-instance-maintenance-policy-for-amazon-ec2-auto-scaling/

フレームワークで要件定義を行う

このフレームワークは、クラウドアーキテクチャの設計におけるベストプラクティスを提供し、信頼性、セキュリティ、効率性、コスト最適化、持続可能性の5つ の柱に基づいています。

信頼性

Reliability

目的: システムが意図したとおりに機能し、障害から迅速に回復する能力を確保する。
要件: 自動フェイルオーバー、バックアップとリカバリプロセス、マルチAZデプロイメント。

1. 自動フェイルオーバー

自動フェイルオーバーは、システムの一部が障害を起こした場合に、別の正常なリソースに自動的に切り替える機能です。これにより、システムのダウンタイムを最小限に抑え、継続的なサービス提供を確保します。

2. バックアップとリカバリプロセス

定期的なバックアップとリカバリプロセスは、データの損失を防ぎ、障害発生時に迅速にデータを復元するために重要です。

3. マルチAZデプロイメント

マルチAZデプロイメントは、システムの可用性を高めるために、リソースを複数のアベイラビリティゾーンに分散させる方法です。これにより、単一のAZで障害が発生しても、他のAZでサービスを継続できます。

セキュリティ

Security

目的: システムとデータを保護し、脅威から守る。
要件: IAMポリシー、暗号化、ネットワークセキュリティ、アクセス制御、監査ログ。

1. IAMポリシー

IAM（Identity and Access Management）ポリシーは、AWSリソースへのアクセスを制御するためのルールを定義します。これにより、適切な権限を持つユーザーだけがリソースにアクセスできるようにします。

2. 暗号化

データの暗号化は、データが不正アクセスされた場合でも、内容が解読されないようにするための手段です。

3. ネットワークセキュリティ

ネットワークセキュリティは、ネットワークレベルでの不正アクセスを防ぐための対策です。

4. アクセス制御

アクセス制御は、特定のリソースに対するアクセス権限を管理するための仕組みです。

5. 監査ログ

監査ログは、システムの操作履歴を記録し、後で確認できるようにするためのものです。

パフォーマンス効率

Performance Efficiency

目的: コンピューティングリソースを最適に使用し、システムのスケーラビリティを確保する。
要件: 適切なインスタンスタイプの選択、オートスケーリング、負荷分散、キャッシング戦略。

1. 適切なインスタンスタイプの選択

適切なインスタンスタイプを選択することで、リソースの無駄を減らし、コスト効率を高めることができます。

2. オートスケーリング

オートスケーリングは、トラフィックの増減に応じて自動的にインスタンスの数を調整する機能です。これにより、リソースの無駄を減らし、パフォーマンスを最適化します。

3. 負荷分散

負荷分散は、トラフィックを複数のインスタンスに分散させることで、システムのパフォーマンスと可用性を向上させます。

4. キャッシング戦略

キャッシングは、頻繁にアクセスされるデータを一時的に保存することで、データベースやバックエンドシステムへの負荷を軽減し、応答時間を短縮します。

コスト最適化

Cost Optimization

目的: コストを最小限に抑えつつ、ビジネス価値を最大化する。
要件: リソースの使用状況とコストの監視、リザーブドインスタンスやスポットインスタンスの利用、不要なリソースの削減。

1. リソースの使用状況とコストの監視

AWS Cost Explorerを使用して、毎月のコストと使用状況を分析し、AWS Budgetsを設定して予算を超えた場合にアラートを受け取る。

2. リザーブドインスタンスやスポットインスタンスの利用

長期的なワークロードにはリザーブドインスタンスを購入し、短期的なワークロードにはスポットインスタンスを利用する。

3. 不要なリソースの削減

AWS Trusted Advisorを使用して、未使用のリソースを特定し、AWS Lambdaを使用して定期的に自動削除する。

持続可能性

Sustainability

目的: 効率の良いリソースを使用する。
要件: 効率の高いサービスの選択、リソースの最適化、環境に配慮した運用。

1. 効率の高いサービスの選択

Amazon Auroraを使用して、従来のデータベースエンジンに比べて高いスループットとコスト効率を実現します。

2. リソースの最適化

AWS Compute Optimizerを使用して、EC2インスタンスやEBSボリュームの最適なサイズを推奨し、リソースの効率的な利用を実現します。

3. 環境に配慮した運用

AWSの再生可能エネルギーの使用が進んでいるリージョンを選択し、AWSのサステナビリティプログラムに参加します。

読んで頂きまして、ありがとうございました。

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(1/6)　
https://qiita.com/kimuni-i/items/aff6339130f160de16af

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(2/6)
https://qiita.com/kimuni-i/items/4da6a2c91a5ecdf2c526

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(3/6)
https://qiita.com/kimuni-i/items/1760874d6eec96fe75d7

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(4/6)
https://qiita.com/kimuni-i/items/496ae4d41c8098f32f21

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(5/6)
https://qiita.com/kimuni-i/items/a893228ce1ab52d3133e

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(6/6)
https://qiita.com/kimuni-i/items/8dadc65f38d06a960f1a

AWS Well-Architected アーキテクチャの持続可能性を分析する