AWS Startup ブログ

Well-Architected for Startups -信頼性の柱- 導入編

こんにちは、スタートアップ ソリューションアーキテクトの松田 (Twitter: @mats16k) です。

スタートアップのみなさんは、サービスの開発にあたりアプリケーションのコードだけでなく、アーキテクチャの設計や開発運用フローについても悩みながら開発をされているかと思います。言うまでもありませんが、質の高いサービスを作り上げていくためには、コード以外の部分にも気を配り改善していく必要があります。一方で、クラウド上での開発が一般的になった現代において、最適なアーキテクチャや運用とはどのようなものでしょうか。

このような課題を解決するために AWS が提唱しているものが AWS Well-Architected フレームワーク です。Well-Architected フレームワークとはクラウド上でサービスを提供するにあたっての ベストプラクティス集 であり、このフレームワークに沿って開発や運用体制を整備していくことで、効率よくサービスの品質を高めていくことが出来ます。

※ フレームワークと言っていますが、Ruby on Rails のようなアプリケーションフレームワークでは無いのでご注意を。

Well-Architected フレームワークは「運用上の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コスト最適化」の5 つの柱から構成されていますが、今回は「信頼性」にフォーカスし、スタートアップの背景を踏まえ解説していきます。

目次

 

信頼性の柱

信頼性の柱には、インフラストラクチャまたはサービスの障害からの復旧、必要に応じた 動的なコンピューティングリソースの獲得、設定ミスや一時的なネットワークの問題など による障害の軽減などのシステムの機能が含まれます。

AWS ではこのような観点で設計することを Design for Failure と表現したりしますが、単にシステムを落とさないということでなく、有事の際にどの様にリカバリ出来るのかといったことを予め考えておくことが重要になります。（下記は AWS re:Invent での関連セッションになります。）

 

設計の原則

詳細についてはホワイトペーパーと重複するため割愛しますが、クラウド上のシステムの信頼性向上においては下記のような 設計の原則 が重要になります。お客様自身が意識し則っていくことも重要ですが、AWS の各サービスがこれらを実現できるように機能拡充をしていることや、組み合わせることによって実現可能になっていることを理解することも同じくらい重要です。
もしこれらを意識出来ていない構成になっているようでしたら、AWS のサービスや機能を有効活用できていない可能性が高いため、設計の見直しやソリューションアーキテクトに相談することをお勧めします。その際のチェックには後半で触れている AWS Well-Architected Tool を活用してみてください。Well-Architected Tool は網羅的に課題を洗い出せるようなチェックリストになっており、以下のような設計の原則を考慮出来ているかチェックすることが出来ます。

  • 復旧手順をテストする
  • 障害から自動的に復旧する
  • 水平方向にスケールしてシステム全体の可用性を高める
  • キャパシティーを推測しない
  • 自動化で変更を管理する

 

目指すべき可用性と可用性の定義

お客様から（バックアップ戦略や BCP についてなど）信頼性に関するご相談を頂くことは数多くありますが、その際に「目指すべきサービスの可用性」を明確にすることからお話しするようにしております。お客様の中には「絶対に落ちないサービス」を求めている（あるいは営業部門やエンドユーザから求められる）方もおられますが、最も重要なことは絶対に落ちないサービスは無いということを理解し、目標とするサービスの可用性を達成するためにしっかりと計算された対策を講じるということです。ではその目標とはどのように設定すればいいのでしょうか。

「サービスの可用性」は、一般的にアプリケーションの正常な稼働時間の割合で定義され、多くの場合 99.9% のように百分率で表現されます。AWS でも「可用性 = 正常稼働時間/合計時間」として定義しています。
アプリケーションの性質によって目指すべき可用性は変わりますが、「99.9%」のような数字が実際のところどの程度の可用性を意味しているのかを正しく認識することがはじめの一歩になります。

