Skip to content

Latest commit

 

History

History
247 lines (146 loc) · 13.6 KB

distributed-tracing.md

File metadata and controls

247 lines (146 loc) · 13.6 KB

Distributed Tracingの導入

次に、Distributed Tracingの考え方を導入し、1リクエスト中の各サービスの呼び出しに関してどこでどのくらいの時間がかかっているのかを把握しましょう。 トレージングデータを収集、検索、視覚化するサーバーとしてZipkinを利用します。 各サービスからトレージングデータを透過的に送信するクライアント(instrumentation)としてSpring Cloud Sleuthを利用します。

本ページで作成するソースコードはこちら(07_distributed-tracingブランチ)から参照可能です。

Zipkin Serverの作成

作業手順

  1. File -> New -> Spring Starter Project image

    • Name : zipkin-server
  • Group: com.metflix
  • Artifact: zipkin-server
  • Package: com.metflix image
    • Cloud Config -> Config Client
  • Cloud Tracing -> Zipkin UI, Zipkin Server image

  1. workspaceを確認 image

  2. src/main/java/com/metflix/ZipkinServerApplication.javaをこの内容に変更

  3. src/main/resources/application.propertiesを削除

  4. src/main/resourcesを右クリック -> New -> File

  5. File name: bootstrap.properties

  6. src/main/resources/bootstrap.propertiesをこの内容に変更

  7. forkしたmetflix-confgプロジェクトのservice-registryブランチにzipkin-server.propertiesを作成して、この内容に変更

スクリーンショット 0028-06-18 18.45.53.png

image

動作確認

Package ExplorerのZipkinServerApplication.javaを右クリック -> Run As -> Spring Boot App

image

コンソールを確認。9411番ポートで起動していない場合はConfig Serverの設定が正しくありません。

image

http://localhost:9411にアクセス

image

Zipkin Serverは以下のように実行可能jarをダウンロードすることでも実行可能です。

$ wget -O zipkin.jar 'https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec'
$ java -jar zipkin.jar

ストレージの変更やプロパティの変更を行う場合は、Zipkin Server用のプロジェクトを作成した方がメンテナンスしやすいです。今回はConfig Clientの設定を追加したため、あえてプロジェクトを作成しました。

Zipkin Client (Instrumentation)の設定

Zipkinクライアントとして、各サービスにSpring Cloud Sleuth(org.springframework.cloud:spring-cloud-starter-zipkin)を依存関係を追加します。この依存関係を追加することにより、Springアプリケーションからの外部へのリクエスト情報(Span)が蓄積され、org.springframework.cloud.sleuth.zipkin.ZipkinSpanReporterクラスが非同期にZipkin Serverに情報を送信するための設定が自動で行われます。Instrument対象はこちら。

ZipkinSpanReporterの実装としてデフォルトではorg.springframework.cloud.sleuth.zipkin.HttpZipkinSpanReporter(HTTPで送信)が使用されます。 リクエスト情報はorg.springframework.cloud.sleuth.Sampler実装クラスによってサンプリングされます。ここではorg.springframework.cloud.sleuth.sampler.PercentageBasedSamplerが使用され、リクエストの10%がZipkin Serverに送信されます。この割合はspring.sleuth.sampler.percentageプロパティで変更できます(デフォルトは0.1)。

作業手順

Membership
  1. membershipのpom.xmlをこの内容に変更
Recommendations
  1. recommendationsのpom.xmlをこの内容に変更
UI

動作確認

  1. membership、recommendations、uiを再起動

http://localhost:8080に何回かアクセスしてください。

ログに[appname,traceId,spanId,exportable]が含まれることを確認してください。

image

http://localhost:9411にアクセスし、「Find Traces」ボタンを押してください。

スクリーンショット 0028-06-18 20.05.58.png

複数のTraceが表示されます。一つクリックしてください。

image

選択したTraceの中の各Spanでどのくらいの時間を要しているのかが視覚的にわかります(「Expand All」ボタンを押すと見やすいです)。

image

image

「Dependencies」タブをクリックするとサービスの依存関係がわかります。

image

次にサンプリング率を変更して全てのリクエストが収集されるようにしましょう。

forkしたmetflix-confgプロジェクトのservice-registryブランチのapplication.propertiesに

spring.sleuth.sampler.percentage=1.0

を追加してください。

image

各サービスを再起動するか/refreshにPOSTでリクエストを送ってください。開発中はこの設定が便利です。

Cloud Foundryにデプロイ

