2022-11-07

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

読書会

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

読書会の題材

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

2回目レポート

今回は2章「Linuxのインストール」と3章「基本的なコマンド」で、参加者は7名でした。

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

Linux のインストール

WSL2でUbuntu(20.04 LTS)の環境を構築した
- Ubuntu.exe起動時に「システムコールに渡されるデータ領域が小さすぎます」とエラーメッセージが表示された
- FILESTREAMが有効なMSSQLサービスが実行されているときにこのエラーメッセージが表示されて起動できない模様
- 無効にしPCを再起動すると無事起動することが出来た
Hyper-V+CentOSで環境作成した
- 仮想スイッチが難しかったがDefault Switchで事足りそうだったので、Default Switchを使用した
VirtualBox+CentOSで環境構築した
- VirtualBoxとCentOSのバージョンが合致するものとしないものがあるらしい
VirtualBoxでCentOSのGUI環境を作った
- Audioを無効にしないとエラーで強制終了する

ファイル操作

大学の頃に使用していたコマンドが登場して懐かしい気持ちになった
sshで入った際に使うことが多い
クライアントで使うことは少ない
- GUI操作で済むから
権限に関するコマンドは使うことが多い印象
ファイル絞り込みで文字数が分かっている場合は?を使って絞り込める事を知ったが、 *で十分な気がする
- cpやmvとかにもワイルドカードが使えるので、txt拡張子全てを操作したいときとかは便利

lsコマンド

lsオプションで -lや-aはよく使う
- よくll(ls -l)とかla(ls -a)とか使う
  - Macだとエイリアス設定している
- ls -laSr でファイルサイズでソートしたりもする
- -tで最終更新時間でソートできる事を知った

cpコマンド

マウス操作でファイル複製するからあまりcpは使ったことがなかった
cpとmvは-iオプションで上書きミスを防げるので使うときは-iを付けることを基本としたらいいかもしれない
cp のオプションを使う機会はあまりなかったので学び

rmコマンド

ディレクトリ削除(rm -rf)は万が一があるので注意して扱う必要がある

ディレクトリの操作

pwdコマンド

pwdコマンドは知っていたが正式名称Print Working Directoryは初めて聞いた
pwdの略は昔教えてもらったことがあったことを読んでて思い出した
字面的にパスワードに見える、このコマンドはいつも心の中でパスワードって呼んでる
pwdは使ったことなかった
- RailsだとRails.rootがあるから使ってないな...
pwdは特にCUIに慣れない頃によく使っていた覚えがある
- cdしまくると自分がどこにいるのかわからなくなった…
いきなり自分の知らない地点に行くことってないのであんまり使うことないけど、DockerとかだとImageから作ったコンテナに入ったときに今どこにいるか知りたくて実行することはある

cdコマンド

cdなどはWindowsでも常連のコマンドのため、業務でも使うことが多い
cdは、よく使ってるコマンド
一番使ってるコマンドかなー
- cd - で直前にいたディレクトリに戻れるのが便利

mkdirコマンド

mkdirはあまり使ったことがない
mkdirの-pオプションは初めて知った
mkdirとtouchをまとめてできるコマンド欲しいなってよく思う

rmdirコマンド

rmdirは実は知らなかったコマンド
中身があるない関係なく消したいことの方が多いのでいつも rm -r で消してる
ディレクトリの作成ミスで使うぐらい

パス指定

親ディレクトリ(..)やルートはcdで使うことがよくある
絶対パスは現在位置に左右されずに使える
あるパッケージ内のみでファイルの参照関係が完結する場合、例えばアプリケーション開発の場面とかでは基本的に相対パスを使う
必ずrootパスから追いたい時は絶対パスを使う、パッケージじゃなくてサーバ自体に依存する時とか

ファイルの内容を表示

cat,more,lessコマンド

catはドットファイルを確認するときに使うことが多い、moreやlessは知らなかった
catとlessはよく使うがmoreは使ったことが無い
moreとlessとmanは初めて知った、今後使えそう
ログファイルの閲覧でless +Fをとてもよく使う
- less +Fはファイルが更新されると、リアルタイムで表示も更新される
lessで事足りるので、moreはあまり使わないかなあ
catはファイルの中身を丸ごと別のファイルに挿入したい時とかでよく使うかな...
- ファイルの中身を参照したいだけだったらlessとかtailの方をよく使う
ページングとページャの名前は初めて聞いたことと、機能としては意識していなかった
moreはファイル末尾まで行くと終了するらしい
catで標準出力→grepで絞り込み→lessで表示みたいな感じで、パイプで繋いで使ったりもする
ファイル開いた後のコマンドモードで使うコマンド類は覚えておくと作業がだいぶ捗る
catコマンドは複数ファイルを指定して結合してくれる

ファイルの検索

findコマンド

findもあまり使ったことがない
findは使い方をあまりおぼえていないので、あまり使っていない...
shellの世界で頑張る必要がある時に結構使う
- 普段だとFinderとかGUIでファイル探す方がわかりやすいしあんまり使わない気がする
findコマンドは卒業研究で前年度までのプログラムを探す際に助けられた
指定ディレクトリ以下のファイルを対象とする場合に使う

