「入門 監視」読書会レポート 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・専門店向けコミュニケーションウェアです。(ホームページ商品説明引用)

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

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

読書会の題材

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

6回目レポート

今回は、「6章 フロントエンド監視」で、参加者は6名でした。

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

フロントエンドのパフォーマンス・監視について
  • フロントエンドのパフォーマンスについては気にはしているが、監視をするという考えはなかった。
  • JavaScriptはbody閉じタグの直前で読み込め」とか、「CSSはheadで読み込ませるけど書く場所はなるべくまとめる」とか、「アセットパイプラインで全部ひとまとめにしてやる」とか、「なるべく圧縮した方がいや使用頻度が高いならCDNを使え」とか、そんな話もあったなどと懐古。
  • 以前はチャッチャとできるくらいは高速化に取り組んでたりしたけど、そっち専業ではないので、最近はあまりキャッチアップできてない。
    • PageSpeed Insightsを使ったりしていたくらい。
  • 去年やった社内ISUCONを思い出しつつ読んだ。当時はN+1の改善に注力していたが、画像サイズが大きいとかの問題もあったな。
  • ゴール=動き続ける×=素早くロードされる○
遅いアプリケーションのコスト
  • 早くすることでページビューやコンバージョンの改善につながるというのは、そうだろうなと思う。
    • やはり「遅いから使いたくない」とか言われたら負けだと思う。
  • フロントエンドのパフォーマンスチューニングは、沼なので、ずっとそればっかりやってもいられないのだが、頃合いを見ては取り組む、というのはやっていくべきだろう。
  • ECサイトはパフォーマンスの影響がかなり大きそう
    • 人によっては買い物でストレス発散したりするぐらいだから。(ECサイトが遅く)気分が良くないと買い物する気にならなそう
  • 担当サービスでも、ページ表示が遅いと言われることがある。
    • ほとんどはSQLが遅いので、改善できる箇所は積極的に改善していきたい。
  • 遅い事が悪いと直感的に理解している
    • 調べ物してて読込遅いサイトに行くと、すぐ別のサイトに切り替えるなあ
DOM
  • scriptタグがあると、そこでDOMのパースを停止してしまう。昨今は、async属性をつけて非同期にロードすればいい。
    • なるほど。やってたような。
  • 大量のscriptをロードせずに、少しにしたほうがよい、と書いてあるが、最近は多分事情が違って、HTTP2やHTTP3を使って小さいファイルを並列でロードしろっていう方向だと思う。
    • webpackでよく「JSのファイルサイズがデカすぎるよ!」て警告出てるし。1つのファイルにするのって、ファイルサイズが大きくなるため、初回ロードがかなり遅くなる。2回目以降はキャッシュが効くからいいんだけど。
    • 昔はJSをモジュールにできなかったのでバンドルせざるをえなかったが、モダンブラウザだとデフォルトでimportをサポートしているものもあるので、そろそろバンドルするなっていう流れになるんかなとか思う。
  • Reactの仮想DOMとjQueryのDOM操作のように、同じDOMでもライブラリによって仕組みが違うこともある。
パフォーマンスのメトリクス・監視/計測サービス
  • Google Analytics、名前はよく聞くけど、何かは分かっていない...
  • Google Analyticsアクセス解析などの目的で用いるものというイメージが強かったが、調べてみるとサイトの速度などフロントエンド側のデータ収集や可視化なども行ってくれているようなので、下手に自分であれこれするよりは任せてしまった方が良いと思われる。
  • Navigation Time API
    • 開発者ツールのネットワークタブに出てくるあれかな。
    • 使い方はあまり理解していないので確認する。
  • Speed Index
    • B-PARKのサイト作成の時に色々確認してた
      • 特にホーム画面のところが重かったからlazysizes導入してページ下部の写真は遅延読み込みさせたりした
  • PageSpeed Insightsなどの計測サイトは利用したことがあり、指標の部分にSpeed Indexも出てくるが、その程度の利用。
シンセティック監視
  • 単なる外形監視ではなく、サービスのロード時間とか表示時間とかをビジュアルで教えてくれるっぽい。WebpageTestを軽く動かしてみたら、そんな感じだった。
  • パフォーマンスへの影響をCIで計測できるのは便利
  • 自動テストで継続的にパフォーマンスを測定するのはありだと思う。

