cronを書くときのtips

cronを書くときの自分用メモ

  • まずは短い間隔で試して動くか確認する
    下記の例だと2分ごとに実行し、標準出力と標準エラーをファイルに出力する。
$*/2 * * * * hoge >> fuga.log 2>> fuga_error.log
  • ファイルの実行権限を確認する
  • ファイルパスは絶対パスで書く
  • 設定を確認するとき
$crontab -l
  • crondが稼働しているか確認する
  • cronのログを確認する
$tail /var/log/cron

ツール選定する時の流れ

概要

ツール選定をおこなう事が多かったので、どのように実施しているかメモ

  • 目的とそれを要件を決めて比較項目を挙げる
  • ツール選定の方向性を早めにチームに共有する
  • 共有したらひたすら公式Doc読んで調べる

フレームワーク

目的

何を目的とするか書く。

要件

目的を実現するために必要な要件を決める。

調査項目

要件を満たすための項目を羅列する。
この時点でレビューをもらうために情報をチームに公開する。

比較表

上記で挙がった各要件を比較する。

具体例

ブラウザのJavaScriptのエラーを検知したいケースを具体例として挙げる。

目的

ブラウザのJavaScriptのエラーを検知して、障害対応に役立てたい。

要件

エラーの発生箇所を特定するために、

  • フロントエンドでエラーが発生したときに検知できる
  • 検知したエラーを開発者に通知できる
  • どのようなエラーがどこで起きたか特定できる

    調査項目

  • ログ形式
    • ログレベル
    • タイムスタンプ
    • 関数名
    • カスタムメッセージ
  • 料金
  • エラーログの保持期間
  • エラーログの永続化
  • エラーログの閲覧方法
  • 通知

これらを比較し検討する。

Tips

ツールが多すぎるとき絞り込むポイント

  • Web上に情報が多いか?
  • 全社的に契約しているか?
    エンタープライズ契約だと割引が効いている可能性がある。
  • OSSの場合 Star数、直近のコミットの日付、コントリビュータ数など

なぜこの意思決定をしたか振り返ってわかるようにしておく

そうすると次の選択時に一つ選択肢が減って選びやすくなる

なぜフロントエンドのパフォーマンスモニタリングをモニタリングする必要があるのか?

結論

アクセス数の増加や離脱率の減少に寄与することで事業貢献するため

1. 劣化を防ぐ

パフォーマンスは機能を追加するたびに劣化する。
それを可視化して決められた範囲を超えないようにする。

下記のようにパフォーマンスが劣化すると不利益が出ることが知られている。

https://developers.google.com/web/fundamentals/performance/why-performance-matters/?hl=ja

  • 自社サイトの読み込みにかかる時間が 1 秒増えるごとに BBC はユーザーが 10% ずつ減少することを発見しました。
  • ページの読み込みにかかる時間が 3 秒を超えると、DoubleClick by Google は 53% のユーザーがモバイルサイトの訪問をあきらめることを発見しました。

2. 改善する

下記のようにパフォーマンスを改善するとユーザのアクセスが増えることが知られている。

https://developers.google.com/web/fundamentals/performance/why-performance-matters/?hl=ja

  • Pinterest では、ユーザーが体感している待ち時間を 40% 削減した結果、検索エンジントラフィックとサインアップ数が 15% 増加しました。
  • COOK では平均ページ読み込み時間を 850 ミリ秒短縮したところ、コンバージョン数が 7% 増加し、直帰率が 7% 減少し、セッション当たりの閲覧ページ数が 10% 増加しました。 改善施策の前後でユーザ数を計測し、改善効果を数値化する。(数値化は各マイクロサービスチームが必要であれば実施する。統合レイヤーは環境を提供する。)

遅いアプリケーションのコスト

『入門 監視』P77より抜粋

ページロード時間が1秒遅くなると、平均でページビューが11%、コンバージョンが7%、顧客満足度が16%下がる(Aberdeen) 最適なページロード時間は2秒以下で、5.1秒を超えるとビジネスに影響が出始める(Aberdeen) ページロード時間が6秒から1.2秒に短くなったことで、売上げが12%増え、ページビューも25%増えた(Shopzilla) ロード時間が100ms改善するごとに売上げが1%増える(Amazon) 体感の待ち時間を40%短縮したことでSEOトラフィックが15%増え、新規登録も15%増えた(Pinterest)

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

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

フロントエンドのパフォーマンスモニタリングについて調査する

