re:Invent 2023: AWSバックボーンで変革するグローバルネットワーク - Cloud WANとSiteLink活用事例

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

📖 AWS re:Invent 2023 - Adding AWS (backbone) to your network (NET319)

この動画では、AWSのグローバルネットワークインフラの裏側と、それを活用したネットワーキングサービスの最新情報を学べます。AWS Cloud WANやSiteLinkなどの新機能が、どのようにして企業のグローバルネットワークを変革しているかを、具体的な事例とともに解説します。特に、Fortiveの事例では、AWS Cloud WANの導入によってネットワークの問題解決時間が35%短縮され、運用コストが66%削減されたという驚きの結果が紹介されます。AWSバックボーンを活用した次世代のネットワーキングの姿がわかる、貴重なセッションです。
https://www.youtube.com/watch?v=GrsWSMiE264
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。

本編

AWSバックボーンネットワークセッションの概要と登壇者紹介

皆さん、こんにちは。「NET319、ネットワークにAWSバックボーンを追加する」セッションへようこそ。re:Inventの初日を楽しくお過ごしいただき、この後1時間ほど私たちと過ごすことを選んでいただいたことを嬉しく思います。今日この部屋にいらっしゃる方は、クラウドインフラエンジニア、クラウドに進出しようとしているネットワークエンジニア、あるいはネットワーキングに興味がある方だと思います。このセッションでは、これらすべての方々に対応していきます。

このセッションは主にバックボーンについてです。AWSバックグラウンドネットワークの背後にあるインフラストラクチャについて話します。また、このネットワークを構築するために使用した主要な原則や信条にも触れ、その後、AWSの顧客がこのバックグラウンドインフラストラクチャを活用するために使用するオーバーレイサービスに移ります。さらに、顧客と話をする際によく見られる一般的なパターンについても触れます。これは、ネットワーキングポートフォリオというツールボックスからさまざまなサービスやツールを組み合わせて、ビジネスに最適なパターンや最良のアーキテクチャを構築する方法です。また、顧客の一人に事例を共有していただき、AWS Networking Servicesを使用してネットワークをどのように近代化したかについてお話しいただきます。

これはレベル300のセッションですので、ネットワーキングサービスプロトコルに関する基礎知識だけでなく、AWSの基本的な概念についても理解があることを前提としています。つまり、少なくともクラウドに馴染みがあることを想定しています。いずれにせよ、私が最初に復習の意味で触れていきます。多くのコンテンツやサービスがあることは承知しています。そのため、セッションの最初の部分で、これらの基本事項に触れ、聴衆の皆さんを同じレベルに引き上げていきます。

私の名前はErnesto Salasです。シニアネットワークスペシャリストで、約4年間AWSで働いており、基本的に顧客がAWSでネットワーキングに関するあらゆることを行うのを支援しています。今日は、友人のCorina Motoiも一緒です。彼女はハイブリッドクラウドチームで働くシニアソリューションアーキテクトです。また、FortiveのNick Mullenixも参加しており、AWSでの彼らのユースケースについて話してくれます。

クラウド移行に伴うネットワーク重心の変化

意図的にこのユーモラスな写真でセッションを始めたいと思います。なぜなら、これは私が顧客と話す日々の大部分を表しているからです。これは、彼らとの議論の要約です。彼らはワークロードをAWSに移行しています。現在、ワークロード移行の最中か、移行を完了しつつあり、データセンターのフットプリントが縮小し始めています。コールロケーションも同様に縮小し始めています。そして今日のデータセンターは、隅っこに4つのラックがあるような感じで、そこにはハードウェアデバイス、特にネットワーキングハードウェアデバイスだけが置かれているという状況です。

お客様とお話しする中で、ワークロードの重心がAWSに移動するにつれて、ネットワークの重心も移動していることがわかりました。私たちは、お客様がAWSのバックボーンネットワークを活用してワークロードを相互接続できるようサポートしてきました。さらに重要なのは、お客様がAWSのバックボーンネットワークを、これらのサービスのほどを通じて支社の相互接続にも利用していることです。

アジェンダでは、まず私たちのインフラストラクチャ、つまり世界最大で最もスケーラブルなネットワークをどのように構築したかについて説明します。その際の原則、なぜそうしたのか、そしてそれらの原則をオーバーレイサービスの構築にどのように適用したかについても触れます。次に、ネットワーキングとコンテンツデリバリーのポートフォリオには40以上の機能とサービスがあることを簡単に振り返ります。しかし、多くのお客様が今日利用している共通のパターンがいくつかあります。これらの原則をサービス構築にどのように適用したか、その理由について簡単に説明し、その後Corinaに引き継いで、これらの異なるパターンと、さまざまなサービスがどのように関係しているかについて詳しく説明してもらいます。最後に、NickがFortiveのユースケースについて説明します。

AWSのグローバルインフラストラクチャとバックボーンネットワークの概要

では始めましょう。すでに世界地図と私たちのグローバルインフラストラクチャが表示されています。AWSのグローバルインフラストラクチャについて話す際、主にリージョン、つまりAWSリージョンについて触れます。リージョンの詳細には深入りしませんが、少なくとも3つ以上のアベイラビリティーゾーンを持つ地理的な場所だと考えてください。アベイラビリティーゾーン内には1つ以上のデータセンターがあります。つまり、アベイラビリティーゾーンはデータセンターのクラスターと考えることができます。次にLocal Zonesがあります。Local Zonesはこれらのリージョンを人口密集地域に拡張したものと考えることができます。基本的に、Local Zonesでは、アプリケーションをお客様の近くに配置し、レイテンシーを削減するというネットワーキングの問題を解決しようとしています。

Local Zonesの別の見方としては、人口密集地域のお客様により近いアベイラビリティーゾーンだと考えることもできます。さらに、ポイントオブプレゼンス（PoP）があります。これはエッジロケーションとDirect Connectロケーションの組み合わせです。エッジロケーションは、例えばCloudFrontやCDN、あるいはAWS Global Acceleratorに関連します。Direct Connectは、プライベート接続をAWSに拡張できるサービスです。

