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

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

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

読書会の第3回目のレポートです。 第2回目のレポートはこちらです。

tech.rhizome-e.com

読書会の題材

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

3回目レポート

今回は3章「アラート、オンコール、インシデント管理」で、参加者は6名でした。

それぞれの感想と議論まとめ

どうしたらアラートをよくできるか？

アラートのメール通知は反対派多数　※参加者全員

• 誰も叩き起こせないし、スルーしてしまう可能性も高い。SMSに送るのはよくある。
• 一般的な使い方は「期限に余裕があり、期限までに目を通していればいい」「届いていない・見ていない可能性も許容する」
• メールボックスに張り付いているのも、緊急度の高いメールが届いていないか気にするのも疲れる。
• RundeckのJob失敗はメール通知しているが、確かに埋もれてしまう事がある。
• 業務関連のメールと混ざると読まない。見落とす。うんざりする。

手順書を書こう

• 最近バッチ処理失敗時の対応手順書を作成した
  • 作成して共有することで誰でも対応出来るようになったと思う
• 今は設定ファイルがそのままインフラ構成・依存性を表す絶好の資料になっている（DockerfileやCloudFormationなど）
  • ない時代は大変だっただろうなと思う
• よい手順書は質問に答えるように書かれたもの
  • ここまで丁寧に実際かけているのか？
  • 書けた覚えがない…気を付けたい
• 作れていない手順書は正直ある…

固定の閾値を決めることだけが方法ではない

• 使用量の変化量を監視するのはいいかもしれない
• 今朝もメモリの使用率が閾値を超えているアラートが来た
  • サービスの性質上、ある時間帯になると利用増えるので超えるのは問題ないかなとは思う
  • 変化量でアラートを作るのも難しい
  • ディスク使用率は変化量を見るのも良いかもしれない

アラートを削除し、チューニングしよう

• なんのために監視をしているのかの定義の見直そう
  • オオカミ少年のままにしない強い意志が必要
  • 自動復旧ができるからk8sとかが流行ってるのかもしれない
  • アラートは自動復旧に失敗してからでよい
• CPUやメモリ使用率がある値を超えるとアラートを発信している
  • 特にアクションもしていないので減らしてもいいかもしれない

メンテナンス期間を使おう

• SC BASEでは本番メンテナンス前にMackerelの外形監視を時間指定でミュートしている
• メンテナンスモードにしないとデプロイ出来ない仕組みを入れた事があった
• 静観してくださいって連絡をする事があった
  • アラートをミュートしていたのか

まずは自動復旧を試そう

• delayed_jobが落ちたら自動復旧と同時にアラートが鳴る
  • 自動復旧に失敗したらアラートの方がいいなと思った
• 基本は何かを見つけて再起動！
  • サービス維持に繋がるならシンプルでも立派な自動回復なのか！
  • オンプレの古い機器を無暗に再起動するのは怖いからほどほどにしよう

オンコール

• 月に2日程度休日に担当になる
  • 昔はCPUやメモリ使用率のアラートも保守端末に届いて落ち着けなかった
  • 最近は問題が起きることは少ないので精神的に楽になった
• オンコールローテーション。ここの組織デザインが大事。
  • オンコールは精神を削る
  • お酒も飲めないし（お酒が好きな人は…）出かけるのも難しい
• オンコールの内容を次の週の会議に取り上げる計画を立てる方法は重要だと思う

誤報を修正する

• アラートを整理してチューニングを行うというのは改善手段として優れていると思う

無用の場当たり的対応を減らす

• 「触らぬ神に祟りなし」的な対応をしてしまうこともある
  • お金と要望がない限り修正できない契約パターン
  • 仕様や実装経緯が不明
  • 監視・開発だけでなく体制を整えることも大切
• 監視は修復してくれない。直すのはあなた。その通りですね。

インシデント管理

