microXchgマイクロサービス会議のオープニングトークでUwe Friedrichsen氏が登壇し、“Resilient Functional Service Design”のコアコンセプトについて講演した。主な重要事項は次の通りである。マイクロサービス開発者は、フォールトトレラントなデザインパターンとキャッシングについて学んだほうがよいが、根本的に悪い（過度に結合した）システム設計を緩和するためにそれを利用すべきでない。ドメイン駆動設計（DDD）とモジュール性を理解することは不可欠である。コンポーネントについて再利用でなく交換可能であることを目指す。
codecentric社の最高技術責任者（CTO）であるFriedrichsen氏は、ソフトウェア開発の目標はビジネス価値を提供することであり、これを実現するためには、ソフトウェアが本番環境で稼動し、（ほぼ常時）利用可能な状態にある必要があると講演の冒頭で述べた。マイクロサービスなどの最新のアーキテクチャスタイルは、すべてが分散していることを前提としており（ほとんどの場合、少なくともローカルエリアネットワークで分散している）、そのため、システム内の障害は日常であり、予測できない。
開発者は、Michael Nygard氏の著書“Release It！”で普及しているブレーカ、バルクヘッド、タイムアウト、再試行などのフォールトトレラントな設計パターンに慣れておく必要がある。キャッシュは、有用ではあるが、慎重に配置しなければならない。依存関係にある多くのサービスによって起動パスが長くなってしまっているような、悪いシステム設計に対処するために使用してはいけない。
Friedrichsen氏はマイクロサービス（以下の写真）のための‘設計の基礎’について一通り説明した。高凝縮性（汎用的でなく特化した機能の作りこみ）、疎結合、関心の分離に焦点を当てた一連の設計原則について述べた。この原則は、システムの境界で特に重要であり、David Parnas（PDFリンク）によって理論が70年代に多く文書化されているにもかかわらず、依然として誤解されがちである。
ドメイン駆動型設計（DDD）は便利なツールであるが、多くの開発者は、ドメインの静的コンテキストモデルに過剰に重点を置いている。Friedrichsen氏はそのモデルを‘Entity DDD’と呼んでいる。システムの動的な振舞いは、ビジネス活動、ドメインイベント、データの流れの説明に役立つことが多い。
静的なドメインモデルから始めないでほしいです。魅力はシステムの動的な振る舞いにあります。
マイクロサービスの開発者は、再利用性のために努力すべきでなく、代わりに交換可能であることを目指すべきである。Friedrichsen氏は、Fred Brooksの言葉を引用し、開発者が長年追求してきたソフトウェア再利用に対する期待について議論した。Brook氏は、再利用可能なコンポーネント（1つのケースに適した機能を超えている）を作成するために必要な作業労力は、通常3倍となる。つまり、再利用への投資を超える収益は、コンポーネントを変更せずに少なくとも4回使わないと得られない。
マイクロサービスシステム内で使用される通信パラダイムも機能サービス設計に大きく影響を与える。Friedrichsen氏は、将来の変更と拡張性を制限する可能性のある先を見越したアーキテクチャの選択に注意を払うべきだと提案している。
最終的なメッセージと、講演から得られる重要事項は、マイクロサービスのような分散システムを実装する際には、開発者やアーキテクトが機能的なサービス設計を再び学ぶ必要があるということであった。このシステムの特性によって、我々が長年認識していた設計問題の影響が表面化し、拡大する。
Uwe Friedrichsen氏の講演“Resilient Functional Service Design”のビデオは、microXchgカンファレンスのYouTubeチャンネルで視聴できる。
Rate this Article
- Editor Review
- Chief Editor Action