こんにちは。SRE部 ECプラットフォーム基盤SREブロックの高塚です。
11/28〜12/2に開催されたAWS re:Invent 2022に、ZOZOのエンジニア10名が参加しました。アドベントカレンダーの1日目ではHave Funイベントなどを紹介しましたが、この記事では現地の様子とセッションについてレポートします！
AWS re:Invent 2022とは
re:InventはAWS最大のカンファレンスです。2012年から毎年ラスベガスで開催されており、今年で11回目を迎えます。
2020年はオンライン開催のみで、2021年はマスク着用での開催でしたが、今年はマスクの着用義務がなくなり、いわば3年ぶりの通常開催でした。
今年も多くの新サービスや新機能が発表され、5日間で1500以上のセッションが行われています。セッションにはいくつかの形式があります。
| 形式 | 説明 |
|---|---|
| Keynote | 基調講演 |
| Breakout Session | 講義形式。登壇者はAWSの中の人、カスタマー、パートナーなど様々 |
| Chalk Talk | 登壇者と参加者がディスカッションする大学の講義のような形式 |
| Workshop | 参加者で少人数のグループを組み、テーマに沿って手を動かす形式 |
| Gamified Learning | ゲーム形式の参加型コンテンツ。GameDayやJamなど |
現地の様子
キャンパス（会場）は全部で6つあります。地図の黄色がキャンパスです。南北で4km以上離れているため、無料のシャトルバスが運行されています。
メインのキャンパスはベネチアン（地図の3）です。その隣のミラージュ（地図の8）に私たちは宿泊していましたが、ホテルの部屋からKeynote会場までは徒歩15分ほどかかりました。それほど各ホテルが巨大です。
Googleストリートビュー。正面がベネチアン、右後ろがミラージュです。
Keynote会場。1日目のMonday Night LIVEの様子です。
こちらはExpo。企業のブースがたくさん並びます。
Self-paced labs。自分のペースでAWSを学習できるコーナーです。
期間中は5つのキャンパスで朝食と昼食が提供されます。ビュッフェのほか、テイクアウトできるランチボックスも用意されていました。
食後のデザートもあります。
また、食事とは別に各所でコーヒーや軽食が配られていました。
こちらはAWS公式グッズのストア。
4日目の夜にはre:Inventを締めくくるパーティー「re:Play」があります。キャンパスから少し離れた特設会場で行われ、DJやバンドの演奏と、ドッジボールやアーチェリータグなどのアクティビティを楽しめます。下記は全員の集合写真。
セッション紹介
ここからは各メンバーが気になったセッションを1つずつ紹介します。
- Workshop
- Chalk Talk
- Breakout Session
- What's new and what's next with Amazon EKS (CON205)
- Architecting sustainably and reducing your AWS carbon footprint (SUS205)
- A close look at AWS Fargate and AWS App Runner (CON406)
- The future of sport: How Riot Games is reinventing remote esports broadcasts (CMP311)
- How to save costs and optimize Microsoft workloads on AWS (ENT205)
- Optimizing Amazon EKS for performance and cost on AWS (CON324)
Workshop
From serverful from serverless Java with AWS Lambda (SVS310)
計測プラットフォーム開発本部 計測システム部の児島です。私の所属する計測システム部は、今夏アメリカに向けてフィットネスアプリZOZOFITをリリースしました。その認証機構にはCognitoを採用したのですが、カスタム認証フローを利用するため、Lambdaのトリガー処理を書く必要がありました。
私たちのチームは、開発言語にScalaを採用しています。一方で、LambdaとJVMの組み合わせはコールドスタートの問題があり、相性はよくありません。かつて、Lambdaを使いたいケースでPythonを採用したこともありました。最近では、より軽量なGoなどの言語もあり、多くの開発の現場でLambdaのために開発言語を分けるという選択がとても多く見られる様になりました。しかし、私たちのチームは2つ以上の言語を維持運用するほどのチーム規模もなく、言語としてはScalaのまま、LambdaのカスタムランタイムでGraalVMを選択する意思決定をしました。
In this workshop, learn how to bring traditional Java Spring applications to AWS Lambda with minimal effort and iteratively apply optimizations to enhance your serverless Java experience. Hear about best practices, performance trade-offs, and design considerations for each step to help you make well-informed decisions when bringing enterprise Java applications to AWS Lambda.
今回のWorkshopに参加したきっかけは、このWorkshopの説明欄にあったこの一節がきっかけでした。私たちは、多くの世に出ている知見からGraalVMを採用する意思決定をしたわけですが、その他に取り得た手法の検証に十分な時間がありませんでした。そのため、改めてLambdaでJVMを採用する際の選択肢と、それらの比較、それぞれの選択に潜在するトレードオフに関する知見を得たいというモチベーションがありました。
ワークショップでは、まず初めに暫定的なAWSアカウントが与えられ、Cloud9に既に必要なコード群が事前に用意された状態で、Lambda等の必要なリソースのセットアップを済ませます。そして、Spring Bootをベースとした何も最適化されてないサンプルアプリケーションをLambdaで動かすことからはじめます。そこから、TieredCompilationの有効化、依存の軽量化などを経て、GraalVMの採用まで、様々な最適化を施していきます。その過程で、実際のコード変化を確認し、ビルドと実行を繰り返し、ベンチマークを確認していきます。
結果です。既知のものも含まれていましたが、今回のWorkshopを通してあらかじめ用意されたLambdaのパフォーマンス改善の追体験ができたことは、とても有意義な時間でした。
さて、この前日のKeynoteでは、Lambda Snapshotという更なるLambdaにJVM系言語の採用を後押しする新機能の発表がありました。今回のre:Inventの他のセッションを通しても、毎年AWSがサーバーレスへの移行をサポートする機能を強化していく実感があります。今後も、こうしたアプリケーション開発者が開発に集中しやすくなる技術のリリースに期待するとともに、引き続き注視していきたいです。
Data analysis with Amazon EKS and AWS Batch (CMP355-R)
計測システム部 SREブロックの纐纈です。
基調講演では今年新しくリリースされたサービスや機能が紹介されます。その中で、AWS BatchをEKS上で利用できるようになったという発表がありました。
まず、AWS Batchは2016年のre:Inventで発表された、バッチ処理の実行基盤のマネージドサービスです。処理すべきジョブに合わせてコンピューティングリソースの配分を自動で最適化するという特徴を持っています。今まではECSでの実行環境のみだったのですが、2022年10月から新しくEKSにも対応したとのことでした。ただ、2022年12月時点ではEKS Fargateには未対応なので注意が必要です。
今回私が参加したワークショップでは、AWS Batchを使ってAmazon EKS上でデータ分析のサンプルを動かしてみるという内容でした。2時間のワークショップの中で、前半はAWS BatchのEKS対応について概要や内部構造などの説明があり、後半はAWS Workshop Studioを使って手を動かします。EKSクラスタを立てて、PrometheusやGraphanaをデプロイし、円周率の計算をするバッチ処理でクラスタに負荷をかけながらリソースの変動を見るということもできました。
ワークショップの内容はこちらからも見ることができます。
catalog.us-east-1.prod.workshops.aws
Chalk Talk
Prevent unintended access with AWS IAM Access Analyzer policy validation (SEC319)
SRE部 ZOZO-SREブロックの鈴木です。
普段はZOZOTOWNの裏で動いているオンプレ、AWSにあるインフラの管理をするとともに社内のAWS管理者としてセキュリティ周りの対応や各種運用をしています。
今回私が参加したSEC319は「Chalk Talk」という形式のセッションです。スピーカの方がスライドを発表するだけでなく、横にホワイトボードが置かれており参加者も質問したりディスカッションしたりしながら、さながら大学の講義のように進んでいきます。動画配信がなく現地に行ったメンバーのみが参加できるセッションであり、現地へ行った優越感に浸れるおすすめのセッションです。発表頂いたスライドは資料欄にリンクを掲載しています。
本セッションではIAMポリシーのライフサイクルを定義し、その過程で安全なIAMポリシーを作成、メンテナンスしていくにはどうしたらいいかを議論しました。IAMポリシー作成過程の1つに「Validation」のステップがあり、ここで正しくポリシーを検証することが安全性を高める1つの手段となることを確認しました。そのValidationのツールとして「IAM Access Analyzer」が紹介され、実際にどのように使うかのデモをいただきました。
IAM Access Analyzerを利用する際のCI/CD構成例の1つに「CloudFormation hooks」を利用した例があげられました。参加者にはCloudFormation hooksを使っているか、どんなところで使っているのかという質問が投げかけられ、各社の真似したくなるような事例をいくつか聞くことができました。
- 資料
Breakout Session
What's new and what's next with Amazon EKS (CON205)
計測システム部 SREブロックの西郷です。
普段はZOZOMATやZOZOGLASS、ZOZOFITといった計測サービスの運用に携わっています。これらの基盤にはEKSを採用しているので、業務に活かせるものがあればと思い参加しました。
今回のセッションの中で気になったトピックとしては以下です。
- EKSクラスタのKubernetesバージョンアップデートにかかる平均時間の短縮
- 40分以上かかっていたものが10分少々にまで短縮された
- VPC Latticeのサポート
- VPC Latticeはre:Invent期間中に発表された新機能で、VPCの1機能
- L7のサービス間ネットワーク通信機能を提供するとのことで、サービスメッシュに近いものの印象
- サイドカーなしで利用でき、プロトコルはHTTP、HTTPSに加えgRPCもサポートしている
- VPCPeeringなしでアカウントおよびVPCを跨いだ接続が可能
- MarketplaceのソフトウェアとAWSによって開発されている主要なOSSのプロダクトをEKS add-onsがサポート
- re:Invent期間中に発表された新機能、EKS add-onsを通してEKSクラスタ内にデプロイ可能
- DatadogやNewRelic、KubernetesのポリシーエンジンであるKyvernoを提供するNirmata等がComing Soonなものとして上がっていた
これまでにも計測ではEKSクラスタのバージョンアップの省力化を進めてきたこともあり、Kubernetesバージョンアップ自体にかかる時間を短縮できることは大きなメリットになりそうです。
また、VPC Latticeはサイドカーなしで利用できるという点が魅力的です。現時点でサービスメッシュの利用はないものの、システムの成長に伴い検討していた背景もあるため、機会があれば検証してみたいと思っています。
※2022/12時点ではVPC Latticeはプレビュー機能です。
Architecting sustainably and reducing your AWS carbon footprint (SUS205)
SRE部 ECプラットフォームサービスSREブロックの佐藤です。普段はZOZOTOWNで使用されるマイクロサービスのインフラ構築と運用を担当しています。それ以外にも、チームをまたいだ活動としてクラウドサービスのコスト可視化・最適化にも取り組んでいます。
アダム・セリプスキーCEOのキーノートでもふれられていたようにサステナビリティは今年のre:Inventでも重要なテーマの1つでした。
本セッションは、AWSにおけるサステナビリティへの取り組みと、Amazon Prime Videoでの実例を紹介する内容になっています。コスト効率の良いシステムを考える上で、今後必須の知識になるであろうと思い、このセッションに参加しました。
セッション前半では、まずAmazonのサステナビリティに対する考えが述べられました。それから気候変動の対策に関する誓約であるThe Climate Pledgeや、データセンターで使用される100％再生エネルギーについて、ウォーターポジティブへの取り組みなどが紹介されました。Amazonのサステナビリティに対する取り組みは、下記のサイトで確認できます。
sustainability.aboutamazon.com
その中で、サステナビリティとは持続可能な未来というゴールへ向かうものではなく、永続的に繰り返す活動（セッションの中ではジャーニーと呼んでいました）であると解説していました。そのために適切なリソースを適切なタイミングで使用することが重要で、つまり効率化が中核をなす要素だと説明しており、日常的に自動化・効率化に励むSREにとって刺さる話でした。
また、Well-Architectedフレームワークから、リージョンを選ぶ基準としてレイテンシやコストに加えAmazonの再生エネルギープロジェクトに近い地域、または二酸化炭素排出量の少ない地域であるか検討するプラクティスや、よりエネルギー効率の良いインスタンスを継続的に使用するためのプラクティスの解説もありました。
後半ではAmazon Prime Videoにどのようにサステナビリティのカルチャーを取り入れ、システムの効率化を行ったのか、そのプロセスの紹介がありました。プロセスの概要は下記です。
- 目標を設定する
- 二酸化炭素の排出量削減に繋がる具体的なゴールを決める。例えばネットワーク負荷を減らすようなエンコードアルゴリズムやインフラリソースの最適化など。
- この時点で、この活動に必要なリソース確保をマネージャーレベルで調整する。
- 指標を設定する
- 自分たちのサービスがどれくらい二酸化炭素を排出しているかは、Customer Carbon Footprint Tool で確認できるが、より自分たちがコントロールしやすい代替指標（プロキシメトリクス）を定義する。例えば特定のワークロードにかかるインスタンス時間など。
- 反復的な改善プロセスを実行する
- ステップ1: 改善対象を特定する。例えば適切なインスタンスのサイジングなど。
- ステップ2: 改善点を評価する。AWS Compute Optimizerなどのツールを利用する。
- ステップ3: 優先順位をつけて計画を立てる。得られる成果をビジネス価値に置き換え判断材料とする。同時に、成果に関心を持つ財務や利害関係者への窓口を設置する。
- ステップ4: テストし検証する。単一ホストのみで動作させるなどして小規模に始める。本番トラフィックが流れない環境を用意してスケーリングもテストする。
- ステップ5: 本番環境にデプロイする。
- ステップ6: 結果を測定し、成功事例を別チームに展開する。
さらに、NFLの中継を独占配信した際に行われた取り組みが取り上げられていました。それは社内から効率化の専門家を集め、各サービスのコードとスタックについてパフォーマンスレビューをするというものです。これは現在弊社で行っている正月セールに向けた取り組みと重なる部分があり、案外こういう社内の関心が高いイベントのときこそ、周りを巻き込みやすいので新しい挑戦がしやすいのではと思いました。
またスパイク対策として、重要度の低い機能をオフにするコンティンジェンシースイッチと呼ばれる仕組みの導入や、クライアントサイドでのプリキャッシュについて説明がありました。これらは持続可能な方法でスケールできるようにデザインパターン化しているとのことでした。
セッション全体を通しての気づきは、我々が普段行っているパフォーマンスチューニングやコスト最適化は、実はサステナビリティな活動そのものだということです。そして業務にはコストやビジネス要件、コンプライアンスなど優先すべきことが多いですが、まずは同じ天秤に乗せるのが大切であると感じました。そうすることで、今後の設計や技術選定などにおいて別の観点が加わり、組織や社会にとってより良い判断ができると思いました。
A close look at AWS Fargate and AWS App Runner (CON406)
ブランドソリューション開発本部 バックエンド部の笹沢（@sasamuku）です。
Archana SrikantaさんよりAWS Fargateの裏側の仕組みが紹介されました。re:Invent 2019における同氏らの発表と重複する箇所もありましたが、今回はよりセキュリティと可用性に焦点を当てた内容となっていました。以下、抜粋してご紹介します。
前半はコンピューティングサービスの進化について説明がありました。Amazon EC2が主役だった頃と比較するとAWSの責任領域が次第に拡大しています。直近にリリースされたAWS App Runnerでは、ソースコードあるいはDockerイメージを用意して基本的な設定をするだけでスケーラブルなサービスを公開できます。
後半はセキュリティに関する興味深い話がありました。AWS Fargateはマルチテナントなサービスです。悪意あるユーザによって脆弱性を突かれれば他のユーザにも影響が出かねません。AWSは仮想的にハードウェアを分離することでこれを防止しています。具体的には、Firecrackerと呼ばれるMicro VMをタスク1つにつき1台用意しています。また、タスク間やベアメタルサーバ間の意図しない通信を許可していません。
他にもセルラーアーキテクチャと呼ばれるAWS Fargateの可用性に関する仕組みも紹介されていました。Amazon ECS on AWS FargateやAWS App Runnerを利用している方にはぜひおすすめしたいセッションの1つです。
The future of sport: How Riot Games is reinventing remote esports broadcasts (CMP311)
SRE部 ZOZOSREブロックの秋田です。オンプレとクラウドのハイブリットな環境を運用保守するチームに所属しています。
私は普段からesports観戦が好きで、特にRiot Gamesが出しているLegue of LegendsやVALORANTのタイトルをよく観戦しています。大会の裏側で全世界へどのようにして配信をしているか興味がありこのセッションを聴講することにしました。
このセッションでは、Riot Gamesが従来の配信方法からどのようにeスポーツの配信方法を進化させたか、どのように配信基盤を作成しているかという話がされました。
特に興味を引いたものがRiot Directです。世界中に専用のネットワークを有しており、オンライン対戦で使われるほか、配信でもこれが使われています。
Riot Directは以下のようなものになります。
- Riotのパケットに特化したケーブルとルーターを世界中に展開
- Cold-potato routing
- 世界中で数Tbpsの帯域が利用可能
- IXPやPNIを経由して世界の主要ISPにピアリング可能
- 独自のDDoS軽減ソリューションと既製品のDDoS軽減ソリューションの混在
また、このRiot Directですが3500以上ものBGPセッションが管理されており、様々な地域と拠点で相互接続することが可能になっています。
ZOZOTOWNのサービスとはかけ離れているセッションでしたが、普段は聞くことが出来ない世界トップゲームの話をリアルで聞けてとてもいい経験になりました。
How to save costs and optimize Microsoft workloads on AWS (ENT205)
SRE部 カート決済SREブロックの伊藤です。ZOZOTOWNはWindowsサーバーやSQL Serverを使用して稼働している箇所が多くあります。それらのコスト最適化の参考になればと本セッションを受講しました。
techblog.zozo.com techblog.zozo.com
一部を抜粋してご紹介させていただきます。
- FCI(Failover Cluster Instance)を構築する
- SQL Serverで高可用性を実現する方法としてAlwaysOnが使われがちではあるが、FCIを構築するという方法がある
- FCIの場合必要なSQL Serverのライセンスは1つだけであり、コストを抑えることができる
- EC2のCPUオプションを指定する
- メモリを多く使用したいが、CPUはそこまで必要ないなど一致するインスタンスが存在しない場合にvCPUの数を抑えることができる
- インスタンス自体のコストは変わらないが、SQL Serverなどコア単位でライセンス量が変わってくる場合にコストを抑えることができる
- 具体的にはr5.2xlarge(8core, 64GB)を選んでvCPUを4coreに抑えると40％の節約となる
その他、NitroSystemであるが故にリソースを効率良く利用できることや、既存環境を分析してレポートしてくれる OLA(Optimization and Licensing Assessment) に関しての説明などがありました。
Optimizing Amazon EKS for performance and cost on AWS (CON324)
SRE部 ECプラットフォームサービスSREブロックの三品です。普段の業務でEKSを利用しているので、EKSのコスト最適化に関するこちらのセッションに参加しました。
前半はKubernetesのコスト監視の難しさと、どのようなところでコストが発生しやすいかについて解説されていました。前半の最後には、Kubernetesのコストをどのように可視化したら良いかが述べられていました。
後半では、コストを最適化するためにはどうしたら良いかについて解説されていました。具体的にはAWS Gravitonインスタンス、EC2 Spot、Karpenterについて実際の企業事例を踏まえて紹介されていました。
- AWS Gravitonインスタンス
- AWS Gravitonインスタンスの特徴（一部抜粋）
- C7gインスタンスは、計算集約型のワークフローに最適な価格性能を提供しています
- 同クラスのEC2インスタンスと比較して60％エネルギー効率化されています
- （注意）AWS Gravitonインスタンスを利用するためには、ARM互換のイメージを作成する必要があります
- EC2 Spot
- EC2 Spotの特徴（一部抜粋）
- インスタンスタイプの種類やAZを増やすことでSpotの可用性が向上し、中断が少なくなくなります
- 時間に融通の効くワークロードは、空き容量を待つことができるのでEC2 Spotは最適です
- EC2 Spotは短期間の中断可能なワークロードに適しており、逆に長時間稼働するようなJobやstatefulなワークロードには適していません
- Karpenter
- Karpenterの特徴（一部抜粋）
- EC2 SpotやAWS GravitonインスタンスなどをKubernetesネイティブに統合しています
- ノードの起動を高速化することでコストを最小限に抑えることができます
- オペレーションのオーバーヘッドを削減することによって開発者はサービス開発/運用に集中できます
個人的には、前半で紹介されたkubecostに興味を持ちました。まずはkubecostを導入して適切なリソースを割り当てられているかを確認することが、コスト最適化の糸口を探すことになるはずなので、検証してみたいと思います。
おわりに
re:Inventは多くのセッションをオンラインでも視聴できます。それにも関わらず、わざわざ現地参加する価値とはなんでしょうか？
会場をキャンパスと呼ぶとおり、re:Inventは学習型のカンファレンスです。しかし、その雰囲気はまるで「お祭り」です。AWSの大好きな人々が世界中から集まり、皆で学び合い、熱く語らう「お祭り」です。この盛り上がりは現地でしか感じられません。
また、WorkshopやChalk Talkなどの体験型セッションが豊富で、そこに集まる参加者のレベルも高く、濃密な知見を得られます。AWSやパートナー企業のエンジニアと直接話せる貴重な機会でもあります。
もちろん、オンライン参加でも多くの学びを得られると思います。KeynoteやBreakout Sessionは1つ1つのクオリティがとても高く、たくさんの新情報を含んでいます。
でも、この刺激、特に他のエンジニアから受ける刺激は、ラスベガス現地でしか味わえないと確信します。この刺激を求め、私たちは来年もre:Inventに参加するはずです。
今回得た知見と刺激を社内外に共有しながら、これからもAWSを活用してプロダクトとビジネスの成長を支えていきます！
ZOZOではAWSが大好きなエンジニアを募集しています。奮ってご応募ください。
最後に、ラスベガスでお世話になった方々へ御礼申し上げます。ありがとうございました。
