The First Virtue

アーキテクトの審美眼

翔泳社のDBマガジンに連載中の記事のこれまでの一覧です。 No. 1 アーキテクチャとは何か 例えばイベント駆動を考える アーキテクトの悩み アーキテクチャの縦と横の関係 縦横2つに分ける理由と効果 縦と横で表現したアーキテクチャの例 もう一度世の中の動きを見る 今後の連載予定 No. 2 俊敏なアーキテクチャ システムを俯瞰する視点「俊敏さ」 抽象化を支えるボトムアップ 俊敏なアーキテクチャの構築法 ITシステム間の接続 データ品質の確保 ビジネスプロセスの最適化 ビジネスの観測可能性の実現 ビジネスの制御可能性の実現 Read More...

非分散アーキテクチャの原則は正しいか？

一般にスケーラビリティを得るためには、分散させないことがアーキテクチャの原則です。 プロセス間通信のマーシャリングコストはインプロセスのローカルコールに対して桁違いのオーバーヘッドになるからです。また、分散トランザクションのロックもこの状況を悪化させます。それにもかかわらず、GoogleやAmazonなど大規模サイトは分散アプローチをとり、スケーラビリティを確保しています。この事実は非分散アーキテクチャの原則を否定しているともいえます。 企業システムや大規模Webアプリケーションを想定する場合、非分散のアーキテクチャの原則は有効でしょうか。分散させない原則は企業システムではなかなか現実的に実行は困難です。性能面だけでなく、管理コスト面で分散システムには不利益がありますが、本当でしょうか？性能面と管理面の2つを考えてみましょう。 Read More...

分散トランザクションを回避するアーキテクチャ

スケールアウトの分散システムにおいての鉄則は分散トランザクションを使わないことです。しかし、現在のプログラミングモデルでは.NETもＪａｖａでもトランザクション伝搬がプログラミングの位置の透過性から防止することができません。つまり、システム設計上トランザクションを利用するとき、開発プロセスの後半の配置の決定の段階で分散配置を選択すると、プログラムはそのまま分散トランザクションを実行してしまいます。この機能は位置の透過性という点では優れているのですが、アーキテクチャのスケラビリティの要求からは、このプログラミングモデルは不都合なのです。 Read More...

アーキテクチャ設計とは

レイヤーアーキテクチャを語るための事前準備。 レイヤーという言葉は開発ライフサイクル管理の中では複数の箇所に登場します。 概念レベルの分析段階で使われるレイヤーは、概念モデルの分類、責務の配置に関して使われます。したがって、分類法の一種です。一方、レイヤーアーキテクチャは、非機能要求を論理的なノード上の配置で動作させるための実現法です。ここで、論理ノードとは必ずしも物理ノードを意味しないで、ノード上のシステムのバージョンや構成定義の条件を決めます。 概念モデルは分析を経て責務がそのモデル上に配置されます。次に概念モデルを適切な分割単位である、パッケージやコンポーネント上で動作させます。このパッケージやコンポーネントの構造がアーキテクチャです。レイヤーアーキテクチャのレイヤーはここでのパッケージの一種です。概念モデルの責務は、適切な基準の下で、パッケージやコンポーネント上に配置されます。この場合、責務を純粋に動作させるのはコンポーネントの方です。 Read More...

レイヤーアーキテクチャはSOAでも有効か

SOAにおけるサービスの実装法ではカプセル化の考え方から、どんな実装法でも選択が可能です。 多くの場合は、OOPを使い、インターフェイス定義を使ってクラスを実装するとともに、インターフェイス定義をWSDLで外部に公開します。 あるいは、Contract-Firstで開発する場合には、先に契約を定義して、実装法を後で選択します。 しかし、この場合でも主流の開発言語がOOPであることや、SOAで必要となる他の非機能要求の実現のために必要な機能を提供する実行環境がOOPのフレームワークで提供されているので、OOPが現実的な選択となります。こうしたフレームワークはたいていの場合、スケーラブルなアーキテクチャを想定するあまり、レイヤー構造となっています。たとえば、.NETの場合は、asmxやWCFを選択し、HTTP実行エンジンとしてはWebサーバ（UI層）、データ処理にはデータアクセス層を利用します。 Read More...

レイヤーアーキテクチャの見直し

現在のソフトウェア技術は不必要に複雑な部分があります。 世の中の要求から、複雑にならざるを得ない部分もあるのですが、 技術的な発展の経緯や、かならずしも技術だけでは決まらない互換性、標準化、政治的決定などがあるからです。 たとえば、ファイナライザは非決定論的なVMのGCに依存する以上、リソースの消費に対して 安全な見積もりができないという点では、あるべき機能ではありません。 また、オブジェクトを生成するDI（依存性注入）と解放するGCは、対となる機能ですが、 実現する場所もメカニズムも異なっています。これは不要な複雑さです。 Read More...

トランザクション処理の現状

トランザクション処理はデータ管理の必須機能で、プログラミングモデルの進化とともに容易に利用できるようになってきました。 このプログラミングモデルの進化で記念的な出来事がMicrosoft Transaction Server（MTS）のプログラミングモデルの登場です。COMコンポーネントに属性による宣言を付け加えることで、トランザクションの実行スコープをメソッドのブロックに限定する発想でした。これ以降は、コンポーネントないしオブジェクトと、トランザクション処理に関するリソースマネージャとの親和性がよくなりました。現在のEJBやその他の属性ベースプログラミングモデルはこのモデルを基盤としているといっても過言ではありません。XMLを使う構成定義でも、.NETのカスタム属性でも、EJBのアノテーションでも基本的な考え方は同じです。属性の宣言により、振る舞いに関するコードを代替えできるので、開発コードの削減や保守の容易化をもたらしました。しかし、一方では属性の氾濫は、コードの可読性や管理の容易性を損なう原因ともなっています。そのために、convention Read More...