EC2-Classicとの別れ、素晴らしい時間でした
(allthingsdistributed.com)- AWSは2023年8月15日にEC2-Classicの最後のインスタンスを終了し、2006年のEC2リリース時に始まった初期クラウドコンピュートモデルの運用を終えた
- Classicの中核は10.0.0.0/8の単一フラットネットワークであり、複雑な内部実装を隠しつつコンピュート確保を単純化した点が当時の革新だった
- 2006年のm1.smallは、1.7GHz Xeon相当のvCPU、1.75GB RAM、160GBローカルディスク、250Mb/sネットワークを時間あたり**$0.10**で提供し、その後EC2はP3dn.24xlargeのような大型インスタンスへと拡張した
- Elastic IP、Auto Scaling、Load Balancing、CloudWatchと新しいインスタンスタイプが追加され、2013年にはVPCが顧客ごとに分離・定義可能なクラウド領域の新しい標準となった
- ClassicはNitroのような新しい仮想化プラットフォームの登場後も顧客利用のためにさらに10年維持され、すべてのインスタンスが終了または移行されるまでドキュメント・ツール・サポートが提供された
EC2-Classic終了と初期構造
- AWSは顧客ビジネスが依存するサービスを終了する際、慎重に対応してきた
- SimpleDBは、DynamoDBが顧客の「NoSQL」DB選択肢として定着した後も引き続き提供されている
- Jeff BarrによるEC2-Classic終了予告から2年が経ち、2023年8月15日にClassicの最後のインスタンスが終了した
- EC2はおよそ17年間運用されており、AWSサービスの中でEC2より古いのはSQSとS3だけである
- 「Classic」を分ける最大の要素はネットワークアーキテクチャだった
- 2006年のEC2は10.0.0.0/8という1つの巨大なネットワークとして始まった
- すべてのインスタンスが他の顧客と共有する単一フラットネットワーク上で動作していた
- セキュリティグループや、インスタンス起動時に割り当てられるPublic IPのような機能を提供していた
- 内部スタックは非常に複雑だったが、ユーザーは必要なコンピュートをシンプルに確保できた
インスタンス性能の変化
- 2006年にm1.smallインスタンスを実行すると、次の構成を利用できた
- 1.7GHz Xeonプロセッサ相当の仮想CPU
- 1.75GB RAM
- 160GBローカルディスク
- 250Mb/sネットワーク帯域幅
- 時間あたり**$0.10**
- その後EC2はP3dn.24xlargeのようなインスタンスへと拡張した
- 100Gbpsのネットワークスループット
- 96 vCPU
- 32GiBメモリを備えたNVIDIA v100 Tensor Core GPU 8基
- 768GiBシステムメモリ
- 1.8TBローカルSSDストレージ
- MLワークロード高速化のためのEFA
- EC2-Classicはハードウェアをプログラム可能なリソースへと変え、開発者・創業者・スタートアップ・エンタープライズが必要なときに必要なだけコンピュートを使えるようにした
- インフラ管理、新しいハードウェア購入、ソフトウェアアップグレード、故障したディスク交換といった複雑さが抽象化された
VPC移行と長期サポート
- このブログはEC2リリース直後にm1.smallへ移行され、Moveable Typeとローカルデータベースを動かしていた
- その後、RDSのフェイルオーバーなどを備えた高可用性サービスへと変わった
- 2011年にAmazon S3 Website機能がリリースされた後、S3ベースへ移行した
- その後12年間「serverless」な状態で運用された
- 顧客要件の増加に伴い、Elastic IP、Auto Scaling、Load Balancing、CloudWatch、さまざまな新規インスタンスタイプが追加された
- 2013年にVPCが有効化され、各AWS顧客は安全で分離され、ビジネスに合わせて定義されたクラウド領域を管理できるようになった
- VPCは新たな標準となり、顧客がクラウドでより包括的なシステムを構築できるだけの制御レベルを提供した
- EC2がNitroという新しい仮想化プラットフォームへ進化した後も、Classicは顧客利用のためにさらに10年間サポートされた
- EC2チームは、すべてのClassicインスタンスが終了または移行されるまで運用を維持した
- その過程全体を通じて、ドキュメント、ツール、エンジニアリングチームの支援、アカウント管理チームの支援が提供された
- EC2-Classicの終了は、2006年以降クラウドが大きく変化したことを示しており、進化可能なシステムを構築し、アーキテクチャをオープンな視点で見直す必要がある
1件のコメント
Hacker News のコメント
EC2-Classic は魔法のようだった
ついにソフトウェアがネットワーキングを担い、ケーブルでネットワークを作っていた時代の古い複雑さを忘れてよい未来に到達したように感じた
従来の IP サブネットよりも、クラウドはセキュリティグループを中心に動作していて、階層構造のようないくつかの機能さえあれば、伝統的なネットワーキングにおけるサブネットの役割を完全に置き換えられたように思う
EC2-Classic を長く使ってみるとネットワークエンジニアリングは簡単で楽しかったが、新しい VPC 方式は複雑でやる気をそがれるし、セキュリティグループでは表現できなかった何かを可能にしてくれるのかもよく分からない
以前にももっと詳しく、あるいは気分によってはもっと激しく書いたが、EC2-Classic から移行する中で最も強く感じたのは、他人がまともに動いているものをより悪くしてしまうときのフラストレーションだった
https://news.ycombinator.com/item?id=36829190
https://news.ycombinator.com/item?id=33569889
https://news.ycombinator.com/item?id=27990847
https://news.ycombinator.com/item?id=25988915
裏側で AWS が VPC を自動的に作ってくれて、ユーザーがあえて「緊急時にガラスを割る」ように VPC 設定に手を入れるまでは、昔の Classic とほぼ同じように使える
https://aws.amazon.com/vpc/lattice/
ただし単にフラットなネットワークの上にセキュリティグループを載せるよりさらに進んでいて、各 HTTP エンドポイントが自動的に IAM リソースになり、すべてのサービスを AWS ネイティブのように扱い、同じ IAM ポリシーを使えるので、かなり良い
パブリックインターネットを経由せず、社内ルーティングテーブルに AWS 宛ての単一エントリを追加できるが、共有されたフラットネットワークではこうした構成は問題になる
社内ネットワークや VPN などと統合する際に VPC が必要なのは理解できるが、実際には VPC がまったく不要なのに、仕事を過度に複雑にしてしまうことがよくある
引用文中の IPv4 表記が分かりにくい
「2006年に EC2 をローンチしたときは 10.2.0.0/8 という一つの巨大なネットワークだった」とあるが、/8 なら最初のオクテットだけが固定され、10.0.0.0〜10.255.255.255 の範囲になると理解している
だとすると、ここで 2 がなぜ重要なのか分からないし、2 が重要なら /16 と書くべきではないかと思う
出典と表記法に対する自分の確信を踏まえると、専門家なら読み取れる別の意味があるのかもしれないと思って気になっているし、単なるタイプミスなら細かく突っ込みすぎたようで申し訳ない
10.0.0.0/8 であるべきで、ブログで修正した。また、P3dn.24xlarge のメモリに関する混同もあわせて直した
10.2.0.0 から始めて作れる最大のサブネットは 10.2.0.0/15 だ
タイプミスというより、10.1.0.0/16 を除いた 10.0.0.0/8 を奇妙な形で書いたものかもしれないとも思う
書き手は、マシンが 10.2/16 のアドレスを受け取るが、10.1/16 のような別の 10/8 サブネットにある AWS サービスやマシンにもルーティングできた、という意味で書いたのだと解釈した
「インフラ管理、新しいハードウェアの購入、ソフトウェアアップグレード、故障したディスク交換の複雑さが抽象化された」とはいうが、その場所に AWS の複雑さが入ってきただけだ
AWS 以前でも、ハードウェアを自分で買ったり、壊れたディスクを自分で交換したりする必要はなく、Web ホスティング会社がやってくれた
もちろん自分でデータセンターに入ってディスクを交換したわけではないが、AWS で得られるやり方とは非常に異なる手順だった
今でも昔ながらの方式で運用している Web ホスティング会社は多いが、人々が AWS のようなサービスを好むのには理由がある
数回ボタンを押すだけで別ハードウェア上の新しいサーバーを立ち上げられる能力とは大きな差がある
必要なのが VPS だけなら VPS を使えばよく、個人的にはその場合 Hetzner のほうが好きだ
しかし大規模組織の要件を処理するには、AWS は複雑にならざるを得ない
さらに AWS コンソールの EC2 起動インターフェースは本当にかなり良くなっており、相当な複雑さを肩代わりしてくれる
Oracle もさまざまな評判にもかかわらず、今なお数十億ドルを稼いでいる
「サービスを終了するのはAWSがやることではなく、かなり珍しい」という文を読んでいたところで、ちょうど5月の終了前にOpsWorksから自分たちのものを移すエピック作業の合間に休んでいた
KubernetesとTerraformが登場する前に、いくつかのクラスターをOpsWorksで作った
ただ、AWSの人たちから聞いたところでは、内部的には保守があまりうまくされておらず、裏側はかなり混沌としていたらしいので、サービスが最初に出た頃から技術の勢力図が大きく変わった今、終了するのは驚きではない
RIP OpsWorks
タイトルは「私たちはXをする」なのに、本文は「私たちはここではXをしない」と読めるので、最初はこの記事が何を言いたいのかよく分からなかった
そのサービスは「メンテナンスモード」に入り、今年初めにはコンソールへのアクセスも削除された
「10年前の2013年のre:Invent基調講演で、今日のワークロードと明日のワークロードの両方をサポートしたいと述べ、Classicへのコミットメントがその最良の証拠だ」というくだりこそ、企業がAWSを信頼する理由
EC2チームは、すべてのインスタンスが終了または移行されるまでClassicをきちんと動かし続けたし、こういうことが信頼を生むのだと思う
Serifで働いていたとき、スクラップブック用デスクトップソフトウェアと統合される新しいソーシャルメディアWebサイト向けにWebホスティングが必要になったときのことを、今でも覚えている
当時はいつものように目新しい新技術がたくさんあり、その一つがMicrosoft Silverlightで、私たちはユーザーが公開されたスクラップブックを簡単に拡大して細部を見られるように、「Deep Zoom」をWebサイトに実装した
もう一つの新技術がAWSで、EC2が出たばかりの頃だったので、ボタン一つで米国、アイルランド、アムステルダムにインスタンスを立ち上げられ、落ちたらまたボタンを押して新しく立ち上げられるという点にかなり興奮した
今と同じく当時も、シンプルなUIの裏には相当な複雑さが隠れていて、複数のストレージ種類と、どれが永続的なのかを学ぶ必要があった
初期のEC2インスタンスは今ほど安定していなかったようで、実際に1つか2つを完全に失って作り直す必要があり、スナップショットをたくさん取った
Infrastructure as CodeやDevOpsはなかったが、独自の高可用性クラスターを作り、一緒に働いていたエンジニアがC++で一から書いて、複数のEC2インスタンス上のデータベースを監視し、クラスターが生き続けるようにしていた
当時はクラウドアーキテクトもいなかったので、自分たちが何をしているのか、何が賢いやり方なのかよく分かっていなかったが、技術は非常によく動き、初期の試行錯誤を越えた後はかなり活発なインターネットコミュニティを作れた
WebサイトはPHPとMySQLで作り、SQLのリレーショナルデータから生成したXMLをXSLTでHTMLに変換し、JavaScriptは多くなくjQuery程度だけを使っていた
デプロイはおそらくFileZillaでアップロードした後、C++のクラスターソフトウェアがアップロードされたファイルを別のアベイラビリティゾーンのEC2インスタンス群へ複製していたのだと思う
振り返ると、3つのアベイラビリティゾーンにサーバーを置く必要はなかっただろうが、作業は本当に楽しく、AWSに初めて触れさせてくれた良い時代だった
AWSにはデータベース層がなかったので、耐久性のためにElastic Block Storeを付けたインスタンスを使っていた
あとは、クレジットカード請求が暴走する可能性の代わりに、固定予算を実際に許可してくれるだけでいい
Microsoftはやっているし、Googleもそうだったと記憶しているが、Amazonがなぜやらないのか分からない
これもほぼ20年待ち続けている
個人的には、AWSがただ決断してClassicにIPv6を付け、そのまま続けてくれればよかったと思う
皮肉なことに、post-Classicは退歩のように見え、クラウド以前に扱わなければならなかったインフラにずっと近くなった
新しく作るものの大半はCloudflareの上に載せているので、今ではサブネットやVPCのようなものはほとんど考えない
彼らはいずれも社内ネットワークと統合する必要があるため、VPCが必要になる
正しく理解できているなら、すべての Classic インスタンスがアカウント所有者の介入なしに、より現代的なタイプへ移行されたのかが気になる
その過程で再起動があったのか、それともライブマイグレーションで処理されたのかも気になる
もともとそういうことを想定していない仮想化プラットフォームからライブマイグレーションを引き出すのは難しいからだ
元のネットワーク設定はまだエミュレートされているのか、それとも一部の顧客アプリケーションが壊れた可能性もあるのかも気になる
詳細はここにある: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
AWS は顧客を EC2-Classic から移行させるために時間、人員、資金を投じたようで、プロセスを自動化し、苦痛を減らす努力もかなりしていた
例: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
元のネットワークは、全員が同じサブネットにいるモデルから、それぞれが自分のサブネットを受け取るモデルに変わったので、顧客アプリケーションは実際に壊れる可能性があった
ネームサーバーが落ちたときに /etc/hosts に IP アドレスをハードコードして、後で戻すのを忘れるように、人は十分な理由があってもあまり賢くないことをするものだ
こうしたマイグレーションをうまくやるには、ムチとニンジンの両方が必要だ
ムチは最終的にサービスを停止し、提供を拒否するという点で、ニンジンは自動化、メンテナンスウィンドウが必要だという繰り返しの通知、明確な指針、そして何より顧客と実際に話し、対応しようとする姿勢だ
ただし AWS は人々にそれを行う時間を何年も与え、必要ならすべてのユーザーを個別に探して支援した
割引や終了の脅しがあったのかもしれない
所有者が忘れていたり作業を拒否したりしたインスタンスが一つもなかったというのは驚きで、これがどうして可能だったのか本当に興味深い
クレジットカードの有効期限切れが鍵だったのかもしれず、忘れられたアカウントの大半を自動的に無効化した可能性がある
おそらく似たようなやり方だったのだろう
VM は移動可能なように特別に構成しない限り、自動的に移すのは難しく、たとえば PCIe バス上のデバイス順が変わることがあり、MAC アドレスなど複数のマシン ID も変わり得る
VM がこうした変化の影響を受けないことを保証しなければ、移動後に問題が起きる可能性が高い
このレベルのサポートは、すべてのソフトウェア企業が目指すべきものだ
エンタープライズ顧客が見たいもの、そしてお金を払うものはまさにこれだ