コマンドのパス

whichコマンド

whichはほぼ使ってない
whichは使うことはほぼなさそうだけれど覚えておこうと思った
whichもトラブルシューティングでよく使う
- どこのコマンドを参照しているのかとか
  - yumでインストールしたコマンド、ソースからビルドしたコマンドが同居していて、意図していないコマンドを利用していたり
ツール類をいろんなところからインストールしてる程よく使うかな...
- 例えばRubyとかも公式からインストールしたやつじゃなくてrbenvでインストールしたやつになってるか確認する時とか
ライブラリのバージョンが変わらない時に使ったりもする

ヘルプの使い方、マニュアルの使い方

man, helpはこのコマンドのオプション何だったか調べるときに良く使っている

helpオプション

helpオプションを使うのはオプションの確認する時ぐらい?

manコマンド

manもほぼ使ってない
コマンド名知ってれば使うことってあまりないよな...コマンド名がうろ覚えの時とかに使うのかな？Linuxコマンド以外のマニュアルを見たい時に使うんだろうなーって感じはする
manコマンドがセクションで分かれていることは知らなかった
ゲームのコマンド(セクション6)もあるみたい

まとめ

基本的なコマンドでも担当業務が異なると使うもの、使わないものがあることが分かりました。実際にどのような場面で使ったり、どういった使い方をすることで便利に扱えるかといった部分で意見の交換を行えてとても参考になりました。

今後の業務などで、ここは読書会で触れたところだなと思いだし活かしていければと思います。

次回は第4章「正規表現とパイプ」です。

2022-10-24

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

読書会

株式会社リゾーム技術部システム開発第4グループの平松です。「入門監視」読書会が終わりましたので社内の有志で新たに読書会を始めました。それをレポートしていきたいと思います。

読書会の題材

題材として選んだのはLinux標準教科書です。

linuc.org

読書会の本を決める際に賛同する声が多かったので、こちらになりました。
また、標準教科書は今回選んだ本以外にもサーバー構築やセキュリティについて書かれたシリーズもあり情報技術を包括的に学べる教材となっています。

読書会の進め方

進め方は、「入門監視」読書会の時と同じです。

当日までに事前に章を読んでおく
感想や疑問点をまとめる
Yammer(Viva エンゲージ)にアウトプットする
読書会当日、感想をそれぞれ発表する
意見交換を行う

1回目レポート

初回は、「Linuxとは」で、参加者は6名でした。

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

基本ソフトウェアと応用ソフトウェア

大学の頃にLinux環境でのプログラミングを少し学習したが、今はほとんど覚えていない
例を挙げて説明されている部分が分かりやすく、知識を定着させやすいと感じた
基本ソフトウェアの役割について、分かりやすく明文化されていて理解が深まった
基本ソフトウェアと応用ソフトウェアは自分の中で明確に区別をつけていなかったため勉強になった
普段の業務に活かせる部分は活かしていきたい
卒業研究でRaspbianには触れていたのでその時の経験とすり合わせながら学習を進めていきたい

UNIX

Linus TorvaldsさんがLinuxを作ったということ自体は知っていたが、Linuxの特徴(特にライセンス形式)は知らなかったため新たな知識になった
多機能・高機能のOSを目指した結果、広まったのはコンパクトで小回りが利くUNIXなのは面白い
歴史を辿るのは結構大事
大学で一通り学習したはずだが、誕生の歴史はほとんど覚えていなかった
UNIXが派生し、BSDやSystem V・Linuxがある
- あまりそれぞれがどういった経緯でできていったのかは覚えていなかった

Linuxの特徴

ユーザランドでコマンドが動作する事は初めて知った
シェルはzshを使っている
- プラグインが多くあり便利
ハードウェアに直接アクセスする部分がカーネルで、それ以外のPCを利用する側が認識できる部分がユーザーランド?
- なのでユーザーが実行するコマンドとかファイルシステムとかの動作領域もユーザーランド?

ディストリビューション

大学でLinuxディストリビューションの一つであるUbuntuを使用した経験があるため、そのことともリンクさせながら学習を行っていきたい
LinuxのディストリビューションだとUbuntuは触ったことがある
パッケージマネージャはOS以外にもプログラム言語だとRubyはRubyGems、javascriptとかはnpm、yarn
サーバー用途だと、Red HatやAmazonLinux(AWS)が主流？
クライアント(開発環境)だと、Ubuntuが主流?
- Ubuntu派生のOS(Linux Mint)とか、いろいろお好みで選択肢はある
各ディストリビューションの特徴を知っておくとDockerのベースイメージを選定するときに少し役に立つ

まとめ

今回は誕生の経緯や特徴など前提知識がほとんどでしたので経験知の共有がしづらい章ではありましたが開発環境に関する共有は多少できたかと思います。次章以降コマンドの実習等もあるのでより業務や過去の経験と絡めた感想を共有していきたいと思います。

