2024-03-27

「AWSコスト最適化ガイドブック」を読んだのでメモ2

AWSコスト最適化ガイドブック

harukin721.hatenablog.com

続き。

Cloud Financial Management (CFM)

AWS が提唱しているクラウド利用費用最適化を進めるためのフレームワーク、実践の4つの柱を持つ。

クラウド利用費用の可視化
クイックウィン最適化(迅速なクラウド利用費用削減)とアーキテクチャ最適化(中長期的な視点でのクラウド最適化)
クラウド利用費用の予測と次年度の予算策定のための予測に基づいた計画
持続的なクラウド最適化を推進していくための FinOps

具体的なコスト分析手法やアーキテクチャ最適化

1. クラウド利用費用の可視化

アカウント分割
- ( これはいまは考えない )
タグ付け
- AWS リソースに対してのタグポリシーを定める
- IAM ポリシーや AWS Configルール [required-tags] によるタグ付けの強制
可視化のためのAWSサービス
- AWS Cost Explorer
- AWS Cost and Usage Reports ( AWS CUR )
- AWS Cost Categories による費用分類
- AWS Cost Anomaly Detection による異常検知
- AWS Billing Conductorによる請求管理

2. クイックウィン最適化とアーキテクチャ最適化

クイックウィン最適化の概要

インスタンス選定( EC2, RDS, ElastiCache ...etc )
購入オプション選定( SP, RI, スポットインスタンス ...etc )
不要リソース停止( AWS Trusted Advisor, 愚直に不要リソースの洗い出し ...etc )
リソース調整( Auto Scaling, スケジュールや需要と供給の調整 ...etc )
ストレージ選定( EBS, EFS, S3 ...etc )
ライセンス最適化( SQL Server, Oracle Database ...etc )
- 共有テナンシーと Dedicated Hosts
クイックウィン最適化のための AWSサービス( AWS Cost Explorer, AWS Compute Optimizer ...etc )

アーキテクチャ最適化

ネットワークアーキテクチャ
- ネットワーク関連の利用費用
  - インターネット、リージョン、AZ の通信量の確認
  - AWS Cost Explorer など活用して転送費用の見直し
クラウドネイティブアーキテクチャ
- コンテナ
- マネージド型サービス / サーバーレス
- クラウドネイティブ / モダナイゼーション

3. クラウド利用費用の予測と次年度の予算策定のための予測に基づいた計画

過去の傾向に基づく費用予測
新たな需要に対する費用予測

このあたりを予算を監視すると良いとのこと。

コスト予算：指定された金額に照らして、クラウド利用費用
使用量予算：指定された1つまたは複数の使用タイプ、あるいは使用タイプグループの使用量
Savings Plans の予算：Savings Plans に関連付けられている利用率、またはカバー率
予約予算：リザーブドインスタンスに関連付けられている利用率またはカバー率

4. 持続的なクラウド最適化を推進していくための FinOps

人材・体制
- 組織モデル
- ( CCoE の活動・役割定義 )
運用プロセス
- SP / RI 購入戦略
- クラウドサービスに対する単価指標
- 中長期的なビジネスへの貢献のための指標
FinOps事例紹介
- KPI に基づいたビジネス部門とIT部門との協業
- ( CCoE によるクラウド利用費用最適化の推進 )

2024-03-24

「AWSコスト最適化ガイドブック」を読んだのでメモ1

AWSコスト最適化ガイドブック

www.kadokawa.co.jp

aws.amazon.com

Cloud Financial Management (CFM)

AWS が提唱しているクラウド利用費用最適化を進めるためのフレームワーク、実践の4つの柱を持つ。

クラウド利用費用の可視化
クイックウィン最適化(迅速なクラウド利用費用削減)とアーキテクチャ最適化(中長期的な視点でのクラウド最適化)
クラウド利用費用の予測と次年度の予算策定のための予測に基づいた計画
持続的なクラウド最適化を推進していくための FinOps

1. クラウド利用費用の可視化

クラウド利用費用に対する責任の所在を明確にする。利用費用のデータ取得と分析を通して投資対効果を把握し、適切なIT投資・リソース配分を決定する。

2. クイックウィン最適化とアーキテクチャ最適化

クラウド利用費用を可視化したうえで、ワークロードの特性を評価し、段階的かつ定期的に見直しを行う。

最初のアクションがクイックウイン最適化になる。その6つが該当する。

インスタンス選定
購入オプション選定
不要リソース停止
スケジュール調整
ストレージ選定
ライセンス最適化

