本記事は、AWSソリューションアーキテクト認定試験の試験勉強として、「Architecting for the Cloud」を読んでいて、そのまとめです。完全な翻訳ではありません。私の勝手な解釈もいくぶんか含んでいます。その点、理解した上でご自身の学習の参考にしてください。

要約

このドキュメントはAWS上にソリューションを構築するソリューションアーキテクトや開発者のために向けて書かれたものです。 AWS上での設計パターンやセキュアで信頼性のある、ハイパフォーマンスで、コスト効率のいいシステムをどのように設計したらいいかのアドバイスを提供します。これはクラウドの特性（エラスティック性やインフラの自動化）をどのように活かすかという話題も含みます。

導入

大きな変更なく、AWSへアプリケーションを移行できることは、組織にとってセキュリティやコストの面で大きなメリットをもたらします。しかし、クラウドコンピューティングか可能にするエラスティック性やアジリティ性を有効活用するためには、エンジニアはアプリケーションのアーキテクチャを進化させる必要があります。

新しいアプリケーションに対しては、クラウド特有のアーキテクチャパターンを適応させ、効率性・拡張性を確保しています。このようなアーキテクチャはリアルタイムの大規模データ分析からIoTデバイスからの大量のトラフィックを受けるアプリケーションまでどのようなものにも対応します。

このドキュメントは既存のアプリケーションをAWSへ移行するか、クラウドに適した新しいアプリケーションを設計するか検討するための設計原則をしめします。

クラウドコンピューティングの違い

IT資産がプログラマブルになる

クラウドではない環境では、最大のピークに合わせてサーバの調達、プロビジョニングが必要でした。これは、リソースが働いていない時間帯を発生させ、余剰コストがかかることになります。クラウドコンピューティングを利用することで、需要に応じて必要な分だけリソースを利用することができ、またその分のお金を払えばいいことになります。 AWSではサーバやデータベース、ストレージなどを僅かな時間で調達することができます。そのため、リソースを一時的に使い捨てすることができます。有限で固定的なITインフラから開放されます。これは、いままでの管理方法やテスト方法、キャパシティプランニングなどを変えてしまいます。

グローバルに利用できる制限のないインフラ

AWSのグローバルインフラストラクチャを利用することで、アプリケーションを最適のリージョンにデプロイすることができます。エンドユーザの近く、コンプライアンス、コストなど最適な場所を選んで。グローバルアプリケーションにとって、CloudFrontを使うことで世界中でユーザに近いロケーションから配信できるので、レイテンシーを少なくできます。また、複数のデータセンターをまたいだプロダクションアプリケーションやデータベースを運用することはとても簡単です。

マネージドサービス

EC2のコンピュートリソースの他に、AWSカスタマーは様々なストレージやデータベース、分析、アプリケーション、デプロイサービスを利用できます。これらのサービスは開発者が簡単に利用できるようになっているので、組織内の特殊なスキルの依存から開放できるし、新しいソリューションをより早く提供することができるようになります。これらのサービスはAWSによって管理され、運用の複雑さやコストを下げることができます。AWSのマネージドサービスはスケーラビリティとアベイラビリティをもって設計されているため、自前の実装のリスクを下げることができます。

セキュリティ

従来のITでは、インフラのセキュリティ監査は、定期的にそして手動で行われるものでした。AWSでは、設定の変更に対しての継続的な監視を可能にすることができます。AWSのリソースはプログラマブルなため、セキュリティポリシーを形式化（コード化）することができ、インフラ設計の一部として組み込むことができます。セキュリティテストは継続的デリバリーの一部とすることができるのです。結果的に、ソリューションアーキテクトは、より高度なデータ保護やコンプライアンスを実現するためのAWSの多くのセキュリティや暗号化機能を最大限活用できるようになります。

設計原則

拡張性

時間とともに成長を期待されているシステムは、拡張可能なアーキテクチャで構築される必要があります。そのようなアーキテクチャはユーザ、トラフィック、データの増加にもパフォーマンスを落とすことなく対応できます。クラウドコンピューティングは制限がないオンデマンドな拡張を提供しています。そのメリットを活かした設計をしていく必要があります。一般的に垂直スケーリングと水平スケーリングがあります。

