はじめに

はじめまして。CyberAgent group Infrastructure Unit（CIU）に所属している後藤 秀信です。

普段は CIU にてプライベートクラウドを社内向けに提供しているチームに所属しています。

今回は、Cycloud の新基盤の全貌に迫る連載シリーズの第一回として、新リージョン基盤の全体像についてお届けします。

本稿では、CIU が総力を挙げて開発に取り組んでいる「新リージョン」について、その概要とアーキテクチャの全体像、そしてこれまでの課題をどう技術で解決しようとしているのか、設計の裏側を Developers Blog にてお届けします。

本記事では、新しいリージョンが必要な背景、新リージョンで採用されるアーキテクチャ、そしてネットワークや仮想VMの管理における新たな取り組みについての概要をお伝えします。

プライベートクラウド（Cycloud）とは

組織の形を変えながらも、20年以上にわたり自社のインフラを支え続けており、社内向けクラウドプラットフォームを内製で開発・運用しています。

このプライベートクラウドサービス群を、私たちは「Cycloud」と呼んでいます。Cycloudでは、OpenStackベースの仮想マシン（VM）環境の「Cycloud Compute」、マネージドKubernetesサービス「AKE」、機械学習基盤「Cycloud ML Platform」など、社内の多様なニーズに応える基盤を提供しています。

本シリーズでは、Cycloudにおける仮想マシン（VM）基盤の新しいリージョンをテーマに、その背景、アーキテクチャ、改善ポイント、運用設計について数回にわたって紹介します。

なぜ新リージョンが必要なのか

Cycloud はこれまで、既存リージョンを通じて、数多くの社内サービスに対して仮想マシン（VM）基盤を提供してきました。

高いコストパフォーマンスを実現し、様々なマネージドサービスを提供していく中で、開発者にとって使いやすい環境を提供してきたと自負しています。しかし運用を続ける中で、既存のアーキテクチャや運用手法の限界が浮き彫りになってきました。

1. 事業成長を支えるハードウェア性能の重要性

この新リージョンプロジェクトの取り組みを考える大きなきっかけになったのは、社内の大規模システムでリソースがどのように使われているかを見直したことでした。

最新のハードウェアでは、同じようなコストを投じた場合でも、既存環境と比べて大幅に高い処理能力を発揮できることが確認され、単なるスペックの違いではなく、サービスの性能、コスト効率、ひいては事業競争力に直結する重要な要素であることが改めて明確になりました。

パブリッククラウドが継続的に新しいハードウェアを投入している中で、プライベートクラウドにおいても定期的なハードウェア更新を行い、インフラ性能を継続的に高めていく必要がありました。

2. 既存基盤の運用・アーキテクチャの限界

ハードウェア・仮想マシン（VM）基盤を更新したいという動機に対して、既存リージョンは以下のような構造的な問題を抱えていました。

• コンポーネントの更新が困難: 仮想マシン（VM）基盤で利用しているOpenStackのアップグレードには多大なコストとリスクが伴い、アップグレードを行う場合は実質的に新たなOpenStackを構築し、利用者へ移設してもらうという方法をこれまではとってきました。これは利用者側にも大きな負担となることはもとより、コンポーネントのアップグレードが滞るという実態がありました。
• テナント間NWの分離不足: 特に既存リージョンではNWレイヤーで分離されていないリージョンもあり、さらなるセキュリティ強化・ゼロトラスト思想への対応が、まだ不足している部分がありました。
• 利用者の高い移設負担: 1つ目の部分でも言及しましたが、新しい基盤を作るたびに利用者に多大な労力を強いてVMの移設作業をお願いする必要がありました。事業開発の足かせとなる可能性もあります。さらに、一部既存リージョンではライブマイグレーション機能がないため、物理サーバ（Computeノード）の定期メンテナンスが発生する際には、予め利用者に仮想マシン（VM）の停止・起動をお願いしており、運用負荷が発生してしまうという課題がありました。

これらの課題を根本から解決し、「利用者に負担を強いることなく、半永久的に最新のハードウェアとサービスを提供し続けられる仮想マシン基盤」を創り出すことが「新リージョン」の最大の目的となっています。