可用性 最大中断時間（１年あたり） 代表的なワークロード
99% ３日と１５時間 バッチ処理、データ抽出、転送、ロードジョブ
99.9% ８時間４５分 ナレッジ管理、プロジェクト追跡などの社内ツール
99.95% ４時間２２分 オンラインコマース、POS
99.99% ５２分 動画配信、ブロードキャストシステム
99.999% ５分 ATM処理、通信システム
表: ホワイトペーパー より抜粋

いかがでしょうか。実際にはこの時間の中で対応の判断や復旧作業を行うのですが、年に数回発生することを考慮すると、それぞれの障害対応にかけられる時間は想像より短いのではないでしょうか。可用性の設計についてはホワイトペーパー内でも次のように触れられています。

私たちの推定では、復旧の実行を決定するまでに 30 分、復旧自体が 30 分以内に完了するとしています。この場合は障害から復旧するまで 60 分かかることになります。年間で障害が 2 件発生すると仮定すると、その影響時間は年間 120 分です。つまり、可用性の上限は 99.95% です。実際の可用性は、実際の障害発生率、障害の持続期間、各要因の実際の復旧速度によっても異なります。このアーキテクチャでは、プログラム更新のためにアプリケーションを一時的にオフラインにする必要がありますが、この更新作業は自動化されています。これについては年間 150 分、更新作業ごとに 15 分、年間 10 回と推定します。これによってサービスが利用できない時間は年間 270 分であるため、可用性の設計目標は 99.9% です。

詳細についてはホワイトペーパーをご確認頂ければと思いますが、かなり具体的に RPO（目標復旧時点）や RTO（目標復旧時間）を設計していることが分かるかと思います。RTO 達成可能であるか評価するためには、実際に復旧にかかる時間が試算可能である必要があります。復旧時間を安定させるためには自動化の仕組みが必要であり、前述の「設計の原則」に立ち返っての設計が重要というわけです。業種業態によっては、お客様によっては、ダウンタイムが○分発生した際に△万円の損失が発生するといったところまで試算した上で、計画に盛り込んでおられるケースもあります。

なぜ、ここまで明確に RPO（目標復旧時点）や RTO（目標復旧時間）を設定するのでしょうか。もちろんサービスが落ちないに越したことはないので可用性は高ければ高いほどよいのですが、多くの場合、高い可用性はコストとのトレードオフの関係にあります。検討をする際に、どの程度のコストをかけることで、どの程度の可用性を達成できるのかの見通しが立っていない状況では、どのような対応をしたとしても「コストに対して可用性が上がっていない。。」のような結果に繋がりかねません。

事実、目指すべき可用性が高くなればなるほど、実数としての中断時間に対してコストは指数関数的に増大する傾向にあります。例えば、可用性を 99% → 99.9% に改善するのと、99.9% → 99.999% に改善するのでは、改善幅が 0.9% と 0.099% 大きく差がある一方で後者のほうが（ワークロードにもよりますが）数倍のコストがかかります。

可用性について SLA や SLO といった言葉を耳にすることがあるかと思いますが、こちらについても軽く触れておきます。

 

SLA

SLA は Service Level Agreement の略称であり、AWS もサービス毎に SLA を設定しています。しばしば誤解されている方もいらっしゃいますが、 SLA とは決められた可用性を満たせなかった場合に補償や補填を行うといった契約であり、明示された基準の可用性を保証するものではありません。（AWS に限らず一般的な話です）

したがってお客様は利用している AWS サービスの SLA に関わらず、常に Design for Failure を意識し環境構築や運用について考える必要があります。もちろん各サービスは開発者をサポートする機能（例えば Amazon RDS の Multi-AZ 構成など）を多く提供しているので、実際にはそれらを活用していくことになります。

 

SLO

SLO とは Service Level Objective の略称であり、サービス提供における可用性の目標値なります。先ほど、SLA は外部のお客様向けの契約と解説しましたが、その SLA 内の指標を達成するために内部的に定めた目標値が SLO になります。したがって多くの場合 SLO の内容は外部に公開されません。SLO は「目指すべき可用性」について具体化したものになりますが、SLO を設定し達成することだけが重要ということではなく、目標との乖離を定期的に評価していくことも重要になります。

 

