Architecting for the Cloud – AWS Best Practices
クラウドのためのアーキテクチャ – AWSのベストプラクティスのホワイトペーパーはアーキテクチャのパターンとシステムをセキュアで、高い信頼性で、高パフォーマンスで、コスト効果が高くするたえのアドバイスを提供します。
AWSデザインの原則
スケーラビリティ
- AWSは仮想的に無制限のオンデマンドなキャパシティを提供するため、アーキテクチャはこれらのリソースを有利に使うための設計をすべきです。
- ITアーキテクチャをスケールさせるためには、以下の2つの方法があります。
- 垂直スケーリング
- ここのリソースの使用を増加させる。つまり、EC2のインスタンスタイプをアップデートし、RAM、CPU、IOPS、ネットワークのキャパシティを増加させる。
- このアプローチは次第に限界に到達するため、常にコスト効果が高く、高可用性があるとは限りません。
- 水平スケーリング
- リソースの数を増加させる。つまり、より多くのEC2インスタンスやEBSボリュームを使用する。
- このアプローチはクラウドコンピューティングの弾性を活用できます。
- ワークロードの複数のリソースに分散させる設計を全てのアーキテクチャで取れるわけではありません。
- アプリケーションｈあステートレスにすべきです。
- 過去のインタラクションを知っている必要はなく、セッション情報を保持しないようにします。
- 実行中のタスクが終了した後、キャパシティを増加、減少できます。
- ステートを保存する必要がある場合、以下の方法で実装できます。
- 低遅延な外部ストア（DynamoDB、Redis等）を使い、ステートを維持します。
- ELBのスティッキーセッションを使うことで、セッションの全てのトランザクションを特定の計算リソースにバインドできます。しかし、既存セッションにおいては、新しく追加したリソースの利用は保証されない、もしくは、リソース追加の優位性を受けることはできません。
- 処理負荷は以下の方法で複数のリソースに分散できます。
- ELBを使った複数のEC2インスタンスに跨がり負荷を分散するプッシュモデル
- SQLやKinesisを使用した複数のコンシュマーがサブスクライブし、処理するプルモデル
- EMRやKinesisを使った分散処理は大量のデータをタスクに分割し、データを小さく分割します。
- 垂直スケーリング
固定されたサーバではなく、使い捨てリソース
- リソースは永続的に固定されたオンプレミスのリソースの様に扱うのではなく、一時的で使い捨てるように扱います。
- AWSはイミュータブルなインフラというコンセプトを持っており、
- サーバは一度ローンチされると、そのライフタイムを通じてアップデートしない
- アップデートはサーバを新しく最新の設定で作ることで実施する
- これにより、リソースは常に（テストされ）整合性を保った状態となり、ロールバックを容易にします。
- AWSは計算リソースを自動的、繰り返しインスタンス化する複数の方法を提供しています。
- ブートストラッピング
- スクリプトにより構成、設定を実施する、すなわち、data scriptやcloud-initを使用してソフトウェアをインストール、リソース・コードのコピーを実施する方法
- ゴールデンイメージ
- リソースを特定の状態でスナップショットを取る方法
- スタートさせるための時間を短縮するとともに構成するサービスとのやサードパーティのレポジトリとの依存関係をなくせます。
- コンテナ
- AWSはElastic BeanstalkやECSでDockerイメージをサポートしています。
- Dockerにより、ソフトウェアを実行するのに必要な全て：コード、ランタイム、システム・ツール、ライブラリなど、を含んで、Dockerイメージとしてパッケージ化し、ソフトウェア開発の標準的なユニットとできます。
- ブートストラッピング
- Infrastructure as Code
- AWSの資産は、プログラマブルで、技術、プラクティス、ソフトウェア開発のツールを適用して、インフラストラクチャ全体を再利用可能、保守可能、拡張性、およびテスト可能にすることができます。
- AWSはそのようなサービスとして、CloudFormation、OpsWorksを提供しています。
自動化
- AWSは様々な自動化ツールやサービスを提供しており、システムの安定性、効率化、市場投入までの時間の改善に役立ちます。
- Elastic Beanstalk
- リソースのプロビジョニング、ロードバランシング、オートスケーリング、監視等を担い、アプリケーションの迅速なデプロイを実施できるPaaSです。
- EC2 Auto Recovery
- EC2インスタンスを監視するCloudWatchアラームを作成し、障害発生時に自動復旧させます。
- 復旧したインスタンスはオリジナルのインスタンスと同じであり、instance ID、プライベートIPアドレス、Elastic IPアドレス、全てのインスタンスメタデータは同じです。
- インスタンスは再起動によりマイグレーションされるため、メモリの内容は消去されます。
- Auto Scaling
- 定義された条件にて、自動的にアプリケーションの可用性を維持し、キャパシティをスケールアップ/ダウンします。
- CloudWatch Alarms
- SNS
- 特定のメトリックがある期間内に指定したしきい値を超えた場合にSNSをトリガーできます
- CloudWatch Events
- AWSリソース変化時にシステム・イベントのストリームをリアルタイムに作成します。
- OpsWorks
- 環境の変更に合わせてインスタンスの構成を自動的に更新するライフサイクルイベントを通じて連続的な構成が可能です。
- イベントはChefのレシピをトリガーすることができ、各インスタンスに特定の構成タスクを実行できます。
- Lambda Scheduled Events
- Lambda関数を定期的なスケジュールで実行するよう設定が可能です。
- Elastic Beanstalk
疎結合
- AWSは相互依存関係を減らし、各コンポーネントの変更や障害が他のコンポーネントにカスケードしないように、疎結合なアーキテクチャを構成できます。
- 非同期統合
- SQSやKinsisによる、直接的なポイントツーポイントのインタラクションをしない、中間の耐久性のあるストレージレイヤー
- 追加の弾力性を導入することでコンポーネント間を切り離します
- 要求が登録されたackで十分な、即時応答を必要としない任意の相互作用に適しています
- サービスディスカバリー
- 任意の時点で新しいリソースを起動または終了させることができます。ELBを用いて、配下にあるインスタンスの詳細を隠したり、Route 53ゾーンにより抽象ロードバランサのエンドポイントを隠すことができます。
- よく定義されたインターフェース
- 様々なコンポーネント間を特定の技術に依存しないインターフェースで接続します。API Gatewayを用いたRESTfulなAPIを使用します。
- 非同期統合
サーバでなく、サービス
データベース
- AWSは異なるカテゴリのデータベーステクノロジーを提供しています。
- Relational Databases (RDS)
- 行と列で構成されるテーブル構造にデータを正規化します。
- 強力なクエリ言語を提供し、柔軟、インデックス可能、完全性、高速で効率的な方法による複数テーブルのデータの結合が可能
- リソース増加による垂直スケーラビリティ、リードレプリカによる読み込みに対する水平スケーラビリティ、シャーディングやパーティショニングによる書き込みに対する水平スケーラビリティの確保が可能です。
- データを同期的に複製するマルチAZ構成による高可用性を提供します。
- NoSQL Databases (DynamoDB)
- リレーショナル・データベースのいくつかのクエリやトランザクション能力とのトレードにより、水平スケーラビリティをシームレスに実現するより柔軟なデータモデルを提供します。
- データパーティショニングやレプリケーションにより読み込み、書き込み双方に対して水平スケーリングを可能としています。
- DynamoDBはサーバ障害やアベイラビリティゾーン障害に対して、AWSリーsジョン内の3つのファシリティに対してデータを同期的にコピーすることで、耐障害性提供しています。
- Data Warehouse (Redshift)
- 大量データの分析とレポートに最適化されたリレーショナルデータベースです。
- Redshiftはmassively parallel processing (MPP)、カラム指向のデータストレージ、対象データに対する圧縮の組み合わせにより、効率的なデータアーカイブと最適な検索性能を提供します。
- RedshiftのMPPアーキテクチャはデータウェアハウスクラスタのノード数の増加によるパフォーマンス増加を可能とします。
- Relational Databases (RDS)
- より詳細な情報はAWS Storage Options Whitepaperを参照してください。
単一障害点をなくす
- AWSは冗長性、自動復旧、中断の削減をアーキテクチャの全てのレイヤーにて実装する方法を提供します。
- AWSは以下の方法で冗長性の確保をサポートします。
- Standby Redundancy
- リソースに障害が発生した際、フェイルオーバーにより待機系のリソースで機能を復旧させます。
- フェイルオーバーは完了するまでにいくらか時間を要するため、その期間はリソースを使用することができません。
- 待機系のリソースは（コスト削減のために）必要な時のみ自動的に起動することも、（フェイルオーバを加速し、中断を最小限にするために）常に起動させておくことも可能です。
- Standby redundancyはリレーショナルデータベースなど、ステートフルなコンポーネントにてよく使用されます。
- Active Redundancy
- 複数の冗長性を持つ分散リソースにより、一つに障害が発生しても、残りのリソースにより、ワークロードを吸収させます。
- standby redundancyに比べ、運用しやすく、障害時の影響は少なくなります。
- Standby Redundancy
- AWSがサポートするレプリケーション
- 同期レプリケーション
- プライマリロケーションとそのレプリカの両方に永続的に格納されたトランザクションを認識します。
- プライマリノードの障害イベントからデータの完全性を保護します。
- 最新データに対するクエリ（強い一貫性）の読み込み性能をスケールさせるためにも使用されます。
- パフォーマンスと可用性はトレードオフとなります。
- 非同期レプリケーション
- プライマリノードとレプリカは複製の遅延により、切り離されます。
- 複製の遅延が問題にならないシステムのクエリに対する読み込み性能を水平スケールさせるために使用されます。
- Quorumベースのreplication
- 同期、非同期レプリケーションを組み合わせ、大規模分散データベースを構築できます。
- 最少の野＝度数を定義しておき、書き込み処理の成功を判定することで、複数のノードへの複製を管理します。
- 同期レプリケーション
- AWSは単一障害点を少なくする、あるいは、減らすサービスを提供しています。
- リージョン、アベイラビリティゾーンにおける複数のデータセンター
- ELBもしくはRoute53によるヘルスチェックと正常なエンドポイントへのルーティングによる障害の隠蔽
- 異常が発生したノードを自動的に置き換えるAuto Scaling
- 障害が発生したノードを復旧させるEC2 auto-recovery
- 複数のファシリティに対してデータを保存するS3、DynamoDB
- マルチAZのRDS及びリードレプリカ
- レプリケーションと自動フェイルオーバをサポートするElastiCache Redisエンジン
- より詳細な情報はAWS Disaster Recovery Whitepaperを参照してください。
コストの最適化
- AWSは、AWSの規模の経済の結果として、企業が設備投資を削減し、節約を促進するのに役立ちます。
- AWSはユースケース毎に利用すべき複数のオプションを提供しています。
- EC2インスタンスタイプ
- オンデマンドインスタンス
- リザーブドインスタンス
- スポットインスタンス
- Trusted AdvisorやEC2の利用履歴
- S3ストレージクラス
- 標準ストレージ
- 低冗長化ストレージ
- Standard-IA（低頻度アクセス）
- EBSボリューム
- マグネティック
- 汎用SSD
- プロビジョンドIOPS SSD
- タグに基づくコストの特定
- オンデマンドなキャパシティの水平アップダウンを可能とするAuto Scaling
- アイドル中、冗長なりソースに課金されないLambdaによるアーキテクチャ
- AWSによりスケールされるマネージドサービスの活用（ELB、CloudFront、Kinesis、SQS、CloudSearchなど）
- EC2インスタンスタイプ
キャッシュ
- キャッシュによりアプリケーションのパフォーマンスとコスおt効果が増加します。
- アプリケーションデータのキャッシュ
- 情報を保存、取得可能な、高速、マネージド、インメモリなキャッシュサービスを提供します。
- ElastiCacheは容易にデプロイ、運用、スケール可能なインメモリキャッシュのWebサービスであり、MemcachedとRedisの2つのオープンソスのインメモリキャッシュエンジンをサポートします。
- エッジでのキャッシュ
- 閲覧者に対してより近い場所にあるインフラにおいてコンテンツを提供することで、低遅延、持続的な高データ転送速度により、多くのエンドユーザへのスケーラブルなデータ配信を可能とします。
- CloudFrontは複数のエッジロケーションを持つContent Delivery Network (CDN)であり、静的・動的なコンテンツのコピーをキャッシュすることができます。
- アプリケーションデータのキャッシュ
セキュリティ
- AWSの責任共有モデル
- AWSは基盤となるクラウドインフラのセキュリティを担当します。
- ユーザはAWSにデプロイされるワークロードのセキュリティを担当します。
- AWSは十分なセキュリティに関する機能も提供します。
- IAMにより、ユーザ、グループ、AWSリソースに対して詳細なポリシーのセットを定義、適用できます。
- IAMロールにより自動的に配布、ローテーションされる、リソースに対する短期間のクレデンシャルをアサインできます。
- Amazon Cognitoはモバイル・アプリケーション向けにAWSリソースに対するアクセスを許可する一時的なトークンを発行します。
- VPCはサブネット、セキュリティグループ、ルーティング制御によりインフラの一部を隔離します。
- WAFはWebアプリケーションを、SQLインジェクションや他のアプリケーションコードの脆弱性から保護する際に役立ちます。
- CloudWatch logsは一時的なサーバ利用におけるログの集中管理に役立ちます。
- CloudTrailはAWSのAPIコールを監査し、ログをS3バケットへの配信できます。ログはイミュータブルに保存し、自動的に処理して通知するか、あなたの代わりにアクションを実施することで、組織を違反から保護することができます。
- AWS Config、Amazon Inspector、AWS Trusted Advisorはコンプライアンスもしくは脆弱性を監視し、ITインフラに対するコンプライアンスが遵守されているかどうか明示します。
- より詳細な情報はAWS Security Whitepaperを参照してください。
参考文献
Architecting for the Cloud: AWS Best Practices – Whitepaper – 2016
本ページはJayendra’s Blogを許可のもと、日本語訳し、転載したものです。
本ページに関する全ての権利は、Jayendra’s Blogに留保されます。
随時、翻訳後掲載していきます。
Thanks, Jayendra san
