1
【AWS Black Belt Online Seminar】
失敗例を成功に変える
AWSアンチパターン
2016/6/14 アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト シニアマネージャー 荒木靖宏自己紹介
• 名前 – 荒木 靖宏 • 所属 – アマゾンウェブサービスジャパン株式会社 – 技術本部レディネスソリューション部 シニアマネージャ プリンシパルソリューションアーキテクト • 好きなAWSサービス– Amazon Virtual Private Cloud – AWS Direct Connect
AWSクラウドデザインパターンとは...
• AWSクラウドを使ったシステムアーキテクチャ設計を 行う際に発生する、典型的な問題とそれに対する解決 策・設計方法を、分かりやすく分類して、ノウハウとし て利用できるように整理したもの。 4うまく組み合わせると・・
• ピーク対応が楽
• セキュアなシステ
ム構築
• 安価に世界展開
• 障害にも強いシス
テム設計
これまで、数多くのAWS成功例がうまれていっ
た。。
その成功例は「パターン」として受け継がれ。。
そして、それらは時に「秘伝のたれ」「さわって
はいけないもの」とされてきた。。
7アンチパターン
• 失敗に陥るパターンを類型化し、事例の早期発
見と対応策に関しての提案を目的とする
• 動作やプロセス、構造について、当初は妥当で
あったのに、最終的に悪い結果が繰り返される
パターン
• リファクタリングするための方法が存在するパ
ターン
8適用例：DBの使い分け
• 状況
– パフォーマンスが高いDBと聞いて、並列度の高い SQLアクセス用途（OLTP）にRedShiftを採用• 症状
– 「パフォーマンスが悪い」• 解決法
– DBの特性を理解する 9データ・ストアの特性に応じた使い分け
Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon Redshift SQL NoSQL • 低レンテンシ • インメモリ • 3拠点間での レプリケーション • SSDに永続化 • トランザク ション処理 • 汎用用途 • 集計・分析処理 • 大容量データ • DWHRedshiftが向く用途
• 特化型のデータベースのため、適した用途に使うことでパ フォーマンスを発揮 • Redshiftに向くワークロード – 巨大なデータ・セット（数百GB～ペタバイト） – １つ１つのSQLが複雑だが、同時実行SQLは少ない – データの更新は一括導入 • ユースケース – データウェアハウス（DWH） – ユーザがクエリーを作成する（自由クエリー）（BI等）Redshiftの特徴を生かせないユースケース
• SQLの並列実行数が多い（※同時接続数ではなく同時実行数）
– RDS（MySQL ,PostgreSQL, Oracle, SQL Server)を検討
• 極めて短いレーテンシが必要なケース – ElastiCache (インメモリDB)やRDSを検討 • ランダム、かつパラレルな更新アクセス – RDSもしくはDynamoDB (NoSQL)を検討 • 巨大なデータを格納するが集計等はしない – DynamoDBや大きいインスタンスのRDSを検討
適用例：ストレージの使い分け
• 状況
– 「ストレージ代込」でEC2が使えると聞いて、イン スタンスストアにシステム構築• 症状
– データの消失、容量不足• 解決法
– ストレージの特性を理解する 13インスタンスストアとEBS
• インスタンスタイプに応じて、追加コスト無しで揮発性のイン スタンスストアが利用できる • 実体はEC2の物理ホストのローカルディスク。Stop/Startによ り仮想マシンが別ホストに移動するとデータが消去される • アプリケーションが利用する一時的なデータの置き場所や、分 散ファイルシステムのストレージとして活用する • EBSは永続化ストレージなので、OSの領域やDBのデータなど永 続化が必要なデータの置き場所としてはEBSを利用するEBSとインスタンスストアの利用ケース
OSブートディスク としての利用 D: C: EBS EC2 EBS Windows データ格納ディスク としての利用 Instance Store E: データ計算用など 一時的な利用 データ ファイル システム データ 一時 データ適用例：EBSの使い分け
• 状況
– 旧世代のEBSにシステム構築• 症状
– 速度（IOPS, スループット）に不満• 解決策
– EBSそれぞれの特性を理解する 1617 • ユースケースに応じて性能やコストが異なる5 種類のボリュームタイプから選択できる – 汎用SSD(General Purpose(SSD)) – プロビジョンドIOPS(SSD) – スループット最適化HDD – コールドHDD – マグネティック(Magnetic) • Snapshotを経由することでボリュームタイプ や容量を変更可能
EBSのボリュームタイプ
18
EBSのボリュームタイプの整理(SSDタイプ)
ボリュームタイプ 汎用SSD(gp2)
- General Purpose SSD プロビジョンドIOPS(io1)- Provisioned IOPS(SSD)
ユースケース • システムブートボリューム • 仮想デスクトップ • 小～中規模のデータベース • 開発環境や検証環境用 • 汎用SSDでは処理しきれない高いIO性能 を要求するアプリケーション • 10,000IOPSや160MB/sを超える性能を 要するワークロード • 大規模なデータベース ボリュームサイズ • 1GBから16TBまで • 4GBから16TBまで IOPS • 1GBあたり3IOPSのベースラインパ フォーマンス • ベースラインパフォーマンスが 3,000IOPS以下の場合、3,000IOPSま でバーストが可能 • 最低100IOPS、最大10,000IOPS • 必要なIOPS値を指定可能 • 容量(GB)あたり30IOPSを指定できる • 最大20,000IOPS スループット • 最低128MB/秒(170GB以下)から 最大160MB/秒(214GB以上)まで • 最大320MB/秒(1280IOPS以上のとき）※1IOPSあたり256KB/sを利用可能
19
EBSのボリュームタイプの整理(HDDタイプ)
ボリュームタイプ スループット最適化HDD(st1)
- Throughput Optimized HDD コールドHDD(sc1)- ColdHDD
ユースケース • EMR • データウェアハウス • 大規模なETL処理 • 大規模なログ分析 ※起動ボリュームには利用できない • ログデータ保管 • バックアップ • アーカイブ ※起動ボリュームには利用できない ボリュームサイズ • 500GBから16TBまで • 500GBから16TBまで
IOPS • 最大500IOPS • 最大250IOPS
スループット • ベース値：1TBあたり40MB/s • バースト値：1TBあたり250MB/s • バーストクレジット上限：1TB/1TB • 最大500MB/s • ベース値：1TBあたり12MB/s • バースト値：1TBあたり80MB/s • バーストクレジット上限：1TB/1TB • 最大250MB/s
20
おぼえていただきたい、
21
インフラ塩漬けアンチパターン
ノールック明細アンチパターン
インフラ塩漬けアンチパターン
AWSのイノベーションの歩 み
AWS has been continually expanding its services to support virtually any cloud workload, and it now has more than 60 services that range from compute, storage, networking, database, analytics, application services, deployment, management and mobile.
2009
Amazon RDS Amazon VPC AWS Auto Scaling AWS Elastic Load Balancing 2010 Amazon SNS AWS Identity & Access Management Amazon Route 53 2011 Amazon ElastiCache Amazon SES AWS CloudFormation AWS Direct Connect AWS Elastic Beanstalk GovCloud 2012 Amazon SWF Amazon Redshift Amazon Glacier Amazon Dynamo DB Amazon CloudSearch AWS Storage Gateway AWS Data Pipeline 2013 Amazon CloudTrail Amazon CloudHSM Amazon WorkSpaces Amazon Kinesis Amazon Elastic Transcoder Amazon AppStream AWS OpsWorks 2014 AWS KMS Amazon Config Amazon Cognito Amazon Mobile Analytics Amazon EC2 Container Service Amazon RDS for Aurora Amazon Lambda Amazon WorkDocs AWS Directory Service AWS CodeCommit AWS CodePipeline 2015 Amazon EFS Amazon API Gateway
Amazon WorkMail Amazon Machine Learning AWS Device Farm AWS WAF Amazon Elasticsearch Service Amazon QuickSight AWS Import/Export Snowball
Amazon Kinesis Firehose Amazon RDS for MariaDB Amazon Inspector AWS Database Migration Service
AWS IoT
Amazon EC2 Container Registry
Amazon Kinesis Analytics AWS Mobile Hub
* As of 8 Oct 15
AWS EMR
Amazon CloudWatch
Amazon FPS AWS Import/Export
Trusted Advisor AWS Service Catalog
AWS CodeDeploy
Amazon CloudWatch Logs
82
159
280
516
インフラ塩漬けアンチパターン
• 原因
– 構築した当初のままインフラの見直しをしない• 症状
– 実際の利用にくらべてキャパシティの過不足を放置 したまま利用している – 一時凌ぎで選んだサービスをそのまま使い続けてい る 24インフラ塩漬けアンチパターン
• 解決法
– サービスは四半期に一度は見直す
– 新サービスや新機能が助けになることが
サービスアップデートにより
塗り替えたパターンの例
• Managed NATが塗り替えたもの
– HA NAT
– Auto Scaling NAT
• VPC endpoint for S3が塗り替えたもの
– HA EC2 proxy for S3
• WAFが塗り替えたもの
Availability Zone A Private Subnet Availability Zone B Private Subnet Internet Amazon S3 DynamoDB AWS Region
Public Subnet NATPublic Subnet
• NATインスタンスに オートスケールを設 定 （min=1,max=1) し、AZ毎に1NAT • プライベートサブ ネットのルートテー ブルは同じAZのNAT にむける HA NAT NAT
Auto Scale NAT
• AZ毎にHA NATを配置する • スケールアップ！ • ネットワーク関連メトリクスを見る • プロトコル別アプリケーションプロキシも有効 m1.small Low m1.large Moderate m1.xlarge, c1.xlarge High t1.micro Very LowHA EC2 Proxy for S3
• ELB＋Proxy+AutoScalingでの実装
ELB sandwich for WAF appliance
• Auto scaleに対応していないWAFアプライアン
スをELBで挟んで機能を補う
31 Auto Scaling group WAFアプライアンス
2015年以降の新サービスにおける
アンチパターンの紹介
Amazon API Gateway
• 特徴 (http://aws.amazon.com/jp/lambda/) – OS、キャパシティ等インフラの管理不要 – バックエンドとしてLambda、既存Webシス テムを利用可能 – スロットリング/キャッシュ • 価格体系 (http://aws.amazon.com/jp/lambda/pricing/) – 呼び出し回数とキャッシュ容量 – 100万回の呼び出しにつき$3.5 – キャッシュ容量に応じて$0.02/時～$3.8/時 Web APIの作成・保護・運用と公開を簡単に Mobile Apps Websites Services API Gateway AWS Lambda functions AWS API Gateway Cache Endpoints on Amazon EC2 / Amazon Elastic BeanstalkAny other publicly accessible endpoint
Amazon CloudWatch
同期API Gatewayアンチパターン
• 原因
– API Gatewayを「同期」サービスとして使う• 症状
– APIGWがタイムアウトしてしまう – APIGWの同時実行数が足りない – APIGWの価格が高い 34同期API Gatewayアンチパターン
• 解決法
– APIの非同期化。「実施のオーダー」と「状態の確 認」で構成する• 留意点
– APIGW→Lambda→RDS(VPC)のようなレイテンシ が大きく変化するケースを避ける。 – Javaを使う場合さらに注意 35AWS IoT
• 特徴 (https://aws.amazon.com/jp/iot/) – デバイスとクラウドの双方向コミュニケーション – HTTP、MQTT、Websocketに対応 – SQLベースのルールとアクション定義 – AWSサービスとのシームレスな連携 – デバイス向けのSDK • 価格体系 (https://aws.amazon.com/jp/iot/pricing/) – 100万メッセージあたり$8(日本リージョン) – 無料利用枠利用は25万メッセージ/月を(1年間) 簡単で安全なクラウドへのデバイス接続サービス 様々な産業での利用 アーキテクチャ図NOシャドウアンチパターン
• 原因
– デバイスのリモート制御をMQTTトピックだけで行う• 症状
– AWS IoTでデバイスへのコマンドが到達しない 37NOシャドウアンチパターン
• 解決法
– MQTTトピックだけではRetainが効かないためシャ ドウを利用するのがベスト• 留意点
38ノールック明細アンチパターン
ノールック明細アンチパターン
• 原因
– 月末の料金請求しかないと思っている• 症状
– 支払い周期のずれ – クレジットカード与信額のつかいきり 40ノールック明細アンチパターン
• 解決法
– 「AWSサポート新規契約」「RI購入」の際に請求書 がわかれる – RI購入は契約時の購入費用分のみ / サポート契約は 初月分のみ請求書が分かれる – Consolidated Billing 使用の場合、子アカウントが RIを購入しても親アカウント宛に請求書が届くこと になるので注意 41机上の空論アンチパターン
机上の空論アンチパターン
• 原因
– サーバ発注、システムデプロイ、納品の硬直した ループにはまっている• 症状
– 動作確認をしない – 事前のキャパシティプランニングに時間をかけすぎ る 43机上の空論アンチパターン
• 解決法
– ともかく小さく試してみること
アンチパターンまとめ
• アンチパターンはリファクタリング方法が存在
する
• 3つの避けるべきメタアンチパターン
– インフラ塩漬けアンチパターン – ノールック明細アンチパターン – 机上の空論アンチパターン 45Webでノウハウを共有
WIKI http://aws.clouddesignpattern.org/index.php FACEBOOK https://www.facebook.com/awscdp 46書籍でノウハウを共有
Amazon Web Services クラウドデザインパターン 設計ガイド
48
49 詳しくは、http://aws.amazon.com/training をご覧ください メリット • AWS について実習や実践練習を通じ て学習できる • AWS を熟知したエキスパートから直 接 AWS の機能について学び、疑問の 答えを得られる • 自信をもって IT ソリューションに関 する決定を下せるようになる 提供方法 e ラーニングや動画 セルフペースラボ クラスルーム トレーニング AWSトレーニングでは様々な学習方法をご提供しています
50
公式Twitter/Facebook
AWSの最新情報をお届けします
@awscloud_jp 検索 最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを 日々更新しています！ もしくは http://on.fb.me/1vR8yWm51
![¯]^°uv amp;#'&](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==)