Who am I? 名前 : 江川大地所属アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト経歴データベースエンジニア AWS テクニカルトレーナー好きなサービス AWS サポート 2 好きなデータベース PostgreSQL

Size: px

Start display at page:

Download "Who am I? 名前 : 江川大地所属アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト経歴データベースエンジニア AWS テクニカルトレーナー好きなサービス AWS サポート 2 好きなデータベース PostgreSQL"

こうしろうかくはり
6 years ago
Views:

1 AWS Black Belt Online Seminar クラウドのためのアーキテクチャ設計 - ベストプラクティス - Architecting for the Cloud アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト江川大地

2 Who am I? 名前 : 江川大地所属アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト経歴データベースエンジニア AWS テクニカルトレーナー好きなサービス AWS サポート 2 好きなデータベース PostgreSQL

3 内容についての注意点本資料料では 2016 年年 9 月 29 日時点のサービス内容および価格についてご説明しています最新の情報は AWS 公式ウェブサイト ( にてご確認ください資料料作成には十分注意しておりますが資料料内の価格と AWS 公式ウェブサイト記載の価格に相違があった場合 AWS 公式ウェブサイトの価格を優先とさせていただきます価格は税抜表記となっています日本居住者のお客様が東京リージョンを使用する場合別途消費税をご請求させていただきます AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided. 3

4 Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティスまとめ

5 Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティスまとめ

6 AWS 上でシステム設計にあたっての疑問例例えば AWS の特性を活かせるような設計とは? オンプレミスと違う発想で臨臨んだほうがいいの? EC2 上でデータベースを構築するのと RDS を使うことの違いは? スケールアウト構成を構築する場合に何を意識識すればよいの? 6

7 本日お話しすることクラウドらしいアーキテクチャを構築するための原則 AWS でシステムを構築するためのベストプラクティスより深く確認したい方は下記のホワイトペーパーを参照 Ø Architecting for The Cloud: AWS Best Practices Cloud_ Best_ Practices.pdf 7

8 Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティスまとめ 8

9 AWS / クラウドコンピューティングとは俊敏性アジリティの向上低額な利利用価格伸縮自在性初期投資不不要従量量課金金セルフサービスなインフラ Deploy 豊富なサービスワールドワイド 9

10 クラウドコンピューティングならではの特性 IT 資産がプログラマブルにグローバル展開可用性無制限のキャパシティ高レベルなマネージドサービス Built- in Security 10

11 Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティスまとめ

12 10 の設計プリンシプルスケーラビリティ固定資産から可処分資産へ自動化疎結合サーバではなくサービスの利利用 ( マネージドサービスの活用 ) データベースの使い分け単一障害点の排除コストの最適化キャッシュの利利用セキュリティ 12

13 スケーラビリティ Scalability

14 スケーラビリティ運用中のシステムを拡張 / 縮小させる能力力スケーラビリティを生かすことで可能になること Ø 柔軟性の向上 ( 事業の必要性に応じたリソース確保 ) Ø コスト削減 ( 必要な時に必要な分だけのリソース確保 ) スケールの種類 Ø 水平スケーリング ( スケールアウト / スケールイン ) Ø 垂直スケーリング ( スケールアップ / スケールダウン ) 14 Scalability

15 水平垂直のスケーリングの比較垂直スケーリング ( スケールアップ / スケールダウン ) Ø 個々のリソースのスペックを増減 Ø リソースの限界が存在 Ø インスタンスの停止が伴う水平スケーリング ( スケールアウト / スケールイン ) Ø リソースの台数を増減 Ø 論論理理的には限界が存在しない Ø インスタンスの停止が伴わない small small small small large small small small small small small small 15 Scalability

16 16 水平スケーリングを行行うために心がけることステートレスアプリケーション / コンポーネント Ø ステートフルになる要素を水平スケールするリソースの外部に配置セッション情報は DynamoDB/ElastiCache へバイナリファイル, ログなどは Amazon S3 へステートフルになるコンポーネントをどう扱うか Ø 水平スケールするマネージドサービスの利利用 Ø 水平スケールができない場合に注意すべき制約を洗い出す分散処理理 ( 今までのやり方を見見直す ) Ø 長時間かかっていた単一のタスクを分割できないか検討 1 台のサーバで 4 時間かかるタスクを 4 台のサーバで 1 時間でこなす商用ライセンスの扱い Ø ライセンスの提供元に確認 Scalability

ステートレスにするためのセッション情報の扱いセッション情報を水平スケールさせたいコンポーネントで持つと Ø スケールアウト時スケールアウトしたリソースが使われにくい Ø スケールイン時セッションも一緒に落落とすことになるので困難 Sticky Session セッション Web/ App 既存ユーザのセッションは既存のコンポーネントにあるためリクエストは

17 ステートレスにするためのセッション情報の扱いセッション情報を水平スケールさせたいコンポーネントで持つと Ø スケールアウト時スケールアウトしたリソースが使われにくい Ø スケールイン時セッションも一緒に落落とすことになるので困難 Sticky Session セッション Web/ App 既存ユーザのセッションは既存のコンポーネントにあるためリクエストは同じリソースへ Sticky Session セッション Web/ App インスタンスを削除すると既存ユーザのセッション情報も失われてしまう ( ログアウトされた挙動となる ) Client ELB Web/ App Client ELB Web/ App 17 Web/ App Auto Scaling スケールアウトしたリソースを活かしにくい Auto Scaling Scalability

18 ステートレスにするためのセッション情報の扱いスケールさせやすくするためにセッション情報は外だし ElastiCache Web/ App or Client- Side で書き換えられると困る情報は Server- Side で保持 Client ELB Web/ App 18 書き換えられても問題ない情報肥大化の恐れがない情報は Client- Side で保持することも可能 Auto Scaling 各リソースに固有の情報がないのでいつでも増減しやすい DynamoDB セッション情報 Scalability

19 固定資産から可処分資産へ Disposable Resources Instead of Fixed Servers

20 リソースに対する考え方今まで ( オンプレミス ) 固定のリソースで運用 Ø リソース購入は前払い Ø リソース追加には長いリードタイム事前のサイジングが必須 AWS 固定資産ではない Ø 使い捨て可能なソフトウェア ( いつでも増減変更更可能 ) 事前のサイジングは不不要サイジングにより決まった台数スペック追加には長時間かかるタスクが増えたらインスタンスを増やして対応 20 タスクが完了了したらシャットダウン Disposable Resources Instead of Fixed Servers

21 マインドセットを変える今まで ( オンプレミス ) 固定リソース運用により助長されがちなプラクティス Ø 手作業による設定変更更 Ø IP アドレスのハードコード Ø シーケンシャルな処理理 Ø 常に電源 ON AWS リソースが常に存在する / 変更更しない前提の設計運用を止める Ø 自動化 Ø DNS によるアクセス Ø バッチスケジュールの見見直し Ø 利利用時間帯の確認 21 Disposable Resources Instead of Fixed Servers

22 自動化水平スケールも自動的に水平スケールしたインスタンスに対する設定も自動的に Ø EC2 ユーザーデータメタデータ jp/awsec2/latest/userguide/ec2- instance- metadata.html Ø 構成管理理ツール (Chef, Puppet などの 3rd party ツール ) 次のプリンシプルも参照 22 Disposable Resources Instead of Fixed Servers

DNS によるアクセス固定 IP アドレスアクセスによる弊害の例例スケールイン時使用率率率が低くなったのでスケールイン 10.0.0.52 直打ちでのアクセス 10.

23 DNS によるアクセス固定 IP アドレスアクセスによる弊害の例例スケールイン時使用率率率が低くなったのでスケールイン直打ちでのアクセス Disposable Resources Instead of Fixed Servers

24 バッチスケジュールの見見直し並列列化で早く終わらせる Ø 1 台で n 時間も n 台で 1 時間も料料金金は同じタスク 3 タスク 2 タスク 1 タスク 2 タスク 3 タスク 1 1h 2h 3h 時間 1h 2h 3h 時間 24 Disposable Resources Instead of Fixed Servers

25 利利用時間帯の確認固定資産ではないので常に稼働させる必要はない実際のワークロード利利用時間帯に合わせて稼働させる必要がない時間は落落としてコスト節約につなげる 25 Disposable Resources Instead of Fixed Servers

26 可処分所得にするためのポイント AMI, スナップショット戦略略 ( いつでもリソースを作成できるように準備 ) Ø 全部入り AMI Ø Bootstrapping Ø Hybrid(AMI と Bootstrapping の組み合わせ ) Infrastructure as Code Ø 個々のリソースだけでなくシステム全体をいつでも作成できるよう準備 ( 例例 ) バッチシステムを CloudFormation で作成し完了了したら削除 26 Disposable Resources Instead of Fixed Servers

c h e c a t J Ee E x c h e c a t J Ee E c h e c a t J Ee E JEE x JEE x AMI 戦略略 Apache Tomcat Struts

Tomcat Struts アプリコード Log4J Spring Hiberna te J2EE Linux Java AMI EC2 アプリコード Struts Log4J Spring Amazon

H ib e r n at L i n u x EC2 A pa T o m H ib e r n at L i n u x アプリコード Apache Struts Tomcat Log4J Hiberna

27 c h e c a t J Ee E x c h e c a t J Ee E c h e c a t J Ee E JEE x JEE x AMI 戦略略 Apache Tomcat Struts アプリコード Log4J Spring Hibernate J2EE Linux Javaスタック 27 [1] 全部入り AMI [2] 部分設定済 AMI [3] 最小構成 AMI Apache Tomcat Struts アプリコード Log4J Spring Hiberna te J2EE Linux Java AMI EC2 アプリコード Struts Log4J Spring Amazon S3 Apache Tomcat Hiberna te J2EE Linux Java AMI 起動時取得起動時取得 A pa T o m H ib e r n at L i n u A pa T o m H ib e r n at L i n u x EC2 A pa T o m H ib e r n at L i n u x アプリコード Apache Struts Tomcat Log4J Hiberna Spring te Amazon S3 Chef J2EE Linux AMI Disposable Resources Instead of Fixed Servers 起動時取得スクリプト Linu Chef EC2 Linu

28 AMI 戦略略 Pros/Cons 方式利利点欠点 [1] 全部入り AMI 同一性の確保起動時間が早い [2] 部分設定済 AMI あとはアプリコードのみ最新を取得すれば良良く扱いやすいデプロイ毎に AMI を作り直す必要がある ( 作成プロセスを自動化すれば欠点とはならない ) [3] 最小構成 AMI 柔軟に中身を変更更できる起動処理理に時間がかかる場合によっては外部ライブラリが取得できないことも 28 Disposable Resources Instead of Fixed Servers

AWS CloudFormation 設定管理理 & クラウドのオーケストレーションサービススタック

com/jp/cloudformation/) Ø テンプレートを元に EC2 や ELB といった AWS

