Wixは、ユーザー登録、ウェブサイト編集、公開ウェブサイトのメンテナンス、画像アップロードなどのすべての機能を提供する単一のサーバーで始まりました。 かつて、この単一のサーバーは、私たちが急速に成長し、柔軟な開発方法を適用できるため、正しい決定でした。 ただし、2008年までに、定期的に繰り返される展開の問題が始まり、新しいサイトの作成と既存のサイトのメンテナンスの両方で計画外のダウンタイムが発生しました。
場合によっては、システムの新しいバージョンをデプロイするには、MySQLスキーマを変更する必要がありました。 Hibernateは、予想されるスキーマと実際のデータベーススキーマ（DB）の不一致を許容しないため、ソフトウェアの展開の一般的なプラクティスを使用しました。 このスケジュールされた停止中に、サービスを停止し、サーバーの電源を切り、MySQLスキーマに変更を加え、新しいバージョンをデプロイして、サーバーを再起動する必要がありました。
この計画された2時間の停止は、展開中に発生する可能性のある問題により、しばしばより複雑なものに変わりました。 場合によっては、MySQLスキーマに変更を加えると、計画よりも大幅に時間がかかりました（大きなテーブルの変更、インデックスの再構築、データ移行の制限の削除など）。 スキームを変更してサーバーを再起動しようとしても、展開、構成、またはスキームの予期しない問題が原因でサーバーが起動しなかったことがあります。 また、場合によっては、ソフトウェアの新しいバージョンが動作しないことが判明したため、サービスを復元するには、MySQLスキーマを再度変更して（以前のバージョンと一致させるため）、以前のバージョンのシステムを再デプロイする必要がありました。
しかし、「成功した」展開の数日後、最悪の事態が発生しました。新しいバージョンでは、まれではありますが、ユーザーサイトに損害をもたらす重大なバグが見つかりました。 この場合、最良の方法は（少なくともバグが修正されるまで）前のバージョンにロールバックすることでした。そのため、回路を再度変更する必要がありました。これは、サービスの予定外のシャットダウンを意味しました。
1つのサーバーアプリケーションを使用してすべてのWixシステムにサービスを提供したため、この停止は公開サイトを含むサービス全体に影響したことに注意することが重要です。 ユーザーベースが拡大するにつれて、計画中および計画外のストップの影響を受けるサイトが増えています。
そして、それは私たちに夜明けをもたらしました
Wixには、既存のサイトのサービスと新しいサイトの作成という2つの異なる機能があります。 サイトを停止すると、毎日の販売に直接影響しますが、既存のサイトを停止すると、既存のユーザーと有料ユーザーに直接影響します。 機能ごとに異なるサービスレベルを定義および作成する必要がありました。
さらに、さらに分析した結果、ほとんどのイノベーションは新しいサイトの開発に関連しており、既存のサイトに関連する変更はごくわずかであることがわかりました。 これは、変更が作成されたサイトのみに関係する場合でも、作成されたサイトと既に動作しているサイトの両方の機能を危険にさらすソフトウェアを頻繁にリリースすることを意味しました。
これを実現するために、システムを2つのセグメントに分割しました。新しいサイトの構築を担当する編集セグメントと、サイトの保守を担当するパブリックセグメントです。 このソリューションにより、各ビジネス機能に対応するさまざまなレベルのサービスを提供できました。
パブリックセグメントを構築するために選択されたテクノロジースタックは、意図的にシンプルでした。 Hibernateはもう使用せず、キャッシュの形式をすべて放棄し、Spring MVC 3.0の使用を開始しました。 重要な設計原則は、ソフトウェア、リリースサイクル、およびデータストレージに関してセグメントを非接続にし、ソフトウェアスタックを理解しやすくし、Webサイトのメンテナンスに最適化することでした。
そのような矛盾の明確な兆候は、編集プロセスデータベースからパブリックセグメントデータベースにデータをコピーした公開プロセス（その子孫はまだWixカーネルに存在する）でした。 このプロセス中に、データ構造は編集可能なビューから、公開サイトに最適なビューに変換されました。
その結果、パブリックセグメントの展開はまれで低リスクになりました。 最初の展開から6年経った今でもWixシステムで動作します（それ以降は何かが変更されていますが）。
私たちが学んだこと
リリースサイクルがリスクを伴うことは既にわかっていましたが、サイトの構築と保守という2つの重要なビジネス機能が異なるリスクレベルにあることに気付きました。 これらの機能にはさまざまなレベルのサービスを提供する必要があり、システムを構築する必要があるのはその周りであることがわかりました。 これらの異なるサービスレベルとは何ですか？ 可用性、パフォーマンス、変更の危険性、障害後の復旧時間などの側面を考慮しました。 すべてのユーザーとすべてのWixサイトに影響するパブリックセグメントは、これらの領域で最高レベルのサービスを提供する必要があります。 ただし、編集セグメントでは、失敗はサイトの作成に直接関係するユーザーにのみ影響するため、ビジネスへの影響はそれほど大きくありません。 そのため、柔軟性を高めるために高レベルのサービスを多少妥協し、開発に必要な労力を削減することができました。
Wix Site Designer Softwareのチーフアーキテクト、
ヨアヴ・アブラハミ
元の記事： Wix Engineers Blog