まとめ

フロントエンド側のパフォーマンスについては、過去に実施した手法や教訓の話、PageSpeed Insights等の計測サイトを用いたパフォーマンス計測の話が挙がりました。
継続的な監視・パフォーマンス計測については、あまり実施できていませんでしたが、Google AnalyticsやNew Relicを用いたログやメトリクスの取得・CIでの計測等、実践できそうな様々なヒントを得られることができました。
また、(主に私が)Google Analyticsについてあまり詳しく知らなかったのですが、実際にGoogle Analyticsを使用している例を見せてもらい、活用方法や取得できるメトリクス等について知ることができました。

次回は、「7章 アプリケーション監視」です。楽しみですね!

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

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

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

tech.rhizome-e.com

読書会の題材

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

5回目レポート

今回は、5章「ビジネスを監視する」で、参加者は5名でした。

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

ビジネスKPI

  • KPIはメトリクスって言われたら確かに。
  • これらのメトリクスはサービスを作るときに取得できるように設計しておかないと、次の打ち手を考えるときのデータがない。
  • 月次での推移とか作ってみたら良さそう。解約数とか、アクティブユーザー数とか。
  • 結局、お客様が儲かるシステムを作らないと、現在進行系で困るし先も続かない。
  • お金について語れると強い。
  • 「お客様は喜んでいるか」これを開発側が意識する機会が不足している。
  • ビジネスKPIを確認できるダッシュボードがあれば開発以外の人がよく見てくれる場所になるかも。
  • ビジネスKPIになるうる指標は営業と開発の橋渡しになりそう
ネットプロモータースコア
  • ツールやアプリを使用している時やアンケートで出てくる問いにはこのような意味があったのか。
    • この手のコストが関与しないアンケートが、どの程度信頼できるデータなのか疑問に思っている。
  • アプリを使っていて「評価してね」って出るのはこれの関係か。
  • NewRelicだとApdexスコア?
  • 開発としてもどこに満足しているかなど知っておきたい
顧客生涯価値(LTV)
  • これはSC業界でやっていそうな視点
顧客獲得単価(CAC)
  • SC BASE*1だと、お客様の環境へ導入するまでに、一定の期間やコストがかかっている話は度々聞く。
    • それは現在の運用を補うための機能追加や修正コストであったり、関わる人数が多く施設全体への周知コストがかかるであったり、導入時の機器設置や初期設定であったり。
    • これらを集計・グラフ化する術というのはあるのか。数字としては出ていそう。
  • 契約が増えればいいというわけではない
    • 採算が取れるかという意味でも大事だと思う
ランレート
  • 貯金残高を月々の支出で割って一喜一憂するあれの会社版だろうか。
    • 円安の影響なども考えると実際の計算はより複雑そう。
アクティブユーザ数
  • ユーザ数に加えて、いつ使われているか、どの機能を使っているかなど詳細がわかれば開発や改善の優先度を決めやすい

2つの事例

  • 事例から想像できるだけでも、いろんなメトリクスが取れる。
    • SC GATE*2で考えてみると、検索実行回数、各機能のビュー数、アクティブユーザー数、Excel出力回数(機能ごと)とかはいけるかもしれない。
  • もしページ毎のアクセス数や操作の流れを集計・分析していれば、客観的な数字から改善点を求めることができて良いのでは。
    • ある操作をメニュー経由で頻繁に繰り返しているなら、ショートカットを設置するだけで便利になる可能性があるなど。
  • 気づきを得るための監視。
    • 正常よりエラーをよく見たり、エラーとユーザー利用の相関性を見ることが大事
  • BOND GATE*3だと、ショップのログイン回数や各機能のアクセス数とかのメトリクスを取るのが良さそう。
  • Google Analyticsでいろいろわかる

ビジネスKPIを技術指標に結び付ける

  • レイテンシをつけておくのは良さそう。
  • 失敗率やレイテンシに関するメトリクスも重要、なるほど。
  • ここで言われている失敗率は何を含んでいるのか
    • ユーザー側の設定ミスなども含めるのか等

