背景：サーバーの仮想化とオーケストレーション
近年のサーバーセンターでは、コンピューター内で動かすプログラムをコンテナ(Pod)化し、マシン(Node)間で柔軟に配置・移動させることで、資源の有効活用と運用の自動化を図っています。コンテナをどこのサーバーに置くかを決める仕組みをオーケストレーションといい、Kubernetesなどが有名です。
複数マシンの協調管理
たくさんのサーバーをまとめて一つの大きなコンピューターのように扱い、 コンテナを効率よく配置・移動させることで、資源の無駄を減らします。
障害時の冗長性
どこかのサーバーが故障しても、すぐに別のマシンにコンテナを移してサービスを継続します。
負荷変動への対応
負荷が高いサーバーから低いサーバーへコンテナを移動させることで、 全体の負荷を均等に保ち、性能低下を防ぎます。
課題点：多様な制約が絡み合う配置問題
コンテナの配置問題では、複数の制約条件を同時に満たす必要があり、それらが互いに衝突することで最適化が困難になります。
容量制約
各サーバーには CPU・メモリ・ストレージ などの物理的な上限があります。 この容量を超えてコンテナを配置することはできません。
- CPU使用率の上限
- メモリ容量の上限
- ストレージ・帯域の制限
配置ルール制約
運用上の理由から、コンテナの配置場所に ルール が設けられることがあります。
- 同一サービスは別サーバーに分散（冗長性）
- 特定のサーバーへの配置禁止（メンテ中など）
- GPU等の特殊ハードウェア要件
移動コスト制約
コンテナの移動には コスト が伴います。無制限に移動させると運用に悪影響が出ます。
- 移動中のサービス一時停止・遅延
- ネットワーク・ディスクI/Oの増加
- 監視・復旧の運用負担
解決策：量子アニーリングで“多目的最適化”を一撃で
置き場所の組合せ（0/1）を一つの最適化問題にまとめ、アニーリングで“良い配置”を探します。負荷の偏りと移動量を同時に小さくします。
入力（観測）
- サーバーのスペック（CPU/メモリ）
- コンテナごとの必要量（CPU/メモリ、優先度）
- 現在のコンテナ配置
- 移動コスト（影響が大きいものほど高い）
- アンチアフィニティ（同一サービス分散）
出力（意思決定）
- 変更後のコンテナ配置
最小の移動
メモリやCPUの使用率が高いコンテナほど移動コストを高く設定することで、負荷が跳ね上がったタスクがあるときはそれ以外のコンテナをどかすよう促します。
均等な負荷
各サーバーの理想負荷からのズレを二乗で評価し、マシンの劣化を均等にします。マシン間の性能差も適切に考慮します。
分散配置
同一サービスの同居をペナルティ化して、冗長性とスパイク耐性を高めます。これによりマシン障害時にサービスを維持しやすくなります。
新規追加ノードの自動配置
新しいサーバーが追加された場合、負荷を計算して適切なノードを活用するよう促します。
障害/退役の自動退避
ノード停止、隔離、メンテナンス時は停止したコンテナを新規配置ノードとして扱い、適切なノードに再配置します。
今後やりたいこと
オートスケーリングとQA接続を軸に、“オンライン最適化”としての価値を伸ばします。
オートスケーリング
“再配置”だけでなく、コンテナ数の増減（作成/削除）まで意思決定に含めます。 需要に応じたスケールと配置を一体化します。
QAとの直接接続
量子アニーラ（QA）やハイブリッド実行環境へ直接投げ、 最新の状態に基づいて低レイテンシで高頻度の最適化を狙います。
サーバー容量を考慮した自動停止
CPU/メモリの使用率が限界に近づいた時、優先度の低いコンテナを自動的に停止し、全体の安定性を保ちます。
運用制約の吸収
物理的に別の場所へ分散、ハードウェア要件（GPU/特定機種など）、優先度、遅延目標などを段階的に統合。
高速化と安定化
前回の解を初期解にする、変更分だけ最適化する、重みを自動調整するなどで、より迅速で安定した最適化を目指します。
ネットワーク帯域の考慮
コンテナ移動時のネットワーク負荷を考慮し、帯域制約を超えないように最適化します。