リージョンのネットワークトポロジーを高レベルで見てみると、このようになっています。少なくとも3つのアベイラビリティーゾーンがあります。各アベイラビリティーゾーン内に1つ以上のデータセンターがあります。これらの各ボックス内には、何百もの、あるいは何千ものネットワーキングデバイスと、それらを結ぶ何十万ものリンクがあります。これにより、リージョン内で高可用性の接続とアーキテクチャを提供しています。以前のイベントでのフィードバックに基づいて、このアーキテクチャの詳細について深く掘り下げたコンテンツをますます多く公開しています。しかし、今日はそれについて話すわけではありません。今日はバックボーンについて話します。

では、マップに戻りましょう。バックボーンネットワークを重ねると、さらに印象的に見えると思います。ここでハイライトされている線は、それぞれ400ギガの接続またはファイバーケーブルのペアだと考えてください。これらは全て、AWSがグローバルに構築し、管理・運用しているプライベートネットワークです。でも、なぜでしょうか？クラウドビジネスを始めた当初から、お客様が期待する可用性、スケーラビリティ、パフォーマンス、セキュリティを提供するためには、ネットワークを完全にコントロールする必要があると判断しました。そのため、早い段階で独自のグローバルプライベートネットワークを構築することを決定し、それに伴い、独自のカスタムハードウェアとソフトウェアの開発も始めることにしたのです。

AWSの独自ハードウェア開発とネットワーク設計の原則

通常、この話をする際、最も一般的な例として挙げられるのは、EC2サービスやVPCなどを支えるNitroプラットフォームです。しかし、これはネットワーキングハードウェアやデバイスにも当てはまります。最初に従来のサードパーティベンダーと協力し始めた頃を想像してみてください。私たちはシャーシプラットフォームを使用していました。これは、皆さんも見たことがあるかもしれない、典型的な冷蔵庫サイズのルーターのことです。これらは素晴らしい技術の塊で、その役割を見事に果たします。しかし、私たちは他の企業が直面したことのない新しい課題に直面していました。これらのハードウェアには多くの機能が搭載されていましたが、それは多くの顧客と多様なユースケースに対応しようとしていたからです。私たちには、私たちにしかない非常に特殊なユースケースがありました。

そこで、これらの複雑なシャーシプラットフォームから離れることを決めました。例を挙げると、運用の観点から考えると、これらのシャーシの1つを再起動する必要がある場合、それは非常に大きな作業になります。私たちの規模では、そのような大規模な再起動は許容できませんでした。シャーシ全体を再起動することはできなかったのです。そこで、独自のハードウェアの開発と構築に乗り出すことにしました。これらのハードウェアは通常、シングルチップのネットワークデバイスです。つまり、ネットワーキングスタック全体で使用する1ラックユニットのIPスイッチやルーターのことです。同じデバイスをトップオブラックスイッチとして使用したり、バックボーンで使用したり、エッジで使用したりできます。同じデバイスの異なるバージョンがあり、通常はスピードが異なります。

また、簡素化の原則を適用して、セルの作成も始めました。これは、EC2ネットワーキングやVPC、あるいはTransit Gatewayの背後にあるハイパープレーン技術について話すときに、よく耳にするセルラーアーキテクチャのメッセージにつながります。私たちは、これらの1ラックユニットのスイッチやルーターを1つのラックにまとめてセルを作りました。故障したセルを交換する必要がある場合は、単にそれを取り外して新しいものを送り、そのセル内で障害が発生しても他のセルに影響が及ばないようにしました。これはバックボーンを含む、ネットワークの異なるスタック全体に当てはまります。特別なモデルを追加する必要がある場合、私たちは、パケットが施設を出る際には物理層で暗号化すると言っています。つまり、AWS施設を出るすべてのトラフィックは物理層で暗号化されています。

この暗号化プロセスは、私たちの核心的な原則につながります。

AWSネットワーキングサービスの進化：VPCからTransit Gatewayまで

インフラストラクチャ組織全体と、お客様が利用するネットワーキングサービスにおいて、すべての開発チームが従うこの中核的な信条や原則があります。その指針となる原則は、シンプルさがスケールするということです。

この原則の最も良い例がAmazon VPCです。VPCを最初にローンチしたとき、私たちはお客様が1つのVPCしか使用しないと考えていました。そのため、システムにハードコードされていました。1つ以上のVPCが必要な場合は、私たちに連絡する必要がありました。しかし、お客様がVPCを使って事業部門やアプリケーションを分離し、マルチVPC環境に移行し始めたため、多くの問い合わせを受けるようになりました。これにより新たな課題が生まれました：VPCとアプリケーションをどのように接続するかということです。

この課題に対処するため、Amazon VPC peeringをローンチしました。 Peeringは2つのVPCを1対1の、ポイントツーポイント接続で結ぶ方法ですが、非推移的です。これはAWSネットワーキングの基本的なルールの1つです。VPC peeringでは、2つのVPCを直接接続する必要があり、複数のピアリング間でVPCをトランジットとして使用することはできません。この解決策は、10〜20のVPCを持つ環境でも今日でもうまく機能しています。しかし、数百や数千のVPCにスケールする場合、管理が難しくなります。

2018年、このスケーリングの問題を解決するためにAWS Transit Gatewayをローンチしました。Transit Gatewayはリージョナルルーターとして考えることができますが、バックグラウンドではルーターとは似ていません。論理的には、リージョン内のすべての接続を集中させ、数千のVPCにスケールできるリージョナルルーターとして機能します。Transit Gatewayは、統合を通じてその接続をオンプレミスインフラストラクチャにも拡張できます。

Transit GatewayはAWS Direct ConnectやサイトツーサイトVPNと統合できます。画面に表示されているこのパターンは、お客様の間で最も一般的なパターンの1つとなっています。多くのエンタープライズのお客様にとってのベストプラクティスであり、今日私たちが話をするお客様の多くに広く適用されています。

AWS Cloud WANの導入とグローバルネットワーキングの新時代

データセンターから離れることで、物理的な場所に縛られなくなります。複数のAWS Regionを活用して、エンドカスタマーにより近い場所にアプリケーションを配置できるようになります。お客様は同じパターンを複数のリージョンで繰り返し始めました。3つ以上のリージョンになると、クロスリージョンピアリング接続やポイントツーポイント接続に戻ります。この規模になると、同じ課題に直面します。10、15、あるいは20のリージョンを管理することは複雑になり、特にクラウド環境内のこのグローバルネットワークを管理する専任のネットワーキング担当者がいない場合は難しくなります。

