第1回 AWSコスト削減 天下一武道会 に行ってきた #costdown_2024

第1回 AWSコスト削減 天下一武道会 に参加しました。オンライン参加。簡単に所感をまとめます。

no1.connpass.com

所感

コスト削減は、分析からボトルネックの調査、改善まで地道な活動が必要。その分、やりがいもありそうでよさそう。刺激になる話が聴けてよかったです。

インフラコスト削減代行サービスってのがあるのか、強そう...。代行サービスとはいえ表面的ではなくドメインの深いところまで理解するから大きい効果が生み出せる。ここまでやらないといけないのね。

事業成長とコスト削減については事業フェーズによって攻めと守りのバランスが必要とのこと。あと、コスト最適化とシステム最適化が繋がる話もよかった。

パネルディスカッションでも話があったけど、他社事例やアンチパターンから学ぶことは多いのでそのあたりをアンテナ張っておくといいのかもしれない。あと、そもそもコスト意識と周りへの働きかけが大事なんだなと感じました。

そういえば、自分も気軽にデバッグしやすいようにどんどんログ埋め込んでおこうとはならなくなった。Datadog 高いし。そういう意味では以前よりコスト意識が身に付いてきたのかもしれない...。(たぶん)

アーカイブこちら。

youtu.be

以下、メモから抜粋。

100社のコスト診断から見えてきた、コスト削減の王道とケモノ道

  • コスト削減代行サービス
  • コスト削減は総力戦
  • FinOps
    • 全員がコストに対して責任を持つ
  • AWS Well-Architected
  • 料金モデル分析
    • RIが使えるか
    • ワークロード伸縮性 (休日夜間縮退など)
    • コストに基づいてリージョンを選択する
  • コスト削減の成果が早く出るだけ事業インパクトが大きい
  • 全員参加
    • モブコスト分析
    • 各領域のエンジニアがそれぞれの観点で考える (FE/BE/インフラ)
  • ドメインアーキテクチャを繋げてみる
  • Elephant in The Room に向き合う
  • バックアップ戦略見直し
    • ロジック見直して無駄を削減する
  • アーキテクチャ更改
    • シングルテナント → マルチテナント
  • データ通信量削減
    • 使ってないレスポンスをなくす

節約は技術!削減は芸術!何より必要なものは覚悟!

  • ボトルネックから潰す
  • 覚悟を持つ
  • プロダクト急成長
    • 3年でMAU5倍
    • 1~2万rps (スパイク時)
    • AWS月額利用料 $146000
  • パフォーマンスチューニング
    • ボトルネックから潰す
    • 支配的なコストから減らす (大きな部分から)
  • 事業成長
    • コスト削減が後回しになりがち
    • 覚悟
  • 早く削減するほど効果が大きい
  • VPC Endpoint 導入
    • NAT Gateway 経由でインターネットに出る通信
    • ECR/S3 に対する VPN Endpoint 作成
    • NAT Gateway 通信料削減
  • ECR pull through cache
    • ECR Public キャッシュ
  • WAF ログ配信先
    • CloudWatch Logs → S3
    • 可視化/分析は難しくなるので注意
  • 不要リソース削除
    • アタッチされていないEIP削除
    • 使っていない環境削除
  • Gravitonインスタンス利用
    • Intelに比べてコスト効率20%向上
  • Auto Scaling Policy 見直し
  • CloudFront Request Collapsing
    • オリジンへのリクエストの折りたたみ
    • TTL1秒でもキャッシュヒット率がそこそこ高い
  • 削減しないと削減されない

dev.classmethod.jp

パネルディスカッション

  • ドメイン
    • ヒアリングする
    • ノウハウが横展開できる
    • よくあるパターンがありそう
  • 他社事例を学ぶ
  • Aurora
  • ソフトウェアエンジニアを巻き込む
  • コスト削減に取り組むタイミング
    • 売上に対してシステム費用の割合のラインを決めてたり
  • コスト削減の必要性に気が付けるか
  • Azure
    • コスト削減のノウハウは少ない

AWSコストを全体で43.75%削減するためのコストモニタリング技術

