タグ: Microservices

「水平型から垂直型への移行」によって、今までアプリケーションのビルドまで面倒を見ればよかったアプリケーション開発者は、（マイクロ）サービス開発者となって、サーバーの構築 (Provisioning) から運用の一部まで面倒を見ることになった。一つ一つのサービスの独立性が高くなり、開発者あるいは開発チームの自律性は高まるが、やることが増えた分、外部に対する責任をより明確にしておかないと運用やメンテナンスの局面で様々な問題に直面することが予想される。

前回も少し触れたが、開発者やチームの責任を考えるときは、ソフトウェアのモジュール、あるいはオブジェクト指向でいうところの「責務 (responsibility)」の考え方が参考になる。まずシステムが果たすべき役割を検討して、そこから個々のサービスの責務を割り出し、その責務を実現することを第一優先とする。責任を明確にする理由の第一は、優先度に沿ってリソースを効率よく分配することである。「そもそも我々は何のためにこのシステムを作っているのか」という組織やチームのゴールが共有されてないとバランスの悪いリソース配分をしてしまう危険性が高くなる。

よくある問題の一例として、技術者が技術者の責任を考えると、この優先度の考え方が欠落して必要以上に内部の問題に耽溺してしまうということがある。例えば、技術者の間でよく行われる成果物のチェック方法としてコードレビューがある。スケーラビリティやセキュリティといった比較的目的が明確で判定しやすい指標はよいのだが、可読性や保守性といった、人によって判断が分かれることが多い指標は、無駄に議論が長引いたり、最悪なケースだと技術者同士の衝突に発展してしまうケースもある。

プログラムデザインの良し悪しを判断する時に厄介なのは、重要性が高いものほど多くの人間の同意を取るのが難しくなることである。関数やメソッドレベルの設計はまだ良くても、クラス・パッケージレベルやフレームワーク、アーキテクチャレベルになると、必要になる前提知識も増え、考え方のスペクトラムも大きくなるため、宗教論争的になって同意に至るのは容易ではない。結果的に、声が大きい人の意見が採用されるか、衝突を避けるために同意しづらい事項についてはスルーして、反論されづらい些末な指摘ばかりを繰り返すことになる。

このようなことを避けるため、レビューをするとしても出来るだけ価値の高い外部視点のもの、例えばテストコードをレビューすることを過去の現場では奨めてきたのだが、これも現実にはなかなか難しかった。技術者同士でレビューするとすれば、単体から結合テストレベルのコードになるが、テストの価値が相対的に低いので些末な感じは否めない。受け入れテストなど、もっと上位のテストになれば、ユーザー視点からのレビューも可能になるというのが、Acceptance Test Driven Development (ATDD) などの考え方であるが、以前の記事でFitの失敗を紹介したように、この分野もなかなか前途多難である。

さて話を戻すと、まずサービス開発者の責任を明確にして、責任を果たす限りは自由な裁量に任せるという形にした方が、プロジェクトの参加者全員にゴールへの意識を持たせつつも、無駄なコミュニケーションコストを省くことが出来るし、ゴールと関係ない内部の詳細に耽溺することも無くなる。というわけで、次回以降では、まずサービスの受益者は誰かということを考えて、そこからサービス開発者の果たすべき責任を一つ一つ定義してみたいと思う。

たまチームで管理しているGitHubリポジトリの数もどんどん増えてきて、今ではデプロイ可能なサービスだけでも20個ぐらい、リポジトリの総数は30を超えた。既に書いた通り、これらのサービスに共通するサーバーの構築 (Provisioning) と管理は、これまで一人のインフラ担当者が頑張って面倒を見てきた。しかしこのままサービスの数が増えていくと、インフラ部分がボトルネックになって効率が大きく損なわれることが目に見えている。そこで Deployment や Provisioning の管理方法を変えよう、というのが前回の話であった。

この方針変更をたまチームでは「水平型から垂直型への移行」と呼んでいる。

