こんにちは。LINEヤフーでプライベートクラウドのインフラを担当している井上です。
LINEヤフーの膨大なトラフィックとデータを支えているのは、私たち自らが開発・運用している大規模なプライベートクラウドです。現在は、旧LINEの「Verda」と旧ヤフーの「YNW(IaaS)」という2つの巨大な基盤を、次世代基盤「Flava」へと集約していく過渡期にあります。
| Verda | YNW | Flava | |
|---|---|---|---|
| サービス開始 | 2016 | 2013 | 2025 |
| Hypervisor（物理サーバ）数 | 11,000+ | 27,000+ | 500+ |
| VM（仮想マシン）数 | 130,000+ | 220,000+ | 9,000+ |
| OpenStack クラスター数 | 4 | 160+ | 1+ |
| Object Storage容量(PB) | 200+ | 100+ | 5+ |
この膨大なリソースをいかに効率よく、かつ止めることなく運用していくか、私たちのクラウドを支える設計思想とコア技術、そして次世代基盤Flavaが目指す世界について掘り下げていきます。
なお、本記事では私たちのクラウドの土台となるIaaS、ネットワーク、ストレージといったレイヤーの技術スタックに焦点を当てています。その上で稼働するKaaS(Kubernetes as a Service)やDBaaS(Database as a Service)、PaaS(Platform as a Service)などの上位レイヤーについては、また別の機会に譲り、今回は割愛します。
設計思想と運用について
私たちのクラウドは、以下の思想に基づいて設計・運用されています。
障害を前提とした設計と利用
サービス開発のスピードを最大化するため、インフラ単体での過剰な可用性担保には固執せず、障害は常に起こりうることを前提としています。具体的には、以下の3点を設計の柱としています。
-
ステートレス性の追求
VMのRoot Disk(Ephemeral Disk)へのデータ保存は一時的なものと定義しています。永続化データは外部ストレージへ逃がすことで、インスタンス障害時のサービス影響を極小化します。 -
アプリケーション主導の可用性
インフラ単体で完全な可用性を担保するのではなく、アプリケーション側の構成と組み合わせることで信頼性を確保し、インフラの複雑性を排除しています。 -
復旧の迅速化
障害時の優先事項は現状復帰ではなく、サービスの継続です。原因究明に時間をかけるよりも、IaCを用いて環境を即座に再構築する運用を推奨しています。
この設計思想を実現するには、利用者側の理解と協力が欠かせません。 そのため、私たちは障害を前提とした設計に関する啓蒙活動やコンサルティングを継続的に行っています。また、KaaSやPaaSなどの、より抽象度の高い環境の利用を推奨し、開発者が意識せずとも堅牢なサービスを作れる文化の定着を図っています。
運用と監視の高度化
大規模クラウドを少人数で安定運用するため、徹底した自動化とObservabilityの確立に注力しています。
IaCによる完全自動化と統制
OS設定から各種パッケージのインストール、ネットワーク投入まで、あらゆる構成管理をコード化し、CI/CDパイプラインによる自動適用を徹底しています。また、デプロイはAZ（Availability Zone）単位で実行することで、万が一の障害時にも影響範囲を局所化する安全機構を組み込んでいます。
森と木の両方を見るObservability
大規模環境で現状を正確に把握するため、マクロな監視とミクロな調査、それぞれのレイヤーに特化したツールを整備しています。エンジニアはこれらを駆使し、状況に応じて森と木の視点をシームレスに行き来しながら調査を行います。
- 森（マクロ視点）
Prometheus/Grafanaや内製ダッシュボードを用い、クラウド全体の健全性や傾向を常にモニタリングし、異常の兆候を掴みます。 - 木（ミクロ視点）
異常検知時は、カーネルレベルのトレースやパケットキャプチャなどの深層情報を掘り下げ、原因を特定します。
これらのツール群と、それを使いこなして事象の全体像から根本原因までを追跡できるメンバーの技術力こそが、安定稼働の要です。
大規模クラウドを支える技術とマインド
クラウドの各領域において、私たちはSoftware Definedを基本とし、OSSコミュニティと共に成長しながら、足りないものは自分たちの手で作るというスタンスを貫いています。
OSSの利用と貢献
私たちの基盤は、OpenStack, Envoy, Linux kernel(eBPF/XDP), FRR, Ceph といったOSSを中核に据えています。私たちは単にそれらを利用するだけではなく継続的にコミュニティへの貢献活動を続けています。
例えば、OpenStackやCephに対してはUpstreamへ修正パッチを提供（例1,例2,例3,例4）し続けており 、ネットワーク領域ではFlavaのVPC（Virtual Private Cloud）に必要なSRv6 BGPに関する機能を設計実装し、FRRoutingやLinux Kernelへのコミット（例1,例2,例3,例4）をしてきました。
自分たちのワークロードに必要な機能があれば、それを独自の改造で済ませるだけではなく、本家のOSS自体に実装しています。そうすることで、独自パッチの将来的なメンテナンスコストを回避しつつ、世界中のコミュニティと共に技術そのものを進化させることができると考えています。
汎用ハードウェアの限界を引き出すSoftware Defined技術
性能やコスト、柔軟性の観点から高価な専用アプライアンスへの依存を最小化しています。 IaaSのコンピュートノードはもちろん、VPC, DNS, LB（Load Balancer）といったネットワークプロダクトも、汎用的なx86サーバー上で動作させています。
その上で、高い性能が要求される箇所には、XDP (eBPF) による高速なデータプレーン実装やハードウェアオフロードの活用、チューニングなどを徹底し、汎用サーバーでありながら、ワイヤースピードに近いスループットや、極めて低いレイテンシを実現できる構成を目指しています。
ギャップを埋めるフルスクラッチ開発
OSSだけではカバーしきれない社内固有の課題に対しては、フルスクラッチでの内製開発を行ってい ます。
例
-
オブジェクトストレージDragon
HDDの容量効率と運用性を最優先して設計した独自オブジェクトストレージの開発 -
ネットワーク制御と周辺ツール
SDN Control PlaneやロードバランサのHealthCheck Agent、サービスディスカバリなど、運用の中枢を担うコンポーネントをRust, Golang, Pythonなどで開発
ハードウェアの故障を見据えた自律運用
数万台のHypervisorとペタバイト級のストレージを抱える環境では、ハードウェア故障が毎日どこかで必ず発生します。これら全てを人手で対応することは不可能です。現在は、故障検知からデータセンター現地の作業員への依頼、交換後のクラスターへの再投入作業まで、大半を自動化しています。
しかし、一部の作業やイレギュラーな故障パターンなど、まだエンジニアの手動対応が必要なフローも残されています。今後は、こうした判断業務にもLLMを活用し、一層の自動化を目指していきます。
次世代基盤Flavaへの進化
旧クラウド運用における長年の知見を結集し、2023年後半から開発開始、2025年にリリースされたのが次世代基盤「Flava」です。すでに1万台近くのVMが作成されるなど、利用が拡大しています。Flavaでは、旧基盤で課題となっていた多くの点を根本から解決するため、さまざまな改善を加えています。これほどの大規模なインフラを1から作り直せるまれな機会を最大限に活かし、既存の延長線上による改修ではなく、抜本的なアーキテクチャの刷新 に踏み切りました。
Flavaにおける主な改善点
専用環境の廃止と単一リソースプール化
旧クラウドでは特定のプロダクトやサービスのための専用環境（クラスタ、リソースプールなど）が多数存在し、キャパシティ管理がパズルのように複雑化していた上、リソースの利用効率にも課題がありました。Flavaでは、この複雑さを解消するため、専用環境を廃止し、ほぼ全てのプロダクト・サービスを単一の巨大なリソースプールで吸収する設計としました。これにより、キャパシティプランニングにおける変数が激減し、リソース効率と調達から提供までのアジリティが劇的に向上します。
メンテナンス性を維持する、Upstream追従のアーキテクチャ
旧クラウドではOpenStackに対し、独自の改造を重ねすぎた結果、アップグレードが困難になる課題がありました。 その反省を踏まえ、FlavaではUpstreamのOpenStackに追随するアーキテクチャを採用しました。独自パッチを最小限に抑え、必要な機能改修は積極的にUpstreamへコミットして本家に取り込んでもらう方針としています。こうしてアップグレードの障壁を取り除くことで、定期的な更新サイクルを実現し、セキュリティと最新機能を常に維持できるようにしています。
VPCデフォルト化
Flavaではネットワークセキュリティのレベルを根本から引き上げるため、VPCの利用をデフォルト化しました。これにより、マルチテナント環境でありながら、互いの通信が干渉しない堅牢なセキュリティモデルを標準で提供しています。
また、VPCの導入は個人情報等の機密性の高い情報を扱うセキュア環境の構築にも大きな変化をもたらしました。従来はFW(Firewall)や専用VLANを用いた物理的なテナント分離が必要で、環境準備に月単位の時間が必要でした。FlavaではVPCによる論理分離とそれに応じたプロダクト群の連携で同等の安全性を確保でき、これにより、セキュア環境をわずか数分で提供できるようになりました。
一方で、全社規模でのVPCのデフォルト化は旧クラウドでは行っておらず、Flavaが初の挑戦です。すべてのトラフィックを処理するVPC基盤には、極めて高い信頼性と性能が求められます。 旧クラウドの運用で培った安定運用の知見を活かしつつ、VPCのデータプレーン刷新（XDP化）などの根本的な性能改善策を並行して進めています。
ユーザーと共に実現するコスト最適化
Flavaでは利用者が自律的にコストを最適化できる機能も組み込んでいます。 開発環境（クラウド利用者にとっての開発環境）ではリソースのLifetime（有効期限）設定を必須化し、ゾンビリソースの自動削除を実施しています。
また、オブジェクトストレージには「High Performance」と「Scalable（大容量・低コスト）」という複数のバケットクラスを用意し、ユーザがエンドポイントを変更することなく、クラス変更を後から行うことも可能にしました。 これによりアクセス頻度の変化などの業務特性に応じて、コストと性能を動的に最適化できます。
Flavaにて直面している課題と挑戦
現在、Flavaはまだ最低限のプロダクトをリリースした段階であり、今後はさらなる機能拡充が急務です。また、開発スピードを優先した反面、リリース後にバグや考慮漏れが明らかになることもあります。これらを迅速に解消しつつ、基盤の成熟化を進めています。
そして、最大の課題は旧基盤からのマイグレーションです。透過的な移行やツールの提供などで利用者の負担軽減を図っていますが、どうしても手動対応が必要な部分も出てきます。新旧基盤の重複投資期間をいかに短くし、トータルコストを最適化できるか、私たちの挑戦はまだ始まったばかりです。
スタックの進化を支えるチームとカルチャー
最後に、この技術スタックを進化させ続けるチームについて触れます。私たちのチームには、カーネルのコードを読み解く低レイヤーのスペシャリストから、モダンなWebフロントエンドで管理画面を作り込むエンジニアまで、レイヤーを横断した多様なバックグラウンドを持つメンバーが集結しています。
共通しているのは、インフラをブラックボックスとして扱わず、中身を理解し、主体的にコントロールしようとする姿勢です。先述したOSSへの深い介入（Upstreamへのパッチ提供など）も、ソースコードレベルで挙動を追跡できるメンバーの技術力があってこそ実現できています。また、商用製品を採用する場合でも、単なるユーザーに留まらず、ベンダーと深く議論を重ねて仕様改善を要望しています。このような、自分たちの手でコントロール可能なクラウドを作るという姿勢こそが、LINEヤフーのプライベートクラウドを支える原動力です。
おわりに
独自の進化を遂げてきた、旧LINEと旧ヤフーの2つの巨大なクラウドを統合し、次世代基盤Flavaへと刷新する取り組みについて紹介してきました。私たちのクラウドは、OpenStackなどのオープンソースソフトウェア（OSS）を最大限に活用しつつ、規模や要件に合わない部分は自分たちの手で作り変えるというアプローチを徹底しています。障害の発生を前提にした設計や、IaCによる徹底した自動化、そして汎用ハードウェアの性能を極限まで引き出す技術、これらはすべて、LINEヤフーの膨大なトラフィックを安定して支え続けるために私たちが積み上げてきた技術です。
本記事が、大規模インフラの設計やプライベートクラウドの技術スタックに関心を持つ方々にとって、ひとつの参考事例となれば幸いです。