www.docswell.com

  • 覚悟と計測
  • コスト管理責任者
    • コスト計測
    • 現状把握
    • いつでもコストについて説明できるように - コスト管理タグ
  • Cost Explorer
  • コスト構造を把握する
  • 変動要因
    • サービスごとに分類する
  • コストモニタリング技術
    • ライトなコスト分析基盤
    • QuickSight

大規模通信制御信号ETLシステムにおける大幅なコスト削減・意識改革の取り組み

www.slideshare.net

  • EC2数百台規模
  • EC2 Savings Plans
  • Graviton 移行
  • コスト監視
    • slack
  • コストを見る会
    • コスト意識
  • 夜間縮退

クラウド利用料を半額にするために取り組んだ10+のコト

  • コスト構造の抽象度を上げる
    • システム最適化に付随するコスト最適化
  • リアーキ
  • 運用負荷/信頼性改善にも効果あるかも

新サービスリリースして早々に通信費が膨れた件

  • SDKダウンロード
    • 通信費増
  • CloudFront

機械学習で使用しているGCSの料金を激減させた話

  • 機械学習の中間成果物をGCSに保存
  • GCSコスト増
  • ストレージクラス最適化
  • GCSの用途を分析
    • アクセス頻度に応じてストレージクラスを変える
    • ライフサイクル

30%のMAU増加と78%のコスト削減を両立する方法

www.slideshare.net

  • Cloud Composer
    • 常時起動/常時課金 → 高コスト
    • 基盤移行
    • Cloud Scheduler + Workflows + Cloud Functions

VPCエンドポイントを活用したコスト削減

  • NAT Gateway 処理データ料金が高い

やらなきゃ損!ECS Fargateのコスト削減の手引

  • Backlog Gitホスティング
  • x86 → ARM64 移行
    • ローカルでは x86 を使う
    • マルチアーキテクチャビルド
      • 両方のイメージが作れるように
    • ビルド時間短縮
  • gRPCクライアントのメモリ使用量を抑える
    • http2 ウィンドウサイズが動的に変更される (増える)
    • ウィンドウサイズを 64k-1 以上に
    • メモリ使用量安定
  • Compute Savings Plans

Amazon Aurora のインフラコストを55%削減した話

  • OPTIMIZE TABLE
  • 書き込み多い
    • 秒間5~9万書き込み
    • SLO見直し
    • 1日N回に制限する
  • コスト削減祭り

プロダクトマネジメントのすべて著者 及川さんに聞く 技術から価値を生み出すエンジニアになるには に行ってきた #Offers_プロダクトマネジメントのすべて

プロダクトマネジメントのすべて著者 及川さんに聞く 技術から価値を生み出すエンジニアになるには に参加しました。オンライン参加。簡単に所感をまとめます。

offers.connpass.com

所感

ソフトウェア開発からプロダクト開発にマインドチェンジすることが重要。「エディタや管理画面の向こうにユーザーを見る」という言葉は刺さりました。

顧客価値をどうやって収益に結び付けるか、その収益をプロダクトの進化に還元し、新しいユーザー価値を提供する、その結果として収益を得る、このサイクルを回せるようにするにはどうするかというビジネス視点も大事。

プロダクトマネジメントのすべて』は前にちょっと読んでたけど、またしばらく積読してる状態なので読み直そう...。

www.shoeisha.co.jp

以下、メモから抜粋。

  • オーナーシップを持ってプロダクトに向き合う
  • ユーザーに喜んでもらう
    • この体験を他メンバーに伝搬させる
  • ビジョンの実現
    • 事業価値の最大化
    • 顧客価値の最大化
  • ソフトウェア開発からプロダクト開発へ
  • ビジネス視点
    • ユーザーファーストの視点から
    • いかにユーザーに使ってもらうか
    • 顧客価値から収益に結び付けられるか
      • ビジネスモデルの話
      • ビジネスモデルが正しいかを考えられるように
        • コスト, 課金ポイント, ...
    • 収益 → プロダクト進化 → ユーザーへの価値 → 収益 → ...
  • 内発的動機づけ
  • 外発的動機づけ
  • ユーザーにとって必要なものと売上に直結するものは両立する
    • ビジネスモデルは適切に設定できているか
    • UX改善は売上向上に寄与するか
      • 因果関係が証明できるか
  • エンジニア/ビジネスのギャップ
    • それぞれに背景がある
    • 背景を理解する
  • 機能要望の優先順位付け
    • RICEスコア
    • アイゼンハワーマトリクス
    • KGI/KPI
    • ノーススターメトリック
    • 先行指標
    • KPIツリー
    • リリースした機能をモニタリングする
  • スピードと品質のバランス
    • 品質とは
      • ユーザーの期待のちょっと上を行ってればいい
      • 簡単に直せるものと難しいものがある
        • データモデルなどは最初のうちにしっかり考えた方がいい
    • スピードと品質は両立する
  • ユーザーヒアリング
    • 仮説を作ってからインタビューする
    • 定量調査
    • 仮説が正しくないことも貴重な情報

