AWSコアサービス２
AWSアーキテクチャの設計原則
５つの設計原則
Well-Architected Frameworkは次の５つの原則で構成される。
・回復性の高いアーキテクチャを設計する → Reliability
・パフォーマンスに優れたアーキテクチャを定義する → Performance Efficiency
・セキュアなアプリケーションおよびアーキテクチャを規定する → Security
・コスト最適化アーキテクチャを設計する → Cost Optimization
・オペレーショナルエクセレンスを備えたアーキテクチャを定義する → Operational Excellence
●Reliabitity（信頼性）
●Perfomance Efficiency（パフォーマンス効率）
●Security（安全性）
●Cost Optimization（コスト最適化）
●Operational Excellence（運用上の優秀性）
Well-Architected Framework
次の３つの内容で構成される。
❶Well-Architected Framework ホワイトペーパー
❷AWSのSAまたは認定パートナーによる支援制度
❸セルフチェック向けのWell-Architected Tool
ベストプラクティスを利用することで最適解や改善点を把握する。
あくまで参考であり絶対というものではない。
・要件定義
AWSを利用したシステム要件を検討する材料として
ホワイトペーパーを確認して最適な要件検討に利用する。
・設計
設計においてホワイトペーパーを確認しながら、適切な設計方式を検討する。
・構築
リリース前にAWSのインフラ構成にリスクや改善点がないか
ホワイトペーパーに基づいて確認する
・運用
運用中に定期的にホワイトペーパーに沿ったレビューを実施し、
リスクや改善点がないか確認する
AZの選択
１つのリージョンにつき２つのAZを利用してアーキテクチャーを設計することが基本。
※３つ以上はコスト効率が低下する。
マルチAZ構成
マルチAZにサーバーやDBの冗長構成を確立させることで高い可用性を実現する。
マルチリージョン構成
Route53を介して、２つの同じシステム構成をフェイルオーバーすることが可能。
Well-Architected Toolの確認
Well-Architected Toolは構築中または運用中のアプリケーションがベストプラクティスに沿っているかを検証できるツール。
Well-Architected Toolの定義
Well-Architected Toolの独特の用語を理解して、利用していく。
●ワークロード
ウェブサイト、ECサイト、モバイルアプリのバックエンド、分析プラットフォーム
などビジネス価値をもたらす一連のコンポーネントが特定する
設計、テスト、実稼働、本稼働の製品ライフサイクルを通じて
進捗するアーキテクチャでの重要な変更内容のこと
●レンズ
改善すべき分野を特定する一貫した方法
●高リスクの問題（HRI）
ビジネスに最大な悪影響を及ぼす可能性があるアーキテクチャおよび運用上の問題
●中リスクの問題（MRI）
その程度はHRIより低いビジネス上の問題
ELBの概要
ELB（Elastic Load Balancing）
マネージド型のロードバランシングサービスで、EC2インスタンスの処理を分散する際に標準的に利用する。
・インスタンス間の負荷を分散する
・異常なインスタンスを認識して対応する
・パブリック / プライベートどちらでも使用可能
・ELB自体も負荷に応じてキャパシティを自動増減するスケーリングを実施
・従量課金で利用可能
・マネージドサービスなので管理が不要
・Auto Scaling、Route53、Cloud Formationなどと連携
ELBの主要機能
●ヘルスチェック
EC2インスタンスの正常 / 以上を確認し、利用するEC2の振り分けを行う
●負荷分散
配下のEC2の負荷に応じて、複数のAZに跨るEC2インスタンスの負荷分散を行う
●SSLサポート
ELBでSSL Terminationできる
●スティッキーセッション
セッション中に同じユーザから来たリクエストを全て同じEC2インスタンスに送信
●Connection Draining
インスタンスが登録解除されるか異常が発生した場合に、
そのバックエンドインスタンスへの新規リクエスト送信を中心する
●S3へのログ保管
ELBのアクセスログを指定したS3に自動保管
負荷分散によるスケーラビリティとヘルスチェックによる高可用性を実現。
スケーラビリティの確保
複数のEC2インスタンス / ECS Serviceへの負荷分散
トラフィックの量を分散できる
高可用性
複数のアベイラビリティゾーンにある複数のEC2インスタンスECS Serviceの中から
正常なターゲットにのみ振り分け
ELBのタイプ
現在利用できるロードバランサーは３タイプで用途に応じて使い分ける。
CLB（Classic Load Balancer）
初期に提供されたELBであり、標準的なL4 / L7におけるロードバランシングが可能だが複雑な設定はできない。
・HTTP / HTTPSとTCP / SSLプロトコルのL4とL7に対応
・ELBとバックエンドのEC2インスタンス間で
・CLB配下のインスタンスは、全て同一の機能を持ったインスタンスが必要
・異なる機能に対してコンテントベースルーティングは出来ない
ALB（Application Load Balancer）
レイヤー７の対応が強化された単一ロードバランサーで、異なるアプリケーションへリクエストをルーティングが可能。
・URLのパスに基づいてルーティングが可能なパスベースルーティングが可能
・WebSocketとHTTP/2のリクエストを受付
・１インスタンスに複数ポートを登録可能
・EC2インスタンスをターゲットグループに割り当てる際、
複数ポートを個別のターゲットとして登録することが可能なため、
ポートを利用するコンテナをロードバランシング可能
・ターゲットグループでのヘルスチェックが可能
・アクセスログの情報追加
・EC2と同様に削除保護が可能
・ALB自体が自動的にキャパシティを増減
CLBとALB
ALBはパスルーティングによりCLBより容易にバランシング構成が可能。
NLB（Network Load Balancer）
NLBは超低遅延で高スループットを維持しながら秒間何百万リクエストを捌く様に設計された新しいロードバランサー。
・開放型システム間相互接続（OSI）モデルの固定IPアドレスをもつL4ロードバランサ
・揮発性ワークロードを処理し、毎秒数百万のリクエストに対応できる能力
・VPC外のターゲットを含めたIPアドレスや静的IPアドレスでの登録可能
同一ターゲットグループに登録可能
・大規模アクセスが予測される際にCLBやALBで必要だったPre-warming申請が不要
・ALBやCLBはX-Forwarded-Forでアクセス元IPアドレスを判断していたが、
NLBは送信元IPアドレスと送信元ポートの書き換えを行わないため、
パケットからアクセス元が判断可能
・NLBはフォルトトレランス機能を内臓したコネクション処理をもち、
数ヶ月から数年のオープンなコネクションを処理できる
・コンテナ化されたアプリケーションのサポート
・各サービスの個別のヘルスステータスのモニタリングのサポート
Auto-Scalingの概要
５つの設計原則と１１のベストプラクティス
使い捨てリソースの使用
サーバーなどのコンポーネントを一時的なリソースとして利用・設計する。
スケーラビリティの確保
需要増にトラフィック量が処理できなくなる前に、処理サーバーを拡張することで対処する必要がある。
スケーリングのタイプ
スケーリングタイプは垂直スケーリングと水平スケーリングの２タイプ。
Auto-scalingは水平スケーリング。
●垂直スケーリング
スケールアップ
メモリやCPUの追加・増強
スケールダウン
メモリやCPUの削除・低性能化
●水平スケーリング
スケールアウト
処理する機器 / サーバー台数を増加する
スケールいん
処理する機器 / サーバー台数を低減する
Auto-Scalingの要素
Auto-Scalingは主に次の３つの要素で構成される。
１、Auto-Scalingグループ
２、Auto-Scaling configuration起動設定
３、スケーリングプラン
Auto-Scalingグループ
スケールするインスタンスの最大数など基本情報を設定する。
・起動インスタンスの最小数と最大数を設定する
・今時点で必要な最適なインスタンス数（Desired Capacity）の数量になる様に
インスタンスを起動 / 終了
・起動台数をAZ間でバランシングする
・AZ障害時は障害のない別のAZにその分のインスタンスを起動する
Auto-Scaling Configuration：起動設定
スケールアウトの際に起動するインスタンス内容を設定する。
主な設定項目
・AMI
・インスタンスタイプ
・セキュリティグループ
・キーペア
・IAMロール
Auto-Scaling Plan
どの様にスケールするかの方法を定義する。
●Auto-Scaling Groupサイズの維持
現在のAuto-Scaling Groupのインスタンス最小台数を維持する設定をする
●手動スケーリング
設定外で予期せぬスケーリングが必要となった場合に手動でスケーリングを実施
●スケジュールベース
予測された需要増時期に合わせたスケーリングスケジュールを設定
●動的スケーリング
予測不能なケースにスケーリングポリシーにスケール方針を設定して、
動的にスケールアウトを実施
Auto-Scaling Plan
Auto-Scaling Planは複数組み合わせて利用することができる。
ヘルスチェック
Auto-Scaling配下のEC2のヘルスチェックにはEC2のステータス情報またはELBのヘルスチェックのどちらかを利用する。
●EC2ステータス
インスタンスのステータスがrunning以外の状態を異常と判断
●ELB
ELBのヘルスチェック機能を活用する
ELBとAuto-Scalingによる冗長構成の構築
EC2
ロードバランサー作成
ALBを選択
証明書を取得しているならHTTPSを選択
