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

株式会社リゾーム 技術部 システム開発 第2グループの土井です。 「Linux標準教科書」読書会の第11回レポートです。第10回目のレポートはこちらです。 tech.rhizome-e.com

読書会の題材


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

11回目レポート


今回は「第12章 ファイル管理」で、参加者は6人でした。

それぞれの意見交換


Linux のファイル管理

  • ルートディレクトリ直下の各ディレクトリがそれぞれ何用のディレクトリなのか曖昧なまま使っていた
  • 業務でよく使うディレクトリはhome, 設定の変更のetcとログ調査目的のvar
  • 昔のサーバはetcではなく、optに設定ファイルを置いている事があり、どこに設定ファイルがあるか分からない事があった
  • 改めて考えると、ディレクトリで階層構造でファイルを保管できるというのは便利
  • 大学時代研究でラズパイを操作するにあたって設定やログが/usr/etcや/var/logにあるのは調べたことがあったがFHSで定められているということは知らなかった
  • FHS(File Hierarchy Standard)
    • 設定ファイルがetcディレクトリ、一般ユーザー用プログラムはbinディレクトリにあるのは理解していたが、そういった決まりがあるのは知らなかった

ディスクのパーティション

  • パーティションの作成等はしたことがない
  • パーティション分割したことはない
  • パーティションについてはそもそも知識がなかった
    • 実際に構成だったりを考える部分が特に難しそう
  • GPTという管理方式だとパーティションが4つまでの制約とかもないみたい
    • 拡張、論理があるのはMBRという管理方式
    • GPTに対応しているコマンドもある。gdiskコマンド
  • 既に利用しているハードディスクのパーティション操作等、注意すべき点がいくつかあるため覚えておく
  • 業務でハードディスクを増設したり、パーティションを作成したり、というのはあまりないかなあ
  • パーティションの一覧の見方(fdisk -l)とかは、覚えておくとトラブル時に役に立つかもしれない
  • MBR・GPTの両方に対応した、パーティション操作のコマンドとして、partedというのもある
  • 意識してパーティション分けたことなかった
  • パーティション分けるとアクセス速度が上昇するのは、検索スコープが分かれるからなのかな

ファイルシステム

マウント

  • mount,unmountコマンドは使ったことがない
  • マウントの単語自体はDockerとかでも出てくる
  • EC2にS3のマウントする時に使ったかな、他はDockerでホストのディレクトリをマウントするとかで出てくる
  • マウントするために利用するディレクトリをマウントポイントと呼ぶことを初めて知った
  • AWSのハンズオンでマウントを行った記憶がある(復習しようと思った)
  • OS起動時にマウントするには、/etc/fstabファイルを編集する
  • WindowsだとSSDとかHDDがC:とかD:とかE:とかにマウントされて使えるようになるよね
  • マウントを意識したことないからこれもLinuxならではって感じなんだろうか

スワップ領域の作成

  • パーティションスワップ領域として使うのにスワップファイルシステムを作る必要があることを初めて知った
  • スワップ領域の有効・無効化用のコマンドがあるのはわかりやすい
  • メモリのメトリクス監視でスワップ領域が表示されるが、どういう仕組みかは分かっていなかった(利用していないメモリ上のデータを一時退避する場所)
  • メモリサイズと同じサイズでハードディスクのパーティション領域を作る
  • スワップファイルシステムをパーティションに作成し、スワップ領域として利用する
  • パーティション領域は mkswap コマンドで作り swapon コマンドで有効にし swapoff コマンドで無効にできる
  • スワップについてイマイチわかっていなかったため勉強になった
  • 実際に作成したことはこれまでなかった
    • スワップ領域は作成した後に swapon コマンドを実行しなければ有効化されないという部分は意識しておきたい

自動マウント

  • /etc/fstab ファイルに記述しておけば自動マウントされるのは知らなかった
  • mount コマンドで /etc/fstab の設定で自動マウントする
  • fstabはfile systems tableの略
  • /etc/fstab にある設定ファイルに自動マウントの設定を書ける
  • S3を自動マウントする時にfstabを設定した記憶がある
  • やや記述が面倒な印象を持った
  • 自動でできることを知っていないと、この設定を書き換えようとはならないため今後覚えておきたい

CD/DVD/USB メモリ (リムーバブルメディア) の利用

  • リムーバブルメディアを使う場合はマウントする必要がある
  • mount コマンドでディレクトリを指定して手動でマウントする必要がある
  • メディアを取り出す前に umount でアンマウントする必要がある
  • Windowsだと、自動的に○○ドライブに割り当てられるが、Linuxだと手動でマウントする必要がある
  • Windowsでは意識しない部分だったため、なるほどと思った
  • ラズパイでリムーバブルメディアを接続するときそういえばマウントって単語が出てきた気がする

i ノード

  • ファイルやディレクトリごとにiノード番号を割り振られる
    • そのためiノードの容量が足りなくなると新規にファイルを作成できなくなる
    • ディスクに空きがあっても、iノード領域に空きが必要
    • ファイルを作成する際はデータ領域の空き容量だけではなく、iノード領域の大きさも意識する必要がある
  • ファイルシステムにファイルを作成する際にiノード領域が足りないと作成できないことは注意していきたい
  • ファイルシステムを作成した時にiノード領域が確保される
  • ファイルシステムには、データ領域の他にファイルごとの場所やアクセス権限などを管理するiノードと呼ばれる領域がある
  • df -i で確認可能
  • df -i でファイルシステムの情報を参照できる
  • 手元の環境で確認すると、gunzipコマンド・gzipコマンド・zcatコマンドのiノード番号は異なっていた

ハードリンクとシンボリックリンク

  • 直接参照しているか、パスで参照しているか
  • postgresql関連のエラーでさわった記憶がある
  • シンボリックリンクはよく使うが、ハードリンクという仕組みがあることを知った
  • ln コマンドでリンクを作成する
  • ハードリンク、シンボリックリンク共に初めて聞いた
  • ショートカットはファイル(.lnk)として扱うためエディタに直接貼り付けると開けないが、シンボリックリンクではそれが可能
  • ハードリンクは使ったことがあったがシンボリックリンクはそもそも知らなかった
  • ハードリンク
    • 元ファイルを削除してもハードリンクが残っていれば消えないのか
    • ファイルの実体(iノード番号)を共有する
    • iノード番号で同じファイルの実態を参照する必要があるので、同一のパーティション内である必要がある
    • 通常のファイルの新規作成はハードリンクを1つ作るのと同義
    • 元ファイルが削除されてもハードリンクされたファイルが実行できる
    • フォルダのリンクは作成不可
  • シンボリックリンク
    • 元ファイルが保管されている位置を示す擬似的なファイルを作成する
    • Windowsのショートカットファイルのような感じ
    • 元ファイルが削除されるとシンボリックリンクされたファイルは実行できない
    • Windowsでいう、ショートカットみたいなもの
    • フォルダのリンクを作成可能

