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

Size: px

Start display at page:

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

あいねみうら
5 years ago
Views:

Architecting for the Cloud クラウドにおけるアーキテクチャの設計原則 Daichi Egawa, AWS Solutions

2 Agenda はじめにクラウドコンピューティングの特徴クラウドの特徴を活かすための設計原則まとめ

3 Agenda はじめにクラウドコンピューティングの特徴クラウドの特徴を活かすための設計原則まとめ

4 本日お話しすること想定する参加者 AWS の概要/メリットを理解している AWS を触ったことがある AWS でのシステム設計やサービス選定について悩んでいるお話しする内容クラウドらしいアーキテクチャを構築するための原則そういった原則にのっとることで嬉しくなるポイント

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

6 Agenda はじめにクラウドコンピューティングの特徴クラウドの特徴を活かすための設計原則まとめ

7 AWS / クラウドコンピューティングとは初期費用ゼロ低価格継続的な値下げサイジングからの解放商機を逃さない俊敏性最先端の技術やサービスいつでも即時グローバル展開

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

9 Agenda はじめにクラウドコンピューティングの特徴クラウドの特徴を活かすための設計原則まとめ

10 Ten Design Principles スケーラビリティ常設のサーバではなく使い捨て可能なリソース自動化疎結合サーバではなくサービスの利用 ( マネージドサービスの活用 ) データベースの使い分け単一障害点の排除コストの最適化キャッシュの利用セキュリティ

11 スケーラビリティ - Scalability -

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

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

14 水平スケーリングを行うために心がけることステートレスアプリケーション / コンポーネントステートフルになる要素を水平スケールするリソースの外部に配置 - セッション情報は DynamoDB/ElastiCache へ - バイナリファイル, ログなどは Amazon S3 へステートフルになるコンポーネントをどう扱うか水平スケールするマネージドサービスの利用水平スケールができない場合に注意すべき制約を洗い出す Scalability

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

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

17 常設のサーバではなく使い捨て可能なリソース - Disposable Resources Instead of Fixed Servers -

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

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

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

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

AMI 戦略 Apache [1]全部入りAMI [2]部分設定済 AMI Tomcat Struts アプリコードアプリコード Spring Struts Tomcat Log4J Spring Spring J2EE Javaスタック A p a c h e T o m c a ts t r u t s Y o u r C o L d o e g 4 J S p r i n g H i b

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

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

24 自動化 - Automation -

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

Amazon EC2 Systems Manager Amazon CloudWatch Alarms

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

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

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

29 疎結合 - Loose Coupling -

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

31 Well-Defined Interfaces アクセス元から見てアクセス先をブラックボックスに必要な情報はインターフェースで全て提供 - 内部情報に依存しない - 必要な情報だけをわたし API でアクセス - IP アドレスではなく DNS 名でアクセス - 処理を実施するインスタンスへの直接アクセスを避け ELB, SQS へアクセスさせるよう設計 Loose Coupling

32 Service Discovery 透過的にアクセスするために増えたリソース減ったリソースを検知することが必要 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

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

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

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

実行していく Sticky Session Amazon SQS Queue ELB 重たい処理は Backend

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

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

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

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

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

40 責任共有モデルから見るマネージドサービスの管理負荷責任共有モデルから見るサービス区分 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など詳細 Services, Not Servers

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

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

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

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

45 データベースの使い分け - Database -

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

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

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

49 単一障害点の排除単一障害点排除のためのポイント冗長化障害検知堅牢なデータストレージ Multi-AZ の利用疎結合な構成による障害分離参考 Removing Single Points of Failure

50 コストの最適化 - Optimize for Cost -

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

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

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

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

55 キャッシュの利用 - Caching -

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

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

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

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

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

59 セキュリティ - Security -

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

すべてのレイヤーでセキュリティを確保アクセス管理 AWSアカウント IAMユーザーの管理 AWSリソース

レージサービス上のデータを暗号化 Public Segment Private Segment (Web) サブネット

ネットワークアクセス制御 SecurityGroup及びNetwork ACLを使ってアクセス制御を実施詳細 DDoS対策 AWS

Subnet (DMZ) Web Web Web 操作ログ AWS操作ログ AWS操作ログの取得管理コンソールやCLI含む Web

Private Subnet Availability Zone リソース監視 AWSサービス監視各種AWSサービス ELB RDS

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

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

63 Agenda はじめにクラウドコンピューティングの特徴クラウドの特徴を活かすための設計原則まとめ

64 まとめ (Ten Design Principles) スケーラビリティ常設のサーバではなく使い捨て可能なリソース自動化疎結合サーバではなくサービスの利用 ( マネージドサービスの活用 ) データベースの使い分け単一障害点の排除コストの最適化キャッシュの利用セキュリティ

65 参考資料 Architecting for The Cloud: AWS Best Practices クラウドのためのアーキテクチャ設計 - ベストプラクティス失敗例を成功に変える AWS アンチパターン 2016 年 : 年 : antipattern

66 本セッションの Feedback をお願いします受付でお配りしたアンケートに本セッションの満足度やご感想などをご記入くださいアンケートをご提出いただきました方にはもれなく素敵な AWS オリジナルグッズをプレゼントさせていただきますアンケートは受付又はパミール 3F の EXPO 展示会場内にて回収させて頂きます

67 Thank you!

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

Who am I? 名前 : 江川大地所属アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト経歴データベースエンジニア AWS テクニカルトレーナー好きなサービス AWS サポート 2 好きなデータベース PostgreSQL AWS Black Belt Online Seminar クラウドのためのアーキテクチャ設計 - ベストプラクティス - Architecting for the Cloud アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト江川大地 2016.09.29 Who am I? 名前 : 江川大地所属アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト経歴データベースエンジニア