BT

Juval Löwy氏が語る - クラスがすべてサービスであるべき理由

| 作者: Thomas Betts フォローする 34 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2016年8月17日. 推定読書時間: 8 分 |

原文(投稿日:2016/07/01)へのリンク

Juval Löwy氏はどこにでもサービスを作りたがる,と多くの人が思っている。しかし氏は,システムを思慮深く分解した論理的結果がマイクロサービスなのだ,と主張する。

Löwy氏が設計開発するシステムは,すべてのクラスがサービスである。2007年に開拓したこのアプローチを,氏は自身の著書“Programming WCF Services”の第4版でも取り上げている。サービス指向アプリケーションは,ビジネスロジックとその基盤構造が明確に分離されていることから,メンテナンス性に優れているとされる。Löwy氏は,この分離をシステムの全レイヤに拡げることで,ソフトウェア開発プラットフォームの限界を克服したのだ。

InfoQはLöwy氏に,氏のソフトウェア開発方法論と,従来のアプローチでは多発する問題について聞いた。

InfoQ: あなたは10年にわたって“すべてのクラスをサービスに”することを提案していますが,このようなアプローチに至ったのはなぜですか?

Juval Löwy: 一般論として,サービス指向は飛躍的進歩ではありません – ソフトウェア技術の長い進化における,次なるステップに過ぎないのです。例えばもし,オブジェクト指向がすばらしいアイデアだったとすれば,システムやサブシステムのレベルで止めてしまって,それがオブジェクトとして適切な粒度だとは言わないでしょう。まったく逆に,オブジェクトのメリットを可能な限り下位レベルにまで押し下げて,プリミティブまでもオブジェクトにしようと試みるはずです。

サービスは,(ユーザの関心の的であり,金銭的支出の対象でもある)ビジネスロジックを,それを維持するために必要なセキュリティやアクティベーション,同期,トランザクション,エラー処理,デプロイメントといった基盤のプラミング(plumbing)から切り離そうという,この業界の試みです。それは,開発時間と労力の大半がそのプラミングに費やされている上に,品質的に十分な成果が上っていないことが分かったからです。サービスでは,既製品として用意されたプラミングの使用が選択できるので,それらとの境界を維持しつつ,標準的なプラミングによるメリットを享受できます。

プラミングはそのスコープ(企業,システム,サブシステム,クラス)に関わらず望ましくないものなので,サービスのメリットを可能な限り活用することは理に適っています。究極の結論としては,整数や文字列もサービスであるべきです。開発者が文字列のセキュリティや,整数値の同期などを心配する必要がどこにあるのでしょう?

そこで問題となるのは,当時の(そして現在の)開発プラットフォームが,通常はそのような使用方法をサポートしていない,という点です。しかしながら,私はこれに対処して,プログラムモデルと通常のクラスの層所有コストを維持しつつ,希望するならば全クラスのレベルでサービスを利用可能にするような技術拡張を見出すことができました。

InfoQ: すべてのクラスをサービスにすること(every class as a service)は,この10年間のSOA,あるいは今日のマイクロサービスという流れと比較した場合,どのようなものなのでしょう?

Löwy: 比較するということは,違いや対立性の存在を前提としていますが,そういったものはありません。成功を収めるためには,私が10年前に指摘した粒度のレベルでサービスを使用する必要がある,ということです。設計の適切さの問題なのです。

人間の身体は,1つの大きな組織ではありません。同じように,たったひとつのサービスという巨大なモノリスを持ったシステムは,メンテナンス不能で,保持することも難しく,欠陥だらけなのです。再利用できるものは何もありませんし,拡張もできません。

外部に提供するものがビッグ(BIG)サービスや機能であっても,マイクロサービスの統合によって実現されているのであれば,問題は何もありません。ちなみにこれは,普遍的な設計ルールです。機能はいつもどこでも,実装ではない,統合という側面を持っています。これは家,車,ラップトップ,工場,何にでも当てはまります。車には人をAからBへ運ぶという重要な機能がありますが,それを実装する部品というものは存在しません。内部のコンポーネントと運転者,燃料,道路などの要素が統合されて,その機能が実現されるのです。

InfoQ: システムを分解するためには,どのような方法が適切なのでしょう,またそれは,従来のアプローチとどのような違っているのでしょうか?

Löwy: 分かっているのは,ほとんどの人たちが,機能またはドメインを基準にした設計を分解している,ということです。AとBとCが必要ならば,Aサービス,Bサービス,Cサービスを用意するか,あるいはAまたはBを配置する場所(ドメイン)を探す,という具合です。このアプローチの問題点は,(それ程長くない)時間が経つと,何らかの変更の必要が生じて,結果的に設計が変更されることです。設計が変更されると,このアプローチでは対応が難しいのです。

