先日、ある教会と新しいウェブサイトの制作に取り組んでいた際、あまり望ましくない状況に遭遇しました。当初、その教会のインフラは、開発用Webサーバーが本番環境のRockインスタンスと同じ
VM上に配置されるように構成されていました。もし他の方でも同様の構成を検討されている方がいらっしゃるかもしれないため、なぜこれが好ましくないのかについて、ここで少し解説したいと思います。
開発環境と本番環境を分離したい理由は、「共有リソース」と「複雑な設定」という2つのカテゴリーに分類されます。それぞれについて詳しく見ていきましょう。
共有リソース
本番環境と開発環境を単一のサーバー上で同時に稼働させる際の主な懸念点は、サーバーのリソースにあります。開発環境が構築されるのは、
本番環境では行いたくないような作業をそこで行いたいからです。一方、本番環境は組織の日常業務にとって極めて重要です。これら2つの目的は、根本的に相反するものです。
ウェブサイトプロジェクトでは、現在の環境が新サイトの負荷に対応できる十分な容量を備えているかどうかを検討する工程を設けています。現在のパートナー企業が
教会のアーキテクチャマップを管理していないため、この不適切な慣行が行われているという兆候は見られませんでした。
ただし、週末のチェックイン処理のパフォーマンスについて、現在懸念が寄せられているという話は聞いていました。
最後の点を考えてみてください。チェックインのパフォーマンスをめぐるスケーリング上の課題があります。1台のVMが2つの役割を担っていることを知っていると、
現状の評価や考えられる解決策の検討がはるかに困難になります。 Azureのパフォーマンスログに戻って、チェックイン期間中のCPUおよびメモリ使用状況を確認しても、その負荷が
本番環境のIISインスタンスによるものなのか、開発用インスタンスによるものなのかを判別する手段はありません。もしかすると、誰かが同時に開発用マシンで何かを使用したりテストしたりしていたのかもしれません。
複雑な構成
共有リソースの問題だけでも、この構成が不適切であることは明らかですが、さらに、同じVM上でRockのインスタンスを2つ実行するために必要な構成についても検討する必要があります。これは主に、
1つのIPアドレス宛てに届くトラフィックを、2つ以上のIISインスタンスで処理するために必要なIISのバインディングの問題に帰着します。この構成では、各ホスト名に対して
2つのバインディング（HTTP用とHTTPS用）を設定する必要があります。
通常のIISインストールでは、すべてのトラフィックは単一のIISインスタンスに送信されます。これにより、新しいホスト名（たとえば、追加したばかりの新しいマイクロサイトなど）の追加が簡単になります。DNSを設定するだけで、
そのトラフィックが確実にRockに届くようになります。複数のインスタンスを実行する場合は、IISの本番インスタンスに2つの新しいバインディングルールを追加する必要があります。
これらの設定は決して難しいものではありませんが、予期されるものでもないため、新たな障害要因となり得ます。
まとめ
本番環境と開発環境を分離することは、Rock環境を安定かつ予測可能な状態に保つために不可欠です。特に、開発環境を実行可能なAzureのバースタブルVMが
月額約30ドルで利用可能であることを考慮すれば、その重要性はさらに高まります。
トライアンフでは、常にベストプラクティスを念頭に置いて物事に取り組むことに情熱を注いでいます。また、これらのベストプラクティスをロック・コミュニティと共有し、
教育や支援を通じて社会に貢献することにも、同様に情熱を注いでいます。