フロントエンドのパフォーマンスモニタリングについて調査

結論

  • 計測する項目がいろいろあるので、プロダクトの特性に合わせて見るべき数値を考える
  • とりあえず計測してみてデータを集める
  • まずは計測、いきなり改善しようとしない

計測対象を決める

  • URL数
  • 対応リージョン
  • 対応ブラウザ
  • 対応デバイス
  • 環境(stg, prd)
    • 基本的にprdのみで良い
      理由は、STGはユーザやサーバ台数が本番と異なるので、外部からアクセスした際のパフォーマンスに関して意味のあるデータを取ることができないため。
      STGのランタイムのパフォーマンスを計測することには意味がある。

計測タイミングを決める

  • PRのタイミング
  • masterにmargeされたとき
  • 定期的に

細かく計測できるのが理想だが、料金と相談
ピーク時間のパフォーマンスが重要なので予めピーク時間の検討をつける(計測してみて、アクセスが少ない時間帯の計測を削る方法もありそう)

モニタリング指標を決める

主な計測指標

  • Time To First Byte...最初のバイトを受け取るまでの時間
  • DOMContentLoaded...HTMLドキュメントのダウンロードとDOMツリーの構築が完了するまでの時間
  • load...CSS/JS/画像などのサブリソースのダウンロードと評価が完了(遅延ロード除く)
  • Throughput...同時接続数/同時リクエスト数

  • First Paint (FP)...ページが表示され始める(Paint Timing APIで定義)

  • First Contentful Paint (FCP)...コンテンツが表示され始める(Paint Timing APIで定義)
  • First Meaningful Paint (FMP)...ユーザに意味のある表示になる(標準化されていないので実装側で要算出)
  • Time To Interactive (TTI)...ユーザの操作に応答できるようになる(標準化されていないので実装側で要算出)
  • Speed Index...Above the Fold(ファーストビュー)のレンダリング時間を示すスコア(Resource Timing APIから算出) https://github.com/WPO-Foundation/RUM-SpeedIndex

スコアの重み付けについて

アプリの特性によって見るべき指標は異なる

  • CSR(クライアントサイトレンダリング): 真っ白な時間が長いのでFMPを指標に
  • SSR(サーバサイドレンダリング): 真っ白な時間は短いが、操作できるまで(JSを読む)の時間を測るためTTIを指標に

ページロードはn秒以内を目指す。
『入門監視』では4秒とある。 競合サービスを計測し、目標値を決める。

モニタリングの方法(Synthetic monitoring と Real User Monitoring)

Synthetic monitoring

サーバから計測のためのリクエストを送る。
環境にばらつきなし、定期実行しやすい、実際の環境とは乖離することがある。

Real User Monitoring

ユーザがアクセスしたときに埋め込まれたJavaScriptが走りサーバにデータを投げる。
環境にばらつきあり、実際の環境に近い。

ツールの評価ポイント

  • RUM、Synthetic対応しているか
  • 対応ブラウザ
  • 対応デバイス
  • 対応リージョン
  • CIに組み込めるか

計測ツールを決める

ざっくりメモ。

WebPageTest

https://www.webpagetest.org/
SaaS。Synthetic Monitoring。

SpeedCurve

SaaS。SpeedCurve syntheticはWebPageTestを使用している。
SpeedCurve LUXというツールでRUMも計測できる。

Lighthouse

ChromeのDebbuggingAPIを使って動く。参考
PageSpeed Insights
Lighthouseの上で動いている分析ツール

sitespeed.io

https://www.sitespeed.io/
pluginとしてWebPageTestを動かせる。
gitlab-ciとsitespeed.ioのドキュメント

pingdom
appdynamics
catchpoint

次のアクション

とりあえず無料枠でやってみる
RUMとSynthetic両方やる
各ツールの比較
各サービスの動作原理を把握
アプリの特性の把握

用語メモ

  • median:中央値
  • avarage:平均値(外れ値の影響を受けやすい)
  • nパーセンタイル:上位(100-n)%のデータを捨てた最大値。大部分の傾向はどの様になっているか把握する。
    例:課金やレイテンシのレポート
  • performance budget:パフォーマンスにおいて一定の基準を決めて、それを超えないように管理すること。
    c.f. https://developers-jp.googleblog.com/2019/03/blog-post_15.html

参考にしたサイトや書籍

網羅的にまとまっているページ
Googleが提唱するパフォーマンス
FMPやTTIなどの説明図

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

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