昨年のre:Inventで、AWS Cloud WANを発表しました。これはTransit Gatewayと同じテクノロジーを基盤とするサービスで、グローバル規模の接続を簡素化します。また、ネットワーキングサービスの新しいビジョンであるインテントベースのネットワーキングも紹介しました。このアプローチでは、ネットワークをどのように構築したいかを伝えると、私たちがバックグラウンドでそれを構築し、Transit Gatewayとの後方互換性を維持します。

画面に表示されている組み合わせは、Transit Gateway、AWS Direct Connect、サイト間VPNを使用し、AWSの新しいバージョンのグローバルネットワーキングであるAWS Cloud WANと統合した最も一般的なパターンを表しています。ただし、これらは私たちが提供するサービスのほんの一部です。

以前にも述べましたが、AWSでネットワークを構築するお客様としてご存じのように、お客様の環境は複数のネットワーキングサービスが連携して機能します。これには、Network Load Balancer、サイト間VPN、Client VPN、Transit Gateway、そしておそらくAmazon VPC Latticeのような新しいサービスも含まれます。これらのオーバーレイサービスはすべて、私たちの基盤となるネットワークを利用する方法です。これらをツールボックス内のツールと考えることができます。

AWSネットワーキングサービスの多様性と適材適所の重要性

私たちがお見せしたいのは、適切な仕事に適切なツールを使用する方法です。

このアプローチは、あなたの環境に応じてのみ適切なものとなります。共通のパターンはあるかもしれませんが、そのパターンをそのままあなたの環境に実装しなければならないというわけではありません。また、AWS Local ZonesやAmazon Peeringのような、少しニッチな他のネットワーク以外のサービスもあります。しかし、これらも特にAWSのバックボーンネットワークを活用する方法です。

冒頭で述べたように、CorinaとI私は、お客様との対話に多くの時間を費やしています。お客様と話すことで、これらの共通パターンを見出し、まとめることができるのです。それでは、Corinaがこれらすべてについて説明します。ありがとうございます。

Unicorn.incの事例：クラウド移行とグローバルネットワーク最適化

ありがとう、Ernesto。皆さん、こんにちは。確かに、私たちは顧客やパートナーと多く話をしています。それでは、Unicorn.incをご紹介しましょう。少し楽しんでいきましょう。Unicorn.incは私たちの顧客で、ニューヨークのData Center、本社、そしてムンバイにも本社を持つグローバル企業です。彼らのオフィス、現地拠点はGlobal WANで接続されています。これは基本的に、MPLS、インターネットサービスなど、さまざまなネットワーク技術の組み合わせです。これらは全拠点の接続に使用されていますが、彼らは規模を拡大し始めており、エンドユーザーの体験を重視しています。

私たち全員と同じように、彼らもエンドカスタマーを大切にしています。可能な限り最高の体験を提供する必要があります。では、レイテンシーを改善し、アプリケーションのパフォーマンスを向上させながら、どのようにスケールアップできるでしょうか？答えは、クラウド、AWSクラウドに移行することです。近接性のため、ニューヨーク本社に最も近いVirginiaリージョン、そしてもちろんムンバイ本社に最も近いMumbaiリージョンを選択しました。クラウドに移行した今、彼らは混合環境、ハイブリッド環境を持つことになりました。

次の疑問は、「では、私、Unicorn.incは、どのようにしてエンドユーザーの体験を実際に改善できるのか？」です。AWSのバックボーンを使ってどのように改善できるか見てみましょう。これがこのセッションのテーマですよね？ では、再び、このUnicorn.incのアーキテクチャ、クラウドとオンプレミスの混合アーキテクチャを見てみましょう。より現実的にするために、Unicorn.incがゲーム会社で、彼らのゲーム「Unicorn Assembly」が非常に人気で、世界中のユーザーやゲーマーがプレイしたがっていると仮定しましょう。メキシコのユーザーがいます。オーストラリアのユーザーもいて、とても人気があるので誰もがプレイしたがっています。

これらのゲームをご存知かもしれませんが、ユーザーはインターネットを介してAWSリージョンにデプロイされたゲームにアクセスしています。メキシコからNorth Virginiaやメキシコからムンバイへの接続は、想像できるように信頼性が低い可能性があります。では、どうすればよいでしょうか？ユーザーはゲームにアクセスする際に素晴らしい体験を求めています。プレイしようとする時に素早いレスポンスを望んでいます。では、このユーザー体験、あるいはゲーマー体験をどのように改善できるか見ていきましょう。

AWS Global Acceleratorを活用したゲームパフォーマンスの向上

そのために、AWS Global Networkについて見てみましょう。Ernestoが言っていたように、これは世界中のAWSデータセンターとエッジロケーションを完全に冗長化された400ギガビットイーサネットファイバーで相互接続するプライベートバックボーンです。このファイバーケーブルとネットワークデバイスのウェブは、基本的にすべてのAWSロケーション間でグローバルな低レイテンシーを実現するために作られています。これが550以上のPoints of Presence（エッジPoP）と連携して、エンドユーザーにサービスをより近づけ、クラウドのデプロイメントとやり取りする際により良い体験、より良いパフォーマンスを提供できるようにしています。

では、どのように機能するか見てみましょう。想像できるように、すべてに適合する1つのケース、1つの製品、1つのサービスというものはありません。私たちはみな異なる体験をしています。そこで、最初のケースを見てみましょう。プレイヤーたちは、オンラインプレイやゲーム内購入などのために、クラウド上のゲームにできるだけ速くアクセスしたいと考えています。では、AWS Global Acceleratorを使用しながら、外部インターネットを介してどのようにそれを実現できるか見てみましょう。

このサービスは、ほとんどのエッジPoints of Presence（PoP）で利用可能で、特にマルチリージョンデプロイメントのトラフィック管理を簡素化し、動的コンテンツの配信を加速することでアプリケーションのパフォーマンスを向上させます。

AWS Global Acceleratorでは、インターネットからのトラフィックがGlobal Acceleratorが存在する110のPoints of Presenceを通過し、AWSバックボーンに移動します。その後、このトラフィックはAWS Global Networkを介してリージョナルエンドポイントにルーティングされます。このアプローチにより、ゲーム内のレイテンシー、ジッター、パケットロスが削減され、企業とエンドユーザーの両方にメリットがあります。AWS Global Acceleratorは、エンドカスタマーの地理的位置に基づいて最適なAWSリージョンを選択します。これは特にマルチリージョンデプロイメントにとって重要です。これにより、Unicorn.incは基本的なインターネットアクセスと比較して60%のパフォーマンス向上を実現し、改善されたパフォーマンスを提供できます。

Global Acceleratorは OSI モデルのレイヤー4 で動作するため、TCP や UDP アプリケーションであれば何でも利用できるという大きな利点があります。Global Accelerator は、EC2 インスタンス、Network Load Balancer、Application Load Balancer、Elastic IP など、クラウド内の複数のアプリケーションエンドポイントを、同じ Anycast IP アドレスの背後に置くことができます。 Global Accelerator を作成すると、2 つの静的 IPv4 Anycast アドレスが割り当てられます。デュアルスタックの Global Accelerator を選択した場合は、2 つの IPv6 静的 Anycast IP アドレスも追加で取得できます。

これらの IP アドレスは、すべての AWS Global Accelerator PoP で公開され、エンドユーザーに最も近いエッジロケーションで、インターネットからの着信トラフィックを AWS グローバルネットワークに受け入れます。AWS のバックボーンに乗ると、トラフィックは最適なネットワークパスを通って、リージョン内のエンドポイントに到達します。

Amazon CloudFrontによるコンテンツ配信の最適化

では、コンテンツのダウンロード時間を短縮したり、プロモーションコンテンツを配信したりして、ユーザー体験を向上させたい場合はどうでしょうか？ここで Amazon CloudFront の出番です。 Amazon CloudFront は、AWS グローバルネットワークを活用した、静的および動的コンテンツの高速配信サービスです。視聴者により近い場所でコンテンツを保存するグローバルなエッジロケーションネットワークと、リージョナルエッジキャッシュを利用しています。静的コンテンツだけでなく、動的コンテンツや TCP フローの配信にも対応しているのですが、この機能はあまり知られていないものの、非常に便利です。

AWS CloudFront は、オリジンとの永続的な接続を維持します。つまり、エッジ PoP にコンテンツがない場合でも、オリジンとの新しい TCP や TLS 接続を確立する必要はなく、既存の永続的な接続をそのまま使用できるのです。 さらに、Amazon CloudFront を Amazon Route 53 と組み合わせることで、マルチリージョン展開におけるフェイルオーバーのための堅牢なアーキテクチャを構築できます。

このサービスを利用するには、CloudFront ディストリビューションを作成し、公開されているドメイン名でオリジンを設定します。オリジンはコンテンツが保存される場所で、CloudFront はそこからコンテンツを取得して視聴者に配信します。エッジ PoP にコンテンツがない場合、CloudFront はリージョナルエッジキャッシュを使用します。 このリージョナルキャッシュは、エッジ PoP とオリジンの間に位置し、より大きな保存容量を持っています。これにより、AWS バックボーンを経由してリージョンに戻ることなく、ユーザーにより近い場所でコンテンツを提供できます。Amazon CloudFront は、AWS バックボーンを活用してオリジンフェッチを改善し、動的コンテンツの高速化を実現することで、効果的にお客様にサービスを提供し、ユーザー体験を向上させています。

AWS Local Zonesを活用した低遅延アプリケーションの実現

Amazon CloudFrontはコンテンツ配信に優れたソリューションを提供していますが、特定のユースケース向けに設計された他のAWSサービスもあります。 例えば、AWS Global Acceleratorはパフォーマンス向上のための別のアプローチを提供しています。しかし、あなたのゲームがAR/VR体験も提供している場合はどうでしょうか？ユーザーはゲームへの一桁ミリ秒のアクセスを必要としています。ここで、ユーザーの地理的近接性を考慮したAWS regionの拡張であるAWS Local Zonesについて見てみましょう。 現在、AWSは世界中の都市圏に33のLocal Zonesを展開しています。このシナリオでは、メキシコにゲーマーがいることを考慮して、メキシコのケレタロLocal Zoneを選択し、オーストラリアのユーザー向けにはパースLocal Zoneを選びました。これらの場所は、クラウド上のAR/VR体験にアクセスすると予想されるユーザーにより近い位置にあります。

Local ZoneはAWSのバックボーンを通じて物理的にregionに接続されています。これを実装するには、アカウントでLocal Zoneを有効にし、regionからAWS Local ZoneにVPCを拡張します。これにより、お客様により近いLocal Zoneでの構築が可能になり、デプロイメントにアクセスする際に全てのお客様が一桁ミリ秒の遅延の恩恵を受けられるようになります。 さらに遅延を改善するため、Local Zoneは都市圏のISPとのインターネット接続を独自に持ち、Direct Connectもサポートしています。これにより、Local Zone内のリソースへの非常に低遅延でのアクセスが保証されます。また、regionとは完全に別個のIPアドレスプールも持っています。

まとめると、AWS Local Zoneは、コンピューティング、ストレージ、その他の専用サービスをエンドユーザーの近くに配置することで低遅延を実現し、同時にAWSバックボーンを介してregionとの接続を維持します。この接続により、他の全てのAWSサービスへのアクセスが可能になります。ユーザー体験の向上方法について説明しましたので、 次はAWSバックボーンを使用して企業のインフラストラクチャをどのように強化できるかを見ていきましょう。いくつかのシナリオを検討しますが、まずは最も一般的なハイブリッドアーキテクチャの構築と、このプロセスにおけるAWSバックボーンの役割から始めます。

AWSを活用したハイブリッドネットワークアーキテクチャの構築

オンプレミスのサイトをregionにデプロイしたリソースに接続することに焦点を当てましょう。最初のシナリオでは、Unicorn.incがリソースをデプロイしているAWS regionへの非常に高スループットの接続を必要としているとします。朗報として、パブリックインターネットを使用せずに、Amazon peeringサービスを使ってAWS Global Networkと直接相互接続できます。これは、98のパブリックインターネットエクスチェンジポイントのいずれかで行えます。また、特定の場所でプライベートピアリングも提供しています。相互接続の仕組みと接続方法の詳細については、peeringdb.comのamazon.comプロファイルをご確認ください。

