どのようなシチュエーションかが見えないので一般論よりの回答となりますが。
Datadogを見るよりは、まずはユーザーサイドに近い意見や感覚値を吸い上げるのが良いと思います。
ただ漠然と「パフォーマンスアップしたい!」という話が出てくるシチュエーションはあまり考えづらく、なんらかのトリガーとなる事象があってのことと思います。であれば、まずはユーザーサイドに近い人からの意見を吸い上げて仮説を立てて絞り込むのかよろしいかと思います。
例えば、特定のページでのみ応答/表示が遅い、ということであれば、そのページで投げているバックエンドAPIを掘り下げればなにか手がかりがあるかも?と多少なり方向性が見いだせますし、全体的に遅いのであればフロントでロードするファイルサイズが重すぎたり、CDNのキャッシュが十分効いていなかったりするかもしれません。
なにも手がかりのない状態から漠然と手を出すのはさすがに辛すぎますので、報告事例が集められるならそこから網を絞っていくのが良いと思います。
lambdaを使っているということは、おそらく裏は API Gateway や DynamoDB を使っているのでは無いでしょうか。その前提で初歩的なところを挙げるなら、
・DynamoDBをScanしていないか?(これは明確にバッドプラクティスです)
・Lambdaの同時実行数の制限に抵触していないか?(lambdaの同時実行数はリージョン単位で制限があります。たしか、東京リージョンのデフォルトでは100ぐらいだったような気がしてますが、詳しくは公式ドキュメント、 lambda の制限事項をお調べください)
バックエンドにアタリをつけるのであれば、とりあえず lambda の duration time, throttling, error などを見ると思います。API Gateway のレスポンスコードやレイテンシあたりも有力なのではないかと。あとは前述したように DynamoDB に変なクエリを投げていないかコードとスキーマを確認するなどが考えられます(いずれにせよ、収集できる仮説を集めるのが最優先であろうとは思いますが)。
私自身はあまり使ったことがありませんが、トレーシングである程度バックエンドの状況を概観することことで見える傾向があるかもしれません。こちらは Datadog のAPM (個別の有償プランだったと思います)や、AWS の X-Ray を有効化するなどで確認可能です。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/08/08 02:48