自由に記述可能 Ø Microsoft Windows Server や SAP HANA

com/quickstart/) EC2 テンプレートに基づき各リソースが自動起動 EC2 Auto

com/jp/cloudformation/pricing/) Ø 追加料料金金はありません AWS

29 AWS CloudFormation 設定管理理 & クラウドのオーケストレーションサービススタックテンプレート ( 設定ファイル ) Cloud Formation 特徴 ( Ø テンプレートを元に EC2 や ELB といった AWS リソースの環境構築を自動化 Ø JSON, YAML フォーマットのテキストでテンプレートを自由に記述可能 Ø Microsoft Windows Server や SAP HANA などのリファレンス実装を用意 ( aws.amazon.com/quickstart/) EC2 テンプレートに基づき各リソースが自動起動 EC2 Auto Scaling 価格体系 ( Ø 追加料料金金はありません AWS リソース (Amazon EC2 インスタンスや Elastic Load Balancing ロードバランサーなど ) に対してお支払いいただきます 29 Disposable Resources Instead of Fixed Servers

30 自動化 Automation

31 自動化自動化を意識識することで得られるメリット Ø オペミス防止などの安定した運用 Ø 運用負荷の軽減 Ø 可用性の向上 AWS と自動化 Ø API で動作するので自動化しやすい Ø 自動化をサポートするサービスが豊富 31 Automation

32 自動化をサポートする代表的なサービス / 機能 AWS Elastic Beanstalk AWS OpsWorks Auto Scaling Amazon EC2 Auto Recovery Amazon CloudWatch Alarms Amazon CloudWatch Events AWS Lambda Scheduled events 32 Automation

AWS ElasticBeanstalk インフラ構成の構築アプリデプロイの自動化サービス特徴 (http://aws.amazon.

33 AWS ElasticBeanstalk インフラ構成の構築アプリデプロイの自動化サービス特徴 ( Ø 速く簡単にアプリケーションをデプロイ可能 Ø インフラストラクチャの準備 & 運営からアプリケーションスタックの管理理まで自動化 Ø Auto Scaling によりコストを抑えながらスケーラビリティを確保 Ø Java, PHP, Ruby, Python, Node.js,.NET, Docker などに対応 33 価格体系 ( Ø 追加料料金金なし Ø アプリケーションの保存実行行に必要な AWS リソース (EC2, S3, RDS, DynamoDB など ) に対してのみ課金金 Automation

34 AWS OpsWorks アプリケーションのデプロイ管理理サービス AWS OpsWorks EC2 インスタンス上の OpsWorks エージェントスタック LB レイヤー Web レイヤー DB レイヤー特徴 ( Ø Chef のレシピを使ってデプロイや運用タスクを自動化可能 Ø ライフサイクルイベントにより動的な構成変更更への対応が可能 Ø 継続的な構成管理理価格体系 ( Ø AWS OpsWorks 自体の利利用は無料料 Ø (OpsWorks エージェントをオンプレミスサーバで利利用する場合はその起動時間 ) 34 Automation

Auto Scaling EC2 インスタンスを負荷またはスケジュールに応じて自動増減起動設定インスタンスタイプ AMI など Desired Capacity Auto Scaling group 必要に応じて追加される Capacity 特徴 (http://aws.amazon.

35 Auto Scaling EC2 インスタンスを負荷またはスケジュールに応じて自動増減起動設定インスタンスタイプ AMI など Desired Capacity Auto Scaling group 必要に応じて追加される Capacity 特徴 ( Ø Amazon EC2 インスタンス群を自動的にスケール Ø 耐障害性の向上 ( インスタンスの異異常を検知して新しいインスタンスを起動 ) Ø EC2 インスタンスの起動料料金金の最適化価格体系 ( Ø Auto Scaling 自体の利利用は無料料 Ø Auto Scaling によって起動される EC2 インスタンスの起動料料金金 35 Automation

Amazon CloudWatch AWS の各種リソースを監視するサービス特徴 (http://aws.amazon.

各メトリックスに対してアラーム作成価格体系 (http://aws.amazon.

36 Amazon CloudWatch AWS の各種リソースを監視するサービス特徴 ( Ø AWS リソースの死活性能ログ監視 Ø 取得メトリックスのグラフ化 Ø 各メトリックスに対してアラーム作成価格体系 ( Ø 基本モニタリング (5 分間隔 ) は無料料 Ø ( 利利用する場合 ) 詳細モニタリング Ø ( 利利用する場合 ) カスタムメトリックス API リクエストアラームログ等 36 Automation

com/jp/lambda/) Ø OS キャパシティ等インフラの管理理不不要 Ø S3 Kinesis SNS 等でのイベント発生を元にユーザが用意したコード (Node.

37 AWS Lambda イベントをトリガーにコードを実行行するコンピュートサービスイメージのリサイズやサムネイルの作成元画像 1 3 Amazon S3 Bucket イベントサムネイル画像 2 値チェックや別テーブルへのコピー Amazon DynamoDB Table and Stream 37 AWS Lambda AWS Lambda 別テーブルを更更新プッシュ通知特徴 ( Ø OS キャパシティ等インフラの管理理不不要 Ø S3 Kinesis SNS 等でのイベント発生を元にユーザが用意したコード (Node.js) を実行行 Ø ユーザアプリからの同期 / 非同期呼び出し価格体系 ( Ø コード実行行時間 (100ms 単位 ) Ø Lambda ファンクションへのリクエスト回数 Ø 1 月あたり 100 万リクエスト 400,000GB/ 秒が無料料で利利用可能 Automation

38 水平スケーリングの自動化システムの状況を監視し自動的にスケールアウト / インアラーム CloudWatch Alarms Auto Scaling Group アベイラビリティーゾーンアベイラビリティーゾーン 38 Automation

39 水平スケーリングの自動化システムの状況を監視し自動的にスケールアウト / インスケールアウトしたインスタンスはユーザーデータのカスタムスクリプトなどで自動設定アラーム CloudWatch Alarms Auto Scaling Group アベイラビリティーゾーンアベイラビリティーゾーン 39 Automation

40 インスタンスの復復旧も自動化 Auto Scaling による自動復復旧 (Auto Healing) Auto Scaling group min = 1 サーバークラッシュ代替リソースが自動的に起動 EC2 Auto Recovery による自動復復旧 40 Automation

41 運用も自動化 Amazon CloudWatch Events を利利用した運用自動化 Ø Amazon EBS の自動スナップショット Ø EC2 インスタンスの停止 / 削除 AWS Lambda のスケジュール実行行 Ø プログラムを書いてカスタムな運用項目を自動化 41 Automation

42 疎結合 Loose Coupling

43 疎結合 (Loose Coupling) 結合度度 (Coupling) は低いほど好ましい Ø 不不具合の影響範囲を最小限にとどめられる Ø スケーリングしやすい疎結合にするために心がけること Ø Well- Defined Interfaces Ø Service Discovery Ø Asynchronous Integration Ø Graceful Failure 43 Loose Coupling

44 Well- Defined Interfaces アクセス元から見見てアクセス先をブラックボックスに Ø 個々のリソースに固有の情報に依存しない必要な情報だけをわたし API でアクセス IP アドレスではなく DNS 名でアクセス処理理を実施するインスタンスへの直接アクセスを避け ELB, SQS へアクセスさせるよう設計 44 Loose Coupling

45 Service Discovery 45 透過的にアクセスするために増えたリソース減ったリソースを検知することが必要 Service Discovery の例例 Ø Auto Scaling を使ったインスタンスの ELB への自動登録 Ø EC2 ユーザーデータ Amazon Route 53 Ø Auto Scaling Life Cycle Hook Amazon Route 53 Ø 3 rd party solutions Netflix Eureka Airbnb Synapse HashiCorp Consul etc Loose Coupling

46 AWS のサービスを活用した疎結合の例例 Web Server App Server Web Server は単一の ELB の DNS 名だけを見見てれば良良い (App Server は Web Server にとってブラックボックス ) ELB Web Server ELB は Auto Scaling を組み合わせ増減する App Server を自動で登録 / 解除可能 App Server スケールアウト / インするたびに Web Server の設定ファイルの書き換えが必要 46 ウェブサーバーはアプリサーバーと密結合 ELB を挟んで疎結合に Loose Coupling

47 Asynchronous Integration 同期処理理である必要がなければ非同期でつながる非同期処理理の利利点 Ø ユーザ側の利利点アプリケーションがブロックされない Ø サーバ側の利利点スケーラブルかつ高可用なバックエンド Frontend を停止させることなく Backend を容易易にメンテナンス可能少ない Frontend のキャパシティで多くのリクエストを受付可能リクエストの処理理順序やリトライ等の制御が容易易に 47 Loose Coupling

48 AWS のサービスを活用した非同期処理理の例例 Amazon SQS Ø メッセージキューを挟んで Frontend と Backend を疎結合に Amazon Kinesis Ø ストリームデータの生成受け取りとそのデータ処理理部を疎結合に Amazon Simple Workflow Ø 複雑なワークフローにのっとる複数のタスクワークフローの状態管理理を疎結合に AWS Lambda Ø DynamoDB へのアップデート S3 へのデータアップロードと後続の処理理を疎結合に 48 Loose Coupling

49 AWS のサービスを活用した非同期処理理の例例 Amazon SQS を挟んで Frontend と Backend を疎結合に Sticky Session 重たい処理理は Backend Servers に任せる SQS キューから取得したメッセージを元にバッチ的に処理理を実行行していく Client ELB Amazon SQS Queue 重たい処理理は Backend で非同期に行行われるので Client へのレスポンスは迅速に Frontend Servers Backend Servers 49 Loose Coupling

50 Amazon Simple Queue Service (SQS) 高い可用性と信頼性を提供するフルマネージドなメッセージキューサービス Producer message message polling Consumer Producer, Consumer は EC2 やモバイルデバイスオンプレミスんサーバーなどで構成する実際のやりとりには Amazon SQS API を使って行う特徴 ( Ø 高い信頼性 : 複数のサーバー / データセンターにメッセージを保持 Ø スケーラブル : 多数の送信者 / 受信者に対応 Ø 高スループット : メッセージが増加しても高スループットを出し続ける価格体系 ( Ø 無料料利利用枠 : 毎月 100 万 Amazon SQS リクエストまで無料料 Ø その後 Amazon SQS リクエスト 100 万件につき USD( 東京リージョン以外は 0.5USD) Ø 複数のメッセージを 1 度度のリクエストで処理理することによりコスト効率率率をあげることも可能 50 Loose Coupling

51 Amazon Kinesis フルマネージド型リアルタイム大規模ストリーミング処理理大量量トランザクション処理理複数データ処理理の容易易なインテグレーション特徴 ( Ø 生成されるデータをリアルタイムに近い状況でデータ処理理部に伝送 Ø 預かったデータは 3AZ に 24 時間保存 Ø AWS のサービスとの簡単インテグレーション Ø 目的に応じた処理理を並列列処理理することが可能価格体系 ( Ø シャード数 Ø Put API コール数 51 Loose Coupling

52 Graceful Failure 安全に落落とすための戦略略 Ø リソースの停止削除障害時のクライアントや他のリソースへの影響を最小限にするように設定しておく Graceful Failure の例例 Ø ELB Connection Draining 52 新規割り振りは中止して処理理中のリクエストは終わるまで一定期間待つ Ø Route 53 による DNS Failover 障害発生時は CloudFront + S3 で構築した Sorry Site へ誘導 Ø 再試行行処理理の実装失敗した場合にはリトライで対応 Loose Coupling

53 サーバではなくサービスの利利用 Services, Not Servers

Ø AWS 上でのサーバーレスアーキテクチャ入門 http://www.slideshare.

54 サーバではなくサービスの利利用マネージドサービスの利利用によって得られるメリット Ø コア業務アプリケーション部分への集中 Ø 高可用性 Ø 運用負荷軽減 Ø 自動スケール ( サイジング不不要 ) マネージドサービスの活用により Serverless での構築も可能 Ø AWS 上でのサーバーレスアーキテクチャ入門 black- belt- online- seminar aws 54 Services, Not Servers

55 責任共有モデルから見見るマネージドサービスの管理理負荷責任共有モデルから見見るサービス区分 Ø Infrastructure Services: コンピュートとそれに関わるサービス OS, Apps などの設定を自由に行行うことが可能例例 )Amazon EC2, Amazon EBS など Ø Container Services: Amazon EC2 などのインフラストラクチャ上で提供されるマネージドサービスオプション ( 例例 :RDS Multi- AZ) などの設定により簡単に可用性を確保可能例例 )Amazon RDS, ELB など Ø Abstracted Services : プラットフォームが抽象化されたマネージドサービス ( サーバレスサービス ) 可用性は AWS によって自動的に確保例例 )Amazon S3, Amazon DynamoDB など 55 詳細 : Security_ Best_ Practices.pdf Services, Not Servers

56 セキュリティ責任共有モデル (Infrastructure Services) お客様による管理理 AWS が管理理クライアント側のデータ暗号化とデータの整合性認証基盤サービスコンピューティングストレージデータベースネットワーク AWS グローバルインフラストラクチャ顧客データサーバ側の暗号化 ( ファイルシステムおよびデータ ) プラットフォームアプリケーションオペレーティングシステムネットワーク構成アベイラビリティーゾーンリージョン NW トラフィックの保護 ( 暗号化 / 整合性 / アイデンティティ ) ファイアウォール構成エッジロケーションアイデンティティアクセス管理理 AWS IAM 凡例例 56 お客様が担当する範囲 AWS が担当する範囲 Services, Not Servers

57 セキュリティ責任共有モデル (Container Services) お客様による管理理クライアント側のデータ暗号化とデータの整合性認証顧客データサーバ側の暗号化 ( ファイルシステムおよびデータ ) プラットフォームアプリケーション NW トラフィックの保護 ( 暗号化 / 整合性 / アイデンティティ ) ファイアウォール構成アイデンティティアクセス管理理 AWS が管理理基盤サービスコンピューティングストレージデータベースネットワーク AWS グローバルインフラストラクチャオペレーティングシステムネットワーク構成アベイラビリティーゾーンリージョンエッジロケーション AWS IAM 凡例例お客様が担当する範囲 AWS が担当する範囲 57 Services, Not Servers

58 セキュリティ責任共有モデル (Abstracted Services) お客様による管理理クライアント側のデータ暗号化とデータの整合性認証顧客データサーバ側の暗号化 ( ファイルシステムおよびデータ ) NW トラフィックの保護 ( 暗号化 / 整合性 / アイデンティティ ) アイデンティティアクセス管理理プラットフォームアプリケーションファイアウォール構成 AWS が管理理基盤サービスコンピューティングストレージデータベースネットワーク AWS グローバルインフラストラクチャオペレーティングシステムネットワーク構成アベイラビリティーゾーンリージョンエッジロケーション AWS IAM 凡例例お客様が担当する範囲 AWS が担当する範囲オプション機能として提供されるもの 58 Services, Not Servers

59 AWS では多くのサーバーレスオプションを用意ストレージネットワークデータベースコンピューティングセキュリティメッセージングとキューコンテンツ配信ユーザー管理理モニタリングとログ記録機械学習ゲートウェイストリーミング分析 IoT 59 Services, Not Servers

60 データベースの使い分け Database

61 データベースの使い分け万能なデータベースストレージは存在しないデータストアの特性 ( 得意不不得意 ) に応じた使い分け低レイテンシインメモリ NoSQL 3 拠点間でのレプリケーション SSD に永続化 Amazon ElastiCache Amazon DynamoDB トランザクション処理理汎用用途 SQL 集計分析処理理大容量量データ DWH Amazon RDS Amazon Redshift 61 Database

62 単一障害点の排除 Removing Single Points of Failure

63 単一障害点の排除障害に備えておくことでその影響を極小化 Ø 下記のようにあらかじめ冗長化をしておくなどの準備が重要もしこの 1 台が落落ちてもシステムの全停止にはつながらない Auto Scaling Group アベイラビリティーゾーンアベイラビリティーゾーン 63 Removing Single Points of Failure

64 単一障害点の排除単一障害点排除のためのポイント Ø 冗長化 Ø 障害検知 Ø 堅牢牢なデータストレージ Ø Multi- AZ の利利用 Ø 疎結合な構成による障害分離離詳細 : building- fault- tolerant- applications.pdf 64 Removing Single Points of Failure

65 コストの最適化 Optimize for Cost

66 コストの最適化単に既存システムをクラウドに移行行するだけでも初期投資を減少させ AWS の規模の経済の恩恵を享受可能クラウド環境の特性を活かすことによりさらなるコスト最適化が可能 Ø 適切切なサイジング Ø 伸縮自在性 Ø 適切切な購入オプションの利利用 66 Optimize for Cost

67 適切切なサイジングオーバープロビジョニングの回避 Ø AWS のリソースはいつでも増減可能継続的な改善 Ø 適切切なインスタンスタイプを見見極めるために常に監視 Amazon CloudWatch によるリソース監視 AWS Trusted Advisor で使用率率率に低いリソース 67 Amazon CloudWatch AWS Trusted Advisor Optimize for Cost

68 伸縮自在性水平スケーリングにより必要な時に必要なリソースを確保需要によって判断マネージドサービスのキャパシティを利利用 Ø ELB, CloudFront, Amazon SQS, AWS Lambda etc Ø キャパシティを簡単に設定できるリソースの活用 Amazon DynamoDB, Amazon Kinesis Stream 68 Optimize for Cost

69 適切切な購入オプションの利利用 Amazon EC2 の購入オプション Ø リザーブドインスタンス Ø スポットインスタンス Amazon S3 のストレージ価格 Ø スタンダードストレージ Ø 標準低頻度度アクセスストレージ Ø 低冗長化ストレージその他のサービスの購入オプション Ø CloudFront のリザーブドキャパシティ Ø DynamoDB のリザーブドキャパシティ 69 Optimize for Cost

70 70 適切切な購入オプションの利利用 Amazon EC2 の購入オプション Ø リザーブドインスタンス Ø スポットインスタンス Amazon S3 のストレージ価格 10 月のオンラインセミナーもチェック! Ø スタンダードストレージ AWS のコスト削減オプション Ø 標準低頻度度アクセスストレージ cost- reduction/event/event_ info.html Ø 低冗長化ストレージその他のサービスの購入オプション Ø CloudFront のリザーブドキャパシティ Ø DynamoDB のリザーブドキャパシティ Optimize for Cost

71 キャッシュの利利用 Caching

72 キャッシュの利利用繰り返し利利用されるデータをキャッシュ Ø 性能向上 Ø コスト節約リクエスト配信 Amazon CloudFront コンテンツ取得オリジンサーバ台数の削減リクエストクライアントキャッシュから配信レスポンス向上 CDN キャッシュ負荷軽減オリジンサーバ 72 Caching

Amazon ElastiCache による Application Data Caching フルマネージドキャッシュサービス特徴 (https://aws.amazon.

一部パラメータ以外はアプリケーション特性に応じて変更更可能 Ø フェイルオーバーやパッチの適用バックアップ (Redis) も自動で行行われる Ø Memcached 用の Auto Discovery 対応

73 Amazon ElastiCache による Application Data Caching フルマネージドキャッシュサービス特徴 ( Ø フルマネージド環境で Memcached / Redis が利利用可能 Ø Redis は Multi- AZ 配置することで可用性向上 Ø 一部パラメータ以外はアプリケーション特性に応じて変更更可能 Ø フェイルオーバーやパッチの適用バックアップ (Redis) も自動で行行われる Ø Memcached 用の Auto Discovery 対応 Client Library も提供中 73 価格体系 ( Ø インスタンスタイプに応じて Ø Redis を利利用しバックアップを有効にした場合はバックアップストレージの利利用量量に応じて Caching

Amazon CloudFront による Edge Caching マネージド CDN(Contents Delivery Network) サービス配信 Amazon CloudFront オフロード特徴 (http://aws.amazon.

74 Amazon CloudFront による Edge Caching マネージド CDN(Contents Delivery Network) サービス配信 Amazon CloudFront オフロード特徴 ( Ø 簡単にサイトの高速化が実現できると共にサーバの負荷も軽減 Ø 様々な規模のアクセスを処理理することが可能 Ø 世界 53 箇所のエッジロケーションクライアントレスポンス向上キャッシュ負荷軽減 Web サーバ価格体系 ( Ø データ転送量量 (OUT) Ø HTTP/HTTPSリクエスト数 Ø ( 利利用する場合 )SSL 独自証明書など 74 Caching

75 セキュリティ Security

76 セキュリティすべてのレイヤーでセキュリティを確保 Ø 一箇所でもセキュリティホールがあればそこを突かれてしまうセキュリティ確保のためのポイント Ø AWS の機能の活用 Ø AWS へセキュリティの担保をオフロード Ø 最小権限の原則 Ø Security as Code Ø リアルタイム監査詳細 : aws Security

77 すべてのレイヤーでセキュリティを確保アクセス管理理 AWS アカウント IAM ユーザーの管理理 AWS リソースへのアクセス制御 ( 最小権限の原則を順守可能 ) 権限管理理データ暗号化保管するデータの暗号化 S3 や EBS RDS といったストレージサービス上のデータを暗号化 Public Segment サブネット外部からアクセスできるサブネットと外部からはアクセスできないサブネットの作成 Private Segment (Web) NAT NAT Public Subnet (DMZ) Public Subnet (DMZ) Web Web Web Web Private Subnet Private Subnet 操作ログリソース監視 AWS 操作ログ AWS 操作ログの取得 ( 管理理コンソールや CLI 含む ) AWS サービス監視各種 AWS サービス (ELB RDS EC2 等 ) のリソース監視ネットワークアクセス制御 SecurityGroup 及びNetwork ACLを使ってアクセス制御を実施 Private Segment (DB) Lo g Private Subnet Availability Zone Private Subnet Availability Zone 通知 77 詳細 : aws Security

78 AWS の機能の活用 78 AWS が提供する便便利利なセキュリティ機能を活用することでよりシンプルにセキュリティ確保が可能に AWS が提供するセキュリティ機能活用の例例 Ø AWS IAM による権限制御 Ø セキュリティグループによるアクセスコントロール Ø AWS WAF による DDoS 緩和 Ø AWS CloudTrail による監査ログ取得 Ø AWS KMS による暗号化鍵管理理 Ø etc Security

79 AWS へセキュリティの担保をオフロードマネージドサービスの活用により AWS がセキュリティ管理理を行行うレイヤーを広くすることが可能サーバではなくサービスの利利用で示したセキュリティ責任共有モデルの図を参照 79 Security

80 AWS IAM を活用した最小権限の原則順守 AWS サービスおよびリソースへのアクセスを安全にコントロール特徴 ( Ø AWS リソースへのきめ細かなアクセス制御 Ø 認証情報の利利用状況を一目で把握できるレポート機能 Ø 社内ディレクトリとの統合も可能 Ø ウェブ ID プロバイダーを使ったモバイルアプリケーションへのアクセスコントロールの管理理 Ø 権限の高いユーザーに対する多要素認証の利利用 ( Multi- Factor Authentication) 価格体系 ( Ø IAM の利利用自体は全て無料料多様な MFA デバイスをサポート 80 Security

81 Security as Code AWS はプログロマブルセキュリティの Golden Environment をコード化し適切切なセキュリティ設定がされた環境の配布を容易易に Ø AWS CloudFormation Ø AWS Service Catalog 81 Security

82 リアルタイム監査継続的にコンプライアンスのための監視を実施 Ø AWS Config Ø Amazon Inspector Ø AWS Trusted Advisor AWS 環境の操作ログの取得 Ø AWS CloudTrail アプリケーションログの収集 Ø Amazon CloudWatch Logs 82 Security

83 Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティスまとめ

84 84 まとめ (10 の設計プリンシプル ) スケーラビリティ固定資産から可処分資産へ自動化疎結合サーバではなくサービスの利利用 ( マネージドサービスの活用 ) データベースの使い分け単一障害点の排除コストの最適化キャッシュの利利用セキュリティ Architecting for The Cloud: AWS Best Practices Cloud_ Best_ Practices.pdf

85 参考資料料 Architecting for The Cloud: AWS Best Practices Ø Cloud_ Best_ Practices.pdf 失敗例例を成功に変える AWS アンチパターン Ø 2016 年年 : black- belt- online- seminar- antipattern Ø 2015 年年 : antipattern

Webinar 資料料の配置場所 AWS クラウドサービス活用資料料集 Ø http://aws.amazon.

86 Webinar 資料料の配置場所 AWS クラウドサービス活用資料料集 Ø jp- introduction/ AWS Solutions Architect ブログ Ø 最新の情報セミナー中の Q&A 等が掲載されています Ø 86

87 公式 Twitter/Facebook AWS jp 検索索もしくは最新技術情報イベント情報お役立立ち情報お得なキャンペーン情報などを日々更更新しています! 87

88 AWS の導入お問い合わせのご相談 AWS クラウド導入に関するご質問お見見積り資料料請求をご希望のお客様は以下のリンクよりお気軽にご相談ください us/aws- sales/ 88 AWS 問い合わせで検索索してください

Architecting for the Cloud -クラウドにおけるアーキテクチャの設計原則

Architecting for the Cloud -クラウドにおけるアーキテクチャの設計原則 Architecting for the Cloud クラウドにおけるアーキテクチャの設計原則 Daichi Egawa, AWS Solutions Architect June 1, 2017 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Agenda はじめにクラウドコンピューティングの特徴クラウドの特徴を活かすための設計原則

Who am I? 名前 : 江川 大地 所属 アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト 経歴 データベースエンジニア AWS テクニカルトレーナー 好きなサービス AWS サポート 2 好きなデータベース PostgreSQL

Who am I? 名前 : 江川大地所属アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト経歴データベースエンジニア AWS テクニカルトレーナー好きなサービス AWS サポート 2 好きなデータベース PostgreSQL