前回の振り返り
前回は、WEBサーバー構築を通じて、通信の流れについて学習しました。
その際にふと感じたことは、実務ではBCPの観点から冗長化が必要なので、
シングル構成から冗長化させた構成にするにはどうすればよいかということです。
今回は、(Copilotと相談しながら)自分なりに冗長構成について考えてみました。
完成形
今回の完成形は以下です。
このハンズオンを通じて、冗長化における、同期であったり一貫性の維持というものの難しさを感じました。
特に、DBの同期は非常に難易度が高いと感じました。
シャーディングではないので、一般でいうところの分散型DBではないですが、
master-slave型をCAP定理に当てはめると、
一貫性(C)を完全に捨てて、可用性(A)に重きを置いた構成であると感じました。
CAP定理
分散型DBにおいて以下の3つは、同時に満たすことができないという定理。
一貫性(Consistency) / 可用性(Availability) / ネットワーク分断耐性(Partition-tolerance)
■一貫性の維持
他DBの更新内容を確認するため待つ
→応答できなくなって可用性がなくなる
■可用性の維持
通信断の場合、他DBの更新内容を待たずに稼働
→一貫性がなくなる
Appendix. この構成に辿り着くまでの足跡
シングル構成だと災害に弱いので、実務に即して冗長構成にしたい
①DBサーバーの冗長化
①-1.binary-logでのレプリケーション (フェイルオーバーが複雑、ラグあり)
①-2.RDSでのレプリケーション
②WEBサーバーの負荷分散・可用性確保
②-1.ALBでの冗長化
③複数WEBサーバー間の一貫性の維持
③-1.S3マウント (画像をWEBサーバー経由で読みこむため遅い)
③-2.EFSマウント (画像をWEBサーバー経由で読みこむため遅い)
③-3.S3プラグイン+CloudFront
前提
①DBサーバーの冗長化
①-1.binary-logでのレプリケーション (フェイルオーバーが複雑、ラグあり)
①-2.RDSでのレプリケーション
②WEBサーバーの負荷分散・可用性確保
②-1.ALBでの冗長化
③複数WEBサーバー間の一貫性の維持
③-1.S3マウント (画像をWEBサーバー経由で読みこむため遅い)
③-2.EFSマウント (画像をWEBサーバー経由で読みこむため遅い)
③-3.S3プラグイン+CloudFront
おまけ
■今回の構成で重視した観点
Reliability（信頼性）： 故障しない
Availability（可用性）： サービスが止まらない
Serviceability（保守性）： メンテナンスがしやすい
Integrity（完全性）： データ欠損・矛盾がない
Security（安全性・機密性）： 情報の保護