AWSが定義する信頼性とは？Well-Architected Frameworkの『Reliability』ペーパーが群を抜いて面白い件（日本語ガイド）

こんにちは。DA事業本部の春田です。

AWSには様々な種類のホワイトペーパーが提供されていますが、『Reliability（信頼性）』のホワイトペーパーを読んだことはありますか？Well-Architectedフレームワーク五本柱のうちの一つです。ソリューション・アーキテクトを目指す方にとってはお馴染みでしょう。

このペーパー、めちゃめちゃ丁寧かつ面白いんですよ。読んだことがある人にはわかると思うのですが、5つのWell-Architectedフレームワークのホワイトペーパーのうち、『Reliability』だけ気合の入れ方が違っていて、他のペーパーよりも用語の定義や具体例が豊富なため、アーキテクトの経験がなくてもイメージがしやすいものになっています。また、各観点を表にまとめてくれているので、困ったときにパッと見れるTips集的にも使えます。AWSのサービスに絡めた説明が多いですが、システムの信頼性についての観点は大体網羅できている普遍的な内容だとも思います。

概要を日本語でまとめてみたので、よければ参考にしてください。

AWS-Reliability-Pillar

※ （2019/09/02 追記）
"Calculating availability with hard dependencies" の箇所を修正しました。ご指摘いただきありがとうございます。

目次

• Introduction
  • Reliability (信頼性とは？)
  • Design Principles (信頼性を達成するための観点5つ)
  • Definition (可用性の定義)
• Foundation - Limit Management (システムやリソースの制限)
• Foundation - Networking (AWSのネットワーク)
• Application Design for High Availability (高可用なアプリケーションのデザイン)
  • 99.999% available application (可用性のポイント1 ATMネットワークの例)
  • A smart home heating product (可用性のポイント2 暖房スマートホームの例)
  • Understanding Availability Needs (必要な可用性を把握する)
  • Application Design for Availability (可用性のためのアプリケーションデザイン)
  • Operational Considerations for Availability (可用性のために運用で考慮すべきこと)
• Example Implementations for Availability Goals (可用性目標の例)
  • Dependency Selection (使用するAWSリソース)
  • Single Region Scenarios (単一リージョンでのシナリオ)
  • Multi-Region Scenarios (複数リージョンでのシナリオ)

※原文のセクションを少し改良しています

Introduction

• 単一障害点や不完全な自動化・伸縮性（elasticity）によって、オンプレ環境でシステムの信頼性（Reliability）を達成することはかなりの労力が必要だった
• 本ペーパーのプラクティスによって、次の特徴を持ったアーキテクトでシステムを構築できるようになる
  • 強固な基盤（strong foundations）
  • 継続的な変更管理（consistent change management）
  • 障害からの高い回復力（proven failure recovery processes）

Reliability (信頼性とは？)

• Reliabilityとは
  • システムが、インフラやサービスの障害（disruptions）から回復する能力
  • システムが、必要なコンピューティングリソースを動的に確保する能力
  • システムが、設定ミスや一時的なネットワーク障害による影響を最小限に抑える能力

Design Principles (信頼性を達成するための観点5つ)

リカバリーの手続きをテストする（Test recovery procedures）

• オンプレ環境のテストでは、ある特定のシナリオでシステムが動くかどうかを証明するために実行されていたが、リカバリー戦略そのものを検証（validate）するためには使われていなかった
• クラウド環境のテストでは、システムがどう止まるか（fail）も検証できるが、リカバリー手続きも検証することができる
• 様々なパターンの障害をシミュレートしたり、以前障害が起きたシナリオを再現したり、といったことを自動化できる
• 起こりうる障害が実際に発生する前に、コンポーネントのテストや改修ができるため、より理想的

障害から自動的にリカバリーする （Automatically recover from failure）

• システムのKPIを監視し、しきい値に達したときに設定した処理が自動的に実行される
• KPIはビジネス価値を測る指標であり、サービス運用で必要なテクニカルな指標ではない
• 通知や障害のトラッキング、リカバリープロセスを自動化できる
• さらに洗練された自動化では、障害の事前検知や影響範囲の縮小が可能

システム全体の可用性を上げるための水平スケーリング （Scale horizontally to increase aggregate system availability）