2022-09-14

RubyKaigi2022レポート

Ruby

技術部第3グループの廣江(@buta_botti)です。会社のサポートを受けてRubyKaigi2022に参加させていただきましたので、自分の見聞きした範囲で簡単に紹介させていただきます。内部の難しい話はわからないので、その辺りに興味のある方には他の方の参考になるレポートや、発表者の方のスライドやブログを参考にしていただくとして、今回は利用する側の目線で色々書ければなと思っています。

タイトルはこちらのスケジュールに記載のものを流用しています。

rubykaigi.org

Ruby meets WebAssembly

speakerdeck.com

ざっくりと言うとRubyがブラウザ上で動くようになりました。多少の課題は残っているものの、多くのRuby スクリプトには影響がないので、どんどん利用してフィードバックしていくことが私のような一般Rubyistが貢献できる方法となります。

利用方法は至って簡単です。

<script src="https://cdn.jsdelivr.net/npm/ruby-head-wasm-wasi@0.3.0-2022-09-06-f/dist/browser.script.iife.js"></script>
<script type="text/ruby">
  # Ruby code
</script>

<script type="text/ruby">内に書いたRubyコードが実行され、pメソッドやputsメソッドを使うとコンソールに出力されます。

少し凝ったことをしようとすると、JavaScriptで多少ゴニョゴニョする必要があります。

<script src="https://cdn.jsdelivr.net/npm/ruby-head-wasm-wasi@latest/dist/browser.umd.js"></script>
<script>
  const { DefaultRubyVM } = window["ruby-wasm-wasi"];
  const main = async () => {
    const response = await fetch("https://cdn.jsdelivr.net/npm/ruby-head-wasm-wasi@latest/dist/ruby.wasm");
    const buffer = await response.arrayBuffer();
    const _module = await WebAssembly.compile(buffer);
    const { vm } = await DefaultRubyVM(_module);

    vm.eval("# Ruby code");
  }
</script>

凝ったことをするにあたって、RubyからJavaScriptを実行したいこともあるでしょう。その場合はrequire 'js'でJSライブラリを使えるようにします。

<script>
  // ...省略
  vm.eval(`
    require 'js'
    text = "Hello Ruby!"
    JS.eval("document.body.innerText = '#{text}'")
  `)
</script>

HTML上のbodyに「Hello Ruby!」を表示できます。

ここで紹介したようなサンプルは、全てruby.wasmで詳しく書かれています。とても親切。

github.com

また、require 'js'したJSライブラリの実体は以下のファイルのようです。

github.com

C言語が読めなくても、親切なコメントが書かれているため、使い方を理解することができます。

Types teaches success, what will we do?

speakerdeck.com

こちらは gem_rbs_collection の紹介になります。

github.com

実際にプルリクを出して取り込まれるまでの過程を丁寧に解説してくださっており、自分もやってみようという気にさせていただけました。内容としては docs/CONTRIBUTING.md の内容を日本語で詳しく解説していただきました(スライドは英語)。

github.com

自分のプロダクトで使っているケースで型を書けばよいということらしく、そのライブラリが想定しているすべてのパターンを考慮しなくても気軽にPRを出せるのということなので、すごく取り組みやすいのではないでしょうか？個人的にはOSS活動の中でも(ライブラリの理解は使っている以上前提として)typo探しの次くらいに取り組みやすい領域だと思います。早速手元のRailsプロダクトでsteep checkして、不足している型をgem_rbs_collectionに提出しましょう！

Tools for Providing rich user experience in debugger

Introduction of Tools for providing rich user experience in debugger from Naoto Ono

www.slideshare.net

(VS Codeを利用していない方でも)ChromeのDevToolsでめちゃくちゃ好体験のデバッグができるようになったという話でした。

利用しているRubyにdebug.gemがインストールされていることが前提です。

$ rdbg --open=chrome sample.rb

もしくはプログラム内のdebuggerで開くrdbgコンソール上で

open chrome

でデバッグ用のChromeDevToolsを開くことができます。

Sourcesタブでデバッグ対象のRubyプログラムが確認でき、ConsoleタブでRuby スクリプトを実行できるみたいです。これだけでもテンションが上がりますね。Consoleタブで実行したRubyプログラムはSourcesタブのプログラムの状態に影響するようです。

↑変数aの値が書き変わっている様子

Make RuboCop super fast

speakerdeck.com

RuboCopはrequire 'rubocop'の処理が重いという課題があったそうなのですが、この度サーバーモードというのが追加されたことによって、RuboCopサーバーをローカルに立て、そこにRuboCopモジュールをロードしておき、RuboCopの実行をこのサーバー上で行うことで重いrequire処理をスキップ(正確にはrubocop/serverという軽量なものだけで済む)でき、高速化します。

RuboCopサーバーが起動していない状態でのデフォルトのrubocopコマンドは従来通りの動きで、オプションを明記したrubocop --no-serverと同等です。rubocop --serverでRuboCopサーバーが起動していない場合に起動し、サーバーモードでRuboCopを実行し、サーバーの停止、再起動はそれぞれ--server-stopと--server-restartが対応しています。起動しているサーバーのステータスは--server-statusで確認できます。

