「入門 監視」読書会レポート 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 にしても詳しい人が必要になるので、コスト削減に繋がるかは疑問が残る。
    • メンテナンスコストを考えれば理解できるが、他のコストについても考慮に入れるべきでは。
    • メンバー全員に対して教育コストがかかると考えると、既製ツールを使っても結構なコストになりそう。
  • 監視の仕組みが成熟していない時は買い、システムがツールを超えて成長してきたら何かに特化した自作ツールを作る感じ。
    • 現状は、監視のサービスを使って基礎を整える段階っぽい。
    • 監視ツールはSaaSOSSをそのまま使う形にしがちだが、あるところまではこれでいい、ということが分かったのは大きい。
  • 安いしどんどん便利になるし導入も簡単です使いなさい。
    • はい。
  • 自分達で構築するよりは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くらいのデータで実験しています。

検証環境のスペック

結果

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に詳しくなるべきではないだろうか…。しかし、日常的にサーバ管理やってるわけではないから、すぐに忘れてしまう。
  • 既に動いている自動化されていないシステムを自動化するのは大変
    • できることなら開発の早い段階から、理路整然と自動化されたシステムを構築するのが良いんだと思う
その他、色々
  • ツールを増やすのを恐るなという話。確かにと思う反面、多すぎて把握できなくなるのでまとめたいという話も出てくる
  • ツールの導入にはお金の話も絡むので、簡単に試せないケースがある
  • 監視ツールを常に表示しておくためのディスプレイ欲しいなぁ〜と思った
  • 会社で導入している監視ツールでどういうことができるのか確認してなかった。調べておきたい
  • 自作ツール、作るのはいいけれど、メンテが大変になるケースもちらほら…。

まとめ

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

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

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

「現場で役立つシステム設計の原則」読書会レポート vol.10

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

tech.rhizome-e.com

10回目レポート

今回は、第10章「オブジェクト指向設計の学び方と教え方」で参加者は6名でした。

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

  • ドメインオブジェクトを設計していくという考え方にはあまりなってなかった
  • 受託開発をしているときはリファクタリングをする機会があまり与えられないため、良さがよくわかってなかった
  • オブジェクト指向は言葉で説明するのは難しい
  • オブジェクト指向を学ぶにはリファクタリングがいいと思う
  • 手を動かして覚える
    • 仕事のタスクだけだと覚えるのに時間がかかりそう
    • オブジェクト指向を意識して作業してもらわないと意味がない
    • コードレビューで言及して意識してもらうとか
  • 実際の実装を読んで理解する
    • 一番手っ取り早い気がする
    • 長くメンテされているライブラリ等は綺麗に実装されているものが多い
    • ついでにPRも出せば、手も動かせて良い勉強方法になりそう
  • 極端なコーディング規則を作ると、1人ならいいのかもしれないけれど、チームでやるとイライラしそう
    • 仕事で実践していくのは厳しい
    • プライベートで勉強がてら取り組むのには良さそう
    • Todoリストとかのサンプルアプリを作って試すなど
    • 一部、簡単に実践できる内容もあったので、今後、機能開発する際はチェックするようにしたい
  • ドメイン駆動設計の本は先輩社員にもオススメされた
    • 書かれたのが2000年代初頭なので、それを念頭に置いて読まなければならない
    • 書かれてる実装方法が現代においては冗長だったりするらしい
  • 「モノ」にフォーカスした「データクラス」がアンチパターンであることを理解する
    • データクラスは複数箇所で参照されるため、修正の影響範囲が大きくなるということを理解する
    • モノにフォーカスしたテーブルを作るとこれが出来上がる
    • モノにフォーカスしたテーブルを作っていいのは業務ロジックを持たないマスタデータだけ?

まとめ

この章では、オブジェクト指向の学び方について意見交換を行いました。
リファクタリングで学ぶという意見やライブラリ等の実装を読んで理解するという意見など、それぞれが思うオブジェクト指向の学び方が出てきました。

第10章で「現場で役立つシステム設計の原則」の読書会は終わりです。
この本を読んできて、ドメインオブジェクトの視点からオブジェクト指向とはどのようなものか、オブジェクト指向の開発とは何かを知ることができたのではないかと思います。 また、この本の内容が自社製品のリファクタリングをする上で基準の参考になりました。

次の読書会は入門 監視 ―モダンなモニタリングのためのデザインパターンを読んでいきます。

「現場で役立つシステム設計の原則」読書会レポート vol.9

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

9回目レポート

今回は、第9章「オブジェクト指向開発プロセス」を読み進めました。

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

開発の進め方
  • 分析・設計にほとんど時間をかけずにとにかくプログラミングするという流れはある。
    • 特に、Railsでは顕著ではないかと思う。ちょっと規模が大きくなるとコードの見通しが急速に悪化するというのは、身に覚えがある。
    • コードの見通しが悪い
    • 手がつけられないほど難解
  • もう少し分析や設計に時間をかけるのが良いのかもしれない..。
