AppSignal、長時間実行ストリーミングRackレスポンスの監視サポートでRuby監視を強化
AppSignalでは、長時間実行されるストリーミングRackレスポンスに対する監視機能を強化したことをお知らせいたします。この改善により、Rubyアプリケーションの長時間応答の健全性をより深く把握できるようになり、レスポンスボディの送信後数分、場合によっては数時間後に発生する可能性のあるエラーも検知できるようになりました。
この新たな可観測性の層は、Cheddar PaymentsのエンジニアリングディレクターであるJulik Tarkhanov氏による貴重なコントリビューションによって実現しました。彼の貢献により、Ruby gem内で長時間実行されるレスポンスを監視できるようになり、リアルタイムパフォーマンス監視への対応が一段と強化されました。
本記事では、この新機能がRubyアプリの監視において何をもたらすのかを解説するとともに、オープンソースのアプローチがどのようにクライアントとの協業を促進し、実用的でインパクトのあるインサイトの提供につながるのかをご紹介します。
なぜ長時間実行されるRackレスポンスの監視が重要なのか?
通常、Rackレスポンスを監視する際、AppSignalはレスポンスボディのレンダリングにかかる時間をトレースできます。

しかしこれまでのAppSignalでは、大きなファイルのダウンロードなど、長時間実行されるレスポンスを監視することができませんでした。そのため、レスポンスのレンダリングにどれほどの時間がかかったのか、またレンダリング中に例外が発生していないかを把握することが不可能でした。
この問題はかなりニッチなもので、多くのお客様のレスポンス監視には影響しないと思われますが、Cheddar Paymentsにとっては現実の課題でした。彼らのユースケースでは、長時間実行されるレスポンスを監視できないことが、パフォーマンスの追跡や長時間の処理中に発生しうる障害の診断における大きなハードルとなっていたのです。
「Cheddar Paymentsでは、Railsからzipファイル形式でストリーミング配信される重要なレポートのダウンロード機能を提供しています。しかし、これらのレポートの配信がAppSignalの監視対象から除外されていることに気づきました。これは、アプリ内でのHTTPインタラクションの『メイン』部分が完了すると、AppSignalのトレースが停止してしまうためです。レポートの生成時にはエラーが発生していたにもかかわらず、AppSignal上ではそれを確認できなかったため、これらのレスポンスのトレースは非常に重要だったのです。」
— Julik Tarkhanov氏(Cheddar Payments エンジニアリングディレクター)
コントリビューションによる解決策:長時間実行Rackレスポンスの監視
WeTransfer在籍時代にRackでの長時間実行レスポンスに関する豊富な経験を積んだJulik氏は、私たちのRuby gemへのコントリビューションを決意し、長時間実行されるレスポンスを監視するソリューションの実装に取り組みました。
「すでにAPM(AppSignal)は導入済みで、比較的容易に実装できる機能でした。ならば、やってみない手はないでしょう?」
代替ツールを探ることなく、Julik氏の最初のプルリクエストは、AppSignalのトレース内で長時間実行されるRackレスポンスを監視する手法をもたらしました。その後、AppSignalインテグレーションチームのTomの尽力により、エッジケースへの対応と信頼性の向上が図られ、PR #1140としてソリューションが完成。Ruby gemのバージョン3.10として正式リリースされました。
このソリューションにより、Julik氏のチームは代替ツールを実装したり乗り換えたりすることなく、引き続きAppSignalを使いながら、長時間実行されるレスポンスの追跡というニーズにも対応できるようになりました。
現在、AppSignalは長時間実行されるレスポンスの所要時間をキャプチャし、レスポンスのレンダリング中のどの時点で問題が発生してもお客様に通知できるようになっています。これにより、お客様のアプリケーションにさらなる可観測性の層が加わりました。

