信頼性の設計について解説します。
信頼性の確保
信頼性の確保するためには、スケーラビリティ・単一障害点の排除・コンポーネントの疎結合をおこないます。
その他、パフォーマンス効率やスケーラビリティを行ってください。
耐障害性の向上
- 別リージョンや別AZにバックアップを取得保管することで耐障害性を高めます
- 別リージョンや別AZへのスタンバイ構成を取ることで即座にフェイルオーバーなどの手順を検証します
- 事業継続性計画（BCP）を整備し、バックアップから復元やファイルオーバーなどの手順を検証します。
高可用性の確保
高可用性とは、アーキテクチャにより自動でシステムのダウンタイムを限りなくゼロにすることを言います。
「アーキテクチャ」は建築分野で多く使われている言葉です。建築におけるデザイン設計思想のことを意味していました。 ITに置き換えると「ソフトウェアやハードウェアの設計概念」となります。
設計における「手順」や「方式」と思ってもらえるとシックリくるんじゃないかと思います。
AWSアーキテクチャ設計
高可用なサービス
- S3
- IAM
- DynamoDB
- SWF
- Route53
- Lambda
高可用なアーキテクチャ設計
- EC2
- EMR
- Direct Connect
S3はイレブン９と呼ばれる耐久性が高く高可用性なストレージサービスの代表例です。
高可用性の非機能要件
| 目標復旧時間 | いつまでにシステムが復旧するかという目標時間を表す指標 |
| 目標復旧時点 | システム障害などでデータが損壊した際に、復旧するバックアップデータの古さの目標 |
| 耐障害性 | アプリケーションのコンポーネントに組み込まれた冗長性 |
| 復元可能性 | システム障害／災害発生時におけるサービス復旧に関わる機能とプロセスとポリシー |
| 拡張性 | 既存設計・構成において、アプリケーションの拡張性を確保する能力 |
高可用性を求めると当然コストUPや構成の複雑さが増しまう。
コストとのトレードオフです。
設計方法
AWSを利用する際は、配置構成や高可用性を達成するサービスを組み合わせて高可用性を実現していきます。
AWSのサービス配置により高可用性を高める
リージョンの選択
単一リージョンまたはマルチリージョンの選択
AZの選択
マルチAZ構成により高可用性を高める
VPCの設計
VPC設計（複数VPC利用／サブネット設計）により高可用性を高める
AWSサービスの利用
高可用性を実現するサービスをアーキテクチャ設計に組み込む
- Route53によるフェイルオーバー
- ELBによるロードバランサー
- CloudWatchによるモニタリング
- Auto-Scalingによるスケーラビリティの確保
- Lambdaによるスケーリング処理
- ElestiCacheを利用したキャッシュアクセス活用
ELBの概要
マネージド型のロードバランシングサービスで、EC2インスタンスの処理を分散する際に標準的に利用する
こういう場面で使われます。
- インスタンス間の負荷を分散する
- 異常なインスタンスを認識して対応する
- パブリック・プライベートどちらでも使用可能
- ELB自体も負荷に応じてキャパシティを自動増減するスケーリングを実施
- 従量課金で利用可能
- マネージドサービスなので管理が不要
- AutoScaling,Route53、CloudFormationなどと連携
主要機能
- ヘルスチェック
- 負荷分散
- SSLサポート
- スティッキーセッション
- ConnectionDraining
- S3へのログ保管
ELBタイプ
ALB(Application Load Balancer)
レイヤー７の対応が強化された単一ロードバランサーで、異なるアプリケーションへリスエストをルーティングが可能
- ✅ URLのパスに基いてルーティングが可能なパスベースルーティングが可能
- ✅ WebSocketとHTTP/2のリクエストを受付
- ✅ 1インスタンスに複数ポートを登録可能
- ✅ EC2インスタンスをターゲットグループに割り当てる際、複数ポートを個別のターゲットとして登 録することが可能なため、ポートを利用するコン テナをロードバランシング可能
- ✅ ターゲットグループでのヘルスチェックが可能
- ✅ アクセスログの情報追加
- ✅ EC2と同様に削除保護が可能
- ✅ ALB自体が自動的にキャパシティを増減
NLB(Network Load Balancer)
NLBは超低遅延で高スループットを維持しながら秒間何百リクエストを捌くように設計された新しいロードバランサー
- ✅ 開放型システム間相互接続 (OSI) モデルの固定IPアドレスを持つL4ロードバランサ
- ✅ 揮発性ワークロードを処理し、毎秒数百万のリクエストに対応できる能力
- ✅ VPC外のターゲットを含めたIP アドレスや静的IPアドレスでの登録可能
- ✅ 複数のポートで各インスタンスまたは IP アドレスを同ターゲットグループに登録可能
- ✅ 大規模アクセスが予測される際にCLBやALBで必要だったPre-warming申請が不要
- ✅ ALBやCLBはX-Forwarded-Forでアクセス元IPアドレスを判断していたが、NLBは送信元IPアドレスと送信元ポートの書き換えを行わないため、パケットからアクセス元が判断可能
- ✅ NLBはフォルトトレランス機能を内蔵したコネクション処理を持ち、数カ月から数年のオープンなコネクションを処理できる
- ✅ コンテナ化されたアプリケーションのサポート
- ✅ 各サービスの個別のヘルスステータスのモニタリングのサポート
CLB(Classic Load Balancer)
初期に提供されたELBであり、標準的なL4／L7におけるロードバランシングが可能だか、複雑な設定はできない。
- ✅ HTTP/HTTPSとTCP/SSLプロトコルのL4とL7 に対応
- ✅ Proxyプロトコルによる発信元IPアドレス識別
- ✅ ELBとバックエンドのEC2インスタンス間で HTTPS/SSL使用時にサーバ証明書認証を実施
- ✅ CLB配下のインスタンスは、全て同一の機能を 持ったインスタンスが必要
- ✅ 異なる機能に対してコンテントベースルーティングは出来ない
AutoScalingの概要
需要増によりトラフィック量が処理できなくなる前に、処理サーバを拡張することで対処する必要がある。 これをスケーラビリティの確保と言う。
スケーリングのタイプ
スケーリングタイプは垂直スケーリングと水平スケーリングの２タイプがあります。Auto-Scailingは水平スケーリングになります。
垂直スケーリング
拡張方法・・・スケールアップ：メモリやCPUの追加・増強
低減方法・・・スケールダウン：メモリやCPUの削減・低減方法
水平スケーリング
拡張方法・・・スケールアウト：処理する機器／サーバ台数を増加する
低減方法・・・スケールイン：処理する機器／サーバ台数を低減する
Auto-Scalingの要素
Auto-Scalingグループ
スケールするインスタンスの最大数など基本情報を設定する
- ✅ 起動インスタンスの最小数と最大数を設定する
- ✅ 今時点で必要な最適なインスタンス数 （Desired Capacity）の数量になるようにインスタンスを起動／終了を調整
- ✅ 起動台数をAZ間でバランシングする
- ✅ AZ障害時は障害のない別のAZにその分のインスタンスを起動する
Auto-Scaling Configuration起動設定
スケールアウトの際に起動するインスタンス内容を設定する
【主要な設定項目】
- ✅ AMI
- ✅ インスタンスタイプ
- ✅ セキュリティグループ
- ✅ キーペア
- ✅ IAMロール
まとめ
AWSアーキテクチャ設計する上で、これまで解説したように信頼性の確保と高可用性の確保することでシステムを止めない基盤作りができます。
これを実現するには、はやり基本が大事です。
AWSのサービス基本機能を習得しておくことが重要です。
そこから、色々なサービスを組み合わせ設計することで、信頼性と高可用性の確保ができるのではないかと思います。
次は「Route53」についてです。
前回の「Well Architected Framework」はこちら
コメント