2016年10月24日のQCon Tokyo 2016 にてご講演いただきました鈴木雄介氏（グロースエクスパートナーズ（株）執行役員／日本Javaユーザーグループ 会長）の講演「今どきのアーキテクチャ設計戦略」について、以下ご紹介させていたきます。
転載元：アーキテクチャ設計のジレンマと拡張構造としてのマイクロサービスアーキテクチャ – arclamp
アーキテクチャ設計のジレンマ
伝統的に、アーキテクチャ設計というのは設計や実装に先立って事前的に行われる必要がある、とされています。設計や実装は定義されたアーキテクチャを参照しながら進めなくてはならないからです。なので、アーキテクチャ設計にあたっては「システムの振る舞いに対する要求」という「話」を理解して進めていくことになります。そのため、その要求が正確であればあるほど適切な構造を定義できることになります。これは当たり前のことですね。
一方で、現在的なシステム開発というのはアジャイルに代表される「フィードバックと改善によって段階的に機能を拡張する」という前提にあります。これも当たり前のことで「誰も事前に正しい要求を定義できるわけがない」から「動くソフトウェアを見てフィードバックをすることで正しい要求に近づいていく」のです。
というわけで、ここに「アーキテクチャ設計のジレンマ」が生じます。
- 構造を決めるには正しい要求が必要
- 正しい要求は「フィードバックと改善」で導かれる
- そのためには動くソフトウェアが必要
- 動くソフトウェアを作るためには構造が必要
このジレンマは長らく「アジャイルとアーキテクチャの対立」として表現されてきたものです。ところが、ここに来てようやくマイクロサービスアーキテクチャが、この対立構造を解消しつつあります。
拡張構造の採用
アーキテクチャ設計のジレンマというのは避けられないものなので、アーキテクト側としては何らかの設計戦略によって、これを回避することを考えます。
1つ目のアプローチは予測型アーキテクチャ設計です。将来に発生する機能拡張を予測し、それをも含んだ最適なアーキテクチャを設計すればよい、と考えるわけです。しかし、この予測型こそがアジャイルが最も嫌うアプローチであり、実際には破たんすることになります。良くあるのは予測増改築型アーキテクチャ設計（別名：温泉旅館型）への進化であり、悲しくも不思議な館を作ったり、増築した経験がある人も多いでしょう。
そこで2つ目のアプローチとして言われているのが犠牲型アーキテクチャ設計です。これは現時点で分かっている機能に対して必要十分なアーキテクチャ設計を行い、それで耐えられるまでやって、ダメになったら作り変えればいい、という考え方です。XPのYGNIの法則（You ain't gonna need it/機能は実際に必要となるまでは追加しないのがよい）といってもよいでしょう。このアプローチは非常に有効ですが、アーキテクチャの改変には大きなコスト（お金的にも時間的にも）が発生するというデメリットがあります。よって、「技術的負債」という言い方をして、段階的に負債を返しながら再構築にならないアプローチを取ります。
そんな中で常に求められるのが拡張構造型アーキテクチャ設計です。これは現時点でわかっている機能に対して最適な構造を用意しつつ、将来に必要なった機能について段階的に構造を拡張できる、といういいとこどりのアプローチです。
※拡張構造における基本構造はプラットフォームと称されることが多い
ところが、拡張構造型には大きな問題があります。それは「※天才に限る」ということです。というわけで、私のような凡人アーキテクトはコミュニティの英知であるところのオープンソースを採用したり、クラウドサービスを利用することになります。
拡張構造としてのMSA
この拡張可能な構造にするための努力について、現時点での集大成がマイクロサービスアーキテクチャだと思っています。ただ。拡張性を確保するために相当に複雑な構造になっています。
資料内に構造として色々とあげたものをリストとして記載しておきます。もうすこし詳しい内容は講演資料を確認してみてください。ただ、あっさりしか書いていないので個別のテーマは検索してください。1つ1つのテーマで講演ができちゃうぐらい深いです。
- 疎結合を維持する戦略
- データ分離：共有データ、ビュー、トリガー/ストアド、ETL、イベントソーシング
- テスト戦略：Test Doubles、Dark Canaries、Consumer-Driven Contract testing
- 不整合の許容：Amazonのクーポン
- リジリエンスを確保する戦略
- サービスの集中管理：設定の集中管理、知的なルーター、非同期メッセージング
- 階層型障害への対応：サーキットブレーカー、分散トレース、障害注入テスト
- ツール群
- CI/CDツール群：チケット管理、ソースコード管理、CI/CDツール、ドキュメント管理、チャットツール
- インフラツール群：インフラ構成管理、コンテナ
- 分析ツール群：メトリクスツール
MSAの採用に向けて
とはいえ、「プラットフォームとして拡張構造型のマイクロサービスアーキテクチャを採用しよう」といってもなかなか簡単なことではありません。マイクロサービスの拡張構造を習熟し、チームが機能するようになるのは長い時間がかかります。
マイクロサービスのアーキテクチャは設計コンセプトから実際のフレームワーク、さらにツール群などを含めて相当複雑な構成になっています。これはアジャイルから始める長い歴史の積み上げがあるわけです。このストーリーはCloud First Architecture設計ガイドに書いていますし、デブサミ関西でも「アジャイルから現在までの15年間の歴史で自分がどこにいるかは意識すべき」（参照：デブサミ関西2016「クラウドの発展とデベロッパーの役割について）という話をしました。
僕は「マイクロサービスで全体一括再構築はうまくいかない」と思っています。なので、僕が考えるアプローチは「マイクロサービスアーキテクチャには明日からでも取り組もう」です。
マイクロサービスというと、どうしても「マイクロ」が気になることですが、その本質は「サービス同士を疎結合にして個別変更を許容する」ということです。だから、サービスの大きさや、そのサービスの変更リズムというのはドメインに合わせていけばいいと思います。たとえば10人ぐらいのチームで抱えるような規模で、大きなリリースは数か月おき、とかでもよいと思います。
ともかく、今の仕組みを大きく変えるのではなく、段階的に導入していかなくてはなりません。できることから取り入れていけばいい。実際、多くのウェブサービス企業でも、そういった段階的な取り組みをしています。
ただ、内製化の進んでいないエンタープライズ分野では、こうした考え方は非常に厳しいものがあることも分かります。情シスの担当者もベンダーの担当者も、どうしても一括再構築という選択肢しか取れないのです。弊社はSIerではあるものの、顧客との協業関係を築きながら段階的な拡張に対してビジネス的にも矛盾せずに対応できるようになっていますが、これはレアケースでしょう（←ステマ）。
せっかく拡張構造の集大成としてマイクロサービスアーキテクチャというものが定義され、かつ、オープンソースやクラウドサービスとして整備もされつつある状況です。なので、アーキテクトがすべきなのは、それを学んで自分のドメインへの適用方法やタイミングを考えるだけです。ただ、その「だけ」ですら、なかなかできていないのが現状でしょう。
日本のエンジニア（特にエンタープライズの）がアーキテクチャ設計のジレンマを乗り越えるべく、主体的に取り組んでくれることを心から願っています。
InfoQ編集部より鈴木雄介氏の最新刊著書の紹介
本文の中でも言及されているように『Cloud First Architecture 設計ガイド（日経BP Next ICT選書）』（www.amazon.co.jp/dp/B01KUN5LI2/）が出版されています。
本書は、前半でエンタープライズシステムが「クラウドファースト」に到るまでのアーキテクチャの変遷を技術的な観点で物語的にたどるとともに、後半では今回のQConTokyo講演のテーマであったアーキテクチャ設計戦略についてその基本的な考え方を筋道立てて解説しています。個別の具体的なプラットフォームを前提にした設計というよりも、その前段でクラウド時代の基本的なアーキテクチャ「マインド」を身に付ける上で不可欠なモノの見方・考え方を学ぶのに非常によいテキストだと思います。
入門者にとっても上級者にとってもそれぞれの立場で学ぶことの多いスルメのような書籍だと感じます。講演スライドを読まれた上で、さらに本書を読まれることをお勧めします。
QCon Tokyo 2016公式サイトにて講演資料を公開しております。ぜひご確認ください。
http://www.qcontokyo.com/program.html
以上