re:Invent 2024: AWSのRegion構築プロセスとBootstrap Regionの活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Anatomy of an AWS Region (ARC204)
この動画では、AWSが新しいRegionをどのように構築しているのかについて詳しく解説しています。34の地理的Regionと108のAvailability Zoneを展開するAWSのグローバルインフラの全体像から、Bootstrap NinjaによるRegion構築の歴史的手法、そして現在のBootstrap Regionを活用した並列化された構築プロセスまでを紹介しています。特に、Region構築における10万以上の依存関係の管理方法や、Static Stabilityの原則、Ticket・ORR・COEといったAWS独自のメカニズムについて具体的に説明しており、AWSの大規模インフラ運用における実践的なノウハウが凝縮されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSリージョン構築の概要と本セッションの目的
ARC 204「AWS Regionの解剖学」へようこそ。AWSが新しいRegionをどのように構築しているのか、そしてそこから自身のアーキテクチャに活かせる学びは何かと考えたことはありませんか？今朝はまさにそのことについてお話ししていきましょう。まずはアジェンダからご説明します。
本日のセッションでは、まずAWS Global Infrastructureについてお話しします。Region、Availability Zone、そしてグローバルネットワークについて説明します。次に、私たちAWSがレジリエンシーのためにどのように構築しているのか、そしてそのコンセプトをお客様がAWS上でワークロードを構築する際にどのように適用できるかについてお話しします。そして、昔のRegion構築方法から現在に至るまでの興味深い歴史的な変遷をご紹介し、状況がどのように変化し、以前の方法では対応できなくなっていったかをお話しします。その後、現在のRegion構築方法について、依存関係の処理方法、関係者、構築したメカニズム、Region構築プロセスをサポートするツールなどを含めて詳しく説明します。最後に重要なポイントをまとめ、質問の時間も設けたいと思います。セッション後は会場のすぐ外でお待ちしています。まずは簡単な自己紹介をさせていただきます。私はDonで、Amazon EC2のエンジニアです。そして私はMichelleで、同じくAmazon EC2のTPMを務めています。
AWS Global Infrastructureの構造と設計思想
まずはAWS Global Infrastructureの概要を地図でご覧いただきましょう。こちらの地図にはすべてのAWS Regionが表示されています。緑色で示されているのが既にローンチされているRegionで、赤色で示されているのが現在構築中のRegionです。AWSクラウドは34の地理的Regionに108のAvailability Zoneを展開しています。さらに、18のAvailability Zoneと6つの新しいRegionの追加を発表しています。構築中の6つの新しいRegionには、Mexico、New Zealand、Kingdom of Saudi Arabia、Thailand、Taiwan、そして新しいEU Sovereign Cloudが含まれます。Points of PresenceやLocal Zonesなど他のインフラストラクチャ提供も行っていますが、今日のプレゼンテーションではそれらについては触れません。
AWS Global Infrastructureの最上位の抽象化レベルはPartitionで、Partitionには1つ以上のRegionが含まれ、各AWS RegionはひとつのPartitionに属しています。ほとんどの方はAWSまたはCommercial Partitionをご存知かと思います。というのも、大多数のRegionがここに含まれているからです。その他にも、US GovCloud、China、そして今後展開予定のEU Sovereign Cloud用のPartitionがあります。Partitionにはグローバルサービスのインスタンスも含まれています。IAM、CloudFront、Route 53などはグローバルな性質を持つサービスで、それぞれがPartition内に含まれています。
Partitionの次にRegionがあります。Regionは基本的に世界中の物理的な場所であり、各Regionには複数のAvailability Zoneがあり、それらのAvailability Zoneには複数の独立したデータセンターがあります。 AWSは常にレジリエンシーを重視してきたため、これらのAvailability Zoneは約60マイルまたは100キロメートルの意味のある距離を置いて配置されています。これは関連障害を防ぐためです。そのため、異なる氾濫原や電力グリッドに配置され、電力や冷却システムも共有していません。つまり、ある Availability Zoneが自然災害の影響を受けても、同じRegion内の他のAvailability Zoneが影響を受ける可能性は低くなっています。ただし、Region内のレイテンシーを最小限に抑えるため、これらのAvailability Zoneは適度な近さを保つ必要があります。
ソフトウェアの観点から、エンジニアリングチームがサービスに変更をデプロイする際、例えばAmazon EC2に変更を加える場合、彼らは一度に1つのAvailability Zoneにデプロイします。つまり、変更をデプロイする際は、最初のAvailability Zoneにデプロイし、待機期間を設けて問題がないことを確認してから、次のAvailability Zoneに進むという具合です。これも、関連障害を防ぐための対策の一つです。
Regionの中には複数のAvailability Zoneがあり、それらは複数の独立した高帯域幅の光ファイバー接続でRegion内で相互に接続されています。また、Transit Centerと呼ばれる拠点も設けています。Transit Centerには主に2つの役割があります。1つ目はAvailability Zone同士を相互接続することです。2つ目は、AWSのグローバルバックボーンネットワークとの接続性を提供することです。このネットワークにより、Region AからRegion Bに向かうトラフィックは、AWSが独自に管理するバックボーンネットワーク上を通ることができます。そのため、Region間のトラフィックがパブリックインターネットを経由する心配はありません。Transit Centerはインターネットバックボーンと高度に連携しており、インターネットとの間で送受信されるトラフィックはTransit Centerサイトを経由します。これは素晴らしいことですが、お客様にとって実際にどのような意味を持つのでしょうか。
AWSのレジリエンシー設計とお客様への推奨事項
AWSがレジリエンシーを念頭に置いてグローバルインフラストラクチャを設計していることについてお話ししてきました。AWSでは責任共有モデルに基づいて運営しているため、お客様とお話しする際には、この点も考慮していただくようお勧めしています。つまり、利用しているサービスの範囲を理解すること、例えば、使用しているサービスがZonal（AZ単位）なのかRegional（リージョン単位）なのかを把握することが重要です。 例として、こちらのアーキテクチャ図をご覧ください。Amazon EC2はZonalサービスの例で、EC2インスタンスを起動する際には、どのAvailability Zoneで起動するかを指定します。 Regionalサービスの例としては、Amazon Simple Storage Service（Amazon S3）があります。S3バケットを作成する際には、作成したいRegionを指定します。
これが重要な理由は、この情報を基に運用上の対応を計画できるからです。ビジネスにとって重要なメトリクスが何であり、どのしきい値でアラートを設定すべきかを理解することが重要です。これにより、災害復旧シナリオなどの際に、どの時点でフェイルオーバーすべきかといったビジネス判断を下すことができます。具体的な例については、Donが説明してくれます。また、高レベルでは、Game Dayなどを通じてこれらをテストすることも重要です。計画を立てるだけでなく、実際に機能することを確認する必要があります。私たちもRegionの構築時にこれを実践しています。Regionを立ち上げる直前にGame Dayを実施し、障害をシミュレートしてサービスが期待通りに素早く復旧することを確認します。これは、お客様にも常に推奨していることです。
この例では、Load Balancerの背後にWeb serverがあり、それらのWeb serverはAvailability Zone全体に分散されたAuto Scaling groupに属しているというシンプルなアプリケーションを見ていきます。これらのWeb serverはAmazon S3からファイルの保存と取得を行い、Amazon DynamoDBのテーブルからデータを取得しています。このアーキテクチャを見て、どのような障害パターンが考えられるでしょうか？ Amazon EC2は素晴らしいサービスですが、ホストにソフトウェアをデプロイする際や、ホストが機能低下する場合があり、インスタンスやAvailability Zoneでの障害が発生することがあります。ほとんどの場合、Elastic Load Balancingがヘルスチェックを通じてこれを認識し、そのインスタンスをサービスから除外します。Auto Scalingは他のホストが高負荷で動作していることを検知し、問題を解決するために新しいホストを起動します。
深刻な障害が発生するシナリオもあります。例えば、そのインスタンスへのトラフィックの50%は通過するものの50%は失敗する場合や、Amazon EBSボリュームが完全にオフラインではないものの機能が低下して劣化している場合などです。このようなシナリオでは、Load Balancerはそのインスタンスのヘルスチェックを通過させ続けているかもしれませんが、アプリケーション全体としては健全ではないかもしれません。ここで重要になってくるのがビジネスメトリクスです。注文率や注文エラーに関するメトリクスとアラームを設定していれば、ビジネスへの影響が手動での対応が必要なレベルに達しているかどうかを判断できます。
例えば、Auto Scaling groupで追加のインスタンスをスケールアップし、それらを手動でLoad Balancerにバインドしたり、不健全なインスタンスをLoad Balancerから手動で削除したりすることができます。これは、ビジネス判断が必要な事項です。適切なリーダーを招集してミーティングを行い、オペレーターが実行するためのRunbookを用意し、先ほど述べたように、本番環境でではなくGame Dayで事前に練習しておく必要があります。利用しているサービスのゾーンレベルおよびリージョンレベルの特性を理解し、RunbookとGame Dayを事前に準備しておくことで、インシデント発生時に効果的に対応することができます。
リージョン構築の歴史的変遷と現在の手法
では、実際にRegionをどのように構築するのかについて話を進めていきましょう。 Donと私は、皆さんがこのセッションに参加したのは、実際にRegionの構築方法を学んで自分で運用する方法を理解するためではないと考えています。しかし、私たちが長年にわたってRegionを構築してきた中で学んだことを少しでも共有できればと思います。正直なところ、Regionの構築方法は過去数十年で大きく変化してきました。
しかし、一貫して変わらないことが一つあります。それは、主に2つのワークストリームがあるということです。1つ目は物理的なものです。AWSクラウドについて話すとき、結局のところ物理的なサーバーが基盤となっています。 物理的なワークストリームには、土地の調達、拡張オプションの検討、光ファイバーや電力の制約の調査、物理的なデータセンターの建設、ラックの発注・設置・ケーブル配線、そしてそれらすべてをAWSネットワークに接続することなど、多岐にわたる作業が含まれます。
2番目の主要なワークストリームは、ソフトウェアのビルドです。ソフトウェア面についてより詳しく掘り下げていきましょう。大まかに言えば、ソフトウェアをデプロイできるホストの起動から、お客様が新しいRegionで期待するすべてのAWSサービスの構築まで、全てを行う必要があります。状況は大きく変化していますが、 過去のやり方と、それがどのように進化してきたかを見るのは非常に興味深いので、2010年当時にさかのぼってみましょう。
2010年、私たちが南米で最初のRegionを構築し始めた頃のお話です。2010年、AWSはブラジルのSão Paulo Regionの開設を発表しました。これは AWS8番目のRegionでした。最初のre:Inventもまだ開催されていない時期です。この懐かしい感じのブログ投稿を見ていただくとわかるように、当時のAWSやAmazon EC2は今とはかなり異なる様相でした。このRegionの開設を発表し、15のサービスすべてがそこで利用可能になることを説明しました。
当時のRegion構築方法について説明するために、ある人物を紹介する必要があります。それがJohnです。Johnは実際の職名が「Bootstrap Ninja」でした。 新しいRegionを構築する必要があるとき、私たちはコンクリートが打たれ、光ファイバーが敷設され、電力が供給されるのを待ちます。そして、Johnは3つのジャンプドライブを持って、新しいデータセンターを建設したサイトに飛んで行きました。この3つのジャンプドライブは各Availability Zone用で、そのAZを構築するために必要な初期証明書と設定が含まれていました。彼らはデータセンターに入り、最初のホストにジャンプドライブを接続して、基本ソフトウェアとプロビジョニングスタックを手動でインストールし始めました。
各Availability Zone間を移動する必要があったため、このプロセスはかなりの時間を要しました。Johnは素晴らしい人物でしたが、1日10-12時間しか働けなかったため、これは本当にスケーラブルなプロセスとは言えませんでした。私たちのチームには、実際にこの仕事をしていた人が2人いますが、何百ラックもの何も入っていないサーバーに向かって設定を始めるには、多くのことについて知識が必要でした。Bootstrap Ninjaは、AWSインフラストラクチャがどのように機能するかについて深い知識が必要でした。人間は完璧ではないので、特に設定に関しては簡単にミスを起こす可能性があり、ミスが発生した場合、後で発見してどこで起きたのかを突き止める必要がありました。
実は、São Pauloの直後にはBootstrap Ninjaのプロセスから脱却していました。仮にそのモデルを続けようとしていたとしても、AWSが革新を続けるにつれて、他の理由で持続不可能になっていたでしょう。 私たちは常にお客様のために革新を続けています。時とともに進化してきたことの1つは、初期の頃は、サービスを構築してそれらのサービスを実行していただけでしたが、その後AWSの上にサービスを構築するようになり、今日構築するAWSサービスのほとんどが、その上で動作しているということです。まるでScooby-Dooで誰かのフードを引っ張るようなものですね。
内部構造を見てみると、私たちのサービスの大半のコンピューティングはEC2上で実行されています。興味深いことに、EC2上でEC2を実行することも可能で、これは少し頭を整理する必要がある考え方です。この分野でもう一つ重要な進展は、新しいRegionをIAMのオプトインRegionとして構築し始めたことです。これは、新しいRegionを立ち上げる際に、お客様のアカウントとIAM情報が、お客様が選択してオプトインするまでその新しいRegionに存在しないため、お客様にとって有益です。もし私たちがまだ手動でインストールを管理していたら、そこにIdentityスタックを構築する必要があり、これは非常に困難だったでしょう。
お客様の状況は大きく変化してきました。Michelleが言及したEU Sovereign Cloudは、時間とともに発展してきたデジタル主権とデータ主権の要件によって主に推進されています。お客様はAWS上でより機密性の高いワークロードを実行したいと考えており、その結果、私たちはより厳格な制限やガイドラインに従う必要が出てきました。これにより、より多くのRegionを構築する必要性が生まれ、時間とともに改善が行われて、異なるセキュリティ基準で構築する必要が出てきました。最後に、クラウド自体の価値提案があります。それはグローバルにリーチできる能力です。私はUS East 1の西側の自宅に座りながら、南アフリカのケープタウンやクアラルンプールでアプリケーションを起動できます。小規模企業であっても、アプリケーションをグローバルに展開できる能力があり、これが私たちがお客様のためにより多くのグローバルロケーションを持ちたい理由です。
AWSリージョン構築の複雑性と依存関係の管理
Bootstrap Ninjaのアプローチは長期的には持続可能ではありませんでしたが、現在の私たちのアプローチはどのようなものでしょうか？Donが言及したこれらの変化すべてに対応して、AWSは革新を続け、お客様のためにより多くのAWS Regionを提供し続けています。これらは、最近構築したRegionの発表の一部です。確かに多くのRegionに拡大しましたが、これは古いアプローチでは不可能だったでしょう。では、私たちは何をしたのでしょうか？私たちはAWSを使ってAWSを構築しています。
データセンターを構築してからBootstrap Ninjaによるソフトウェアビルドを開始するという順序的なプロセスに従う代わりに、私たちはワークストリームを並列化しました。新しいRegionの構築を開始する際、土地の調達とデータセンターの建設を開始すると同時に、世界中の既存のAWS Regionを活用して新しいRegionをブートストラップします。現在は、物理的な作業ストリームの完了を待つ必要はなく、物理的な建設とソフトウェアビルドを並行して進めることができます。私たちにはBootstrap Regionがあり、これは既存のAWS Regionですが、そのRegionがBootstrap Regionとして機能するかどうかの決定には非常に慎重です。なぜなら、そのRegionは外部のAWSお客様のトラフィックにサービスを提供しているからです。
私たちは、Region構築中に使用する容量が外部のお客様に影響を与えないよう、容量の制約などの要因を考慮します。Bootstrap RegionとRegion構築中の新しいRegion間のレイテンシーを調査し、光ファイバーや帯域幅の制限を評価します。この構築段階では、データセンターの建設を開始し、Bootstrap RegionにVPCを作成しています。このソフトウェアビルドの初期段階でも、すでにレジリエンシーを念頭に置いて設計しています。3つのAvailability Zoneを作成し、このBootstrap VPCで起動するすべてのサービスは、構築中の新しいRegionに存在すると認識しています。
では、VPCができましたが、次は何をするのでしょうか？ DonがVPCで最初にすべきことについて説明してくれます。空のVPCができました。これで完了でしょうか？いいえ、まだです。何が必要でしょうか？まず最初に必要なのはホストです。ソフトウェアを構築する必要があり、そのためにはホストが必要になるでしょう。では、ホストを起動してみましょう。そして、そのホストにソフトウェアをデプロイする必要があります。 これを実現するには、Amazonのデプロイメントシステムと通信できる必要があり、ホストにデプロイメントエージェントを配置し、自分が悪意のある人物ではなく信頼できるAmazonの従業員であることをデプロイメントシステムに証明する必要があります。DNS、PKI、RPMリポジトリなどの基本的な機能が必要ですが、今は空のVPCしかありません。
このプロセス全体を通じて、多くの創造的なエンジニアリングが行われます。なぜなら、AWS内部にはDNS、PKI、RPMリポジトリを処理するサービスがありますが、これらのサービスを構築するにはホストが必要で、かつ、ホストを機能させるにはこれらのサービスが必要だからです。DNSは本質的に名前と数字を相互にマッピングするデータベースであり、PKIは基本的にWebサーバーで、RPMも同様です。
このVPCに別のインスタンスを起動し、そこにWebサーバーを数台、DNSサーバーを設置し、Bootstrap RegionのDynamoDBやAmazon S3を少し使用します。これでDNS、PKI、RPMリポを作成でき、Amazonのデプロイメントシステムと通信してホストにソフトウェアをデプロイできるようになりました。これで、先ほど循環依存を解消したこれらの初期サービスをすべて構築できます。このインスタンスは様々なパーツを組み合わせて作られているため、Frankenstein Instanceと呼ばれています。
DNS、PKI、RPMリポなど、AWSを支える基本的なコンポーネントを構築できるようになりましたが、これでAWSサービスの構築を始められるでしょうか？楽しそうですよね？できるでしょうか？ まだできません。ソフトウェアをデプロイできるホストはすべて揃いましたが、各サービスに共通して必要なものは何でしょうか？ 最初に立ち上げるサービスの一つが認証サービスです。AWS Identity and Access Management（IAM）やSecurity Token Service（STS）のようなサービスを考えてみてください。これらは、VPC環境で最初に立ち上がるサービスの一部です。
先ほど、オプトインリージョンについて触れました。2019年初頭以降、新しいリージョンを構築する際には、オプトインリージョンとなり、リージョンにオプトインしない限りサービスは実際には機能しません。そのため、認証スタックを早い段階で立ち上げることがさらに重要になっています。 これらは、その発表以降に立ち上げた新しいリージョンの例です。素晴らしい。これでVPCができ、ソフトウェアをデプロイできるホストがあり、サービスも認証できるようになりました。しかし残念ながら、大多数のサービスにはまだ他にも依存関係が多くあります。
AWSの運用プラクティスとツール：Ticketシステムからリージョン構築まで
Amazon EC2は最高のサービスだと考えているので、これを構築したいと思います。IAMがあるので、誰かがEC2 RunInstancesを呼び出した時に、少なくともその呼び出しを認証し、どのアカウントからのものかを把握できます。先ほど、ほとんどすべてのものがEC2の上に構築され、AWSはAWSを使って構築していると言いましたが、実はEC2自体もAWSの一部のサービスを使用しています。EC2はオブジェクトストレージとしてAmazon S3にデータを保存し、キーバリューストレージとしてAmazon DynamoDBを使用しています。これらは素晴らしいサービスなのですが、ここで問題が。S3とDynamoDBはEC2上で動作していますが、EC2はS3とDynamoDBを使ってデータを保存しているのです。
本番環境では、これは問題なく動作します。これらは Regional なサービスで、S3オブジェクトやDynamoDBテーブルにゾーンアフィニティを持たせるような工夫を裏側で行っているため、お客様向けの耐障害性を維持できています。しかし、この初期ブートストラップが問題になります。Regional な耐障害性を実現するためには、それらのすべてが事前に存在している必要があるからです。私たちは、まだ存在していない Region を構築している最中でも、サービスがその Region で動作していると認識させたいと考えました。 Bootstrap Region にはDynamoDBとS3があり、それらは異なるDNSエンドポイントを持っており、オプトインRegionは使用しません。 そこで、プロキシのようなものを配置し、Region内の認証に対して認証を行い、S3.build-region.amazonaws.comをリッスンして、一時的にS3にデータを保存するようにできないかと考えました。
その後、すべてをそちらに移行します。これは何を作り出したことになるでしょうか？私はMullet（マレット）を作り出しました。なぜなら、 フロントエンドがBuild Region で、バックエンドがBootstrap Region だからです - ビジネスは前面に、パーティは後ろにという具合です。
これでAmazon EC2の循環依存を解消できました。EC2を実際に構築するために必要なものがすべて揃いました。依存関係がすべて整うと、 Amazon EC2とネットワークサービスなどの他のコアインフラストラクチャサービスを立ち上げます。この時点で、物理的な側面では、データセンターが建設され、ラックの設置とケーブル配線が完了し、すべてがAWSネットワークに接続されています。これにより、新しいBUILD Regionでホストを実際に起動し、Region内で必要となるすべてのAWSサービスの構築を開始できます。
ここではいくつかの例を挙げましたが、Region立ち上げ前に利用可能にする必要のあるすべてのサービスを起動しなければなりません。先ほどEC2を起動すると簡単に言いましたが、これは非常に単純化した見方です。なぜならAmazon EC2は単一のサービスではなく、実際には何百ものサービスで構成されているからです。これを理解していただくために、DonがEC2の最も基本的なAPIの1つであるRunInstancesについて説明し、EC2内部だけでも実際にはどれだけ多くのサービスが関わっているのかを説明します。
一般的に、お客様はサービスというとEC2やAmazon S3、DynamoDBなどを思い浮かべます。それはもっともなことですが、Amazonの中ではサービスという言葉は異なる意味を持っています。例えば、RunInstancesというAPIコール - これはEC2の基本中の基本で、お客様がインスタンスを要求し、私たちがそれを提供する際に使用するものです。このRunInstancesコールが実際にどのように動作するのか、内部の仕組みを見てみましょう。
これは読もうとしないでください。ちょっと目を細めて見てしまうような図なんです。これは私たちの社内APIオーケストレーションソフトウェアのスクリーンショットです。上部の小さなボックスにカーソルを合わせていますが、そこがRunInstancesコールの開始点で、そこから伸びている緑の線は、そのボックスがその処理段階で呼び出すものを表しています。
画面上のこれらのボックスの一つ一つが、私たちが「サービス」と呼ぶものを表しています。Amazonは「2枚のピザチーム」モデルを採用しています。これは、2枚のピザで食事が足りるサイズのチームという意味です。画面上の各ボックスは、2枚のピザチームが運営するサービスを表しています。インスタンスの実行に必要な要素 - Security Group、VPC、EBSボリュームなど、様々な要素を頭の中で計算してみると、いかに多くのチームが関わっているかが分かってきます。では、これだけの数のチームをどのように調整し、Amazonのスケールでこのようなビルドを実現しているのでしょうか。
Donの例が示すように、たった1つのEC2 APIコールの中にも、膨大な数の依存関係が存在します。依存関係は非常に扱いが難しく、追跡が困難で、しかも常に変化しています。例えば、あるサービスが新機能を発表する際に新しい依存関係が導入されたり、全社的な取り組みとしてサービスを廃止する場合にRegionビルドの依存関係に影響が出たりします。Regionビルドでは、サービス間に10万以上もの依存関係があるため、それらの順序付けとスケジューリングは非常に複雑になります。
私たちが行っている一つの方法は、それらをWaveにグループ分けすることです。ここでは非常に単純化した例を示しています。基本的に、一つのWaveを立ち上げ、すべてが稼働したら次のWaveに移行します。ビルドが進むにつれて、Waveは徐々に広がっていきます。コアとなる依存関係が利用可能になると、Wave内の各依存関係は、自身が依存するサービスの健全性を継続的にチェックします。依存するサービスが健全であれば、そのサービスも稼働を開始できます。これは、Regionビルド時だけでなく、この後Donが話す運用上の問題が発生した際にも非常に重要になります。
運用上の問題が発生した際、EC2サービスを中心に、AWSの多くのサービスは「Static Stability」と呼ばれる原則や考え方に従っています。
Static Stabilityとは基本的に、何らかの理由でサービスが停止した場合に、手動での介入なしに自動的に復旧を試みることを意味します。これはAmazon EC2にとって重要な機能です。先ほど述べたように、EC2では社内外の多くのシステムが稼働しており、ビジネスにとって非常に重要であり、データセンターで停電などのイベントが発生する可能性があるためです。
データセンターでの停電イベントは、基本的に大規模な「電源を切って入れ直してみましたか？」のようなものです。家庭用ルーターであれば、コンセントを抜いて差し直せば動くだろうということは暗黙の了解です。しかし、EC2のデータセンターの電源を切って入れ直す場合は、確実に復旧させるためにはそれなりの作業が必要になります。この同じ原理をリージョン構築に活用して、依存関係の波を機能させることができます。
サービスがコールドスタートまたは再起動を試みる際、サービスのアクティベーションのみがブロックされます。アクティベーションとは、例えば80番ポートでリッスンするように設定されているという意味です。サービスを起動して実行状態にするために絶対に必要な要素だけが、サービスの起動を妨げる要因となります。サービスが実行状態になれば、依存関係のあるサービスと通信できなくても500エラーを返しながらも、少なくとも動作は継続します。これは「実行中か」と「正常に動作しているか」という2段階のプロセスなのです。
この特性を活用して、多数のサービスを一度に起動し、起動した50のサービスが実行状態になるのを待って確認することができます。その後、システムを通してAPIトラフィックを送信し、正常に動作しているかを確認します。すべてのサービスが実行状態になり、正常に動作していることを確認できたら、次のバッチに進むことができます。依存関係は、そのグループ内で自然と整理されます。高レベルでの順序付けは必要ですが、10万個もの異なる要素に対して「まずこれをして、次にこれをする」という低レベルの順序付けは必要ありません。それは非常に面倒で、すべてが常に変化している状況では実質的に不可能な作業となるからです。
リージョン構築を支えるツールとプロジェクト管理
では、これらを実際にまとめ上げるために社内で使用しているプログラミングやツールについて、Michelが説明します。ここまでリージョン構築の物理的側面とソフトウェアの側面について説明してきましたが、他に関係する要素についてはまだ触れていません。次は、AWS Buildersや、私たちが導入している仕組み、そしてリージョン構築に特化したツールについて説明し、まずは人的側面から始めたいと思います。
AWSは非常に大規模なグローバル企業で、Region構築の際には1500以上の社内外のサービスを立ち上げています。これらのチームは世界中に分散しており、EC2だけを見ても、Seattle、DC、Dublin、Cape Townに主要な拠点があります。私たちは常に異なるタイムゾーンをまたいで働いており、これらのチームは全てのRegionでサービスを維持し、今週のre:Inventで紹介されたような新機能の開発を行っています。さらに、これら全ての新しいRegionやAvailability Zoneでサービスを構築することも求められています。これには膨大な協力体制が必要で、EC2内だけでなく、世界中のAWS全体での連携が不可欠です。
AWSでは、Region構築に特化したものだけでなく、このプロセスを円滑にするための仕組みを導入しています。皆さんも自社のビジネスに取り入れることができるかもしれないので、私たちが使用している仕組みについてお話ししたいと思います。Mechanismは、Amazonの用語で、誰もが自動的に従う反復可能なプロセスのことです。まず第一に、Amazonでは全てがTicketになります。私のサービスに障害が発生した場合もTicketです。チームAがチームBに何かを依頼する場合もTicketです。福利厚生の変更もTicketです。建物のトイレが故障した場合もTicketです - 全てがTicketなのです。社内では「またTicketか」という声も聞かれますが、実はTicketは非常に良いものなんです。
Amazonに入社したばかりの頃、「全てがTicket」と言われて「ああ、なるほど」と思いました。問題Xがあることがわかれば、Ticketをどこに提出し、どのチームに送るべきかを把握するだけでよいのです。基本的に、Ticketをどこに送ればよいかさえ分かれば、どんな問題でも自己解決できます。誤って送られた場合は適切なチームに転送されるか、直接対応されます。誰でも問題を自己解決できるようになるだけでなく、Ticketは検索可能で、監査可能で、発見可能です。問題が発生した場合、同じ問題についてのTicketが既に提出されていないかを検索して、そのTicketをフォローすることができます。
私たちは構築プロセス全体を通じてTicketを監査し、パターンを追跡しています。構築の度に同じ問題が繰り返し発生していることに気付いた場合、特に自動化したい手作業のプロセスについて、そのチームと協力して対処します。私たちはAnalyticsと協力して、Amazon EC2に関するTicketだけでなく、Region構築に関する全てのTicketを分析し、構築フェーズや対象分野を調べています。また、この情報を読み取って要約し、構築全体で共通する問題を特定するために、Generative AIツールの実験も行っています。
次にお話ししたいMechanismは、ORR（Operational Readiness Review）と呼ばれるものです。これはチェックリストとして機能するWebベースのツールです。ORRでは、エンジニアが自分のサービスについて、その目的、Fault Container、障害モード、Pipelineの構造、主要な運用メトリクス、ビジネスメトリクス、測定方法、アラームなどの詳細を文書化します。EC2のPrincipal Engineerとして、私は新機能やサービスを立ち上げる前に、個々のチームのORRを確認することに多くの時間を費やし、適切な項目を測定しているか、適切なアラームを設定しているか、主要な機能や障害モードに対処しているかを検討しています。
ORR（Operational Readiness Review）は、サービスが顧客向けにローンチされる前と、その後定期的に（通常は年1回、場合によってはより頻繁に）実施されます。チームは前年度に文書化した内容を見直し、運用上の変更を評価し、アラームやモニタリングに必要な調整を行います。最後に説明したいメカニズムは、COE（Correction of Error）です。何らかの影響を及ぼすイベントが発生した場合、そのサービスを所有するチーム、さらには二次的な影響を受けたチームも、何が起こったのか、タイムライン、影響、根本原因、アクションアイテム、得られた教訓を詳細に記したCOEドキュメントを作成します。
COEの最も重要な側面は、懲罰的なものではなく、学習のためのメカニズムだということです。例えば、Javaで書かれたバッチ処理サービスがメモリ集中型の処理とロードスパイクによって障害を経験した場合、根本原因分析を通じて、異なるGarbage Collectorに切り替えることで問題を防げることがわかるかもしれません。これは、メモリ集中型のバッチ処理アプリケーションを実行している誰にとっても貴重な教訓となり、JavaのGarbage Collector設定を評価し、適切なテストを実施するきっかけとなります。
これらは社内のコードレビューで出てくる類のことで、「このメトリクスやアラームをもっと早く設定しておくべきだった」といった気づきを共有します。同様のワークロードを実行している場合は、このようなアラームやメトリクスの設定を検討してください。
もう一つ触れた点は根本原因についてです。根本原因はオペレーターのミスということには決してなりません。そう言うのは簡単ですが、Amazonやみなさんの会社では、優秀な人材を採用しています。例えば、Donがオペレーションボックスでデータベースに変更を加えようとしていて、テスト環境だと思っていたら実はProduction環境だった場合 - きっとこの部屋の誰にもそんな経験はないでしょうが - そしてProductionデータベースに変更を加えてしまった場合、それはDonの責任でしょうか？私たちはDonを採用し、彼は優秀で一生懸命働く人です。では、Production環境のボックスにいることに気付かなかったのは本当にDonの責任なのでしょうか？いいえ、それは実はProductionボックスであることがDonにとって明白でなかったという、ツーリングの問題です。根本原因はオペレーターのエラーではなく、不適切なツーリングなのです。
これにより、懲罰的でない文化が育まれます。私は多くのコードレビューに参加してきましたが、そこではオペレーターが何をしたかについて話し合い、部屋にいる全員がそのオペレーターが誰かを知っていますが、それは重要ではありません。なぜなら、そのオペレーターは私たち誰もがなりえたからです。これらのメカニズムは、時間とともにビジネスに適した形で確立され、これらのテクニックを強化し、プロセスを継続的に改善し、監査できるようになるという点で、非常に優れています。
リージョンの構築を支援するためのツールがいくつかあります。Amazon EC2には多くの依存関係があり、その中でも特に重要なのが、すべてのサービス間の高レベルな依存関係や、特定のサービスを立ち上げるのにかかる時間、そして全体的なスケジュールを把握するためのプロジェクト管理ツールです。これが重要な理由は、新しいAWSリージョンの構築を発表する際に、通常「2026年初頭に開始予定」といった具合に予定される開始時期を示すため、お客様への約束を守る必要があるからです。
私たちは毎日このハイレベルなスケジュールを確認しており、新たなリスクや遅延が発生した場合は、すぐにエスカレーションして、リージョンを予定通りに提供できるよう、それらのリスクや遅延を軽減できないか検討します。また、リージョン構築に特化した詳細な社内ドキュメントも用意しています。リージョン構築の自動化を改善したいと考えているサービスチームのエンジニアは、このドキュメントを参照して、リージョン構築のタイプに応じて利用可能なツールを確認することができます。
ここ数年でリージョン構築は大きく変化しているため、ツールに不足がある場合もあります。10の異なるチームがリージョン構築中に同じ問題に遭遇しているのを見かけたら、それは誰の時間の無駄にもなりません。そこで、これらの問題をプログラムとして取り上げ、新しいツールの開発や、現在のリージョンに対する一時的な修正と将来のリージョンに向けた長期的な修正を通じて、中央で解決します。そうすることで、多くのエンジニアがこの問題の修正に悩まされることなく、サービスの健全性維持や新機能の開発に集中できるようになります。
AWSリージョン構築から学ぶビジネスへの重要な洞察
先ほども述べたように、皆さんが独自のリージョンを構築して運用しようとしているとは考えていません。しかし、皆さんのビジネスに役立つかもしれないいくつかの重要なポイントをお伝えしたいと思います。 このトークを通じて理解していただきたいのは、Availability Zoneモデルとリージョンモデルは、AWSソフトウェアの起動直前に付け加えられるものではないということです。これらは私たちのソフトウェアの機能に深く組み込まれており、新しいリージョンを構築する際には、最初から独立してマッピングされたAvailability Zoneを作成する必要があるほどです。
このような手の込んだリージョン構築プロセスが必要な理由の1つは、リージョン間に強力な分離障壁を設けているからです。リージョンAでのインシデントがリージョンBに影響を与えないようにしたいと考えており、この方針を強く守っています。皆さんもソフトウェアを設計する際に、同じような原則を適用することができます。
AWSが提供するフォールトコンテナをお客様が自社のソフトウェアで利用する最も一般的な方法の1つは、コンポーネントごとに異なるアカウントを使用することです。例えば、Don's Awesome Widget Serviceを US West 2と US East 1にデプロイする場合、US West 2用に1つのアカウント、US East 1用に別のアカウントを用意します。US West 2で作業をする際に、同じアカウントを使用していても誤って別のリージョンのリソースに影響を与えることがありません。このようなアカウントレベルのフォールトコンテナを使用することは、そういった影響の波及を防ぐ強力な方法なのです。
Bootstrap Ninjaから、Bootstrap Regionを使用したソフトウェアビルドに切り替えた際、あの複雑な組織図に示された各チームは、TPMから「リージョンXYZでサービスをビルドする時期です」というチケットを受け取っていました。これだけの作業を調整するのは本当に大変です。TPMにとっても困難な仕事ですし、サービスチームにとってもリージョンビルドには特別な知識が必要となります。これが分散モデルで、Amazonが通常採用している2ピザチームアプローチです。チームがそのサービスの最初から最後まですべてを担当するというものです。
ここ数年、私たちはこのアプローチを見直し始めました。1,000のチームそれぞれが月に8時間をリージョンビルドに費やすとすると、チーム全体で8,000時間を費やしていることになります。月に8時間の作業であれば、他の優先事項と比べて大きな作業ではないため、そのプロセスを最適化しようというモチベーションは生まれにくいでしょう。しかし、各チームから8時間を取り上げて、新しいリージョンでAmazon EC2をビルドする責任を持つ中央チームに与えたらどうでしょう？そうすれば、そのチームには8,000時間分の作業が与えられ、プロセスを最適化し所有することへの強いモチベーションが生まれます。
これを成功させるカギは、その判断のタイミングを見極めることです。1,000人が何かを行うべきか、1人が1,000回何かを行うべきか、どちらが適切かを判断することです。誰もが知っているShared Responsibility Modelがありますが、中央チームに対しても同じモデルを持つことが重要です。サービスチームが何を担当し、中央チームが何を担当するのか、早い段階で定義することが重要です。これをできるだけ早く確立し、すべての人にとって機能するようにすることが大切です。リージョンビルドの自動化を健全に保つ責任は維持しながらも、リージョンビルドのような差別化されていない重労働を代わりに引き受けることを、チームは高く評価します。
すべてをコードにし、そのコードをソース管理にチェックインする必要があります。 ソフトウェアコードはソース管理にチェックインされます。設定もコードで、インフラストラクチャの定義もコードで、ドキュメントもコードで - すべてがコードであるべきです。これにより、知識と設定が一元化され、検索可能で監査可能になります。コードレビューの観点からも、これは非常に良いことです。
私は Amazon のコードを検索することに多くの時間を費やしています。それは、なぜ特定の方法で設定されているのかを理解するためです。コードを読んで各チームに説明し、彼らの設定の自動化が機能しない理由を示し、適切な実装方法を指導することができます。チームの設定方法を改善したい場合は、コード内でそのインスタンスを検索し、チームの実装を改善するための PR を自動的に作成することができます。特に複数のリージョンにデプロイしたいシステムがある場合、コードで管理することは非常に重要です。US East 1 や SA East 1 向けの設定を自動的に生成する自動化やスクリプトを用意することで、将来にわたって何度もその恩恵を受けることができます。
4つ目の重要なポイントは、問題と解決策を測定することです。AWS では、私たちはデータ駆動型の企業です。問題があると考える場合は、優先順位付けの判断に役立つデータによる裏付けが必要です。解決策を実装した後は、当初解決しようとした問題が実際に解決されたかどうかを測定して確認することができます。私たちは、誰かが問題を提起する際には必ずデータを持ってくることを求めており、皆さんにも同じことをお勧めします。
最後に、リーダーシップの関与が極めて重要です。Region の構築は、リーダーシップから大きな注目を集めており、AWS のリーダーシップは Region 構築プロセスに積極的に関与しています。AWS では、とても健全なエスカレーション文化があります。エスカレーションというと否定的な印象を持つかもしれませんが、実際にはとてもポジティブなものとして捉えられています。Region の構築において、新しいリスク、遅延、またはチーム間の不一致が生じた場合、それらの問題を迅速に解決し、効率的に前に進む方法を決定することが重要です。チーム間で内部的に解決できない場合は、リーダーシップにエスカレーションして、適切な判断を仰ぎ、正しい結果に導いてもらいます。これができないと、予定通りに Region を提供することが非常に困難になってしまいます。
ここで、いくつかの追加リソースをご紹介します。明日、AWS でのスケーリングに関するプレゼンテーションがありますので、興味があるかもしれません。また、今日お話しした内容に非常に関連する Amazon Builders' Library のリソースが2つあります。上のQRコードが最初の記事用で、下のQRコードが2番目の記事用です。Don と私への質問がありましたら、この後5分ほど会場に残りますので、お気軽にお声がけください。 AWS の Region 構築プロセスについて公の場で話すのは今回が初めてですので、ぜひフィードバックをいただけますと幸いです。アンケートにご協力いただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion