RubyKaigi2022レポート

技術部第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

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に行きたい!という方が社内に増えてくれるととても嬉しいなと思っています。

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

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

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

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

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

tech.rhizome-e.com

読書会の題材

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

11回目レポート

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

感想・意見交換

ビジネスKPI

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

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

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

実践 監視 SaaS

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

監視SaaSの利点

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

監視SaaSは信用できるのか

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

まとめ

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

「入門 監視」読書会レポート 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アプリケーションの作り方」という本が、セキュリティについて多く書かれていてよかった

まとめ

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

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

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

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

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

tech.rhizome-e.com

9回目レポート

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

感想・意見交換

SNMP のつらさ

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

構成管理

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

音声と映像

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

ルーティングプロトコル

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

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

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

本体の監視

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

フロー監視

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

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

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

疑問・質問

  • 「この辺りの話が分かると変更時や障害発生時に嬉しい」ということがあれば知りたい
    • いつ どこから(送信元) どこへ(送信先) 何をしようとしたか(ポート・プロトコル等)が大事
  • AWSを使う上で必要な知識は?

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

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

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

  • 参加者の好きなおにぎりの具
  • この後すれ違った社員にも聞いたら「昆布」って言われました。人気ですね。

まとめ

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

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

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

株式会社リゾーム システム企画・開発部 第4グループの尾古(@patorash)です。

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

tech.rhizome-e.com

8回目レポート

今回は、「8章 サーバ監視」で、参加者は5名でした。

感想・意見交換

OSの標準的なメトリクス

  • メトリクスは取るが、アラートは設定しない。確かに狼少年になってしまう。数値ではなく、意味の方が大事。
  • 適切なインスタンスサイズを選ぶには、CPUやメモリの使用量を意識する必要がある。
  • topコマンドはよく使うが、freeコマンドは使ったことがなかった。topでもメモリの使用率はわかる。
    • オプションを使いこなさないと!
  • OOMkillerの呼び出しを監視するのは、なるほどと思った。
  • IOPSは下がったらディスクパフォーマンスに問題あり。
    • AWSだったらburst balanceを見ればいいはず。

SSL証明書

  • HerokuだとHerokuが面倒見てくれるので意識せずともよい。現在は特に監視していないが、以前はMackerelの外形監視でSSL証明書の有効期限を監視していた。
  • ドメイン更新・サーバー管理用のアカウントなども含め、お客様が契約した環境で動かす管理体制だと特にあるある。
    • 契約の段階でどちらがどこに責任を持つのかハッキリさせるのは勿論、通知が機能するようにチェックしておくことも必要。
  • 有効期限切れはゾッとする。特にワイルドカード証明書は範囲が広いので怖い。
  • SSL証明書の期限は監視しているが、更新方法がわからないのでやり方を共有してほしい。
    • => 読書会の後、共有されました。

SNMP

  • 使うのはやめましょう、と書いてあるので使うことはなさそう。

Webサーバ

  • ステータスコードが大事。エラーが起きまくっているとしたら、何かがおかしい。
  • 秒間リクエスト数やリクエスト時間を見る。
  • 大体エラーになってから問い合わせが入るので、事前に検知できて修正できていれば、問い合わせを減らせるかもしれない。

データベースサーバ

  • スロークエリは時々チェックしている。これはAPMツールを使っていたら教えてくれるからわかりやすいんだけれど、だからといってどう高速化できるか?キャッシュする等はよくやっている。
  • 実践ハイパフォーマンスMySQLはDB勉強会でもよく紹介されていたと思うけれど、普段PostgreSQLを使っているからあまりチェックしていない。
  • スロークエリはアプリケーション側の修正の話になる。
    • BulletでN+1は拾えているが、countよりsize、不要なオブジェクトを生成しない等、意識して行わなければならない。
  • RDSでクレジットが枯渇してIOPSが下がっていることがあった。
  • RDSを使っているならクレジットの監視もしたほうがいい気がする。
  • RDSだとPerformance Insights、New RelicだとAPMで遅いクエリを検出することができる。
  • DBのパフォーマンスチューニング難しい

メッセージキュー

  • ActiveJobのキューの数とかを見ればいいのかな?Sidekiqとか。
  • SC BASE *1 では帳票作成などの普通のJobに失敗すると、 Amazon SQS の デッドレターキュー (DLQ) から AWS Lambda に通知が行き、ログ保存した後に Amazon SNS を経て開発者向けの通知が飛ぶ仕組み。基本的にAWSに任せる感じ。

