wwwave'sTechblog |ウェイブのエンジニアブログ

株式会社ウェイブのエンジニアによるテックブログです。会社の話や Ruby、Vue.jsについてなど技術的な話をしていきたいと思います。

株式会社ウェイブの人事部ブログです。社内の雰囲気やイベント、福利厚生などについてお伝えいたします!

株式会社ウェイブのエンジニアブログです。 エンジニアの目線から会社の話や技術的な話をしていきます。

ギャップに刺激を受けた入社3か月のエンジニアにインタビュー

ウェイブTechブログとは?

ウェイブの仕事をエンジニア目線でお伝えするWebメディアです。毎月15日の更新を目指しています。肩の力を抜いて執筆し、ありのままのウェイブをお見せできるよう心がけています。

 


インタビュアー:広報  ホニャシマ

 ・ロングスリーパーの夜型
 ・特茶と豆乳、トマトジュースを常飲
 ・社内には言っていないが文章を書くのは苦手

インタビュイー: ComicFestaエンジニア ミウラ

・2022年2月入社
 ・酒とゲーム好きのインドア派(酒イベントのためなら外に出る)
 ・社内では酒好きで推してるが資格を持ってるのは日本茶


 

ー現在のお仕事について教えてください。

 

ミウラ

ComicFestaの機能追加や不具合の改修などComicFestaの基本開発業務全般を担当しています。ユーザー様に気持ちよく使っていただく、売上に貢献できる仕組みにするといったところで、常に何か課題はあるので、それを解決するっていうのをくるくるやってますね。

 

ーComicFestaではどんな技術を使っていますか?

 

ミウラ

プログラミング言語はRubyで、フレームワークはRuby on Rails、フロントエンドは一部Vue.jsも使ってます。データベースはPostgreSQLです。インフラはAWSで構成しています。開発環境としてはそんな感じだと思います。

 

ーウェイブに転職されて3カ月強。前職とのギャップに刺激を受けたと聞きました。前職はどんなお仕事だったんですか?

 

ミウラ

いわゆるSIerで請負受注型の開発をしていました。僕の場合は、顧客のやり取りから実開発までほぼほぼ一人でやってましたね。内容としては、基幹系や業務系システムが多かったです。前職の退職前のころは、eラーニングとか小規模・中小企業向けのwebサービス系を多く担当していました。

 

ーウェイブでどんな点にギャップを感じたんですか?

 

ミウラ

もちろん会社が違うのでいろいろあるんですけど、一番ギャップを感じたのはチームでの開発と進め方ですかね。前職は、ウォーターフォールってわけでもなかったんですけど、トップダウン型の開発でした。請負ですから納期が絶対。納品日までに開発・お客様の受け入れ検証をして、リリースするって感じでした。

ウェイブはスクラムでの開発で、1週間単位でスプリントを回しています。短いスパンでリリースや検証を行うので、そこはギャップでしたね。

 

ー時間をかけて納品するというのと、短いスパンでタスクをこなしていくという違いですか?

 

ミウラ

期間の問題というよりも仕事の仕方、感覚の部分だと思います。

請負の場合は、納期までに確実に納品(リリース)することが大事なんですよね。開発期間に余裕があろうとなかろうと納品できればいいんです。納期中に確実に納品することを考えると何かあったときのバッファも必要ですし、逆に何もないと追われるような気持ちで開発してやっと納品ということになる。

もし、ウェイブのスプリント(1週間)でバッファを持ったら進まないですよね。合わない。結果、余力を想定しない形で取り組むことになります。全力でやった結果、タスクというか作りたかったものが作れなくても、それはそれでいい。1週間でやろうと思ったけどダメだった。この方法はダメだってわかったことが成功なんだってよく言われます。

前職とウェイブで納品意識というか、作る・リリース・検証するってことに考え方の違いがあるなと感じました。

 

ーその違いに刺激を受けたんですね。

 

ミウラ

そのスピード感で仕事をするから、チームの型みたいなのも違いますしね。前職がトップダウン型だったって話をしましたけど、チーム内でそれぞれが違うことをしているので、ある意味では属人化してるんです。自分の担当の部分を納期までに完成させれば良いので。

スクラムでの開発だと、今のタスクが終わったらどの機能とか問わず次のタスクをやるって感じで進みます。なので、みんなある程度は全体のことをわかってなきゃいけないんですよ。広く仕様を理解していて全体を見渡さなければいけないので、学ぶことが多いなと思いました。そもそもチームでの開発経験が乏しいので、この体制自体も刺激になっています。

 

ーなにか経験とかノウハウみたいなものが蓄積しやすく、挑戦の多い環境なのかなぁって気がしました。

 

ミウラ

そうですね。ウェイブではコードレビューなんかもするんですけど、レビューしてもらって「この辺こう書いたほうがいいよ」みたいな自分の知らない書き方を教えてもらったり、自分では気づかないところを指摘してもらえると勉強になるし、ノウハウがたまりますよね。実際それで結構早くいろんなことが覚られたと思ってます。

 

ーこれからウェイブに入りたいとか入ってもいいなぁってエンジニアの方にアドバイスはありますか?

 

ミウラ

「自分はこれしかできない」って決めつけずに、何でもやるって心意気で入ったほうがいいですね。スクラムは、みんながある程度浅く広くできて、かつ専門分野を持ってていいよねって思考です。「私はこのインフラ周りしかできません」とか、「この領域しかできません」って閉じちゃうとやっていくのが難しいかなと思います。

逆にやってなかったことに挑戦していったら、刺激がいっぱいで楽しいです。わからないときは「あの時どうしたんですか」とか「いい案があればよろしくお願いします」みたいな感じで周りとコミュニケーションを取りながら、今までにない方法とか価値観が学べると思います。

 

ウェイブではともにチャレンジしてくれるエンジニアを募集しています。
現在の募集職種はこちらをご覧ください。

recruit.wwwave.jp

Railsで例外発生時、prometheus-client のメトリクスが取得できていない問題の解決方法

執筆者:SRE シラト

今回のお話

海外向けコミック配信サービス「Coolmic」では、Prometheus を使用してシステム監視を行っております。
Prometheus のメトリクスを確認すると、Railsで例外発生時にメトリクスが取得できていないことが判明いたしました。
今回は、その解決方法をご紹介いたします。

状況整理

今回取得したかったメトリクスはhttp_server_requests_totalです。
Kibanaのログと照らし合わせると、数値が合わなかったので気が付きました。。。

原因

Rails は標準で ActionDispatch::ShowExceptions の仕組みで例外を捕捉して、エラーページを表示しております。
ソースコードを確認すると、処理の途中で以下の値を上書きしている箇所を発見。

request.path_info = "/#{status}"
request.request_method = "GET"

実はこの2つの値、prometheus-client で参照している値だったため、期待する値ではなかったです。

path method
参照 path_info request_method
実際の値 /422 get
期待する値 /user/sessions post

解決策

ShowExceptions を無効化することもできるみたいですが、レスポンスにデバッグコードが含まれてしまうため却下しました。
ShowExceptions が値を上書きする前の情報も取得することができましたので、モンキーパッチで処理を上書きしました。

module Prometheus
  module Middleware
    class Collector
      def record(env, code, duration)
        method = if env["action_dispatch.original_request_method"].present?
                   env["action_dispatch.original_request_method"].downcase
                 else
                   env["REQUEST_METHOD"].downcase
                 end

        counter_labels = {
          code: code,
          method: method,
          path: strip_ids_from_path(env["REQUEST_PATH"], method),
        }

        duration_labels = {
          method: method,
          path: strip_ids_from_path(env["REQUEST_PATH"], method),
        }

        @requests.increment(labels: counter_labels)
        @durations.observe(duration, labels: duration_labels)
      rescue StandardError
        # 例外発生時ここでキャッチできるのでデバッグも可能
        nil
      end
    end
  end
end

まとめ

実際のところこの方法が適切だったかはわかりません。。。
調べても情報が出てこなかったので、少しでもお役に立てれば幸いです!

トップに戻る