re:Invent 2025: RivianによるAWS Outpostsを活用した製造現場のミッションクリティカルアプリケーション刷新事…
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Rivian: Modernize mission-critical manufacturing applications with AWS (HMC217)
この動画では、AWS Senior Solutions ArchitectのMatt ReedがAWS Outpostsについて解説し、RivianのSenior Staff AWS Solutions ArchitectであるVinny Machacekが製造現場での実装事例を共有しています。Outpostsは低レイテンシー要件やエッジでのAI/ML推論に対応するフルマネージドサービスで、Generation 2ではネットワーキングアーキテクチャが再設計され、コスト効率と展開の柔軟性が向上しました。Rivianは当初、レガシーなVMスタックからの移行で課題に直面しましたが、ネットワークレジリエンスを考慮した設計とDirect Connect、EKSの活用により、統合されたプラットフォームを実現しました。重要な教訓として、レジリエンスを考慮した設計、キャパシティ管理の重要性、RAM共有VPCの活用、そして社内顧客との信頼構築の難しさが強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
製造業の課題とAWS Outpostsによる解決策
素晴らしい。皆さん、私の声は聞こえていますか？おそらく皆さんがここにいらっしゃるのは、製造施設をお持ちで効率改善をお探しだからでしょう。あるいは、ビジネスにとって重要なラインプロセスを支えるITおよびOTインフラストラクチャを所有されているからかもしれません。もしかしたら、プロセスを改善してコストを削減するためにテクノロジーを活用するようプレッシャーを受けているという理由でここにいらっしゃるのかもしれません。これらの理由のいずれかに当てはまるなら、あなたは正しい場所にいます。
私はMatt Reedです。AWSのSenior Solutions Architectを務めています。今日はAWS Outpostsと、オンプレミスのエッジでクラウドを活用する能力についてお話しします。 まず、私たち全員が置かれている状況と環境について少し背景をお話しします。誰もが可能な限りテクノロジーを活用して既存のプロセスを改善しようとしています。Research and Marketsの調査によると、今後5年間でこれらの分野だけでも支出が4倍に増加すると言われています。おそらく皆さんも何らかの運用効率や、設計およびエンジニアリングサイクルの市場投入までの時間短縮をお考えでしょう。この分野で取り組んでいるのはあなただけではありません。
特に製造業に焦点を当てると、これらがお客様から聞くトレンドです。 大きく3つのカテゴリーに分かれます。低レイテンシー要件をお探しの方々、ローカルデータ処理のためのエッジでのコンピューティング。リアルタイム分析を活用したいとお考えかもしれません。ローカルのラインプロセスを改善するためのAIとML推論があるかもしれませんし、レジリエンスの態勢を改善したいとお考えかもしれません。ここにいらっしゃる方で、これらの分野のいずれかを評価されている方はいますか？エッジでのコンピューティングやAIとML推論など、何かありますか？
では、これらの分野に取り組む上で何が障害になっているのでしょうか？どのような課題が見えていますか？重要なプロセス、ロボティクス、または安全上の懸念があり、自信を持つためには一桁ミリ秒のレイテンシーが必要かもしれません。接続性の問題で、適切なレジリエンス態勢やフェイルオーバーが設定されていないため、データをクラウドに置くことにまだ自信が持てないかもしれません。多くの調整と依存関係、そしてリードタイムを必要とするレガシーインフラストラクチャがあり、それは単独で引き受けるには少し負担が大きすぎるかもしれません。
今日、これらの課題に対処し始めるのに役立つソリューションがあります。それがAWS Outpostsファミリーです。AWS Outpostsは フルマネージドサービスで、現在AWSクラウドで使用しているのと同じインフラストラクチャとサービスを、事実上あらゆるオンプレミスのエッジロケーションに提供し、非常に一貫性のあるハイブリッド体験を実現します。AWS Outpostsのフォームファクターは、お客様自身のデータセンターやコロケーション施設向けに設計された42Uフルラックと、1Uおよび2Uの小型サーバーがあり、これらは地域のオフィス、クリニック、レストラン、または小規模な製造施設向けです。
AWS Outpostsは皆さんに何ができるのでしょうか？ 先ほど述べたように、皆さんが最新のクラウドネイティブアプリケーションをWeb上で構築・デプロイする際に使用しているのと同じコマンドラインインターフェース、同じSDKを使用できます。それらをオンプレミスのローカル環境でも実行できるんです。APIの管理計画を独自に決定し、ガバナンスポリシー、セキュリティコントロール、自動化を設定できます。これらすべてがAWSのフルマネージドサービスという付加価値とともに利用可能です。つまり、パッチを当てる必要もなく、アップデートする必要もありません。私たちが訪問してそれらの面倒を見させていただきます。
最近、AWSはGeneration 2 Outpost rackをリリースしました。 そしていくつかの重要な機能が追加されています。実際、ネットワーキングのアーキテクチャが完全に再設計されており、ネットワーキングが分離されるようになりました。コンピュートドロップレット、つまり以前は一対一の要件があったのですが、Generation 2 Outpostでは、すべてのコンピュートを処理する単一のネットワーキングスタックになっているため、コスト効率と展開の柔軟性が本当に向上します。ラックを成長を見越して一定の充填率で仕様を決め、その後追加リクエストを行うことができます。AWSが訪問し、それらを追加しますので、資本支出を推測する必要がなくなります。これがフルマネージドサービスの利点の一つです。
また、ネットワーキングの回復性も大幅に向上しています。デバイスのフェイルオーバーを本質的に処理できるようになり、これも回復性の向上につながっています。そして、Outpostとの接続がこれまで以上に簡単になりました。ドメインルーティンググループのようなことができるようになり、エッジで実行されているコンテナ用のローカルダイレクトVPCのルーティングを選択できます。これは通常、パフォーマンスにとって重要です。さらに、一部のAWSサービスにはCOIPセットアップを使用して独自のIPブロックを使用することもできます。RDSでは、フォールバック用のマルチアベイラビリティゾーンを使用したい場合、COIPルーティングが必要になります。これらが新しいGeneration Outpostsとの接続を容易にする新機能の一部です。
Outpostsは多くの異なる場所で利用可能です。 緑色で示されているのが第一世代のOutpostsがまだ利用可能な場所で、オレンジ色は第一世代または第二世代の両方が利用できる場所です。そして常に追加されています。最後に、AWSがこの分野でリードしていることを強調したいと思います。 2024年のGartner Magic Quadrant調査によると、AWSはこれら4つの分野すべてで第1位にランクされています：ハイブリッドインフラストラクチャ管理、エッジコンピューティング、アシュアードワークロード、そしてAI/MLです。それでは、Vinnyにバトンタッチしますので、RivianのOutpostジャーニーについてお話しいただきます。
Rivianの挑戦：レガシーシステムからの脱却と失敗からの学び
ありがとうございます、Matt。皆さんこんにちは、私の名前はVinny Machacekです。 私はRivianでSenior Staff AWS Solutions Architectとして働いています。私たちのチームは、すべてのビジネスユニットにわたるAWSエステート全体の管理を担当しています。本日は、RivianがどのようにOutpostを使用しているか、Outpostの実装で直面した課題、そして製造ワークロードを本当にレガシーなスタックから、コスト効率と運用効率を実現するはるかに最新のものへ移行しようとする中で得た教訓についてお話しします。
それでは私たちについてですが、もしまだお聞きになったことがなければ、私たちは電気自動車を製造しています。トラック、SUV、そして商用バンなどです。私たちの車両は非常に高度に接続されており、素晴らしいソフトウェアスタックを持っています。実際、もしあなたがブラックフライデーに何か注文されたなら、私たちの車両の1台が、Amazonの配送車両として、あなたのご自宅へ荷物を配達するのに関わっていたかもしれません。具体的には、会社として私たちにとって重要なことの1つに、テクノロジーリーダーシップがあります。繰り返しになりますが、ソフトウェアは私たちの車両のすべてです。本当にユニークな体験なんです。もしまだ私たちの車両を試されたことがなければ、ぜひ運転席に座ってみることを強くお勧めします。本当に素晴らしいですよ。2列目の方が笑顔になっているのが見えますね。
この話をする中で、明らかにテクノロジーは需要創出を促進し、より多くの人々を私たちの製品に興味を持たせることになります。そしてもちろん、それはすべて役立ちます。優れたテクノロジーを使うことで、より良い効率性を得て、コストを下げ、より良い製品を提供することができます。そしてもちろん、もし私たちのCEOであるRJがこのトピックについて話すのを聞いたことがあれば、私たちは本当に持続可能な方法で体験を可能にしようとしているんです。そしてそれは、Rivianにおける私たちの役割をどう見ているかという点で、本当にユニークなものなんです。
それでは、私たちについて少しご理解いただいたところで、私たちの課題についてお話しします。ご存知かもしれませんが、自動化された製造は非常に長い間存在しており、多くのテクノロジーがあり、その多くはレガシーです。ですから、私たちはオンプレミスのデータセンターに存在していた、多くのレガシーなVMホスト型スタックと確実に取り組まなければなりませんでした。また、私たちはコンテナが本当に、本当に大好きなんです。Rivianには素晴らしいKubernetesプラットフォームチームがいます。しかし、製造ワークロードが使用していたレガシーなVMスタックのために、Kubernetesワークロードのデプロイ、管理、運用、スケーリングの方法について社内に持っていた専門知識を、実際には活用することができなかったんです。
もちろん、スキルのサイロ化もありました。2つの異なるチームが2つの異なるスキルを学ばなければならず、オンコールローテーションや何か問題が起きたときにお互いを助け合うことができませんでした。そして、もちろん、レガシーなVMベースのワークロードで可用性を維持することは非常に困難でした。パッチを適用しなければなりませんが、どうやってパッチを調整するのか？サーバーをオフにしなければなりません。そのモデルではダウンタイムを取らなければなりません。ですから、これは想像できると思いますが、ビジネスにおいて運用効率を得ようとしていた私たちにとって、本当に非常に困難なことでした。
どのような種類のワークロードを実行しているのか？私たちは製造実行システムを実行しています。それは私たちのオーケストレーションエンジンであり、メッセージングエンジンであり、工場でのすべての活動を調整するのに役立っています。また、産業オートメーションも行っています。溶接機や、車を作る、さまざまな部品を作ってそれらを組み立てる、あらゆる種類の本当にクールなロボットツールがあります。そのすべてが産業オートメーションツールを使って自動化されなければなりません。もちろん、私たちは非常にテクノロジー重視です。AI、機械学習、コンピュータービジョンを使っています。何でもいいんです、それらを顧客成果を促進するためにプロセスに組み込もうとしているんです。
そして、Rivianの多くの優秀な人たちが「これは私たちにとってうまくいっていない。何か違うことを試してみよう」と言いました。それで私たちはOutpostsを試してみることにしました。そして私たちがやったことは、VMをスナップショットして、Outpostsに移行し、いくつかのRDSインスタンスをデプロイして、プロジェクトは成功だと言いました。しかし、私たちは大きな間違いを犯していました。
私たちが直面した課題には、ネットワークの回復性がありました。Outpostsサービスについて一つ文句を言わせてもらうなら、私はこの名前が本当に嫌いです。この名前は誤解を招きます。人々はOutpostsという名前を聞いて頭の中で想像するのは「私は辺境にいる。どこかでカンガルーと一緒にいる」といった感じです。実際には、Outpostsはリージョンへのネットワーク接続が本当に必要で、データセンターのOutpostsから期待するすべての素晴らしいサービスやオーケストレーション、すべての価値を提供するためにそれが必要なのです。Outpostsを使用する際には、ネットワークの回復性を考慮した設計をしなければなりません。明らかに、アプリケーションのリカバリー戦略も似たようなものです。新しいハードウェア、新しいプラットフォームでの障害モードを知っておくべきですが、私たちはそれをあまりうまくやれていませんでした。
そして、もちろん、標準化の欠如がありました。先ほど述べたように、私たちはコンテナを使いたかった。もっと現代的なスタックを使いたかったのですが、問題を別の場所に移しただけでした。そして最終的な結果として、社内での信頼を失い、私たちがやっていることを再評価しなければなりませんでした。
そして、優秀な人たちが集まって、「自分たちでやってみよう」と言いました。そして私たちはMCP、Manufacturing Container Platformを構築しました。これは様々なベンダーツールの組み合わせでした。オンプレミスシステムのためにITハードウェアを購入したことがある方ならご存知だと思いますが、ストレージを手に入れるために一つの会社に行き、ネットワーク機器を手に入れるためにネットワークベンダーに行き、KubernetesのPlatform as a Serviceや仮想化技術を手に入れるためにハイパーバイザーベンダーに行き、それらすべてを連携させなければなりません。それらは本質的に一つの包括的でまとまった考えとして設計されているわけではなく、一緒に動作する必要がある別々のシステムであり、それは結構大変なことです。
私たちが目にした課題には、チケット地獄がありました。それぞれの異なるコンポーネントは異なるベンダーが所有し、異なるチームが所有していて、それらすべてが互いに通信しなければなりません。だから、インシデントが発生したとき、このインシデントの原因となっているものの根本原因を突き止めるために誰に連絡すればいいのでしょうか?どうやって修復するのでしょうか?プラットフォームから期待する価値を提供するために、ベンダーをどうやって連携させるのでしょうか?明らかに、キャパシティプランニングも問題でした。私たちはまだラッキングやスタッキング、購入や調達、発注書など、顧客に何の価値も付加しないことに縛られていて、事前に計画を立てなければなりません。ベンダーから適切な機器をデータセンターに導入するまでに、構想から納品まで6ヶ月から1年かかることもあります。これは、Normalファシリティで私たちのR2プラットフォーム、R2ラインを構築しようとしている中で、スケーラブルではありません。
そしてもちろん、またしても標準化がありません。Kubernetesプラットフォームなんです。もしEKSを使ったことがあって、そのEKSワークロードをEKSではないKubernetesプラットフォームに移行しようとしたことがあれば、違いがあることがわかるでしょう。例えばサービスアカウント用のIAMロールといったものが存在しないんです。期待していた便利な機能の一部が、その環境には存在しないわけです。その結果、いわば千の紙切れによる死のような状態になります。十分な違いがあって、クラウドからオンプレミスにワークロードを単純に移植できないほど異なっているんです。つまり、今度はオンプレミスで開発をしなければならなくなります。容量もスペースも電力も冷却も限られていて、クラウドの利点を活用して
それをオンプレミス環境に移すだけ、というわけにはいかず、なんと、また再びこのサイロに閉じ込められてしまうわけです。
Outposts第2世代への全面移行と成功への教訓
そこで私たちの将来的なソリューションですが、散々悩んだ末に決定しました。私たちは白紙に戻りました。優秀な人材を全員集めて、どうすればもっとうまくできるか、最初の2回の試みで何を間違えたのか、と問いかけたんです。私たちはレジリエンスを考慮した設計をしていなかったことに気づきました。実際、Outpostsをビジネスにとって生産的な方法で設計していなかったんです。そこで私たちは、Normalの製造施設における製造ワークロードについて、Outposts第2世代に全面的に取り組むことを決定しました。
これは私たちがデプロイしたものの非常に簡略化された図です。いくつか重要なポイントがあります。以前は、Outpostにはインフラストラクチャのオーケストレーションを代行してもらうために、リージョンへのサービスリンク接続が必要なんですが、以前はそのために公衆インターネットを使用していました。つまり、正面玄関から公開エンドポイントに接続してリージョンまで行っていたわけです。これはあまりレジリエントではありません。途中に多くのインターネットの不安定さが入り込むため、結果としてDirect Connectを採用しました。Rivianのバックボーンがあり、それが主要なデータセンタープロバイダーに接続されていて、それによってAWSリージョンに冗長性があり信頼性が高く安全な方法で接続できるようになっています。
そしてもちろんEKSを使用しているので、機能の同等性が得られます。Kubernetesプラットフォームチームの深い専門知識から恩恵を受けることができます。彼らは実際に移行プロジェクトでアドバイスをしてくれています。では、私たちの旅を振り返ってみましょう。2020年半ばにOutposts第1世代のPOCを開始しました。誰かが、データセンターにOutpostが欲しいと言ったんです。注文して、ラックに入れて、積み上げて、そこに移行する、という感じですよね?
2021年後半、悪いことは三つ重なるものです。三つの異なる理由で三つの別々のネットワーク障害が三ヶ月の間に発生し、そのうちの一つは本当に痛ましいシャットダウンイベントにつながりました。私たちは多くの信頼を失いました。そのうちの一つは、信じられないことに、私たちの施設にクリスマスツリーが設置されたことが原因だったんです。彼らが光ファイバーに当ててしまったんですよ。本当に、作り話じゃないんです。そして2022年から2024年に移ります。私たちは戻って、自分たちでやってみようとしました。私たちは自分たちが得意なことと、あまり得意ではないことについて多くを学びました。
そして2024年後半、私たちは再評価を行いました。私たちは言いました、「よし、実際に比較検討をしよう。これらの異なるプラットフォームでの体験がどのようなものになるか見てみよう」と。そして私たちは結束しました。私たちは合意に達し、一つになりました。これは私たちのRivianの原則の一つ、コンパスバリューです。Normalの製造ワークロードに対してOutpostsに全力投球することにしました。成果とメリットですが、皆さんも理解されていると思いますが、統合、可搬性、低レイテンシー、認知的な簡素化、ですよね？私たち、会社全体が使用する一つのプラットフォームが欲しいんです。そのプラットフォームは現在、私たちの多くのワークロードにとってAWSです。ですから、これは以前持っていたものに比べて大きな改善なんです。
そして、最後の1分で学んだ教訓をまとめましょう。レジリエンスを考慮した設計をすること。Outpostsでもキャパシティ管理は依然として重要です。ある程度のリードタイムが必要なんです。正直なところ、従来のベンダーよりは短いですが、それでもより多くのキャパシティを得るためにはリードタイムが必要です。ですから、レポートダッシュボードを構築して、Outpostで消費しているキャパシティを確認できるようにし、何を注文する必要があるのか、ビジネスが許す限り、キャパシティニーズがどうなるかをできるだけ予測しようとすることです。
そして真ん中のポイント、RAM共有VPCです。Outpostsは有限のリソースセットであり、そのため有限の電力と冷却、そして最終的にはCIDRを利用します。私は強くお勧めします、800個のVPCを作成しないでください。一つのVPCを作成して共有してください。一つのデータセンター内にあるんです。これによってチームの運用オーバーヘッドが大幅に削減されます。そして最も重要なのは、信頼は得るのが難しく、失うのは簡単で、再構築するのは困難だということです。社内の顧客との信頼も獲得しなければなりません、そうでしょう？そしてそれが最も重要なことなんです。
ですから、ここに来てOutpostsでの私たちの経験についてお話しさせていただき、ありがとうございました。皆さんが素晴らしい一日を過ごされることを願っています。どうもありがとうございました。もし質問があれば、横の方でお会いできます。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion