この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「AWS Well-Architected Framework」
昨年、AWSより「AWS Well-Architected Framework」というドキュメントが公開されました。この文書は、みなさんがより良いクラウドベース設計を評価改善し、設計によるビジネスへの影響についてより良い理解をするためのものです。AWSで良い設計をしているかを定義する柱として、4つの分野におけるベストプラクティスとガイドを定義し、一般的な設計指針について取り組みます。
今回は、セキュリティ編の続きとして、信頼性についての確認事項をご紹介します。
前回のセキュリティ編はこちらです。
AWSで優れた設計をしているか？の質問と回答（セキュリティ編）「AWS Well-Architected Framework」
4つの柱
「AWS Well-Architected Framework」で示されている4つの柱は以下のとおりです。
- セキュリティ（Security） リスクアセスメントとマイグレーション戦略を通じたビジネス価値の提供による、情報・システム・資産を保護する能力について
- 信頼性（Reliability） システムの能力を動的に需要を満たすためにコンピューティング資源を獲得し、インフラやサービスの障害からの回復、およびそのような設定ミスや一時的なネットワークの問題などの混乱を軽減する能力について
- パフォーマンス効率（Performance Efficiency） システム要件を満たすことと、需要の変化や技術の進化を前提し、その効率を維持するために効率的にコンピューティングリソースを使用する能力について
- コスト最適化（Cost Optimization） 最適ではないリソースや不要なコストを回避または取り除く能力について
質問＆回答とベストプラクティス（信頼性編）
REL1：どのようにAWSアカウントにおけるサービス上限を管理するか？
AWSアカウントは、新規ユーザーが誤って多くのリソースをプロビジョニングすることを防止するために、デフォルトでサービス利用制限が適応されています。AWS利用者は、AWSサービスの各リージョンにおける適切で必要な上限の変更について評価すべきです。
☆ベストプラクティス
- 上限の監視と管理。AWS上で潜在的な仕様状況について評価する。適切にリージョンにおける上限を上げ、利用増の計画に対応します。
- 自動化されたモニタリングツールを設定します。例）SDKなどを利用して、閾値に近づいたらアラートを上げます。
- 上限が固定のサービスに注意。上限を変更できないサービスを用いた設計に注意してください。
REL2：どのようにネットワークトポロジを計画するか？
アプリケーションは、1つ以上の環境で存在します。ECクラシック、VPC、デフォルトVPCなどです。ネットワークの考慮点は、ネットワークの接続性、EIP/パブリックIPアドレス管理、VPC/プライベートアドレス管理、名前解決などは、クラウドにおける基本的な活用に関する事項です。よく計画されて文書化されたデプロイは、重複や競合を軽減するために必要不可欠です。
☆ベストプラクティス
- 高接続性を可能にするために、複数DX回線、複数VPNトンネル、AWSマーケットプレイスアプライアンスの利用
- 高接続性を可能にするために、ロードバランシングやプロキシなどによるシステム高可用化、DNSベースのソリューション、AWSマーケットプレイスアプライアンスの利用など
- 重複しないプライベートIPレンジの使用。仮想プライベートクラウドにおいて、IPレンジとサブネットは、互いに他のクラウド環境やオンプレミス環境と、重複しようようにしてください。
- IPサブネットの割当。個々のAmazon VPC IPアドレスレンジは、Availability Zoneをまたいでサブネットを割当てし、将来の拡張を加味し、アプリケーション要件に対応して十分な大きさでなければなりません。
REL3：技術的な問題に対処するためのエスカレーションパスを持っているか？
お客様は、AWSサポートやAWSパートナーを活用するべきです。
☆ベストプラクティス
- 定常的なやり取りは、既知の問題に対処し、知識ギャップ、設計上の問題などの防止に役立ち待ちます。これは、実装上の不備や大規模なシステム停止などのリスクを低減させます。
- AWSサポートやAWSパートナーと、計画進行中に関与や関係を持つ。AWSサポートAPIの活用。AWSサポートAPIと内部の監視やチケットシステムを統合します。
REL4：あなたのシステムは、どのように要求の変化に対応するか？
スケーラブルなシステムは、任意の時点でその時の需要に一致するように、自動的にリソースの増減をするための、伸縮性を提供することができます。
☆ベストプラクティス
- 自動スケール。自動的にスケールするサービスを利用します。Amazon S3, Amazon CloudFront, Auto Scaling, Amazon DynamoDB, AWS Elastic Beanstalkなど。
- 負荷テスト。アプリケーション要求に適応することを測定するために、負荷テスト手法を適応する。
REL5：どのようにAWSリソースを監視するか？
ログとメトリックは、アプリケーションが正常かどうかの洞察を得るために協力なツールです。ログとメトリックを監視し、重要なイベントが発生または閾値を超えた際に、通知を送信するようにシステムを構成することができます。理想的には、パフォーマンス低下の閾値を超えたとか、障害が発生した場合には、システムが自動的に応答して、自動ヒーリングするかスケールするように設定されていることです。
☆ベストプラクティス
- 監視。Amazon CloudWatchやサードパーティツールを使ってアプリケーションを監視する。
- 通知。重要なイベントが発生したときに通知するように設計する。
- 自動応答。故障したコンポーネントを置き換えるなど、障害を検知したときに自動的にアクションする自動化を利用する。
- レビュー。 重要なイベントにおける、アーキテクチャーを評価するために、システムの頻繁なレビューを行います。
REL6：どのように変更管理をするか？
プロビジョニングされたAWSリソースやアプリケーションの変更管理は、アプリケーションや運用環境が既知のソフトウェアを実行していて、制御されたやり方でパッチや置換できるようにする必要があります。
☆ベストプラクティス
- CM自動化。デプロイとパッチ当ての自動化。
REL7：どのようにデータをバックアップするか？
リカバリー平均時間（MTTR：mean time to recovery）やリカバリーポイント目標（RPO：recovery point objectives）の要件を満たすために、データ、アプリケーション、運用環境（定義されたアプリケーションやOSの設定）をバックアップします。
☆ベストプラクティス
- データがバックアップされる。Amazon S3、Amazon EBSスナップショット、サードパーティソフトウェアを用いてRPOを満たすために、バックアップをします。
- 自動バックアップ。AWSの機能、AWSマーケットプレイスソリューション、サードパーティソフトウェアを用いて自動バックアップをします。
- セキュアで暗号化されたバックアップ。AWSセキュリティベストプラクティスのホワイトペーパーを見てください。
- 定期的なリカバリーのテスト。リカバリー試験を通じて、バックアッププロセスの実装が、RTOやRPOを満たしていることを検証します。
REL8：使用中のシステムは、どのようにコンポーネント障害に耐えるか？
あなたのアプリケーションは、低MTTRで高可用性のために、暗黙的または明示的な要件がありますか？もしそうなら、耐障害性のためのアプリケーションを設計し、システム停止に耐えるためにそれらを配布します。高可用性を達成するために、物理的に異なる場所に配置すべきです。監視、自己ヒーリング、失敗や中断などの重要なイベントを通知することを含み、耐障害性のために、個々のレイヤー（Webサーバー、DBサーバー）を設計します。
☆ベストプラクティス
- ロードバランシング。リソースプールの前でロードバランサーを利用します。
- 複数のAZやリージョン。リージョンやAZをまたいでアプリケーションを配布します。
- 自動ヒーリング。障害を検知して修復を実行するために、自動化機能を用いてください。
REL9：どのようにリカバリーを計画するか？
データの復旧は重要であり、適切なバックアップ方式が求められます。 データの目的やリソース、配置場所や機能に関する定義や実行に関してはRTO（目標復旧時間）やRPO（目標復旧ポイント）の目的に沿っている必要があります。
☆ベストプラクティス
- 目的の定義。RTOやRPOの定義をする。
- 災害対策。DR戦略を確立する。
- 構成の流れ。AMIとシステム構成の状態が最新のDRサイト/リージョンであることを確認します。
- サービス上限。フェイルオーバーに対応するために、DRサイトでサービス上限に引っ掛からないように上限緩和します。
- DRのテストと検証。定期的なDRのフェイルオーバーテストによって、RTOとRPOが満たされていることを確認します。
- 自動リカバリー。AWSやサードパーティツールを用いてシステムの自動リカバリーを実装します。
まとめ
AWSを使ってシステムの信頼性を確保する際にチェックすべき事項についてご紹介しました。DR先がデフォルトのサービス上限に引っかるというのはありがちですね。これらは何度も実際に動作させて検証することで防げると思います。他にも、困ったときのエスカレーション先を用意しておくってのはセールストークですねw。
参考資料
Are You Well-Architected?
- Documentation & Blogs
- Whitepapers
- Videos
0
