Cisco Advent Calendar 2022 第23日目！
1. はじめに - 「みんなの意見」は案外正しい
今年もAdvent Calendarの季節が巡ってきました。2022年もいろいろなことが起こりましたが、顕著なものの一つは機械学習の進化でしょうか。「AI画家」と言われるような画像生成AIが相次いで登場し、さらに、OpenAIが開発した自然言語生成モデルであるChatGPT [1] がリリースされました。AIとは、つまりは「集合知」であると考えられますが、ChatGPTはその集合知を自然な言語で対話的に出力してくれます。「『みんなの意見』は案外正しい」という本 [2] がありましたが、まさにそれを強く感じます。若干微妙な話題をふっても、一つの立場にとらわれない、たぶん現在人類が考えつく限り最も適確であろうと思われる回答を返してくれます。一人の権威よりも集合知！
私は年に一度仲間と綴るAdvent Calendarの場で、「システム理論」について連載しています。しかしその「システム理論って何」ということについて、これまで何度か解説を試みているもののあまりしっくりきていないかもしれません。そこで、ChatGPT先生に訊いてみます！
ほわー、なるほど...。
早いもので今年は6年目。過去5回のエントリーもご覧いただけたら嬉しいです。
- 2017年 ネットワーク・エンジニアリングから学ぶこと − システム理論の見地から
- 2018年 システム理論の続き - 生命モデルの限界と克服
- 2019年 システム理論の続き - 宣言的ネットワーキング
- 2020年 システム理論の続き - 音楽をネットワーク分析してみた
- 2021年 システム理論の続き - 量子コンピューティング・思考のフレームワークを拡張する
2. システム理論から学ぶアーキテクチャ設計
「アーキテクチャ」は元来建築分野の用語で、建築様式や工法、構造を意味します。しかし、目には見えないソフトウェアやネットワークシステムにおいても、アーキテクチャの重要性が際立ってきています。アーキテクチャによって性能、信頼性（頑健性・耐障害性）、スケール性、セキュリティ、迅速性、再利用性、保守性などが決定づけられるからです。
ではどのようにアーキテクチャ設計したら良いのでしょうか。ソフトウェアアーキテクチャを記述するための標準は存在する [3] のですが、Wikipediaには「今までのところソフトウェアアーキテクチャという用語に関して、万人が合意した厳密な定義は存在しない」と書かれています [4]。アーキテクチャには建築と同様、「サイエンス」の要素と「アート」の要素が含まれます。「サイエンス」の部分は定義できるとしても、「アート」の部分は定義できない、ということでしょうか。
そこでここでは、Mark W.MaierとEberhardt Rechtinという二人のシステム理論家による著書「The Art of Systems Architecting」[5] を参考に、システムアーキテクチャをどのように設計すると良いのか、について考察してみたいと思います。
彼らはまず、システム設計の方法論を4つに分類します。
| 分類 | 特徴 | 例 | どちらかというと |
|---|---|---|---|
| 規範的 (Normative) | ソリューションに基づく | 建築基準法、通信規格 | Science |
| 合理的 (Rational) | 方法論に基づく | システム分析 | Science |
| 参加型 (Participative) | システムのステークホルダーに基づく | コンカレントエンジニアリング、ブレーンストーミング | Art |
| 発見的 (Heuristic) | 教訓や経験から学ぶ | 格言、デザインパターン | Art |
規範的・合理的な方法は、昔も今もこれからも、システム設計において必須、欠かすことのできないものです。しかしこれらだけに依存すると、前例のない新たなタイプのシステムのアーキテクティングが難しいし、未知なものや急な状況変化にも対応しにくい、という欠点があります。
そこで、それを補うのが発見的な方法です。発見的手法 (heuristics) とは、知識や経験をもとにして、問題を解決するための方法やアプローチのことを指します。完全な解決策を見つけることができない場合に、近似解を提供するためにも使われることがあります。
そのためか私たちの業界は経験則、格言、箴言に満ちています。「銀の弾丸は存在しない」―万能な解決策などない。「ライト、ついてますか？」― 何が真の問題なのかを正しく把握することが重要。「分散システムの8の誤謬」―分散システムってそんなに簡単ではない（って端折りすぎ！）。「早すぎる最適化は諸悪の根源」―最適化、最適化って言うけど、初期の段階で最適化に走ると碌なことにならない。「起こりうることは起こる」―マーフィーの法則！「KISS (Keep it Simple, Stupid)」―できる限りシンプル性を保つ。「システムを設計する組織は，その構造をそっくりまねた構造の設計を生み出してしまう」―コンウェイの法則！「送る時は厳格に、受ける時は寛容に」―ポステルの法則、、、、などなどなど。
こういった先人の教えは真理と愛と哀愁に満ちており、意思決定、価値判断、評価などに役立ちます。さらにこれらは、アーキテクチャ設計時のみならず人生訓にもなります。
ちなみに、超蛇足ですが、私の発見した法則を記述しておきます。。
「動機は不純でも良い。高尚な動機より、不純であっても直截的な動機の方がうまく行く」
「先回りはだめ。課題は自ら発見しなくては。」
3. デザインパターン
もう一つの発見的な手法として、パターンランゲージ(pattern language)があります。パターンランゲージとは、建築や都市計画、システムデザインなどにおいて、問題を解決するための方法やアプローチを、デザインパターンとして抽出し明示するためのツールです。経験則、格言、箴言が先人の教えだったのに対し、その先人の教えのようなものをボトムアップで生み出そう、と言う試みとも言えます。 パターンランゲージは、具体的な解決策を提示するだけでなく、その解決策がどのような背景や問題を解決するのかを明確にすることで、複雑な問題をできるだけスムーズに解決するためのツールとして使われます。
デザインパターンがソフトウェアエンジニアリングの分野で最初に使われたのは、「オブジェクト指向プログラムのためのパターンランゲージの使用」[6]だそうです。トップダウンで規範的なルールに基づき設計するのではなく、オブジェクト指向プログラム設計において「繰り返し現れる構造」を捉え、それを再利用できるようにまとめられました。
このようなデザインパターンによって組み上げられたシステムは、例えるならば「多くの人がそこを通ることによってできた登山道と、そこにさりげなく置かれた休憩用のベンチ」のようなもので、設計図から起こした計画都市にはない味わいがあり、自然と無理なく調和し、かつ必要以上に複雑にならず、堅牢である可能性があります。
4. マイクロサービスとデザインパターン
マイクロサービスとは、単一のモノリシックなシステムとは対照的に、アプリケーションの機能を提供するために連携する、相互に接続された多数の疎結合サービスから構成されるアプリケーションを指します。CNCFにおけるクラウドネイティヴの定義[7]の中心概念のひとつです。
この最も現代的アーキテクチャであるマイクロサービスが、実はデザインパターンの集合体である、と言うことを知り、システム理論学徒(?!)である私はテンションが上がりました。未知の領域をアーキテクティングする場合、やはり発見的な方法が必要なのだと思います。
マイクロサービスは万能ではありません（銀の弾丸は存在しない！）。そのため、マイクロサービスを理解し、適用領域を吟味する必要があります。私はアプリケーション開発者ではありませんが、アプリケーションからのインフラへの要請はおさえておく必要があります。そして、マイクロサービスのデザインパターンを知ることは、マイクロサービス・アーキテクチャがどのような原則に基づいて構築されているかを理解することに繋がります。
「マイクロサービスのデザインパターン」[8]では、下記の項目を基本原則としています。
- Scalability （スケーラビリティ）
- Availability （可用性）
- Resiliency （回復力）
- Independent, autonomous （独立性、自律性）
- Decentralized governance （分散型ガバナンス）
- Failure isolation （故障の隔離）
- Auto-Provisioning （自動プロビジョニング）
- Continuous delivery through DevOps （DevOpsによる継続的なデリバリー）
これらは、ネットワークシステムのアーキテクチャに、そのまま当てはまりますね。
5. そしてサービスメッシュ！
そして、サービスメッシュです。サービスメッシュは、マイクロサービス間のネットワーク接続、制御、監視を可能にし、マイクロサービスアーキテクチャの一貫した開発・展開、ヘルスチェック、セキュリティ、およびスケーラビリティを提供しますが、サービスメッシュ自体が、マイクロサービスアーキテクチャに適用可能なデザインパターンの一つです。[9]
サービスメッシュは、前述の基本原則の中の「独立性・自律性」を実現するためのデザインパターンであり、各マイクロサービスの通信に関する作業を切り出します。またサービスメッシュの実装にあたっては、サービスインスタンスと並行して実行される「サイドカー」デザインパターンが使用されることがあります。[10]
こうしてサービスメッシュを探求してみたいと思い、今に至ります。前回のONICでは同僚と一緒に「サービスメッシュ – これからのクラウドネイティヴアーキテクチャのあり方を探る」と題して発表させていただきました。[11]
また、来年1月のJANOG51では、「ネットワークエンジニアが知るべきサービスメッシュ」と題し、コンピューティングとネットワーキングの境界が変化していること、そしてマイクロサービスのデザインパターンは、ネットワークシステムにも有効であることなど、ネットワークエンジニアがサービスメッシュを知るべきポイントについて議論したいと考えています。[12]
ご意見やフィードバックを戴けましたら、大変嬉しいです。
References
[1] ジェームズ・スロウィッキー「「みんなの意見」は案外正しい」 KADOKAWA (2009/11/25)
[2] https://chat.openai.com/chat
[3] ISO/IEC/IEEE 42010 Systems and software engineering―Architecture description
[4] https://ja.wikipedia.org/wiki/ソフトウェアアーキテクチャ
[5] Mark W. Maier, Eberhardt Rechtin, “The Art of Systems Architecting”, third edition, CRC Press
[6] https://kdmsnr.com/translations/using-pattern-languages-for-oop/
[7] https://github.com/cncf/toc/blob/main/DEFINITION.md
[8] https://dzone.com/articles/design-patterns-for-microservices
[9] https://microservices.io/patterns/deployment/service-mesh.html
[10] https://microservices.io/patterns/deployment/sidecar.html
[11] https://onic.jp/_cms/wp-content/uploads/2022/11/2022_Service-Mesh.pdf
[12] https://www.janog.gr.jp/meeting/janog51/servicemesh/