大まかに言えば、Amazon peeringは次のように機能します：インターネットエクスチェンジのPoints of Presence（PoP）には、ピアリングに興味のある全てのネットワークがあります。当社のルーターはGlobal Networkにアクセスでき、相互接続を希望する場合、全て同じファブリックに接続されます。BGPを通じて、お互いにルートを交換します。Amazon peeringでは、regionへの近接性、サービスエンドポイント、その他の考慮事項に応じて、これらの場所で配信するルートを選択的に選んでいることに注意することが重要です。

Amazon ピアリングは、インターネットをバイパスして AWS グローバルネットワークを使用して直接リージョン内のリソースにアクセスする優れた方法ですが、サービス提供ではありません。 必要に応じて SLA を提供できる信頼性の高い接続を持つサービス提供が必要な場合は、AWS Direct Connect を見てみましょう。AWS Direct Connect は、Direct Connect ロケーションと AWS グローバルバックボーンを介して、オンプレミスからクラウド内のリソースへの最短パスを専用のネットワーク接続で提供します。

現在 AWS Direct Connect を使用している場合、AWS Direct Connect ロケーションはサードパーティのコロケーション施設です。 AWS のホームデバイスとパートナーまたは顧客のデバイス間のクロスコネクトを通じて、顧客は AWS バックボーン全体にアクセスでき、リソースをデプロイしているどのリージョンにもルーティングできます。 お客様は、最大 100 Gbps のリンクを持つ専用接続を選択することができます。あるいは、ホステッド接続と呼ばれるパートナーからの接続を選択し、最大 10 Gbps の速度を提供することもできます。

AWS Direct Connect には、Direct Connect Gateway という概念もあります。 これはグローバルに利用可能なリソースです。AWS Direct Connect Gateway を使用して、 オンプレミスの場所から AWS Direct Connect 接続を介して、プライベート VIF またはトランジット VIF を使用してクラウド内のリソースに接続できます。 また、Direct Connect 接続にパブリック VIF を設定して、パブリックエンドポイントにアクセスすることもできます。ただし、Direct Connect Gateway はパブリック VIF では機能せず、プライベート VIF とトランジット VIF でのみ機能することに注意してください。

さて、AWS グローバルネットワークにアクセスしてオンプレミスからクラウドリソースに到達する方法について説明しましたが、次はマルチリージョンデプロイメントについて考えてみましょう。VPC の数が少ない場合、Direct Connect 接続にプライベート VIF を設定し、Direct Connect Gateway に接続し、そこに VPC の仮想プライベートゲートウェイを関連付けるでしょう。そこで疑問となるのは、「異なるリージョン間で VPC をどのように接続するか」ということです。

このシナリオでは、クロスリージョン VPC ピアリングを使用できます。異なるリージョンの VPC 間でピアリング接続を確立すると、トラフィックがプライベート IP スペース内に留まり、常に AWS バックボーン上を通ることが保証されます。 クロスリージョン VPC ピアリングを使用すると、トラフィックは AWS によって安全に管理されます。ただし、クロスリージョン VPC ピアリングは推移的ではないことに注意が必要です。 例えば、ニューヨークから Mumbai リージョンへの Direct Connect 接続がなく、ニューヨークから Mumbai リージョンの VPC にアクセスしたい場合、ネイティブにはそれを行うことができません。もちろん、回避策はありますが、クロスリージョン VPC ピアリングが推移的でないことを覚えておいてください。

より良いアプローチで、より多くのVPCを持つデプロイメントにも適しているのは、Transit Gatewayを使用することです。 Transit Gatewayを使用する場合、通常、Direct Connect上にトランジットVIFを設置し、それをDirect Connect gatewayに接続します。そして、Transit GatewayをそのDirect Connect gatewayに関連付けます。VPC間の通信を可能にするには、リージョン間Transit Gatewayピアリングを使用できます。クロスリージョンVPCピアリングと同様に、リージョン間Transit Gatewayピアリングでは、トラフィックはAWSのグローバルバックボーン上に留まり、セキュリティとパフォーマンスが確保されます。

つまり、あるリージョンから別のリージョンへの通信は、AWSのグローバルバックボーン内に留まります。管理の観点から見ると、リージョン間ピアリングでは、Transit Gateway上で設定する必要のあるルーティングエントリを手動で挿入する必要があります。異なるリージョンでTransit Gatewayを設定する際は、それぞれ異なるASNを持つようにしてください。将来的には、ルートが動的に伝播されるようになる可能性もありますが、Transit Gatewayを設定してASNを選択すると、後から更新することはできません。そのため、異なるASNを確実に設定するようにしましょう。

ハイブリッドアーキテクチャについて話してきましたが、AWSのグローバルバックボーンの非常に興味深い使用例として、AWSリージョンを完全にバイパスしてオンプレミスサイトを接続する方法があります。この例では、Unicorn.incがニューヨークとムンバイを接続して、信頼性の高いトランジットネットワーク接続を作成したいと考えています。ここでは、AWS Direct Connect SiteLinkを使用します。これは本質的に、リージョンをバイパスしてオンプレミスサイトを接続します。つまり、リージョン内に何も必要ありません。必要なのは、Direct Connectを使用してDirect Connect上にVIFを作成することだけです。

VIFと言いましたが、プライベートVIFまたはトランジットVIFを持つことができ、それらを作成する際に、「このVIFでSiteLinkを有効にしたい」というチェックボックスにチェックを入れるだけです。非常に簡単で便利です。さらに興味深いことに、3つ目のサイトを追加することもできます。実際、最大30のインターフェースを追加してDirect Connect gatewayに接続できます。つまり、最大30の異なるオンプレミスサイトを、すべてDirect Connectを使用して接続し、SiteLinkを利用できるのです。

これらのVIFがすべて同じDirect Connect gatewayに接続されると（これが重要です）、それらの間でデータの送信を開始できます。データは、AWSのグローバルバックボーンを使用して、AWS Direct Connect locationの間で最短経路を辿ります。プライベートVIFとトランジットVIFを持つことができます。繰り返しになりますが、パブリックVIFはDirect Connect gatewayでは機能せず、接続はAWS Global Network内に留まります。

SiteLinkを使用すると、Direct Connect gatewayは、SiteLink対応のVIFを介してお客様のルーターからBGP IPv4およびIPv6プレフィックスを学習し、BGPベストパスアルゴリズムを実行し、ネクストホップやAS PATHなどの属性を更新し、その後これらのBGPプレフィックスを残りのSiteLink対応VIFにアドバタイズします。 Direct Connect gatewayからこのアドバタイズメントを受信した後、お客様のルーターはルートテーブルを更新し、AWS backboneを介してAWS Direct Connect拠点間の最短経路を使用して、SiteLink対応拠点間のトラフィックを転送します。

