AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-
•
55 likes•22,749 views
AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-
![AMI 戦略略
Linux
J2EE
アプリコード
Log4J
Spring
Hibernate
Struts
Tomcat
Apache
Linux
J2EE
アプリコード
Log4J
Spring
Hiberna
te
Struts
Tomcat
Apache
EC2
アプリ
コード
Amazon
S3
Log4J
Spring
Struts
Linux
J2EE
Hiberna
te
Tomcat
Apache
Linux
J2EE
アプリ
コード
Amazon
S3
Hiberna
te
Tomcat
Log4J
Spring
Struts
Apache
EC2
L
i
n
u
x
J
E
E
H
i
b
e
r
n
a
t
e
T
o
m
c
a
t
A
p
a
c
h
e
L
i
n
u
x
J
E
E
H
i
b
e
r
n
a
t
e
T
o
m
c
a
t
A
p
a
c
h
e
L
i
n
u
x
J
E
E
H
i
b
e
r
n
a
t
e
T
o
m
c
a
t
A
p
a
c
h
e
EC2
Linu
x
JEE
Linu
x
JEE
Chef
Chef
スクリプト
Java AMIJavaスタック Java AMI
AMI
起動時取得
起動時取得
起動時取得
[1]全部⼊入りAMI [2]部分設定済 AMI [3]最⼩小構成AMI
27 Disposable Resources Instead of Fixed Servers](https://image.slidesharecdn.com/20160929aws-blackbelt-architectingforthecloud-160929105840/85/AWS-Black-Belt-Online-Seminar-2016-27-320.jpg)
![AMI 戦略略 Pros/Cons
⽅方式 利利点 ⽋欠点
[1]全部⼊入りAMI 同⼀一性の確保
起動時間が早い
デプロイ毎にAMIを作り直
す必要がある(作成プロセス
を⾃自動化すれば⽋欠点とはな
らない)。
[2]部分設定済AMI あとはアプリコードのみ最
新を取得すれば良良く扱いや
すい
[3]最⼩小構成AMI 柔軟に中⾝身を変更更できる 起動処理理に時間がかかる。
場合によっては外部ライブ
ラリが取得できないことも
28 Disposable Resources Instead of Fixed Servers](https://image.slidesharecdn.com/20160929aws-blackbelt-architectingforthecloud-160929105840/85/AWS-Black-Belt-Online-Seminar-2016-28-320.jpg)
AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-
- 1. 【AWS Black Belt Online Seminar】 クラウドのためのアーキテクチャ設計 -ベストプラクティス- アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト 江川⼤大地 2016.09.29 Architecting for the Cloud
- 2. Who am I ? • 名前：江川 ⼤大地 • 所属 • アマゾン ウェブ サービス ジャパン株式会社 • ソリューションアーキテクト • 経歴 • データベースエンジニア • AWS テクニカルトレーナー • 好きなサービス • AWS サポート • 好きなデータベース • PostgreSQL 2
- 3. 本資料料では2016年年9⽉月29⽇日時点のサービス内容および価格についてご説明しています。 最新の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。 資料料作成には⼗十分注意しておりますが、資料料内の価格と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 http://aws.amazon.com/agreement/. 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 https://d0.awsstatic.com/whitepapers/AWS_̲Cloud_̲Best_̲Practices.pdf 7
- 8. Agenda • はじめに • The Cloud Computing Difference • 設計におけるベストプラクティス • まとめ 8
- 10. クラウドコンピューティングならではの特性 • IT 資産がプログラマブルに • グローバル展開、可⽤用性、無制限のキャパシティ • ⾼高レベルなマネージドサービス • Built-‐‑‒in Security 10
- 11. Agenda • はじめに • The Cloud Computing Difference • 設計におけるベストプラクティス • まとめ
- 12. 10 の設計プリンシプル • スケーラビリティ • 固定資産から可処分資産へ • ⾃自動化 • 疎結合 • サーバではなく、サービスの利利⽤用(マネージドサービスの活⽤用) • データベースの使い分け • 単⼀一障害点の排除 • コストの最適化 • キャッシュの利利⽤用 • セキュリティ 12
- 14. スケーラビリティ • 運⽤用中のシステムを拡張/縮⼩小させる能⼒力力 • スケーラビリティを⽣生かすことで可能になること Ø 柔軟性の向上(事業の必要性に応じたリソース確保) Ø コスト削減(必要な時に必要な分だけのリソース確保) • スケールの種類 Ø ⽔水平スケーリング(スケールアウト/スケールイン) Ø 垂直スケーリング(スケールアップ/スケールダウン) Scalability14
- 15. ⽔水平・垂直のスケーリングの⽐比較 • 垂直スケーリング (スケールアップ/スケールダウン) Ø 個々のリソースのスペックを増減 Ø リソースの限界が存在 Ø インスタンスの停⽌止が伴う • ⽔水平スケーリング (スケールアウト/スケールイン) Ø リソースの台数を増減 Ø 論論理理的には限界が存在しない Ø インスタンスの停⽌止が伴わない small large Scalability small small small small small small small small small small 15
- 16. ⽔水平スケーリングを⾏行行うために⼼心がけること • ステートレスアプリケーション/コンポーネント Ø ステートフルになる要素を⽔水平スケールするリソースの外部に配置 - セッション情報は、DynamoDB/ElastiCache へ - バイナリファイル, ログなどは、 Amazon S3 へ • ステートフルになるコンポーネントをどう扱うか Ø ⽔水平スケールするマネージドサービスの利利⽤用 Ø ⽔水平スケールができない場合に注意すべき制約を洗い出す • 分散処理理（今までのやり⽅方を⾒見見直す） Ø ⻑⾧長時間かかっていた単⼀一のタスクを分割できないか検討 - 1台のサーバで4時間かかるタスクを、4台のサーバで1時間でこなす • 商⽤用ライセンスの扱い Ø ライセンスの提供元に確認 Scalability16
- 17. ステートレスにするためのセッション情報の扱い Ø スケールアウト時 - スケールアウトしたリソースが 使われにくい Ø スケールイン時 - セッションも⼀一緒に落落とすことにな るので、困難 Web/ App Auto Scaling ELB Client Web/ App Scalability • セッション情報を⽔水平スケールさせたいコンポーネントで持つと Web/ App セッション 既存ユーザのセッ ションは、既存のコ ンポーネントにある ため、リクエストは、 同じリソースへ Sticky Session スケールアウトした リソースを活かしに くい Web/ App Auto Scaling ELB Client Web/ App セッション インスタンスを削除す ると、既存ユーザの セッション情報も失わ れてしまう(ログアウト された挙動となる) Sticky Session 17
- 18. ステートレスにするためのセッション情報の扱い • スケールさせやすくするためにセッション情報は外だし Web/ App Auto Scaling ELBClient Web/ App DynamoDB セッション情報 ElastiCache or 書き換えられても問 題ない情報、肥⼤大化 の恐れがない情報は Client-‐‑‒Side で保持 することも可能 Client-‐‑‒Side で書き換 えられると困る情報は Server-‐‑‒Side で保持 Scalability 各リソースに固有の情報がないの で、いつでも増減しやすい 18
- 19. 固定資産から可処分資産へ Disposable Resources Instead of Fixed Servers
- 20. 今まで(オンプレミス) • 固定のリソースで運⽤用 Ø リソース購⼊入は前払い Ø リソース追加には⻑⾧長いリードタイム → 事前のサイジングが必須 リソースに対する考え⽅方 AWS • 固定資産ではない Ø 使い捨て可能なソフトウェア (いつでも増減、変更更可能) → 事前のサイジングは不不要 Disposable Resources Instead of Fixed Servers タスクが増えたら インスタンスを増やして対応 タスクが完了了したら シャットダウン サイジングにより 決まった台数、スペック 追加には ⻑⾧長時間かかる 20
- 21. マインドセットを変える AWS • リソースが常に存在する/変更更しな い前提の設計、運⽤用を⽌止める Ø ⾃自動化 Ø DNS によるアクセス Ø バッチスケジュールの⾒見見直し Ø 利利⽤用時間帯の確認 Disposable Resources Instead of Fixed Servers 今まで(オンプレミス) • 固定リソース運⽤用により 助⻑⾧長されがちなプラクティス Ø ⼿手作業による設定変更更 Ø IP アドレスのハードコード Ø シーケンシャルな処理理 Ø 常に電源 ON 21
- 22. ⾃自動化 • ⽔水平スケールも⾃自動的に • ⽔水平スケールしたインスタンスに対する設定も⾃自動的に Ø EC2 ユーザーデータ、メタデータ - http://docs.aws.amazon.com/ja_̲jp/AWSEC2/latest/UserGuide/ec2-‐‑‒instance-‐‑‒metadata.html Ø 構成管理理ツール（Chef, Puppet などの3rd party ツール) • 次のプリンシプルも参照 Disposable Resources Instead of Fixed Servers 22
- 23. DNS によるアクセス • 固定 IP アドレスアクセスによる弊害の例例 Disposable Resources Instead of Fixed Servers 23 スケールイン時 10.0.0.51 10.0.0.52 10.0.0.51 10.0.0.52 10.0.0.52 直打ちでの アクセス 使⽤用率率率が低くなったので、 スケールイン
- 24. バッチスケジュールの⾒見見直し • 並列列化で早く終わらせる Ø 1台で n 時間も n台で 1時間も料料⾦金金は同じ Disposable Resources Instead of Fixed Servers 24 時間 1h 2h 3h タスク １ タスク ２ タスク ３ タスク １ タスク ２ タスク ３ 時間 1h 2h 3h
- 25. 利利⽤用時間帯の確認 • 固定資産ではないので、常に稼働させる必要はない • 実際のワークロード、利利⽤用時間帯に合わせて稼働させる必要 がない時間は落落として、コスト節約につなげる Disposable Resources Instead of Fixed Servers 25
- 26. 可処分所得にするためのポイント • AMI, スナップショット戦略略 (いつでもリソースを作成できるように準備) Ø 全部⼊入り AMI Ø Bootstrapping Ø Hybrid(AMI と Bootstrapping の組み合わせ) • Infrastructure as Code Ø 個々のリソースだけでなく、システム全体をいつでも作成できるよう準備 (例例)バッチシステムを CloudFormation で作成し、完了了したら削除 Disposable Resources Instead of Fixed Servers 26
- 27. AMI 戦略略 Linux J2EE アプリコード Log4J Spring Hibernate Struts Tomcat Apache Linux J2EE アプリコード Log4J Spring Hiberna te Struts Tomcat Apache EC2 アプリ コード Amazon S3 Log4J Spring Struts Linux J2EE Hiberna te Tomcat Apache Linux J2EE アプリ コード Amazon S3 Hiberna te Tomcat Log4J Spring Struts Apache EC2 L i n u x J E E H i b e r n a t e T o m c a t A p a c h e L i n u x J E E H i b e r n a t e T o m c a t A p a c h e L i n u x J E E H i b e r n a t e T o m c a t A p a c h e EC2 Linu x JEE Linu x JEE Chef Chef スクリプト Java AMIJavaスタック Java AMI AMI 起動時取得 起動時取得 起動時取得 [1]全部⼊入りAMI [2]部分設定済 AMI [3]最⼩小構成AMI 27 Disposable Resources Instead of Fixed Servers
- 28. AMI 戦略略 Pros/Cons ⽅方式 利利点 ⽋欠点 [1]全部⼊入りAMI 同⼀一性の確保 起動時間が早い デプロイ毎にAMIを作り直 す必要がある(作成プロセス を⾃自動化すれば⽋欠点とはな らない)。 [2]部分設定済AMI あとはアプリコードのみ最 新を取得すれば良良く扱いや すい [3]最⼩小構成AMI 柔軟に中⾝身を変更更できる 起動処理理に時間がかかる。 場合によっては外部ライブ ラリが取得できないことも 28 Disposable Resources Instead of Fixed Servers
- 29. AWS CloudFormation • 特徴 (http://aws.amazon.com/jp/cloudformation/) Ø テンプレートを元に、EC2やELBといった AWSリソースの環境構築を⾃自動化 Ø JSON, YAMLフォーマットのテキストで、 テンプレートを⾃自由に記述可能 Ø Microsoft Windows Server や SAP HANA などのリファレンス実装を⽤用意（http:// aws.amazon.com/quickstart/） • 価格体系 (http://aws.amazon.com/jp/cloudformation/pricing/) Ø 追加料料⾦金金はありません AWS リソース（Amazon EC2 インスタンスや Elastic Load Balancing ロード バランサーなど）に対してお⽀支払いいただきます。 設定管理理 & クラウドのオーケストレーション サービス スタック EC2 Auto Scaling テンプレート（設定ファイル） テンプレートに基づき 各リソースが⾃自動起動 EC2 Cloud Formation 29 Disposable Resources Instead of Fixed Servers
- 30. ⾃自動化 Automation
- 31. ⾃自動化 • ⾃自動化を意識識することで得られるメリット Ø オペミス防⽌止などの安定した運⽤用 Ø 運⽤用負荷の軽減 Ø 可⽤用性の向上 • AWS と⾃自動化 Ø API で動作するので、⾃自動化しやすい Ø ⾃自動化をサポートするサービスが豊富 Automation31
- 32. ⾃自動化をサポートする代表的なサービス/機能 Automation • AWS Elastic Beanstalk • AWS OpsWorks • Auto Scaling • Amazon EC2 Auto Recovery • Amazon CloudWatch Alarms • Amazon CloudWatch Events • AWS Lambda Scheduled events 32
- 33. AWS ElasticBeanstalk • 特徴 (http://aws.amazon.com/jp/elasticbeanstalk/) Ø 速く簡単にアプリケーションをデプロイ可能 Ø インフラストラクチャの準備＆運営からアプリ ケーションスタックの管理理まで⾃自動化 Ø Auto Scaling によりコストを抑えながらスケー ラビリティを確保 Ø Java, PHP, Ruby, Python, Node.js, .NET, Docker などに対応 • 価格体系 (http://aws.amazon.com/jp/elasticbeanstalk/pricing/) Ø 追加料料⾦金金なし Ø アプリケーションの保存、実⾏行行に必要なAWSリ ソース (EC2, S3, RDS, DynamoDB など) に対 してのみ課⾦金金 インフラ構成の構築・アプリデプロイの⾃自動化サービス Automation33
- 34. AWS OpsWorks • 特徴 (http://aws.amazon.com/jp/opsworks/) Ø Chefのレシピを使って、デプロイや運⽤用タス クを⾃自動化可能 Ø ライフサイクルイベントにより動的な構成変 更更への対応が可能 Ø 継続的な構成管理理 • 価格体系 (http://aws.amazon.com/jp/elasticloadbalancing/pricing/) Ø AWS OpsWorks⾃自体の利利⽤用は無料料 Ø （OpsWorksエージェントをオンプレミス サーバで利利⽤用する場合はその起動時間） アプリケーションのデプロイ・管理理サービス AWS OpsWorks スタック LBレイヤー Webレイヤー DBレイヤー EC2インスタンス上の OpsWorksエージェント Automation34
- 35. Auto Scaling • 特徴 (http://aws.amazon.com/jp/autoscaling/) Ø Amazon EC2インスタンス群を⾃自動的にス ケール Ø 耐障害性の向上（インスタンスの異異常を検知 して、新しいインスタンスを起動） Ø EC2インスタンスの起動料料⾦金金の最適化 • 価格体系 (http://aws.amazon.com/jp/autoscaling/pricing/) Ø Auto Scaling⾃自体の利利⽤用は無料料 Ø Auto Scalingによって起動されるEC2インス タンスの起動料料⾦金金 EC2インスタンスを負荷またはスケジュールに応じて⾃自動増減 Auto Scaling group Desired Capacity 必要に応じて 追加される Capacity 起動設定 • インスタンスタイプ • AMI など Automation35
- 36. Amazon CloudWatch • 特徴 (http://aws.amazon.com/jp/cloudwatch/) Ø AWSリソースの死活、性能、ログ監視 Ø 取得メトリックスのグラフ化 Ø 各メトリックスに対してアラーム作成 • 価格体系 (http://aws.amazon.com/jp/cloudwatch/pricing/) Ø 基本モニタリング（5分間隔）は無料料 Ø (利利⽤用する場合) 詳細モニタリング Ø (利利⽤用する場合)カスタムメトリックス、APIリ クエスト、アラーム、ログ等 AWSの各種リソースを監視するサービス Automation36
- 37. AWS Lambda • 特徴 (http://aws.amazon.com/jp/lambda/) Ø OS、キャパシティ等インフラの管理理不不要 Ø S3、Kinesis、SNS等でのイベント発⽣生を元に ユーザが⽤用意したコード（Node.js）を実⾏行行 Ø ユーザアプリからの同期/⾮非同期呼び出し • 価格体系 (http://aws.amazon.com/jp/lambda/pricing/) Ø コード実⾏行行時間（100ms単位） Ø Lambdaファンクションへのリクエスト回数 Ø 1⽉月あたり100万リクエスト、400,000GB/秒 が無料料で利利⽤用可能 イベントをトリガーにコードを実⾏行行するコンピュートサービス AWS LambdaAmazon S3 Bucket イベント 元画像 サムネイル画像 1 2 3 AWS LambdaAmazon DynamoDB Table and Stream プッシュ通知 別テーブルを更更 新 ■イメージのリサイズやサムネイルの作成 ■値チェックや別テーブルへのコピー Automation37
- 38. ⽔水平スケーリングの⾃自動化 アベイラビリティーゾーンアベイラビリティーゾーン アラーム CloudWatch Alarms Auto Scaling Group • システムの状況を監視し、⾃自動的にスケールアウト/イン 38 Automation
- 39. ⽔水平スケーリングの⾃自動化 • システムの状況を監視し、⾃自動的にスケールアウト/イン • スケールアウトしたインスタンスは、ユーザーデータの カスタムスクリプトなどで⾃自動設定 アベイラビリティーゾーンアベイラビリティーゾーン アラーム CloudWatch Alarms Auto Scaling Group 39 Automation
- 40. インスタンスの復復旧も⾃自動化 Automation • Auto Scaling による⾃自動復復旧(Auto Healing) • EC2 Auto Recovery による⾃自動復復旧 サーバー クラッシュ 代替リソースが ⾃自動的に起動 Auto Scaling group min = 1 40
- 41. 運⽤用も⾃自動化 Automation • Amazon CloudWatch Events を利利⽤用した運⽤用⾃自動化 Ø Amazon EBS の⾃自動スナップショット Ø EC2 インスタンスの停⽌止/削除 • AWS Lambda のスケジュール実⾏行行 Ø プログラムを書いてカスタムな運⽤用項⽬目を⾃自動化 41
- 43. 疎結合(Loose Coupling) • 結合度度(Coupling)は低いほど好ましい Ø 不不具合の影響範囲を最⼩小限にとどめられる Ø スケーリングしやすい • 疎結合にするために⼼心がけること Ø Well-‐‑‒Defined Interfaces Ø Service Discovery Ø Asynchronous Integration Ø Graceful Failure Loose Coupling 43
- 44. Well-‐‑‒Defined Interfaces • アクセス元から⾒見見て、アクセス先をブラックボックスに Ø 個々のリソースに固有の情報に依存しない - 必要な情報だけをわたし、API でアクセス - IP アドレスではなく DNS 名でアクセス - 処理理を実施するインスタンスへの直接アクセスを避け、 ELB, SQS へアクセスさせるよう設計 Loose Coupling 44
- 45. Service Discovery • 透過的にアクセスするために、増えたリソース、減った リソースを検知することが必要 • Service Discovery の例例 Ø Auto Scaling を使ったインスタンスの ELB への⾃自動登録 Ø EC2 ユーザーデータ × Amazon Route 53 Ø Auto Scaling Life Cycle Hook × Amazon Route 53 Ø 3rd party solutions - Netflix Eureka - Airbnb Synapse - HashiCorp Consul - etc Loose Coupling 45
- 46. AWS のサービスを活⽤用した疎結合の例例 Loose Coupling ウェブサーバーは アプリサーバーと密結合 Web Server App Server ELB を挟んで疎結合に Web Server App Server ELB ELB は、 Auto Scaling を組み合わせ、増減する App Server を⾃自動で 登録/解除可能 Web Server は単⼀一 の ELB の DNS 名だ けを⾒見見てれば良良い (App Server は Web Server にとってブ ラックボックス) スケールアウト/インする たびに、Web Server の 設定ファイルの書き換え が必要 46
- 47. Asynchronous Integration • 同期処理理である必要がなければ⾮非同期でつながる • ⾮非同期処理理の利利点 Ø ユーザ側の利利点 - アプリケーションがブロックされない Ø サーバ側の利利点 - スケーラブルかつ⾼高可⽤用なバックエンド - Frontend を停⽌止させることなく Backend を容易易にメンテナンス可能 - 少ないFrontend のキャパシティで多くのリクエストを受付可能 - リクエストの処理理順序やリトライ等の制御が容易易に Loose Coupling 47
- 48. AWS のサービスを活⽤用した⾮非同期処理理の例例 • Amazon SQS Ø メッセージキューを挟んで、Frontend と Backend を疎結合に • Amazon Kinesis Ø ストリームデータの⽣生成・受け取りとそのデータ処理理部を疎結合に • Amazon Simple Workflow Ø 複雑なワークフローにのっとる複数のタスク、ワークフローの 状態管理理を疎結合に • AWS Lambda Ø DynamoDB へのアップデート、S3 へのデータアップロードと 後続の処理理を疎結合に Loose Coupling 48
- 49. AWS のサービスを活⽤用した⾮非同期処理理の例例 • Amazon SQS を挟んで Frontend と Backend を疎結合に Loose Coupling Frontend Servers ELB Client 重たい処理理は Backend Servers に任せる Sticky Session Backend Servers SQS キューから取得した メッセージを元にバッチ 的に処理理を実⾏行行していく 重たい処理理は Backend で⾮非同期に⾏行行われるので、 Client へのレスポンスは 迅速に Amazon SQS Queue 49
- 50. Amazon Simple Queue Service (SQS) • 特徴 (http://aws.amazon.com/jp/sqs/) Ø ⾼高い信頼性: 複数のサーバー/データセンターにメッセー ジを保持 Ø スケーラブル: 多数の送信者/受信者に対応 Ø ⾼高スループット: メッセージが増加しても⾼高スループッ トを出し続ける • 価格体系 (http://aws.amazon.com/jp/sqs/pricing/) Ø 無料料利利⽤用枠: 毎⽉月100万Amazon SQSリクエストまで無 料料 Ø その後Amazon SQSリクエスト100万件につき0.476 USD(東京リージョン以外は0.5USD) Ø 複数のメッセージを１度度のリクエストで処理理することに より、コスト効率率率をあげることも可能 ⾼高い可⽤用性と信頼性を提供する フルマネージドなメッセージキューサービス Producer Consumer polling Producer, ConsumerはEC2やモバイルデバイス、 オンプレミスんサーバーなどで構成する。実際の やりとりにはAmazon SQS APIを使って行う。 message message Loose Coupling 50
- 51. Amazon Kinesis • 特徴 (http://aws.amazon.com/jp/kinesis/) Ø ⽣生成されるデータをリアルタイムに近 い状況でデータ処理理部に伝送 Ø 預かったデータは、3AZに24時間保存 Ø AWSのサービスとの簡単インテグレー ション Ø ⽬目的に応じた処理理を並列列処理理すること が可能 • 価格体系 (http://aws.amazon.com/jp/kinesis/pricing/) Ø シャード数 Ø Put APIコール数 フルマネージド型リアルタイム⼤大規模ストリーミング処理理 ⼤大量量トランザク ション処理理 複数データ処理理の 容易易なインテグ レーション Loose Coupling 51
- 52. Graceful Failure • 安全に落落とすための戦略略 Ø リソースの停⽌止、削除、障害時の クライアントや他のリソースへの影 響を最⼩小限にするように設定しておく • Graceful Failure の例例 Ø ELB Connection Draining - 新規割り振りは中⽌止して、処理理中のリクエストは終わるまで⼀一定期間待つ Ø Route 53 による DNS Failover - 障害発⽣生時は、CloudFront + S3 で構築した Sorry Site へ誘導 Ø 再試⾏行行処理理の実装 - 失敗した場合にはリトライで対応 Loose Coupling 52
- 54. サーバではなく、サービスの利利⽤用 • マネージドサービスの利利⽤用によって得られるメリット Ø コア業務、アプリケーション部分への集中 Ø ⾼高可⽤用性 Ø 運⽤用負荷軽減 Ø ⾃自動スケール(サイジング不不要) • マネージドサービスの活⽤用により Serverless での構築も可能 Ø AWS上でのサーバーレスアーキテクチャ⼊入⾨門 - http://www.slideshare.net/AmazonWebServicesJapan/aws-‐‑‒black-‐‑‒belt-‐‑‒online-‐‑‒seminar-‐‑‒2016-‐‑‒aws Services, Not Servers 54
- 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など Services, Not Servers 詳細：http://media.amazonwebservices.com/jp/wp/AWS_̲Security_̲Best_̲Practices.pdf 55
- 56. セキュリティ責任共有モデル (Infrastructure Services) 基盤サービス コンピューティング ストレージ データベース ネットワーク AWS グローバル インフラストラクチャ リージョン アベイラビリティーゾーン エッジロケー ション クライアント側のデータ暗号化 とデータの整合性認証 サーバ側の暗号化 （ファイルシステムおよびデータ） NWトラフィックの保護 （暗号化/整合性/アイデンティティ） プラットフォーム、アプリケーション オペレーティングシステム、ネットワーク構成 顧客データ AWSが 管理理 アイデンティティ アクセス管理理 お客様に よる管理理 AWS IAM AWSが担当する範囲お客様が担当する範囲凡例例 Services, Not Servers ファイアウォール構成 56
- 57. セキュリティ責任共有モデル (Container Services) 基盤サービス コンピューティング ストレージ データベース ネットワーク AWS グローバル インフラストラクチャ リージョン アベイラビリティーゾーン エッジロケー ション クライアント側のデータ暗号化 とデータの整合性認証 サーバ側の暗号化 （ファイルシステムおよびデータ） NWトラフィックの保護 （暗号化/整合性/アイデンティティ） プラットフォーム、アプリケーション オペレーティングシステム、ネットワーク構成 顧客データ AWSが 管理理 アイデンティティ アクセス管理理 お客様に よる管理理 AWS IAM AWSが担当する範囲お客様が担当する範囲凡例例 Services, Not Servers ファイアウォール構成 57
- 58. セキュリティ責任共有モデル (Abstracted Services) 基盤サービス コンピューティング ストレージ データベース ネットワーク AWS グローバル インフラストラクチャ リージョン アベイラビリティーゾーン エッジロケー ション クライアント側のデータ暗号化 とデータの整合性認証 サーバ側の暗号化 （ファイルシステムおよびデータ） NWトラフィックの保護 （暗号化/整合性/アイデンティティ） プラットフォーム、アプリケーション オペレーティングシステム、ネットワーク構成 顧客データ AWSが 管理理 アイデンティ ティ アクセス管理理 お客様に よる管理理 AWS IAM AWSが担当する範囲お客様が担当する範囲凡例例 Services, Not Servers ファイアウォール構成 オプション機能として 提供されるもの 58
- 59. AWS では多くのサーバーレスオプションを⽤用意 ストレージ データベースネットワーク コンピューティング コンテンツ配信メッセージングとキューセキュリティ ゲートウェイ ユーザー管理理 モニタリングとログ記録 IoT 機械学習 ストリーミング分析 Services, Not Servers 59
- 61. データベースの使い分け • 万能なデータベース・ストレージは存在しない • データストアの特性(得意不不得意)に応じた使い分け Database Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon Redshift SQL NoSQL• 低レイテンシ • インメモリ • 3拠点間での レプリケーション • SSDに永続化 • トランザク ション処理理 • 汎⽤用⽤用途 • 集計・分析処理理 • ⼤大容量量データ • DWH 61
- 62. 単⼀一障害点の排除 Removing Single Points of Failure
- 63. 単⼀一障害点の排除 • 障害に備えておくことで、その影響を極⼩小化 Ø 下記のようにあらかじめ冗⻑⾧長化をしておくなどの準備が重要 Removing Single Points of Failure アベイラビリティーゾーンアベイラビリティーゾーン Auto Scaling Group もし、この1台が落落ち ても、システムの全停 ⽌止にはつながらない 63
- 64. 単⼀一障害点の排除 • 単⼀一障害点排除のためのポイント Ø 冗⻑⾧長化 Ø 障害検知 Ø 堅牢牢なデータストレージ Ø Multi-‐‑‒AZ の利利⽤用 Ø 疎結合な構成による障害分離離 Removing Single Points of Failure 詳細：https://d0.awsstatic.com/whitepapers/aws-‐‑‒building-‐‑‒fault-‐‑‒tolerant-‐‑‒applications.pdf 64
- 66. コストの最適化 • 単に既存システムをクラウドに移⾏行行するだけでも 初期投資を減少させ、AWS の規模の経済の恩恵を享受可能 • クラウド環境の特性を活かすことにより、 さらなるコスト最適化が可能 Ø 適切切なサイジング Ø 伸縮⾃自在性 Ø 適切切な購⼊入オプションの利利⽤用 Optimize for Cost 66
- 67. 適切切なサイジング • オーバープロビジョニングの回避 Ø AWS のリソースはいつでも増減可能 • 継続的な改善 Ø 適切切なインスタンスタイプを⾒見見極めるために常に監視 - Amazon CloudWatch によるリソース監視 - AWS Trusted Advisor で使⽤用率率率に低いリソース Optimize for Cost Amazon CloudWatch AWS Trusted Advisor 67
- 68. 伸縮⾃自在性 • ⽔水平スケーリングにより必要な時に必要なリソースを確保 • マネージドサービスのキャパシティを利利⽤用 Ø ELB, CloudFront, Amazon SQS, AWS Lambda etc Ø キャパシティを簡単に設定できるリソースの活⽤用 - Amazon DynamoDB, Amazon Kinesis Stream Optimize for Cost 需要によって 判断 68
- 69. 適切切な購⼊入オプションの利利⽤用 • Amazon EC2 の購⼊入オプション Ø リザーブドインスタンス Ø スポットインスタンス • Amazon S3 のストレージ価格 Ø スタンダードストレージ Ø 標準 – 低頻度度アクセスストレージ Ø 低冗⻑⾧長化ストレージ • その他のサービスの購⼊入オプション Ø CloudFrontのリザーブドキャパシティ Ø DynamoDBのリザーブドキャパシティ Optimize for Cost 69
- 70. 適切切な購⼊入オプションの利利⽤用 • Amazon EC2 の購⼊入オプション Ø リザーブドインスタンス Ø スポットインスタンス • Amazon S3 のストレージ価格 Ø スタンダードストレージ Ø 標準 – 低頻度度アクセスストレージ Ø 低冗⻑⾧長化ストレージ • その他のサービスの購⼊入オプション Ø CloudFrontのリザーブドキャパシティ Ø DynamoDBのリザーブドキャパシティ Optimize for Cost 10⽉月のオンラインセミナーもチェック！ 「AWSのコスト削減オプション」 https://connect.awswebcasts.com/blackbelt-‐‑‒cost-‐‑‒reduction/event/event_̲info.html 70
- 72. キャッシュの利利⽤用 • 繰り返し利利⽤用されるデータをキャッシュ Ø 性能向上 Ø コスト節約 Caching オリジンサーバ Amazon CloudFront オリジンサーバ 台数の削減 レスポンス向上 負荷軽減 リクエスト 配信 リクエスト キャッシュから配信 キャッシュ コンテンツ取得 CDN クライアント 72
- 73. Amazon ElastiCache による Application Data Caching • 特徴 (https://aws.amazon.com/jp/elasticache/) Ø フルマネージド環境でMemcached / Redisが利利⽤用可能 Ø RedisはMulti-‐‑‒AZ配置することで可⽤用性向上 Ø ⼀一部パラメータ以外はアプリケーション特性に応じて 変更更可能 Ø フェイルオーバーやパッチの適⽤用、バックアップ (Redis)も⾃自動で⾏行行われる Ø Memcached⽤用のAuto Discovery対応Client Libraryも 提供中 • 価格体系 (https://aws.amazon.com/jp/elasticache/pricing/) Ø インスタンスタイプに応じて Ø Redisを利利⽤用しバックアップを有効にした場合はバック アップストレージの利利⽤用量量に応じて フルマネージド キャッシュサービス 73 Caching
- 74. Amazon CloudFront による Edge Caching • 特徴 (http://aws.amazon.com/jp/cloudfront/) Ø 簡単にサイトの⾼高速化が実現できると共に、 サーバの負荷も軽減 Ø 様々な規模のアクセスを処理理することが可能 Ø 世界53箇所のエッジロケーション • 価格体系 (http://aws.amazon.com/jp/cloudfront/pricing/) Ø データ転送量量(OUT) Ø HTTP/HTTPSリクエスト数 Ø (利利⽤用する場合)SSL独⾃自証明書 など マネージドCDN(Contents Delivery Network)サービス クライアント レスポンス向上 負荷軽減 Amazon CloudFront キャッシュ 配信 オフロード Webサーバ 74 Caching
- 75. セキュリティ Security
- 76. セキュリティ • すべてのレイヤーでセキュリティを確保 Ø ⼀一箇所でもセキュリティホールがあれば、そこを突かれてしまう • セキュリティ確保のためのポイント Ø AWS の機能の活⽤用 Ø AWS へセキュリティの担保をオフロード Ø 最⼩小権限の原則 Ø Security as Code Ø リアルタイム監査 Security 詳細：http://www.slideshare.net/AmazonWebServicesJapan/awswebinar-‐‑‒aws-‐‑‒56260969 76
- 77. すべてのレイヤーでセキュリティを確保 Web Web Web Web Private Segment (Web) Public Segment Lo g Private Segment (DB) Public Subnet (DMZ) Public Subnet (DMZ) Private Subnet Private Subnet Private Subnet Private Subnet NAT NAT 操作ログ リソース監視 通知 データ暗号化 権限管理理 【サブネット】 外部からアクセスできるサブ ネットと、外部からはアクセ スできないサブネットの作成 【ネットワークアクセス制御】 SecurityGroup及びNetwork ACLを使ってアクセス制御を実 施 【保管するデータの暗号化】 S3やEBS、RDSといったスト レージサービス上のデータを暗 号化 【アクセス管理理】 AWSアカウント・IAMユー ザーの管理理。AWSリソースへ のアクセス制御(最⼩小権限の 原則を順守可能) 【AWS操作ログ】 AWS操作ログの取得（管理理コン ソールやCLI含む） 【AWSサービス監視】 各種AWSサービス（ELB、RDS、 EC2等）のリソース監視 Availability Zone Availability Zone Security詳細： http://www.slideshare.net/AmazonWebServicesJapan/awswebinar-‐‑‒aws-‐‑‒5626096977
- 78. AWS の機能の活⽤用 • AWSが提供する便便利利なセキュリティ機能を活⽤用することで よりシンプルにセキュリティ確保が可能に • AWS が提供するセキュリティ機能活⽤用の例例 Ø AWS IAM による権限制御 Ø セキュリティグループによるアクセスコントロール Ø AWS WAF による DDoS 緩和 Ø AWS CloudTrail による監査ログ取得 Ø AWS KMS による暗号化鍵管理理 Ø etc Security78
- 79. AWS へセキュリティの担保をオフロード • マネージドサービスの活⽤用により、AWS がセキュリティ 管理理を⾏行行うレイヤーを広くすることが可能 • 「サーバではなく、サービスの利利⽤用」で⽰示したセキュリ ティ責任共有モデルの図を参照 Security79
- 80. AWS IAM を活⽤用した「最⼩小権限の原則」順守 • 特徴 (http://aws.amazon.com/jp/iam/) Ø AWS リソースへのきめ細かなアクセス制御 Ø 認証情報の利利⽤用状況を⼀一⽬目で把握できるレポート機能 Ø 社内ディレクトリとの統合も可能 Ø ウェブ ID プロバイダーを使った、モバイルアプリケー ションへのアクセスコントロールの管理理 Ø 権限の⾼高いユーザーに対する多要素認証の利利⽤用（ Multi-‐‑‒ Factor Authentication） • 価格体系 (http://aws.amazon.com/jp/iam/pricing/) Ø IAMの利利⽤用⾃自体は全て無料料 AWS サービスおよびリソースへのアクセスを安全にコントロール 多様なMFAデバイスをサポート Security80
- 81. Security as Code • AWS はプログロマブル →セキュリティの”Golden Environment” をコード化し、 適切切なセキュリティ設定がされた環境の配布を容易易に Ø AWS CloudFormation Ø AWS Service Catalog Security81
- 82. リアルタイム監査 • 継続的にコンプライアンスのための監視を実施 Ø AWS Config Ø Amazon Inspector Ø AWS Trusted Advisor • AWS環境の操作ログの取得 Ø AWS CloudTrail • アプリケーションログの収集 Ø Amazon CloudWatch Logs Security82
- 83. Agenda • はじめに • The Cloud Computing Difference • 設計におけるベストプラクティス • まとめ
- 84. まとめ(10 の設計プリンシプル) • スケーラビリティ • 固定資産から可処分資産へ • ⾃自動化 • 疎結合 • サーバではなく、サービスの利利⽤用(マネージドサービスの活⽤用) • データベースの使い分け • 単⼀一障害点の排除 • コストの最適化 • キャッシュの利利⽤用 • セキュリティ Architecting for The Cloud: AWS Best Practices https://d0.awsstatic.com/whitepapers/AWS_̲Cloud_̲Best_̲Practices.pdf 84
- 85. 参考資料料 • Architecting for The Cloud: AWS Best Practices Ø https://d0.awsstatic.com/whitepapers/AWS_̲Cloud_̲Best_̲Practices.pdf • 失敗例例を成功に変える AWS アンチパターン Ø 2016年年： http://www.slideshare.net/AmazonWebServicesJapan/aws-‐‑‒black-‐‑‒belt-‐‑‒online-‐‑‒ seminar-‐‑‒antipattern Ø 2015年年： http://www.slideshare.net/AmazonWebServicesJapan/20150609-‐‑‒ antipattern-‐‑‒49198289
- 86. Webinar資料料の配置場所 • AWS クラウドサービス活⽤用資料料集 Ø http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/ • AWS Solutions Architect ブログ Ø 最新の情報、セミナー中のQ&A等が掲載されています Ø http://aws.typepad.com/sajp/ 86