「Cloud Foundryにデプロイ」でデプロイしたサービスにZipkin Serverを連携させましょう。

Zipkin Serverのデプロイ

$ cd $WORKSHOP/zipkin-server
$ ./mvnw clean package -Dmaven.test.skip=true

zipkin-serverプロジェクト直下にmanifest.ymlを作成してこの内容を設定し、cf pushでデプロイします。(tmakiの部分は自分のアカウント名またはイニシャルに置き換えてください。)

$ cf push zipkin-server-tmaki

次にこのZipkin ServerをService Instanceとして他のサービスにバインドできるようにUser Provider Serviceを作成します。

$ cf create-user-provided-service zipkin-server -p '{"uri":"http://zipkin-server-tmaki.cfapps.io"}'

Membership, Recommendations, UIのデプロイ

membership, recommendations, uiの接続先のZipkin ServerのURLをUser Provided Serviceのcredintialsの値を使うように、Config Serverのプロパティをを設定します。またCloud Foundry上ではspring.sleuth.sampler.percentageが0.1になるように設定します。 Cloud Foundryで起動する場合にのみ適用されるようにapplication-cloud.propertiesを、この内容を変更してください。

image

次に各サービスのmanifest.ymlにzipkin-serverサービスをバインドするように設定します。

Membership

manifest.ymlをこの内容に変更。

$ cd $WORKSHOP/membership
$ ./mvnw clean package -Dmaven.test.skip=true
$ cf push membership-tmaki
Recommendations

manifest.ymlをこの内容に変更。

$ cd $WORKSHOP/recommendations
$ ./mvnw clean package -Dmaven.test.skip=true
$ cf push recommendations-tmaki
UI

manifest.ymlをこの内容に変更。

$ cd $WORKSHOP/ui
$ ./mvnw clean package -Dmaven.test.skip=true
$ cf push ui-tmaki

動作確認

http://ui-tmaki.cfapps.ioにアクセス (tmakiを自分のアカウントまたはイニシャルに変更してください)。

image

http://zipkin-server-tmaki.cfapps.ioにアクセス

image

image

StrageをMySQLに変更

デフォルトではZipkin ServerのStrageはインメモリ実装(zipkin.storage.InMemoryStorage)なので、再起動するとデータが揮発します。また、アプリケーションのヒープを圧迫するので、開発中以外には利用できません。

ZipkinはStrageの実装にMySQL、Cassandra、Elasticsearchを選択できます。

ストレージをMySQLに変更しましょう。依存関係にio.zipkin.java:zipkin-autoconfigure-storage-mysqlを追加すれば自動で設定されます。(zipkin-serverプロジェクトのpom.xmlをこの内容に変更してください。)

Zipkin ServerのストレージとしてMySQLを使うためのプロパティをConfig Serverに設定します。Cloud Foundryで起動する場合にのみ適用されるようにzipkin-server-cloud.propertiesを作成して、この内容を設定してください。

image

Pivotal Web Servicesで使えるMySQLサービス(cleardb)のフリープラン(spark)でzipkin-mysqlというService Instanceを作成します。

$ cf create-service cleardb spark zipkin-mysql

zipkin-mysqlサービスをバインドするようにmanifest.ymlをこの内容に変更して、cf pushでデプロイしましょう。

$ cd $WORKSHOP/zipkin-server
$ ./mvnw clean package -Dmaven.test.skip=true
$ cf push zipkin-server-tmaki

これで、Zipkin Serverのデータが永続化され、再起動しても消えません。

ZipkinのストレージとしてのMySQLはパフォーマンスの問題が知られています。高負荷下での利用を検討している場合は、CassandraやElasticsearchも検討してください。Pivotal Web ServicesではElasticsearchのサービスとしてsearchlyを利用できます。

$ cf create-service searchly starter zipkin-elasticsearch

zipkin-autoconfigure-storage-mysqlの代わりにzipkin-storage-elasticsearchを使用してください。

Spring Cloud Streamとの連携

本章で説明したZipkin ClientはHTTPのみに対応していましたが、spring-cloud-sleuth-zipkin-streamを使用することによりSpring Cloud Streamによるメッセージングのトレーシングも可能になります。またZipkin ServerへのレポートもSpring Cloud StreamがサポートするbinderであるRabbitMQまたはKafkaを経由して行われます。

この場合は、Zipkin Serverの実装はZipkinServerApplicationクラスに@EnableZipkinServerの代わりに@EnableZipkinStreamServerをつけます。