出題範囲
- 移行/統合/テスト
- 非機能要件/品質属性
- 性能/可用性/信頼性設計
- 要求分析/要件定義
- アーキテクチャ/構成設計
- デプロイ（コンテナ/オーケストレーション/CI-CD）
- 要求/品質特性（ISO/IEC 25010）
- データ/統合/メッセージング/API
- アーキテクチャスタイル（レイヤ/マイクロサービス/EDA）
- 非機能（性能/拡張性/信頼性/可用性）
- 移行/テスト戦略/リリース計画
例題に挑戦
スキルサートのAIが生成した演習問題のサンプルです。アプリでは毎週新しい問題が追加されます。
例題1
RESTful APIの設計において、リソースの操作に用いるHTTPメソッドの適切な使い分けに関する記述として、最も適切なものはどれか。
- POSTはべき等性が保証される必要があるが、PUTは保証しなくてよい。
- PATCHはリソースの完全な置換に、PUTは部分的な更新に用いる。
- PUTはリソースの置換、または指定した識別子での新規作成に用いる。
- DELETEメソッドは、必ずレスポンスボディに削除した全データを返却しなければならない。
- GETはリソースの更新に、POSTはリソースの取得に用いる。
解答と解説を見る
正解: PUTはリソースの置換、または指定した識別子での新規作成に用いる。
正解は「PUTはリソースの置換、または指定した識別子での新規作成に用いる。」です。RESTful APIにおいて、PUTメソッドはリソースの全体を更新（置換）するか、クライアントがURIを指定して新規作成する場合に使用されます。これに対し、POSTは通常、サーバ側でIDを生成する新規リソースの作成に使用され、べき等性は保証されません。GETはリソースの取得、DELETEはリソースの削除、PATCHはリソースの一部更新に用いられます。PUTやDELETE、GETはべき等性（同じ操作を繰り返しても結果が変わらない性質）を持つように設計することが原則です。
例題2
データ統合技術の一つであるCDC（Change Data Capture）を導入するメリットとして、最も適切なものはどれか。
- ファイル転送方式に比べ、ネットワークの帯域消費を大幅に増大させることができる。
- システム間の全データを常に比較するため、不整合を即座に修正できる。
- バッチ処理時間を短縮できるが、ソースDBへの直接負荷はETLより大きくなる。
- データベースの更新内容をリアルタイムに近い形で抽出し、転送負荷を軽減できる。
- API経由での取得に限定されるため、データベースのログを参照する必要がない。
解答と解説を見る
正解: データベースの更新内容をリアルタイムに近い形で抽出し、転送負荷を軽減できる。
正解は「データベースの更新内容をリアルタイムに近い形で抽出し、転送負荷を軽減できる。」です。CDCはデータベースの更新ログ（ログベースCDC）などを監視し、変更された差分データのみを抽出して他システムに反映する手法です。全件データを転送するフルダンプ方式に比べてネットワーク負荷が低く、リアルタイム性の高いデータ統合が可能です。ソースDBへのクエリ負荷も抑えられるため、稼働中の基幹システムから分析基盤へデータを同期する際などに広く利用されています。
重要用語
- スループット
- 単位時間あたりにシステムが処理できる仕事量のことです。システム全体の処理能力を示す重要な指標であり、オンライン処理では1秒あたりのトランザクション数（TPS）、バッチ処理では時間あたりのジョブ数などで評価されます。アーキテクトは、ネットワーク帯域やCPU性能、ディスクI/Oなどを総合的に考慮し、目標とするスループットを維持できるよう設計する必要があります。
- レスポンスタイム
- ユーザがシステムに対して処理を要求してから、システムが最初の応答を返すまでにかかる時間のことです。利用者の利便性に直結する指標であり、ネットワークの遅延、サーバ内での処理時間、データベースの検索時間などの合計で決まります。ターンアラウンドタイムが処理完了までの時間であるのに対し、レスポンスタイムは最初の反応に焦点を当てた指標である点に注意が必要です。
- MTBF (Mean Time Between Failures)
- 平均故障間隔のことで、システムが故障せずに正常に動作している時間の平均値です。この値が大きいほど、システムの信頼性が高いことを示します。可用性を高めるためには、高品質な部品の採用や冗長構成の導入によってMTBFを長くすることが重要です。試験では、MTTR（平均修復時間）と組み合わせて稼働率を算出する計算問題が頻出するため、計算式を理解しておく必要があります。
- MTTR (Mean Time To Repair)
- 平均修復時間のことで、システムが故障してから復旧するまでにかかる時間の平均値です。この値が小さいほど、保守性が高いことを示します。可用性を向上させるためには、障害の検知を早める、遠隔操作を可能にする、予備機への切り替えを自動化するなどの対策により、MTTRを短縮することが求められます。MTBFと並んで、システムの可用性管理において不可欠な指標です。
- 稼働率
- システムが一定期間のうち、実際に稼働していた時間の割合を示す指標です。計算式は「MTBF / (MTBF + MTTR)」で表されます。システム全体の信頼性を評価する際に用いられ、直列構成では各要素の稼働率の積となり、並列構成では1から全要素が故障する確率を引くことで求められます。アーキテクトは、要求されるサービスレベルに応じて最適な構成を検討し、目標稼働率の達成を目指します。
- フェイルセーフ
- システムに故障や誤操作が発生した際、常に安全な状態（停止など）に制御する設計思想です。例えば、踏切の遮断機が故障した際に重力で降りる仕組みなどが該当します。ITシステムにおいては、一部の機能に異常が生じた際、システム全体が制御不能に陥るのを防ぎ、データの整合性を保ちながら安全に停止させることが求められます。利用者の安全やデータの保護を最優先する考え方です。
- フェイルソフト
- システムの一部に障害が発生した際、故障箇所を切り離し、機能を制限してでも処理を継続させる設計思想です。これを「縮退運転」とも呼びます。例えば、複数台のサーバで構成されるシステムで1台が故障しても、残りのサーバで処理を続ける形態です。全機能停止による機会損失を防ぐために重要であり、可用性を重視するシステムにおいて不可欠なアプローチです。
- スケーラビリティ
- システムの規模や負荷の増大に対して、柔軟に性能を拡張できる能力のことです。サーバの台数を増やす「スケールアウト」と、個々のサーバのスペックを上げる「スケールアップ」の2つの手法があります。将来的な利用者の増加やデータ量の拡大を予測し、設計段階からボトルネックを排除しておくことで、低コストかつ迅速にシステムを拡張できるようなアーキテクチャが求められます。
システムアーキテクト試験の対策はアプリで
AIが毎週生成する新作問題・ランクマッチ・週次ランキング・AI診断で「続けられる」資格学習を。無料で始められます。
