Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
気軽に始めるGraviton2マネージドサービスによるコスト最適化 / Amazon Game...
Search
FUJIWARA Shunichiro
November 25, 2021
Technology
4
2.3k
気軽に始めるGraviton2マネージドサービスによるコスト最適化 / Amazon Game Tech Night #23
https://gamingtechnight.connpass.com/event/230933/
FUJIWARA Shunichiro
November 25, 2021
Tweet
Share
More Decks by FUJIWARA Shunichiro
See All by FUJIWARA Shunichiro
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
7
3.3k
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
1
1.2k
awslim - Goで実装された高速なAWS CLIの代替品を作った/layerx.go#1
fujiwara3
5
670
AWS CLIの起動が重くてつらいので aws-sdk-client-go を書いた / kamakura.go#6
fujiwara3
7
9.7k
コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地
fujiwara3
30
7k
fujiwara-ware OSSをひたすら紹介する/ya8-2024
fujiwara3
7
720
Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024
fujiwara3
23
8.2k
リアル事例から読み解くWebパフォーマンスチューニングの勘所/Offers web performance tuning
fujiwara3
4
1.8k
隙間家具OSS開発で『自分の庭』をつくる / kayac-andpad-event
fujiwara3
0
880
Other Decks in Technology
See All in Technology
それでもやっぱり ExpressRoute が好き!
skmkzyk
0
270
UE5の雑多なテク
ryuichikawano
0
400
プロダクト開発の貢献をアピールするための目標設計や認知活動 / Goal design and recognition activities to promote product development contributions.
oomatomo
5
860
OPENLOGI Company Profile for engineer
hr01
1
12k
ガバメントクラウド開発と変化と成長する組織 / Organizational change and growth in developing a government cloud
kazeburo
4
770
【shownet.conf_】クロージングセッション
shownet
PRO
0
310
LeSSはスクラムではない!?LeSSにおけるスクラムマスターの振る舞い方とは / Scrum Master Behavior in LeSS
toma_sm
0
210
受託開発でもアジャイル開発できました / Agile in Contract Development
takaking22
9
4.2k
kube-vipとkube-proxy置き換えCiliumを積んだ究極のK3sクラスタを建てる
logica0419
4
210
軽いノリで"自動化"に取り組んではいけないという話
tetsuyaooooo
1
500
業務ヒアリングと知識の呪い
tamai_63
0
290
【shownet.conf_】ネットワークテストの最適化と利便性の追求
shownet
PRO
0
340
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.5k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
GraphQLとの向き合い方2022年版
quramy
43
13k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
105
48k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Gamification - CAS2011
davidbonilla
80
5k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Fireside Chat
paigeccino
32
3k
Optimizing for Happiness
mojombo
375
69k
The Brand Is Dead. Long Live the Brand.
mthomps
53
38k
Transcript
気軽に始める Graviton2 マネージドサービスによるコスト最適化 2021.11.25 Amazon Game Tech Night #23 ゲームワークロードにおけるコスト最適化
面白法人カヤック 藤原俊一郎 @fujiwara
@fujiwara SREチーム - 自社サービスを主に担当 ISUCON 11優勝 github.com/kayac/ecspresso Amazon ECS デプロイツール
github.com/fujiwara/lambroll AWS Lambda デプロイツール
Game & Community
Graviton2 AWS により 64-bit の Arm Neoverse コアを使用してカスタム構成されたプロセッサ Arm CPU
は Intel(AMD64)CPUとはバイナリ互換性がない 当然、OSもアプリケーションもArm用にビルドされたものでないと動かない 正直、全然気軽ではない でも速くて安いらしい! 比較し得る現行世代の x86 ベースインスタンスより最大で 40% 向上したコストパフォ ーマンスを発揮します。 aws.amazon.com/jp/ec2/graviton/
マネージドサービスで『気軽に始める』Graviton2 自分でOSやアプリケーションを動かすのはArm用のビルドが必要でちょっと大変 OSやアプリケーションを自分で動かさなければ気軽に使えるのでは? → AWSのマネージドサービスで Graviton2 気軽に「速くて安い」恩恵を受けられる!? 今日は ElastiCache, Aurora,
Lambda, Fargate について話します
Graviton2 ElastiCache Redis 2020/11 リリース 2020/11 とあるサービスで R5.large → R6g.large
に切り替え 動機「使ってみたかったから」
Graviton2 ElastiCache Redis の移行方法 同一 Replication Group 内に異なるインスタンスを混在できない ReaderとしてGraviton2インスタンスを追加→Failoverで切り替え、などは不可 サービスをメンテナンスに
snapshot を作成 snapshot からレストア ダウンタイムがそれなりに大きくなる(数十分程度)ので無停止移行は難しい
Graviton2 ElastiCache Redis 移行した結果 コマンドのレイテンシが明らかに下がっている = 速い! (CPU使用率も微減) r5.large 0.259USD/hour
→ r6g.large 0.247USD/hour = 安い! (5%ですが)
Graviton2 ElastiCache Redis まとめ 速い、安い、使い勝手は何も変わらない 新規で使わない理由はない ただし移行はダウンタイムが発生するので面倒 Readerに混ぜてfailoverとかできるようになってほしい 検証環境などはT系にGraviton2が来ないのでt3のまま。t4gも欲しい 2021/11/21
T4g インスタンスが来ました! aws.amazon.com/jp/about-aws/whats-new/2021/11/amazon-elasticache-supports-t4g- graviton2-based-instances/
Graviton2 Aurora MySQL 2021/03 リリース 弊社の構成において、Aurora(RDS)のコスト比率は高い(全体の約25%) ここを削減できると効果が高い
Graviton2 Aurora MySQL Aurora MySQL 5.6系は非対応 MySQL 5.7系(Aurora MySQL 2.x)以降のみ対応
順番に移行していく必要があった 1. MySQL 5.6 → 5.7 アプリケーションの対応 2. Aurora MySQL 1 → Aurora MySQL 2 3. R5 インスタンス → R6g インスタンス
MySQL 5.6 → 5.7 アプリケーションの対応 5.7 にしてとりあえずCIを回す 落ちたテストを直す GROUP BY
で ORDER BY していないクエリで返却順が変わったとか テストがカバーし切れてないところは別途QAで Perlで10万行以上のアプリケーション(ぼくらの甲子園!ポケット, Lobi) どちらも数カ所の修正でいけた 実際のDBをテストに使っている場合、そこまで大変ではないはず
Aurora MySQL 1 → Aurora MySQL 2 移行方法はいくつかあるので、要件に応じて選択 1. in
place upgrade - 既存のクラスタをそのままアップグレード お手軽 (マネコンポチー) ダウンタイムが大きい 何かあった場合に戻すのが面倒 2. snapshot からのレストア - 別クラスタに復元→切り替え 元のクラスタはそのまま残っているので切り戻しが楽 Graviton2 移行も同時にできる snapshot取得 → 起動までのダウンタイムはやはり大きい 3. snapshot からレストア + binlogレプリケーション ダウンタイムが一番短い (レプリケーション停止→アクセス先変更だけ) Graviton2 移行も同時にできる 面倒くさい
Aurora MySQL 1 → Aurora MySQL 2 であったこと Auroraクラスタが本番系に3個あるプロダクト 安全性と手間のバランスを考えて、2.
snapshotから別クラスタ復元を選択 事前に複製したクラスタでsnapshotからの復元時間を検証(3個同時) 1時間程度ですべて終わることを確認 実際にサービスをメンテナンスに入れてアップグレードすることに メンテナンス時間は余裕を見て設定 3クラスタ同時に復元開始 なぜか2クラスタしか進まない (事前検証と違う!?) 2クラスタの復元が終わった途端に残りの1クラスタが進行開始 ここでメンテ時間を突き抜けたので切り戻し…(後日binlogレプリでやり直しました)
None
Aurora R5 インスタンス → R6g インスタンス 移行 同一クラスタ内に異種インスタンスを混在できる いきなりインスタンスタイプを変更してもいいが、慎重にするなら… 1.
Reader として R6g インスタンスを追加 2. Reader Endpoint を使ってクエリを振り分けて様子見 3. 問題なければ順次 Reader のインスタンスタイプ変更 4. 最後に failover 注意: カスタムエンドポイントのメンバーを「変更」すると 変更中に名前が引けないダウンタイムが発生してつらい目に遭います 必ず別のカスタムエンドポイントを作って切り替えること
None
Graviton2 Aurora R6g が起動できないAZ インスタンスを 3AZ に分散していた とある AZ で
R6g.8xlarge が起動できな かった 毎朝起動チャレンジ → 失敗 一週間繰り返したが無理だったの で諦めて一時的に 2AZ 運用
Graviton2 Aurora であったこと Aurora 2.10.0 → 2.10.1 へのバージョンアップが R6g/T4g 混在クラスタで失敗
R6g のみにしたらできた → サポートで本来はできるはずだができない問題と確認 (修正されました) T4g の RI(Reserved Instance) が買えない (2021/11/24時点) まだ出たばかりなのでいろいろありそう サポートを積極的に使っていきましょう
Graviton2 Aurora まとめ クラスタ内にインスンタンスタイプ混在ができる → 本番ワークロードで少しずつ試せる (速いかは微妙だったが) 安い (約10%Off) Auroraは高額になりがちなので移行メリットが大きい
R5.8xlarge 5.60USD/h → R6.8xlarge 5.012USD/h MySQL5.6互換はそろそろ EoL なのでまだの人は頑張って移行しましょう MySQL8.0互換も出ています(2021/11/18リリース)
Graviton2 Lambda 2021/09 リリース Amazon2 LinuxベースのRuntimeでGravion2が利用可能に カヤックの自社プロダクトの場合 Lambda では主にGoを使っている Goを使える人が多い
言語ランタイムでは頻繁なアップデートが必要になりがち Goはビルド済みバイナリをzipに入れるだけなのでランタイムに依存しない (まったくしないわけではないが影響は受けづらい) go1.x ランタイム は Amazon Linux 1 ベース Graviton2 を使う場合は provided.al2 ランタイムで
Graviton2 Lambda with Go Build github.com/aws/aws-lamda-go 1.18 以降を使う go1.x /
provided.al2 どちらにも対応できる GOOS=linux GOARCH=arm64 でビルドする できたバイナリを bootstrap というファイル名で zip に入れる (Lambda カスタムランタイムの仕様)
Graviton2 Lambda with Go Deploy github.com/fujiwara/lambroll はGraviton2リリース後、即対応済み(v0.12〜) 設定ファイル(function.json)に Architectures 要素を追加
Runtime: provided.al2 を指定 // function.json { "Architectures": [ "arm64" ], "Runtime": "provided.al2", // ... } これだけで Graviton2 対応 Lambda に!
Graviton2 Lambda まとめ 安い (GB-秒単価 25% off) 性能差は観測できていない (CPU boundな処理をしないので)
Go ならビルド時の環境変数の設定変更のみ 既存関数もArchitecturesを設定変更できる。気軽に移行可能
Graviton2 Fargate まだ Graviton2 対応は来ていない 2021/11/24 にリリース!! タスク定義の runtimePlatform を指定すると
Graviton2 で動く { // ... "runtimePlatform": { "cpuArchitecture": "ARM64", // X86_64 "operatingSystemFamily": "LINUX" }, } 当然ですが Image を Arm 用にビルドする必要あり $ docker buildx build --platform=linux/arm64,linux/amd64 .
Graviton2 Fargate Deploy github.com/kayac/ecspresso では v1.7.0(2021-10-30リリース)で対応済み 2021-10-30リリース ← 一ヶ月前? 実は
Windows Containers サポート時点で SDK に対応が入っていた
Graviton2 Fargate まとめ 安い (CPUもメモリも20%Off) vCPU/hour $0.05056 → $0.04045 GB/hour
$0.00553 → $0.00442 (性能評価はまだ) 数タスク起動したら… (2021/11/25時点、ap-northeast-1) Capacity is unavailable at this time. Please try again later or in a different availability zone イメージのビルドとテストを ARM64 で回す必要がある とはいえ、もはやハードルはそこだけ?
まとめ Graviton2 はマネージドサービスで気軽に始められます ElastiCache, Aurora は使う側としては何も変わらない 確実に安い (5%〜20%) 速い…かどうかは要検証 リソースの潤沢さは…(使う人が多くなれば増えるはず)
Lambda, Fargate も Graviton2 対応 アプリケーションの Arm 化も今後は気軽に進められそう