顧客に寄りそった要件定義とWell-Architected Frameworkを考える(6/6)
素人がプロのやり方を模倣して、作品を完成させる事が容易です。メンテナンスも楽です。
さあ、これは、モジュール型、インテグラル型？どちらでしょうか？
パーソナルコンピューターはモジュール型アーキテクチャの一例です。ユーザーはCPU、メモリ、ストレージなどの異なるコンポーネントを選択し、素人が、カスタマイズされたPCを構築できます。
自動車はインテグラル型アーキテクチャの一例です。自動車のエンジンやシャシーは複数の機能を統合しており、部品の交換には専門的な知識と技術が必要です。
はじめに
サーバレス化が、進んでいるが、本当にコンテナの活用が有効なのか 、ベテランに聞いたところ、必ずしもそうではないことが、わかったので、ロジカルに分析してみました。サーバレスというと、一度作ってしまえば、同じパターンのコンテナを用意すれば良いのかというと、そうではないようです。サーバレス化をする際、イメージにまとめるなどの統合をおこなう事が特徴です。確かに統合してしまえば、 インテグラルで、構築時は、全体最適化されている状態になると思います。ただ、これが曲者になる場合もあるので、注意が必要だという事です。部品の交換やアップグレードが困難であり、しばしば製品全体を交換する必要があります。
製品アーキテクチャは、製品を構成する部品やサブシステムの配置と統合の方法を指します。製品アーキテクチャには主にモジュール型（Modular Architecture）とインテグラル型（Integral Architecture）の二つのタイプがあります。これらのアーキテクチャは、製品の設計、製造、メンテナンスにおいて異なるアプローチを取ります。
モジュール型とインテグラル型アーキテクチャにおけるWebサーバーとデータベースサーバーの構築パターン例
モジュール型アーキテクチャ
構築時に、モジュール間の連携を考慮する必要があるが、カスタマイズが容易で、メンテナンスがし易い。素人がプロのやり方を模倣して、作品を完成させる事が容易です。
例). マイクロサービスアーキテクチャを取り、小さなサービスを組み合わせて統合することで大規模アプリケーションを構成する方式を取ります。各サービスが独立して動作 するため、テクノロジーの多様性への対応や拡張性も高く、システム全体に大きな影響を与えることなく柔軟にアプリケーションの開発が可能になります。
インテグラル型アーキテクチャ
短期間で用意する事が可能だが、カスタマイズがめんどくさい。構築時は、全体最適だが、時間の経過と供に、パーツに不具合が生じるので、メンテナンスが工数が膨大。素人がプロのやり方を模倣して、作品を完成させる事が難しいです。
例). Amazon Elastic Beanstalk または コンテナを使用します。
参考 バージョンが変わるたびにイメージを作り直す手間が生じる場合がある。
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/kubernetes-versions.html
https://qiita.com/oruharo/items/8309ac2836aa27e3efe0
メンテナンスを行う技術力が豊富にあるというならば、インテグラル型で良いと思います。
モジュール型アーキテクチャ
特徴
- 標準化されたインターフェース モジュール型アーキテクチャでは、部品やサブシステムが標準化されたインターフェースを通じて組み合わされます。これにより、各モジュールを独立して設計、製造、交換することが可能になります。
- 柔軟性 異なるモジュールを組み合わせることで、製品のバリエーションを容易に増やすことができます。また、特定のモジュールのアップグレードや交換が容易です。
- カスタマイズ 顧客のニーズに合わせて製品をカスタマイズすることが容易で、市場の変化に迅速に対応できます。
インテグラル型アーキテクチャ
特徴
- 密接な統合 インテグラル型アーキテクチャでは、部品やサブシステムが密接に統合されており、一つの部品が複数の機能を果たすことがあります。
- 最適化 製品全体が最適化されており、部品間の相互作用が製品のパフォーマンスを向上します。
- メンテナンスの複雑さ 部品の交換やアップグレードが困難であり、しばしば製品全体を交換する必要があります。
モジュール型とインテグラル型の違い
- 設計の柔軟性 モジュール型は部品の独立性が高く、設計の柔軟性に優れています。一方、インテグラル型は部品間の相互依存性が高く、全体としての最適化が求められます。
- 製品のカスタマイズ モジュール型は顧客のニーズに合わせたカスタマイズが容易ですが、インテグラル型はカスタマイズが困難です。
- 製造とメンテナンス モジュール型は製造とメンテナンスが容易で、部品の迅速な交換が可能です。インテグラル型はメンテナンスが複雑で、コストが高くなる傾向があります。
ステップ1: 要件定義
モジュール型にするか、インテグラル型にするのか、方針を決めて、要件定義を行います。
将来的な変更のし易さを優先するならば、モジュール型を採用します。
部品が少ないならば、部品間の相互作用を最大化するインテグラル型を採用します。
-
モジュール型アーキテクチャの適用
- プロジェクトの柔軟性とカスタマイズのニーズを考慮して、モジュール型アーキテクチャを採用するかどうかを決定します。これにより、将来的な拡張や変更に対応しやすい設計を目指します。
-
インテグラル型アーキテクチャの適用
- 製品 全体の最適化とパフォーマンスを重視 する場合は、インテグラル型アーキテクチャを採用します。これにより、部品間の相互作用を最大化し、全体としての効率を高めることができます。
ステップ2: 概要設計
-
Well-Architected Frameworkの適用
- AWS Well-Architected Frameworkの5つの柱を基に、システムの概要アーキテクチャを設計します。この段階では、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性を考慮に入れます。
-
モジュールの選定
- モジュール型アーキテクチャを採用する場合は、各モジュールのインターフェースを標準化し、独立性を確保 します。
-
統合の計画
- インテグラル型アーキテクチャを採用する場合は、部品やサブシステムの密接な統合を計画し、全体としての 最適化 を図ります。
ステップ3: 詳細設計
-
モジュールの詳細設計
- 各モジュールの詳細な設計を行い、標準化されたインターフェースを通じて組み合わせられるようにします。
-
統合部品の詳細設計:
- インテグラル型アーキテクチャの場合は、部品間の統合を詳細に設計し、相互作用を最大化 します。
-
運用とメンテナンスの計画
- モジュール型アーキテクチャでは、運用とメンテナンスの容易さ を考慮し、インテグラル型アーキテクチャでは、全体の 最適化 を考慮した運用計画を立てます。
このプロセスを通じて、プロジェクトチームは、モジュール型アーキテクチャの 柔軟性とカスタマイズの利点 と、インテグラル型アーキテクチャの最適化とパフォーマンスの利点をバランス良く組み合わせることができます。
読んで頂きまして、ありがとうございました。
顧客に寄りそった要件定義とWell-Architected Frameworkを考える(1/6)
https://qiita.com/kimuni-i/items/aff6339130f160de16af
顧客に寄りそった要件定義とWell-Architected Frameworkを考える(2/6)
https://qiita.com/kimuni-i/items/4da6a2c91a5ecdf2c526
顧客に寄りそった要件定義とWell-Architected Frameworkを考える(3/6)
https://qiita.com/kimuni-i/items/1760874d6eec96fe75d7
顧客に寄りそった要件定義とWell-Architected Frameworkを考える(4/6)
https://qiita.com/kimuni-i/items/496ae4d41c8098f32f21
顧客に寄りそった要件定義とWell-Architected Frameworkを考える(5/6)
https://qiita.com/kimuni-i/items/a893228ce1ab52d3133e
顧客に寄りそった要件定義とWell-Architected Frameworkを考える(6/6)
https://qiita.com/kimuni-i/items/8dadc65f38d06a960f1a
AWS Well-Architected アーキテクチャのベストプラクティスを使う
https://qiita.com/kimuni-i/items/9f08f382ad73a03f601d