Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Well Architected Tool 使い方セミナー(コスト最適化編) ver.1.1

943 views

Published on

Well Architected Tool 使い方セミナー(コスト最適化編) ver.1.1
2019/2/19

Published in: Internet
  • Be the first to comment

Well Architected Tool 使い方セミナー(コスト最適化編) ver.1.1

  1. 1. Well-Architected Toolの使い方 (コスト最適化編) AWS事業本部 2019/2/19 Nobuhiro Nakayama 1
  2. 2. スライドは後で入手することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター音が出ないようにご配慮ください
  3. 3. 3はじめに この資料は、 「Well-Architected Tool の使い方セミナー」後半パートの資料です 前半ではWell-Architected Framework自体の概要を解説しています。 Well-Architected Frameworkについては以下の資料をご確認ください。 AWS Black Belt Online Seminar 2018 AWS Well-Architected Framework https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar- 2018-aws-wellarchitected-framework
  4. 4. 4目次 ✓ 一般的な設計の原則 ✓ Well-Architected Tool の使い方 ✓ コスト最適化に関する質問事項と改善方法 ✓ まとめ
  5. 5. 5 一般的な設計の原則 (Well-Architectedな設計を実現するために 意識するべきこと)
  6. 6. 6一般的な設計の原則? Well-Architected Frameworkは、5本の柱/46の質問を通して 設計がベストプラクティスに則っているかを確認するための考え方/プ ロセス • そもそも、「より良いアーキテクチャ」とは?
  7. 7. 7 質問に対する模範的な回答は いくつかの設計原則に則っている
  8. 8. 8一般的な設計の原則 ✓ 必要なキャパシティーを勘に頼らない ✓ 本番規模でシステムをテストする ✓ 自動化によってアーキテクチャ上の実験を容易にする ✓ 発展的なアーキテクチャを受け入れる ✓ データ計測に基づいてアーキテクチャを決定する ✓ 本番で想定されるトラブルをあらかじめテストし、対策する
  9. 9. 9必要なキャパシティーを勘に頼らない 課題 • 明確な根拠なく先行してハードウェアの調達を行った場合、無駄なリソースが 発生する場合がある(逆も然り) クラウドサービスを利用する場合 • 柔軟なキャパシティ変更が可能 • 変更の根拠になるメトリクスを容易に収集可能(事実に基づいた設計)
  10. 10. 10本番規模でシステムをテストする 課題 • テストのために本番環境と同等の環境を準備することが困難 • 不十分なテストしかしないままサービスをリリースし、直後に課題が顕在化 クラウドサービスを利用する場合 • テスト中のみリソースをプロビジョニング/テスト終了後に削除することが可 能 • インフラをコード化することで容易に複製可能
  11. 11. 11自動化によってアーキテクチャ上の実験を容易にする 課題 • 手作業による工数の増加、ミスによる手戻り • そもそも、本番環境を変更するリスクが高くて作業できない クラウドサービスを利用する場合 • 構成や複製を容易に自動化することが可能
  12. 12. 12発展的なアーキテクチャを受け入れる 課題 • ビジネス的な変化にインフラが追従できない (ビジネスの成長によるアクセス/データ量の増加、など) クラウドサービスを利用する場合 • 自動化や複製が容易であることによりテストがしやすい (=設計および構成変更のリスクを低減)
  13. 13. 13データ計測に基づいてアーキテクチャを決定する 課題 • 独自で監視システムを構築する必要がある クラウドサービスを利用する場合 • 各サービスで様々なメトリクスを取得可能 • 監視やロギングを行うサービスの提供
  14. 14. 14本番で想定されるトラブルをあらかじめテストし、対策する 課題 • 障害発生時のサービスへの影響を事前に確認することが困難 クラウドサービスを利用する場合 • システムの複製が容易(=破壊的なテストを気軽に実施することが可能) • テスト中のみリソースをプロビジョニングし、テスト終了後に削除することが 可能
  15. 15. 15一般的な設計の原則(再掲) ✓ 必要なキャパシティーを勘に頼らない ✓ 本番規模でシステムをテストする ✓ 自動化によってアーキテクチャ上の実験を容易にする ✓ 発展的なアーキテクチャを受け入れる ✓ データ計測に基づいてアーキテクチャを決定する ✓ 本番で想定されるトラブルをあらかじめテストし、対策する
  16. 16. 16 Well-Architected Toolの使い方
  17. 17. 17レビューの方法 1. AWSもしくはパートナーのソリューションアーキテクトと実施 • 質問に対する回答を事前に準備(可能な範囲で) • ソリューションアーキテクトと関係者でレビューを実施 • 顕在化した問題に対して、 改善策の策定(改善の対象にするかの判断も含む)と優先順位の設定を実施 2. Well-Architected tool を利用してセルフサービスで実施 • ホワイトペーパーを参照し、設計の一般原則やレビュープロセス等を確認 • セルフサービスで行う場合、レビューのファシリテーションが必要 • マネージメントコンソール上で質問に回答 • 顕在化した問題に対して、(以下同文)
  18. 18. 18Well-Architected Tool re:Invent 2018で新サービスとして発表 • Well-Architected Frameworkに基づくレビューをセルフサービスで実施でき るツール • 現時点(2019年2月19日)では英語のみ
  19. 19. 19ホワイトペーパー General Design Practices(設計の一般原則)と The Review Process(レビュープロセス、後述)は特に重要
  20. 20. 20日本語化について 現時点でW-A Tool日本語化の予定などは公開されておりません 「AWS クラウドサービス活用資料集」で質問を日本語化した資料が公開 AWS クラウドサービス活用資料集 https://aws.amazon.com/jp/aws-jp-introduction/ AWS Well-Architected Framework ヒアリングシート(日本語版) https://d1.awsstatic.com/webinars/jp/pdf/services/images/Well- Architected_2018Nov.c682850f634e788de4c112f0b782a8520bf35ac5.xlsx 日本語のホワイトペーパーはまだ最新化されていません(2018年6月版) https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well- Architected_Framework_2018_JA_final.pdf 最新の英語版は2018年11月版
  21. 21. 21
  22. 22. 22 Demo
  23. 23. 23マネージメントコンソールへログイン • バージニア北部、オハイオ、オレゴン、北アイルランドリージョンで利用できます • 東京リージョンのワークロードを評価できます(評価にあたりW-A Toolはリソースにアクセスしません)
  24. 24. 24ワークロードの定義
  25. 25. 25レビュー
  26. 26. 26レビュー “Question does not apply to this workload” ワークロードに適用できない質問をスキップ するときにチェック 例)「AWSサービスへのプログラムによるア クセスをどのように制御していますか?」→ プログラムによる制御をしていない “Notes - optional” 補足事項を記載 例)「RPO/RTOに関する要求レベルが低いた め、単一障害点の排除は付与」のように、ベ ストプラスティスに沿う必要が無い理由など を記載
  27. 27. 27レビュー 各選択肢の解説 (選択肢の意味や改善するために 何をすればいいかわからないときに参照)
  28. 28. 28レビュー リスクの概要 改善活動のステータス
  29. 29. 29レビュー どの柱に関する改善を優先するか (この下の改善項目の表示順に影響する) 改善すべき事項と改善のための参考情報
  30. 30. 30レビュー
  31. 31. 31マイルストーンの保存 現時点の回答状況をマイルストーンとして保存可能
  32. 32. 32改善とレビューを継続 ある程度改善活動が実施できたら、 再レビューを実施してどの程度リスクを緩和できたか確認 マイルストーン作成時の回答を参照可能 継続的な改善により、リスクを削減
  33. 33. 33改善とレビューを継続 複数のワークロードに対する評価を1カ所に集約 (どのワークロードから優先して改善するべきかを判断)
  34. 34. 34Well-Architected Tool 以下のリソース/機能をマネージメントコンソールで提供 • チェックリスト(質問)とその回答結果の保存/更新 • 組織内のリスク(複数のワークロード)や継続的な改善結果(マイルストーン)を可視化 • 改善案の提示 • 各種リソース(W-A Frameworkの解説ページや公式ドキュメント)へのリンク
  35. 35. 35レビュープロセス ステークホルダー全員がレビューに参加 CTO、アーキテクト、開発、運用、他 何か問題が見つかっても担当者を責めない 心理的安全性の確保、レビューは「監査」ではなく「話し合い」です 設計初期段階での実施を推奨 手戻りの回避、修正が困難な課題の発生を予防 最新情報の収集とそれを踏まえた継続的なレビュー AWSの新サービス/新機能の活用、ビジネス環境の変化への対応
  36. 36. 36レビュー時の留意点 全てのベストプラクティスに対応する必要はあるのか? • リスクや改善点を把握できることが重要 • ベストプラクティスを満たすべきかどうかは、ビジネス環境によって異なる (トレードオフ) レビューの実施を受け入れてもらえない可能性 • 「忙しい」、「機密情報を扱うので設計を共有できない」など • 『リスクを抱えたままでサービスを開始したいんですか?』
  37. 37. 37 コスト最適化に関する質問事項と改善方法
  38. 38. 38コスト最適化における設計原則 ✓ 消費モデルを導入する ✓ 全体的な効率を評価する ✓ データセンターの運用費を排除する ✓ 支出を分析し、帰属させる ✓ 所有コストを削減するためにマネージドサービスとアプリケーショ ンサービスを使用する
  39. 39. 39消費モデルを導入する 課題 • 開発/検証環境を用意したいが、十分な予算を確保できない クラウドサービスを利用する場合 • 必要な時間のみ起動して利用することが可能(時間課金) • スケールアップ/スケールダウンはいつでも可能(初期費用なし)
  40. 40. 40全体的な効率を評価する 課題 • コストの削減がビジネスの成長につながるのか クラウドサービスを利用する場合(に限らず実施すべき) • 収益とそのためのコストを把握する • コスト削減のために工数をかけても利益の改善が見込めないなら何もしないのもあり (塩漬けやサービスの縮小や廃止も)
  41. 41. 41データセンターの運用費を排除する 課題 • データセンターの運用に大きなコストが発生 (ラッキングやケーブリングなどの作業、電源供給、移動時間など) クラウドサービスを利用する場合 • 物理レイヤーの作業はほぼ不要 • 初期投資/コミットメントも不要 (コミットメントによるディスカウントは別途検討するべき)
  42. 42. 42支出を分析し、帰属させる 課題 • 厳密な経費の配賦やROI(投資収益率)の評価が困難 クラウドサービスを利用する場合 • コストを詳細に分類することが可能
  43. 43. 43マネージドサービスとアプリケーションサービスを使用する 課題 • 物理インフラやOS、ミドルウェアの導入/設定が必要 クラウドサービスを利用する場合 • マネージドサービスを利用することで、責任を負うべき範囲を削減
  44. 44. 44分類 現状の把握(1~3) コスト効率に優れたサービス/リソースの選択(4~7) 需要と供給の一致(8) 最適化の継続(9)
  45. 45. 451.使用量をどのように管理していますか?  社内のルールに基づいて、ポリシーを設定している (リソース使用ルールやコスト目標など)  AWSアカウントは、組織やプロジェクトに対応した構成にしている  グループとロールはポリシーに基づいた構成にしている (開発、テスト、本番など)  組織のポリシーと定義されたグループおよびロールに基づいたコストコントロー ルを実装している (IAMによる特定リソースやリージョンへのアクセス禁止制御など)  プロジェクトのライフサイクルを追跡している (不要なリソースや支払いが無いかなどの確認)
  46. 46. 461.使用量をどのように管理していますか?  社内のルールに基づいて、ポリシーを設定している (リソース使用ルールやコスト目標など)  AWSアカウントは、組織やプロジェクトに対応した構成にしている  グループとロールはポリシーに基づいた構成にしている (開発、テスト、本番など)  組織のポリシーと定義されたグループおよびロールに基づいたコストコントロー ルを実装している (IAMによる特定リソースやリージョンへのアクセス禁止制御など)  プロジェクトのライフサイクルを追跡している (不要なリソースや支払いが無いかなどの確認)
  47. 47. 47ポリシーの例 月額の利用料金をXX万円までに抑制する ワークロードを管理する部署を識別できるようにする 検証環境で利用してもよいインスタンスタイプはxx.largeまで (ただし、負荷テストの環境は例外で本番環境と同じにする) 検証環境はオレゴンリージョンを利用する (東京リージョンより安い) 開発環境は夜間自動停止/必要に応じて手動起動
  48. 48. 481.使用量をどのように管理していますか?  社内のルールに基づいて、ポリシーを設定している (リソース使用ルールやコスト目標など)  AWSアカウントは、組織やプロジェクトに対応した構成にしている  グループとロールはポリシーに基づいた構成にしている (開発、テスト、本番など)  組織のポリシーと定義されたグループおよびロールに基づいたコストコントロー ルを実装している (IAMによる特定リソースやリージョンへのアクセス禁止制御など)  プロジェクトのライフサイクルを追跡している (不要なリソースや支払いが無いかなどの確認)
  49. 49. 49マルチアカウント戦略 1つの組織で目的に応じて複数のAWSアカウントを利用するアプローチ メリット コストの分離(後述するタグだけでは厳密な識別が難しい場合がある) 権限の分離 デメリット ネットワークの複雑性 AWS Multiple Account Security Strategy https://aws.amazon.com/jp/answers/account-management/aws-multi-account-security-strategy/
  50. 50. 50マルチアカウントの実装例 AWS Landing Zone • 各アカウントで必要になる機能(ログやセキュリティ対策など)を共有アカウ ントに分離/実装 • アカウントの発行を仕組み化 • シングルサインオン • 最低限必要なセキュリティ/通知設定をアカウント発行時点で自動設定 AWS Answers | AWS Landing Zone https://aws.amazon.com/jp/answers/aws-landing-zone/
  51. 51. 51マルチアカウントの実装例 [REPEAT 1] Architecting Security & Governance across your AWS Landing Zone (SEC303-R1) - AWS re:Invent 2018 https://www.slideshare.net/AmazonWebServices/repeat-1-architecting-security-governance-across-your-aws-landing-zone-sec303r1-aws-reinvent-2018/59
  52. 52. 52Landing Zoneのマネージドサービス化 AWS re:Invent 2018 - Keynote with Andy Jassy https://www.youtube.com/watch?v=ZOIkOnW640A
  53. 53. 531.使用量をどのように管理していますか?  社内のルールに基づいて、ポリシーを設定している (リソース使用ルールやコスト目標など)  AWSアカウントは、組織やプロジェクトに対応した構成にしている  グループとロールはポリシーに基づいた構成にしている (開発、テスト、本番など)  組織のポリシーと定義されたグループおよびロールに基づいたコストコントロー ルを実装している (IAMによる特定リソースやリージョンへのアクセス禁止制御など)  プロジェクトのライフサイクルを追跡している (不要なリソースや支払いが無いかなどの確認)
  54. 54. 54IAM Policy IAM User / Role に対して付与する権限を定義 • Effect(許可/拒否) • Action(どの操作) • Resource(どのリソース) • Condition(条件)
  55. 55. 55IAM Policy 例:特定のインスタンスタイプのみ起動可能(EC2) { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*", "Condition": { "StringEquals": { "ec2:InstanceType": “t3.small" } } } ] }
  56. 56. 56IAM Policy 例:特定のリージョン以外での操作は不可 { "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "eu-central-1", "eu-west-1" ] } } }] }
  57. 57. 572.AWS使用量とコストをどのようにモニタリングしていますか?  AWSのコストと使用量レポートで詳細を確認している  組織と使用量の紐づけを行っている  組織ごとのメトリクスを確認している  タグ付け可能なリソースに組織や作業属性に基づいて定義したタグ付けをしてい る  AWS Cost ExplorerとAWS Budgetsを設定している  目標コストと使用状況についての分析を実施している  コストをダッシュボードなどで積極的に監視している  使用状況またはビジネスの成果に応じて、コストを各チームに分配している (Athenaで分析することも出来る)
  58. 58. 58請求ダッシュボード 標準の請求ダッシュボード 標準ではリソースの利用目的や利用組織を識別することは困難 (AWSアカウントを目的/組織別に分割していれば識別可能)
  59. 59. 59コスト配分タグ コストの分析を目的として付与したタグをレポートに出力することが可 能 • 例:ワークロード(システム)名、オーナー など • レポートにタグがないと必要な切り口での分析ができない Using Cost Allocation Tags https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html
  60. 60. 60【参考情報】タグの利用目的 以下の目的でタグを利用することが多い Technical Tags システムの名称やアプリケーションのバージョン など Tags for Automation バックアップの要否や監視対象かどうかの識別 など Business Tags コストを負担する部門名やプロダクトオーナー名 など Security Tags データの機密性 など AWS Answers | AWS Tagging Strategies https://aws.amazon.com/jp/answers/account-management/aws-tagging-strategies/
  61. 61. 61AWS Cost Explorer 様々な切り口(月日/サービスなど)でコストを分析 リザーブドインスタンスの利用率なども分析可能
  62. 62. 62Budget 指定した期間の利用料金を監視、閾値を超えたら通知
  63. 63. 63AWS Cost and Usage Report 詳細な料金情報をCSV形式でS3に出力 • 時間別/日別での出力 • コスト配分タグを利用可能 • 1つのAWSアカウント内部で利用目的や組織を識別したい場合には設定する必要がある • S3をハブにして Athena / QuickSight / RedShift と連携(後述)
  64. 64. 64Cost Optimization Monitor (AWS Answers) Kibanaによるダッシュボードを容易に構築 Cost Optimization Monitor https://aws.amazon.com/jp/answers/account-management/cost-optimization-monitor/
  65. 65. 65Athena / QuickSightによるダッシュボード Query and Visualize AWS Cost and Usage Data Using Amazon Athena and Amazon QuickSight https://aws.amazon.com/jp/blogs/big-data/query-and-visualize-aws-cost-and-usage-data- using-amazon-athena-and-amazon-quicksight/
  66. 66. 663.不要なリソースをどのように削除していますか?  ライフサイクルを意識したリソース追跡をしている (タグ付けを利用して、リソースとワークロードの紐づけを把握している)  孤立した不要なリソースを特定し、リソース停止を検討するプロセスがある  なにかイベントがあった際(定期監査時や気づいたときなど)に手動で削除してい る  利用率が低い、重要度の低いなどの不要なリソースを安全に自動的に停止する仕 組みになっている (AutoScalingやスクリプトなど)
  67. 67. 673.不要なリソースをどのように削除していますか?  ライフサイクルを意識したリソース追跡をしている (タグ付けを利用して、リソースとワークロードの紐づけを把握している)  孤立した不要なリソースを特定し、リソース停止を検討するプロセスがある  なにかイベントがあった際(定期監査時や気づいたときなど)に手動で削除してい る  利用率が低い、重要度の低いなどの不要なリソースを安全に自動的に停止する仕 組みになっている (AutoScalingやスクリプトなど)
  68. 68. 68ワークロードのライフサイクル 設計時にワークロードの廃止可能条件を定義していますか? • 例 • 検証用途 • 検証終了の時点で廃止可能 • Blue/Green Deploymentを行っている環境 • 新しい環境の正常動作を確認できた時点で廃止可能 • タグを利用して識別することも可能 Upgrades Without Tears Part 1 — Introduction to Blue/Green Deployment on AWS https://aws.amazon.com/jp/blogs/startups/upgrades-without-tears-part-1-introduction- to-bluegreen-deployment-on-aws/
  69. 69. 69 ペットから家畜へ
  70. 70. 703.不要なリソースをどのように削除していますか?  ライフサイクルを意識したリソース追跡をしている (タグ付けを利用して、リソースとワークロードの紐づけを把握している)  孤立した不要なリソースを特定し、リソース停止を検討するプロセスがある  なにかイベントがあった際(定期監査時や気づいたときなど)に手動で削除してい る  利用率が低い、重要度の低いなどの不要なリソースを安全に自動的に停止する仕 組みになっている (AutoScalingやスクリプトなど)
  71. 71. 71Trusted Advisor AWSアカウントの状態を自動で評価するサービス 利用率が低い/利用されていないリソースの特定などが可能 20180711 AWS Black Belt Online Seminar AWS Trusted Advisor https://www.slideshare.net/AmazonWebServicesJapan/20180711-aws-black-belt-online-seminar-aws-trusted-advisor
  72. 72. 723.不要なリソースをどのように削除していますか?  ライフサイクルを意識したリソース追跡をしている (タグ付けを利用して、リソースとワークロードの紐づけを把握している)  孤立した不要なリソースを特定し、リソース停止を検討するプロセスがある  なにかイベントがあった際(定期監査時や気づいたときなど)に手動で削除してい る  利用率が低い、重要度の低いなどの不要なリソースを安全に自動的に停止する仕 組みになっている (AutoScalingやスクリプトなど)
  73. 73. 73CloudTrailによるログの取得
  74. 74. 743.不要なリソースをどのように削除していますか?  ライフサイクルを意識したリソース追跡をしている (タグ付けを利用して、リソースとワークロードの紐づけを把握している)  孤立した不要なリソースを特定し、リソース停止を検討するプロセスがある  なにかイベントがあった際(定期監査時や気づいたときなど)に手動で削除してい る  利用率が低い、重要度の低いなどの不要なリソースを安全に自動的に停止する仕 組みになっている (AutoScalingやスクリプトなど)
  75. 75. 75AutoScaling リソースの利用率(CPUUtilizationなど)に基づいてEC2インスタン スを増減させる機能 AWS Black Belt Online Seminar 2017 Auto Scaling https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-auto-scaling/25
  76. 76. 76CloudWatch Events スケジュールもしくはイベントドリブンで何らかの処理を実行できる スケジュールの例 EC2インスタンスを毎日22時に停止 検証/開発環境などは夜間の稼働は不要(である場合が多い)なので停止する イベントドリブンの例 EC2インスタンスが新たに作成されたらメールで通知 計画されていない作成であれば、CloudTrail や Config で原因を調査する
  77. 77. 774.AWSサービス選択の際にコストをどのように評価していますか?  コストの組織要件を定義している (他の柱とのトレードオフのバランスなど)  ワークロード内のすべてのコンポーネントをコスト削減の対象にしている  各コンポーネントについて徹底的な分析をする (マネージドサービスの削減できる運用コストや管理コストも考慮する)  コスト全体最適のためにコンポーネントを選択している (マネージドサービス利用、ライセンス費用の考慮)  定期的にコスト最適化の評価をしている (ワークロードの変化や、新サービスの活用)
  78. 78. 784.AWSサービス選択の際にコストをどのように評価していますか?  コストの組織要件を定義している (他の柱とのトレードオフのバランスなど)  ワークロード内のすべてのコンポーネントをコスト削減の対象にしている  各コンポーネントについて徹底的な分析をする (マネージドサービスの削減できる運用コストや管理コストも考慮する)  コスト全体最適のためにコンポーネントを選択している (マネージドサービス利用、ライセンス費用の考慮)  定期的にコスト最適化の評価をしている (ワークロードの変化や、新サービスの活用)
  79. 79. 79要件定義 コスト以外の非機能要件、定義してますか? • 非機能要求グレードでは以下の分類で要件を定義 • 可用性 • 性能/拡張性 • 運用/保守性 • 移行性 • セキュリティ • システム環境・エコロジー • 要件を「どの程度」のレベルまで満たすか定義可能 システム構築の上流工程強化(非機能要求グレード) https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html
  80. 80. 80要件定義(トレードオフの例) 可用性よりもコストを重視する場合 RDSインスタンスをSingle-AZで運用する Single-AZであってもある程度のRPO/RTOは担保できる “Amazon RDS Under the Hood: シングル AZ インスタンスのリカバリ” https://aws.amazon.com/jp/blogs/news/amazon-rds-under-the-hood-single-az-instance- recovery/ コストよりも移行性(時間)を重視するの場合 EC2インスタンスでDBサーバーを構築/移行 オンプレミスからRDSへ移行するための検証に時間を割けない EC2であれば機能上の制約がない(検証/動作確認が容易)
  81. 81. 814.AWSサービス選択の際にコストをどのように評価していますか?  コストの組織要件を定義している (他の柱とのトレードオフのバランスなど)  ワークロード内のすべてのコンポーネントをコスト削減の対象にしている  各コンポーネントについて徹底的な分析をする (マネージドサービスの削減できる運用コストや管理コストも考慮する)  コスト全体最適のためにコンポーネントを選択している (マネージドサービス利用、ライセンス費用の考慮)  定期的にコスト最適化の評価をしている (ワークロードの変化や、新サービスの活用)
  82. 82. 82例:マネージドサービスによる運用コストの削減 Amazon RDS • リレーショナルデータベースのマネージドサービス • 様々なデータベースエンジンを選択可能(商用/OSS) • バックアップ/リカバリー、バッチ適用、ストレージの拡張が容易 • 冗長化構成の構築が容易 • (ある程度)最適化された各種パラメーター
  83. 83. 83責任共有モデル IaaSの責任分解点 SaaSの責任分解点 The AWS Shared Security Responsibility Model in Practice https://www.slideshare.net/AmazonWebServices/the-aws-shared-security-responsibility-model-in-practice-59942345
  84. 84. 844.AWSサービス選択の際にコストをどのように評価していますか?  コストの組織要件を定義している (他の柱とのトレードオフのバランスなど)  ワークロード内のすべてのコンポーネントをコスト削減の対象にしている  各コンポーネントについて徹底的な分析をする (マネージドサービスの削減できる運用コストや管理コストも考慮する)  コスト全体最適のためにコンポーネントを選択している (マネージドサービス利用、ライセンス費用の考慮)  定期的にコスト最適化の評価をしている (ワークロードの変化や、新サービスの活用)
  85. 85. 85Commercial LicenseのDBエンジンからの移行 Database Migration Service • データベースの移行サービス • 同種のデータベースだけでなく、異なるデータベース間の移行もサポート • 継続的レプリケーションをサポート Schema Conversion Tool • 異なるデータベース間でデータを移行する前にスキーマの変換を行うことが可 能
  86. 86. 86Commercial LicenseのDBエンジンからの移行 Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するベストプラクティス: 移行プロセスと インフラストラクチャに関する考慮事項 https://aws.amazon.com/jp/blogs/news/best-practices-for-migrating- an-oracle-database-to-amazon-rds-postgresql-or-amazon-aurora- postgresql-migration-process-and-infrastructure-considerations/ Oracle から PostgreSQL へ移行する際に、よく直面する課題を解決 する方法 https://aws.amazon.com/jp/blogs/news/how-to-solve-some-common- challenges-faced-while-migrating-from-oracle-to-postgresql/
  87. 87. 875.コスト目標を達成するためにインスタンスタイプとサイズを どのように選択していますか?  コストモデリングを実行する (ワークロード内の各コンポーネントのコスト比率やコストの変化など)  以前のワークロードの計測や特性に基づいてリソースタイプとサイズを選択して いる  パフォーマンスメトリクスに基づいたサイジングを実施している
  88. 88. 88パフォーマンスメトリックの取得 CloudWatchでリソース利用率 やパフォーマンスの監視が可能 (移行の場合)移行元での計測 結果を参考に 参考にするのはHWスペックではなく、 実際のリソース利用量/利用率 CloudWatchダッシュボードを利用してオートスケール環境の稼働状態を可視化してみた https://dev.classmethod.jp/cloud/aws/autoscalling-with-cloudwatch-dashboard/
  89. 89. 89パフォーマンスメトリックの取得 エージェントによるEC2インスタンスの詳細な監視も可能 • CloudWatch Agent • 各種メトリックの監視 • cpu_*, disk_*, diskio_*, mem_*, net_*, netstat_*, processes_*, swap_* • 各種プラグインの利用も可能 • procstat, StatsD, collectd マネージドサービス毎に各種メトリクスを取得可能 • (例)DynamoDB • ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits • 計測結果に基づき、手動もしくは自動でスケーリング
  90. 90. 906.コスト削減のために料金モデルをどのように選択していますか?  購入オプション活用に向けた分析をしている (Cost ExplorerのRI推奨機能など)  スポットインスタンス(スポットフリートやスポットブロックを含む)を活用して いる  すべてのコンポーネントに購入オプション(オンデマンド、リザーブ、スポットイ ンスタンス)を検討している  リージョン毎の料金の差を考慮している
  91. 91. 916.コスト削減のために料金モデルをどのように選択していますか?  購入オプション活用に向けた分析をしている (Cost ExplorerのRI推奨機能など)  スポットインスタンス(スポットフリートやスポットブロックを含む)を活用して いる  すべてのコンポーネントに購入オプション(オンデマンド、リザーブ、スポットイ ンスタンス)を検討している  リージョン毎の料金の差を考慮している
  92. 92. 92様々な購入オプション 1. オンデマンドインスタンス 2. リザーブドインスタンス 3. スポットインスタンス
  93. 93. 93オンデマンドインスタンス 利用量/時間に応じた課金、前払いなしの課金体系 • インスタンスの稼働時間 • 保存しているデータ量 • API Call数 • データ転送量 • ユーザー数 • 他・・・ AWSサービスのデフォルトはこの購入オプション
  94. 94. 94リザーブドインスタンス 年または3年の利用コミットによる料金割引 • EC2、RDS、Redshift、Elasticache、Elasticsearch Serviceで利用可能 • m5.xlarge(Linux)のEC2インスタンスを3年間利用する場合の料金例 • オンデマンド • $0.248 / h × 24h × 365d × 3y = $6,517.44 • リザーブドインスタンス(3年/全額前払い/スタンダード) • $2,861.00 → オンデマンドと比較して約56%の割引 Amazon EC2 リザーブドインスタンス料金表 https://aws.amazon.com/jp/ec2/pricing/reserved-instances/pricing/
  95. 95. 95スポットインスタンス AWS上の余ったリソースを格安で提供 • 現在の価格を上回る価格で入札するとインスタンスが起動 • 現在の価格が入札価格を上回るとインスタンスが削除 アプリケーションに よる対応が必須
  96. 96. 96スポットインスタンスの値動き 近年は落ち着いている 印象
  97. 97. 97お得なインスタンスタイプは? スポットインスタンスアドバイザー https://aws.amazon.com/jp/ec2/spot/instance-advisor/ 古いほどお得? (新しいものは人気?)
  98. 98. 98スポットインスタンス 「Amazon EC2 スポットでスポットインスタンスの停止と開始が可能 に」(2017年9月) https://aws.amazon.com/about-aws/whats-new/2017/09/amazon-ec2- spot-can-now-stop-and-start-your-spot-instances/ → 利用しているサービスのアップデートを把握しておくことが重要
  99. 99. 99スポットブロック リクエスト時に使用予定時間(1-6時間)を指定 • 指定した時間は削除されない • スポットインスタンスに比べると割引率は低い • 課金は落札時の価格で固定
  100. 100. 100スポットフリート 指定した条件(価格、インスタンス/vCPU)に基づいてインスタンス を利用 • 配分戦略に応じて複数のスポットプールを利用し、インスタンスを起動 • Lowest Price / Diversified を選択 • 詳細は以下の資料をご確認ください • AWS Black Belt Online Seminar 2016 Amazon EC2 Spot Instances (スポットインスタンス) https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online- seminar-2016-amazon-ec2-spot-instances
  101. 101. 101料金の試算 購入オプション(オンデマンド/リザーブド)を変更した場合の料金を 試算 SIMPLE MONTHLY CALCULATOR https://calculator.s3.amazonaws.com/index.html?lng=ja_JP# AWS Pricing Calculator https://calculator.aws/#/
  102. 102. 1026.コスト削減のために料金モデルをどのように選択していますか?  購入オプション活用に向けた分析をしている (Cost ExplorerのRI推奨機能など)  スポットインスタンス(スポットフリートやスポットブロックを含む)を活用して いる  すべてのコンポーネントに購入オプション(オンデマンド、リザーブ、スポットイ ンスタンス)を検討している  リージョン毎の料金の差を考慮している
  103. 103. 103Cost Explorer によるRIの推奨 RIの購入によりどの程度のコストの削減が見込るかをレポート リザーブドインスタンスの推奨事項へのアクセス https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/ri-recommendations.html
  104. 104. 1046.コスト削減のために料金モデルをどのように選択していますか?  購入オプション活用に向けた分析をしている (Cost ExplorerのRI推奨機能など)  スポットインスタンス(スポットフリートやスポットブロックを含む)を活用して いる  すべてのコンポーネントに購入オプション(オンデマンド、リザーブ、スポットイ ンスタンス)を検討している  リージョン毎の料金の差を考慮している
  105. 105. 105リージョン間の価格差 m5.xlargeのEC2インスタンス(Linux)の場合 • 東京リージョン • $ 0.248/時間 • オレゴンリージョン • $ 0.192/時間 → 約23%安い Amazon EC2 料金表(オンデマンド料金) https://aws.amazon.com/jp/ec2/pricing/on-demand/
  106. 106. 1067.データ転送料金についてどのように計画していますか?  データ転送量についてのモデリングを実行する (ビジネス計画に基づくデータ転送量の変化など)  データ転送量を最適化するアーキテクチャになっている (アプリケーション設計, WAN最適化, Multi-AZ, リージョン選択等)  データ転送量を削減するためのサービスを活用する (CloudFront、ElastiCache、Direct Connectなど)
  107. 107. 1077.データ転送料金についてどのように計画していますか?  データ転送量についてのモデリングを実行する (ビジネス計画に基づくデータ転送量の変化など)  データ転送量を最適化するアーキテクチャになっている (アプリケーション設計, WAN最適化, Multi-AZ, リージョン選択等)  データ転送量を削減するためのサービスを活用する (CloudFront、ElastiCache、Direct Connectなど)
  108. 108. 108試算例 S3の課金要素 保存されているデータ量 AWSから送信されたデータ量 リクエスト数 (API Call)
  109. 109. 109試算例 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/
  110. 110. 110どうすれば費用を削減できるか? データ転送量が費用の大半を占める • コンテンツのサイズを減らす(技術的なアプローチ) • 圧縮方式など • リクエストを減らす(技術的なアプローチ) • クライアントサイドキャッシュなど • CloudFrontのリザーブドキャパシティーを利用(ビジネス的なアプローチ) • 10TB以上の利用をコミットすれば、ディスカウント可能 → モデリングを通して、何がコストに効くのかを把握
  111. 111. 1117.データ転送料金についてどのように計画していますか?  データ転送量についてのモデリングを実行する (ビジネス計画に基づくデータ転送量の変化など)  データ転送量を最適化するアーキテクチャになっている (アプリケーション設計, WAN最適化, Multi-AZ, リージョン選択等)  データ転送量を削減するためのサービスを活用する (CloudFront、ElastiCache、Direct Connectなど)
  112. 112. 112VPN接続(冗長接続の場合) 接続時間 AWSから送信されたデータ量
  113. 113. 113専用線接続(冗長接続/接続を占有する場合) AWSから送信されたデータ量 ポートの使用時間
  114. 114. 114Direct ConnectとVPN接続の比較 (例)月間のデータ転送量が100GBの場合 • DirectConnect(1Gbpsのポート × 2) • ポート料金:$0.285/h × 2ポート × 24h × 30d = $410.4 • データ転送(送信):$0.0410/GB × 100GB = $4.1 • 合計:$414.5 • VPN接続(接続を冗長化) • 接続時間: $0.048/h × 2接続 × 24h × 30d = $69.12 • データ転送(送信): $0.114/GB × 100GB = $11.4 • 合計:$80.52 AWS Direct Connect の料金 https://aws.amazon.com/jp/directconnect/pricing/ Amazon VPC の料金 https://aws.amazon.com/jp/vpc/pricing/
  115. 115. 115Direct ConnectとVPN接続の比較 (例)月間のデータ転送量が10TBの場合 • DirectConnect(1Gbpsのポート × 2) • ポート料金:$0.285/h × 2ポート × 24h × 30d = $410.4 • データ転送(送信):$0.0410/GB × 10000GB = $410 • 合計:$820.4 • VPN接続(接続を冗長化) • 接続時間: $0.048/h × 2接続 × 24h × 30d = $69.12 • データ転送(送信): $0.114/GB × 10000GB = $1140 • 合計:$1,209.12 → 利用量によってコスト効率の高い方法が変わり得る (サイト間接続については、アクセス回線の費用も含めて比較検討をお願いします。) AWS Direct Connect の料金 https://aws.amazon.com/jp/directconnect/pricing/ Amazon VPC の料金 https://aws.amazon.com/jp/vpc/pricing/
  116. 116. 1168.リソースの供給と顧客の需要をどのように一致させていますか?  ワークロード需要の分析を実施している (季節的な変動など様々な要因)  リソースを需要に応じて手動で追加削除している  需要ベースで対応している (変化する要求に対応するためにAuto Scalingを利用)
  117. 117. 1178.リソースの供給と顧客の需要をどのように一致させていますか?  ワークロード需要の分析を実施している (季節的な変動など様々な要因)  リソースを需要に応じて手動で追加削除している  需要ベースで対応している (変化する要求に対応するためにAuto Scalingを利用)
  118. 118. 118需要変動の例 日 レシピ共有サイト 夕飯買い物前などがピーク? 週 チケット予約サイト 土曜申込開始時刻がピーク? 月 会計システム 月末にリクエストが集中? 不定期だが予測可能 W○S砲、Yah○○砲
  119. 119. 1198.リソースの供給と顧客の需要をどのように一致させていますか?  ワークロード需要の分析を実施している (季節的な変動など様々な要因)  リソースを需要に応じて手動で追加削除している  需要ベースで対応している (変化する要求に対応するためにAuto Scalingを利用)
  120. 120. 120様々なスケーリング 手動 • インスタンスタイプの変更(スケールアップ/ダウン) • EC2インスタンスをELBに登録/登録解除 • AutoScaling Desired Countを手動で変更 自動 • AutoScalingによる自動スケーリング (スケジュール/リソースベース)
  121. 121. 121インスタンスタイプの変更 インスタンスタイプ変更 • インスタンスを停止 • インスタンスタイプを変更 • インスタンスを起動 課題 • ダウンタイムが発生 • インスタンスタイプの上限が性能の 限界
  122. 122. 122手動でのインスタンスの追加 ELB配下のEC2インスタンスを 手動で操作 (追加する場合) • インスタンスを作成 • ELBの配下ににインスタンスを追加 課題 • 再現性のある構築手順の確立 • インスタンスの作成/追加が手間
  123. 123. 123AutoScaling Groupの手動運用 AutoScaling GroupのDesired Countを手動で操作 • Desired Capacityを変更 (インスタンス数がDesired Capasityの数に収束する)
  124. 124. 124AutoScaling Groupの自動運用 スケジュールに基づくスケーリ ング(例) • 毎週土曜のAM9:00にスケールアッ プ • 毎週土曜のPM1:00にスケールダウ ン
  125. 125. 125AutoScaling Groupの自動運用 CloudWatchメトリクスの値に 応じてDesired Countを増減 (例) • CPU利用率が60%を超えたらス ケールアウト • CPU利用率が30%を下回ったらス ケールイン
  126. 126. 126The Twelve–Factor App 「アプリケーションを疎結合にするための指針/方法論」 • 密結合なアプリケーションではクラウドサービスの良さを生かすことが困難 • 疎結合にすることで、クラウドサービスのメリットを引き出すことが可能 The Twelve-Factor Appで考えるAWSのサービス開発 https://www.slideshare.net/AmazonWebServicesJapan/the-twelvefactor-appaws
  127. 127. 127The Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係 依存関係を明示的に宣言し分離する III. 設定 設定を環境変数に格納する IV. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する VI. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスと して実行する VII. ポートバインディング ポートバインディングを通してサービスを公開する VIII. 並行性 プロセスモデルによってスケールアウトする IX. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する X. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ XI. ログ ログをイベントストリームとして扱う XII. 管理プロセス 管理タスクを1回限りのプロセスとして実行する Twelve-Factor App https://12factor.net/ja/
  128. 128. 1289.新しいAWSサービスをどのように評価していますか?  コスト最適化を担当するチームがある  コスト最適化のルールがある (AWS利用料の10%を超えるサービスは四半期ごと、10%未満は1年毎に見直す など)  計画されておらず、必要そうであれば都度検討する  定期的にコスト関するレビューをして、分析している  定期的にAWSのソリューションアーキテクトやAPNパートナーとのミーティング を実施したり、ブログをチェックするなどコスト削減に役立ちそうな新機能の適 用を検討している
  129. 129. 1299.新しいAWSサービスをどのように評価していますか?  コスト最適化を担当するチームがある  コスト最適化のルールがある (AWS利用料の10%を超えるサービスは四半期ごと、10%未満は1年毎に見直す など)  計画されておらず、必要そうであれば都度検討する  定期的にコスト関するレビューをして、分析している  定期的にAWSのソリューションアーキテクトやAPNパートナーとのミーティング を実施したり、ブログをチェックするなどコスト削減に役立ちそうな新機能の適 用を検討している
  130. 130. 130情報収集(オンライン) AWS公式 製品ドキュメント、ブログ、プレゼン資料、ホワイトペーパー、など https://docs.aws.amazon.com/index.html https://aws.amazon.com/blogs/ https://www.slideshare.net/AmazonWebServices/presentations https://aws.amazon.com/whitepapers/ AWSのユーザー 例)クックパッド開発者ブログ https://techlife.cookpad.com/ AWSのパートナー 例)Developers.IO 手前味噌で恐縮です… https://dev.classmethod.jp/
  131. 131. 131情報収集(オフライン) ユーザーコミュニティ JAWS-UG https://jaws-ug.jp/ AWS Loft ソリューションアーキテクトに相談もできるコワーキングスペース https://aws.amazon.com/jp/start-ups/loft/tokyo/
  132. 132. 132【例】インスタンスタイプの世代による価格差 汎用インスタンス(Linux/東京)の場合 • m3.xlarge:$0.385/時間 • m4.xlarge:$0.258/時間 • m5.xlarge:$0.248/時間 Amazon EC2 料金表(オンデマンド料金) https://aws.amazon.com/jp/ec2/pricing/on-demand/ 旧世代のインスタンス https://aws.amazon.com/jp/ec2/previous-generation/
  133. 133. 133M5などのNITROインスタンスへの移行について 第5世代のインスタンスタイプは新しいハイパーバイザーを利用してい るため、移行には注意が必要 • Windows • 最新世代のインスタンスタイプへの移行 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/migrating-latest- types.html • Linux • NITRO世代(C5、M5)へのEC2インスタンスタイプ変更を試してみた(Amazon Linux編) #reinvent https://dev.classmethod.jp/cloud/aws/change-type-to-m5-nitro-generation/
  134. 134. 134 まとめ
  135. 135. 135Well-Architected Framework ベストプラクティスに則っているかを確認できる • 質問は一貫して設計の基本原則に則っているかを確認するものになっている • ただし、全てのベストプラクティスに対応する必要はない (コストは他の柱とのトレードオフになりがち) • 優先順位は利用者のビジネス環境やステークホルダーの要求によって異なる (要件や優先順位を自分たちで決める必要がある) 「組織で」「継続的に」レビューすることが重要 • 多くのステークホルダーとレビューを実施 • AWSがアップデートするように、AWSで構築したシステムもアップデート • ビジネス環境は常に変化する
  136. 136. 136アンケートへご協力をお願いします 次回も参加をご希望ですか? 期待とのズレがあれば、ぜひフィードバックをお願いいたします。
  137. 137. 137

×