# 可用性（Availability）

## 可用性の基本方針

システムの停止リスクを最小化し、障害発生時の影響範囲・復旧時間を最小限に抑えるための全体戦略を以下に示す。

### 冗長化方針
- **単一障害点（SPOF）の排除**: すべての主要コンポーネントを冗長化
- **N+1構成**: 通常運用に必要な台数+1台の冗長構成を基本とする
- **Active-Active構成**: 負荷分散と可用性向上を両立

### データ保護方針
- **多重化**: 本番データは最低3箇所に保持（本番DB、スタンバイDB、バックアップ）
- **リアルタイム同期**: トランザクションログのストリーミングレプリケーション
- **暗号化**: 保存データ・転送データともに暗号化

### バックアップ方針
- **定期バックアップ**: フルバックアップ（週次）、増分バックアップ（日次）
- **多世代管理**: 直近7世代を保持
- **リストアテスト**: 月次で復元テストを実施

### 監視・運用方針
- **24時間365日監視**: 障害の早期検知と迅速な対応
- **自動化**: 障害検知から復旧までの自動フェイルオーバー
- **エスカレーション**: 重要度に応じた通知・対応フロー

### 災害対策の基本方針
- **DR環境**: 別リージョンにDR（Disaster Recovery）環境を構築
- **定期訓練**: 年2回のDR切替訓練を実施
- **手順書整備**: フェイルオーバー手順を文書化・定期更新

---

## 可用性要件の実現方式

### A1. 継続性（Continuity）

#### A1.1 運用スケジュール

##### A1.1.1 通常運用時間
- **要件**: 24時間365日稼働
- **実現方式・仕様**:
  - アプリケーションは常時稼働前提で構築
  - 無停止デプロイ方式（Blue-Green Deployment / Rolling Update）を採用
  - 計画停止作業は深夜帯 02:00–04:00 に限定し、年間12回以内

##### A1.1.2 特定日の運用
- **要件**: 年度末・決算期は計画停止を実施しない
- **実現方式・仕様**:
  - メンテナンス禁止期間を運用カレンダーで設定
  - CI/CDパイプラインに禁止期間チェックを組み込み、自動制御

##### A1.1.3 計画停止
- **要件**: 月1回、1時間以内
- **実現方式・仕様**:
  - OSパッチ適用はRolling Updateでサービス影響ゼロ
  - ミドルウェア更新は短時間メンテナンスウィンドウで実施
  - 事前通知は2週間前にユーザーへ通知

---

#### A1.2 業務継続性（BCP）

##### A1.2.1 対象業務範囲
- **要件**: 受注処理系・決済処理系は継続必須
- **実現方式・仕様**:
  - 対象業務モジュールは完全冗長構成（Active-Active）
  - 非対象業務（レポート生成など）は停止許容
  - 機能フラグによる縮退運転モード実装

##### A1.2.2 サービス切替時間
- **要件**: 10分以内に代替系へ切替
- **実現方式・仕様**:
  - LB（ロードバランサ）が障害検知後、自動フェイルオーバー
  - ヘルスチェック間隔：5秒 × 連続3回失敗で切替
  - DNSフェイルオーバーのTTL：60秒

![BCP切替フロー](./diagrams/bcp-failover-flow.drawio.svg)
*※ draw.ioで作成した切替フロー図を配置*

---

#### A1.3 障害時の目標復旧水準

##### A1.3.1 RPO（Recovery Point Objective）
- **要件**: 30分以内のデータ保全
- **実現方式・仕様**:
  - DBスナップショット：15分間隔で自動取得
  - トランザクションログ：リアルタイム同期（ストリーミングレプリケーション）
  - 実効RPO：最大15分（スナップショット間隔に依存）

##### A1.3.2 RTO（Recovery Time Objective）
- **要件**: 2時間以内に復旧
- **実現方式・仕様**:
  - 代替ノードはWarm Standby（常時起動・待機状態）
  - IaC（Infrastructure as Code）により環境構築を自動化
  - 手動切替の場合でも30分以内に復旧可能
  - 自動フェイルオーバーの場合は5分以内

