[レポート] STG206 Data resiliency design patterns with AWS #reinvent #reinvent2022

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

セッション名 : Data resiliency design patterns with AWS

概要概要(機械翻訳) : 企業は、アプリケーションデータを保護し、アプリケーションスタック全体の耐障害性を高める、シンプルで完全なマネージドサービスを求めています。開発者は、使いやすく拡張性のあるアプリケーションデータサービスを求めています。両者とも、顧客の事業継続とディザスタリカバリ（DR）を確保するために、アプリケーションデータの回復力と保護を求めています。このセッションでは、AWSストレージのネイティブなデータ回復力機能から、AWS Elastic Disaster Recoveryを使ったDRソリューションまで、アプリケーションデータの回復力と保護設計について説明します。

スピーカー : Jay Rolette, Sr. Principal Engineer, AWS
Rajesh Vijayaraghavan, Sr GTM Specialist, Amazon

レポート

お客様は、24時間体制でデータを保護するシンプルなフルマネージドサービスを望んでいます。
また、アプリケーション・データの回復力と事業継続性の確保に重点を置いています。
そこで本日は、データ回復力とは何か、なぜそれが重要なのか、そしてその理由をお話しします。

What is data resliency?

データ回復力、高可用性、ディザスタリカバリ、これらの用語を聴衆の皆さんに説明していただけますか？

データ回復力とは、アプリケーションがコンポーネント間の部分的・断続的な障害に耐え、最終的に不測の事態から回復する能力を指します。

高可用性とは、サービス損失を防ぐことです。コンポーネントの故障のような、規模は小さいがより頻繁に発生する事象に対処することです。
優れたアプリケーション設計の原則の1つは、失敗を想定して設計することです。 Amazon の CTO である Werner Vogel が言うように、すべてのものは常に失敗しています。
弾力性のあるアプリケーションは、障害が発生しても継続的にサービスを提供します。

データ回復力のもう1つの側面はディザスタリカバリです。
ディザスタリカバリとは、サービスの損失から回復することです。
災害、ハリケーンや地震のような自然災害でデータセンターが浸水した場合も含まれます。
ネットワーク接続の喪失やサイト全体の停電のような技術的な障害、またはより一般的な人為的な行為も含まれます。

データ復旧には2つの重要な対策があります。
RTO、再び使えるようになるまでにどれくらいの時間がかかるかです。
RPO、どれだけのデータを失う余裕があるかということです。

Business impact of resilience is bigger than ever

高可用性に関する顧客の期待を超えて、データの回復力がビジネスに与える影響は非常に大きいのです。

IDC が 2020年に行った調査では、アプリケーションのダウンタイムにかかるコストは年間約12億5,000 万ドルから25億ドルであることが判明しました。

BCG は、主要なデータ回復力アーキテクチャへの投資によるコスト削減について、同様の調査を実施しました。 その結果、15 ～ 25% のコスト削減が可能であることがわかりました。

この数字は年々増え続けています。

Impact vs likelihood of failure

では、イベントの影響と失敗の可能性について見てみましょう。

意図しない人為的なミスは、最も一般的な出来事の1つです。
間違ったサーバーを再起動したり、間違ったバージョンのソフトウェアをデプロイしたり、依存関係の順番を間違えてデプロイしたり。 などなど、数え上げればきりがありませんが、自動化されていないことが主な原因です。

次は、負荷ベースの失敗です。
規模が大きくなるにつれて、リソースの量が負荷に追いつかなくなることです。

アプリケーションのアップタイムを維持する方法は、高可用性を設計することです。
人為的なミスや、データセンターが完全に停止した場合にも対応できるように設計することです。

高可用性のために設計する場合とディザスターリカバリーのために設計する場合の線引きをするとしたら、それはアプリケーションの重要度によって異なります。
スクリーンショットの青い線は、おそらくエンジニアリング・チームの一部が日常業務を行っていて、たった1つのデータセンターの問題でアイドル状態になってはいけないという、適切なポイントにあると思います。