ドキュメントについて
  • 開発の初期から利用規約・ユーザーガイドのアウトラインを作成しておき、開発が進むにつれ内容を充実させる、というのはいい考えだと思う。
  • データベースのテーブル名/カラム名とコメントは書くようにしている。I18nのデータを元にコメントにしていく仕組みを準備している。gemにしてもいいかもしれない。
    • 何のためのカラムか、制約か、わかりやすくなる
  • 技術方式のドキュメントもソースコードで表現できる(Infrastructure as Code)
    • 現代においては、この辺りはもう全てコード化しておくべきもの。学ばなければならないものが多い反面、自動化できることの恩恵は大きい。
  • ソースコードがドキュメントの代わりになる
    • ドメインオブジェクトのクラス名等と業務の関心事が一致してれば可能
    • とても魅力的だが、テスターの人にもある程度の知識が必要になる(IDE使えたりとか)
    • 技術者ではない人向けには別途ユーザーガイドなどを用意すると良い
    • ドメインモデルで設計ができれば、コードがドキュメントみたいなことが実現できる
情報共有の方法について
  • 口頭でのやりとりをラフスケッチとしてホワイトボードに起こしていくというのは、写真を撮るだけでいいしよくやっていた。
    • リモートワークが主流になった現在だと、MiroやMS Whiteboard等を活用するのもいいかもしれない。
  • ラフスケッチ良さそう
    • 今は口頭とかテキストベース
      • イメージしにくかったり見落としがあったりとか
ドメイン知識について
  • オブジェクト指向の開発を進めていく上で業務の理解は必須になっている
  • 分からないことは聞く。分かったふりはしないこと。
    • どのようにしてドメイン知識をつけたか、同じチームのメンバーに確認する
  • 他の章にも書いてあったが、プログラミングスキルとドメイン知識の両方を備えていかないと、優秀なエンジニアとは言えないと思う。業務知識の勉強会を行うことも大事と思われるので、そういうことも計画していったほうがよいかもしれない。

まとめ

本章では特に「ドキュメント」「情報共有」について、今までの経験でどうした方がいいのか答えが出ていなかったのですが、答えを見つける手がかりを得ることができました。
技術者向けには、ドメインモデルでの設計やInfrastructure as Codeにより、ソースコード自体をドキュメントとし、技術者以外の関係者との情報共有は、「利用者向けのドキュメント」や「画面・帳票」をメインに利用できるようしていきたいです。

現在実施している「現場で役立つシステム設計の原則」読書会は、ついに次回の第10章で最後となりました。
改めて今までを振り返り、今回得た知識を業務で活用して行こうと思います。

「現場で役立つシステム設計の原則」読書会レポート vol.8

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

読書会の第8回目のレポートです。

前回のレポートは、こちらになります。

tech.rhizome-e.com

8回目レポート

今回は、第8章「アプリケーション間の連携」で参加者は4名でした。

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

アプリケーション間の連携方式
  • 代表的なものは以下の4つ
    • ファイル転送
    • データベース共有
    • Web API
    • メッセージング
  • 弊社でよくやる方式なのはファイル転送、WebAPI連携も多少やっている。
Web API設計
  • 更新も削除もPOSTにする
    • アプリケーションの独立性が高くなり、修正の影響を小さくできる
    • 更新や削除もPOSTで行うのはRESTに反するので、どうだろう..。
  • 大は小を兼ねるAPI
    • 必要のないパラメータまで理解しなければならなくなる
    • 受け取ったデータから必要なデータを取り出す処理が必要になる
  • 計算ロジックの置き場所
    • 以下の理由から、単純なものも含めてクライアント側を基本とするのが良い気がする。ただし、DBで集計できるものなどはWeb API側で処理する。
      • どちらに書くべきか判断に迷わなくなる
      • ロジックを書いてある箇所が特定しやすい
  • 登録と参照を分ける
    • 例えば指定席を予約するAPIの場合、POSTのレスポンスは予約番号だけを返し、予約内容はその予約番号を使って別途GETする
      • この例だとPOSTした際に予約内容の詳細を返す場合と比べて1回リクエストが増えるが、シンプルな設計になることのメリットのほうが大きいと思う
  • リソース単位を分ける
    • Web API側はシンプルになるが、これはリクエスト数がかなり増えそう
      • 例えば名前、生年月日、性別の3項目を1つの画面に表示したい場合、3回リクエストする必要がある。リソースの数だけリクエストが増えてしまう。
    • クライアント側はリソースの数だけリクエストする処理や受け取ったデータを管理する処理が必要になるので煩雑になりそう
      • URLを叩く処理などをSDKなどにまとめていけば再利用しやすくなり、クライアント側の負担を減らすことができるかも
非同期メッセージング
  • 非同期メッセージングをアプリケーション間で使ったことはない気がする..。
  • dRubyを使えばできる?
マイクロサービス化
  • 試行錯誤がしづらそうだと思った。サービス単位の分離を上手にやらないといけない。
  • 対象業務への理解が不十分な場合はモノリスで作っておき、後々分けていくのが良いかも
  • サーバーレス&マイクロサービスが今後の主流になっていくとは思うが、それはある程度サービスが枯れてからが良さそう

まとめ

今までWeb APIを利用することがあまりありませんでしたが、本章を読み進めることでWeb API自体やシンプルでより良い設計の方法について理解を深めることができたと思います。

ただし、Web API側のシンプルさを追求する一方でリクエストの頻度やクライアント側の負担についても考慮する必要があると感じました。

本章を通じて得た知見を活かしてシンプルで保守しやすいWeb API設計を意識しつつ、サービス全体としても最適な設計を模索していきたいと思います。