• 緊急時の対応マニュアルは必要
  • いざというときに組織としてどう対処していくか
  • 会社全体や法務としてどう対応するかもあればベスト
    • 場合によっては情報漏えいなども絡んでくる
  • アラートでチケットの自動作成までは出来ていない
    • 記録漏れのないように改善していきたい
• 現場指揮官・スクライブを関わらせないのすごく大事
  • 特定の誰かが全部やっている状態では、客観的な記録が残らなかったり、コミュニケーションが歪んだものになる可能性がある。
• コミュニケーション調整役はめちゃくちゃ大事
  • まさにコード書いて直してる人はそれに集中するべき

社内の課題は？

• すべてのアラートをPCメール・携帯メール・Teamsに送りがちなのでいいようにしたい
• どのような監視・アラートがあって、どこに通知されているのか・通知する必要があるのかを整理したい
• アラートが混在しているので良くない（システムの利用に影響のあるアラート・影響はないけど注意は必要なアラート）

事例・アイディア など

• SC GATEではTeamsに送られるようになっている
• 注意が必要だがすぐにアクションが必要でないアラートは社内チャットにしよう
• 手動復旧じゃなくて自動復旧にできるものはしよう
• 調査の仕方を手順書に書いておく
  • ネクストアクションが書いてあるといい
    • papertrail / bugsnag / Mackerel / New Relicをみてみましょう
    • 判断できるかはわからないけれど、見てみたら、いつもと違う何かがあるかもしれない。

まとめ

アラート、オンコールについてはメンバー各々思い当たる事があったようです。 どうすれば互いの負担を減らせるか、良い体制を整えられるか意見を交わせるよい機会になったように思います。 アイディアも出てきましたので、少しでも取り入れて改善していきたいですね。

次回は「4章　統計入門」です。

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

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

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

tech.rhizome-e.com

読書会の題材

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

2回目レポート

今回は、2章「監視のデザインパターン」で、参加者は6名でした。

それぞれの感想

組み合わせ可能な監視

• UNIX哲学「一つのことを、うまくやれ」
  • ここでもUNIX哲学が出てくる。
  • 改めて監視に当てはめて聞くと、なるほどと納得した。
  • 聞いたことはある(が、内容を理解はしていない……)。
• 専門的なツールを組み合わせる方が、複合的なツールを扱うよりいいのかもしれない。
  • 個別にも使えるし、組み合わせても使える。一つだけ乗り換えることもできる。
  • 必要なものだけ使用することで、無駄を省くことができる。
    ただ、どんな監視が必要かを明確にしておかないと持ち腐れになってしまう。
• Elastic Stack が正にこれ、やはり気になる。

監視サービスのコンポーネント

データ収集

• 最近の主流はプッシュ型でしょう。
  • プル型では監視対象の増減管理などが面倒そう。
    プッシュ型であればデータをプッシュしなくなるだけなので楽そう。
  • スケールしやすいメリットも、クラウドサービスを利用しているなら重要。
  • 送りたいものが送りたいところに送る自発的・合理的なツール。便利そう。
• BOND GATE*1 では、以下を利用している。
  • 外形監視としてプル型
  • インフラ等のメトリクス取得にはプッシュ型

メトリクス

• 「カウンタ(Counter)」
  • CPU使用率・メモリ使用率
• 「ゲージ(Gauge)」
  • アクセス回数・ログイン回数
• HDD使用量はゲージっぽさがあるけれど、カウンタの役割にも似ている。
  Nヶ月後に80%超える的な予測ができる。

ログ

• 非構造化ログが普通と思っていたが、JSONで出力すればいいのかと気付かされた。
• JSON・キーと値のペアなど、ログが見やすい。
  • 追加したキーの分ログサイズが大きくなるデメリットはあるが、ログが読みやすくなるメリットにおいて勝る。
  • 考えれば考えるほど、JSON出力して Elasticsearch に食わせて Kibana で検索すればいいのでは……。