結論としては,要件(あるいは機能,あるいはユースケース,あるいはユーザストーリ)を前提とした設計をしてはならない,ということです。そうではなく,行なうべきなのは,最小のビルディングブロックの明確化です。それをマイクロサービスと呼ぶのもよいでしょう,とにかくそれを集結して,現時点と将来,既知と未知,いずれの要件をも満足できることが必要です。そのためには,プロセスの観点が非常に重要になります。

適切な設計アプローチとは不安定領域を特定することであり,それを(マイクロ)サービス内にカプセル化するのです。その上で必要な動作を,それらサービス間のインタラクションとして実装します。新たな要件は,新たな分解(decomposition)ではなく,別のサービスとのインタラクションに過ぎません。ですから,要件が変更されても,設計は変わらないのです。

さらに,分解は不安定領域に沿って行なわれているので,何かが変化しても,それを処理すべきただひとつの場所が存在します。そのため,変更が必要な 部分を抑制することができるのです。機能ないしドメインによる分解では,変更がひとつの場所に留まらないため,その影響は最大化され,アーキテクチャを実践するには最悪の事態になります。

分解に関するこのアプローチは,インタラクションとインテグレーションの容易さを身上とするマイクロサービスによってさらに促進されます。しかも,大部分のソフトウェアシステムには同じような不安定領域があるので,出発点としてそれを利用することができます。インタラクションにも典型的なパターンがありますから,それを理解できれば,設計作業は極めて迅速かつ正確に収束します。

InfoQ: 不安定性をベースとした分解を行なった後,システムを構築するための開発プロセスを,その高度にモジュール化されたアプローチに適応させるには,どうすればよいのでしょう?

Löwy: サービスの設計と構築も必要ですが,それを組み立てるファクトリも必要です。車を作るのであれば,個々のコンポーネント(ギヤボックスやエンジン,ポンプ,シートなど)の設計から始めると思いますが,パーツを組み上げるアセンブリラインの設計も必要になります。設計という意味では,そちらの方が車自体のパーツ設計よりも難しいくらいです。車のポンプ設計は誰でもできますが,数百種類の自動車に対応可能なポンプや,さまざまな車を組み立て可能なアセンブリラインの設計は容易ではありません。

ソフトウェアの世界では,マイクロサービス(部品)とプロジェクト(アセンブリライン)を設計する必要があります。偶然やアクシデントではあり得ません。いつの間にかファクトリが完成している,ということはないのです。経験と実践をもとに,サービスやユニットテスト,インテグレーションなどのマルチパイプラインを導入すれば,ファクトリのスループット改善も可能です。さらには,不安定領域間の所定のインタラクションパターンで得ることのできた強力なエンジニアリングガイドラインを,すべてにおいて活用することができます。

これらマイクロサービスを使って,新しい機能と動作の迅速なクランクアップが可能になれば,結果として得られるのはハイパーアジリティです。アジャイル用語を使用するためには,すでに構築したマイクロサービスを,可能であれば新規コードの必要なく使用したユーザストーリの実装が必要になります。車のファクトリの場合,ファクトリ内で実施される製造作業は,実際にはごく少数です - 工場に届くパーツはすべて完成しているので,後は組み立てるだけなのです。

インタビュー回答者について
Juval Löwy氏はIDesignの創設者であり,システムとプロジェクト設計を専門とするマスタソフトウェア・アーキテクトである。氏はアーキテクチャやプロジェクト設計,開発プロセス,テクノロジの分野において世界中で百人を超えるアーキテクチャを指導し,自身の洞察や技術,ブレークスルーを公開してきた。氏はシリコンバレーにおけるMicrosoftリージョナルディレクタであり,C#やWCF,関連するテクノロジに関するMicrosoft内の戦略的レビューにも参加している。また,主要な国際ソフトウェア開発カンファレンスでも,何度となく講演を行なっている。何冊かのベストセラーや多数の記事も著しており,現代のソフトウェア開発やアーキテクチャに関するあらゆる側面を取り上げてもいる。Microsoftでは,世界のトップクラスの専門家ないしリーダのひとりとして,氏をソフトウェアレジェンドとして認めている。Löwy氏へのコンタクトは,氏のwebsiteで可能だ。

 
 

この記事を評価

関連性
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

特集コンテンツ一覧

.NETの派生を理解する

Wayne Citrin 2018年7月18日 午前3時44分

ASP.NET Core - シンプルの力

Chris Klug 2018年6月4日 午前3時26分

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT