はじめに
こんにちは、そしてこんばんは。
クラウドインテグレーション事業部の大嵩です。
初めてAWS様のワークショップへ参加しましたので、レポートを投稿します。
参加したワークショップ
タイトル
耐障害性ワークショップ Resiliency Quest
内容
AWSを利用した障害対応、耐障害性についてクエスト形式で体験できるワークショップ
ワークショップのゴール
- AWS上でレジリエンス（回復力）を備えたシステムの設計ポイントが理解できるようになり、調達仕様書は設計書に正しく記載できる
- 実際に手を動かすことで具体的な実現方法のイメージをつける
レジリエンスとは
- 障害に備えた設計を行うこと
“Everything Fails All the Time”(故障しないものはない)
今回お話の中で紹介があった、AWS最高技術責任者のヴァーナー・ボーガス氏の言葉で
「常に障害が起こることを想定してアーキテクチャを設計していく必要がある」とのこと。
新卒で経験が浅い身ではありますが、予期しないことが発生する想定で動くことでリスクを減らしていくということを意識付けられるお言葉でした。
耐障害性について
耐障害性の重要性
- 公共システムは定めた時間帯は止めてはいけないという大前提がある
- 災害や障害のリスクは避けられない前提
耐障害性の確保
オンプレミス
- 物理的に離れた場所でのサーバーの調達、管理が困難
- バックアップ体制を維持するためには大幅なコストが必要
クラウド
- 物理サーバーのメンテナンスが不要
- 可用性とコストによって選択できる冗長性
よってクラウドでも障害の発生を考慮し、RTO/RPOを定め設計をする。
可用性を向上させるには
- MTBF(平均故障間隔)とMTTR(平均復旧時間)を向上・改善するアプローチが必要
主にマルチAZの活用や再起動時間の短いサービス、復旧対応の自動化を行うことで改善アプローチが可能。
詳細なアプローチについて以下に記載します。
耐障害性向上のアプローチ
- MTBFを長くする
- インスタンスの冗長化（マルチAZを活用）
- 過負荷の防止（キャパシティと使用率を見てバランス調整）
- テストによりバグや欠陥を排除
- 障害範囲の限定
障害復旧、運用性向上のアプローチ
Disaster Recovery（DR）目標について検討する
DRの目的と想定
- 大規模で低頻度のイベントに対応する（大規模災害など）
- 災害が起こる前のデータがどれだけ消えるのか
目標とは
- RTO（目標復旧時間）
- どれだけのデータを再作成、損失する余裕があるのか
- RPO（目標復旧時点）
- どれぐらいのスピードで復旧しなければならないのか
- ダウンタイムにかかるコスト
上記を考慮して目標を検討し、DR対応を実施することで大規模災害においても対応が可能となります。
DRのニーズ
コンポーネント単位でシステムの重要性をもとに目標設定を行い、
設計目標を差別化することで、可用性/DRの効果が発揮される。
FSI Resiliency Quest
今回のシナリオ
「My Bank」という銀行のお客様の「MyDigitalWallet」というサービスが不具合によりダウンしている状態。
お客様から来週までに解消したいとの要望。
構成
- ECS(on EC2)はシングルAZ、インスタンス1台の基本構成
- RDSもシングルAZ、マルチAZなし
クエストで通過すべき障害性テスト
- テスト1 ECSタスクの障害
- テスト2 EC2の障害
- テスト3 RDSインスタンスの障害
- テスト4 AZの障害
この障害性テストをパスするために、各リソースの構成を変更していくクエストになります。
使用するサービス
AWS Fault Injection Service
カオスエンジニアリングの原則に基づいて、AWS上のワークロードに対してフォールトインジェクション実験を行うマネージドサービス。
カオスエンジニアリングとは
システムの耐障害性を確認するため、意図的に障害を発生させて検証する手法のこと。
実際に注入されるフォールトイベント
- サーバーダウンのようなハードウェア障害
- 不正応答などのソフトウェア障害
- トラフィックのスパイクやスケーリングなど、障害ではないイベント
- 安定状態を破壊するすべてのイベント
テスト1 ECSタスクの障害
テスト1では、シングルAZで構成されているECSに対して、マルチAZ化やタスクをスケーリングすることによって耐障害性を高めるクエストです。
以下の画面からテストを実行し、ワークショップ限定のAWSマネコンから構成変更を行います。
テスト2 EC2の障害
テスト2では、EC2インスタンスが不通となってもダウンタイムなくアプリケーションが動作するように構成変更を行うクエストになります。
EC2インスタンスを使ったECSタスクが動いているため、インスタンス側もAutoScaling Groupを使ってスケーリングを行います。また、マルチAZ化も実施します。
テスト3 RDSデータベースの障害
テスト3では、RDSインスタンスに障害が発生してもアプリケーションが動作するように構成変更を行います。
基本構成として、シングルAZでの起動のためマルチAZ化を実施します。
テスト4 AZの障害
テスト4では、AZのうち1つに大規模障害が発生しマルチAZでの対応を検証するクエストです。
これまでのクエストを通してマルチAZ化を実施しているため、すんなり通過することができました。
残念ながらランクインならず
今回のクエストでは、実施したクエストごとにスコアが計算され、合計得点で上位10位の方には賞品があるとのことでした。
ですが、筆者は残念ながらギリギリランクインできず。。。
次回また挑戦したいと思います！
今回のワークショップの感想
- 自身の頭の中では理解できていたとしても、実際に手を動かしてテストを実施してみると思っていたよりも対応ができていないことがあると感じました。
- テストを入念に実施していないと、見落としてしまっている点があるかもしれないことへの気付きがありました。
- 障害に対して、避けられない前提でそれに対してどのように復旧させるのか、またどのように抑えていけるのかを考えて、今後お仕事の中でお客様に提案や対応策の提示をしていけるように意識していきたいと思います。
