読者です 読者をやめる 読者になる 読者になる

arclamp

ITアーキテクト 鈴木雄介のブログ

アーキテクチャのトレンドサマリ(2014)

今年はJavaOneに参加できたので、標準Java系は詳しい人に任せて、僕はアーキテクチャ関連の技術紹介や事例系のセッションを回ってきました。このサマリをJavaOne 2014 サンフランシスコ報告会 Tokyoにて発表しています。資料はこちらから。

動画はこちらから(コミュニティアップデートの途中からがアーキテクチャトレンドになります)。

発表時間が30分なのでコンパクトになっていますので、さっくりと見ていただければと思います。

もちろん「明日から案件に使えます」という話ではありません。ただ、JavaOneということもあって、話者はエンタープライズへの適用を前提にしています。よって、単純なスケーラビリティだけではなく、システム連携や信頼性についても意識はしています。意識したうえで「まだ簡単にはいかないけど、こうやっていくべきだ」という話です。

サマリとしては、アーキテクチャ設計をする上のポイントが、

  • アプリケーション構築ではなく、サービス運営に目を向けた設計が必要になる
  • コンピューティングパワーを効率的に使うためのデザインパターンが「ミドルウェア」として整理されてきているため、それを最大限に活用する設計にする

であり、アーキテクトに求められることは「サービス全体におけるドメインの境界を見分ける力」ということになります。

アプリケーション構築からサービス運営

アプリケーション構築とは「スコープがあり、終わりがある行為」であり、サービス運営とは「常に変化し、終わりのない行為」です。

サービス運営に求められる要素はアジャイル・DevOps・リーンスタートアップといった用語で包含されているので、ここでは詳細は述べません。簡単に言えば「フィードバックを元にした持続的な開発」なので、「いかにフィードバックを効率的に受け取るか」「それをいかに早く反映させ続けるか」といったところでしょうか。

特にIoTと呼ばれるデバイスの多様化は「ユーザーの利用シーン(システムのコンテキスト)」の多様化を引き起こし、より変化の度合いが広がることを意味します。

こうした状況においてアーキテクチャ設計で考慮すべきなのは以下のようなことです。

  • マネジメントプロセスとアーキテクチャ設計を関連付ける(コンウェイの法則)
  • CI/CDのようなアプリケーションライフサイクルマネジメントを前提にする
  • システムやユーザーのアクティビティを計測する仕組みをいれる
  • スケーラビリティを確保する(増えるだけではなく、減らす方も)
  • ロジック同士を疎結合にする(個別ロジックの変更影響を全体に与えない)

デザインパターンとしてのミドルウェア

そうした中で注目されているのがミドルウェアの存在です。より変化を受け入れ、早く構築するために必要な設計がパターン化され、ミドルウェアとして提供されているようになっています。

大きく進んだのはクラウドデザインパターン(CDP)でしょう。これはクラウドプラットフォームで提供されているミドルウェアの最大活用を前提にしたアーキテクチャ設計のデザインパターンです。もちろん、この考え方はオンプレミスでも重要です。

OSSのプロダクトを見ていても、アプリケーションフレームワークは少なくなってきて、ミドルウェアが活況です。そのアプリケーションフレームワークも、いかにミドルウェア的な要素を包含するか、というのが1つのテーマでしょう。SpringBootDropWizardは開発容易性(EoD)を実現しているだけではなく、ルーティングやマネジメントといった要素を最初から取り込んでいます。

アーキテクチャ設計上のとらえ方をすると「固有で複雑な問題を、いかに汎用で単純な問題に置き換えていくか」という活動です。これまでミドルウェアの領域が成熟していなかったため、汎用化単純化に工数をかける意味がなかったのですが、今は違います。

ミドルウェア自体も「設定ファイルなどで行う設定」だけではなく「コードで行う設定」も増えており、適用領域はすごく増えています。インフラ領域で言われているSoftware-Defined Anything(SDx)は「インフラのミドルウェア化」と捉えるとわかりやすいですね。昨今話題のDockerは、その象徴的なものでしょう。

余談ですが「アプリケーションフレームワークの標準化」という考え方は早晩なくなるでしょう。今必要なのは「基盤としてのプラットフォームの整備」であり「各ドメインに最適化されたアプリケーションフレームワークの採用」です(これだけで記事が書けそうフラグ)。

アーキテクトに求められること

この状況でアーキテクトに求められることはなんでしょうか。最も大事なのは「ドメインの境界を見分ける目」だと思っています。ドメインの境界が見えなければ、その後、どのようにシステムを分断し、統合すればよいのかを考えることはできません。

ドメイン境界の発見において特に注目すべきなのが「変化の予測」です。対象となるドメインにおいて、将来発生してくる変化の要因を理解するとドメインの境界が見えてきます。ユーザーの変化であったり、ビジネスの変化であったり、様々なことが考えられるでしょう(これだけで記事が書けそうフラグ)。

DDDは、JavaOneでも最注目されている印象です。ただし、カタログ的な知識だけではなく、対象のシステムをきちんと見て、自分で境界線を発見することは忘れてはいけません。

まとめ

こうしたトレンドの変化は既に起きていることで、着実に進んでいます。エンタープライズでは、まだまだ顧客の意識も付いてきていないですし、レガシーシステムも消えてなくなるわけではありません。でも、5-10年先を見れば、今から取り組んでいかなくはいけません。

2014/10/27追記

動画リンクを追加しました。