従来の管理方法だと、アプリケーション開発者はアプリケーションのビルドにだけに注力すればよい一方、インフラ担当者は、すべてのアプリの Deployment、サーバーの Provisioning や Monitoring まで面倒を見なければならなかった。

これを垂直型に移行すると以下のようになる。

アプリケーション開発者はサービス開発者となり、アプリケーションのビルドに加えて、そのアプリケーションが動作する環境の Provisioning も担当し、最終的には Server Image をアウトプットするようにビルドプロセスを変更する。インフラの共通部分は最小限に抑えて、チームメンバー全員で共同管理出来るようにする。

水平型も垂直型も、それぞれ一長一短でありトレードオフがある。インフラの共通部分を厚くすれば、同じような構成のサーバーを一括で変更したり、多くのProvisioningコードを再利用出来る一方、共通部分と各アプリケーション開発者間で生じるコミュニケーションコストは馬鹿にならない。

あるいは、高度に訓練されたチームであれば、メンバーの誰もが共通部分（インフラ）とアプリケーションを行ったり来たりしながら自在に開発出来るのかもしれない。しかし、残念ながら我々たまチームはそこまでのレベルには達していないので、共通管理する部分を出来るだけ薄くして、後はアプリケーション開発者の裁量に任せてみることにした。

この考え方はソフトウェアのモジュール（あるいはオブジェクト）の考え方に似ている。モジュールは外部との責任を明確にする一方、内部構造については隠蔽しておくのが望ましいとされる（責任を果たす限り内部の詳細を問題にしない）。これはモジュール間のコミュニケーションコストを最小限にして、大量のモジュールが柔軟に連携出来るようにするための考え方であり、これをそのままサービス開発に応用するとすれば、アプリケーション開発者は、そのアプリケーションが外部に果たす役割を明確にする限り、他の開発者はその内部のことを（とりあえずは）気にしなくて済む。

サービスの数が増えていくのと同時に、技術の進歩に伴って、サービスの粒度が小さくなってきている。サービスが Microservice化すると、一つのリポジトリを複数の人間が管理するよりも、一人の人間が複数のリポジトリを管理するケースの方が増えてくる。その意味でも、コミュニケーションコストを抑える方法を考えておかなければならない。

個々のサービス開発者に課せられる責任は、オープンソースプロジェクトの開発に要求されることに似ている。そのプロジェクトを誰かに使って欲しければ、それが外部に提供する価値について、そしてその利用方法について、第三者が分かる形で説明する必要がある。ここで何を説明するべきかという最小限のラインを考えることが垂直型の勘所ではないかと思う。

ソフトウェアアーキテクチャと組織の構造

Martin Fowler氏が記事 Microservices の中で言及しているように、コンウェイの法則によれば、ある組織が開発するソフトウェアのアーキテクチャはその組織の構造をそっくりそのまま反映した形になる。今回の話で言えば、水平型のアーキテクチャを生み出す組織は職能で分けられた水平分業組織であり、垂直型の場合は cross-functional な垂直統合チーム型組織になる。

既に述べたように、いずれも一長一短があるため、どちらが良いとは一概には言えない。たまチームではたまチーム独自の事情があって、今回は垂直型への移行を試みることになった。この移行によって開発のやり方やアウトプットがどう変わったかはこのブログで逐一レポートする予定である。

最後に一つだけ垂直型への期待を述べるとすれば、現代は専門領域の境界がめまぐるしく変化する時代である。一つの専門領域に留まっていたら、あっという間に時代遅れになることも珍しく無い。このような時代においては、多様な領域に横断的に関わり、それらの融合をもって競争社会のアドバンテージとするべきであり、そういう意味ではチームだけでなく、個人にも cross-functional な能力が求められるのではないだろうか。

• 参考
  • Microservices
  • Scaling with Microservices and Vertical Decomposition | dev.otto.de