最初に「OpenFlowコントローラって何を選べばいいの？」と聞かれたら、私はこう返します。コントローラ選びは、スペック表や“有名どころ”だけで決めると高確率で遠回りします。大事なのは「何をしたいか」「どの規模で運用するか」「どこまで検証できるか」。この3つが曖昧なままだと、導入が進んだタイミングで“動くけど使えない”状態に陥りやすいんです。
私自身、最初は学習目的で「とりあえず動けばいい」と軽い気持ちで始めました。ところが、簡単なL2転送ができたと思ったら、翌日はARPで沼。別の日は疎通が取れているのにフローが入らない。ログは山ほど出るのに、肝心の原因に辿りつけない。こういう“あるある”を何度も踏んだ結果、ようやく自分の中で「コントローラ選定の順番」が固まりました。この記事では、そのときの失敗と立て直しをベースに、OpenFlowコントローラの選び方と検証の型をまとめます。
まず、OpenFlowコントローラの役割をざっくり整理しておきます。ネットワーク機器（スイッチ）がパケットを流すのがデータプレーン、どんなフローを入れるか決めるのがコントロールプレーン。OpenFlowコントローラは、スイッチからイベントや統計を受け取って判断し、フローテーブルへルールを配布します。ここで重要なのは「OpenFlowだけで全部やろうとすると詰む」という点です。監視、可視化、設定管理、外部システム連携まで、すべてをコントローラだけで抱える設計は、検証では成立しても運用で破綻しがちです。最初から“コントローラは意思決定と配布の核”と割り切ると、構成が落ち着きます。
次に、代表的な選択肢の“肌感”です。私が実際に触ってみて、向き不向きがはっきり出たのはこの3系統でした。
1つ目は、まず手を動かしたい人向けの軽量系。私はここでRyuを最初に触りました。チュートリアルやサンプルの雰囲気が掴みやすく、「イベントを受けてフローを入れる」一連の流れを短距離で体験できます。学習用途やPoCなら十分戦えます。ただ、やれることが増えるほど設計の責任が自分側に寄ってくる感覚があり、チーム運用や冗長化を強く意識し始めると、次の段階を考えたくなります。
2つ目は、運用規模が上がるほど効いてくる分散・クラスタ前提の系統。ここではONOSが頭に浮かびます。私は「落とせない」「止まったら困る」という話が出たタイミングで意識するようになりました。最初の導入は正直ちょっと重いです。構成要素が増えるので、いきなり“Hello World”のテンションで触ると面食らいます。でも、運用や拡張のことを本気で考え始めたとき、分散設計の土台があるのは強い。検証段階でも、将来の本番像が透けて見えるのがメリットでした。
3つ目は、モジュール型で拡張しやすい方向。私はOpenDaylightを触るとき、「どこまでやるか」を先に決めてから入るようにしています。拡張性があるぶん、設計の自由度も高い。逆に言うと、目的がぼんやりしているとコンポーネント選びで迷走しやすい。ここは“運用で必要になる機能”を先に棚卸ししておくと、選定が一気に楽になります。
ここまで読んで「結局どれが正解？」と思うかもしれませんが、私の結論はシンプルです。最初の正解は“用途の正解”であって、“製品の正解”ではありません。だから私は、コントローラを選ぶ前に次の3行を必ず書きます。
・何を制御したい？（L2/L3/ACL/帯域/経路制御など）
・対象スイッチは何？（OpenFlowバージョン、ベンダー、実機か仮想か）
・止められない？（冗長化、復旧時間、監視、運用体制）
この3行が決まったら、検証手順は“段階式”にします。私は一気に複雑なトポロジを組んで自滅したことがあるので、今は必ず最小構成から始めます。ここは回り道に見えて、最短ルートです。
ステップ1：最小トポロジで「会話できる」ことを確認
私はMininetで、1スイッチ2ホストから始めます。ここで見るのは、疎通より先に「コントローラがスイッチを認識しているか」「スイッチがどのOpenFlowバージョンで喋っているか」。この時点でバージョン不一致が起きると、疎通が取れているように見えてもフローが入らず、後半で必ず詰まります。最初に“会話の前提”を揃えるのがコツでした。
ステップ2：L2転送を“意図通り”にする
最初は「MAC学習っぽい挙動」をさせたくなりますが、ここで欲張るとログが増えて原因を見失います。私はまず、受け取ったパケットインに対して、最小限のフローを入れて動作を固定します。うまくいったら、次に学習やフラッディングを足す。段階を分けると、何が効いて何が壊れたかが分かりやすいです。
ステップ3：ARPで沼る前に“沼の形”を知っておく
これは本当に経験談です。L2が動いた翌日に「なぜか急に不安定」となりがちなのがARP周り。私はここで、パケットキャプチャを見る順番を決めました。ホスト→スイッチ→コントローラの順に追うと混乱するので、まずホスト間でARPリクエスト/リプライが成立しているかを確認し、次にスイッチでパケットインが起きているか、最後にコントローラがどう判断しているかを見る。順番を固定するだけで、疲労が減ります。
ステップ4：ログ地獄を抜ける“見る順番テンプレ”
コントローラのログは、真面目に全部読むほど沼です。私は「発生時刻」「スイッチ接続状態」「パケットインの有無」「フロー投入の成否（エラーコード）」「統計が取れているか」だけを先に拾って、枝葉のログは後回しにします。特に“疎通はしているのにフローが入らない”とき、エラーコードやバージョン、テーブルミスが原因であることが多く、最初からそこを見に行くのが早いです。
ステップ5：性能評価は“ざっくり”でいいから指標を固定
PoCでありがちなのが「なんとなく速い/遅い」で終わること。私は、レイテンシ・スループット・フロー投入時間・障害復旧（再接続までの時間）だけは毎回測るようにしています。完璧なベンチマークでなくていい。指標を固定するだけで、選定が感覚から判断に変わります。
この検証の型を回したうえで、本番に寄せるタイミングが来たら、ここからが“コントローラ選びの本番”です。運用目線で効いてくるのは、クラスタや冗長化の設計、監視とメトリクスの取り方、そして北向きAPIの使い方です。私は一度、検証で動いた構成をそのまま本番へ持ち込もうとして、監視や復旧手順が無いことに気づいて青ざめました。運用では「壊れたときに誰が、何を見て、どこまで戻せるか」が最重要。コントローラ自体の機能より、周辺の運用設計が勝負になります。
最後に、私のおすすめを用途別に短くまとめます。
学習・手元検証なら、まずRyuで“OpenFlowが動く感触”を掴むのが早いです。コードと挙動がつながる瞬間が多く、理解が進みます。
中〜大規模や可用性が必要なら、早めにONOSやOpenDaylightの世界観を覗きにいくのが得です。いきなり完璧に使いこなさなくても、分散・運用の前提を知っておくだけで、後の設計がぶれにくくなります。
そして何より、選定の前に「目的×規模×検証手段」を言語化する。これをやった瞬間、迷いが半分になります。
OpenFlowコントローラは“選ぶこと”がゴールではなく、“運用で困らない形に落とすこと”がゴールです。焦って近道を探すほど沼りやすい領域なので、最小構成から段階的に積み上げて、あなたの環境に合う正解を作っていきましょう。
コメント