1 Minute Tips

日: 2019年5月6日

  • SCRUM BOOT CAMP THE BOOKを読んだ

    SCRUM BOOT CAMP THE BOOKを読んだ

    はじめに

    SCRUMのプロジェクトに属した事がなかったので、スクラムのスの字も分からなかった。

    しかし、色々な方々と話している時にSCRUMの言葉が出て来てついていけなくなった事があった。

    自分のチームがスクラムを導入するわけではないけど、スクラムというのはどうゆうものなのか概要は知っておくべきだなと思い、本書を手に取った。

    本記事の対象者

    • SCRUM BOOT CAMP THE BOOKに興味を持っている人
    • SCRUMを知らない人

    どのような本か

    SCRUMはアジャイル開発の一つ。

    現場の人たちの持てる力を最大限に引き出すための必要な事がまとまっているフレームワーク。

    ストーリーは漫画がベースになっていて、登場人物が色々問題にぶつかっていくが、SCRUMチームが解決していく。シンプルな話を通じて、具体例がわかりSCRUMがだいたいどんなものなのか理解できるようになる構成になっている。

    よって、以下の人が本書の読者対象として設定されているようだ。

    • 全体像と決められているルールについて理解したい人
    • 自分の現場でうまく取り入れていくためのヒントを得たい人

    本書の構成

    大きく二つ。スクラムの概要が約20ページでシンプルにまとまっており、実践編が約200ページと手厚くなっている。

    得られる知識

    SCRUMの概要

    SCRUMのルールは細かく決まっているものがあるが（例えばなぜスプリントの期間は一定でなければいけないのか）、それについてなぜそのようなルールが決まっているのかが説明されている。

    それが２時間程度で読めるボリュームに収まっている。

    自分のように直ぐに業務では使わないが、最低限の概要を知りたいという人にとってSCRUM入門の最初の一冊目に読んでよかった。

    本書の足りない所

    残念ながら索引がない。なので、せっかく分かりやすい良書ではありつつも、辞書的に使う事ができない。SCRUMの用語がどのページに出て来るのか、本の最後に欲しかった。

     

  • Go言語での正規表現

    Go言語での正規表現

    はじめに

    Go言語内の文字列の判定で正規表現を使う際の“regexp”ライブラリについてまとめる

    使い方

    MatchString

    正規表現のフォーマットに沿った文字列か確認し、True/Falseを返す

    	match, _ := regexp.MatchString("b([a-z]+)a", "banana")
	fmt.Println(match)

    結果

    true

    しかし、この書き方では複数の文字に対してチェックしたい場合、都度正規表現を書かなくてはならない。

    MustCompile

    以下の書き方をすることで正規表現の定義は一度のみでよくなる

    	r := regexp.MustCompile("b([a-z]+)a")
	ms1 := r.MatchString("banana")
	fmt.Println(ms1)
	ms2 := r.MatchString("apple")
	fmt.Println(ms2)
	ms3 := r.MatchString("orange")
	fmt.Println(ms3)

    結果

    true
false
false

    FindString

    MustCompileの中でURIを正規表現で定義し、
    FindStringで、そのルールに収まっているか確認をするという使い方もできる。
    	r2 := regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
	fs := r2.FindString("/view/test")
	fmt.Println(fs)

    結果

    /view/test

    もしヒットしない場合は、結果を返さない。

    FindStringSubmatch

    格納されるデータはスライスで入っているので、一つ一つ取り出すことも可能。

    	fss := r2.FindStringSubmatch("/view/test")
	fmt.Println(fss[0])
	fmt.Println(fss[1])
	fmt.Println(fss[2])

    結果は以下の通り

    /view/test
