AWS SysOpsに関する知識をまとめたい (信頼性・ビジネス継続性 後編)

はじめに

こちらの記事では、前回の記事を引き続き信頼性・ビジネス継続性を高めるための各種AWSサービスを見ていきます！

本記事はAWS認定資格試験テキスト AWS認定SysOpsアドミニストレーター - アソシエイト(SBクリエイティブ) - 「信頼とビジネス継続性」 の章の後半部分を参考に整理しています。

前回の記事はこちら → 前回記事

(続) 高可用性と耐障害性のある環境の構築

シングル AZ とマルチ AZ

シングルAZとマルチAZの話へ入る前に、まずは「リージョン」と「アベイラビリティゾーン」について軽くおさらいしてみます。

名称	意味・役割
リージョン	データセンターの所属している領域のこと 例)東京リージョンはap-northeast-1
アベイラビリティゾーン	リージョン内におけるデータセンターの集まり。ゾーンは互いに分離されており、障害による影響を最小限に抑える

AZはリージョンに内包されている感じですね。

シングルAZはその名の通り単一のAZで、マルチAZは複数のAZで運用することを指します。
これにより、例えばデータベース（RDS）があったとき、インスタンスAが落ちてしまってもインスタンスBに切り替えてサービスを継続させることができるわけです。

次は実例で見てみます。

よく使われるRDSと、AZと関連性があるElastic File System（以下、EFS）を例に、マルチAZ構成の比較をしてみます。

サービス	マルチAZの扱いと恩恵	フェイルオーバー	シングルAZ時の挙動
RDS	作成時に「シングルAZ / マルチAZ」をどちらか決める。マルチAZにすると別AZにセカンダリ機を配置し、AZ障害時もDBが継続利用できる	プライマリ障害時に自動でセカンダリ機へ切り替え（通常60〜120秒）	利用中のAZで障害が発生するとDBが停止してしまう
EFS	標準ストレージクラスはデフォルトで複数AZに自動分散され、AZ障害時もファイルシステムへのアクセスが生きる	ユーザー側の切り替え操作なしで継続	「One Zone」ストレージクラスを選んだ時だけシングルAZ構成になり、そのAZが障害になるとアクセス不可になる

Route 53 のルーティングポリシー

Route 53については前回の記事のヘルスチェックのところで少し触れました。

ヘルスチェックは（1日に何度も行う）システムの定期検診のことでしたが、
ルーティングポリシーは、「リクエストが来た時に、どのようにユーザーに応答を返すかを決めたルール」のことです。
交通整理の役割を担ってくれます。

単一のポリシーで運用されているものは「シンプルルーティング」と呼ばれますが、ここではそれ以外の、特徴的なポリシーに関していくつか見ていきます。

フェイルオーバー

フェイルオーバー（failover）とは、システムで異常が発生した時に、自動的に待機しているシステムに切り替えることをいいます¹。

通常使うリソースAとは別のリソースBを用意しておき、Aに障害が起きた時にリクエストがBに流れるようにする設定です。

ヘルスチェックでAが落ちたと検知された瞬間にリソースBへ切り替わります。

加重

加重（weighted）ルーティングは、各リソースに「重み（weight）」を割り当てて、その比率に応じてリクエストを振り分けるルーティングポリシーです。

例えばリソースAに重み90、リソースBに重み10を設定すると、リクエストの90%がA・10%がBに流れるようになります。

主な使い道としては、以下のようなものがあります。

• A/Bテスト: LP（ランディングページ）を2パターン用意し、50:50で振り分けてクリック率などを比較したい
• 段階的リリース: 1% → 10% → 50% → 100%と徐々に新環境へ寄せたい

レイテンシーベース

レイテンシーベース（latency-based）ルーティングは、複数のリージョンにリソースを置いておき、ユーザーから見て一番ネットワーク遅延が小さいリソースにリクエストを振り分けるポリシーです。

「物理的に近い」ではなく「ネットワーク的に速い」で判定するのがポイントで、Route 53 が AWS 内部で計測しているデータを元にルーティング先が決まります。

グローバルにサービス展開していて、ユーザーの体感速度（UX）を上げたいときに有効です。

---

なお、ここで紹介した3つ以外にも、

• 位置情報
• 地理的近接
• マルチバリュー応答
• IPベース

といったルーティングポリシーが用意されています。本記事では名前に触れるだけになってしまいますが、それぞれに適切なユースケースがあるので目的にあった利用が大事ですね。

バックアップとリストア戦略

次に、データのバックアップとそれを復旧させる仕組みについてみていきます。

スナップショットとバックアップの自動化

いきなり本題に入る前に、目標復旧時間(RTO), 目標復旧地点(RPO), 保持ポリシー　という概念について簡単にまとめてみました。

名称	意味
目標復旧時間(RTO)	障害発生から、システムやデータを復旧して業務を再開するまでに許容する時間
目標復旧地点(RPO)	最大で過去どの時点までデータを失って良いか
保持ポリシー	過去何世代分（もしくは何日間）バックアップを保持するか

• RTOは、当然ですが短ければ短いほど好ましいですね。
• RPO=1時間　-> 1時間ごとにバックアップを取る
• Herokuなどマネージドなホスティングサービスでは（プランによりますが）サービス側で保持ポリシーが決まっていたりすることもあります。

これらの概念を踏まえて、AWSでバックアップを自動化する代表的なサービスを2つ見ていきます。

AWS Backup

複数のAWSサービスのバックアップを一元的に管理できるフルマネージドサービスがAWS Backupです。

複数のAWSサービスに異なって散らばっているバックアップを、ひとつのプランにまとめて自動化できる、というのが大きな特徴です。

