2025年春に見直したい、
リソース最適化の基本

2025/04/12 @sogaoh
https://phpcon-odawara.jp/2025/

About Me

sogaoh: 曽我 央

・合同会社 ant-in-giant 代表社員 (2022/03〜) 　・６社で業務委託するクラウドインフラ仕事人 ・一般社団法人 SRE NEXT 理事 (2022/01〜) 　・"Road to" と会計(自分&将来の誰か)をラクにするために奔走

AGENDA

CPU

• ARM64 系CPUを なるべく 使う
  • DBインスタンスでは迷わずに移行する(自分の場合)
  • Appサーバは検証後に移行(ライブラリ使えないとかある)
  • 理由：性能が良い・コストが低い・消費電力が少ない
  • ※ まだ x86 系CPUが依然として適している場合もある

Memory Store

• Valkey を かなり 推している
  • Redisのフォーク(容易に移行可能)
  • パフォーマンスとリソース使用量に焦点を当てた最適化
  • コスト効率が良く、OSS(各種費用面でbetter)
  • ※ データの永続化と実績において Redis に劣る面がある

ストレージ

• より新世代のディスクを使う

  • gp3/HyperDisk/Premium SSD v2(※for data only)
  • 高速で、だいたいがコスト・性能効率「より良い」

• ワークロードに適したオプションを選択

  • AWS RDS の I/O最適化オプションなど
  • メガクラウド以外にも選択肢が出てきている
    • TiDB Serverless など

(Data)ライフサイクル

• アクセス頻度に応じたストレージクラス設定

  • AWS: 標準->IA->Archive
    • “参照時に「標準」に戻す” もある
  • Google Cloud: Standard->Nearline->Coldline->Archive
  • Azure: Hot->Cold->Archive

• 古いスナップショットの定期的な棚卸し

  • 10年前のなんてもう使わないでしょ？

コンテナ軽量化

• slimなベースイメージ選択

  • distroless など
  • 小さいimageはより速いdeployへの布石

• マルチステージビルド

  • ビルドステージと実行ステージの分離
  • 必要最小限のファイルでアプリケーション実行

実行最適化

• マルチCPUアーキテクチャの駆使

  • docker buildx の利用
  • ※ 基盤が未対応、なこともある

• 処理の並列化

  • 小さく始めると良さそう
  • 適切な分割が重要
  • リソース状況を可視化して改善していく

(非推奨?) Public subnet ONLY 構成

• Security Group のみでアクセス制御
  • No NAT Gateway
  • No VPC EndPoint
  • 検証用途なら・・・
  • ※ わりとすぐに破綻します…
    • VPC内 Lambda とかできない
  • だいぶコストは抑えられる

注目の AWS CloudFront VPC Origins

• Private subnet からの配信を可能とする機能
  • ALB・NLB・EC2 に直接ポイントできる
  • 早速 internal ALB 経由での疎通を試した(成功)
  • Vercel FE との疎通には AllViewerExceptHostHeader
  • ※余談：IPv4とIPv6の併用も試してみた
    • Egress Only Internet Gateway 初めて知った

新しいものを使っていきましょう。
ただし、今動いているものを尊重しながら。

デフォルトで提供されてるのを脳死で使うのも
そんなにダメじゃないけど、特性を理解して
うまーく使いこなしてると気持ちイイですよ。

End

あたらしい
技術で世の中
よくしよう

お気づきの点あれば @sogaoh まで

[PR] 5/17(土)会津若松へ何卒🙏

[PR] SRE NEXT 2025 も何卒🙏

けろぺん素材は -> https://github.com/sre-next/keropen