垂直スケーリング（スケールアップ）

垂直スケーリングは個々のインスタンスのスペックを上げることで行います。例えば、インスタンスのCPUスペックを上げるなど。 AWS EC2ではインスタンスを停止しリサイズすることで、簡単に垂直スケーリングができます。 この方法のスケーリングには限界があり、必ずしもコスト効率がよくいつでも利用できる方法ではありません。しかし、とても簡単で一時的にはたいてい多くのケースで解決できるものでもあります。

水平スケーリング

水平スケーリングは、インスタンスの数を増やすことでスケールする方法です。クラウドコンピューティングの弾力性を活かしていて、インターネットのアプリケーションにおいては効果的なスケールする方法です。

ステートレスアプリケーション

ユーザやサービスがアプリケーションを利用する時、たいていはセッションを使って一連の操作を行います。ステートレスアプリケーションはセッション情報を保持しないアプリケーションです。例えば、どんなユーザにも同じ結果を返すアプリケーションです。このアプリケーションではどのサーバ・インスタンスから情報を返してもいいので、水平スケーリングができます。

ステートレスコンポーネント

実際には、ほとんどのアプリケーションはなんらかの状態を持ちます。Webアプリケーションではユーザがサインイン状態かどうかトラックする必要があるし、前のアクションに応じてパーソナライズドされた情報を提供する必要があります。自動化された複数のステップをもつ処理もまた、次に何を行うか決定するために前のアクションをトラッキングする必要があります。

例えば、WebアプリケーションはHTTPクッキーを使ってクライアントブラウザのセッションを保持することができます。ブラウザはその情報をサーバ側に後に起こるリクエストごとにおくります。そのため、アプリケーション側で保持する必要はありません。しかしこの方法には２つの欠点があります。１つは、HTTPクッキーの情報はクライアントサイドで改ざんされる可能性があります。そのため、サーバ側はつねに、バリデーションするべき信頼できない情報として扱わなければいけません。２つは、HTTPクッキーは毎回のリクエストで送信されます。つまり、そのサイズを常に最小にする必要がでてきます。

HTTPクッキーに一意のセッション識別子を格納し、サーバー側で詳細なユーザーセッション情報を格納することだけを考えましょう。ほとんどのプログラミングプラットフォームは、このように動作するネイティブのセッション管理メカニズムを提供しますが、これはデフォルトではローカルファイルシステムに格納されることがよくあります。これにより、ステートフルなアーキテクチャが実現します。この問題の一般的な解決策は、ユーザーセッション情報をデータベースに格納することです。Amazon DynamoDBはスケーラビリティ、高可用性、および耐久性の特性をもつために最適な選択肢です。多くのプラットフォームでは、オープンソースのライブラリがあり、セッションをAmazon DynamoDBに保存することができます。

他のシナリオでは、より大きなファイル（例えば、ユーザアップロード、バッチプロセスの中間結果など）の記憶が必要である。 これらのファイルをAmazon S3やAmazon Elastic File System（Amazon EFS）などの共有ストレージレイヤに配置することで、ステートフルなコンポーネントの導入を避けることができます。もう1つの例は、各実行の現在の状態を追跡する必要がある複雑なマルチステップワークフローです.Amazon Simple Workflow Service（Amazon SWF）を使用して、実行履歴を一元的に保存し、これらのワークロードをステートレスにすることができます。

ステートフルコンポーネント

必然的に、ステートレスコンポーネントにすることのできないアーキテクチャのレイヤーもあるでしょう。まずはじめに、定義的にデータベースはステートフルです。加えて、多くのレガシーアプリケーションはローカルのリソースに依存し、１つのサーバ上で動作するように設計されています。さらに、他のユースケースでは、特定のサーバと長時間コネクションを維持するクライアントを必要とするかもしれません。例えば、リアルタイムのマルチプレーヤーゲームでは、非常に低レイテンシーでプレイヤーにゲーム世界のビューを提供しなければいけません。これは、プレーヤーが同じサーバに接続する非分散的な実装のほうが、実現が簡単です。