Wondershare EdrawMind
マインドマップギャラリー システムインテグレーションプロジェクトマネジメントエンジニア 第3版第4章 情報システムアーキテクチャ
- 7
システムインテグレーションプロジェクトマネジメントエンジニア 第3版第4章 情報システムアーキテクチャ
システムインテグレーションプロジェクトマネジメントエンジニア 第3版/第4章 情報システムアーキテクチャ、情報システムアーキテクチャとは、情報システムに関連するコンポーネント、関係、システム設計と進化の原則を反映する基本的な概念または特性を指します。
2024-03-17 11:39:10 に編集されました
- おすすめ
- アウトライン
情報システムアーキテクチャ
一、 アーキテクチャの基礎
I. まとめ
米国電気電子学会 (IEEE) は、システム アーキテクチャとは、システムのコンポーネント構成、コンポーネント間の関係、システムとその環境との関係、ガイドラインなど、システムを構成する基本的な組織構造であると考えています。建築設計と進化のために。システム カテゴリに組織のシステム全体が含まれる場合、アーキテクチャは組織の情報システム アーキテクチャの方向、構造、関係、原則、標準を定義します。
情報システム アーキテクチャとは、情報システム関連のコンポーネント、関係、システム設計と進化の原則を具体化する基本的な概念または特性を指します。
情報システム統合プロジェクトに関わるアーキテクチャには、通常、システム アーキテクチャ、データ アーキテクチャ、テクノロジー アーキテクチャ、アプリケーション アーキテクチャ、ネットワーク アーキテクチャ、セキュリティ アーキテクチャなどが含まれます。組織レベルの情報システム統合アーキテクチャは、組織の開発戦略とビジネス アーキテクチャを上向きに伝え、下向きに導きます。特定の情報システム計画の実施に伴い、前と次を繋ぐバックボーンの役割を果たします。
この階層構造は、組織の戦略目標、運用モデル、情報化レベルに基づいて決定する必要があり、ビジネス価値の実現を密接にサポートします。
建築の本質は、方向性、構造、関係性、原理など、さまざまな要素を考慮した上での意思決定です。情報システムプロジェクトは、プロジェクト構築の指針となるイデオロギー、設計原則、構築目標に基づいて、さまざまなアーキテクチャの設計を実行できます。
II. 指導的イデオロギー
指導的イデオロギーは、特定の作業を実行するために従わなければならない全体的な原則、要件、ガイドラインであり、指導的イデオロギーの実装を通じて、マクロな観点から作業の進行を導きます。プロジェクトの複数の参加者が価値観の一貫した理解を維持することを促進し、それによって不必要な矛盾や対立を減らします。
例：ある都市における社会保険スマートガバナンスセンター建設の指導イデオロギーは次のように定義されている：習近平の新時代の中国の特色ある社会主義思想に導かれ、第20回全国代表大会の精神を完全に実践する。中国共産党は人民中心の発展理念を堅持し、人民のためにすべてを堅持し、すべてにおいて人民に依存し、常に人民を心の最上位に置き、人民のより良い生活への切望を真摯に受け止める。私たちの取り組みの目標は、新時代の社会保険改革と発展のニーズに適応し、社会保険業務の重要分野と重要なつながりに焦点を当て、計画を調整し、イノベーションを推進し、データに力を与え、包括的に実行することです。都市のスマートな人間社会ガバナンスセンターを構築し、新時代のスマート社会保険制度、イノベーションシステム、能力開発を推進し、社会保険ガバナンス能力とサービスレベルを継続的に向上させ、新時代の高品質な社会保険事業を提供する。 . 開発は強力な情報サポートを提供し、特定の都市の統治システムと統治能力の近代化を促進します。
III. 設計原則
設計原則は、アーキテクチャと計画の決定、ポリシー、手順、標準の開発、および矛盾する状況の解決のための強固な基盤を提供します。
原則は多数ある必要はありませんが、未来志向であり、関連当事者の上級管理者によって認識され、支持され、遵守される必要があります。原則が多すぎるとアーキテクチャの柔軟性が低下し、多くの組織は上位レベルの原則のみを定義する傾向があり、多くの場合、その数は 4 ～ 10 に制限されます。
都市の社会保険スマート ガバナンス センターを構築するための設計原則には、次のものが含まれます。
1. 人間本位を貫く
人間中心の発展理念を堅持し、人々のサービスニーズとサービス経験を綿密にフォローし、特定の都市での社会保険スマートガバナンスセンターの建設を通じて、人々の満足、不満、不満、不満を仕事の目標とします。では、某都市における充実した社会保険公務員制度の構築を支援します。
2. イノベーションのリーダーシップを堅持する
インターネット、ビッグデータ、インテリジェンス、モノのインターネット、5G、AI、GISなどの主流テクノロジーを包括的に利用し、メカニズム改革、モデルイノベーション、データドライブ、テクノロジーエンパワーメントを原動力として、社会保険スマートガバナンスセンターを構築し、ある都市における社会保険の近代化を推進する 統治システムと統治能力の近代化。
3. 問題の方向性を遵守する
私たちは、特定の都市におけるスマートな社会保険ガバナンスセンターの構築の焦点として、特定の都市における社会保険の発展を制限する重要な、困難な、問題点の解決に焦点を当て、突破口を特定し、適切性を高め、全体的な状況を強調します。 、サービスの標準化、専門化、コラボレーションを改善します。管理と管理のレベルは、知的、正確、科学的である必要があります。
4. 全体的なコーディネートを大切にする
都市の社会保険スマート ガバナンス センターの構築では、システム接続、政策サポート、部門連携、ビジネス コラボレーション、データ共有などの多面から始めて、ビジネスとテクノロジーを創出する都市の社会保険システムの全体的な作業に焦点を当てる必要があります。内部と外部、水平の垂直、オンライン、オフラインを統合した新しいスマートな社会保険システムは、新時代の社会保険の質の高い発展を支える新たな原動力となっています。
5. 安全性とコントロール性へのこだわり
特定の都市で社会保険スマートガバナンスセンターを構築するには、革新的な開発とセキュリティの関係を適切に処理し、情報セキュリティと個人のプライバシー保護を強化し、マルチレベルの社会保険リスク予防および管理システムを改善し、信頼性と利用可能性を統合する必要があります。 、持続可能な情報サポート能力。
6. 科学的実施を遵守する
ある都市の社会保険スマートセンターの全体計画と建設計画に従って、社会保険スマートガバナンスセンターの建設と金融保険プロジェクト全体の建設との境界、関係、優先順位を明確にし、既存の政策を最大限に活用する。情報インフラストラクチャとアプリケーションシステムを調整し、計画を調整し、特定の都市における社会保険スマートガバナンスセンターの構築の有効性が完全に発揮されることを保証するために、実装は実装可能、運用可能、および評価可能であることに焦点を当てて慎重に実施する必要があります。
IV. 構築の目標
建設目標とは、統合建設の最終目標、どのような効果が得られるのか、なぜそれが実現されるのかを指し、通常、関係者の幹部が提案するアイデアやビジョンが建設目標となります。
都市の社会保険スマートガバナンスセンターの建設目標は、新時代の社会保険業界の機能的使命と発展方向に基づき、「委任、規制、サービス」の改革要件に従い、以下のように定義されています。新しい公共管理理論、インターネットの包括的な利用、ビッグデータ、インテリジェンス、現代の思考とモノのインターネット、5G、AI、GIS などの主流テクノロジーは、ビジネス ガバナンス、包括的ガバナンス、ビッグ データ ガバナンスに焦点を当てています。ある年までに、サービス機能、インテリジェントな監督機能、およびリスク管理を包括的に改善するために、汎接続、オープン、統合、リンク、インテリジェント、オンライン、可視性、安全性を備えた都市の社会保険スマート ガバナンス センターが最初に構築されます。都市の社会保険システムの予防および制御機能、意思決定分析機能、およびグローバル連携機能により、国内をリードする社会保険インテリジェントガバナンスシステム、インテリジェントなリスク管理システム、インテリジェントなコネクテッドビジネスシステム、およびインテリジェントな大衆給付システムの構築が促進されます。 、都市ガバナンス業界の新たなベンチマークを確立し、社会保険ガバナンスに関する新たな国家パラダイムを構築し、新時代における特定の都市における質の高い社会保険の発展を促進する新たな推進力を提供し、科学的政策の改善に貢献します。特定の都市の統治の洗練された知的なレベル。
V. 全体的な枠組み
フレームワークは、アーキテクチャの計画、開発、実装、管理、および保守に使用される概念的な構造です。フレームワークは、アーキテクチャの設計にとって重要です。このフレームワークは、組織のビジネス内容への注目を合理的に分離し、ロールを出発点として使用して、組織のビジネス内容をさまざまな視点から表示します。このフレームワークは、アーキテクチャ設計のロードマップを提供し、高度で効率的かつ適用可能なアーキテクチャを構築するという目標を達成するためにアーキテクチャ設計を導き、支援します。
情報システム アーキテクチャの全体的な参照フレームワークは、次の 4 つの部分で構成されます。
1. 戦略システム
戦略システムとは、組織内の戦略策定や高度な意思決定に関連する管理活動およびコンピュータ支援システムを指します。
情報システム アーキテクチャ (ISA) では、戦略システムは 2 つの部分で構成されます。
1||| 1つは情報技術を活用した高度な意思決定支援システムです。
2||| 2つ目は、組織の戦略計画システムです。
ISA における戦略体制の確立には 2 つの意味があります。
1||| まず、組織のトップ マネージャーに対する情報システムの意思決定サポート機能を表します。
2||| 第二に、情報システム構築に対する組織戦略計画の影響と要件を表します。
通常、組織の戦略計画は長期計画と短期計画の 2 種類に分けられます。長期計画は、製品構造の調整など、一般に長期計画の目的に基づいて策定されます。 -期の計画を立てることができ、新製品の種類の決定など、環境や組織運営の変化に適応することが比較的容易です。
2. 業務システム
ビジネスシステムとは、一定のビジネス機能を遂行する組織内のさまざまな部分（物質、エネルギー、情報、人）から構成されるシステムを指します。
組織内には、生産システム、販売システム、購買システム、人事システム、会計システムなどの多くの業務システムが存在します。各業務システムは、業務システムの機能を完成させるためのいくつかのビジネス プロセスで構成されています。多くの場合、買掛金、買掛金、会計システム、請求書発行、監査、その他のビジネス プロセスが含まれます。
ビジネス プロセスは、論理的に相互依存する一連のビジネス アクティビティに分解できます。各ビジネス アクティビティは、関連するデータを実行および処理する役割を持っています。組織が内部および外部の開発環境 (情報システムの導入と使用など) にさらに適応するために開発戦略を調整するとき、多くの場合、ビジネス プロセスの再編成が実行されます。業務プロセス再編とは、業務プロセスを中心に、組織の機能部門間の分業を打破し、既存の業務プロセスを改善・再編することで、生産効率、コスト、品質、納期などの大幅な改善を図り、生産性の向上を図るものです。組織の競争力。
ISA におけるビジネス システムの役割は次のとおりです。
組織の既存のビジネス システム、ビジネス プロセス、およびビジネス活動をモデル化し、組織の戦略の指導の下、ビジネス プロセス リエンジニアリング (BPR) の原則と手法を使用してビジネス プロセスを最適化および再編成し、再構築されたビジネス領域、ビジネスを実行します。プロセスや事業活動をモデル化し、比較的安定したデータをもとに、組織のアプリケーションシステムの開発や情報インフラの構築を行います。
3. オペレーティング·システム
アプリケーションシステムはアプリケーションソフトウェアシステムであり、情報システムのアプリケーションソフトウェア部分を指します。
組織情報システムのアプリケーション ソフトウェア (アプリケーション システム) の場合、一般に完成した機能には次のものが含まれます。
（1） トランザクション処理システム (TPS)
（2） 経営情報システム (MIS)
1||| 販売管理サブシステム
2||| 調達管理サブシステム
3||| 在庫管理サブシステム
4||| 輸送管理サブシステム
5||| 財務管理サブシステム
6||| 人事管理サブシステムなど
（3） 意思決定支援システム (DSS)
（4） エキスパートシステム（ES）
（5） オフィスオートメーションシステム（OAS）
（6） コンピュータ支援設計/コンピュータ支援プロセス設計/コンピュータ支援製造、製造実行システム(MES)など
アプリケーション システムがどのレベルであっても、アーキテクチャの観点から見ると、内部機能実装部分と外部インターフェイス部分という 2 つの基本コンポーネントが含まれています。これら 2 つの基本部分は、より具体的なコンポーネントとそれらの間の関係で構成されます。インターフェイス部分は、アプリケーション システムの中で比較的頻繁に変更される部分であり、主にインターフェイス形式に対するユーザーの要件の変更によって引き起こされます。機能実装部分では、主にアプリケーションシステムに対するユーザーの機能要件の変化やインターフェース形状の要件の変化により、処理されるデータの変化は少なく、プログラムのアルゴリズムや制御構造の変化が大きくなります。
4. 情報インフラ
組織の情報インフラストラクチャとは、組織の現在のビジネス、予測可能な開発傾向、および情報の収集、処理、保管、流通の要件に基づいて、情報機器、通信ネットワーク、データベース、システム ソフトウェアおよび支援ソフトウェアで構成される環境の構築を指します。
組織の情報インフラストラクチャは 3 つの部分に分かれています。
1||| 技術インフラストラクチャ
コンピュータ機器、ネットワーク、システムソフトウェア、サポートソフトウェア、データ交換プロトコルなどで構成されます。
2||| 情報資源施設
データと情報そのもの、データ交換の形式と標準、情報処理方法などで構成されます。
3||| 経営インフラ
組織における情報システム部門の組織構造、情報資源施設管理者の役割分担、組織の情報基盤の管理方法や規程などを指します。
テクノロジーの発展と組織のシステム要件の変化により、技術インフラストラクチャーは情報システムの設計、開発、保守において多くの変化要因に直面しており、実装テクノロジーの多様性により、同じ機能を実現する方法も複数存在します。情報リソース設備は、組織がどのような機能を実行するか、またはビジネス プロセスがどのように変化するかに関係なく、データと情報を処理する必要があり、そのほとんどはビジネスの変化によっても変化しません。これは、特に我が国の市場経済への移行や経済政策の導入の段階において、組織は環境の変化に適応し、競争のニーズに応える必要があるためです。 、ビジネスモデル改革などが大きな影響を及ぼし、組織のルールや規制、管理方法、人事分業、組織構造の変化につながります。 上記は、情報インフラストラクチャの 3 つの基本コンポーネントの相対的な安定性と相対的な変化の全体的な説明にすぎません。技術インフラストラクチャ、情報リソース設備、および管理インフラストラクチャには、比較的安定した部分と比較的不安定な部分が存在します。
5. 戦略システムは第 1 レベルにあり、その機能は戦略管理レベルの機能と似ていますが、一方ではビジネス システムの革新、再構築、リエンジニアリングの要件を推進し、他方では統合を推進します。アプリケーション システムの要件。ビジネスシステムとアプリケーションシステムは第 2 層にあり、戦術管理層に属します。ビジネスシステムは業務処理プロセスの最適化を通じて組織を管理および制御し、アプリケーションシステムは情報とデータを効果的に活用する手段を提供します。この制御により、組織の業務効率が向上します。情報インフラストラクチャは第 3 層にあり、組織の情報化とデジタル化を実現するための基本的な部分であり、アプリケーション システムや戦略システムのコンピューティング、伝送、データなどのサポートを提供します。同時に、組織のビジネス システム再編のための効果的、柔軟、即応性の高い技術および管理サポート プラットフォームも提供します。
二、 システム構造
I. アーキテクチャの定義
i. 一般的な定義には主に次のようなものがあります。
①ソフトウェアまたはコンピュータシステムの情報システムアーキテクチャは、システムの1つ（または複数）の構造であり、その構造はソフトウェア要素、外部から見える要素の属性、およびそれらの間の関係で構成されます。
②情報システムアーキテクチャは、システムを構成する要素の記述、これらの要素の相互作用、要素の統合を導くパターン、およびそしてこれらのパターンの制約。
③情報システムアーキテクチャとは、システムのコンポーネント、コンポーネント間の関係、コンポーネントと環境の関係で具体化されるシステムの基本的な構成、およびその設計と進化を導く原則を指します。
最初の 2 つの定義は、「要素-構造-アーキテクチャ」という抽象レベルに従って記述されており、それらの基本的な意味は同じです。この定義における「ソフトウェア要素」は、「コンポーネント」よりも一般的な抽象概念を指し、要素の「外部から見えるプロパティ」は、その要素が提供するサービス、パフォーマンス特性、等
ii. それは次の6つの側面から理解できます。
1. アーキテクチャは、要素、その外部から見えるプロパティ、要素間の関係を記述することによってこの抽象化を反映するシステムの抽象化です。したがって、内部の具体的な実装にのみ関連する詳細はアーキテクチャの一部ではありません。つまり、定義は要素の「外部から見える」プロパティを強調しています。
2. アーキテクチャは複数の構造で構成されます。構造は機能の観点から要素間の関係を記述しますが、個々の構造は一般に大規模な情報システム アーキテクチャを表すことができません。
3. どのソフトウェアにもアーキテクチャがありますが、そのアーキテクチャを説明した特定のドキュメントが必ずしも存在するとは限りません。つまり、アーキテクチャは、アーキテクチャの記述とは独立して存在できます。ドキュメントが古い場合、スキーマは反映されません。
4. 要素とその動作の集合がアーキテクチャのコンテンツを構成します。システムはどのような要素で構成され、これらの要素はどのような機能を持ち (外部から見える)、これらの要素はどのように接続され相互作用するのでしょうか?つまり、抽象化は 2 つの側面で実行されます。静的側面では、システムの大粒度 (マクロ) 全体構造 (階層化など) に焦点を当て、動的側面では、システム内の主要な動作の共通特性に焦点を当てます。システム。
5. アーキテクチャは「基本的」です。通常、アーキテクチャには、さまざまな重要な繰り返しの問題 (再利用性) に対する共通の解決策と、システム設計における広範囲にわたる影響を伴う重要な決定 (アーキテクチャに依存する) が含まれます (一度実装すると、変更には費用がかかります)。
6. アーキテクチャは「意思決定」を意味します。つまり、アーキテクチャは、主要な機能要件および非機能要件 (品質属性とプロジェクト関連の制約) に基づいたアーキテクトによる設計と意思決定の結果です。
iii. 情報システム アーキテクチャは組織にとって非常に重要であり、主に次の点に反映されます。
① アーキテクチャに影響を与える要因。
ソフトウェア システムのプロジェクト関係者 (顧客、ユーザー、プロジェクト マネージャー、プログラマー、テスター、マーケティング担当者など) はソフトウェア システムに対して異なる要件を持ち、開発組織 (プロジェクト チーム) の人員知識構造も異なり、ソフトウェア システムの品質も異なります。アーキテクチャ設計者 経験や現在の技術環境などの側面はすべて、アーキテクチャに影響を与える要素です。これらの要因は、機能要件、非機能要件、制約、および矛盾する要件を通じてアーキテクトの決定に影響を与えることにより、アーキテクチャに影響を与えます。
② アーキテクチャは、開発組織の構造に影響を与えるなど、上記の要因に逆効果をもたらします。
アーキテクチャはシステムの大粒度（マクロ）な全体構造を記述するため、アーキテクチャに応じて作業を分割することができ、プロジェクト グループがいくつかのワーキング グループに分かれることにより、開発組織の目標に影響を与える秩序ある開発が可能になります。つまり、成功したアーキテクチャは開発組織に次のことを提供します。同時に、システムの実証性、アーキテクチャの再利用性、チームの開発経験の向上により、新しいビジネス チャンスが生まれます。次のシステムに対する顧客の要件に影響を与えます。
II. アーキテクチャの分類
i. 分類
1. 物理アーキテクチャ
物理アーキテクチャとは、システムの各部分の実際の動作や機能アーキテクチャを考慮せず、ハードウェア システムの空間分布のみを抽象的に検討することを指します。
宇宙における情報システムの位相関係に従って、それらは一般に次のように分類されます。
（1） 集中型アーキテクチャ
集中型アーキテクチャとは、空間内の物理リソースを集中的に割り当てることを指します。
初期のスタンドアロン システムは、ソフトウェア、データ、主要な外部デバイスをコンピュータ システムに集中させた、最も典型的な集中型アーキテクチャでした。端末を介してリソースを共有する、異なる場所に分散した複数のユーザーで構成されるマルチユーザー システムも集中型アーキテクチャです。集中型アーキテクチャの利点は、リソースが集中化され、管理が容易になり、リソースの使用率が高くなる点です。しかし、システム規模の拡大やシステムの複雑化に伴い、集中型アーキテクチャの維持管理はますます困難となり、情報システム構築プロセスへの利用者の熱意や主体性、参加意識が発揮されにくい場合が多くなります。また、リソースが集中しすぎるとシステムが脆弱になり、コアリソースに異常が発生するとシステム全体が麻痺しやすくなります。
（2） 分散アーキテクチャ
分散システムとは、コンピュータ ネットワークを介して異なる場所にあるコンピュータ ハードウェア、ソフトウェア、データ、その他のリソースを接続し、異なる場所でリソースの共有を実現することを指します。
分散アーキテクチャの主な特徴は、アプリケーションの要件に応じてリソースを構成できるため、ユーザーのニーズや外部環境の変化に対する情報システムの適応性が向上し、システムの拡張が容易であり、特定のノードに障害が発生してもセキュリティが確保されることです。システム全体の機能を停止することはありません。しかし、リソースは分散しており、さまざまなサブシステムに属しているため、システム管理基準の統一や調整が難しく、リソース全体の計画・管理が困難です。
分散アーキテクチャは次のように分類できます。
1||| 一般的な分散システム
サーバーはソフトウェア、コンピューティング、およびデータ サービスのみを提供し、各コンピューター システムは指定されたアクセス許可に従ってサーバー上のデータとプログラム ファイルにアクセスします。
2||| クライアント/サーバー アーキテクチャ
クライアントとサーバーの 2 つのカテゴリに分類されます。サーバーには、ファイル サーバー、データベース サーバー、プリント サーバーなどが含まれます。ネットワーク ノード上の他のコンピュータ システムはクライアントと呼ばれます。ユーザーはクライアントを通じてサーバーに対してサービス要求を行い、サーバーは要求に応じて加工された情報をユーザーに提供します。
2. 論理アーキテクチャ
論理アーキテクチャとは、情報システムのさまざまな機能サブシステムの統合を指します。
情報システムの論理アーキテクチャは、その機能が複雑で概念的なフレームワークです。
生産組織の経営情報システムは、調達、生産、販売、人事、財務などの主要な機能を持つ情報管理サブシステムを含め、管理機能の観点から分割されています。完全な情報システムは、組織のさまざまな機能サブシステムをサポートし、各サブシステムがトランザクション処理、運用管理、管理制御、戦略計画などのさまざまなレベルで機能を完了できるようにします。各サブシステムは独自の専用ファイルを持つことができると同時に、情報システム内の各種データを共有することができ、ネットワークやデータなどの標準化されたインターフェースを介してサブシステム間の接続を実現します。同様に、各サブシステムには独自のアプリケーション プログラムがあり、システム モデル ライブラリ内のさまざまな機能やモデルを提供するパブリック プログラムを呼び出すこともできます。
ii. システム統合
1. 水平統合
水平統合とは、さまざまな機能やニーズを同じレベルで統合することを指します。たとえば、運用管理層の人事および給与サブシステムを統合して、草の根の業務処理を統合します。
2. 垂直統合
垂直統合とは、特定の機能と要件を備えたあらゆるレベルのビジネスを組織することを指します。この統合では、たとえば、組織部門の会計システムと組織全体の会計システムがすべて統合されています。共通の処理プロセスを形成できます。
3. 垂直方向と水平方向の統合
垂直統合と水平統合とは、情報の一元的な共有を実現し、プログラムを可能な限りモジュール化し、共通部分の抽出に留意し、システム共通のデータシステムと統合情報を確立するために、主に情報モデルと処理モデルの2つの側面から統合することを指します。処理システム。
III. 一般原理
情報システムアーキテクチャとは、組織の戦略、事業、組織、経営、技術などをコンポーネントを中心に総合的に検討し、多次元・階層的・統合的かつオープンなオープンシステムを構築することを指します。体系的なアーキテクチャを採用し、組織に情報システムのある程度の柔軟性と柔軟かつ効果的な実装方法を提供します。
アーキテクチャは、コンポーネントとコンポーネント間の関係という 2 つの基本的な部分で構成されます。
情報システムでは、比較的安定した構成要素と関係が抽出され、比較的安定した部分のサポートを受けて、変化する要件に合わせて相対的に変化する部分が再編成され、情報システムが環境の変化に対応できるようになります。適応性の程度、つまりある程度の柔軟性は、情報システム アーキテクチャの基本原則です。
IV. 一般的な建築モデル
i. スタンドアロン アプリケーション モード
スタンドアロン システムは最も単純なソフトウェア構造であり、物理マシン上で実行されることを指します。 スタンドアロン アプリケーション。もちろん、アプリケーションはマルチプロセスまたはマルチスレッドにすることができます。
大規模なソフトウェア システムには、グラフィカル インターフェイス上で統合および実行される多くのサブシステムが必要であり、Linux、UNIX、Windows などの複数のプラットフォームで実行できます。コンピュータ支援設計分野のCATIA、Pro/Engineer、AutoCADなどのプロフェッショナル分野の製品や、画像処理・編集分野でおなじみのPhotoshop、CorelDRAWなど。
ソフトウェアアーキテクチャ設計のより重要な応用分野は情報システムの分野、すなわちデータ処理（データの保存、送信、セキュリティ、クエリ、表示など）を中核とするソフトウェアシステムです。
ii. クライアント/サーバーモード
クライアント/サーバー モデルは、情報システムで最も一般的なモデルです。これは、TCP/IP プロトコルに基づくプロセス間通信 IPC プログラミングの「送信」および「反射」プログラム構造として理解できます。つまり、クライアントが TCP または UDP パケットをサーバーに送信し、サーバーが受信したリクエストまたは UDP パケットに基づいてクライアントに返される TCP パケット。
4 つの一般的なアーキテクチャ
1. 2層C/S
2 層 C/S は本質的に、IPC クライアント/サーバー構造のアプリケーション システムの具体化です。それが「ファットクライアント」モードです。実際のシステム設計では、この種の構造は主にフロントエンドのクライアントとバックエンドのデータベース管理システムを指します。
フロントエンド インターフェイスとバックエンド データベース サービス モデルが最も一般的です。データベース フロントエンド開発ツール (PowerBuilder、Delphi、VB など) はすべて、この構造を具体的に作成するために使用されるソフトウェア ツールです。
2. C/S、B/Sの3層構造
データベース アクセス操作に加えて、フロントエンド インターフェイスはバックエンドにリクエストを送信し、処理する必要のあるビジネス ロジックは他にも多数あります。 3 層 C/S のフロントエンド インターフェイスとバックエンド サービスは、プロトコル（独自開発または標準プロトコルを使用）を通じて通信（リクエスト、応答、リモート関数呼び出しなどを含む）する必要があります。
通常、次のものが含まれます。
1||| TCP/IP プロトコルに基づいており、基盤となるソケット API に基づいて直接開発されています。これは通常、要件と機能が単純な小規模システムにのみ適しています。
2||| まず、カスタム メッセージ メカニズムが確立され (TCP/IP およびソケット プログラミングをカプセル化)、次にこのメッセージ メカニズムを通じてフォアグラウンドとバックグラウンド間の通信が実現されます。メッセージ メカニズムは、XML またはバイト ストリーム (Stream) 定義に基づくことができます。カスタム通信ですが、それをベースに大規模な分散システムを構築できます。
3||| RPC プログラミングに基づいています。
4||| CORBA/IOP プロトコルに基づいています。
5||| Java RMI に基づいています。
6||| J2EE JMS に基づいています。
7||| HTTP プロトコルに基づいて、ブラウザと Web サーバー間の情報交換などを行います。ここで注意しなければならないのは、HTTP はオブジェクト指向の構造ではなく、オブジェクト指向のアプリケーション データはまずフラット化されてから送信されるということです。
3 層 C/S 構造に基づく最も代表的なアプリケーション モデルは、B/S (ブラウザ/サーバー、ブラウザ/サーバー) モデルです。
Web ブラウザは、ドキュメントの取得と表示に使用されるクライアント アプリケーションであり、ハイパー テキスト転送プロトコル HTTP (Hyper Text Transfer Protocol) を介して Web サーバーに接続されます。このモードでは、汎用の低コストブラウザにより、2層構造のC/Sモードクライアントソフトウェアの開発費や保守費を節約できます。これらのブラウザは、MSInternet Explorer、Mozilla FireFox など、誰もがよく知っています。
Web サーバーは、インターネット上の特定の種類のコンピューターに常駐するプログラムを指します。 Web ブラウザ (クライアント) がサーバーに接続してファイルまたはデータをリクエストすると、サーバーはリクエストを処理してファイルまたはデータをブラウザに送信し、付随する情報によってファイル (つまり、ファイル) を表示する方法がブラウザに指示されます。タイプ）。サーバーは情報交換に HTTP を使用するため、HTTP サーバーと呼ぶこともできます。
人々は毎日 Web ブラウザ上でさまざまな操作を実行しますが、これらの操作のほとんどは実際には Web サーバー上で実行され、Web ブラウザはユーザーのリクエストを HTTP プロトコル形式で Web サーバーに送信するか、クエリの結果を表示するだけです。もちろん、Web ブラウザとサーバーをホストするハードウェア デバイスは、Web ネットワーク上で数千マイル離れた場所にある 2 台のコンピュータである可能性があります。
B/S モード ブラウザと Web サーバー間の通信は依然として TCP/IP ですが、プロトコル形式はアプリケーション層で標準化されていることを強調しておく必要があります。実際、B/S はユニバーサル クライアント インターフェイスを採用した 3 層の C/S 構造です。
3. 多層C/S構造
多層C/S構造とは、一般に3層以上の構造を指しますが、実際には主にフロントエンドインタフェース（ブラウザなど）、Webサーバ、ミドルウェア（またはアプリケーションサーバ）、データベースサーバの4層になります。 。
ミドルウェア層は主に次の作業側面を完了します。
1||| システムのスケーラビリティを向上させ、同時実行パフォーマンスを向上させます。
2||| ミドルウェア/アプリケーション層は、リクエストの転送やアプリケーション ロジックに関連する一部の処理に特化しており、この機能を備えたミドルウェアは、一般にリクエスト プロキシまたはアプリケーション サーバーとして使用できます。ミドルウェアのこの役割は、J2EE の多層構造でよく使用されます。たとえば、BEA WebLogic、IBM WebSphere などによって提供される EJB コンテナは、複雑な組織ロジックを処理するために特別に設計されたミドルウェア テクノロジのコンポーネントです。
3||| データのセキュリティを強化します。
4. モデル-ビュー-コントローラーのパターン
Model-View-Controller (MVC) は、実際には、上記の多層 C/S 構造の一般的に使用される標準化パターンです。
J2EE アーキテクチャでは、ビュー プレゼンテーション層はリクエスト結果をグラフィカルに表示するために使用されるブラウザ層を指し、コントローラーは Web サーバー層を指し、モデル モデル層はアプリケーション ロジックの実装とデータ永続化部分を指します。現在人気のある J2EE 開発フレームワーク (JSF、Struts、Spring、Hibernate など)、およびそれらの組み合わせ (Struts Spring Hibernate (SSH)、JSP Spring Hibernate など) はすべて MVC アーキテクチャーを指向しています。また、PHP、Perl、MFC などの言語には、いずれも MVC 実装パターンがあります。
MVC では主にプレゼンテーション層 (ビュー) とデータ層 (モデル) のコードを分離する必要があり、コントローラーを使用して接続できます。 ユーザーのニーズを満たすさまざまなモデルとビュー。階層化システムの観点から見ると、MVC の階層構造、そのコントローラーおよびビューは通常、Web サーバー レベルにあり、「モデル」がビジネス ロジック処理を個別のサービス処理に分離するかどうかに応じて、MVC は 3 つの層または 4 つの層に分割できます。ティアシステム。
iii. サービス指向アーキテクチャ (SOA) パターン
1. サービス指向アーキテクチャー
2 つの多層 C/S 構造アプリケーション システムが相互に通信する必要がある場合、サービス指向アーキテクチャが作成されます。 (サービス指向アーキテクチャ、SOA)
独立したアプリケーション システムとは、アプリケーション システムが何層のサービスで構成されているとしても、いずれかの層が削除されると、完全な機能を外部に提供する独立したアプリケーションになり得ることを意味します。
メッセージミドルウェア、トランザクションミドルウェアなどのSOA要件を実現するミドルウェアを使用します。
実際には、サービス指向アーキテクチャは、異種システム統合、同種システム集約、フェデレーテッド アーキテクチャなどに具体的に分類できます。
2. ウェブサービス
サービス指向アーキテクチャは Web アプリケーション間で反映され、Web サービスになります。つまり、2 つのインターネット アプリケーションがいくつかの内部「サービス」を相互に開くことができます (このようなサービスは、機能モジュール、機能、プロセスなどとして理解できます)。現在、Web アプリケーションが内部サービスを外部に公開するためのプロトコルには、主に SOAP と WSDL が含まれます。具体的な情報については、関連する標準を参照してください。
Web サービスは、サービス指向アーキテクチャの最も一般的で人気のあるアプリケーション パターンの 1 つです。
3. サービス指向アーキテクチャの本質
本質はメッセージ メカニズムまたはリモート プロシージャ コール (RPC) です。
iv. 組織データ交換バス
つまり、異なる組織アプリケーション間で情報を交換するための共通チャネルです。
この構造は、大規模な組織の異なるアプリケーション システム間の情報交換で一般的に使用されており、中国では主に高度な情報化とデジタル化が進んでいる組織で使用されています。
データバス自体については、その本質はコネクタ（Connector）と呼ばれるソフトウェアシステムであり、ミドルウェア（メッセージミドルウェアやトランザクションミドルウェアなど）をベースに構築することも、主にCORBA/IOPプロトコルをベースに開発することも可能です。この機能は、事前定義された構成またはメッセージ ヘッダー定義に従って、データ、要求、または応答を受信および配布することです。
組織レベルのデータ交換バスは、リアルタイム トランザクションと大量のデータ送信の機能を同時に持つことができますが、実際には、成熟したエンタープライズ データ交換バスは主にリアルタイム トランザクションと信頼性の要求向けに設計されています。大容量データの送信には個別の設計が必要になることがよくあります。 CORBA が通信プロトコルとして使用される場合、スイッチング バスは「エージェント システム」とも呼ばれるオブジェクト リクエスト ブローカー (ORB) になります。
V. 企画とデザイン
i. 統合されたアーキテクチャの進化
1. アプリケーション機能を基軸としたアーキテクチャ
中小企業や情報化・デジタル化の初期段階にある産業企業にとって、情報システム統合構築の主な目的は、業務効率の向上とビジネスリスクの軽減です。同時に、自社の情報化チームや人材の不足、およびビジネス システムにおける情報化とデジタル化に対する深い理解の欠如により、企業は情報システムを構築するために「借用原則」を採用することがよくあります。つまり、完成したアプリケーション ソフトウェアの完全なセットを直接購入し、アプリケーション ソフトウェアの動作要件に基づいて関連インフラストラクチャを構築します。
企業開発のこの段階では、組織機能の詳細な分割と業界のベスト プラクティスの導入に焦点が当てられます。したがって、組織の情報構築は、情報システムを実行するための財務管理、設備管理、資産管理などの情報システムのソフトウェア機能が中心となることが多くなります。企画、設計、展開、運用。同時に、ソフトウェアの完全なセットの展開を通じて、独自の管理またはプロセス レベルを強化できます。アプリケーション ソフトウェアまたはモジュール間の統合と融合は、主にシステムのソフトウェア インターフェイスを通じて完了します。企業は多くの場合、統合された計画と段階的な実装方法、つまり、どの機能が必要で、どの機能がオンラインで展開されるかを採用しています。
2. メインラインアーキテクチャとしてのプラットフォーム機能に基づく
プラットフォーム機能を主軸としたシステム統合アーキテクチャは、クラウド コンピューティング技術の発展とクラウド サービスの漸進的な成熟から生まれました。その中心的なコンセプトは、「サイロ型」情報システムの各コンポーネントを、フラット化されたデータ収集、フラット化されたネットワーク送信、フラット化されたアプリケーションミドルウェア、フラット化されたアプリケーション開発などを含む「フラット化された」構築方法に、標準化されたインターフェイスを通じて変換することです。新しい情報技術により、情報システムの弾力性と機敏性を構築できます。プラットフォームアーキテクチャによってサポートされる情報システムアプリケーションは、特別な構築または独立した構成（または小規模開発）と組み合わせることで、企業が必要とするアプリケーションシステムの機能を迅速に取得できるため、個別のソフトウェアカスタマイズにおける完全なソフトウェアベンダーの欠点を克服できます。
具体的には、企業のアーキテクチャの変革は継続的なプロセスです。企業は、成熟度が高く変更が少ないアプリケーションには完全なソフトウェア展開モデルを引き続き使用し、新しいアプリケーションや変化するアプリケーションにはプラットフォーム アーキテクチャを採用し、最終的には 2 つのアーキテクチャ (デュアルステート IT とも呼ばれます) の共存を維持します。 、敏感な状態と定常状態の統合）、またはすべてがプラットフォーム アーキテクチャに変換されます。
3. メインラインアーキテクチャとしてのインターネット
企業が産業チェーンやエコロジーチェーン段階に発展したり、複雑化・多様化したグループ企業になると、インターネットを基幹としたシステム統合アーキテクチャへの移行・移行を模索し始める。
インターネットを幹線とし、情報システムの各機能の最大限の応用（マイクロサービス）を重視したシステム統合アーキテクチャ
インターネットを幹線としたシステム統合アーキテクチャにより、より多くの新世代情報技術とその応用革新を統合・応用
4. さまざまなメインライン アーキテクチャの採用は、基本的に企業のビジネス開発の程度に依存し、企業のデジタル トランスフォーメーションの成熟度に反映されます。
ii. TOGAFアーキテクチャ開発手法
TOGAF (The Open Group Architecture Framework) は、標準、方法論、エンタープライズ アーキテクチャの専門家間のコミュニケーションの一貫性を保証するオープン エンタープライズ アーキテクチャ フレームワーク標準です。
TOGAFの基本
TOGAF は、国際組織 The Open Group によって開発されました。
この組織は、顧客の要求に応えて 1993 年にシステム アーキテクチャ標準の開発を開始し、1995 年に TOGAF アーキテクチャ フレームワークを公開しました。 TOGAF の基盤は、米国国防総省の情報管理のための技術アーキテクチャ (TAFIM) です。これは、ベスト プラクティスと再利用可能な既存のアーキテクチャ資産セットをサポートする反復プロセス モデルに基づいています。これを使用して、適切なエンタープライズ アーキテクチャを設計、評価、確立できます。 TOGAF は、エンタープライズ IT アーキテクチャを柔軟かつ効率的に構築できることが国際的に証明されています。
このフレームワークは、次の 4 つの目標を通じて、企業がすべての重要なビジネス ニーズを整理し、対処できるように設計されています。
1||| 主要な関係者からチームメンバーまで、すべてのユーザーが同じ言語を話すようにしてください。これにより、全員がフレームワーク、内容、目標を同じように理解できるようになり、ビジネス全体が同じ認識でコミュニケーションの障壁を打ち破ることができます。
2||| エンタープライズ アーキテクチャ向けの独自のソリューションに「ロック」されることを避けます。企業が営利目的ではなく社内で TOGAF を使用している限り、フレームワークは無料です。
3||| 時間とお金を節約し、リソースをより効率的に使用します。
4||| 大幅な投資収益率 (ROI) を達成します。
TOGAF は、企業の内部アーキテクチャ機能の構造と内容を反映しています。TOGAF9 バージョンには、次の 6 つのコンポーネントが含まれています。
1||| アーキテクチャ開発手法
この部分は TOGAF の核心であり、エンタープライズ アーキテクチャを開発するための段階的な手法である TOGAF アーキテクチャ開発メソッド (ADM) について説明します。
2||| ADM のガイドラインとテクノロジー
このセクションには、ADM を適用するために使用できる一連のガイドラインとテクニックが含まれています。
3||| アーキテクチャコンテンツフレームワーク
このセクションでは、アーキテクチャ成果物の構造化メタモデル、再利用可能なアーキテクチャ ビルディング ブロック (ABB) の使用、および典型的なアーキテクチャ成果物の概要を含む、TOGAF コンテンツ フレームワークについて説明します。
4||| エンタープライズ コンティニュアムとツール
このセクションでは、企業内のアーキテクチャ活動の出力を分類して保存するための分類法とツールについて説明します。
5||| TOGAF 参照モデル
このパートでは、TOGAF テクノロジー参照モデル (TRM) と統合情報インフラストラクチャ参照モデル (II-RM) という 2 つのアーキテクチャ参照モデルを提供します。
6||| アーキテクチャ機能フレームワーク
このセクションでは、企業内でアーキテクチャの実践を確立し、運用するために必要な組織、プロセス、スキル、役割、および責任について説明します。
TOGAF フレームワークの中心的な考え方は次のとおりです。
1||| モジュラーアーキテクチャ
TOGAF規格はモジュール構造を採用しています。
2||| コンテンツフレーム
TOGAF 標準には、アーキテクチャ開発手法 (ADM) に従って、より一貫した結果を生成するコンテンツ フレームワークが含まれています。 TOGAF コンテンツ フレームワークは、製品を設計するための詳細なモデルを提供します。
3||| 拡張ガイド
TOGAF 標準の拡張された概念と仕様のセットは、大規模組織の内部チームが包括的なアーキテクチャ ガバナンス モデル内で動作する多層統合アーキテクチャを開発するためのサポートを提供します。
4||| 建築様式
TOGAF 標準は柔軟に設計されており、さまざまなアーキテクチャ スタイルで使用できます。
5||| TOGAF の鍵となるのは、ビジネス ニーズの組織構造を満たすことができる信頼性が高く効果的な手法であるアーキテクチャ開発手法です。
ADM方式
アーキテクチャ開発メソッド (ADM) では、エンタープライズ アーキテクチャを開発するために必要なさまざまな手順と、それらの手順間の関係について説明します。 詳細な定義であり、TOGAF 仕様の中核となる内容でもあります。
ADM アプローチは、アーキテクチャ ドメイン内のアーキテクチャ開発の順序でリング状に配置された一連のフェーズで構成されます。
このモデルは、ADM の全ライフ サイクルを、準備フェーズ、需要管理、アーキテクチャ ビジョン、ビジネス アーキテクチャ、情報システム アーキテクチャ (アプリケーションとデータ)、技術アーキテクチャ、機会とソリューション、移行計画、実装ガバナンス、アーキテクチャ変更ガバナンスを含む 10 のフェーズに分割します。ステージ、これら 10 のステージは反復プロセスです。
ADM アプローチは、アーキテクチャ開発プロセス全体、フェーズ間、および各フェーズ内で繰り返し適用されます。 ADM のライフサイクル全体において、各段階では元のビジネス要件に基づいて設計結果を確認する必要があります。これには、ビジネス プロセスに固有の段階も含まれます。検証には、企業の対象範囲、期間、詳細レベル、計画、マイルストーンを再検討する必要があります。各フェーズでは、アーキテクチャ資産の再利用が可能である必要があります。
ADM は、次の 3 レベルの反復概念を形成しています。
1||| ADM 全体に基づいた反復
ADM アプローチを循環的に適用することは、1 つのアーキテクチャ開発フェーズの完了が次の次のフェーズに直接つながることを示しています。
2||| 複数の開発フェーズにわたる反復
技術アーキテクチャフェーズの開発作業が完了すると、ビジネスアーキテクチャ開発フェーズに戻りました。
3||| ステージ内の反復
TOGAF は、ステージ内の複数の開発アクティビティに基づいた複雑なアーキテクチャ コンテンツの反復開発をサポートします。
ADMの各開発段階における主な活動
VI. 価値主導のアーキテクチャ
i. モデル概要
システムの目的は、ステークホルダーに価値を生み出すことです。
価値モデルの中核となる特徴は次のとおりです。
（1） 期待値
期待価値は、内容 (機能)、満足度 (品質)、さまざまな品質レベルでの実用性など、特定の機能に対する需要を表します。
たとえば、車の運転手は、時速 60 キロメートルの速度での車の急ブレーキの速度と安全性に価値のある期待を持っています。
（2） 反力
実際のシステム導入環境では、期待値が高いほど困難、つまり反力も大きくなるのが一般的です。
たとえば、時速 60 キロメートルの速度で車が緊急ブレーキをかけた場合、結果は路面の種類、路面の勾配、車の重量によって異なります。
（3） 変化の触媒
変化触媒は、価値期待の変化を引き起こす、または異なる結果をもたらす制約となる環境内の何らかのイベントを表します。
変化に対抗する力やきっかけは制約と呼ばれ、これら 3 つを総称して価値推進要因と呼ばれます。システムが利害関係者の価値モデル要件を効果的に満たすように設計されている場合、価値モデルを特定して分析できる必要があります。
ユースケースのシナリオやビジネス/マーケティング要件などの一般的なアプローチは、システムと対話するアクターの種類に焦点を当てることから始まります。このアプローチには 4 つの顕著な制限があります。
（1） 参加者の中にある目標ではなく、参加者の行動モデルにもっと注意を払います。
（2） 多くの場合、参加者はいくつかの役割に厳密に分割されますが、各役割の個人は基本的に同じです (ビジネスマン、投資マネージャー、システム管理者など)。
（3） 制限要因の違いは無視されることがよくあります（たとえば、ニューヨークの証券トレーダーがロンドンの証券トレーダーと同じかどうか、市場が取引可能かどうか、日次取引が可能かどうかなど）。
（4） 結果は簡単です。要件が満たされているか満たされていないか、ユースケースが正常に完了したかどうか。
このアプローチには非常に論理的な実際的な理由があり、逐次推論とカテゴリー論理を使用するため、教えたり説明したりするのが簡単で、検証しやすい一連の結果が生成されます。
ii. 構造的な課題
アーキテクチャ上の課題は、1 つ以上の制約によって 1 つ以上の期待を満たすことが困難になるために発生します。
どのような環境においても、アーキテクチャ上の課題を特定するには評価が必要です。
（1） どの制約が 1 つ以上の望ましい値に影響を与えるか。
（2） 影響がわかっている場合、期待に応えることが容易になるか (プラスの影響)、それとも困難になるか (マイナスの影響) ますか。
（3） さまざまな影響がどの程度深刻であるか。この場合、通常は単純な低、中、高のレベルで十分です。
評価では、アーキテクチャ自体の課題を考慮してアーキテクチャを考慮する必要があります。コンテキスト全体で効用曲線を平均化することは可能ですが、期待値に対する制約の影響に同じ処理を適用することはできません。たとえば、Web サーバーが 2 つの状況でページを提供するとします。1 つは、1 ～ 3 秒の応答時間を必要とする静的情報へのアクセスであり、もう 1 つは、進行中のスポーツ イベントに関する情報などの動的情報へのアクセスです。個人スコアシートの応答時間は 3 ～ 6 秒です。
どちらの場合も、CPU、メモリ、ディスク、ネットワークの制限があります。ただし、リクエスト量が 10 倍または 100 倍に増加すると、これら 2 つのシナリオは非常に異なるスケーラビリティの障壁に遭遇する可能性があります。動的コンテンツの場合、高負荷時には更新とアクセスの同期が制限要因になります。静的コンテンツの場合、読み取りページを頻繁にキャッシュすることで重い負荷を克服できます。
システムのアーキテクチャ戦略の開発は、次のことから始まります。
（1） 適切な価値コンテキストを特定し、優先順位を付けます。
（2） 各コンテキストでユーティリティ曲線と優先順位付けされた期待値を定義します。
（3） それぞれの状況における変化に対する対抗力と触媒を特定し、分析します。
（4） 制約により期待に応えることが困難な領域を検出します。
初期のアーキテクチャ上の決定が最大の価値を生み出すのは当然のことです。アーキテクチャの優先順位付けにはいくつかの基準があり、重要性、程度、結果、分離性などのトレードオフを示唆しています。
（1） 重要性
課題によって影響を受ける期待にはどの程度優先順位が付けられていますか。また、それらの期待が少数のコンテキストに固有のものである場合、それらのコンテキストの相対的な優先順位は何ですか。
（2） 程度
制約が期待値にどの程度の影響を与えるか。
（3） の結果として
利用可能なオプションのおおよその数と、それらの難易度や有効性が大幅に異なるかどうか。
（4） 分離
最も現実的なシナリオの分離についてはどうでしょうか。
アーキテクチャ戦略のガイドライン
（1） 整理する
サブシステムとコンポーネントはどのように組織化されていますか? その構成と責任は何ですか? システムはどのような種類のユーザーと外部システムに配置され、どのように接続されていますか?
（2） 操作する
コンポーネントはどのように相互作用しますか? どのような場合に通信が同期されますか? コンポーネントのさまざまな操作はどのように調整されますか? コンポーネントのエラーはどのように検出、診断、修正されますか?
（3） 変動性
デプロイメント環境の変化に応じて、システムのどの重要な機能が変更される可能性がありますか? 各機能について、どのオプションがいつサポートされますか? (コンパイル、リンク、インストール、起動時など) さまざまな点は何ですか?それらの間にはどのような相関関係があるのでしょうか?
（4） 進化
安定性を維持しながら変化をサポートするシステムはどのように設計されていますか? 具体的にどのような種類の大きな変化が予想されますか? これらの変化に対処する望ましい方法は何ですか?
建築戦略は帆船の舵と竜骨のようなもので、方向と安定性を決定します。これは、すべての利害関係者が理解できる、短く高水準の方向性を示すものである必要があり、システムの存続期間を通じて比較的安定したものである必要があります。
iii. モデルと構造の関係
価値モデルとソフトウェア アーキテクチャとの関係は明確かつ論理的であり、次の 9 つの点で表現できます。
（1） ソフトウェア集約型の製品およびシステムは、価値を提供するために存在します。
（2） 価値は、限界効用の理解と、さまざまな目標の相対的な重要性を組み合わせたスカラー量です。これは非常に重要な問題です。
（3） 値は複数のレベルで存在し、その一部には値プロバイダーとしてターゲット システムが含まれます。これらの分野で使用される価値モデルには、ソフトウェア アーキテクチャの主要な推進力が含まれています。
（4） 階層内の上位レベルの価値モデルは、その下位の価値モデルに変更を引き起こす可能性があります。これは、システム進化の原則を定式化するための重要な基礎です。
（5） 各価値グループについて、価値モデルは同種です。異なる環境条件にさらされた価値コンテキストは、異なる期待値を持ちます。
（6） システム開発スポンサーは、さまざまな価値観のニーズを満たすためにさまざまな優先順位を持っています。
（7） アーキテクチャ上の課題は、コンテキスト内の期待に対する環境要因の影響から発生します。
（8） アーキテクチャ アプローチでは、最も優先度の高いアーキテクチャ上の課題を最初に克服することで、価値を最大化しようとします。
（9） アーキテクチャ戦略は、共通のルール、ポリシー、組織原則、運用、変更、進化を要約することにより、最優先のアーキテクチャ アプローチから合成されます。
三、 アプリケーションアーキテクチャ
I. まとめ
アプリケーション アーキテクチャの主な内容は、ターゲット アプリケーションの階層ドメイン アーキテクチャを計画し、ビジネス アーキテクチャに従ってターゲット アプリケーション ドメイン、アプリケーション グループ、およびターゲット アプリケーション コンポーネントを計画し、ターゲット アプリケーション アーキテクチャの論理ビューとシステム ビューを形成することです。
機能的な観点から、各アプリケーション コンポーネントとアプリケーション アーキテクチャ全体が組織の高度な IT ニーズをどのように達成できるかを説明し、主要なターゲット アプリケーション コンポーネント間の相互作用について説明します。
II. 基本原則
1. ビジネス適応原則
アプリケーション アーキテクチャは、ビジネス機能を提供および強化し、組織のビジネスまたはテクノロジ開発の戦略的目標をサポートできる必要があります。同時に、アプリケーション アーキテクチャは、将来のビジネス アーキテクチャによってもたらされる変化に適応するために、ある程度の柔軟性と拡張性を備えている必要があります。発達。
2. 集計原則を適用する
既存のシステム機能をベースに、部門レベルのアプリケーションを統合することで、アプリケーションシステムの複数化、機能の分散、重複、境界の不明確さなどの課題を解決し、組織的に一元化された「組織レベル」のアプリケーションシステムの構築を推進します。
3. 機能特化の原則
業務機能の集約に応じてアプリケーションを計画し、アプリケーションコンポーネントに対応したアプリケーションシステムを構築します。 さまざまなビジネスラインのニーズを満たし、専門能力の開発を達成するためのシステム。
4. リスク最小化の原則
システム間の結合を減らし、単一アプリケーション システムの独立性を向上させ、アプリケーション システム間の相互依存を減らし、システム レベルとシステム グループ間の疎結合を維持し、単一点リスクを回避し、システム運用リスクを軽減し、アプリケーション システムの信頼性を確保します。安全で安定しています。
5. 資産再利用の原則
迅速な開発と開発および保守コストの削減の要件を満たすために、建築資産の改良と再利用を奨励および促進します。組織レベルの共有アプリケーションを基本サービスとして計画し、標準化されたシステムを確立し、組織内で再利用および共有します。同時に、サービスを再利用したり、サービスを組み合わせたりすることで、このアーキテクチャは、さまざまな事業分野の差別化されたビジネス ニーズを満たし、組織のビジネスの持続可能な発展をサポートするのに十分な柔軟性を備えています。
III. 階層的なグループ化
アプリケーション アーキテクチャを階層化する目的は、ビジネスとテクノロジーの分離を実現し、各層間の結合を軽減し、各層の柔軟性を向上させ、障害の分離を容易にし、アーキテクチャの疎結合を実現することです。
アプリケーション階層化は、顧客中心のシステム サービスと対話パターンを反映し、顧客サービス指向のアプリケーション アーキテクチャ ビューを提供します。
アプリケーションをグループ化する目的は、ビジネス機能の分類と集約を反映し、密接に関連するアプリケーションまたは機能を 1 つのグループにまとめることです。これにより、アプリケーション システムの構築をガイドし、システム内の高い凝集性、システム間の結合度の低さを実現できます。重複した構築を削減します。
都市の社会保険スマート管理センターのアプリケーション アーキテクチャの概略図
企画は4つのカテゴリーに分かれています
（1） ガバナンスチャネル
1||| モバイルアプリ
主に、あらゆるレベルの管理者に、さまざまな重要なトピック、人気のあるトピック、ビジネストピック、ビッグデータトピック、重要な指標の監視、指標分析、パフォーマンス評価、傾向分析、コマンドとディスパッチ、およびさまざまなアプリケーションシナリオを実現するためのその他のアプリケーション機能の視覚的なビューを提供します。ガバナンスセンターの社会保障開発データ、ビジネス環境指標および関連レポートの同時レビュー。
2||| デスクトップアプリ
ある都市のさまざまな事業分野の管理者および社会保険情報部門を対象に、社会保険分野の総合トピック、各事業分野のビジネストピック、ビッグデータトピック、視覚的監督、インテリジェント監督、科学的テーマに関する人文サービスを提供します。指揮と派遣、会議での協議、タスクの分散、調査と調整の支援、特別な是正など、さまざまなアプリケーション シナリオでスマート ガバナンスを実現できます。
3||| 大画面アプリケーション
都市のあらゆるレベルの社会保険担当者や部門責任者を対象に、さまざまな重要トピック、話題のトピック、ビジネストピック、ビッグデータトピックに関する重要な指標の監視、意思決定分析、パフォーマンス評価、傾向分析などを視覚的にプレゼンテーションします。
（2） ガバナンスセンター制度
インタラクティブなテーマの 3 つの主要カテゴリの表示に主に焦点を当てます。
1||| ビジネストピック
雇用と起業、社会保険、労働者の権利保護、人事管理、人材サービス、人事および専門試験、行政承認、電話相談サービス、社会保障カードなどが含まれます。
2||| 包括的なトピック
マクロ意思決定、指揮と派遣、誠実性とリスク管理、資金管理、キャリア開発、ビジネス環境、貧困緩和追跡、サービス監視、世論監視、ビジネススタイル監督、業績評価、イベント管理、電子ライセンス、規格管理を含む、人々と農民に利益をもたらすのを待ちます。
3||| ビッグデータのテーマ
社会保障のポートフォリオ、社会保障ポートフォリオ、社会保障信用スコア、社会保障マップ、社会保障アトラス、社会保障基金数理、社会保障指数評価、社会保障パノラマ分析などが含まれます。
（3） ガバナンス支援体制
本プロジェクトのスマートガバナンスセンター向けに大きく4種類のアプリケーションを提供
1||| データサポートアプリケーション
データ集約システム、データガバナンスシステム、データアプリケーションシステムを含みます。
2||| 連携サービスアプリケーション
指揮・配車管理システム、精密貧困緩和管理システム、労働者の権利保護早期警戒管理システム、電子ライセンスシステム、ユーザー肖像システムなど。
3||| ガバナンスおよび監督アプリケーション
基準管理システム、業態監視システム、与信管理システム、資金数理分析システム、サービス効率評価システムなど。
4||| インタラクティブなアプリケーションを表示する
モバイル ガバナンス アプリが含まれています。
（4） 関連するシステムの変更
これには主に、関連するトピックのデータ収集、表示、対話に関連する労働雇用システム、社会保険システム、労働関係システム、人事および人材システム、公務員システム、リスク予防および管理システムなどの変革が含まれます。このスマートガバナンスセンターに。
四、 データアーキテクチャ
I. まとめ
データ アーキテクチャは、組織の論理的および物理的なデータ資産および関連するデータ管理リソースの構造を記述します。
データ アーキテクチャの主な内容には、データの生成、流通、統合、適用、アーカイブ、消滅を含むデータのライフ サイクル全体におけるアーキテクチャ計画が含まれます。
データ アーキテクチャは、データのライフ サイクルにおいて操作されるデータの特性に焦点を当てており、データの種類、データ量、データ技術処理の開発、データの管理と制御戦略などのデータ分野の概念に関連しています。
II. 発展と進化
1. モノリシックアプリケーションアーキテクチャの時代
情報化の初期段階 (1980 年代)、情報化が最初に構築されていたとき、情報システムは主に単一のアプリケーションでした。たとえば、次のとおりです。 現在の財務ソフト、OAオフィスソフトなどこの時期、データ管理の概念はまだ初期段階にあり、データ アーキテクチャは主にデータ モデルとデータベース設計で構成されており、システムのビジネス ニーズを満たすのに十分でした。
2. データウェアハウスの時代
情報システムを利用すると、システムデータが徐々に蓄積されていきます。この時点で、人々はデータが組織にとって貴重であることに気づきましたが、断片化したシステムにより多数の情報の島が作成され、組織のデータの使用に深刻な影響を及ぼしました。その結果、データ分析のための新しい主題指向の統合アーキテクチャ、つまりデータ ウェアハウスが誕生しました。
従来のリレーショナル データベースとは異なり、データ ウェアハウス システムの主なアプリケーションは OLAP です。OLAP は、複雑な分析操作をサポートし、意思決定のサポートに重点を置き、直観的でわかりやすいクエリ結果を提供します。この段階では、データ アーキテクチャはデータ モデルだけでなく、データの分散とフローにも焦点を当てます。
3. ビッグデータ時代
ビッグデータ テクノロジーの台頭により、組織は独自のデータをより柔軟かつ効率的に使用し、データからより重要な価値を抽出できるようになります。同時に、ビッグ データ アプリケーションのニーズに後押しされて、バッチ処理からストリーム処理へ、集中型から分散型へ、バッチとストリームの統合から完全なリアルタイムに至るまで、さまざまなビッグ データ アーキテクチャも絶えず開発および進化しています。
III. 基本原則
データ アーキテクチャの設計原則は、アーキテクチャ設計の一般原則に従い、データ アーキテクチャ自体について特別な考慮事項を持つことです。
合理的なデータ アーキテクチャ設計では、機能の配置の合理性、将来の開発のための拡張性、効率的な処理またはコスト効率、合理的なデータ分散とデータの一貫性といった問題を解決する必要があります。
基本原則には以下が含まれます：
1. データ階層化の原則
2. データ処理効率の原則
3. データの一貫性の原則
4. データ アーキテクチャのスケーラビリティの原則
（1） 階層的位置付けの合理性原理に基づいています。
（2） アーキテクチャのスケーラビリティには、データ ストレージ モデルとデータ ストレージ テクノロジを考慮する必要があります。
5. ビジネス原則の実現
IV. アーキテクチャの例
都市の社会保険スマート管理センターのデータ アーキテクチャの概略図。
主なデータ リポジトリには次のものがあります。
（1） ソースデータベース
ソース データベースは、都市の社会保険スマート ガバナンス センターに必要なデータのソースです。
（2） 交換ライブラリ
OGG などの同期ツールを使用するか、データ同期やサービス呼び出しなどでソース データベースを同期します。 Exchange データベースにステップインし、データ同期またはミラーリングを使用して、ソース データベースへの影響を軽減します。
（3） 遷移ライブラリ
交換ライブラリ内のデータは、OGG For Bigdata を通じて変数データの抽出、Sqoop 抽出、プッシュ、インポートなどを介して抽出され、Hadoop プラットフォームの移行ライブラリに保存され、大規模なバッチ データ処理のパフォーマンスが向上します。
（4） 統合ライブラリ
移行データベース内のデータを比較、変換、クリーンアップ、集計し、統合されたデータベース テーブル構造に保存します。 統合データベースでは、対象データベースごとに増分データ ソースと完全データ ソースが提供されます。
（5） テーマライブラリ
つまり、サービス ライブラリは、ガバナンス テーマのアプリケーション要件に従って統合ライブラリから必要なデータを抽出し、ガバナンスを提供します。 理論的な応用と視覚的なプレゼンテーションのサポートを提供します。
五、 テクノロジーアーキテクチャ
I. まとめ
技術アーキテクチャは、組織のアプリケーション アーキテクチャとデータ アーキテクチャを実行するための基礎であり、組織のビジネス アプリケーションを実装するために使用される技術システムまたはその組み合わせ、およびサポートに必要なインフラストラクチャと環境を記述します。アプリケーション システムの展開を待ちます。
技術アーキテクチャには全体的な検討と統一された計画が必要です。IT 技術アーキテクチャに全体的な戦略やアイデアが欠けていると、最も弱い部分によって全体の機能が損なわれ、IT がビジネス開発のボトルネックになってしまいます。
II. 基本原則
1. 成熟度管理の原則
2. 技術的一貫性の原則
3. 現地交換可能性の原則
4. 人材スキル適用原則
5. イノベーション主導の原則
III. アーキテクチャの例
都市の社会保険スマート管理センターの技術アーキテクチャの概略図。
このプロジェクトは、今日の高度で成熟した技術アーキテクチャとルートを採用し、都市の社会保険スマート ガバナンス センターの進歩、効率、信頼性、拡張性を確保します。
技術アーキテクチャは、次のような分類と階層化のアプローチに従って設計されています。
（1） 技術基準
J2EE、HTML5、CSS3、SQL、シェル、XML/JSON、HTTP、FTP、SM2、SM3、JavaScript などの国際標準および国内標準に従います。
（2） 基本的なサポート
1||| このプロジェクトに基本的なネットワーク サポートを提供するために 5G ネットワークとモノのインターネットに依存します。
2||| このプロジェクトのアプリケーション展開サポートを提供するためにアプリケーション ミドルウェアを利用します。
3||| 分散キャッシュ、メモリ データベース、MPP データベース、トランザクション データベースを利用して、このプロジェクトに基本的なデータ ストレージ サポートを提供します。
4||| このプロジェクトに分散ストレージとコンピューティング環境のサポートを提供するために Hadoop プラットフォームに依存します。
5||| 検索エンジンおよびルール エンジン コンポーネントを利用して、ガバナンス アプリケーションの技術コンポーネント サポートを提供します。
（3） アプリケーションフレームワーク技術
アプリケーションシステム開発においては、厳密に遵守して採用する必要がある技術です。
アプリケーション フレームワークは、アクセス層、対話制御層、ビジネス コンポーネント層、リソース アクセス層を含む階層設計を採用しています。
（4） アプリケーション統合技術
シングル サインオン、サービス バス (ESB)、プロセス エンジン、メッセージ キュー、およびさまざまなアプリケーション システム間の統合をサポートするその他のテクノロジが含まれます。
（5） データ統合技術
ETL ツール、データ同期レプリケーション ツール、データ インデックス作成、SQL/ストアド プロシージャ、MapReduce/Spark コンピューティング エンジン、その他のテクノロジを含み、都市の社会保険にデータ収集、データ クリーニング、データ変換、データ処理、データ マイニングなどを提供します。スマート ガバナンス センター。業務の技術サポートを提供します。
（6） データ分析技術
BI エンジン、レポート エンジン、GIS エンジン、チャート コンポーネント、3D エンジン、多次元モデリング エンジン、AI アルゴリズム パッケージ、データ マイニング アルゴリズム パッケージおよびその他のビッグ データ テクノロジを含み、社会保障マップ、リモート コマンドおよびディスパッチ、パノラマ分析、マクロを提供します。意思決定、監視、監督 他のアプリケーションの視覚化のための技術サポートを提供します。
（7） 運用・保守技術
操作追跡、障害警告、エネルギー効率監視、ログ収集、脆弱性スキャン、アプリケーションを含む 監視、ネットワーク分析、その他のテクノロジーを使用して、アプリケーション システムの標準化された運用と保守をサポートします。
六、 ネットワークアーキテクチャ
I. ネットワークは情報技術アーキテクチャの基礎であり、ユーザーが IT 情報リソース サービスを要求および取得するためのチャネルであるだけでなく、情報システム アーキテクチャ内のさまざまなリソースを統合およびスケジュールするためのハブでもあります。
II. 基本原則
1. 高信頼性
基盤となるリソースのスケジューリングとサービス伝送のためのハブおよびチャネルとして、ネットワークには高い信頼性に対する当然の要件があります。 それは言うまでもない。
2. 高いセキュリティ
情報システムのセキュリティは、アプリケーション レベルのセキュリティ保証に依存するだけではなく、基礎となる ID 認証、アクセス制御、侵入検出機能などによっても重要なセキュリティが保証される必要があります。アプリケーション用。
3. ハイパフォーマンス
ネットワークはサービス配信のチャネルであるだけでなく、サービスを提供するために必要なリソース スケジューリングのハブでもあります。したがって、ネットワークのパフォーマンスと効率は、より良いサービス品質を提供するための保証となります。
4. 管理性
これは、ネットワーク自体の管理を指すだけでなく、ビジネス展開戦略に基づいてネットワークを迅速に調整および制御することも指します。
5. プラットフォームとアーキテクチャ
ネットワークには、基礎となる基本リソースとして、将来のアプリケーション アーキテクチャに適応するための幅広いビジョンが必要です。 変化に応じて、ネットワーク自体もより柔軟になり、将来のさまざまなビジネス規模の変化や発展に適応するために、需要に応じて拡張できます。
III. LANアーキテクチャ
LAN は、コンピュータ ローカル エリア ネットワーク、つまり単一の組織が所有する専用のコンピュータ ネットワークを指します。
特徴は次のとおりです。
① 地理的範囲は狭く、通常は建物または集中した建物群などの比較的独立した範囲に限定されます（通常は 2.5km 以内）。
②高いデータ伝送速度（通常は 10Mb/s 以上、通常は 1Gb/s、さらには 10Gb/s）。
③ビットエラー率が低く（通常10°未満）、信頼性が高い。
④複数の伝送メディアをサポートし、リアルタイムアプリケーションをサポートします。ネットワーク トポロジには、バス、リング、スター、ツリーなどのタイプがあります。
伝送媒体としては、有線LANと無線LANが挙げられます。
ローカル エリア ネットワークは通常、コンピュータ、スイッチ、ルーター、その他の機器で構成されます。
LAN は、レイヤー 2 スイッチング機能を提供するだけでなく、レイヤー 3 ルーティング機能を備えた複雑なネットワークも提供します。
アーキテクチャの種類
1. シングルコアアーキテクチャ
シングルコア LAN は通常、ネットワークのコア デバイスとしてコア レイヤ 2 またはレイヤ 3 スイッチング デバイスで構成され、ユーザー デバイス (ユーザー コンピュータ、スマート デバイスなど) は複数のアクセス スイッチング デバイスを介してネットワークに接続されます。 。
このタイプの LAN は、コア ネットワーク スイッチング装置と WAN を接続する相互接続ルーティング装置 (ボーダー ルータまたはファイアウォール) を介して WAN に接続し、サービスの LAN 間アクセスを実現します。
シングルコアネットワークには次の特徴があります。
1||| コア スイッチング機器は通常、レイヤ 2、レイヤ 3 以上のスイッチを使用します。レイヤ 3 以上のスイッチを使用する場合は、VLAN 内でレイヤ 2 データ リンク転送が使用され、VLAN 間の転送にはレイヤ 3 ルーティングが使用されます。 VLAN。
2||| アクセス スイッチング デバイスは、レイヤ 2 データ リンク転送のみを実装するレイヤ 2 スイッチを使用します。
3||| コアスイッチング装置とアクセス装置間では、100M/GE/10GE (1GE=1Gb/s) などのイーサネット接続を使用できます。
シングルコアでネットワークを構築するメリットは、ネットワーク構成がシンプルで設備投資を節約できることです。 LAN を使用してアクセスする必要があるサブ組織は、アクセス スイッチング デバイスを介してコア スイッチング デバイスのアイドル インターフェイスに直接接続できるため、より便利です。欠点は、ネットワークの地理的範囲が限られており、LAN の使用を必要とするサブ組織が比較的コンパクトであることです。コア ネットワークのスイッチング機器には単一障害点があり、全体的または部分的な障害が発生しやすいです。ネットワークの拡張能力が制限されている LAN に接続されているスイッチング デバイスが多い この場合、コア スイッチング装置のポート密度が高い必要があります。
あるいは、小規模ネットワークの場合、このネットワーク アーキテクチャを使用するユーザー機器をコア スイッチング機器と直接相互接続することもでき、投資コストをさらに削減できます。
2. デュアルコアアーキテクチャ
デュアルコア アーキテクチャとは、通常、3 層以上のスイッチを使用するコア スイッチング装置を指します。
100M/GE/10GE などのイーサネット接続は、コア スイッチング装置とアクセス装置間で使用できます。ネットワーク内で VLAN を分割する場合、各 VLAN 間のアクセスは 2 つのコア スイッチング装置を介して完了する必要があります。ネットワーク内のコアスイッチ装置のみがルーティング機能を持ち、アクセス装置はレイヤ 2 転送機能のみを提供します。
コア スイッチング デバイスは相互接続され、ゲートウェイ保護または負荷分散を実現します。コア スイッチング装置には保護機能があり、ネットワーク トポロジは信頼性があります。ホット スイッチングは、サービス ルーティングおよび転送に実装できます。ネットワークに接続された各部門のLAN間の相互アクセスや、基幹業務サーバへのアクセスなどにおいて、より信頼性の高い複数の経路を選択できます。
LAN を使用してアクセスする必要がある特殊な組織では、アクセス スイッチング デバイスを介してコア スイッチング デバイスのアイドル インターフェイスに直接接続できるため、より便利です。シングルコアLANに比べて設備投資が高くつきます。コア スイッチング装置のポート密度要件は比較的高いです。すべてのビジネス サーバーは 2 つのコア スイッチング デバイスに同時に接続され、ゲートウェイ保護プロトコルによって保護され、ユーザー機器への高速アクセスを提供します。
3. リングアーキテクチャ
リング LAN は、ネットワークのコアを構築するために、デュアル RPR (Resilient Packet Ring) 動的弾性パケット リングに接続された複数のコア スイッチング デバイスで構成されます。
コアスイッチング装置は通常、3 層以上のスイッチを使用してビジネス転送機能を提供します。
一般的なリングLANネットワークの各VLANは、RPRリングを介して相互アクセスを実現します。 RPR には、光ファイバ リソースを節約するための自己修復保護機能があり、MAC 層で 50 ミリ秒の自己修復時間の機能があり、マルチレベルで信頼性の高い QoS サービス、帯域幅公平性メカニズム、および輻輳制御メカニズムを提供します。 RPR リングは両方向で使用できます。ネットワークは 2 本の逆方向光ファイバーを介してリング トポロジを形成し、リング上のノードは 2 方向から別のノードに到達できます。各ファイバーはデータと制御信号を同時に送信できます。 RPR は空間再利用テクノロジーを使用して、リング上の帯域幅を効果的に利用します。
RPR を介して大規模な LAN を構築する場合、複数のリングはサービス インターフェイスを介してのみ相互に通信でき、直接のネットワーク通信を実現できません。リング LAN 機器への投資は、シングルコア LAN よりも高額です。コア配線の冗長設計は実装が難しく、簡単にループが形成される可能性があります。このネットワークは、リング上のスイッチング デバイスを相互接続するボーダー ルーティング デバイスを介して WAN にアクセスします。
4. 階層型LANアーキテクチャ
階層型 LAN (またはマルチレイヤ LAN) は、コア層スイッチング装置、アグリゲーション層スイッチング装置、アクセス層スイッチング装置、および ユーザー機器およびその他のコンポーネント
階層型 LAN モデルのコア層装置は高速データ転送機能を提供し、アグリゲーション層装置が提供する十分なインターフェースによりアクセス層との相互アクセス制御を実現し、アグリゲーション層はその管轄下に異なるアクセスデバイスを提供できます。サービススイッチング機能は、コアスイッチング装置の転送圧力を軽減し、アクセス層装置はユーザ装置へのアクセスを実現します。階層型 LAN ネットワーク トポロジは拡張が容易です。ネットワーク障害を分類してトラブルシューティングできるため、メンテナンスが容易になります。通常、階層型 LAN は WAN との境界ルーティング デバイスを介して WAN に接続され、LAN サービスと WAN サービスの相互アクセスを実現します。
IV. WAN アーキテクチャ
ワイド エリア ネットワークは、ローカル エリア ネットワークよりも広いエリアに分散されたコンピュータ装置を接続するネットワークです。
WAN は、通信サブネットとリソース サブネットで構成されます。通信サブネットは、公衆パケット交換網、衛星通信網、無線パケット交換網を利用して構築し、異なるエリアに分散したローカルエリアネットワークやコンピュータシステムを相互接続し、リソースサブネットの共有を実現します。
WAN はマルチレベルのネットワークであり、通常はバックボーン ネットワーク、ディストリビューション ネットワーク、アクセス ネットワークで構成されます。ネットワーク規模が小さい場合は、バックボーンネットワークとアクセスネットワークのみで構成できます。 WANを計画する際には、ビジネスシナリオとネットワーク規模に基づいて第3レベルのネットワーク機能を選択する必要があります。たとえば、地方銀行の広域ネットワークを計画し、データ、音声、画像、その他の情報共有をサポートするバックボーン ネットワークを設計し、銀行システム全体に高速で信頼性の高い通信サービスを提供します。データセンターと支店および支社間で長距離回線の再利用とバックボーン アクセスを提供し、支店と営業所間でデータを交換する際のアクセス ルーティングを提供して、コンセント回線の再利用と端末アクセスを実現するようにアクセス ネットワークを設計します。
アーキテクチャの種類
1. シングルコア広域ネットワーク
図 4-13 に示すように、シングルコア WAN は通常、コア ルーティング デバイスと各 LAN で構成されます。コアルーティング機器はレイヤー3以上のスイッチを使用します。ネットワーク内の LAN 間のアクセスには、コア ルーティング装置が必要です。
ネットワーク内の LAN 間には、他のルーティング デバイスはありません。各ローカル エリア ネットワークとコア ルーティング装置の間ではブロードキャスト回線が使用されます。 ルーティング機器と各 LAN 間の相互接続インターフェイスは、対応する LAN サブネットに属します。コアルーティング機器と各ローカルエリアネットワークは、10M/100M/GE イーサネットインターフェイスを使用して接続できます。このタイプのネットワークは構造が簡単で、設備投資を節約できます。各 LAN はコア LAN にアクセスし、また相互に高効率でアクセスします。基幹ルーティング機器にポートがあれば、新しい部門 LAN を WAN に接続する方が便利です。ただし、コアルーティング機器の単一障害点がネットワーク全体の障害に簡単につながるリスクがあります。ネットワーク拡張能力は低く、コアルーティング機器のポート密度は高い必要があります。
2. デュアルコアWAN
図 4-14 に示すように、デュアルコア WAN は通常、2 つのコア ルーティング デバイスと各 LAN で構成されます。
デュアルコア WAN モデルの主な特徴は、コアのルーティング機器が通常 3 層以上のスイッチを使用することです。コアルーティング機器は通常、10M/100M/GE などのイーサネット インターフェイスを介して各ローカル エリア ネットワークに接続されます。ネットワーク内の LAN 間のアクセスには 2 つのコア ルーティング デバイスが必要です。ビジネス アクセス用の LAN 間には他のルーティング デバイスはありません。コアルーティングデバイス間のゲートウェイ保護または負荷分散を実装します。各 LAN には、コア LAN にアクセスするため、および相互にアクセスするための複数のパス オプションがあり、ルーティング レベルで信頼性の高いホット スイッチングを実現し、ビジネス継続性アクセス機能を提供します。コア ルーティング機器インターフェイスが予約されている場合、新しい LAN に簡単にアクセスできます。ただし、設備投資はシングルコア WAN よりも高くなります。コアルーティング機器のルーティング冗長設計は実装が難しく、簡単にルーティング ループを形成してしまう可能性があります。ネットワークには、コア ルーティング機器に対してより高いポート密度の要件があります。
3. リングWAN
リング ワイド エリア ネットワークは通常、3 つ以上のコア ルータ デバイスを使用してルーティング ループを形成し、さまざまなローカル エリア ネットワークを接続し、WAN サービスの相互アクセスを実現します。
リング広域ネットワークの主な特徴は、コアのルーティング装置が通常 3 層以上のスイッチを使用することです。コアルーティング機器と各ローカルエリアネットワークは通常、10M/100M/GE などのイーサネットインターフェイスを介して接続されます。ネットワーク内の LAN 間のアクセスは、コア ルーティング デバイスによって形成されたリングを通過する必要があります。 LAN 間の相互アクセスのための他のルーティング デバイスはありません。コア ルーティング デバイスには、ゲートウェイ保護または負荷分散メカニズム、およびループ制御機能が装備されています。各 LAN には、コア LAN にアクセスするため、または相互にアクセスするために選択できる複数のパスがあり、ルーティング レベルでのシームレスなホット スイッチングを実現して、ビジネス アクセスの継続性を確保できます。
基幹ルーティング装置のインターフェースを予約しておくと、新しい部門内LANに簡単にアクセスできます。しかし、設備投資がデュアルコアWANに比べて高く、コアルーティング機器のルーティング冗長設計が難しく、ルーティングループが形成されやすい。リング トポロジはより多くのポートを占有する必要があり、ネットワークにはコア ルーティング機器に対してより高いポート密度の要件があります。
4. 準冗長WAN
半冗長 WAN は、図 4-16 に示すように、さまざまな LAN を接続する複数のコア ルーティング デバイスによって形成されます。その中で、コア ルーティング デバイスには、他のルーティング デバイスに接続された少なくとも 2 つ以上のリンクがあります。半冗長 WAN の特殊なケースは、2 つのコア ルーティング デバイス間にリンクがある場合、完全冗長 WAN になります。
半冗長WANの主な特徴は、柔軟な構造と容易な拡張です。一部のネットワーク コア ルーティング デバイスは、ゲートウェイ保護または負荷分散メカニズムを採用したり、ループ制御機能を備えたりすることができます。ネットワーク構造はメッシュ状となっており、各LANが基幹LANへのアクセスやLAN相互へのアクセス経路を複数確保しており、信頼性が高い。ルーティング レベルでのルーティングの選択がより柔軟になります。このネットワーク構造は、OSPF などのリンク ステート ルーティング プロトコルの導入に適しています。ただし、ネットワーク構造は断片化されており、管理やトラブルシューティングが困難です。
5. ピアツーピア サブドメイン WAN
ピアツーピア サブドメイン ネットワークは、WAN のルーティング機器を 2 つの独立したサブドメインに分割し、各サブドメインのルーティング機器は半冗長方式で相互接続されます。図 4-17 に示すように、2 つのサブドメインは 1 つ以上のリンクを通じて相互接続されており、ピア サブドメイン内のルーティング デバイスは LAN にアクセスできます。
ピアツーピア サブドメイン WAN の主な特徴は、ピアツーピア サブドメイン間の相互アクセスがピアツーピア サブドメイン間の相互接続リンクによって支配されることです。ルートの概要または詳細なルート エントリの照合はピア サブドメイン間で実現でき、ルート制御は柔軟です。一般に、サブドメイン間のリンクの帯域幅は、サブドメイン内のリンクの帯域幅よりも高くなければなりません。ドメイン間のルーティング冗長設計は実装が難しく、簡単にルーティング ループが形成されたり、不正なルートが公開される危険性があります。ドメイン境界ルーティング機器のルーティング パフォーマンス要件は比較的高いです。ネットワーク内のルーティング プロトコルは主にダイナミック ルーティングです。ピアツーピア サブドメインは、WAN が 2 つのエリアに明確に分割でき、エリア内のアクセスが比較的独立しているシナリオに適しています。
6. 階層型サブドメイン広域ネットワーク
階層型サブドメイン WAN 構造では、大規模な WAN ルーティング機器が複数の比較的独立したサブドメインに分割され、各サブドメインのルーティング機器は、複数の低レベル サブドメイン間に階層関係が存在します。レベルのサブドメイン。図 4-18 に示すように、階層サブドメイン内のルーティング デバイスはすべて LAN にアクセスできます。
階層型サブドメインの主な特徴は、階層型サブドメイン構造のスケーラビリティが優れていることです。下位サブドメイン間の相互アクセスは、上位サブドメインを介して完了する必要があります。ドメイン間のルーティングの冗長化設計は実装が難しく、ルーティングループが形成されやすく、不正な経路が公開される危険性があります。サブドメイン間のリンク帯域幅は、サブドメイン内のリンク帯域幅よりも高くなければなりません。ドメイン相互アクセスに使用されるドメイン ボーダー ルーティング デバイスのルーティングおよび転送パフォーマンス要件は比較的高いです。ルーティング デバイスのルーティング プロトコルは、主に OSPF プロトコルなどの動的ルーティングです。階層サブドメインと上位レベルの外部ネットワーク間の相互接続は主に高レベルのサブドメインの助けを借りて完了し、下位レベルの外部ネットワークとの相互接続は主に下位レベルのサブドメインの助けを借りて完了します。
V. 移動通信ネットワークのアーキテクチャ
モバイル通信ネットワークは、個人ユーザーや垂直産業などに多様なサービスを提供するモバイルインターネット、特に5Gネットワークを強力にサポートします。
一般的な 5G ビジネス アプリケーションには次のものがあります。
1. 5GS (5G システム) と DN (データ ネットワーク) の相互接続
5GS が移動端末ユーザー (ユーザー機器、UE) にサービスを提供する場合、通常、UE に必要なサービスを提供するには、インターネット、IMS (IP メディア サブシステム)、プライベート ネットワーク、その他の相互接続などの DN ネットワークが必要です。 5GS の UPF ネットワーク要素は、さまざまなインターネット、音声、AR/VR、産業用制御、ドライバーレス サービスの DN のアクセス ポイントとして機能します。図 4-19 に示すように、5GS と DN は、5GS によって定義された N6 インターフェイスを通じて相互接続されます。
5G ネットワークは 5G カテゴリに属し、AMF/SMF/PCF/NRF/NSSF などのいくつかのネットワーク機能エンティティが含まれます。わかりやすくするために、図ではユーザー セッションに密接に関連するネットワーク機能エンティティのみをマークしています。
5GS と DN が IPv4/IPv6 に基づいて相互接続されている場合、DN の観点からは、UPF は通常のルーターとみなすことができます。逆に、5GS の観点から見ると、N6 インターフェイスを介して UPF と相互接続されるデバイスは通常ルーターです。つまり、5GS と DN の間にはルーティング関係があります。 DN にアクセスする UE のサービス フローは、双方向ルーティング設定を通じてそれらの間で転送されます。 5G ネットワークに関する限り、UE から DN に流れるサービス フローはアップリンク (UL、UpLink) サービス フローと呼ばれ、DN から UE に流れるサービス フローはダウンリンク (DL、DownLink) サービス フローと呼ばれます。 UL サービス フローは、UPF に設定されたルートを介して DN に転送され、DL サービス フローは、UPF に隣接するルータに設定されたルートを介して UPF に転送されます。
さらに、UE が 5GS を通じて DN にアクセスする方法の観点からは、次の 2 つのモードがあります。
（1） トランスペアレントモード
トランスペアレント モードでは、5GS は UPF の N6 インターフェイスを介して事業者の特定の IP ネットワークに直接接続し、その後ファイアウォールまたはプロキシ サーバーを介してインターネットなどの DN (外部 IP ネットワーク) に接続します。 UEの割り当てはオペレータによって計画されます ネットワーク アドレス空間の IP アドレス。図 4-20 に示すように、UE が 5GS に対してセッション確立要求を開始する場合、通常、5GS は外部 DN-AAA サーバへの認証プロセスをトリガーしません。
このモードでは、5GS は少なくとも基本的な ISP サービスを UE に提供します。 5GS の場合は、基本的な機能のみを提供する必要があります。 トンネル QoS フロー サービスで十分です。 UE がイントラネット ネットワークにアクセスする場合、UE レベルの設定は UE とイントラネット ネットワーク間で独立してのみ完了し、5GS に対して透過的です。
（2） 非透過モード
非透過モードでは、5GS はイントラネット/ISP に直接アクセスすることも、他の IP ネットワーク (インターネットなど) 経由でアクセスすることもできます。 イントラネット/ISP。たとえば、5GS がインターネット経由でイントラネット/ISP にアクセスする場合、通常は、UE のアクセスをイントラネット/ISP サービスに転送するために、UPF とイントラネット/ISP の間に専用トンネルを確立する必要があります。 UE には、イントラネット/ISP アドレス空間に属する IP アドレスが割り当てられます。このアドレスは、図 4-21 に示すように、UPF およびイントラネット/ISP で UE サービスを転送するために使用されます。
要約すると、UE は 5GS を介してイントラネット/ISP サービス サーバーにアクセスします。これは、インターネットなどの任意のネットワークに基づいて実行できますが、データ通信の保護は特定のセキュリティ プロトコルに基づいて行うことができます。 UPF とイントラネット/ISP の間。使用されるセキュリティ プロトコルは、携帯電話会社とイントラネット/ISP プロバイダーの間でネゴシエートされます。
UE セッション確立の一部として、5GS の SMF は通常、外部 DN-AAA サーバー (Radius、Diameter サーバーなど) を開始することによって UE の認証を開始します。 UE が正常に認証されると、UE セッションの確立が完了し、UE はインターネット/ISP サービスにアクセスできるようになります。
2. 5Gネットワークエッジコンピューティング
5G ネットワークは、これまでのデバイス中心およびビジネス中心の方向性を変更し、ユーザー中心の概念を提唱します。 5G ネットワークはユーザーにサービスを提供する一方で、ユーザーのサービス エクスペリエンス QoE (Quality of Experience) にもより注意を払っています。その中でも、5G ネットワーク エッジ コンピューティング機能の提供は、垂直産業を強化し、ユーザーの QoE を向上させるための重要な手段の 1 つです。
5G ネットワークのモバイル エッジ コンピューティング (MEC) アーキテクチャを図 4-22 に示します。これは、エンド ユーザー UE に近いモバイル ネットワークのエッジでの 5G UPF ネットワーク要素の展開と、エッジの展開を組み合わせたものをサポートします。モバイル ネットワークのエッジにあるコンピューティング プラットフォーム (モバイル エッジ プラットフォーム、MEP) は、時間に敏感で高帯域幅を特徴とする近くのビジネス オフロード サービスを垂直産業に提供します。したがって、一方ではユーザーに優れたサービス エクスペリエンスを提供し、他方ではモバイル ネットワークのバックエンド処理への負担を軽減します。
通信事業者自身のアプリケーションまたはサードパーティ アプリケーションの AF (アプリケーション機能) は、5G ネットワークをトリガーして、5GS によって提供される機能オープン機能ネットワーク要素 NEF (ネットワーク エクスポージャー機能) を通じてエッジ アプリケーションのローカル オフロード ポリシーを動的に生成します。これは PCF (ポリシー課金機能) これらのポリシーを関連する SMF に設定します。SMF は UPF (つまり、モバイル エッジ クラウドに展開された UPF) を動的に実装し、エンドユーザーの位置情報または位置の変更に基づいてユーザー セッションに挿入または削除します。ユーザーが移動した後に発生する情報を収集し、これらの UPF をオフロードすることで、ユーザーが必要なサービスにアクセスできるようにするための優れた結果が得られます。
さらに、ビジネス継続性の観点から、5G ネットワークは SSC モード 1 (ユーザーの移動中にユーザー セッションの IP アクセス ポイントが変化しない)、SSC モード 2 (ユーザーの移動中にネットワークがユーザーの既存のセッションの解放をトリガーする) を提供できます。サービス プロバイダーの ASP (アプリケーション サービス プロバイダー) またはオペレーターが選択できるように、SSC モード 3 (ユーザーの移動中にユーザーの既存のセッションを解放する前に新しいセッションを確立します)。
VI. ソフトウェアデファインドネットワーク
本書の第 2 章のセクション 5、セクション 2.1.2 を参照してください。
七、 セキュリティアーキテクチャ
I. セキュリティの脅威
現在、組織はハイブリッド クラウドでホストするビジネスが増えており、ローカル インフラストラクチャと複数のパブリック クラウドとプライベート クラウドで構成される複雑な環境により、ユーザーはハイブリッド クラウドのセキュリティに対する高い要件を認識するようになりました。この普及と応用には次の 2 つの効果があります。
① あらゆる分野のビジネス運営は、ほぼ完全にコンピュータ、ネットワーク、クラウド ストレージに依存しています。政府文書、アーカイブ、銀行口座、企業のビジネス情報、個人情報などのさまざまな重要なデータはすべて、コンピュータとネットワークの保存と送信に依存しています。ネットワーク。
② 人々はコンピュータについてより包括的な理解を持ち、より多くのコンピュータ技術がより高いレベルの人々によって不法に使用され、情報資源を盗んだり攻撃したりするためにさまざまな手段が使用されています。
現時点で、情報システムが受ける可能性のある脅威は次のように要約できます。 以下の4つの側面に分けられます
1. 情報システムの場合、脅威は物理環境、通信リンク、ネットワーク システム、オペレーティング システム、アプリケーション システム、および管理システムを標的にする可能性があります。
2. 物理的なセキュリティの脅威とは、自然災害、停電、オペレーティング システムの起動障害やデータベース情報の損失、データ損失や情報漏洩を引き起こす装置の盗難/破壊など、システムで使用される機器に対する脅威を指します。
3. 通信リンクのセキュリティの脅威とは、伝送路に盗聴装置を設置したり、通信リンクを妨害したりすることを指します。
4. ネットワーク セキュリティの脅威とは、インターネットのオープン化と国際化により、人々が技術的手段を通じてインターネット情報を簡単に盗むことができ、ネットワークに深刻なセキュリティ上の脅威をもたらすという事実を指します。
5. オペレーティング システムのセキュリティの脅威とは、「トロイの木馬」、「トラップ ドア」、BIOS のユニバーサル パスワードなど、システム プラットフォームのソフトウェアまたはハードウェア チップに埋め込まれた脅威を指します。
6. アプリケーション システムのセキュリティの脅威とは、ネットワーク サービスやユーザーのビジネス システムのセキュリティに対する脅威を指し、「トロイの木馬」や「落とし戸」によっても脅かされます。
7. 管理システムのセキュリティ脅威とは、人為的なコピー、写真の撮影、転写などによるコンピュータ情報の窃取など、人事管理上の過失によって引き起こされる人為的なセキュリティの脆弱性を指します。
一般的なセキュリティ脅威には次のようなものがあります。
（1） 情報漏洩
情報が漏洩したり、権限のない組織に開示されたりした場合。
（2） 情報の完全性を破壊する
不正な追加、削除、変更または破壊によりデータが失われます。
（3） サービス拒否
情報やその他のリソースへの正当なアクセスは無条件にブロックされます。
（4） 不正アクセス（不正アクセス）
リソースが権限のない人物によって、または権限のない方法で使用されています。
（5） たたく
あらゆる合法的または違法な手段を使用して、システム内の情報リソースや機密情報を盗みます。たとえば、通信回線で伝送される信号を監視したり、通信機器の運用中に発生する電磁漏洩を利用して有用な情報を傍受したりするなどです。
（6） 業務フロー分析
システムを長期間監視し、通信頻度や通信状況などを統計解析手法を用いて分析 情報の流れや総通信量の変化を調査し、価値のある情報やパターンを発見します。
（7） 偽造
通信システム（またはユーザー）を騙すことで、不正なユーザーが正規のユーザーになりすましたり、権限の低いユーザーが高い権限のユーザーになりすまして目的を達成することを目的としています。ハッカーは主に、なりすましを使用して攻撃します。
（8） バイパス制御
攻撃者は、システムのセキュリティ上の欠陥や脆弱性を利用して、不正な権利や特権を取得します。たとえば、攻撃者はさまざまな攻撃方法を使用して、秘密にしておく必要があるが公開されているいくつかのシステム「機能」を発見します。これらの「機能」を使用すると、攻撃者は防御者を迂回し、システムに侵入することができます。
（9） ライセンス侵害
特定の目的でシステムまたはリソースを使用する権限を与えられた人が、この権限を他の不正な目的で使用することは、「インサイダー攻撃」とも呼ばれます。
（10） トロイの木馬
ソフトウェアには、実行されると破壊される、検出不可能または無害なプログラム セグメントが含まれています。 ユーザーのセキュリティ。この種のアプリケーションはトロイの木馬と呼ばれます。
（11） トラップドア
「シャーシ」は、特定の入力データが提供された場合にセキュリティ ポリシーの違反を許可するようにシステムまたはコンポーネント内に設定されます。
（12） 拒否
これは、ユーザーが投稿したメッセージを拒否したり、相手からの手紙を偽造したりするなど、ユーザーからの攻撃です。
（13） リプレイ
正規の通信データのバックアップが、違法な目的で傍受・再送信されたもの。
（14） コンピュータウイルス
いわゆるコンピュータ ウイルスは、コンピュータ システムの動作中に感染して侵害する可能性のある機能的なプログラムです。ウイルスには通常 2 つの機能があります。1 つは他のプログラムに「感染」することであり、もう 1 つは損傷を引き起こすか、攻撃を埋め込む機能です。
（15） 人事不正
権限を有する者が、金銭や利益を目的として、あるいは不注意により、権限のない者に情報を開示する。
（16） メディアスクラップ
情報は廃棄されたディスクまたは印刷された記憶媒体から取得されます。
（17） 物理的侵入
侵入者は物理的な制御をバイパスしてシステムにアクセスします。
（18） 窃盗
トークンやIDカードなどの重要なセキュリティアイテムが盗まれます。
（19） ビジネス上の欺瞞
正規のユーザーまたはシステムをだまして機密情報を自発的に放棄させる偽のシステムまたはシステム コンポーネント。
II. 定義と範囲
セキュリティ アーキテクチャは、アーキテクチャ レベルでの情報システム セキュリティに焦点を当てた細分化です。
セキュリティは情報システムに反映され、通常のシステム セキュリティ アーキテクチャ、セキュリティ テクノロジ アーキテクチャ、および監査アーキテクチャによって 3 つのセキュリティ防御が形成されます。
1. システムセキュリティアーキテクチャ
システム セキュリティ アーキテクチャとは、情報システムのセキュリティ品質属性とそれらの間の関係を構築する主要なコンポーネントを指します。
システム セキュリティ アーキテクチャの目標は、外部の防御システムに依存せずにソースから独自のセキュリティを構築する方法です。
2. セキュリティ技術のアーキテクチャ
セキュリティ テクノロジ アーキテクチャとは、セキュリティ テクノロジ システムを構築する主要なコンポーネントとそれらのコンポーネント間の関係を指します。
セキュリティ技術アーキテクチャのタスクは、セキュリティインフラストラクチャ、セキュリティツールとセキュリティテクノロジ、セキュリティコンポーネントとサポートシステムなどを含む一般的なセキュリティ技術インフラストラクチャを構築し、各部分のセキュリティ防御能力を体系的に強化することです。
3. 監査アーキテクチャ
監査構造とは、独立した監査部門、またはそれが提供できるリスク発見機能を指します。監査の範囲には、主にセキュリティ リスクを含むすべてのリスクが含まれます。
システムを設計する場合、通常、システムが直面する可能性のあるセキュリティ脅威を特定し、システムが直面するセキュリティ脅威を合理的に評価し、対応する制御措置を実装することで、セキュリティを形成するための効果的かつ合理的なセキュリティ技術を提案する必要があります。情報システムのセキュリティを向上させる方法。ソリューションはセキュリティ アーキテクチャ設計の基本的な目標です。実際のアプリケーションでは、暗号化や復号化、ネットワークセキュリティ技術などのセキュリティ技術の観点からセキュリティアーキテクチャの設計を検討することができます。
III. 全体的なアーキテクチャ設計
一、 情報セキュリティ保証システムの枠組みは、技術体制、組織体制、管理体制の３つの部分から構成される必要があります。つまり、人材、管理、技術的手段が情報セキュリティアーキテクチャ設計の三大要素であり、動的な情報およびネットワークセキュリティ保証システムの枠組みを構築することがシステムセキュリティの実現を保証することになります。
二、 ネットワーク セキュリティ保護の問題に対応して、さまざまな国が PDRR などの複数のネットワーク セキュリティ システム モデルとアーキテクチャを提案してきました。 (保護/検出/対応/復旧、保護/検出/対応/復旧) モデル、P2DR モデル (ポリシー/保護/検出/対応、セキュリティ ポリシー/保護/検出/対応)。
三、 WPDRRCモデル
WPDRRC（Waring/Protect/Detect/React/Restore/Counter Attack）は、我が国の情報セキュリティ専門家グループが提案した情報システムセキュリティ保証システム構築モデルです。
WPDRRC は PDRR 情報セキュリティ システム モデルに基づいており、早期警告および反撃機能が追加されています。
PDRR モデルでは、セキュリティの概念が情報セキュリティから情報保証へと拡張され、情報保証の意味は、従来の情報セキュリティと機密性の組み合わせを超えています。 PDRR モデルは、情報セキュリティ保護を基礎としており、保護をアクティブなプロセスと見なし、検出方法を使用してセキュリティの脆弱性を発見し、タイムリーに修正します。同時に、システムが侵入された場合には、緊急対応措置を講じてシステムを正常な状態に戻す必要があります。これによってのみ、情報のセキュリティが完全に保証されます。このモデルは、自動障害回復機能を重視しています。
6 つのリンクには、早期警告 (W)、保護 (P)、検出 (D)、対応 (R)、回復 (R)、反撃 (C) が含まれます。これらには強力なタイミングとダイナミクスがあり、早期警告をより適切に反映できます。 、情報システムセキュリティシステムの保護、検出、対応、回復および反撃の機能。
（1） 早期警戒(W)
これは主に、リモート セキュリティ評価システムによって提供される模擬攻撃テクノロジを使用して、システム内で悪用される可能性のある弱点を確認し、ネットワークと情報のセキュリティ リスクを収集およびテストし、解決策の提案を提供するための直感的な方法でレポートを作成することを指します。
（2） プロテクト(P)
通常、保護には、ネットワークと情報のセキュリティを実現するために、成熟した情報セキュリティ テクノロジと方法が採用されています。
主な内容としては、暗号化の仕組み、デジタル署名の仕組み、アクセス制御の仕組み、認証の仕組み、情報隠蔽やファイアウォール技術などが挙げられます。
（3） 検出(D)
テストとは、ネットワークとシステムを検出および監視して、新しい脅威と弱点を発見し、セキュリティ ポリシーを適用することです。
このプロセスでは、侵入検知や悪意のあるコードのフィルタリングなどのテクノロジーを使用して、動的検知システムと報酬レポート調整メカニズムを形成し、検知のリアルタイム性を向上させます。
主な内容としては、侵入検知、システム脆弱性検知、データ整合性検知、攻撃検知などが挙げられます。
（4） レスポンス(R)
これは、セキュリティの脆弱性やセキュリティ イベントを検出した後、システムを安全な状態に調整するために適時に適切な対応を行う必要があることを意味します。この目的を達成するには、ブロック、隔離、レポート、その他の機能を含む、対応するアラーム、追跡、処理システムが必要です。
主な内容としては、緊急戦略、緊急メカニズム、緊急手段、侵入プロセス分析、セキュリティ状況評価などが含まれる。
（5） リカバリー(R)
現在のネットワーク、データ、サービスがハッカーによって攻撃され、損傷または影響を受けた後、必要な技術的手段を使用して、可能な限り短期間でシステムを正常に復元することを指します。
主な内容としては、耐障害性、冗長性、バックアップ、交換、修理・復旧などが挙げられます。
（6） 反撃(C)
これは、強力な証拠収集能力と法的攻撃方法を構築するために、あらゆるハイテク手段を使用してコンピューター犯罪者の手がかりと犯罪証拠を検出および抽出することを指します。
3 つの主要な要素には、人材、戦略、テクノロジーが含まれます。人が核であり、戦略が橋渡しであり、テクノロジーが保証です。
長年の開発を経て、ネットワーク セキュリティ システム モデルは、PDP、PPDR、PDRR、MPDRR、WPDRRC などのモデルを形成し、情報セキュリティ防止においてより完全な機能を備えています。
四、 建築デザイン
情報システムのセキュリティ要件は、単一のセキュリティ技術だけでは解決できません。情報セキュリティ アーキテクチャを設計するには、適切なセキュリティ アーキテクチャ モデルを選択する必要があります。
情報システムのセキュリティ設計は、次の 2 つの側面に重点を置いています。
1. システムセキュリティシステム
セキュリティ保証体系は、セキュリティサービス、プロトコルレベル、システム単位の3つのレベルで構成されており、各層がセキュリティ管理の内容をカバーしています。
システムセキュリティ保証システムの設計作業では、主に以下の点を考慮します。
（1） セキュリティゾーン戦略の決定
管轄当局は、安全保障分野の区分に基づいて、対象を絞った安全保障戦略を策定する必要がある。定期的な監査評価、侵入検知システムの導入、統一的な認可、認証など。
（2） ウイルス対策システムの統合構成と管理
管轄当局は、統一された構成と管理を実現するための全体的な防御戦略を確立する必要があります。ネットワークのウイルス対策戦略は、包括性、使いやすさ、リアルタイムのパフォーマンス、拡張性の要件を満たしている必要があります。
（3） ネットワークと情報セキュリティの管理
ネットワークセキュリティにおいては、技術的な対策に加え、ネットワークや情報のセキュリティ管理を強化し、関連規定を整備する必要があります。関連する管理において、安全保証措置は、最終的には特定の管理規則および管理規定および特定の管理責任に基づいて実装され、管理者の仕事を通じて実現されなければなりません。
2. 情報セキュリティアーキテクチャ
情報システムアプリケーションを包括的に理解することで、セキュリティリスク、要件分析結果、セキュリティポリシー、ネットワークおよび情報セキュリティ目標に従ってセキュリティシステムアーキテクチャの設計作業を実行します。
具体的には安全制御システムにおいて、5つの側面から解析・設計が可能です。
（1） 物理的なセキュリティ
コンピュータ情報システムにおけるさまざまな機器の物理的なセキュリティを確保することは、ネットワークシステム全体のセキュリティを確保するための前提条件となります。
物理的セキュリティとは、地震、洪水、火災などの環境事故、人為的な操作ミスやミス、さまざまなコンピュータ犯罪によって引き起こされる損害からコンピュータネットワーク機器、施設、その他のメディアを保護するプロセスです。
物理的セキュリティには主に、環境セキュリティ、機器セキュリティ、メディア セキュリティなどが含まれます。
（2） システムセキュリティ
システムセキュリティとは、主に情報システムの各コンポーネントのセキュリティ要件を指します。
システム セキュリティは、システム全体のセキュリティの基礎です。
これには主に、ネットワーク構造のセキュリティ、オペレーティング システムのセキュリティ、アプリケーション システムのセキュリティが含まれます。
（3） サイバーセキュリティ
サイバーセキュリティは、セキュリティ ソリューション全体の鍵です。
これには主に、アクセス制御、通信の機密性、侵入検出、ネットワーク セキュリティ スキャン、ウイルス対策が含まれます。
（4） アプリケーションのセキュリティ
アプリケーション セキュリティとは、主に、複数のユーザーがネットワーク システムを使用する場合に、共有リソースや情報ストレージ操作によって引き起こされるセキュリティ問題を指します。
これには主に、リソース共有と情報ストレージという 2 つの側面が含まれます。
（5） セキュリティ管理
主に健全な安全管理体制の構築、安全管理基盤の構築の3つの側面に反映されます。 従業員の安全意識を高めるためのプラットフォーム。
五、 デザインポイント
I. システムセキュリティ設計のポイント
ネットワーク構造セキュリティの分野では、ネットワーク トポロジが合理的であるか、回線が冗長であるか、ルーティングが冗長であるか、および単一障害点の防止に焦点が当てられます。
オペレーティング システムのセキュリティは、次の 2 つの側面に重点を置いています。 ① オペレーティング システムのセキュリティを防ぐために講じることができる対策。たとえば、より安全なネットワーク オペレーティング システムを使用し、必要なセキュリティ構成を行う、一般的には使用されないがセキュリティ リスクのある一部のアプリケーションを終了するなどです。 , 権限を使用して、パスワードなどの使用を制限または強化します。 ② オペレーティングシステムのセキュリティスキャンシステムを搭載し、オペレーティングシステムのセキュリティスキャンを実施し、脆弱性を発見し、適時にアップグレードします。
アプリケーション システムのセキュリティの観点からは、アプリケーション サーバーに重点を置き、ファイル サービスや電子メール サーバーなど、あまり使用されないプロトコルやプロトコル ポートを開かないようにしてください。サーバー上の HTTP、FTP、Telnet などのサービスをオフにすることができます。ログイン ID 認証を強化して、ユーザーの使用の合法性を確保できます。
II. ネットワークセキュリティ設計の要点
隔離とアクセス制御には厳格な管理体制が必要であり、「ユーザー認可実装ルール」、「パスワードおよびアカウント管理仕様」、「権限管理策定」などの一連の管理措置を策定することができます。
ファイアウォールの装備は、ネットワーク セキュリティにおける最も基本的で経済的かつ効果的なセキュリティ対策です。内部ネットワークと外部ネットワーク、または内部ネットワーク内の異なる信頼ドメイン間の分離とアクセス制御は、ファイアウォールの厳格なセキュリティ ポリシーによって実現され、ファイアウォールは一方向または双方向の制御を実装でき、一部のレベルではより詳細なアクセス制御を実装できます。 -レベルのプロトコル。
侵入検知では、既存および最新の攻撃手法の情報コードに基づいて、ネットワークセグメント内外のすべての操作をリアルタイムに監視および記録し、確立された戦略に従って対応（ブロック、警告、電子メールの送信）を実行する必要があります。これにより、ネットワークに対する攻撃や犯罪が防止されます。侵入検知システムには通常、コンソールと検知器 (ネットワーク エンジン) が含まれます。コンソールは、すべての検知器 (ネットワーク エンジン) を作成および管理するために使用され、ネットワーク エンジンは、ネットワーク内外のアクセス動作を監視し、それに応じて対応する動作を実行します。コンソールの指示。
ネットワーク環境においては、コンピュータウイルスの脅威や破壊力は計り知れないため、ウイルス対策はネットワークセキュリティにとって必要な手段です。ネットワークシステムで使用されるオペレーティングシステム（Windows システムなど）はウイルスに感染しやすいため、ネットワークセキュリティ構築において考慮すべき重要な要素の 1 つであるウイルス対策技術には、次の 3 種類があります。ウイルスの予防、ウイルスの検出、ウイルス対策。
III. アプリケーションのセキュリティ設計の要点
リソース共有では、社内従業員によるネットワーク共有リソースの使用を厳密に管理する必要があります。一般に、社内サブネット内の共有ディレクトリは簡単に開かないでください。そうしないと、従業員間の情報交換時に重要な情報が漏洩する可能性があります。頻繁に情報を交換する必要があるユーザーの場合は、共有時に必要なパスワード認証機構を追加する必要があります。つまり、パスワード認証によってのみデータへのアクセスを許可する必要があります。
情報ストレージとは、機密情報を含むユーザー ホストを指します。ユーザーは、申請プロセス中に一般的ではないネットワーク サービスをできるだけ開かないようにする必要があります。データ サーバーにデータベースの安全なバックアップを作成します。データベースは、ネットワーク バックアップ システムを通じてリモートでバックアップおよび保存できます。
IV. 安全管理設計のポイント
セキュリティ管理体制の確立と改善は、ネットワークセキュリティを実現するための重要な保証となります。 セキュリティ運用手順、セキュリティインシデントに対する賞罰制度を実情に応じて策定し、セキュリティ管理者を任命し、監督と監視の全責任を負います。ガイダンス。
セキュリティ管理プラットフォームを構築すると、意図しない人的要因によって引き起こされる多くのリスクが軽減されます。セキュリティ管理プラットフォームを構築すると、セキュリティ管理サブネットの形成、集中統合セキュリティ管理ソフトウェア、ネットワーク機器管理システム、ネットワークセキュリティ機器統合管理ソフトウェアなどの導入など、ネットワーク全体のセキュリティ管理を実現するための技術的保護を提供できます。セキュリティ管理プラットフォームを通じて。
全体的なセキュリティ手法に対する従業員の意識を包括的に向上させるために、ネットワーク セキュリティ予防意識向上研修を部門従業員に対して頻繁に実施する必要があります。
六、 アーキテクチャの例
ここでいう安全制御システムとは、関連設備の不安全状態を最大限回避し、悪質な事故の発生を防止し、あるいは事故後の損失を可能な限り軽減する、信頼性の高い安全保護手法を提供できるシステムを指します。デバイスと最も重要な個人の安全を保護します。
アーキテクチャは従来の階層構造を採用しており、データ層、機能層、プレゼンテーション層に分かれています。データ層は主に組織データを統一的に管理し、データのさまざまなセキュリティ特性に従ってデータを保存、分離、保護します。機能層は、可用性監視、サービス サポート、セキュリティ監視など、システム セキュリティ防止の主要なコア機能です。可用性監視は、主にネットワーク セキュリティ、システム セキュリティ、およびアプリケーション セキュリティの監視機能を実装します。サービス サポートのビジネス プロセスには、セキュリティ管理設計が含まれ、セキュリティ管理環境での運用および保守管理のほとんどの機能が実現されます。発見された現象は、リスクの分析と評価だけでなく、脅威の追跡、セキュリティドメインの監査評価、認可、認証などを含めて、適切に処理されます。プレゼンテーション層は主に、セキュリティ アーキテクチャの使用、保守、意思決定などを含む、さまざまな種類のユーザー アプリケーション機能の実装を完了します。
IV. ネットワークセキュリティアーキテクチャの設計
i. 情報システム セキュリティ システムを確立する目的は、普遍的なセキュリティ原則と情報システムの現実を組み合わせて、情報システムのセキュリティ ニーズを満たすセキュリティ アーキテクチャを形成することです。ネットワーク セキュリティ システムは、情報システム システムの中核の 1 つです。
ii. システムセキュリティシステム
1. OSIセキュリティアーキテクチャ
OSI (Open System Interconnection/Reference Mode、OSI/RM) は、国際標準化団体によって策定されたオープン通信システム相互接続モデル (ISO 7498-2) の国家規格 GB/T9387.2「オープン システム情報処理システムの基本リファレンス」です。相互接続「モデル パート 2: セキュリティ アーキテクチャ」は ISO 7498-2 と同等です。
OSI の目的は、オープン システム プロセス間で長距離にわたる情報の安全な交換を保証することです。これらの標準は、参照モデルのフレームワーク内でいくつかの指導原則と制約を確立し、それによってオープン相互接続システムにおけるセキュリティ問題を解決するための一貫したアプローチを提供します。
OSI は 7 層のプロトコルを定義しており、層 5 (セッション層) を除く各層は対応するセキュリティ サービスを提供できます。
物理層、ネットワーク層、トランスポート層、アプリケーション層でのセキュリティ サービスの構成に最適ですが、他の層でのセキュリティ サービスの構成には適していません。
OSIオープンシステム相互接続セキュリティシステムの5種類のセキュリティサービスには、認証、アクセス制御、データ機密性、データ完全性、否認防止が含まれます。
OSI は、多層防御セキュリティ技術アーキテクチャとも呼ばれる階層型マルチポイント セキュリティ技術アーキテクチャを定義しており、次の 3 つの方法で情報システム全体に防御機能を分散します。
（1） 多点テクニカルディフェンス
1||| ネットワークとインフラストラクチャ:
可用性を確保するには、LAN と WAN をサービス拒否攻撃などの攻撃から保護する必要があります。機密性と完全性を確保するには、これらのネットワーク上で送信される情報とトラフィックの特性を意図しない開示から保護する必要があります。
2||| 境界：
アクティブなネットワーク攻撃から保護するには、境界はトラフィックのフィルタリングと制御、侵入検出などのより強力な境界防御を提供する必要があります。
3||| コンピューティング環境:
内部の密集した分散攻撃から保護するには、ホストとワークステーションが適切なアクセス制御を提供する必要があります。
（2） 多層的な技術的防御
これらの攻撃による攻撃が成功する可能性と手頃な価格を減らすために、各メカニズムは独自の障壁を表し、保護と検出の両方の方法を含む必要があります。
たとえば、ネストされたファイアウォールを外部境界と内部境界の両方で侵入検出とともに使用することは、多層テクノロジー防御の一例です。
（3） インフラを支える
1||| 公開鍵インフラストラクチャ
公開キー証明書と従来の対称キーを安全に作成、配布、管理するための共通フェデレーションを提供し、ネットワーク、境界、コンピューティング環境に安全なサービスを提供できるようにします。これらのサービスは、送信者と受信者の完全性を確実に検証し、情報の不正な開示や改ざんを防止します。公開鍵インフラストラクチャは、制御された相互運用性をサポートし、各ユーザー コミュニティによって確立されたセキュリティ ポリシーと一致する必要があります。
2||| 検出および対応インフラストラクチャ
侵入を迅速に検出して対応する機能。また、イベントを他の関連イベントと合わせて簡単に観察できる「サマリー」機能も提供します。さらに、アナリストは潜在的な行動パターンや新たな傾向を特定できます。
情報システムのセキュリティはテクノロジーに依存するだけでなく、非技術的な防御方法も必要とします。許容可能なレベルの情報保証は、人材、管理者、テクノロジー、プロセスの組み合わせに依存します。
2. 認証の枠組み
認証の基本的な目的は、他のエンティティが認証されたエンティティの ID を占有し、独立して操作することを防ぐことです。
認証は、エンティティがその身元を主張し、主体と検証者の間の関係のコンテキストにおいてのみ意味があることを保証します。
識別には 2 つの重要な関係コンテキストがあります。
①エンティティは申請者によって代表されており、申請者と検証者との間に特定の通信関係（エンティティの識別など）がある。
②主体はデータ項目のソースを検証者に提供する。
識別方法は主に以下の5つの方法があります。
1||| 秘密のパスワードなどの既知のもの。
2||| ICカード、トークン等の所持
3||| 生物学的特性など、変化しない特性。
4||| 信頼できる第三者によって確立された認証を信頼します (再帰)。
5||| 環境 (ホストアドレスなど)。
認証情報とは、申請者の認証要求から認証プロセスの終了までに生成、使用、交換される情報を指します。
認証情報の種類には、認証情報交換、認証情報要求、認証情報検証がある。
場合によっては、申請者は交換認証情報を生成するために信頼できる第三者と対話する必要があります。同様に、認証情報の交換を検証するために、検証者も信頼できる第三者と対話する必要があります。この場合、信頼できる第三者は、関連するエンティティの検証 AI を保持し、また、信頼できる第三者を認証情報の転送および交換に使用することもできます。エンティティは、信頼できる第三者の認証に使用される認証情報も保持する必要がある場合があります。
認証サービスは次の段階に分かれています。
1||| 設置段階
アプリケーション認証情報と検証用認証情報を定義します。
2||| 識別情報変更ステージ
エンティティまたは管理者は、認証情報を申請し、認証情報の変更 (パスワードの変更など) を確認します。
3||| 流通段階
認証および認証情報を交換するには、認証認証情報をさまざまな主体（申請者や検証者など）に配布します。 証人）使用します。
4||| 獲得段階
申請者または検証者は、認証インスタンスの特定の交換認証情報を生成するために必要な情報を取得できます。 認証情報の交換は、信頼できる第三者と対話するか、認証エンティティ間で情報を交換することによって取得できます。
5||| 送信フェーズ
申請者と検証者の間で認証情報を送信および交換します。
6||| 検証フェーズ
交換認証情報は検証認証情報と照合されます。
7||| 非活性化フェーズ
以前に認証されたエンティティを一時的に認証できない状態が確立されます。
8||| 再活性化フェーズ
非アクティブ化フェーズ中に確立された状態は終了します。
9||| インストールフェーズをキャンセルする
エンティティはエンティティ コレクションから削除されます。
3. アクセス制御フレームワーク
アクセス制御は、オープン システム環境でどのリソースの使用を許可するか、および不正アクセスを防止するのが適切な場所を決定するプロセスです。
アクセス制御の場合、アクセスはシステム (つまり、システムの通信部分であるエンティティ) に対して行うことも、システム内に対して行うこともできます。
図 4-25 および図 4-26 は、アクセス制御の基本機能を示しています。
ACI (アクセス制御情報) は、コンテキスト情報を含む、アクセス制御の目的で使用されるあらゆる情報です。 ADI (アクセス制御決定情報) は、特定のアクセス制御決定を行うときに ADF が利用できる ACI の一部 (またはすべて) です。
ADF (アクセス制御決定機能) は、アクセス要求、ADI、およびアクセス要求のコンテキストに関するアクセス制御ポリシー ルールを使用して、アクセス制御の決定を行う特定の機能です。 AEF (Access Control Enforcement Function) は、ターゲットへの許可されたアクセスのみがイニシエータによって実行されることを保証します。
アクセス制御に関与するのは、イニシエーター、AEF、ADF、およびターゲットです。イニシエーターは、ターゲットにアクセスする、またはアクセスを試みる人々およびコンピューターベースのエンティティを表します。ターゲットは、アクセスが試行される、またはイニシエータによってアクセスされるコンピュータまたは通信ベースのエンティティを表します。たとえば、ターゲットは OSI エンティティ、ファイル、システムなどです。アクセス要求は、アクセス試行の一部を形成する操作とオペランドを表します。
イニシエーターがターゲットへの特別なアクセスを要求すると、AEF は、決定を下すために決定が必要であることを ADF に通知します。決定を行うために、ADF にはアクセス要求 (決定要求の一部として) と次のアクセス制御決定情報 (ADI) が提供されます。
（1） イニシエータ ADI (ADI はイニシエータにバインドされた ACI から派生します)。
（2） ターゲット ADI (ADI はターゲットにバインドされた ACI から派生します)。
（3） アクセス要求 ADI (ADI は、アクセス要求にバインドされた ACI から派生します)。
ADF へのその他の入力は、(ADF のセキュリティ ドメイン権限からの) アクセス コントロール ポリシー ルールと、ADI またはポリシーを解釈するために使用される必要なコンテキスト情報です。コンテキスト情報には、発信者の位置、アクセス時間、または使用中の特別な通信パスが含まれます。これらの入力と、場合によっては以前の決定で保持された ADI 情報に基づいて、ADF は、イニシエーターによるターゲットへのアクセス試行を許可または禁止する決定を下すことができます。決定は AEF に渡され、AEF はアクセス要求をターゲットに渡すことを許可するか、他の適切なアクションを実行します。
多くの場合、イニシエータによるターゲットへの連続したアクセス要求には関連性があります。アプリケーションにおける典型的な例は、同じレイヤ ターゲットとの接続を開いた後、アプリケーション プロセスが同じ (予約された) ADI を使用して複数のアクセスを実行しようとすることです。その後、その接続を通じて通信される一部のアクセス要求については、これが必要になる場合があります。追加のアクセス要求を ADF に提供する場合、ADI はアクセス要求を許可します。また、セキュリティ ポリシーにより、1 つ以上のイニシエータと 1 つ以上のターゲット間の特定のアクセス要求に対する制限が必要になる場合があります。この場合、ADF は複数のイニシエータを使用することがあります。アクセス要求は、ターゲットに関する以前の決定から保持された ADI を使用して裁定されます。
AEF によって許可されている場合、アクセス要求にはイニシエーターとターゲット間の対話が 1 回だけ含まれます。イニシエータとターゲット間の一部のアクセス要求は他のアクセス要求とまったく無関係ですが、多くの場合、2 つのエンティティはチャレンジ/レスポンス パターンなど、関連する一連のアクセス要求に入ります。この場合、エンティティはイニシエータとターゲットの役割を同時にまたは必要に応じて交互に変更し、アクセス制御機能は個別の AEF コンポーネント、ADF コンポーネント、およびアクセス制御ポリシーによってアクセス要求ごとに実行できます。
4. 機密保持の枠組み
機密保持 (Confidentiality) サービスの目的は、権限を与えられた人のみが情報を利用できるようにすることです。情報はデータによって表され、データによって関係が変化する可能性があるため (たとえば、ファイル操作によりディレクトリの変更や利用可能な記憶領域の変更が生じる可能性があります)、情報はさまざまな方法でデータから取得できます。例えば、データの意味（データの価値など）を理解して導出する、データに関する属性（データの存在、作成されたデータ、データサイズ、最終更新日など）を用いて導出する。データのコンテキスト。つまり、データ表現の動的な変化を観察することで得られる、それに関連する他のデータ エンティティを通じて得られます。
情報の保護は、データが権限のある人に限定されること、またはデータを特定の方法で表現することによって取得されることを保証することです。この保護方法のセマンティクスは、特定の重要な情報を所有する人のみがデータにアクセスできるようにすることです。効果的な機密保護には、必要な制御情報 (キーや RCI など) が保護されることが必要です。この保護メカニズムは、データの保護に使用されるメカニズム (キーは物理的手段で保護できるなど) とは異なります。
機密保持フレームワークでは、保護環境と重複保護環境という 2 つの概念が使用されます。保護された環境内のデータは、特定のセキュリティ メカニズムを使用して保護できます。保護された環境内のすべてのデータは同様の方法で保護されます。 2 つ以上の環境が重複する場合、重複する環境内のデータを複数回保護できます。ある環境から別の環境に移動されたデータを継続的に保護するには、必然的に保護環境の重複が必要になると推測できます。
データの機密性は、データが存在し送信される媒体に依存する可能性があるため、保存されたデータの機密性は、データのセマンティクスを隠すメカニズム (暗号化など) またはデータをシャーディングするメカニズムを使用することによって保証されます。送信中のデータの機密性は、アクセスの禁止、データ セマンティクスの隠蔽、またはデータの分散 (周波数ホッピングなど) のメカニズムによって保証されます。これらのメカニズム タイプは、個別に使用することも、組み合わせて使用することもできます。
機構の種類
（1） アクセスを拒否することで機密性を確保する
（2） 暗号化による機密性の確保
暗号化メカニズムは、対称暗号化メカニズムと対称暗号化メカニズムに分かれています。 非対称暗号化に基づく機密性メカニズム。
5. 整合性フレームワーク
整合性 (Integrity) フレームワークの目的は、脅威の防止または検出によって、さまざまな方法で侵害される可能性のあるデータの整合性とデータ関連属性の整合性を保護することです。完全性とは、データが不正な方法で変更または破壊されない特性を指します。
整合性サービスはいくつかの方法で分類されます。
1||| 防止すべき違反の分類に応じて、不正なデータ変更、不正なデータ作成、不正なデータ削除、不正なデータ挿入、および不正なデータ再生に分類されます。
2||| 提供される保護方法は、完全性損傷の防止と完全性損傷の検出に分けられます。
3||| 回復機構に対応しているかどうかにより、回復機構ありのものと回復機構なしのものに分かれます。
データを保護する機能は使用されているメディアに関連しているため、データ整合性保護メカニズムはメディアごとに異なり、次の 2 つの状況に要約できます。
1||| メディアへのアクセスをブロックするメカニズム。物理的に分離された中断のないチャネル、ルーティング制御、アクセス制御が含まれます。
2||| データまたはデータ項目のシーケンスに対する不正な変更を検出するためのメカニズム。不正な改変には、不正なデータの作成、データの削除、データの再生が含まれます。対応する整合性メカニズムには、封印、デジタル署名、データ複製 (他の種類の侵害に対抗する手段として)、暗号変換と組み合わせたデジタル指紋、およびメッセージ シーケンス番号が含まれます。
保護の強度に応じて、整合性メカニズムは次のように分類できます。
1||| 保護はありません。
2||| 改変および作成の検出。
3||| 変更、作成、削除、重複の検出。
4||| 復元機能による改変と作成の検出。
5||| 変更、作成、削除、重複の検出と回復。
6. 否認防止の枠組み
否認防止 (否認防止) サービスには、証拠の生成、検証、記録だけでなく、紛争解決時のその後の証拠の回復と再検証も含まれます。フレームワークに記載されている否認防止サービスの目的は、特定のイベントまたはアクションに関する証拠を提供することです。イベントまたは行為自体以外の主体は、否認防止サービスを要求できます。否認防止サービスによって保護できる動作の例には、X.400 メッセージの送信、データベースへのレコードの挿入、リモート操作の要求などが含まれます。
メッセージコンテンツの否認防止サービスに関しては、発信元の証明を提供するために、データ発信者の身元とデータの完全性を確認する必要があります。配達証明を提供するには、受信者の身元とデータの整合性を確認する必要があります。場合によっては、コンテキスト情報 (日付、時刻、発信者/受信者の場所など) を含む証拠も必要になる場合があります。否認防止サービスは、否認が試みられた場合に使用できる次の機能を提供します。証拠の生成、証拠の記録、生成された証拠の検証、証拠の回復と再調査です。紛争は、証拠の調査を通じて係争当事者間で直接解決される場合もありますが、問題の行為や出来事が発生したかどうかを評価および決定する仲裁人を通じて解決する必要がある場合もあります。
否認防止は、次の 4 つの独立した段階で構成されます。
1||| 証拠の生成
このフェーズでは、証拠生成要求者は、イベントまたはアクションの証拠を生成するように証拠生成者に要求します。事象や行動に関与する主体は証拠主体と呼ばれ、その関与関係は証拠によって確立される。否認防止サービスの種類に応じて、証拠は、証拠エンティティによって、信頼できる第三者のサービスとともに、または信頼できる第三者のみによって生成されます。
2||| 証拠の送信、保管、回復
この段階では、証拠がエンティティ間で転送されるか、メモリから取得またはメモリに転送されます。
3||| 証拠検証
この段階では、証拠利用者の要求に応じて、証拠検証者によって証拠が検証される。この段階の目的は、証拠の使用者に、提供された証拠が紛争の際に実際に十分であることを納得させることです。信頼できるサードパーティ サービスも、この証拠を検証する情報を提供するために参加できます。
4||| 議論を解決する
紛争解決段階では、仲裁人は当事者間の紛争を解決する責任を負います。
V. データベースシステムのセキュリティ設計
i. データベースの整合性とは、データベース内のデータの正確さと一貫性を指します。データベースの整合性はさまざまな整合性制約によって保証されるため、データベース整合性設計はデータベース整合性制約の設計であると言えます。データベースの整合性制約は、データベース管理システム (DBMS) またはアプリケーション プログラムを通じて実装できます。DBMS に基づく整合性制約は、スキーマの一部としてデータベースに保存されます。
ii. データベース整合性の設計原則
1. データベース整合性制約の種類に基づいてシステムレベルと実装方法を決定し、システムパフォーマンスへの影響を事前に考慮してください。一般に、静的な制約は可能な限りデータベース スキーマに含める必要があり、動的な制約はアプリケーションによって実装されます。
2. エンティティ整合性制約と参照整合性制約は、リレーショナル データベースの最も重要な整合性制約であり、システムの主要なパフォーマンスに影響を与えずに、可能な限り適用する必要があります。システムの使いやすさと引き換えに、一定の時間とスペースを費やす価値があります。
3. 現在主流の DBMS でサポートされているトリガー機能を使用する場合は、トリガーのパフォーマンスのオーバーヘッドが大きい一方で、トリガーの複数レベルのトリガーは制御が難しく、エラーが発生しやすいため注意してください。必要に応じて、Before Type ステートメント レベルのトリガーを使用することをお勧めします。
4. 要件分析の段階では、整合性制約の命名規則を策定し、英単語、略語、テーブル名、列名、下線を意味のある組み合わせで認識し覚えやすくするように努める必要があります。 CASE ツールを使用する場合、通常はデフォルトのルールがあり、これに基づいて変更して使用できます。
5. データベースの整合性は、ビジネス ルールに従って慎重にテストして、暗黙的な整合性制約とパフォーマンスへの影響との間の矛盾をできるだけ早く排除する必要があります。
6. データベースの分析、設計、テスト、実装、初期メンテナンスを最初から最後まで担当する専任のデータベース設計チームが必要です。データベース設計者は、DBMS に基づいたデータベース整合性制約の設計と実装を担当するだけでなく、アプリケーション ソフトウェアによって実装されるデータベース整合性制約をレビューする責任もあります。
7. データベース設計の各段階での作業負荷を軽減するには、適切な CASE ツールを使用する必要があります。優れた CASE ツールはデータベースのライフサイクル全体をサポートできるため、データベース設計者の作業効率が大幅に向上し、ユーザーとのコミュニケーションが容易になります。
iii. データベースの整合性の役割
データベース整合性制約により、正当なユーザーがデータベースの使用時に非セマンティックなデータ コンテンツをデータベースに追加することができなくなります。
DBMS に基づく整合性制御メカニズムを使用してビジネス ルールを実装すると、定義と理解が容易になり、アプリケーションの複雑さが軽減され、アプリケーションの運用効率が向上します。同時に、DBMS の整合性制御メカニズムは集中管理されるため、アプリケーションよりもデータベースの整合性を実現するのが容易です。
合理的なデータベース整合性設計では、データベース整合性とシステム パフォーマンスの両方を考慮できます。たとえば、大量のデータをロードする場合、DBMS に基づくデータベースの整合性制約をロード前に一時的に無効にしてから有効にすれば、データのロード効率に影響を与えることなくデータベースの整合性を保証できます。
アプリケーション ソフトウェアの機能テストでは、データベースの整合性を向上させると、アプリケーション ソフトウェアのエラーをできるだけ早く検出できます。
データベース整合性制約は、列レベルの静的制約、タプル レベルの静的制約、関係レベルの静的制約、列レベルの動的制約、タプル レベルの動的制約、および関係レベルの動的制約の 6 つのカテゴリに分類できます。動的制約は通常、アプリケーション ソフトウェアによって実装されます。異なる DBMS でサポートされるデータベースの整合性は基本的に同じです。一般的なリレーショナル データベース システムでサポートされる DBMS ベースの整合性制約を表 4-3 に示します。
iv. データベース整合性の設計例
優れたデータベース整合性設計では、まず、要件分析フェーズでデータベース整合性制約を通じて実装するビジネス ルールを決定する必要があります。そして、特定のDBMSが提供する整合性管理の仕組みを十分に理解し、システム全体のアーキテクチャや性能要件を踏まえ、データベースの設計手法やアプリケーションソフトウェアの設計手法に準拠して、各ビジネスルールの実装方法を決定します。合理的に選ばれています。最後に、慎重にテストして、暗黙的な制約の競合やパフォーマンスの問題を排除します。
DBMSに基づくデータベース整合性設計は大きく分けて次のようになります。
（1） 要件分析段階
（2） 概念的な構造設計段階
概念構造設計段階では、要件分析の結果を特定の DBMS に依存しない概念モデル、つまりエンティティ関係図 (ERD) に変換します。
（3） 論理構造設計段階
この段階では、概念構造を特定の DBMS がサポートするデータ モデルに変換し、リレーショナル モデルの標準化を含む最適化を行います。
VI. セキュリティアーキテクチャ設計事例の分析
i. ハイブリッド クラウドに基づく産業セキュリティ アーキテクチャ設計を例に挙げます。
ii. ハイブリッド クラウド アーキテクチャは大企業に採用されることがよくあります。ハイブリッド クラウドは、パブリック クラウドとプライベート クラウドを組み合わせたもので、近年のクラウド コンピューティングの主要なモデルおよび開発の方向性です。
iii. ハイブリッドクラウド技術を活用した大企業向けセキュアな生産管理システムのアーキテクチャ
iv. ハイブリッド クラウドに基づく安全な生産管理システムを設計する場合、セキュリティ問題の 5 つの側面を考慮する必要があります。
（1） デバイスのセキュリティ
（2） サイバーセキュリティ
（3） コントロールセキュリティ
（4） アプリケーションのセキュリティ
（5） データセキュリティ
八、 クラウドネイティブアーキテクチャ
I. まとめ
「クラウド ネイティブ」 クラウド ネイティブとは、アプリケーション ソフトウェアとサービスが従来のデータ センターではなくクラウドにあることを意味します。ネイティブとは、当初からクラウド環境を前提としており、クラウドの特性に合わせて設計されたアプリケーションソフトウェアであり、クラウド環境の弾力性と分散性の利点を最大限に活用し、クラウド環境の生産性を最大化します。
II. 開発概要
i. 「ウォーターフォール プロセス」開発モデルは、一方では上流と下流の情報開発を生み出します。 一方、非対称性は開発サイクルを延長し、調整を困難にします。
ii. アジャイル開発はソフトウェアの開発効率やバージョン更新速度の問題を解決するだけで、運用管理の問題はまだ解決できません。 保守管理を効果的に結び付けることができます。
iii. DevOps は、開発、技術運用、品質保証の交差点と見なされ、それらの間のコミュニケーション、コラボレーション、統合が促進され、それによって開発サイクルと効率が向上します。
iv. クラウド ネイティブ コンテナやマイクロサービスなどのテクノロジーは、DevOps の適切な前提条件を提供し、IT ソフトウェア開発が DevOps 開発と継続的デリバリーの主要なアプリケーションを実現することを保証します。言い換えれば、DevOps と継続的デリバリーを実装できることが、クラウド ネイティブ テクノロジーの価値の不可欠な部分になっています。
v. クラウド ネイティブとビジネス シナリオの緊密な統合は、さまざまな業界に開発とイノベーションの新たな勢いを注入するだけでなく、クラウド ネイティブ テクノロジのより迅速な開発とより成熟したエコロジーを促進します。これは主に次の点に反映されます。
1. 組織にもたらす価値の観点から見ると、クラウド ネイティブ アーキテクチャは、複数のコンピューティング パワーをサポートすることで、さまざまなアプリケーション シナリオのパーソナライズされたコンピューティング パワーのニーズを満たし、ソフトウェアとハードウェアの協調アーキテクチャに基づいて、究極のクラウド ネイティブ コンピューティング パワーを提供します。アプリケーションのパフォーマンス。マルチクラウド ガバナンスとエッジクラウド コラボレーションに基づいて、効率的で信頼性の高い分散ユビキタス コンピューティング プラットフォームを構築し、コンテナ、ベア メタル、仮想マシン、機能などのさまざまな形式でユニファイド コンピューティング リソースを構築します。効率的な「アプリケーション」中心のリソース スケジューリングおよび管理プラットフォームは、企業にワンクリック導入、アプリケーションを認識したインテリジェントなスケジューリング、包括的な監視および運用および保守機能を提供します。
2. 最新のDevSecOpsアプリケーション開発モデルにより、アジャイルなアプリケーション開発が実現され、ビジネスアプリケーションのイテレーション速度が向上し、ユーザーニーズへの効率的な対応が実現され、プロセス全体のセキュリティが確保されます。サービス統合については、エンタープライズ アプリケーション アーキテクチャのアップグレードを支援する侵入型と非侵入型の 2 つのモードが提供され、新旧アプリケーション間の有機的な連携を実現し、中断することなく構築できます。
3. 企業がデータを適切に管理し、データ操作機能を迅速に構築し、データの資産蓄積と価値のマイニングを実現し、一連の AI テクノロジーを使用してエンタープライズ アプリケーションを再び強化し、データと AI の機能を組み合わせて企業がインテリジェントなアップグレードを実現できるように支援します。ビジネス。
4. クラウド プラットフォームの包括的な組織レベルのセキュリティ サービスおよびセキュリティ コンプライアンス機能と組み合わせることで、組織のアプリケーションがクラウド上に安全に構築され、ビジネスが安全に運営されることが保証されます。
III. アーキテクチャの定義
i. 技術的な観点から見ると、クラウド ネイティブ アーキテクチャは、クラウド ネイティブ テクノロジに基づいたアーキテクチャ原則と設計パターンの集合であり、クラウド アプリケーション内の非ビジネス コード部分を最大限に削除し、クラウド施設が元のコードを引き継げるようにすることを目的としています。アプリケーションには、非機能的な機能 (弾力性、回復力、セキュリティ、可観測性、グレースケールなど) が数多く備わっているため、機能外のビジネス中断による問題がなくなり、また、軽量で俊敏性が高く、高度に自動化されています。
ii. クラウド ネイティブ テクノロジは、従来のクラウド コンピューティングの 3 層の概念、つまりサービスとしてのインフラストラクチャ (laaS)、サービスとしてのプラットフォーム (PaaS)、およびサービスとしてのソフトウェア (SaaS) に部分的に依存しています。
iii. クラウド ネイティブ コードは通常、次の 3 つの部分で構成されます。
1. 事業者コード
ビジネスロジックを実装するコードを指します。
2. サードパーティ製ソフトウェア
ビジネス コードが依存するのは、ビジネス ライブラリやビジネス ライブラリなど、すべてのサードパーティ ライブラリです。 基本ライブラリ
3. 機能しない機能を処理するコード
高可用性、セキュリティ、可観測性などの非機能的な機能を実装するコードを指します。
ビジネス コードのみがコアであり、他の 2 つの部分は付属品にすぎません。
iv. コード構造の大幅な変更
クラウド環境では、「ストレージをどのように取得するか」は、オブジェクトストレージサービス、ブロックストレージサービス、ファイルストレージサービスなど、多くのサービスになります。クラウドは、開発者がこれらのストレージ機能を取得するためのインターフェースを変更するだけでなく、高可用性の課題、自動拡張と縮小の課題、セキュリティの課題、運用とメンテナンスのアップグレードの課題など、分散シナリオにおけるさまざまな課題を解決します。コード内でノードがダウンする前に、ローカルに保存されたコンテンツをリモート エンドに同期する方法の問題に対処する必要がなく、ビジネスのピークが到来したときにストレージ ノードを拡張する方法の問題に対処する必要もありません。 「ゼロデイ」セキュリティ問題が発見された場合、アプリケーションの運用および保守担当者が問題に対処する必要はありません。サードパーティのストレージ ソフトウェアは緊急にアップグレードされます。
v. 機能しない機能は大幅に委任される
i. どのアプリケーションでも、次の 2 種類の機能が提供されます。
1. 機能的特徴
顧客プロファイルの作成、注文の処理、支払いなど、ビジネスに真の価値をもたらすコード。組織管理、ビジネス辞書管理、検索などの一般的なビジネス機能機能も、ビジネス ニーズと密接に連携しています。
2. 機能しない機能
高可用性、災害復旧、セキュリティ機能、操作性、使いやすさ、テスト容易性、グレースケール リリース機能など、ビジネスに直接的な価値をもたらすわけではないが、通常は不可欠な機能。
ii. クラウドコンピューティングソリューション
1. 仮想マシン
仮想マシンが基盤となるハードウェアの異常を検出すると、アプリケーションのライブ マイグレーションの実行が自動的に支援されます。移行されたアプリケーションを再起動する必要はありませんが、アプリケーション自体とそのユーザーは外部サービスを提供できません。移行プロセス全体の認識。
2. 容器
コンテナは監視と検査を通じて異常なプロセス状態を検出し、異常なノードのオフライン化、新しいノードのオンライン化、本番トラフィックの切り替えなどの操作を実行し、運用保守担当者の介入なしにプロセス全体が自動的に完了します。
3. クラウドサービス
アプリケーションが「ステートフル」部分をクラウド サービス (キャッシュ、データベース、オブジェクト ストレージなど) に引き渡し、加えてグローバル オブジェクト保持の小型化やディスクから迅速に再構築する機能を備えている場合、クラウド サービス自体は非常に強力です。高可用性機能を使用すると、アプリケーション自体がより薄型の「ステートレス」アプリケーションになり、高可用性の障害によるビジネスの中断がほんのわずかに軽減されます。 ベル レベル。アプリケーションが N:M のピアツーピア アーキテクチャ モデル (N 個のクライアントがそれぞれ M 台のサーバーにアクセスできる) の場合、負荷分散製品と組み合わせることで、強力な高可用性機能を実現できます。
vi. 高度に自動化されたソフトウェア配信
コンテナは標準的な方法でソフトウェアをパッケージ化し、コンテナと関連テクノロジは異なる環境間の違いを保護するのに役立ち、それによってコンテナに基づいた標準化されたソフトウェア配信が可能になります。
自動配信の場合は、ソフトウェアがターゲット環境、配信内容、構成リストを「理解し」、コードを通じてターゲット環境の違いを特定し、「目的に向かって方向付ける」ことができるように、さまざまな環境を記述できるツールも必要です。納品内容に基づいて「状態」を確認し、ソフトウェアのインストール、設定、操作、変更を完了します。
IV. 基本原則
1. サービス化
コードのサイズが小規模チームの協力範囲を超える場合は、マイクロサービスアーキテクチャやミニサービス(MiniService)アーキテクチャなどへの分割や、サービスを通じたライフサイクルの異なるモジュールの分離など、サービス指向の分割を行う必要があります。指向のアーキテクチャ。ビジネスの反復を個別に実行して、頻繁な反復モジュールが遅いモジュールによって速度を低下させるのを回避し、それによって全体の進行を加速し、システムの安定性を向上させます。同時に、サービス指向アーキテクチャはインターフェイス指向プログラミングに基づいており、サービス内の機能は高度に結合されており、モジュール間の共通機能モジュールの抽出によりソフトウェアの再利用の度合いが高まります。
分散環境における電流制限とダウングレード、サーキット ブレーカー コンパートメント、グレー スケール、バック プレッシャー、ゼロ トラスト セキュリティなどは、基本的に (ネットワーク トラフィックではなく) サービス トラフィックに基づいた制御戦略であるため、クラウド ネイティブ アーキテクチャはサービスの使用を重視します。この目的は、ビジネス モジュール間の関係をアーキテクチャ レベルから抽象化し、サービス トラフィックの送信を標準化することにより、サービスが開発されている言語に関係なく、ビジネス モジュールがサービス トラフィックに基づいてポリシー制御とガバナンスを実行できるようにすることです。 。
2. 弾性
弾力性とは、事前の容量計画に基づいて固定のハードウェアおよびソフトウェア リソースを準備する必要がなく、ビジネス量の変化に応じてシステムの導入規模が自動的に拡大および縮小できることを意味します。優れた弾力性により、調達からオンライン化までの時間が短縮されるだけでなく、組織は追加のソフトウェアおよびハードウェア リソースのコスト (アイドル コストを含む) に注意を払わなくなり、さらに重要なことに、ビジネスが拡大した場合に組織の IT コストが削減されます。は大規模な緊急事態に直面していますが、拡張する場合、既存のソフトウェアおよびハードウェア リソースの予約が不十分であるために「ノー」と言う必要がなくなり、組織の利益が確保されます。
3. 観察可能な
可観測性は、監視、ビジネス探索、アプリケーション パフォーマンス監視 (アプリケーション パフォーマンス モニター、APM) などのシステムによって提供される機能とは異なります。これは、クラウドなどの分散システムにおけるログ、リンク追跡、メトリクスの積極的な使用です。このメソッドを使用すると、1 回のクリックで複数のサービス呼び出しの時間消費、戻り値、パラメーターが明確に表示され、各サードパーティ ソフトウェア呼び出し、SQL リクエスト、ノード トポロジ、ネットワーク応答などにドリルダウンすることもできます。メンテナンス、開発、およびビジネス担当者は、ソフトウェアの実行状況をリアルタイムで把握し、多次元からのデータ指標を組み合わせて相関分析機能を取得することで、ビジネスの健全性とユーザー エクスペリエンスをデジタル的に継続的に測定し、継続的に最適化することができます。
4. 靭性
回復力は、ソフトウェアが依存するソフトウェアおよびハードウェア コンポーネントでさまざまな異常が発生した場合にソフトウェアが耐える能力を表します。これらの異常には、通常、ハードウェア障害、ハードウェア リソースのボトルネック (CPU/ネットワーク カードの帯域幅の枯渇など)、および制限を超えるビジネス トラフィックが含まれます。ソフトウェア設計能力、コンピュータ室の作業に影響を与える障害や災害、ソフトウェアの脆弱性（バグ）、ハッカー攻撃、およびビジネスの可用性に致命的な影響を与えるその他の要因。
回復力は、ソフトウェアがさまざまな側面からビジネス サービスを提供し続ける能力を説明します。その中心的な目標は、ソフトウェアの平均故障間隔 (MTBF) を改善することです。アーキテクチャ設計の観点から見ると、回復力には、サービスの非同期機能、再試行/電流制限/劣化/サーキット ブレーカー/バック プレッシャー、マスター/スレーブ モード、クラスター モード、AZ (アベイラビリティ ゾーン) 内の高可用性、ユニット化、クロスリージョン (リージョン) が含まれます。 ) 災害復旧、リモート マルチアクティブ災害復旧など。
5. すべてのプロセスの自動化
一方では、組織内のソフトウェア配信プロセスが標準化され、他方では、構成データの自己記述とエンドステート指向の配信プロセスを通じて、自動化が標準化に基づいて実行されます。配信目標や環境の違いを考慮し、ソフトウェアの配信と運用全体の自動化を実現します。
6. ゼロトラスト
ゼロ トラスト セキュリティは、従来の境界セキュリティ アーキテクチャの考え方を再評価および検討し、セキュリティ アーキテクチャのアイデアに新しい提案を行います。中心となる考え方は、ネットワーク内外の個人、デバイス、システムはデフォルトでは信頼されるべきではないということです。アクセス制御の信頼基盤は、IP アドレス、ホスト、地理的位置、ネットワークなどの認証と認可に基づいて再構築する必要があります。など、信頼できる証拠としては使えません。ゼロトラストは、アクセス制御のパラダイムを覆し、セキュリティ アーキテクチャを「ネットワーク集中化」から「アイデンティティ集中化」に導きました。その本質的な魅力は、アイデンティティ中心のアクセス制御です。
ゼロ トラストの最初の中心的な問題はアイデンティティです。アイデンティティは、誰がどの環境で特定のリソースにアクセスするかという問題を解決するために、さまざまなエンティティに異なるアイデンティティを与えます。研究開発、テスト、運用と保守などのマイクロサービスのシナリオでは、ID と関連ポリシーはセキュリティの基礎であるだけでなく、ユーザーがアクセスするシナリオにおける多くの分離メカニズム (リソース、サービス、環境などを含む) の基礎でもあります。組織の内部アプリケーション、アイデンティティ、およびそれらに関連するポリシーにアクセスすることで、インスタント アクセス サービスが提供されます。
7. アーキテクチャは進化し続ける
クラウドネイティブアーキテクチャ自体も、クローズドなアーキテクチャではなく、継続的に進化できるアーキテクチャでなければなりません。段階的な反復やターゲットの選択などの要素に加えて、組織 (アーキテクチャ管理委員会など) レベルでのアーキテクチャのガバナンスとリスク管理、特にこの場合のアーキテクチャ、ビジネス、実装のバランスのとれた関係を考慮する必要もあります。高速なビジネス反復の実現。クラウド ネイティブ アーキテクチャは、新しいアプリケーションのアーキテクチャ制御戦略を選択するのが比較的簡単です (通常は、弾力性、俊敏性、コストの次元を選択します)。ただし、既存のアプリケーションをクラウド ネイティブ アーキテクチャに移行するには、レガシー アプリケーションの移行コストが必要になります。 /リスクと移行コスト/クラウドへのリスク、およびマイクロサービス/アプリケーション ゲートウェイ、アプリケーション統合、アダプター、サービス メッシュ、データ移行、オンライン グレースケールなどを介したアプリケーションとトラフィックの技術的にきめ細かい制御を考慮する必要があります。
V. 一般的なアーキテクチャ パターン
1. サービス指向アーキテクチャー
サービス指向アーキテクチャは、新しい時代のクラウドネイティブ アプリケーションを構築するための標準的なアーキテクチャ モデルです。これには、ソフトウェアをアプリケーション モジュールに分割し、インターフェイス コントラクト (IDL など) で相互のビジネス関係を定義し、標準との相互信頼を確保する必要があります。プロトコル (HTTP、gRPC など) の相互運用性と、ドメイン駆動設計 (DDD)、テスト駆動開発 (TDD)、およびコンテナー化されたデプロイメントを組み合わせることで、各インターフェイスのコード品質と反復速度が向上します。
サービス指向アーキテクチャの典型的なパターンは、マイクロサービスと小規模サービス パターンです。小規模サービスは、データを共有する非常に密接に関連したサービスのグループの組み合わせとして見ることができます。通常、小規模サービス モデルは、過度の呼び出し損失 (特にサービス間呼び出しとデータ整合性処理) や、インターフェイスの粒度が細かすぎることによって生じるガバナンスの複雑さを回避するために、非常に大規模なソフトウェア システムに適しています。
2. メッシュアーキテクチャ
メッシュ (グリッド) アーキテクチャは、ミドルウェア フレームワーク (RPC、キャッシュ、非同期メッセージなど) をビジネス プロセスから分離し、ミドルウェア ソフトウェア開発キット (ソフトウェア開発キット、SDK) がビジネス コードからさらに分離されるようにします。その結果、ミドルウェアのアップグレードはビジネス プロセスに影響を与えず、別のプラットフォームに移行されたミドルウェアもビジネスには透過的です。
分離後は、非常に「薄い」クライアント部分のみがビジネス プロセスに保持され、クライアントは通常、変更されることはほとんどなく、元々メッシュ プロセスで処理する必要があったフロー制御、セキュリティ、その他のロジックのみを担当します。 SDKはMeshプロセスによって完成します。
メッシュ アーキテクチャが実装されると、これらのサードパーティ ソフトウェア パッケージが使用されている場合でも、多数の分散アーキテクチャ モード (サーキット ブレーカー、電流制限、ダウングレード、再試行、バック プレッシャー、分離など) がメッシュ プロセスによって完了します。ビジネス コード製品では使用されません。同時に、より優れたセキュリティ (ゼロ トラスト アーキテクチャ機能など)、トラフィックに基づく動的な環境分離、トラフィックに基づくスモーク/回帰テストなどが得られます。
3. サーバーレス
サーバーレス(サーバーレス)は運用や保守から「デプロイ」という行為を「奪う」ため、開発者はアプリケーションの運用を意識する必要がなくなります。 実行場所、オペレーティング システム、ネットワーク構成、CPU パフォーマンスなど。
サーバーレスはどのタイプのアプリケーションにも適しているわけではないため、アーキテクチャの意思決定者は、アプリケーションのタイプがどのタイプのアプリケーションにも適しているかどうかを考慮する必要があります。 サーバーレス コンピューティング。アプリケーションがステートフルである場合、サーバーレス スケジューリングはアプリケーションの状態同期に役立ちません。そのため、アプリケーションがバックグラウンドで長時間実行される集中的なコンピューティング タスクである場合、クラウドによってコンテキストの損失が発生する可能性があります。アプリケーションに頻繁な外部 I/O (ネットワークやストレージ、サービス間の呼び出しなど) が含まれる場合は、I/O の負荷が高く、遅延が大きいため、適切ではありません。サーバーレスは、イベント駆動型のデータ コンピューティング タスク、コンピューティング時間の短い要求/応答アプリケーション、複雑な相互呼び出しのないサイクルの長いタスクに非常に適しています。
4. ストレージとコンピューティングの分離
分散環境における CAP (一貫性: 可用性: パーティション耐性) の難しさは主にステートフル アプリケーションにあります。ステートレス アプリケーションには C (一貫性) の次元がないため、A (可用性) と P (パーティション耐性)、より優れた復元力を実現します。クラウド環境では、クラウド サービスを使用して、あらゆる種類の一時データ (セッションなど)、構造化および非構造化永続データを保存し、それによってストレージとコンピューティングの分離を実現することをお勧めします。ただし、リモート キャッシュに保存すると、トランザクション パフォーマンスが大幅に低下する状態がまだあります。たとえば、現時点ではトランザクション セッション データが大きすぎるため、コンテキストに基づいて常に再取得する必要があります。タイム ログ スナップショット (またはチェックポイント) の使用を検討できます。この方法により、再起動後の迅速かつ段階的なサービスの復元が可能になり、ビジネスへの利用不能の影響が軽減されます。
5. 分散トランザクション
従来の XA (eXtended Architecture) モードが使用されますが、これは強力な一貫性がありますが、パフォーマンスは低くなります。
メッセージベースの結果整合性は一般に高いパフォーマンスを発揮しますが、汎用性は限られています。
TCC (試行-確認-キャンセル) モードはアプリケーション層によってトランザクションを完全に制御し、トランザクションの分離は制御可能で比較的効率的ですが、ビジネスにとって非常に煩雑であり、設計、開発、保守のコストが高くなります。すごく高い。
SAGA モード (一貫した分散アプリケーションの確立を可能にする障害管理モードを指します) には、TCC モードと同様の長所と短所がありますが、Try フェーズがなく、代わりに各転送トランザクションが補償トランザクションに対応します。開発費や維持費が高額になる。
オープン ソース プロジェクト SEATA の AT モードは非常に高性能で、コード開発の負荷がなく、ロールバック操作を自動的に実行できます。また、使用シナリオの制限もあります。
6. 観察可能な
監視可能なアーキテクチャには、ロギング、トレース、およびメトリクスの 3 つの側面が含まれます。ロギングは、アプリケーション開発者によって事前に提供される、複数のレベル (詳細/デバッグ/警告/エラー/致命的) での詳細な情報追跡を提供します。バックエンドの完全なコール リンク追跡は、分散シナリオで特に役立ちます。メトリクスはシステム定量化の多次元測定を提供します。
アーキテクチャの意思決定者は、可観測性をサポートする適切なオープンソース フレームワーク (Open Tracing、Open Telemetry など) を選択し、コンテキストに応じた監視可能なデータ仕様 (メソッド名、ユーザー情報、地理的位置、リクエスト パラメーターなど) を標準化する必要があります。 ）、観察可能なデータがどのサービスおよび技術コンポーネントに分散されるかを計画し、ログおよびトレース情報で spaid/traceid を使用して、分散リンク分析を実行するときに高速な相関分析に十分な情報があることを確認します。
オブザーバビリティを確立する主な目的は、サービスの SLO (サービス レベル目標) を測定し、それによって SLA (サービス レベル アグリーメント) を最適化することであるため、アーキテクチャ設計では、同時実行性、消費時間、利用可能時間、サービス レベルなどのコンポーネントごとに明確な SLO を定義する必要があります。容量など
7. イベント駆動型
イベント駆動型アーキテクチャ (EDA) は、本質的にアプリケーション/コンポーネント間の統合アーキテクチャ パターンです。イベントは従来のメッセージとは異なり、スキーマを持っているため、イベントの正当性を検証することができ、同時に QoS 保証メカニズムを備えており、イベント処理の失敗にも対応できます。
イベント駆動型アーキテクチャは、(マイクロ) サービスの分離に使用されるだけでなく、次のシナリオにも適用できます。
1||| サービスの回復力を強化する
サービスは非同期で統合されるため、下流での処理の失敗やダウンタイムさえも上流では認識されず、当然ながら上流に影響を与えることはありません。
2||| CQRS (Command Query Responsibility Segregation、コマンドクエリ責任分離)
サービスのステータスに影響を与えるコマンドはイベントを使用して開始されますが、サービスのステータスに影響を与えないクエリは、EDA のイベント ソーシング メカニズムと組み合わせて同期的に呼び出される API インターフェイスを使用して、一貫性を維持することができます。サービス状態では、EDA でイベントを再度「再生」するだけです。
3||| データ変更通知
サービス アーキテクチャでは、多くの場合、1 つのサービスのデータが変更されると、他のサービスが関心を持ちます。たとえば、ユーザーの注文が完了した後、ポイント サービス、クレジット サービスなどにイベントを通知し、ユーザー ポイントとクレジット レベルを更新する必要があります。 。
4||| オープンなインターフェースを構築する
EDA では、サービス呼び出しとは異なり、イベント プロバイダーはサブスクライバーを気にする必要がありません。データ プロデューサーはデータ コンシューマーがどこにあるかを知ってそれを呼び出す必要があるため、インターフェイスのオープン性が維持されます。
5||| イベントストリーム処理
(個別のイベントではなく) 多数のイベント ストリームのデータ分析シナリオに適用される典型的なアプリケーションは、Kafka に基づくログ処理です。
6||| イベントトリガーの応答
IoT時代には、人間とコンピュータのインタラクションのように、多数のセンサーによって生成されたデータが処理結果の返却を待つ必要がなくなり、EDAを使用してデータ処理アプリケーションを構築することが当然適しています。
VI. クラウドネイティブの場合
i. 急成長を遂げている物流組織の 1 つである宅配会社は、コストを削減し効率を向上させるために、技術革新を通じてビジネスの成長を促進する方法を積極的に模索してきました。現在、同社の毎日の注文処理量は数千万件に達し、物流トラックの処理量は数億件に達しており、毎日生成されるデータは TB レベルに達し、1,300 個のコンピューティング ノードを使用してリアルタイムにビジネスを処理しています。 。以前は、同社のコア ビジネス アプリケーションは IDC コンピュータ ルームで実行されていました。オリジナルの IDC システムは、同社が急速なビジネス展開の初期段階を安定的に乗り切るのに役立ちました。しかし、ビジネス量の急激な増加に伴い、ビジネス形態もますます多様化しています。元のシステムでは、従来の IOE アーキテクチャ、各システム アーキテクチャの不規則性、安定性、研究開発効率などのすべてが、迅速なビジネス展開の可能性を制限していました。ソフトウェアの配信サイクルが長すぎる、大規模なプロモーションのための特別なリソース要件を達成するのが難しい、システムの安定性を保証するのが難しいなど、ビジネス上の問題が徐々に明らかになります。クラウド サービス プロバイダーとの複数の要求のコミュニケーションと技術検証を経て、同社は最終的に中核ビジネスをクラウドに移行するためのクラウド ネイティブ テクノロジとアーキテクチャを決定しました。
ii. 解決
1. クラウドネイティブデータベースの導入
OLTP データベースと OLAP データベースの導入により、オンライン データとオフライン分析ロジックが 2 つのデータベースに分割され、Oracle データベースに完全に依存していた以前の現状が変わります。履歴データのクエリを処理するシナリオで、Oracle データベースによってサポートされる実際のビジネス要件の欠点を満たします。
2. アプリケーションのコンテナ化
コンテナ化テクノロジーの導入により、一貫性のない環境の問題はアプリケーションのコンテナ化によって効果的に解決され、開発、テスト、実稼働環境におけるアプリケーションの一貫性が確保されています。仮想マシンと比較して、コンテナ化により効率と速度が二重に向上し、アプリケーションがマイクロサービス シナリオにより適したものになり、生産と研究の効率が効果的に向上します。
3. マイクロサービスの変革
これまでのビジネスの多くはOracleのストアドプロシージャやトリガーをベースに完結していたため、システム間のサービスの依存関係によりOracleデータベースのOGG（Oracle Golden Gate）も同時に完結する必要がありました。これにより生じる問題は、システムの保守が困難であり、安定性が低いことである。 Kubernetesサービスディスカバリを導入することで、マイクロサービスソリューションを構築し、業務ドメインごとに事業を分割できるため、システム全体の保守が容易になります。
iii. 体制の確立
特定の宅配便会社の実際のビジネス ニーズと技術的特性を考慮して、その会社が決定したクラウド アーキテクチャを図 4-3 に示します。
（1） インフラストラクチャー
すべてのコンピューティング リソースは、クラウド サービス プロバイダーのベア メタル サーバーから取得されます。 Kubermetes は、一般的なクラウド サーバー (ECS) と比較して、サーバーと組み合わせることで優れたパフォーマンスとより合理的なリソース使用率を実現できます。さらに、クラウド リソースはオンデマンドで取得できるため、プロモーション活動などの短期的に高トラフィックのビジネス シナリオを扱う企業にとっては非常に重要です。オフラインの自作コンピューター室や常設マシンと比較して、クラウドリソースはすぐに利用できます。プロモーションイベント終了後はクラウドリソースを使用後に解放できるため、管理コストや調達コストを削減できます。
（2） 交通アクセス
クラウド サービス プロバイダーは、2 セットのトラフィック アクセスを提供します。1 つはパブリック ネットワーク リクエスト用で、もう 1 つは内部サービス呼び出し用です。ドメイン名解決にはクラウド DNS と PrivateZone を使用します。 Kubernetes の Ingress 機能を使用して統一ドメイン名転送を実現し、パブリック ネットワーク SLB の数を節約し、運用と保守の管理効率を向上させます。
（3） プラットフォーム層
Kubernetes 上に構築されたクラウドネイティブ PaaS プラットフォームには、次のような明らかな利点があります。
1||| DevOps のクローズド ループを開き、テスト、統合、プレリリース、運用環境を統合します。
2||| 自然なリソースの分離と高いマシン リソースの使用率。
3||| トラフィックアクセスにより、洗練された管理が可能になります。
4||| 統合されたログ、リンク診断、およびメトリクス プラットフォーム。
5||| API サーバーのインターフェイスと拡張機能を統合して、マルチクラウドおよびハイブリッド クラウドの展開をサポートします。
（4） アプリケーションサービス層
各アプリケーションは Kubernetes 上に個別の名前空間を作成し、アプリケーション間でリソースの分離が実現されます。各アプリケーションの構成 YAML テンプレートを定義すると、アプリケーションのデプロイ時にその中のイメージ バージョンを直接編集して、バージョン アップグレードを迅速に完了できます。ロールバックが必要な場合は、イメージの履歴バージョンをローカルで直接起動して、迅速にロールバックできます。 。
（5） 運用保守管理
オンライン Kubernetes クラスターは、クラウド サービス プロバイダーのホスト型バージョンのコンテナー サービスを使用するため、マスター ノードの運用と保守の必要がなく、ワーカー ノードのオンライン プロセスとオフライン プロセスを作成するだけで済みます。同時に、ビジネス システムは Alibaba Cloud の PaaS プラットフォームを通じてビジネス ログの検索を完了し、ビジネス ニーズに応じて拡張タスクを送信します。システムは拡張操作を自動的に完了するため、Kubernetes クラスターの直接運用によって生じるビジネス リスクが軽減されます。
iv. アプリケーションの利点
1. 料金
クラウド製品はすべてクラウド上で自己ホストされており、運用や保守が不要なため、手動による運用や保守のコストが効果的に節約され、企業はコアビジネスにさらに集中できるようになります。
2. 安定性
クラウド製品は、システムの安定性を確保するために少なくとも 5 つの 9 (99.999%) SLA サービスを提供しますが、自社構築システムの安定性ははるかに高くなります。データセキュリティの観点では、クラウド上のデータをオフサイトに簡単にバックアップできるクラウドサービスプロバイダーのデータストレージシステムのアーカイブストレージ製品は、高信頼性、低コスト、セキュリティ、無制限のストレージという特徴を備えており、エンタープライズデータを作成します。より安全です。
3. 効率
クラウド製品との緊密な統合により、研究開発担当者は研究開発、運用、保守作業をワンストップで完了できます。ビジネス要件の確立からプル ブランチ開発、テスト環境機能の回帰検証、そして最終的にリリース前検証とオンラインへの展開に至るまで、継続的統合プロセス全体を数分に短縮できます。トラブルシューティングに関しては、研究開発担当者が担当するアプリケーションを直接選択し、統合された SLS ログ コンソールを通じてプログラムの例外ログを迅速に取得して問題を特定できるため、ログを確認するためにマシンにログインする必要がなくなります。
4. ビジネスを強化する
クラウド サービス プロバイダーは、コンピューティング、AI、ビッグデータ、IoT をカバーする 300 種類を超えるクラウド コンポーネントを提供します その他多くの分野。研究開発担当者は箱から出してすぐに使用できるため、ビジネス革新によってもたらされる技術コストを効果的に節約できます。