ディスクを管理するコマンド

  • アンマウントした状態でfsckコマンドを実行するほうが安全
  • fsckはfile system check, file system consistency checkの略
  • fsck デバイス名 のコマンドでそのデバイスファイルシステムのチェックと修復ができる
  • fsckコマンドで修正する場合、修正対象のパーティションはマウント解除してから行う
  • fsckコマンドを使う場面はおそらく焦っていると思うので、問題を増やさないためにもチェックするパーティションがアンマウントされている状態であるかのチェックを行うようにしたい
  • duはdisk usedの略
  • duコマンドで細かいディレクトリ使用量が見える。df -h で全体を調べて深堀りする時に使えそう
  • df コマンドでハードディスク全体、du コマンドでフォルダの使用量やファイルのサイズを確認できる
  • df -hでファイルシステムごとの空き容量を確認して、du -sh /* で各ディレクトリのファイルサイズを確認したりするのはよくやる

まとめ


「第12章 ファイル管理」の内容は知識として知らない部分も非常に多く勉強になりました。気を付けないといけないポイント(スワップ領域は作成した後に swapon コマンドを実行しなければ有効化されない、ファイルシステムにファイルを作成する際にiノード領域が足りないと作成できないetc)は実際にLinx系のシステムを取り扱う際には気を付けていきたいと思います。

Linux標準教科書」読書会は今回で終了となりましたが、今後の読書会にも参加していきたいと思います。

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

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

tech.rhizome-e.com

読書会の題材

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

10回目レポート

今回は11章「プロセス管理」で、参加者は4名でした。

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

プロセスとは

  • プロセスはkillコマンドで終了させるときに確認するぐらいでプロセスの親子関係や流れを意識したことはなかった

スケジューリング

  • ラウンドロビンFIFOはよく出て来るので覚えておくといいかも
  • プロセスの優先度のパラメータの1つにNice値がある
    • psコマンドでプロセスの確認をすることがあるので、その出力に表示されていたか調べたが、-O nice を付けないと表示されないらしい
  • プロセスの優先度を変更できるnice,reniceコマンドは初めて知った
  • Nice値は知らなかった
  • Nice値は優先度を示す値
    • 初見では19が最も優先度が高そうに見えたけど、-20が一番高い
    • 他プロセスに処理を譲るほどNiceであるということ…?

フォアグランドジョブとバックグラウンドジョブ

  • ジョブをバックグラウンドとフォアグランドに切り替えることができるのは知らなかった
  • コマンドをバックグラウンドで起動する際に&をつけるのはやったことがある気がするが具体的に何で使ったかは覚えていない
  • コマンドでバックグラウンドとフォアグランドを切り替えるのは新鮮だった

プロセスID

  • 自身のPIDの取得は、溜まったプロセスを定期的にkillするスクリプトを書いた時に使った
  • psコマンドは強制終了させたいプロセスを調べるのに使うぐらい

シグナル

  • ctrl + C はSIGINTを送信してたのか。知らない内に使っていた
  • プロセスを強制終了させるために使っていたため、9以外のシグナル番号は知らなかった
  • killコマンドで強制終了と終了のシグナルを送信するぐらいしか使ったことがない
  • killコマンドしか使ったことがない
  • プロセスの終了は、15番を基本使ってそれで終了しなかった場合に9番で強制終了させた方が安全にプロセスの終了が行える

topコマンドとpstreeコマンド

  • CPUやメモリ使用率が高いプロセスを特定したい時にtopコマンドを使う
  • topコマンドはあまり使ったことがない
  • topコマンドはリアルタイム故に違うidと読み間違えるのを気を付けたほうがいいらしくなるほどなと思った
  • pstreeコマンドはプロセスの親子関係が図として表示されるので直感的に理解しやすい

プロセス間通信

  • パイプ、シグナルをよく使っているかな
  • セマフォなんかはよく聞く

まとめ

普段、使っていて意識することがなかったプロセスやジョブなどの内部構造について学ぶことができました。 プロセスIDやシグナルの項目は使う場面もあると思うのでこの読書会で知ることができてよかったです。次回は、「第12章 ファイル管理」です。

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

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

tech.rhizome-e.com

読書会の題材

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

9回目レポート

今回は「第10章 ネットワークの設定と管理」で、参加者は5名でした。

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

TCP/IPとは

  • いつも説明できなくて再度定義を確認した
  • プロトコルの話なので、そういう仕組みがあるというだけの話
  • IPは通信先の指定とパケットを送る仕組み
  • pingコマンドでサーバーと通信できているか確認する
  • pingコマンドで外部につながるか試すとき、8.8.8.8でグーグルにつながるか確認する
  • ping -cで発行回数を指定できるのは知らなかった
  • ping -sでパケットサイズを指定できるのは便利そう
  • TCPはIPを使ったデータ送信の仕組み
  • TCPはデータの確認をする。UDPはデータを送りっぱなし

IPアドレス

  • サブネットマスク等勉強したけど知っているだけの状態
  • 情報技術者試験にも頻繁に出題される内容
  • アドレスの長さ(量)によってクラスが分けられている
  • このクラスの話がいまだによくわかってないけど、範囲を暗記する系?
    • 暗記する系です(あまり使うことはない…)
  • IPアドレスサブネットマスクからネットワークアドレスを導出して、同一ネットワークかどうかを判別する
  • AWSVPCを作る時にアドレスの範囲を考える必要があるが、どのくらいIPアドレスを用意しておけば良いのかよく分かっていない
  • CIDR記法はサブネットマスクの部分の表記がビットが先頭からいくつ立ってるかという書き方に変わっただけ
  • AWSVPCやセキュリティグループ作る時とかにCIDR表記を使う

経路の確認

  • ゲートウェイにもIPアドレスが設定されていて、データが中継される
  • tracerouteコマンドは使ったことがあったがtracepathコマンドは知らなかった
  • tracerouteコマンドとtracepathコマンドを使ってみる
    • ネットワークの障害とかで使うのかなと思う
    • 以降のコマンドも含めて、どういう風に調査していくのか知りたい

ネットワークの設定

  • ipコマンドはほとんど使ったことがない
  • IPアドレスの確認にifconfigコマンドを使っていたがCentOS 7だとip aが推奨されているようなので今後気を付けたい
  • IPアドレスの確認コマンドはLinuxはifconfig, Windowsはipconfigで紛らわしい
  • IPアドレス以外の情報が何を指しているのか分かっていないので調べる
  • ubuntuだとネットワークの設定は以下

ubuntu.com

ルーティング

  • 設定した事がない
  • ip routeコマンドは使ったことがない
  • ip routeコマンドやssコマンドは使ったことがなかったので何も知らなかった
  • 大学の研究で設定したことがあったことを思い出した

DNSを使う設定

  • FQDNの正式名称が「Fully Qualified Domain Name」だと初めて知った
  • /etc/hostsファイルしか編集したことがない
  • /etc/hosts は触ったことある
  • nslookupコマンドは使った事があるな。DNSの設定が正しいかどうかの確認だったかな
  • nslookupコマンドはSSL化の勉強した際に使ったりした

ポート番号

  • SSHのポートはよく攻撃されるので別のに変えたりしている
  • サービスによってポートが決められている、だから攻撃する時にこのポートでしょ?って決め打ちでアクセスしてこようとしてくる場合があるからあまりに有名すぎるものは使わないとか聞いたことがあるような

サービスの確認

  • ssコマンドは使ったことがない
  • ssコマンドで見てもよく分からんので調べる

ネットワークセキュリティの設定

  • このあたりの設定は触ったことがなかった
  • ファイアウォールの設定はSQL Server周りのことをWindowsでやった覚えがあるが、コマンド操作は初めて見たため新鮮だった
  • ファイアウォールホワイトリストでサービスを許可するみたいなのはどこかでやった気がするけど、GUIからやったことしかないのでCUIからの操作は全然知らない
  • さらっと読んだけど、あんまり理解できてないからまた読み直す
  • CentOS7でfirewalldに変わったのか
  • DB接続の許可を制限したい時に使った記憶がある

まとめ

今回はネットワークに関する章でした。意見交換を通じて、コマンドの使いどころなどをなんとなくイメージできました。 ネットワークについてはLinux以外でも非常に重要な内容のため、本章で学んだことを業務に活かしていきたいと思います。 次回は「第11章 プロセス管理」です。

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

株式会社リゾーム 技術部 システム開発 第2グループの土井です。 「Linux標準教科書」読書会の第8回レポートです。第7回目のレポートはこちらです。 tech.rhizome-e.com

読書会の題材


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

8回目レポート


今回は「第9章 シェルスクリプト」で、参加者は5人でした。

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


シェルとシェルスクリプト
  • シェルスクリプトはほぼ書いたことがない
  • カーネルを包み込んでいるからシェルという名が付いている、なるほど
  • これが噂に聞くシェルスクリプトかと思った
    • Windowsのバッチと似ていたため内容の理解はスムーズにできた
    • バッチよりも書きやすそう…
シェルスクリプト
  • 一次元の配列変数を扱う事が出来る
  • set, unsetコマンドでシェル変数の一覧表示と削除が出来る
  • バッチだとコメントはrem、シェルスクリプトは# でわかりやすい
  • バッククォートで囲むことでコマンドとして解釈される
    • JavaScriptのテンプレートリテラルに似ている
    • ほぼ使わないからバッククォートのキーを忘れがち
  • 1行目のシェルの指定、指定しなかったらどうなるんだろうか
    • 現在のshellで実行って感じかな?
  • パーミッションの変更
    • これいつも変更し忘れてpermission error起こしてる
  • 変数は値を参照したいときに$を頭につけるの、最初の頃はよくわからなかった
  • read
    • readコマンドで標準入力からシェル変数の内容を変更出来る
    • コマンドツールを作るときに変数の値を標準入力から指定できれば便利そう
    • 値が入ってなかったら標準入力から受け付けるとか
  • 引数
    • $0で実行コマンド名、$# で引数の数を参照できる事を知った
    • 可長変な引数を受け付けたいときに便利なのかな
    • 実際に使ったことは数えるくらいしかない
  • shift文
    • shiftコマンドで引数の順序をずらせる。どういう時に使うのだろうか
    • 使ったことがないのでユースケースを知りたい
  • 研究でログ取得のためにシェルスクリプトを作成したが、記法だったりは覚えられていないし知識が全体的に足りてないと感じた
条件分岐
  • ファイルの属性を確認できるのは便利
  • testコマンドまたは[ ]で評価するのは知らなかった
  • 条件分岐の終わりはfiやesacで文字を逆にするのか
  • 別の条件書く時は elif 。rubyだとelsifなので混乱する
  • 比較演算子使った事なかったけど、eq, ne, ge等で書くのか
  • 数値比較の演算子は>や<とかでは比較できないのか?
  • 数値比較を行う演算子はかなり見にくいと感じた
  • 数値比較は忘れてしまってエラーの原因になりそう
  • 条件分岐と繰り返しはプログラムを書くうえで基本なので押さえておこう
繰り返し
  • select文
    • 数値による入力ができるのは知らなかった
    • ユーザーに数値の入力を促せる事を知った
    • 数値による入力を促すことができるのは結構使えそうだと思った
  • for文
    • 処理対象のリストが明確な場合にのみ使用できる感じで、明確でない場合はwhile文を使用すると解釈
    • 動作が特殊で、ル-プには使えないことは気を付けようと思った
サブルーチン
  • 言語設定によって出力される文字列が変わってしまうのは比較などする際に意識した方がいいところ
  • 関数使ってまでシェルスクリプト書いた事ないな
  • 関数とかメソッドとか呼ばれるやつをサブルーチンというのか
  • Rubyだと聞かないので意識したことなかったけど、Goの「ゴルーチン」って言葉がよく分かってなくて少し気になってたのでスッキリした
実際のシェルスクリプト
  • /etc/init.d/functionsの中の関数一度も使ったことない
デバッグ
  • shに-xをつけて実行すると内容を確認できるのは知らなかった
    • 変数の中身を表示しながら実行するのは便利
  • sh -x でコマンドや変数の中身を表示できる事を初めて知った
    • echoで変数の中身確認してた
  • sh -xでコマンド、変数の中身を見れるのは便利な予感がする
  • デバッグが必要な規模の自作シェルスクリプトを作ったことがないな...
  • Dockerfileでビルドがうまくいかないときにデバッグ使えると便利だったりしそう

まとめ


今回はシェルスクリプトに関する記法などがメインでした。実際にシェルスクリプトには触れていても使っていない機能があるなという印象でした。私自身も忘れている部分などが多かったので復習に取り組みたいと思います。 次回は第10章「ネットワークの設定と管理」です。

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