進化的アーキテクチャ - 読書会 第4回
https://gyazo.com/c683784d06cbd3dbf75d03f7f6a52ed3
日時 ：2020/10/07(水) 20:30 - 22:00
参加者 ：tkskkd.icon,
イベント：
Zoom ：
対象 ：3.1.3 適応度関数の分類を組み合わせる - ３章の終わりまで
司会 ：tfujita.icon
20:30-20:40 10 min 近況
20:40-21:50 読書会わいわい（司会のかた自由にデザインしてくださいね）
21:50-22:00 ふりかえり
はじめに
気になったコメントには、顔アイコン(ショートカット: Ctrl + i)で教えてください。
kobatomo.icon*5とか書けばkobatomo.icon*5複数表示されて興味津々具合がわかりますよー。
できる限り自分のログは自分で残して、みんなでログを作り上げましょう。
近況
tfujita.icon：Agile Tech EXPO - New Normal Agile Episode 0 -参加してきました！＾＾川口 耕介さんの講演、進化的アーキテクチャを読んでてしっくりくる話だなーと思いました。
tkskkd.icon：先日、iPhone なくしたがドコモの保証入っていて端末が新しいの届いた。スマホ依存の生活に気づけた。
makopi23.icon 私もスマホ買おうと思います。。。
3章 漸進的な変更を支える技術
3.1.3 適応度関数の分類を組み合わせる pp.46-48
tfujita.icon
p46 アトミック＋トリガー式
UTのことらしいのでこれは想像しやすかった。しかし、ホリスティック＋トリガー式、アトミック＋継続的、ホリスティック＋継続的はなかなか想像しずらかった。。
セキュリティ強化のメトリクスとかどうやるんだろう？RESTの継続的なテストってどんな感じなんだ。。Chaos Monkey使ってみたいなー。
実行するタイミング？tkskkd.icon
table: 組み合わせ
アトミック ホリスティック
トリガー ユニットテストや機能テストによって検証 統合テストの一部として実施
継続的 アーキテクチャの一部として実施 システムの複数の部分を常に実施
SimianArmyはRITIREDだった
Chaos Monkey
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開
Chaos Monkeyはあくまでも障害を発見し、対策するのを助けるためのツールですから、デフォルトでエンジニアが対応できる時間帯に活動するようにセットされています。
ずいぶん前に、Netflixが本番環境でわざと障害を起こすツールを日常的に使っている、ということを初めて知ったときには「なんという大胆な発想だろう」と思いました。
しかし、システムが大規模になればなるほど、そのどこかで障害が起きるもの。であれば、あえてわざと管理された範囲内の障害を日常的に引き起こし、それに日常的に対応できていることを証明し続けることで、本物の障害が起きても問題なく対処できることが証明できるわけです。
昼間にわざと障害を起こして、それが何の問題もなくシステム的に乗り越えられていれば、夜中に障害が起きても心配する必要もなく、安心してシステム管理者が眠れることでしょう。クラウド時代だからこそ登場した運用管理の発想といえそうです。
tfujita.icon管理された範囲内の障害ってところがいいですね。
tkskkd.iconこういうケースにはこう対応するを日常的に引き起こして、対応の練習になる。
復旧タイムアタックができるtkskkd.icon
その繰り返しで熟練していく
復元性とスケーラビリティの適応度関数
ChaosEngineering
本番環境で実験をおこなえば、想像以上の悪影響がおこる可能性があります。ユーザーに被害を受けさせないよう、緊急停止を可能にするなど被害を最小限に抑える工夫が必要です。いつでもトラブルへの対処ができるよう、実験は深夜ではなくオフィスに人がいる日中におこないましょう。
金融系や医療系も、本番前のシステムテストなどで使えそうtkskkd.icon
3.1.4 ケーススタディ：60回/日のデプロイごとのアーキテクチャ再構築 pp.48-51
発想が賢い！tkskkd.icon
tfujita.iconぐぐると日本では2016年頃以降見かけないなあ。Rubyのコードリファクタリングツールなの？？
p51 彼らは、新しいバージョンと既存のバージョンを並行して実行することで、
tfujita.iconこんなやり方があるんだなあ
丁寧なリファクタリングプロセスをアーキテクチャレベルでちゃんと本番環境で試しているtkskkd.icon
makopi23.icon現新比較を人でやったことあるが、ツールでやるのいいな。比較できる明確な定義ができるものしか難しいのかな？
設計がテスタブルになってないとできないよね。tkskkd.icon
コードレベルからテスト可能性を意識しないとこういうアーキテクチャにならない気がするなー。tkskkd.icon
Scientistの名前が検索しづらい。。tkskkd.icon
リリースの後のことまで考えてこういう仕組み作るの凄いね。。。
今のを作るので手一杯だったりする。。。
3.1.5 目標の衝突 pp.52-55
p52 コードを頻繁に変更していくということは、データベーススキーマも頻繁に変更していくことを意味する。
この方法とても興味ある。CoCでできてない、データベースを変更する方法があればなあ。。
スコットアンブラーはDADも提唱してる。
Flyway
Liquibase
c5-db-migration
dbdeploy
mybatis
MIGRATEdb
migrate4j
dbmaintain
AutoPatch
ツールもいいけど、プロセスの理解が大事だね。それを理解できていれば、手でやることもできるので。tkskkd.icon
長期的視点をもとう！
P54 図3-8
適応度関数って、アーキテクチャに対してのテスト（ただし機能要件ではなく非機能要件にたいして）だと思えばいい気がしてきた。アトミック＝ユニットテスト、ホリスティック＝受入テストtkskkd.icon
makopi23.icon 3.1.6で、４つのニーズをステージ１～６のどこに追加したのかよくわからなかった・・・
3.2 仮説駆動開発とデータ駆動開発 pp.55-58
tfujita.icon問題のある写真の確認大変そう。。MVPの話が出て来た。
P. 56
データ駆動と仮説駆動
仮説＝ストーリーの受入条件としてもいいかなぁtkskkd.icon
仮説が検証できなければ不要になるのか？tkskkd.icon
P57 mobile.de
やみくもに新しい機能を生み出していった結果、売上を減少させ続けた
自分の使ってるアプリがバージョンアップしていらんモノ追加されて幻滅してサブスクやめる感じかなtkskkd.icon
P 57
仮説駆動開発は、進化的アーキテクチャや現代的なDevOps ~ 稼働する多くの部品を調整を必要とする。
基本的なアジャイルな振る舞いの上に成り立っているのだなぁと再認識tkskkd.icon
makopi23.icon 仮説の設定と検証、MVPの設定がいつも難しい・・・
リーンキャンバスや顧客インタビューやるんだけど、仮説の設定、検証のペアがしっくりこなくて悩んでる。
顧客の意見に引っ張られる問題。。。tkskkd.icon
仮説の当たり具合を適応度関数にできないか？
仮説検証の適応導関数があるといいのになぁmakopi23.icon
仮説検証の「うまい」とは何か？
仮説検証の適応度関数とは？！みたいなのできるといいね。
今日のふりかえり
カオスエンジニアリング、Scientistのコンセプトは凄いなぁと思った。考え方だけでも参考になるなぁtkskkd.icon
仮説検証の適応度関数を作ろう！！ｗtkskkd.icon
抽象と具体の振れ幅が凄い本だなぁと改めてtkskkd.icon
日本の事例を探してみよう！！
makopi23.icon 仮説検証の有効性を評価できる適応度関数、めっちゃ欲しい
いろんなツールあるけど、プロジェクトへどう説得して導入するかを考えないといけないなぁ
どう導入にこぎつけたかとかヒントがあるといいなあ
tfujita.icon三章は、アトミックやホリスティックといった理解しづらい用語もあったが、Chaos MonkeyやSientistなどの興味深い考え方・コンセプトのツールをしれてよかった。
役に立つ(?)リンク
次回
日時： 2020/10/21 (水) 20:30 - 22:00
対象： 4章
ページ：59-76
役割分担
司会：tfujita.icon
ページ作成：
connpass：makopi23.icon
読書会ベロシティ
46-58, 13p