AWS Black Belt Online Seminar クラウドのためのアーキテクチャ設計 - ベストプラクティス - Architecting for the Cloud アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト江川 大地 2016.09.29
Who am I? 名前 : 江川 大地 所属 アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト 経歴 データベースエンジニア AWS テクニカルトレーナー 好きなサービス AWS サポート 2 好きなデータベース PostgreSQL
内容についての注意点 本資料料では 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
Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティス まとめ
Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティス まとめ
AWS 上でシステム設計にあたっての疑問 例例えば AWS の特性を活かせるような設計とは? オンプレミスと違う発想で臨臨んだほうがいいの? EC2 上でデータベースを構築するのと RDS を使うことの違いは? スケールアウト構成を 構築する場合に 何を意識識すればよいの? 6
本 日お話しすること クラウドらしいアーキテクチャを構築するための原則 AWS でシステムを構築するためのベストプラクティス より深く確認したい 方は下記のホワイトペーパーを参照 Ø Architecting for The Cloud: AWS Best Practices https://d0.awsstatic.com/whitepapers/aws_ Cloud_ Best_ Practices.pdf 7
Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティス まとめ 8
AWS / クラウドコンピューティングとは 俊敏性 アジリティの向上 低額な利利 用価格 伸縮 自在性 初期投資不不要 従量量課 金金 セルフサービスなインフラ Deploy 豊富なサービス ワールドワイド 9
クラウドコンピューティングならではの特性 IT 資産がプログラマブルに グローバル展開 可 用性 無制限のキャパシティ 高レベルなマネージドサービス Built- in Security 10
Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティス まとめ
10 の設計プリンシプル スケーラビリティ 固定資産から可処分資産へ 自動化 疎結合 サーバではなく サービスの利利 用 ( マネージドサービスの活 用 ) データベースの使い分け 単 一障害点の排除 コストの最適化 キャッシュの利利 用 セキュリティ 12
スケーラビリティ Scalability
スケーラビリティ 運 用中のシステムを拡張 / 縮 小させる能 力力 スケーラビリティを 生かすことで可能になること Ø 柔軟性の向上 ( 事業の必要性に応じたリソース確保 ) Ø コスト削減 ( 必要な時に必要な分だけのリソース確保 ) スケールの種類 Ø 水平スケーリング ( スケールアウト / スケールイン ) Ø 垂直スケーリング ( スケールアップ / スケールダウン ) 14 Scalability
水平 垂直のスケーリングの 比較 垂直スケーリング ( スケールアップ / スケールダウン ) Ø 個々のリソースのスペックを増減 Ø リソースの限界が存在 Ø インスタンスの停 止が伴う 水平スケーリング ( スケールアウト / スケールイン ) Ø リソースの台数を増減 Ø 論論理理的には限界が存在しない Ø インスタンスの停 止が伴わない small small small small large small small small small small small small 15 Scalability
16 水平スケーリングを 行行うために 心がけること ステートレスアプリケーション / コンポーネント Ø ステートフルになる要素を 水平スケールするリソースの外部に配置 セッション情報は DynamoDB/ElastiCache へ バイナリファイル, ログなどは Amazon S3 へ ステートフルになるコンポーネントをどう扱うか Ø 水平スケールするマネージドサービスの利利 用 Ø 水平スケールができない場合に注意すべき制約を洗い出す 分散処理理 ( 今までのやり 方を 見見直す ) Ø 長時間かかっていた単 一のタスクを分割できないか検討 1 台のサーバで 4 時間かかるタスクを 4 台のサーバで 1 時間でこなす 商 用ライセンスの扱い Ø ライセンスの提供元に確認 Scalability
ステートレスにするためのセッション情報の扱い セッション情報を 水平スケールさせたいコンポーネントで持つと Ø スケールアウト時 スケールアウトしたリソースが使われにくい Ø スケールイン時 セッションも 一緒に落落とすことになるので 困難 Sticky Session セッション Web/ App 既存ユーザのセッションは 既存のコンポーネントにあるため リクエストは 同じリソースへ Sticky Session セッション Web/ App インスタンスを削除すると 既存ユーザのセッション情報も失われてしまう ( ログアウトされた挙動となる ) Client ELB Web/ App Client ELB Web/ App 17 Web/ App Auto Scaling スケールアウトしたリソースを活かしにくい Auto Scaling Scalability
ステートレスにするためのセッション情報の扱い スケールさせやすくするためにセッション情報は外だし ElastiCache Web/ App or Client- Side で書き換えられると困る情報は Server- Side で保持 Client ELB Web/ App 18 書き換えられても問題ない情報 肥 大化の恐れがない情報は Client- Side で保持することも可能 Auto Scaling 各リソースに固有の情報がないので いつでも増減しやすい DynamoDB セッション情報 Scalability
固定資産から可処分資産へ Disposable Resources Instead of Fixed Servers
リソースに対する考え 方 今まで ( オンプレミス ) 固定のリソースで運 用 Ø リソース購 入は前払い Ø リソース追加には 長いリードタイム 事前のサイジングが必須 AWS 固定資産ではない Ø 使い捨て可能なソフトウェア ( いつでも増減 変更更可能 ) 事前のサイジングは不不要 サイジングにより 決まった台数 スペック 追加には 長時間かかる タスクが増えたら インスタンスを増やして対応 20 タスクが完了了したら シャットダウン Disposable Resources Instead of Fixed Servers
マインドセットを変える 今まで ( オンプレミス ) 固定リソース運 用により 助 長されがちなプラクティス Ø 手作業による設定変更更 Ø IP アドレスのハードコード Ø シーケンシャルな処理理 Ø 常に電源 ON AWS リソースが常に存在する / 変更更しない前提の設計 運 用を 止める Ø 自動化 Ø DNS によるアクセス Ø バッチスケジュールの 見見直し Ø 利利 用時間帯の確認 21 Disposable Resources Instead of Fixed Servers
自動化 水平スケールも 自動的に 水平スケールしたインスタンスに対する設定も 自動的に Ø EC2 ユーザーデータ メタデータ http://docs.aws.amazon.com/ja_ 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.0.0.51 10.0.0.52 10.0.0.51 10.0.0.52 23 Disposable Resources Instead of Fixed Servers
バッチスケジュールの 見見直し 並列列化で早く終わらせる Ø 1 台で n 時間も n 台で 1 時間も料料 金金は同じ タスク 3 タスク 2 タスク 1 タスク 2 タスク 3 タスク 1 1h 2h 3h 時間 1h 2h 3h 時間 24 Disposable Resources Instead of Fixed Servers
利利 用時間帯の確認 固定資産ではないので 常に稼働させる必要はない 実際のワークロード 利利 用時間帯に合わせて稼働させる必要がない時間は落落として コスト節約につなげる 25 Disposable Resources Instead of Fixed Servers
可処分所得にするためのポイント 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 アプリコード 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
AMI 戦略略 Pros/Cons 方式 利利点 欠点 [1] 全部 入り AMI 同 一性の確保 起動時間が早い [2] 部分設定済 AMI あとはアプリコードのみ最新を取得すれば良良く扱いやすい デプロイ毎に AMI を作り直す必要がある ( 作成プロセスを 自動化すれば 欠点とはならない ) [3] 最 小構成 AMI 柔軟に中 身を変更更できる 起動処理理に時間がかかる 場合によっては外部ライブ ラリが取得できないことも 28 Disposable Resources Instead of Fixed Servers
AWS CloudFormation 設定管理理 & クラウドのオーケストレーションサービス スタック テンプレート ( 設定ファイル ) Cloud Formation 特徴 (http://aws.amazon.com/jp/cloudformation/) Ø テンプレートを元に EC2 や ELB といった AWS リソースの環境構築を 自動化 Ø JSON, YAML フォーマットのテキストで テンプレートを 自由に記述可能 Ø Microsoft Windows Server や SAP HANA などのリファレンス実装を 用意 (http:// aws.amazon.com/quickstart/) EC2 テンプレートに基づき 各リソースが 自動起動 EC2 Auto Scaling 価格体系 (http://aws.amazon.com/jp/cloudformation/pricing/) Ø 追加料料 金金はありません AWS リソース (Amazon EC2 インスタンスや Elastic Load Balancing ロードバランサーなど ) に対してお 支払いいただきます 29 Disposable Resources Instead of Fixed Servers
自動化 Automation
自動化 自動化を意識識することで得られるメリット Ø オペミス防 止などの安定した運 用 Ø 運 用負荷の軽減 Ø 可 用性の向上 AWS と 自動化 Ø API で動作するので 自動化しやすい Ø 自動化をサポートするサービスが豊富 31 Automation
自動化をサポートする代表的なサービス / 機能 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.com/jp/elasticbeanstalk/) Ø 速く簡単にアプリケーションをデプロイ可能 Ø インフラストラクチャの準備 & 運営からアプリケーションスタックの管理理まで 自動化 Ø Auto Scaling によりコストを抑えながらスケーラビリティを確保 Ø Java, PHP, Ruby, Python, Node.js,.NET, Docker などに対応 33 価格体系 (http://aws.amazon.com/jp/elasticbeanstalk/pricing/) Ø 追加料料 金金なし Ø アプリケーションの保存 実 行行に必要な AWS リソース (EC2, S3, RDS, DynamoDB など ) に対してのみ課 金金 Automation
AWS OpsWorks アプリケーションのデプロイ 管理理サービス AWS OpsWorks EC2 インスタンス上の OpsWorks エージェント スタック LB レイヤー Web レイヤー DB レイヤー 特徴 (http://aws.amazon.com/jp/opsworks/) Ø Chef のレシピを使って デプロイや運 用タスクを 自動化可能 Ø ライフサイクルイベントにより動的な構成変更更への対応が可能 Ø 継続的な構成管理理 価格体系 (http://aws.amazon.com/jp/elasticloadbalancing/pricing/) Ø AWS OpsWorks 自体の利利 用は無料料 Ø (OpsWorks エージェントをオンプレミスサーバで利利 用する場合はその起動時間 ) 34 Automation
Auto Scaling EC2 インスタンスを負荷またはスケジュールに応じて 自動増減 起動設定 インスタンスタイプ AMI など Desired Capacity Auto Scaling group 必要に応じて追加される Capacity 特徴 (http://aws.amazon.com/jp/autoscaling/) Ø Amazon EC2 インスタンス群を 自動的にスケール Ø 耐障害性の向上 ( インスタンスの異異常を検知して 新しいインスタンスを起動 ) Ø EC2 インスタンスの起動料料 金金の最適化 価格体系 (http://aws.amazon.com/jp/autoscaling/pricing/) Ø Auto Scaling 自体の利利 用は無料料 Ø Auto Scaling によって起動される EC2 インスタンスの起動料料 金金 35 Automation
Amazon CloudWatch AWS の各種リソースを監視するサービス 特徴 (http://aws.amazon.com/jp/cloudwatch/) Ø AWS リソースの死活 性能 ログ監視 Ø 取得メトリックスのグラフ化 Ø 各メトリックスに対してアラーム作成 価格体系 (http://aws.amazon.com/jp/cloudwatch/pricing/) Ø 基本モニタリング (5 分間隔 ) は無料料 Ø ( 利利 用する場合 ) 詳細モニタリング Ø ( 利利 用する場合 ) カスタムメトリックス API リクエスト アラーム ログ等 36 Automation
AWS Lambda イベントをトリガーにコードを実 行行するコンピュートサービス イメージのリサイズやサムネイルの作成 元画像 1 3 Amazon S3 Bucket イベント サムネイル画像 2 値チェックや別テーブルへのコピー Amazon DynamoDB Table and Stream 37 AWS Lambda 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/ 秒が無料料で利利 用可能 Automation
水平スケーリングの 自動化 システムの状況を監視し 自動的にスケールアウト / イン アラーム CloudWatch Alarms Auto Scaling Group アベイラビリティーゾーン アベイラビリティーゾーン 38 Automation
水平スケーリングの 自動化 システムの状況を監視し 自動的にスケールアウト / イン スケールアウトしたインスタンスは ユーザーデータの カスタムスクリプトなどで 自動設定 アラーム CloudWatch Alarms Auto Scaling Group アベイラビリティーゾーン アベイラビリティーゾーン 39 Automation
インスタンスの復復旧も 自動化 Auto Scaling による 自動復復旧 (Auto Healing) Auto Scaling group min = 1 サーバー クラッシュ 代替リソースが 自動的に起動 EC2 Auto Recovery による 自動復復旧 40 Automation
運 用も 自動化 Amazon CloudWatch Events を利利 用した運 用 自動化 Ø Amazon EBS の 自動スナップショット Ø EC2 インスタンスの停 止 / 削除 AWS Lambda のスケジュール実 行行 Ø プログラムを書いてカスタムな運 用項 目を 自動化 41 Automation
疎結合 Loose Coupling
疎結合 (Loose Coupling) 結合度度 (Coupling) は低いほど好ましい Ø 不不具合の影響範囲を最 小限にとどめられる Ø スケーリングしやすい 疎結合にするために 心がけること Ø Well- Defined Interfaces Ø Service Discovery Ø Asynchronous Integration Ø Graceful Failure 43 Loose Coupling
Well- Defined Interfaces アクセス元から 見見て アクセス先をブラックボックスに Ø 個々のリソースに固有の情報に依存しない 必要な情報だけをわたし API でアクセス IP アドレスではなく DNS 名でアクセス 処理理を実施するインスタンスへの直接アクセスを避け ELB, SQS へアクセスさせるよう設計 44 Loose Coupling
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
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
Asynchronous Integration 同期処理理である必要がなければ 非同期でつながる 非同期処理理の利利点 Ø ユーザ側の利利点 アプリケーションがブロックされない Ø サーバ側の利利点 スケーラブルかつ 高可 用なバックエンド Frontend を停 止させることなく Backend を容易易にメンテナンス可能 少ない Frontend のキャパシティで多くのリクエストを受付可能 リクエストの処理理順序やリトライ等の制御が容易易に 47 Loose Coupling
AWS のサービスを活 用した 非同期処理理の例例 Amazon SQS Ø メッセージキューを挟んで Frontend と Backend を疎結合に Amazon Kinesis Ø ストリームデータの 生成 受け取りとそのデータ処理理部を疎結合に Amazon Simple Workflow Ø 複雑なワークフローにのっとる複数のタスク ワークフローの 状態管理理を疎結合に AWS Lambda Ø DynamoDB へのアップデート S3 へのデータアップロードと 後続の処理理を疎結合に 48 Loose Coupling
AWS のサービスを活 用した 非同期処理理の例例 Amazon SQS を挟んで Frontend と Backend を疎結合に Sticky Session 重たい処理理は Backend Servers に任せる SQS キューから取得したメッセージを元にバッチ的に処理理を実 行行していく Client ELB Amazon SQS Queue 重たい処理理は Backend で 非同期に 行行われるので Client へのレスポンスは迅速に Frontend Servers Backend Servers 49 Loose Coupling
Amazon Simple Queue Service (SQS) 高い可 用性と信頼性を提供する フルマネージドなメッセージキューサービス Producer message message polling Consumer Producer, Consumer は EC2 やモバイルデバイス オンプレミスんサーバーなどで構成する 実際のやりとりには Amazon SQS API を使って行う 特徴 (http://aws.amazon.com/jp/sqs/) Ø 高い信頼性 : 複数のサーバー / データセンターにメッセージを保持 Ø スケーラブル : 多数の送信者 / 受信者に対応 Ø 高スループット : メッセージが増加しても 高スループットを出し続ける 価格体系 (http://aws.amazon.com/jp/sqs/pricing/) Ø 無料料利利 用枠 : 毎 月 100 万 Amazon SQS リクエストまで無料料 Ø その後 Amazon SQS リクエスト 100 万件につき 0.476 USD( 東京リージョン以外は 0.5USD) Ø 複数のメッセージを 1 度度のリクエストで処理理することにより コスト効率率率をあげることも可能 50 Loose Coupling
Amazon Kinesis フルマネージド型リアルタイム 大規模ストリーミング処理理 大量量トランザクション処理理 複数データ処理理の容易易なインテグレーション 特徴 (http://aws.amazon.com/jp/kinesis/) Ø 生成されるデータをリアルタイムに近い状況でデータ処理理部に伝送 Ø 預かったデータは 3AZ に 24 時間保存 Ø AWS のサービスとの簡単インテグレーション Ø 目的に応じた処理理を並列列処理理することが可能 価格体系 (http://aws.amazon.com/jp/kinesis/pricing/) Ø シャード数 Ø Put API コール数 51 Loose Coupling
Graceful Failure 安全に落落とすための戦略略 Ø リソースの停 止 削除 障害時のクライアントや他のリソースへの影響を最 小限にするように設定しておく Graceful Failure の例例 Ø ELB Connection Draining 52 新規割り振りは中 止して 処理理中のリクエストは終わるまで 一定期間待つ Ø Route 53 による DNS Failover 障害発 生時は CloudFront + S3 で構築した Sorry Site へ誘導 Ø 再試 行行処理理の実装 失敗した場合にはリトライで対応 Loose Coupling
サーバではなく サービスの利利 用 Services, Not Servers
サーバではなく サービスの利利 用 マネージドサービスの利利 用によって得られるメリット Ø コア業務 アプリケーション部分への集中 Ø 高可 用性 Ø 運 用負荷軽減 Ø 自動スケール ( サイジング不不要 ) マネージドサービスの活 用により Serverless での構築も可能 Ø AWS 上でのサーバーレスアーキテクチャ 入 門 http://www.slideshare.net/amazonwebservicesjapan/aws- black- belt- online- seminar- 2016- aws 54 Services, Not Servers
責任共有モデルから 見見るマネージドサービスの管理理負荷 責任共有モデルから 見見るサービス区分 Ø 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 詳細 :http://media.amazonwebservices.com/jp/wp/aws_ Security_ Best_ Practices.pdf Services, Not Servers
セキュリティ責任共有モデル (Infrastructure Services) お客様に よる管理理 AWS が 管理理 クライアント側のデータ暗号化とデータの整合性認証 基盤サービス コンピューティング ストレージ データベース ネットワーク AWS グローバル インフラストラクチャ 顧客データ サーバ側の暗号化 ( ファイルシステムおよびデータ ) プラットフォーム アプリケーション オペレーティングシステム ネットワーク構成 アベイラビリティーゾーン リージョン NW トラフィックの保護 ( 暗号化 / 整合性 / アイデンティティ ) ファイアウォール構成 エッジロケーション アイデンティティ アクセス管理理 AWS IAM 凡例例 56 お客様が担当する範囲 AWS が担当する範囲 Services, Not Servers
セキュリティ責任共有モデル (Container Services) お客様に よる管理理 クライアント側のデータ暗号化とデータの整合性認証 顧客データ サーバ側の暗号化 ( ファイルシステムおよびデータ ) プラットフォーム アプリケーション NW トラフィックの保護 ( 暗号化 / 整合性 / アイデンティティ ) ファイアウォール構成 アイデンティティ アクセス管理理 AWS が 管理理 基盤サービス コンピューティング ストレージ データベース ネットワーク AWS グローバル インフラストラクチャ オペレーティングシステム ネットワーク構成 アベイラビリティーゾーン リージョン エッジロケーション AWS IAM 凡例例 お客様が担当する範囲 AWS が担当する範囲 57 Services, Not Servers
セキュリティ責任共有モデル (Abstracted Services) お客様に よる管理理 クライアント側のデータ暗号化とデータの整合性認証 顧客データ サーバ側の暗号化 ( ファイルシステムおよびデータ ) NW トラフィックの保護 ( 暗号化 / 整合性 / アイデンティティ ) アイデンティティ アクセス管理理 プラットフォーム アプリケーション ファイアウォール構成 AWS が 管理理 基盤サービス コンピューティング ストレージ データベース ネットワーク AWS グローバル インフラストラクチャ オペレーティングシステム ネットワーク構成 アベイラビリティーゾーン リージョン エッジロケーション AWS IAM 凡例例 お客様が担当する範囲 AWS が担当する範囲 オプション機能として 提供されるもの 58 Services, Not Servers
AWS では多くのサーバーレスオプションを 用意 ストレージ ネットワーク データベース コンピューティング セキュリティ メッセージングとキュー コンテンツ配信 ユーザー管理理 モニタリングとログ記録 機械学習 ゲートウェイ ストリーミング分析 IoT 59 Services, Not Servers
データベースの使い分け Database
データベースの使い分け 万能なデータベース ストレージは存在しない データストアの特性 ( 得意不不得意 ) に応じた使い分け 低レイテンシ インメモリ NoSQL 3 拠点間での レプリケーション SSD に永続化 Amazon ElastiCache Amazon DynamoDB トランザクション処理理 汎 用 用途 SQL 集計 分析処理理 大容量量データ DWH Amazon RDS Amazon Redshift 61 Database
単 一障害点の排除 Removing Single Points of Failure
単 一障害点の排除 障害に備えておくことで その影響を極 小化 Ø 下記のようにあらかじめ冗 長化をしておくなどの準備が重要 もし この 1 台が落落ちても システムの全停 止にはつながらない Auto Scaling Group アベイラビリティーゾーン アベイラビリティーゾーン 63 Removing Single Points of Failure
単 一障害点の排除 単 一障害点排除のためのポイント Ø 冗 長化 Ø 障害検知 Ø 堅牢牢なデータストレージ Ø Multi- AZ の利利 用 Ø 疎結合な構成による障害分離離 詳細 :https://d0.awsstatic.com/whitepapers/aws- building- fault- tolerant- applications.pdf 64 Removing Single Points of Failure
コストの最適化 Optimize for Cost
コストの最適化 単に既存システムをクラウドに移 行行するだけでも 初期投資を減少させ AWS の規模の経済の恩恵を享受可能 クラウド環境の特性を活かすことにより さらなるコスト最適化が可能 Ø 適切切なサイジング Ø 伸縮 自在性 Ø 適切切な購 入オプションの利利 用 66 Optimize for Cost
適切切なサイジング オーバープロビジョニングの回避 Ø AWS のリソースはいつでも増減可能 継続的な改善 Ø 適切切なインスタンスタイプを 見見極めるために常に監視 Amazon CloudWatch によるリソース監視 AWS Trusted Advisor で使 用率率率に低いリソース 67 Amazon CloudWatch AWS Trusted Advisor Optimize for Cost
伸縮 自在性 水平スケーリングにより必要な時に必要なリソースを確保 需要によって 判断 マネージドサービスのキャパシティを利利 用 Ø ELB, CloudFront, Amazon SQS, AWS Lambda etc Ø キャパシティを簡単に設定できるリソースの活 用 Amazon DynamoDB, Amazon Kinesis Stream 68 Optimize for Cost
適切切な購 入オプションの利利 用 Amazon EC2 の購 入オプション Ø リザーブドインスタンス Ø スポットインスタンス Amazon S3 のストレージ価格 Ø スタンダードストレージ Ø 標準 低頻度度アクセスストレージ Ø 低冗 長化ストレージ その他のサービスの購 入オプション Ø CloudFront のリザーブドキャパシティ Ø DynamoDB のリザーブドキャパシティ 69 Optimize for Cost
70 適切切な購 入オプションの利利 用 Amazon EC2 の購 入オプション Ø リザーブドインスタンス Ø スポットインスタンス Amazon S3 のストレージ価格 10 月のオンラインセミナーもチェック! Ø スタンダードストレージ AWS のコスト削減オプション Ø 標準 低頻度度アクセスストレージ https://connect.awswebcasts.com/blackbelt- cost- reduction/event/event_ info.html Ø 低冗 長化ストレージ その他のサービスの購 入オプション Ø CloudFront のリザーブドキャパシティ Ø DynamoDB のリザーブドキャパシティ Optimize for Cost
キャッシュの利利 用 Caching
キャッシュの利利 用 繰り返し利利 用されるデータをキャッシュ Ø 性能向上 Ø コスト節約 リクエスト 配信 Amazon CloudFront コンテンツ取得 オリジンサーバ 台数の削減 リクエスト クライアント キャッシュから配信 レスポンス向上 CDN キャッシュ 負荷軽減 オリジンサーバ 72 Caching
Amazon ElastiCache による Application Data Caching フルマネージドキャッシュサービス 特徴 (https://aws.amazon.com/jp/elasticache/) Ø フルマネージド環境で Memcached / Redis が利利 用可能 Ø Redis は Multi- AZ 配置することで可 用性向上 Ø 一部パラメータ以外はアプリケーション特性に応じて変更更可能 Ø フェイルオーバーやパッチの適 用 バックアップ (Redis) も 自動で 行行われる Ø Memcached 用の Auto Discovery 対応 Client Library も提供中 73 価格体系 (https://aws.amazon.com/jp/elasticache/pricing/) Ø インスタンスタイプに応じて Ø Redis を利利 用しバックアップを有効にした場合はバックアップストレージの利利 用量量に応じて Caching
Amazon CloudFront による Edge Caching マネージド CDN(Contents Delivery Network) サービス 配信 Amazon CloudFront オフロード 特徴 (http://aws.amazon.com/jp/cloudfront/) Ø 簡単にサイトの 高速化が実現できると共に サーバの負荷も軽減 Ø 様々な規模のアクセスを処理理することが可能 Ø 世界 53 箇所のエッジロケーション クライアント レスポンス向上 キャッシュ 負荷軽減 Web サーバ 価格体系 (http://aws.amazon.com/jp/cloudfront/pricing/) Ø データ転送量量 (OUT) Ø HTTP/HTTPSリクエスト数 Ø ( 利利 用する場合 )SSL 独 自証明書など 74 Caching
セキュリティ Security
セキュリティ すべてのレイヤーでセキュリティを確保 Ø 一箇所でもセキュリティホールがあれば そこを突かれてしまう セキュリティ確保のためのポイント Ø AWS の機能の活 用 Ø AWS へセキュリティの担保をオフロード Ø 最 小権限の原則 Ø Security as Code Ø リアルタイム監査 詳細 :http://www.slideshare.net/amazonwebservicesjapan/awswebinar- aws- 56260969 76 Security
すべてのレイヤーでセキュリティを確保 アクセス管理理 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 詳細 : http://www.slideshare.net/amazonwebservicesjapan/awswebinar- aws- 56260969 Security
AWS の機能の活 用 78 AWS が提供する便便利利なセキュリティ機能を活 用することでよりシンプルにセキュリティ確保が可能に AWS が提供するセキュリティ機能活 用の例例 Ø AWS IAM による権限制御 Ø セキュリティグループによるアクセスコントロール Ø AWS WAF による DDoS 緩和 Ø AWS CloudTrail による監査ログ取得 Ø AWS KMS による暗号化鍵管理理 Ø etc Security
AWS へセキュリティの担保をオフロード マネージドサービスの活 用により AWS がセキュリティ管理理を 行行うレイヤーを広くすることが可能 サーバではなく サービスの利利 用 で 示したセキュリティ責任共有モデルの図を参照 79 Security
AWS IAM を活 用した 最 小権限の原則 順守 AWS サービスおよびリソースへのアクセスを安全にコントロール 特徴 (http://aws.amazon.com/jp/iam/) Ø AWS リソースへのきめ細かなアクセス制御 Ø 認証情報の利利 用状況を 一 目で把握できるレポート機能 Ø 社内ディレクトリとの統合も可能 Ø ウェブ ID プロバイダーを使った モバイルアプリケーションへのアクセスコントロールの管理理 Ø 権限の 高いユーザーに対する多要素認証の利利 用 ( Multi- Factor Authentication) 価格体系 (http://aws.amazon.com/jp/iam/pricing/) Ø IAM の利利 用 自体は全て無料料 多様な MFA デバイスをサポート 80 Security
Security as Code AWS はプログロマブル セキュリティの Golden Environment をコード化し 適切切なセキュリティ設定がされた環境の配布を容易易に Ø AWS CloudFormation Ø AWS Service Catalog 81 Security
リアルタイム監査 継続的にコンプライアンスのための監視を実施 Ø AWS Config Ø Amazon Inspector Ø AWS Trusted Advisor AWS 環境の操作ログの取得 Ø AWS CloudTrail アプリケーションログの収集 Ø Amazon CloudWatch Logs 82 Security
Agenda はじめに The Cloud Computing Difference 設計におけるベストプラクティス まとめ
84 まとめ (10 の設計プリンシプル ) スケーラビリティ 固定資産から可処分資産へ 自動化 疎結合 サーバではなく サービスの利利 用 ( マネージドサービスの活 用 ) データベースの使い分け 単 一障害点の排除 コストの最適化 キャッシュの利利 用 セキュリティ Architecting for The Cloud: AWS Best Practices https://d0.awsstatic.com/whitepapers/aws_ Cloud_ Best_ Practices.pdf
参考資料料 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
Webinar 資料料の配置場所 AWS クラウドサービス活 用資料料集 Ø http://aws.amazon.com/jp/aws- jp- introduction/ AWS Solutions Architect ブログ Ø 最新の情報 セミナー中の Q&A 等が掲載されています Ø http://aws.typepad.com/sajp/ 86
公式 Twitter/Facebook AWS の最新情報をお届けします @awscloud_ jp 検索索 もしくは http://on.fb.me/1vr8ywm 最新技術情報 イベント情報 お役 立立ち情報 お得なキャンペーン情報などを 日々更更新しています! 87
AWS の導 入 お問い合わせのご相談 AWS クラウド導 入に関するご質問 お 見見積り 資料料請求をご希望のお客様は 以下のリンクよりお気軽にご相談ください https://aws.amazon.com/jp/contact- us/aws- sales/ 88 AWS 問い合わせ で検索索してください