re:Invent 2024: The New York Timesのマルチクラウド最適化事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Optimizing network efficiency & strengthening multicloud connectivity (MAE308)
この動画では、The New York Timesのマルチクラウドインフラストラクチャーの最適化事例が紹介されています。複数のクラウドプロバイダー間のワークロードを効率的に接続するため、Hub-and-Spokeモデルを採用し、AWS Transit GatewayやDirect Connectを活用した新しいネットワークアーキテクチャを構築しました。その結果、データ転送コストを60%削減し、HTTPレイテンシーを20-40%改善。さらに、セキュリティコストも50%削減することに成功しています。また、内部開発者プラットフォームの標準化や効率化にも取り組み、エンジニアがより迅速にアプリケーションを開発できる環境を整備した事例は、マルチクラウド環境における実践的な解決策として示唆に富んでいます。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
The New York Timesのクラウドジャーニー：自己紹介と本日のテーマ
こんにちは。まず初めに、本日ご参加いただき、誠にありがとうございます。本日は、ネットワーク効率の最適化とマルチクラウド接続の強化についてお話しさせていただきます。始める前に、簡単に自己紹介をさせていただきます。私はHarleen Kaurと申します。AWSのSenior Solutions Architectとして、The New York Timesと密接に協力させていただいております。ここで、The New York Timesの同僚をご紹介させていただきます。
皆さま、こんにちは。Ahmed Bebarsと申します。The New York TimesのPrincipal Engineerとして、Delivery Engineeringチームに所属しています。具体的には、クラウドインフラストラクチャーが私の専門分野で、プラットフォームの構築と接続方法について取り組んでいます。皆さま、こんにちは。Kaon Thanaと申します。The New York TimesのEnterprise TechnologyチームのStaff Network Engineerを務めています。データセンターの接続、ハイブリッドクラウドの接続、さらには企業ネットワークの接続まで、幅広く担当しています。
本日のアジェンダは、まずThe New York Timesのクラウドジャーニーから始めます。私たちがどこから始まり、現在どこにいるのかについてお話しします。次に、The New York Timesが社内開発者プラットフォームをどのように構築したかについて説明します。これは、社内インフラストラクチャーとガードレールを整備するだけでなく、様々なクラウドプロバイダーからAWSへの移行を促進するためのものです。また、ネットワーキングの構想から解決策まで、ネットワークの最適化と効率化、特にマルチクラウドとオンプレミス環境間での運用における遅延の削減とコスト削減について説明します。
アーキテクチャを通じて、特にマルチクラウドとオンプレミス環境間での運用において、私たちが注目していた主要な指標をどのように改善できたかを、具体的な数値とともにご紹介します。最後に、The New York Timesが経験したこのプロセス全体から得られた重要な教訓を共有して締めくくりたいと思います。ここからは、The New York Timesのエンジニアの方々に、その journey と経験についてお話しいただきます。
The New York Timesのデジタル戦略とクラウド移行の背景
The New York Timesについて少し背景をお話しさせていただきます。The New York Timesは誰もが知る有名な新聞社ですが、今回のプレゼンテーションでご紹介する興味深い統計については、あまり知られていないかもしれません。世界中で約2億2,200万人の読者を持つ、最も引用される新聞社としてグローバルな存在感を示しています。出版業界全体がコストを削減し、ジャーナリズムへの投資を縮小している中、The New York Timesは逆の戦略を取りました。コンテンツ制作に投資を行い、ジャーナリストを雇用し、質の高いコンテンツを提供すれば人々は対価を支払ってくれるはずだという考えで、購読者数の増加を目指したのです。最近の年次報告会で発表された購読者数を見る限り、この戦略は成功を収めているようです。
デジタルフットプリントについて、The New York Timesは大幅に拡大し、現在1,036万人のデジタル購読者を抱えており、そのうち970万人が有料購読者です。そして、そのフットプリントは継続的に成長しています。また、"The Daily"というポッドキャストを提供しており、これは英語圏で最もダウンロード数の多いポッドキャストとなっています。CEO のMeredith Kopit Levienと話すと、彼女の目標はThe New York Timesをテクノロジーカンパニーにすることだと言います。同社のビジョンや競合他社について尋ねると、彼女はThe New York TimesをNetflixと比較したいと答えます。これは従来の出版社では通常考えられない発想です。彼女のビジョンと戦略を見ると、それは実現できると私は考えています。
これは従来の出版社が言うようなことではありません。 まず、The New York Timesが数年前に開始したクラウドジャーニーの基礎から説明していきましょう。当時、ワークロードをクラウドに移行する必要があるという決定が下されました。彼らはワークロードをオンプレミスとクラウドに分割し、半分をAWS、もう半分を別のパブリッククラウドに配置することを決めました。この構成は数年間、実際にうまく機能していました。
そして数年前、彼らは別のパブリッククラウドのワークロードの80〜90%を AWSに移行することを決定しました。私が「もう終わったの？完了したの？」と言うのは、私たちはThe New York Timesと緊密に連携し、彼らの組織と協力して計画を立て、実行してきたからです。まだ道半ばです。そう早くはありませんが、プロセスは進行中です。今日皆さんと共有する事例や使用例を通じて、私たちがどのように移行を開始し、基盤を築き、運用効率を高めていったかという journey をご紹介します。先ほど申し上げた主要な統計データもお話ししますが、次のトピックはAhmadに引き継ぎたいと思います。
内部開発者プラットフォームの構築：標準化から効率化へ
ありがとう、Harleen。始める前に、いくつか質問させてください。皆さんの組織で内部開発者プラットフォームを構築している方は何人いらっしゃいますか？手を挙げていただけますか？素晴らしいですね。マルチクラウドアーキテクチャを使用している方は？もっと多いですね。私の話を、Alan Kayの未来についての考え方に関する引用から始めたいと思います：未来を予測する最良の方法は、それを発明することです。私たちが直面している問題は、マルチクラウドやマルチツールの世界では、単にパスに従うことが時として難しいということです。ほとんどの場合、私たちは自分たちの組織に合うものを発明し、ニーズに適合させ、生産性を向上させたいと考えています。
これにより、エンジニアのために構築するものすべてのスケーリングの機会が向上し、彼らが独自のアプリケーションを発明し構築する方法がより簡単になります。アイデアから本番環境までの過程で、私たちの目標についてどのように考えているか話しましょう。まず第一に、エンジニアがより多くのものをより速く、より効率的に構築できるよう、組織全体で一貫した体験を提供することを考える必要があります。そのためには、すべての障害を取り除きながら、開発ライフサイクル全体を加速させる必要があります。エンジニアリングチームは皆、専門家であり、何をすべきか知っていますが、インフラストラクチャと管理を行う際に、繰り返しの作業に多くの時間を費やしています。そこで、彼らが与えられた課題を解決し、より効率的に多くのプロダクトを構築できるよう、より効率的にする必要があります。
マルチクラウド、マルチツールの世界において、異なる環境、異なるクラウドプロバイダー、さらには異なる地域や大陸間での分散システムをどのように効率的に運用するかという課題に直面しています。この点についてより詳しく説明するために、私たちの組織、そしておそらくみなさんの組織でも、なぜこれを行うのか、そしてプラットフォームを構築する上で最も重要な柱は何かについて議論したいと思います。まず標準化から始めましょう。何かをより効率的にするための第一歩は、それを標準化して障害となるものがないようにすることです。組織全体で経験が一貫性を持ち、統一されているため、新入社員であってもベテランエンジニアであっても、次のサービスやアイデア、製品を構築しようとする際に同じ体験が得られます。次の論理的なステップは効率化です。つまり、繰り返しの作業を排除し、複雑さを取り除き、インフラストラクチャの上に抽象化層を設けることで、これらのタスクを実行するためのプラットフォーム機能を成熟させる方法です。そして統合です。私たちは単なるツールの集合体としてプラットフォームを構築しようとしているわけではありません。
その代わりに、複数のシステムやクラウドプロバイダーと統合される、組織全体で一貫した機能を作り出すことを目指しています。これを実現するために、これらのシステムやツールをすべてプラットフォームに抽象化して統合し、エクスペリエンスを向上させることに注力する必要があります。スケーリングを考える際には、Proof of Conceptから本番環境まで、ゼロから100までどのようにスケールさせるか、そしてプラットフォームのオーバーヘッドを減らしながらそのプロセスをより迅速にする方法を考えることが重要です。これにより、エンジニアリングチームはアプリケーションのスケーリングについて考える時間を費やすのではなく、顧客のために最高の製品を作ることに集中できます。
可視性は非常に重要です。なぜなら、知らないこと、見えないことは改善できないからです。パフォーマンスの洞察を提供するプラットフォームを構築することで、どの領域に改善が必要かを理解し、コストの洞察を得ることで、どこで支出を削減すべきかを特定できます。これらは、組織のプラットフォームを構築してスケールを実現し、より効率的に構築するための生産性を加速させるための実践的な要素です。
これらの要素を、プラットフォーム上でのクラウドインフラストラクチャ基盤の構築方法に適用してみましょう。私たちのプラットフォームはマルチアカウントアーキテクチャ上に構築されており、なぜこの決定を下したのかについて説明します。標準化に関して、より集中化され、AWSで標準化されたプラットフォームアカウントを構築することを決定しました。ここには私たちのランタイムが存在し、すべてが機能しており、すべてのブループリントによってランタイムチームとプラットフォームチームがベストプラクティスを活用しながら、より迅速で優れたエクスペリエンスを提供できるようになっています。スケールする際には、エンジニアリングチームがデータベース用のRDSやElastiCache、S3バケットなど、アプリケーションのためのリソースをより多く起動できる機能をどのように提供するかを考慮する必要があります。私たちは彼らがイノベーションを起こすためのこれらのブループリントをすべて提供しています。
これらのコンポーネントを接続するためにAWS Transit Gatewayをプロセスに組み込み、チームに対してすぐに使える形で提供しています。つまり、チームはこれらのコンポーネントをどのようにネットワーク接続するかについて考える必要がなく、アプリケーションの開発を始める時点ですでに準備が整っているということです。スケーラビリティと可視性については、AWS Control Towerを使用してこれらのアカウント組織をプロビジョニングし、アカウントが特定のOrganization Unitで階層的に構成されていることを確認しています。CloudTrailは、プラットフォームチームやエンジニアリングチームによってこれらのアカウントで実行されるすべてのアクションの可視性を提供し、IAMアイデンティティ管理アクセスは、プラットフォームプロセス全体を理解する上で重要な役割を果たしています。
これが私たちの内部開発者プラットフォーム向けのクラウドインフラを構築する際の基盤となっています。 しかし、ネットワークの観点からは、時間とともにさまざまな課題に直面してきました。10個のアカウントでうまく機能していたものが、数百から数千のアカウントになるにつれて、より複雑になってきたのです。 ネットワークのコストは高額であり、クラウドインフラストラクチャーと組織における最も重要な側面の1つとなっています。 プラットフォームをスケールする際に直面した主な問題の1つが、NAT（Network Address Translation）です。
数ギガバイトの移動であれば、コストへの大きな影響もなく問題なく動作しますが、テラバイトやペタバイトのデータを扱い始めると、特に大規模な組織で複数のクラウドプロバイダー間でデータを移動する場合、NATエグレスによって大きなコストが発生します。複数のクラウドプロバイダー間を移動する際、インターネットへのエグレストラフィックが多くなりすぎるのです。これを解決するには、カスタムNATインスタンスを実装する必要があります。AWSはNAT Gatewayで優れた体験を提供していますが、スケールが大きくなると組織にとって必ずしも有益ではないかもしれません。これは解決策の1つですが、他にもさまざまなアプローチがあります。
私が話した内容の1つは、スケーラビリティと固定費用についてです。1つのアカウントがある場合、VPCにNAT Gatewayが付属し、選択した数に応じて複数のNAT Gatewayを取得できます。しかし、1000のアカウントがある場合、数多くのNAT Gatewayが必要となり、それぞれにアカウントに紐付いた固定費用が発生します。問題は、チームが本当にこれらのリソースを必要としているかどうかです。チームの不要な固定費用を削減する方法を見つける必要があるため、私たちはネットワーク全体を中央集中化し、効率性を向上させるオプションを検討しています。
これが本日のメインテーマであるマルチクラウドコミュニケーションにつながります。私たちは異なるクラウドプロバイダー間の移行を進めていますが、これは異なるクラウドプロバイダー間のコミュニケーションが終わるということではありません。より迅速に移行しながらコストを削減する方法に焦点を当てており、そのためにマルチクラウドプロバイダー間のプライベート接続を、エンジニアリングチームにすぐに使える形で提供することに、より多くの時間を投資しています。
マルチクラウド環境におけるネットワーキングの課題と解決策
既存のアーキテクチャを見てみましょう。チームアカウントとネットワークアカウントがあり、すべてがAWS Transit Gatewayで接続されています。また、ストレージやその他の機能のためのオンプレミス要件があり、AWS Direct Connectを通じて接続されています。これは単一のクラウドプロバイダーの場合はうまく機能します。しかし、複数のクラウドプロバイダーを導入すると、ワークロードが別の場所に配置され、現在のクラウドプロバイダーと通信する唯一の方法は、パブリックインターネット、VPN、または後で説明する他のソリューションを通じてとなります。これにより、すべてのトラフィックがインターネットを経由することになり、私たちがコントロールできない重大な問題が発生します。
私たちの目標は、クラウドプロバイダー間のパブリックインターネットトラフィックを排除し、内部化することです。より良いユーザーエクスペリエンスを提供するために考慮している制約について説明しましょう。マルチクラウド環境で直面する最大の問題の1つは、エグレスコストです。クラウドプロバイダー間でデータを転送する際、両側で課金されるため、これを最小限に抑えたいと考えています。さらに、複数のクラウドプロバイダーにワークロードを展開すると、ベストプラクティスに従って保護する必要がある新しい攻撃対象領域が生まれるため、セキュリティの露出も懸念事項となります。また、インフラを所有していない限り、パブリックインターネットを使用する際のルーティングを制御することはできません。
私たちの評価によると、トラフィックの大部分はEastリージョンで実行されています。East-to-Eastアーキテクチャを持つ複数のリージョンを活用できます。異なるクラウドプロバイダー間のトラフィックと帯域幅の要件を評価し、10ギガビットのトラフィックがより効率的であると判断しました。これらが初期の制約であり、コスト効率とパフォーマンスの面でユーザーエクスペリエンスを向上させるため、これらのパラメータから始めることにしました。
では、この問題をどのように解決しようとしたのか、Kaonに説明を譲りたいと思います。ありがとう、Ahmed。マルチクラウドのパズルについて効果的に説明してくれました。6歳の息子とパズルに取り組む時は、エッジとコーナーから始めて問題を分解していきます。複雑なITインフラプロジェクトでも、同様のアプローチを取ります。制約と要件を特定することが重要なので、Ahmedが前のスライドで説明した制約は、優れた出発点となります。
利用可能なすべてのソリューションの中で、クラウド間のワークロードとアプリケーションワークロードの大部分は、少なくともトラフィックの大半についてはEast-to-Eastです。そのため、すぐにその地理的位置に焦点を当てて問題を解決できます。さらに、フローを分析した後、10ギガビット回線以上は必要ないものの、同時に1本以上は確実に必要だとわかりました。そこで、Site-to-Site VPNを選択肢から除外し、AWSのDirect Connectの提供内容に焦点を当て、Direct Connectを使って複数のクラウドプロバイダーを相互接続するにはどのようなオプションがあるか検討しました。
いくつかのオプションを検討し、私たちが利用できるものの分析を始めました。ニューヨークの本社には既存のデータセンターがあり、そこにはオンプレミスのDirect Connect接続が既に存在します。1つのオプションは、選択した任意のCloud Service Providerに追加の回線をプロビジョニングし、既存の稼働中のルーティングインフラを使用してトラフィックをルーティングすることでした。オンネットの新しい回線を導入するだけなので、コストもそれほどかからず、比較的迅速に実装できます。しかし、このやり方にはいくつかのトレードオフがありました。VirginiaからNew Yorkを経由して再びVirginiaへと、東海岸を上下するヘアピン状のトラフィックが発生し、クラウドネイティブワークロードに追加の遅延が生じます。2つ目の要因として、クラウドネイティブワークロードにオンプレミスのSLA要因が加わることになります。
ネットワークエンジニアとして、データセンターのルーターをアップグレードするためのメンテナンスウィンドウを探す場合、すでに十数人のステークホルダーに配慮する必要があるのに、オンプレミスのネットワークをアップグレードするためだけでも、クラウドチームのために更に十数人追加することになります。できればそれは避けたいところです。オプション2として、ネットワーク・インフラエンジニアの立場から見ると、Greenfieldな環境を構築し、AshburnとRestonにそれぞれColoベンダーを見つけ、ベンダーから最新のLayer 3スイッチやルーターを購入して、すべて自前で構築するという案は非常に魅力的でした。完全なコントロール権を持ち、ルーティングを完全に制御し、回線のプロビジョニングまですべて自分たちで行うというものです。魅力的に聞こえますが、トレードオフもありました。多額の初期投資が必要で、新しいColo事業者のオンボーディングプロセスも必要です。さらに、コロナ後のサプライチェーンの問題で、新しいLayer 3ルーターやスイッチがいつ入手できるか分からず、1年かかる可能性もありました。
そのため、ステークホルダーに対して、この解決策の実装に1年かかる可能性があると伝えなければならず、それはあまり良い選択肢ではありませんでした。この検討プロセスを進める中で、主要なPoints of Presenceにすでにこのようなインフラを構築し、想定されるすべてのCloud Service Providerへの回線をプロビジョニング済みのベンダーが存在することに気づきました。これらのルーターの一部を借り、主要なPoints of Presenceで冗長性を持った独自の仮想ルーターを入手し、そこから接続して回線をプロビジョニングすることができ、Network as a Serviceとしてスケールアップダウンも可能でした。月単位や年単位の契約で柔軟に対応できます。エンジニアとしては、BGPルーティングのCommunity Strings、Prefix Listなど、自前の機器で可能な機能の90%程度は使用できます。もちろん、高度な設定オプションのすべてが使えるわけではありませんが、正直なところ、特殊なユースケースがない限り、それらを使う必要はないでしょう。
私たちはこのオプションで進めることを決定しました。これでコア接続の部分は解決できましたが、次のステップとして、各チームが各クラウドでどのように構築しているか、そして必ずしも同じやり方をしていないかもしれないということを考える必要がありました。AWSではよく定義されているかもしれませんが、他のCloud Service Providerではどうしているのでしょうか？調査を始めると、すぐにモデルを作る必要があることがわかりました。そこで、各Cloud Service Providerに対してHub-and-Spokeモデルを作成し、各チームをSpokeとし、NetworkとInfrastructureチームがHubアカウントを管理することにしました。
チームはこのHubアカウントにアタッチまたはピアリングを行い、オンプレミスや他の必要な接続先へのルートと接続性を提供することにしました。AWSでは、Ahmedが先ほど説明したように、東西のTransit Gatewayがすでに存在し、成熟した設定となっていました。右側では、採用を決めたパートナーの仮想ルーターへの新しい回線を準備する必要がありましたが、これは比較的簡単に実現できました。
他のService Providerについては、Hubアカウントを構築し、他のチームとのVPCピアリングを開始する必要がありました。すべてをInfrastructure as Codeで実装することを重視し、可視化されパイプラインを通じて実行されるようにしました。これにより、チームは一定のコントロールを持ち、インフラがどのようにプロビジョニングされているかを理解できるようになりました。このようなインフラを設計する際、アプリケーションチームは通常、高可用性と冗長性について考えます。AWSでは、異なるAvailability ZoneやRegionでの構築など、アプリケーションチームが気にする必要のないバックグラウンドでの処理が多くありますが、このようなインフラプロジェクトでは、少なくとも99.99%の可用性を達成することに特に注意を払う必要があります。
インフラストラクチャチームとして、アプリケーションチームのオンボーディング時にネットワーク関連のP1インシデントを防ぐため、確実なソリューションを提供する必要があります。 これには、ベンダーのドキュメントを広範に読み込み、プロバイダーごとに異なるベストプラクティスを理解することが含まれます。AWSでは2つの接続で済む場合でも、他のプロバイダーでは4つのInterconnectが必要かもしれません。また、リージョナルルーティングにも細心の注意を払う必要があり、BlueゾーンとRedゾーンを考慮しなければならない場合もあります。
ネットワーク最適化の実装と成果：コスト削減からセキュリティ向上まで
また、最小権限アクセスを実装し、可能な限りスコープを絞ることでCybersecurityを優先しています。 チームが企業全体で自由にルーティングできるわけではありません。代わりに、Infrastructure as Codeパイプラインを通じてセルフサービスモデルを提供しています。チームが新しいプライベートネットワークへのアクセスを希望する場合は、承認用のPull Requestを提出します。承認されてマージされると、プライベートネットワークが利用可能になります。チームは移行のタイミングをコントロールでき、パブリックロードバランサーを維持しながら、自分たちのペースでプライベートロードバランサーにトラフィックを徐々に移行できます。
このようなインフラストラクチャソリューションを設計する際、ルーティングの決定が極めて重要です。BGPはインターネットの言語であり、AWSや他のプロバイダー、そしてオンプレミスのルーターでも使用されています。優先パスを制御するためにBGPポリシーをどのように操作するか、慎重に検討する必要があります。通常、より具体的なサブネットが広範なものより優先される、プレフィックス長が主な方法となります。また、高度なテクニックも利用可能です。例えば、ルーターAがAWSエッジに10/8を送信し、ルーターBが同じ10/8をコミュニティタグ7224:7300付きで送信した場合、AWSルーターはより高いローカルプリファレンスを設定することでそのパスを優先します。同様に、AS Path Prependingを使用してパス長を人為的に増やし、クラウドサービスのエッジルーターに特定のパスの優先順位を下げさせることもできます。
この人為的に増加したパス長によって、それに応じてトラフィックが制御されます。これらのパスを作成する際は、式の書き方や追加のトラフィックの送信方法を考慮することが重要です。
エッジルーターとパートナールーター、そしてエッジルーターまたはクラウドサービスプロバイダーとのBGPメンバーシップを設定した後、 メンテナンスや予期せぬ障害が発生した場合はどうなるでしょうか？BGPのフェイルオーバーを待つと、3分以上のダウンタイムが発生する可能性があります。BGPは本来、高速フェイルオーバー機構として設計されていません。ベストプラクティスは、その上にBFDを実装することです。BFDは300ミリ秒ごとにハートビートを送信し、3回のハートビート（900ミリ秒）を見逃すとフェイルオーバーします。これにより1秒未満のフェイルオーバーが可能になり、AWSはこれらの高感度な機能を提供しています。他のクラウドサービスプロバイダーでは少し異なり、1000ミリ秒×5で5秒のフェイルオーバーになる場合もあります。フェイルオーバーと冗長性のためのパスを構築して検討する際は、これらを念頭に置く必要があります。
クラウドプロバイダー間で複数の冗長パスを構築する際のもう一つの重要な検討事項は、Active-PassiveとActive-Active（Equal Cost Multi-Pathing、つまりECMPと呼ばれる）のどちらの構成を採用するかということです。Active-Passiveの場合、トラフィックは非常に決定論的です。AからBへ移動する場合、ホップ1-2-3を経由するため、トラブルシューティングが容易になります。問題が発生した場合、どこを確認すべきかが明確です。一方、Active-Activeを選択した場合、トラフィックはハッシュアルゴリズムに基づいてリンクを共有し、往路と復路で異なる経路を通る可能性があります。これにより、どこかでグレーアウトが発生した場合のトラブルシューティングが難しくなります。しかし、プロビジョニングしたすべての容量を最大限に活用できるというメリットもあります。ただし、一方のパスが失われた場合に備えて、単一パスを過剰にプロビジョニングしないよう注意が必要です。私たちの場合は、メリットがデメリットを上回ると判断し、ECMPを選択しました。
さて、他のITプロジェクトと同様に、リソースの実装と作成を開始すると、問題に直面し、進行に応じて迅速な調整が必要になります。 ここでは、他のチームが学べる私たちが遭遇した課題をご紹介します。 過去に独立した環境を持ち、他のプライベートIPスペースとの相互接続が必要なかったチームの中には、あるチームが他のチームとRFC 1918スペースを共有しているようなIPスペースの重複が発生することがありました。 さらに、異なるCloud Service Provider（CSP）では、ネットワーキングの概念や構成要素が異なります。あるCSPでは特定のリソースの呼び方が異なったり、LoadBalancerがリージョン間で同じように動作しなかったり、あるVPCが他のVPCのようにグローバルにルーティングされなかったりする場合があります。
また、特にトラフィックコストに関して、AWSのコストフレームワークに細心の注意を払う必要があります。 IPスペースの重複に関しては、影響を受けたのは一部のチームだけで、それらを再IPアドレス割り当てすることができたため、幸運でした。一部の組織ではそれができない場合もありますが、私たちはここで幸運でした。これは、既存環境や技術的負債を抱えるブラウンフィールドプロジェクトに取り組む際に念頭に置くべき点です。
Transit GatewayコストとDirect Connectゲートウェイコストに関して、私たちは80/20ルールに従う大量のトラフィックを発生させるアカウントがあることを発見しました。つまり、帯域幅を大量に使用する少数のAWSアカウントが存在したのです。これらのアカウントをDirect Connectゲートウェイに直接関連付けることで、Transit Gatewayコストと比較して約60%のコスト削減を達成できることがわかりました。これは、これらの大量トラフィックを発生させるアカウントをDirect Connectゲートウェイに直接接続することで実現しました。
これにより追加の複雑さが生じ、パラレルパスを構築する必要がありました。パートナールーターへの追加回線や、反対側での追加インターコネクトが必要になりました。しかし、月間で数千テラバイトのデータを扱う場合、これらの固定月額コストは十分に回収できました。これは実際、プロジェクトの途中で行った重要な最適化であり、プロジェクトの進行を助けるために修正を加えたものでした。
パズルのアナロジーに戻りますと、最終的な統合アーキテクチャは、このように中央に Partner Interconnect Router を配置し、オンプレミスや異なる Cloud Service Provider、そして AWS へ完全な冗長性と高可用性を備えた回線を構築するという形になります。もちろん、可能な限りインターネットトラフィックを避け、プライベート接続を通すようにします。ここで Ahmed に戻して、重要なポイントをまとめてもらいましょう。
ありがとう、Kaon。私たちは「なぜ」「何を」「どのように」について話してきましたが、ここで最初に掲げたビジネス目標に立ち返り、このようなソリューションを組織に導入して得られた成果についてお話ししましょう。まず、データ転送コストを60%削減することができました。これは、複数のクラウドプロバイダー間で発生していたエグレスコストを全て排除できたためです。内部ルートを使用することでより効率的になり、大幅なコスト削減を実現しました。ここで扱っているのはギガバイト単位のデータではなく、実際の本番環境ではペタバイト単位のデータなのです。
異なるアプリケーションやクラウドプロバイダー間のサービス通信は、HTTPレイテンシーが20〜40%改善され、より効率的になりました。これは現在このパターンを使用しているプラットフォーム上のアプリケーションに付加価値をもたらしています。複数の露出サービス攻撃がある場合、これらすべての要素を保護する必要があります。現在は、クラウドプロバイダー間で内部通信を行っているため、少なくとも1つは露出し、1つは露出しないようにサービス攻撃を削減しています。セキュリティを軽視しているわけではありませんが、セキュリティコストを50%削減することができました。
これらすべてがプロジェクトの成功につながり、将来的なスケールを可能にし、複数のクラウドプロバイダーだけでなく、オンプレミスへの接続なども実現して、The New York Times でのアプリケーション開発のスピードと加速を向上させています。本日のトークのまとめとして、一貫性、体験、効率性という3つの目標に関して、私たちはアプリケーションチームや開発者チームがより速くイノベーションを起こし、移行を容易にできるようなセルフサービスの道筋を提供しようとしています。このようなソリューションにより、異なるクラウドプロバイダー間の依存関係を気にすることなく、あるクラウドプロバイダーから別のプロバイダーへとサービスを移行することが可能になりました。クラウドプロバイダー間に多くのシステムやアプリケーションがある場合、移行の制約を検討する際にコストとネットワークが重要な要素となります。以上で締めくくらせていただきます。ご参加いただき、ご清聴ありがとうございました。皆様の環境でこれがどのように革新され、実装されるのか、そしてマルチクラウド接続をどのように改善できるのか、ぜひ拝見させていただきたいと思います。ご質問をお待ちしております。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion