気軽に始めるGraviton2マネージドサービスによるコスト最適化 / Amazon Game Tech Night #23

https://gamingtechnight.connpass.com/event/230933/

Transcript

1. 気軽に始める Graviton2
   マネージドサービスによるコスト最適化
   2021.11.25 Amazon Game Tech Night #23
   ゲームワークロードにおけるコスト最適化
   面白法人カヤック 藤原俊一郎 @fujiwara
   

   View Slide

2. @fujiwara
   SREチーム - 自社サービスを主に担当
   ISUCON 11優勝
   github.com/kayac/ecspresso
   Amazon ECS デプロイツール
   github.com/fujiwara/lambroll
   AWS Lambda デプロイツール
   

   View Slide

3. Game & Community
   

   View Slide

4. Graviton2
   AWS により 64-bit の Arm Neoverse コアを使用してカスタム構成されたプロセッサ
   Arm CPU は Intel(AMD64)CPUとはバイナリ互換性がない
   当然、OSもアプリケーションもArm用にビルドされたものでないと動かない
   正直、全然気軽ではない
   でも速くて安いらしい!
   比較し得る現行世代の x86 ベースインスタンスより最大で 40% 向上したコストパフォ
   ーマンスを発揮します。
   aws.amazon.com/jp/ec2/graviton/
   

   View Slide

5. マネージドサービスで『気軽に始める』Graviton2
   自分でOSやアプリケーションを動かすのはArm用のビルドが必要でちょっと大変
   OSやアプリケーションを自分で動かさなければ気軽に使えるのでは?
   → AWSのマネージドサービスで Graviton2
   気軽に「速くて安い」恩恵を受けられる！？
   今日は ElastiCache, Aurora, Lambda, Fargate について話します
   

   View Slide

6. Graviton2 ElastiCache Redis
   2020/11 リリース
   2020/11 とあるサービスで R5.large → R6g.large に切り替え
   動機「使ってみたかったから」
   

   View Slide

7. Graviton2 ElastiCache Redis の移行方法
   同一 Replication Group 内に異なるインスタンスを混在できない
   ReaderとしてGraviton2インスタンスを追加→Failoverで切り替え、などは不可
   サービスをメンテナンスに
   snapshot を作成
   snapshot からレストア
   ダウンタイムがそれなりに大きくなる(数十分程度)ので無停止移行は難しい
   

   View Slide

8. Graviton2 ElastiCache Redis 移行した結果
   コマンドのレイテンシが明らかに下がっている = 速い！ (CPU使用率も微減)
   r5.large 0.259USD/hour → r6g.large 0.247USD/hour = 安い! (5%ですが)
   

   View Slide

9. 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/
   

   View Slide

10. Graviton2 Aurora MySQL
    2021/03 リリース
    弊社の構成において、Aurora(RDS)のコスト比率は高い(全体の約25%)
    ここを削減できると効果が高い
    

    View Slide

11. 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 インスタンス
    

    View Slide

12. MySQL 5.6 → 5.7 アプリケーションの対応
    5.7 にしてとりあえずCIを回す
    落ちたテストを直す
    GROUP BY で ORDER BY していないクエリで返却順が変わったとか
    テストがカバーし切れてないところは別途QAで
    Perlで10万行以上のアプリケーション(ぼくらの甲子園！ポケット, Lobi)
    どちらも数カ所の修正でいけた
    実際のDBをテストに使っている場合、そこまで大変ではないはず
    

    View Slide

13. Aurora MySQL 1 → Aurora MySQL 2
    移行方法はいくつかあるので、要件に応じて選択
    1. in place upgrade - 既存のクラスタをそのままアップグレード
    お手軽 (マネコンポチー)
    ダウンタイムが大きい
    何かあった場合に戻すのが面倒
    2. snapshot からのレストア - 別クラスタに復元→切り替え
    元のクラスタはそのまま残っているので切り戻しが楽
    Graviton2 移行も同時にできる
    snapshot取得 → 起動までのダウンタイムはやはり大きい
    3. snapshot からレストア + binlogレプリケーション
    ダウンタイムが一番短い (レプリケーション停止→アクセス先変更だけ)
    Graviton2 移行も同時にできる
    面倒くさい
    

    View Slide