中長期的な計画として TCO を最適化していくには、アーキテクチャの観点が不可欠。ネットワークアーキテクチャとクラウドネイティブサービス(マネージド型サービス / サーバーレス) の利用による既存アーキテクチャの最適化が重要になる。

ネットワークアーキテクチャ

可用性やネットワークの遅延等の各非機能要件とクラウド利用費用の両方を適切に評価し、データ転送に係る費用体系の原則を理解する。

インターネットからのインバウンド通通が無料、アウトバウンド通信なら有料
同一の AZ 内の通信は無料、AZ 間の通信は双方向で有料
リージョン間の通信はインバウンドは無料、アウトバウンドは有料
その他、ゲートウェイサービスの利用費用の費用体系を押さえる。

クラウドネイティブサービス

クラウドを活用することで、運用・拡張性、そして回復力を確保し、運用工数を削減し、生産性を向上させ、ビジネスの柔軟性を高める。利用者が設定や保守作業に費やす時間を減らすために、システムを疎結合化し、コンテナサービスやマネージド型サービス、サーバーレスを活用したアーキテクチャを検討する。

3. クラウド利用費用の予測と次年度の予算策定のための予測に基づいた計画

クラウド利用費用を予測し、年次予算策定の計画を立てる。

従来のオンプレミス環境では、ハードウェアの調達計画は中長期間にわたって行われるが、クラウドでは必要な時に必要なリソースを利用できるため、過剰支出を避けることができる。需要の変化に柔軟に対応することで、適切なリソースを効率的に構築できる。

一方、クラウドでは予測が難しく、予算計画と実際の支出との差異が相対的に多く発生するので、予測スパンを短くし、予実差異が生じた場合には迅速に原因を特定し、予測の見直しを行うことが重要になる。

4. 持続的なクラウド最適化を推進していくための FinOps

持続的なクラウド利用費用最適化を実現するには、個々のアプローチの仕組み化が必要となる。

ビジネス戦略に基づいたアーキテクチャ最適化の検討
手動作業の排除と自動化の推進( AWSサービスやサードパーティー製品の活用 )
クラウド利用費用の可視化とガバナンスの構築
IT・クラウド利用のビジネスへの貢献を可視化する仕組みの確立
FinOps の実践によるクラウド最適化

その他

aws.amazon.com

speakerdeck.com

2024-03-08

Infracostというものを使うとTerraformのテンプレートファイルからAWSのコスト試算ができる

Infracost

Terraformのテンプレートファイルからコストを試算することができるらしい。基本的に AWS リソースは Terraform 管理しているので使えるかも(?)と思った。CI に組み込むこともできるようなので GitHub Actions で試しても良さそう。

CLI 機能をサポートするOSSやVSCodeの拡張ツールがある模様。

github.com

www.infracost.io

実際に CLI の方を使ってみる

まず、infracost を install する。

% brew install infracost

API Key を取得する。個人の GitHub でログインした。

% infracost auth login
We're redirecting you to our log in page, please complete that,
and return here to continue using Infracost.

If the redirect doesn't work, either:
- Use this URL:
    https://dashboard.infracost.io/login?cli_port=49740&cli_state=84677633-a7ab-4db7-a357-26e50bacd98e&cli_version=v0.10.34&os=darwin&utm_source=cli

- Or log in/sign up at https://dashboard.infracost.io, copy your API key
    from Org Settings and run `infracost configure set api_key MY_KEY`

Waiting...

The API key was saved to /Users/harukin/.config/infracost/credentials.yml

Your account has been authenticated. Run Infracost on your Terraform project by running:

  infracost breakdown --path=.

% cat  /Users/harukin/.config/infracost/credentials.yml
version: "0.1"
api_key: <api_key>
pricing_api_endpoint: https://pricing.api.infracost.io

認証が完了すると、この画面表示に切り替わる。

AWS リソースで実行してみる

Amazon EC2 の t2.micro で試す。

% pwd
/Users/harukin/ghq/github.com/harukin721/aws/terraform/ec2

% cat main.tf 
resource "aws_instance" "ec2" {
  count = 1
  # Amazon Linux 2023 AMI 2023.0.20230419.0 x86_64 HVM kernel-6.1
  ami           = "ami-01b32aa8589df6208"
  instance_type = "t2.micro"
  root_block_device {
    volume_type = "gp3"
    volume_size = 30
  }
}

コマンドを実行。Monthly cost が $11 との試算が出た。

% infracost breakdown --path .
Evaluating Terraform directory at .
  ✔ Downloading Terraform modules 
  ✔ Evaluating Terraform directory 
  ✔ Retrieving cloud prices to calculate costs 