リージョンレベルの停止は非常に稀なことです。ほとんどはマルチリージョンの設計をする価値はありません。
一方、航空会社のスケジューリング・システムや高速取引システムを考えてみましょう。 数分、数秒でもオフラインになると、ビジネスコストが高くなります。 このような場合、理想的なのはアクティブ・アクティブ設計またはマルチ・リージョン設計を行うことです。

Shared responsibility model for resilience

データ回復力のための共有責任モデルについてお話したいと思います。

レジリエンスはAWSとお客様の間で責任を共有するものです。
AWS は、クラウド上のすべてのアプリケーションを実行するインフラの耐障害性に責任を負います。

お客様は、クラウド上のアプリケーションの回復力に対して責任を負うことになります。
お客様は、アップデートやソフトウェアパッチを含むゲスト OS の責任と管理を負います。そして、アプリケーションソフトウェア、および AWS が提供するセキュリティグループのファイアウォールの設定に責任を持ちます。

ディザスタリカバリ戦略、すなわちバックアップ計画、データレプリケーション、データ保護計画など、本プレゼンテーションで取り上げる内容は、お客様の責任において実施されるべきものです。
ストレージ管理者やエンジニアリングチームだけでなく、ビジネスチームや法務チームにも相談する必要があるかもしれません。

AWS Regions and Availability Zones

データの耐障害性を確保するために、私たちの設計原則は、基盤となる物理インフラにおける単一障害点を排除することです。
世界中に30のリージョンがあり、それぞれに複数のアベイラビリティゾーンがあります。 96のアベイラビリティゾーンはそれぞれ独立して動作するように設計されており、障害隔離境界を提供します。
あるアベイラビリティゾーンで障害が発生しても、そのリージョン内の別のアベイラビリティゾーンのオペレーションに影響を及ぼしてはならないのです。 ですから、アベイラビリティゾーン独立性は、私たちがどのようにデータレジリエントを構築するかの基礎の1つです。

そのため、リージョナルストレージサービスは、アベイラビリティゾーンレベルの停電に対して回復力があり、高い耐久性を持っています。 S3、DynamoDB、そして Elastic File System、これらのサービスはすべて11 9 (イレブンナイン) の耐久性を備えています。
また、回復力を高めるために、オブジェクトのバージョニングやレプリケーション、ライフサイクル管理、スナップショットなどの拡張機能も利用可能です。

アベイラビリティゾーン独立性 Availability Zone Independence (AZI) を活用して、アプリケーションをマルチアベイラビリティゾーン、あるいはマルチリージョンで構築すると、高い耐障害性を実現可能です。

AWS customer persona and cloud journey

顧客のペルソナを考えてみます。

まず、オンプレミアが中心のお客様。
ストレージアレイにプライマリデータを保存しています。
セカンダリデータやバックアップの一部をクラウドに移行することで、まずはクラウドに足を踏み入れたいと考えています。

次に、ハイブリッドのお客様もいらっしゃいます。
アプリケーションの半分くらいはクラウドに、ミッションクリティカルなアプリケーションの半分くらいは、まだオンプレミスにあります。

3つ目は、最近よく見かけるようになった新興企業のお客様です。
デジタルネイティブのお客様は、オンプレミスのインフラを持たず、アプリケーションやワークロードは、クラウドを念頭に置いて設計されています。

この3つの顧客ペルソナすべてにとって最重要課題である、事業継続と災害復旧についても見ていきます。

オンプレミス ペルソナ

ということで、まずはオンプレミスのバックアップのユースケースを見てみましょう。
左側にあるように、典型的なオンプレミス・アプリケーションがあります。そして、典型的なオンプレミス・アプリケーションがあります。
このような場合、AWSのクラウドサービスを利用する最も簡単な方法は、バックアップをクラウドに移行することです。
Storage Gateway を使いクラウドにデータを移動します。バックエンドは S3 です。
また、ほとんどのエンタープライズバックアップソフトウェアが S3 と統合されています。

同じような使用例ですが、こちらをご覧ください。

このデザインパターンでは、顧客はまだテープを配備しています。 LTO テープベンダーは、今でも企業のお客様に大量のデータを販売していることをご存知でしょうか。
テープにバックアップを取り、それをバンカーサービスに移動し、長期保管に備えています。

Storage Gateway を使えば、物理的なテープライブラリを使う代わりに、仮想テープゲートウェイとなります。
前の使用例と同様に、お客様はデータをクラウドに向けることができます。
これにより、お客様はテープを購入する必要がなくなりました。 テープドライブを物理的にロードしたりアンロードしたりする作業は不要です。

ハイブリッド ペルソナ

次はハイブリッドペルソナです。
オンプレミスにワークロードを持つお客様を対象としています。

Amazon FSx for NetApp ONTAP を使用したハイブリッドストレージのユースケースを考えてみましょう。 これは、パートナーである NetApp と提携したマネージド・ファイル・サービスです。

このサービスを使うと、クラウドバーストと呼ばれることが使い方が可能です。
例えば、データがオンプレミスにあるとします。 FSx for NetApp ONTAP の FlexCache という機能を使えば、データをリモートでキャッシュできます。

オースチンのファイラーにオンプレミスでデータを保存しているとします。 リモート・ユーザーがシンガポールにいて、オンプレミスの NetApp で FlexCache を使用して、このデータへの低レイテンシーアクセスを必要としています。
シンガポールでには FSx for NetAPP ONTAP を使用します。この ONTAP インスタンスではツールライブラリの機能でオンプレミスからキャッシュをコピーします。 シンガポールユーザーは非常に低レイテンシーなアクセスを実現します。

Cloud bursting to accelerate workloads

ハイブリッドなケースでは、オンプレミスで大量のデータを生成している場合でも、クラウドのスケーラビリティと弾力性を利用したいケースがあります。
このケースにクラウドバーストを使用します。

NFSサーバーを保有するオンプレミスのお客様のケースを考えてみましょう。
データをオンプレミスの NFS ファイルシステムにプッシュしています。
研究パートナーはデータを直接 S3 にプッシュしているとします。

今まではデータ処理をオンプレミスで行っていましたが、顧客はクラウドの弾力性を気にいっています。 そこで SageMaker を使ってデータをトレーニングすることにしました。

このケースでは Amazon File Cache が有効です。
File Cache は完全に管理された高速分散キャッシュで、クラウドバーストを支援します。このサービスはオンプレミスとクラウドのレイテンシーを隠蔽します。

デジタルネイティブ ペルソナ

では、デジタルネイティブの顧客を見てみましょう。
このユースケースは、アプリケーションを大規模に運用し、データの可用性を確保することを目的としています。

3つのアベイラビリティゾーンにわたって弾力的なロードバランシングを行い、EC2 AutoScaling で負荷の増加に応じて新しいインスタンスをプロビジョニングします。
また、負荷が減少した場合には、その分スケールダウンしています。クラウドユーザーにとって費用対効果の高いソリューションです。

次にデータベース層ですが、Amazon のリレーショナルデータベース RDS は、オンプレミスと同じような仕組みになっています。
プライマリインスタンスがあり、そこでデータベースが更新されます。 その変更を他のアベイラビリティゾーンのレプリカにレプリケートします。 プライマリデータがあるアベイラビリティゾーンが何らかの理由でダウンした場合、レプリカの1つがプライマリとして引き継ぎます。

データレイヤーの可用性と耐久性を高める方法として、リージョナルサービスを利用する方法があります。
S3、DynamoDB と EFS についてはすでにお話しましたが、これらのサービスは自動的に複数のアベイラビリティゾーンにデータとコンピュートデータをレプリケートします。

