マイクロサービスアーキテクチャ本の感想（１章、２章））

年末年始ですね。この長期休暇を利用して停滞していた意識改革を行うために、O'Reillyのマイクロサービスアーキテクチャを読み始めたので読んだ部分から感想をメモしていきます。（一気読みするには内容が濃いのです...）

１章「マイクロサービス」を読んで

1章ではマイクロサービスって何？から入り、それは「強調して動作する小規模で自律的なサービス」であると定義しています。小規模とは組織や人それぞれの感覚によるとしながら一例として「2週間程度で書き直せる」程度の規模であること、自律的とは分離されて他に影響を与えずに変更することができること、としています。

マイクロサービスによるメリット

マイクロサービスがどのようなメリットを生み出すかについては、

• 分離によってサービス単位で異なる技術を採用することができるという「技術特異性」
• 各サービスが分離されていることで単一サービスの障害影響がまるで隔壁が存在するかのように広まらないという「回復性」
• 分離されているんだから特定のサービスの規模だけ大きくできる「スケーリング」
• 特定のサービスだけ変更できる（独自のライフサイクルを持てる）「デプロイの容易性」
• サービス単位に柔軟に人をアサインできる「組織面の一致」
• 多様化するサービスの提供形態に応じるために、サービスを部品として組み合わせられるという「合成可能性」
• 小さいコードであることで書き換えが容易であることから「交換可能性」
• マイクロサービス化の結果としての「SOA」の実現

が挙げられています。

似て非なる分解技法

「あなたとは違うんです」byマイクロサービス
として、共有ライブラリとモジュールについて何が違うのかが解説されています。共有ライブラリについてはその特性として"結合"が生じやすく、変更の容易性が失われてしまうケースが多いことが問題としてあること。モジュールは適切に分離されたモジュールを開発することがそもそも大変であり、共有ライブラリと同様に結合性をもってしまうケースが多くなりがちとあります。

定番のあのワードで釘を刺される

マイクロサービスは銀の弾丸ではありません。と1章の終わり前に明記されています。上述したメリットを得るためにはマイクロサービスの複雑さ、難しさに挑む必要があるんだぜ？だから2章以降もしっかり読みなされ、と釘をさされます。

1章の感想

ふわっとしていたマイクロサービスという言葉がかなり明確な形になりました。特に「技術特異性」の項でサービスごとに異なるストレージを選択している図が提示されていて、それを見てマイクロサービスってこういうことかと腑に落ちました。

2章「進化的アーキテクト」を読んで

2章ではマイクロアーキテクチャを設計するアーキテクトの心得について語られます。章の冒頭からアーキテクト(建築士)という言葉がソフトウェア開発におけるアーキテクトにはふさわしくないという否定から入り、本来の意味でのアーキテクトは物理建築のような見通しがたって物理的制約を受けるものを設計する役職であるに対し、ソフトウェアのアーキテクトは不確実性が多く柔軟性が求められるから勘違いするなよ、と言われます。

進化的アーキテクト

アーキテクト(建築士)という言葉を否定した上で、ソフトウェアのアーキテクトがどのような役割を持つべきかというと、進化し続けるソフトウェアと同様に常に進化が求められるとし、建物を建てるというよりはシムシティを例に「都市計画課」が役割として近いとしています。決められるのは区画までで、区画内で開発者がどのような建物を建てるのか、ユーザがどのように建物を利用するのかまでは制御できないとしています。その上で開発者もユーザも満足が行く区画配置を行うのが進化的アーキテクトの役割であると定義します。

良いアーキテクトへの道しるべ

ではどうすればよいのか？開発者もユーザも満足させるアーキテクトになるためのノウハウとして、

• 区画間で起こることに目を向けるべし
• 各区画の中に積極的に入り、状況を把握すべし（ここちょっと矛盾している気がしたけど、制御はしなくて良いから状況は理解しろってことだと読んだ）
• 組織が決定した戦略的目標を理解し、原則とプラクティスを持って各区画を正しい方向に導く必要がある
  • 原則とは戦略的目標に行動を一致させるための規則集（有名なHerokuの12Factorsは設計原則週)
  • プラクティスとは開発者よりの原則を実行するための指針（CI/CDを実践する、みたいな)
• 標準的な機能を定義して適切な監視、インターフェース、エラーコードを実装する
• 手本とサービステンプレートを利用したコードを介したガバナンスの実践
  • 手本とは実際に稼働しているマイクロサービスのコードが望ましい
  • サービステンプレートとは上述した「標準的な機能」を提供できるようなテンプレートをさす
• 技術的負債を把握し、全体的な視点から対処すべき負債を洗い出す必要がある
• 原則に沿わない技術もある程度許容し、ただし「例外処理」の理由をログとしてしっかりと残しておく
• 上述した項目を個人で抱えるのではなく、グループとしてガバナンスを形成することが望ましい
  • ただしグループが誤った方向へ向いていると判断した場合は、毅然とした大度で拒否するべし
    • ただしグループからの信頼と、グループのやる気を失うリスクを十分に承知して、慎重な判断をすべし（ここは本当に著者の苦しみが伝わってくるところでした）
• マイクロサービスは小さいがゆえに開発者が所有しやすく、成長を促そう

とした上で、章のまとめとしては「進化的アーキテクト」はこれらを全部綱渡りしつつ実践する必要があって、それを達成するには経験を積むしかないけれど、とにかく固定(停滞といってもいいかも)せずに努力していこうぜとしていました。

2章の感想

2章は言葉の勉強と進化的アーキテクトという超人の物語だったなという感想です。原則、プラクティス、戦略的目標といった言葉の意味を学べたということは、人にも説明しやすくなったということで、自分たちのサービスのマイクロサービス化を実践していく上で認識の共有に役立てることができそうだと思ったし、進化的アーキテクトに求められる様々な要求を通してマイクロサービスに必要な考え方を教えられたと感じています。