はじめに
Well-Architected アーキテクチャのベストプラクティスを簡潔にまとめてみました。全体像を整理する過程で、持続可能性を実現するためには、効率の高いサービスの選択、リソースの最適化を行う事が重要です。とはいえ、有効なツールを知っているのと知らないのとでは、随分、対応が変わってくるのではないでしょうか？そこで、今回は、AWSブログを用いて、持続可能性を実現する方法を模索してみました。
目次
公式ブログで理解する
信頼性（Reliability）
運用監視を行うことで、信頼性を維持することが出来ます。
https://aws.amazon.com/jp/blogs/news/amazon-cloudwatch-launches-alarms-on-dashboards/
セキュリティ（Security）
データ保護に暗号化を取り入れるする事が該当します。
https://aws.amazon.com/jp/blogs/news/new-amazon-s3-dual-layer-server-side-encryption-with-keys-stored-in-aws-key-management-service-dsse-kms/
パフォーマンス効率（Performance Efficiency）
負荷に応じてパフォーマンスを維持出来るようにする事が該当します。
https://aws.amazon.com/jp/blogs/news/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/
コスト最適化（Cost Optimization）
コスト最適化ハブで、推奨アクションを一元化してコストを節約する事が該当します。
https://aws.amazon.com/jp/blogs/news/new-cost-optimization-hub-to-find-all-recommended-actions-in-one-place-for-saving-you-money/
持続可能性（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
目的: コストを最小限に抑えつつ、ビジネス価値を最大化する。
要件: リソースの使用状況とコストの監視、リザーブドインスタンスやスポットインスタンスの利用、不要なリソースの削減。
持続可能性
Sustainability
- 目的: 効率の良いリソースを使用する。
- 要件: 効率の高いサービスの選択、リソースの最適化、環境に配慮した運用。
読んで頂きまして、ありがとうございました。
顧客に寄りそった要件定義と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