spanner-cli: command not found

Homebrew で Go はインストール済みだったので、spanner-cli の README を参考にインストール。

github.com

$ go version
go version go1.21.6 darwin/arm64
$ go install github.com/cloudspannerecosystem/spanner-cli@latest
...

しかし、spanner-cli: command not found になってしまう...。

で、spanner-cli の README にある Install Go を見たら PATH を設定してねって書いてある。Go ってそういうものなのか。

export PATH=$PATH:$HOME/go/bin

現場からは以上です。

その他

spanner-cli で Cloud Spanner にアクセスして SQL を実行する。GCP コンソールの Spanner Studio でもトランザクション管理できるといいんだけど。

$ spanner-cli -p {PROJECT} -i {INSTANCE} -d {DATABASE}
Connected.
spanner> BEGIN;
Query OK, 0 rows affected (0.03 sec)

spanner(rw txn)> ...(略)
Query OK, 1 rows affected (0.34 sec)

spanner(rw txn)> COMMIT;
Query OK, 0 rows affected (0.04 sec)

spanner> exit;
Bye

2023年のふりかえりと2024年に向けて

年末年始は帰省先で過ごしています。

2023年早々に中学時代からのヒーローが逝ってしまった。2023年はずっとこの喪失感を引きずってしまった。R.I.P.

2022年のふりかえりと2023年に向けて - kntmr-blog

今は5-6名程度のチームなので、改めてスクラムチームとしてチームビルディングして開発をリードしたいお気持ち。

2023年前半は5-6名のチームの開発をリードするのが主な役割でした。不確定要素が多くて生産性は決してよくはなかったけど、メンバーがリズムよく開発できるような動き方がそこそこできたような気はする。たぶん。

後半はプロジェクトの方針転換と体制変更があり、リーダーからプレイヤー寄りに。機能開発よりは基盤構築周りのタスクを受け持つことが多くてインフラ周りの知見は増えたと思う。以前はインフラ周りのタスクは SRE チームに依頼することが多かったが、プロダクトチーム内でできることが増えたという意味では Embedded SRE としての役割を担えたと言ってもいいんだろうか...。

あと、会社でエンジニア Hub に Terraform 記事を寄稿することになり記事の一部を書いた。文章を書くのは好きな方なので楽しかったです。

とはいえ、仕事では思い悩むことも多くてそこそこ大変だったし、プライベートでは引っ越しもあってバタバタしたりで、個人的に趣味に興じる時間と気力はなかった。2023年はあまりいい年とは言えなかったような気がする。

今年からまた組織体制が変わりチームリードとテックリードを担う感じに。プロジェクトは去年から継続する感じだけど領域は少し変わる。メンバーは10名程度で、参画して間もないメンバーもいるので改めてチームビルディングからやっていきたい。というわけで、年末年始はこの本を読んでます。

gihyo.jp

あと、これまであまり関わってない領域をテックリードとして見ることになりそう。ただ、品質管理は既存の知見のあるメンバーに任せて、まずは自分は開発プロセスを整理していこうかと。

耐障害性向上・パフォーマンス改善・運用負荷軽減をどう実現する?事業を支えるSREのノウハウを共有 に行ってきた #SREノウハウ

耐障害性向上・パフォーマンス改善・運用負荷軽減をどう実現する?事業を支えるSREのノウハウを共有 に参加しました。オンライン参加。簡単に所感をまとめます。

