Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie 目的別に考える冗長構成
Ähnlich wie 目的別に考える冗長構成 (20)
目的別に考える冗長構成
- 1. 目的別に考える冗長構成 2019/9/18 JAWS-UG名古屋 Safe Architecture
- 2. 自己紹介 $ name 杉本 啓史(Twitter: @kecSg, Qiita: @ihsiek) $ organization JAWS-UG名古屋, 株式会社エイチーム EC事業本部 $ favorite aws service AWS Systems Manager
- 10. ここからが本題
- 11. おことわり - 稼働率はAWSの各サービスのSLAに基づいて計算したもので、SLAどおりの可用 性を保証するものではありません - アプリケーションレイヤーの影響を一切無視しているため、ご自身の環境に当ては める際には障害発生確率なども加味してご検討ください - ユーザー体験を損なうアーキテクチャを推奨する意図はありません
- 12. 稼働率の計算についておさらい 直列システム 稼働率 ＝ A1 × A2 ＝ 99.99%×99.95% ＝ 99.940005% 並列システム 稼働率 = 1 - (1 - B1) × (1 - B2) = 100%-0.01%×0.05% = 99.999995%
- 13. Case1. 可用性の要求が低いサービス - オウンドメディアなどSEOを中心に集客しているもの - ダウンタイムが致命的なインパクトにつながらない - シングル構成でも構わないので費用を下げたい
- 14. シングル構成
- 16. デメリット - 可用性が低い - 99.95%、21.6分/月程度ダウンする想定が必要 - AZ障害による影響が大きい - AZが復旧するまでサービスを復旧できない - AZが復旧した場合でもEBSが破損するとサービスを復旧できない
- 17. 障害の影響度を下げる工夫
- 18. EBSの定期バックアップ - 作成したスナップショットはAmazon S3に置かれるので、AZ障 害が発生した場合も復元可能 - 復元したEBSを新規インスタンスにアタッチすることでデータの サルベージが可能
- 20. Amazon CloudFront + Amazon S3への移行 - 動的ページを持たないWebサイトであれば、 CMSをサイトジェネレータとして利用し、 S3からCDN経由で配信することも検討する
- 21. Amazon CloudFront + Amazon S3
- 22. Case2. ほどほどの可用性が求められるサービス - 社内ツールなど若干のダウンタイムが許容できるもの - 業務時間外の計画メンテナンスなども許容する - 目標復旧時間は短くしたい - 商用サービスでも非機能要件次第でこの水準を許容する
- 23. Multi-AZ構成(2AZ)
- 25. デメリット - シングル構成よりも稼働率は低下する - リリース管理が面倒 - インスタンス台数分の費用がかかる - ELBがAZ障害に対応していない - RDSのパッチあてでダウンタイムが発生 - セッション共有・ファイル共有の仕組みが必要になる
- 26. Multi-AZ構成(3AZ)
- 28. 運用負担を下げる工夫
- 29. オートスケーリンググループの利用 - インスタンスダウンを検知してスケーリングできるようにしてお く - 必要数を2インスタンスに設定しておけば、1インスタンス分費 用を節約できる - リリース時にAMIを作るなど工夫が必要
- 30. Amazon RDSのリードレプリカを並列化する - Readerだけの並列化は比較的容易 - 照会系のサービスだけリードエンドポイントに向ける
- 31. Amazon RDSをAmazon Auroraに移行する - RDS→AuroraでSLAが99.95%から99.99%に - フェイルオーバーが高速(障害検知から1分程度) - Zero Downtime Patchによる無停止のパッチあてが可能 - 3AZに計6つのコピーが自動的に作成されるのでAZ障害に強 い - Slaveが最低1台ないとフェイルオーバーできない
- 32. Case3. 高可用性が求められるサービス - ECサイトや動画サービスなどの商用サービス - 停止がクレームに繋がりうるもの
- 34. コンテナ化 ＋ Fargateへの移行 - コンテナがダウンすると自動で立ち上がる - インスタンス管理からも解放されているのでユーザー側での 運用がほとんど存在しない
- 37. 追求はできるがキリがない
- 38. AZ障害の備え - 障害が発生しているAZはAZ IDでチェックする - Multi-AZ構成は3AZ以上で設定する - 障害が発生しているAZを切り離しできるようにする - 定期的にEBSのスナップショットを取っておく - マネージドサービスをMulti-AZで展開しておく - Chaos Engineeringや避難訓練を実施する
- 39. ご清聴ありがとうございました