キャッシュ

DNS

  • 大昔に自宅サーバ立ててた頃にBind触ったなぁ
  • 自社では運用していない
  • Route53でほとんど運用している

スケジュールジョブの監視

  • バックアップが動いてなかったなどがあってはならないので監視すべきと。なるほど。
  • デッドマン装置は知らなかったが、タイムリミットを過ぎてもちゃんと動作していなさそうだったらアラートをあげる感じか?
  • BOND GATE *2 では、主にRundeckを使用
    • エラー通知はRundeckがやってくれるので便利
  • cronを使用している環境もある
    • エラーの監視が厄介
      • エラー発生→ログに出力→Mackerelでログ監視→エラー通知
    • ログを出力しないタスクもあるので、本に記載のような、コマンドがエラーになるとログを出力する方式はいいなと思った。

ロギング

  • syslogデーモンのドキュメントを読みましょう→はい。
  • ログをsyslogサーバに送ると二度と見なくなるからログ管理システムへ送りましょう。そうですね。
  • ログ分析にElasticStackが紹介されていた。取り組むかー。

まとめ

サーバ監視で何を監視したらいいか、メトリクスは取るがアラートは設定しない等、様々な学びがありました。結局はそのメトリクスの値に意味を与えるのは我々なので、メトリクスを取り、数値と向き合えということなのでしょう…。

SSL証明書の期限については、更新の仕方がわからないという話の後にすぐに更新の仕方が書かれているWikiのURLが共有されたので、非常によかったなと思います。

今回も監視するべき項目が明確になってきたなと感じました。

次回は「9章 ネットワーク監視」です。

*1: 売上管理業務をはじめとした、これからのSC運営に必要な機能を搭載した次世代SCクラウドサービス(ホームページ商品説明引用)

*2: BOND GATEは直観的で使いやすい、店長支援のためのSC・専門店向けコミュニケーションウェアです。(ホームページ商品説明引用)

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

株式会社リゾーム システム企画・開発部 第4グループの萩原です。

読書会の第7回目のレポートです。 第6回目のレポートは、こちらになります。

tech.rhizome-e.com

読書会の題材

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

7回目レポート

今回は、「7章 アプリケーション監視」で、参加者は5名でした。

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

メトリクスでアプリケーションを計測する
  • クエリの実行時間や応答時間以外に、何を計測するべきか。
  • アプリケーションパフォーマンス監視(APM)
    • そのままでも小綺麗な滝グラフ、それっぽいグラフは出るけれど、言われてみれば確かに。
    • APMを追加しだけでは何のコンテキストも把握していないというのは、そりゃそうだよなぁと思った。
    • 自分たちが計測したいものと向き合う必要がある。
  • 7章全体を通して StatsD の説明が多い。
    • StatsD を利用すれば、Logger などのように必要な箇所に追加しておくだけで良い。
      かなり細かい部分までデータ収集できそう。
    • 確かにメトリクスの組み込みは、病みつきになりそうな予感がした。
    • 自分たちのモチベーションに繋がるメトリクス取得ができると良い気がする。
      反応が得られないとやりがいを見出しにくい。
    • New Relic ではどう取り扱えばよいか確認しておきたいところ。
  • StatsD は聞いたことがない……。
    • CloudWatch エージェント、カスタムメトリクスでCPU使用率を取得していた。
    • 思い出すまでにいくらか時間がかかってしまったが、気付かないうちに恩恵を受けているのだな。
  • StatsD よりも Prometheus の方が良いという意見も……。
    • StatsDはドット区切りの記法になるので、書き方がバラける可能性がある。
    • StatsD が古株だからではないか。後発の技術の方が融通が効く。
