Coveを試してみた
Coveって？
要は会社のOKR、チームのOKR、個人のOKRを便利に管理するツールです。
ざっくり特徴とか
日報的に毎日進捗等を記したり、進捗N%と更新することで定量的なレポートが見えるので管理がしやすくなる。
- そのレポートをメールで飛ばされる。チームのObjectiveはチーム全員へメールされると思われる
- そのレポートをメールで飛ばされる。チームのObjectiveはチーム全員へメールされると思われる
Key Resultの部分でTO-DOSを登録できたりする
OKRのマップ（視覚化）
感想やら雑感
- 目標に対する進捗なるものの管理はすでにあったりして、もし導入するならそれを置き換えるイメージになると思う。
- 追加でこのツールも導入とか考えると、ダブル管理の部分が出てくるし、手間でしかなくなる気がする
- ちゃんと使いこなす文化ができれば、あまり関わりの無い部署のOKRの進捗が簡単にみれたりする(OKR Map)でのその点は良いと思う
- エンジニアでは無い人は使いこなせるかは、んー
- 結局ある特定の人、チームだけが使いこなしていても他の人達が分からなかったり、伝わらなければ仕事の透明性を欠き色々と問題が噴出してくるのは変わらないと思う
- 少し前にプロジェクトの見取り図なるものを教えてもらって作って運用してるけど、他部署の人への伝わってる感はそれなりに感じている
PMについて思った事
元ネタは下記の動画をみて、自分的に思った点やメモを残す
まずはPMとは
- ここで言っているのはプロジェクトマネージャでは無く、プロダクトマネージャ である
- この辺りは色々な所で違いを定義したり、言われたりするけど個人的には下記の文がしっくりきている
プロダクトマネージャ
プロダクトの課題の解決に向けて技術的なアプローチも含めどうやって実現していくかに責任をもつ
プロジェクトマネージャ
品質であったり、開発コスト、スケジュールに責任をもつ。
補足等々
- パッケージソフトが主流だった頃を考えるとプロジェクトマネージャの立ち位置はわかりやすいと思う。
- webやアプリでサービスを継続的にスピード感持って提供していく上ではプロダクトマネージャがより重要になってきると思う
- プロダクトマネージャには技術的な理解や手法の習得がとても重要でほとんどエンジニアのような存在だったりする
- プロダクトマネージャの部下はエンジニアではなく、お互いに対等なレイヤーなので、指示等は基本存在しない
- なんでお互いの信頼関係がとても重要
- でも実際はプロダクトマネージャがリードしていくパターンが多く、エンジニアをリードするにはエンジニアリングもスーパーな人でないと厳しい気がする
Product Manager vs Project Managerでもひと記事いけそう...
さて本題. PM(プロジェクトマネージャ)の役割に関して
結局は全社でCross Functional TeamになるんだけどPM(プロジェクトマネージャ)とEngineerは両輪になるし、密に連携しながら進めなければいけない。なので重要なPMとEngineerの役割をピックアップする
PM(プロジェクトマネージャ)
- 「What」「When」「Why」をしっかり定義して押し進める。
- PRD:Product Requirements Documenを主に活用していく
- プロダクトの課題の解決に向けて技術的なアプローチも含めどうやって実現していくか (2回目記載)
- OKR
Engineer
- 「What」「When」「Why」で決まった方針に関して「How」どのように実装していくかを担当していく
- Design Doc
memoやら
- 「How」の実装方法はEngineerのリスペクトにつながるのでPMは基本的に関与しない
- ただ、Engineerのただ試してみたいという意向だけでselectされたオーバーアーキテクチャには注意が必要だなとおもった
- そこまでやる必要ある？ってスタートアップではよくある話で....
- 「How」の実装方法はEngineerに託すが、PMは内容に関してはしっかりコードレベルで理解していかないとキツいと思う。
- PRD:Product Requirements Documenは重要で工期の終盤、リリースを優先する場合は機能を削減しなければいけない場合がある
- その時に方針をブレずに判断する為に必要
参考
- Servant leadership - Wikipedia, the free encyclopedia
- job-descriptions/product_manager.ja.md at master · increments/job-descriptions · GitHub
- OKR (目標と主な結果) – 前田ヒロ
- OKR：組織内のコミュニケーション効率化と重要なゴールへの集中を促すシステム - yaotti's diary
- Design Docの例:WebKit WebSocket design doc - Google ドキュメント
最後
主にKPIの所からPRDに落とし込んでOKRを設定して開発を進めるが、当然それだけだと全く楽しくないし、それだけでは不十分。思ってもみなかった不具合やユーザの反応を見ての改善＝ボトムアップで出てくる改善の開発も入れながらバランスを取ってやっていく事が重要だなと思う。
ひとえにPMといってもプロダクトマネージャなのかプロジェクトマネージャを指してるのか曖昧になってる事がよくあると思う。スタートアップでは両方の役割を一人がこなす事が多いから問題にならないけど、違う事を理解しておかないとスケールした時に色々と問題が生じる
作るプロダクトによる（B2B向け？B2C向け？）けどプロダクトマネージャはほぼengineerと同程度のテックは必要だと思ってる。 日本でよくいる技術的な事が分からないディレクターやプロデューサーとは全然別ものなんだけど、彼らにプロダクトマネージャの役割を担わせようとしてる事が多い気がする。当然無理が生じる。結局はengineerの誰かが補ってるパターンが多い。
別にテックが無いディレクターやプロデューサーを批判しているわけではない。仕事を通してスキルを身につけていく事は普通だけど、例えば経済を学ぶ学生アルバイトに弁護士試験をパスしていてと言っているぐらい、別物で難易度が高いもを担わせようとしているような感じ？かな。もっとイイ例えがありそうだけど。
プロダクトマネージャと言うものをちゃんと理解してテックのバックボーンがある人間が担っていく事が理想だけど、なかなかそういう人っていないよなーって思うし、社内から生み出していかないといけないだろうなーと思う。
とにかくそれぞれの役割の違いをみんなで理解するところかな。ちなみに動画でも言っていたけどそれぞれの役割とラップする部分は多くあるのでオーバーラップは当然ある。重要なのはどこに軸足を置いてるかと
Habitat Meetup #1 に参加してきた
勉強会に参加させてもらったのでその時のメモやら
勉強会概要
発表
Habitatとは？ Chef Software, Inc. Alex Vinyar
- Habitatを含むChef Automationのお話
- Chef Automate – Embrace DevOps | Chef
- Chef Automationのポイントは下記3つ
- Visibility
- Workflow
- Compliance
- Chef Automationの概要図は下記の図がわかりやすい（本家から）
感想
今、Chef,Rubocop, Foodcriticを使ってレシピかいてServerSpecで担保してってやってるけどこれらをChef内で完結できるとより良いエコシステムになるしビジュアライズはステキだなと感じた。 githubのPRのような人によるレビューをするワークフローが存在していた。
関連情報
Foodcritic - A lint tool for your Chef cookbooks
Habitat考察(仮) 高石諒(@r_takaishi)
- Chefがデータセンターの自動化なら、Habitatはアプリの自動化というお話
- HabitatはRustで書かれているらしい
- HatbitatはInfrastructure as Codeの分類で言う所のinfractures serviceに属するお話
- Infrastructure as Code の分類の話は関連情報で
- Habitatの特徴としては
packageとsuperviorがある - どういったアーキテクチャで動いているかや他のプラットフォームでも動く点など
- docker上でもいける
- 実際のデモ
関連情報
Infrastructure as Code のこれまでとこれから/Infrastructure as Code // Speaker Deck
ChefConf2016参加レポート クリエーションライン株式会社 鈴木逸平
VP of EngineerのSeth FalconのKeynote
@r_takaishiさんがデモしてくれた内容やChef Automationに関しての話が中心
CEOのBarry CristのKeynote
Chef Automationの話はあるが、注目すべきポイントは下記
slowness kills
ビジネスアイディアとshipingはという要素は重要で良いアイディアはあるけど実際にshippingできたのは2年後といったものではもはや遅すぎる。 たとえどんな素晴らしいアイディアであっても遅いと全てが無くなってしまうという話。Amazonなどのサービスがなぜ良いか、当たり前のサービスを迅速にユーザにshippingし続けているからだ！！と
ここではShippingまでのスピードといってるけど、サーバのレスポンスだったり、カスタマーサポートのレスポンスだったりのスピードも同じだと思っている
ideas = easy
アイディアを出すのは簡単。shippingをどれだけ迅速にできるかが重要。shippingまで至るまでにはどうやって実現するかや乗り越えるべき障壁は色々とあるだろうが、結局はshippingできてからの話
まとめ的なもの
- Chefの製品は自分が３年前に見た時よりかなり変わってて、Chef内で完結するような製品群になってきているなと
- 日本だとServerSpecとかがあってそれなりに定着してる感あるのでInspecとかはどうかなと思ってる
- Inspecの書き方や動作はServerSpecそのままのように見えた
- Habitatも各デプロイツール+Dockerとかという部分とかぶる気がするけど、Supervisorやクラスタ機能は手軽感あったので今よりは良いのかな
- visualizeの機能は可視化は重要なので今までに無い機能でよいなと思った
- ChefConf2016のKeynoteを聞いた。英語全然得意じゃ無いけど雰囲気わかった
slowness killsの話は本当にそうだし、実現するには色々な壁があるけど、重要性をずっと説いていくことは意味あることだと認識した- 同じことを事ある後に言い続けるのはツライけどそれだけ価値があることだと思った
- 自分は不得意です
- 今回の勉強回に参加させてもらって改めて思ったのは、その先にあるProductivityやDevOpsの話に必然的に繋がって、どう事業を成長させるかという感じになって深くなっていく。
- そして本当のObjectiveにぶつかる
お疲れさまでした
API Meetup Tokyo #15 〜OpenAPI Specification (Swagger)特集〜 の勉強会に参加してきた
勉強会に参加させてもらったのでその時のメモやら
勉強会概要
発表
1. OpenAPI Specification/Swagger概要 (19:05〜19:20) API Meetup運営チーム/Apigee 関谷和愛さん @kazuchika
www.slideshare.net
- Swaggerとの関係というか歴史の話
- 今後のロードマップの話
- OAS 3.0は2.0とガラリと変わるだろうとの話
2. OpenAPI Specification を使ったスマートな API 運用 (19:20〜19:40) 株式会社 KUFU 芹澤雅人さん
- SmartHRの紹介の話
- 黎明期のAPIの話から現在に至るまでのAPIの話
- ドキュメントにSphinxを活用していたのはちょっと懐かしく思った
- 昔Pythonで作ってるプロダクトで導入してた人がいたなぁーっと
- ソースとおなじレポジトリ（ディレクトリ）にSphinxでつくったドキュメントを置く事でレビューの対象になり抜け漏れがなくなる話
- なるほどなと思った。
- インターネットへの公開領域のディレクトリとかあったら注意ですね。
- 仕様書とコードは近ければ近いほど良いは大賛成
- Swagger導入までには書きのようなステップで導入していった話
- step1 Swagger coreの導入
- step2 Swagger specの確認
- Swagger UIの導入
3. Swaggerを使用したモデルファーストなAPI開発のよもやま話 (19:40〜20:00) TIS株式会社 小西啓介さん
www.slideshare.net
- すべてが使いやすいわけではないという話
- 表示されてるレスポンスが加工されてる場合があり、HTTP statusコードが実際には違う話とかちょっとハマりそう
- 内部と外部のAPIのSwaggerを分けたくなるけど統一のがいい
- 共通化のポイントは下記
- Parameters Definitions
- Responses Definitions
- Schema Definitions
このあたりは参考になる
4. Lightning Talks by Open API Initiative members! (20:05〜20:55)
Mashape Augusto Mariettiさん ※英語トーク
下記のプロダクトで活用している話 www.mashape.com
- 個人的にはちょっと時間を作っていじってみたいと思った
- 英語のリスニングってむずいっすね。結構海外の基調講演の動画とか見てたりするんだけど、、、
Paypal 岡村純一さん
IBM 森住祐介さん
Microsoft 佐藤直樹さん
Apigee 関谷和愛さん
まとめ・雑感的な
Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code に参加してきた
勉強会に参加させてもらったのでその時のメモやら
勉強会概要
発表
"Infrastructure as Code" から数年、結果どうなったか @naoya_ito さん
日本語でいうところの冪等性=ReproducibleBuildちょっとしたキーワードだった。
自分はわりとそのままにしていた管理画面からのポチポチ業もReproducibleBuildしなきゃいけないなーと感じた。最近はDNSの設定でさえもコード化されていてサービス（プロダクト）を最速に提供する事が重要でそこに集中する為にという流れなんだろう。
AWSのIAMの設定重要っすね。
あとはモデリングの話で今の業務をそのままシステムに落とし込んで効率化や自動化を図っていくのが本質では無くて、複雑な業務をいかにシンプルにモデリングしてシステムに落とし込んでいくかが重要
自分もアプリケーション開発が主なのでアプリケーションを開発するときに考える、言語、FWの特性が今回の要件に合うかや正規化等々を想像したら分かりやすかった
最後にコンテナとかが出てきているのでモデリングがそこまで議論にならなそうって。
スライドに出てきた参考
Domain-Driven Design: Tackling Complexity in the Heart of Software
- 作者: Eric Evans
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2003/08/22
- メディア: Kindle版
- この商品を含むブログを見る
Infrastructure as Code と企業文化 @ryuzee さん
クラウドがどんどん使われ始めてインフラなのかアプリなのかという境界線がどんどんなくなっていっている(同意)
採用アーキテクチャをうまく回していくにはやはり使う側の人・組織構造もセットで変えていかないとツライはなし（=コンウェイの法則）が出てきて最近別のところでも聞いた内容だったのでやはりそうですよねって思った。
同じくその際の注意点としてどうしても横断的に見た方が良いプロダクとの一貫性やセキュリティ面は考慮しておいた方がよいと。
なので共通するチームは残る。
文化面でのチャンレンジは正直相当ツライだろうなと想像してしまった。半端な決意では出来ないというか、、、相当な覚悟が必要
まぁ一気にやろうとすると正しい事でも爆死しますね。
Infrastructure as Code のこれまでとこれから mizzyさん
現代の開発の三本柱の「バージョン管理」「テスト」「自動化」を実現した部分が大きいと。
Infrastructure definition toolsでTerraformは最近あまりよい話を聞かないなぁ。
Infrastructure as Codeを下記の分類に分けて説明していた部分はとても分かりやすかって理解の整理になった
- Dynamic Infrastructure Platforms
- Infrastructure Definition Tools
- Server Configuration Tools
- Infrastructure Services
ここでもコンテナの話やマイクロサービスの話が出てきて繋がってるもんだなと。
モニタリングとの融合の話で”テスト＝本番デプロイ前、モニタリング＝本番デプロイ後”はなるほど！
スライドに出てきた参考
Monitoring is Dead // Speaker Deck
運用・監視もコード化する。開発者が監視まで考える方法論 @songmu さん
どんどんコード化され、インフラ・アプリの境界線が曖昧になってきているし、アプリケーションエンジニアはコードを書くのが得意な領域なのでどんどん取り組んだ方が良いと思った。
I Love Webhookの話はもっと色々と持ってそうでしたね。
今の会社でも最近Mackerel使ってるので聞きやすかったです。
プロビジョニングツールはMakeで決まりだろ @katzchang さん
タイトルの釣り感がはんぱない。
プロビジョンイングツールでCofuってあったけど始めて知りました。 github.com
chefのcookbookレシピの中でmakeを書いてた過去を思い出しました。。。
まとめ
話を聞いていて最近特に調べたりする「マイクロサービス」「ThoughtWorks社」「Martin Fowler」「コンウェイの法則」とかのワードが出てきて、まぁ繋がってきますよねって感じました。DDDの話はちゃんと理解していないので勉強していかないとなと
最近Chefいじってなくて。別の同僚に任せきりになってることを反省した。Infrastructure as Codeでもちろん頑張って自分もコード書いていこうと思うと同時に構造もセットで変えていかなくちゃななー。スモールスタート。成功実例作り。んー胃が痛い
第16回elasticsearch勉強会に参加してきた
概要
下記の勉強会に参加した時のメモ elasticsearch.doorkeeper.jp
はじめに
よくある検索サービスやログ+分析と言ったところに使われるElasticSearchの勉強会
発表
LogstashとElasticsearchで作るEnterprise Search Platform Elastic Kosho Owaさん
今まではログ+分析、検索メインの使い方の紹介が多かったが、ちょっとそれとは違う話
内容的にはESP(Enterprise Search Platform)なので社内に保管・運用されている様々な形式のデータを横断的に検索するシステムの紹介と言ったところかな
Elasticsearch + Fluentのパターンで使ってる人は大多数でしたが、Elasticsearch + Logstashで使ってる人はちょっと少なくてネタになってた
以前近くにいた人と世間話をした際にその方が、社内の情シスの部門の方だった。自分はwebの人なので言い方むずいけど割と固い方もいるんだなぁと感じたが、こういう活用もあるのかとちょっと納得した。参加者の方でスーツの方が多いのはこのあたりかな
簡単に技術的なところをピックアップすると下記
- inotify
- fanotify
- vfs_full_audit
あたりを参照して
mapper-attachments-plugin github.com
あたりでExtractしてElasticsearchへindexさせている様子
あとはまだ下記の課題がある様子で改善に取り組んでいるみたいです
課題
- 検索UIが提供されていない
- 不整合発生時(sambaサーバとESの間での不整合)の解消方法
- 汎用性
- セキュリティ
企業・業界情報プラットフォームSPEEDAにおけるElasticsearchの活用 株式会社ユーザベース 北内 啓さん @tau3000
www.slideshare.net
企業、プロダクトの紹介
- NewsPicksは色々見るけどSPEEDAはあまり見ないなー。と思ってたら、前者は個人ユーザ向け・後者は法人向けという事らしい
- デモで見たけど業界ごとの詳細レポートデータがかなり充実してた
- SPEEDAは下記の役割の人がいる
- エンジニア、アナリスト、コンサルサービス（カスタマーサポートのような直接人がサポートするポジション）
本題
と言った過去を経験してElasticsearchへ切り替えてた
インデックスに関して
- 1企業を1ドキュメントとして持つ。すべて1ドキュメントで持つ。mysqlでいうと１つのテーブルにすべて突っ込むイメージ
- 財務や現地通貨、主要６通貨も一緒のドキュメントに持つらしいです
- 1ドキュメトで最大約40MB、約11万フィールドに及ぶ
そんなに1ドキュメントにフィールドを突っ込んで普通に動くんだと感心した。
しかもバージョンは1.x
企業名検索に関して
- 日本語は文字bi-gram、英語は文字uni-gramで
- uni-gramは流石にインデックスが大きくなりすぎるけど
- phrase_prefixを使う日本語は文字単位、英語は前方一致
- max_expansionsを活用して制御を加えている
- 英語ではストップワードを活用
- 小規模なデータについてはRDBのデータの内容をオンメモリにして検索させてるのでElasticsearchと併用している
- ノードの役割分けは当初なく、Full GCが走ったノードに検索が走りのたびにツライ状況に
- その後ちゃんと役割分けをして改善へ
最後にElasticsearchのバージョンアップとinner hitsに注目してると言ってたけど下記あたりをちょっとじっくり見てみるか
クローラーあたりの技術やノウハウもすごそうだなーと感じた
Elasticsearchベースの全文検索システムFess 株式会社エヌツーエスエム 菅谷信介さん
Fessというプロダクトをもとに発表されてた
www.slideshare.net
オープンソース全文検索サーバー Fess — Fess 10.1 ドキュメント
- Fessというプロダクトで古くはNamazu、lucene、Solrあたりからプロダクトに活用していてその流れからElasticsearchを使っている様子
ロール検索というユーザによって検索可能な領域を限定して検索させる機能があるらしい
plugin開発を多くしているようで下記にオープンソースになっている
- いろいろと見てみるとほぼ菅谷さん一人で書いている？w
形態素解析の辞書をカスタマイズしてクラスタに配るってゆう部分でElasticsearchに食わせる(indexさせる)時に使う辞書と検索の時に使う辞書を合わせないと期待値がずれる場合があると。確かに陥りそうな部分だなー。
LT 「ElasticsearchとGCPのネットワークでハマった話」 株式会社サイバーエージェント 平田大地 さん @daichild
すでに公開されてたのでリンクを貼っておく
ElasticsearchとGCPのTCP Keepaliveではまった話 - blog.daich.org
- GCPでの活用事例も今後増えるだろうし、新しいクラウドでのよくはまるFirewall問題の内容だった
- AWSでmulticast discoveryが使えない課題とかを思い出した。。。
- ネットワーク周りの課題はソフトウェアエンジニアからするとちょっと馴染みのないことだったりするのでデバッグの仕方とか改めて参考になった
LT スクリプトフィールドで作るランキングみたいな何か」iwag さん
elasticsearch で作るランキング - SSSSLIDE
- スクリプトは重い、比べたらもちろんプラグインのが軽いんだけど、開発のしやすさでスクリプトを使うのは利用場面ありそう
- Elasticsearchへデータを投入する前にRabbitMQ（メッセージキュー）を使ってリアルタイム性よりはデータの整合性を優先させてた
- スライドの中に出てくるfielddataはES2.x系からは
doc_valueというものが出てきてて下記あたりをちょっと追いかけたいなと思った
最後・まとめ・感想
マクロサービスアーキテクチャを数回読んだ
はじめに
今でも割と語られてるかな？マイクロサービスアーキテクチャを数回は読んだ。まぁそのアウトプットではないが色々と思うところやメモ的なものをここに残しておく
- 作者: Sam Newman,佐藤直生,木下哲也
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/02/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
各章ごとに気になった文や内容を自分なりにまとめていこうと思います
1章：マイクロサービス
まぁマイクロサービスとはいかなるものか的な内容。その中でも今までとは違う点では下記あたりがあるのかなぁと感じた
- より多くの技術的な決断を下さす必要がある点
- すべて正しい決断となるわけではないが、たとえ間違えたとしても影響は局所的になる
2章：進化的アーキテクト
マイクロサービスアーキテクチャに限った事ではないけど、アーキテクトが日進月歩なので変化は激しい。その中で一番気をつけなければいけないのは考え方を固定化させ硬直する事。これは常に自分が間違っているかもしれないという問いを自分自身に問いながら進まなければいけない事を意味する。
スタートアップで事業を立ち上げる立場にある人は割と当たり前だし、その姿勢をシステム設計にも適用しなければならないという事を改めて感じた。
3章：サービスのモデル化方法
またモデリングによる分割が時期尚早な場合が存在する。特にスタートアップ時期ではまた固まりきらない事業フェーズ（ビジネスサイドでよく言うフィジビリ時期）の時とかは注意なのかな
4章：統合
ここは結構内容の重い話が多かったと思う。まずは
- いかなる代償をはらってもデータベース統合は避ける
今までの経験上、データベースのテーブルスキーマの変更を伴う改修はやっぱり気を使うし、それなりにパワーを消費するのでちょっと避けてる部分があった。でも変化を受け入れ、柔軟に対応する上ではこのあたりも受け入れてやっていかないとなと感じた
でも弊害というかそれぞれで分割されたデータベースを持つということは独立性を高め、変更を恐れなくなるとは思うけど。同じ内容のデータを複数持つことになったり、データベース間で同期をとりたい場合やトランザクションで整合性をとりたい場合はでてくるよなぁー。
そうなると共有のライブラリ(API)でデータの更新や参照するような仕組みは完璧に補えるわけではないけど案として浮かぶ。
このへんは本でも指摘されてるけど今まではDRY（Don't Repeat Yourself）という言葉があるように重複するコードを書くことは必要以上にコードが増え、可読性も落ちて良くないとされてきた。けどマイクロサービスでは同じマイクロサービス単位内ではDRYだけど、別の境界づけられたサービスではokという事だった。
むしろ、結合を産んでしまうので同じライブラリだが、それぞれ独立して持つべきという感じ。１つのマイクロサービスは１つの独立した会社として見た方が腑に落ちるかも
次に
- オーケストレーションよりコレオグラフィ
音楽で言うところの指揮者がいてオーケストラによる演奏とコレオグラフィ（振付け師）による舞台みたいな対比
少々概念的な話で
- オーケストレーションは、中央の指揮者が他のサービスを呼び出し等を行い処理する動き
- コレオグラフィはそれぞれのサービスが自律的に動き、他のサービスに働きかけていく感じ
まぁSVNとGitみたいな感じかな。でも全てコレオグラフィに寄せることはできないので思考としてそう持つべきという内容と理解
次に
- ポステルの法則（英語: Postel's law）
送信するものに関しては厳密に、受信するものに関しては寛容に
なんかこの言葉だけでとてもしっくりきてしまった。今のAPIを活用したクライアント実装はすでにこれだなと。
5章：モノリス（一枚岩）の分割
ここでも改めて思ったけど、データベースの分割はむずいなーと感じた。サービス（ビジネス）モデルに基づいた分割が全然理解できてないんだろーなー。
本の中でもトランザクションがが必要な時は、キューやログファイルを使い後でリトライの仕組みを裏で幾つか持ち、結果整合性（eventual consistency）で保つことと。。。
むしろお手間な感じがしてしまった。
ここは結構いろいろな意見があるだろうし判断に難しいところなので本でも下記のような言い方をしてた
本当に一貫性を維持したい状態に遭遇したら、まずは分割を避けるためにあらゆる手を尽くします。本当に精一杯やってみてください。本当に分割を進める必要がある場合にはそのプロセスの完全に技術的視点から離れ、トランザクション自体を表す具体的な概念を実際に作成してください
やり尽くした上での選択なんだろう。
あとはデータポンプ、イベントデータポンプといったワードも出てきてETLと呼ばれるような手法も活用すべきだと。
ETLで思い浮かぶのはtalendとかかな。。。
6章：デプロイ
ここでは改めて自動化重要性を感じた。インフラのイミュータブルサーバの話から、アプリケーションのビルド、各種自動テスト等々本当にどれもスキップできない構成がある中で効率的に且つ何度も回す必要があると。
7章：テスト
まずはモックとスタブの違いはわかりづらく、ここをしっかり抑える必要がる。
モックとは
- ユーザーインターフェイスの振る舞いを模倣したもの。。。。個人的な理解でいうと、例えばPHPUnitで
getMockBuilderというメソッドがある。まぁこの振る舞いをモックと理解している getMockBuilder
- ユーザーインターフェイスの振る舞いを模倣したもの。。。。個人的な理解でいうと、例えばPHPUnitで
スタブとは
- テスト時の呼び出し時にあらかじめ用意された結果を返す。通常はテスト用にプログラムされたところ以外では使わない。接続先のサービス(API)のインターフェースが変われは追随する必要がある
原文を一応あげておくけどMartin Fowlerの説明はちょっと分かり難い？英語の問題もあるけど。 martinfowler.com
必然的に疎結合が多くなるのでテスト時はスタブ化してテストしてくことは必須でThoughtWorks社から便利なツールが色々ある様子
あとはE2Eテストの存在がある。今のチームでもE2EテストではCapybaraを試してみてるが、やはりメンテコストが結構かかる。でもやらないわけにはいかないし、メンテして1日終わってしまう事もある。
ここで初めて複数のチームが共有所有する事がベストプラクティスではないかとある。今まで独立性、自律性に重きを置いた思考であったが、E2Eテストに関しはちょっと違う。
次に
- カナリアリリース
ここは具体的な方法をもっと知りたいなぁー。会社によって色々とやり方あり出し。そーいやリーンスタートアップってゆう本にもこのワード出てきてた。
- 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
- 出版社/メーカー: 日経BP社
- 発売日: 2012/04/12
- メディア: 単行本
- 購入: 24人 クリック: 360回
- この商品を含むブログ (93件) を見る
すべて完璧な状態でリリースは結構難しくて、平均故障間隔と平均修復時間のメトリックスを気にしながら絶妙なバランスが必要。そのサービスが担う役割によって当然話は変わってくるけど基本的にこのトレードオフの関係を理解しておくこと
8章：監視
- 相関IDを活用
サービスの疎結合と高凝集性があるので障害・不具合が出てきた時に追いかけて、特定しづらくなる。そこで相関IDを活用して効率化を図る
- 合成監視
一般的なCPUやメモリのメトリックではわからない。偽イベントを生じさせてそこから得られる結果からシステムが正常に稼動しているかを推し量る考え方でセマンティック監視とも呼ばれるみたいです。この観点は今まであまりなかったのでプロダクトに生かしたいなと。
9章：セキュリティ
境界内のアクセスに対するセキュリティはほぼなく、暗黙的に信頼のもとにできている
ここで出てくるセキュリティの項目は割と一般的な項目であり、様々な役割のサービスごとに最適なセキュリティ対策を実施すべし。ですべてにおいて厳しいセキュリティ項目を設けなくとても良い。
- 間違っても自分で暗号化実装をしてはならぬ
間違っても手を出しません。
10章：コンウェイの法則とシステム設計
ここはなかなか重い話だなぁ。結局はソフトウェアは人が作るし、運用していくのは人、組織であるからコンウェイの法則はまぁその通りと思う
でも逆向きのコンウェイの法則の話があったけど、業態のパラダイムシフトが必須の状態が追い風となってると思う。こう言ったものがセットでないとなかなか厳しいなぁと感じた。
会社によってシステムアーキテクチャがどの程度の発言権があるかによるが、日本の場合は当事者がファンダーとかでない限り、この考えを浸透させるのは厳しいだろうな。
システムアーキテクトと組織構造がセットで、その２つを一致させないとツライという話。。。想像しただけでもツライよね。
11章：大規模なマイクロサービス
- Swaggerの話が出てきてふと社内勉強会の内容を思い出した。下記です。ちょっと点が繋がった
www.slideshare.net
- CAP定義
整合性（consistency）、可用性（availability）、分断耐性（partition tolerance）があり、トレードオフの関係値になっている。頭文字をとってAP,CPシステムという感じになりケースバイケースで判断していく
本書を読んでのまとめ・感想的なもの
- 何度読み返したかわからないけど、今回この本を読んで残ったものは
コンウェイの法則,DBの分割(整合性の分割)の部分かなぁ。ムズすぎ。 - DBの分割はコストもかかるし、かなり慎重にすべきだなぁー
- 会社ってどこもセールスの人がいてそれなりの営業的な文化がある
- よくその文化の中の文脈で
一枚岩というワードが出てきてone for all的にチームとして頑張ろうという流れがある。別に普通に賛成なんだが、たまにその事がモノリスの弊害のようになってて、逆に効率が悪いというかってゆう場面を思い返した。協調性がないって思われそうだから何も言えないけど。そーゆー落とし穴は誰かが気をつけなければいけない。
- よくその文化の中の文脈で
- 自律的なチームはまさにそうで、専門性をどんどん高めていかないといけないし、どうしてもモクモクとやる姿が多くなっちゃうよなー
- 他の手法、考え方でもそうだけど、決して銀の弾丸ではない
