9月 3, 2019AWS,EC2,システム設計

Server / システムの可用性

概要

はじめに

• 今日は、可用性についての記事を書きました。今回の記事は目新しい内容ではなく、先日のAWS障害を受け、ITシステム設計の基本に戻り、オンプレミスから通じるポイントを記載したつもりです。改めて、自ら可用性を考慮したシステム設計を意識したいものです。
• また、システムを構成する上で欠かせない要素であるELB（ロードバランサー）の可用性については、ポイントを下記の記事に個別にまとめています。宜しければ、合わせて参照ください。

可用性とは

• 可用性（Availability）は、ユーザーから見た「使用できる」度合いを表します。また、可用性に信頼性（Reliability）・保守性（Serviceability）を含めたものをRASと呼び、コンピュータなどを総合的に評価する指標として使われます。
• 各指標は混同されがちですが、それぞれ観点が異なります。信頼性は、部品や製品単位で定義されることが多く、信頼性が低ければ故障率が上がり、可用性も低くなります。
• しかし、コンピューターシステムでは多くの部品でアクティブコンポーネントが搭載され、電源・HDDなどの駆動部品も用いられているため、故障は避けられません。そのため、製品レベルは部品を冗長したり、電源供給を二重化したり、システムレベルはHA（High Availability）を構成するなど、障害の影響の緩和や局所化に努めることが望ましいです。

EC2のSLA

• EC2のSLAは99.99%です。（2019年9月現在）
• このSLAが対象とするダウンタイムとはリージョン障害を表し、AZ（アベイラビリティゾーン）の障害は含みません。これは何を意味するでしょうか。
  • 1つ目は、上記SLAは単体のEC2で実現しているわけではなく、サーバーおよび関連するプロダクトを含むシステムがAZを跨いで冗長化されていることを前提としています。
  • 2つ目は、AWSを使用する上で「責任共有モデル」であることを理解する必要があります。EC2はIaaS（Infrastructure as a Service）に分類されるため、サーバーの冗長性・耐障害性を考慮したシステム設計、障害時の復旧、セキュリティの管理などは全てユーザー側の責任となります。

AWS障害の構え

概念

• 可用性の重要さが理解できたでしょうか？　それでは、いかにAWSでサーバーの可用性を高めれば良いでしょうか。それは、オンプレミスのサーバー製品やシステムで掲げられるベネフィットと同じです。
• サーバーおよびシステム内のSPOF（Single Point Of Failure）を減らすこと。SPOFは単一障害点を指し、システムを構成する要素のうち、そこが停止するとシステム全体が停止してしまう部分のことです。
• サーバー、システムが冗長化されていること。コストを考慮する必要がなければ、DR（ディザスタリカバリ）、少なくともMulti-AZで構成しなければいけません。
• システム内のプロダクト、サービスの障害を自動で検知すること。
• システム内のプロダクト、サービスの障害を自動で復旧すること。

具体策

• セオリーばかりですが、上記に記載した概念に沿って、AWSのサーバーで可用性を高めるアーキテクチャを記載します。
•  ELB-EC2
  • Auto Scalingを使用することでターゲットの異常を検出してELBから切り離し、Auto Scalingによって代替の起動が可能です。ELB、EC2は、2AZ or 3AZのMulti-AZで構成します。
• ELB-ECS FargeteによるコンテナのAuto Scaling
  • ECS FargateもEC2 と同様にELBを使用したAuto Scalingが使用できます。もちろん、ECSクラスターは、2AZ or 3AZのMulti-AZで構成します。
• Lambdaによるサーバーレス化
  • 関数のタイムアウトを適切に設定し、リトライやログ検知の仕組みを取り入れること。
• 外部の管理ソフトウェアと連携
  • クラウド上のインスタンスやコンテナを一元管理する管理ソフトウェアを使用し、障害時の自動検知・復旧を組み込む方法。実際に使用したことはありませんが、Spotinst社のソフトウェアがこの機能を実現できるとのこと。先日のAWS障害を受け、ITmediaに事例が記載されていましたので、紹介します。