• 一つの大きなリソースを複数の小さなリソースに置き換え、システム全体の単一障害を減らす
• リクエストを分散させ、小さなリソース同士で共通の障害点をもたないようにする

システムスペックの推計をやめる （Stop guessing capacity）

• オンプレ環境の障害は、コンピュータリソースを超える負荷がかかったときによく起こる（DoS攻撃）
• クラウド環境では、システム要求や利用状況を監視し、自動でリソースを追加・削除することで、適切なスペックを維持できる

自動で変更を管理する （Manage change in automation）

• 自動でインフラに変更を加え、その変更を管理する

Definition (可用性の定義)

• サービスの可用性（Service availability）
  • 一般 → アプリケーションが期待通り動いている時間の割合（月・年・3年など）
  • AWS → アプリケーションが期待通り動いている時間の割合（月・年・3年など） + スケジュール通りのメンテナンスによってシステムが止まっている時間
• AWSのAvailabilityの定義
  • Availability = Normal Operation Time / Total Time
  • 稼働時間の割合（例 99.9%）は、ある一定時間で測られる（1年間が多い）
  • 省略表現は9の数で表される。（例 "five nines" = 99.999% available）
  • システム利用者は実際、メンテナンス中も利用したいというのが本音なので、メンテナンスによるシステム中断の時間も式に含める

Availabilityのデザインゴール一覧