• Webアプリを作成する視点から見ると、構造化ログの取り回しが良さそう。 非構造化ログだとコンソールのように出力するか、構造化ログに直してから使用するか。
• BOND GATE では、Nginxログを Elasticsearch + Kibana で閲覧するためLTSV形式で構造化している。 New Relic でもログを見やすく改善したい。

データストレージ

• 「メトリクスの間引き」
  • ログの量もバカにならないため、間引くというのはなるほどなと思った。
    確かに過去のCPU使用率など細かく見る必要がない。
  • 料金コストがもったいないので、運用ルールを作成し削除を行うようにしたい。
• 必要なものはどれくらいの周期で見るかをきちんと考える必要がある。
  毎分見る必要ないものなど当然ある(CPU・HDD空き容量)。
• Webアプリが出すログにはデータベース保存・ログファイル出力・直接Amazon CloudWatchに送るなど種類があるが、 どれが監視の場面で使いやすいかをあまり考えずに、デフォルトで使っていることが多い気がする。
• BOND GATE では、ログを Fluentd で Amazon S3 へ転送・バックアップしている。

可視化

• 価値あるダッシュボードとは？
  • あまりダッシュボードを使ったことがなかったので気になる。
  • 何を見れるようにすればいいのか分からなかった。何を見るべきかを学びたい。
  • Tableau などのデータ可視化ツールは、これにあたるのか。
• Service Level Agreement(SLA, サービス水準合意)
  • 可用性をあげるのはAWSをもってしても難しいので、ほどほどにしておけという話。
  • SLAが出せるのは、アプリケーションの稼働率が算出できるから。 これ以外の目的・場面でどのように監視で得たデータを利用していけば良いのだろうか。
• 自分でダッシュボードを作るのは難しい。
  • 何をダッシュボードに表示させるべきなのかが、よく分からない……。
  • 何のデータを欲しているか、正しく分析出来ていないからか。
  • 機能ではなくデザインを追求して、余計なことをしてしまうことはよくある。
    作る側は綺麗に色々なグラフを並べたくなりがち。監視という目的を忘れないようにしたい。
  • New Relic のデフォルトのダッシュボードで十分な気もする。

アラート

• 「何か問題がおきた時にアラートを出すことが監視システムの目的だと信じている」
  • 何か問題が起きた時にアラートを出すことが監視システムの目的、ではないのか？
  • どうしてもWebアプリの範囲しか見えていないと、障害やエラーへの対処と紐付いてしまう。
    もちろん開発中に明らかに時間のかかる処理などはパフォーマンスを確認するが。
• 「監視は、質問を投げかけるためにある。」
  • 分かるような、分からないような……。
  • CPU使用率が高いからといって問題とは限らないとか、高い原因を探るための判断材料とかいうことだろうか。
• アラートには、本当にまずいアラート・気付きのあるアラートの2種類が存在する。
  • 運用的にはセーフだが気付きのあるアラートを作ることも大切なのではないか。

ユーザー視点での監視

• ユーザーから監視するとはどういうことか？
  • とても大事な視点。監視のスタートはお客様からだったか。
  • 真っ先に浮かんだのは外形監視。まずはアプリケーションが動いているかどうかが重要。
  • どの機能がよく使われているか分かれば、サービス改善の順番を考えるのに使える。
  • 時間帯別のアクセス数がわかれば、スケールアウト・スケールイン戦略を立てることができる。
    常時同じスペックのサーバを動かすよりはコスト削減に繋がるだろう。
• サービスを継続させるための監視なのに、ユーザー視点を度外視していたら、それは監視と言えないのでは。
• 「HTTPレスポンスコード(特に HTTP 5xx 番台)」
  • New Relic APM でデフォルトのダッシュボードに表示されるようになったので見ようと思う。
• 監視ツールの具体的な活用方法が見出だせないでいる。
  • リクエスト時間、ページの表示速度などたまに見るが、そこから発展して何かするとかはあまりない。
  • 結局障害発生時しか見ないので、常時監視ツールを開いておく必要があるかどうか。

