Ch14. Well-Architected Framework

信頼性

復旧手順のテスト

オンプレミスのシステムではロードバランサやネットワーク機器はシステム間で共有されており、「一つを意図的にダウンさせて障害をシミュレートする」と言った使い方はほとんどできない。

クラウドでは各システムごとに(そして各環境ごとに)設備を仮想的に設置しているため、そのような障害シミュレートも用意に行える。したがって復旧手順の確認も随時行いやすい。障害を好きなだけテストできる環境があれば、障害回復手順を自動化させることも可能になる。

障害からの自動復旧

閾値を利用した障害の検知にはCloudWatchが利用される。CloudWatch自体に自動リカバリ機能がついているので自動復旧を試みることが出来る。Cloud Watch Auto RecoveryはAWSの基盤側の障害が発生した場合に、インスタンスを自動で再起動してくれるシステム。つまりアプリケーションがストップした場合は特に復旧等は行われない。アプリケーションの復旧はELBのヘルスチェックを用いる

CloudWatch AlarmのAuto Recoveryに触れる | DevelopersIO

アプリケーションの復旧はAutoScalingとELBによるヘルスチェックを行い、インスタンスに異常があった場合のみロードバランサから切り離して新しいインスタンスを追加する。

DBの自動復旧はマルチAZ構成によって実現できる。マスター/スタンバイ構成のうち、マスターがダウンしたのを確認するとスタンバイ側がマスターに昇格する。マスターへ昇格する際はDNSを利用して、DBへのアクセスを行うサーバーが同じURLでスタンバイDBにアクセスできるようにする。

スケーラブルシステム

スケーラブルなシステムを構築することは信頼性の観点からも重要である。

スケールアウト(水平拡張)でスケーラビリティを実現するのであれば、サーバーインスタンスをステートレスに保つ必要がある。とはいえ、Webサービスのセッション情報など全てをステートレスに実装することは出来ない。セッション情報はElastiChash(redisまたはmemcached)を利用する場合もあるが、（非常に高性能なI/Oを実現できるDBの）DynamoDBを利用する場合もある。

スケーラブルなシステムを構築するにあたり、スケールアウト出来るのであれば一つのリソースのサイズは小さいほうがおぞましい。ロードバランサにぶら下がるEC2のインスタンスがあまりに高性能であれば、スケーリングの調整が難しくなる(過少性能か過大性能かどちらかになってしまう)。

キャパシティの推測が不要

Webサーバ・アプリケーションサーバはスケールアウトが容易である。

それに対してDBはスケールアウトが比較的難しい。DBのスケーリングには以下が考えられる。

参照系・更新系の分離(スケールアウト)
リードレプリカの増加(スケールアウト)
更新系のパフォーマンスを上げる(スケールアップ)

このうち1. は参照系が更新系から分離されるためパフォーマンスが落ちてしまうし、2.のリードレプリカの数にも上限がある。