2024年8月アーカイブ

はじめに

今回は、アクセルユニバースのインフラエンジニアがAWSアカウントのコスト削減を実施する際に利用しているチェックリストをご紹介いたします。

AWSコスト削減チェックリスト

私たちアクセルユニバースのAWSコスト削減チェックリストは

• チェック対象リソース/サービス
• コスト削減観点(状態)
• 手段

の3つの項目から構成されています。 私たちインフラエンジニアはこのチェックリストを元に「クラウド支出の最適化(FinOps)」におけるコストの最適化を実践しております。

こんなお悩みはありませんか？

• クラウド化は実施したが想定よりコストがかかっている...
• コスト削減可能性を感じているが多忙で調査に手が回らない...

そのお悩みアクセルユニバースが解決します！

アクセルユニバースでは、素早くお手頃、でも根本的にAWSコストの最適化を実現します。 AWSコスト削減サービスをお求めの方はこちらまで

はじめに

AWSにてデプロイのリスクを緩和するにあたり「Well-Architected Framework 運用上の優秀性」への考慮は大変重要です。 今回は、AWS Summit Japan「Amazon ECSから考える安全なアプリケーションデリバリー」をベースに、デプロイのリスクを緩和する方法をご紹介いたします。

目次

• 安全なアプリケーションデリバリーとは
• 線形デプロイ/Canaryデプロイ
• 機能フラグ(Feature Flag)
• 自動ロールバックの必要性
• まとめ

安全なアプリケーションデリバリーとは

AWSの定義する「安全なアプリケーションデリバリー」とは意図しない障害が発生した際の影響範囲を最小限にすることです。 残念ながら、システムを運用する上で、意図しない障害が発生する可能性をゼロにすることはできません。 だからこそ「いかに影響範囲を最小限にするか？！」に着目すべきなのだと思います。

いかに影響範囲を最小限にするか？

AWSはこの課題を解決するためにデリバリーによる新機能の公開を少数のユーザから段階的に行う手法を推奨しています。

新機能を段階的に公開する手法

1. 線形デプロイ/Canaryデプロイ
2. 機能フラグ(Feature Flag)

それでは、それぞれの手法を詳しく見ていきたいと思います。

1. 線形デプロイ/Canaryデプロイ

線形デプロイおよびCanaryデプロイとは、ユーザからのトラフィックの一部分のみを新バージョンのアプリケーションへアクセス許可する手法です。

線形とCanaryの違い

線形デプロイ
線形デプロイとは、デリバリーされた新機能にアクセス許可するトラフィックの比率を10% → 20% → 30%...と線形的に増やし、正常性確認を慎重に行う手法です。

Canaryデプロイ
Canaryデプロイとは、デリバリーされた新機能にアクセス許可するトラフィックの比率を10%程度の少数に定め、その小規模なトラフィックに対して正常性が確認でき次第、全てのトラフィックを新機能にアクセス許可する慎重かつ大胆な手法です。

線形/CanaryデプロイのAmazon ECSでの実践

それでは、線形デプロイ/CanaryデプロイのAmazon ECSでの実践について詳しく見ていきたいと思います。

必要となるAWSのリソース

• AWS ALB
  → ユーザからのトラフィックの一部を新バージョンのアプリケーションにルーティングさせる役割
  
• Amazon ECS
  → 現バージョンで稼働させているアプリケーションはそのまま稼働させつつ新バージョンのアプリケーションも追加で稼働させる役割
  
• AWS CodeDeploy
  → 線形デプロイ/Canaryデプロイの司令塔
  → AWS ALBにおけるトラフィックの比率管理およびAmazon ECSにおけるサーバの並行稼働を実現する役割
  

フロー

1. 新バージョンのアプリケーションをデプロイ
   → AWS CodeDeployがAmazon ECSに自動でデプロイ
   
2. ユーザからのトラフィックの一部を新バージョンのアプリケーションにルーティング
   → AWS CodeDeployがAWS ALBのトラフィックの比率を自動で変更
   
3. 全てのユーザからのトラフィックを新バージョンのアプリケーションにルーティング
   → AWS CodeDeployがAWS ALBのトラフィックの比率を自動で変更
   
4. 現バージョンのアプリケーションを停止
   → AWS CodeDeployがAmazon ECSを自動で停止
   

上記のようなフローで、線形デプロイ/CanaryデプロイをAmazon ECSにて実践することができます。

ALBの仕組み

AWS ALBはターゲットグループと重み(トラフィックの比率)を設定することができます。
例えば、現バージョンのターゲットグループに80%の重みを、新バージョンのターゲットグループに20%の重みを設定します。 そうすることで、ユーザからのトラフィックの一部分のみを新バージョンのアプリケーションへアクセス許可することが可能です。 しかしながら、その設定だけではユーザの割り当て先が毎回バラバラになってしまう課題が残ります。
そこで登場するのが、AWS ALBの機能の内の1つであるスティッキーセッションです。

スティッキーセッション
セッションが有効な間、クライアントとサーバーを常に一対一で接続させる役割

スティッキーセッションを利用することで、ユーザの割り当て先を固定し、線形/CanaryデプロイのAmazon ECSでの実践を可能にします。

2. 機能フラグ(Feature Flag)

機能フラグ(Feature Flag)とは、特定の属性を持つユーザからのトラフィックのみに対して新バージョンのアプリケーションへアクセス許可する手法です。 具体的には、アプリケーションコードに「機能フラグがONの場合にのみ実行されるロジック」を組み込み、機能フラグのON/OFFによりアプリケーションの振る舞いを切り替えます。

補足 : フラグ(Flag)とは、ONかOFFのどちらの状態かを判断するために使用する変数です。

アプリケーションコードに組み込むロジック

ユーザからのトラフィックの情報に含まれるuserID(Flag)が、機能フラグ(FlagGroup)に含まれている場合にのみ、新機能へのルーティングがONになります。 これにより、ユーザID単位での新機能へのON/OFFを制御することが可能になります。

機能フラグ(Feature Flag)のAmazon ECSでの実践

それでは、機能フラグ(Feature Flag)のAmazon ECSでの実践について詳しく見ていきたいと思います。

必要となるAWSのリソース

• AWS AppConfig
  → 機能フラグを管理する役割
  → アプリケーションコードに組み込むロジックの保存や配布を簡素化する役割
  
• Amazon ECS
  → 機能フラグを定期的に取得するためのサイドカーコンテナ(AppConfigエージェント)を稼働させる役割
  
• AppConfigエージェント(サイドカーコンテナ)
  → アプリケーションの代わりに機能フラグを定期的に取得する役割
  → アプリケーションが直接的にAWS AppConfigを叩く必要がなくなり、アプリケーションコードをよりシンプルに書くことが可能
  

フロー

1. 新機能を含むアプリケーションコードを本番環境にデプロイ
   → AWS AppConfigに保存されている機能フラグはOFFの状態
   
2. 新機能を公開したい一部のユーザに対して機能フラグをONに変更
   → AWS AppConfigに保存されている機能フラグの値を更新
   
3. 機能フラグがアプリケーションに反映され一部のユーザに新機能が公開
   → AppConfigエージェント(サイドカーコンテナ)が非同期で機能フラグの値を取得しアプリケーションに反映
   
4. 全てのユーザに対して機能フラグをONに変更し、全体のユーザに新機能が公開
   

上記のようなフローで、機能フラグをAmazon ECSにて実践することができます。

自動ロールバックの必要性

ここまで、線形/Canaryデプロイと機能フラグについて見てきましたが、ここで自動ロールバックについて考えます。 線形/Canaryデプロイや機能フラグによる新機能の段階的公開では、問題が確認されたタイミングでロールバックを実施する必要があります。 もし、ロールバック作業が手動である場合、せっかく確保できた時間リソースを無駄にしてしまうことになります。

そこで登場するのが自動ロールバックです。

自動ロールバックのAmazon ECSでの実践

それでは、自動ロールバックのAmazon ECSでの実践について見ていきたいと思います。

必要となるAWSのリソース

• Amazon CloudWatch
  → AWS CodeDeployとAWS AppConfigと連携しALARM状態を伝達する役割
  
• Amazon ECS
  → 新バージョンのアプリケーションからメトリクスを発行する役割
  
• AWS CodeDeploy & AWS AppConfig
  → AWS CloudWatchのALARM状態時に自動でロールバックをする役割
  

フロー

1. 常時発行されるメトリクスに対してしきい値を設定
   → Amazon ECSから常時発行されるメトリクスに対してAmazon CloudWatchアラームを作成
   
2. しきい値を超えた場合のみ旧アプリケーションへの自動ロールバックを実行
   → AWS CodeDeploy & AWS AppConfigがAmazon CloudWatchのALARM状態を検知し自動ロールバックを実行
   

補足 : Amazon CloudWatchのデフォルト機能だけでは自動ロールバックをすることはできません。そのため、上記のようなアラームの作成が必要とされます。

上記のようなフローで、自動ロールバックをAmazon ECSにて実践することができます。

まとめ

ここまで「Amazon ECSから考える安全なアプリケーションデリバリー」について見てきました。 デプロイのリスクを緩和する方法のイメージは湧きましたでしょうか？

AWS CodeDeployやAWS App Configなど、マネージドなリソースを利用することで時間リソースを確保するだけではなく、オペレーションミスなどによるインシデントを未然に防ぐことができます。 AWSにおいて、アプリケーションのデリバリー頻度を上げつつ、そのデリバリーを安全に行いたい想いを持つエンジニアの方々には、ぜひ利用を試みていただきたいです！ ご精読いただき、ありがとうございました。

はじめに

AWSのコスト管理を実施するにあたり「Well-Architected Framework コスト最適化の柱」への考慮は欠かせません！ その中でも「クラウド財務管理(CFM)」の実装は特に重要です！ 今回は、そのクラウド財務管理(CFM)を実践するためにクリアすべきミッションを3つご紹介いたします。

目次

• クラウド財務管理(CFM)とは？
• ミッション① : コストの可視化
• ミッション② : コストの最適化
• ミッション③ : コストの計画・予測の確立
• まとめ

クラウド財務管理(CFM)とは？

まず初めに、クラウド財務管理(CFM)を一緒に確認しましょう。 クラウド財務管理(CFM)は、AWSにおいて「クラウド支出の最適化(FinOps)」=コスト管理を実践するための指標となり、

• 可視化
• 最適化
• 計画・予測の確立

の3つの項目から構成されています。 私たちAWSユーザは、クラウド支出の最適化(FinOps)の継続的な実践を、AWSからベストプラクティスとして推奨されています。 それでは、3つの項目をそれぞれミッションとし、適切な対応を1つずつ確認していきたいと思います。

ミッション① : コストの可視化

ミッション①は「コストの可視化」です。 実際にAWSのコスト管理を実施するためには、その第1段階として、AWSアカウントのコストの現状を把握しなければなりません。 とはいえ、コストの可視化を実践するためには、どのAWSサービスを採用するべきでしょうか？

AWSでは、コストの可視化のために下記のサービスを採用することを推奨しています。

• AWS Cost Explorer
  • AWSコストのグラフ化によりコストの可視化が可能
  • → レポートパラメータの使用による粒度別のコストデータ調査
  • → 過去のコストデータの使用による向こう1年のコスト視覚化

• コスト分配タグ
  • AWSリソースへのタグ付けによりコストの追跡・可視化が可能
  • → キーと値の組み合わせによるコスト分類
    • 例) キー : env
    • 例) 値 : prod
    • 注意点 : 各アカウントでのAWSリソースへのタグ付けだけでは不十分であり、ペイヤーアカウントでのコスト配分タグへの登録が必須
  • AWS Tag Editor
    • コスト分配タグを付け忘れたAWSリソースの検索およびタグの付与が可能
    • → コスト分配タグの漏れの無い付与による徹底的なコスト管理

• AWS Cost and Usage Report(CUR) 2.0
  • AWSコストの テーブル化 によりコストの可視化が可能
  • → AWS Cost and Usage Report(CUR) 2.0の S3 への格納により Amazon Athena のSQLを使用したコストデータ分析が可能
  • 特徴 : AWS Cost Explorerよりも詳細にコストの可視化・分析が可能

• AWS Cost and Usage Dashboard(CUD)
  • AWSコストデータの ダッシュボード への一元的な表示によりコストの可視化が可能
  • → AWS Cost and Usage Dashboard(CUD)の S3 への格納により Amazon QuickSight のSQLを使用したコストデータ分析が可能
  • 特徴 : ダッシュボードの作成によるハイクオリティな可視化が可能

基本的には、AWS Cost Explorerやコスト分配タグにてコストの可視化を実践することができます。 しかしながら、本格的なコストの可視化を実践するためには、AWS CUR 2.0やAWS CUDの採用が推奨されます。 どのサービスを利用するかにより可視化のレベルが異なるため、環境や非機能要件に合わせて手段を適切に採用しましょう！

ミッション② : コストの最適化

ミッション②は「コストの最適化」です。 AWSのコスト管理の第2段階として、実際にAWSアカウントのコストの削減を実践していきましょう。

コストの最適化はAWSから推奨される手順があり、

1. 需要に応じたスケジューリング
2. 適切なインスタンスタイプ・ストレージの見直し
3. 1と2を踏まえたReserved InstancesまたはSavings Plansの購入

の3つの項目から構成されています。 それでは、手順を3つのブロックに分けて確認していきます。

1. 需要に応じたスケジューリング

需要に応じたスケジューリングとは、例えば、開発環境などにおける常時稼働不要なサーバの夜間・土日の停止などを指します。 AWSでは、需要に応じたスケジューリングのために下記のサービスを採用することを推奨しています。

• Amazon EventBridge スケジューラ
  • タスクへのスケジュールの指定によりAWSコストの最適化が可能
  • → cron式やrate式の使用によるタスク別の詳細な時間管理

• AWS Lambda
  • 必要な時間帯のみの関数の実行によりAWSコストの最適化が可能
  • → トリガーとの同期により関数を実行
  • → イベントの発生の検知により非同期で関数を実行

• AWS Systems Manager Resource Scheduler
  • AWS System ManagerにてEC2インスタンスの管理をしている場合、EC2インスタンスへのスケジュールの指定によりAWSコストの最適化が可能
  • → Quick Setupでの設定によりEC2インスタンスの起動と停止を自動で実行

• Amazon EC2 Auto Scaling
  • Amazon EC2インスタンスへのスケジュールの指定によりAWSコストの最適化が可能
  • → スケジュールされたアクションの作成により特定の時間帯に希望する分のキャパシティが増減

2. 適切なインスタンスタイプ・ストレージの見直し

AWSは、適切なインスタンスタイプ・ストレージの見直しに応じる適切な対応についてAWS Cost Optimization Hubにて確認することを推奨しています。

• AWS Cost Optimization Hub
  • AWSアカウントへの推奨アクション(レコメンデーション)の一元化によりAWSコストの最適化に関する適切な戦略の特定が可能
  • → 各アカウントにおけるアイドル状態のAWSリソースの検出
  • → 各AWSリソースの適切なサイズやスペックの推奨

3. 1と2を踏まえたReserved InstancesまたはSavings Plansの購入

AWSは、さらなるコストの最適化を目指してReserved InstancesまたはSavings Plansを購入することを推奨しています。

• Reserved Instances(RI)
  • 一定期間(1年or3年)の継続利用をコミットすることにより大幅な割引(最大-72%)が適用可能
  • SPとの違い
    • → 事前にインスタンスのタイプの指定が必要
      • リージョン/インスタンスファミリー/テナンシー/OS/アベイラビリティーゾーン

• Savings Plans(SP)
  • Reserved Instancesの後に発表された費用見積ツールであり、仕様はリザーブドインスタンスとほぼ同様だが高い柔軟性を持つ
  • 一定期間(1年or3年)一定量の継続利用をコミットすることにより大幅な割引(最大-72%)が適用可能
  • RIとの違い
    • → 事前に対象サービスに対する1時間当たりに支払う利用金額の決定が必要

AWSアカウントにおいて既に採用しているサービスやリソースにより、スケジューリングの手段、見直しの箇所、および料金モデルが異なります。 ご自身のAWSアカウントの環境に最もマッチするサービスを見極めた上で、コストの最適化を適切に実践しましょう！

ミッション③ : コストの計画・予測の確立

ミッション③は「コストの計画・予測の確立」です。 AWSのコスト管理を 継続的に 実施するために、その最終段階として、AWSアカウントのコストの計画・予測を確立しなければなりません。 AWSでは、コストの計画・予測を確立するために下記のサービスを採用することを推奨しています。

• AWS Budgets
  • AWSコストのカスタム予算の追跡によりコストの計画・予測の確立が可能
  • → カスタム予算におけるしきい値の設定による予算超過時のアラート発信
  • → 予算超過時アラートによるカスタムアクションの自動的な実行

• AWS Cost Anomaly Detection
  • 機械学習を通じたAWSコスト異常検出と根本原因分析によりコストの計画・予測の確立が可能
  • → AWSコストのカスタム異常しきい値の設定によるベースライン逸脱時のアラート発信
  • → 高度な機械学習によるベースライン逸脱時アラートの根本原因分析

しきい値の逸脱時にアラート通知が可能なサービスを適切に実装することにより、あらかじめ定めた予算やコストの大幅なズレを未然に防ぎ、コストの計画・予測を確立しましょう！

まとめ

ここまで、クラウド財務管理(CFM)を実践するためにクリアすべき3つのミッションを順に見てきました。 ご自身のAWSアカウントのコスト管理を実施するための最適なサービスは見つかりましたでしょうか？

• ミッション① : コストの可視化
• ミッション② : コストの最適化
• ミッション③ : コストの計画・予測の確立

上記の3つのミッションを継続的に実践することで、クラウド財務管理(CFM)の実装を叶え、AWSのベストプラクティスに沿ったコスト管理を徹底しましょう！ ご精読いただき、ありがとうございました。