デジタルネイティブのお客様が利用するもう1つの重要な要素は、サーバーレスアプローチです。
サーバーレスアプローチでは、AWS 側に責任分担を押し付けることができます。
デジタルネイティブの顧客のアーキテクチャは、通常、API Gateway のようなサービスを使いアプリケーションのインターフェースを提供します。
DynamoDB は低レイテンシーでウェブスケールの nosql ストレージとして使用します。 S3 は耐久性のある長期オブジェクト・ストレージとして、EFS は弾力性のあるファイル・ストレージとして、非常に複雑なワークフローに対応するために利用されます。
Step Functions を使ってオーケストレーションすることも可能です。サーバーレスアプローチは、イベントベースのアーキテクチャに適しています。

これらのすべてが揃ったとき、本当にこれらのコンポーネントが一体となったとき、デジタルネイティブの顧客にとって弾力性のあるアーキテクチャが見えてくるのです。

サーバーレスアプローチは、マルチアベイラビリティゾーンです。高可用性とフォールトトレランスが備わっています。

Multi-Region design considerrations

さて、マルチリージョンについて話を始めます。

クラウドのエンタープライズ設計では、オンプレミスの場合と同じ要件が求められるため、マルチリージョンのお客様向けの設計上の留意点を検討する必要があります。オンプレミスの場合と同じ要件があり、コンプライアンス上、複数のサイトにデータを複製する必要があります。

そこで、2021年後半にアクセスポイントを拡張し、S3 用のマルチリージョンアクセスポイントを立ち上げました。
これは、複数のバケットの前にある1つのグローバルエンドポイントです。 ネットワーク経由で最も近いデータのコピーに自動的にルーティングできます。 マルチリージョン・アプリケーションを最大60%高速化することができました。

FSX for NetApp ONTAPは、オンプレミスとAWSの両方にまたがって堅牢なレプリケーション機能を提供します。

EFS は、ファイルシステムの最新コピーを第2の AWS リージョンに保持したり、同じリージョン内で数分以内にレプリケートします。

これらに加えて、S3レプリケーション機能もあり、ディザスターリカバリーに非常に有効です。同じリージョンのレプリケーションも、リージョンをまたいだレプリケーションも数分以内に行うことができます。

マルチリージョンアーキテクチャには課題もあります。
マルチリージョンアーキテクチャには、パフォーマンスの回復力など、多くの利点があるかもしれません。 しかし、このマルチリージョンストレージの上にアプリケーションを構築することは、非常にチャレンジです。
リクエストを最も近いバケットにルーティングするカスタムリージョナルロジックが必要であり、さらにフェイルオーバーやレイテンシーベースのルーティングなど、より高度なトラフィック管理を実装すると、ロジックはさらに複雑になります。

Automatic traffic routing

S3 マルチリージョンアクセスポイントは、お客様が導入を検討される際の重要な機能です。
複数のリージョンにあるバケットにアクセスするための新しいユニークなグローバルホスト名です。

S3 への要求は、最もレイテンシーの低いバケットに自動的にルーティングされます。
ここでアニメーションを見ますと(実際に動画をご覧ください。25:24 あたりです)、

1. East US ユーザーが書き込んだデータは us-east-1 のバケットに書き込まれます
2. 他リージョンにレプリケーションされます
3. Asia ユーザーはマルチリージョンアクセスポイントを通じて ap-southeast-2 のバケットから読み込みます

Strategies for disaster recovery

ディザスターリカバリー戦略は、一般的にコストと運用の複雑さ、保護と復旧時間のバランスによって AWS の4つのアプローチに分類されます。

最初の1つはバックアップとリストアです。
低コストでデータを保護することができますが、データ復元には数時間から数日かかるかもしれません。
安価で、ノンクリティカルなアプリケーションに適しています。

ひとつ飛ばしてウォームスタンバイです。
ウォームスタンバイは、従来のオンプレミスでのディザスターリカバリーに非常によく似ています。 アプリケーションのセカンダリコピーを別の場所にプロビジョニングし、パッシブで動作させます。
データはアクティブリージョンからスタンバイにレプリケートされています。
フェイルオーバー時にセカンダリをスケールアップし、アクティブインスタンスにします。
ウォームスタンバイは、ビジネスクリティカルなアプリケーションの最小限のリカバリ時間とコストとの間で、良いバランスを提供します。

