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

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

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

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

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

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

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

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

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

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

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

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