BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース microXchgマイクロサービスカンファレンス第1日 - DDD、プラットフォーム、企業への影響

microXchgマイクロサービスカンファレンス第1日 - DDD、プラットフォーム、企業への影響

ブックマーク

原文(投稿日:2017/02/27)へのリンク

ベルリンで開催されたmicroXchgカンファレンスで、ソフトウェア開発の実務家たちが、マイクロサービスアーキテクチャスタイルに関する最新の実践成果を発表した。論じられたのは、機能サービス設計、ドメイン駆動開発(DDD)とRESTの統合、トランスクルージョン(transclusion)を用いたマイクロサービスによるWebサイト開発、マイクロサービスプラットフォームの選択、企業や個人に対するマイクロサービスの影響、IoT(モノのインターネット)を活用する上でマイクロサービスをどのように利用するか、といった話題だ。

カンファレンスのオープニングトークではUwe Friedrichsen氏が、‘Resilient Functional Service Design’というタイトルで、中核概念としてのレジリエントな機能サービス設計について論じた。この講演についてはInfoQのニュースとしてすでに伝えているが、その中では、“マイクロサービス開発者はフォールトトレラントのデザインパターン(サーキットブレーカやバルクヘッドなど)を学ぶ必要があるが、基本的な問題のある(過度な結合性を持った)システム設計の軽減にそれを用いるべきではない”、“ドメイン駆動設計(DDD)とモジュール化の概念の中核を学ぶ”、“再利用性(reuse)よりも交換可能性(replaceability)を目標とする”、“システムの動的な挙動をモデル化する”などが、注目すべき話題として紹介されている。

静的なドメインモデルを開始点としないでください – 秘密はシステムの動的挙動の中にあるのです。

続いて登壇したOliver Gierke氏の講演‘DDD & REST – Domain-Driven APIs or the Web’では、最初にDDDの中核的概念の優れた入門書として、InfoQの書籍 である‘Domain Driven Design Quickly’が紹介された。Gierke氏はドメインモデルソフトウェアを開発する開発者に対して、‘暗黙的な概念の明示化’に努めるべきだ、とした上で、このトピックに関する理解を深める手段として‘Power Use of Value Objects in DDD’を見ることを推奨した。ドメインの標準的モデルと言えば、データベーススキーマを思い浮かべる開発者が多いかも知れない。しかしDDDスタイルのモデルは、単純な外部キーによる関係表現などに比べて、ビジネスの概念をより明確に表現することができる。

A DDD domain model reveals more than a database schema

Gierke氏は、RESTと‘HTTP経由のCRUD’は等価ではない、と明確に述べた上で、クライアントに提示するビューなどのデータの設計に十分な配慮をするべきだとして、APIを経由した明示的な操作から始まり、イベントとしてのオペレーション、イベントソース(ES)の採用、CQRS(コマンドクエリ責務分離)と続くAPIオペレーションの4段階モデルを紹介した。その上で氏は、概念としての‘HATEOAS(Hypermedia As The Engine Of Application State)’の価値を説くとともに、これをドメインに関する独立したドキュメントとして配信するのではなく、アクションや状態遷移の可能なクライアントとの通信に使用することが可能だ、と述べた。クライアントにとっては、ドメインの知識と交換に複雑なプロトコルを強いられることになるかも知れない。しかし氏は聴衆に向かって、これが有効なトレードオフであることを説いた。

HATEOASはクライアントに対して、アクションや状態変化が可能であることを通知するために使用できます。これはドメインの知識と引き換えに、複雑なプロトコルの実装をクライアントに強いるものかも知れません。ですが、考えてみてください – ‘ビジネスルールと運用プロトコル、定期的に変更されるのは果たしてどちらでしょうか?’

当日の3番目の講演として‘Microservice Websites’を行なったGustaf Nilsson Kotte氏は、複数のマイクロサービスを使用しながらも単一のサイトとして提供されるWebサイトについて、その構築の効果性を支える原則を論じた。講演の中核となったのは、マイクロサービスはそれぞれが自身のフロントエンドを提供すべきである、という前提である。それによって、トランスクルージョンを用いたユーザ向けページの構築が可能になるのだ。サーバ側でトランスクルージョンを提供するためにはAkamaiVamishなどのESI(Edge Side Includes)が、JavaScriptベースのクライアント側ではAngularJSh-includeといったトランスクルージョンを提供する一連のフレームワークが利用できる。講演では、それぞれのアプローチに関するメリットとデメリットが紹介された。

Server transclusion vs client transclusion

