この記事はNew Relic 使ってみた情報をシェアしよう！ by New Relic Advent Calendar 2022 24日目の記事です。 株式会社リゾーム 技術部 システム開発第3グループの藤岡です。 弊社の扱っているシステムで最近New Relicを導入しました。 New Relic APMのDeploymentsが便利だったのでご紹介したいと思います。 Deploymentsとは コードのデプロイ時にマーキングをします。 マーキングする事で、下記の事が実現出来ます。 デプロイの履歴を一覧で見る事が出来る デプロイ前後のパフォーマンスを確認する事が出来る マーキング方法はREST APIやエージェントを使用して出来ます。 詳細は公式のドキュメントを参照してください。 デプロイメントの記録と表示 | New Relic Documentation お客様毎にデプロイしているバ

この記事はNew Relic 使ってみた情報をシェアしよう！ by New Relic Advent Calendar 2022 10日目の記事です。 株式会社リゾーム 技術部 システム開発第3グループの廣江です。 弊社では、現在稼働しているアプリケーションのパフォーマンス改善やエラーの修正を効率よく発見・修正するために、最近New Relicを導入しました。また、その中でシングルテナントでアプリケーションを提供しているものがあり、シングルテナントでNew Relicを導入しているケースも少なかろうということでアドベントカレンダーに参加してみることにしました。 シングルテナントで複数のアプリケーションを登録しているため、若干特殊なNRQLかもしれません。ご了承ください。 パフォーマンス改善・エラー修正 アプリケーションを長らく運用していると、パフォーマンスの劣化やエラーの発生はどうしても避

株式会社リゾーム 技術部 システム開発 第4グループの平松です。「入門 監視」読書会が終わりましたので社内の有志で新たに読書会を始めました。それをレポートしていきたいと思います。 読書会の題材 題材として選んだのはLinux標準教科書です。 linuc.org 読書会の本を決める際に賛同する声が多かったので、こちらになりました。 また、標準教科書は今回選んだ本以外にもサーバー構築やセキュリティについて書かれたシリーズもあり情報技術を包括的に学べる教材となっています。 読書会の進め方 進め方は、「入門 監視」読書会の時と同じです。 当日までに事前に章を読んでおく 感想や疑問点をまとめる Yammer(Viva エンゲージ)にアウトプットする 読書会当日、感想をそれぞれ発表する 意見交換を行う 1回目レポート 初回は、「Linuxとは」で、参加者は6名でした。 それぞれの感想・意見交換 基本ソ

株式会社リゾーム システム企画・開発部 第4グループの萩原です。 読書会の第7回目のレポートです。 第6回目のレポートは、こちらになります。 tech.rhizome-e.com 読書会の題材 前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。 7回目レポート 今回は、「7章 アプリケーション監視」で、参加者は5名でした。 それぞれの感想・意見交換 メトリクスでアプリケーションを計測する クエリの実行時間や応答時間以外に、何を計測するべきか。 アプリケーションパフォーマンス監視(APM) そのままでも小綺麗な滝グラフ、それっぽいグラフは出るけれど、言われてみれば確かに。 APMを追加しだけでは何のコンテキストも把握していないというのは、そりゃそうだよなぁと思った。 自分たちが計測したいものと向き合う必要がある。 7章全体を通して StatsD

株式会社リゾーム システム企画・開発部 第3グループの渡邉です。 読書会の第6回目のレポートです。 第5回目のレポートは、こちらになります。 tech.rhizome-e.com 読書会の題材 前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。 6回目レポート 今回は、「6章 フロントエンド監視」で、参加者は6名でした。 それぞれの感想・意見交換 フロントエンドのパフォーマンス・監視について フロントエンドのパフォーマンスについては気にはしているが、監視をするという考えはなかった。 「JavaScriptはbody閉じタグの直前で読み込め」とか、「CSSはheadで読み込ませるけど書く場所はなるべくまとめる」とか、「アセットパイプラインで全部ひとまとめにしてやる」とか、「なるべく圧縮した方がいや使用頻度が高いならCDNを使え」とか、そんな話もあ

株式会社リゾーム システム企画・開発部 第4グループの平松です。 読書会の第5回目のレポートです。 第4回目のレポートは、こちらになります。 tech.rhizome-e.com 読書会の題材 前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。 5回目レポート 今回は、5章「ビジネスを監視する」で、参加者は5名でした。 それぞれの感想・意見交換 ビジネスKPI KPIはメトリクスって言われたら確かに。 これらのメトリクスはサービスを作るときに取得できるように設計しておかないと、次の打ち手を考えるときのデータがない。 月次での推移とか作ってみたら良さそう。解約数とか、アクティブユーザー数とか。 結局、お客様が儲かるシステムを作らないと、現在進行系で困るし先も続かない。 お金について語れると強い。 「お客様は喜んでいるか」これを開発側が意識する機会

