はじめに
システムを構築していると、パフォーマンスチューニングの必要な状況に直面することはかなり多いと思います。ただ、パフォーマンスチューニングを行うにはどの処理で何秒かかっているのかを測定して、ボトルネックとなっている箇所を特定しなければなりません。 そんな際に X-Ray をお手軽に使ってみませんか？ というご提案です。お手軽設定
AWS X-Ray には、いろいろと機能がありますが、AWSのベストプラクティスにもあるように まずはスモールスタートで開始することにします。 Lambda 好きの私としては Lamba関数 のパフォーマンスチューニングのネタとして計測に使いたいのでLambda関数内の処理の時間計測で使用したいと思います。ライブラリのインポート
Python の環境へのインストールはpip install aws-xray-sdk
で行います。
AWS Serverless Application Model (AWS SAM) などを利用して構築している場合には、 requirements.txt の中に aws-xray-sdk を追加します。
ソースコード側では、こんな感じで xray_recoreder や patch_all を aws_xray_sdk.core から import します。
参考:
AWS X-Ray – 開発者ガイド – AWS X-Ray SDK for Python
AWS X-Ray SDK for Python - AWS X-Ray
X-Ray SDK for Python を使用して Python アプリケーションを計測します。
docs.aws.amazon.com
aws-xray-sdk-python/README.md at master · aws/aws-xray-sdk-python
AWS X-Ray SDK for the Python programming language. Contribute to aws/aws-xray-sdk-python development by creating an acco...
github.com
サブセグメントの作成
Lambda関数の場合は、セグメントの定義を抜かして、いきなり subsegment から書けます。どうやら親となる segment は Lambda の Trace を ON にしたときからAWS側で作ってくれているようです。 下のように、ソースコードの計測したい箇所の前後をxray_recorder.begin_subsegment と xray_recorder.end_subsegment サブセグメントとして定義することで、そのサブセグメント内にかかる時間を測定します。
ちなみに Lambda 関数内でセグメントの開始を定義( ![]()
![]()
xray_recorder.begin_segment())すると WARNING メッセージが出ますが、WARNINGなので処理は継続します。
Stack overflow – AWS Xray: Cannot create segments inside Lambda function and segment not found
AWS Xray: Cannot create segments inside Lambda function and segment not found
A really strange behaviour I was experiencing, I am following online documentation and while creating a segment to work ...
stackoverflow.com
測定結果確認
Management Console で CloudWatch > 左のメニューの X-Ray トレース > トランザクション検索 から、結果を検索します。 Filter spans by: の下の空欄を選択すると候補がズラッと表示されるので、attributes.aws.lambda.name を選んで = を選択、右側の空白に自分のLambda関数名を入力してクエリ実行ボタンを押します。スパンの下に traceId の一覧が出るのでそこをクリックします。
（正直ここにたどり着くまで迷いました）
2024/12/18 時点でこのBlogを作成している最中に Management Console のレイアウトが変わっていました…
X-Ray トレースの下から、 Application Signals の下に移ったようです。
（レイアウトが変更されてまた迷いました…）
ここから、サービスマップのイケてる図や
本命のトレース詳細が出ます。こんなわかりやすくてかっこいい図を出してくれるんですよ！
これを見てみると、先程ソースコードで囲ったサブセグメントに 284ms かかったことがわかります。
これで、これらの分析を利用してパフォーマンスのボトルネックになっている箇所を特定できるようになりました。
X-Ray なしでボトルネックを分析しようとすると、ひたすら CloudWatch などのログから解析という大変な状況から比べると、とても楽に分析できるようなったと感じます。