Summit20182018-11-10今日話すこと¶マイクロサービス化されたアプリケーションでは、パフォーマンス測定の一つとして分散トレーシングが挙げられます。HTTPをAPIサーバの一つとして構築した際に、他のサービスとのやり取りを含め全体のパフォーマンスを可視化するには、分散トレーシングの仕組みに載せる必要が出てきます。HTTPのAPIサーバでの分散トレーシングの可視化を紹介します。背景¶どの処理にどれくらい時間がかかっているかを知りたい。本番環境はコンテナで動かしているので、SSHで入ってログファイルをtailしてなんてのは無理。ログには出力しているが、整理しながら見るにはシェル芸や超絶技巧検索スキルを駆使する必要がある。時系列で可視化しておいて、後で見たい。自分以外が見られるようにしたい。他のHTTPサービスとやり取りしてると、どこがボトルネックなのか分かりづらい。各Spanの間には関係性があり、有効巡回グラフ(DAG)で表すことができる。他にもあるが一例として、以下のプロダクトが挙げられる。tracing仕様を統一し、実装は各プロダクトのものを採用できるように。Foundation)の管理下にあるプロジェクトのひとつ。Tracing同じカテゴリにJaegerが存在。OpenTracingとは¶CNCFの他のプロジェクトとの関わりは、TrailMapを参照。Days、CNCFのCTOが語るクラウドネイティブへの道を参照。OpenTracingに対応したTracerライブラリ¶https://opentracing.io/docs/supported-tracers/ここのリストに挙げられているもの以外にも、プロダクトでサポートしているものは、以下のが挙げられる。数ある実装からJaegerを選んだ理由CNCFのプロジェクトである。ZipkinJaegerについて¶アーキテクチャは、主に以下のコンポーネントで構成されている。imageが利用可能。本番向けとして、k8sのmanifestが公開されている。jaegertracing/jaeger-kubernetes更にHelmのChartも公開されているので、デプロイもHelmから可能。Operatorも用意されたので、更にデプロイが省力化されている。分散トレーシングについて¶ここまでのまとめ分散トレーシングは、TraceとSpanで構成されている。OpenTracingという統一された仕様が存在する。JaegerをTracerとして使うことでOpenTracingを利用できる。仕様OpenTracingとは別物。Observabilityの為のライブラリ。metricsとtracesまとめて面倒を見るために。Googleが作っている部分が多いが、OSSである。各サービスのライブラリを使って書くのもいいが、統一した仕様のもとに書ける。ロックインされることなく、切り替えまたは同時に利用出来る。MetricsとTracingどちらも欲しいTracingだけでは、RuntimeやOSといった情報までは持っていない。wrapperScalaの主要なHTTPライブラリをサポートPlayは計画中...OpenCensus-Scalaについて¶ちょっとした注意点jaegerのtrace-exporterはjavaにあるものの、scalaではconfigが無い。出力属性がzipkinのB3フォーマットより少ない。若干ScalaのtoStringそのままなのが気になる。propagationを要求されているので、jaegerのフォーマットではエラーとして扱われてしまう。headerに以下のものを付与することで、トレーシングが可能に。用意されているので、対応していないframeworkでも実装が可能。headerがTracingに用いられている。ロードバランサーやプロキシーが行う。以下のプロダクトが例として挙げられる。envoyistionginxでは、実際にどんな感じなのか見てみましょう¶デモ¶デモアプリケーションについて¶メッセージを登録するAPIアプリケーションメッセージのIDはID生成サービスから取得デモアプリケーションについて¶メッセージ用のID生成について¶kayac/go-katsubushiで順序のあるIDを生成。Streamで利用出来るように。driverとしてfluentdを利用。fluentdからfluent-plugin-elasticsearchでelasticsearchへ。ログの加工を楽にするひと手間として、json形式へ加工。logstash/logstash-logback-encoderを利用し、そのまま標準出力へ。コンテナ以外は見やすい形式にするために、sbt-native-packager側で切り替え。Metricsについて¶Prometheusをバックエンドにすることで、opencensusからMetricsを転送することが可能。利用して、JDBCのMetricsを可視化。他のexporterと組み合わせることで、より詳細な監視が可能に。今後について¶OpenCensusがサポートする言語、バックエンドがまだ少ないが徐々に増えていくと思われる。opencensus-scalaのようにブリッジとなるライブラリが出来ていくことで、今のプロダクトへ導入することが進むと思われる。出来ればフレームワークが公式にサポートするとありがたい。DatadogやZipkinを単体で使っているような場合でも、OpenCensusに切り替えることで、複数のバックエンドに転送が可能に。Datadog、ローカルで開発するときは、Zipkinのコンテナみたいなのも可能。cats-effect関数の合成が出来るようになると、さらにいろいろと便利に。いったプロジェクトがCNCFで立ち上がっているので、こちらも同様に注視しておくと良いかも。Buffersのフォーマットを選択出来るようになっていくそう。分散トレーシングを織り込んで作ることで、ログだけでは分かりにくいことが見えるように。OpenTracingやOpenCensusを利用することで、ロックインされることなく、複数のバックエンドを有効活用出来る。Scalaだと言語のチカラで、より簡単に導入することが出来るように。