この機能を使用して、AWSのグローバルバックボーンをお客様のプライマリバックボーンに変換したり、既存のバックボーンのバックアップとして使用したりできることを知っておくことが重要です。SiteLinkのもう一つの一般的なユースケースは、ビジネスの成長に伴って新しい拠点を簡単に追加できることです。

これで最後のシナリオに移ります：AWSでSD-WANハブを構築する場合です。 ここでも、Unicorn.incを例に挙げましょう。Unicorn.incはオンプレミスでSD-WANを運用しています。 お客様からよく聞かれる質問は、「AWSクラウドにデプロイメントがあるので、オンプレミスで運用しているSD-WANをAWSクラウドとどのように統合できますか？」というものです。 お客様が行っているのを見てきたのは、SD-WANアプライアンスをAWS内の専用のVPCにデプロイすることです。これをSD-WANアプライアンスVPCと呼びましょう。

その後、Direct Connect private VIFを使用してオンプレミスをAWSグローバルバックボーンに接続し、Direct Connect gatewayと仮想プライベートゲートウェイを使用してそのVPCに接続します。クラウド内に複数のVPCがある場合のシナリオでは、Transit Gatewayを使用します。このTransit Gatewayには、すでにすべてのワークロードVPCが接続されています。そこで、このSD-WAN VPCアプライアンスをTransit Gatewayに接続します。これにより、オンプレミスからクラウドへのオーバーレイを拡張します。

このオーバーレイをAWS SD-WANアプライアンスVPCに拡張するには、SD-WANアプライアンスVPCをTransit Gatewayと統合する必要があります。 なぜなら、そこにすべてのワークロードVPCが接続されているからです。この統合には、Transit Gateway Connectを使用します。これは、 Transit GatewayへのVPC接続の上にGREトンネルを実行することで、SD-WANアプライアンスをAWS Transit Gatewayにネイティブに統合する方法です。

このようにすることで、現在のSD-WANパートナーのオーケストレーションプラットフォームを使用して、オンプレミスのグローバルネットワークをエンドツーエンドで管理できるという大きな利点があります。Direct Connectは、SD-WANのトランスポートメカニズムとして使用する一つの方法ですが、インターネットを使用してクラウド内のSD-WANアプライアンスVPCに接続することもできます。

複数のサイトがある場合、SiteLinkを使用すると、仮想プライベートインターフェースまたはトランジット仮想インターフェースでSiteLinkを有効にするだけで、実際にSD-WANを1つのサイトから別のサイトに拡張できることを指摘したいと思います。そこで疑問が生じます。複数のリージョンがある場合はどうでしょうか？ 複数のリージョンと複数のオンサイトロケーションにまたがるSD-WAN統合をどのように管理すればよいでしょうか？さらに重要なのは、トラフィックの送信元や宛先に関係なく、オンプレミスで持っている同じトラフィックセグメンテーションをクラウドでどのように維持するかということです。

このシナリオの範囲では、オンプレミスに本番環境と開発/テスト環境という2つのルーティングドメインがあると仮定しましょう。これらのドメインを使用しているすべてのリージョンで維持したいと考えています。 SD-WANを使用すると、オンプレミスにある各種セグメントごとに異なるトランジットゲートウェイ接続を作成し、それらをリージョン内のトランジットゲートウェイに拡張できます。ご存じの通り、トランジットゲートウェイでは複数のドメインを持つことができます。

しかし、ここで疑問が生じます。「トランジットゲートウェイピアリングを使用して、異なるドメインをリージョン間で拡張できるでしょうか？」 実は、そう簡単ではありません。その理由は、トランジットゲートウェイのリージョン間ピアリングを経由するトラフィックがすべてのトラフィックで使用されるためです。異なるセグメンテーションは維持されません。では、 開発環境、テスト環境、特に本番環境を分離するために重要なトラフィックセグメンテーションを維持しながら、オンプレミスと異なるリージョンにまたがるグローバルネットワークをどのように実現できるでしょうか？

AWS Cloud WANによるグローバルネットワーク管理の簡素化

そのために、AWS Cloud WANを見てみましょう。AWS Cloud WANは、Ernestoも言及したように、 オンプレミスとマルチリージョンの展開の両方を含む統合ネットワークの監視を容易にするサービスです。これを実装するために、マルチリージョンのトランジットゲートウェイベースのアーキテクチャから、包括的なCloud WANアーキテクチャへの移行を開始します。

まず、グローバルネットワークの構築から始めます。これには、グローバルネットワーク内のすべてのネットワーク要素が含まれます。次に、コアネットワークを作成します。これはグローバルネットワークの一部ですが、 AWSが管理する要素のみを含んでいます。3番目で最も重要なコンポーネントは、コアネットワークポリシーです。 これにより、AWS Cloud WANでネットワークを非常に簡単に管理できるようになります。コアネットワークポリシーはJSON形式を使用し、セグメントの設定方法、アタッチメントの内容、ルーティングの動作方法を宣言します。これがどのように私たちのアーキテクチャに反映されるか見ていきましょう。

コアネットワークポリシーでは、含めたいリージョンを定義します。今回の場合、VirginiaとMumbaiがあります。この時点で、Cloud WANはこれらのコアネットワークエッジルーターを構築します。これらは Transit Gatewayとかなり似ています。各リージョンにそれぞれ構築し、その後アタッチメントがコアネットワークエッジルーターに接続されます。次に、セグメントの構築を開始します。先ほど説明したproductionとdevのセグメントがあり、on-premisesとの接続用にhybridセグメントも設けましょう。セグメントは専用のルーティングドメインです。hybridセグメントはon-premises環境との接続にも使用されます。

VRFと呼びたい方もいるかもしれません。これらのセグメントもルーティングポリシーで定義できます。すべてルーティングポリシーで行われ、非常に簡単です。時間の都合上、Cloud WANへの一気移行に直接進みます。

