この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。
当エントリでは2017年06月1日に行われた『Architecting for the Cloud -クラウドにおけるアーキテクチャの設計原則』に関する内容をレポートしたいと思います。
発表資料や当日の発表の様子などはAWSの公式ページからも確認することができます。
セッション概要
当セッションの登壇者及び概要は以下の通りです。
スピーカー：
江川 大地
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 ソリューションアーキテクト
江川 大地
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 ソリューションアーキテクト
AWS 上にセキュアで、信頼性が高く、高性能で、コスト効率の高いシステムを設計するには、どうしたらよいでしょうか？
本セッションでは、AWS のメリットを活かした、クラウドらしいアーキテクチャを構築するための原則をご紹介します。伸縮自在性に代表されるクラウドコンピューティングならではの動的な性質を活かすための考え方を学び、AWS らしい設計を行うために意識すべきベストプラクティスについてご紹介します。
セッションレポート
以下、セッションのレポートです。
このセッションで話すこと
- 設計にあたっての疑問
- クラウド・AWSの特性を活かすための設計とは
AWSのメリットとは何か？
- 初期費用ゼロ
- 継続的な値下げ
- 数のメリット
- 商機を逃さない俊敏性
- 最先端の技術
- グローバル展開
クラウドならではの特性
- IT資産をプログラマブルに
- グローバル展開、可溶性、無制限のキャパシティ
- ハイレベルなマネージドサービス
設計原則
スケーラビリティ
- 運用中のシステムを拡張/縮小させる能力
- 柔軟性の向上 (事業規模に応じたリソースの確保)
- コスト削減
- スケーリング
- 垂直スケーリング(スケールアップ/ダウン)
- 1台のスペックを上げる
- リソースの限界がある
- インスタンスの停止を伴う
- 水平スケーリング(スケールアウト/イン)
- リソースの台数を増減
- インスタンスの停止をともなわない
- 水平スケーリングを行う際にこころがけること
- ステートレスアプリケーション
- ステートはリソースの外部へ
- session情報はdynamodb/elasticacheへ
- バイナリ、ログはS3へ
常設のサーバではなく使い捨てのリソース
- リソースに対する考え方を変える
- 今まで(オンプレミス)
- 固定のリソース
- AWS
- いつでも増減可能
- マインドセットの変更
- 柔軟なリソースを有効活用する仕組みへ
- 設定は自動化
- DNSによるアクセス
- バッチの並列化
- 使い捨て可能にするためのポイント
- インスタンスをいつでも復元できるように
- Infrastructure as a Code
- AMI戦略
- 全部AMI
- フルスタックなAMIをつくる
- 一部AMI
- frameworkなど変更しやすい部分を後から
- 最小構成
- chef, ansibleで全て自動セットアップ
自動化
- AWSには様々な自動化サービスがある
- 水平スケーリングの場合
- cloudwatchで負荷監視
- autoscaleで自動スケーリング
疎結合
- 障害の影響を最小限にする
- Well-defined Interface
- 内部情報に依存しない
- IPではなくDNSで
- Service Discovery
- 増減したリソースに透過的にアクセスできるように
- ELBを挟んで内部のアクセスも疎結合に
- webサーバとアプリサーバ
- Asynchronous Integration
- 同期処理が必要でなければ、非同期で
- ブロックされない
- スケーラブル
- 部分的に停止し、メンテナンスしやすい
- SQSを間にはさむ
- Graceful Failure
- リソース停止時に、障害をおこさない
- ELBでの新規振り当て禁止など
サーバではなく、サービスの利用
- 責任共有モデル
- Infrastructure Service
- コンピュートとそれに関わるサービス
- Container Service
- EC2上のコンテナのサービス
- Abstracted Service
- 完全にマネージドなAWSサービス
- Abstracted Serviceであれば、管理責任がAWSに多く寄る
- データベースの使い分け
- サービスの特徴を踏まえて要件に合わせたサービスを
単一障害点の排除
- 冗長化 -> マネージドサービス
- Multi-AZ
- 疎結合
コスト最小化
- クラウドの特性を生かしてコストを削減させる
- 適切なサイジング
- リソースを増減させる
- 継続的な改善
- 適切なインスタンスタイプの選択
- Cloudwatchで常にリソースを監視
- rusted Advisorでリソース検知
キャッシュの利用
- 負荷軽減による性能向上
- コスト削減
- Elasticacheによるインメモリでのキャッシング
- CloudFrontによるコンテンツのEdge caching
セキュリティ
- 全てのレイヤーでセキュリティを確保
- AWsへセキュリティの担保をオフロード
- セキュリティ検知のためのサービスを利用
- AWS WAF
感想
様々な観点からAWSの考える定石についての情報を知れて興味深いセッションでした。
0
