AWS Summit Japan 2024

すでにご存知の方も多いと思いますが、このAWS SummitというイベントはAWSに関する日本最大級の技術イベントで、全国のAWSを活用している数々の企業やユーザーコミュニティが一堂に会するものとなっています。

オフラインだけでなく、オンラインでも参加が可能で、 7/5(金)まで100以上のセッションがオンデマンド配信されています。

気になる方は是非下記リンクからご覧になってください。

aws.amazon.com

私は、今年も現地参加してきました。ここからは、AWS Summit Japan 2024で今年特に注目されていたトピックと、聴講したセッションの中で気になったものについて共有していきたいと思います。

今年のトピック

昨年から引き続き、AIや機械学習に関するセッションが多かった印象ですが、今年はさらに生成AIに関するセッションが多くなっている印象を受けました。

基調講演の中でもBedrockにおけるClaude 3ファミリーの東京リージョンでの提供開始が大々的に発表されていたりと、かなり生成AIに関するトピックが盛り上がっていました。

また、来場者数で見てみても、おそらく近年のAWS Summitの来場者数の中で最も多かったのではないでしょうか。

初日の入場列も長蛇の列（入場まで15分〜20分くらいかかった気がする）となっており、クラウドに関する関心が非常に高まっていることを肌で感じました。そのため、生成AIといったホットなTopicも多くある一方で、クラウド移行や業務効率化といったモダナイゼーションに関するブースやセッションも多くあり、より多くの方にリーチした内容となっていました。

気になったセッションのご紹介

聴講したセッションの中でも、特に気になったトピックの一部についてご紹介します。

① Dive deep on Amazon S3

本セッションでは、S3のパフォーマンスを最大化するためのTipsや、最近リリースされていたExpress One Zoneについても詳しく紹介がありました。

docs.aws.amazon.com

本セッションの資料はこちらになります。

適切なプレフィックスの付け方

S3には350兆のオブジェクトが保存されており、毎秒1億件以上のリクエストを処理する必要がある
特定のインデックスにアクセスが集中してしまうと、自動的に処理を分散するように実装されている
- ただし、それでも限界があるため、ユーザー側で事前にアクセス分散ができるような実装をしておくと良い
- これにプレフィックスという概念を使う
プレフィックスは以下のようなフォルダのような概念のこと（厳密にはフォルダではない）
- sample-bucket/p , sample-bucket/prefix , sample-bucket/prefix1/data
- ただ、実態としてはフォルダ構造にはなっておらず、全てのデータがフラットに保存されている
- つまり、いくらプレフィックスを丁寧に分割したとしてもレイテンシーには影響しない
適切なプレフィックス定義（キー名）によって、TPS（Transactions Per Second）を最大化することができる
- TPSとは秒あたりのトランザクション数を指すもので、S3バケット内で行われる読み取り（GET）、書き込み（PUT）、削除（DELETE）などの操作の数を測定する指標
- S3のパフォーマンスとスケーラビリティを評価するために重要で、高いTPSは、システムが多くのリクエストを効率的に処理できることを意味する
- ポイントとしては以下の２つ
  - できるだけカーディナリティの高いキー名は左側に寄せる
  - 日付は右側に寄せる
  - 例）sample-bucket/prefix/data/2024/06/25

S3 Express One Zone

今までのS3はGeneral Purpose Bucketsといい、3AZ以上のマルチAZでデータが保存されていることがデフォルトとなっている
- プレフィックス単位でスケールする
- 負荷によって段階的にTPSが増えていき、パフォーマンスが最適化されていく
- 各バケットとの通信においては、IAMを用いた認証認可を行う必要がある
Express One ZoneはDirectory Bucketというもので、シングルAZでデータが保存されている
- バケット単位でスケールする
- 初めから一定のパフォーマンスを提供することができる
- セッション単位で認証認可を行うため、セッションが張られている中では認証認可は行われない
- つまり、シングルAZではあるもののレイテンシーが向上するものになっている
- 機械学習などのジョブの時間を短縮することができたり、I/O性能が向上することでGPUが待機状態になる時間を減らすことができる

所感

Dive deepという題名に相応しく、あまり知る機会のなかったS3の運用Tipsを知ることができて非常に良かったです。聞き終わった周りの方からも「これを聞けただけで今年のSummitに来てよかった」という声が聞こえたほどでした。

また、最近リリースされていたExpress One Zoneについてもあまり用途が理解しきれていなかったので、本セッションを通して理解を深めることができました。

② Amazon EKS + Karpenterで始めるスケーラブルな基盤作り

こちらのセッションでは、Amazon EKSのNodeのスケーリングに使用されるCluster Autoscalerと比較した際のKarpenterのメリットや、Cluster Autoscalerからの移行方法などが紹介されていました。

Cluster Autoscalerの課題

NodeのオートスケールとしてCluster Autoscalerを使っている場合、ノードグループを複数作らなければいけなかったりとコスト最適化がしづらいのが課題点としてある
Cluster Autoscaler で運用する際の課題
- ノードグループの属性（vCPU, Mem, AZ, on-demand, Spot etc）をノードグループで揃える必要がある
- そのため、Podの要求に応じて複数のノードグループを作成し管理する必要がある

Karpenterの特徴

Karpenterでは、ノードグループ（Auto Scaling Group）を叩くのではなく、直接ノード（EC2 Fleet）を叩くため、ノードの属性を完全一致させる必要がない
そのため、様々なPod要求に対応することが可能になるため、EC2コストが最適な状況を作りやすくなる
Spotインスタンスも使える
- ただし、Spotインスタンスを優先的に起動してしまう点に注意が必要
- オンデマンドインスタンスを示すラベルを使用して、LabelSelector経由でノードをデプロイするなどの工夫が必要
リソースを使い余しているPodを最適なインスタンスタイプで再起動する Consolidation という機能もある
- ただし、長時間実行が行われるようなJobがノードの削除に巻き込まれないようにする工夫が必要
- karpenter.sh/do-not-disrupt: "true" のようなラベルを使用することで、それを回避できる
- SpotはデフォルトではConsolidationに対応していない
Karpenterの設定
- NodePool
  - Karpenterが作成可能なノードの条件
  - CPUアーキテクチャ , OS , EC2購入オプション, インスタンスファミリーを指定する
- EC2NodeClass
  - NodePoolが起動するAmazon EC2の設定
  - これが起動テンプレートに該当するもので、AMIや検出ロジック（SelectorTerms）などを指定する

Cluster AutoscalerからKarpenterへ

以下はやるべきことの概要

権限まわりの設定
AWSリソースに対するタグ付け
- サブネット
- セキュリティグループ
Karpenterの設定作成
EC2のイベント取得用リソース作成
- SQSの構築
- EventBridgeの構築
- これはスポットインスタンスのTermination Handlingに使用する
Karpenterのデプロイ、設定の適用、ロールのアタッチ
- Karpenterが管理するノードにKarpenter Podを配置するのは非推奨である点に注意
Cluster AutoscalerのPodをシャットダウン
- Cluster AutoscalerとKarpenterが同時にアクションする恐れがあるため、注意が必要
Managed Node Groupで管理するEC2の数を削減