New Relic APMのDeployments を使ってデプロイ履歴の登録とパフォーマンス比較をする

この記事はNew Relic 使ってみた情報をシェアしよう! by New Relic Advent Calendar 2022 24日目の記事です。

株式会社リゾーム 技術部 システム開発第3グループの藤岡です。

弊社の扱っているシステムで最近New Relicを導入しました。
New Relic APMのDeploymentsが便利だったのでご紹介したいと思います。

Deploymentsとは

コードのデプロイ時にマーキングをします。
マーキングする事で、下記の事が実現出来ます。

  • デプロイの履歴を一覧で見る事が出来る
  • デプロイ前後のパフォーマンスを確認する事が出来る

マーキング方法はREST APIやエージェントを使用して出来ます。
詳細は公式のドキュメントを参照してください。

デプロイメントの記録と表示 | New Relic Documentation

お客様毎にデプロイしているバージョンを把握したい

弊社ではシングルテナントでアプリケーションを提供しているため、デプロイしているバージョンがお客様毎にバラバラになっています。 お客様毎にデプロイしているバージョンを把握するため、独自のシステムで最新のバージョン情報を一覧で見れるようにしていました。

お客様毎にデプロイ履歴を登録して一覧表示する

Deploymentsを使用する事で、最新のバージョン情報以外にも過去のデプロイ情報も蓄積されて見る事が出来るようになります。 また、ダッシュボードに出すことで、独自システムと同じように最新のバージョン情報を一覧で見る事も出来ます。

FROM Deployment SELECT latest(version) AS バージョン, latest(timestamp) AS デプロイ日時 FACET entity.name AS ユーザー名 LIMIT MAX SINCE 50 years ago UNTIL now

シングルテナントなので、まだ全てのお客様のデプロイ履歴は登録出来ていませんが、登録出来れば独自システムの運用も不要になりそうです。

デプロイ前後でパフォーマンスが改善されたか知りたい

APMを分析しパフォーマンスの改善をしていますが、デプロイ前後でどのくらいパフォーマンスが改善しているか確認したいです。
New Relicを導入する前は、お客様に直接ヒアリングして確認する事もありました。

デプロイ履歴からパフォーマンスを比較する

Deploymentsの詳細からWeb Transaction毎にデプロイ前後のパフォーマンスを確認する事が出来ます。 もし劣化しているのであればそこからTransactionに遷移して深掘りするといった使い方も出来ます。
また、グラフに縦棒の線が入るので、長期間のパフォーマンスやエラー率等を確認したい時にも便利です。

デプロイ前後のパフォーマンス比較

まとめ

New Relic APMのDeploymentsを使う事でデプロイの履歴やデプロイ前後のパフォーマンスを簡単に確認する事が出来ました。 グラフでパフォーマンスがどのくらい改善したかが分かるので、モチベーションアップにも繋がります。
今後はデプロイ履歴の独自システムからの移行を進めていき、お客様のパフォーマンス比較を更に実施していきたいと思います。

「Linux標準教科書」読書会レポート vol.7

株式会社リゾーム 技術部 システム開発 第3グループの渡邉です。
Linux標準教科書」読書会の第7回レポートです。第6回目のレポートはこちらになります。
tech.rhizome-e.com

読書会の題材

前回に引き続きLinux標準教科書を題材としています。

7回目レポート

今回は「第8章 ユーザ権限とアクセス権」で、参加者は6人でした。

それぞれの感想・意見交換

ファイルの所有者と所有グループについて
  • chmodはchange mode、chownはchange owner、chgrpはchange groupが由来
    • コマンドの元になってる言葉を知っておくと、コマンドの動作も理解しやすい
  • 「chgrp」の読み方として「ちぐるっぷ」「ちぇぐるぷ」と呼ぶのを聞いたことがあるが、素直に「ちぇんじぐるーぷ」と呼ぶのがいいかなと思った
  • chownで所有グループも変更できるので、chgrpの存在を忘れていた
ファイルとアクセス権について
  • ファイルが読み込み権限だけだったのを、書き込みもできるように変更したりなどをしたことがある
  • 秘密鍵はユーザーの権限だけ(600)にしないと、SSH接続時にエラーになるので良く変更する
  • アクセス権の変更は大体、8進数で指定している
  • 8進数で指定しても、実際にどんな指定になったのか分かりにくそう
    • タイプ量が減るのがメリットくらいかな
    • よく使う指定は暗記して使ったりするんだろうか
      • パターンも少ないので、慣れればすぐに覚えられると思う
    • 分かりやすさではテキストで指定した方がよさそうだが、書きやすさ的には8進数指定の方がササっと書けそうなイメージ
  • umaskコマンドでパーミッションの設定ができるのは知らなかった
  • モードの指定に setuid ビットと setgid ビットと sticky ビットという特殊な属性がある事を初めて知った
  • システムテストで失敗した際に画面のスクリーンショット取るので、それを保存するためのディレクトリに対してアクセス権を変更したりしている

