AWSの概念 アーキテクチャの設計原理

Topic

• 故障に備えた設計(Design for Failure)
• コンポーネントの分離(疎結合)
• 弾力性
• 並列化

---

故障に備えた設計(Design for Failure)

結論からいうと障害が起こることを前提に障害が発生しても問題のない設計をする考え方です。

クラウドはネットワーク上で全て完結するといえど、物理サーバーはAWSが管理しており、利用している元をたどると実態が存在します。災害、寿命、物理的要因と様々な要因で機器は壊れる可能性があります。100%壊れないものは存在しません。
　しかし、予備電源のように壊れても別のシステムや機械で補えるように設計すると、システムが完全に停止することを防ぐことができます。
　このように、全ての障害は起こることを前提にし、障害が発生しても問題のないようにする考え方をDesign for Failureと言います。機械だけでなくサービスの利用にあたっても同様です。

1つが故障するとシステムが停止してしまう(SPOF:単一障害点)ような設計はやめましょうということです。

コンポーネントの分離(疎結合)

疎結合とはシステムの構成要素(コンポーネント)間との依存性や関連性が低く、独立性の高い状態のことを指します。
1つ1つのシステムの中で完結していることが望ましい状態と言えるでしょう。
反対の密結合である場合、1箇所でエラーを起こすと、連動して複数の部分で影響を与える可能性があります。Aシステムで問題が発生したことにより、連動しているBシステム、Cシステムへと障害が広がり、複数のシステムで障害が発生してしまいます。そうなると問題の原因を特定することに時間を費やさなければなりません。
　同様に、更新やメンテナンスの際にAシステムの内容を更新時にBシステム、Cシステムと障害が発生しないかを確認する必要があり、更新作業も簡単ではありません。
そのため、各種処理ごと、データの特性ごとにコンポーネントを細分化し、独立性の高いシステムを構築していきましょう。

弾力性

弾力性とは急激な負荷の増加に対応する能力のことを指します。
たとえば、毎週火曜日だけサーバーの負荷が5倍に増加し、普段の設定ではオーバーフローしてしまうとします。そのため、毎週火曜日にはサーバーを増加させ、水曜日には必要のなサーバーを切り捨て、普段の状態に戻します。
このように、急増する負荷に対応する方法を3パターン以下に記載いたしました。なんとなくこんな方法もあるんだな〜程度に把握しておくといいかもしれません。

• 巡回スケーリング
  上記例のように一定間隔に発生する定期的な負荷に対して対応する方法。
• イベントベーススケーリング
  　予定しているイベントやキャンペーンにより負荷が増えそうな時に実施する方法。
• オンデマンドの自動スケーリング
  　アクセスや負荷の状況を監視し、一定の値を超えた時や下回った時、自動で拡大や縮小を行う方法。

並列化

同一の処理行う場合、装置を増やして効率的に処理を実行すること。
例えば、工場で餅を丸める機械があるとします。1台の機械でお餅を丸めるよりも2台で丸める方が早いですよね。
また、同じ機械でお餅を丸めるので、20台の機械で作成しても、機械1~機械20で作成されたお餅は同じものが出来上がります。
そのように、同じ処理を行う装置を増やして効率化することを並列化と言われます。
AWSではシステムの複製が簡単に行うことができるので並列化の処理も容易に取り入れることができます。