マイクロサービスアーキテクチャ読書メモ 2章進化的アーキテクト
黒字部分は本書の抜粋。赤字部分は私のコメントです。
不正確な比較
アーキテクトになるのは、建築士になるのに比べて必要とされる勉強量が少ない
イギリスでは建築士と呼ばれるまでに最低七年間の勉強が必要
アーキテクトと建築士の間の類似点は少ない
この話で思い出すのは耐震偽装で逮捕された姉歯建築士である。もう１０年以上前の話なので若い人は知らないかもしれないが。建築士は間違った設計をすると建築基準法で逮捕される。アーキテクトはシステムの設計をごまかしても逮捕されない。この差はデカイよ。。。
進化するアーキテクト像
ソフトウェア開発では、建物の設計や建設を行う場合よりも、急に要件が変更される
完璧な最終製品を作成するという考え方を変え、代わりに適切なシステムが得られるようなフレーウワークを作成することに重点を置く
アーキテクトは建築家というよりもむしろ都市計画家に近い
建物を建てるのではなく、都市を区画する
区画設定
区画（サービス）間の連携には注意が必要
あるサービスがRESTを使い、別のサービスがProtocol Buffers、また別のサービスがJava RMIという具合だと統合は悪夢となる
「ボックス間で起こることについて心配し、ボックス内で起こることには寛大になる」べき
原則に基づいたアプローチ
戦略的目標
戦略的目標は組織が目指す方向性なので、技術がその目標に一致するようにする必要がある
原則
原則は目標実現のための規則で、ときどき変更される
プラクティス
プラクティスは原則を実行する方法で、原則よりも頻繁に変更されることがある
コーディング指針
ログの保管
HTTP/REST
必要な標準
監視
サービスをまたがったわかりやすいシステム健全性のビューを作成できることが、不可欠
インターフェース
標準の数は１つが適切
技術やプロトコルの選択だけでなく、RESTのエンドポイント名に動詞と名詞のどちらを使うか、リソースの改ページの対処をどうするか、エンドポイントのバージョニング等も含まれる
アーキテクチャ上の安全性
不適切な下流呼び出しから適切に身を守るようにしなければならない
サーキットブレーカーの利用
コードを介したガバナンス
指針に従っているかを確認するのに時間を費やすのはあまり楽しくなく、各サービスが実行すべきすべての標準を実装するという負荷を開発者に負わせるのも楽しくない
手本
推奨したい一連の標準やベストプラクティスがある場合、開発者たちに示すことができる手本があると便利
カスタムのサービステンプレート
DropwizardやKaryon等のマイクロコンテナを使うと、適切な実装をすぐに実現できる
サービステンプレートが適用されない新技術スタックを導入すると、労力がかかるだけでなく間違いが起こりやすくなる
押し付けられた強制的なフレームワークでチームのやる気や生産性が損なわれる例が多い
共有コードのリスクを削減するために、サービステンプレートを手動でコピーする運用をとるケースもある
（サービステンプレートのアップグレード容易性vs結合のリスク）
現在はSpring BootのシェアがDrowizard, Karyonを圧倒している。
サービステンプレート戦略は、DRY原則を逸脱しているので、一見微妙に思えるが、実践的にはかなり有力なやり方だろう。最初はサービステンプレートで運用して、ある程度成熟したところで順次共有コードに切り替えていくのもありかも。
技術的負債
例外処理
十分な例外が見つかったら、いずれは原則やプラクティスを変更して世界の新しい認識を反映する
中央からのガバナンスと指導
ガバナンスは構築しているものがビジョンに一致していることを保証し、必要に応じてビジョンを進化させること
アーキテクトの仕事と責務は多岐に及ぶので、ガバナンスをアーキテクト一人で担当すべきではない
ガバナンスはグループ活動である。十分に小さなチームでの非公式な雑談の場合も、広範囲での公式なグループメンバーとの組織的な定期会議での場合もある。
Flume1.7がリリースされました。
全く話題になってない気もしますが、Flumeの最新バージョンである1.7が先日リリースされました。
何と言ってもこのバージョンアップの目玉は、Taildir Sourceのサポートでしょう。ログファイルをtailするときに、従来のExec Sourceでtail -fするやり方を採用すると、せっかくのFlumeの持つend to end reliabilityが発揮できませんでしたが、Taildir Sourceを使うとログの収拾漏れが無くなるようです。
またKafkaのサポートが大きく変わり、0.9をサポートするようになった一方、0.8以前はサポートしなくなったようです。Kafkaと連携してるサービスでFlumeのバージョンをあげると即死すると思われるのでご注意を。
マイクロサービスアーキテクチャ読書メモ 1章マイクロサービス
黒字部分は本書の抜粋。赤字部分は私のコメントです。
マイクロサービスとは
強調して動作する小規模で自律的なサービス
小さく、かつ１つの役割に専念
凝縮生（関連するコードが集まるようにすること）が重要
単一責任原則「変更する理由が同じものは集める、変更する理由が違うものは分ける」
Jon Evansはマイクロサービスを「２週間で書き直せるもの」と定義している
サービスが小さければ小さいほど、マイクロサービスアーキテクチャの利点と欠点が最大化される。
マイクロサービスのサイズについて、「２週間」という具体的な数字を示している。標準的なスクラム開発だと、ちょうど１スプリント分だろう。これ以上小さくすると利点よりも欠点が大きくなるケースが多くなる。
自律性
マイクロサービスは独立したエンティティ
サービス間のすべての通信はネットワークを経由して呼び出す
黄金律は「他には何も変更せずに、単独でサービスの変更やデプロイを行えるか」
主な利点
技術的異質性
サービスごとに異なる技術を使うことができる
それぞれのサービスで最適な技術を使える
リスクが低いサービスを選んで新技術を試すことができる
複数の技術の採用にはオーバーヘッドが伴う
サービスごとに異なる技術を使えるという点は、マイクロサービスの利点として喧騒されることが多いが、必ずしも最適解という訳ではない。むしろ本書で紹介されているNetflixやTwitterのように利用可能な技術に制約を課しているところがほとんどだろう。じゃないといずれメンテナンスが破綻して収拾不能になると思われる。
回復性
マイクロサービスではサービスの全体障害に対処し、それに応じて機能低下させるシステムを構築できる
究極的には全てのサービスがなんらかの機能のSPoFになってしまうと思われるので、マイクロサービス化をすると、システム全体で見たときの狭義でのサービス稼働率は下がることになると思う。ただエラーハンドリングを適切に実施することで一部機能を落とした状態で縮退運転をさせることが可能になり、結果として*しぶとい*システムになる。
スケーリング
デプロイの容易性
組織面の一致
アーキテクチャを組織によりよく一致させることができる
１つのコードベースで作業する人数を最小化し、チームの大きさと生産性を最適化できる
チーム分散の問題を解消できる
私の所属してる部署は開発チームが世界中に分散してるので、このチーム分散による弊害を肌で感じている。特に時差の大きいチーム同士で、一個のレポジトリを開発していくのは悪夢だ。この状況を改善できるだけでも、マイクロサービス化を進める意義はあるだろう。
合成可能性
第三者がサービスの機能を再利用しやすい
交換可能にするための最適化
サービスが小さいと実装置き換えや削除がしやすい
サービスをリプレースしたり破棄するために、わざわざマイクロサービス化の改修を行うなんて、いかにもまどろっこしいやり方で予算を取るのも大変そうだが、ビッグバンリプレースの困難さ（不可能さ）を思えば、むしろそうすべきだと思う。
他の分解テクニック
共有ライブラリ
共有ライブラリの欠点
技術的多様性が失われる
ライブラリは同じ言語であるか、少なくとも同じプラットフォームで動作しなければならない
システムの各部を独立してスケールさせられない
新しいライブラリをデプロイするにはプロセス全体をデプロイし直さなければならない
ビジネスドメイン固有ではなく組織内で再利用したい一般的なタスクのためのコードを作成することは、ライブラリの候補
モジュール
ライブラリより高度なライフサイクル管理が可能で、プロセスを停止せずに変更が可能になる等の利点がある
適切に分解された独立したモジュールを作ることは技術的には可能だが、実世界では、プロセス境界内のモジュール分離の約束が守られたことはほとんどない
Javaのモジュール化の仕組みであるOSGiは実際のプロダクトで導入を試したことがあるが、管理コストとベネフィットが全く見合わないので早々と破棄した経験がある。あれをまともに運用できてるシステムはどの程度あるのだろうか？
銀の弾丸などない
マイクロサービスは金のハンマーとして使うと好ましく無い選択となる
マイクロサービスには分散システムに関連するすべての複雑さがある
私の感覚だとマイクロサービスはまだそこまで流行ってないと思うが、今後メディアとか偉い人たちが口にするようになったら要注意だろう。マイクロサービスが有効な状況は限られている。
ある三味線の名手が語った指導の真髄
そう言えば、ある津軽三味線の名手の話でこんなのがあった。その人が若い頃についていた師匠は、住み込みの弟子として彼が家に上がって以来数年、教えらしい教えはただ一言。「とにかく外へ行って弾け！」だけだったそうな。 で、彼は「なるほど、家の中で閉じこもって弾いていては小さな音楽になるばかりだ。外へ出て大自然と向かい合い、それに負けない大きな音楽をつかみ取れ、と言うことなのだな」と一念発起し、雨が降っても雪が降っても、毎日毎日外に出て行って海や滝や風に向かって三味線を弾き、修行したという。 やがて、彼はその世界で押しも押されもせぬ名手となり、「これも、大自然と向かい合って弾け、と教えてくださった師のおかげです。」と言うと、師はこう答えたそうだ。 「そんあことは言っとらん。ただ、家の中で弾かれるとやかましくてたまらんから、外へ出て弾け、と言っただけなんだナ。」
出典は吉松隆の楽勝!クラシック音楽講座ですが、この話は多分捏造だと思う。
三味線の話なだけにね！！
プレシデント編集部調査による、仕事に効く落語ベスト５
私は引退したらタクシーの運転手か落語家になりたいと所望しておりますが、運転下手だし滑舌悪いので、どちらも実現困難な情勢にあります。
それはさておき、最近落語を聞き始めたのですが、次の書籍に、仕事に効く落語ベスト５というものが載っていたので紹介いたします。
年収1000万円以上のビジネスマン679人に調査をして集計したらしいです。余談ですが、この本の著者は「年収1000万円以上の人は落語好きが多い。だから落語を効くと仕事ができるようになる！」と主張してますが、ただ単に年収高い人は平均年齢が高いから落語好きが多いだけの気がしますｗ
それでは、さっそくランキングをベスト５を紹介してきます。
百年目
「聞いて参考になった噺」ダントツで第１位に輝いたそうです。
中村仲蔵
淀五朗
柳田角之進
古今亭志ん朝 (三代目) Shincho Kokintei 柳田格之進 落語 Rakugo
芝浜
立川談志 Danshi Tatekawa 芝浜 落語 Rakugo
ソーシャルゲームに宿るバーチャルボーイと横井軍平の魂
最近読んだ『横井軍平ゲーム館』という書籍内に興味深い一節があったので転載する。
ご存知のとおり、バーチャルボーイは商品としては失敗に終わった。
あまりにもマニア向けすぎると市場に受け取られたからだ。
ところが、横井氏の発想は違った。
競争の時代に入ったゲームの世界をもう一度原点に引き戻せないかという挑戦だったのだ。
バーチャルボーイはマニア向けの商品ではなく、ゲームにあまり馴染みのない初心者を狙ったのだという言う。
ゲームとは本来暇つぶしのためのものである。ところが今のゲームは、非常に複雑になってプレイヤーに高度なテクニックを求めるものや、プレイするのに膨大な時間がかかるものが多い。
確かに子供たちやゲームマニアの間ではこのようなゲームは高い評価を受けてはいるが、それ以外の人たちはまったく入り込む余地がなくなっているのも実情だ。
（中略）
ゲーム人口が確実に先細りになっている。これをもう一度引き戻そうというのがバーチャルボーイの挑戦だった。
ゲーム内容のマニアック化、ゲーム人口の減少という問題は、バーチャルボーイの発売された20年前にすでに顕在化していた。そしてそれは最近まで進行していた。そう、ソーシャルゲームゲームが世に出るまでは。
ボタン連打で札束で殴りあうだけのゲームはさすがになりを潜めるようになったが（まだあるのかもしれないけど）、それでも専用機に比べるとほとんどの操作が大幅に簡易化されており、金さえ積めばバカでもクリアできる。金払ってアイテム買えば時間がなくても大丈夫。
結果として今までゲームを離れていた大人達がゲームに戻って来た。意図せずして横井軍平さんの念願をかなえてしまったのである（なんてこったい）。
つまりバーチャルボーイは現代に蘇ったバーチャルボーイであると言えよう。
銭にまみれて変わり果てた姿となったバーチャルボーイを見て、横井軍平さんは何を想うか。。。「コレジャナーイ」と絶句するのは間違いないだろうｗｗｗ
アジャイルなリメイク
開発には４つのファクターがある。すなわち、品質、納期、予算、機能である(byアジャイルサムライ)。
ウォーターフォールは、事前に調査・設計を行うことで、妥当な納期、予算を事前に算出する開発モデルである。
対してアジャイルは、いくら入念に調査・設計したところで正確な納期、予算の見積もりはでないというスタンスで、調査・設計もほどほどに開発を始めてしまう。当然、進捗にブレが出てくるのだが、これは機能の量を調整することで解決する。
つまり進捗に遅れが出た場合、ウォーターフォールでは納期・予算に影響が及ぶが、アジャイルでは機能の量に影響が及ぶ。これがウォーターフォールとアジャイルの大きな違いである。
アジャイル開発では実装すべき機能に優先度を付け、優先度の通りに開発することが求められる。でないと進捗によっては重要な機能を欠いた状態でリリースをせざるおえない状況になりうる。特にリリースのために絶対に欠かすことができない優先度MAXの機能のみが実装された状態をMVP(Minimum Viable Product)と呼ぶ。他にも似たような呼び方があった気がしたけど忘れた。
例えばファミコンのドラクエ４では真のラスボスになるはずだったエビルプリースを実装せず、デスピサロを倒すところで開発を打ち切りリリースをしている。これは工数ではなく容量的な問題で実装を見送ったらしいが、これは優先度をコントロールしてリリースを成功させた例といえるだろう。
この手法がとれた理由の一つはドラクエ４が当時新規開発案件であり、MVPを小さく保てたからだ。もしエビスプリーストだけ消してもまだ足りなかった場合は、例えばカジノをなくす、トルネコを葬り去る、などの手段がとれたはずである。
しかしこれがリメイク版の開発だと話が変わってくる。
スマートフォンのリメイク版ドラクエ４が、工数の関係でストーリーがエスタークで終わってしまったり、カジノが無かったりしたらユーザレビューは大炎上間違いなしである（トルネコはいてもいなくても大差ないので多分大丈夫）。リメイク開発は、新規開発に比べて機能を削りづらい＝MVPが大きくなる傾向にあるといえよう。
前述の通りアジャイル開発の肝は、進捗のブレを機能の量を調整して納期を守ることにあった。これを機能を調整できないリメイク開発に適用してしまうと、プロジェクトの中盤以降で品質、納期、予算、機能全てが制御不能な状態に陥り、プロジェクトが破綻する。リメイク開発では、アジャイル開発であっても事前に調査・設計をある程度の確度をもって行い納期の目処をつけた状態で開発に着手するか、納期に十分な余裕をもたせるべきである。
