Programming Self-Study Notebook

勉強したことを忘れないように! 思い出せるように!!

バックエンドエンジニアがテストについて考えた

f:id:overworker:20210214002306p:plain:h400

現在、スマホアプリを通じて、一般ユーザーにサービスを提供するシステムのバックエンドの開発、運用を実施しています。 今回はバックエンドの開発(運用は除外)の観点からテストについて考えたことをまとめたいと思います。

テストに対する考え方を抽象的にまとめました。 (ツールや手法に関する具体的な内容は別の機会を設ける予定です。)

前提

開発対象

  • インフラの開発
  • データベースの開発
  • WebAPIの開発

インフラ環境の種類・特徴

  • ローカル環境:Feature
  • 開発環境(≒バックエンド開発環境):Develop
    • 機能実装時の動作検証環境
  • 結合テスト環境(≒フロントエンド開発環境):Staging
    • 本番環境と同等のスペック
  • 本番環境:Production
    • 実際のユーザーがアクセスする環境
  • (本番修正環境:Hotfix)
    • 必要に応じて稼働する環境。平常時はsleepしている。

環境別実施テスト

f:id:overworker:20210217075006p:plain

開発環境でのテストの目的

機能要件に対する確認
- 機能が正しく実装されていることを確認する
バグの発見+除去
- バグに対するコードの変更が、想定外の部分へ影響を及ぼしていないことを確認する

結合テスト環境でのテストの目的

フロントエンドとのI/Fの確認
非機能要件に対する確認
- 本番環境相当の性能が前提となるテスト

テストの種類

ユニットテスト単体テスト

