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
「最高のチューニング」をしないために / hack@delta 24.10
fujiwara3
21
3.4k
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
8
4.1k
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
2
1.3k
awslim - Goで実装された高速なAWS CLIの代替品を作った/layerx.go#1
fujiwara3
6
710
AWS CLIの起動が重くてつらいので aws-sdk-client-go を書いた / kamakura.go#6
fujiwara3
7
9.9k
コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地
fujiwara3
31
7k
fujiwara-ware OSSをひたすら紹介する/ya8-2024
fujiwara3
8
750
Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024
fujiwara3
25
8.4k
リアル事例から読み解くWebパフォーマンスチューニングの勘所/Offers web performance tuning
fujiwara3
6
1.8k
Other Decks in Technology
See All in Technology
初心者に Vue.js を 教えるには
tsukuha
5
390
WINTICKETアプリで実現した高可用性と高速リリースを支えるエコシステム / winticket-eco-system
cyberagentdevelopers
PRO
1
190
「視座」の上げ方が成人発達理論にわかりやすくまとまってた / think_ perspective_hidden_dimensions
shuzon
2
3.6k
バクラクにおける可観測性向上の取り組み
yuu26
3
420
Aurora_BlueGreenDeploymentsやってみた
tsukasa_ishimaru
1
120
生成AIの強みと弱みを理解して、生成AIがもたらすパワーをプロダクトの価値へ繋げるために実践したこと / advance-ai-generating
cyberagentdevelopers
PRO
1
180
わたしとトラックポイント / TrackPoint tips
masahirokawahara
1
240
ガバメントクラウド先行事業中間報告を読み解く
sugiim
1
1.3k
生成AIと知識グラフの相互利用に基づく文書解析
koujikozaki
1
140
AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book
iselegant
15
4k
ABEMA のコンテンツ制作を最適化!生成 AI x クラウド映像編集システム / abema-ai-editor
cyberagentdevelopers
PRO
1
180
CyberAgent 生成AI Deep Dive with Amazon Web Services / genai-aws
cyberagentdevelopers
PRO
1
480
Featured
See All Featured
Optimizing for Happiness
mojombo
376
69k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Thoughts on Productivity
jonyablonski
67
4.3k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
Building Applications with DynamoDB
mza
90
6.1k
Git: the NoSQL Database
bkeepers
PRO
425
64k
Building Your Own Lightsaber
phodgson
102
6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
Building Adaptive Systems
keathley
38
2.2k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
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 化も今後は気軽に進められそう