【レポート】AWS Summit Tokyo 2017: Architecting for the Cloud -クラウドにおけるアーキテクチャの設計原則 #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年06月1日に行われた『Architecting for the Cloud -クラウドにおけるアーキテクチャの設計原則』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜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の考える定石についての情報を知れて興味深いセッションでした。