ちなみに、RuboCopサーバーが起動している状態でオプションなしの rubocop コマンドを実行すると、サーバーモードになるそうです。

error_highlight: user-friendly error diagnostics

(スライド見当たらず...)

エラー表示がとても親切になりました。実際どう便利なの？今でもファイル名と行数出てるから場所わかるし十分では？みたいな意見に対しては明確に便利になるケースを提示してくださっていました。

例えばerror.rbの2行目に次のコードがあります。

hash[:foo][:bar][:baz]

ここでNoMethodErrorが起きた場合のエラー表示は以下のようになります。

error.rb:2:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError)

何番目の[]が原因か分かりにくいですね。これがerror_highlightによって

error.rb:2:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError)

hash[:foo][:bar][:baz]
          ^^^^^^

のようになります。原因箇所が一発でわかって便利です。

また、実際のコードがチラッと見えることによって、見覚えのあるコードであればおおよそのあたりをつけてデバッグを開始できたりと、デバッグにおいてかなり便利になるのではないかなと思います。

Real World Applications with the Ruby Fiber Scheduler

Falconやasync.gemが出てきてPumaよりFalconの方がパフォーマンスが出ていたというのはスライドを見ていて分かったのですが、なにぶん英語が聞き取れなくて後でスライド見ようと諦めて聞き入っていたのに、いざまとめようとするとスライドも見つけられなくてめちゃくちゃ悲しい思いをしています。他力本願すぎたことを戒めに英語を勉強しなければなという気持ちにさせられました。スライドを眺めていただけのイメージで話をすると、今のアプリケーションは大量のリクエストを捌ききれないことがあり、それがノンブロッキングなFiberを使うことで捌けるようになってパフォーマンスも上がるみたいな感じなのかなと思っています...。FalconをRailsで使うとActiveRecordのリクエストをFiberで捌けるようになるとかそんな内容もあったとか。実際はそんなサラッとした内容ではなくて実現するための苦労話がたくさんあったと思います。

github.com github.com github.com

Rack3でストリーミングに対応するという話も出てたみたいですが、この辺りのことのなのかな...？

There is one new feature in Rack 3 which is not directly backwards compatible:

・Response body can now respond to #call (streaming body) instead of #each (enumerable body), for the equivalent of response hijacking in previous versions.

github.com

ここのリポジトリに情報が詰まってそうなので、読んだり動かしたりした後にまたブログを書ければなと思っています。 github.com

History of Japanese Ruby reference manual, and future

slide.rabbit-shocker.org

るりまの話を聞きました。個人的にはるりまをRDocからMarkdownで書けるように...や、サンプルコードをwasmで動かせるように...と計画しているのが一番インパクトがありました。Markdownなら普段から使っているので、ちょっとドキュメントの修正をしたい時に簡単に提案ができていいなと思いますし、サンプルコードをブラウザ上で実行できるのもすごく手軽に動作を確認できていいですね！るりまは新しく追加された機能とかについては割と大丈夫だけど、昔からある機能については更新されてなかったりとかするみたいなので、その辺りにコントリビュートチャンスがありそうな気配がします。ひっそりとissueを出しても埋もれてしまうので、ruby-jpのslackなどで相談しながら進めていくのがいいのかなと思います。

多言語対応もロングスパンで進めていくそうで、日本語以外を母国語に持ち、翻訳をしてくれる方を募集しているそうです。

あとはissueが山盛り溜まっているっぽくて、現在のステータス管理とかしてくれる人を募集中だそうです。Ruby本体の方でも似たような話を聞いたような...？

github.com

るりまには長年お世話になっているので、何らかの形で恩返しをしていきます。

全体の感想

TwitterやSlack、Discordで普段話している人とオフラインで会うことができてとても楽しい3日間を過ごすことができました。発表に関してはやや難しくて理解しきれない部分も多くありましたが、そこは実際に触ってみて、体で覚える方向でカバーしていきます。実際にデモを用意して動かしてみる記事も別で書いていますのでお楽しみに！RubyKaigiは美味しいご飯とお酒を飲みながら、知り合いと好きなプログラミング言語についてわいわいと語らうことができるので最高ですね。今回、現地参加は弊社からは私一人でしたが、私と一緒にRubyKaigiに行きたい！という方が社内に増えてくれるととても嬉しいなと思っています。

2022-09-14

「入門監視」読書会レポート vol.12

読書会

株式会社リゾーム技術部システム開発第4グループの平松です。
読書会の第12回目のレポートです。第11回目のレポートは、こちらになります。 tech.rhizome-e.com

入門監視 ―モダンなモニタリングのためのデザインパターン

作者:Mike Julian
オライリー・ジャパン

Amazon

12回目レポート

今回は、「付録C 実践監視 SaaS C.6~C.8」で、参加者は5名でした。

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

テスト駆動開発と監視