株式会社リゾーム システム企画・開発部 第3グループの藤岡です。 読書会の第4回目のレポートです。 第3回目のレポートは、こちらになります。 tech.rhizome-e.com 読書会の題材 前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。 4回目レポート 今回は4章「統計入門」で、参加者は4名でした。 それぞれの感想 システム運用における統計を学ぶ前に アラートが鳴りすぎるのは良くないので、フラッピング検出によるアラート制御が害悪か判断しかねる。 計算が救いの手を差し伸べる 過去のログも記録する、統計を見て何か掴む。 AWSを使って過去ログを記録するのが当たり前になっていた。使いこなせてるかは別。 統計は魔法ではない 恣意的な統計の使い方をすれば、必然そういう数字が誇張されて出てくる。 計算方法の選択や実際の計算を間違えることも考えられる

株式会社リゾーム システム企画・開発部 システム管理のあめぎです。 読書会の第3回目のレポートです。 第2回目のレポートはこちらです。 tech.rhizome-e.com 読書会の題材 前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。 3回目レポート 今回は3章「アラート、オンコール、インシデント管理」で、参加者は6名でした。 それぞれの感想と議論まとめ どうしたらアラートをよくできるか？ アラートのメール通知は反対派多数　※参加者全員 誰も叩き起こせないし、スルーしてしまう可能性も高い。SMSに送るのはよくある。 一般的な使い方は「期限に余裕があり、期限までに目を通していればいい」「届いていない・見ていない可能性も許容する」 メールボックスに張り付いているのも、緊急度の高いメールが届いていないか気にするのも疲れる。 RundeckのJob

株式会社リゾーム システム企画・開発部 第4グループの萩原です。 読書会の第2回目のレポートです。 第1回目のレポートは、こちらになります。 tech.rhizome-e.com 読書会の題材 前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。 2回目レポート 今回は、2章「監視のデザインパターン」で、参加者は6名でした。 それぞれの感想 組み合わせ可能な監視 UNIX哲学「一つのことを、うまくやれ」 ここでもUNIX哲学が出てくる。 改めて監視に当てはめて聞くと、なるほどと納得した。 聞いたことはある(が、内容を理解はしていない……)。 専門的なツールを組み合わせる方が、複合的なツールを扱うよりいいのかもしれない。 個別にも使えるし、組み合わせても使える。一つだけ乗り換えることもできる。 必要なものだけ使用することで、無駄を省くことができる。

株式会社リゾーム システム企画・開発部 第4グループの尾古（@patorash）です。 「現場で役立つシステム設計の原則」読書会が終わりましたので、先週から社内の有志で新たに読書会を始めました。 それをレポートしていきたいと思います。 読書会の題材 読書会の題材として選んだのは、入門 監視 ―モダンなモニタリングのためのデザインパターンです。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon 複数の候補がある中で決戦投票を行った結果、大差でこちらに決まりました。 皆、どう監視と向き合っていけばいいか、何をどう監視したらいいかを理解したいというのが現れていたかと思います。 読書会の進め方 進め方は、「現場で役立つシステム設計の原則」読書会のときと変わらずです。 当日までに事前に章を読んでおく 感想や疑問点をまとめる 読書

株式会社リゾーム システム企画・開発部 第4グループの平松です。 今回は、読書会の第10回目のレポートになります。 前回のレポートは、こちらになります。 tech.rhizome-e.com 10回目レポート 今回は、第10章「オブジェクト指向設計の学び方と教え方」で参加者は6名でした。 それぞれの感想・意見交換 ドメインオブジェクトを設計していくという考え方にはあまりなってなかった 受託開発をしているときはリファクタリングをする機会があまり与えられないため、良さがよくわかってなかった オブジェクト指向は言葉で説明するのは難しい オブジェクト指向を学ぶにはリファクタリングがいいと思う 手を動かして覚える 仕事のタスクだけだと覚えるのに時間がかかりそう オブジェクト指向を意識して作業してもらわないと意味がない コードレビューで言及して意識してもらうとか 実際の実装を読んで理解する 一番手っ取

株式会社リゾーム システム企画・開発部 第3グループの渡辺です。 今回は、読書会の第9回目のレポートになります。 前回のレポートは、こちらです。 tech.rhizome-e.com 9回目レポート 今回は、第9章「オブジェクト指向の開発プロセス」を読み進めました。 それぞれの感想・意見交換 開発の進め方 分析・設計にほとんど時間をかけずにとにかくプログラミングするという流れはある。 特に、Railsでは顕著ではないかと思う。ちょっと規模が大きくなるとコードの見通しが急速に悪化するというのは、身に覚えがある。 コードの見通しが悪い 手がつけられないほど難解 もう少し分析や設計に時間をかけるのが良いのかもしれない..。 ドキュメントについて 開発の初期から利用規約・ユーザーガイドのアウトラインを作成しておき、開発が進むにつれ内容を充実させる、というのはいい考えだと思う。 データベースのテーブ

株式会社リゾーム システム企画・開発部 第1グループの小田です。 読書会の第6回目のレポートです。 前回のレポートはこちらです。 tech.rhizome-e.com 6回目レポート 今回は、第6章「データベースの設計とドメインオブジェクト」で参加者は5名でした。 それぞれの感想・意見交換 制約について NOT NULL制約、一意性制約、外部キー制約を徹底すると自然と正規化が進む。 適切なDB設計をするための指標としてわかりやすい ここに書いてあるNOT NULL制約、ユニーク制約、外部キー制約などは基本的なものなので、出来る限り使う。データベース側の機能のチェック制約やenumなどを使うと、更にデータを守ることができる。 原則としてNULLを許容しない。 もしNULL値がどうしても必要なカラムを見つけたら別のテーブルに分ける。 NOT NULL制約を使っていないカラムだとプログラム側でn

株式会社リゾーム システム企画・開発部 第3グループの鳥井です。 読書会の第5回目のレポートです。 前回のレポートは、こちらです。 tech.rhizome-e.com 5回目レポート 今回は、第5章「アプリケーション機能を組み立てる」で参加者は5名でした。 それぞれの感想・意見交換 三層+ドメインモデル 三層とRailsにおける処理の対応関係は以下のように捉えることができそう プレゼンテーション層 ルーティングとコントローラーの不正パラメーターのフィルタリング アプリケーション層 コントローラーの各アクションでの処理やサービスクラス、モデル データソース層 モデル 複数のモデルにまたがるような複雑なビジネスロジックをサービスクラスにするものだと考えていたが、そうでないことに気付かされた シナリオクラス サービスクラスを組み合わせたシナリオクラスを作ることで、業務の視点で必要とする機能単位

株式会社リゾーム システム企画・開発部 第3グループの渡辺です。 今回は、読書会の第4回目のレポートになります。 前回のレポートは、こちらです。 tech.rhizome-e.com 第4回目レポート 今回は、第4章「ドメインモデルの考え方で設計する」を読み進めました。 それぞれの感想・意見交換 ドメインモデルについて ドメインモデルで設計することで、業務の流れや用語がプログラムにそのまま反映され、プログラム自体が業務の説明書になる。 抽象度を高めることが汎用的なプログラミングには大事だが、それとは対照的。 ロジックを変更する際、変更による影響範囲が把握できないので、検索して洗い出した箇所を1つ1つ見ていくこともある。そういった事態が発生しにくいドメインモデルでの設計は非常に魅力的に見えた。 ドメインオブジェクトの見つけ方・作り方 「関心事」の粒度を正しく理解しないと正しいドメインモデルを

株式会社リゾーム システム企画・開発部 第4グループの平松です。 今回は、読書会の第3回目のレポートになります。 前回のレポートは、こちらになります。 tech.rhizome-e.com 3回目レポート 今回は、第3章「業務ロジックをわかりやすく整理する」で参加者は4名でした。 それぞれの感想・意見交換 データクラスと機能クラス Railsだとコントローラーとモデルの関係 コントローラーのアクションに処理をまとめるのは悪手 モデルにデータとロジックをまとめておけばコードの重複をなくせるし、テストもできる モデルにデータとロジックを寄せているが、現状、値オブジェクトを使っていないため、半分正解の状態 モデルが肥大化したら、値オブジェクトを導入する良いタイミングでは？ ロジックとメソッド メソッドには必ずインスタンス変数を使うのはリファクタリングなどの面でも良い指針だと思う クラス変数はイン

株式会社リゾーム システム企画・開発部 第3グループの廣江(@buta_botti)です。 読書会の第2回目のレポートです。 第1回目のレポートは、こちらになります。 tech.rhizome-e.com 読書会の題材 前回に引き続き現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法を題材としています。 2回目レポート 今回は、第2章の「変更を楽で安全にするオブジェクト指向の実践技法」で、参加者は6名でした。 それぞれの感想 + 意見交換 if文がネストしてる箇所があるので、そこは短文にするとわかりやすくなりそう 大きすぎるメソッドや不必要なネストがダメというのは、RubyだとRuboCopが指摘してくれるので意識できている インターフェースってなんだ？(Rubyist) Rubyだとインターフェースってないよな Rubyだと継承や移譲を使ってインターフェース