ビルドとリリースのパイプラインの監視
  • パイプラインの監視・ログ出力は行っているが、得た情報を上手く利用できていない。
    • 現状、エラー時のトラブルシューティング程度にしか活用できていない。
      何かあった時に見る程度。
    • Webistrano でデプロイ情報を確認できるが、これらの情報を元に更に何かアクションを起こすことはない。
    • Heroku で誰がデプロイしたか記録されているし、Rundeck の方も時間の記録はされているが、やはり活用はできていない。
    • これやったの誰? が起きると困るから、誰が何をしたかも必要なんだろうなと。
      AWS では AWS CloudTrail がこれに当たると思われる。
  • デプロイ前後でアプリケーションがどう変わったかの監視は十分にできていないかも。
    • デプロイ前後で仕様変更にない部分に変化が発生したら異常ではあるが、問題はそれをどう把握すれば良いのかということ。
      メールやアラートの閾値を様々なものに付けるのは現実的ではないので、監視サービスのダッシュボードなどを流し見するような形になるのだろうか。
  • 本当に役立つのはアプリケーションやインフラのメトリクスと共に利用するメタ情報。
    • デプロイ履歴が監視サービス上で追跡できることは、パフォーマンスの向上・低下の確認や、障害調査時の原因特定に有用かもしれない。
    • 環境全体が動作しているかの確認は、どこに問題が発生しているか一目で分かるので便利。
  • メトリクスにデプロイタイミングをラベルとして付けておくと、その前後でどうなったかが一目瞭然で凄い。
    • New Relic ではデプロイによるパフォーマンス変化を追跡できるらしい。
  • SC BASE *1 では一部環境のデプロイに Rundeck を利用している。 現在進捗何パーセントか、成功・失敗したか、どのくらいの時間がかかったかが分かるようになっている。
healthエンドポイントパターン
  • ヘルスチェック用APIを作っておくのは良さそう。
  • 以前、バージョンとステータス一覧を表示させるページを用意し、異常を発見した場合は報告を上げるようにしようというやり取りをしたことがある。これを自動化するイメージかな。
  • エンドポイントにアクセスが可能なアドレスは限定する。
    • ですよね。その通りだと思う。
    • New Relic Synthetics の場合、IPアドレスが公開されている(Syntheticsモニター パブリックミニオンIP)。 これを利用してアクセス制限をかければOK(だと思う)。
  • 外形監視としてこのエンドポイントを利用しているが、よくある考え方だったのか。
    • ロードバランサーのヘルスチェックに使う一般的なURL名だと思っていた。
    • 確かにデータベースやデータストアにアクセスできなければアプリは使用できない状態なので、これらの情報もあった方がいいと思う。
  • データストアや外部APIを使用している場合これらも確認するとよいらしい。
    • やり過ぎるとエラーが返ってきた時に調査範囲が広くなってしまい面倒なような。
    • 複数のエンドポイントを用意するのがいいんだろうか?
  • 改めてHTTPステータスコードは正しく使おうと思った。
    そして構造化ログとして必要な情報をきちんと載せるようにする。
  • BOND GATE *2 では本で紹介している内容と同じく、データベースに接続して1レコード SELECT し、成功すればHTTPステータスコード200を返す処理を行っている。
アプリケーションロギング
  • syslog 正直あんまりよく分かってない。rsyslog もよく分かってない。
  • Ruby on Rails の Lograge が紹介されていた。
    デフォルトの production.log は見にくいので、導入しても良いかもしれない。
  • Ruby on Rails の複数行にまたがったログを、まとまった情報として見られるようになればいいのに。
  • ログ出力する場合は、ログをパースしていい感じに表示する環境・サービスがあれば、そっちの方がいいのかもしれない。
メトリクスにすべきか、ログにすべきか
  • ログエントリとして情報をデータベースに保存しておけば、後からこれらを加工・統計処理して使用することも可能なように見える。
  • メトリクスの方が良い場合とは?
    • メトリクスの方がシンプルだが、いくつも送るようならログの方が良さげ。