作るのではなく買う

• 監視ツールの設計・作成による恩恵をどう捕らえるか。
  • SaaS によるアウトソースを行うことで、溜まりにくい知見もあるのではないか。 確かに直接売上をもたらさないかもしれないが、運用スキルは上がるのではないか。
  • これらの経験を踏まえた上でコスト面・監視対象を考慮に入れたSaaS選定ができるようになれば次に繋げていくことができる。
  • クラウドサービスを利用した方が良いという結論も、 共有のレンタルサーバ・VPS・自宅サーバの運用経験しているからこそ出てくるものだと思う。
  • 優先順位の問題ではないか。車輪の再発明や自作ツールの作成により技術を高めるか、 自社プロダクトの専門分野に特化した開発に注力するか。
• SaaS にしても詳しい人が必要になるので、コスト削減に繋がるかは疑問が残る。
  • メンテナンスコストを考えれば理解できるが、他のコストについても考慮に入れるべきでは。
  • メンバー全員に対して教育コストがかかると考えると、既製ツールを使っても結構なコストになりそう。
• 監視の仕組みが成熟していない時は買い、システムがツールを超えて成長してきたら何かに特化した自作ツールを作る感じ。
  • 現状は、監視のサービスを使って基礎を整える段階っぽい。
  • 監視ツールはSaaSやOSSをそのまま使う形にしがちだが、あるところまではこれでいい、ということが分かったのは大きい。
• 安いしどんどん便利になるし導入も簡単です使いなさい。
  • はい。
• 自分達で構築するよりはSaaSを使うか、出来の良いFOSSを使う方がいい気はする。

継続的改善

• 「継続は力なり」
  • 常に監視を行う習慣を身に付けるとともに、設備や環境も整えていかねば。
• ふと「コードと向き合い過ぎてませんか？　サービスと向き合えてますか？」という問いが頭に浮かんだ。
• インフラやログは一度作ると、動いているうちは更新が滞りがち。
  バージョンアップは大前提だが、より良い機能が増えたなら活用するなど、常に良い監視ができるように改善するようにしていきたい。
• 完成と思わない、変わるのが前提。
  実用性重視で取り組むのが良いのだろうなと感じた。
• 段階を踏んで監視を変えないと、仕組みが整ってない状態で進んでしまい失敗する。
  とりあえず、変えてみたになる。

意見交換

「価値あるダッシュボード」とは

Q.「価値あるダッシュボード」とは何か、具体的なイメージが掴めていません。
これまでの業務で行ったカスタマイズ事例などがあれば知りたいです。

A.New Relic APM のダッシュボードを眺めつつ、備わっている機能の確認やダッシュボードについての議論を行った。

• New Relic APM を見てみる。
  • CPU利用率がスパイクしている部分を拡大。
  • 遅いクエリのリストを確認。
• ダッシュボードのカスタマイズについて。
  • 複数のダッシュボードを作ることはできる。
  • プランや仕様によってはダッシュボードに表示できないものもある。
  • 見たい情報をダッシュボードに集めるようにすれば、それが「価値あるダッシュボード」なのでは。
• 開発者・営業・サポート・ユーザー視点など、様々なダッシュボードがあるのでは。
  • 開発者にとって遅いクエリの情報は重要だが、営業には不要。
  • 同様に立場や仕事内容によって、必要な情報は異なる。
  • こういった監視方法もユーザー目線の監視なのかもしれない。
• アクセス解析は広義の監視と捉えても良いのではないだろうか。
• システム利用率が低下したときにアラートを出してはどうか。
  • 疑問をなげかけるアラート。見る価値がありそう。
  • カスタムメトリクスでログイン回数を集計し、ログイン率が低い場合にアラートを出すなど。
  • アクティブユーザー数を分析することで、事前に何らかの対策を打つことができるのでは。 営業視点で考えれば減少というのは大事な事象なので、共有した方がいいかもしれない。