##### A1.3.3 RLO（Recovery Level Objective）
- **要件**: 縮退運転で受注・決済機能のみ復旧
- **実現方式・仕様**:
  - 機能フラグで優先度の高いサービスのみ有効化
  - 周辺API（レポート生成、分析機能など）は停止状態を許容
  - 段階的復旧：第1段階（受注・決済）→第2段階（在庫管理）→第3段階（全機能）

---

#### A1.4 大規模災害時の復旧

##### A1.4.1 システム再開目標
- **要件**: 72時間以内にDR環境でシステム再開
- **実現方式・仕様**:
  - 別リージョン（東京→大阪）にDR環境を構築
  - DRへのデータ同期：非同期複製（遅延時間：5秒以内）
  - 手動フェイルオーバー手順書を整備（年2回訓練実施）
  - DNS切替による接続先変更（TTL：300秒）

![DR構成図](./diagrams/dr-architecture.drawio.svg)
*※ draw.ioで作成したDR構成図を配置*

---

#### A1.5 稼働率

##### A1.5.1 稼働率目標
- **要件**: 99.9%（年間停止時間：約8.76時間）
- **実現方式・仕様**:
  - 冗長構成（N+1）による障害時の影響最小化
  - 監視アラート 24時間365日体制
  - MTTR目標：30分以内
  - MTBF目標：720時間（30日）以上

##### A1.5.2 稼働率の計算式

```
稼働率 = (総運用時間 - 停止時間) / 総運用時間 × 100

例）年間稼働率 99.9% の場合
停止許容時間 = 365日 × 24時間 × (1 - 0.999) = 8.76時間/年
```

---

### A2. 耐障害性（Fault Tolerance）

#### A2.1 サーバー冗長化方式

| 層 | 冗長化方式 | 構成台数 | 備考 |
|----|-----------|---------|------|
| ロードバランサー | Active-Active | 2台 | クラウドLB使用 |
| Webサーバー | Active-Active | 3台（N+1） | 最小2台で運用可能 |
| APサーバー | Active-Active | 3台（N+1） | オートスケール対応 |
| DBサーバー | Primary-Standby | 2台+読取レプリカ2台 | 同期レプリケーション |

![冗長化構成図](./diagrams/redundancy-architecture.drawio.svg)
*※ draw.ioで作成した冗長化構成図を配置*

#### A2.2 ネットワーク冗長化
- **2ルート構成**: 異なるISPから2系統の回線を確保
- **VRRP**: 仮想ルーターによる自動切替（切替時間：3秒以内）

#### A2.3 データベース冗長化
- **同期レプリケーション**: Primary-Standby間は同期複製
- **非同期レプリケーション**: 読取レプリカへは非同期複製
- **自動フェイルオーバー**: Primaryダウン時、Standbyが自動昇格（30秒以内）

#### A2.4 ストレージ保護
- **RAID構成**: RAID 10（ミラーリング+ストライピング）
- **スナップショット**: 15分間隔で自動取得、7世代保持

#### A2.5 アプリケーションのフェイルオーバー仕様
- **ステートレス設計**: セッション情報は外部ストア（Redis）に保持
- **リトライ機構**: 一時的な障害に対する自動リトライ（最大3回）
- **サーキットブレーカー**: 連続障害時の自動遮断と復旧

---

### A3. 監視・障害検知方式

#### A3.1 監視項目一覧

| カテゴリ | 監視項目 | 閾値（警告/致命的） | 監視間隔 |
|---------|---------|------------------|---------|
| リソース | CPU使用率 | 70% / 90% | 1分 |
| リソース | メモリ使用率 | 80% / 95% | 1分 |
| リソース | ディスク使用率 | 80% / 90% | 5分 |
| サービス | HTTP応答時間 | 1秒 / 3秒 | 1分 |
| サービス | エラー率 | 1% / 5% | 1分 |
| DB | レプリケーション遅延 | 10秒 / 30秒 | 1分 |
| ネットワーク | パケットロス率 | 1% / 5% | 1分 |