何のログを取るべきか
  • 何でもかんでも取りましょう! でなくて良かった。
    • 書いてあることにほぼ同意。
      ツールの問題なら一次情報を多く保存しておいた方が良いと思う。
    • 問題があった部分を探す時間を短くするためにも取捨選択は必要。
      ログが肥大化してしまい、拾ってこれない・検索しづらい状況はある。
    • 必要なログを選定するためにも、目的を見失わないようにすることが大事。
      ログを取得することばかりに気を取られるのではなく、ログの中身を見ておかないといけない。
    • 今までは障害発生時にアラートを出す意味で監視していたが、この本を通じて他の意味を持つログを出力する重要性も理解した。
      一方でログ出力にも一定のコストがかかる訳で、単に量を増やすのではなく、必要なログを必要なだけ取らないといけない。
      これは程度の問題になるので判断に迷うところではないだろうか。
  • 俺たちは何を取ればいいんだ?
    • ログインにかかる時間の計測から少しずつ追加していけば良いのではないか。
    • BOND GATE であればバッチ処理の時間? Rundeck で動かしているので取得はできている。
      例えば日付単位のメトリクスを New Relic 上で確認できるようにすれば、日に日に遅くなっているかを確認することができるようになるのでは。
    • 時間のかかる処理、失敗しやすい処理には、細かめのログがあった方がいいのかもしれない。
      失敗した場合に画面やデータベースを調査しないと分からない状態だと、気付くにしても調査にしても時間がかかってしまう。
  • BOND GATE では操作ログを取っているので、調査する時など便利ではある。
    問題はデータ量が多すぎる点。迂闊にSQLを投げることができないし、ディスク容量を圧迫するので何とかしたい。
ディスクに書くべきか、ネットワーク越しに送るべきか
  • ログをディスク上のファイルに書き込む方が良い。
    定期的に外部にデータを送る機能があるサービスも組み合わせられる。
    • Logstorage を利用しているプロジェクトを見たことがある。
    • ログの転送・AWS S3 での保管対応を行ったことがある。
      ログサイズが大きすぎるとフローの途中で詰まることがあり、小さくすると今度は AWS S3 に分割されたログが出力されて料金コストがかかる結果に。
    • 1ヶ月程度の期間、New Relic 上で確認できるようにしておくのが良さそう。
  • データベースに保存しておくと、データ中継やバックアップはしやすそう。
    • NoSQLデータベース? Elasticsearch?
    • データベースバックアップにかかる時間や、データベース自体の容量が増えそう。
    • Django Admin が管理画面の操作ログを取得しているが、ログの量が膨大なため Heroku の無料枠を超えることも。一長一短はあると思う。
マイクロサービスアーキテクチャを監視する
  • マイクロサービスは監視の問題も含めてだが、先進的過ぎるような気が。
  • サーバレス・マイクロサービス・分散トレーシングは、そもそもよく分からない……。
  • 分散トレーシングの仕組みは理解できるが、実際の実装・設定はリクエストIDの受け渡しが常に付いて回る訳で。
    • AWS X-Ray や New Relic のようなサービスを利用するのが良いんだろうか。
  • Zipkin は勉強会で聞いたことがあるけれど、マイクロサービスから縁遠い生活を送っているので、どこの世界の話や……みたいな気分だったのを覚えている。
  • マイクロサービスにすると1つ1つはシンプルだけど、異なるところで複雑さが生まれてくるよなぁ……と思う。
  • これもまた慣れの問題かもしれない。Zipkin に慣れていたら、どうということはない的な。でもやっぱり複雑。
  • マイクロサービスアーキテクチャの採用は、成熟した組織でないと厳しいのではないだろうか。
    • 技術選定や設計の段階からモノリシックなアプリケーションとは異なる。
    • 新しい技術に臆さず知識を吸収していけるようなスキルは必要に思う。

まとめ

healthエンドポイントの利用やStatsDによるメトリクスの取得など、あまり『監視』を意識せずその恩恵にあずかっていたようです。
既製のサービスをそのまま利用していると、自分たちが計測したいこと・アプリケーションのコンテキストを反映せずに使用してしまうことも……。今後は『自分たちのアプリケーションでは何を監視したいのか・監視すべきなのか』を更に意識して利用していきたいと思います。

エンドポイントによるヘルスチェックや、ログの収集・送信など基本的な部分はどのプロジェクトも問題なく実施できている様子。 今の方法が基本から逸れていないことを再確認できました。

一方で取得後のデータを活用し切れていないのではないか、という課題も浮き彫りになりました。 リリース後のパフォーマンス追跡、操作ログの管理方法など、当書を通じて改善すべき点を見出すことができました。

次回は「8章 サーバ監視」です。

*1: 売上管理業務をはじめとした、これからのSC運営に必要な機能を搭載した次世代SCクラウドサービス(ホームページ商品説明引用)

*2: BOND GATEは直観的で使いやすい、店長支援のためのSC・専門店向けコミュニケーションウェアです。(ホームページ商品説明引用)