パイロットライトに戻ります。
パイロットライトは、ウォームスタンバイのコスト最適化版です。クラウド特有のものです。
ウォームスタンバイと同じようにデータも複製されますが、異なるのは、セカンダリロケーションが部分的にしかプロビジョニングされないことです。
フェイルオーバーを行う前に、アプリケーションのインスタンスをスピンアップして、それを実行し、スケールアウトする必要があります。 リカバリ時間はウォームスタンバイよりも長くなります。

マルチサイト・アクティブ・アクティブは、ダウンタイムが許されないミッション・クリティカルなアプリケーションの場合に採用します。
アプリケーションは複数の地域で稼動し、トラフィックはそれらの地域で負荷分散されます。 トラフィックは負荷とレイテンシーに応じて各地域に振り分けられます。 災害が発生して1つのサイトがオフラインになった場合、もう1つのサイトが動的にスケールアップする必要があるかもしれません。

Backup & Restore

ここでは、バックアップとリストアについて見ていきます。

ある AZ でシンプルなアプリケーションを EC2 で動作させています。 このインスタンスでは3種類のストレージが利用可能です。EBS ボリューム、EFS ファイルシステム、RDS インスタンスです。

ディザスタリカバリのためにこれらをバックアップするために、EBS ボリュームは EBS スナップショットを使用します。
EFS ファイルシステムは AWS バックアップを使用してデータを保護します。
RDSインスタンスはデータベースのスナップショットを行います。
トランザクションログを S3 バケットにプッシュしていれば、個々のトランザクションまで復元することが可能です。

もし、別のリージョンへリストアはするならどうしたらいいでしょうか。
S3 バケットと EFS ファイルシステムをバックアップリージョンにレプリケートすることです。
リソースの展開と復元に時間がかかるかもしれませんが、費用対効果の高いデータ保護が可能です。

Pilot Light

次に紹介するのは、コストと復旧時間のバランスが良いパイロットライトです。

スクリーンショットのアーキテクチャを見てください。このアーキテクチャは高可用性とスケーラビリティの両方を兼ね備えています。
しかし、データの回復力を高めるために、リージョン全体の停電に対応する能力も必要です。

右側が DR リージョンで、データベースのリードレプリカは一番下にあります。 クロスリージョンレプリカを使用してプライマリデータを数秒で複製しています。

DR リージョンでは、VPCを設定する、サブネットを設定する、ELB を設定する、EC2 AutoScaling を設定する、ここまでやっておきます。 しかし、インスタンス数はゼロにしておきます。

DR リージョンは基本的にゼロインスタンスで構成されますが、DR リージョンをアクティブにするには、どうすればいいでしょうか。
DR リージョンのリード・レプリカをプライマリに昇格させます。 これで、書き込みができるようになります。
EC2 AutoScaling の起動台数を増やしアプリケーションを実行するようにします。
そして最後に Route 53 でルートウェイトを更新し、クライアントを DR リージョンに送ります。

もう一つのパイロットライトデザインパターンです。
オンプレミスのデータセンターで稼働している顧客が、DR サイトとして AWS を使用しているハイブリッドシナリオを見てみましょう。

Elastic Disaster Recovery (EDR) をを使用することで、このシナリオを非常に簡単かつコスト効率よく実現します。
オンプレミスのサーバーにレプリケーションエージェントをインストールします。
その後、ブロックレベルのレプリケーションが開始されます。レプリケーションは圧縮・暗号化されています。

フェイルオーバーが必要な場合は、他のパイロットライトデザインパターンと同様です。 すべてのリソースをプロビジョニングし、数分でアプリケーションをオンラインに戻すことができます。

Warm Standby

