AWSアーキテクチャについて
設計原則
リージョンとAZの活用
- 1つのリージョンにつき2つのAZを利用してアーキテクチャを設計すること
- 3つ以上はコスト効率が低下するため、2つが適切
- ロードバランサ―によるトラフィック制御するのが基本的な姿
- インスタンス、DBどちらもマルチAZ構造を採用することで、サーバーやDBの冗長構成を確立し高い可用性を実現する
VPC
- 基本的に1つのアプリケーションは1つのVPCで設計すること
- ネットワークの通信の連携などが複雑になってきてしまうが、システムを複数にわけることが必要な場合に２つ以上利用することもある（テスト用と本番用にわける場合などはVPCを分割する）
- ネットワークの分割方法は
マルチVPC方式とマルチアカウント方式がある- マルチVPC方式：アカウント内のVPC自体をシステムによってわけていくこと
- マルチアカウント方式：アカウントごとにVPCを持っており、所有するシステムをわけていることによって分割すること
サブネットの分割
- インターネットアクセスに必要なものだけをパブリックサブネットに配置
-
/24以上のサブネットマスクによる設定が推奨されている - プライベートサブネットに多くのIPアドレスを割り当てることが一般的
データの分散
- 別リージョンにDBのレプリカを配置するなどしてデータアクセスを分散する
- 冗長性を確保することで災害対策としても良い
Well-Architected Framework
AWSで推奨されるクラウド設計原則（ベストプラクティス）のこと。
6本の柱で体系化している。
-
優れた運用効率（Operational Excellence）
システムの実行とモニタリングおよびプロセスと手順の継続的な改善に焦点を当てる- コードに基づいて運用実施を自動化
- ビジネス目的に沿った運用手順を整備する
- 定期的かつ小規模に運用手順を更新する
- 予期せぬイベント発生に備えて事前にプロセスを確認する
- 運用イベントと障害から学習して運用手順を更新する
- 常に運用手順を最新のものにしておく
-
セキュリティ（Security）
情報とシステムの保護に焦点を当てる- すべてのレイヤにおいてセキュリティを適用
- アクセス追跡・モニタリングを実施
- 条件によるアラートをトリガーとしてセキュリティイベントへの応答を自動化する
- AWS責任共有モデルに基づく対象範囲の保護に集中
- セキュリティのベストプラクティスの自動化
-
信頼性（Reliability）
期待通りの機能を実行するワークロードと異常時に迅速に回復する方法に焦点を当てる- 基本対応領域は基盤、変更管理、障害管理
- 障害復旧の自動化による影響を軽減する設計を行う
- 復旧手順をテストして事前に検証しておく
- 需要変化に応じた水平方向へのスケーラビリティによる高可用性を確保する
- モニタリングと自動化を進める
- キャパシティの推測をやめる（オートスケーリング）
-
パフォーマンス効率（Performance Efficiency）
IT およびコンピューティングリソースの構造化、合理化された割り当てに焦点を当てる- システム要件を満たすためのコンピューティングリソースを効率化する
- AWSサービスの進化に応じてAWSインフラの効率化を推進する
-
コストの最適化（Cost Optimization）
不要なコストの回避に焦点を当てる- 不必要なリソースを削減
- コストを計測して透明性のある費用賦課を実現（コストを分析していく）
- マネージド型サービスを利用して運用コストを削減
- 固定の償却コストを変動コストへと転換
- スケールによるコストメリットを享受する
- データセンターへの投資を不要にする
-
持続可能性（Sustainabillity）
実行中のクラウドワークロードによる環境への影響を最小限に抑えることに焦点を当てる
Well-Architected Framework の活用方法
準拠するために以下のガイドラインやツールなどが提供されている。
-
Well-Architected Framework ホワイトペーパー
クラウドの知識を深めるために提供される技術情報。
原則やベストプラクティスについて説明したり AWS クラウドでのシステム設計や運用に役立つガイダンスを提供している。 -
Well-Architected Framework パートナープログラム
AWS の SA または認定パートナーによる支援制度。
サポートを受けて実装やベストプラクティスの適用に関する助言や支援を得ることができる。 -
セルフチェック向けの Well-Architected Tool
ワークロードの状態を評価しベストプラクティスと比較するための無料ツール。
自身の AWS 環境やアプリケーションの設計を評価し、改善のための指針を得ることができる。
あくまでこれらはベストプラクティスを利用することで最適解や改善点を把握するため参考にするもので、絶対ではない。
要件定義を検討する材料、適切な設計の材料として、インフラ構成にリスクや改善点がないかを確認するものとして、運用として定期的にレビューを行う観点としてホワイトペーパーなどを使用すると良い。
まとめ
AWSの設計では「ベストプラクティスの理解」と「ビジネス要件とのバランス」が鍵となる。
ベストプラクティスを理解していればリスクだったり改善点に気付くことができるため、 ベストプラクティスを理解した上でビジネス的に判断すること が重要。