go-athome

go-athome サービス品質保証書（SLA）

本サービス品質保証書（以下「本 SLA」といいます。）は、go-athome サービス利用規約（以下「本規約」といいます。）第15条に基づき、本サービスの品質保証に関する事項を定めるものです。本 SLA は本規約の一部を構成します。

第1条（適用範囲）

  1. 本 SLA は、本規約に基づき本サービスを利用する全ての契約者に適用されます。
  2. 本 SLA に定めのない事項については、本規約の定めに従います。

第2条（可用性目標）

  1. 月間稼働率目標：99.5%

    • 計画的なメンテナンス時間を除き、月間稼働率 99.5% 以上を目標とします。
    • 月間稼働率 = (月間総時間 - 停止時間) / 月間総時間 × 100

  2. 計画的メンテナンス：

    • 計画的メンテナンスは事前に契約者に通知し、月間4時間以内に収めるよう努めます。
    • メンテナンス時間は月間稼働率の計算から除外されます。

  3. 月間稼働率が目標を下回った場合：

    • 利用料金の減額は行わず、契約者への通知及び原因調査をもって措置とします。

  4. 免責事項：

    • 以下の事由による停止は、月間稼働率の計算から除外されます。
      • 契約者の行為に起因する停止
      • 天災、停電、通信障害その他の不可抗力
      • 第三者のサービス（決済サービス、通信事業者等）の障害
      • セキュリティインシデントへの緊急対応（DDoS 攻撃、不正アクセス等）

第3条（バックアップ）

  1. データベース（Aurora PostgreSQL）：

    • バックアップの頻度： 本番環境のデータベースを、毎日1回バックアップします。
    • 保存世代数： 日次の復旧ポイントを14日分保持します。
    • 地理的冗長性： 本番環境の日次バックアップを、別リージョン（大阪リージョン ap-northeast-3）へ複製します。
    • Point-in-Time Recovery（PITR）： 5分粒度で過去の任意の時点へのリストアは、東京リージョンの Aurora において、直近14日間の範囲で可能です。大阪リージョンへ複製された復旧ポイントは日次であり、大阪リージョンでは PITR はできません。

  2. キャッシュ（Redis）：

    • Redis データは一時的なキャッシュであり、データベースが正本です。
    • 自動フェイルオーバーは構成していません。 Redis に障害が生じた場合、失われたキャッシュはデータベースから再構築されます。

  3. 静的ファイル（S3）：

    • バージョニング： 本番環境のバケットでバージョニングを有効化し、誤削除時の復元が可能です。フロントエンド用バケットの旧バージョンは 30日間で失効します。メディア用バケットの旧バージョンに失効期間の設定はありません。
    • デプロイ時バックアップ： CI/CD デプロイ時に、現行ファイルを _backups/{timestamp}/ に自動バックアップします（5世代保持）。

第4条（目標復旧時間・目標復旧地点）

  1. RTO（Recovery Time Objective - 目標復旧時間）：

    • 障害発生から本サービスの復旧までの目標時間
    • 東京リージョン内の障害で、PITR による復旧が可能な場合、障害発生から 30分以内を目標とします（目標であり保証ではありません）。リージョン全体の障害は本目標の対象外です。

  2. RPO（Recovery Point Objective - 目標復旧地点）：

    • 障害発生時にデータを復旧できる直近の時点の目標
    • 東京リージョンの Aurora の Point-in-Time Recovery により、障害発生時点から 5分以内を目標とします（目標であり保証ではありません）。
    • リージョン全体の障害は本目標の対象外です。 この場合に復旧できる直近の時点は、大阪リージョンへ複製された最後の日次バックアップの時点となります。

  3. 障害シナリオ別の復旧手順：

    以下は復旧の手順です。数値の目標は、前2項に定める RTO 及び RPO に限ります。

    障害シナリオ復旧手順
    ECS タスク障害タスクの自動再起動とヘルスチェック
    Aurora 障害（単一 AZ）PITR リストア
    Redis 障害Redis はキャッシュであり、データベースが正本です。失われた分はデータベースから再構築します。自動フェイルオーバーはありません。
    AZ 全体障害ストレージは複数 AZ に複製されています。計算ノードは PITR の手順で戻します。
    データ破損PITR リストア
    フロントエンド破損S3 のバックアップから復元

