Marvell とクラウド基盤を支える“静かな”シリコン

現代のクラウドデータセンターにおけるMarvellの役割

多くの人は「クラウド＝サーバー」だと考えがちですが、実際にはクラウドデータセンターはデータを高速に移動・保存・保護するための巨大なシステムです。データインフラ向けシリコンとは、そうしたデータ量の多い作業を処理してメインCPUの負担を減らすための専用チップ群のことです。

Marvellはこの「中間層」に注力しています：コンピュートとネットワーク／ストレージを接続し、共通のデータセンター処理を高速化し、負荷下でも予測可能に流れを保つチップです。

クラウドスタックの典型的な位置付け

ラックを上から下へ見たとき、Marvellのデバイスはしばしば次のような場所にあります：

• サーバーのネットワークエッジ上で、トラフィックの送受信を効率化する
• スイッチやネットワーク機器内で、パケットを適切に振り分ける
• ストレージ近傍で、SSD、ストレージネットワーク、サーバー間でデータを移動する
• 重要なインターコネクト上で、コンポーネント間の高速通信を可能にする

これらは一般的な「アプリ」や「サーバー」とは違い、何千台ものサーバーを一つの整合したサービスとして動作させるハードウェアの構成要素です。

エンドユーザーに見えない理由

インフラシリコンが正しく機能している時、ユーザーはそれに気づきません。ページの読み込みが速くなり、動画のバッファが減り、バックアップが時間通りに終わる──しかしユーザーはネットワークオフロードエンジンやストレージコントローラ、スイッチングファブリックがそれを実現していることを見ません。これらのチップは静かにレイテンシを下げ、CPUサイクルを解放し、性能をより一貫させます。

簡単な分類：ネットワーキング、ストレージ、アクセラレーション

Marvellの役割は大きく三つに分けると分かりやすいです：

• ネットワーキング： パケットを迅速かつ予測可能に移動する
• ストレージ： 大規模にデータを安全に読み書きする
• アクセラレーション： インフラの反復的処理向けの専用演算

これが、表面上はシンプルに見えるクラウドサービスを支える“静かな”シリコンです。

なぜクラウドは専用インフラチップを必要とするのか

クラウドアプリは「ソフトウェア定義」であるように見えますが、実際の作業はラックに詰まったサーバー、スイッチ、ストレージの物理層で行われます。需要が増えるにつれ、すべてを汎用CPUに頼っていてはコストや効率の面で限界に達します。

トラフィックはCPUの余裕より速く増えている

AIトレーニングや推論はデータセンター内で大量のデータを移動します。動画配信、バックアップ、アナリティクス、SaaSは常時負荷を加えます。計算資源があっても、ボトルネックはしばしばデータの移動、フィルタ、暗号化、保存を十分な速度で行うことに移ります。

データセンター内部は東西トラフィックが支配する

多くのクラウドトラフィックはパブリックインターネットに出ません。サービス間の呼び出しやデータベースの読み出し、キャッシュ更新、ストレージの複製、分散AIワークロードなどが「東西」に流れます。内部トラフィックは予測可能なレイテンシと高スループットが必要であり、ネットワーキングやストレージのハードウェアによりデータパス近傍での処理を求めます。

効率性が第一級の要件になった

電力とスペースは無限ではありません。パケット処理、暗号化、圧縮、ストレージチェックサムなどの作業を専用シリコンにオフロードできれば、CPUはオーバーヘッドに使われる時間が減り、次の点が改善します：

• ワット当たりの性能（同じ電力でより多くの仕事）
• サーバ密度（ラック当たりの有効な計算量が増える）
• 運用コスト（同じスループットでのエネルギー・冷却コストの低減）

「一つの大きなCPU」から専用ヘルパーへ

汎用コアを増やすのではなく、Smart NIC/DPU、スイッチシリコン、ストレージコントローラ、アクセラレータなどの目的特化型チップを使って反復的で大量のインフラ作業を処理する傾向が強まっています。結果として、ワークロードがよりデータ集約になってもクラウドは速く、安く運用できます。

ネットワーキングオフロード：Smart NICとDPUの説明

