・アプリケーション構成 アプリケーションで必要な機能を論理的な役割(階層)に分割する。 開発する単位を明確化する。
・ 階層(レイヤー)の設定 ・業務要件から機能を論理的な役割に分割する。 ・分割することで実装範囲(設計対象)を整理する。 3層アーキテクチャの例を記す。
 ・ レイヤーの実装方針、レイヤー間インタフェース 実装方針と受け渡しのインタフェースが決定することで アプリケーションとしての処理フロー(抽象化版)が明らかにする。 ・レイヤーの分割を決めたら、各レイヤーの実装方針を検討する。 (適用する技術、ミドルウェア指定等) - レイヤー間の受け渡し方法(インタフェース)を取り決める。 レイヤー間インタフェースの検討ポイントを記す。  ・実行形態の分類 オンライン処理、バッチ処理が担う範囲を定義する。 例) 実行形態の分類例 ・オンライン:ユーザがWEBアプリケーションの画面を介して対話する形式 ・バッチ:スケジューラによりバックグラウンド(利用者と対話しない)で実行する形式 ・オンラインバッチ:ユーザがWEBアプリケーションの画面で非同期バッチ処理の実行を指示
・ トランザクション(データ更新)管理 システムで取り扱うデータの整合性が保てるように、 トランザクションデータ更新のルールを決める。 ・トランザクション管理、リランの考え方 処理においてデータ不整合が起きないようにトランザクションのスコープを決定する。 障害発生、異常終了時においてもデータ不整合を保つ仕組みを検討する。 業務におけるデータ状態遷移からUMLシーケンス図を用いるなどをして設計する。 トランザクションのスコープの例を記す。 ・オンラインアプリケーション : ロジック層の入口~出口まで。失敗時は元に戻すことで整合性を保つ。 ・バッチアプリケーション : ケース1: 1バッチ1トランザクションとする。単純リランを可能にするため。 ケース2: 一定の処理件数で分割する。再実行時間を短縮するため。
・データ更新時のロック制御 同一データソースに対して同時更新が発生する場合に データ整合性を保つための仕組みを設計する。 ・データベースで提供するロック機能採用による業務機能への弊害の有無 - 参照から更新までに時間がかかる処理があり、他の処理が更新待ちにならないか? - システム的な更新制御では、タイミングにより上書きが発生されないか?
・更新制御の仕組み・ルールの導入 例)”楽観的ロック”の採用 - 制御用項目(シリアル番号や更新日時)により、更新前後の状態をチェック →同時に他の更新がないことを確認する - ロックの単位を決定する。行単位・テーブル単位等。
・性能確保の方針 性能要件に対して、当該アプリケーションアーキテクチャでの実現方法を設計する。 ・性能劣化を起こす場所と要の因洗い出し 性能劣化を起こす可能性がある箇所とその要因を洗い出す。 システム化要件と前述で考えたレイヤーに対して次の視点で洗い出す。 ・オンラインアプリケーション:レスポンスタイム、スループット ・バッチアプリケーション :ターンアラウンドタイム ・サーバ/ストレージ/ネットワーク: リソース利用
・実現方法(対応策、また性能劣化時の処置方法を設計する) 対応策を例示する。 ・分散処理 - 水平分散:同じ処理を行うサーバを複数用意する。 - 垂直分散:処理内容により処理するサーバを振り分ける。 ・キャッシュの利用 - メモリ上にデータや定義情報を保持することで物理I/Oを減らす。 ・非同期処理 – メッセージキュー等を利用して非同期で処理を行う。 (処理を完結する前に見せかけ上のレスポンスを返す) ・リソース拡張(スケーラビリティ) - システム運用中にリソース追加が出来る仕組みにする。
・可用性の方針 可溶性に対して当該アプリケーションアーキテクチャでの実現方法を設計する。 ・可用性を高める必要がある箇所の洗い出し システム化要件と前述で考えたレイヤーから、可用性が必要な業務を特定する。 それに関連する機能を洗い出す。
・実現方法(対応策と、復旧方法(発生前状態への戻し)を設計する。) ・冗長化 (Active-Active構成、Active-Standby構成) どのレイヤー(ハードウェア/ミドルウェアも含む)で冗長化を実現させるか。 ・状態引継ぎ: 縮退発生時にどこまで事前状態を引き継ぐ必要があるか。(システム、データ) ・正常状態への戻し どのように戻すか(システム停止(運用への影響)の可否・要否確認 など)
・例外の取り扱い システム不具合や業務エラーが発生した際の処理を設計する。 ・例外の分類と取り扱い 不具合が発生するケースを洗い出し、その際に実施中の処理の扱いを検討する。 -エラーケース ・ 業務エラー:業務シナリオ上のエラーケースなどの業務上のエラー ・ システムエラー:ハードウェア障害、製品バグなどのシステム面でのエラー -例外発生後の処理(トランザクション)の扱い ・ロールバックして例外扱い ・ロールバックせずに例外扱い ・例外扱いにしない
・例外処理の方法 例外発生の検知から処理終了までを設計する。 ・ロールバック機能を実装する箇所 ・エラーの表示方法(画面の要否、画面遷移等) ・ログ(エラーメッセージ)出力イメージ
・セキュリティの確保 アプリケーションのセキュリティとして実装すべきことを設計する。 ・認可・認証 利用者のアクセス権の制御(認可)、利用者本人の特定(認証)について設計する。 -認証の仕組み: 認証に必要な情報と特定(判断)の仕方 -認可の仕組み: 認証された情報を元にアクセス権の制御の仕方
・ロール管理 システムユーザーに割り当てる機能・アクセスできる情報の利用範囲を定義する。 その情報の管理方法を設計する。 ・役割(ロール)の定義 … システムを利用するユーザに必要な役割は何か? ・各ロールの範囲 ・ロールの管理方法(ユーザ画面でメンテナンスする等)
・セッション管理 ステートレスなサーバ通信の処理の中で共有する情報(セッション)の管理方法を設計する。 セッションIDの入手による乗っ取りや成りすましを排除する。 ・セッションIDの発行方法 ・セッションIDの受渡方法 ・共通情報(ログイン、ユーザ情報、買物カート 等)の格納方法 ・共通情報のスコープ( = 作成~破棄のタイミング) アプリケーション/セッション/リクエスト
・暗号化 データ項目から通信、媒体に対して暗号化すべき対象を洗い出す。 暗号化・複合化の仕組みを設計する。
・対象 ・データ項目: データベースやファイルの情報で、第3者に漏れると社会的な影響があるもの 個人を特定できる情報、クレジットカード番号、ログインパスワード 等 ・通信データ: プロトコルレベルまたはアプリケーションでの通信データの暗号化 ・媒体 : ディスクやその他の媒体で保存するファイルなどに対する暗号化
・仕組み 採用する暗号化方式、強度を設計する。
・ ログの出力 ・ログ出力対象とログの用途の洗い出し アプリケーションが出力するログの用途を明確にする。 あわせて、出力するアプリケーションレイヤーを検討する。 ・アクセスログ: ユーザインタフェースからリクエストとレスポンス情報。 ・障害時:エラー影響(リクエスト、ユーザ)の特定 ・通常時:性能評価、アクセス分析 ・サービスレイヤーが出力する。 ・ロジックログ:業務ロジックの実行ログ、ターンアラウンドタイム。 ・障害時:エラー箇所と原因の特定 ・通常時:性能評価 ・開発時:実行の証跡 ・サービスレイヤー+ロジックレイヤーが出力する。 ・データアクセスログ:データソースへのSQL実行ログ ・障害時:エラー原因(SQLと条件)の解析 ・通常時:監査用 ・データアクセスレイヤーが出力する。 ・エラーログ: 各レイヤーで起こったエラーを集約したもの。 ・通常時:監視向け ・障害時:障害箇所の切り分け ・サービスレイヤーが出力する。
・ログレベル、フォーマット 出力するログレベルとフォーマットを決定する。 ・ログレベル ログの重要度で分類する。レベルで出力要否を設定出来るようにする。 ・FATAL(致命的エラー) ・ERROR(エラー) ・WARN(警告) ・INFO(情報) ・DEBUG(デバッグ情報) ・TRACE(トレース情報) ・フォーマット 解析に必要な情報を特定する。 どのようなフォーマットで出力するか決定する。
・出力先、出力タイミングの決定 ログの出力先と出力するアプリケーションレイヤー、出力方法を決定する。 ・出力先(例) ・ アプリケーションのファイルに出力する。 ・ OSやミドルウェアのログに一緒に出力する。 ・ 監視ツールへ送信する。 SNMP、メッセージキューを利用する。
・出力方法とタイミング ・ ログを出力するアプリケーションレイヤーと出力するタイミングを決定する。 ・ APIやライブラリの使用方法を決定する。 ・ 業務処理と非同期で出力する仕組みを検討・決定する。 ・ ログの新規作成やローテーションの仕組みなどのログ運用方法を決定する。
・メッセージの管理 メッセージの利用方法(ログ出力や画面出力)と管理方法を決定する。 ・ログ・画面への出力方法 ログや画面へ出力する際の実現方法(インタフェース)を決定する。
・メッセージの管理方針 メッセージとして管理する項目やメンテナンス方法を決定する。 ・ 管理項目 例)メッセージID、レベル、メッセージ 等 ・ 管理方法 例) データベースで管理。定義ファイルで管理。プログラムに埋め込み。等
|