Awsのインフラをデザインパターン駆使して設計構築

1. 社内勉強会vol.3 AWSのインフラをデザインパターン駆使して設計・構築できる！？ Takayuki Niinuma@Kagoshima

2. お願い • 参加者は基本的にはミュートにしてください • 画面共有のボタンは押さないでください • 質問があればmentionを入れて通知ください

3. agenda • 自己紹介 • AWSのCloud Design Pattern紹介 • アプリケーション機能要件に対しての構築パターン • CloudFormationを使ったAWSの各サービスを自動構築 • 参考資料 • まとめ • 質疑応答

5. Title: technologist Facebook: takayuki.niinuma Twitter: @twinuma GitHub: https://github.com/Twinuma Blog: http://takachan.hatenablog.jp

6. “AWS”タグが付いた投稿は、現在19個

7. 私のクローズドだったtipsダダ漏れ

9. ＼ここで、皆さんに質問／  AWSのサービスはどれだけ知っていますか？

10. Amazon EC2 Route 53 Amazon S3 Amazon RDS

11. ＼ここで、皆さんに質問／  AWSのサービスはどれだけ知っていますか？自己紹介 AWSのCloud Design Pattern紹介アプリケーション機能要件に対しての構築パターン

12. ＼ここで、皆さんに質問／  AWSのサービスはどれだけ知っていますか？自己紹介 AWSのCloud Design Pattern紹介アプリケーション機能要件に対しての構築パターン

13. クラウドアーキテクティング原則クラウドの特性を考えると、これまでのシステムアーキテクティングと異なった視点が必要となる。それをクラウドアーキテクティング原則として整理している。引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

14. クラウドアーキテクティング原則クラウドの特性を考えると、これまでのシステムアーキテクティングと異なった視点が必要となる。それをクラウドアーキテクティング原則として整理している。 • できるだけサービスを利用 • 机上実験よりも実証実験 • スモールスタートからスケールアウト • 変化に対して全レイヤで対処 • 故障のための設計(Design For Failure) • 最初だけではなく周期的なカイゼン引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

15. クラウドアーキテクティング原則クラウドの特性を考えると、これまでのシステムアーキテクティングと異なった視点が必要となる。それをクラウドアーキテクティング原則として整理している。 • できるだけサービスを利用 • 机上実験よりも実証実験 • スモールスタートからスケールアウト • 変化に対して全レイヤで対処 • 故障のための設計(Design For Failure) • 最初だけではなく周期的なカイゼン引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

16. できるだけサービスを利用すでにクラウド上に存在しているサービスのメリット/デメリットを正確に理解し、使いこなすことが重要である。利用者としては、車輪の再開発は極力避けるべきである。 SDKs Java Python PHP .NET Ruby nodeJS iOS Android AWS Toolkit for Visual Studio AWS Toolkit for Eclipse Tools for Windows PowerShell CLI 引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

17. 例：S3でWebサイトのホスティング引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

18. 例：S3でWebサイトのホスティング • 99.999999999%の堅牢性と、99.99%の可用性を提供 • 3ヶ所以上の異なるロケーションにデータ保管 • データ転送量、ファイルサイズで課金(基本的にEC2より安価) 引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

19. 例：RDSでマネージドリレーショナルデータベース引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

20. 例：RDSでマネージドリレーショナルデータベース • 自動バックアップ、Restore To Point In Time • レプリケーション（Multi-AZ、Read Replica） • パッチ管理（自動マイナーバージョンアップ）引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

21. 机上実験よりも実証実験クラウドの良さは瞬時に安く調達できることなので、机上の実験に時間をかけず、その場ですぐに試すべきである。そうすることで短時間で精度の高い結果が分かり、よりカイゼンできる。数日引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

22. 机上実験よりも実証実験クラウドの良さは瞬時に安く調達できることなので、机上の実験に時間をかけず、その場ですぐに試すべきである。そうすることで短時間で精度の高い結果が分かり、よりカイゼンできる。数日数秒引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

23. 例：EC2でキャパシティプランニングの短縮 • 負荷テストでリソース不足がわかった場合、その後のチューニングが大変 • 事前のキャパシティプランニングに時間をかけてしまうオンプレミス引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

24. 例：EC2でキャパシティプランニングの短縮 • 負荷テストでリソース不足がわかった場合、その後のチューニングが大変 • 事前のキャパシティプランニングに時間をかけてしまうオンプレミス • 負荷テストでリソース不足が分かったらすぐに調整（スケールアップ/アウト） • 調整時に仮想サーバを増やし過ぎたら減らせばいい（課金も止まる）クラウド（AWS）引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

25. ただし・・・（注意点）できるだけサービスを利用 • 何でもかんでもサービスを使えばいいというわけではない • ちゃんとできないことも把握して適材適所で利用する引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

26. ただし・・・（注意点）できるだけサービスを利用 • 何でもかんでもサービスを使えばいいというわけではない • ちゃんとできないことも把握して適材適所で利用する Amazon S3 • 独自ドメインがHTTPS通信が利用できない • BASIC認証が利用できない引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

