Amazon Web Services ブログ
新機能 – AWS Well-Architected Tool のサーバーレスレンズ
クラウドでアプリケーションをビルドして実行するとき、どのくらい「正しくやっているか」を自問していますか?
実際、これは非常に良い質問です。私たちは良い答えを得るために、AWS Well-Architected フレームワークを 2015 年に公開しました。これは、ワークロードをベストプラクティスと比較し、改善方法に関するガイダンスを得るための正式アプローチです。今日、「Well-Architected フレームワーク」は、顧客とパートナーがクラウドアーキテクチャを設計および評価するための一貫した方法を提供します。この方法は、5 つの柱に基づいています。
- 優れた運用効率
- セキュリティ
- 信頼性
- パフォーマンス効率
- コストの最適化
より多くのワークロード固有のアドバイスを提供するために、2017 年に「レンズ」の概念でフレームワークを拡張し、一般的な視点を超えて特定のテクノロジードメインに参入しました。現在、使用できるレンズは 3 つあります。
- サーバーレス
- ハイパフォーマンスコンピューティング (HPC)
- IoT (モノのインターネット)
何かを改善するには、最初に何をどのように測定するかを決める必要があります。より構造化された方法でワークロードを確認できるようにするために、AWS マネジメントコンソールで利用できる無料ツールである AWS Well-Architected Tool を 2018 年にリリースしました。ここでは、ワークロードを定義し、5 つの柱に関する質問に答えることができます。
Well-Architected Tool はさまざまな方法で使用できます。以下に例を示します。
- 特定のアプリケーションで作業している場合、ツールを使用してリスクを評価し、改善すべき領域を見つけることができます。
- 複数のアプリケーションを担当している場合は、ツールを使用して、すべてのアプリケーションの現在のステータスを確認できます。
本日、レンズを Well-Architected Tool に適用する機能を追加しました。最初にサーバーレスレンズをご利用いただけます。
AWS Well-Architected Tool でサーバーレスレンズを使用する
Well-Architected Tool コンソールで、ワークロードを定義することから始めます。現在、Amplify フレームワークを使用してモバイルアプリのバックエンドを構築しています。簡単なゲームになりますが、ユーザーのデータを保存するために DynamoDB グローバルテーブルを使用し、アプリケーションは 2 つの AWS リージョンで実行されます。AWS アカウント ID の追加は任意事項ですが、マルチアカウント設定でのアプリケーションのデプロイを理解するのに役立ちます。
これで、適用するレンズを選択できます。AWS Well-Architected フレームワークはデフォルトです。サーバーレスレンズを選択します。これにより、フレームワークのベストプラクティス通りにサーバーレスアプリを設計、デプロイ、および設計方法を理解するのに役立つ、一連の追加質問が追加されます。
ワークロードが定義されると、レビューを開始します。サーバーレスレンズに直行します。 新しい質問は 5 つの柱に分散されています。たとえば、私のお気に入りの質問の 1 つはパフォーマンスに関するものです。
質問ごとに、コンソールの右側に、可能な答えと使用されている用語を理解するのに役立つリソースが表示されます。 具体的には、実装の一部であるアクティビティとテクノロジーを選択します。
- データストリーム (Amazon Kinesis や DynamoDB Streams によって提供されるものなど) と非同期関数呼び出しを使用して、同時実行性を改善しています。
- データベースアクセスを減らすために、ユーザーデータをメモリにキャッシュしています。Lambda 関数の
/tmp
または Amazon ElastiCache のような外部データストアも使用できます。 - Amazon API Gateway から Kinesis Data Firehose を呼び出す必要がある場合など、サービス統合がネイティブでジョブを実行できる場合、機能を削除しています (これもコストを最適化しています)。
保存してから終了し、1 つの質問にしか答えなかったとしても、すでにツールからフィードバックを受け取っています。ワークロードの概要から、サーバーレスレンズを選択します。そこで、リスクを軽減する必要があることに気付きました。
すぐ下に、リスクを提起する質問に基づいた具体的な推奨事項など、リスクの対処方法に関する提案があります。サーバーレスアプリケーションの場合、プラットフォームによって自動的にスケーリングされる適切な容量単位を使用して、パフォーマンスとコストのバランスを取ることが重要です。
最初の推奨事項をクリックすると、改善計画のための特定のアクション項目を受け取ります。これは、Lambda 関数、DynamoDB テーブル、API Gateway エンドポイントなど、サーバーレスアプリで使用できるさまざまなアーキテクチャコンポーネントを対象としています。私の場合、Lambda Power Tuning オープンソースツールを使用して Lambda 関数のメモリ/電力構成を微調整するという提案通りに実行します。
改善計画に取り組む前に、すべての質問に答えます。AWS コンソールでレポート全文を確認するか、PDF 形式でダウンロードして他の関係者と共有できます。このように、私たちは協力を通して必要な改善を計画し、サーバーレスアプリを成功させることができます。
改善が完了したら、戻って正しい回答にマークを付けて、リスクの高い問題を削除します。優れたアーキテクチャは、複数回繰り返すことでもたらされます。
今すぐご利用いただけます
サーバーレスレンズは、AWS リージョンテーブルで説明されているように、現在、Well-Architected Tool が提供されているすべてのリージョンでご利用いただけます。既存のワークロードに適用するか、ツールで定義した新しいワークロードに使用できます。
AWS Well-Architected Tool の使用に対する費用は発生しません。このツールを使用して、作業中のアプリケーションを改善したり、作業中の部門または領域が使用する複数のワークロードを可視化したりできます。
CIO/CTO は、担当するすべてのアプリケーションのステータスを説明するダッシュボードとして使用できます。ワークロードを別の AWS アカウントと共有して、容易に使用できます。これによって、複数のアプリケーションにわたって単一のビューを作成できます。
ツールの出力はリスクとその対処方法を含むレポートであるため、設計および実装段階でもツールを使用する必要があります。お客様が得た一部の提案を実装するには遅すぎるかもしれないため、特に本番環境だけでなく、アプリケーションのライフサイクル全体を使用しなければなりません。
— Danilo