対応しているサービスとしては

• EC2 / EBS
• RDS / Aurora
• DynamoDB
• S3

などなど、他にもさまざまあります。

例えば

毎日午前3時にスナップショットを取得して35日間保持し、別リージョンへもコピーする

といったプランをRDSにだけでなく、対応サービスにまとめて適用できます。
多種多様なAWSサービスを運用して成り立っている巨大なサービスで使われるイメージでしょうか。

☆余談になりますが、
小〜中規模のアプリではなかなかお世話になる機会が少なそうだな...と思いきや、監査などに活用できるレポート機能、データをロックする機能などもあるそうで、そういった使い方をすることもあるようです。

Amazon Data Lifecycle Manager（DLM）

Amazon Data Lifecycle Manager（DLM） は、Elastic Block Store（EBS）スナップショットとAmazon Machine Image（AMI）に特化した自動化サービスです。AWS Backupより古いサービスで、より軽量な仕組みになっています。

ライフサイクルポリシー ... データが作成〜破棄されるまでの全過程（=ライフサイクル）を自動的に管理・運用するための方針

EBSとAMIについてはここでは深く触れないようにしますが、DLMでは「どのリソースを・いつ・どれだけ残すか」を、1つのライフサイクルポリシーとして定義します。そのあとはポリシーに沿って自動で管理されます。

<<設定内容>>

1. （どのリソースを）対象を タグ で指定　
   • 例: Backup=daily というタグが付いたEBSボリュームを対象にする
2. （いつ）スケジュール設定
   • 例: 毎日午前2時に取得
3. （どれだけ残すか）保持ポリシー設定
   • 例: 直近7世代を保持、古いものから自動削除

タグで対象を指定する仕組みなので、対象が増減した時もタグを付け外しすれば自動で追従してくれます。

データベースのリストア

バックアップを取るだけでなく、戻す側の手段も見ておきます。

RDSにてよく使われるリストア手段は主に3つあります。

手段	戻せる時点	主な使い道
ポイントインタイムリカバリ（PITR）	任意の時刻を指定可能（直近の数分前まで）	オペミスや論理障害から「直前の状態」に戻したい
スナップショットからの復元	スナップショット取得時点	定期バックアップから戻す、別環境への複製
リードレプリカの昇格	レプリケーションラグ分の遅延あり	プライマリ障害時にリードレプリカを昇格させてDBを継続

PITR、スナップショットからの復元はなんとなくイメージしやすいですが、リードレプリカについて整理したい。

リードレプリカの昇格

リードレプリカは、プライマリDBの内容を非同期レプリケーションで同期し続けている読み取り専用のコピーです。

ふだんは読み取り処理を肩代わりして負荷を分散する役割を担いますが、いざプライマリが壊れた時には、このレプリカを**昇格（promote）**して書き込み可能な本番DBに切り替えることができます。

ただしレプリケーションはあくまで非同期なので、まだコピーが追いついていない分（レプリケーションラグ分）のデータは失われる可能性がある点には気をつける必要があります。

S3 のバージョニング・ライフサイクル

S3 が持っている、信頼性・ビジネス継続性につなげるための機能たちです。

バージョニング

バージョニング は、S3バケットにおけるオブジェクトの過去のバージョンをすべて保持する機能です。Gitのイメージそのままですね。

普通、同じキーで上書きしたり削除したりすると元のオブジェクトは消えてしまいますが、バージョニングを有効にすると以下のような挙動になります。

• 上書きしても、過去バージョンが履歴として残る
• 削除しても、削除マーカー が付くだけで実体は残る（特定のバージョンIDを指定すれば取り出せる）

ただし、古いものを放置してしまうとコストもその分かかってきてしまうため、後述のライフサイクルルールと組み合わせて「古いバージョンは自動で削除」のような設定をするのが定石です。

ライフサイクルルール

S3オブジェクトを経過日数に応じて別のストレージクラスに移したり、削除したりする自動化の仕組みです。

S3 には、アクセス頻度に応じた複数のストレージクラスが用意されています。

ストレージクラス	想定アクセス頻度	コスト感
S3 Standard	頻繁にアクセスする標準クラス	高
S3 Standard-IA	月1回程度の低頻度アクセス	中
S3 Glacier Instant Retrieval	四半期に1回程度・即時取り出し可	低
S3 Glacier Flexible Retrieval	数分〜数時間で取り出し	より低
S3 Glacier Deep Archive	12時間程度で取り出し、長期保管向け	最低

デフォルトは「S3 Standard」が適用されるようになっています。

これに対して、ライフサイクルルールで例えば次のような設定をしておくと「そこまで利用頻度はないにしろ、削除は避けたい」といったものでも、自動でストレージコストを下げていくことができます。

• 作成 30日後 → Standard-IA に移行
• 作成 90日後 → Glacier Flexible Retrieval に移行
• 作成 365日後 → 削除

おわりに

今回は信頼性とビジネス継続性の後半として、マルチAZ・Route 53のルーティングポリシー・バックアップとリストアまでを整理しました。

前回・今回を通して見てみると、信頼性・ビジネス継続性の話は「障害が起きないようにする」のと「発生時にできる限り早く戻せるようにする」の両輪で組み立てていくものなんだなと改めて感じました。

また、普段は聞きなれない細かい専門用語もちらほらありましたね。なかなか普段の業務でこういったワードを直接使って会話をすることは少ないですが、いざというときの考え方として身につけておく必要がありそうです。

最後まで読んでくださりありがとうございました！

参考記事

• データはどのようにバックアップするのですか? - AWS Well-Architected

1. 手動で切り替えることを「スイッチオーバー」といいます。 ↩