ウォームスタンバイのデザインパターンを見てみましょう。

パイロットランプのデザインパターンにとてもよく似ていることにお気づきでしょう。
唯一の違いは、アクティブなアプリケーションサーバーが DR リージョンにあることです。
フェイルオーバーをより迅速に行うことが可能です。

パフォーマンスの観点から、全負荷を処理するのに十分なインスタンスをスピンアップするために、オートスケーリンググループを調整する必要はあります。
しかし、RTOはより高速になります。パイロットライトとウォームアップのどちらかを選択かは、出費を正当化するために数分または数十分の RTO が必要かどうかにかかっています。

Multi-Region Active/Active

ダウンタイムやデータ損失が絶対に許されないような大企業の場合は、マルチリージョン・アクティブ・アーキテクチャを採用することになります。

まず、一番上の Route 53 ですが、この両側がアクティブになっていることに注目してください。 これはクライアントを両方のリージョンにフルタイムで転送しています。

そして、両方のリージョンで Auto Scaling Group がずっと起動しています。

一番下にあるのは、DynamoDB の場合です。 データストレージを RDS から DynamoDB に変更しました。DynamoDB はリージョナルサービスです。 AZ レベルの停止やリージョン全体のイベントから私たちを守ってくれます。

アプリケーションは、ローカルに書き込んで競合書き込みに対処するか、グローバルに書き込んで高いレイテンシに対処するかを選択する必要があります。

このようなアクティブ・マルチリージョンの設計は、最高のデータ回復力を提供しますが、それに伴うコストと複雑さはかなりのものです。

Serverless

では、ディザスターリカバリーのためのサーバーレスアプリケーションを見てみましょう。

トップに Route 53 があり、クライアントをアクティブリージョンへ誘導しています。
API Gateway は並列の Lambda 関数の束をスピンアップします。そのため負荷に応じてスケールアップします。
スタンバイリージョンと同期するために、グローバルテーブルを持つ DynamoDB を使用しています。

災害が発生した場合、Route 53 のウェイトを更新することで、プライマリージョンからフェイルオーバーすることが可能です。

さらに両方のリージョンのウェイトを同じにすると両方をアクティブにできます。
サーバーレスでないアプローチよりはるかに複雑さが軽減されます。
サーバーレスはデータ復旧のためのイージーモードであると、私たちは強く信じています。

Importance of data protection

さて、ここまで、データ回復力のための一般的なデザインパターンを、あらゆる角度から見てきました。 しかし、どのような種類のデータであっても、データ保護の重要性について語らないのは不注意を招きます。

どのようなデータディザスタリカバリ戦略を選んだとしても、レプリケーションはある種のデータ損失を防いでくれます。
しかし、不正なデータを書き込むソフトウェアから保護することはできません。
ユーザーが誤ってデータベースのテーブルやファイルを削除してしまうことも防げません。
また、悪意ある人物による背後のデータの改ざんから保護することもできません。

どうすればこのような事態からデータを守り、データを復元できるようになるのでしょうか。

本番アカウントでは、適切なバックアッププランでバックアップヴォルトをセットアップして、データを保護します。

完全に独立したアカウントを作成します。 データバンカーアカウントと呼ぶことにします。 データバンカーアカウントは、本番用アカウントで設定した認証や権限とは関係ありません。
Vault Lock と呼ばれる機能を有効にし、コンプライアンスモードに設定します。 コンプライアンス・モードでは、バックアップは不変です。
これはランサムウェアに対する究極の防御策です。

本番アカウントで取得したバックアップをデータバンカーアカウントにコピーします。
そして、AWS Backup Audit Manager のようなものを使って、監査レポートを作成します。

もしも本番アカウントに侵入された場合、侵入者が行ったすべての操作を把握するのは困難です。
ベストプラクティスでは、すべてを本番アカウントに復元するのではなく、 新しいリカバリーアカウントを作成し、そこにデータバンカーアカウントからデータをコピーします。
データコピーが終わったらアプリケーションを復元し、サービスをオンラインに戻します。

