多くの有名なサイトがAWSの問題によって影響を受けたと不平をこぼしている。ところがTwilioのAPIおよびサービスは、そのクラウドテレフォニープラットフォームの成長とスケーリングをAWSに大きく依存しているにもかかわらず影響を受けなかった。Twilioの共同創業者でありCTOのEvan Cooke氏は、現在のインターネットエコシステムを実現しているクラウドサービスの驚くべき成功とともに、クラウドサービス構築時の堅牢な分散アーキテクチャ設計の重要性について語っている。
TwilioをAmazon Web Services上でスケールさせる上で、まれですが必ず起こり得るインフラの問題による影響を最小限に留めるため、私たちは次のようなアーキテクチャ設計原則に従いました。
- 障害の単位を単一ホストにする
依存関係のある複数のホストではなく、単一のホストで構成されるシンプルなサービスを作りましょう。サービスインスタンスの複製を作ることで、ホスト障害にも耐えられます。
- 短いタイムアウトとすばやいリトライ
障害が発生したときには、すばやくその障害を特定して要求をリトライしましょう。各サービスの冗長なコピーを複数走らせて、すばやいタイムアウトとリトライを利用することで、障害が発生したサービス、もしくは到達不能なサービスを迂回できます。
- べき等な（Idempotent）サービスインターフェイス
依存関係のあるサービスのAPIがべき等（idempotent）であれば、失敗した要求を安全にリトライできます。
- 小さくステートレスなサービス
シンプルで均一なプールにまとめられるよう、ビジネスロジックを小さくステートレスなサービスに分離しましょう。
- 一貫性要件の緩和
厳格な一貫性を必要としない場合には、冗長な複製のリードデータのプールを作りましょう。
機能停止を考慮して、Twilioはそれほど重要ではなく遅延にセンシティブでないタスクにだけEBSを使っている、とEvan氏は説明した。EBSは「障害の単位を単一ホストにする」という原則を満足しないためだ。もしEBSに問題が起これば、依存関係のあるサービスすべてに障害が発生することになる。彼らはそうする代わりに、EC2にあるEphemeralディスクを永続化目的に利用することに注力した。もし一時的なディスクに障害が発生しても、障害はそのホストに限定される。Evan氏はこのあとの記事で、I/Oパフォーマンスを改善するためにどのようにEphemeralディスクでRAID0ストライピングをしているか説明するようだ。
これはSmugMugがとっている原則とアプローチと一致している。Don McAskill氏が説明するように、SmugMugはEBSを使わないことを決めた。
M-Dot NetworkのCTOであるMike Kavis氏はAmazonのIaaSはPaaSになってきたと語る。
Amazonには開発者が呼び出せる数々のサービスがあります。これらは時間と人的資源をかなり必要とするタスクを引き受けて、シンプルな呼び出しでそれを簡単化したり、自動化してくれます。Cloudwatch（モニタリングおよびオートスケーリング）やAmazon RDS（データベース管理）が思い浮かぶかもしれませんが、これらは多数のサービスのほんの一部にすぎません。こうしたサービスを使い始めると、事実上あなたはベンダー独自のスタックを利用するというPaaSシナリオにいることになります。
アーキテクチャおよびビジネスモデルにおいて、こうした依存関係と機能停止の可能性を考慮しておく必要があると彼は言う。クラウドプロバイダにとらわれないアーキテクチャを構築することは、これらサービスを自分で再構築しない限りほとんど実用的でないためだ。
明らかに、障害復旧計画はクラウドでも必須であり、アーキテクチャはクラウドベースのソリューションを構築する上で今もこれからも重要だ。これは何ら新しいことではない。Twilioの原則は十分だろうか？ クラウドアーキテクチャはここからどう進化するのだろうか？ さらに冗長性が高まるのだろうか？ サービスは内製化されるのだろうか？ さらにアーキテクチャ原則ができるのだろうか？ これはPaaSベースのソリューションへどのように変換するだろうか？