クラウドサーバーは意外と多くの時間を「インフラ作業」に費やしています。各パケットは移動され、検査され、ログされ、時には暗号化されます—これらはしばしばメインCPUが担当します。ネットワークオフロードはその作業を専用ハードウェアに移し、Smart NICやDPUが現代の多くのデータセンターで重要な役割を果たします（Marvellのシリコンを使うシステムを含む）。

Smart NICとDPU（平易な定義）

Smart NIC は送受信以上のことをするネットワークインターフェースカードです。通常のEthernetポートに加え、カード上でネットワーク機能を動かすための追加処理（しばしばArmコアやプログラム可能ロジック）を備えます。

DPU（Data Processing Unit） は一歩進み、サーバー内部の専用「インフラコンピュータ」として設計されています。DPUは通常、高性能ネットワーキング、複数コア、ハードウェアアクセラレータ（暗号、パケット処理）、強力な分離機能を組み合わせ、ホストCPUに頼らずデータ移動とセキュリティを管理できます。

実用的なイメージ：

• Smart NIC: カードに頭脳が付いたNIC。
• DPU: ネットワーキングに加えインフラ処理を独立して行えるシステム。

CPUからオフロードされる作業

オフロード対象は反復的で大量の仕事で、アプリケーションのCPU時間を奪うものです。一般的な例：

• ネットワーキングデータパス： 仮想スイッチ、ルーティングルール、カプセル化/復号化（オーバーレイ等）、トラフィック整形
• セキュリティ： TLS/IPsec暗号化、ファイアウォールポリシー適用、マイクロセグメンテーション、セキュアブートとアテステーション
• ストレージトラフィック加速： ストレージパケットの効率的な誘導、設計によってはネットワーク上のストレージフロー支援
• テレメトリ： フローログ、パケットサンプリング、カウンタ、レイテンシ測定—ワイヤレートで取得

なぜ重要か：予測可能な性能と低いCPU負荷

CPUがネットワーキングを“見張る”必要があると、トラフィックの急増やノイジーネイバー、セキュリティ作業のバーストでアプリ性能が変動します。オフロードにより：

• CPUコアをアプリケーションに解放 できる
• レイテンシが安定化 する（パケット処理が専用経路で行われるため）
• ホスト密度が向上 する（インフラに使うCPUリソースが少なければ有用な作業が増える）
• 分離が改善 され、インフラ制御がテナントワークロードから独立して動ける

DPUの物理的な位置（そして接続先）

物理的にはDPUは通常PCIeのアドインカードまたはOCP NICモジュールとして実装されます。接続先は：

• ラック上部のネットワーク（ToR） へEthernetポート（しばしば高速リンク）で接続
• ホストサーバー へはPCIe経由で接続し、ネットワークとCPU/メモリのゲートウェイとして振る舞います

概念的には、DPUはネットワークとサーバーの間の「交通整理役」となり、ポリシーや暗号、スイッチングを処理してホストOSとCPUはアプリ実行に専念できます。

クラウドネットワーキングの内部：イーサネットスイッチングとパケット処理

アプリを開いたりクラウドへデータを移したりするとき、リクエストは単に「サーバーへ行く」のではなく、何千ものサーバーを一つの巨大な機械のようにつなぐイーサネットスイッチのファブリックを通ります。

サーバー間のデータ移動：ToRとスパイン

多くのクラウドデータセンターは「リーフ-スパイン」設計を採用しています：

• Top-of-rack（ToR）/リーフスイッチ は各ラックにあり、そのラック内のサーバーに直接接続します。\n- スパインスイッチ はすべてのToRを相互接続し、どのサーバーからでも予測可能なホップ数で他のサーバーに到達できるようにします。

この設計は経路を短く一貫させ、スケール時のパフォーマンスに重要です。

低レイテンシと高スループットが重要な理由

2つの指標がユーザー体験とコストを決めます：

• レイテンシ（パケットにかかる時間）はAPIやデータベース、マイクロサービス、リアルタイム分析などのインタラクティブワークロードに影響します。\n- スループット（秒あたりのデータ量）はストレージ複製、バックアップ、ストリーミング、大規模なAIデータセットの移動に影響します。

運用者はリンクが混雑してもレイテンシを安定させつつ大量のトラフィックを流すことを目指します。

主要な機能：スイッチング、パケット処理、QoS