ソフトウェア開発とテストがセットであるように、システム運用と監視はセットで語られるべき
- システム運用側の視点が薄かったかなと思った
監視とテストを同じ枠で考えたことがなく、頭の中で何か別のものとして切り離していた
- 確かに毎回テストしているようなものだ
燃料警告灯を付け忘れないのはそれが既に完成されているからであって、新しい何かを作るときは監視まで意識していないとできない気がする
今後はより本質的な捉え方をしていこうと思う
監視しやすいシステムを作っていくにはシステム運用と監視の両方の視点が必要になってくる
- そのシステムをどれだけ理解しているかが重要になってきそう
システムの監視に自覚的にならないといけない
ヘルスエンドポイントのように、開発していく中で、そういった観点は必要になる

自分で監視を作る

テストは不安なところを書くべきとは自分もよく言っているのだけれども、監視も同じなのか
- 何を監視するべきかを知っているのは開発者自身…なのかもしれないが、だったらなんで開発者は何を監視すればいいのかこんなに悩んでいるのか
- ちゃんと自分たちの運用の不安と向き合う時間がいるんだよなと思う
アラートが上がってるけれど、なにをすればいいのか？となったら、放置してしまいそう
監視はビジネスロジックを理解していないと作れない
「後で修正するときにテストがないと漏れる可能性ある」「テストなかったら常に改修で壊れていないかどうか心配しないといけないじゃない？」
- この考え方を監視にも当てはめて考えればいいのか
SQLでデータベースの状態をメトリクスとして引っ張れるなら、色々計測できそうな気がしてくるが、具体的に何を取得したらいいのか悩むところ
締め処理など非同期Jobの結果が格納されるレコードのステータスなんかは見たほう良さそうだが、SC BASE*1は基本的にデータを蓄積していくアプリなので
テストと同様に、開発しているアプリケーションの心配事を監視するべき
- でも何を監視するべきか悩んでいる...
「テスト」という観点だと、「仕様どおりに」「バグを起こさないように」といったことが考えられるが、監視という観点だと、どのような不安があるか...

監視を育てる

ヘルスエンドポイントパターンに変更する…。監視も育てる思考
- たしかにヘルスエンドポイントパターンに移行すれば、テストが可能になるので良い
- 標準化の視点を持てる
アプリを作成しているとバージョンアップや改修など、作りきりでないことは一般的になってきていると思うが
育てると聞くと、育てない場合の罪悪感が半端ない
より良い監視の方法を模索し続けないと現状より悪くなることはあっても良くなることはないのでコードのリファクタリングなど同じで定期的な見直しは必要
今一度何が監視できていて、何が監視できていないのか整理したい

自動復旧のためのアイデア

アラートのWebhookを使って自動復旧用のリクエストを行うわけか
- そういう発想自体がなかった
何らかの復旧が必要な異常を検知し、これを契機として作動させるということか
教科書に書かれている仕組みではなくて、応用みたいな話になってくるのかも

監視パラダイムの変遷

便利な反面に複雑化している昨今のシステム構成。
監視SaaSならば分散トレーシングにも対応しやすいというのは、確かにそうかも…
「Observability」、最近よく聞くワード

機械学習と異常検知

監視に対する機械学習の適用。たしかに膨大なデータがあるので、何かしら兆候を察知させるのに使えるのかも
- データが膨大にある監視SaaSならではのサービス
こんなところにも機械学習の波が
機械学習の場合はデータセットの質や量にかなり影響されるかもしれないが、サーバー監視ならある程度揃っているだろうし使えそう
考慮漏れの可能性があるからレビューなどがあるわけでその部分を機械学習で補填してくれるのはとても便利
監視SasSは膨大なデータ量を扱うので、確かに機械学習を利用出来るな
標準的なメトリクスを監視することは有効ではないが、兆候を検知して通知するのは、長期的に保守していくBOND GATE*2で非常に助かりそう

監視SaaSのまとめ

昔に比べると監視のハードルはずいぶん下がっているんだから、自分たちの手で監視したいものを決めていけたらいいなと思った
監視の民主化は、今後取り組んでいくべき箇所
監視SaaS(New Relic/Mackerel)を利用して、みんなが見れる状態を整備したい所存

まとめ

今回は監視SaaSの活用や今後について各々、疑問や課題などを上げてそれについて話し合うことができました。特に監視する上での考え方は今後、監視に取り組む際に必要な基礎の部分になるため、それを今回の読書会で学ぶことができてとても良かったです。「入門監視」を読む前は、監視についての理解も浅く、監視SaaSを導入してもあまり活用できてない状況でした。ですが、この本から監視についての様々な知見を得ることができました。すでに取り組んでいるものもありますが、今後、本から学んだことを実践してより充実した監視が行えるように環境を整えていきたいと思います。

「入門監視」読書会はこれで終わりですが今後も、読書会を行いたいと思います。

*1:売上報告・賃料計算も一体化したDX対応の業務支援システム(ホームページ商品説明引用)

*2:情報共有と業務効率化、遠隔でもデベロッパー・ショップの充実したコミュニケーションを実現するグループウェア(ホームページ商品説明引用)