14. Aurora MySQL 1 → Aurora MySQL 2 であったこと
    Auroraクラスタが本番系に3個あるプロダクト
    安全性と手間のバランスを考えて、2. snapshotから別クラスタ復元を選択
    事前に複製したクラスタでsnapshotからの復元時間を検証(3個同時)
    1時間程度ですべて終わることを確認
    実際にサービスをメンテナンスに入れてアップグレードすることに
    メンテナンス時間は余裕を見て設定
    3クラスタ同時に復元開始
    なぜか2クラスタしか進まない (事前検証と違う!?)
    2クラスタの復元が終わった途端に残りの1クラスタが進行開始
    ここでメンテ時間を突き抜けたので切り戻し…(後日binlogレプリでやり直しました)
    

    View Slide

15. View Slide

16. Aurora R5 インスタンス → R6g インスタンス 移行
    同一クラスタ内に異種インスタンスを混在できる
    いきなりインスタンスタイプを変更してもいいが、慎重にするなら…
    1. Reader として R6g インスタンスを追加
    2. Reader Endpoint を使ってクエリを振り分けて様子見
    3. 問題なければ順次 Reader のインスタンスタイプ変更
    4. 最後に failover
    注意: カスタムエンドポイントのメンバーを「変更」すると
    変更中に名前が引けないダウンタイムが発生してつらい目に遭います
    必ず別のカスタムエンドポイントを作って切り替えること
    

    View Slide

17. View Slide

18. Graviton2 Aurora
    R6g が起動できないAZ
    インスタンスを 3AZ に分散していた
    とある AZ で R6g.8xlarge が起動できな
    かった
    毎朝起動チャレンジ → 失敗
    一週間繰り返したが無理だったの
    で諦めて一時的に 2AZ 運用
    

    View Slide

19. Graviton2 Aurora であったこと
    Aurora 2.10.0 → 2.10.1 へのバージョンアップが R6g/T4g 混在クラスタで失敗
    R6g のみにしたらできた
    → サポートで本来はできるはずだができない問題と確認 (修正されました)
    T4g の RI(Reserved Instance) が買えない (2021/11/24時点)
    まだ出たばかりなのでいろいろありそう
    サポートを積極的に使っていきましょう
    

    View Slide

20. Graviton2 Aurora まとめ
    クラスタ内にインスンタンスタイプ混在ができる
    → 本番ワークロードで少しずつ試せる
    (速いかは微妙だったが) 安い (約10%Off)
    Auroraは高額になりがちなので移行メリットが大きい
    R5.8xlarge 5.60USD/h → R6.8xlarge 5.012USD/h
    MySQL5.6互換はそろそろ EoL なのでまだの人は頑張って移行しましょう
    MySQL8.0互換も出ています(2021/11/18リリース)
    

    View Slide

21. Graviton2 Lambda
    2021/09 リリース
    Amazon2 LinuxベースのRuntimeでGravion2が利用可能に
    カヤックの自社プロダクトの場合 Lambda では主にGoを使っている
    Goを使える人が多い
    言語ランタイムでは頻繁なアップデートが必要になりがち
    Goはビルド済みバイナリをzipに入れるだけなのでランタイムに依存しない
    (まったくしないわけではないが影響は受けづらい)
    go1.x ランタイム は Amazon Linux 1 ベース
    Graviton2 を使う場合は provided.al2 ランタイムで
    

    View Slide

22. Graviton2 Lambda with Go Build
    github.com/aws/aws-lamda-go 1.18 以降を使う
    go1.x / provided.al2 どちらにも対応できる
    GOOS=linux GOARCH=arm64
    でビルドする
    できたバイナリを bootstrap
    というファイル名で zip に入れる
    (Lambda カスタムランタイムの仕様)
    

    View Slide

23. 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 に！
    

    View Slide

24. Graviton2 Lambda まとめ
    安い (GB-秒単価 25% off)
    性能差は観測できていない (CPU boundな処理をしないので)
    Go ならビルド時の環境変数の設定変更のみ
    既存関数もArchitecturesを設定変更できる。気軽に移行可能
    

    View Slide

25. 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 .
    
    

    View Slide

26. Graviton2 Fargate Deploy
    github.com/kayac/ecspresso では v1.7.0(2021-10-30リリース)で対応済み
    2021-10-30リリース ← 一ヶ月前?
    実は Windows Containers サポート時点で SDK に対応が入っていた
    

    View Slide

27. 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 で回す必要がある
    とはいえ、もはやハードルはそこだけ?
    

    View Slide

28. まとめ
    Graviton2 はマネージドサービスで気軽に始められます
    ElastiCache, Aurora は使う側としては何も変わらない
    確実に安い (5%〜20%)
    速い…かどうかは要検証
    リソースの潤沢さは…(使う人が多くなれば増えるはず)
    Lambda, Fargate も Graviton2 対応
    アプリケーションの Arm 化も今後は気軽に進められそう
    

    View Slide