『入門監視』の個人用メモ

1章

  • 監視はロールではなくジョブ チーム全員でおこなう。勉強会などを開催し、知識を広める。
  • 不安定なシステムに監視を追加するのではなく根本的な原因を改善する
  • 監視ツールに依存しない、交換可能であるべき
  • 現代では監視ツールの負荷が問題になることは少ない 開発初期から導入する
  • チェックボックス監視という状態 表面上だけの監視
    • メトリクスは記録しているがシステムダウンの理由がわからない
    • 誤検知が多いのでアラートを無視する
    • 監視の間隔が長い(60secを基本とし、高トラフィックのシステムほど間隔を短くする)
  • 監視設定やエージェントインストールは自動化する

2章

  • 監視するデータの種類
    ・メトリクス
    カウンタ(ex,走行距離計、アクセス数など)
    ゲージ(ex,速度計、CPU、メモリなど)
    ・ログ
    非構造化ログ(Nginxの生ログなど)
    構造化ログ(情報の抽出のため、殆どの場合構造化する)

  • 監視はまずユーザ目線から(ヘルスチェック、HTTPステータス、画面の表示要素など)

  • 人件費より安い事がほとんどなので、自社で作らずSaaSを使う
  • 監視するからには継続的に改善する

3章

  • アラート対応の手順書を書く
  • 閾値だけでなく標準偏差移動平均を使う(突発的な上昇に対応できないから)
  • アラートのチューニングを行う
  • アラートを送る前に自動復旧を検討する
  • オンコールの期間、対応疲れに留意する
    https://response.pagerduty.com/

ドメイン駆動設計 本格入門レポ

行ってきたのでレポ。

資料

概要と感想

スライドの各章ごとに概要と感想をメモする。

ドメイン駆動設計の考え方

ドメイン駆動設計でなぜ作るか簡潔に述べている。
とくに、コードの変更を安全で楽にするということは、セキュリティ向上、性能改善、ビジネス要求の素早い実現にもつながるという説明がためになった。
言われてみれば当然かもしれないが、このような話題はエンジニア視点で語られることが多く、コードの変更が容易になった先の視点が抜けがちなので、ビジネス視点での有用性を説明する際に積極的に使っていこうと思った。

ドメイン駆動設計を理解する3つのキーワード

ドメイン駆動設計の文脈において頻出するキーワードを、焦点を絞りより具体化して説明している。
この章は『現場で役立つシステム設計の原則』で語られている部分がいくつかあったので事前に読んでおいてよかった。(まだ読んでいる途中)
1、2、3、4、5章に重複している部分があるので相互に読むとより理解できると思う。

3つのキーワード(ビジネスルール、計算モデル、型指向のプログラミング)についてかなり大雑把にまとめると、

  • ビジネスルールとは金額、数量、期日などの計算と判定である。それらは、状態、区分、タイミングなどにより複雑に条件分岐する。
    例:商品種別、有効期間、キャンセル可能条件など
  • ビジネスルールは計算モデル(計算式、判定式、条件分岐)であり、Fact、Rule、Goalに分類してモデル化できる
  • ビジネスルールはに登場する値は専用の型を作り整理する(型指向のプログラミング)
  • ビジネスルールの設計パターンとして

が挙げられる。具体的にはスライド参照。

特に以下のような具体例が参考になった。

メソッド名は標準クラスでよく見るものなので、値オブジェクトのメソッド名をつける際には参考にしていきたい。
これら以外の特殊な名前になるときは値オブジェクトのクラス設計を見直しても良さそうだと感じた。

エヴァンス本のススメ

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)


上記エヴァンス本で

  • 誤解されがちな概念
  • 全体構成と要点
  • 読み進め方

について述べられている。
とくにエヴァンス本の読み進め方はDDDに興味を持ってこれから読み進める人は読んでおくと良いと思った。
すでに最初から読みすすめているので、もう少し早く知りたかった…

レガシーに立ち向かう

ドメイン駆動設計の手法で、レガシーシステムに対して、

  • どのように現状の調査分析をおこなうか?
  • 手がかりをもとにどのように整理していくか?

その具体的な方法について述べられている。
特に心の準備編ではあるあるなことが多かった。

マイクロサービスとドメイン駆動設計

マイクロサービスとドメイン駆動設計の関連性について、

  • マイクロサービスの4軸に分けた分割方針
  • 相互のアーキテクチャの特性と移行タイミング
  • マイクロサービス化と相性の良いアプリケーション層・データベースの分析/設計手法

