この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
セッション概要
- 登壇者: 江藤武司 & 岩井良和
- Sony Corporation
内容
分散トレーシングを必要とした背景
API Gateway+Lambdaに加えて､非同期イベントが多く､クロスアカウントやオンプレミスも利用していた｡ 調査のために､2ヶ月以前の情報を調査する必要があった｡ 泥臭くやるなら､辺りを付けてAWSアカウントに入ってログを見て...を繰り返す必要がある｡
分散トレーシングとは
マイクロサービスなどの分散アーキテクチャで処理の可視化や追跡性を向上させる為の仕組み｡
- Span: 処理ユニット
- Trace: 関連するSpanをまとめる単位
- Propagation: Trace実現の為のメタデータ
Lambda → SQS → Lambdaというアーキテクチャの場合､人間はこれらのSpanが連携している事が理解できるが､システムは理解できない｡ なので､識別する為のメタデータを差し込んで､システムにTraceを理解させる｡
なぜLake Formationを使うか
複数のAWSアカウントにまたがるログを一元的に集めて分析を行うという要件にマッチし選定した｡ これだけではなく､X-RayやDatadogなど他のツールも使っている｡これらは詳細や短期的なスパンでメトリクス・ログを確認するのに使用している｡
どのように行うか
Step Functionを利用して､CloudWatch Logsのエクスポートを順次行っていく｡そして､Lake Formationを利用して各アカウントからログを集める｡
前述の通り､短期的なスパンでの確認にはDatadogがあるので､こちらはゆっくりで良い｡
集約したデータはS3バケットに保存され､これに対してAthenaでクエリーを行う
トレースIDの重要性
X-Rayだけでは､非同期イベントを追跡するのが困難なので､トレースIDを伝播させて追跡を行います｡
API Gatewayの場合はカスタムHTTP Headerを利用しています｡もしヘッダーが存在しなければ生成します｡
SNSの場合はmessage attributesを利用しています｡SNSにパブリッシュ時にこれを指定する事で､後続にトレースIDを伝えます｡
Step Functionsの場合は､起動時にインプット情報にトレースIDを渡し､各処理にもResultPathを活用してトレースIDを伝えます｡
S3の場合はオブジェクトメタデータを利用します｡S3トリガーにはオブジェクトデータが含まれないので後続の処理でヘッダーを取得します｡問題なのが､削除イベントです｡この場合ヘッダーが取れないので､単一のLambda内で処理を行うなど工夫をしています｡
まとめ
サーバーレスは必然的にマイクロサービスになり､情報が分散してしまいます｡ Lake Formationを使った､分散トレーシングを行う事でシステムの視界を確保できます｡ BIのイメージが強いデータレイクですが､システムの可視化に非常に役立ちます｡
0
