アーキテクチャの議論でどう思考するべきか
いつもにもまして雑な記述です。
先日、新しい開発プロジェクトを立ち上げる際に、アーキテクチャの方針をアツく議論することがあり、そこにSREとして参加させてもらい色々と意見を出させてもらう機会があった。
自分はいくつかのクライアントアプリケーションやマイクロサービスアーキテクチャ（と少なくとも自分は当時思っていた）なシステムの設計に中心的に関わったことはあれど、アーキテクトとしての専門性は素人レベルであるという前提で書く（のでいろいろ勘弁して欲しい）。また、マイクロサービスアーキテクチャそのものに対しての理解を深めたい人のための内容ではない（のでいろいろ勘弁して欲しい）。
どんな議論だったかというと、ざっくりいうと
- 既存のサービスに追加機能として実装するか
- それとも、開発チームは切り出されているわけだし、将来的な想定のもとでいわゆるマイクロサービス的に実装するか
という議論だった。
今回の議論においては、最終的な合意ができた（様々な複雑性を回避するための時間と組織が不足しているという理由で一旦モノリスに統合して実装していくという方針）し、それ自体に何も異論はなく完全に同意しているが、「議論の進め方」の部分で自分は実際はあまりしっくりきておらず、そのしっくりきていなさを個人的なメモとして整理しておきたいな、と思ってこれを書いている。
もっと注意深くいうと、特に内部の決定に対してだったり、メンバーへの非難をしたいわけでは一切なく、自分の中での解釈の仕方の問題を自分なりに整理して記述しておきたい、ということなので理解してもらいたい。
ひとつめ
まず、議論の難易度があがってしまったかも、と思ったところがあり、それは「最終的な理想系・目指すべきアーキテクチャのイメージを共有しあって結論を出そう」としてしまっていたところだ。
たしか、最初はマイクロサービスアーキテクチャのようにシステムを切り離してスケールでき、言語もフレームワークも既存サービスとは違うものとして実装してみたい、というアイデアが議論のテーブルに乗っていたはずだった。
それに対して、「そのようなアーキテクチャが最適か？マイクロサービスの複雑性を許容できるものか？」というところからどんどん議論が深まっていった。その中で「将来にわたってマイクロサービスアーキテクチャで実装するしていくとして、その理想の姿はどんなものなのか？」というところに回答を出そうとして時間を結構費やした。そこが、自分にとっては難易度が異常に高い宿題だと思った。
難易度が高い、と感じる部分をもう少し説明すると、システムでもクライアントアプリでも、アーキテクチャの議論において「最終的なゴール・理想」は、「変化していくこと」前提だとすると、最初の時点で見出すのはかなり難しいし、示せたとしてもそれが正しいかがわからないため、自信をつことができない。
なので、やるべきだったのは、「理想を示す」のではなくて、「解決したい課題がなんなのか」をもっと事細かく最初にテーブルに並べるところから始めるべきだった気がする。今回の議論は「最終的なゴール→ここは課題になりそう→ゴールをちょっと変えて再考→やっぱりここも課題がありそう→ループ」みたいな思考になっていたので、これは依存関係としておかしかった。どちらかというと課題があって、それを解決するのがアーキテクチャなのであって、多分理解の順序としては逆だったように思う。
ふたつめ
次に、今回の議論中に解釈しきれなかった点としては、マイクロサービスアーキテクチャというプラクティスの難易度の高すぎる面にばかり目を向けてしまい、ひるみすぎてしまっていたように思った点。
マイクロサービスアーキテクチャは技術の選択性やスケーリングの効率化、組織との一致など、多くのメリットがある一方、特に組織が追いついていない場合、「この組織でいまそこまでやる必要があるのか？」という議論になる。実際、これまでも何度かそういう失敗体験をしてきたのも事実ではある。
ただ、マイクロサービスアーキテクチャ、というか、組織を超えたシステム間連携のもっとも議論すべきところは、疎結合と高凝集性をどうやって担保・実現するかであり、そこにある程度結論が出せるのであれば、自分はマイクロサービスアーキテクチャ（か、それに類する形態）を採用していくことことで、メリットを自然と享受できるスタイルになっていくのでは？という楽観的にみてしまう節がある。（ただ、実際に、ほったらかしのサービスを生み出すわけにもいかないので注意は必要ではあるので、自分が自信ないところでもある。）
疎結合・高凝集なアプリケーションはマイクロサービスアーキテクチャでなくとも、モノリスなアーキテクチャであったとしてもプログラミングレベルで追求していくべき考え方で、常にそのポイントに目を向けて、あわよくばいつでも組織と一緒に切り離していくことができるように準備しておくべき（そこまでできなくてもDB分割くらいはやっていきたいよね、とか）、であると日頃から考えている。時間が許せば、マイクロならこういう実装・モノリスならこういう実装、という比較もしておきたかった。
また、マイクロサービスアーキテクチャを支える「完全な」組織が構築できない・トランザクション・テスト・運用など複雑性があがる、というのは同意だが、ただ、それも実際に開発したいサービスの要件と照合してどこがどれだけ複雑性を受け入れるべきかを詳細に議論すべきで、そういう風に解釈せず、一気にマイクロ or モノリスという見方を自分はしてしまって、これは失敗したな、もっとメリット・デメリットを理解して議論して行きたかった、と思った。そのための時間もなかったので難しいところではあるが。
整理
なので、「最終的なゴールはなんだ」「理想はなんだ」という議論は、やはり難易度が高い議論の思考であって、「解決したい課題はなんだ」「その上で失っていけないものはなんだ」という議論をするべきだった、とある種反省をしているが、これ自体が良い経験なので、次に活かしていこうと思う。
とかなんとかいいつつ、アプリケーションに対しての要求が複雑化し、高度な技術が必要になるようなプロダクトをゼロから長年かけて作り続けてこれた、というのはエンジニアとしてはとても喜ばしいことだとは思うし、チャレンジできる環境とはまさにこういう環境だと思う。
というわけで、貼っておきます。
