パフォーマンス効率の測定：トランザクションあたりのコスト最適化ガイド
AWSにおけるトランザクションあたりのコスト（CPT）最適化を習得し、インフラ支出をビジネス成果に合わせます。このガイドでは、CPTの計算方法、オートスケーリングや適正サイズ設定などの重要なパフォーマンスチューニング戦略の実装、そして長期的なクラウド効率を最大化するためのReserved InstancesとSavings Plansの間での重要な財務トレードオフのナビゲートについて詳しく説明します。
パフォーマンス効率の測定：トランザクションあたりのコスト最適化ガイド
トランザクションあたりのコストは、エンジニアリングの作業をビジネスが理解できるものに結び付けるため、有用なクラウドメトリクスです。「RDSの請求が上がった」とか「CPUが低くなった」と言う代わりに、「今月は1回の成功したチェックアウトの処理に約0.5セントかかっていて、先月はそれより高かった」と言えます。その数字が完璧になるわけではありませんが、より良い会話のきっかけになります。
AWSでは、トランザクションあたりのコストは通常、無料で得られる単一のメトリクスではありません。請求データとアプリケーションデータから構築します。難しいのは割り算ではありません。難しいのは、分子に何を含めるか、何をトランザクションとみなすか、そしてユーザーを害する形で数字を最適化することを避ける方法を決めることです。
計算する前にトランザクションを定義する
トランザクションは、単なるランダムなリクエスト数ではなく、ビジネスイベントまたはサービス成果であるべきです。Eコマースシステムの場合、トランザクションは完了した注文かもしれません。ペイメントAPIの場合、承認された支払い試行かもしれません。データパイプラインの場合、処理されたファイルまたは100万件の処理されたレコードかもしれません。内部APIの場合、レイテンシ目標の下で処理された成功したリクエストかもしれません。
人々が守れる定義を選んでください。すべてのヘルスチェックと失敗したリクエストをカウントすると、分母が膨らみ、メトリクスは実際よりも良く見えます。完全なエンドツーエンドの成功のみをカウントすると、メトリクスはより正直かもしれませんが、インフラレベルのスループットと比較するのは難しくなります。
実用的な式は次のとおりです：
トランザクションあたりのコスト = 割り当てられたサービスコスト / 成功したビジネストランザクション
例えば：
月間割り当てコスト = $1,500
成功した注文 = 300,000
注文あたりのコスト = $1,500 / 300,000 = $0.005
この例では丸い数字を使用しています。実際のシステムでは、コスト配分は複雑です。共有ロードバランサー、NATゲートウェイ、可観測性プラットフォーム、サポートプラン、CIランナー、データ転送はすべて、複数のサービスをサポートできます。メトリクスが大まかな傾向追跡用か、正確なチャージバック用かを決めてください。これらは異なる目的です。
分子を慎重に構築する
トランザクションの処理に直接関与するAWSサービスから始めます：EC2、ECS、EKSワーカーノード、Lambda、RDS、DynamoDB、ElastiCache、SQS、SNS、Kinesis、S3、CloudFront、API Gateway、Elastic Load Balancing、NAT Gateway、データ転送。次に、共有コストの処理方法を決定します。
AWS Cost Explorer、Cost and Usage Reports、コスト配分タグ、アカウント構造が通常のツールです。タグは特に重要です。コンピューティングリソースがサービス、環境、またはチームごとにタグ付けされていない場合、トランザクションあたりのコストは推測になります。
Webチェックアウトフローの場合、割り当てられた月間コストには以下が含まれる可能性があります：
| コスト項目 | 配分アプローチ |
|---|---|
| ECSサービスまたはEC2 Auto Scalingグループ | 直接サービス タグ |
| RDSクラスター | アプリケーション所有権またはクエリワークロードで分割 |
| ElastiCache | 専用の場合は直接、共有の場合は比例配分 |
| ロードバランサー | リクエスト数またはサービス所有権で分割 |
| NAT Gateway | 多くの場合共有；可能な場合はトラフィックで配分 |
| CloudWatchログとメトリクス | 直接ロググループタグまたはボリュームで推定 |
配分が不便だからといって、高価な共有インフラを隠さないでください。NAT Gatewayのデータ処理、クロスAZトラフィック、詳細なログは、チャットなサービスにとってコスト状況を大きく変える可能性があります。
分母をアプリケーションの真実から構築する
分母は、インフラカウンターだけでなく、ビジネスイベントの記録システムから取得する必要があります。Application Load Balancerのリクエスト数はトラフィック量を教えてくれますが、注文が正常に作成されたかどうかは教えてくれません。CloudWatchメトリクスは有用ですが、アプリケーションメトリクスやデータベースイベントがよりクリーンなトランザクション数を提供することがよくあります。
APIサービスの場合、SuccessfulPaymentAuthorizationやCompletedReportGenerationなどのカスタムメトリクスを発行するかもしれません。パイプラインの場合、ソースから読み取っただけでなく、宛先に正常にコミットされたレコードをカウントします。非同期ジョブの場合、リトライを別のトランザクションとしてカウントするかどうかを決定します。通常はカウントすべきではありません。リトライは、1つの論理的な作業単位を完了するためのコストの一部です。
トランザクションあたりのコストをレイテンシとエラー率とともに使用する
トランザクションあたりのコストが低いことは、自動的に良いことではありません。ユーザーが長く待たされたり、リクエストがタイムアウトしたり、リトライがコストを他の場所に移動させたりするまでプロビジョニングを減らすことで、数字を良く見せることができます。CPTは、レイテンシ、エラー率、飽和度、キュー深度と一緒に読むべきです。
健全なレビューは次のように言うかもしれません：
成功したレポートあたりのコストは、ワーカーの適正サイズ設定後に18%減少しました。
P95レイテンシは目標を下回ったままでした。
エラー率は増加しませんでした。
ピーク負荷時にキューエイジは5分未満のままでした。
コストが下がり、レイテンシが倍増した場合、サービスを最適化したのではありません。痛みを請求書からユーザーに移したのです。
最適化は通常どこから来るか
適正サイズ設定が最初のパスです。長期間低い使用率で動作しているインスタンス、タスク、データベースを探します。AWS Compute OptimizerはEC2、EBS、Lambda、および一部のコンテナワークロードに役立ちますが、推奨事項は出発点として扱ってください。アプリケーションのコンテキストは依然として重要です。平均CPUが低いデータベースでも、バッチウィンドウ中にキャッシュやI/Oヘッドルームのためにメモリが必要な場合があります。
オートスケーリングが2番目のパスです。スケーリングポリシーはボトルネックに一致する必要があります。CPUターゲット追跡はCPUバウンドのサービスに適しています。キュー深度またはエイジは、多くの場合ワーカーに適しています。ターゲットあたりのリクエスト数は、Webフリートに適している場合があります。Lambdaの場合、期間、メモリ構成、同時実行性、ダウンストリームスロットリング、コールドスタート感度を確認します。
使用量が安定したら、購入コミットメントが役立ちます。Savings PlansとReserved Instancesは実効コンピューティングコストを削減できますが、無駄を修正するわけではありません。ベースラインを理解した後にコミットしてください。そうしないと、削除すべきリソースに支出を固定化する可能性があります。
ストレージとデータ転送は一般的な盲点です。意味がある場合は大きなペイロードを圧縮します。不要なクロスAZまたはクロスリージョントラフィックを避けます。ログの保持期間を意図的に設定します。アクセスパターンと取得コストを確認した後でのみ、古いオブジェクトをより安価なS3ストレージクラスに移動します。
具体的なレビュープロセス
1つのサービスと1つのトランザクションを選択します。先月の割り当てられたAWSコストを取得します。同じ月の成功したトランザクション数を取得します。ベースラインを計算します。次に、コストをサービスごとに分解します。
最初のレビューでは、多くの場合、明白な何かが明らかになります：サイズが大きすぎるデータベース、アイドル状態のインスタンス、高価なNATトラフィック、過剰なデバッグログ、または節約するデータベース負荷よりもコストがかかるキャッシュ。一度に1つずつ修正し、メトリクスに注釈を付けて、次の読者が何が変わったかを知ることができるようにします。
シンプルな月次テーブルで十分です：
| 月 | 割り当てコスト | トランザクション | CPT | 注記 |
|---|---|---|---|---|
| 1月 | $1,500 | 300,000 | $0.0050 | ベースライン |
| 2月 | $1,350 | 310,000 | $0.0044 | アイドルワーカーを削減 |
| 3月 | $1,420 | 420,000 | $0.0034 | トラフィック増加、同じDBサイズ |
トレンドは誤った精度よりも重要です。配分ルールが変更された場合は、その変更をマークしてください。共有データベースコストを除外することによるCPTの低下は、エンジニアリング上の勝利ではありません。
よくある間違い
最も一般的な間違いは、環境を混同することです。本番トランザクションは本番コストと一致させる必要があります。開発とステージングには独自の効率メトリクスを設定できますが、本番の数値を希釈化してはいけません。
もう1つの間違いは、失敗した試行を成功したトランザクションとしてカウントすることです。失敗した作業は依然としてコストがかかり、無駄として表示されるべきです。必要に応じて、リクエストあたりのコストの別のメトリクスを保持します。
3番目の間違いは、1つのコンポーネントを局所的に最適化することです。チームはより少ないワーカーを使用してEC2コストを削減するかもしれませんが、キュー遅延とデータベースロック競合が増加するだけです。トランザクションあたりのコストは、フロー全体を悪化させる狭い勝利を阻止するのに役立つため、有用です。
有用な目標
目標は可能な限り低いCPTではありません。目標は、信頼性とパフォーマンスの目標を満たしながら、持続可能な最低のCPTです。つまり、その数値はSLO、インシデント履歴、キャパシティ計画とともにレビューされるべきです。
メトリクスが安定したら、変更を評価する良い方法になります。新しいキャッシュは、データベースコストをそれ自体を正当化するのに十分削減しましたか？より大きなインスタンスファミリーは、ドルあたりのスループットを向上させましたか？書き換えによりコンピュート時間は減少しましたが、データ転送は増加しましたか？トランザクションあたりのコストはすべての質問に答えるわけではありませんが、チームに共有された具体的な出発点を提供します。
リトライをコストシグナルとして扱う
リトライは、多くの場合、集計メトリクスの中に隠れています。ユーザーが1つのレポートを送信しますが、ダウンストリームコールが2回タイムアウトするため、システムは3回試行します。インフラリクエストをカウントすると、分母が高く見えるかもしれません。成功したレポートをカウントすると、追加の試行は完了したトランザクションあたりのコストの増加として表示され、通常はより有用なシグナルです。
CPTと並行してリトライ率を追跡します。安定したトラフィックでCPTが上昇している場合は、リトライストーム、部分的な障害、ロック競合、または非効率的なコードパスを示している可能性があります。分散システムでは、無駄は多くの場合、1つの高価なリクエストではありません。それは、バックオフが適用されなかったり、永続的なエラーの後にリトライを停止しなかったりしたために、何千回も繰り返される安価なリクエストです。
固定費と変動費を分離する
一部のインフラコストは、特定のアーキテクチャでは固定されています。最小のデータベースクラスター、ベースラインの可観測性、ロードバランサー、および小さな常時稼働ワーカープールは、1万件のトランザクションを処理するか10万件を処理するかに関係なく、ほぼ同じコストがかかる場合があります。他のコストはトラフィックに応じて変動します：Lambdaの期間、データ転送、キューリクエスト、ログボリューム、追加のコンピューティング容量。
CPTを固定部分と変動部分に分割すると、数値の解釈が容易になります：
月間固定サービスコスト = $900
月間変動サービスコスト = $600
トランザクション = 300,000
ブレンドCPT = $0.0050
変動CPT = $0.0020
トラフィックが2倍になり、固定費が変わらない場合、ブレンドCPTは改善されるはずです。同時に変動CPTが上昇した場合、スケーリングの非効率性がある可能性があります。おそらく、負荷がかかるとキャッシュヒット率が低下します。おそらく、データベースのクエリプランが変更されます。おそらく、ペイロードが大きくなると転送とログのコストが増加します。
アーキテクチャの選択にユニットエコノミクスを使用する
CPTは、両方とも要件を満たす2つの設計を比較する場合に役立ちます。APIがLambdaまたはECSで実行できるとします。Lambdaは低ボリュームでより安価で、運用がよりシンプルかもしれません。ECSは、トラフィックが安定して高くなると、より安価になる可能性があります。月々の請求書だけではそのストーリーはわかりません。成功したリクエストあたりのコストがそれを物語ります。
同じことがキャッシングにも当てはまります。月額400ドルかかり、データベースコストを100ドル削減するキャッシュは、おそらくコスト最適化ではありませんが、レイテンシ最適化である可能性はあります。400ドルかかり、データベース層を1,200ドル縮小できるキャッシュは、正当化が容易です。新しいコンポーネントを自動的に効率的であると扱うのではなく、決定をレイテンシ、信頼性、CPTに結び付けます。
コストシフトに注意する
チームは、コストを別のラインアイテムに押し込むことで、1つの請求書を下げることがあります。EC2からLambdaに作業を移すと、アイドルコンピュートは削減できますが、期間料金、ログ、またはダウンストリームデータベースの負荷が増加する可能性があります。応答を圧縮するとデータ転送は削減できますが、CPUが追加されます。より積極的なオートスケーリングはコンピューティング時間を削減できますが、コールドスタートやキュー待ち時間が増加する可能性があります。
優れたCPTレビューでは、コストがどこに行ったかを尋ねます。割り当てられた総コストが減少し、サービス品質が維持されている場合、それは本当の勝利です。共有プラットフォームコストが差額を吸収したために1つのアカウントがより安く見える場合、メトリクスは嘘をついています。
ダッシュボードを退屈にする
有用なCPTダッシュボードは派手である必要はありません。毎月同じ定義が必要です：
割り当てられたAWSコスト
成功したトランザクション
トランザクションあたりのコスト
p95またはp99レイテンシ
エラー率
リトライ率
主要なリリースやインシデントに関する注記
デプロイメント、トラフィックスパイク、価格コミットメントの変更、配分ルールの変更に関する注釈を追加します。注釈がないと、人々はグラフを説明するためにストーリーを作り出します。「3月12日に画像処理を非同期ワーカーに移動」のような簡単なメモは、後で時間を節約します。
レビューでメトリクスを使用し、武器として使用しない
トランザクションあたりのコストは、鈍器のターゲットになると悪い行動を引き起こす可能性があります。チームは必要な冗長性を避けたり、ログを削減しすぎたり、クリティカルパスを過小プロビジョニングして数値を良く見せようとするかもしれません。エンジニアリングレビューのメトリクスとして使用し、単独のスコアとして使用しないでください。
最良の会話は実用的に聞こえます：「トラフィックがより重いエンドポイントにシフトしたため、CPTが上昇しました」、「データベースが現在コストの最大の部分を占めています」、「最後のリリース以降、リトライが2倍になりました」、または「Savings Plansによりコンピューティングコストは下がりましたが、ストレージが現在より大きな機会です」。そこでメトリクスがその価値を発揮します。