Shota Sawada 2021年1月29日に行われた「Tier IV 自動運転Web&Dataミートアップ」のプレゼン資料です https://tier4.connpass.com/event/198897/preview/

1. Shota Sawada
AWS X-Rayを使った
マイクロサービスの
トレーサビリティ向上
Jan 29th, 2021
1

2. Shota SAWADA
Profile
* FMSの開発
* 認証認可基盤の開発
GitHub: @sawadashota
Twitter: @xioota
2

3. CONTENTS
マイクロサービスの課題
分散トレーシングとは
AWS X-Rayの紹介
ティアフォーにおける活用方法
3

4. マイクロサービスにおける課題
4

5. Advantages
5
障害の影響を局所化できる
効率よくリソースをスケールできる
耐障害性
スケーリング効率
デプロイ容易性
小さなチーム・小さなコードベース
再利用性
迅速にデプロイ/ロールバックできる
サービスを独立してデプロイできる
チームやコードベースが小さくなることで生産性
が向上したり、メンバーがオーナーシップを
持ちやすくなる
異なるアプリケーションからサービスを
使うことができる

6. Pain Points
6
サービスが増えていくほど、ローカルでサービスを
end-to-endで動かすことが難しくなる
サービスごとに異なる言語・ランタイム・
データベースが選択可能ではあるが、
オンボーディングコストが高くなる
ローカル開発体験
認知負荷
トラブルシューティング
レイテンシ
データ一貫性
トラブルが起きたときにや影響範囲を調査したり、
原因の特定や解決する難易度が高くなる
モノリスでは1つのプロセスで行ってた処理を
複数ネットワークを経由して行うため
レイテンシが大きくなる
サービスを跨いでトランザクションを張ることが
できない

7. Pain Points
7
サービスが増えていくほど、ローカルでサービスを
end-to-endで動かすことが難しくなる
サービスごとに異なる言語・ランタイム・
データベースが選択可能ではあるが、
オンボーディングコストが高くなる
ローカル開発体験
認知負荷
トラブルシューティング
レイテンシ
データ一貫性
トラブルが起きたときにや影響範囲を調査したり、
原因の特定や解決する難易度が高くなる
モノリスでは1つのプロセスで行ってた処理を
複数ネットワークを経由して行うため
レイテンシが大きくなる
サービスを跨いでトランザクションを張ることが
できない

8. 一般的なトラブルシューティングの流れ
トラブル発生
エンドポイントの特定
原因影響調査 恒久対応
リカバリ
ユーザからのレポートや
アラートでトラブルに気づく
トラブルを引き起こした
エンドポイントを特定
ログやリソース使用状況などから
原因や影響範囲と特定
同じことが起こらないようにする
正しい状態にする
8

9. 一般的なトラブルシューティングの流れ
トラブル発生
エンドポイントの特定
原因影響調査 恒久対応
リカバリ
ユーザからのレポートや
アラートでトラブルに気づく
トラブルを引き起こした
エンドポイントを特定
ログやリソース使用状況などから
原因や影響範囲と特定
同じことが起こらないようにする
正しい状態にする
9

10. 一般的なトラブルシューティングの流れ
トラブル発生
エンドポイントの特定
原因影響調査 恒久対応
リカバリ
ユーザからのレポートや
アラートでトラブルに気づく
トラブルを引き起こした
エンドポイントを特定
ログやリソース使用状況などから
原因や影響範囲と特定
同じことが起こらないようにする
正しい状態にする
10
片っ端から各サービスのログを調査するのはツライ

11. 分散トレーシング
11

12. 分散トレーシングとは
相関ロギングの一種。
分散システムの動作の可視化を助け、
パフォーマンスのプロファイリング、
本番環境でのデバッグ、障害や
インシデントの根本原因分析などに
役立つ。
12
図は「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」より引用 https://research.google/pubs/pub36356/

13. 可視化
複数のコンポーネントに跨って、
リクエストの順序や各コンポーネント
で処理に要した時間が可視化される。
13
図は「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」より引用 https://research.google/pubs/pub36356/

