Instiq

システムアーキテクト試験 のナレッジマップ

システムアーキテクト試験 の主要概念 42 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧(42)

  • 結合度(coupling)

    モジュール間の依存の強さを表す尺度で、低いほど良い設計とされる。強い順(悪い順)から内容結合>共通結合>外部結合>制御結合>スタンプ結合>データ結合で、データ結合(必要なデータだけを引数で渡す)が最も望ましい。良い設計は高凝集かつ低結合であり、システムアーキテクトはインタフェースを最小化して変更の波及を局所化する設計判断を下す。

    前提: 凝集度(cohesion)

  • 要件定義

    システム開発の上流工程で、利用者・発注者が求める機能や性能を明確にし、開発対象の範囲を確定する工程。ここでの認識齟齬は後工程の手戻りに直結するため特に重要。

  • クライアントサーバシステム(3層クライアントサーバ)

    機能をサービスを要求するクライアントと提供するサーバに分担させる分散処理形態。3層クライアントサーバでは画面表示を担うプレゼンテーション層、業務ロジックを担うファンクション(アプリケーション)層、永続化を担うデータ層に分離し、各層を独立に配置・増強できる。システムアーキテクトは負荷特性やセキュリティ境界に応じて層をどのマシンへ配置するかを設計判断する。

    前提: 集中処理と分散処理

  • 垂直分散と水平分散

    垂直分散(機能分散)は層や機能ごとに別マシンへ役割を分けて配置する方式で、プレゼンテーション用とデータベース用を分けるなど機能単位の独立性を高める。水平分散(負荷分散)は同一機能を担うマシンを複数複製し、負荷分散装置で処理要求を振り分けて処理能力と可用性を高める。両者を組み合わせて拡張性を設計するのがアーキテクトの典型的判断である。

    前提: ロードバランサ(L4/L7)スループット

  • 稼働率

    システムが正常に稼働している時間の割合。稼働率=MTBF÷(MTBF+MTTR) で求められ、故障間隔が長く修復時間が短いほど高くなる。可用性の代表指標で、SLA の合意値(例 99.9%)としても用いる。

    前提: 平均故障間隔(MTBF)

  • 非機能要件

    機能そのものではなく、性能・可用性・セキュリティ・保守性など、システムの品質面に関する要件。要件定義で機能要件と併せて明確にしておく必要がある。

    前提: 要件定義

  • スループット

    単位時間当たりにシステムが処理できる仕事量を表す性能指標で、1秒当たりの処理件数(トランザクション/秒)やデータ転送量(バイト/秒)などで表す。同時処理数やハードウェア資源の増強、ボトルネックの解消によって向上する。システムアーキテクトはピーク時の要求スループットを見積もり、それを満たす構成と余裕(キャパシティ)を設計する。

  • E-R図(実体関連図)

    データベース設計において、実体(エンティティ)とその間の関連(リレーションシップ)を図で表現する概念モデリング手法。実体間の多重度(1対1・1対多・多対多)を明示し、論理データベース設計や正規化の前段階として用いられる。

  • UML(統一モデリング言語)

    オブジェクト指向のシステム設計・分析結果を統一的な記法で図示するための標準化されたモデリング言語。静的な構造を表すクラス図、システムと利用者の相互作用を表すユースケース図、オブジェクト間のメッセージのやり取りを時系列で表すシーケンス図など、目的に応じた複数の図種を持つ。

    前提: ユースケース図

  • 平均故障間隔(MTBF)

    修理して使い続けるシステムで、ある故障から次の故障までの平均稼働時間。値が大きいほど故障しにくく信頼性が高い。総稼働時間÷故障回数で算出する。

  • ロードバランサ(L4/L7)

    複数サーバへ負荷を分散する装置。L4ロードバランサはIPアドレスとポート番号までで振り分ける。L7ロードバランサはHTTPのURLパスやCookie等アプリケーション層の情報を解釈でき、パスベースの振り分けやCookieによるセッション維持(パーシステンス)を実現する。ヘルスチェックで異常サーバを自動的に振り分け対象から除外する。

  • 集中処理と分散処理

    集中処理は1台の中核システムに処理とデータを集約する方式で、管理・整合性維持が容易な反面、その1台が単一障害点となり性能上限にも縛られる。分散処理は複数ノードに処理を分けて可用性と拡張性を高めるが、通信・整合性・運用が複雑化する。システムアーキテクトは信頼性要件とコスト、運用体制を勘案して両者の配分を設計する。

  • クラスタリング(HAクラスタ・負荷分散クラスタ)

    複数のサーバを相互に連携させ、利用者からは1つのシステムとして見えるよう束ねる技術。HA(高可用性)クラスタは一部ノードが障害でも他ノードへフェールオーバーして稼働を継続することを目的とし、負荷分散クラスタは要求を複数ノードに振り分けてスループットと同時処理能力を高めることを目的とする。システムアーキテクトは可用性要求か性能要求かに応じて構成を選び、共有ディスクの有無やスプリットブレイン対策を設計する。

    前提: フェールオーバーとフェールバックスループット垂直分散と水平分散

  • オーケストレーションとコレオグラフィ

    マイクロサービス連携の2つの制御様式。オーケストレーションは中央の指揮役(オーケストレータ)が各サービスを順に呼び出して全体フローを統制する方式で、流れが把握しやすい反面その指揮役に依存が集中する。コレオグラフィは中央制御を置かず、各サービスがイベントを発行・購読して自律的に連携する方式で、疎結合になる反面全体像の追跡が難しくなる。

    前提: 結合度(coupling)

  • ポリグロットパーシステンス

    データの特性ごとに最適なデータストアを使い分ける考え方。強い整合性・結合が要る業務データはRDB、単純な高速参照はKVS、階層的な文書は文書データベース、関係の探索はグラフデータベースというように用途で選ぶ。単一DBに無理に押し込めない代わりに、複数ストア間の整合性維持や運用コストの増加をアーキテクトが引き受ける判断になる。

    前提: ドキュメント指向データベースKVS(キーバリューストア)

  • CI/CD

    CI(継続的インテグレーション)はコード変更のたびに自動ビルド・自動テストを行い早期に不具合を検出する手法。CDには2つの意味があり、継続的デリバリーは本番リリースの直前まで(リリース可能な状態まで)を自動化し本番反映は手動承認を残す方式、継続的デプロイメントは本番反映まで全て自動化する方式を指す。

  • DevOps

    開発(Development)と運用(Operations)が密接に連携し、自動化やCI/CDを活用して、より速く継続的にソフトウェアを提供しようとする考え方・文化。

    前提: CI/CD

  • 仮想化

    1台の物理的なコンピュータ上に、複数の仮想的なコンピュータ(仮想マシン)をソフトウェア的に作り出す技術(サーバ仮想化)。ストレージ・ネットワーク・デスクトップなども同様に仮想化できる。ハードウェア資源を効率的に活用でき、集約や柔軟な構成変更が可能になる。

  • 平均修復時間(MTTR)

    故障が発生してから復旧するまでの平均時間。値が小さいほど早く復旧でき、保守性(メンテナンス性)が高い。総修復時間÷故障回数で算出する。稼働率=MTBF÷(MTBF+MTTR) の分母に含まれ、MTBF(平均故障間隔)と対にして信頼性・保守性を評価する。

    前提: 稼働率平均故障間隔(MTBF)

  • アーキテクチャパターン

    システム全体の構造に関して繰り返し現れる問題への、再利用可能な解決の型。レイヤ、クライアントサーバ、イベント駆動、マイクロサービス、パイプフィルタなどが代表例で、それぞれ長所短所と適用文脈をもつ。デザインパターンがクラス・オブジェクト粒度の設計を扱うのに対し、アーキテクチャパターンはより粗い全体構造を扱い、アーキテクトが品質特性の要求に照らして選択する。

    前提: クライアントサーバシステム(3層クライアントサーバ)デザインパターン(GoFパターン)

  • 凝集度(cohesion)

    一つのモジュール内の要素がどれだけ単一の目的に向けてまとまっているかを表す尺度で、高いほど良い設計とされる。弱い順から暗合的凝集<論理的凝集<時間的凝集<手続的凝集<通信的凝集<逐次的凝集<機能的凝集で、機能的凝集(単一の機能だけを担う)が理想である。システムアーキテクトはモジュール分割時に各モジュールが高凝集となるよう責務を整理し、保守性と再利用性を高める判断を行う。

    関連: モジュール分割技法(STS分割・TR分割・共通機能分割)

  • デザインパターン(GoFパターン)

    オブジェクト指向設計で繰返し現れる問題への再利用可能な解法を類型化したもので、GoF(Gang of Four)が23個を整理した。生成に関するパターン(Creational=Factory Method、Singleton、Builder など)、構造に関するパターン(Structural=Adapter、Facade、Proxy など)、振る舞いに関するパターン(Behavioral=Observer、Strategy、State など)の三分類から成る。システムアーキテクトは共通語彙として設計意図を伝え、実績ある構造で品質と保守性を確保する。

  • データ中心アプローチ(DOA)

    処理よりも変化しにくいデータの構造を安定した基盤に据えて情報システムを設計する方法論。業務で扱うデータをE-R図などでモデル化して正規化し、そのデータモデルを土台に処理機能を組み立てる。処理は業務変更で頻繁に変わるが、データ構造は比較的安定しているという前提に立ち、システムアーキテクトが長期的に保守しやすいデータ資産を築く際の基本方針となる。

    前提: E-R図(実体関連図)

  • レイヤードアーキテクチャ(3層アーキテクチャ)

    ソフトウェアの責務を層に分割し、上位層は原則として直下の層のみに依存させる構造パターン。関心の分離により保守性・可換性・テスト容易性が高まり、ある層の実装差し替えが他層に波及しにくい。プレゼンテーション・ビジネスロジック・データアクセスの3層構成が代表例で、物理的なクライアントサーバの3層配置とは概念が異なる点に注意する。

    前提: クライアントサーバシステム(3層クライアントサーバ)

  • モジュール分割技法(STS分割・TR分割・共通機能分割)

    プログラムを保守しやすい単位に分割する代表的手法群。STS分割はデータフロー図の最大抽象入力点と最大抽象出力点で源泉(Source)・変換(Transform)・吸収(Sink)の三つに分ける手法、TR分割は入力の種別(トランザクション)ごとに処理を振り分ける手法、共通機能分割は複数箇所で共用される機能を独立モジュールとしてくくり出す手法である。システムアーキテクトは処理特性に応じてこれらを使い分け、高凝集・低結合の構造を導く。

    前提: 結合度(coupling)

    関連: 凝集度(cohesion)

  • Sagaパターン(補償トランザクション)

    サービスごとにデータベースが分かれるマイクロサービスで、複数サービスにまたがる更新を一貫させるためのパターン。全体を1つのACIDトランザクションにせず、各サービスのローカルトランザクションを連鎖させ、途中で失敗したら実行済みの処理を打ち消す補償トランザクションを逆順に走らせて結果整合性を保つ。実装には中央のオーケストレータが各ステップを指示するオーケストレーション型と、各サービスがイベント連鎖で自律的に進むコレオグラフィ型の2方式がある。分散トランザクションの2相コミットを避けたい設計で採用される。

    前提: オーケストレーションとコレオグラフィ

  • ユースケース図

    UMLの図の一つで、システムが外部に提供する機能(ユースケース)と、それを利用する人や外部システム(アクター)との関係を表す。アクターを人型、ユースケースを楕円で描き、両者を線で結んでシステム境界を明示し、include(包含)やextend(拡張)で関係を補足する。システムアーキテクトが要求分析の初期に利用者視点で機能範囲を合意し、スコープを可視化する目的で用いる。

  • コンテナ仮想化

    ホストOSのカーネルを複数のアプリケーション実行環境(コンテナ)で共有し、プロセスやファイルシステムを名前空間で隔離する軽量な仮想化方式。ゲストOSを持つハイパーバイザ型仮想化と比べ、起動が高速でオーバーヘッドが小さい一方、ホストOSのカーネルに依存するため異なるOS種別のカーネルは動かせない。Dockerが代表的な実装。

    前提: 仮想化

  • ドキュメント指向データベース

    JSON のような半構造化ドキュメント単位でデータを格納する NoSQL のモデル。ドキュメントごとに異なる項目を持てる柔軟なスキーマが特徴で、階層的・可変的な構造のデータに向く。

  • KVS(キーバリューストア)

    キーと値の組だけでデータを管理するシンプルな NoSQL データモデル。スキーマレスで水平スケールしやすく、セッション管理やキャッシュなど読み書きが単純で高速性が求められる用途に向く。

  • ウォーターフォールモデル

    要件定義・設計・実装・テストといった各工程を順番に進め、原則として前工程には戻らないという前提で開発する手法。計画が立てやすい一方、途中の仕様変更には弱い。

    前提: 要件定義

  • アクティビティ図

    UMLの振る舞い図の一つで、業務や処理の一連の流れをアクション(丸角の箱)の連なりとして表す。分岐・合流や並行処理(フォーク/ジョイン)を表現でき、スイムレーンで担当者や役割ごとに処理を区分できるため、業務フローや処理手順のモデル化に適する。1つのオブジェクトの状態変化を表す状態遷移図とは目的が異なる。

    前提: 状態遷移図(ステートマシン図)

  • コンポーネント図

    UMLの構造図の一つで、システムを構成する物理的なソフトウェア部品(コンポーネント)と、それらが提供・要求するインタフェースおよび依存関係を表す。提供インタフェース(ボール)と要求インタフェース(ソケット)で部品間の結合を示し、再利用単位や配置単位の分割を検討できる。実行時のノード配置を表す配置図とは対象が異なる。

    前提: 結合度(coupling)

  • デッドロック

    複数のプロセスやトランザクションが互いに相手の保持する資源の解放を待ち合い、いずれも処理を進められなくなる膠着状態。相互排他・保持と待機・横取り不可・循環待ちの4条件が同時に成立すると発生し、資源獲得順序の統一による予防、資源要求のスケジューリングによる回避、待機グラフの監視による検出と一方のロールバックといった対策がある。システムアーキテクトはロック粒度と獲得順序を設計してデッドロックを抑止する。

    前提: ロールバックとチェックポイント(リカバリ)

  • フェールオーバーとフェールバック

    フェールオーバーは主系に障害が生じたとき、処理を自動的に待機系へ切り替えて可用性を維持する仕組み・動作を指す。フェールバックは主系が復旧した後、待機系で継続していた処理を本来の主系へ戻すことをいう。システムアーキテクトはフェールオーバー時のデータ整合性やセッション引継ぎ、フェールバック時の再切替に伴う瞬断を設計上考慮する。

  • ジャクソン法(JSP)

    入力データ構造と出力データ構造を基準にプログラム構造を導くプログラム設計技法(Jackson Structured Programming)。データを順次・選択・繰返しの三つの基本構造でモデル化し、入出力のデータ構造からプログラムの制御構造を機械的に対応づけて設計する。データ構造が処理構造を規定するという考え方に立ち、システムアーキテクトが構造的な妥当性を保証しやすい点が特徴である。

  • 非機能要求グレード

    IPAが公開する、可用性・性能/拡張性・運用保守性・移行性・セキュリティ・システム環境/エコロジーといった非機能要求を、発注者と受注者が段階的なグレードとして具体的に合意するための体系・ツール群。抽象的で見落とされやすい非機能要求を項目とレベルで可視化し、要求水準の認識齟齬やコスト見積りの食い違いを防ぐ。システムアーキテクトはこれを用いて非機能要求を漏れなく引き出し、アーキテクチャ設計の前提として確定させる。

    前提: 非機能要件

  • プロセス中心アプローチ(POA)

    業務の処理機能(プロセス)を中心に情報システムを分析・設計する方法論。DFD(データフロー図)などで機能を段階的に分割し、各機能が扱う入出力を定めていく。機能の変化にデータ構造が引きずられやすく保守性で不利になりがちで、データ構造を安定基盤とするデータ中心アプローチ(DOA)と対比される。システムアーキテクトは対象業務の性質に応じて両者を使い分ける判断を行う。

    前提: データ中心アプローチ(DOA)

  • ロールバックとチェックポイント(リカバリ)

    ロールバックは、トランザクションの障害時にその開始前の状態へデータを戻して整合性を保つ回復操作。チェックポイントは、メモリ上の更新を定期的にディスクへ反映して整合の取れた基準点をログに記録するもので、障害時にはこのチェックポイント以降のログだけを用いてロールフォワード(前進復旧)することで復旧時間を短縮できる。システムアーキテクトはチェックポイント間隔とログ運用を、性能と目標復旧時間の両立から設計する。

  • 共通フレーム(SLCP)

    ソフトウェアの企画から開発・運用・保守・廃棄に至るライフサイクル全体の作業内容と用語を共通化し、発注者と受注者が同じ理解で取引できるようにした「ものさし」となる枠組み(SLCP-JCF、共通フレーム)。個々の作業をプロセス・アクティビティ・タスクとして体系化し、契約範囲や責任分担を明確化するが、具体的な作業手順や方法論そのものは規定しない。システムアーキテクトは要件定義や設計の取引・分担を共通フレームの用語で整理し、認識齟齬を防ぐ。

    前提: 要件定義

  • 状態遷移図(ステートマシン図)

    1つのオブジェクトやシステムが取りうる状態と、イベントによって状態から状態へ移る遷移を表す図。遷移にはトリガとなるイベント、成立条件(ガード条件)、実行される動作を対応づけられ、状態依存の振る舞いを漏れなく定義できる。取りうる状態が有限で明確な制御対象(組込み制御や注文の進行など)のモデル化に適する。

  • ワーニエ法

    入力データ構造に着目し、集合論的な観点からプログラム構造を導く設計技法。データが「いつ・どこで・何回」現れるかを繰返しの入れ子として括弧で階層的に表現し、順次・選択・繰返しの3つの制御構造を組み合わせてプログラムをトップダウンに組み立てる。入力と出力の両データ構造の対応を扱うジャクソン法と対比される。システムアーキテクトがデータ構造主導で処理を設計する際に用いる。

    前提: ジャクソン法(JSP)