2022-09-06

「入門監視」読書会レポート vol.11

読書会

株式会社リゾームシステム企画・開発部第3グループの藤岡です。
入門監視読書会の第11回目のレポートです。 10回目のレポートは、こちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続き入門監視 ―モダンなモニタリングのためのデザインパターン | Mike Julian, 松浦隼人 |本 | 通販 | Amazon を題材としています。

11回目レポート

今回は、「11章監視アセスメントの実行」と「付録C 実践監視 SaaS C.1~C.5」で、参加者は5名でした。

感想・意見交換

ビジネスKPI

製品毎に何のメトリクスが取れるか
- 施設数(テナント数)、月次経常収益、顧客あたりの収益
- 顧客あたりのコスト、導入・サポートコスト
- 各種機能の活用率（検索・登録・閲覧）、オプション機能導入率
- 顧客生涯価値
- 項目毎の検索実行数
- ユーザー毎、契約会社毎のログイン回数
- システムの利用状況
営業やお客様からユーザーのログイン回数やシステムの利用状況を求められることがあるので、真面目に検討していきたい

フロントエンド監視・セキュリティ監視・アラート

本書に挙げられている、ほとんどの項目は流用できそう
締め処理など非同期処理が反映されるまでの時間を計測したい
NewRelicで監視できそう。この辺りをダッシュボード化したい
ミドルウェア周りの監視(メトリクス取得)ができていない
- Nginx, PostgreSQL
  - 秒間トランザクション数とかHTTPレスポンスコードとか、レイテンシとか
何ができて、何ができてないのかを見直す時がきたのかも

実践監視 SaaS

PaaS, SaaS, laaS は確かに料金コストがかかるが運用コストはもっとかかるし、知識・技術の不足やセキュリティのことを考えると利用した方が安心だよな...
- 個人開発だとどうしてもコスパ的にVPSに詰め込む形になりがちだけど
導入自体は、エージェントをインストールするだけで簡単だが、監視・アラートやダッシュボード設計とかの学習コストはかかる
今は外形監視をしているだけなので活用できてないな...

監視SaaSの利点

チーム全員が監視システムにアクセス出来て、属人化が排除できる
- ただ現状はSaaSを利用しても属人化してしまっているので、使い方の勉強会や手順書の整備は必須
Mackerelはサーバー監視・New RelicはAPMとして組み合わせて使うとか出来ればいいが、ツールが増えると面倒だったり、お金の問題がある

監視SaaSは信用できるのか

疑って手をださなかったらいよいよ何もしないだろうな
- だったら手軽にでも始めるのがきっと正解なんだと思う
料金改定・障害発生率・セキュリティインシデント、最近は特に目立つ気がしている
運用をサービスに合わせる姿勢は大事だと強く思う
- サービスを運用に合わせることが基本スタンスになっていると、改善も見込めず非常に使いづらい
GitHub, GitLab, Bitbucket etc... のように類似サービスのコア機能にはほとんど違いがなくなり、差別化された機能や料金、サービス停止や買収なんかの心配をするようになる日が、既に来ているのかも

まとめ

現状、SaaSを利用しても属人化してしまっている、活かすことが出来ていないと思います。今回の章で課題や検討事項を整理出来たので、その内容を他のメンバーにも共有して改善していければと思います。

2022-08-24

「入門監視」読書会レポート vol.10

読書会

株式会社リゾームシステム企画・開発部第3グループの渡邉です。
読書会の第10回目のレポートです。第9回目のレポートは、こちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続き入門監視 ―モダンなモニタリングのためのデザインパターンを題材としています。

10回目レポート

今回は、「10章セキュリティ監視」で、参加者は6名でした。

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

監視とコンプライアンス

出てきたキーワード、全てがHerokuに載っていたと思う。
- こういうのでもっとカジュアルな規格とかがあればいいんだが。
この場合のすべてのログとは万一の事態が発生したときに、裁判において証拠能力を有するすべてのログという意味にも取れる？
様々なコンプライアンス規制がある事を知った。
- 多くの統制事項が期待する通りに動くようにするには、監視を実装するのが良い方法。

ユーザ、コマンド、ファイルシステムの監査

auditdは使ったことがないけれど、本来は入れておいたほうがいいんだろうなと思う。痕跡を残さなければならない。
- コンテナにしたときでも必要なんだろうか？このログをクラウドサービスに書き込めたらいいんかな？と思ったら、プラグインがあるそうな。
AmazonLinux2はauditdが標準でインストール済みだった。
- 実際にログを見た事が無かったので確認してみたが、sudoコマンドの実行が記録されていた。
- ログの保管とカスタムルールについては検討した方がよさそう

ホスト型侵入検知システム(HIDS)、rkhunter

ルートキットなどインストール時はよくよく気を付けなければいけない。
- 危険なのはそれなりの権限を持ったユーザーが、自分の手で導入してしまうケース。

ネットワーク侵入検知システム(NIDS)