新リージョンが目指す全体像とコンセプト

新リージョンの開発にあたり、明確な目標（Goals）と非目標（Non-goals）、そしてシステムコンセプトを定義しました。

Goals と Non-goals

【目標（Goals）】

• 一生運用できる持続的に開発可能なVM基盤
• 「NIST によるクラウドコンピューティングの 定義」を満たすVM基盤
• 半永久的に提供し続けられる（すべてのコンポーネントが更新可能な）VMサービスになっていること。
• 利用者の利便性に直結する部分を改善すること（利用者の作業依頼を軽減する）

【非目標（Non-goals）】

• 後から追加・拡張できる機能をリリース段階で追い求めない
• 利用者の需要を度外視した要件・必要な理由を説明できない要件は入れない

Cycloudでは、プライベートクラウドとしての価値を高めるため、長期的に運用し続けられる仮想マシン（VM）基盤の実現を重視しています。

内製認証基盤との統合やリソースの利用効率を向上させるとともに、基盤内部の複雑な仕様を利用者に意識させない設計を進めることで、複数の利用者やワークロードが同じ基盤を効率的に共有できる状態を目指しています。

さらに、仮想マシン（VM）の起動までの時間を短縮など、ワークロードの変化に応じて素早くリソースを利用できる、スピーディな拡張性を実現していきます。

NW面ではVPCによって（後述）、利用者ごとの分離性を保ちながら、安全なリソース共用と柔軟な拡張を可能にします。

加えて新リージョンを一度作って終わりにするのではなく、継続的に改善・更新できる仮想マシン（VM）基盤を目指しています。

新リージョンでの新たな取り組みとアーキテクチャ

ここからは、新リージョンで具体的にどのような技術的アプローチを採用しているのかの概要をお伝えします。

1. Compute Controller による OpenStack APIの隠蔽

既存の運用では、利用者が CLI や構成管理ツールで直接OpenStackのAPIを操作していました。

しかし、この方式には、OpenStackのバージョンアップや機能拡張が難しくなるという課題がありました。変更の影響が利用者の業務や利用体験に及ぶ可能性があり、場合によっては構成管理ツールや利用者側の運用自動化ツールにも改修が必要になります。そのため、基盤側の改善が進めづらく、長期的な運用における制約になる懸念がありました。

そこで新リージョンでは、中核となるコンポーネントとしてKubernetes上に独自開発を行った「Compute Controller」を配置し、利用者からのリクエストは、WebコンソールやCycloud CLI、構成管理ツールなどを通じて抽象化された API にリクエストをし、この API リクエストから Kubernetes のカスタムリソース（CRD）を生成・更新し、それを Compute Controller が Watch して、背後にある適切なOpenStackクラスタに対して操作を行うというアーキテクチャとなっています。

この二層構造により、「OpenStackへの依存を減らし、Cycloud独自の仕様を実装する余地」を確保しました。ストレージアプライアンス間のVolumeの移動も、このコントローラー層で吸収します。

2. マシンファミリーごとのOpenStackクラスタ分割

過去の経験から稼働中のOpenStackクラスタを、インプレースでメジャーアップデートすることは極めて困難であると判断した経緯があり、「OpenStackの更新を諦め、マシンファミリー（世代）ごとに新しいOpenStackクラスタを構築する」というアプローチで仮想マシン（VM）基盤を提供しています。

たとえば、A世代の物理サーバ群には「A世代用のOpenStack」を、次世代のB世代の物理サーバが登場した際には「B世代用のOpenStack」を構築します。前述のCompute Controllerが、利用者が指定したインスタンスタイプ（フレーバー）に基づいて、適切な OpenStack クラスタへとAPIリクエストをルーティングします。

利用者が旧世代から新世代へマシンタイプを変更して再起動（Stop/Start）するだけで、裏側ではCompute Controller が「別の OpenStack クラスタへの VM 再作成と Volume の付け替え」を自動的に行います。利用者から見れば単なるインスタンスタイプの変更ですが、これにより実質的にクラスタの移行が完了し、インフラ側は古いOpenStackクラスタを安全にリタイアさせることが可能になります。