について述べられている。

継続的に分割の見直しができるかどうか?が重要だと感じた。

全体の感想とメモ

  • 具体例を通してエヴァンス本を読んでいたときよりもドメイン駆動設計の解像度があがった(特にビジネスルールのモデル化や設計パターンなど)
  • とにかく値オブジェクトが大事
  • ブレイクスルーについて語られるときもほとんど値オブジェクトの話
  • DDDは長く継続して運用されるシステムに特に効果がある
  • DDD本は通読するより全体を把握して都度読み返す方法がよさそう
  • 発表前に「これは正解ではなく、自分の体験・経験である」と前置きがあり、参加者の思考・議論を促していたのがよかった
  • 現場で役立つシステム設計の原則9章と関連したエピソード(おそらく9章を書くきっかけになったもの)が披露されて、他人に説明して納得してもらうスキルも必要だと感じた
  • Tryは担当システムのビジネスルールとその値オブジェクトの分析、整理

CI/CD Test Night #3に参加してきた

概要

いってきたのでメモ。
testnight.connpass.com
Tryを中心に書いていく。
共通していることが多いので、後半になるにつれTryが少なめ。

LTメモ

fastlaneとBitriseで構築するiOSのCI/CDレシピ

https://speakerdeck.com/rockname/cd-recipe-constructed-with-fastlane-and-bitrise

やったことある

  • Slackからデプロイ
    SlackでCode Deploy叩く
  • リモートでCI結果確認
    CI結果のSlack通知
  • カバレッジ計測
    mocha+nyc

Try

  • ビルドアクションのソース管理
  • 毎週パッケージのアップデートを検知しPRを自動で作成
  • ビルド時間とカバレッジを毎日計測して改善

Automate All the Things

https://t.co/M90bD94WLr?amp=1

やったことある

Try

  • cspellでスペルチェック
    無視リストがあるので有効活用する
  • CI結果をPRにポストする
    Dangerでやっているとのこと。 SlackにはポストしていたがPRで一覧できるのはいいかも?
  • コードカバレッジをPRにポストする
    同上
  • 画面キャプチャを撮ってPRにポストする
    スナップショットテスト。テスト走らせなくてもまずはポストするだけでも気づけることはありそう。
  • CIの速度改善、ビルド生成物をキャッシュして速度改善する

10分でわかるGitHub Actions

https://speakerdeck.com/ikeike443/10fen-defen-rugithub-actions-08a47f83-0acb-4fd3-9615-c7ec22cf0f8c

Try

  • GitHubActions触ってみる
    Delete marged branchあたりはすぐ試せそう。
    テスト、ビルド、デプロイ、リリース作成あたりも試したい。
    CircleCIとの棲み分けどうなるのか気になる。

Jenkinsのつらみを軽減した話

https://speakerdeck.com/theoden9014/jenkins-falseturamiwoqing-jian-sitahua

やったことある

  • Ansible

Try

  • Ansibleの検証環境をVagrantで作ってみる

GASを使ってBitriseを手軽に拡張する(仮)

https://speakerdeck.com/kwzr/ciwogasdeji-sok-de-nigai-shan-sitaraxing-seninatuta

Try

  • ビルド状況の計測

CI/CDと継続的ワークフロー改善

https://speakerdeck.com/gaussbeam/cdtoji-sok-de-wakuhurogai-shan

GitHub と連携する CI を作る

https://speakerdeck.com/duck8823/github-tolian-xi-suru-ci-wozuo-ru

社内の遊休PCをAzure PipelinesでCI/CDに活用しよう

https://www.slideshare.net/shinyanakajima37/pcazurepipelinescicd

まとめ

  • CIはスモールスタートではじめてみる
  • CI/CDを計測して改善していく
  • 機械的な指摘やパッケージのアップデートのPRはCIでやる
  • ビルド時にやっていることはコード化する

懇親会雑談メモ

  • cspell導入コスト低そう
  • ローカルとCIで静的解析のダブルチェック
  • ローカルで静的解析はコード量おおくなると時間かかるからやらない
  • 上位のテストはコストかかるので後回しになりがち
  • スナップショットテストはコスト低め
  • iOSアプリはwebより巻き戻しが大変
  • カバレッジ、ビルド時間はみんな計測してて、定期的に改善する会やる
  • 何を基準に自動化するか?早すぎる自動化はきつい。作業をおこなっている回数や同じ作業をおこなっている人数を見る。