Testing resiliency

さて、弾力性を考慮した設計をすることは一つの方法ですが、それが実際に機能するかどうかを知る唯一の方法はテストすることです。
スケールすることを確認し、AZ やリージョンをまたいでフェイルオーバーできることを確認することです。
バックアップをとっていて、RPO や RTO、SLA のテストしていないとすると、本質的にお金を無駄にしていることになります。
ランブックを作成し、メカニズムが適切に機能しているかどうかを継続的にテストする必要があります。

What is AWS Resilience Hub?

私たちのサービスの1つに、AWS Resilience Hub というものがあります。
これは、アプリケーションの回復力を定義し、検証し、追跡するための中心的な場所を提供するサービスです。

ここでは、Resilience Hub で行うステップを簡単に説明します。

ステップ1では、まずインフラをコードとしてインポートします。

2番目のステップは、レジリエンス・ポリシーを作成することです。 このアプリケーションの目標 RPO RTO を定義します。

3番目のステップでは、評価を実行します。
リソースを照会し、設定を理解した上で、お客様が SLA を達成できるかどうかの評価を行います。
例として、単一のアベイラビリティゾーンRDSインスタンスを持っているとします。 そのバックアップがある しかし、マルチ AZ ではない場合、その回復力を理解する必要があります。 RTO が非常に低いとしたらどのように回復できるかもお伝えします。
推奨される構成についても説明します。 RDSをマルチ化するのが良いのではないでしょうか？ CloudWatch Alarm や標準操作手順を使ってリカバリをテストするなどの運用上の提案もします。

ステップ4では、レジリエンス・ハブからの推奨事項の一部または全部を実行に移します。
FIS と呼ばれるものがあります。これは、レジリエンスをテストするための実験を行うものです。 これを CI/CD パイプラインに組み込むと、新しいソフトウェアがリリースされたときに、これを継続的にチェックできます。

最後のステップでは、ダッシュボードが用意されています。
計算された回復力スコアがあり、姿勢を改善し続けることができます。

Chaos engineering

カオスエンジニアリングの話しましょう。
人為的に破壊的な事象を発生させ、アプリケーションにストレスを与えるプロセスです。
簡単なレベルの障害に対してアプリケーションがどのように反応するかを、実際に簡単な障害が発生するのを待つことなく確認できます。

AWS Fault Injection Simulator の出番です。
アプリケーションにストレスを与え、どのような挙動をするかを観察することができます。 そして、回復力とパフォーマンスを向上させることができるのです。
データの回復力は技術的な問題ではなく、組織全体の問題であるということを念頭に置いてください。 組織全体が、そして社員やプロセスも、積極的にその定義に関与すべきものなのです。

ゲームデイは、社員とプロセスがそれに従うことを確認するために有効な概念です。
例えば、データベースがダウンした場合、オンコールのサポーターである SRE エンジニアがどのように対応しているかを把握できます。
どのようなプロセスで、ランブックはあるのか、重要な問題を診断するのに十分な観測性あるか、などです。

ゲームデイは人、プロセス、技術を含むイベントの完全なシミュレーションです。
それぞれの役割分担を決めて、分野横断的なゲームチームを編成し、状況を計画します。
誰かに連絡するのにかかる時間を確認するために、オブザーバーを用意する必要があります。
このようなシナリオに対応するための十分な資料やドキュメントを再度用意する必要があります。

所感

マルチゾーン、マルチリージョンで高い可用性を実現するためには、データの回復性が重要だと考えます。
データをどれだけ複数の場所に配置するか、そして正しくレプリケートするかは事業継続性の観点で最重要ポイントです。

本セッションでは、データ回復性をどのようにデザインするべきか詳しく解説されています。データを第一に考えてデザインとなっています。
様々なパターンを実践的に紹介しているので、幅広いエンジニア層から指示させるセッションではないでしょうか。

以上、吉井 亮 がお届けしました。