非機能要件対策 - ntuf/Tips GitHub Wiki

逆引き
■データベースのアクセス集中によるパフォーマンス低下を改善したい

・Amazon RDSをマルチAZ構成でクラスタリングし、可用性を高める
・リードレプリカを導入
　　読み込み専用クエリはレプリカへ振り分けることで、マスタDBの負荷を軽減する。
・頻繁に参照されるデータについてはElastiCacheなどのキャッシュ機構を導入
　　DBアクセス自体を削減し、パフォーマンスを大きく向上

・静的コンテンツはCloudFrontなどのCDNでキャッシュし、Webサーバーの負荷を低減する

■稼働中のシステムから新システムへの切替を行う場合、ダウンタイムを最小限に抑えつつ、
確実にデータを移行するためにはどのような方法や工夫が有効か

■可用性を高める
・冗長構成（クラスタリング）を導入する
システムを複数台のサーバで構成し、一部に障害が起きても他のサーバが処理を継続できるようにすることで、
ダウンタイムを最小化できる。たとえば、アプリケーションサーバをロードバランサ配下に配置することで、
1台の障害でも業務継続が可能になる
・RDSのマルチAZ構成を利用する
AWSなどのクラウドでは、RDSのマルチAZ構成を使うことで、プライマリDBに障害が発生しても自動的に
スタンバイDBにフェイルオーバーされ、サービスの継続性が保たれる
・バックアップと迅速なリストア
・監視と自動復旧
・インフラをコード化して迅速再構築

ーーー

フェイルオーバーとは
意味：
システムに障害が発生したとき、あらかじめ用意しておいた代替システムに自動的に切り替える仕組み
目的：
サービスを止めないこと（高可用性の実現）
具体例：
・データベースのプライマリが落ちたら、スタンバイに自動で切り替える（例：RDS Multi-AZ）
・冗長構成のアプリケーションサーバー群に対して、ロードバランサーが死活監視をして、落ちたら他に振り分ける

フェイルセーフとは
意味：
障害が起きたときでも、人命や機器への被害を最小限に抑えるための設計。
目的：
安全性の確保（壊れても危なくならないこと）　
具体例：
・エレベーターが故障したときに安全な階で停止する
・自動ドアが故障時には開いたままになる（人が挟まれないように）
・工場機械が異常を検知したら自動的に停止する

ーーー

■バッチが長く、困っている
単一のバッチプログラムで構成されており、実行時間が長く、障害時の影響範囲も広い

・バッチ処理の分割（マイクロバッチ化）
バッチ処理を機能単位または処理単位に分割し、個別に実行できるようにする。
理由：バッチ全体が長時間かかる場合、一部の処理だけがボトルネックになっていることがある。
処理を分割することで、並列実行や部分的な障害切り分けが可能になり、障害影響範囲を限定できる。

・イベント駆動・非同期処理への移行
データが入力されたタイミングで処理をトリガーするイベント駆動型設計を導入し、一部の集計処理をリアルタイムで行う。
理由：全データを一括で処理するのではなく、データが届いたタイミングで処理すれば、バッチ処理の負荷を軽減できる。
また、Lambdaやキュー（SQSなど）を利用すればスケーラブルかつ耐障害性の高い構成が実現できる。

「バッチ処理が長い」→「分割・並列化・スケジューリング改善」
「影響範囲が広い」→「機能分割・リトライ制御・ログの細分化」
「クラウド利用」→「Lambdaやイベント駆動によるスケーリング」

■要件定義フェーズで「ユーザ部門との合意形成がうまくいかず、手戻りが発生する
1. ユーザとのレビューサイクルを短く設け、プロトタイプを活用すること
→ 要件を具体的なUIや画面遷移の形で可視化し、実際に触れてもらうことで認識のズレを早期に発見できる。
これにより、抽象的な要件定義の誤解を防ぐことができる。

2. 要件定義の成果物として合意文書を作成し、関係者全員から承認を得ること
→ 言った言わないのトラブルや、後から出てくる要望への線引きを明確にすることで、
仕様の確定とその変更に対する責任を明文化できる。

■セキュリティ要件
セキュリティ要件を満たすため、
WAFやIPS/IDSを導入して外部からの攻撃を防ぐ。
通信はTLSにより暗号化し、認証には多要素認証を採用する。
顧客情報はRDSの暗号化機能を使って保存し、
アクセス制御はIAMで最小権限の原則に従って設計する。

多層防御：WAF・IPS/IDS・TLS・IAM などの複数層で守る設計
暗号化：通信（TLS）もデータ（RDS）も暗号化
認証強化：多要素認証
アクセス制御：IAMで「最小権限の原則」