![35EC2 インスタンス購入オプション
●[オンデマンドインスタンス] – 起動するインスタンスに対して秒単位でお支払いいただきます。
●[リザーブドインスタンス] – 1～3 年の期間で、常に使用できるインスタンスを大幅な割引で購入し
ます。
●スケジュールされたインスタンス – 1 年の期間、指定された定期的なスケジュールで常に使用で
きるインスタンスを購入します。
●スポットインスタンス – 未使用の EC2 インスタンスをリクエストして、Amazon EC2 コストを大幅に
削減します。
●Dedicated Hosts – 完全にインスタンスの実行専用の物理ホストに対してお支払いいただき、既存のソケ
ット単位、コア単位、または VM 単位のソフトウェアライセンスを持ち込んでコストを削減できます。
●ハードウェア専有インスタンス – シングルテナントハードウェアで実行されるインスタンスに対
して、時間単位でお支払いいただきます。
●キャパシティーの予約 – 特定のアベイラビリティーゾーンの EC2 インスタンスに対して任意の期間
キャパシティーを予約します。](https://image.slidesharecdn.com/20190905awswell-architectedframeworkseminarcostoptimization-190905043143/85/20190905-aws-well-architected_framework_seminar_costoptimization-36-320.jpg)
20190905 aws well-architected_framework_seminar_costoptimization
- 1. コスト最適化 編
- 2. 始める前に AWS Well-Architected は長いので本資料ではところどころで W-A に略して表記します。 ご了承ください。
- 5. 4ポリシー コストにフォーカスしたポリシーを決定します。 プロジェクト毎 or システム毎に予算が決まっていると思います。 その予算を超えないような取り組みをします。 ✔ 開発環境は本番環境の 1/n のサイズにする ✔ 開発環境は t2/3系インスタンスを使用する ✔ 開発環境のサービス起動時間は平日日中帯に限定する ✔ 開発環境は北米リージョンを使用する (東京に比べ割安) ✔ 負荷試験など例外時には一時的にスケールアップを許可 ✔ 本番以外の環境(開発/ステージング)の利用期間を定める
- 6. 5サービス起動時間は平日日中帯に限定する 例) EC2の場合 ・東京リージョンで m5.xlarge (Linux) を 24時間 31日 稼働した場合 0.248USD * 24h * 31days = 184.512USD ・東京リージョンで m5.xlarge (Linux) を 10時間 22日 稼働した場合 0.248USD * 10h * 22days = 54.56USD
- 7. 6EC2インスタンスを定時起動停止する方法 ■ OpSwitch (クラスメソッドのサービス) AWSの定型作業スケジュール実行サービス。 ウェブ画面から簡単に設定を行うことが可能です。 https://opswitch.io/ ■ AWS Instance Scheduler AWS が提供しているテンプレートを実行すると EC2インスタンスの起動停止をスケジュールする機能が実装されます。 https://aws.amazon.com/jp/solutions/instance-scheduler/?trk=sl_card
- 14. 13IAMグループ例 Administrators 全ての操作が実行可能。 プロジェクトやシステムの責任者が持つ権限。 Developers EC2 インスタンスの起動停止、Lambda 関数のデプロイなど システム開発に必要な権限を付与。 Network Admin VPC 関連の操作権限を付与。 Database Admin RDS 関連の操作権限を付与。
- 15. 14 コストのモニタリング
- 16. 15コストのモニタリング コストをモニタリングします。 AWS 請求およびコスト管理コンソール でモニタリングしますが デフォルトでは root ユーザーのみアクセスとなっています。 IAM ユーザー/ロールによる請求情報へのアクセスを有効します。 https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/grantaccess.ht ml コストをモニタリングします。 AWS 請求およびコスト管理コンソール でモニタリングしますが デフォルトでは root ユーザーのみアクセスとなっています。 IAM ユーザー/ロールによる請求情報へのアクセスを有効します。 https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/grantaccess.ht ml
- 19. 18Cost Explorer Cost Explorer でコスト分析 今月初めから今日までのコスト 今月末の予測 コスト傾向 特定サービスでコスト増大など
- 20. 19Cost Explorer フィルターを駆使して独自の切り口でコスト分析 (フィルター例) リージョン サービス インスタンスタイプ コスト配分タグ (後術) 使用タイプ (データ転送、CloudWatch メトリックなど) etc…
- 22. 21コスト配分タグ リソースに付与するラベル タグでリソースを整理し コストの追跡を容易にします。 右図の例でいうと、 Widget2 というアプリケーションは 本番環境で $3.84 の料金が発生ということ がわかります。
- 23. 22AWS Budget 予算を計画し、発生コストと予算の比較や予測コストと予算の比較、 アラートの通知を行います ３タイプの予算を設定 ● コスト予算 指定した金額をモニター、しきい値を超えたらアラート ● 使用量予算 １つ以上のサービス使用量をモニター、アラート ● 予約予算 RI使用量をモニター、しきい値を下回ったらアラート
- 24. 23 コストの抑制
- 27. 26アイドル状態のインスタンスを検出 Trusted Advisor でアイドル状態のリソースを検出 → 必要がなければリソース削除
- 28. 27 リソースの検索
- 31. 30 コストの評価
- 32. 31コストの評価 コストの評価は利用料金だけではなくビジネス要件全体から判断。 • ビジネスKPI • アプリケーション機能 • 可用性、信頼性、ビジネス継続性 • 拡張性、パフォーマンス • 運用、保守 • セキュリティ
- 33. 32運用を重視してサービスを選ぶ 例えば Amazon RDS を使うとEC2にRDBMSをインストールする場合に 比べて運用コストが下がります。 以下がAWSの管理になり、これらにかかるコストが抑えられます。 ✔ 冗長構成 ✔ バックアップリストアの仕組み ✔ 製品パッチ管理 ✔ OS管理
- 34. 33コストを重視してサービスを選ぶ 現行 AWS 静的WebサイトをLinuxサーバーで運用 → S3 月に数十回しか実行しないバッチサーバー → Lambda バックアップサーバー → AWS Backup 監視サーバー → CloudWatch, Lambdaなど リレーショナルではないDB → DynamoDB 現行仮想サーバー/EC2で運用している機能もAWSサービスを使い コストを下げます。
- 35. 34 購入オプションを知る
- 36. 35EC2 インスタンス購入オプション ●[オンデマンドインスタンス] – 起動するインスタンスに対して秒単位でお支払いいただきます。 ●[リザーブドインスタンス] – 1～3 年の期間で、常に使用できるインスタンスを大幅な割引で購入し ます。 ●スケジュールされたインスタンス – 1 年の期間、指定された定期的なスケジュールで常に使用で きるインスタンスを購入します。 ●スポットインスタンス – 未使用の EC2 インスタンスをリクエストして、Amazon EC2 コストを大幅に 削減します。 ●Dedicated Hosts – 完全にインスタンスの実行専用の物理ホストに対してお支払いいただき、既存のソケ ット単位、コア単位、または VM 単位のソフトウェアライセンスを持ち込んでコストを削減できます。 ●ハードウェア専有インスタンス – シングルテナントハードウェアで実行されるインスタンスに対 して、時間単位でお支払いいただきます。 ●キャパシティーの予約 – 特定のアベイラビリティーゾーンの EC2 インスタンスに対して任意の期間 キャパシティーを予約します。
- 37. 36リザーブドインスタンスがあるサービス ● EC2 インスタンス ● RDS ● ElastiCache ● Redshift
- 38. リザーブドインスタンス割引例 支払い方法 前払い 毎月 実質時間単価 オンデマンドと比較 オンデマンド No Upfront 0 USD 126.29 USD 0.173 USD 30% 0.248 USD Partial Upfront 721 USD 59.86 USD 0.164 USD 34% All Upfront 1,412 USD 0 USD 0.161 USD 35% m5.xlarge スタンダード 1年 支払い方法 前払い 毎月 実質時間単価 オンデマンドと比較 オンデマンド No Upfront 0 USD 105.12 USD 0.144 USD 42% 0.248 USD Partial Upfront 1,750 USD 48.91 USD 0.134 USD 46% All Upfront 3,430 USD 0 USD 0.131 USD 47% スタンダード 3年
- 39. 38Reserved Instance Cost Explorer で Reserved Instance 購入のすすめ 推奨実施した場合の節約額 どの種類の Resered Instance を どれだけ購入すれば 推奨を表示。 それによって月額で どの程度削減見込みかも 表示。
- 40. 39 転送料金を知る
- 41. 40EC2 データ転送料金 From To 料金発生 インターネット EC2 しない EC2 インターネット する EC2 CloudFront しない EC2 別リージョンEC2など する EC2 同リージョン別AZ EC2など する ※双方向 EC2 VPCピアリング先 EC2など する ※双方向 EC2 同AZ EC2など しない EC2 同リージョン S3など しない EC2 同リージョン CLB/ALB しない 詳細は公式ドキュメントを参照 https://aws.amazon.com/jp/ec2/pricing/on-demand/ 料金が発生するパターンをおさえておきましょう。（サービスごと）
- 42. 41S3 データ転送料金 S3のWebサイトホスティング（デジタルコンテンツの配信） • ストレージ料金 • 10MB/Content × 約100,000 Contentと仮定 • $0.025 × 1024GB = $25.5 • リクエスト料金 • 10,000,000 GETと仮定 • $0.00037/k × 10,000k = $3.7 • データ転送料金 • 10MB × 10,000,000 GET = 100TB • $0.114/GB × 10TB + $0.089/GB × 30TB + $0.086/GB × 60TB = $9185.28 • 合計：$9214.48 Amazon S3 の料金 https://aws.amazon.com/jp/s3/pricing/
- 43. 42データ転送量の削減 ■ CloudFront 前ページのように S3 に静的コンテンツを配置するパターンで 大きな効果を発揮します。 ■ Multi AZ 構成 EC2、RDS マスター (Active) を同じ AZ に配置。 ■ ファイル圧縮 転送する前にファイル(ディレクトリ) を圧縮。
- 46. 45サイジング 現行 8 Cores Server 新サーバーも 8 Cores メトリクス (使用率) は？ 最大でも 30% 新サーバーは 4 Cores でスタート
- 47. 46パフォーマンスメトリクスを取得 CloudWatchなどでパフォーマンスメトリクスを取得し 実際の負荷に合わせてインスタンスタイプをアップダウンさせます。 (例) ・CPU使用率が常時10%前後 → インスタンスタイプを下げる ・EBSボリューム → 活性拡張が可能なのでギリギリのサイズにする
- 51. 50需要のトレンド ご自身が管理しているシステムが需要のピークを迎えるのは いつでしょうか？ ✔ キャンペーン時 (SNS、メール、Web等) ✔ 季節 (レジャー、行事) ✔ 時間帯 (ユーザー行動特性により) ✔ 業務ごと (基幹システムなら夜間バッチ、月次バッチなど)
- 52. 51スケーリング AWS の長所を活かしてスケールアップ/ダウン、イン/アウトします。 需要ピークに合わせてリソースを増減させ利用料金を節約します。 手動 • インスタンスタイプの変更（スケールアップ／ダウン） • EC2インスタンスをELBに登録／登録解除 • AutoScaling Desired Countを手動で変更 自動 • AutoScalingによる自動スケーリング （スケジュール／リソースベース）
- 53. 52EC2 Auto Scaling アプリケーションの負荷に応じて自動的に EC2 インスタンスを 増減させるサービスです。 指定した最小数と最大数の間でインスタンス数が調整されます。
- 54. 53 新サービスを評価
- 55. 54増え続ける AWS サービス
- 57. アップデートでコストが下がった例 (2018年12月3日のアップデート) 汎用 SSD (gp2) ボリュームのパフォーマンスが 60% 向上し、10,000 IOPS から 16,000 IOPS に、ボリュームあたりのスループットが 160 MB/秒か ら 250 MB/秒になりました。 夜間データ連携時間帯にスループットが 160MB/秒で張り付いて ボトルネックになっていたのでプロビジョンド IOPS を検討、 しかし、上記アップデートでボトルネックが解消され 高価なプロビジョンド IOPS への変更は不要になった。
- 58. 57評価方法 1. AWS 最新リリースを情報収集、理解 2. 現行アーキテクチャの改善になるか？ を検討
- 59. 58情報収集 ■ AWS Blog & Podcast Category=news https://aws.amazon.com/blogs/?awsf.blog-master-category=category%23news ■ AWS Blackbelt https://aws.amazon.com/jp/aws-jp-introduction/ ■ Twitter awscloud_jp https://twitter.com/awscloud_jp ■ Release Note https://aws.amazon.com/jp/releasenotes/ ■ Developers.IO https://dev.classmethod.jp/