概要

  • プログラムを構成する比較的小さな単位(ユニット)が想定通り動作しているかどうかを検証するテスト。
  • 関数やメソッド単位で実施する。
  • カバレッジ解析、及びテスト拡充を行うことがバグの早期発見につながる。(ホワイトボックステスト

メリット

  • 問題原因の特定や修正が容易。開発全体のバグ修正コストを下げる効果が高い。

課題

  • 開発者にかかる負担が大きくなりやすい。

結合テスト

バックエンド内のパーツ結合

  • 外部に提供する形(私の場合のI/FはWebAPI)で使用し、正常系および異常系が仕様通りの振る舞いをしていることを確認する
  • 公開仕様を網羅するようにテストを拡充する

フロントエンドとの結合

  • 外部(私の場合はスマホアプリ)から実際に使用して、想定通りの振る舞いをしていることを確認する
    • 私の場合はスマホアプリ開発が他のグループなので、疎通確認程度の確認を実施してもらっている
  • 疎通確認

差分検証

シナリオテスト(WebAPIの組み合わせテスト)

  • 複数のWebAPIを順番に利用し、個々の結果及び最終結果が想定通りであることを確認する。

システムテスト

  • ユースケースを想定したテスト
  • エンドユーザーが実施する操作を想定したシナリオテストを実施する

性能テスト(非機能要件に対する確認)

ロードテスト

  • 想定ユーザー数想定アクセス数相当での負荷をかけた際に、想定通り機能することを確認する。

ストレステスト

  • 実際に限界を超える負荷を与え、最初に発生する部分はどこかどのような問題が生じるかを確認するテスト。
    • 結果をもとに、発生する問題が許容可能な内容か問題に対しどのように対応を行うかをあらかじめ想定しておく。

脆弱性検証(リリース準備期に実施)

  • インターネット上に公開されるサービスであるため、あらゆる攻撃に対する耐性が必要になる。
  • 重大な問題が発覚した場合は、リリースを中止せざるを得ない場合もある。

WebAPI

  • WebAPIを悪用する攻撃への耐性を確認する。

インフラ

  • インフラの使用方法等により生じる可能性がある脆弱性の確認を実施する。

システムテスト(リリース準備期に実施)

疎通確認テスト(リリース時に実施)

  • リリース内容が正しく反映されていることを確認するためのテスト

テスト機能のためにポイント

テストに対するコスト(時間、手間、予算)は品質と連動しやすい要素だと思いますが、計画の範囲内で効果を最大化することを検討する必要があります。
効率的な開発のために出来ることを検討します。

品質を高める

開発環境へのテスト実施回数を増やす

  • 開発段階で実施するテストを充実させることが、早い段階での品質向上に貢献しするとともに、手戻りを減らすことがができます。

自動化する

  • 開発環境に対するテスト(単体テスト結合テスト、シナリオテスト)は自動化するためのツールがそろっていることが多いです。
    • テストの実施~テスト結果の通知を自動化することで、バグ発生~バグの発見~バグ修正の時間サイクルを短縮することが可能になります。

ルール化する

  • テストはスキルの違い意識の違いの両方が影響する項目です。
  • この違いにより、作成・実施されるテストの質と量が大きく影響を受けます。
  • この差を埋めるための手段として、プログラムをリリースするための条件にユニットテストのカバレッジ結合テストの実施レポート作成等を定めることをお勧めします。

効率を高める

専門性が高い項目は業務委託をする。

  • 脆弱性検証は最新の攻撃手法や対応方法に対する情報更新コストが非常に大きいので専門家に委託することをお勧めします。
  • 社内で専門チームを育成しても、世間的に需要の高い技術なので転職による機能喪失のリスクが高いです。

その他の記事へ

AWS CloudWatchでメトリクスをグラフ化してみた

f:id:overworker:20200812002527p:plain:h150

以下は私が個人的にグラフ化している、メトリクスの設定値です。

発生した障害の内容を確認する

  • クラウドウォッチアラーム等と組み合わせることで、障害、または障害の前兆を検知し、被害が拡大する前に行動をとることが求められる項目

APIGateway

5XXError

  • 指定された期間に取得されたサーバー側エラーの数。
  • Sum 統計は、このメトリクス、つまり、指定された期間内の 5XXError エラーの合計数を表します。
  • Average 統計は、5XXError のエラー率、つまり、5XXError エラーの合計数をその期間のリクエストの合計数で割ったものです。
    • 分母は Count メトリクス (下記) に対応します。

ポイント

  • 5XXのエラーは意図的に発生させていない可能性が非常に高い。
  • CloudWwatchAlarm等を使って全ての原因を調査し、原因の除去を検討する覚悟でいたべき。

Lambda

Errors

  • 関数エラーが発生した呼び出しの数。
  • 関数エラーには、コードによってスローされた例外と、Lambda ランタイムによってスローされた例外が含まれます。
  • ランタイムは、タイムアウトや設定エラーなどの問題に対してエラーを返します。
  • エラー率を計算するには、Errors の値を Invocations の値で割ります。

ポイント

  • コードにより例外がスローされた場合、及びタイムアウトが発生した場合はコード上のバグシステム的なバグ仕様的なバグを疑う必要がる。

Throttles

  • ロットリングされた呼び出しリクエストの数。
  • すべての関数インスタンスがリクエストを処理していて、スケールアップできる同時実行がない場合、Lambda は TooManyRequestsException を使用して追加のリクエストを拒否します。
  • ロットリングされたリクエストやその他の呼び出しエラーは、Invocations または Errors としてカウントされません。

ポイント

  • 事前にConcurrentExecutionsを確認しておくことで前兆を検知することが可能な場合がある。
  • Lambdaの同時起動数の上限緩和申請という選択肢があるかもしれない。

DynamoDB

ReadThrottleEvents/WriteThrottleEvents

  • テーブルまたはグローバルセカンダリインデックスのプロビジョニングされた「読み取り/書き込み」容量ユニットを超える DynamoDB へのリクエスト。

ポイント

  • 既に飽和状態であることを示す。
  • システム、設定値、内部処理シーケンス等の見直しが必要

ThrottledRequests

  • リソース (テーブルやインデックスなど) でプロビジョニングされたスループットの上限を超える、DynamoDB へのリクエスト。

ポイント

  • 既に飽和状態であることを示す。
  • システム、設定値、内部処理シーケンス等の見直しが必要

SystemErrors

  • 指定された期間中に HTTP 500 ステータスコードを生成する、DynamoDB または DynamoDB ストリームへのリクエスト。
  • 通常、HTTP 500 は内部サービスエラーを示します。

ポイント

  • DynamoDBの使い方が悪い可能性もないわけではない?

UserErrors

  • 指定された期間中に HTTP 400 ステータスコードを生成する、DynamoDB または DynamoDB ストリーム へのリクエスト。
  • 通常、HTTP 400 は、パラメータの無効な組み合わせ、存在しないテーブルの更新の試み、不正なリクエスト署名などのクライアント側エラーを示します。

ポイント

  • DynamoDBの使い方が悪い可能性が非常に高いです。

RDS

障害の気配を検知する

  • クラウドウォッチアラーム等と組み合わせることで、障害、または障害の前兆を検知し、被害が拡大する前に行動をとることが求められる項目

APIGateway

Latency

ポイント

  • APIGatewayのタイムアウトは30秒です。内部処理時間が想定以上に長くAPIGatewayでタイムアウトが発生した場合、APIGatewayはクライアントに対し504を返却します。
  • Latencyを確認することで2XX(正常動作)504(タイムアウト)の間に存在する5XXエラーの前兆見落とされた異常動作を検知することができるかもしれません。
    • Max値を確認するのが良いでしょう。

Lambda

ConcurrentExecutions

f:id:overworker:20210207145633p:plain - イベントを処理している関数インスタンスの数。この数値がリージョンの同時実行クォータ、または関数で設定した予約済み同時実行制限に達すると、追加の呼び出しリクエストがスロットリングされます。

ポイント

  • Lambdaの同時起動数の上限は初期設定で1000です。上限を超えた処理はスロットリング(エラー)されます。
  • つまり起動数の上限設定に対し、どの程度の余裕があるかを観察しておく必要があります。
    • Max値を確認するのが良いでしょう。

Duration

  • 関数コードがイベントの処理に費やす時間。
  • 関数のインスタンスによって処理された最初のイベントの場合、これには初期化時間が含まれます。
  • 呼び出しの請求期間は、最も近い 100 ミリ秒に切り上げられた Duration の値です。

ポイント

  • 各Lambdaに設定されているタイムアウト時間との関係を確認することで、障害の可能性を事前に検知することができるかもしれない。

DynamoDB

RDS

CPUUtilization

f:id:overworker:20210207145651p:plain - CPU 使用率 (%)

ポイント

  • CPU使用率が100(%)に張り付いた状態は、DBとして機能しなくなっている可能性が高いです。
  • 付加状況の飽和を事前に検知し、対策を打つ必要があります。

BurstBalance

  • バースト残量 (%)
  • 汎用 SSD (gp2) のバーストバケット I/O クレジットの利用可能パーセント。

ポイント

  • バースト残量 (%)が0(%)になると、各種Read/Write等の応答速度(処理速度)が著しく低下する可能性があります。
  • バースト残量の枯渇を事前に検知し、対策を打つ必要があります。

BinLogDiskUsage

  • バイナリログのディスク使用状況 (MB)
  • プライマリでバイナリログが占有するディスク領域の量。MySQL リードレプリカに適用されます。

FreeableMemory

  • 解放可能なメモリ (MB)
  • 使用可能な RAM の容量。
  • MariaDBMySQLOracle、および PostgreSQL DB インスタンスの場合、このメトリクスは /proc/meminfo の MemAvailable フィールドの値を報告します。

FreeStorageSpace

  • 空きストレージ領域 (MB)
  • 使用可能なストレージ領域の容量。

パフォーマンスの改善を検討する

  • 異常が発生していないことを確認するへの対応がパフォーマンスの改善を検討するに対しても効果を発揮することは言うまでもないが、その手前にも改善すべきポイントを発見するためのがある。

APIGateway

4XXError

  • 指定された期間に取得されたクライアント側エラーの数。
  • Sum 統計は、このメトリクス、つまり、指定された期間内の 4XXError エラーの合計数を表します。
  • Average 統計は、4XXError のエラー率、つまり、4XXError エラーの合計数をその期間のリクエストの合計数で割ったものです。分母は Count メトリクス (下記) に対応します。

ポイント

  • 4XXのエラーはクライアント側に原因があることがほとんどであるが、なぜクライアントが4XXエラーを出しているかを考えることがクライアントに対するユーザビリティー向上につながる可能性がある。
  • 改善ポイントを探るためには、個々の4XXエラーの内容に目を向ける必要がある。
  • 改善効果を定量的に評価するためにはAverage統計が役立つ可能性がある。

Latency

f:id:overworker:20210207145510p:plain - API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間。レイテンシーには、統合のレイテンシーおよびその他の API Gateway のオーバーヘッドが含まれます。

ポイント

  • レイテンシーの増加は内部資源(各種CPU等)の負荷の増加ユーザービリティーの低下の両方を意味することが多い。
  • API毎にレイテンシーを可視化することにより、どのAPIが内部資源へ負荷をより多く与えているかが確認できる。
    • サーバでの改善が難しい場合は、クライアントでの使い方を含めた改善によるユーザービリティの向上を検討することが可能かもしれない。
  • Average値を確認することで、平均的に負荷を高めている処理を発見することにができます。
  • Max値を確認することで、例外的に負荷を高めている項目を確認することができます。

Lambda

DynamoDB

SuccessfulRequestLatency

  • 指定された期間中に DynamoDB または DynamoDB ストリームに対して成功したリクエスト。
  • SuccessfulRequestLatency は、2 種類の情報を提供できます。

ポイント

  • レイテンシーの増加は内部資源(各種CPU等)の負荷の増加ユーザービリティーの低下の両方を意味することが多い。

RDS

ReadLatency/WriteLatency

f:id:overworker:20210207145724p:plain - 「読み取り/書き込み」レイテンシー (ミリ秒) - 1 回のディスク I/O 操作にかかる平均時間。

ポイント

  • レイテンシーの増加は内部資源(各種CPU等)の負荷の増加ユーザービリティーの低下の両方を意味することが多い。
  • indexのつけ方、正規化の程度、場合によってはDBの構成を冗長化することで、アクセスを高速化することを検討しても良い。

ReplicaLag

ポイント

  • リードレプリカを使用することは多いと思う。
  • 実際に遅延がどの程度許容されるかよりも、遅延を前提としたシステムを構築できているかの方が重要な場合もある。

DatabaseConnections

  • DB 接続 (数)
  • 使用中のデータベース接続の数。
  • メトリクス値には、データベースによってまだクリーンアップされていない、切断されたデータベース接続が含まれていない可能性があります。
  • したがって、データベースによって記録されるデータベース接続の数は、メトリクス値よりも多い可能性があります。

ReadIOPS/WriteIOPS

  • 読み取り IOPS (数/秒)/書き込み IOPS (数/秒)
  • 1 秒あたりのディスク「読み取り/書き込み」 I/O 操作の平均回数。
  • 単位: カウント/秒

ユーザーの行動を分析する

APIGateway

Count

f:id:overworker:20210207145427p:plain - 指定された期間内の API リクエストの合計数。 - SampleCount 統計は、このメトリクスを表します。

ポイント

  • 時系列のデータを確認することで、時間帯別のリクエスト数の変化をかくにんすることができる
  • さらに、API別のCountを確認することで、機能別の利用状況を確認することができる。
    • リクエスト数が多いAPIに対しての解釈は難しい、クライアントから指示されている機能の可能性もあるが、クライアントが不必要なAPIコールを強いられている可能性もある。

Lambda

Invocations

  • 関数コードが実行された回数 (成功した実行や関数エラーが発生した実行を含む)。
  • 呼び出しリクエストがスロットリングされた場合、呼び出しは記録されません。それ以外の場合は、呼び出しエラーになります。これは、請求対象リクエストの数に等しくなります。

ポイント

  • 時系列のデータを確認することで、時間帯別の起動状況を確認することができる
  • APIと直接連携しないバックグラウンドでのLambda処理の回数も確認することができる

DynamoDB

RDS

補足:実装時に確認しておくべきエラー

Lambda

DeadLetterErrors

  • 非同期呼び出しの場合、Lambda がイベントをデッドレターキューに送信しようとしたが、失敗した回数。
  • デッドレターエラーは、アクセス許可エラー、リソースの設定ミス、またはサイズ制限が原因で発生する可能性があります。

DestinationDeliveryFailures

  • 非同期呼び出しの場合、Lambda がイベントを送信先に送信しようとしたが、失敗した回数。
  • 配信エラーは、アクセス許可エラー、リソースの設定ミス、またはサイズ制限が原因で発生する可能性があります。

DynamoDB

RDS

その他の記事へ

RDSのメトリクスについて調べてみた

f:id:overworker:20200812002527p:plain:h150

メトリクスを単位別にならげ変えてみました。

単位:パーセント

BurstBalance

  • バースト残量 (%)
  • 汎用 SSD (gp2) のバーストバケット I/O クレジットの利用可能パーセント。

CPUUtilization

  • CPU 使用率 (%)

単位:時間(ミリ秒)

ReadLatency/WriteLatency

  • 「読み取り/書き込み」レイテンシー (ミリ秒)
  • 1 回のディスク I/O 操作にかかる平均時間。

ReplicaLag

単位:バイト

BinLogDiskUsage

  • バイナリログのディスク使用状況 (MB)
  • プライマリでバイナリログが占有するディスク領域の量。MySQL リードレプリカに適用されます。

FreeableMemory

  • 解放可能なメモリ (MB)
  • 使用可能な RAM の容量。
  • MariaDBMySQLOracle、および PostgreSQL DB インスタンスの場合、このメトリクスは /proc/meminfo の MemAvailable フィールドの値を報告します。

FreeStorageSpace

  • 空きストレージ領域 (MB)
  • 使用可能なストレージ領域の容量。

MaximumUsedTransactionIDs

OldestReplicationSlotLag

  • 最も古いレプリケーションスロット遅延 (MB)
  • 受信した先行書き込み (WAL) データに関して最も遅延の長いレプリカの遅延サイズ。
  • PostgreSQL に適用されます。
  • 単位: メガバイト

ReplicationSlotDiskUsage

SwapUsage

TransactionLogsDiskUsage

単位:Count

DatabaseConnections

  • DB 接続 (数)
  • 使用中のデータベース接続の数。
  • メトリクス値には、データベースによってまだクリーンアップされていない、切断されたデータベース接続が含まれていない可能性があります。
  • したがって、データベースによって記録されるデータベース接続の数は、メトリクス値よりも多い可能性があります。

DiskQueueDepth

  • キューの深さ (数)
  • 未処理のディスク I/O アクセス (読み取り/書き込みリクエスト) の数。

単位:クレジット (vCPU 分)

CPUCreditUsage

  • CPU クレジット使用状況 (数)
  • (T2 インスタンス) CPU 使用率に関してインスタンスで消費される CPU クレジットの数。
  • 1 CPUクレジットは、1 分間 100% の使用率で実行される 1 つの vCPU、または vCPU、使用率、時間の同等の組み合わせに相当します。
  • たとえば、2 分間 50% の使用率で実行されている 1 つの vCPU、または 2 分間 25% の使用率で実行されている 2 つの vCPU があるとします。

  • CPU クレジットメトリクスは、5 分間隔でのみ利用可能です。5 分を超える期間を指定する場合は、Sum 統計の代わりに Average 統計を使用します。

CPUCreditBalance

  • CPU クレジット残量 (数)

  • (T2 インスタンス) インスタンスが起動または開始後に蓄積した獲得 CPU クレジットの数。

  • T2 スタンダードの場合、CPUCreditBalance には蓄積された起動クレジットの数も含まれます。
  • クレジットは、獲得後にクレジット残高に蓄積され、消費されるとクレジット残高から削除されます。
  • クレジット残高には、インスタンスサイズによって決まる上限があります。
  • 制限に到達すると、獲得された新しいクレジットはすべて破棄されます。
  • T2 スタンダードの場合、起動クレジットは制限に対してカウントされません。
  • CPUCreditBalance のクレジットは、インスタンスがそのベースライン CPU 使用率を超えてバーストするために消費できます。
  • インスタンスが実行中の場合、CPUCreditBalance のクレジットは期限切れになりません。
  • インスタンスが停止すると、CPUCreditBalance は保持されず、蓄積されたすべてのクレジットが失われます。

  • CPU クレジットメトリクスは、5 分間隔でのみ利用可能です。

単位:カウント/時間

FailedSQLServerAgentJobsCount

  • 失敗した SQL Server エージェントジョブ数 (数/分)
  • 直近 1 分間に失敗した Microsoft SQL Server エージェントジョブの数。
  • 単位: カウント/分

ReadIOPS/WriteIOPS

  • 読み取り IOPS (数/秒)/書き込み IOPS (数/秒)
  • 1 秒あたりのディスク「読み取り/書き込み」 I/O 操作の平均回数。
  • 単位: カウント/秒

単位:バイト/秒

NetworkReceiveThroughput

NetworkTransmitThroughput

ReadThroughput/WriteThroughput

  • 「読み取り/書き込み」スループット (MB/秒)
  • 1 秒あたりのディスクからの平均「読み取り/書き込み」バイト数。

TransactionLogsGeneration

その他の記事へ

APIGatewayのメトリクスについて調べてみた

f:id:overworker:20200812002527p:plain:h150

メトリクスを単位別にならげ変えてみました。

単位:Count

4XXError

  • 指定された期間に取得されたクライアント側エラーの数。
  • Sum 統計は、このメトリクス、つまり、指定された期間内の 4XXError エラーの合計数を表します。
  • Average 統計は、4XXError のエラー率、つまり、4XXError エラーの合計数をその期間のリクエストの合計数で割ったものです。分母は Count メトリクス (下記) に対応します。

5XXError

  • 指定された期間に取得されたサーバー側エラーの数。
  • Sum 統計は、このメトリクス、つまり、指定された期間内の 5XXError エラーの合計数を表します。
  • Average 統計は、5XXError のエラー率、つまり、5XXError エラーの合計数をその期間のリクエストの合計数で割ったものです。分母は Count メトリクス (下記) に対応します。

CacheHitCount

  • 指定された期間内に API キャッシュから配信されたリクエストの数。
  • Sum 統計は、このメトリクス、つまり、指定された期間内のキャッシュヒットの合計数を表します。
  • Average 統計は、キャッシュヒット率、つまり、キャッシュヒットの合計数をその期間のリクエストの合計数で割ったものです。分母は Count メトリクス (下記) に対応します。

CacheMissCount

  • API キャッシュが有効になっている特定の期間における、バックエンドから提供されたリクエストの数。
  • Sum 統計は、このメトリクス、つまり、指定された期間内のキャッシュミスの合計数を表します。
  • Average 統計は、キャッシュミス率、つまり、キャッシュミスの合計数をその期間のリクエストの合計数で割ったものです。分母は Count メトリクス (下記) に対応します。

Count

  • 指定された期間内の API リクエストの合計数。
  • SampleCount 統計は、このメトリクスを表します。

単位:Millisecond

IntegrationLatency

  • API Gateway がバックエンドにリクエストを中継してから、バックエンドからレスポンスを受け取るまでの時間。

Latency

その他の記事へ

Lambdaのメトリクスについて調べてみた

f:id:overworker:20200812002527p:plain:h150

各種AWSサービスの利用状況をグラフ化したときのメモです。

メトリクスの分類

  • 呼び出しメトリクスの使用
  • パフォーマンスメトリクスの使用
  • 同時実行メトリクスの使用

呼び出しメトリクスの使用

Invocations

  • 関数コードが実行された回数 (成功した実行や関数エラーが発生した実行を含む)。呼び出しリクエストがスロットリングされた場合、呼び出しは記録されません。それ以外の場合は、呼び出しエラーになります。これは、請求対象リクエストの数に等しくなります。

Errors

  • 関数エラーが発生した呼び出しの数。関数エラーには、コードによってスローされた例外と、Lambda ランタイムによってスローされた例外が含まれます。ランタイムは、タイムアウトや設定エラーなどの問題に対してエラーを返します。エラー率を計算するには、Errors の値を Invocations の値で割ります。

DeadLetterErrors

  • 非同期呼び出しの場合、Lambda がイベントをデッドレターキューに送信しようとしたが、失敗した回数。デッドレターエラーは、アクセス許可エラー、リソースの設定ミス、またはサイズ制限が原因で発生する可能性があります。

DestinationDeliveryFailures

  • 非同期呼び出しの場合、Lambda がイベントを送信先に送信しようとしたが、失敗した回数。配信エラーは、アクセス許可エラー、リソースの設定ミス、またはサイズ制限が原因で発生する可能性があります。

Throttles

  • ロットリングされた呼び出しリクエストの数。すべての関数インスタンスがリクエストを処理していて、スケールアップできる同時実行がない場合、Lambda は TooManyRequestsException を使用して追加のリクエストを拒否します。スロットリングされたリクエストやその他の呼び出しエラーは、Invocations または Errors としてカウントされません。

ProvisionedConcurrencyInvocations

  • プロビジョニングされた同時実行で関数コードが実行される回数。

ProvisionedConcurrencySpilloverInvocations

  • プロビジョニングされたすべての同時実行が使用されているときに、標準同時実行で関数コードが実行される回数。

パフォーマンスメトリクスの使用

Duration

  • 関数コードがイベントの処理に費やす時間。関数のインスタンスによって処理された最初のイベントの場合、これには初期化時間が含まれます。呼び出しの請求期間は、最も近い 100 ミリ秒に切り上げられた Duration の値です。

IteratorAge

  • ストリームから読み取るイベントソースマッピングの場合、イベントの最後のレコードの所要時間。所要時間は、ストリームがレコードを受信してから、イベントソースマッピングがイベントを関数に送信するまでの時間です。

同時実行メトリクスの使用

ConcurrentExecutions

  • イベントを処理している関数インスタンスの数。この数値がリージョンの同時実行クォータ、または関数で設定した予約済み同時実行制限に達すると、追加の呼び出しリクエストがスロットリングされます。

ProvisionedConcurrentExecutions

  • プロビジョニングされた同時実行でイベントを処理している関数インスタンスの数。プロビジョニングされた同時実行数を割り当てたエイリアスまたはバージョンの呼び出しごとに、Lambda は現在のカウントを出力します。

ProvisionedConcurrencyUtilization

  • バージョンまたはエイリアスの場合、ProvisionedConcurrentExecutions の値を、割り当て済みのプロビジョニングされた同時実行の合計量で割った値。たとえば、.5 は、割り当て済みのプロビジョニングされた同時実行数の 50% が使用中であることを示します。

UnreservedConcurrentExecutions

  • AWS リージョンの場合、同時実行が予約されていない関数によって処理されているイベントの数。

その他の記事へ

DynamoDBのメトリクスについて調べてみた

f:id:overworker:20200812002527p:plain:h150

各種AWSサービスの利用状況をAWS CloudWatchのメトリクスでグラフ化したときのメモです。
AWSのサイトだとアルファベット順でソートされていそうですが、少し読みづらいので自分なりにソートしてみました。

単位:Count

AccountMaxReads

アカウントで使用できる読み取りキャパシティーユニットの最大数。この制限は、オンデマンドテーブルまたはグローバルセカンダリインデックスには適用されません。

有効な統計:

Maximum – アカウントで使用できる読み取りキャパシティーユニットの最大数。

AccountMaxWrites

アカウントで使用できる書き込みキャパシティーユニットの最大数。この制限は、オンデマンドテーブルまたはグローバルセカンダリインデックスには適用されません。

有効な統計:

Maximum – アカウントで使用できる書き込みキャパシティーユニットの最大数。

AccountMaxTableLevelReads

アカウントのテーブルまたはグローバルセカンダリインデックスで使用できる読み取りキャパシティーユニットの最大数。オンデマンドテーブルの場合は、この制限により、テーブルまたはグローバルセカンダリインデックスが使用できる最大読み取りリクエスト単位が制限されます。

有効な統計:

Maximum – アカウントのテーブルまたはグローバルセカンダリインデックスで使用できる読み取りキャパシティーユニットの最大数。

AccountMaxTableLevelWrites

アカウントのテーブルまたはグローバルセカンダリインデックスで使用できる書き込みキャパシティーユニットの最大数。オンデマンドテーブルの場合は、この制限により、テーブルまたはグローバルセカンダリインデックスが使用できる最大書き込みリクエストのユニットが制限されます。

有効な統計:

Maximum – アカウントのテーブルまたはグローバルセカンダリインデックスで使用できる書き込みキャパシティーユニットの最大数。

ConsumedReadCapacityUnits

指定の期間内に消費された読み取り容量ユニットの数。これにより、どれだけのプロビジョンドスループットが使用されたかをトラックすることができます。テーブル、すべてのグローバルセカンダリインデックス、または特定のグローバルセカンダリインデックスで消費された読み取り容量の合計を取得できます。詳細については、「読み込み/書き込みキャパシティーモード」を参照してください。

注記 Sum の統計を使用して、使用したスループットを算出します。たとえば、1 分間の Sum の値を取得し、1 分間の秒数 (60) で除算して、1 秒あたりの平均 ConsumedReadCapacityUnits を算出します (この平均によって、その 1 分間に発生した読み込みアクティビティでの、大幅であっても短い急増は明らかになりません)。その算出した値を DynamoDB に指定したプロビジョンドスループットの値と比較できます。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計:

Minimum – テーブルまたはインデックスへの個別のリクエストによって消費される読み込みキャパシティーユニットの最小数。

Maximum – テーブルまたはインデックスへの個別のリクエストによって消費される読み込みキャパシティーユニットの最大数。

Average – 消費されたリクエストごとの平均読み込みキャパシティー

注記 Average 値は、サンプル値がゼロになるアイドル状態の期間によって影響を受けます。

Sum – 消費された合計読み込みキャパシティーユニット数。これは ConsumedReadCapacityUnits メトリクスで最も有用な統計です。

SampleCount – DynamoDB へのリクエスト数 (読み込みキャパシティーを消費していない場合でも関係ありません)。

注記 SampleCount 値は、サンプル値がゼロになるアイドル状態の期間によって影響を受けます。

ConsumedWriteCapacityUnits

指定の期間内に消費された書き込み容量ユニットの数。これにより、どれだけのプロビジョンドスループットが使用されたかをトラックすることができます。テーブル、すべてのグローバルセカンダリインデックス、または特定のグローバルセカンダリインデックスで消費された書き込み容量の合計を取得できます。詳細については、「読み込み/書き込みキャパシティーモード」を参照してください。

注記 Sum の統計を使用して、使用したスループットを算出します。たとえば、1 分間の Sum の値を取得し、1 分間の秒数 (60) で除算して、1 秒あたりの平均 ConsumedWriteCapacityUnits を算出します (この平均によって、その 1 分間に発生した書き込みアクティビティでの、大幅であっても短い急増は明らかになりません)。その算出した値を DynamoDB に指定したプロビジョンドスループットの値と比較できます。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計:

Minimum – テーブルまたはインデックスへの個別のリクエストによって消費される書き込みキャパシティーユニットの最小数。

Maximum – テーブルまたはインデックスへの個別のリクエストによって消費される書き込みキャパシティーユニットの最大数。

Average – 消費されたリクエストごとの平均書き込みキャパシティー

注記 Average 値は、サンプル値がゼロになるアイドル状態の期間によって影響を受けます。

Sum – 消費された合計書き込みキャパシティーユニット数。これは ConsumedWriteCapacityUnits メトリクスで最も有用な統計です。

SampleCount – DynamoDB へのリクエスト数 (書き込みキャパシティーを消費していない場合でも関係ありません)。

注記 SampleCount 値は、サンプル値がゼロになるアイドル状態の期間によって影響を受けます。

ProvisionedReadCapacityUnits

テーブルまたはグローバルセカンダリインデックスのプロビジョニングされた読み取り容量ユニットの数。

TableName ディメンションは、任意のグローバルセカンダリインデックスではなく、テーブルの ProvisionedReadCapacityUnits を返します。グローバルセカンダリインデックスの ProvisionedReadCapacityUnits を表示するには、TableName と GlobalSecondaryIndex の両方を指定する必要があります。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計

Minimum – プロビジョニングされた読み込みキャパシティーの最も低い設定。UpdateTable を使用して読み込みキャパシティーを引き上げる場合、このメトリクスは、この期間中にプロビジョニングされた ReadCapacityUnits の最も低い値を示します。

Maximum – プロビジョニングされた読み込みキャパシティーの最も高い設定。UpdateTable を使用して読み込みキャパシティーを引き下げる場合、このメトリクスは、この期間中にプロビジョニングされた ReadCapacityUnits の最も高い値を示します。

Average – プロビジョニングされた平均読み込みキャパシティー。ProvisionedReadCapacityUnits メトリクスは 5 分間隔でパブリッシュされます。そのため、プロビジョニングされた読み込みキャパシティーユニットを急速に調整すると、この統計には正しい平均が反映されない場合があります。

ProvisionedWriteCapacityUnits

テーブルまたはグローバルセカンダリインデックスのプロビジョニングされた書き込みキャパシティーユニットの数。

TableName ディメンションは、任意のグローバルセカンダリインデックスではなく、テーブルの ProvisionedWriteCapacityUnits を返します。グローバルセカンダリインデックスの ProvisionedWriteCapacityUnits を表示するには、TableName と GlobalSecondaryIndex の両方を指定する必要があります。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計

Minimum – プロビジョニングされた書き込みキャパシティーの最も低い設定。UpdateTable を使用して書き込みキャパシティーを引き上げる場合、このメトリクスは、この期間中にプロビジョニングされた WriteCapacityUnits の最も低い値を示します。

Maximum – プロビジョニングされた書き込みキャパシティーの最も高い設定。UpdateTable を使用して書き込みキャパシティーを引き下げる場合、このメトリクスは、この期間中にプロビジョニングされた WriteCapacityUnits の最も高い値を示します。

Average – プロビジョニングされた平均書き込みキャパシティー。ProvisionedWriteCapacityUnits メトリクスは 5 分間隔でパブリッシュされます。そのため、プロビジョニングされた書き込みキャパシティーユニットを急速に調整すると、この統計には正しい平均が反映されない場合があります。

ReadThrottleEvents

  • テーブルまたはグローバルセカンダリインデックスのプロビジョニングされた読み取り容量ユニットを超える DynamoDB へのリクエスト。

  • 1 つの リクエストで複数のイベントが発生する場合があります。たとえば、10 個の項目を読み取る BatchGetItem は、10 個の GetItem イベントとして処理されます。イベントが抑制されると、そのイベントの ReadThrottleEvents は 1 ずつ増加します。10 個すべての GetItem イベントが抑制された場合を除き、BatchGetItem 全体の ThrottledRequests メトリックスは増加しません。

  • TableName ディメンションは、任意のグローバルセカンダリインデックスではなく、テーブルの ReadThrottleEvents を返します。グローバルセカンダリインデックスの ReadThrottleEvents を表示するには、TableName と GlobalSecondaryIndex の両方を指定する必要があります。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計

  • SampleCount、Sum

WriteThrottleEvents

  • テーブルまたはグローバルセカンダリインデックスのプロビジョニングされた書き込み容量ユニットを超える DynamoDB へのリクエスト。

  • 1 つの リクエストで複数のイベントが発生する場合があります。たとえば、3 つの任意のグローバルセカンダリインデックスを持つテーブルの PutItem リクエストから、テーブルへの書き込みと、3 つのインデックスへの書き込みという 4 つのイベントが発生します。イベントが調整されると、そのイベントの WriteThrottleEvents メトリクスは 1 ずつ増加します。いずれかのイベントが調整された場合には、各 PutItem リクエストにおいて ThrottledRequests も 1 ずつ増加します。BatchWriteItem においては、すべての ThrottledRequests あるいは BatchWriteItem イベントが抑制された場合を除いて、全体の PutItem の DeleteItem メトリクスは増加しません。

  • TableName ディメンションは、任意のグローバルセカンダリインデックスではなく、テーブルの WriteThrottleEvents を返します。グローバルセカンダリインデックスの WriteThrottleEvents を表示するには、TableName と GlobalSecondaryIndex の両方を指定する必要があります。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計

  • Sum、SampleCount

ConsumedChangeDataCaptureUnits

消費された変更データキャプチャユニットの数。

ディメンション

  • TableName、DelegatedOperation

有効な統計

  • Minimum、Maximum、Average

OnlineIndexConsumedWriteCapacity

新しいグローバルセカンダリインデックスがテーブルに追加される際に消費された書き込み容量ユニットの数。インデックスの書き込み容量が小さすぎる場合、バックフィルフェーズ中の受信書き込みアクティビティは調整される可能性があります。これによりインデックスの作成にかかる時間が長くなる場合があります。インデックスの書き込み容量がプロビジョニング不足かどうかを判断するには、インデックスの構築中に、この統計を監視する必要があります。

インデックスの構築中であっても、UpdateTable 操作を使用して、インデックスの書き込み容量を調整することができます。

インデックスの作成中に消費された書き込みスループットは、インデックスの ConsumedWriteCapacityUnits メトリクスに含まれません。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計

  • Minimum、Maximum、Average、SampleCount、Sum

OnlineIndexPercentageProgress

新しいグローバルセカンダリインデックスがテーブルに追加されている場合の完了率 (%)。DynamoDB は、最初に新しいインデックスにリソースを割り当て、次に表からインデックスに属性を埋め戻す必要があります。大きなテーブルの場合、このプロセスに長時間かかる場合があります。DynamoDB によるインデックスの構築時に相対的な進捗状況を確認するには、この統計を監視する必要があります。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計

  • Minimum、Maximum、Average、SampleCount、Sum

OnlineIndexThrottleEvents

新しいグローバルセカンダリインデックスがテーブルに追加される際に発生した書き込み調整イベントの数。これらのイベントの発生は、インデックス作成の完了に長い時間がかかることを示しています。受信書き込みアクティビティが、インデックスに対してプロビジョニングされた書き込みスループットを超えているためです。

インデックスの構築中であっても、UpdateTable 操作を使用して、インデックスの書き込み容量を調整することができます。

インデックスの作成中に発生した調整イベントは、インデックスの WriteThrottleEvents メトリクスに含まれません。

ディメンション

  • TableName、GlobalSecondaryIndexName

有効な統計

  • Minimum、Maximum、Average、SampleCount、Sum

PendingReplicationCount

(このメトリクスは DynamoDB グローバルテーブル用です。) 1 つのレプリカテーブルに書き込まれるが、グローバルテーブルの他のレプリカにはまだ書き込まれていない項目の更新数。

ディメンション

  • TableName、ReceivingRegion

有効な統計

  • Average、Sample Count、Sum、

ReturnedItemCount

  • 指定された期間中に Query または Scan オペレーションで返された項目の数。

  • 返された項目の数は、評価された項目の数と必ずしも同じではありません。たとえば、100 個の項目が存在していたテーブルで Scan をリクエストしたが、結果を絞り込む FilterExpression を指定したため、15 個の項目のみが返されたとします。この場合、Scan からのレスポンスには、ScanCount として 100 個、Count として 15 個の返された項目が含まれます。

ディメンション

  • TableName、Operation

有効な統計

  • Minimum、Maximum、Average、SampleCount、Sum

ReturnedRecordsCount

指定された期間中に、GetRecords オペレーション (DynamoDB ストリーム) で返されたストリームレコードの数。

ディメンション

  • Operation、StreamLabel、TableName

有効な統計

  • Minimum、Maximum、Average、SampleCount、Sum

TimeToLiveDeletedItemCount

  • 指定した期間中に有効期限 (TTL、Time To Live) で削除された項目の数。このメトリクスにより、テーブルでの TTL による削除のレートをモニタリングできます。

ディメンション

  • TableName

有効な統計

  • Sum

ThrottledPutRecordCount

  • Kinesis Data Stream の容量不足で Kinesis データストリームにレプリケートできなかったレコードの数。

ディメンション

  • TableName、DelegatedOperation

有効な統計

  • Minimum、Maximum、Average、SampleCount

ThrottledRequests

  • リソース (テーブルやインデックスなど) でプロビジョニングされたスループットの上限を超える、DynamoDB へのリクエスト。

  • リクエスト内で任意のイベントがプロビジョンドスループットの制限を超過した場合、ThrottledRequests は 1 ずつ増加します。たとえば、グローバルセカンダリインデックスを持つテーブルの項目を更新する場合、テーブルへの書き込みと、各インデックスへの書き込みという複数のイベントが発生します。1 つ以上のイベントが抑制されると、ThrottledRequests が 1 ずつ増加します。

    • 注記
      • バッチリクエスト (BatchGetItem または BatchWriteItem) では、バッチ内のすべてのリクエストが調整されている場合にのみ ThrottledRequests が増加します。

      • バッチ内の個別のリクエストが調整されている場合、次のいずれかのメトリクスが増加します。

  • ReadThrottleEvents – BatchGetItem 内の調整された GetItem イベント用。

  • WriteThrottleEvents – BatchWriteItem 内の調整された PutItem、DeleteItem イベント用。

    • どのイベントがリクエストを抑制しているかを確認するには、ThrottledRequests と、そのテーブルとインデックスの ReadThrottleEvents と WriteThrottleEvents を比較してください。

    • 注記

      • 調整されたリクエストでは、HTTP 400 ステータスコードになります。これらのすべてのイベントは、ThrottledRequests メトリクスに反映されますが、UserErrors メトリクスには反映されません。

ディメンション

  • TableName、Operation

有効な統計

  • Sum、SampleCount

TransactionConflict

ディメンション

  • TableName

有効な統計:

  • Sum – トランザクション競合が原因で拒否された項目レベルのリクエストの数。

    • 注記
      • TransactWriteItems または TransactGetItems の呼び出しで項目レベルの複数のリクエストが拒否された場合、Sum は項目レベルの Put、Update、Delete、または Get リクエストごとに 1 ずつ増加します。
  • SampleCount – トランザクション競合が原因で拒否されたリクエストの数。

    • 注記
      • TransactWriteItems または TransactGetItems の呼び出しで項目レベルの複数のリクエストが拒否された場合、SampleCount は 1 だけ増加します。
  • Min – TransactWriteItems、TransactGetItems、PutItem、UpdateItem、または DeleteItem の呼び出しで拒否された項目レベルのリクエストの最小数。

  • Max – TransactWriteItems、TransactGetItems、PutItem、UpdateItem、または DeleteItem の呼び出しで拒否された項目レベルのリクエストの最大数。

  • Average – TransactWriteItems、TransactGetItems、PutItem、UpdateItem、または DeleteItem の呼び出しで拒否された項目レベルのリクエストの平均数。

ConditionalCheckFailedRequests

条件付き書き込みに失敗した回数。PutItem、UpdateItem、および DeleteItem オペレーションは、オペレーションの実行前に true と評価される必要のある理論条件の提供を可能にします。この条件が false と評価された場合、ConditionalCheckFailedRequests は 1 ずつ増加します。

注記 条件付き書き込みが失敗すると、HTTP 400 エラー (Bad Request) が発生します。これらのイベントは、ConditionalCheckFailedRequests メトリクスに反映されますが、UserErrors メトリクスには反映されません。

ディメンション

  • TableName

有効な統計

  • Minimum、Maximum、Average、SampleCount、Sum

SystemErrors

  • 指定された期間中に HTTP 500 ステータスコードを生成する、DynamoDB または DynamoDB ストリームへのリクエスト。通常、HTTP 500 は内部サービスエラーを示します。

ディメンション

  • TableName、Operation

有効な統計

  • Sum、SampleCount

UserErrors

  • 指定された期間中に HTTP 400 ステータスコードを生成する、DynamoDB または DynamoDB ストリーム へのリクエスト。通常、HTTP 400 は、パラメータの無効な組み合わせ、存在しないテーブルの更新の試み、不正なリクエスト署名などのクライアント側エラーを示します。

  • このようなイベントは、以下を除き、UserErrors メトリクスにすべて反映されます。

    • ProvisionedThroughputExceededException – このセクションの ThrottledRequests メトリクスを参照してください。

    • ConditionalCheckFailedException – このセクションの ConditionalCheckFailedRequests メトリクスを参照してください。

    • UserErrors は、現在の AWS リージョンおよび現在の AWS アカウントへの DynamoDB または DynamoDB ストリームリクエストに関する HTTP 400 エラーの集計を表します。

有効な統計:

  • Sum、SampleCount

単位:Percent

AccountProvisionedReadCapacityUtilization

アカウントが使用する、プロビジョニングされた読み取りキャパシティーユニットの割合 (%)。

有効な統計:

Maximum – アカウントが使用する、プロビジョニングされた読み取りキャパシティーユニットの最大の割合 (%)。

Minimum – アカウントが使用する、プロビジョニングされた読み取りキャパシティーユニットの最小の割合 (%)。

Average – アカウントが使用する、プロビジョニングされた読み取りキャパシティーユニットの平均比率 (%)。メトリクスは 5 分間隔でパブリッシュされます。そのため、プロビジョニングされた読み込みキャパシティーユニットを急速に調整すると、この統計には正しい平均が反映されない場合があります。

AccountProvisionedWriteCapacityUtilization

アカウントが使用する、プロビジョニングされた書き込みキャパシティーユニットの割合 (%)。

有効な統計:

Maximum – アカウントが使用する、プロビジョニングされた書き込みキャパシティーユニットの最大の割合 (%)。

Minimum – アカウントが使用する、プロビジョニングされた書き込みキャパシティーユニットの最小の割合 (%)。

Average – アカウントが使用する、プロビジョニングされた書き込みキャパシティーユニットの平均比率 (%)。メトリクスは 5 分間隔でパブリッシュされます。そのため、プロビジョニングされた書き込みキャパシティーユニットを急速に調整すると、この統計には正しい平均が反映されない場合があります。

MaxProvisionedTableReadCapacityUtilization

アカウントの最も高いプロビジョニングされた読み取りテーブルまたはグローバルセカンダリインデックスによって使用される、プロビジョニングされた読み取りキャパシティーユニットの割合 (%)。

有効な統計:

Maximum – アカウントの最も高いプロビジョニングされた読み取りテーブルによって使用される、プロビジョニングされた読み取りキャパシティーユニットの最大の割合 (%)。

Minimum – アカウントの最も高いプロビジョニングされた読み取りテーブルによって使用される、プロビジョニングされた読み取りキャパシティーユニットの最小の割合 (%)。

Average – アカウントの最も高いプロビジョニングされた読み取りテーブルによって使用される、プロビジョニングされた読み取りキャパシティーユニットの平均比率 (%)。メトリクスは 5 分間隔でパブリッシュされます。そのため、プロビジョニングされた読み込みキャパシティーユニットを急速に調整すると、この統計には正しい平均が反映されない場合があります。

MaxProvisionedTableWriteCapacityUtilization

アカウントの最も高いプロビジョニングされた書き込みテーブルまたはグローバルセカンダリインデックスによって使用される、プロビジョニングされた書き込みキャパシティーの割合 (%)。

有効な統計

Maximum – アカウントの最も高いプロビジョニングされた書き込みテーブルまたはグローバルセカンダリインデックスによって使用される、プロビジョニングされた書き込みキャパシティーユニットの最大の割合 (%)。

Minimum – アカウントの最も高いプロビジョニングされた書き込みテーブルまたはグローバルセカンダリインデックスによって使用される、プロビジョニングされた書き込みキャパシティーユニットの最小の割合 (%)。

Average – アカウントの最も高いプロビジョニングされた書き込みテーブルまたはグローバルセカンダリインデックスによって使用される、プロビジョニングされた書き込みキャパシティーユニットの平均比率 (%)。メトリクスは 5 分間隔でパブリッシュされます。そのため、プロビジョニングされた書き込みキャパシティーユニットを急速に調整すると、この統計には正しい平均が反映されない場合があります。

単位:Milliseconds

AgeOfOldestUnreplicatedRecord

Kinesis データストリームにレプリケートされていないレコードが最初に DynamoDB テーブルに表示された時点からの経過時間。

ディメンション

  • TableName、DelegatedOperation

有効な統計:

  • Maximum、Minimum、Average

ReplicationLatency

  • (このメトリクスは DynamoDB グローバルテーブル用です。) 1 つのレプリカテーブルに対して DynamoDB ストリームに表示される更新された項目と、グローバルテーブルの別のレプリカに表示される、その項目の間の経過時間。

ディメンション

  • TableName、ReceivingRegion

有効な統計

  • Average、Minimum、Maximum

SuccessfulRequestLatency

  • 指定された期間中に DynamoDB または DynamoDB ストリームに対して成功したリクエスト。SuccessfulRequestLatency は、2 種類の情報を提供できます。

  • 成功したリクエストの経過時間 (Minimum、Maximum、Sum、またはAverage)。

  • 成功したリクエストの数 (SampleCount)。

  • SuccessfulRequestLatency は DynamoDB または DynamoDB ストリーム 内のアクティビティのみを反映し、アカウントのネットワークレイテンシーまたはクライアント側のアクティビティは考慮されません。

ディメンション

  • TableName、Operation

有効な統計

  • Minimum、Maximum、Average、SampleCount

単位:Bytes

ReturnedBytes

  • 指定された期間中に GetRecords オペレーション (DynamoDB ストリーム) で返されたバイト数。

ディメンション

  • Operation、StreamLabel、TableName

有効な統計

  • Minimum、Maximum、Average、SampleCount、Sum

その他の記事へ

開発支援ツール(tox)の導入

f:id:overworker:20200812004214p:plain:h150


『仕事ではPythonを使ったことがない』程度のレベルです。
自習時に調べたことのノートとして記録します。

前提条件

  • WindowsOS
  • VSCodeを利用する

詳細

toxの導入

公式ドキュメント

インストール手順

pip install tox
  • 実行結果
>pip install tox
Collecting tox
  Downloading tox-3.20.1-py2.py3-none-any.whl (83 kB)
     |████████████████████████████████| 83 kB 6.1 MB/s
Requirement already satisfied: toml>=0.9.4 in c:\users\******\appdata\local\programs\python\python38\lib\site-packages (from tox) (0.10.2)
Requirement already satisfied: colorama>=0.4.1 in c:\users\******\appdata\roaming\python\python38\site-packages (from tox) (0.4.1)
Collecting filelock>=3.0.0
  Downloading filelock-3.0.12-py3-none-any.whl (7.6 kB)
Collecting packaging>=14
  Downloading packaging-20.8-py2.py3-none-any.whl (39 kB)
Collecting pluggy>=0.12.0
  Downloading pluggy-0.13.1-py2.py3-none-any.whl (18 kB)
Collecting py>=1.4.17
  Downloading py-1.10.0-py2.py3-none-any.whl (97 kB)
     |████████████████████████████████| 97 kB 6.8 MB/s
Collecting pyparsing>=2.0.2
  Downloading pyparsing-2.4.7-py2.py3-none-any.whl (67 kB)
     |████████████████████████████████| 67 kB ...
Collecting six>=1.14.0
  Downloading six-1.15.0-py2.py3-none-any.whl (10 kB)
Collecting virtualenv!=20.0.0,!=20.0.1,!=20.0.2,!=20.0.3,!=20.0.4,!=20.0.5,!=20.0.6,!=20.0.7,>=16.0.0
  Downloading virtualenv-20.2.2-py2.py3-none-any.whl (5.7 MB)
     |████████████████████████████████| 5.7 MB ...
Requirement already satisfied: appdirs<2,>=1.4.3 in c:\users\******\appdata\local\programs\python\python38\lib\site-packages (from virtualenv!=20.0.0,!=20.0.1,!=20.0.2,!=20.0.3,!=20.0.4,!=20.0.5,!=20.0.6,!=20.0.7,>=16.0.0->tox) (1.4.4)
Collecting distlib<1,>=0.3.1
  Downloading distlib-0.3.1-py2.py3-none-any.whl (335 kB)
     |████████████████████████████████| 335 kB 6.4 MB/s
Installing collected packages: six, pyparsing, filelock, distlib, virtualenv, py, pluggy, packaging, tox
  Attempting uninstall: six
    Found existing installation: six 1.12.0
    Uninstalling six-1.12.0:
      Successfully uninstalled six-1.12.0
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
astroid 2.3.2 requires six==1.12, but you have six 1.15.0 which is incompatible.
Successfully installed distlib-0.3.1 filelock-3.0.12 packaging-20.8 pluggy-0.13.1 py-1.10.0 pyparsing-2.4.7 six-1.15.0 tox-3.20.1 virtualenv-20.2.2

バージョンを確認する

>tox --version
3.20.1 imported from c:\users\******\appdata\local\programs\python\python38\lib\site-packages\tox\__init__.py

設定をカスタマイズする

  • プロジェクトのトップディレクトリにtox.iniというファイルを作成し、内部を記述することで設定をカスタマイズすることができます。
    • コードフォーマッターを利用する場合はFlake8よりも先に実行しておきましょう。
[tox]
envlist = black,flake8,mypy
skipsdist = true

[testenv:flake8]
deps = flake8
commands = flake8 src/*

[testenv:mypy]
deps = mypy
commands = mypy src/*

[testenv:black]
deps = black
commands = black src/*

[flack8]
max-line-length = 119
max-complexity =10