AWSコスト最適化ガイドブック のバックアップ(No.10)

キーワード

キーワード内容備考
AWS Well-ArchitectedAWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。
Cloud Financial Management (CFM)(1)クラウド利用費用の可視化、(2)-1迅速にクラウド利用費用削減を実現するためのクイックウィン最適化、(2)-2中長期的な視点でクラウド最適化に取り組むアーキテクチャ最適化、(3)クラウド利用費用の予測と次年度の予算策定のための予測に基づいた計画、(4)持続的なクラウド最適化を推進していくための Financial Operations (FinOps) の実践の 4 つの柱を持ちます。
Database FreedomAWS データベース/分析サービスへの移行
アマゾン フライホイール効果Amazon の場合は、利益を企業の発展のために再投資することにより、さらに売り上げを伸ばしていきます。このサイクルは一度回り始めると、フライホイールのように成長が持続します。このようなビジネスモデルを、アマゾン フライホイール効果と呼びます。
クイックウイン最適化①インスタンス選定
②購入オプション選定
③不要リソース停止
④スケジュール調整
⑤ストレージ選定
⑥ライセンス最適化

ポイント

ページ内容補足
20技術的な課題の多くは共通の問題を抱えやすいため、AWS ではその声を集約しサービスを改善することで、共通のソリューションが提供できるようになってきています。一方で、ビジネス課題は企業や部門それぞれ固有の事情を考慮して解決していくことになるため、画一化されたソリューションではなく、利用者自らが解決策を見い出さざるを得ないのです。
23障害の多くはハードウェア障害であり、それらは回避不能です。そのため、AWS ではいかに障害を発生させないか、といった障害を回避する設計ではなく、障害が発生してもサービスを継続できるように設計することを重要視しています。
31クラウド環境へ移行したことによるもっとも大きな効果は、IT インフラストラクチャに付随するコストが削減されたことよりも、IT インフラストラクチャがビジネスを加速させるプラットフォームへ変革できる点にあります。
39AWS を含むクラウドへの移行後の支出を調査した結果、平均 32％ の過剰支出がなされているという結果があります。
40クラウド利用費用を最適化するための最初のステップとして、利用しているリソースがどの組織/チーム/開発プロジェクト/サービスに帰属しているのかを明確にし、利用費用・利用量を監視・管理することが必要です。
42中断が発生しても大きな問題が起きないワークロードに対しては、最も単価の安いスポットインスタンスを適用するのも有効な手段です。
44データ転送費用は、インターネットからのインバウンド通信が無料、アウトバウンド通信なら有料です。さらに、同一の AZ 内の通信は無料、AZ 間の通信は双方向で有料、リージョン間の通信はインバウンドは無料、アウトバウンドは有料となります。
48可視化のポイントは、何をどこまで可視化するのか、という点にあります。可視化のための手間や得られた情報の保存にかかる費用など、すべてを可視化することが逆に最適化の足かせになってしまうことも考えられます。
52マルチアカウント対応の AWS サービスが増加し、マルチアカウント環境をシンプルに管理するための方法も充実してきたことから、今日では、単一の管理主体が複数の AWS アカウントを持ち展開する構成、つまりマルチアカウント構成が主流になっています。
56Savings Plans/リザーブドインスタンスはアカウントごとに購入しますが、AWS Organizationsを使うことで、個々のアカウントが持っている Savings Plans/リザーブドインスタンスを AWS Organizations 配下のメンバーアカウントで共有できます。
63AWS Instance Scheduler は、Amazon EC2 インスタンスや Amazon RDS インスタンスの開始スケジュールと停止スケジュールを設定することで、クラウド利用費用を管理するサービスです。
72設定したタグは、このままでは AWS の請求レポートや AWS Cost Explorer には表示されません。設定したタグを表示するには、適用されたタグを AWS Billing and Cost Management コンソールで有効化する必要があります。
76AWS Organizations では、組織を作成する際に「すべての機能を有効にした組織を作成」するか、「一括請求のみを有効にした組織を作成」するかを選択することができます。タグポリシーを利用するためには、「すべての機能が有効化されている組織」である必要があります。
78タグポリシーには、3 種類のルールを適用できます。選択できるルールの内容は、以下になります。
①タグキー大文字化コンプライアンス
②タグ値コンプライアンス
③強制するリソースタイプ
105AWS CUR でできて AWS Cost Explorer では取得できない情報の一つに、Amazon EC2 などの各インスタンスに適用されている Savings Plans/リザーブドインスタンスの ID (ReservationARN あるいは SavingsPlanARN) があります。
105AWS Cost Explorer はフィルターなどの設定により、管理者や運用者が直接見たり、簡単な集計をするために CSV で出力するなどいった用途を想定しています。一方、AWS CUR は、保存された使用状況のデータを Amazon Redshift などのデータウェアハウスに取り込んで分析したり、Amazon QuickSight などの BI ツールでダッシュボードによる可視化を行うことが可能になります。
134クイックウィン最適化は、「クラウドネイティブアーキテクチャの採用によるクラウド最適化」と比較すると「クイック」に実施可能であり、かつその効果も「クイック」に得られるアプローチのことです。そのため、1 年に 1 回ではなく、1 か月に 1 回、あるいは毎週、できればシステムに変更があった場合はすぐに、というように実施サイクルを短くすることが理想です。そのためには、日頃の AWS サービスの利用状況、およびそのクラウド利用費用を把握し、どこに最適化の余地があるのかを常に把握しておくことが肝要です。
135正常時でも、リソースをどの程度利用しているのか、夜間や週末、あるいは季節によって稼働が変化しているのか、どのような特性を持っているのか……といったことを把握できれば、クラウド利用量の最適化の余地がどこにどれだけあるのかを判断する材料になります。
135クイックウィン最適化の余地がどのくらいあるのかを AWS で分析した結果、月額利用料に対して、平均 20％、中央値 17％ という最適化の余地がありました。
136AWS が実施した CPU 使用率に関する調査によれば、ピーク時であっても物理サーバーで約 24％、仮想サーバーで約 21％ でした。
147インテルから AMD への変更や、インテル/AMD から Graviton プロセッサ搭載インスタンスへの変更の際に、アプリケーションのリビルドやコード書き換えが必要になる可能性があることです。
151vCPU を増加させる必要はなかったとしても、大きなメモリが必要な場合は vCPU も大きくなってしまい、それに伴い Amazon RDS インスタンスの利用費用も増加してしまいます。このような状況を回避するため、Amazon RDS ではメモリ最適化インスタンスに対して、メモリのみを大きくする追加機能が提供されています。
172もし期間中に不要となった場合でも、リザーブドインスタンスマーケットプレイスでリザーブドインスタンスを販売することができます。
177割引率は同等ですが、インスタンスの属性変更など柔軟性を持った Savings Plans が推奨となります。Savings Plans はキャパシティ予約ができませんが、オンデマンドでキャパシティ予約を可能とするオンデマンドキャパシティ予約を利用すれば、リザーブドインスタンスのキャパシティ予約と同等の機能を享受できます。
180スポットインスタンスとは、AWS クラウド内の使用されていない Amazon EC2 キャパシティを活用することで、Amazon EC2 インスタンスを割引料金で利用できる購入オプションです。オンデマンド料金に比べ、最大 90% の割引料金で利用できます。
181スポットインスタンス料金は急激に変化することはなく、突然のスパイクや変動がないことが期待できます。Amazon EC2 マネジメントコンソールと API の両方から、最大過去 3 か月間のスポットインスタンスの価格履歴データを表示できます。
183スポットインスタンス料金は急激に変化することはなく、突然のスパイクや変動がないことが期待できます。Amazon EC2 マネジメントコンソールと API の両方から、最大過去 3 か月間のスポットインスタンスの価格履歴データを表示できます。
189ステートレスアプリケーションは、サーバーに固有の情報を持たないことから、リクエスト数に応じたスケールアウトやスケールインと相性がよく、クラウド利用費用の最適化も図りやすくなります。また、ステートレスアプリケーションのクライアントに再送の仕組みを持たせることで、スポットインスタンスとの相性が抜群に向上します。
192クラウド利用費用を抑えるためには、リソースが適切に使われているかどうか、使用されていないリソースがないかどうかを定期的に確認することが重要です。
202Amazon S3 などは Amazon EBS や Amazon EFS と比較すると容量単価が安いため、大量のデータの保管場所に向いていますが、多種多様なデータが大量に保存されていくと、データの重要性や保存期間などの管理が難しくなります。難しいからと手を付けないでいると、さらにデータが保存され、ますます要不要の判別が難しくなります。
212スケーリングおよびインスタンスが起動し、アプリケーションが使えるようになるまでには数分の時間を要します。そのため、トラフィックの急増 (スパイクアクセスといいます) に対応できない可能性があります。
発的なアクセスが事前にわかっているのであれば、サービスレベルの維持を第一に考え、動的スケーリングと予測スケーリング (やスケジュールスケーリング) を組み合わせて使うのがベストプラクティスといえるでしょう。
214ステートレスなアプリケーションとして設計するには、セッション情報を Amazon DynamoDB や Amazon ElastiCache など他のサービスに格納する方法などが一例として挙げられます。引き続き利用する情報や、ほかのサーバーから共通的に利用する可能性があるデータを外部に出すことで、呼び出し元のサーバーが消えたり変わったりしても、処理が続けられるようにします。同じように、ログファイルもサーバーと一緒に消えてしまわないように Amazon CloudWatch Logs や Amazon S3 に保存することをおすすめします。
222スロットリングが実装されているサービスを利用する（もしくはさせる）場合は、アプリケーション側にリトライの仕組みを導入することが重要です。リクエストを処理できない場合は、スロットリングによってサービス提供者からリクエスト元に対してリトライする必要がある旨のエラー（429TooManyRequestsエラーレスポンス）が通知されます。そのため、リクエスト元では一定時間待機してから、リクエストをリトライするよう実装することで、顧客体験を損なわないようにします。
226バッファベースのアプローチでは、メッセージは後続の処理を行うコンシューマーから読み取られ処理される（プル型）ため、コンシューマーの処理可能範囲内の動作速度でメッセージを実行できます。これによりクラウド利用費用の節約などの理由で抑えられたリソース量であっても、サービスの可用性を維持することができます。
234更新頻度が高い場合、オブジェクトストレージでバージョニングを有効にしていると、更新のたびに古いオブジェクトは残しつつ、更新されたデータが新しいオブジェクトとして保存され、大量のストレージ容量が使用され余分な利用費用が発生する可能性があります。
235ランダムアクセスの場合はブロックストレージが適しています。特にサイズの大きなデータに対して、その一部だけを更新するような使い方である場合は、ブロックストレージを使用するべきです。
236AmazonS3はもともと大量のオブジェクトをフラットに管理することに長けているため、アプリケーションからデータに直接アクセスさせたいが、設計をより簡易化するためにデータの配置をフラットにしたい、というときはAmazonS3がおすすめです。
236IOPSが要件として挙がる場合はランダムアクセス志向のワークロードやデータであり、MB/秒,GB/秒が要件として挙がる場合はシーケンシャルアクセス志向のワークロードやデータの可能性が高いです。両方の要件を満たさなければならないこともよくありますが、その場合はトランザクション性能を中心に検討するのがよいでしょう。
256Glacierシリーズには、アーカイブ層ではあるものの、読み出しがあったときにS3標準と同じ遅延で読み出しができるS3GlacierInstantRetrievalというストレージクラスがあります。GlacierInstantRetrievalはメディアコンテンツ、医療画像、ゲノミクスなどTBクラスからPBクラスの容量を長期保存しつつ、必要な場合には即座に呼び出す必要のあるデータの保存に向いています。
258AmazonS3の利用費用を削減するには、「データを適切なストレージクラスに配置する」というアプローチが重要です。保存されるオブジェクトのアクセスプロファイルがわかっている場合は、オブジェクトを保存するときにアプリケーション側でオブジェクトのライフサイクルを設定して、アクセス頻度が落ちると思われる期間が経過すれば、S3-IAやアーカイブ層に移動させるという方法が有効でしょう。
260また、「保存されるオブジェクトに対して保存後どのくらいアクセスがあるのか利用者、管理者でもわからない」こともあると思います。その場合は、S3IntelligentTieringのストレージクラスを使うという選択肢もあります。S3IntelligentTieringはオブジェクトの最終アクセス日からどのくらい経過したかによってS3標準、S3標準-IA、Glacierの各ストレージクラス、それぞれのストレージクラス相当のアクセス階層に自動的に変更してくれる便利なストレージクラスです。
263マルチパートアップロードを使用する場合は、不完全なマルチパートアップロードを中止するためのバケットライフサイクルポリシーを設定し、開始後指定された日数以内に完了しないマルチアップロードを停止し、マルチパートアップロードに関連付けられているすべての分割されたオブジェクトを削除するよう設定することを推奨します。
266AmazonS3StorageLensの情報を定期的に確認することで、各アカウント、バケット、プレフィックスにおけるAmazonS3の利用状況、トレンドを把握し、無駄なオブジェクトの削除、適切なストレージクラスの設定などに活かすことが可能です。
275自社のコンプライアンス要件に「他社とサーバーを共有しない」という項目があった場合、共有テナンシーではこの要件を満たせません。DedicatedHostsであれば、物理サーバーを専有するため、要件を満たすことができます。
292AWSCostExplorerのサイズの適正化に関する推奨事項を選択すると、AmazonEC2におけるダウンサイジング対象、アイドル状態のインスタンスの候補を表示することができます。
304過去の利用実績を利用者にフィードバックし、本当に必要かどうかを確認するプロセスを確立することは、全社的にコスト意識を高め、最適化を進めるのに有効です。
310ネットワークアーキテクチャを検討する際は、特に可用性と遅延を考慮しつつ、クラウド利用費用の抑制にも注視が必要です。
311常に稼働することが求められる極めて高い可用性を求められない限りは、十分な可用性と高いパフォーマンスのあるマルチAZを優先的に検討するとよいでしょう。
313データ転送費用は、インターネットからのインバウンド通信なら無料、アウトバウンド通信なら有料です。さらに、同一のAZ内の通信は無料、AZ間の通信は双方向で有料、リージョン間の通信はインバウンドは無料、アウトバウンドは有料となります。AWSのサービスとリージョンで合計100GBまでのインターネットへのデータ転送費用は、毎月無料となります。また、VPCエンドポイントで接続されたAmazonEC2などの各種AWSサービス間のデータ通信は無料です。
320社内のセキュリティポリシーを評価したうえで、大容量通信が発生する場合はAWSDirectConnectを、容量が多くない場合はVPN接続を利用して費用を削減できます。
324接続するVPCが多い場合、管理工数を考慮するとTransitGWを用いたアーキテクチャとし、接続するVPCの数が少ない場合はVPCPeeringを用いた構成とすることが、TCOの観点で最適な構成となります。
327VPCからAmazonS3やAmazonDynamoDBにアクセスする際、ゲートウェイエンドポイントを設定しなかった場合は、インターネットに通信する仕組み（EIPやNATGW等）が必要になり、それらの利用費用がかかります。
328AmazonS3へのセキュアな通信は、インターフェイスエンドポイントでも実現可能ですが、インターフェイスエンドポイントはAWSPrivateLinkの利用費用（東京リージョンの場合、VPCエンドポイント１つあたり$0.014、最初の1PBでは$0.01/GB/月）が課金されます。プライベートIPアドレス同士で通信したいなどの特別な要件がない場合は、ゲートウェイエンドポイントを選択することでクラウド利用費用を削減できる可能性があります。
330AmazonCloudFrontは遅延、可用性、セキュリティの非機能要件により利用するケースが多いサービスですが、AmazonS3を使って外部にウェブサイトを公開する場合においては、AmazonS3単独で利用するよりもクラウド利用費用の観点でも推奨されるサービスとなります。
331AmazonCloudFrontでは、キャッシュリクエスト等のデータ転送容量は大きくありません。また、インターネットへのデータ転送の無料枠が1TB、HTTP/HTTPSリクエストも1000万件まで無料であることから、AmazonS3のみを利用するよりも、クラウド利用費用の観点で有効となります。
336一般に、IT予算の75％以上は現行ビジネスの維持・運用（ランザビジネス）に割り当てられています。サーバーやネットワークといったインフラの維持・管理費、アプリケーションの保守・変更に伴う人件費や工数が含まれており、維持のために定常的に費用がかかることから、長年、IT部門はコストセンターだといわれてきました。
344定常的な処理が継続し、休閑時間が少ないシステムで厳密に負荷変動を予測できる場合には、適切なサイズのAmazonEC2インスタンスを適正台数揃えて構成すれば、コンテナやサーバーレスを採用するよりも、クラウド利用費用を少なく収めることが可能な場合があります。一方で、そのための作業工数や監視の際の心理的な負担も考慮すべきです。
351手動の作業ではなく、システムとして環境の複製を作ることで、時間の短縮と作業ミスの防止、環境の同一性を仕組みとして保証することが可能となり、クラウド利用費用以外での手間や時間の短縮という観点での「コスト」効果につながるのです。
352コンテナ技術の利用によって、クラウド利用費用の削減（集約率向上）と作業工数の削減（構成の複製環境の構築作業、設定ミスによる手戻りリスクの軽減）、運用の均一化といった効果が期待できます。
353オープンソースベースの技術を利用するということは、その変化のスピードに追従していけるかどうかを、これから先のシステム運用という観点で考慮する必要があります。これは中長期的な「コスト」の観点で重要な判断基準の一つとなります。
356オンプレミスでの実装時にコンテナを利用しておくと、コンテナをそのまま転用できるため、クラウドへの移行がよりスムーズになります。
359AWSFargateを併せて利用することで、コンテナ実行環境の基盤となるコンピューティングリソースの確保や解放作業が自動制御・管理されます。
360AmazonECSonAWSFargateではクラウド利用費用の低減効果のあるスポットインスタンスやGravitonプロセッサを利用するように、設定で指示できます。
363常にマネージド型サービスが最良の選択肢であるとは限りません。どちらを選択すべきなのかは、企業の置かれている状況や対象のシステムの性質にも依存します。
366ある程度のラフな負荷の見積もりはやったほうがよいのですが、それはコンピューティングリソースの容量計画のためではなく、クラウド利用費用のための見積もりという意味合いが強くなります。
367AmazonEC2型のシステムと比較して、クラウド利用費用部分が3分の1や10分の1になったという例は珍しくありません。
どのくらいの効果が出るかは、元のシステムがどのくらい余力を抱えていたのかに依存しますが、休閑時間の多いシステムほど効果があります。
370AmazonAPIGatewayでは、Webサーバーと同等の役割として、認証の仕組みへの連携やキャッシュ機能、通信の暗号化/復号化、負荷の流量制御などの機能を設定ベースで利用できます。
372AWSLambdaにFunctionURLsという機能が追加で利用可能になりました。これを利用すると、APIGateway-Lambdaの構成と同じようなHTTPSリクエストによるLambda関数の呼び出しが簡易な設定でできるようになります。
373初めてサーバーレスアプリケーションに取り組む場合は、例えば、会員制Webサイトをサーバーレスに構築する場合のクラウド構成と料金試算例がAWSのサイトで公開されており※3、会員制Webサイトをサーバーレスに構築する場合のクラウド構成と料金試算例を参考にするとよいでしょう。
376AWSLambdaはAmazonEC2と異なり、インスタンスサイズという概念はありませんが、実行時のメモリサイズの選択で課金単価が変わります。
376小さいメモリで動かす実行時間が長くなれば、結果として、もう少し大きなメモリで短い実行時間で利用するほうがトータルのクラウド利用費用が安価になることもあります。
377あくまで、AmazonDynamoDBにはオンライン処理用のデータのみの保持に留め、レポートや分析用途のデータは場所を移し替え、分析用のデータベースで行うという形が、処理の最適化の観点でもクラウド利用費用の最適化の観点でも賢い選択となります。
377サーバーレスの場合、アプリケーションチューニングで稼働時間・効率が改善すればトータルの処理時間が短縮されるため、そのままクラウド利用費用の最適化につながるという特徴があります。
とはいえ、過度のチューニングでコードの可読性が悪くなり、保守性が下がるようでは本末転倒です。過度なチューニングというよりは、定期的な実行エラー率やタイムアウトの状況を確認して改善していくことを、定期的なアクションとするのがよいでしょう。
379リトライが生じるということは、該当するLambda関数が呼び出された回数が増えていることになり、それはクラウド利用費用に影響します。こうした状況が起きていないかを定期的に確認し改善していくことで、システムが健全・堅牢になり、同時にクラウド利用費用の観点でもよい効果につながります。
379AWSTrustedAdvisorでは、エラー率の高い、またはタイムアウトをしているLambda関数がレポートされるため、定期的なチェックに役立ちます。
379AmazonAPIGatewayのキャッシュ機能は別途クラウド利用費用がかかりますが、これをうまく使うことで、繰り返しの同一リクエストによる負荷が後段のサービス（AWSLambdaやAmazonDynamoDBなど）に向かう前に結果を返すことができます。つまり、後段のサービスの利用量を減らすことになるため、全体としてのクラウド利用費用の最適化につながる可能性があります。
379Lambda基盤には呼び出し時の引数で関数の実行の可否をフィルタリングする機能があります。これを利用すると、関数の実行前に条件判定ができるため、最終的な結果は同じでも、AWSLambdaの課金計算に影響する実行回数を抑えることができます。
380後段の処理の完了までに時間がかかるケースでは、呼び出しの非同期化を検討してもよいでしょう。
アプリケーション全体としてはより堅牢になり（非同期型で再実行がしやすい構造になるため）、クラウド利用費用にも優しくなります。
380スロットリング機能を設定することで、想定を超える負荷から後段処理を保護できます。結果として、後段処理部分のクラウド利用費用を抑えることになります。
385リレーショナルデータベースは集約処理型で設計されています。そのため処理が集中しそうな場合は、その手前で緩衝させる機能を用意しておくのがベストプラクティスです。
385従来型の三階層アプリケーションモデルではアプリケーションサーバーにDB接続プーリングがありますが、RDSProxyはそれと同等に機能し、Lambda関数から大量のDB接続リクエストが来ても緩衝層として大量のDBアクセスが押し寄せないように調整します。
400AWSCostExplorerを用いることで、過去の利用の伸び率から、80％の信頼区間で12か月後までの予測を行うことができます。
402AmazonForecastは、機械学習を使った時系列データを用いて予測を立てます。AWSCostExplorerでは過去12か月のデータに基づいた予測となるため、将来予測としては限定的となります。一方AmazonForecastの場合は、過去の時系列データを分析することで、クラウド利用費用が需要に応じて大きく変動したり、季節変動性がある場合でも、より精緻な予測が行えます。
417インフラアーキテクチャのクラウドへの適合、ならびにクラウド利用費用最適化のためのアプローチを実施するためには、手動作業をできる限り排除し、自動化を進めていくためのAWSサービス、サードパーティー製品、それらを組み合わせたソリューションが必要となります。
419集中管理機能を保有し、持続的に最適化の仕組みを構築している会社は、そうでない会社と比較してクラウド利用費用を38％削減し、クラウド利用費用の予測精度が10％向上していることがわかっています。

リンク