14. 概念
複数のSpanを集まり。Spanの親子関係から
DAG(有効非巡回グラフ)を作ることができる。
Trace
トランザクション内のオペレーションを表す。
以下の状態を持つ
* オペレーション名
* 開始・終了のタイムスタンプ
* attributes
* ログ
* 親Spanの識別子
* 因果関係のある他のSpanへのリンク
* SpanContextの情報(Trace内のSpanを識別する情報)
Span
14
https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/overview.md
Span A
(Root Span)
Span B
Span C
Span D
Span E Span F

15. しくみ
1. ApplicationにSDKをインストール
2. SDKからAgentにトレースデータを送信
3. AgentからCollectorに送信
4. ストレージに保存
15
View
Application
Collector
Storage
SDK
Agent
Application
SDK
Agent

16. 分散トレーシングの仕様と代表的な実装
16
* AWS X-Ray
https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/aws-xray.html
* Google Cloud operations suite (旧Stackdriver)
https://cloud.google.com/stackdriver/docs
* zepkin
https://github.com/openzipkin/zipkin
* Jaeger
https://github.com/jaegertracing/jaeger
* OpenTelemetry (OpenTracingとOpenCensusの時期メジャーバージョン。現在RC)
https://github.com/open-telemetry/opentelemetry-specification

17. AWS X-Ray
17

18. AWS X-Ray
分散トレーシングのマネージドサービス
18

19. OSSの場合はすべてのスタックを
運用しないといけないが・・・
19
View
Application
Collector
Storage
SDK
Agent
Application
SDK
Agent

20. データ保存やサーバの可用性を
気にしなくて良い
20
Application
X-Ray SDK
X-Ray daemon
Application
X-Ray SDK
X-Ray daemon
X-Ray Console
X-Ray API
AWS Managed

21. X-Ray Console
21

22. 特徴
22
データ保存や可用性を気にしなくてよい
AWS Console内でConsoleも提供している
X-Ray DaemonにはUDPで投げっぱなし
X-Ray Daemonが落ちていてもアプリケーションには
影響しない
マネージドサービス
アプリケーションへの影響が軽微
Serverlessとの相性が良い
用語や名前が微妙に異なる
トレースのサイズに上限がある
ELBやLambda、StepFunctionなども
簡単にトレーシングできる
SpanではなくSegmentsという用語を用いたり、
標準化されたHTTPヘッダではなく、
独自のヘッダ名(X-Amzn-Trace-Id)を使用している
トレースサイズのクォータは100-500KBと
されており、引き上げは不可

23. ティアフォーにおける活用方法
23

24. AWS X-Rayの活用状況
Web.Autoでは、様々なAWSのサービスを
使っており、その多くがX-Rayによって
トレースされている
24
Fargate Batch Lambda
Aurora DynamoDB
API Gateway
Athena ELB
Secret
Manager
AppMesh SQS S3

25. Trace Map
25

26. Datadogで可視化
26
X-Ray

27. Datadogで可視化
27
https://docs.datadoghq.com/ja/tracing/guide/serverless_enable_aws_xray/?tab=python

28. 判断材料として
28
エラー発生
原因影響特定
レスポンスタイム低下
パフォーマンス改善の判断

29. 課題
29

30. トレースの最大サイズは100-500KBまで
クォータを超えるとトレースデータは欠損する
引き上げは不可
30

31. gRPC
公式のAWS X-Ray SDKでgRPCに
対応していない
31

32. あとから導入すると導入漏れがある
32
トレースの途中でX-Rayが導入されていないコンポーネントがあると、
その先の処理が追えなくなる

33. まとめ
33

34. まとめ
34
* AWS X-Rayは分散トレーシングのマネージドサービス
* 簡単に導入でき、特にServerlessと相性が良い
* トレースデータがあまりに大きいとトレースデータが欠損することがある
* 異常な状態を見極めるためにも普段からトレースを眺めよう

35. © 2021 Tier IV, Inc. 35