クラウド時代のアーキテクチャ設計 - 次世代アーキテクトが押さえるべきキーポイント - 玉川憲 (Twitter: @KenTamagawa) エバンジェリスト v 1.1 - July 21st, 2011
オープンソース ソフトのライセンス費を90% 削減 AWSクラウド インフラの総運用費を90% 削減 Where open-source computing gave us a 90% reduction in our software, Amazon gave us a 90% reduction in our total operating costs Mark Suster
アーキテクチャ設計
クラウドアーキテクトの 心構え 7 つのプラクティス さいごに
クラウドアーキテクトとして インフラをソフトウェアのように扱う次世代のスケーラビリティ物理デバイス vs. クラウドの特性を理解コスト効率を考える
Demo: インフラをソフトウェアのよう に扱う EC2 でサーバーを 瞬時に起動
iphone からも
Web コンソール ライブラリ & SDK コマンドライン Amazon Web Services API
クラウドアーキテクトとして インフラをソフトウェアのように扱う次世代のスケーラビリティ物理デバイス vs. クラウドの特性を理解コスト効率を考える
これまでのスケーラビリティ 一方通行 Medium Large Small
次世代のスケーラビリティ ドラスティックに伸び縮み Medium Large Small
次世代のスケーラビリティ ドラスティックに伸び縮みする中で : パフォーマンスを維持する運用がやりやすい回復力に富んでいるコスト効率が良い
クラウドアーキテクトとして インフラをソフトウェアのように扱う次世代のスケーラビリティ物理デバイス vs. クラウドの特性を理解コスト効率を考える
物理的なストレージ DAS (Direct-Attached Storage) SAN (Storage Area Network) NAS (Network-Attached Storage)
クラウド時代のストレージ EC2 ( ローカルストレージ ) EBS (Elastic Block Store) S3 (Simple Storage Service) SimpleDB, SQS, etc.
特性を理解する 例えば S3 の耐久性は : 99.999999999 % 1 万個のファイルを 1 千万個おいても 失わない設計 S3 (Simple Storage Service)
クラウド用語集! EBSを付けたEC2をELBの配下におき Route 53で独自ドメインをつけ Cloudfrontで動画配信 S3にバックアップ DBをマルチAZのRDSで動かす
クラウドアーキテクトとして インフラをソフトウェアのように扱う次世代のスケーラビリティ物理デバイス vs. クラウドの特性を理解コスト効率を考える
キャパシティプラニングの弊害 Amazon.com の週間アクセス数
キャパシティプラニングの弊害 Amazon.com の週間アクセス数
キャパシティプラニングの弊害 Amazon.com の 11 月のアクセス数
キャパシティプラニングの弊害 Amazon.com の 11 月のアクセス数
インフラコスト コスト / 規模を線形に 規模感 実際 理想 システムへのリクエストの数
クラウドアーキテクトの 心構え 7 つのプラクティス さいごに
故障に備えた設計 Intro 1 2 3 4 5 6 7 End
フェイルセーフの例
故障に備えた設計 ディスクレベル EBS のスナップショットでバックアップ サーバーレベル AMIを取得して いつでも起動 Elastic IP アドレスロードバランサで冗長構成 データセンターレベル 複数の DC に分散させる ( マルチ AZ)
Demo: EBS のスナップショット
Demo: AMI 作成 ElasticIP
AWS の世界規模のインフラ
AWS のリージョン リージョン : 複数のデータセンターで構成 US West オレゴン US East 東京リージョン US West EU West AP Singapore
アベイラビリティゾーン (AZ) EC2 における AZ は 地理的に離れた場所に US West オレゴン A B US West US East A B C D A B C EU West 東京リージョン A B A B C A B AP Singapore
アベイラビリティゾーン (AZ) AZ 同士は 地理的に離れた場所に リージョン内のネットワークは高速 US West A B C US East A B C D A B C EU West AP Japan A B A B AP Singapore
マルチ AZ 構成 Amazon Route 53 オートスケーリングでサーバ増設 / 縮退自動化 東京リージョン アベイラビリティゾーン A ELB アベイラビリティゾーン B Route 53 で名前解決 ロードバランサーで負荷分散 RDS で DB のインストール 最適化不要 バックアップ パッチ当ても自動化 スペックも後から 変更可能 EC2 RDS マスタ 自動同期 EC2 RDS スレーブ マルチ AZ を用いて 自動レプリケーション 自動フェイルオーバ サーバーを異なる AZ に配置可能 時間課金で Oracle DB( ライセンス込 ), MySQL が利用可能
Demo: ELB で負荷分散 RDS のマルチ AZ
疎結合にする Intro 1 2 3 4 5 6 7 End
Amazon SQS (Simple Queuing Service) プロセスプロセス SQS リージョン キュー 世界中に拠点あり &API 完備 キューのアクセス権の細かな制御が可能 メッセージ プロセスプロセス メッセージキューキューメッセージ 注 : このイメージはあくまでコンセプト図です
例 : ビデオエンコーディング シーケンシャルな作業 A B C D インプット 保存 エンコード 公開
例 : ビデオエンコーディング 非同期で行える A インプット B C D 保存エンコード公開 M M M SQS キュー SQS キュー SQS キュー
例 : ビデオエンコーディング 簡単にスケール! A インプット C B C D 保存エンコード公開 M M M SQS キュー SQS キュー SQS キュー
伸縮自在にする Intro 1 2 3 4 5 6 7 End
Elasticity: 伸縮自在性 スケールアップ スケールアウト
スケールアップ / スケールアウト スケールアップ ( 垂直 )
Demo: EC2 のスケールアップ
スケールアップ / スケールアウト スケールアウト ( 水平 )
Elastic Load Balancing ロードバランサ EC2 EC2サーバを 増減する メカニズム ゾーンA ゾーンB CPU 利用率 Auto Scaling アラーム CloudWatch モニタリングサービス
動 / 静的データの配置 Intro 1 2 3 4 5 6 7 End
動的データ / 静的データの配置 動的データは EC2 の近くに配置する 例 : 大規模データ処理は同じ AZ を使う 静的データはユーザの近くに配置する 例 : Cloudfront を用いたコンテンツ配信
リージョンに加えて
Amazon Cloudfront + Route 53 コンテンツ配信ネットワーク (CDN) + DNS Palo Alto Seattle Newark Amsterdam New York London Dublin Stockholm Tokyo Los Angeles Ashburn Paris Frankfurt Jacksonville Dallas St.Louis Miami ブラジル Singapore Hong Kong
こんなつぶやきも
並列処理を活かす Intro 1 2 3 4 5 6 7 End
新幹線は並列処理? 車体ごとにモーター
クラウドは時短テクニック! ビフォー ジョブ数 n 時間 データ アフター データ
並列処理を使い倒す Elastic Load Balancing Elastic Map Reduce (EMR): Hadoop クラスタ
Demo: Elastic Map Reduce
制約を恐れない Intro 1 2 3 4 5 6 7 End
制約を恐れない データベースのパフォーマンスがでない? 抽象的なクラウドリソース + オンデマンドな調達モデル 無限の可能性
制約を恐れない データベースのパフォーマンスがでない? シャーディング / リードレプリカ
制約を恐れない データベースのパフォーマンスがでない? シャーディング / リードレプリカ RAM がもっと必要? 分散キャッシュ (Memcached): AWS ElastiCache
制約を恐れない データベースのパフォーマンスがでない? シャーディング / リードレプリカ RAM がもっと必要? 分散キャッシュ (Memcached): AWS ElastiCache もっと早いディスクが必要? 複数の EBS を Raid で
全レイヤでセキュリティ Intro 1 2 3 4 5 6 7 End
セキュリティ
全レイヤでセキュリティを考慮 DC ハード OS アプリ ネットワーク
全レイヤでセキュリティを考慮 DC ハード OS アプリ ネットワーク 第 3 者認証 : ISO 27001 PCI-DSS レベル1 等暗号化 : SSL Encrypted FS セキュリティグループ VPC: Virtual Private Cloud IAM: Identity Access Management
セキュリティグループ 自分の PC (107.3.8.123) RDS-servers インターネット RDS RDS RDS 22 80 1521 web-servers app-servers DB-servers EC2 EC2 EC2 EC2 any EC2 22 EC2 1521 EC2 EC2 EC2
Virutal Private Cloud VPN 接続 リージョン EC2 EC2 内に分離した領域を作成 イントラ VPC プライベートサブネット
専有インスタンス : Dedicated Instance 一部のコンプライアンスに対応するため ハードの専有が可能なサービス = デディケイティッドインスタンスを用意 通常の EC2 物理サーバー 顧客 A 顧客 B 顧客 C Dedicated Instance 物理サーバー 顧客 A 顧客 B 顧客 C
Virutal Private Cloud は 仮想ネットワーキング VPN 接続 リージョン EC2 EC2 内に分離した領域を作成 インターネット イントラ VPC プライベートサブネット NAT パブリックサブネット ゲートウェイ
AWSクラウドに専用線接続を可能とする Direct Connectも米国でサービス開始 ( 日本は年度内に計画 ) リージョン EC2 イントラ VPC プライベートサブネット 専用線接続
新しいリージョン AWS GovCloud (US) 米国政府専用のクラウド
IAM: Identity Access Management AWSアカウントの下に 子ユーザ / グループセキュリティ証明書をそれぞれ作成可 APIへのアクセスコントロール特定のリソースへのアクセスコントロール LDAPとの連携可能コストは無料
クラウドアーキテクトの 心構え 7 つのプラクティス さいごに
7 つのプラクティス 1. 故障に備えた設計 2. 疎結合にする 3. 伸縮自在にする 4. 動的データ / 静的データの配置 5. 並列処理を活かす 6. 制約を恐れない 7. 全レイヤでセキュリティを考慮
最古の 建築十書 強がなければ用は果たせない 強と用がなければ美は形だけのもの そして美がなければ建築とはいえない By ウィトルウィウス
最古の 建築十書 Firmitas 強 ( 冗長構成 レプリカ ) Utilitas 用 ( サービスを自在に組合せ ) Venustas 美 ( 伸縮自在 自動化 無駄なし )
AWS は ディベロッパーのための レゴブロック
3S3にwebコンテンツ保存 http://www.slideshare.net/kentamag awa/s3web 他にも 下記の資料をご参考に! 1AWS アカウント開設 http://t.co/3ebghag 2EC2 で Web サーバー立ち上げ http://t.co/hiinygi 3S3 に web コンテンツ保存 http://www.slideshare.net/kentamaga wa/s3web 4EC2 で Windows サーバ立ち上げ http://www.slideshare.net/kentamaga wa/ec2windows 5CloudFormation で Redmine 立ち上げ http://www.slideshare.net/kentamaga wa/aws-cloudformation-redmine
自己紹介 Amazon 100 AWS の無料使用枠 Google 30 Salesforces 毎月 下記の分 無料で使えます 10?? 5 GB/ 月の仮想ストレージ (Amazon S3) 10 万回の Amazon SQS リクエスト 10 万回の Amazon SNS リクエスト 1 GB のストレージ分の Amazon SimpleDB 750 時間分の仮想サーバ 10 GB/ 月の仮想外部ディスク (Elastic Block Storage) 750 時間のロードバランサ (Elastic Load Balancer) 15 GB のインターネットデータ送信 15 GB のインターネットデータ受信
AWS ブログ で最新情報を!!
お問い合わせは http://aws.amazon.com/jp/
操船術が大事ぜよ
明日 11/19 AWSユーザーグループ札幌 14 時 ~ 是非ご参加ください!