元々Transit Gatewayにアタッチされていた私たちのVPCは、今度はCloud WANのセグメントにアタッチされます。Cloud WANはネイティブVPCアタッチメントをサポートしており、 VPCとセグメントのマッピングはコアネットワークポリシーで指定されます。例えば、このコアネットワークポリシーでは、 TAGがprodのすべてのアタッチメントがprodセグメントにマッピングされます。VPCアタッチメントの他に、 Cloud WANはVPC Connectアタッチメントもネイティブにサポートしており、SD-WANアプライアンスをコアネットワークエッジに接続できます。

本当にクールなのは、数週間前に新しいトンネリングプロトコルを発表したことです。GREに加えて、高性能なトンネリングをサポートするようになりました。GREやIPSecプロトコルではパケットオーバーヘッドがありますが、トンネリングプロトコルではそれがありません。そのため、トンネリングを使用すると、最大100ギガビット/秒のアタッチメントが可能になり、 高スループットが必要な場合には非常に興味深い選択肢となります。

さて、VPCを接続しました。 SD-WAN VPCを接続しました。おそらく、VPNも接続されているでしょう。Cloud WANはネイティブVPN接続をサポートしているからです。 Direct ConnectをCloud WANに接続する必要がある場合、現時点ではネイティブ接続はサポートされていません。Direct Connectをトランジットゲートウェイに接続し、そのトランジットゲートウェイをその特定のリージョンのコアネットワークとピアリングする必要があります。

これは重要な考慮事項につながります。アーキテクチャを構築する際、すべてのVPCをCloud WANに移行するビッグバンアプローチが本当に必要なのか、それともトランジットゲートウェイとCloud WANを連携させて共存させるフェデレーションアプローチが必要なのか、よく考えてください。Direct Connectが必要な場合は、Transit Gatewayも必要になることを覚えておいてください。この件については非常に有益なブログ記事がありますので、Cloud WANの使用を検討している場合は、どの戦略が最適かよく考えてみてください。

これで、初期のアーキテクチャがCloud WANに移行されました。つまり、Network Managerを使用して管理することになり、単一のインターフェースが提供されます。コアネットワークポリシーを使用して自動化を構築できます。マルチリージョン展開や複数のオンプレミスサイトに最適です。ぜひ試してみてください。この30分間で多くのことをカバーしましたが、実装できる、あるいは考えるきっかけになる有用なシナリオを少なくとも1つは提供できたと思います。

Fortiveの事例：AWS Cloud WANを活用したグローバルネットワークの近代化

では、Unicorn.incの実例として、FortiveがAWS Cloud WANとAWS Global Networkを使用してグローバルネットワークを構築した方法について、Nickに説明してもらいます。Corina、ありがとうございました。

ここにいられて本当に嬉しいです。私はNick Mullenixです。 Fortiveに所属しており、これは物理的なデータセンターの相互接続をAWSに移行した私たちの話です。これがあなたにとってどのように関連するでしょうか？おそらく、現在物理的なデータセンターの接続環境をお持ちかもしれません。大規模な運用フットプリントをお持ちかもしれません。複数のリージョン、さらには複数の大陸で運用されているかもしれません。

Fortiveでも同様のシナリオがあります。この図をご覧ください。これは数年前の私たちのシナリオです。Fortiveについて少し背景をお話しすると、私たちは技術系のコングロマリットです。製造業、研究所など、多岐にわたる事業を展開しています。そのため、拠点のネットワーク接続にはさまざまなユースケースがありますが、基本的には集中型のインフラサービスを提供しています。拠点の場所に関係なく、すべての拠点がFortiveの中央WANと通信できるようにする必要があります。これらの物理的なデータセンターには多くのレガシー技術が存在していました。機器に手を加えるには人件費がかかり、物理回線にもコストがかかります。管理が難しく、スケーラビリティも良くありません。

運用面では、非同期ルーティングの問題が多くありました。このようなネットワークを大規模に変更するのは非常に困難です。AWSとのパートナーシップを考慮し、FortiveはAWSと素晴らしい関係を築いており、AWSのさまざまな機能を活用しています。そこで、ネットワーク機能の一部をAWSに移行することを検討し始めました。

最初は、Fortiveが持っていた3つの物理的なオンプレミスデータセンター（Amsterdam、Seattle、Ashburn）と同じ地域接続を維持しようとしました。その同じフットプリントをAWSに移行しようとして、このような地域フローを考案しました。もちろん、これは非常に抽象化されたものですが、重要なポイントは、すべてのトラフィックが何らかの地域コアに向かって流れるということです。その地域コアが、ピアリングやルーティング関係などすべてを処理します。

つまり、ANV VPNスポークであろうと、Direct Connectを使用していようと、SDNプロバイダーやSD-WANスポークであろうと、最終的に接続性やルートが地域に入ると、一連のTransit Gateway接続を経由してTransit Gatewayにホームランし、最終的に地域のバックボーンに到達します。これは、マルチリージョン化するまでは非常にうまく機能しました。そこで私たちは、どうすればこれをよりスケーラブルにし、複数のリージョンで運用してルートを交換できるようにできるかという課題に直面しました。

Transit Gatewayピアリングは、私たちにとってあまりスケーラブルではありませんでした。Fortiveにとって大きな欠けていたピースは、AWS Cloud WANでした。AWS Cloud WANについて読んだときのことを今でも覚えています。AWS re:Invent 2021には参加していませんでしたが、確かAWS re:Invent 2021で発表されたと思います。日付は正確ではないかもしれませんが、2022年6月下旬に市場に登場し、Fortiveではすぐに導入する準備ができていました。

私たちにとって、それは次のようなものでした： 3つのリージョンがあります。それぞれのリージョンにCloud WANコアネットワークエッジアタッチメントを作成しました。ここでの魔法、秘訣は、バックボーンのルーティングやファイアウォールのデバイス（何と呼ぶにせよ）が互いに直接通信できるようになったことです。BGPピアリング関係を作成でき、ルートを動的に交換できるようになりました。これは完全に動的なソリューションです。新しいスポークサイトを追加したり、スポークサイトを削除したり、新しいDirect Connectを追加したりしても、高いレベルで地域的に動的に割り当てられます。ほぼ自動的です。

これは非常に高レベルな概要ですが、これによって私たちのネットワークスタック全体の問題解決のMTTRを35%削減することができました。このシステムに移行することで、チケット発行、インシデントチケット、リクエストチケットなどを、実際にそれだけ環境から完全に取り除くことができたのです。そしてもう一つ指摘したいのは、これが非常にパフォーマンスの高いソリューションだということです。