自分のアプリケーションにそんなメトリクスはないという時は

  • ないなら作れってことだよな...
  • 出すように変更しましょう

会社のビジネスKPIを見つける

  • ビジネスKPIを定義して、社員がいつでも確認できるようにしてみたい
  • スプリントレビューで責任者とリーダーが隔週で3時間割いてくれるので、各々の情報や知見の共有もできている。
  • 専門外の人と話をするというのは大事だと感じた
    • どうしても枝葉の方ばかり気にして議論してしまうことがある
    • 広い視点を得るためには専門外の人と話すのが良い
    • 大事な見落としにも気づくはず

まとめ

ビジネスの観点から監視を行うという内容で各々ツールやアプリを使っていて経験したこと、また担当しているサービスに絡めた話などで議論しました。 この章では事業責任者からの質問に答えるための方法を学ぶというものでしたがこれらの知識を得ることで開発側から経営層や営業へのアプローチも可能になってくるのではないかと思いました。
開発者という立場からビジネスについて考える機会があまりなかっただけに今回の読書会は会社のビジネス面に対して開発側ができることについて深掘りすることができたのではないかと思います。
次回は「6章 フロントエンド監視」です。

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

*2:全国のSC・百貨店5300施設、24万ショップ、10万のショップブランド、4万のショップ 運営企業等の情報を搭載したSC&ショップ検索サービス(ホームページ商品説明引用)

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

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

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

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

tech.rhizome-e.com

読書会の題材

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

4回目レポート

今回は4章「統計入門」で、参加者は4名でした。

それぞれの感想

システム運用における統計を学ぶ前に
  • アラートが鳴りすぎるのは良くないので、フラッピング検出によるアラート制御が害悪か判断しかねる。
計算が救いの手を差し伸べる
  • 過去のログも記録する、統計を見て何か掴む。
  • AWSを使って過去ログを記録するのが当たり前になっていた。使いこなせてるかは別。
統計は魔法ではない
  • 恣意的な統計の使い方をすれば、必然そういう数字が誇張されて出てくる。
  • 計算方法の選択や実際の計算を間違えることも考えられる。統計を道具として使うなら、プログラミング同様、理解してから使わないといけないのだろうと思う。
移動平均
  • スパイクを無くして傾向を見やすくするのはよい。
    スパイクが見えなくなるという欠点はあるので、データの蓄積をしておくことが大事。
  • 移動平均は全体のおおまかな値の変化を確認するのに便利そう。
  • 多用している気がする。
中央値
  • よくある例は年収、こういうケースだと平均は役に立たない。
  • 他にどういう時に使えばいいかイメージがわかない。コア層の把握?
周期性
  • パターンを見て、いつもと違う場合は何か気づくことがあるかも。
  • 周期性を見て、対策するべき時間帯とか考えていくのも大事だなと思う。
  • *1BOND GATEは日単位で見ると朝、(昼)、夕方にWebリクエスト多め。週単位だと金曜日が多めの環境もある。
  • 毎日眺めて、初めて得られるものの気がする。
分位数
  • あまり馴染みのない数値。
  • Herokuのメトリクスページにレスポンスタイムの分位数が表示されている。
  • 外れ値を無視して基本的な性能を表してくれるので、中央値の金持ちがいないケースにするって感じかな。
  • データの大部分の傾向は分かるが、ある程度のデータは捨てられるので、平均値出すのは駄目。
標準偏差
  • 正規分布している場合しか信用ならないので注意。
  • 監視ではあまり使わないほうがいいということが分かった。
章のまとめ
  • あまり実数ばかりを見ていても分からないことがあるので、ふんわり傾向を掴むことが大事だなと思った。
  • データポイントに上限下限があるか確認しよう。閾値を考える時に意識したい。
  • ディスク使用率・使用量、両方あるけど、どちらを監視すべきだろうか。
    => 両方監視するべきだと思う。

まとめ

実際に、Herokuのメトリクスを開いてレスポンスタイムの表示確認や利用シーンについて議論しました。
また、MackerelやNewRelicで各製品にどのような周期性があるか確認し、傾向を知ることが出来ました。
これらの統計値を上手く使って、改善出来ればと思います。

次回は「5章 ビジネスを監視する」です。

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