設計のヒント

ここではスタートアップの皆さまがよりショートカットして実装に移れるよう設計のヒントをお話します。
なお、信頼性について初めて学ぶ場合は本セクションの内容に加え、ホワイ トペーパーの後半にある「デプロイを自動化して影響を排除する (変更管理)」と 「リカバリ指向コンピューティング (障害管理)」も合わせて参照してください。

 

基本は Multi-AZ （マルチ アベイラビリティーゾーン）

まず、基本的なところではありますが Multi-AZ は非常に重要です。Multi-AZ とは複数のアベイラビリティーゾーンを組み合わせて可用性の向上を図るアーキテクチャパターンです。

なぜ重要なのでしょうか。それは多くのワークロードにとって非常に費用対効果が高く可用性を向上できる設計方法だからです。多くの AWS サービスは Multi-AZ 化出来ること前提に設計されているため、少ないコストで対応することが可能です。ここで言うコストとはサーバ/インフラコストだけでなく、管理運用の際の人的コストを含みます。例えば Amazon Aurora は数クリックで複数の AZ 間でレプリケーションを張り、障害時には自動でフェイルオーバが行われ、Amazon EC2 は AutoScaling の設定をすることで用意に複数 AZ にインスタンスをバランス良く配置することが可能です。

Multi-AZ について正しく理解するためには、アベイラビリティーゾーン (AZ) ついて正しく理解することも重要です。AZ の特徴を要約すると下記の通りです。

  • 1 つの AWS リージョン内でそれぞれ切り離され、冗長的な電力源、ネットワーク、そして接続機能を備えている 1 つ以上のデータセンター郡
  • リージョン内のすべての AZ は、AZ 間に高スループットかつ低レイテンシーのネットワーキングを提供する、完全に冗長性を持つ専用メトロファイバー上に構築された、高帯域幅、低レイテンシーのネットワーキングで相互接続されている
  • 各 AZ は他の AZ から物理的に意味のある距離離れており、すべて 100 km 以内に配置されている

言い換えれば、それぞれの AZ での障害や不具合は他の AZ に影響しないように構成されつつ、レイテンシなど複数拠点利用する際の考慮事項は最低限に抑えられていると言えます。このような AZ に基礎的なところを理解していると、Multi-AZ 構成の費用対効果についてはもちろんのこと、前述の可用性の試算や障害シナリオの想定にも役立ちます。

また、インスタンス数の増加によるコスト増を懸念されるお客様もいらっしゃいますが、多くの場合、台数の増加に合わせて負荷もバランシングされるため、インスタンスのスペックを落として台数を増やすような構成となります。（Amazon Aurora もスレーブをリードレプリカとして利用することが可能ですので、マスターの負荷軽減に有用です。）コストについて考慮される場合は　単純に AZ 数で等倍するのではなく、各 AZ に処理が分散されることに注意するといいでしょう。

Multi-AZ 構成にする場合は、有事の際に負荷が偏った時の挙動についても考慮してください。例えば３つの AZ を利用している際に１つの AZ で障害が発生した場合、残りの２つの AZ で全ての処理を行わなければなりません。つまり単一の AZ で50%を捌ける必要があるため、平常時は150%の負荷に対応できるようにしておく必要があるといった具合です。（実際には段階的にフェイルオーバーが行われたり、ワークロードによって負荷のかかり方は異なるのであくまで一例になります。）

参考: リージョンとアベイラビリティーゾーン | AWS について

参考: アベイラビリティーゾーンを使用した静的安定性 | The Amazon Builders’ Library

※ The Amazon Builders’ Library とは Amazon がテクノロジーを開発、設計、リリース、そして運用する方法を説明する生きた記事のコレクションであり、Amazon のシニアテクニカルリーダーとエンジニアが書いています。

 

リージョナルサービスを有効活用する