イーサネットスイッチチップは単に「パケットを転送する」以上のことをします。次を行う必要があります：

• 宛先検索（MAC、VLAN、しばしばルーティングやオーバーレイヘッダ）をラインレートで行う
• バッファとスケジューリングで輻輳の波及を防ぐ
• QoSを適用してレイテンシに敏感なフローが背景転送に埋もれないようにする
• テレメトリや輻輳制御をサポートし、運用者が性能を調整できるようにする

Marvellのようなベンダーは、これらのタスクを非常に高速かつ予測可能に行うシリコンを作ります。

「より高速」がもたらすもの

25/100Gから200/400/800Gへの移行は単なる数値競争ではありません。より高速なリンクは次を可能にします：

• ラックあたりのVM数を増やせる（ネットワークの過剰予約を減らせる）
• ストレージへのアクセスが速くなる（特に分散NVMe環境で）
• AIトレーニングのサイクルが短くなる（GPUへ安定してデータを供給できる）

結果としてデータセンターネットワークは単なる"配線"ではなく、上で動くすべてのワークロードの共有インフラのように振る舞います。

ストレージシリコン：コントローラ、NVMe、データ保護

クラウド性能を語るとき、多くの人はCPUやGPUを思い浮かべますが、実際にはフラッシュドライブとシステムの間にあるストレージシリコンが速度（と信頼性）を大きく左右します。この層は通常ストレージコントローラで、データの書込み・読み出し・検査・復旧の管理を行います。

ストレージコントローラの実際の仕事

ストレージコントローラは永続データの交通整理役です。受け取った書き込みを扱いやすいチャンクに分割し、ホットデータの読み出しを優先し、多数のアプリケーションが同じストレージプールにアクセスしてもレイテンシが安定するよう常に整合性チェックを行います。

また、論理ブロックから物理フラッシュへのマッピング、ウェアバランス、複数アプリの同時アクセス時のレイテンシ維持といった地味だが重要な帳尻合わせも担当します。

NVMe：なぜ普及したか

NVMe（Non-Volatile Memory Express）はフラッシュ向けに設計されたプロトコルで、オーバーヘッドを減らし並列のキューをサポートします。クラウドではNVMeはピークスループットだけでなく、負荷下での一貫した低レイテンシを実現する点で特に価値があります。

組み込み機能：暗号化、圧縮、RAID類似保護

現代のコントローラはCPUサイクルを消費する代わりにハードウェアで次を提供します：

• 暗号化/復号（データの保護を性能ペナルティ少なく実現）
• 圧縮（より多くを保存し、より少ない帯域で移動）
• パリティ/消失符号化の支援（故障耐性と高速な再構築）

ストレージ性能がアプリ動作を変える理由

ストレージは孤立したサブシステムではなく、アプリケーションの振る舞いを形作ります：

• データベース はトランザクションやログのために速く一貫した書き込みを必要とする
• アナリティクスパイプライン は大規模データの読み出しでキューが詰まると停滞する
• バックアップ/リストア はスループットが限られると事業継続性の問題になる

要するに、ストレージシリコンが生のフラッシュを信頼できる高スループットインフラに変えます。

接続の基盤：PCIeとCXLを平易に説明

クラウドプロバイダがサーバーをアップグレードする際、CPUだけを交換するわけではありません。ネットワークカード、ストレージ、アクセラレータとCPUが再設計なしに通信できる「結合組織」が必要です。だからこそPCIeやCXLのような規格が重要で、部品の相互運用性を保ち、アップグレードのリスクを下げ、データセンターの拡張を予測可能にします。

PCIe：サーバ内部の高速ハイウェイ

PCIe（Peripheral Component Interconnect Express）は次のようなコンポーネント接続に使われる主要な内部リンクです：

• NIC（ネットワークインターフェースカード）
• SSDやストレージコントローラ
• GPUやその他のアクセラレータ
• DPU/Smart NIC

助けになる比喩：PCIeは車線を増やすようなものです。新しい世代は1車線あたりの速度を上げ、x8やx16のような幅で総容量を増やします。クラウド運用者にとって、これが計算とそれを支えるデバイス間のデータ移動速度に直結します。

MarvellのインフラシリコンはしばしばこれらのPCIe接続の一端に位置しており、PCIeの能力が性能アップグレードの実行可能性を左右することがあります。