3. VPC（Virtual Private Cloud）の導入

これまでフラットに近かったテナント間のNWを見直し、利用者（テナント）ごとに完全に分離された VPC（Virtual Private Cloud）の概念を導入しました。

• IPリソース枯渇の防止と柔軟な設計: 利用者はプロジェクト内に VPC を作成し、割り当てられたCIDRブロック（例: /20）の中で、自由にサブネット（/22〜/26など）を切り出すことができます。
• 厳密なトラフィック隔離: VPCは他の環境からのトラフィックを受け付けないため、テナント間通信は完全に分離されます。
• Security Groupの再定義: 通信の制御はOpenStack の Security Groupによって行われます。コントローラーは、利用者が定義したSecurity Groupとルールを、対象となるすべての背後のOpenStackクラスタに複製・同期します。これにより、VMがどのOpenStackクラスタ（どのマシン世代）に配置されていても、一貫したセキュリティポリシーが適用されます。

また、スイッチの設定管理はAPI経由で自動化しており、VLAN管理の煩雑さ・運用負荷の解消、セキュリティリスクの払拭という課題を解消し、運用コストの削減と安定性向上を図っています。

4. 内製ロードバランサーの提供

Cycloud では 内製 L4/L7 ロードバランサーを提供しています。現在は Application Load Balancer（L7） を提供しており、API 仕様は Kubernetes Gateway API と互換性を持つ形で実装されています。また、IAP（Identity-Aware Proxy）を利用することで、社内サービスを公開する際に必要な認証・認可やセキュリティ要件を満たせるようにしています。

既存リージョンにもソフトウェアロードバランサーがありましたが、一部リージョンでのみ提供されており、独自 API による拡張性の課題や、内製認証基盤との連携ができていないといった課題がありました。そこで、新しい仮想マシン（VM）基盤の開発にあわせて、ロードバランサーサービスも刷新することになりました。目的としては VPN や社内NW接続に関する運用負荷を減らし、各 Cycloud サービスの開発コストを下げることです。あわせて、アクセスログの収集、社員からのリクエストであることの検証、入口部分のセキュリティ要件の標準化を行います。実装では Gateway API との互換性や External Authorization の対応を重視し、候補技術の比較も行いました。また、アクセスログはインシデント対応や監査の観点で重要なため、必要な情報を安全に保管しています。インターネットに接続する Gateway には最小権限の原則を適用し、Network Policy などを用いて接続先を制限することで、安全な公開基盤を目指しています。

おわりに

ここまでご紹介した「新リージョンプロジェクト」は、単なる既存ハードウェアの入れ替えやサーバーの増設プロジェクトではなく、「クラウドインフラを提供する側と利用する側の両方が、インフラのライフサイクル（老朽化やアップデート）を意識しなくて済む世界」を達成するために既存の考え方の刷新および開発・提供を行っております。Kubernetes CRDを用いた抽象化レイヤーの設定、VPCによるテナントの完全分離、そして無停止を前提としたNWとライブマイグレーションの設計。これらすべてが組み合わさることで、Cycloudは社内システムを支える真のスケーラブル・クラウドとしてリリースされました。

次回予告

次回は「Cycloud 新基盤の全貌 第二回: HW 編」の紹介をします。

連載記事一覧

本シリーズでは、各チームが新基盤構築における技術的挑戦を公開しています。他のレイヤーの知見については、ぜひ連載の他の記事も併せてご覧ください。

Cycloud 新基盤の全貌 第一回 新リージョン基盤の全体像

Cycloud 新基盤の全貌 第二回 HW 編

Cycloud 新基盤の全貌 第三回 NW 編

Cycloud 新基盤の全貌 第四回 IaaS 編

Cycloud 新基盤の全貌 第五回 ComputeController 編

Cycloud 新基盤の全貌 第六回 LB 編

Cycloud 新基盤の全貌 第七回 KaaS 編

Cycloud 新基盤の全貌 第八回 FrontEnd 編

各レイヤの Cycloud の新基盤に関して、より詳細な仕様や設計思想を知りたい方は、上記各チームの Developers Blog 記事をぜひご一読ください。