Kotte氏は、マイクロサービスベースのWebサイトについて、継続的デリバリ、分散型ガバナンス、モバイルデバイスや携帯機器ネットワークへのパフォーマンスの最適化などをその目標に含むべきだ、と語り、自身の講演を締め括った。クライアント全体に依存しない、サーバ側リソースのトランスクルージョンを提供することで、Webページ(およびマイクロサービス)分割という方法論が実現可能になると同時に、前述の目標の達成にも結び付いていく。この話題に関しては、Koitte氏の記事‘Microservice Websites’にも紹介されている。

Dustin Huptas氏は‘AaaS &ndsh; Anything as a Service. Anything left to do, then?’と題して講演し、‘X as a Service’デプロイプラットフォームを提供するサービスの数は多いが、アプリケーションに最も適したソリューションの選択には注意が必要だ、と聴衆に向かって警告した。その上でHuptas氏は、モノリシックあるいは古典的SOAアプリケーションが一般的に物理インフラストラクチャやインフラストラクチャ・アズ・ア・サービス(IaaS)と親和性が高いのに対して、マイクロサービスベースのアプリケーションにはIaaS、プラットフォーム・アズ・ア・サービス(PaaS)、新たなサービスであるファンクション・アズ・ア・サービス(FaaS)が、そして‘サーバレス’アプリケーションにはPaaSとFaaSが適している、と示唆した。

Architecture / Technology as a service models

さらに氏は‘Adaptive IT Cube’を提唱して、あるデプロイメントプラットフォームから他への移行においてはアーキテクチャ、テクノロジ、組織(部下やプロセスを含む)を考慮すべきだ、と論じた。ここで必要となるのは、きめ細かなアプローチを移行時に使用するという配慮と、ソフトウェアアプリケーションの移行やアップデートといった移行活動には長期的なコミットメントが必要である、という認識だ。

次のDaniel Bryant(この記事の筆者)は、‘Microservices: The Organisational and People Impact’と題して講演した。プレゼンテーションの中核的なメッセージは、マイクロサービス採用時の課題の多くは主として組織やプロセス、人の問題に関わるものである、というものだ。この中で筆者は、マイクロサービスベースのアプリケーションの実装を決定した組織には、明確な目標(ビジネス価値や技術戦略など)の定義と共有の重視、組織と技術スタック全体を通じたフィードバックの最適化、組織内における責任体制の明確化などが必要だ、という点を指摘した。

communicate the strategic vision

目標設定に関しては、状況認識を高めることと、Wardleyマップバリューストリーム分析を活用することを示唆した。(チーム全体で共有される)強力な技術的リーダシップも重要であり、大規模なオープンソースプロジェクトを通じて学んだ教訓を活用するには‘インナーソース(innersource/組織内OSS)’モデルが有効だ。ビジネス価値やアーキテクチャの品質、運用効率をデモンストレーションする測定値やシグナルをマイクロサービスに‘焼き込んで’おくことも忘れてはならない。講演のまとめとして筆者が示唆したのは、最初にDevOps方法論を導入する際に責任を決めておく必要がある、という点である。マイクロサービスベースのアプリケーション構築に伴う統合の複雑化において、継続的デリバリはしばしば、ソフトウェアデリバリプロセスの継続的変化を推進する触媒として作用するのだ。

カンファレンス初日は、Fred George氏による基調講演 ‘IoT and Microservices in the Home’で幕を閉じた。その中でGeorge氏は、私たちが今、AppleのSiriやGoogle Home、Microsoft Cortanaといった支援技術に囲まれた‘エージェントの時代’を生きていると述べた。このようなIoT(モノのインターネット)技術のイノベーションとして重要なのは、音声認識ではなく、エンドユーザが構築可能なバックサービスとの統合性である。

氏はAmazon EchoやPhillipsのIoT照明、Apple TV、IoT対応スイッチといった、氏の自宅に展開されているIoTを引き合いに出して説明した。デバイス群を操作するソフトウェアはRubyとJavaのマイクロサービスとして作成されていて、Docker Swarm経由でデプロイされ、イベントバスとしてRabbitMQを使用して通信を行なう。IoTコンポーネント接合のために展開されるソフトウェアで鍵となるアーキテクチャ原則としては、ジャスト・イン・タイム設計、可能な限りコンパクトに実装された振る舞い指向サービス、アクション/結果をグローバルイベントとして公開、ハードウェアの冪等性と冗長性を利用した信頼性の確立、といったものが挙げられた。

microXchgカンファレンスは2月16日と17日にベルリンで開催された。全公演のビデオ記録がカンファレンスのYouTubeチャネルで公開されている。

この記事を評価

関連性
スタイル

この記事に星をつける

おすすめ度
スタイル

BT