実践!AWSクラウドデザインパターン

11,200 views
10,945 views

Published on

0 Comments
31 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
11,200
On SlideShare
0
From Embeds
0
Number of Embeds
5,367
Actions
Shares
0
Downloads
117
Comments
0
Likes
31
Embeds 0
No embeds

No notes for slide

実践!AWSクラウドデザインパターン

  1. 1. 実践!AWSクラウドデザインパターン ITアーキテクトカンファレンス2013 アイレット株式会社
  2. 2. 目次 •  ⾃自⼰己紹介 •  クラウドアーキテクティング原則 •  Cloud  Design  Pattern  (CDP) •  CDPの適⽤用例例(事例例) •  まとめ 2
  3. 3. 目次 •  ⾃自⼰己紹介 •  クラウドアーキテクティング原則 •  Cloud  Design  Pattern  (CDP) •  CDPの適⽤用例例(事例例) •  まとめ 3
  4. 4. 自己紹介 鈴鈴⽊木  宏康(すずき  ひろやす) アイレット株式会社  取締役  CTO 好きなAWSサービス Amazon  Simple  Icons 好きなクラウドデザインパターン(CDP) CloudHub  パターン 4
  5. 5. 自己紹介 鈴鈴⽊木  宏康(すずき  ひろやす) アイレット株式会社  取締役  CTO 好きなAWSサービス Amazon  Simple  Icons http://blog.suz-‐‑‒lab.com/ 好きなクラウドデザインパターン(CDP) https://twitter.com/suz_̲lab CloudHub  パターン http://www.facebook.com/suz.lab 5
  6. 6. cloudpack 6
  7. 7. cloudpack •  AWSの導⼊入設計から運⽤用・保守まで  (MSP) •  24/365体制、⼀一部利利⽤用も可 •  AWSをお客様が利利⽤用しやすい形で提供 •  定額・課⾦金金請求払い、バースト保証、… 7
  8. 8. cloudpack •  AWSの導⼊入設計から運⽤用・保守まで  (MSP) •  24/365体制、⼀一部利利⽤用も可 •  AWSをお客様が利利⽤用しやすい形で提供 •  定額・課⾦金金請求払い、バースト保証、… 2013年年度度 世界で17社 ⽇日本で2社 8
  9. 9. cloudpack •  AWSの導⼊入設計から運⽤用・保守まで  (MSP) •  24/365体制、⼀一部利利⽤用も可 •  AWSをお客様が利利⽤用しやすい形で提供 •  定額・課⾦金金請求払い、バースト保証、… 9
  10. 10. cloudpack •  AWSの導⼊入設計から運⽤用・保守まで  (MSP) •  24/365体制、⼀一部利利⽤用も可 •  AWSをお客様が利利⽤用しやすい形で提供 •  定額・課⾦金金請求払い、バースト保証、… 2014年年度度 世界で22社 ⽇日本で2社 10
  11. 11. 目次 •  ⾃自⼰己紹介 •  クラウドアーキテクティング原則 •  Cloud  Design  Pattern  (CDP) •  CDPの適⽤用例例(事例例) •  まとめ 11
  12. 12. クラウドアーキテクティング原則 クラウドの特性を考えると、これまでのシステムアーキテクティングと異異なった 視点が必要となる。それをクラウドアーキテクティング原則として整理理している。 12
  13. 13. クラウドアーキテクティング原則 クラウドの特性を考えると、これまでのシステムアーキテクティングと異異なった 視点が必要となる。それをクラウドアーキテクティング原則として整理理している。 •  できるだけサービスを利利⽤用 •  机上実験よりも実証実験 •  スモールスタートからスケールアウト •  変化に対し全レイヤで対処 •  故障のための設計(Design  For  Failure) •  最初だけでなく周期的なカイゼン 13
  14. 14. クラウドアーキテクティング原則 クラウドの特性を考えると、これまでのシステムアーキテクティングと異異なった 視点が必要となる。それをクラウドアーキテクティング原則として整理理している。 •  できるだけサービスを利利⽤用 •  机上実験よりも実証実験 •  スモールスタートからスケールアウト •  変化に対し全レイヤで対処 •  故障のための設計(Design  For  Failure) •  最初だけでなく周期的なカイゼン 14
  15. 15. できるだけサービスを利用 すでにクラウド上に存在しているサービスのメリット/デメリットを正確に理理解し、 使いこなせることが重要である。利利⽤用者としては、⾞車車輪輪の再開発は極⼒力力避けるべ きである。 15
  16. 16. できるだけサービスを利用 すでにクラウド上に存在しているサービスのメリット/デメリットを正確に理理解し、 使いこなせることが重要である。利利⽤用者としては、⾞車車輪輪の再開発は極⼒力力避けるべ きである。 16
  17. 17. 例: S3でWebサイトのホスティング 17
  18. 18. 例: S3でWebサイトのホスティング •  99.999999999%  の堅牢牢性と、99.99%  の可⽤用性を提供 •  3ヶ所以上の異異なるロケーションにデータ保管 •  データ転送料料、ファイルサイズで課⾦金金(基本的にEC2より安価) 18
  19. 19. 例: RDSでマネージドリレーショナルデータベース 19
  20. 20. 例: RDSでマネージドリレーショナルデータベース •  ⾃自動バックアップ、Restore  To  Point  In  Time •  レプリケーション  (Multi-‐‑‒AZ、Read  Replica) •  パッチ管理理  (⾃自動マイナーバージョンアップ) 20
  21. 21. 机上実験よりも実証実験 クラウドの良良さは瞬時に安く調達できることなので、机上の実験に時間をかけず、 その場ですぐに試すべきである。そうすることで短時間で精度度の⾼高い結果がわか り、よりカイゼンもできる。 21
  22. 22. 机上実験よりも実証実験 クラウドの良良さは瞬時に安く調達できることなので、机上の実験に時間をかけず、 その場ですぐに試すべきである。そうすることで短時間で精度度の⾼高い結果がわか り、よりカイゼンもできる。 数⽇日 22
  23. 23. 机上実験よりも実証実験 クラウドの良良さは瞬時に安く調達できることなので、机上の実験に時間をかけず、 その場ですぐに試すべきである。そうすることで短時間で精度度の⾼高い結果がわか り、よりカイゼンもできる。 数⽇日 数分 23
  24. 24. 例: EC2でキャパシティプランニングの短縮 •  負荷テストでリソース不不⾜足が分かった場合、その後の調整(チューニング)が⼤大変 •  ハードウェアの調達に時間がかかり、買って使ったら返品できない •  事前のキャパシティプランニングに時間をかけてしまう(精度度を上げるため) オンプレミス キャパシティプランニング 負荷テスト 調整 負荷テスト 24
  25. 25. 例: EC2でキャパシティプランニングの短縮 •  負荷テストでリソース不不⾜足が分かった場合、その後の調整(チューニング)が⼤大変 •  ハードウェアの調達に時間がかかり、買って使ったら返品できない •  事前のキャパシティプランニングに時間をかけてしまう(精度度を上げるため) オンプレミス キャパシティプランニング 負荷テスト 調整 負荷テスト クラウド (AWS) •  負荷テストでリソース不不⾜足が分かったらすぐに調整(スケールアップ/アウト) •  調整時に仮想サーバを増やしすぎたら減らせばいい(課⾦金金も⽌止まる) 25
  26. 26. ただし…(注意点) できるだけサービスを利利⽤用 •  何でもかんでもサービスを使えばいいというわけではない •  ちゃんとできないことも把握して適材適所で利利⽤用する 26
  27. 27. ただし…(注意点) できるだけサービスを利利⽤用 •  何でもかんでもサービスを使えばいいというわけではない •  ちゃんとできないことも把握して適材適所で利利⽤用する •  独⾃自ドメインでHTTPS通信が利利⽤用できない •  BASIC認証が利利⽤用できない 27
  28. 28. ただし…(注意点) できるだけサービスを利利⽤用 •  何でもかんでもサービスを使えばいいというわけではない •  ちゃんとできないことも把握して適材適所で利利⽤用する •  独⾃自ドメインでHTTPS通信が利利⽤用できない •  BASIC認証が利利⽤用できない •  OSにログインできない •  権限の制約などによる利利⽤用できない機能がある •  ローカルディスクへのデータの書き出しなど 28
  29. 29. ただし…(注意点) 机上実験よりも実証実験 •  必要な仮想サーバの性能と数量量を決めるためのキャパシティプランニングは、 事前に時間をかける必要は無いが… •  負荷に対するアーキテクチャを間違えると負荷テストの結果、必要な仮想 サーバの性能と数量量が膨⼤大(=⾼高額)になる可能性も… •  終盤のアーキテクチャの変更更は危険がいっぱい… •  頼みのスケールアップも限界はある… 29
  30. 30. ただし…(注意点) 机上実験よりも実証実験 •  必要な仮想サーバの性能と数量量を決めるためのキャパシティプランニングは、 事前に時間をかける必要は無いが… •  負荷に対するアーキテクチャを間違えると負荷テストの結果、必要な仮想 サーバの性能と数量量が膨⼤大(=⾼高額)になる可能性も… •  終盤のアーキテクチャの変更更は危険がいっぱい… •  頼みのスケールアップも限界はある… アーキテクチャの設計は机上の実験も含め、 事前に時間をかけたい! 30
  31. 31. 目次 •  ⾃自⼰己紹介 •  クラウドアーキテクティング原則 •  Cloud  Design  Pattern  (CDP) •  CDPの適⽤用例例(事例例) •  まとめ 31
  32. 32. デザインパターン (ソフトウェア) 過去のソフトウェア設計者が発⾒見見し編み出した設計 ノウハウを蓄積し、名前をつけ、再利利⽤用しやすいよ うに特定の規約に従ってカタログ化したものである。   32
  33. 33. Gang of Four •  エーリヒ・ガンマ •  ラルフ・ジョンソン •  リチャード・ヘルム •  ジョン・ブリシディース オブジェクト指向のソフトウェアにおける有名な23種類の デザインパターンと呼ばれるデザインパターンを考え出した ⽣生成に関するパターン 構造に関するパターン 振る舞いに関するパターン ・Abstract  Factory ・Adapter ・Chain  of  Responsibility ・Builder ・Bridge ・Command ・Factory  Method ・Composite ・Interpreter ・Prototype ・Decorator ・Iterator ・Singleton ・Facade ・Mediator ・Flyweight ・Memento ・Proxy ・Observer ・State ・Strategy ・Template  Method ・Visitor 33
  34. 34. Gang of Four •  エーリヒ・ガンマ •  ラルフ・ジョンソン •  リチャード・ヘルム •  ジョン・ブリシディース オブジェクト指向のソフトウェアにおける有名な23種類の デザインパターンと呼ばれるデザインパターンを考え出した ⽣生成に関するパターン 構造に関するパターン 振る舞いに関するパターン ・Abstract  Factory ・Adapter ・Chain  of  Responsibility ・Builder ・Bridge ・Command ・Factory  Method ・Composite ・Interpreter ・Prototype ・Decorator ・Iterator ・Singleton ・Facade ・Mediator ・Flyweight ・Memento ・Proxy ・Observer ・State ・Strategy ・Template  Method ・Visitor 34
  35. 35. 例: Factory Method パターン 他のクラスのコンストラクタをサブクラスで上書き可能な⾃自分のメソッド に置き換えることで、  アプリケーションに特化したオブジェクトの⽣生成を サブクラスに追い出し、クラスの再利利⽤用性を⾼高めることを⽬目的とする。 35
  36. 36. AWSには多種多様なサービス/コンポーネントが存在 EC2,  ELB,  RDS,  S3,  VPC,  SQS,  SES,  EMR,  IAM,  DX,  … 36
  37. 37. AWSクラウドデザインパターン AWSクラウドを使ったシステムアーキテクチャ設計を⾏行行う際 に発⽣生する、典型的な問題とそれに対する解決策・設計⽅方法 を、分かりやすく分類して、ノウハウとして利利⽤用できるよう に整理理したものである。   37
  38. 38. 発端 •  2011/11  アーキテクトトレーニング  in  シアトル   •  そろそろAWS上での構築パターンをまとめよう! 38
  39. 39. 発端 •  2011/11  アーキテクトトレーニング  in  シアトル   •  そろそろAWS上での構築パターンをまとめよう! Ninja  of  Three 39
  40. 40. Wiki http://aws.clouddesignpattern.org/ 40
  41. 41. 書籍 Amazon  Web  Services   クラウドデザインパターン  設計ガイド クラウドデザインパターン  実装ガイド 41
  42. 42. 48パターン 基本 静的コンテンツを処理理 運⽤用保守 ・Snapshot ・Web  Storage ・Bootstrap ・Stamp ・Direct  Hosting ・Cloud  DI ・Scale  Up ・Private  Distribution ・Stack  Deployment ・Scale  Out ・Cache  Distribution ・Server  Swapping ・Ondemand  Disk ・Private  Cache  Distribution ・Monitoring  Integration 可⽤用性を向上 ・Rename  Distribution ・Web  Storage  Archive ・Multi-‐‑‒Server データをアップロード ・Weighted  Transition ・Multi-‐‑‒Datacenter ・Write  Proxy ・Hybrid  Backup ・Floating  IP ・Storage  Index ネットワーク ・Deep  Health  Check ・Direct  Object  Upload ・OnDemand  NAT 動的コンテンツを処理理 リレーショナルデータベース ・Backnet ・Clone  Server ・DB  Replication ・Functional  Firewall ・NFS  Sharing ・Read  Replica ・NFS  Replica ・Inmemory  DB  Cache ・State  Sharing ・Sharding  Write ・WAF  Proxy ・URL  Rewriting バッチ処理理 ・CloudHub ・Rewrite  Proxy ・Queuing  Chain ・Cache  Proxy ・Scheduled  Scale  Out ・Operational  Firewall ・Multi  Load  Balancer ・Priority  Queue ・Job  Observer ・Scheduled  Autoscaling 42
  43. 43. 48パターン 基本 静的コンテンツを処理理 運⽤用保守 ・Snapshot ・Web  Storage ・Bootstrap ・Stamp ・Direct  Hosting ・Cloud  DI ・Scale  Up ・Private  Distribution ・Stack  Deployment ・Scale  Out ・Cache  Distribution ・Server  Swapping ・Ondemand  Disk ・Private  Cache  Distribution ・Monitoring  Integration 可⽤用性を向上 ・Rename  Distribution ・Web  Storage  Archive ・Multi-‐‑‒Server データをアップロード ・Weighted  Transition ・Multi-‐‑‒Datacenter ・Write  Proxy ・Hybrid  Backup ・Floating  IP ・Storage  Index ネットワーク ・Deep  Health  Check ・Direct  Object  Upload ・OnDemand  NAT 動的コンテンツを処理理 リレーショナルデータベース ・Backnet ・Clone  Server ・DB  Replication ・Functional  Firewall ・NFS  Sharing ・Read  Replica ・NFS  Replica ・Inmemory  DB  Cache ・State  Sharing ・Sharding  Write ・WAF  Proxy ・URL  Rewriting バッチ処理理 ・CloudHub ・Rewrite  Proxy ・Queuing  Chain ・Cache  Proxy ・Scheduled  Scale  Out ・Operational  Firewall ・Multi  Load  Balancer ・Priority  Queue ・Job  Observer ・Scheduled  Autoscaling 43
  44. 44. 例: Clone Server パターン •  解決したい課題 •  クラウドでの解決  /   パターンの説明 •  実装 •  構造 •  利利点 •  注意点 •  その他 •  関連ブログ 44
  45. 45. 例: Clone Server パターン •  解決したい課題 •  スケールアウト構成は⼀一般的な⼿手法であるが、スモール スタートしたシステムでは、そもそも複数サーバーで サービス提供できる構成になっていないことが多い。そ のような場合、負荷対策が必要となった場合に、時間が かかってしまう。 45
  46. 46. 例: Clone Server パターン •  クラウドでの解決  /  パターンの説明 •  このパターンは、負荷分散が考慮されていないシステム を、容易易に負荷分散可能なシステムにする。既に存在す るサーバーをマスターとし、追加するサーバーのマシン イメージを⽤用意する。そのマシンイメージには、コンテ ンツ同期やデータベース接続の調整を⾏行行っておく。そう しておけば、マシンイメージを起動するだけでスケール アウトによる負荷分散が実現可能となる。 46
  47. 47. 例: Clone Server パターン •  実装 •  ロードバランサーサービスの「ELB」とマシンイメージの「AMI」を利利⽤用する。負 荷分散できるようにコンテンツ同期などを調整したクローン⽤用AMIを作成し、負荷 が重くなればクローン⽤用AMIからEC2インスタンスを起動する。それをELBの負荷 分散対象にすれば、既存システムの変更更をほぼ⾏行行わずにスケールアウトできる。 •  ⼿手順 •  (EC2が⼀一つの構成の場合)ELBを⽴立立ち上げて、EC2をその配下に置く。 •  現在稼働しているEC2からクローン⽤用EC2を作成する。 •  クローン⽤用EC2は下記の⽅方法などで必要に応じてマスターEC2とファイルの同期を⾏行行う。 •  定期的にrsyncなどを⽤用いて同期 •  起動時にrsyncなどで同期し、適宜Capistranoなどで、アプリ・コンテンツを配信[関連ブ ログ  1] •  負荷に伴い(または⾼高負荷が予測されたとき)、必要な数のクローン⽤用EC2を稼働させ、 ELBに追加する。 47
  48. 48. 例: Clone Server パターン •  構造 48
  49. 49. 例: Clone Server パターン •  利利点 •  現状のシステムを変更更することなく、容易易にスケールアウトによる負荷分 散を⾏行行うことができる。 49
  50. 50. 例: Clone Server パターン •  利利点 •  現状のシステムを変更更することなく、容易易にスケールアウトによる負荷分 散を⾏行行うことができる。 •  注意点 •  マスターEC2がSPOFになってしまう。 •  マスターEC2でデータベースが動作している場合、クローン⽤用EC2では データベースを動作させず、データベース接続先をマスターEC2にする。 •  ファイルのアップロードや書き込みがある場合は、その処理理をマスター EC2で⾏行行う(Apacheのmod_̲proxyを⽤用いて、該当URLのみクローン⽤用仮 想サーバーからマスター仮想サーバーにプロキシーさせるなど)。 50
  51. 51. 例: Clone Server パターン •  その他 •  NFS  Sharingパターン、NFS  Replicaパターンを参照。 51
  52. 52. 例: Clone Server パターン •  その他 •  NFS  Sharingパターン、NFS  Replicaパターンを参照。 •  関連ブログ 1.  ↑  @ijin  の「Auto  Scalingの設定とデプロイ⽅方法」 (  http://ijin.github.com/blog/2012/12/03/cdp/  ) 52
  53. 53. 他のパターン http://aws.clouddesignpattern.org/ 53
  54. 54. 目次 •  ⾃自⼰己紹介 •  クラウドアーキテクティング原則 •  Cloud  Design  Pattern  (CDP) •  CDPの適⽤用例例(事例例) •  まとめ 54
  55. 55. 日本プロゴルフ選手権大会(2010) 55
  56. 56. 日本プロゴルフ選手権大会(2010) 課題 •  ⽇日本プロ開催期間中のサイ トへのトラフィックに耐え られない 56
  57. 57. 日本プロゴルフ選手権大会(2010) 今までの対応 •  ⼤大会期間、⼀一時的に他のホスティングサービスにコピーサ イト(静的コンテンツのみ)を作成して負荷を分散 57
  58. 58. 日本プロゴルフ選手権大会(2010) 課題 •  ⼤大会期間、動的な機能が利利⽤用できない。 •  CMS(Master)によるコンテンツの更更新ができない。 58
  59. 59. 日本プロゴルフ選手権大会(2010) 課題 •  ⼤大会期間、動的な機能が利利⽤用できない。 •  CMS(Master)によるコンテンツの更更新ができない。 Clone  Server  パターン 59
  60. 60. 「Clone Server パターン」を適用 60
  61. 61. 「Clone Server パターン」を適用 イメージからクローン サーバを起動 61
  62. 62. 「Clone Server パターン」を適用 ロードバランサーで クローンサーバに負荷分散 62
  63. 63. 「Clone Server パターン」を適用 「rsync」で定期的にコンテンツの同期 63
  64. 64. 「Clone Server パターン」を適用 「Master」にデータベース接続 64
  65. 65. 「Clone Server パターン」を適用 管理者はマスターサーバ でコンテンツの更新 65
  66. 66. 「Clone Server パターン」を適用 66
  67. 67. 更なるパターン適用例(負荷対策/高速化) Direct  Hosting  パターン Cache  Distribution  パターン Rewrite  Proxy  パターン 67
  68. 68. Direct Hosting パターン •  ⽤用語 •  S3:  インターネットストレージ •  EC2:  仮想サーバ •  ポイント •  可⽤用性と耐久性が⾮非常に⾼高いS3 にコンテンツを配置してEC2か ら負荷を分散 •  S3には「Web  Site  Hosting」 機能があり、⼀一般的なWebサー バとして運⽤用も可能 68
  69. 69. 「Direct Hosting パターン」を適用 69
  70. 70. 「Direct Hosting パターン」を適用 APIで定期的に静的コンテンツを同期 70
  71. 71. 「Direct Hosting パターン」を適用 静的コンテンツのトラフィックを S3に負荷分散 71
  72. 72. 「Direct Hosting パターン」を適用 72
  73. 73. Cache Distribution パターン •  ⽤用語 •  CloudFront:  CDN •  S3:  インターネットストレージ •  EC2:仮想サーバ •  ポイント •  エッジサーバは世界中に存在し ⾼高速にアクセス可能 •  静的コンテンツの配信に最適化 されている •  HTTPS(独⾃自ドメインも)のアク セスでも利利⽤用可能 73
  74. 74. 「Cache Distribution パターン」を適用 74
  75. 75. 「Cache Distribution パターン」を適用 S3をオリジンサー バとして設定 75
  76. 76. 「Cache Distribution パターン」を適用 静的コンテンツのトラフィックを CloudFrontに負荷分散 76
  77. 77. 「Cache Distribution パターン」を適用 77
  78. 78. Rewrite Proxy パターン •  ⽤用語 •  CloudFront:  CDN •  S3:  インターネットストレージ •  EC2:仮想サーバ •  ポイント •  ProxyサーバがHTML内の画像 などのURLをCroudFrontのも のに⾃自動で書き換える •  現在はCloudFrontのマルチオリ ジン機能で実現することも可能 78
  79. 79. 「Rewrite Proxy パターン」を適用 79
  80. 80. 「Rewrite Proxy パターン」を適用 CloudFrontのマルチオリジン機能で静的 コンテンツはCloudFront、動的コンテンツ はELBに振り分ける 80
  81. 81. 「Rewrite Proxy パターン」を適用 81
  82. 82. 日本プロゴルフ選手権大会(2011) 82
  83. 83. 日本プロゴルフ選手権大会(2011) 83
  84. 84. 日本プロゴルフ選手権大会(2011) 課題 •  年年⼀一回の⽇日本プロ開催期間中の負荷対策をコストをかけず 効率率率よく⾏行行いたい。 84
  85. 85. 日本プロゴルフ選手権大会(2011) 今までの対応 •  毎年年、⼤大会に近づくと⼿手動で拡張⽤用のシステムを0から構 築してきた。 85
  86. 86. 日本プロゴルフ選手権大会(2011) 課題 •  年年⼀一回なので作業に慣れることができず毎回時間がかかる •  毎回0から構築しているので作業者が変わると引き継ぎに 時間がかかる
  87. 87. 日本プロゴルフ選手権大会(2011) 課題 •  年年⼀一回なので作業に慣れることができず毎回時間がかかる •  毎回0から構築しているので作業者が変わると引き継ぎに 時間がかかる Stamp  パターン 87
  88. 88. Stamp パターン •  ⽤用語 •  AMI:マシンイメージ •  EC2:仮想サーバ •  ポイント •  環境構築済みのAMIを使えば、 それを基に⽴立立ち上げたEC2への 設定作業は不不要 •  全く同じOS、データ、設定の EC2インスタンスを、数百台で も⽴立立ち上げることが可能になる。 88
  89. 89. 「Stamp パターン」を適用 2010年 大会時 89
  90. 90. 「Stamp パターン」を適用 2010年 通常時 90
  91. 91. 「Stamp パターン」を適用 2011年 大会時 91
  92. 92. 「Stamp パターン」を適用 2011年 通常時 92
  93. 93. 「Stamp パターン」を適用 2012年 大会時 93
  94. 94. 「Stamp パターン」を適用 2012年 通常時 94
  95. 95. 「Stamp パターン」を適用 2013年 大会時 95
  96. 96. 「Stamp パターン」を適用 2013年 通常時 96
  97. 97. 更なるパターン適用例(イベント時の拡張) Stack  Deployment  パターン Weighted  Transition  パターン
  98. 98. Stack Deployment パターン •  ⽤用語 •  Cloud  Formation:  AWSリソー スを⼀一気に起動 •  テンプレート:  ⼀一気に起動する AWSリソースを記述   •  スタック:  テンプレートから作 成されたAWSリソース群 •  ポイント •  ⼀一気に削除することも可能 •  Auto  Scalingを利利⽤用してEC2の 起動数のパラメータ化が可能 98
  99. 99. 「Stack Deployment パターン」を適用 99
  100. 100. 「Stack Deployment パターン」を適用 テンプレートからスタックを作成 (Auto Scalingで数量設定) 100
  101. 101. 「Stack Deployment パターン」を適用 101
  102. 102. Weighted Transition パターン •  ⽤用語 •  Route  53:  DNS •  ELB:  ロードバランサー •  EC2:  仮想サーバ •  ポイント •  DNSラウンドロビンを重み付け して実現することが可能 •  Route  53はSLA  100% •  Route  53のエッジサーバは世 界中に存在 102
  103. 103. 「Weighted Transition パターン」を適用 103
  104. 104. 「Weighted Transition パターン」を適用 重み付けDNSラウンドロビンで 徐々にトラフィックを移動 1-α% α% 104
  105. 105. 「Weighted Transition パターン」を適用 105
  106. 106. 目次 •  ⾃自⼰己紹介 •  クラウドアーキテクティング原則 •  Cloud  Design  Pattern  (CDP) •  CDPの適⽤用例例(事例例) •  まとめ 106
  107. 107. まとめ •  AWSには多種多様なコンポーネント/サービスが存在 107
  108. 108. まとめ •  AWSには多種多様なコンポーネント/サービスが存在 •  CDPを知っていればベストプラクティスが適⽤用できる 108
  109. 109. まとめ •  AWSには多種多様なコンポーネント/サービスが存在 •  •  CDPを知っていればベストプラクティスが適⽤用できる クラウド(AWS)でコンピューターリソースの調達速 度度が劇的に短縮 109
  110. 110. まとめ •  AWSには多種多様なコンポーネント/サービスが存在 •  •  CDPを知っていればベストプラクティスが適⽤用できる クラウド(AWS)でコンピューターリソースの調達速 度度が劇的に短縮 •  システムの構築速度度の短縮も期待されがち 110
  111. 111. まとめ •  AWSには多種多様なコンポーネント/サービスが存在 •  •  CDPを知っていればベストプラクティスが適⽤用できる クラウド(AWS)でコンピューターリソースの調達速 度度が劇的に短縮 •  システムの構築速度度の短縮も期待されがち •  CDPを知っていればシステム設計の時間も短縮でできる 111
  112. 112. まとめ 実際に… •  営業フェーズでCDPレベルの設計 •  CDPを共通知識識としてシステムの引き継ぎや 社内展開 112
  113. 113. まとめ 実際に… •  営業フェーズでCDPレベルの設計 •  CDPを共通知識識としてシステムの引き継ぎや 社内展開 クラウドのスピードに合わせて⼈人の動きもス ピードもアップ! 113
  114. 114. まとめ AWS以外でもCDPを! 114
  115. 115. ご清聴、ありがとうございました!

×