Project: harukin721/aws/terraform/ec2

 Name                                                   Monthly Qty  Unit   Monthly Cost 
                                                                                         
 aws_instance.ec2[0]                                                                     
 ├─ Instance usage (Linux/UNIX, on-demand, t2.micro)          730  hours         $8.47 
 └─ root_block_device                                                                  
    └─ Storage (general purpose SSD, gp3)                      30  GB            $2.40 
                                                                                         
 OVERALL TOTAL                                                                    $10.87 
──────────────────────────────────
1 cloud resource was detected:
∙ 1 was estimated, it includes usage-based costs, see https://infracost.io/usage-file

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Project                                            ┃ Monthly cost ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━┫
┃ harukin721/aws/terraform/ec2                       ┃ $11          ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━┛

VSCode 拡張機能

自分は VSCode の拡張機能は試していないけど、classmethod さんの記事の通りにやると良さそう。

dev.classmethod.jp

その他

軽くしか調べていないけど、リザーブドインスタンス分でのコスト削減がどのくらいか、CloudWatch,S3, Lambda ...etc、などの使用料ベースの計算もできそう。

おわり

コマンド1発でコスト試算ができるので便利。どこまでの精度なのかはまだ正直よくわかっていないです。Infracost Cloud というものを使えば、コスト試算の他にコストを最適化するための提案もしてくれるみたいです。

参考

AWS Dev Day 2023 Tokyo の [SA-3-2] 成長を続ける SaaS の AWS コスト管理において開発者としてできること で知りました。

youtu.be

2024-02-17

基本的なネットワーク

ネットワーク

TCP/IP モデル

階層	説明	プロトコル
アプリケーション層	メッセージの形式、やりとりの手順	HTTP, SSH, FTP, SMTP
トランスポート層	接続の確立・パケットの分割 / 組み立て	TCP, UDP
インターネット層	IPアドレスで指定された先にパケットを配送	IP, ICMP
リンク層	ハードウェアが通信を実現	イーサネット(有線LAN)、IEEE802.11(無線LAN)

TCPは、パケットの分割や届いたパケットを適切な順番でメッセージを組み立てたり、届かなかったパケットの再送をしたりする。プロセスが接続を待ち受ける時は、IPアドレスとポート番号を指定して、その IPアドレスとポート番号宛のメッセージを受け取る。

基本的なコマンドたち

ping

2つのコンピュータ間で相互にパケットを送受信できることを確認する。 ICMP プロトコルを使って、指定したIPアドレスにパケットを送信、応答を受け取る。

ping < IPアドレス >

traceroute

ping と同じように ICMP プロトコルを使う。パケットが相手のコンピュータに到達するまでに通過したルータを確認する。

tcmdump

Linux でコンピュータが受け取ったパケットを表示する。

1 -> 2 で ping を打っても通らない場合、

sudo tcpdump -n icmp

2 で tcmdump で確認すると、1 からパケットが到達していることはわかる。 2 は 1 へ応答を返そうとするが 1 へのルーティングが適切じゃないので ping が通っていない。

ss

待ち受けているIPアドレスやポート番号を確認する。

sudo ss -antup

nc

TCP コネクションが確立できるか確認する。通信がうまくいかないと状況で、アプリケーション層の問題なのかそれ以下の層の問題なのかを切り分ける。

nc -vz <IPアドレス＞＜ポート番号＞

通信の待ち受けを行う。

nc -l <IPアドレス＞＜ポート番号＞

2024-01-30

探索、整列アルゴリズム

探索

線形探索

リストや配列の先頭から順に要素を比較し、目標の要素を見つけるまで判定していく探索アルゴリズム整列されていないものに対しても整列できるが、あまり効率的ではない。

計算量 : O(n)

二分探索

リストが昇順または降順で整列されていることが前提とされる探索アルゴリズム目的の値が探索するリストの中央の値より大きいか小さいかを判断して次の探索範囲を絞りこみ、それを繰り返す。

計算量 : O(log n)

整列、ソート

バブルソート

隣接する要素を比較し、順番が逆であれば交換するという操作を繰り返す。

計算量 : O(n²)

選択ソート

データ列を未整列と整列済の2つに分けて、未整列の最小の要素を選び、整列済みの末尾に付け加える操作を繰り返す。

計算量 : O(n²)

挿入ソート

データ列を未整列と整列済の2つに分けて、未整列の最小の要素を1つ選び、整列済みの適切な位置に付け加える操作を繰り返す。

計算量 : O(n²)