#### A3.2 アラート通知フロー

![監視アラートフロー](./diagrams/monitoring-alert-flow.drawio.svg)
*※ draw.ioで作成した監視フロー図を配置*

#### A3.3 ログ監視方式
- **集約基盤**: 中央ログ管理システム（ELKスタック等）
- **リアルタイム分析**: エラーログの自動検知とアラート
- **保存期間**: 90日間オンライン保存、それ以降はアーカイブ

---

### A4. バックアップ・リストア方式

#### A4.1 バックアップ方式

| 種別 | 対象 | 頻度 | 保存期間 | 保存先 |
|------|------|------|---------|--------|
| フルバックアップ | DB全体 | 週次（日曜深夜） | 4週間 | 別リージョンストレージ |
| 増分バックアップ | 差分データ | 日次（深夜2時） | 7日間 | 同一リージョンストレージ |
| スナップショット | DBインスタンス | 15分間隔 | 24時間 | クラウドスナップショット |
| ログバックアップ | トランザクションログ | リアルタイム | 7日間 | 同一リージョンストレージ |

#### A4.2 リストアテスト計画
- **実施頻度**: 月次（毎月第2土曜日）
- **テスト内容**: 
  - フルバックアップからの完全復元
  - 特定時点へのポイントインタイムリカバリ
  - DR環境への復元
- **成功基準**: RTO/RPO目標値の達成

---

### A5. 可用性設計に関する依存関係・前提条件

#### A5.1 インフラ依存
- **クラウドサービスSLA**: 99.99%（AWS/Azure/GCPのSLAに依存）
- **ネットワークSLA**: ISPの提供SLA 99.9%

#### A5.2 運用組織の体制
- **24時間365日監視体制**: 3交代制
- **オンコール体制**: 1次対応者2名、2次対応者2名を常時確保
- **緊急対応チーム**: 重大障害時に30分以内に招集可能

#### A5.3 サードパーティ製品
- **監視ツール**: 稼働率99.9%以上
- **バックアップソリューション**: データ損失ゼロ保証

---

## テスト計画（可用性関連）

### フェイルオーバーテスト
- **実施時期**: 本番リリース前、および四半期ごと
- **テスト項目**:
  - LB配下のサーバー1台停止時の動作確認
  - Primary DB停止時の自動フェイルオーバー確認
  - ネットワーク切断時の切替動作確認

### RTO/RPO検証
- **検証方法**: 実際に障害を発生させ、復旧時間・データ保全を計測
- **合格基準**: 設計値（RTO: 2時間、RPO: 30分）を満たすこと

### DR切替訓練
- **実施頻度**: 年2回（6月・12月）
- **訓練内容**: 本番環境からDR環境への完全切替
- **参加者**: 開発チーム、運用チーム、経営層

### 監視アラート動作確認
- **実施頻度**: 月次
- **確認項目**: 各監視項目の閾値超過時のアラート発報確認

---

## リスクと対策

| No | リスク | 影響 | 発生確率 | 対策 |
|----|--------|------|---------|------|
| 1 | 冗長化構成の誤設定 | 全サービス停止 | 低 | IaCによる自動設定管理、peer review |
| 2 | バックアップデータの破損 | 復旧不能 | 低 | 月次リストアテスト、多重化保存 |
| 3 | DRリージョンの同時障害 | 長期停止 | 極低 | 第3のバックアップサイト検討 |
| 4 | 監視システムの障害 | 障害検知遅延 | 中 | 監視システム自体の冗長化 |
| 5 | 運用担当者の対応遅延 | RTO超過 | 中 | 自動復旧機構の強化、手順書整備 |

---