2016年8月5日金曜日

スケーラブルな開発と Conway’s law

Twitter で自分が関わっているサービスの開発者の数は、この 4 年間で約 5 倍に増えた。エンジニアの数とサービスの開発・運用について考えてみたい。

2, 3 人の小さいチームが作ったサービスが徐々に複雑になり、アーキテクチャの大きな変更がないまま、複数のチームに属する数十〜数百人のエンジニアが関わるようになる、ということはよくある。このときの問題点として、次の 3 つが考えられる。

コードレビュー

数十人が関わるサービスは大抵コードが複雑で、全体像をしているのは一部のエンジニアだけという状況になる。そして、その一部のエンジニアが「コアチーム」となり、コード変更の決定権を持つ。
エンジニア全体の増加に比べて、コアチームのメンバーは増えない(システムの複雑性が上がっていくので、全体を理解しているエンジニアの数が比例しない)ので、コアチームのレビューが開発のボトルネックになる。

デプロイ・インシデントレスポンス

エンジニアが増えると、一つのデプロイに含まれる変更の数が増える。当然、デプロイが失敗する確率(機能的なバグやパフォーマンス低下など)が上がる。また、失敗した時にどの変更をロールバックすべきかの判断が難しい。デプロイできるのはコアチームだけになり、また、デプロイの頻度が下がる。

リソースプランニング

そのサービスが使用するリソースの予測が難しくなる。
一つのサービスの中にいくつもの機能が含まれるので、ダウンストリームのサービスへのリクエスト数、CPU / ネットワーク使用量、ストレージのキャパシティの見積もりが非線形になる。



これらに共通する原因は、機能・モジュールごとのアイソレーションが無いことだ。
アイソレーションのわかりやすい実装例として、micro service があるが、もしこの複雑なサービスを複数の単純なサービスに分解できるのであれば、これらの問題は解決する。
それぞれの機能を一つのサービスとして実装し、それぞれのサービスは個別のチームが運用すればよい。
難しいのは、micro service に分解するのが現実的ではないケースだ。例えば、機能間でやりとりされるデータ量が大きい場合、別のサービスに分けると、ネットワークがボトルネックになったりする。あるサービスを micro service に分解できるかどうかは、機能間のデータ量、同期処理・非同期処理の切り分け、リアルタイム性などに依存する。

Conway’s law という法則があって、意訳すると「システムの構造は組織の構造を反映する」というものだ。


組織の構造をシステムに反映させ(またはシステムの構造にあった組織を作り)、機能・モジュール間のアイソレーションを提供する。これは、エンジニアの数に対してスケーラブルな開発環境を保つために、コアチームが解決すべき重要な問題だと思う。

0 件のコメント:

コメントを投稿