Calculating availability with hard dependencies (依存関係にあるハード上のシステム 強依存関係にあるシステム）

99.99%の可用性を持つシステムが、99.99%の可用性を持つ２つの互いに依存したハードの上に構築さている時の全体の可用性は、システムとハードの可用性をかけ合わせた値となる。

ある99.99%の可用性を持つシステムが、他の２つの99.99%の可用性を持つシステムと強依存関係にある時、全体の可用性はそれぞれの可用性をかけ合わせた値となる。

[latex] invoking system * dependent 1 * dependent 2 =\\ 99.99\% * 99.9\% * 99.99\% = 99.97\% [/latex]

Calculating availability with redundant components (独立したコンポーネント上にあるシステム）

AWSの場合、Availability Zones(AZ)が当てはまる。99.99%の可用性を持つシステムが、99.99%の可用性を持つ２つの互いに独立したコンポーネントの上に構築さている時の全体の可用性は、100%から各コンポーネントの障害確率を引いた値となる。

[latex] maximum availability - ((downtime of dependent1) * (downtime of dependent2)) =\\ 100\% - (0.1\% * 0.1\%) = 99.9999\% [/latex]

Calculating dependency availability （依存関係を持つシステムの可用性を推計する方法）

多くのAWSサービスでは可用性に関する情報を掲載しているが、ないものに関しては推定する必要がある。シンプルな方法としては、あるシステム障害から次のシステム障害までの平均時間（Mean Time Between Failure; MTBF）とシステムが復旧するまで時間の平均（Mean Time to Recover; MTTR）を決定し、以下の式を立てる方法がある。

[latex] Availability Estimate = MTBF / (MTBF + MTTR) [/latex]

例えば、MTBFが150日で、MTTRが1時間の場合、可用性の推定値は 99.97%となる。

Cost for availability （可用性を達成するにかかるコスト）

アプリケーションが高いレベルの可用性をもつようデザインしていくことは、かなりのコストがかかることである。システム全体のライフサイクルやビジネス観点からの必要性を考慮し、適切なレベルの可用性でデザインしていくことが重要である。また多目的なサービスより、目的が絞られたサービスを組み合わせていくほうが、より可用性の高いシステムを構築することができる。

Foundation - Limit Management (システムやリソースの制限)

システムを構築する時は、システムの物理的な制限（physical limits）とサービスのリソース制限（resource constraints）を考慮する必要がある。また、それらの制限をアラーティングやレポーティングすることもリソースの管理において重要である。

AWSサービスの場合、リソースの制限はサービス・リージョン・アカウントごとにカウントされ（limit tracking）、AWS Trusted AdvisorやAmazon CloudWatchを活用して、管理を自動化することが望ましい。

Foundation - Networking (AWSのネットワーク)

IPアドレスベースのネットワークを使用したシステムを構築する時、将来的な成長や他のシステムとの統合を見越したネットワークトポロジーやアドレッシング（network topology and addressing）を計画する必要がある。AWSではAmazon Virtual Private Cloud (Amazon VPC) を使用することで、仮想ネットワーク上に隔離されたプライベートセクションを構築できる。

Plan your network topology (ネットワークトポロジーの計画手順)

1. IPアドレススペース（IP address space）を定義する。RFC1918のガイドラインに従い、Classless Inter-Domain Routing(CIDR)ブロックを各VPCに割り当てる。

• リージョンごと一つ以上のVPCに対して、IPアドレススペースを許可する
  • Allow IP address space for more than one VPC per Region.
• クロスアカウント・コネクションを考慮する。事業ごとに独自のアカウントやVPCをもつ場合、それらを共通のサービスと接続できるようにしておくとよい
  • Consider cross-account connections. For example, each line of business might have a unique account and VPCs. These accounts should be able to connect back to shared services.
• VPC内で複数のAZにまたがるように、複数のサブネットのスペースを許可する
  • Within a VPC, allow space for multiple subnets that span multiple Availability Zones.
• VPC内では常に、使用されていないCIDRブロックスペースを残しておく
  • Always leave unused CIDR block space within a VPC.

1. 相互通信能力（connectivity）の弾力性（resiliency; 回復力）を確保する。

• ネットワーク・トポロジーで障害が起きたときにどう対処・回復させるか？
  • How are you going to be resilient to failures in your topology?
• 何か誤った設定をしたり、接続を断ってしまったときに何が起こるのか？
  • What happens if you misconfigure something and remove connectivity?
• 予期しないトラフィックや利用量の増加に対処できるか？
  • Will you be able to handle an unexpected increase in traffic/use of your services?
• DoS攻撃を緩和することができるか？
  • Will you be able to absorb an attempted Denial of Service (DoS) attack?

AWSが提供している選択肢は様々。

• VPCをいくつ使用するか？
• VPC間でVPC peeringを使用するか？
• VPCへVPN(virtual private networks)で接続するか？
• AWS Direct Connectを使用するか？インターネットを使用するか？

ベストプラクティスでは、RFC 1918で定義されているプライベートアドレス・レンジを常に使用する。アドレスレンジが他のネットワーク被らないように注意しながら、デプロイに必要なサブネット数を十分に満たすアドレススペースを確保する。一般的には、大きめのVPC CIDRブロックをデプロイし、デプロイしたあとにサイズを調節していくと対処しやすくなる。サブネットのCIDRは変更できない点と、最大のレンジでVPCをデプロイすると65,000以上ののIPアドレスを展開することになる点に注意が必要である。

VPCからの接続はルートテーブルによって管理され、Internet Gateway、NAT Gateway、VPG、VPC peering connectionはルートテーブルを通してすべてサブネットにさらされる。VPC接続関係のサービスは他に、VPC EndpointやVPN appliancesなどもある。

VPCとオンプレのデータセンターをAWS Direct Connectで接続し、これに高可用性を持たせたい場合は、２つ目のAWS Direct Connectを別のロケーションから引っ張り、冗長性を持たせるとよい（a redundant connection fallback）。データセンターが複数ある場合、それぞれのロケーション側で接続を終了させる。

AWS Managed VPNを使用してインターネット越しにフェイルオーバーさせる場合、一つのVPNトンネルにつき1.25Gbpsスループットまでサポートしているが、同じVGW(Virtual Private Gateway)で終了している複数のAWS Managed VPNトンネルのケースでは、EgressへのEqual Cost Multi Path (ECMP)はサポートしていない点を理解しておく。また、転送スピードが1Gbpsを超える場合、AWS Managed VPNをAWS Direct Connectのコネクションのバックアップに使用することは推奨されていない。一つのネットワークで障害が起きた時に、他のコネクションに影響が出ないかどうか確かめておく必要がある。

プライベートアドレススペース内にあるリソースを保護する場合は既存の規格を使用し、サブネットはインターネットとアプリケーション間の防壁として使用するのが良い。オンプレ環境でよく使用されるファイアウォールやロードバランサー、エッジルーターは、AWS上ではAWS ShieldやAWS WAF、ELB、セキュリティグループ、ネットワークACLなどがその機能をまかなっている。

Application Design for High Availability (高可用なアプリケーションのデザイン)

目標とする可用性のレベルは個々のビジネスによって様々であるため、適切な可用性レベルに合ったコストで構築・運用を行う。構築・運用にかかるコストを全く考慮しなかった場合、"five nines"(99.999%)の可用性が理想である。これには、ヒューマンエラーを限りなく除外したり、リカバリー処理を自動化したりといったことが求められる。

99.999% available application (可用性のポイント1 ATMネットワークの例)

構成要素

• 外部デバイス（ATM）
  • マーチャントバンクが所有している
  • ネットワーク経由でホストプロセッサに接続されている
  • デバイス自体や接続状態に常に可用性があるわけではないので、冗長性を保ち、障害が独立して発生するようにしたい
• ホストプロセッサ
  • 最少で２つのコンピュータ・２つのストレージからなり、それぞれ独立したリージョンをまたがり、同期レプリケーションが行われている
  • マーチャントバンクやバンキングネットワークに対して、冗長性のあるコネクションを確立している
  • 独立したロケーションに、スタンバイコピーを待機させている
• ホストプロセッサ・アカウント（口座）
  • マーチャントバンクが管理する現金取引口座
• ATMとホストプロセッサ間をつなぐネットワーク
• 顧客の預金残高を管理する現金取引口座の情報

• 現金が必要になった時

  1. ポストプロセッサからElectronic Funds Transferが流れ、その顧客の口座から資金を引き出し、ポストプロセッサ・アカウントに入金するようリクエストが走る
  2. ポストプロセッサが資金を転送した後、ATMに現金を供給するようシグナルを送る
  3. ポストプロセッサが資金の小口決済送金（Automated Clearing House transfer; ACH）を開始し、マーチャントバンクの口座に送金される
  4. 資金がポストプロセッサへ転送された後で、ATMとポストプロセッサ間の接続や、ATMの機械自体に問題が起きた時、プロセッサはATMに対して現金を供給するシグナルを送ることができない
  5. この場合、ATMはトランザクションをタイムアウトし、顧客の口座へ返金する処理を行う
  6. ATMがトランザクションをタイムアウトし、out of serviceが提示される

• AWS上のホストプロセッサ → マーチャントバンク(ATM)： 複数のAWS Direct Connect
• マーチャントバンク(ATM) → AWS上のホストプロセッサ： 冗長性のあるDirect Connectプロバイダー
• 両方向の接続が確立されている場合、両プロセッサは接続が復旧するまで小口決済送金のリクエストを保存し、復旧しなかった場合はout of serviceを提示させることができる

このアプリケーションはAWS上で構築・運用することができるが、以下を考慮した上でコストに見合うかどうかを照らし合わせる必要がある。

• 何の問題を解決したいのか？
• 特定レベルの可用性を満たすためには、アプリケーションにどんな特徴が必要なのか？
• このワークロードは一年でどの程度の累積停止時間となるか？
• 本質的に、システムが利用不可になった場合のインパクトは何か？

A smart home heating product (可用性のポイント2 暖房スマートホームの例)

構成要素

• モバイルアプリ
• 無線サーモスタット
  • 暖房システムへ接続
  • インターネットへ接続
• ユーザーはAPI経由でサーモスタットのエンドポイントにアクセスし、コントロールする
• ユーザーは常に使用できることを期待している　→　99.999%の可用性

上の図で可用性を考慮すると、インターネットプロバイダー（internet service provider; ISP）の停止した場合の対応策やユーザーの接続状態の維持などについても考える必要がある。この場合、サーモスタットの生産コストや維持コストが上がり、システムのソースコードもより複雑になる。冗長化が適切にスイッチできているかのテストや、他の単一障害点の管理も必要となる。

当初の要件ではサーモスタットは99.999%の可用性を必要としていたが、実際にはサービス「全体」の可用性を99.999%とする必要はないのである。

多岐に渡るシステム停止の原因は以下の通り。

99.999%の可用性を達成させるには、上の表のパターンを全てマスターし、すべての人的介入を運用上から取り除き、細部に渡るテストも含め自動化することが必要である。全てを達成するには途方も無い労力がかかるため、定義を洗練して要件の順序付けしていくことが重要である。AWSには様々な要件を満たせる多数のサービスが展開されているが、コストと可用性のバランスを考えながらシステムをデザインしていくことが求められる。

Understanding Availability Needs (必要な可用性を把握する)

可用性はアプリケーション全体に対してのみターゲットを定めるのが一般的だが、個々のコンポーネントやサービスごと、サービスが稼働するフェーズや時期ごとに求められるレベルは異なる。ひとつのアプリケーションを分解し、それぞれに対して可用性要件を評価していきたい。

Recommendation
アプリケーションの特徴や、どのレベルの可用性がビジネス要件を反映でき、適切なのかをクリティカルに評価する。
Critically evaluate the unique aspects to your applications and, where appropriate, differentiate the availability design goals to reflect the needs of your business.

AWSではサービスを "data plane" と "control plane" に分割して考える。高レベルの可用性を達成させるには両方とも重要であるが、一般的にdata planeの方が可用性のゴールが高く設定される。

• data plane
  • リアルタイムサービスを提供することに責任をもつ
  • EC2 instances
  • Amazon RDS databases
  • Amazon DynamoDB table read/write operations
• control plane
  • 環境設定に使用する
  • launching new EC2 instances or RDS databases
  • adding or changing table meta-data in DynamoDB

Application Design for Availability (可用性のためのアプリケーションデザイン)

Fault Isolation Zones (障害の分離)

• 可用性を向上させる最も広く使われている方法。複数の独立したコンポーネントを並列で使う
• Data planeを強化するために、AWSではリソースやリクエストをいくつかの側面からパーティションをかけてる(例 リソースID)
  • Cross-cell interactionsを最小化するためにどのパーティションキーが適切なのかを見分ける
  • かつ、個々のリクエストでマッピングが複雑にならないように気をつける
  • マッピングの複雑性とセルの独立性の両方を考慮することが重要
  • 低いレイテンシを保ちながらも、自然災害やハード面のリスクを回避するために複数のAvailability Zonesを使用する手法は、AWSで一般的
• AWSのControl planesは、一つのリージョン内でリソ＝スを管理できる機能を持ち、一部は個々のAZに対してログ等の結果をフィルタリングすることができる

Recommendation
コントロールプレーンのAPIを使えば、個々のAZへログ等の結果をフィルタリングできる
When your application relies on the availability of control plane APIs during a disruption of one Availability Zone, use API filters to request results for a single Availability Zone with each API request (for example, with DescribeInstances.)

• Fault Isolationを構築する上で最も広域なものは、Regionである
• 大部分のサービスが単一のリージョン内で運用していくものだが、S3やAMIなどリージョンをまたげるサービスもある

Redundant components (冗長性コンポ―ネント)

• AWSのサービスデザインの根本原理の一つは、物理的なインフラに潜む単一障害点を避けること
• 複数のAZと個々のリソースの耐障害性

Micro-service architecture (マイクロサービス・アーキテクチャ)

• サービスを細かくシンプルにすることで、疎結合・可用性を向上できる。
• 最小限の機能(minimal set of functionality)を作っていく
• アプリケーションを呼ぶときの“contract” = サービスのAPIやデザインゴール、制限などの「枠組み」
• contractのベネフィット
  • サービス単位で、簡潔なビジネス課題(a concise business problem)と担当する小規模チームをもつことで、組織のスケーリングがしやすくなる。
  • 他のサービスのAPIや“contract”を満たす限り、個々のチームはいつでもデプロイができ、好きな技術を使うことができる。

Recommendation
"contract"を用いて、サービス内の機能を分離する
Isolate discrete functionality into services with a “contract” (API and performance expectations).

• マイクロサービス・アーキテクチャはエンドユーザー側のレイテンシを維持するのが難しい
• デバッグやトレース、運用上の複雑性も上がる（→ AWS X-Rayを使用するとよい）

Recovery Oriented Computing (リカバリ志向コンピューティング)

• AWSは障害が発生した時の中断時間の最小化にも取り組んでいる
• リカバリータイムの削減は可用性の向上に直接的な影響をもっている
• Recovery Oriented Computing(ROC)の観点は、リカバリーを改善するためのシステマティックなアプローチ法
  • 分離と冗長性(isolation and redundancy)や変更のロールバック
  • 監視・ヘルスチェック
  • システム動作診断
  • リカバリーの自動化
  • モジュール設計
  • 再起動
• ROCでは、障害の検知に注力し、異なるタイプの障害に対して、共通のリカバリー手法をexponential back-offで当てることが多い。
• リカバリーを機能させるには、頻繁にテストを通すことが重要。

Distributed systems best practices (分散型システムのベストプラクティス)

• 分散型システムのパフォーマンスはシステム間の距離や中継のネットワークに依存する
• 分散型システムのサービスを通常通り運用するベストプラクティスパターン

• Throttling (スロットリング)

  • 予期しない要求の上昇に対処する保守的なパターン
  • リクエストを受け入れるものと拒否するものに分ける
  • 負荷テストを通すことで、機能を確率できる
  • ノードやセルのそれぞれがリクエストを処理できるようにサービスをデザインしておく
  • リクエストをトラッキングし、レートがリミットを超えた時はシグナルを出し、すぐリトライできるようにする
• Retry with exponential fallback (exponential fallbackでリトライする)
  • スロットリングを発動する側
  • AWS SDKsにはデフォルトで設定済み
  • ポーズしてリトライするまでの間隔が、回を重ねるごとに指数関数的に増加する
• Fail fast (エラーは即座に返す)
  • 即座にエラーを返すこと
  • リクエストに必要なリソースの開放や、キュー待ちのリクエストの削減につながる
• Use of idempotency tokens (冪等性トークン)
  • 分散型システムでは、多くて１回や少なくとも１回の実行は簡単であるが、きっかり１回の実行は保証できない。
  • APIの冪等性を考えることで、予期せぬ複数回実行によるレコードの重複や副作用を防ぐことができる。
• Constant work (コンスタントにジョブを実行する)
  • 負荷の急激な変化はシステム障害につながる
  • ピーク時の負荷に合わせて、インプットやデータがない場合でも穴埋め用のジョブ(filler work)を実行しておく
• Circuit breaker (遮断器)
  • 分散システム上でリモートにリクエストするとき、リクエストに対してモニタリングを繰り返す「遮断器」を挟むことで、全体のレイテンシーの増加や可用性の低下を抑えることができる。
  • 非同期処理で良く使われる手法
• Bi-modal behavior and static stability (異なる状態を共存させない)
  • 分散システムは単一ノードの障害によって引き起こされたnegative feedback loopsが全体に影響を及ぼすことがある
  • Bi-modal behavior = 正常な状態と不正な状態が共存し、通常とは異なる挙動が起こること
  • 静的に安定(statically stable)させ、一つのモードでしか運用できないようにシステムを構築する
  • 障害の発生中はシステムのパフォーマンスが下がる

Operational Considerations for Availability (可用性のために運用で考慮すべきこと)

可用性要件を満たすには、アプリケーションの全体のライフサイクルの内の自動化やヒューマンプロセスの計画を立てていくことや、様々な粒度のテストを実施していくことが重要である。

Automate Deployments to Eliminate Impact (影響を減らすためにデプロイを自動化する)

• 本番環境に変更を加えることは、最も大きなリスクの一つ
• AWSは、デプロイはビジネスの課題に合わせて解決していくべき最重要の課題であると考える
• ここでの自動化は、テストやデプロイによる変更、リソースの加減、データマイグレーションを含む

Recommendation
運用上の難しい手続きは人力でやるべきとされているが、だからこそ自動化すべきである
Although conventional wisdom suggests that you keep humans in the loop for the most difficult operational procedures, we suggest that you automate the most difficult procedures for that very reason.

リスクを最小限に抑えるデプロイパターン

• Canary deployment
  • 一部のユーザーだけに新しいバージョンをリリースし、挙動の変化やエラーを入念に調べる手法
• Blue-Green deployment
  • Canary deploymentと似た手法で、既存バージョンと新規バージョンを並行してデプロイし挙動を検証する手法
• Feature toggles
  • アプリケーションのオプション設定によって、機能のオンオフを切り替える手法
• AWSでは、一つのRegion内の複数のAZに対して、同時に環境を触らないようにしている。

Testing (テスト)

• AWSでは、canary testingを継続的に実施して、顧客の行動をシミュレートすることを重要視している
• ユニットテスト、負荷テスト、パフォーマンステスト、外部モジュールの障害テスやデプロイテストを行い、障害のパターンをシミュレートする
• NetflixがAWS上でさまざまな障害をシミュレートするOSSを公開している(Netflix/SimianArmy)

Monitoring and Alarming (監視とアラート)

• 最悪な障害のパターンは、機能していないことはわかってるが直接検知できない障害、サイレントな障害。
• アラート機能はシステムとはできるだけ乖離させておく
• AWSではサービスのログやメトリクスや記録しているため、percentile monitoringが可能
• AWSでモニタリングを行う時のステップ
  1. Generation : どのサービスやアプリに監視が必要か決め、重要なメトリクスやそれらの抽出方法を定義し、しきい値やアラームの条件を作成する
  2. Aggregation : ログやメトリクスを統合・集計する
  3. Real-time Processing and Alarming : 変化に対してリアルタイムにアラートを発行する
  4. Storage and Analytics : ログやメトリクスを保管し、更に詳細な分析を行う
• モニタリングの過程でしばし見落としがちなのは、データの管理である。ライフサイクルポリシーを適切に設定する

Operational Readiness Reviews (ORRs)

• アプリケーションが本番環境で運用する準備ができているか確かめる
• プロダクションの早期に、定期的に繰り返してORRを行う

Recommendation
最初の本番運用の前にアプリケーションに対してORRを行い、それ以降も定期的に行う。
Conduct an Operational Readiness Review (ORR) for applications prior to initial production use, and periodically thereafter.

Auditing

• アプリケーションがどのくらい可用性目標を満しているのかを確認
• 根本原因解析(Root Cause Analyses)を行い、何が起きていつ障害が発生したかを発見する

Example Implementations for Availability Goals (可用性目標の例)

以下の観点から、可用性要件の範囲を考えていく。

• 必要な分だけ変更を適応する (Adapt to changes in demand)
• モニタリングを実施する (Use monitoring)
• 変更をデプロイする (Deploy changes)
• データのバックアップする (Back up data)
• 弾力性を備える(Implement resiliency)
• 弾力性をテストする (Test resiliency)
• ディザスタリカバリ (Recover from disaster)

Dependency Selection (使用するAWSリソース)

EC2, RDS, multiple AZ, Route 53 for DNS, Elastic Load Balancingを使ったアーキテクチャで、高い可用性を達成する

Single Region Scenarios (単一リージョンでのシナリオ)

2 9s (99%) Scenario

• アプリケーションが中断した場合、「不便に」感じるだけのレベルのシステム要件
• 内部システム（ツール、ナレッジ管理、プロジェクト管理）
• 顧客向けの試験運用のシステム
• 単一リージョン、AZで十分

3 9s (99.9%) Scenario

• 高可用性が求められるが、多少の中断なら耐えられるシステム要件
• 故障した際、内部の従業員のみに影響がある運用システム
• 顧客向けであるが、そこまでビジネスとして高い収益とならないかつ、長めのリカバリーを許容できるシステム
• マルチAZ、ELB、Auto Scalingなどを採用

4 9s (99.99%) Scenario

• 高可用性が求められ、コンポーネントの障害に耐えられるレベルのシステム要件
• メインのビジネスで、重要な収益源となっているミッション・クリティカルなアプリケーション
• Eコマースサイト、B2Bウェブサービス、高トラフィックなコンテンツ・メディアサイト
• "statically stable"を目指す

Multi-Region Scenarios (複数リージョンでのシナリオ)

マルチリージョンで構成することでアイソレーションはより協力なものになるが、管理コストは更にかかる。

3 1⁄2 9s (99.95%) with a Recovery Time between 1 and 30 Minutes

• 極限まで短いダウンタイムと非常に小さいデータロスが求められるシステム要件
• 銀行、投資、緊急サービス、データ収集
• 2リージョンにまたがるホットスタンバイ

5 9s (99.999%) or Higher Scenario

• ダウンタイムやデータロスほぼ認められないシステム要件
• 銀行、投資、ファイナンス、政府、莫大な利益をもたらしているコアのビジネスアプリケーション
• "Active/Active"や"Multi-master"

最後に

かなりの長文でしたが、最後までお読みいただきありがとうございました。『Reliability』ペーパーはAWSのノウハウの塊であり、AWSはあらゆる側面から可用性についてアプローチし、信頼性の向上に努めていることがわかりましたが、それでも先日の東京リージョンような大規模障害が起きてしまうんですね……。銀の弾丸が見つかるのは、果たして何十年後か？

『Reliability』ペーパー原文には更に詳細に書かれているので、ぜひ読んでみてください。

AWS-Reliability-Pillar

誤訳等あればご指摘ください。