enechange-meetup.connpass.com

所感

「コスト最適化」「安定稼働」「アジリティ向上」 のための取り組みが聴けてよかったです。知らない単語とか出てきてちょっと話に追い付けないところもあったけど。

正直、昔は SRE = インフラエンジニア みたいな雑なイメージしか持ってなかったけど、ここ何年か SRE チームと一緒に仕事する機会が増えてからは自分にも「コスト最適化」「安定稼働」「アジリティ向上」の意識が芽生えるようになりました。たぶん。

SRE に限った話でもないけど、現状をしっかり把握して仮説を立てて検証するということと、ものごとを定量的に把握することが重要な気がします。

自分専用の使い捨て検証環境欲しい...。

以下、メモから抜粋。

アソビューSREで実施した各種最適化の視点について

  • 性能限界を意識する
    • Aurora
      • 24xlarge
      • 最大コネクション数 16000
  • キャパシティプランニング
  • 負荷テストで指標を定める
    • どれくらいの負荷に耐えられるか
    • どれくらいパフォーマンスが出せるか
  • スペック/パフォーマンスの相関
    • 限界値に対して必要なスペック/リソース
  • Pod 負荷率
    • Pod ごとの性能限界
    • 秒間処理可能数
  • スパイクを予測する
  • 安定稼働基準
    • 5倍のスパイクに耐えられるように
      • Pod 負荷率, CPU 利用率 20%以内
  • Aurora Serverless v2
    • 利用メモリが減る (CPU に依存する)
  • HPA
    • datadog メトリクス
  • CircleCI
    • ジョブが実行されるリージョンに近いところにビルドイメージを配置する
    • オーバーヘッド削減
    • 通信コスト削減

SRE初心者が急成長しているEV充電サービスの安定稼働にコミットした話

  • OCPP
  • リソース不足による障害
    • スケールアウト
    • バッチ実行頻度を下げる
    • DB スケールアップ
  • デプロイの際にCPU利用率が跳ねる
    • 旧コンテナが落ちる際に一斉に接続断される
    • WebSocket 再接続による負荷増
  • 再接続が集中しない仕組み
  • Exponential Backoff
    • リトライによる再接続のタイミングを分散させる
  • 線形デプロイ (CodeDeploy)
    • トラフィックを徐々に Blue → Green に置き換える
      • WebSocket との相性イマイチ
      • トラフィック置き換えは新規接続のみが対象
      • 接続済みはそのまま残る
  • Graceful Update (自前)
    • CodeDeploy → EventBridge に通知
    • Lambda で接続断
    • 少しずつ置き換える

2023年度版!Chatwork流Kubernetesの運用方法

  • SRE に求められるもの
    • コスト最適化
    • 安定稼働
    • アジリティ向上
  • EC2 台数増加でコスト増
  • スケールアウトする際に EC2 起動が間に合わず不安定に
    • balloon
    • 余剰ノードを確保するための仕組み
  • Karpenter
  • ArgoCD
  • 開発者が開発しやすい環境
    • SRE チームがボトルネックにならないように
    • 本番アカウント/検証アカウント分離
      • 開発者が検証アカウントで作業できるように
    • 自分専用の使い捨て検証環境
  • Terraform x Atlantis

cloudfront functions でクエリパラメータを追加したい

微妙にハマったのでメモ。

docs.aws.amazon.com

関数の中ではクエリパラメータなどはオブジェクトとして扱うことになる。例えば、クエリパラメータに foo=bar を追加する場合は次のようにする。

function handler(event) {
    var request = event.request;

    request.querystring['foo'] = { value: 'bar' };

    return request;
}

現場からは以上です。

Container probes と Spring Boot event listeners

備忘録。Kubernetes にデプロイしている Spring Boot アプリケーションにおいて、とある初期化処理を Spring の起動プロセスの中で実行したい。どのタイミングで実行するのがいいかを調べたときのドキュメントリンク集。

結局、冒頭の初期化処理は ApplicationStartedEvent をハンドリングして実行するようにした。おそらく、Liveness Probe や Readiness Probe が始まる前。