まとめ

現在の監視体制はデザインパターンに即したベストプラクティスなのか、開きがある部分はどのように業務に取り入れていったらよいか、あるいは今はまだ取り入れない方がよいのか。

取り扱うプロダクトはメンバーそれぞれですが、監視という共通の括りで感想・意見交換を行う中で、具体的な改善点が見えてきたようです。

まだ合点がいかない部分も疑問が残る部分もある状態ですが、「第Ⅰ部 監視の原則」もやっと半分というところ。読書会を進めていく中で知識を得、より理解を深めていければと考えています。

次回は「3章　アラート、オンコール、インシデント管理」です。

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

ファイルを読み込んで長い文字列を処理する方式からIOオブジェクトで処理する方式に変えたら10%高速化した話

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

弊社で扱っているシステムで、複数のgzip圧縮したファイルを読み込んでDBにインポートする処理がありました。今回はそれのリファクタリングを行い、10%ほど速度改善した話です。

リファクタリング前の処理

リファクタリング前は、ファイルの内容を読み込んで変数に入れた後、インポート処理を行っていました。そのインポート処理においても、巨大文字列を1行ずつ読み込んで処理するようにしてありました。

file_path = Rails.root.join('files', 'import_file.jsonl.gz')
contents = Zlib::GzipReader.open(file_path) do |gz|
             gz.read
           end
ImportFile.import_from_string!(contents)

class ImportFile
  class << self

    # 文字列からデータをインポートする
    # @param [String] contents 改行コード区切りのJSON文字列
    # @option [Integer] batch_size 何件毎にインポートするかを指定。デフォルト1,000件。
    def import_from_string!(contents, batch_size: 1_000)
      records = []
      contents.each_line do |line|
        records << JSON.parse(line.chomp)
        if records.size == batch_size
          # activerecord-importを使ってバルクインサート
          import(records, validate: false, batch_size: batch_size)
          records = []
        end
      end
      ImportFile.import(records, validate: false)
    end
  end
end

問題点

まず、最も問題なのは、ファイルの内容を一度に全て読み込んでしまっているところです。今回の処理では、gzip圧縮から解凍した際のファイルサイズは100MBを超えるくらいのものでした。これが100MBどころではなく、もっと大きなファイルであった場合、メモリが足りなくなる可能性があります。

そして、次の問題点は、変数の内容を1行ずつ読み込んでいるところでした。1行ずつ読み込むこと自体はそんなに悪くないのですが、activerecord-importでバルクインサートをするかどうかのif文のチェックが毎回実行されていました。

リファクタリング後の処理

では、こちらをリファクタリングしていきます。

file_path = Rails.root.join('files', 'import_file.jsonl.gz')
io = File.open(file_path, 'r')
Zlib::GzipReader.wrap(io) do |gz|
  ImportFile.import_from_io!(gz)
end

class ImportFile
  class << self

    # IOオブジェクトからデータをインポートする
    # @param [IO] io IOオブジェクト
    # @option [Integer] batch_size 何件毎にインポートするかを指定。デフォルト1,000件。
    def import_from_io!(io, batch_size: 1_000)
      io.each_slice(batch_size) do |lines|
        jsons = lines.map { |line| JSON.parse(line.chomp) }
        # activerecord-importを使ってバルクインサート
        import(jsons, validate: false)
      end
    end
  end
end

変更点

IOオブジェクトを使うようにした

ファイルを一気に読み込むのではなく、IOオブジェクトから読み込むようにしました。

#each_sliceで1,000行ずつ読み込む

#each_lineメソッドで1行ずつ読み込むのをやめて、#each_sliceメソッドを使って、1,000行ずつ読み込むようにしました。1,000行読み込んでいるので、わざわざ1,000件のデータがあるかどうかのチェックは不要になったので、if文は削除できました。また、読み込む量も1,000行分毎で済むため、メモリ使用量も少なくて済みます。