view
test

     

  • プロダクションレディマイクロサービスを読んだ

    プロダクションレディマイクロサービスを読んだ

    はじめに

    オライリーのプロダクションレディマイクロサービス（原書: Production-Ready Microservices ）を読んだ。

    本記事はその書籍を通してえられた事についてまとめた。

    本記事の対象者

    • マイクロサービスに興味を持っている人
    • プロダクションレディマイクロサービスに興味を持っている人

    なぜ読もうと思ったか

    ４月からマイクロサービスで動いている共通基盤チームを担当することになり、今まではなんとなくマイクロサービスについて理解はしていたが、きちんと書籍を通して学んだ事がなかったので、比較的時間の作りやすいゴールデンウィークの課題図書として読み、ブログを記載する事で理解を深めようと思った。

    本書を通して何を得られたか

    マイクロサービスのメリットはそれなりに知っていた。大きなところだと、システムを疎結合にする事により、変更の容易性を得られる事にあると思っていた。

    その前提の状態から本書を読み、得られたポイントは以下の通り。

    ドキュメント

    マイクロサービスを導入すると技術的負債が増える傾向がある。本書によると、一種のトレードオフとされてある。

    その対処法を要約すると、ドキュメントの維持・管理とメンバーの理解にあるという。組織的に明確化され、構造化されていれば技術的負債を引き起こす混乱や、意識の欠如、アーキテクチャの理解の欠如を払拭する事ができるとのこと。

    確かに、自分もドキュメントはマイクロサービスでなくても重要であり、しかし更新が後手後手になってしまい陳腐化してしまうプロジェクトやチームを多数見てきた。

    なお一層、ドキュメントを最新にしチームで共有するというのが必要になりそうだ。

    ドキュメントのポイントは以下の通り

    • 包括的か
    • 定期的に更新されているか
    • マイクロサービスの説明、アーキテクチャ図、連絡先、オンコールの情報、重要情報へのリンク、サービスのリクエストフロー、エンドポイント、依存関係、FAQなど盛り込まれているか
    • ドキュメントがチーム内でよく理解されているか
    • 簡単に検索できるか

    注意すべきはREADME。これは本番対応のドキュメントではない。

    組織的な理解

    チーム内の全ての開発者がマイクロサービスの本番対応についての質問に答えられ事ができるかが重要になる。

    マイクロサービスのレビュー、監査は頻繁に行われる必要がある。

    本番対応の監査プロセスも確立されている必要がある。

    成長の判断基準

    サービスがサポートできるRPS（毎秒平均リクエスト数）、QPS（毎秒平均クエリー数）を尺度とする。

    将来サービスに必要とされるRPS/QPSがどれくらいになるかを予想する。

    この指標は量的な成長の判断基準を決めるときの判断材料になる。

    しかし、RPS/QPSの情報は、成長の判断基準を初めて計算した時のマイクロサービスの状態に左右される事が多い。

    マイクロサービスは単独で動いているわけではなく、大きなエコシステムの一部として動いているという事を念頭に置く事が重要。

    マイクロサービス内のプログラムは何でも良いのか

    並行性とパーティション分割（タスクがただ小さな部品に分割されているだけではなく、並列処理できるようにする事）を実現しようとし、非同期フレームワークを使いたい場合、並行性とパーティション分割のために構築された言語である、C++、Java、Goなどが望ましい。仮にPythonでサービスを書くと、スケーラビリティやパフォーマンスを妨げる無数のボトルネックが作られ、それらの悪影響を緩和するのが困難になる。

    並行性とパーティション分割は、相乗効果でマイクロサービスのスケーラビリティとパフォーマンスに影響を与える。

    監視の主要なメトリック

    ホスト、インフラ周り

    • CPU
    • MEMORY
    • スレッド
    • ファイルディスクリプタ
    • データベース接続

    これらの監視はモノリシックなアーキテクチャでも定番だ

    マイクロサービスの主要メトリック

    • 言語固有メトリック
    • 可用性
    • SLA
    • レイテンシ
    • エンドポイントの成功
    • エンドポイントのレスポンス
    • エンドポイントのレスポンス時間

    上記の通り、マイクロサービス単体の外形監視が特に必要になる。

    これらをダッシュボードにまとめれば、チーム内で共有しやすくする。

    ダッシュボードは、わかりやすいか、主要メトリックがまとまっており、ダッシュボードを見ただけでマイクロサービスが正しく動作しているか、などが表現されているかが重要になる。

    読み終わって感じた事

    担当しているマイクロサービス基盤チーム内対応できてないポイントが、すべき理由とともに明確になった。

    いきなり全ては難しいので、優先順位を決めてチーム内で話し合って、現実的な所から改善して行く必要がある。

     

    本書はどの現場でも利用できそうな、汎用的なチェックリストも用意されており、チェックリストから読んでいっても、読者の環境をベースにイメージする事ができると思う。