まとめ

今回はファイルの所有者・グループ及びアクセス権に関する章でした。アクセス権に関しては、開発環境でも秘密鍵シェルスクリプトパーミッションを変更することがあるため、馴染みがある人も多かったように思います。
次回は「第9章 シェルスクリプト」です。楽しみですね!

New Relicでパフォーマンス改善やエラー対応の成果を可視化する

この記事はNew Relic 使ってみた情報をシェアしよう! by New Relic Advent Calendar 2022 10日目の記事です。

株式会社リゾーム 技術部 システム開発第3グループの廣江です。

弊社では、現在稼働しているアプリケーションのパフォーマンス改善やエラーの修正を効率よく発見・修正するために、最近New Relicを導入しました。また、その中でシングルテナントでアプリケーションを提供しているものがあり、シングルテナントでNew Relicを導入しているケースも少なかろうということでアドベントカレンダーに参加してみることにしました。

シングルテナントで複数のアプリケーションを登録しているため、若干特殊なNRQLかもしれません。ご了承ください。

パフォーマンス改善・エラー修正

アプリケーションを長らく運用していると、パフォーマンスの劣化やエラーの発生はどうしても避けては通れない話になります。しかし、明らかなコスト削減につながる場合かクリティカルな不具合である場合を除いてどうしても優先度が落ちてしまい、メンバーそれぞれの個人努力によって少しずつ解消される(もしくは長らく放置される)というのが現実です。

調査コストは随分減った

パフォーマンスの悪い箇所やエラーの発見はNew RelicのAPM & servicesErrors inboxを使うことでとても簡単になりました。使用頻度を加味したパフォーマンスの悪い箇所ランキングを表示してくれるため、素直に上から対応していくだけでパフォーマンス改善につながりますし、エラーも発生箇所から、原因や関連するクライアントの環境やユーザーの情報まで全部辿れるので、原因が特定しやすくなり、対応チケットの作成は以前と比べ比較的容易になりました。

作成されたチケットに対応するモチベーションを高める

パフォーマンス改善やエラー修正のチケットに対応するにあたって、後回しにしないようモチベーションを高く保って対応していきたいです。そこで、どうすればモチベーションを高められるか考えました。この辺りはどうしても個人差があると思いますが、私の場合は単純で承認欲求が満たされるとモチベーションが高まります。成果を可視化し、目に見える形でエラー量を減らして報告するとチームメイトから感謝され、次のチケットも対応しようという気持ちになります。

成果の可視化

さて、この辺りから本題になるのですが、今回はNew Relicのダッシュボードを使って成果を可視化できるパネルを作成します。パフォーマンスに関してはAPMを見れば数値やグラフが詳細に出てくるのですが、シングルテナントで提供しているためそれぞれの環境では確認できても全部まとめて確認というのができません。全ての環境をひとまとめにして、だいたいこれくらい成果が出たというのをわかりやすく表示させます。

パフォーマンスやエラー数の推移をStacked Barで週ごとに表示させます。

SELECT average(apm.service.overview.web) * 1000 FROM Metric WHERE (appName != "") FACET segmentName LIMIT MAX SINCE 1 year AGO TIMESERIES 1 week

SELECT count(*) FROM ErrorTrace FACET error.message SINCE 1 year ago TIMESERIES 1 week
SELECT COUNT(*) FROM JavaScriptError FACET errorMessage SINCE 1 year ago TIMESERIES 1 week

これで、対応すればするほどその成果がグラフに表れてくるはずですので、対応してはグラフを眺めて「成果が出てるな」と実感しながらまた次の対応へ臨むことができます。まだ始めたばかりなので成果の出たグラフをお見せできませんが、これから頑張っていきます。

最後に

New Relicはサポートがとても充実しており、「こういうことがやりたいんだけど、どうやるのかな」といったことがあっても、相談するとすぐにアイデアをいくつか提供していただけるため、今ではとても便利に使わせてもらっています。どう便利に使っているかの話は別のメンバーが、後日記事にしてくれると思いますので、そちらを見ていただけますと幸いです。

今回はNew Relicビギナーによる、ちょっと変わった目的でのダッシュボード利用のアイデアについてお話しさせていただきました。まだまだ勉強中ですので、アドベントカレンダーの皆様の記事を拝読しつつ、さらに使いこなせていけるように頑張っていきます。