先の高速道路の例で言うと交通管理隊の落下物回収・巡回のようなものだろうか。
ネットワーク関連、あまり気にしたことがなかった
- 敷居高そう
最大限の効果の為には各所にネットワークタップが必要
- 冗長構成とか倍々で増えていくんだろうな
  - でも安全には変えられないな…
ネットワークタップはfail-openなモードを備えたタップを選ぶ事
- 可用性の監視も忘れない事
- 確かにこれが障害点になってしまったら困るよね…

10章全体を通して

DDoSについてはレンタルサーバー・VPS問題でかなり話題になった（主にサポートの前提知識不足と対応内容についてという不名誉な内容ではあるが…）。
- 解決策として Cloudflareのの DDoS対策が用いられることも多いが、時代的にはそろそろ標準装備の対策になってもいいような気がする。
ちなみに最も基本的なセキュリティ対策は、恨みを買うような行動をしないことと、危ない場所に行かないことだと思っている。
- 危ない状況に遭遇しても直ぐに適切な判断を行うこと。
いくつかセキュリティを監視する仕組みはすでにあるが、実際うまく動いてくれているのかはよく分かっていない部分もある
セキュリティ監視をする上でセキュリティについての知識は必要不可欠
- どのような脅威があるか知る必要がある
- 以前読んだ「安全なWebアプリケーションの作り方」という本が、セキュリティについて多く書かれていてよかった

まとめ

今回はシステムを運用・保守していく中で、絶対に欠かすことのできないセキュリティの監視についてでした。セキュリティ対策は実施してはいるものの、実際に問題が発生した際のフローや確認箇所など、改めて再確認・メンバーへ周知する必要性を感じました。

今回の読書会も終盤に差し掛かってきました。読んできた内容を業務に活かせるよう、アクションを起こしていきたいですね。

2022-08-04

「入門監視」読書会レポート vol.9

読書会

株式会社リゾームシステム企画・開発部システム管理のあめぎです。

入門監視読書会の第9回目のレポートです。第8回目のレポートは、こちらになります。

tech.rhizome-e.com

入門監視 ―モダンなモニタリングのためのデザインパターン

作者:Mike Julian
オライリー・ジャパン

Amazon

9回目レポート

今回は、「9章ネットワーク監視」で、参加者は6名でした。

感想・意見交換

SNMP のつらさ

SNMPはセキュアではないプロトコルらしい
- 古いけど代替がなく使わざるを得ないケースがあるらしい
- 大変そうだ
デバイスが高負荷の時にはSNMPのエージェントの処理の優先度を下げる
- 一番知りたい時に情報が分からないらしい
  - これ本当に使えるの？理解できるが納得できない…！
SNMPv3では暗号化やユーザベースのセキュリティモデルを適用
- 基本はv3使えば良さそう
  - 負荷が増えたりサポートされていなかったりするので注意
- 2002年に発表されたバージョン3を未だにサポートしていないベンダーも多いというのは辛い
ネットワーク機器の監視（主に物理）をするには使っておいた方がいいのかな
- ハードウェア故障はめちゃくちゃ心臓に悪い　※経験談
OIDだと読みにくく分からないのでMIBを使って変換するらしい
- DNSみたいな感じかな
- 利用ハードルが高く感じる
  - 各ベンダからMIBを入手する
  - 必要に応じて最新のものを入手する
  - 最新にしたことによる影響は自分で調べる
インターフェイスのメトリクス
- 帯域幅（bandwidth）　⇒　理論値
- スループット（throughput）　⇒　実測値
- レイテンシ（latency）　⇒　かかる時間
  - オンラインゲームしていると気になるよね
- ジッタ（jitter）　⇒　バラつき
  - Teamsとか音声アプリだと気になるよね

構成管理

この辺りの考え方はネットワークでも変わらなそう
- Git や Ansible なんかも同じ
- ロールバックしたときの影響を考える必要があるような
ネットワーク機器こそ構成管理ツール使いたいよなぁと思う
- ルーティングテーブルの設計とかめちゃ気を遣う
- なかった時はメモ帳で残してたなぁ
ネットワークデバイスの構成管理としてRANCIDが例として上がっていた
- AnsibleでもNetworkモジュールがあるので同じことが出来そう
- https://docs.ansible.com/ansible/2.9_ja/network/index.html

音声と映像

QoSはCCNPの勉強してた頃に出てきた
- ストリーミング系の通信の優先順位を高くしてある程度の品質を保つとか
監視の要素としてはレイテンシ・ジッタ・パケットロスが全て
- もう1つ特に監視すべきことはコーデック

ルーティングプロトコル

ルーティングテーブルの設定はあってもデータが流れるかどうか見ないといかん
- ping打ったりtracerouteして予定通りの経路通ってるか確認してた
- このあたりはSNMPで見れるのか
ダイナミックルーティングプロトコルを監視しておくと便利
- 動的なものは通知してくれないとわからないものな
BGPって何だ...って思ってたら打合せで出てきた
- 「異なるAS間で経路情報をやり取りするときに使うルーティングプロトコル」だった
BGPの監視項目について
- シャーシのメモリ容量
  - メモリ使い切ったら処理止まるからか
