How we built an automation platform for 600+ managed servers

私はオランダを拠点とするマネージドホスティング企業 Savvii の CTO です。私たちは PHP ベースのウェブサイト（e コマース、WordPress、それに類するワークロード）を専門としており、3 つの顧客セグメント、すなわち小規模顧客、リセラー、エージェンシーにサービスを提供しています。それぞれ異なるニーズ、異なる規模、異なる期待を持っています。

エージェンシーのセグメントで、私たちは最もプレッシャーを感じていました。エージェンシーは高度な顧客ですが、その社内チームは技術者と非技術者が混在していることが多いのです。彼らには GUI が必要です。コマンドラインの中で生きていくことはできません。そして、オンボーディングするエージェンシーが増えるほど、ますます明白になっていきました。 私たちには、本物の自動化に支えられたきちんとしたコントロールパネルが必要でした。

Ansible Tower や類似のツールも検討の対象でしたが、それらはセットアップが複雑すぎるか、ドキュメントに一貫性がないか、あるいはパフォーマンスやデータ主権に関する懸念を伴っていました。 私たちが求めていたのは、自社でホスティングでき、面倒なくアップグレードでき、 そして 1 週間のトレーニングなしでサポートチームに引き渡せるものでした。

何かに踏み切る前に、私たちは徹底的な比較を行いました。2 つの要素によって、候補は素早く絞り込まれました。

データ主権。 状態や認証情報をサードパーティのクラウドに保存するツールは対象外でした。セルフホスティングは譲れない条件でした。

非エンジニアにとっての UX。 一次サポートチームは優れたコミュニケーターであって、システム管理者ではありません。私たちが選ぶものは、あらゆるインシデントを DevOps にエスカレーションせずに使いこなせるものでなければなりませんでした。私たちが評価したツールは以下のとおりです。

Semaphore UI は両方の観点で勝りました。インストールは簡単でした。アップグレードは苦痛がありませんでした。UI は十分に整っていて、非エンジニアでも何が起きているかを理解できました。既存の Ansible インベントリの接続はほぼ摩擦がなく、唯一サポートが必要だったのはインベントリを接続させる部分でしたが、それもサポートにより素早く解決しました。Semaphore のドキュメントはしっかりしており、それが私たちに自信を与えてくれました。

最初のアーキテクチャでは、HostBill（請求）、Semaphore UI、CMDB の間のオーケストレーション層として n8n を使用していました。紙の上では、すっきりして見えました。ローコードで、視覚的で、メンテナンスに開発者が不要でした。

n8n のビジュアルインターフェースは、シンプルな直線的フローには優れています。しかし、条件分岐、エラー処理、複数ステップのコールバック、状態管理が絡んでくると、全体像が見えなくなりました。すっきりした図として始まったものが、シュールレアリスムの回路基板へと姿を変えました。

私たちは n8n を Laravel アプリケーションに置き換えました。これは本物のミドルウェアであり、ノーコードツールではなく、私たちのチームが完全に所有し理解しているものです。

私たちが出発点としたエージェンシーのセグメントでは、このアーキテクチャを通じて約 600 台のサーバーを運用しています。3 つのセグメント全体の総台数は、最終的に 3,000 から 4,000 台になる見込みで、私たちはこのプラットフォームを段階的に展開しています。

次に控えているのは、サーバー更新のための Semaphore のスケジューラーです。現在は外部ツールで処理していますが、スケジューラーが駆動する Ansible へ移行していきます。

私たちが何より変えたいと思う最大のこと。 自動化のコードを 1 行も書く前に、アーキテクチャ設計にもっと時間をかけること。 私たちは、どのフローがスケールし、どのフローが障害を適切に処理するかを十分に慎重に考えていなかったため、一度ならずやり直すことになりました。