AWS Cloud WANには、パフォーマンスに本当に驚かされたいくつかの使用例があります。最初に紹介するのは、ここに3つのリージョンがありますが、私たちには多くの異なる地域に大規模な労働力もあるということです。私たちの場合、インドに非常に大きな派遣労働力があり、オーストラリアにも大きな製造拠点があります。このソリューションを使えば、例えばムンバイのAP Southなどに新しいリージョンを作成し、数時間以内に同じタイプのトポロジーをデプロイすることができます。

ルーター用の仮想イメージ、EC2イメージをロールアウトし、ピアリング関係を作成できます。実際にこれを行ったことがあります。以前の同僚で現在AWSにいるEric Brooksに聞いてみれば、彼も同じことを言うでしょう。私たちは両方とも、このインフラをスピンアップしてテストを実行したときのことを覚えています。パフォーマンスへの影響があるかもしれないと予想していました。オーストラリアから別のサイトへの直接のMPLS接続を見て、「追加の遅延が発生するかもしれない」と考えていました。しかし、これは実際にMPLSよりも優れたパフォーマンスを示し、まるで魔法のように感じました。追加の中継パスやすべての追加技術が関与しているので、少し遅くなるだろうと予想していましたが、うまく機能するかどうか見てみましょうと思っていました。いいえ、実際にはより良く機能しました。

私たちは自分たちの作業を確認し直さなければなりませんでした。何か見落としているのだろうか？ そのため、これは本当に、本当にエキサイティングでした。私にとってのスケールという点では、これによって夜もぐっすり眠れるようになりました。なぜなら、コアネットワークサービスの地域的な可用性を、ユーザーベースにできるだけ近づけて拡張できるからです。私たちは3つから始めましたが、おそらく来年には5つになるでしょう。そして、AWSについて確かに言えることは、彼らが常に新しいものを追加しているということです。おそらく私たちがここで話している間にも何か追加されたでしょう。AWS Cloud WANにも常に新しいリージョンが追加されると思います。これは素晴らしいことです。私のような立場の人間にとって、物事をより簡単にするのに本当に役立ちます。

パフォーマンスが向上したのは確かですが、私にとって最良なのは運用コストがどれだけかかったかということです。実際には、大幅なコスト削減になりました。支出の3分の2近くを削減できたのです。運用コストが66%も削減されたのです。私のような立場の人間が...ネットワークは通常コストセンターです。通常は会社にお金がかかり、新しい技術を導入しようとすると、それもまた会社にお金がかかります。そのため、より良く機能し、サポートが容易で、より柔軟で、スケーラブルで、適応性が高く、しかも会社にとってより安価なものを導入できたことは素晴らしいことでした。まとめると、そしてこれをErnestoに戻しますが、これは非常に大まかな概要ですが、これが実際に、私の意見では、未来だということを覚えておいてください。非常に柔軟性が高く、より多くの企業が同じような変革の旅を経験することを楽しみにしています。どうもありがとうございました。

AWSネットワーキングの今後の展望とフィードバックの重要性

はい、その通りです。Nickに大きな拍手をお願いします。正直、彼のエネルギーが大好きで、NickとFortiveと一緒にグローバルネットワークを近代化する作業は非常に楽しかったです。Nickほど適任な人はいないでしょう、この話を語るには。Fortiveと同様に、私たちには同じような変革を経験している他の多くの顧客がいます。成熟度のレベルやサービスの組み合わせは様々です。Corinaが今日これらのユースケースを通じて紹介したのは、最も人気のあるものの一部です。私は、バックグラウンドでどのように作業を行っているか、つまり通常は見えない部分もお見せしたいと思います。もちろん、これはレベル300のセッションでしたが、他の400以上のセッションもチェックしていただきたいと思います。そこでは、Data Centerからバックボーンに至るまで、実際にネットワークインフラをどのように構築したかについて深く掘り下げています。

最後に、NickとCorinaが言及したように、私たちは常に新機能や新サービスをリリースして、提供内容を改善し、AWSでこれらのグローバルネットワークを構築できるようにしています。Corinaが言及したように、最近、Tunnel-less Connectと呼ばれるものを立ち上げました。これは基本的に、SD-WAN接続をCloud WANに拡張するためのGREトンネルの必要性を排除し、グローバルネットワークの作成を容易にするものです。お好みのSD-WANプロバイダーがある場合、Cloud WANに簡単に接続でき、GREによる追加のオーバーレイの負担を取り除くことができます。また、他の顧客からの事例研究もあり、例えばSiteLinkに移行した際のパフォーマンス向上について語っています。Motionalは、自社で測定したパフォーマンスとコスト削減について話しています。

Nickが言及したように、ネットワーキングは通常コストセンターです。そのため、ネットワーキングについて話し、新しいソリューションをどのように実装するか、会社内でどのように優先順位をつけるかを話す際、通常は「上司に話すときにどうやってコストを削減できるか」を考えています。これらのQRコードを残しておきます。プレゼンテーションの最後にダウンロードして、QRコードを使って読んでみてください。また、イベント期間中に多くのネットワークスペシャリストが発表を行っています。彼らは、このようなブレイクアウトセッションだけでなく、理論をもう少し掘り下げるものや、非常にクールなハンズオンワークショップの作成に多くの労力を費やしています。

ぜひチェックしてみてください。すべて素晴らしいです。私自身もワークショップを試してみました。Amazon VPC LatticeやCloud WANなど、従来のネットワーキングの境界を押し広げている新しいネットワーキングサービスを体験したい場合や、消費モデルを完全に変えたい場合におすすめです。ネットワークエンジニアとして、ネットワークとどのように対話するでしょうか？これらのハンズオンワークショップで実際に手を動かしてみることを強くお勧めします。いつものように、この1時間を私たちと過ごしていただき、ありがとうございます。AWSでは、フィードバックを大切にしています。顧客として、新しいサービスや機能を構築する際のロードマップの90%は顧客からのフィードバックから来ています。私が顧客と話す時間、サービスチームと話す時間、そしてあなたがたのフィードバックを彼らに追加する時間です。同様に、新しいコンテンツを作成し、次のイベントのセッションを計画する際にも行っています。数分かかりますが、フィードバックを残していただければ、どのようなコンテンツを見たいかを理解するのに大変役立ちます。そして、皆さんのためにそれを構築します。ありがとうございました。

---

※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。