27. ただし・・・（注意点）できるだけサービスを利用 • 何でもかんでもサービスを使えばいいというわけではない • ちゃんとできないことも把握して適材適所で利用する Amazon S3 • 独自ドメインがHTTPS通信が利用できない • BASIC認証が利用できない Amazon RDS • OSにログインできない • 権限の制約などによる利用できない機能があるローカルディスクへのデータの書き出しなど引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

28. ただし・・・（注意点）机上実験よりも実証実験 • 必要な仮想サーバの性能と数量を決めるためのキャパシティプランニングは、事前に時間を掛ける必要はないが・・・ • 負荷に対するアーキテクチャを間違えると負荷テストの結果、必要な仮想サーバの性能と数量が膨大（=高額）になる可能性も・・・ • 終盤のアーキテクチャの変更は危険がいっぱい・・・（スケールアップも限界はある・・・）引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

29. ただし・・・（注意点）机上実験よりも実証実験 • 必要な仮想サーバの性能と数量を決めるためのキャパシティプランニングは、事前に時間を掛ける必要はないが・・・ • 負荷に対するアーキテクチャを間違えると負荷テストの結果、必要な仮想サーバの性能と数量が膨大（=高額）になる可能性も・・・ • 終盤のアーキテクチャの変更は危険がいっぱい・・・（スケールアップも限界はある・・・）アーキテクチャの設計は机上の実験も含め、事前に時間をかけたい引用 - 実践！AWSクラウドデザインパターン(http://www.slideshare.net/suzlab/cdp-28868858) -

30. AWSクラウドデザインパターン AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、わかりやすく分類して、ノウハウとして利用できるように整理したものである。

31. AWSクラウドデザインパターン http://aws.clouddesignpattern.org/

33. AWSクラウドデザインパターン現在48パターン＋カテゴライズ待ち15パターン

34. 例：Cloud DI Pattern • 解決したい課題 • クラウドでの解決/パターンの説明 • 実装 • 構造 • 利点 • 注意点 • その他 • 関連ブログ

35. 例：Cloud DI Pattern <解決したい課題> 規模の大きなシステムでは、アクセス数などの増大とともに多数のサーバーを増設することになる。その場合、サーバー構築に必要なインストールや設定を一つひとつ手作業で行うのは非常に手間となり、期限内で終わらせることも難しくなる。サーバー構築の自動化を行う方法としてシステム管理ツールを利用する方法もあるが、そこにはコストの問題もある。

36. 例：Cloud DI Pattern <クラウドでの解決/パターンの説明> 仮想サーバーを起動した際、そのサーバーの目的に合わせてサーバーの内部構成を自動的に構築したいケースがある。特にScale OutパターンやScheduled Autoscalingパターンを使って運用を自動化したい場合に求められる。こうしたケースではBootstrapパターンが有効だが、外出ししておきたい情報（例えばDB接続先IPアドレス、サーバー名、認識番号など）が多くある場合、このCloud DIパターンを利用することでより柔軟にサーバー初期化を行うことができる。

37. 例：Cloud DI Pattern <実装> EC2を起動する際、EC2インスタンスに対して、任意のタグをつける機能がある。この機能を利用して、EC2起動時にタグ情報を読み込み、それに応じた設定を行う。 • EC2の固有情報をタグとしてセットする。（例えばEIPをタグとして設定する） • EC2の起動時に、タグを取得するアプリケーションが起動するよう設定する。 • アプリケーション内で、タグ情報に従ってEC2の初期化を行う（設定したEIPが自動的に EC2に割り当てられる）。

38. 例：Cloud DI Pattern <構造>

39. 例：Cloud DI Pattern <利点> • Stampパターン・Bootstrapパターンを使った汎用的なベースイメージに対して固有の設定を行える。 • タグ情報でパラメータ設定を行うため、マネジメントコンソールで容易に設定したり確認したりできる。 • 自動的に設定を行えるため、運用時のミスを低減できる。 • EC２インスタンスの構築だけでなく、AMIやスナップショットの自動取得を行う仕組みを作る場合にも利用できる。

40. 例：Cloud DI Pattern <注意点> • タグは、付与できる文字数が決まっている場合がある。その場合は、S3のURLやネットワークのファイルパスなど、渡したい情報へのポインタ情報をタグにセットする。

41. 例：Cloud DI Pattern <その他> • 情報を引き渡すために、タグだけでなくユーザーデータと呼ばれるメタデータを利用する事もできる。

44. AWS リファレンスアーキテクチャ http://aws.amazon.com/jp/architecture/ AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、わかりやすく分類して、ノウハウとして利用できるように整理したものである。

45. AWS リファレンスアーキテクチャ

46. AWS リファレンスアーキテクチャ

47. 私が構築設計するときの代表的な4パターン ①Web Storage Pattern • S3を使えば、ネットワーク負荷やデータ容量を気にする必要がなくなる • S3は3カ所以上のデータセンターでバックアップを行っているため、非常に耐久性が高い • 各コンテンツ毎のURLが発行されるため、ファイルをS3に置くだけでファイル共有など広範囲な目的で活用することができる

48. ②Multi-Datacenter Pattern • データセンターレベルの大きな障害が発生しても、サービス継続可能なシステムを構築できる • 東日本大震災以降注目されているディザスターリカバリー（DR）構成を安価に迅速に構築できる • AWSはAZごとに初期費用や月額利用料がかかるわけではないので、単一のAZ を使用しても複数のAZを使用しても費用は変わらない私が構築設計するときの代表的な4パターン

49. ③Scale Out Pattern • トラフィック量の増大に合わせて自動的に EC2インスタンスを増やすことができるので、サービス継続につながる • トラフィック量が多くないときにはEC2インスタンスを削減できる(スケールインと呼ぶ)のでコスト削減につながる • トラフィック量の増減に合わせて自動的に EC2インスタンスを増減させられるので、運用の手間が省ける • ELBの配下に必要な数のEC2インスタンスを並べることができるので、スケールアップと比べると処理能力の限界は極めて高い私が構築設計するときの代表的な4パターン

50. ④Cache Distribution Pattern • 地理的に離れたユーザーに対して、より良いユーザエクスペリエンスを提供できる • ファイルダウンロード処理を分散できるため、負荷分散効果もある • 既存のサーバー（オンプレやホスティングなどのEC2以外のサーバー）をオリジンサーバーにすることで、既存のサーバーを生かしながらパターンを適用することが可能 • オリジンサーバーとしては、S3を直接オリジンに用いることもできる私が構築設計するときの代表的な4パターン

51. AWS リファレンスアーキテクチャをベースにして、そこから要件・予算に応じて構成を加えたり減らしたりすればそれらしい構成にはなる！ビジプロ向け情報"(( ⁰⊖⁰)/)" 【構成を加えるパターン】

52. AWS リファレンスアーキテクチャをベースにして、そこから要件・予算に応じて構成を加えたり減らしたりすればそれらしい構成にはなる！ビジプロ向け情報"(( ⁰⊖⁰)/)" 【構成を加えるパターン】

53. AWS リファレンスアーキテクチャをベースにして、そこから要件・予算に応じて構成を加えたり減らしたりすればそれらしい構成にはなる！ビジプロ向け情報"(( ⁰⊖⁰)/)" 【構成を減らすパターン】

54. AWS リファレンスアーキテクチャをベースにして、そこから要件・予算に応じて構成を加えたり減らしたりすればそれらしい構成にはなる！ビジプロ向け情報"(( ⁰⊖⁰)/)" 【構成を減らすパターン】

55. AWS定番構成を構築＆デプロイを自動化するサービスあるよ。

56. AWS Elastic Beanstalk

57. 引用 - プログラマに贈るクラウドとの上手な付き合い方(http:// www.slideshare.net/keisuke69/how-to-usecloudforprogrammer) -

60. 2-Tier Architecture

68. CloudFormation Demo • 単一 EC2 インスタンスとローカル MySQL データベース • AutoScalingMultiAZSample.template http://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/aws- cloudformation-templates-ap-northeast-1/

69. CloudFormation Demo http://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/aws- cloudformation-templates-ap-northeast-1/ • 単一 EC2 インスタンスとローカル MySQL データベース • AutoScalingMultiAZSample.template

70. 例：単一 EC2 インスタンスとローカル MySQL データベース

79. CloudFormation Demo http://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/aws- cloudformation-templates-ap-northeast-1/ • 単一 EC2 インスタンスとローカル MySQL データベース • AutoScalingMultiAZSample.template

80. 例：AutoScalingMultiAZSample.template

95. ２．WebサービスStartUP向け AWSスケーラブルな構成例 http://www.slideshare.net/AmazonWebServicesJapan/aws-for- ３．スタートアップでのAWS(Amazon Web Services)活用事例 http://www.slideshare.net/schoowebcampus/awsamazon-web- ４．Lv1から始めるWebサービスのインフラ構築 http://www.slideshare.net/itoyusaku/lv1web ５．プログラマに贈るクラウドとの上手な付き合い方 http://www.slideshare.net/keisuke69/how-to-usecloudforprogrammer １．スタートアップならおさえておきたいAWS入門サービス概要と基礎知識編 http://www.slideshare.net/HiroshiTakayama/aws-45311829 参考資料私がオススメするスライド5選

97. まとめ • AWSサービスは、目的に応じて組み合わせすることにより課題を解決することができる。 • インフラサービスに柔軟に対応できるようプログラムのアーキテクチャを考慮 • 2-Tier Architectureを実現するには、モバイルプログラマーもAWS SDKを使えるようになること • テンプレートを使ってインフラを構築し、使い回し可能（ML標準のテンプレート作成もあり。）

99. ありがとうございました！！

Awsのインフラをデザインパターン駆使して設計構築

Monstar Lab Inc.

Transcript

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Awsのインフラをデザインパターン駆使して設計構築

Monstar Lab Inc.

Transcript