ULA、AWSでロケット開発を変革

Pulisher : Cloud Technology Center イ・ヨンジン
Description : 米国を代表する宇宙打ち上げ連合であるULAがAWSを活用する方法について紹介したセッション。

はじめに

ULA (United Launch Alliance)はアメリカを代表する宇宙打ち上げ連合会であり、Aerospace & Satellite分野では必ず話題になる代表的な宇宙産業企業です。このような宇宙産業の代表企業がどのようにAWSを活用しているのか、そのuse caseを確認したいと思い、本セッションを申し込みました。

セッションを通じて、韓国の宇宙産業企業が今後どのような方法でAWSを導入することができ、その過程をどのようにサポートするかを考えてみたいと思いました。

セッションの概要紹介

ミッションクリティカルな分野なので、各分野で最高のSeniorエンジニアが発表者として登場しました。

ULAにとって、AWSサービスは、発射体自体を作ることに直接関わるだけでなく、間接的に関連する全てのサービスやアプリケーションにも使われています。 特に、様々な分野においてAWSクラウド化により、何よりも時間の短縮を実現し、クラウドへの移行後、発射体の数自体が2倍になる結果をもたらしました。

では、どんなサービス、どんなArchitecture、どんなApplicationに関わったのか見てみましょう。

ULAは軍事的な目的だけでなく、民間と公共のためのサービスを目指しています。

また、宇宙探査もその大きな柱の一つです。

宇宙衛星を通じて、世界をつなぎ、データを高速化することにも取り組んでいました。

これまでに158回の人工衛星の打ち上げが成功しています。

上記の成果は、2つの場所で3つの発射パッドを活用して行われました。

発射体の製造・組立も、巨大な工場で直接行っていました。

従来の発射体はATLAS VとDELTA IVでしたが、最近では大容量で一部リサイクルが可能なVULCAN CENTAURを活用しています。

当然ながら、ULAはVULCAN CENTAURを最高の発射体と位置付けています。既存の発射体の経験をもとに、エンジンから外観まで全てアップグレードされたバージョンだそうです。ちなみにProject Kuiperのために現在初期2機が上がった状態ですが、このULAのATLAS V 500が使用されました。

打ち上げ当日は、誰もが期待と緊張感を持って見守るそうです。

需要が爆発的に増加し、年10～12回の打ち上げだったのが、現在は年25回以上が求められているそうです。

結局、今までやってきたことの2倍以上の成果を出す必要があり、ULAは宇宙発射体だけでなく大型船も扱っています。

リアルタイムのデータ取り込みと処理、そしてそれを活用した意思決定などを行う必要があるため、すでに行われているオンプレミスのように、クラウドで最適化を実現することが当面の目標だそうです。

ULAで使用されるソフトウェアは、大きく2つに分けられます。

一つは、ロケットの「頭脳」となる飛行ソフトウェアで、安全性が非常に重要で、非常に忠実度の高いテスト環境でテストされるプログラムです。もう一つは、ミッション統合アプリケーションとして、数万の発射体パラメータ、数千のデータシート、数百の証拠写真で構成されます。

本格的にAWSを活用するために、積極的にAWSの専門家と幅広い分野で協力しました。

既存のon-premiseベースのサービス/サーバーに対するmigration、そして近代化した後、再び改善するライフサイクルを行いました。

Cloud移行にあたり、セキュリティルールや継続的な拡張、高い要求に対応できる基準を先に決めてスタートしました。

この基礎は、最終的に、Landing Zone Acceleratorで構築することになりました。

LZAはユーザー管理とそれに基づくSSOを設定しました。

また、複数のAWSアカウントを統合するOrganizationsを活用し、LZAに基づいてS3にログを集中的に管理し、EC2を利用したSplunkが結果を出すと、再びon-premiseの既存のdatabaseとdashboardでも活用できるように接続しました。

AWS ConfigとLambdaを活用して、セキュリティコンプライアンスの確認と違反に対する即時対応を実現しました。宇宙産業を業とする企業は、データとそのガバナンスとコンプライアンスの要求が非常に厳しく、自動化された管理体制が必須と言えます。

既存のOn-premiseとの連携において、Transit Gatewayを中心に高速かつover VPNを駆使してセキュリティを強化した形で構築されました。AWS内部でもPrivate Link, Route 53 Resolver, Private Hosted Zone, Resource Access Managerなど、セキュリティ基準のサービスで構成されました。

Landing Zone Acceleratorを利用して、統合管理し、セキュリティcomplianceを遵守するインフラを構築できたそうです。AWSが提案するBest Practiceをうまく活用しましたね。

インフラ高度化のために、カテゴリー別の分類と400以上のアプリケーションの統合管理により、本事業に必須のミッションクリティカルな運営と活用が可能になったそうです。

Core Architectureは基本3 tier architectureであり、一般的なものと異なる部分としては、ULA内部でのみ使用する必要があるため、内部でのみ利用可能なURLを管理するRoute 53の設定を利用しました。

ローカルストレージとの連動のためにFile Gateway / DataSyncなどを活用しました。宇宙産業であっても、AWSが提案するnativeサービスを十分に活用しました。

AWSが基本的に提案するAutoscaling、Load Balancing、File Gateway、Auroraなどがうまく活用されました。

AWS Coreサービスだけでなく、開発者の拡張のために、そして柔軟なInfra.拡張のためにMSAもやはり活用されました。

ContainerサービスのためのECSとdocker systemが共有するネットワークストレージとしてNFSを活用しました。代わりに、ECRを使うのではなく、on-premiseのrepositoryと連動するようにしました。

Container開発環境のためのcomponentsで、ミッションクリティカルではない一般的な産業群でも活用できるように構成されています。違う点といえば、network isolationくらいだと思います。

結局、これまで議論されたことをすべてまとめて、AWSでの構築・運用が可能になったそうです。

現在、Coreシステムへの移行、高度化、on-premise連動の後、次の旅路としてHPC、Dataベースの意思決定ツール、そしてAI/MLの導入と言われています。

セッションを終えて

ULAといえば、アメリカの宇宙産業の牽引役として活躍している組織です。このような伝統的な組織がAWSを非常に早くから活用しており、すでに成熟段階に入っていることが分かりました。 このような過程の中でビジネスが最適化され、今後は利用可能な能力を2倍に拡充するということで、AWS Cloudが与える効果は実にあらゆる分野に渡って多くの影響を与えていることを直接感じることができました。

また、私たちがやっている一般的なnative AWS / AWS Coreのサービスは、どこにでも通用することを再検証するセッションでした。

現在、ULAも、これに限らず、AI/MLとHPCを積極的に活用して、予測、データ補完、組織の意思決定に関与できるデータの活用も検討、実行していることが分かりました。

やはり、韓国の宇宙産業の現状と比較するのは惜しいですが、このような内容も国内に多く知られ、Case Studyとして活用され、韓国の宇宙産業も加速することができれば、これ以上望むことはありません。