「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アドレスとサブネットマスクからネットワークアドレスを導出して、同一ネットワークかどうかを判別する
• AWSでVPCを作る時にアドレスの範囲を考える必要があるが、どのくらいIPアドレスを用意しておけば良いのかよく分かっていない
• CIDR記法はサブネットマスクの部分の表記がビットが先頭からいくつ立ってるかという書き方に変わっただけ
• AWSでVPCやセキュリティグループ作る時とかに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 & servicesやErrors 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の基本操作

• CentOS・Red 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の操作に慣れるために、一時期VSCodeのvimのプラグイン入れていたが、めんどうになってやめた(おかげで割りと慣れた)
• 直前の変更を繰り返すドットコマンド「.」
  • 「I」で行頭にインサートモード→「# 」を入力→「ESC」
  • その後は「j」で一行下にカーソル→「.」で上と同じことが実行される

まとめ

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