update.FOLIOのアドベントカレンダー9日目です。前日は@ken5scalによるAzureADでYubiKeyを管理しつつ認証(TOTP)する記事でした。手元の下書きに「前日分の感想を書く」って書いてありましたが、感想が書きづらいタイプのhow-to記事でした。銘打ち、小ネタを書きます。感想が書きづらいタイプのhow-to記事です。Webサービスで利用可能なオンライン証券サービスを作っています。利用しています(詳細後述)。BtoCサービスによくあることですが、裏側にはいわゆる「管理画面」が存在しています。)PORTのフロントエンドをRailsで作成しています。口座開設の審査などの機能を提供していました。PORTフロントエンドは分散トレーシングのための仕組みを導入していなかったので、PORTフロントエンドの利用者がトラブルを報告してきても、どのバックエンドマイクロサービスによる事象かを調査する際、日時によるログの絞り込みを行う必要がありました(低精度)。ライブラリを使うようにしました。導入する方法が見つからなかったので、色々と苦労しました。二度とこんな苦労をする人が現れないように、記録を残しておくのが本稿の趣旨です。前にFinagleの解説をします。FinagleはTwitter社が中心に作成しているOSSのRPCフレームワークです。サーバ側のパフォーマンスを追求しており、多くのリクエストを並行に捌くことができるように設計されています。MySQLが使えます。Thriftは、始めはFacebook社によって開発された、RPCライブラリです。ThriftとしてOSSで公開されています。Architechtureで利用するために、Zipkinによる分散トレーシングのための情報をパケットに載せられるようにしました。この拡張プロトコルをTTwitterと呼びます。ライブラリを使ってTTwitterプロトコルで通信するための方法を記載します。実行方法も書いているので、そちらも参考にしてください。サーバサイドと共有するThriftファイルはこちらです。APIがひとつ定義されただけのシンプルなものです。ディレクトリ以下にRubyのファイルが生成されます。hello_service_types.rbこれでThriftのAPI定義に合わせてRPCする準備はOKです。立っているTTwitterを喋るサーバへのRPCコールができます。callが例外で失敗する。行に注意してください。失敗し、Zipkin用のトレース情報を出すことができませんでした。RailsでTraceIdをロギングするおまけ的な扱いです。先に上げたPORTのフロントエンド(管理画面)はRailsで作っています。PORTフロントエンドのRailsで生成したTraceIdをバックエンドのマイクロサービスに伝達しつつ、PORTフロントエンドのログにもバックエンドのログにもTraceIdを出力するようにしています。ように検索すると、PORTフロントエンドへのリクエストを完遂させるために叩いたバックエンドマイクロサービスのログも一気通貫して見ることができます。Gemを使い、rack_middleware層で下記のように実現しています。ここで取得した値が別のリクエストのtraceIdではないことが保証される。以下、リクエストごとに変わる値。Rubyから使う方法を開拓しました。苦労を供養するため、このドキュメントを残しました。誰かのお役に立てれば嬉しいです。明日はFOLIOアドベントカレンダー10日目、@takanoripeによる記事です。upLoginユーザーは見つかりませんでした。