第5条（モニタリング・アラーム）

  1. 監視項目：

    • ECS タスク稼働状態（Running タスク数）
    • ALB ヘルスチェック（Target Healthy Count）
    • Aurora CPU 使用率・接続数
    • Redis CPU 使用率・接続数・メモリ使用率
    • Secrets Manager の資格情報ローテーションの失敗
    • CloudFront の 5xx エラー率
    • バックアップ及び大阪リージョンへのコピーの失敗

  2. アラーム通知：

    • 重大な障害発生時は、運用チームに即時通知されます。
    • 契約者への障害通知は、本規約第29条（インシデント対応）に基づき、認知から72時間以内に実施します。

第6条（セキュリティ対策）

  1. 通信の暗号化：

    • 通信は TLS 1.2 以上で暗号化します。可能な場合は TLS 1.3 を使います。
    • HTTPS 通信の強制（HTTP → HTTPS 自動リダイレクト）

  2. 認証：

    • SMS OTP（ワンタイムパスワード）による本人確認
    • 2段階認証（TOTP / Google Authenticator）のサポート
    • パスワードのハッシュ化保存（Argon2）

  3. アクセス制御：

    • 診療情報の閲覧は、担当・参加・在籍により制限します。職種による区別は行いません。

  4. 監査ログ：

    • すべての診療情報へのアクセス・操作を記録
    • 監査ログは日次で写しを取り、改ざんできない保管（Amazon S3 Object Lock のガバナンスモード）に置いて3年間保持します。 アプリケーションからは、この写しを変更も削除もできません。
    • 写しを取るまでのあいだ、データベース上の行は更新され得ます。
    • 監査ログの時刻は、本サービスが稼働する AWS Fargate のシステム時刻（Amazon Time Sync Service に同期）に基づき、記録時に自動付与されます。

第7条（ランサムウェア等のサイバー攻撃への対応）

  1. 攻撃検知：

    • AWS GuardDuty による不正アクセスの検知
    • Sentry によるアプリケーションエラーの監視

  2. 攻撃発生時の対応手順：

    • 攻撃を検知した場合、直ちに以下の措置を講じます。
      1. 影響範囲の特定（どのリソースが侵害されたか）
      2. 侵害されたリソースの隔離（セキュリティグループ変更・タスク停止等）
      3. バックアップからの復旧（PITR / S3 バージョニング）
      4. 契約者への通知（本規約第29条に基づき72時間以内）
      5. 原因調査・再発防止策の策定

  3. バックアップからの復旧：

    • データベース：東京リージョンの PITR により、侵害直前の時点（侵害直前から5分以内）への復元を目標とします。リージョン全体の障害の場合、復元できる時点は大阪リージョンへ複製された最後の日次バックアップの時点となります。
    • 静的ファイル：S3 バージョニング / バックアップから復元
    • 復旧後、全データの整合性を検証

第8条（インフラ構成）

  1. データセンター所在地：

    • プライマリリージョン：日本（東京リージョン ap-northeast-1）
    • 日次のバックアップ複製先：日本（大阪リージョン ap-northeast-3）

  2. マルチ AZ 構成：

    • ECS タスクは複数の Availability Zone に分散配置
    • Aurora データベースは複数 AZ にレプリケーション
    • ALB は複数 AZ にトラフィック分散

  3. 再委託先：

第9条（SLA の変更）

  1. 当社は、技術水準の向上、サービス内容の変更その他合理的な理由により、本 SLA を変更することがあります。
  2. 本 SLA の変更は、本規約第3条（本規約の適用と変更）の規定に従います。
  3. 可用性目標の引き下げ、RTO/RPO の延長その他契約者に不利益な変更は、本規約第3条第4項に定める「重大な変更」として取り扱い、契約者の個別の同意を得るものとします。

第10条（問い合わせ）

本 SLA に関するお問い合わせは、本サービスのアプリ内のお問い合わせ（マイページ内）よりご連絡ください。

附則

本 SLA は令和8年6月6日から施行します。