CXL：同じ道路でメモリ共有を効率化する

CXL（Compute Express Link）はPCIeの物理接続を利用しつつ、デバイスがメモリ類似リソースを低オーバーヘッドで共有するための仕組みを追加します。平たく言えば、CXLは外部リソース（メモリ拡張やプールされたメモリ）をローカルの延長のように扱いやすくします。

クラウド設計への実務的効果

速くなるだけでなく、PCIeとCXLは次を可能にします：

• より柔軟なシステム設計：計算、ネットワーク、ストレージのブロックを混在させられる
• より良い利用率：片方に偏ったリソース（例：あるサーバに余るメモリ）を減らせる
• スムーズなアップグレード：新しいカードやコントローラが既存世代に落とし込みやすくなる

接続規格は見出しを飾りませんが、クラウドがより良いネットワーキングやストレージ、アクセラレーションを採用する速度を強く左右します。

カスタムアクセラレーション：クラウドワークロード向けの目的別演算

クラウドインフラにおける「カスタムアクセラレーション」は必ずしも巨大な汎用GPUを意味しません。多くは一つの反復タスクを高速化する小さな専用計算ブロックを追加することを指し、CPUはアプリケーションに専念できます。

「カスタム」が意味するもの

クラウドのワークロードは多様です：ストレージ重視のデータベースノードと動画配信エッジボックス、ファイアウォールアプライアンスではボトルネックが異なります。目的特化シリコンはそうしたボトルネックを直接狙い、機能をハードに移すことでより速く、より一貫して、CPU負荷を小さくします。

実際に現れる一般的なアクセラレーション例

データセンターで繰り返し見られるカテゴリ：

• パケット処理補助：ヘッダ解析、フローの誘導、トラフィック整形、ポリシー適用をラインレートで行う
• セキュリティ加速：暗号（IPsec/TLS）、鍵処理、インライン検査
• ストレージ加速：消失符号化、圧縮、重複排除支援、パリティ/チェックサム計算
• ビデオ/メディア：トランスコーディングやパッケージング
• AI推論補助：フルスケールの学習加速器ではなく、埋め込み検索やモデルサービスの前後処理などの小規模エンジン

企業がワークロードに合わせてチップを設計する方法

大規模なクラウドチームは通常、プロファイリングから始めます：どこでリクエストが詰まり、どのタスクが毎秒何百万回も発生しているかを特定します。次に、プログラム可能エンジン（柔軟）か固定機能ブロック（最高効率）かを選びます。Marvellのようなベンダーはネットワーキングやセキュリティ、ストレージインタフェースというビルディングブロックを提供し、「カスタム」部分はプラットフォーム固有のホットパスに集中できます。

トレードオフ：ワット当たり性能 vs 柔軟性

固定機能はワット当たりの性能と決定性で有利ですが、ワークロードが変わると使い回しが難しい。プログラム可能な選択肢は進化しやすいが消費電力が高く、性能の一部を犠牲にする可能性があります。最良の設計は両者を混在させ、制御面は柔軟に、ホットパスはハードで高速化します。

電力と効率：より少ないワットでより多くの仕事をする

電力はデータセンターの実際の天井であることが多く、買えるサーバー数よりむしろ供給・除熱可能な電力量が制約になります。施設が電力上限に達すると、成長はワット当たりの有用仕事を増やすことでしか実現できません。

なぜ「オフロード」が省エネにつながるのか

汎用CPUは柔軟ですが、パケット処理、暗号化、ストレージプロトコル処理、テレメトリといった反復的な作業には効率が悪いです。Smart NIC/DPU、スイッチ、ストレージコントローラのような目的設計シリコンは、これらのタスクを少ないサイクルと無駄の少ない方法で実行できます。

エネルギーの勝ちはしばしば間接的です：オフロードでCPU利用が下がれば、同じワークロードをより少ないコアや低いクロック、あるいは少ないサーバーで回せます。これによりメモリ負荷やPCIeトラフィックも下がり、さらなる電力削減が期待できます。

冷却とスペースもチップ選定に関わる