オープンソースへのコントリビューションを大切にする理由
AppSignalでは、常にお客様からのフィードバックや機能リクエストを大切にしています。すべてのリクエストが製品化されるわけではありませんが、お客様のニーズを探求することには常にオープンな姿勢です。
誰にとっても有益となり得るニーズを特定した場合は、それを実用的なソリューションへと昇華できるか、最善を尽くして検討します。Railsコミュニティの多くの人々と同様に、私たちはオープンソース協業の力を信じており、それこそが機敏にお客様の進化するニーズへ対応し続ける原動力となっています。
小規模でブートストラップ型のチームとして、すべてのお客様のウィッシュリストにある機能を実装することは困難です。だからこそ、gemへのコントリビューションが重要な意味を持つのです。コミュニティの力を借りることで、製品の能力を拡大し、重要な機能をより迅速に提供できるようになります。
「私たちのオープンソースに対する姿勢は、インテグレーションに関しては可能な限り公開の場で行うというものです。コミュニティからの貢献を見るのは本当に嬉しいことですし、アイデアや改善のご提案はいつでも歓迎しています。」
— Thijs Cadier(AppSignal CTO)
AppSignalでは、お客様をすべての活動の中心に据え、アプリケーションの監視と最適化に役立つ最高の体験とツールの提供を常に追求しています。だからこそ、お客様から愛されているのです:
- 無料の専門家サポート
- 明朗な料金体系
- 柔軟なアップグレードポリシー
- 使いやすいインターフェース
まだ納得いただけませんか?Julik氏の言葉をご紹介します:
「AppSignalは優れた製品で、試してみてもツール導入としての負担は大きくありません。さらにOpenTelemetryの登場により、今後ますます良くなっていくことでしょう。」
インストールウィザードを使えば、無料トライアルを開始して、コーヒーを一杯飲み終わるよりも短い時間でAppSignalを稼働させられます。そういえば、新規のお客様には(ご希望があれば)ストロープワッフルをお送りしていることもお伝えしておきましょう。
AppSignalの各種メトリクスを最大限に活用する方法についてご質問がございましたら、お気軽にお問い合わせください。喜んでお手伝いいたします!

Connor James
AppSignalのデベロッパーマーケティングマネージャー。ポッドキャスト好きで、カンノーリへの愛が深すぎて名前を「Connoli」に変えようか真剣に検討中。「color」に「u」を入れるべきだという派。マイクの前、ステージの上、あるいは勤務外ではソファでくつろぐ姿が見られるかもしれません。
-
HotwireでRailsアプリにインタラクティブ性を素早く追加する方法:初心者向けガイド
現在、HotwireはRails開発者の間で最もホットな話題のひとつです。Railsで開発をしている方なら、すでに耳にする機会が多かったのではないでしょうか。Hotwireは、ごくわずかなコード量でアプリケーションにインタラクティブ性を追加できるまったく新しいアプローチです。HTMLをそのままネットワーク経由で送信することで驚異的な速度を実現します。つまり、SPA(シングルページアプリケーション)フレームワークに手を染めることなく、レンダリングロジックをサーバーサイドに一元化しながら、高速なページ表示とリッチな操作性を両立できるのです。この記事では、Hotwireの主要コンポーネントと、Rai
-
なぜクラスを作るのか?抽象化の重要性と良いクラス設計の基本
前回の記事「なぜnilを使うのか」に続き、普段当たり前と思って使っているものについても、同じ問いを立ててみるのは良いアイデアではないでしょうか。 例えば… 巨大で醜いコードの塊を1つ作るのではなく、なぜ私たちはクラスを使うのでしょうか? 基本的なレベルで言えば、コードとデータを論理的な単位に整理するためにクラスを使います。しかし、それだけではありません。 クラスを使うと、抽象化(abstraction)を作り出せるのです。 抽象化とは何か? 実は、私たちは毎日、毎分、抽象化を利用しています。 今この記事を書いているキーボードは、次のようなもので構成されています。 ケーブル Cherry MX