AWSにおけるコスト最適化
AWSにおけるコスト最適化の考え方
クラウドにおけるコスト最適化の重要性
-
課金内容のうち4-5割は不用意に使われているというリサーチがある
- 使われていないのに起動している
- オーバースペック
- 割引オプション有効活用できていない
AWSにおけるコスト最適化の指針
5つの設計原則
-
必要なリソースを必要な時に必要な分だけ利用する
- スモールスタート
- 開発環境やテスト環境等を使用していない時間帯は仮想マシン停止
-
全体的なコスト効果を測定する
- ビジネス価値 per コスト を最大化
-
データセンター運用への投資を不要に
-
企業の競争力に直接影響しないことはAWSに丸投げ
- インフラ構築・運用とか
- ビジネス開発に集中できる
-
-
投資効果の要因分析
- ITリソースの使用量と、使った組織・チーム・プロジェクトのトレーサビリティ
-
マネージドサービス活用による所有コストの削減
- サーバー機器の保有や拡張等の所有コスト
コスト最適化の4つのベストプラクティス
-
コスト効果が高いリソースの選定
- 適切なサイジングの割り当て
- 割引オプションの利用
- マネージドサービスの利用
-
ITリソースの需要とAWSサービスの適切な供給によるコスト最適化
- Auto Scalingなどの活用
-
全体的なコスト管理
- コストの深掘り調査
- コスト超過時の通知
-
継続的なコスト最適化の活動
- 継続的な監視・改善
- 測定基準
コスト効果が高いリソースの選定
AWSサービスの購入オプション
| 購入オプション | 特徴 | サービス代表例 |
|---|---|---|
| オンデマンドインスタンス | 初期費用なし、従量 | EC2, RDS, Redshift |
| リザーブドインスタンス | 長期利用権(1,3年)を安く買う(~75%オフ) | EC2, RDS, Redshift |
| スポットインスタンス | 余っているリソースに入札(~90%オフ)、強制終了あり | EC2, EMR |
-
オンデマンドインスタンス
- 利用期間制約なし
-
従量課金の課金単位はサービスごとに異なる
- EC2は秒単位、とか
-
ユースケース
-
常時は起動しないやつ
- 開発環境
- テスト環境
- キャンペーン時の一時的なWebサイト
-
-
リザーブドインスタンス
-
利用期間
- 1年
- 3年
-
支払い方法
-
全額前払い
- キャンセル時払い戻しなし
- 一部前払い
- 前払いなし
-
-
タイプ (提供クラス)
-
Standard
- インスタンスサイズ等、一部属性のみ変更可
- インスタンスファミリー変更不可
-
Convertible
-
インスタンスファミリー等異なる、別のコンバーティブルRIに交換可能
- 交換先が同等以上の価格であること
- Standardよりも割引率低い
-
-
-
ユースケース
-
最低限の台数が必要なサーバー
- Webサーバー
-
常時起動しておく必要のあるサーバー
- DBサーバー
-
-
-
スポットインスタンス
- 最も割引率の高い購入オプション
- スポット価格に対して入札
- スポット価格を上回っていればインスタンス起動
-
高騰して入札価格を上回るとインスタンス強制終了
- 2分間の警告期間がある
-
オプション
-
スポットブロック
- 最低限の起動時間保証(~6h)
- 処理途中における想定外の強制終了の回避
-
スポットフリート(スポット群)
- 性能キャパシティを指定しておく
- スポット価格が高騰して、指定したインスタンスが使用不可になったら、
性能キャパシティを満たす代替構成へのフォールバックを試みる
-
リソースの適切なサイジング
-
適切なインスタンスタイプの選定
-
インスタンスファミリー・世代
- t2とかそういうのの分類
-
インスタンスサイズ
- xlargeとかそういうの
-
| インスタンスファミリー | 種類 | 特徴 |
|---|---|---|
| 汎用 | T2,M4,M5 | 一般的なシステム用途、バランス型 |
| コンピューティング最適化 | C4,C5 | コスト効果の高いCPU処理特化 |
| メモリ最適化 | X1e, X1, R4 | 大容量メモリ特化 |
| 高速コンピューティング | P2, P3, G3, F1 | GPU, FPGA等高速処理特化 |
| ストレージ最適化 | H1, I3, D2 | 容量、I/Oスループット性能特化 |
| インスタンスサイズ | vCPU |
|---|---|
| … | 1 |
| large | 2 |
| xlarge | 4 |
| 2xlarge | 8 |
| 4xlarge | 16 |
-
適切なストレージ選定
-
オブジェクトストレージサービス
-
S3
-
各種ストレージクラス
- スタンダード
- 標準低頻度アクセス
- 低冗長化
- 1ゾーン低頻度アクセス
- Glacier
-
-
-
ブロックストレージサービス
-
EBS
- 汎用SSD(gp2)
- プロビジョンドIOPS(io1)
- スループット最適化HDD(st1)
- コールドHDD(sc1)
- マグネティック
- EFS
-
-
需要の変化に応じたITリソースの供給
- 従量課金
- あまり使われていないのにサービス利用し続けるのは無駄
ELBとAuto Scalingによる柔軟なリソース供給
既出
- 負荷をさばくために柔軟にリソース増減
- 同期的に処理することが前提にある
SQSやKinesisによるバッファリング
- 同期的に処理する必要が無い場合、負荷をバッファしておける
-
SQS: Simple Queue Service
- メッセージキュー
-
EC2からポーリングする
-
Short Polling
- キューが空のとき、Emptyメッセージを即レスポンス
- リクエスト単位で課金されるので、空振りが多いと無駄
-
Long Polling
-
キューが空のとき、指定の待ち時間だけメッセージ取得を待つ
- 1-20秒
-
-
可視性タイムアウト
-
ある受信者がメッセージを受信したら、
他の受信者からはそのメッセージを見えなくする(デフォルト30秒間)- 処理の重複を防ぐ
- 無駄なリクエストをなくす
-
スポットインスタンスとの組み合わせ
- メッセージを受信したスポットインスタンスが強制終了される
- 可視性タイムアウトが超過する
- 別のインスタンスがメッセージを受信して処理を再実行する
-
-
-
Kinesis
- ストリーミングデータの収集・処理・リアルタイム分析
- SQSとの違い: 複数のコンシューマが同時に同一のメッセージを取得・処理可能
-
3兄弟
-
Kinesis Data Streams
-
独自アプリケーションに流し込む
- on EMR
- on Lambda
- 「シャード」単位でデータ分割・並列処理
-
-
Kinesis Data Firehose
- アプリケーション不要
- S3, Redshift, ES: Elasticsearch Service に直接流し込める
-
Kinesis Data Analytics
- ストリーミングデータに対してSQL発行、リアルタイム分析
-
コストの管理
AWSにおけるコスト管理
Consolidated Billingによる支払い管理
-
一括請求
-
Payer Account (マスターアカウント)
- 一括請求される
-
Linked Account (メンバーアカウント)
- 請求を統合される
-
-
利点
- 支払い業務の効率化
- 使用状況の統合的な管理
- ボリュームディスカウント
AWS Cost and Usage Reportによる詳細レポート・分析
- リソース使用状況とコストのレポート
-
粒度
- 日次
- 1時間ごと
-
形式
- CSVでS3へ
- Redshiftに格納
- Amazon QuickSightで可視化
-
取得可能な情報
- bill/PayerAccountId
- product/ProductName
- product/region
- lineItem/UsageAmount
-
分析対象
- オンデマンドインスタンス
- リザーブドインスタンス
Cost Explorerによるコストの可視化と傾向分析
-
AWS Cost and Usage Reportのデータの可視化・検索
- 可視化
- 分析
- 予測
予算設定による利用超過の監視
- Billing and Cost Management Dashboardから予算作成可能
- 予算額の設定
-
通知の設定
-
トリガー
-
超過しそう
- パーセンテージ
><=
- 超過した
-
-
通知方法
- CloudWatchアラーム
- SNSトピック
- メール
-
Trusted Advisor によるコスト最適化
-
5項目
-
コスト最適化
-
例
- 使用率の低いEC2インスタンス
- EC2使用量に基づいたリザーブドインスタンスの最適数の推奨
- 関連付けられていないEIP
-
-
セキュリティ
-
例
- 開かれたポート
-
- 耐障害性
- パフォーマンス
-
サービスの制限
- 上限緩和とか
-