パフォーマンス確認

「推測するな、計測せよ」というわけで、benchmark-ipsを使ってパフォーマンスの違いを検証しました。圧縮を解凍したら合計140MBくらいのデータで実験しています。

検証環境のスペック

• PC: MacBook Pro (13-inch, 2018, Four Thunderbolt 3 Ports)
• CPU: 2.3 GHz クアッドコアIntel Core i5
• メモリ: 16 GB 2133 MHz LPDDR3
• Ruby: 2.7.5

結果

11%も速くなりました！🚀

Warming up --------------------------------------
                  io     1.000  i/100ms
                text     1.000  i/100ms
Calculating -------------------------------------
                  io      0.018  (± 0.0%) i/s -      1.000  in  56.379435s
                text      0.016  (± 0.0%) i/s -      1.000  in  62.673752s

Comparison:
                  io:        0.0 i/s
                text:        0.0 i/s - 1.11x  (± 0.00) slower

かなり効果があったと言えると思います。

まとめ

今回はファイルから一気に読み込んでから処理するのではなく、IOオブジェクトを使うようにリファクタリングしたケースをご紹介しました。

ファイルを一気に読み込むのは割とやってしまいがちなのですが、ファイルサイズが大きいデータが想定される場合はあまり良い方法ではありません。そういう場合はIOオブジェクトを活用しましょう。

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

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

「現場で役立つシステム設計の原則」読書会が終わりましたので、先週から社内の有志で新たに読書会を始めました。 それをレポートしていきたいと思います。

読書会の題材

読書会の題材として選んだのは、入門 監視 ―モダンなモニタリングのためのデザインパターンです。

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

複数の候補がある中で決戦投票を行った結果、大差でこちらに決まりました。

皆、どう監視と向き合っていけばいいか、何をどう監視したらいいかを理解したいというのが現れていたかと思います。

読書会の進め方

進め方は、「現場で役立つシステム設計の原則」読書会のときと変わらずです。

1. 当日までに事前に章を読んでおく
2. 感想や疑問点をまとめる
3. 読書会当日、感想をそれぞれ発表する
4. 意見交換を行う
5. まとめをYammerにアウトプットする

ただ、感想を書くときには、以下のような形にしてもらうよう、お願いしました。

• 事前に1章分を読んでおいて、本の感想・疑問点・質問をまとめておいてください。
  • ※要点をまとめないでください。
• 感想・疑問点・質問は、なるべく業務や過去の経験と絡めた形にすると助かります。
  • 経験知をシェアしましょう。

これは、プロダクト開発での課題・困り事と紐づけて考えてもらうことで、本の内容をより咀嚼することができると思ったからです。

1回目 レポート

初回は「1章 監視のアンチパターン」でした。参加者は6名でした。

出てきた感想

ツール依存

• やりたいことをはっきりさせていく事が大事
  • 何を監視するべきなにかを理解しないといけない
  • 監視が目的になると、ツール依存やチェックボックス監視になってしまう
• 目的と手段が逆転してしまう開発あるある
  • 最初は何らかの問題解決を目的としていた筈が、あるツールを採用後、使い倒すために道具を使う方向にシフトしてしまう
  • ツールや技術から選ぶと大体失敗するので、今ある課題を解決するために必要なものを探すという方針は、常に頭の中に入れておけたら苦労しなかった
• ツールに依存するほど使えてない気もする…

自分でツールを作らなければならないときもある

• 以前の職場で監視業務をしていた時は、同僚が作った自作ツールがいっぱいあって、めちゃくちゃ便利だった
• 何だかんだどのCIツールも最後はシェル力が問われるところがある
• 自分でツールを作っても良いという発想は無かった
• 一から作成するのは大変なので、既存の監視サービスに組み込む形がいいのかもしれない(MackerelのカスタムメトリックやNew Relic Flex)

