# ソフトウェアとアーキテクチャ
**Topics**
+ [SUS 3 ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?](sus-03.md)
# SUS 3 ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?
負荷平滑化を実行しデプロイされたリソースが一貫して高使用率で維持されるパターンを実装し、リソースの消費を最小化します。時間の経過とともにユーザーの行動が変化したため、コンポーネントが使用されずアイドル状態になることがあります。パターンとアーキテクチャを改定して、使用率の低いコンポーネントを統合し、全体の使用率を上げます。不要になったコンポーネントは使用停止にします。ワークロードコンポーネントのパフォーマンスを理解し、リソースの消費が最も大きいコンポーネントを最適化します。顧客がお客さまのサービスにアクセスするために使用するデバイスを把握し、デバイスをアップグレードする必要性を最小化するパターンを実装します。
**Topics**
+ [SUS03-BP01 非同期のジョブおよびスケジュールされたジョブ向けにソフトウェアとアーキテクチャを最適化する](sus_sus_software_a2.md)
+ [SUS03-BP02 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする](sus_sus_software_a3.md)
+ [SUS03-BP03 時間やリソースを最も多く消費するコード領域を最適化する](sus_sus_software_a4.md)
+ [SUS03-BP04 デバイスや機器への影響を最適化する](sus_sus_software_a5.md)
+ [SUS03-BP04 データアクセスとストレージパターンのサポートが最も優れたソフトウェアパターンとアーキテクチャを使用する](sus_sus_software_a6.md)
# SUS03-BP01 非同期のジョブおよびスケジュールされたジョブ向けにソフトウェアとアーキテクチャを最適化する
キュー駆動型などの効率的なソフトウェアおよびアーキテクチャパターンを使用して、デプロイされたリソースの使用率を一貫して高く維持します。
**一般的なアンチパターン:**
+ 予期せぬ需要の急増に対応するために、クラウドワークロードのリソースを過剰にプロビジョニングしています。
+ お使いのアーキテクチャでは、メッセージングコンポーネントによって非同期メッセージの送信者と受信者が切り離されていません。
**このベストプラクティスを活用するメリット:**
+ 効率的なソフトウェアとアーキテクチャのパターンは、ワークロード内の未使用リソースを最小限に抑え、全体的な効率を向上させます。
+ 非同期メッセージの受信とは無関係に処理を拡張できます。
+ メッセージングコンポーネントを使用することで、可用性要件が緩和され、より少ないリソースで対応できるようになります。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
[イベント駆動型アーキテクチャ](https://aws.amazon.com/event-driven-architecture/)などの効率的なアーキテクチャパターンを使用することで、コンポーネントを均等に使用し、ワークロードの過剰プロビジョニングを最小限に抑えることができます。効率的なアーキテクチャパターンを使用することで、時間の経過に伴う需要の変化により、使用されずにアイドル状態になるリソースを最小限に抑えることができます。
ワークロードコンポーネントの要件を理解し、リソース全体の利用率を高めるアーキテクチャパターンを採用します。不要になったコンポーネントは廃止します。
**実装手順**
+ ワークロードの需要を分析し、それらに対応する方法を決定します。
+ 同期応答を必要としないリクエストやジョブには、キュー駆動型アーキテクチャとオートスケーリングワーカーを使用して使用率を最大化します。キュー駆動型アーキテクチャを検討する場合の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_software_a2.html)
+ いつでも処理できるリクエストやジョブについては、スケジューリングメカニズムを利用してジョブをバッチ処理することで効率化を図ります。AWS でのスケジューリングメカニズムの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_software_a2.html)
+ ご使用のアーキテクチャでポーリングやウェブフックのメカニズムを使用している場合、それらをイベントに置き換えます。[イベント駆動型アーキテクチャ](https://docs.aws.amazon.com/lambda/latest/operatorguide/event-driven-architectures.html)を使用して、効率性の高いワークロードを構築します。
+ [AWS のサーバーレス](https://aws.amazon.com/serverless/)を活用し、過剰にプロビジョニングされたインフラストラクチャを排除します。
+ アーキテクチャの個別のコンポーネントの適切なサイズを設定し、リソースが入力を待ってアイドル状態になるのを防ぎます。
## リソース
**関連するドキュメント:**
+ [Amazon Simple Queue Service とは](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [Amazon MQ とは](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html)
+ [Amazon SQS に基づいたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html)
+ [AWS Step Functions とは](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Lambda とは](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Lambda を Amazon SQS に使用する](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html)
+ [Amazon EventBridge とは](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
**関連動画:**
+ [Moving to event-driven architectures](https://www.youtube.com/watch?v=h46IquqjF3E) (イベント駆動型アーキテクチャへの移行)
# SUS03-BP02 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする
未使用のコンポーネントや不要になったコンポーネントを削除し、使用率の低いコンポーネントはリファクタリングして、ワークロードの無駄を最小化します。
**一般的なアンチパターン:**
+ ワークロードの個別のコンポーネントの使用率レベルを定期的に確認していない。
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) のような AWS サイズ最適化ツールからのレコメンデーションを確認し分析しない。
**このベストプラクティスを活用するメリット:** 未使用のコンポーネントを削除すると、無駄が最小化され、クラウドワークロード全体の効率が向上します。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
ワークロードを見直して、アイドルや未使用のコンポーネントを特定します。これは、需要の変化や新しいクラウドサービスのリリースに伴う、反復的な改善プロセスです。例えば、[AWS Lambda](https://docs.aws.amazon.com/lambda/) 関数の実行時間が大幅に低下した場合は、メモリーサイズを小さくする指標になり得ます。また、AWS で新しいサービスや機能がリリースされると、ワークロードに最適なサービスやアーキテクチャが変化する可能性があります。
ワークロードのアクティビティを継続的にモニターして、個別のコンポーネントの使用率レベルを改善する機会を見逃さないようにします。アイドルのコンポーネントを削除しアクティビティのサイズ最適化を行って、最小限のクラウドリソースでビジネス要件を満たすようにします。
**実装手順**
+ ワークロードの重要なコンポーネントの使用率メトリクス ([Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)の CPU 使用率、メモリ使用率、ネットワークスループットなど) をモニターし、キャプチャします。
+ 安定したワークロードの場合は、[AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) などの AWS サイズ最適化ツールを定期的に確認して、アイドル、未使用、または使用率の低いコンポーネントを特定します。
+ 一次的なワークロードについては、使用率メトリクスを評価して、アイドル、未使用、または使用率の低いコンポーネントを特定します。
+ 不要になったコンポーネントや関連アセット (Amazon ECR イメージなど) を廃止します。
+ 使用率の低いコンポーネントをリファクタリングまたは他のリソースと統合して、使用効率を改善します。例えば、使用率の低い個別のインスタンスでデータベースを実行するのではなく、単体の [Amazon RDS](https://aws.amazon.com/rds/) データベースインスタンスに複数の小さなデータベースをプロビジョニングできます。
+ [作業の単位を完了するためにワークロードによってプロビジョニングされたリソース](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html)を理解します。
## リソース
**関連するドキュメント:**
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [Automated Cleanup of Unused Images in Amazon ECR](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/) (Amazon ECR における未使用画像の自動クリーンアップ)
**関連する例:**
+ [ Well-Architected Lab - Rightsizing with AWS Compute Optimizer](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)(Well-Architected ラボ - Compute Optimizer を使用したサイズ最適化)
+ [ Well-Architected Lab - Optimize Hardware Patterns and Observe Sustainability KPIs ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)(Well-Architected ラボ - ハードウェアパターンの最適化と持続可能性 KPI の観察)
# SUS03-BP03 時間やリソースを最も多く消費するコード領域を最適化する
アーキテクチャの異なるコンポーネント内で実行されているコードを最適化して、パフォーマンスを最大化しながらリソースの使用量を最小化します。
**一般的なアンチパターン:**
+ リソースの使用量のためにコードを最適化しない。
+ 通常、パフォーマンスの問題にはリソースを増やすことで対処している。
+ コードの見直しおよび開発プロセスで、パフォーマンスの変化を追跡していない。
**このベストプラクティスを活用するメリット:** 効率的なコードは、リソースの使用量を最小化し、パフォーマンスを向上させます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドに構築されたアプリケーションのコードを含むあらゆる機能領域を精査して、そのリソース使用量とパフォーマンスを最適化することが重要です。ビルド環境および本稼働環境でワークロードのパフォーマンスを継続的にモニターし、リソースの使用量が特に高いコードスニペットを改善する機会を特定します。定期的な見直しプロセスを導入して、コードの中でリソースを効率的に使用していないバグまたはアンチパターンを特定します。自分のユースケースに合わせて、同じ結果になるシンプルで効率的なアルゴリズムを活用します。
## 実装手順
+ ワークロードを開発する際に、自動化されたコードレビュープロセスを導入して、品質を向上させ、バグやアンチパターンを特定します。
+ [ Automate code reviews with Amazon CodeGuru Reviewer (Amazon CodeGuru Reviewer を使用したコードレビューの自動化) ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [ Detecting concurrency bugs with Amazon CodeGuru (Amazon CodeGuru を使用した並列バグの検出) ](https://aws.amazon.com/blogs/devops/detecting-concurrency-bugs-with-amazon-codeguru/)
+ [ Raising code quality for Python applications using Amazon CodeGuru (Amazon CodeGuru を使用して Python アプリケーションのコード品質を向上させる) ](https://aws.amazon.com/blogs/devops/raising-code-quality-for-python-applications-using-amazon-codeguru/)
+ ワークロードを実行しながら、リソースをモニターして、作業単位でリソースを多く必要とするコンポーネントを特定し、コードレビューの対象とします。
+ コードレビューでは、コードプロファイラーを使用して、時間またはリソースを最も多く使用するコードの領域を特定し、最適化の対象とします。
+ [ Reducing your organization's carbon footprint with Amazon CodeGuru Profiler (Amazon CodeGuru Profiler を使用して組織のカーボンフットプリントを削減する) ](https://aws.amazon.com/blogs/devops/reducing-your-organizations-carbon-footprint-with-codeguru-profiler/)
+ [ Understanding memory usage in your Java application with Amazon CodeGuru Profiler (Amazon CodeGuru Profiler を使用して Java アプリケーションのメモリ使用量を理解する) ](https://aws.amazon.com/blogs/devops/understanding-memory-usage-in-your-java-application-with-amazon-codeguru-profiler/)
+ [ Improving customer experience and reducing cost with Amazon CodeGuru Profiler (Amazon CodeGuru Profiler を使用してカスタマーエクスペリエンスを改善しコストを削減する) ](https://aws.amazon.com/blogs/devops/improving-customer-experience-and-reducing-cost-with-codeguru-profiler/)
+ 最も効率的なオペレーティングシステムとプログラム言語をワークロードに使用します。エネルギー効率に優れたプログラム言語 (Rust など) の詳細については、 [Sustainability with Rust を参照してください](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/)。
+ コンピューティング負荷が高いアルゴリズムを、結果が同じであり、よりシンプルでより効率的なバージョンに置き換えます。
+ ソートや書式設定などの不要なコードを削除します。
## リソース
**関連するドキュメント:**
+ [Amazon CodeGuru Profiler とは?](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [FPGA インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html)
+ [The AWS SDKs on Tools to Build on AWS (AWS の構築ツールの AWS SDK)](https://aws.amazon.com/tools/)
**関連動画:**
+ [ Improve Code Efficiency Using Amazon CodeGuru Profiler ](https://www.youtube.com/watch?v=1pU4VddsBRw)
+ [ Automate Code Reviews and Application Performance Recommendations with Amazon CodeGuru ](https://www.youtube.com/watch?v=OD8H63C0E0I)
# SUS03-BP04 デバイスや機器への影響を最適化する
アーキテクチャで使用されているデバイスや機器を理解し、それらの使用量を削減する戦略を使用します。これにより、環境に対するクラウドワークロードの全体的な影響を最小化できます。
**一般的なアンチパターン:**
+ 顧客が使用するデバイスの環境に対する影響を無視する。
+ 顧客が使用するリソースを手動で管理および更新している。
**このベストプラクティスを活用するメリット:** 顧客のデバイスに合わせて最適化されたソフトウェアパターンや機能を実装することで、クラウドワークロード全体の環境に対する影響を削減できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
顧客のデバイスに合わせて最適化されたソフトウェアパターンや機能を実装することで、複数の方法で環境に対する影響を削減できます。
+ 後方互換性がある新機能を実装することで、ハードウェアの置換数を削減できます。
+ アプリケーションを最適化してデバイスで効率的に実行できるようにすることで、エネルギー消費を削減し、バッテリー寿命を延ばすことができます (バッテリー駆動の場合)。
+ また、アプリケーションをデバイスに合わせて最適化すると、ネットワーク経由のデータ転送も削減できます。
アーキテクチャで使用されているデバイスや機器、それらの予想ライフサイクル、およびそれらコンポーネントを置換した場合の影響を理解します。デバイスのエネルギー消費、顧客がデバイスを置換する必要性、およびデバイスを手動でアップグレードする必要性を最小限にできるソフトウェアパターンや機能を実装します。
**実装手順**
+ アーキテクチャで使用されているデバイスをリストアップします。デバイスには、モバイル、タブレット、IoT デバイス、スマートライト、さらに工場のスマートデバイスも含まれます。
+ デバイスで実行されているアプリケーションを最適化します。
+ バックグラウンドでのタスク実行などの戦略を使用して、エネルギーの消費量を削減します。
+ ペイロードを構築する際にネットワーク帯域幅とレイテンシーを考慮し、低帯域幅、高レイテンシーのリンクでもアプリケーションが問題なく動作できる能力を実装します。
+ ペイロードやファイルを、デバイスが必要とする最適な形式に変換します。例えば、[Amazon Elastic Transcoder](https://docs.aws.amazon.com/elastic-transcoder/) や [AWS Elemental MediaConvert](https://aws.amazon.com/mediaconvert/) を使用して、サイズが大きい高品質デジタルメディアファイルを、ユーザーがモバイルデバイス、タブレット、ウェブブラウザ、コネクテッドテレビで再生できる形式に変換します。
+ コンピューティングの負荷が高いアクティビティはサーバー側 (画像のレンダリングなど) で実行するか、アプリケーションストリーミングを使用して、古い型のデバイスでのユーザーエクスペリエンスを改善します。
+ 特にインタラクティブセッションの場合は、出力を分割してページ番号を付け、ペイロードを管理しローカルストレージの要件を制限します。
+ 自動化された無線通信 (OTA) の仕組みを使用して、1 つ以上のデバイスに更新をデプロイします。
+ モバイルアプリケーションの更新には、[CI/CD パイプライン](https://aws.amazon.com/blogs/mobile/build-a-cicd-pipeline-for-your-android-app-with-aws-services/)を使用できます。
+ [AWS IoT Device Management](https://aws.amazon.com/iot-device-management/) を使用して、コネクテッドデバイスを大規模にリモートで管理できます。
+ 新機能や更新をテストするには、ハードウェアの代表的なセットを備えたマネージド型 Device Farm を使用し、サポート対象のデバイスを最大化する開発を繰り返します。詳細については、[SUS06-BP04 マネージド型 Device Farm を使用してテストする](sus_sus_dev_a5.md) を参照してください。
## リソース
**関連するドキュメント:**
+ [AWS Device Farm とは何ですか?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)
+ [Amazon AppStream 2.0 のドキュメント](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [ FreeRTOS を実行するデバイスでファームウェアを更新する OTA チュートリアル](https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-ota-workflow.html)
**関連動画:**
+ [ Introduction to AWS Device Farm](https://www.youtube.com/watch?v=UiJo_PEZkD4)(AWS Device Farm の紹介)
# SUS03-BP04 データアクセスとストレージパターンのサポートが最も優れたソフトウェアパターンとアーキテクチャを使用する
データがどのようにワークロード内で使用されているか、ユーザーに消費されているか、転送されているか、保存されているかを理解します。データへのアクセスと保存を最適にサポートするソフトウェアパターンとアーキテクチャを使用して、ワークロードのサポートに必要なコンピューティング、ネットワーク、ストレージのリソースを最小化します。
**一般的なアンチパターン:**
+ すべてのワークロードのデータの保存とアクセスのパターンが類似していると考えている。
+ ストレージ階層を 1 つだけ使用し、すべてのワークロードがその階層に適していると考えている。
+ 時間が経過してもデータアクセスパターンが変わらないと考えている。
+ アーキテクチャはデータアクセスの高バーストの可能性をサポートしているが、その結果リソースがほとんどの時間でアイドルのままになる。
**このベストプラクティスを活用するメリット:** データのアクセスパターンおよびストレージパターンにもとづいてアーキテクチャを選択し最適化すると、開発の複雑性が下がり、全体の使用率が増加します。グローバルテーブル、データのパーティショニング、キャッシュをいつ使用するべきかを理解することで、運用上の諸経費を減らし、ワークロードのニーズに応じてスケーリングできるようになります。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
データの特性やアクセスパターンに最も合うソフトウェアやアーキテクチャのパターンを使用します。例えば、お客様独自の分析ユースケースに合わせて最適化された目的別サービスを使用できる、[AWS のモダンデータアーキテクチャ](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/)を使用します。このようなアーキテクチャパターンを使用すると、データ処理が効率的になり、リソースの使用量を削減できます。
**実装手順**
+ データの特性やアクセスパターンを分析して、クラウドリソースに最適な構成を特定します。考慮する主な特徴には次のものがあります。
+ **データタイプ:** 構造、半構造、非構造
+ **データ成長:** 制限あり、制限なし
+ **データ保存期間:** 永続、一時的、一過性
+ **アクセスパターン:** 読み取りまたは書き取り、更新頻度、急増、または安定
+ データアクセスとストレージパターンのサポートが最も優れたアーキテクチャパターンを使用します。
+ [ Let's Architect\$1 Modern data architectures ](https://aws.amazon.com/blogs/architecture/lets-architect-modern-data-architectures/) (構築してみよう\$1 モダンデータアーキテクチャ)
+ [ Databases on AWS: The Right Tool for the Right Job ](https://www.youtube.com/watch?v=-pb-DkD6cWg)(AWS のデータベース: 適材適所で使い分けるツール)
+ 圧縮データをネイティブに操作するテクノロジーを使用します。
+ アーキテクチャ内のデータ処理に、[目的別の分析サービス](https://aws.amazon.com/big-data/datalakes-and-analytics/?nc2=h_ql_prod_an_a)を使用します。
+ 主要なクエリパターンに対して最も優れたサポートをするデータベースエンジンを使用します。データベースインデックスを管理して、効率的なクエリ実行を確実にします。詳細については、[AWS のデータベース](https://aws.amazon.com/products/databases/)を参照してください。
+ アーキテクチャで消費されるネットワーク容量が削減できるネットワークプロトコルを選択します。
## リソース
**関連するドキュメント:**
+ [Athena でサポートされる圧縮ファイル形式](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)
+ [Amazon Redshift を使用した列指向のデータ形式からの COPY](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html)
+ [Converting Your Input Record Format in Firehose](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) (Kinesis Data Firehose の入力レコード形式を変換する)
+ [AWS Glue の ETL 入出力の形式オプション](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html)
+ [列指向形式に変換して Amazon Athena でのクエリパフォーマンスを改善する](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html)
+ [Amazon Redshift を使用して圧縮されたデータファイルを Amazon S3 からロードする](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon Aurora での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [ Amazon S3 Intelligent-Tiering storage class ](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/)(Amazon S3 Intelligent-Tiering ストレージクラス)
**関連動画:**
+ [ Building modern data architectures on AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)(AWS にモダンデータアーキテクチャを構築する)