消費ワットはすべて熱になります。より多くの熱はファンの回転増加、冷却流量の増加、ラックレベルの設計制約を意味します。高密度ラックは魅力的ですが、均一に冷却できないと意味がありません。したがって、チップは純粋なスループットだけでなく、高負荷時でも効率を維持するかどうかが重要です。

効率主張を評価する方法

「ワット当たり性能が良い」という主張は比較が難しいことが多いです。見るべき点：

• 計測コンテキスト：スループット、レイテンシ目標、パケットサイズ、有効化機能（暗号のオン/オフ等）
• システム境界：チップ単体の消費電力かカード全体か、サーバ全体への影響か
• 負荷曲線の挙動：20–40%の利用率での効率がピークより重要な場合がある
• 同条件比較：同じワークロード、同世代のCPU、類似NIC/スイッチ構成での比較

もっとも信頼できる主張は、ワットと特定の再現可能なワークロードを紐付け、サーバやラックレベルで何が変わったかを示すものです。

インフラシリコンに組み込まれたセキュリティと信頼性機能

クラウドプロバイダは多数の顧客で物理マシンを共有するため、セキュリティは「後付け」では済みません。多くはチップレベルで強制されます—Smart NIC/DPU、クラウドネットワーキングチップ、イーサネットスイッチングシリコン、ストレージコントローラの中で、ハードウェアオフロードによりフルラインレートでの保護が可能になります。

ハードウェアルートオブトラストとセキュアブート

多くのインフラシリコンはハードウェアルートオブトラストを備えています：不変のロジックと鍵のセットで、ファームウェアを起動前に検証します。セキュアブートではチップがファームウェアの暗号的署名をチェックし、改変されたコードや未知のコードの実行を拒否します。

これは重要です。DPUやストレージコントローラがホストとネットワークの「間」に位置する場合、それらが侵害されると持続的な侵入を許す恐れがあります。セキュアブートはそのリスクを下げます。

インライン暗号化（転送中および保存時）

暗号化はしばしばシリコン内で加速され、CPU時間を奪いません：

• 転送中のデータ：DPUやSmart NICはIPsec/TLSのような処理や鍵管理をオフロードでき、高スループットを保ちながら暗号化を実行します。\n- 保存時のデータ：ストレージシリコンは書き込み時にインラインで暗号化し、読み出し時に復号します。NVMe経路に統合してI/OごとにホストCPUを重くしません。

インラインであるため、セキュリティは必ずしもストレージネットワーキングの性能低下を意味しません。

共有インフラにおけるテナント隔離

マルチテナントクラウドでは厳格な分離が必要です。インフラチップはハードウェアキュー、メモリ保護、仮想機能、ポリシー適用を通じて隔離を助けます。これにより一方のテナントのトラフィックやストレージ要求が他方を覗き見たり干渉したりするリスクを下げられます。DPUが仮想ネットワーキングを扱う場合やPCIeデバイスを共有する場合は特に重要です。

問題を早く表面化するための観測機能

信頼性とは単に「故障がない」ことではなく、検出と回復が速いことです。多くのデータインフラシリコンはテレメトリカウンタ、エラーレポート、パケットトレースのフック、ヘルスメトリクスを組み込み、クラウドチームが監視システムに取り込めるようにしています。ドロップやレイテンシスパイク、リンクエラー、再試行の嵐が起きたとき、これらの信号は問題がイーサネットスイッチングかDPUかストレージコントローラのどこにあるかを特定するのに役立ち、復旧時間を短縮します。

エンドツーエンドの例：クラウドリクエストがどう速くなるか

買い物アプリで「注文履歴を見る」をタップした状況を想像してください。その単一リクエストは複数のシステムを横断し、各段階で遅延の可能性があります。

ステップ：リクエスト→データベース→応答

1. リクエストがクラウドエッジとロードバランサに到達 し、健全なアプリサーバーにルーティングされる。\n
2. アプリケーションホストに到達。従来はホストCPUが暗号化、ファイアウォールルール、仮想ネットワーキング、キュー管理など多くの“配管”を処理していた。\n
3. アプリがデータベースを問い合わせる。このクエリはデータセンターネットワークを経てデータベースクラスタへ行き、ストレージからデータを取得する必要がある。\n
4. 応答が同じ経路で戻る。結果はパッケージ化され、暗号化され、あなたの端末に戻る。