役割としての監視

• 監視専門の人がいればなー、と思っていたが、それではいけないのだなと気づいた。
• 監視しやすいシステムはチームワーク・連携力が段違いだった記憶。
  • 監視している誰かがログやアラートを共有してから、例えばアプリ担当者やコンテンツ作成者が心当たりを調査する。
  • なので行った操作・出力されたエラーが即時連携されること、これを受けた関係者が即座に自分のこととしてレスポンスを返すこと。
  • この辺りが綺麗に流れない組織だと、見通しは一気に悪くなる印象。
• 「オペレーションチームだけでなく、全員が本番環境全体に責任をもつべき」
  • すごくいい言葉。自分事にしないと、なかなか身につかない
  • 全員が全員、ここまで意識はできていないと思う

チェックボックス監視

• 耳が痛い話。痛いけれど、この監視は不要ですと言い切れる自信もなかったりするよなぁと思う
• 現場に当てはめて考えてみた
  • 「メトリクスは記録しているがシステムがダウンした理由がわからない」
    • とりあえずサービスを再起動してみることが多いかも
    • それで直ったら調査を後回しにしがち
  • 「後検知が多すぎるのでアラートを常に無視する」
    • 誤検知ではないが、うるさすぎて無視していたことがあった
  • 「リソースがギリギリでもレスポンスタイムが許容範囲内なら問題ない」
    • 確かに
    • むしろリソースを上手に使い切っているとも言える
    • 動いているかを定義するのが大事なんだなぁ

「動いている」とはどういう意味か

• 実際の業務では非機能要件の可用性・パフォーマンス辺りの話になってくるが、であれば関係各所との調整必至で明確な答えのない問題
• 監視初心者としては書かれている内容は分かるが、どの程度にしたら良いのか悩んだり迷ったりして固まりそう

監視を支えにする

• 暫定対応としてはありだろうけれど、常態化はよくない。リファクタリングが終わるまでの役目にするべき
• Webアプリのバグ(開発環境やステージング環境で発見可能なレベル)を、本番環境にデプロイしてからインフラ担当者に指摘されることが常習化している現場はあった
  • よく指摘されていたのは「Webアプリを実装するエンジニアがあまりログを見ない」というもので、保守・運用経験が少ないとログをよく見る癖が付いていなかったり、障害調査がしやすいログ設計ができなかったり、ということがままある。ログ設計できるようになりたい。

手動設定

• 自動設定できるようになりなさいってことで、やはり入門監視の前にAnsibleに詳しくなるべきではないだろうか…。しかし、日常的にサーバ管理やってるわけではないから、すぐに忘れてしまう。
• 既に動いている自動化されていないシステムを自動化するのは大変
  • できることなら開発の早い段階から、理路整然と自動化されたシステムを構築するのが良いんだと思う

その他、色々

• ツールを増やすのを恐るなという話。確かにと思う反面、多すぎて把握できなくなるのでまとめたいという話も出てくる
• ツールの導入にはお金の話も絡むので、簡単に試せないケースがある
• 監視ツールを常に表示しておくためのディスプレイ欲しいなぁ〜と思った
• 会社で導入している監視ツールでどういうことができるのか確認してなかった。調べておきたい
• 自作ツール、作るのはいいけれど、メンテが大変になるケースもちらほら…。

まとめ

アンチパターンの章ということもあって、皆グサグサと刺さっていたと感じました。耳が痛い話ばかりでした。「やりがちですね」とか、「とはいえ、どう設定すればいいのかがちょっとわからない」とか、今の現場での困り事と絡めての感想が出てきて、より自分ごととして考えることができているなと思いました。

ツールを増やしてもいい、自作してもいいというメッセージは、すごくよかったなと思います。いわゆる俺得ツールを自作していくようになっていけば素晴らしいと思います。

次章は「監視のデザインパターン」なので、今からとても楽しみです！