はじめに
今回の記事では、信頼性を高めるための各種AWSサービスについて触れてみます。
本記事は『AWS認定資格試験テキスト AWS認定SysOpsアドミニストレーター - アソシエイト』(SBクリエイティブ) - 「信頼とビシネス継続性」 の章を参考に整理しています。
前回の記事はこちら → 前回記事
一般的に信頼性とは「指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力」とのこと。
ざっくり言うと、システムが想定通りに動き続けられる力ですね。
前回はCloudWatchで「何が起きているか観察する」話を中心に見ましたが、今回はその先の「そもそも止まらないようにする / 止まっても気付ける」仕組みについて
- 拡張性・伸縮性(負荷に応じてリソースを増減させる)
- 可用性・耐障害性(障害があっても動き続ける)
の2つの観点から、代表的なAWSサービスを見ていきます。
ユースケースに応じた拡張性と伸縮性の実現
まずは、拡張性と伸縮性を実現するための代表的な仕組みの１つであるAuto scalingから。
Auto scaling
Auto Scalingとは、AWSリソースを柔軟に増減させるためのサービス。
システムの負荷が上がったときのリソース不足を避けるなど、障害の発生回避に役立ちます。
「AWS Auto Scaling」「Amazon EC2 Auto Scaling」「Application Auto Scaling」の3種類があります。よく使われるのは一番最初に登場したEC2 Auto Scalingですかね。
スケールアウト・イン について
Auto Scaling周りで頻出する単語たちです。
- スケールアウト … サーバーの台数を増やすこと（負荷が上がったとき）
- スケールイン … サーバーの台数を減らすこと（負荷が落ち着いたとき）
スケーリングのオプション
AWSリソースをどのような基準・方法で増減させるかの設定が、スケーリングのオプションです。
これにも種類が様々あるようですが、代表的なものをここで見てみます！
| 名前 | 役割 | 特徴 |
|---|---|---|
| ターゲット追跡スケーリング | 指定メトリクスの目標値を維持するよう台数を自動調整 | 目標値を決めるだけで必要台数をAWSが自動計算。設定がシンプルで第一推奨 |
| スケジュールスケーリング | 決まった時刻に台数を増減する | 時間でアクセスの波が読める負荷に有効。予測ではなく予定ベースで動く |
| ステップスケーリング | メトリクスの大きさに応じて段階的に台数を調整 | しきい値ごとに増減幅を細かく設定可能。急激な負荷変動に対応しやすい |
※メトリクス:前回も触れた、CloudWatchが収集しているCPU使用率やリクエスト数などの数値そのもののこと、ですね。
さらに、EC2・ECS(Elastic Container Service)だけで利用できる「予測スケーリング」というものもありまして
過去のCloudWatchのメトリクスを機械学習でシステム負荷の動向を推測し、そのパターンに応じてスケーリングをしてくれます。
今時はユーザーがAIとCLIを組み合わせて分析するのはもはや当たり前になりましたが、予測から実際のスケーリングまでを行ってくれるマネージドな機能が用意されているのは強みですね。
水平方向のスケーリング・垂直方向のスケーリング
可用性を上げる方法であるスケーリングですが、
- 水平方向のスケーリング
- 垂直方向のスケーリング
の2つがあります。
先ほど触れたスケールアウト・スケールインは、「水平スケーリング」にあたります。リソースの数の増減。
対して、「垂直スケーリング」は、CPUやメモリなどのリソースのスペックを変更すること。
あげることをスケールアップ、下げることをスケールダウンと呼びます。上がる/アップ 下がる/ダウン なのでわかりやすいですね。
水平方向はなぜアウトとインなのか？ 参考程度にですがAI(Claude)に聞いてみました。
英語の "out" には「外に向かって展開する・広げる」というニュアンスがあるんです。
たとえば、spread out（広げる）、roll out（展開する）、lay out（並べる）、build out（増築する）。どれも「外に向かってバーッと広げる」イメージですよね。scale out もこの仲間で、「サーバーを中心から外側に向かって、どんどん並べ広げていく」という発想から来ています。
なるほど？ 横並び(水平)にマシンが増えて広がっていく、というイメージでしょうかね。
キャッシングの実装
以前に計算されたデータや、オリジナルのストレージデータをコピーしたものを保存し、高速アクセスするためのストレージであるキャッシュ。
ストレージへの負荷軽減や、データへの高速アクセスを実現できます。
AWSにおいてキャッシュを行える代表的なサービスとして、ElastiCacheやCloudFrontがあります。
ElastiCacheの概要
Amazon ElastiCacheは、よく使うデータをメモリ上に置いておいて、高速に読み書きできるサービスです。
キャッシュの定番であるMemcachedやRedisを、AWSがまるごと用意・管理してくれます。
例えばPHPフレームワークのLaravelでは、デフォルトのキャッシュの仕組みはデータベースを使うようになっていますが、ユーザーに公開して使ってもらうシステムではRedisを使うというのが定番で
ログイン状態（セッション）の保持や、毎回データベースまで取りに行く代わりに、キャッシュで返せるため、アプリの応答が速くなる＆データベースの負荷を軽減できます。
CloudFront の概要
Amazon CloudFront は、世界中に分散しているエッジロケーションから、画像や動画、CSS / JS などの静的コンテンツを配信するための CDN(Content Delivery Network) サービスです。
例えば日本にいるユーザーがアメリカのサーバーにアクセスすると、物理的な距離だけでも応答が遅くなりがちですよね。CloudFront を間に挟むと、ユーザーから一番近いエッジロケーションがキャッシュ済みのコンテンツを返してくれる、というイメージですね。
ElastiCache が「アプリ ⇔ DB」の間で頻出データをメモリに置いておく内向きのキャッシュなのに対して、CloudFront は「ユーザー ⇔ アプリ」の間で静的コンテンツを世界中にバラまく外向きのキャッシュ、と対比して覚えると整理しやすそうです。
Memcachedについては、こちらの記事がとても参考になりましたm(_ _)m
高可用性と耐障害性のある環境の構築
可用性とは、システムが使用できる状態を維持できる能力のこと。耐障害性とは、障害が起きてもシステムを維持できる能力のこと。ここからは、AWSにおける可用性と耐障害性の高い設計の仕方をみていきます。
ELB(Elastic Load Balancing)
EC2インスタンスやコンテナへ向かうトラフィックを自動分散させる、フルマネージドな負荷分散サービスです。負荷に応じてスケールアップやスケールアウトをしてくれます。ELBの中でも、ALBとNLBなど種類があったりします（名前が似ていて最初はややこしい）
「ELB」はサービス全体の名前で、実際に作成するリソースとしては次の3つに分かれます。
| 名前 | 役割 | 特徴 |
|---|---|---|
| ロードバランサー | クライアントからの通信を受け取り、複数のターゲットへ分散する入り口 | トラフィックの窓口。ALB / NLB / GWLB などの種類があり、可用性の向上と負荷分散を担う |
| リスナー | 指定したポート・プロトコルで接続を待ち受ける | HTTP:80、HTTPS:443 などポート / プロトコルごとに定義。受けた通信をルールに従って転送する |
| ターゲットグループ | 転送先のターゲット（EC2など）をまとめ、通信を振り分ける | ヘルスチェックで正常なターゲットにのみ通信を送る。ターゲットの登録単位となる |
ヘルスチェック
ターゲットに対して設定したプロトコルでアクセスを行い、正常にアクセスできるかをテストする操作がヘルスチェックです。
サイトに障害が起きたらすぐに復旧対応をしなければなりませんが、24時間張り付いてるわけにはいかない。
ヘルスチェックは指定した間隔でリクエストを送り、指定した回数失敗すれば異常と判断します。
（通知する仕組みは、Slackチャンネル, メールなど目的別に応じて別途作る必要があります）
ELBや、DNSのマネージドサービスであるRoute 53にもヘルスチェック機能があります。
ALB/NLB/GWLB
各種ELBについて、以下の表でまとめてみました。
| 名前 | 役割 | 特徴 |
|---|---|---|
| ALB（Application Load Balancer） | HTTP / HTTPS 通信を振り分ける | パスやホスト名など通信の中身に応じた柔軟なルーティングが可能。Webアプリ向けの定番 |
| NLB（Network Load Balancer） | TCP / UDP 通信を振り分ける | 超低レイテンシ・高スループット。静的IPを割り当て可能。大量通信や低遅延が必要な場面向け |
| GWLB（Gateway Load Balancer） | サードパーティの仮想アプライアンスへ通信を振り分ける | ファイアウォールや IDS / IPS などの検査機器を集約・スケールできる |
GWLBというのは私は聞き馴染みがなかったのですが、要は自前のセキュリティ検査機器(ファイアウォール等)に通してチェックさせたいときに使うものとのこと。
それぞれの通信の流れをざっくり図にするとこんな感じです。
普通のロードバランサー(ALB/NLB)は、アプリのサーバーに振り分けるのが目的ですが、GWLBは、通信をセキュリティの機器に振り分けて、検査済みのものを本来の宛先に進ませる、という役割。
普通にWebアプリを作って公開するならほぼ使わない部類のものですが、知識としては持っておくと良さそうですね。
おわりに
今回の章「信頼性とビジネス継続性」については一旦ここで区切りとさせていただき、
次回は後半の記事を投稿できればと思います！
最後まで読んでいただきありがとうございました。