AWS のサービスには AWS Lambda や Amazon DynamoDB、AWS AppSync など、サービスの仕様上 Multi-AZ 構成になっているサービスがあります。（リージョナルサービスと呼んだりします。）これらのサービスには自動スケールやフェイルオーバーなどが仕様として組み込まれているため、これらを採用しサービスを構築することで自然と可用性の高いサービスを作り上げることが出来ます。

また、昨今スタートアップに人気のあるサービス/ツールで AWS Amplify というものがありますが、こちらもおすすめです。AWS Amplify を利用することで、自然とリージョナルサービスを中心とした構成になるため、結果として可用性の向上にも繋がります。GraphQL API や Storage、Predictions といったやりたいこと/利用したいリソースベースで考えて利用できるので、AZ や AWS のサービスに関する知見がなくとも可用性の高いサービスを容易に構築できます。スタートアップの初期のステージにおいて有力な選択肢になるのではないでしょうか。

 

監視はエンドユーザへの影響から考える

監視に関するご相談も多く頂きます。CPU を見ればいいのか？メモリも見るべきか？アラートのしきい値はどうすればいいのか？などなど・・・特にスタートアップの初期のステージにおいて知見のある社員がおらず困っているお客様によくお会いします。Well-Architected フレームワークでは「全ての層のモニタリングが必要」と記載されていますが、知見が無い開発者にとって何をもって「全ての層」なのかを判断することが難しい、、といったケースが多くあります。

そのような場合に私がよくご案内していることは、まずは「ビジネスへの影響」や「エンドユーザへの影響」から始めるということです。例えば Web サービスの場合、エンドユーザのブラウザやアプリにおけるレイテンシや 5XX のステータスコードなどです。場合によってはエンドユーザからの問い合わせ数なども指標に入ってくるでしょう。
もちろんサーバの CPU やメモリといったインフラレベルの監視が不要と言っているわけではありません。これらはビジネスやユーザに悪影響が出ている場合の問題の調査に必要となってきます。一方で CPU 使用率が 40% → 60% になったのような情報だけで、その状況が正常なのか問題があるのかを判断することは難しいと言えます

一例として、モバイルアプリにの裏側の API のレイテンシが大きくなりユーザ影響が出ている場合を想定しましょう。API が遅くなっている場合、いろいろな可能性が考えられます。ロードバランサーのレイテンシが上がっている場合もありますし、サーバの CPU に負荷がかかり処理に時間がかかっているのかもしれません。あるいはデータベースの Disk I/O が頭打ちになっている可能性も考えられます。
このように最終的に補足したい事象からはじめ、関連する要素は何か考えブレイクダウンしていくことで、全ての層のモニタリングに繋げることが出来ます。

「エンドユーザへの影響」を測る最もベーシックな手法としては外形監視があげられますが、AWS では Amazon CloudWatch Synthetics という機能を利用できます。どこから手をつけたらいいか分からない方は、下記ブログを参考に設定してみてはいかがでしょうか。

参考: CloudWatch Synthetics を使用してサイト、API エンドポイント、ウェブワークフローなどをモニタリングする

実際には漏れもあるかと思いますが、運用の中で監視項目が増えていくことは一般的です。どの様な指標があれば問題を防げたのか、あるいは対応を自動化出来たのか、その様な視点で監視についても継続的に改善していくことこそ重要と言えるでしょう。

 

より高い可用性を求めるのであれば、マルチリージョンだがその前に・・・

単一のリージョンで出来ることを全てやった上でより高い可用性が求められるユースケースにおいて、マルチリージョンという選択肢があります。ホワイトペーパー上では 99.95% や 99.999% といった可用性を満たす際のシナリオのひとつとして記載されています。