- BGPピアの変更
  - 変わったのは気になるものなんだろうな
- ASパスの変更
  - 経路変わったら気になるものなんだろうな

スパニングツリープロトコル

ブロードキャストストームが起きないようにする
ルートブリッジの変更を監視
- なんで？誰が変えたの？というのは気になるものなんだろうな

本体の監視

アプリ性能はネットワーク性能を超えられない
CPUとメモリはカード単位で持っている場合もあるので注意という事らしい
CPUとメモリは他の章と同様メトリクスは取れる
- でもアラートはしないでよさそう
ハードウェアの監視こそ大事…再起動繰り返してたりとか…
- まぁ大体はベンダが監視ツールを準備しているとは思う
CPUとメモリの使用率からアラートを送信するのはやめておいた方がいい
- これはOSメトリクスの監視と同じかな

フロー監視

sFlow, IPFIX, NewFlowなどがある
- 帯域幅を大きく使っている活動やノードの監視・分析する
フローがわかれば帯域確保の優先順位とか変わるかなと思うのでよさそう
AWS は VPC Flow Logs　でみれたはず

キャパシティプランニング

必要なキャパシティを予測する時は過去のデータを活用する
- 未来を予想できるのは過去を知っている人だって誰かが言ってた…！
フロー監視がキャパシティプランニングに関係あるのかな？と思った

疑問・質問

「この辺りの話が分かると変更時や障害発生時に嬉しい」ということがあれば知りたい
- いつ　どこから（送信元）　どこへ（送信先）　何をしようとしたか（ポート・プロトコル等）が大事
AWSを使う上で必要な知識は？
- VPCのIPアドレス帯
- セキュリティグループ（ファイアウォール）

難解なネットワーク章・参加者の心の叫び

正直お世話になった事がない…
インフラ屋さんじゃないしあまりピンとこない…
ネットワークの用語を勉強しないと理解出来そうにない章
- New Relicでネットワーク監視出来そう
- https://docs.newrelic.com/jp/docs/network-performance-monito...
ちゃんとやろうと思ったら専業のネットワークエンジニアじゃないと無理じゃないかな
- 最近はインフラもクラウド化したり仮想化したりしている
知らないことすぎてなるほど...になってる
ネットワークについて知識が乏しすぎる
- やっと「3分間ネットワーク基礎講座」を読み始めた

漂う重い空気・気分転換として

参加者の好きなおにぎりの具
- ツナマヨ / 尾古（@patorash）
- エビマヨ / 萩原
- おかか / あめぎ
- 昆布 / 渡邉　平松
- 明太子 / 藤岡
この後すれ違った社員にも聞いたら「昆布」って言われました。人気ですね。

まとめ

今回のネットワーク章は、自分のレベルに合わせて調べたり、学習したりと各々課題を見つけ取り組んでいくものになったかと思います。勉強会では今回の様な難しい章も出てきますが、楽しく前向きに進めています。

次回は「10章セキュリティ監視」です。

読書会の題材

2回目レポート

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

Linux のインストール

ファイル操作

lsコマンド

cpコマンド

rmコマンド

ディレクトリの操作

pwdコマンド

cdコマンド

mkdirコマンド

rmdirコマンド

パス指定

ファイルの内容を表示

cat,more,lessコマンド

ファイルの検索

findコマンド

コマンドのパス

whichコマンド

ヘルプの使い方、マニュアルの使い方

helpオプション

manコマンド

まとめ

読書会の題材

読書会の進め方

1回目レポート

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

基本ソフトウェアと応用ソフトウェア

Linuxの特徴

まとめ

Ruby meets WebAssembly

Types teaches success, what will we do?

Tools for Providing rich user experience in debugger

Make RuboCop super fast

error_highlight: user-friendly error diagnostics

Real World Applications with the Ruby Fiber Scheduler

History of Japanese Ruby reference manual, and future

全体の感想

12回目レポート

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

テスト駆動開発と監視

自分で監視を作る

監視を育てる

自動復旧のためのアイデア

監視パラダイムの変遷

機械学習と異常検知

監視SaaSのまとめ

まとめ

読書会の題材

11回目レポート

感想・意見交換

ビジネスKPI

フロントエンド監視・セキュリティ監視・アラート

実践 監視 SaaS

監視SaaSの利点

監視SaaSは信用できるのか

まとめ

読書会の題材

10回目レポート

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

監視とコンプライアンス

ユーザ、コマンド、ファイルシステムの監査

ホスト型侵入検知システム(HIDS)、rkhunter

ネットワーク侵入検知システム(NIDS)

10章全体を通して

まとめ

9回目レポート

感想・意見交換

SNMP のつらさ

構成管理

音声と映像

ルーティングプロトコル

スパニングツリープロトコル

本体の監視

フロー監視

キャパシティプランニング

疑問・質問

難解なネットワーク章・参加者の心の叫び

漂う重い空気・気分転換として

実践監視 SaaS