Edited at

AWS Well-Architected Frameworkのオンラインセミナー受けてみた

AWS Black Belt Online Seminar AWS Well-Architected Frameworkによるコスト最適化」の自分向けメモ

Well-Architected Framework(W-A)って何?......レベルの人向け


クラウド活用の道のり

活用方法は大きく2つ



  • クラウドネイティブ


    • プロジェクト初期からクラウド前提の設計・構築を行う




  • リフト&シフト


    • オンプレからクラウドへそのまま移行し、段階的にクラウド最適化を行う




よくあるお客様の課題


  • リフト&シフト後、最適化する技術がない


W-Aとは


  • システム設計・運用の大局的な考え方とベストプラクティス集

  • AWSとお客様と共に、W-Aも常に進化し続ける

  • W-Aを利用することでベストプラクティスがすぐに入手できる

  • ビジネス的な判断をするための材料で、全てがW-Aに則っている必要はない


構成要素


  • ホワイトペーパー


    • 設計原則とQA形式のペストプラクティス集

    • あくまで原則



  • SA(Solution Architect)またはパートナーの支援

  • W-A Tool


    • ベストプラクティスとのギャップをセルフチェックできる




設計原則

オンプレと異なり、クラウドでは後から設計を見直すことが容易にできる

とにかくテスト、試行錯誤を繰り返すこと


  • 勘に頼らないキャパシティ設計


    • オンプレでは初期に決めてそのまま最後まで突き進む

    • クラウドでは後でスケール変更が可能



  • 本番規模でのシステムテストの実施


    • オンプレでは物理的に本番規模のテスト環境の用意が困難

    • クラウドでは本番環境も仮想なので、同様のテスト環境の用意が可能



  • 自動化


    • オンプレではアーキテクチャの設計は基本変更しない

    • クラウドでは何度もアーキテクチャを試行することを前提にする



  • 発展的なアーキテクチャ


    • オンプレではある静止点のアーキテクチャを使い続ける

    • クラウドではDDD(ドメイン駆動設計)を前提とし、都度更新していく



  • データ計測


    • オンプレでは初期に決めたアーキテクチャが問題ないか確認するに留まる

    • クラウドでは計測を行ってからアーキテクチャを決める



  • 本番想定のテストを実施、対策


    • オンプレでは本番想定のテストには制限がある

    • クラウドでは本番同様のテスト環境で試行が可能




QAの使い方


  • 問いに対し、明確な答えがない項目が重要

  • AWSを超えた質問もあるが、その問いに対する明確な答えがないと仕様に落ちないことが多々あるため設けられている

  • 使い方はQAを利用したセルフチェック → SAとのレビュー実施 → クラウド最適化の実施


    • SAとのレビューは設計段階がおすすめ

    • SAとのレビューは無料(個別相談会も有効)



  • リスクや改善点の顕在化させるたための問いであり、全項目の答えがベストプラクティスに則っている必要はない 


コスト最適化


  • QAの46項目のうち、9項目がコスト最適化

  • 9項目のうち、5項目を抜粋


サービス選択時にどのようにコストを評価しているか

利用料金だけでなく、人的コストも含めて考えてほしい


  • 必要な分だけ使用する

  • 全体効率の測定をする

  • データセンタへの投資不要

  • 投資のリターンの分析と把握

  • マネージドサービスの活用


    • オペレーションコストを減らす


      • 例えば、DBを利用する際は比較的料金が安いEC2をDBサーバーとするのでなくRDSサービスを使う



    • 日々進化している、他サービスとの連携が容易




インスタンスタイプとサイズをどのように選択しているか

決め打ちではなく、きちんと計測して選択してほしい

オンプレではある静止点での最適解を求め、後からスペック変更をする慣習はない

オンプレではスペックが要求を満たしているのであれば、運用開始後も見直す慣習はない

クラウドでは世代をあげることでコストが安価になるので必ず見直すこと


  • CloudWatchでリソース利用状況を把握する


    • 利用率が安定している場合


      • ファミリー、タイプの見直し

      • リザーブドへの見直し



    • 利用率が一定ではない場合


      • AutoScalingの検討

      • バッファベース、キューイング処理の検討(SQS、Kinesis)






コスト削減のための料金モデルをどのように選択しているか

海外リージョンを含めて検討してほしい


  • リージョンごとに価格が異なる


    • ビジネス要件を満たせるのであれば東京リージョン以外も考慮すべき


      • 例えば、データ分析に必要な高価なインスタンスのみ比較的安価な海外リージョンに立てる





  • レイテンシーも高い実感はない


    • CloudFrontでAPIコールの高速化を実現(静的コンテンツだけではない)



  • 海外リージョンは最新のサービスが使いやすい

  • 購入オプションも考慮すべき


    • オンデマンド


      • 一時利用



    • リザーブド


      • 常時稼働

      • EC2だけでなくCloudFront、DynamoDBでも選べる



    • スポット


      • 処理系






データ転送量について、設計時にどのように考えたか

動画配信等を提供するサービスだとコスト全体に占める割合は大きいので特に考えるべき


  • CloudFrontの活用


    • レイテンシーの改善

    • 分析

    • セキュリティ対策

    • EC2、S3の負荷軽減 ⇒ EC2、S3のスペック、台数削減につながる




AWS使用量とコストをどのようにモニタリングしているか

試行錯誤を繰り返すためには必須


  • 請求情報のアクセス有効化、コストエクスプローラーの有効化

  • コストエクスプローラーでタグ別に見ることが可能

  • AWS Budgetsにて、閾値を超えたら通知可能


サポートの活用


  • Trusted Advisor


    • セキュリティ観点などのチェック項目

    • ビジネス、エンタープライズのプランだと項目数が多い




まとめ


  • ベストプラクティスを知った上でのビジネス的な判断を!

  • AWSサポートとTrusetd Advisorの活用でコスト削減につながる