マルチリージョン化を検討しているお客様にお会いすることも多くありますが、その際に年間の中断時間について再考することをお勧めしています。想定するシナリオにもよりますが、年間で許容される中断時間は４時間〜５分といった桁感であり、年間に数回障害が発生することを考慮すると、復旧に当てられる時間はとても短く非常に高度な自動化が求められます。
非常に高度な自動化をした上で、単一のリージョンではどうしても目標とする可用性を満たせない・・といった状況であれば、マルチリージョン化は非常に有効な手段になり得ますが、復旧の自動化などが疎かになっている状況でマルチリージョン化を進めても可用性の向上には繋がりにくいといえます。むしろ管理するコンポーネントが増えるため、可用性が低下する可能性すらあります。

 

ワークロードの現状と潜在的なリスクを可視化することが目的

（厳密には設計のヒントではありませんが、、）

Well-Architected フレームワークはクラウド上でサービスを提供するにあたってのベストプラクティスではありますが、その主たる目的は現状の把握や潜在的なリスクの可視化です。仮に満たせていない項目があったとしてもワークロード毎に事情があるため、それらを踏まえて考えていけば問題ありません。

例えば、あるインターネット広告系のお客様は非常にレイテンシーにシビアなプロダクトを提供するにあたり、あえて Single-AZ 構成にしておりました。一方であるエンタープライズ系のお客様はオンプレミス環境の考え方のまま AWS に移行したため Single-AZ 構成となっておりました。この両者において、前者のお客様はベストプラクティスは分かった上で Single-AZ 構成にしているため、その AZ に障害が発生した際の対応について事前に考えることが出来ます。後者のお客様はどうでしょうか。そもそもリスクを可視化出来ていないために適切な対策を打てないのではないでしょうか。

Well-Architected フレームワークに沿ってレビューをする際は、是非そのワークロードの開発や運用に携わっている方全員を集めて実施することをおすすめしております。これは可視化の際に、特定の社員しか把握していない事案を把握するためです。（特に初期のスタートアップは、ドキュメントに落とすなど出来ていない or 属人的な開発/運用をしているケースも多いのではないでしょうか）

 

AWS Well-Architected Tool

Well-Architected フレームワークは実装のためのベストプラクティスであり、基本的にはホワイトペーパーの内容がマスターになります。では、そのベストプラクティスにそって、自社のワークロードがどの程度対応できているか確認したくなりませんか？
そのような方にご利用いただきたいのが AWS Well-Architected Tool です。AWS Well-Architected Tool は自社のワークロードがどの程度 Well-Architected フレームワークに沿っているかを診断できるチェックリストになっており、AWS のマネジメントコンソール上からご利用頂くことが出来ます。（AWS のマネジメントコンソールで “Well-Architected” と検索してみてください。）

AWS Well-Architected Tool の画面

私たちソリューションアーキテクトに相談頂く際も、AWS Well-Architected Tool で事前にどこに課題があるのか把握された上でご相談頂くと、より適切なご案内が出来ることがあります。自社でのセルフチェックだけでなく、相談の際の課題の整理にもご活用頂ければと思います。

 

まとめ

今回は Well-Architected フレームワークの「信頼性の柱」についてお話しました。可用性を向上させるにあたり、考え方や方法についてご紹介しましたが、最も重要なことは「ダウンタイムは０にならない（可用性は100%にならない）。だからこそ、落ちた時のビジネスインパクトを考える必要がある」ということです。その際の考え方の指針が Well-Architected フレームワークであるとも言えます。

この機会に、ホワイトペーパーや AWS Well-Architected Tool を活用し、自社のワークロードを見直して頂ければと思います。その上で対策に困る部分も出てくるかと思います。その際はソリューションアーキテクトにご相談ください。お客様のシチュエーションを踏まえ最適な構成になるようにお手伝いさせていただきます。

次回は「Well-Architected for Startups -信頼性の柱- 実践編」として、より具体的にどの様な構成にすればいいのか、どの様なサービスや機能が利用できるのか解説する予定です。

 

このブログの著者

Kazuki matsuda松田 和樹 (Kazuki Matsuda) @mats16k

コンテナやビッグデータが得意分野なスタートアップソリューションアーキテクト。好きなサービスは AWS Fargate。最近は AWS Amplify が好きです。