こんにちは。アイレットの土田です。
re:Invent 2022 現地にて、Netflix による Breakout Session を受けてきました。
テーマは、Amazon EC2 の Capacity planning について。
Netflix がこの辺りについて、どのように考えているか興味があったのでレポートにまとめました。
セッション概要
AWS offers hundreds of different types of Amazon EC2 options, and Netflix has a multitude of different stateful and stateless workloads that need different combinations of CPU, RAM, disk, and network. In this session, learn how Netflix uses a service capacity modeling system to optimally consume Amazon EC2 to run a variety of uncertain workloads ranging from Cassandra databases to stateless Java applications.
AWSは何百種類ものAmazon EC2オプションを提供しており、NetflixはCPU、RAM、ディスク、ネットワークの異なる組み合わせを必要とする多数の異なるステートフルおよびステートレスワークロードを持っています。このセッションでは、Netflixがサービスキャパシティモデリングシステムを使用して、CassandraデータベースからステートレスJavaアプリケーションまで、さまざまな不確実なワークロードを実行するためにAmazon EC2を最適に利用する方法について学びます。
- Session title : Capacity plan optimally in the cloud #NFX304
- Session level : 300 – Advanced
- Session type : Breakout Session
- Services : Amazon EC2, Amazon EC2 Auto Scaling
- Area of Interest : Cost Optimization, Customer Stories, Netflix
- Speakers：
・ Joseph Lynch, Principal Software Engineer, Netflix
・ Prateek Sharma, Senior Solutions Architect, AWS
セッション内容
登壇者の紹介
- Joseph Lynch 氏は、Netflix のデータプラットフォームチームで働くプリンシパルソフトウェアエンジニア。
- 彼はオープンソースコミュニティでも非常にアクティブで、Apache Cassandra のような多くの有名なオープンソースプロジェクトに貢献している。
- Joseph 氏と彼のチームは、データベースシステムからステートレス Java アプリケーションまで、あらゆるワークロードに対して最適なリソースを選択する方法をモデル化するシステムを作った。
概要
- Netflix では確立されたモデルに基づいて、EC2 の Capacity planning を立てている。
- 各インスタンスタイプの性能を測定し、方程式に当てはめて、最適なリソースを選択している。
- 計画を立てるだけでなく、正しい選択をしているかどうかを監視することも大切（SLO の観点）。
- このモデルはどの状況にも適用可能ではなく、あくまで「Netflix にとっては有用」という位置付け。
- 本セッションで説明されたモデルのコードは、GitHub に公開されている。
・ https://github.com/Netflix-Skunkworks/service-capacity-modeling
方程式について
- Capacity modeling では、この方程式が中心になる。
- <式の左側> ワークロードキャパシティモデルには、以下の3つの構成要素がある。
・ User Desire（ユーザーが望むもの）
・ Hardware Profile（データベースの種類や容量などの情報）
・ Current Pricing and Lifecycle（そのハードウェアに対する現在の価格とライフサイクル） - <式の右側> 上記を基にして、候補となるクラスタを出力する。
・ そうすることで、最適なリソースを提供するための具体的なインスタンスタイプを選択することができる。
Hardware
- インスタンスタイプには、世代、サイズ、クラス、アーキテクチャの違いなど様々な選択肢がある。
・ 一見すると、「うわー、いろいろ選べそうだな！」と思うかもしれない。
・ 実際には「みんなは何を使っているんだろう」とググって、インスタンスタイプを選んでいるのでは？
・ しかし、それはハードウェアを購入するベストな方法とは言えない。
・ だから、理論に基づいたモデルが必要。 - ハードウェアの構成要素を分けて考えて、本当に必要なリソースを選択することが大切。
- 例えば4つの構成要素のうち、大まかに2種類に分けられる。
・ Capacity と Latency は、性能を測定して比較検討が可能。
・ Lifecycle と Price は、利用者によって定義(捉え方)が異なる。
ハードウェアのライフサイクル
- Netflix では、ハードウェア（インスタンスタイプ）のライフサイクルを5つに区分している。
・ Alpha : 新しく最初に導入されたハードウェア。本番環境での使用は勧めない。
・ Beta, Stable : 一般的な開発者は、この時点でハードウェアを目にする（利用可能になる）。
・ Deprecated, End of life : これらを使用対象から除外することで、選択肢の大部分を考えなくて済むようになる。 - Netflix としては、数年の予約購入ができるようになってから、特定のインスタンスタイプを本番環境で使い始めている。
Service Tier
- Netflix では、Service Tier をこのようなイメージで捉えている。
・ Service Tier は言い換えると「このクラスタ(インスタンス)が失敗したら、あなたはどれだけ悲しいか」ということ。
・ また、それはどれだけ過剰なプロビジョニングをするかという問題とトレードオフである。
・ 「夜中の2時に起こされないようにするために、どれだけのお金をこの問題に投じたいか」 - 例えば…
・ Tier0 の場合は、本番用のワークロードがそれに該当する。より多くのお金をかけるべき。
・ Tier3 の場合は、テスト用でワークロードを気にする人はいない。お金を節約してコスト削減に繋げられる。
結論
- 最も後悔の少ない選択をするために、まずハードウェアについて理解することが大切である。
- 複雑なモデリングを行なったとしても、間違った選択をすることがあることを理解しておく。
- 自分たちの選択を監視して、必要なリソースよりも多くのお金をかけることが大事（特に本番環境において）。
感想
- 全体を通して、終始理論に基づいて至極真っ当なことを話されていて、とても刺激的でした。
- 最初は「どんな基準でインスタンスタイプを決めているんだろう」と単純な興味でセッションに参加しましたが、蓋を開けてみると徹底した性能計測と複雑な計算式の応酬で面食らったのは事実…。
- 方程式の答えを導き出すための計算まではついていけない部分も多く、簡単に真似できるものではないですが、考え方を知れたのはよかったです。
- 「インスタンスタイプは惰性で選びがち」とか「夜中の2時に起こされないようにするために、どれだけのお金をかけられるか」というようなリアルな表現や例え話が分かりやすく、専門的な内容であっても身近に感じられました。
- 新しいインスタンスタイプが続々と発表される中で、適切な選択を行なっていくことは今後も重要になっていくと考えているため、普段の業務でも意識していけたらと思います。