レイテンシが潜り込む場所

• ネットワークホップとパケット処理：各ホップは微小な遅延を追加しますが、より大きなコストはパケットごとの処理（ルーティング決定、トンネルカプセル化、ACLチェック）です。\n- ストレージI/O：高速なNVMeでも、キューが詰まると遅延が発生します。メタデータ処理の非効率やホストCPUを消費するストレージパスも遅延要因です。\n- CPU競合：同じCPUコアがアプリとインフラ処理の両方を回すと、バースト時に「ノイジーネイバー」影響が出ることがあります。

オフロードとアクセラレーションがボトルネックをどう除去するか

Smart NIC/DPUや専用インフラシリコン（Marvellなどのソリューションを含む）は反復的作業を汎用CPUから移します：

• ネットワークオフロード はトンネリング、スイッチング/誘導、ポリシー適用をワイヤ寄りで処理する。
• 暗号化加速 はTLS/IPsecのコストを下げ、暗号がアプリサイクルを奪わないようにする。
• ストレージ加速 はNVMeのキュー処理、RAID/データ保護タスクを改善し、ホストのI/Oブックキーピング負荷を減らす。

実際に改善されること

• テールレイテンシの低下：トラフィックスパイク時の“稀だが痛い”遅いリクエストが減る。
• スループットの向上：サーバー当たりより多くのリクエストを処理できる（CPUがアプリロジックに集中するため）。
• 一貫性の向上：インフラ作業が分離・予測可能になることで性能が安定する。

クラウドチームがインフラシリコンを選ぶときの考え方

クラウド運用者は抽象的に「速い」からチップを選ぶのではなく、仕事が大きく反復的で専用化の投資に見合うかを基準に選びます。専用シリコンは数百万件単位の類似リクエストや予測可能なプロトコル、そして小さな効率改善がフリート全体で大きな節約になる状況で最も価値を発揮します。

ワークロードから始める（データシートではなく）

チームは通常、自分たちの最大ボトルネックを特定し、それを具体的な機能にマッピングします：ネットワーク経路のパケット処理とセキュリティ、I/O経路のストレージ変換とデータ保護、あるいは圧縮/暗号/AIプリミティブのようなアクセラレーションです。重要な問いは、その仕事をオフロードしてもソフトウェアモデルが壊れないかどうかです。プラットフォームが特定のLinux機能や仮想スイッチの動作、ストレージのセマンティクスに依存するなら、チップはそれらの仮定に合致しなければなりません。

ベンダーに問うべきこと（PoC前）

明確にすべき点：

• そのシリコンが今日チューニングされているワークロード（とそうでないもの）
• ロードマップの安定性：次世代のピン/ボード互換性、ファームウェアサポート期間、機能提供のペース
• 互換性：ドライバ、ハイパーバイザサポート、Kubernetes/CNI統合、観測性のフック
• 供給とライフサイクル：リードタイム、セカンドソース戦略、長期供給性

オプションを評価する方法

ベンチマークは重要ですが、本番に近いものでなければ意味がありません：実際のパケットミックス、実際のキュー深度、現実的なテナント隔離状態で。電力はピークではなく「ワット当たりの仕事量」として評価します。特にラックが電力制限されている場合はそうです。

統合の手間がしばしば決定打になります。紙面上で10%優れるチップが、運用・プロビジョニング・パッチ管理の面で扱いにくければ負けることがあります。

ロックイン回避

クラウドチームはリスクを下げるため、Ethernet、NVMe、PCIe/CXLなどの標準、よく文書化されたAPI、相互運用可能な管理ツールを好みます。Marvellなどのベンダーの機能を使う場合でも、上位のコントロールプレーンを移植可能に保ち、ハードウェアの進化がプラットフォーム全体の書き換えを強いることがないようにします。

ソフトウェア側でも同じ原則が当てはまります。サービスをこのインフラ上で動かす際はアーキテクチャを可搬にしておくと良いです。プラットフォーム例として、Koder.aiのようなツールは（Go + PostgreSQL）バックエンドやReactフロントエンドのプロトタイピングと反復をチャット駆動で加速しつつ、ソースコードのエクスポートやクラウド・コンプライアンス要件に合わせたデプロイを可能にします。