「Linux標準教科書」読書会レポート vol.6

株式会社リゾーム 技術部 システム開発 第4グループの平松です。 「Linux標準教科書」読書会の第6回レポートです。第5回目のレポートはこちらになります。

tech.rhizome-e.com

6回目レポート

今回は7章「管理者の仕事」で、参加者は4名でした。

それぞれの感想・意見交換

グループとユーザ

  • ユーザやグループの作成などはしたことがない
  • ubuntuをインストールした際に画面上でユーザの設定をしたぐらい
  • ユーザやグループの追加はデモサーバを構築する時に使った事がある
  • ユーザID、コメントがある事を知った
  • ファイルを直接編集するのは危険というのは聞いた覚えがあった
  • 実際にユーザの設定したりしたことはほぼない
  • Linuxは複数人で使う前提なんだなと再認識した
  • Linuxに限らずグループごとで権限を一括管理することは多いため理解しやすかった
  • グループの権限が設定できるので用途を限定したグループを作成したりする
  • グループを指定せずにユーザを追加するとデフォルトのグループに分けられる

パスワードとパスワードファイル

  • パスワードやグループの情報が各ファイルに分かれて保存されているとは知らなかった
  • パスワードがシャドウファイルに保存される事を知った。見ることは無さそう
  • 研究室の友人にどのファイルにどの設定が書かれているか教えてもらった記憶がある
  • sudoコマンドは別の調べものをしている時に偶然知った

用意されているユーザとグループ

  • suコマンドは使ったことがない
  • スーパーユーザ権限が必要な場合はsudoで済ませてる
  • rootユーザに切り替えるのはサーバ構築時ぐらいで、基本はsudoで実行する
  • 研究でラズベリーパイを操作するときに権限が必要なファイルの閲覧、編集にsudoはたくさん使った

まとめ

ユーザやグループの作成などはサーバ構築をする際に使うなど実務内容をもとにした感想・意見交換ができたと思います。 今回の内容はLinuxで作業する上での前提知識となっているため、このことを踏まえて次章以降を読み進めていこうと思います。

「Linux標準教科書」読書会レポート vol.5

株式会社リゾーム技術部システム開発第3グループの廣江です。 「Linux標準教科書」読書会の第5回レポートです。第4回目のレポートはこちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続きLinux標準教科書を題材としています。

5回目レポート

今回は6章「vi エディタ」で、参加者は5名でした。

それぞれの感想・意見交換

viの基本操作

  • CentOSRed Hat等、デフォルトで入っているエディタはvimなので、サーバー上でファイルを編集する際は、vimの知識は必須
  • viが使える環境であればvimtutor(vimチュートリアル)がある
  • 保存はwコマンドとqコマンドを別々に使う方が安全なのだろうけどwqで済ませることの方が多い
  • vi で開いて i でインサートモードにして編集して esc でコマンドモードに戻って :wq で保存する、これだけ覚えていれば最低限使える
    • q!コマンドを知らなかったせいで、ファイルの書き込み権限がない時にviエディタから抜けられなくて困ったことがある
  • ファイルを指定せずにviコマンドを実行すると新しいファイルを作成する...?
    • そうだよ

インサートモードとコマンドモード

  • aコマンドを使うことがほとんどで、iコマンドはほぼ使ってない
    • 逆にaコマンドは使った事がなかった
  • 行頭、行末への移動コマンドは使ったことなかった
    • 0コマンドで行頭$コマンドで行末に移動できます
    • 行頭・行末への移動はよく使う操作だから覚えておくと良い
  • モード切り替えが煩わしく感じる
    • 切り替えがiだったりescだったり変わるところが感覚的に合わない
  • モード切替が直感的でないためこれも慣れが必要
    • 初めて使ってみたが、使い続けたいとは思えなかった
  • ESCは押すのが遠いので、ctrl+[ を使っている

編集中の大きな移動

  • 上下左右の移動ぐらいしか使ってなかったのでページ単位や行指定、文書頭、文書末の移動は知らなかった
  • ページ単位の移動は知らなかった
  • 3章で出てきたページャの内容を読んだ後なので理解が進んだ
  • 知ってると時間短縮になる、知らないとカーソル移動で何度も方向キーを押すハメになるので辛い
    • ほとんど覚えていないのでよく間違える

様々な編集操作

  • ペーストコマンドが大文字と小文字で区別されていて驚いた
    • 大雑把にpコマンドのみをカーソルの下にペーストされる仕様なんだと思って使いそう
  • ファイルに追記する際は、文書末が多いのでGコマンドは便利そう
  • カットやコピーのコマンドは知らなかった
    • カットのコマンドはよく使うが、コピーはマウス操作でやりがち
    • 行ごとのカットやコピーは使うかもしれない
    • 1文字とかは書き直すかも
    • Pコマンドで"前に"ペーストは知らなかった
    • 直感的にはコピーはcでペーストはvなんだけどなという気持ちがある
      • ⌘c, ⌘v
  • 1行削除もどうしてxxじゃないんだ...
    • xxだと1文字削除を2回だねw

置換と検索

  • 検索や置換のコマンドも知らなかった
  • 文字の検索はよく使う(lessの時と同じ)
  • 文字列の置換が出来る事は知らなかった
  • 置換する対象を行範囲で指定できることになるほどと感じた
  • optionにgを指定しないと行ごとで1回だけしか置換できないのはうっかりミスでよくありそう

その他

  • コマンドモードでoキーを押すと改行してインサートモードに入れて便利
  • コマンドモードで :set number を入力してエンターキー押すと行番号が表示される
    • viの設定に書いておけば初期状態で表示する事も可能
  • vimの操作に慣れるために、一時期VSCodevimプラグイン入れていたが、めんどうになってやめた(おかげで割りと慣れた)
  • 直前の変更を繰り返すドットコマンド「.」
    • 「I」で行頭にインサートモード→「# 」を入力→「ESC」
    • その後は「j」で一行下にカーソル→「.」で上と同じことが実行される

まとめ

開発中にviエディタを使うタイミングはそれほど多くないため、開発メインのメンバーはviエディタについて知らないことが多いことがわかりました。逆に保守作業をするときによく使うので、保守メインのメンバーから様々な知見が共有されたのがとても有意義だと感じました。開発メインであっても保守作業からは逃れられないため、いざという時に効率的に作業するためにもviエディタの各操作は覚えておいて損はないという認識で全員が一致しました。

「Linux標準教科書」読書会レポート vol.4

株式会社リゾーム 技術部 システム開発 第3グループの藤岡です。 「Linux標準教科書」読書会の第4回レポートです。第3回目のレポートはこちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続きLinux標準教科書を題材としています。

4回目レポート

今回は5章「基本的なコマンド2」で、参加者は6名でした。

それぞれの感想・意見交換

ファイルのタイムスタンプの変更(touch)

  • 空のファイルを作成する用途でしか使った事がない
  • タイムスタンプをいじるよりは空のファイル作成に使いそう
  • 更新時間を任意の時間に指定できるの知らなかったけど、あまりいい使い方はなさそう

ファイルの一部の取得(head, tail)

  • 使ったことがない。どういう場面で使うのか
  • shellでファイルの先頭の数行を取得して何か操作するときに使ったかな
  • 行頭にそのコードの説明を入れる運用にするといった使い方が載っていてなるほどと思った
  • 最初のメタデータを抽出して加工したり、CSVのヘッダーを抽出したい時に使うかな
tail
  • -fと組み合わせて使う以外使ってないかもしれない
    • ログファイルを見るときによく使う
    • ログファイルを監視できるのは便利そう
  • よく less +F が tail -f の上位互換として紹介されている
    • less +F だとそのまま検索とかもできる

ファイルのソート(sort)

  • uniqと合わせる以外であまり使ったことない
  • ソートしてさっきのheadとかと組み合わせて情報取ってきたりするのだろうか
  • 列を指定してソートできるのは知らなかった
  • 数字をソートに使う場合は要注意
    • -nオプションで数字と文字を区別することは忘れそうだから覚えておく
  • -tで区切り文字を指定できるのでcsvファイルのソートも出来そう

行の重複の消去(uniq)

  • 前回の正規表現と合わせて知っていると、できることが広がるコマンドだと思う
  • 重複する行を連続にしておかないと重複を除去できない点に注意が必要
  • 「重複している行だけ出力(-d)」や「重複しなかった行だけ出力(-u)」できるオプションがあるのが地味に便利
  • 特定の条件に合致しないものを抽出したりできる
    • 特定の条件に合致するデータを持ってきて意図的に重複させる使い方も

文字列の置き換え(tr)

  • 文字の置き換え以外にも文字を削除するオプションもあったりして汎用性高そう
  • 大文字を一括で小文字に変換するみたいなことをしたい時に使える
  • 文字列の置き換えが出来ないので、似たコマンドのsedをよく使う

ファイルの比較(diff)

  • 普段の業務で使うとすると-rをつけてディレクトリごとの差分をとることが多そう
  • -yオプションは横並びで差分が表示されるため見やすいと思った
  • Railsのバージョンアップでよく見る
    • アップデートタスクを実行した際に新しいファイルや既存のファイルの変更を確認する時に表示される
  • 研究で過去のプログラムの変更箇所の確認に使用した
  • 設定ファイルの書き換え前後の比較とかで使う
  • 変更のあったファイルを取得できるのでCIやCDで使うことがあるかも

まとめ

テキストファイルを処理するコマンドはtailを使う程度で他はあまり使ってませんでした。 今回の意見交換を通じて、どのようなシーンで使うかが分かりました。
学んだ事を活かして、業務を効率良く出来るようにしたいと思います。
次回は第6章「viエディタ」です。

「Linux標準教科書」読書会レポート vol.3

株式会社リゾーム 技術部 システム開発 第1グループの岩﨑です。 「Linux標準教科書」読書会の第3回レポートです。第2回目のレポートはこちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続きLinux標準教科書を題材としています。

3回目レポート

今回は4章「正規表現とパイプ」で、参加者は6名でした。

それぞれの感想・意見交換

リダイレクト

  • 使う機会がなかったから忘れてた
  • こういうのがあるくらいの認識で、実際に使ったことはなかった
  • catコマンドとリダイレクトで内容を直接書き込んでファイルを作成できることは知らなかった
  • catで自由なファイル作成を出来る事は初めて知ったが、viエディタでいいかなー
  • catでファイル指定せずにいきなりリダイレクトすると、自由な内容でファイルを作れるのは知らなかった
    • shellで適当なファイルを丸ごと書き換えたいときに便利かもしれない
  • 適当な文字列を入れたファイルを作りたい時とかに使う
    • $ echo test > test.txt
  • zshrcにパスを追加する時によく使う
  • viエディタが使えない環境だとcatコマンドとリダイレクトでファイルの編集をしたりする
  • DBにデータを流すときに使う

標準エラー出力

  • 標準出力と標準エラー出力をリダイレクトできることをそもそも知らなかった
  • エラー内容をファイルに出力はやった事がなかった
  • リダイレクトで標準出力か標準エラー出力どちらをファイルに出力させるか指定できるのは知らなかった
  • 標準出力と標準エラー出力を同じリダイレクト先を指定したりするのはまあまあややこしい気がする
  • 標準出力を捨てる場合、/dev/null にリダイレクトしたりする
  • シェルスクリプトでログ取る時とかに便利そう

パイプ

  • 初めて知った
  • あまり使ってない
  • 実行中のプロセスを表示してkillする時によく使う
    • $ ps aux | grep プロセス名
  • パイプ前のコマンドをパイプ後の標準入力とする
  • grepコマンドと組み合わせて使うことが一番多いかな
  • 複数行に渡るコマンドの実行結果やgrepで絞り込んだ結果をパイプでつなげて、lessで表示させたりする
  • ワンライナーで書きたい時に使ったりする
  • Docker, Github Action, CIを触ってると使うと思う
  • 本番環境で調査したりする時に使う

grepコマンド

  • パイプと同じく初めて知った
    • 確かにデスクトップ環境が無い場合にはこういったコマンドがあると助かりそうなイメージが浮かぶ…
  • grepはパイプとの組み合わせの代表的なコマンド
  • 卒業研究で使った

正規表現

  • 業務でもたまに使うことがあるが、毎回忘れていてそのたび調べている
  • 正規表現あたりの記法は覚えづらく使うたびに調べている
  • そこまで使う機会がないから使うときに軽く調べたりする
    • &や?などの記号を変換する処理で使ったりする
    • URLで使えない文字、記号の変換など
  • [^abc] は abc 以外の文字を持っていればマッチ
    • "defg" => match
    • "abcd" => match ←これがマッチしないと勘違いしがち
    • "abc" => unmach
  • 否定先読みができないっぽいので「~を含まない行」みたいなのを探すときに苦労しそうだなと思った
  • 一括で置換したい時とか、なにかとよく使うので、覚えておくといろいろ便利
  • ログから抽出する際に使う
  • Userエージェントからブラウザを確認する際に使う

まとめ

本章では実務でどういった使い方をするかを中心に意見交換ができたかと思います。 私自身Linuxを触った経験がほぼないため、本章で学んだパイプやgrepコマンドについてぼんやりとしたイメージしか持っていませんでしたが、意見交換を通じて具体的な使用方法などを理解することができました。 また正規表現はプログラムを記述するときにも活用できるため、気を付けるべきところ等をしっかりと整理して次の章に進みたいと思います。

次回は第5章「基本的なコマンド 2」です。