「ゼロダウンタイム」設定のヘルプ

サポート インストール
1

「ダウンタイムゼロ」設定について理解しようとしています。現在の環境では、異なるコミュニティ向けの Discourse インスタンスがいくつかあります。どちらもデータ/ウェブの 2 つのコンテナ構成になっています。ホストレベルには Nginx があり、SSL 終端処理を行い、コンテナ内の Nginx へソケット接続を渡す仕組みになっています。

以下の 2 つのトピックに興味を持っています：

このプロセスを理解しようとしています。これを実現するには、ある程度の前提知識が必要とされているように思えます。何かご助言いただければ幸いです。

まず理解したいのは、データコンテナのアップグレードが必要になるタイミングをどう判断するかです。ウェブコンテナを再構築するだけでは済まないケースがあるようです。そのようなケースを確実に特定する方法はありますか？管理 UI のアップグレードオプションがグレーアウトしている場合や、テーマやプラグインのカスタマイズが行われている場合などがそれに当たるのでしょうか？データベーススキーマのマイグレーションを確認することで確実に判断できるでしょうか？それとも、ステージング環境を用意して実際に試してみないと確実にはわからないのでしょうか？

次に知りたいのは、ダウンタイムゼロでのアップグレードをどう実行するかです。上記の 2 つのリンクを読む限り、結局はデータコンテナとウェブコンテナの両方を再構築することになるのでしょうか？この点はよく理解できません。最終的にダウンタイムゼロを実現するには、データとウェブのコンテナを別々に用意する必要があるのでしょうか？

ご教示いただければ幸いです。自分で何時間も調べて「動いたように見える」ものを見つけることもできるかもしれませんが、巨人の肩に乗りたいですし、可能であれば本番環境で試行錯誤してエッジケースに直面する必要はありません。

私の環境に関する追加情報が必要であれば、ご質問ください。直接返信し、この投稿を更新いたします。

よろしくお願いいたします。

「いいね！」 2
2

「デプロイ後のマイグレーション」については詳しくありませんが、ここで（Meta上で）読んだ記憶によると、これを達成する一つの方法は3つのコンテナを使用することです。1つのデータ用コンテナと2つのウェブ用コンテナです。更新していないウェブコンテナを更新し、更新完了後に使用対象として切り替えます。

「いいね！」 3
3

これで意味が通じると思います。つまり、データコンテナはランチャー経由でリビルドを実行しないということですね。負荷分散はホストレベルの Nginx で対応するつもりです。これを整理してみましょう:

データコンテナ:

./launcher enter data_container 
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate

web_container

./launcher rebuild web_container1 && \
sleep 60 && ./launcher rebuild web_container2

データコンテナ:

rails generate post_migration
SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate

これで問題ないでしょうか？

4

これは、データコンテナにどのような更新が必要かによって異なります。

Postgres 12 の更新は、避けられないダウンタイムの好例です。重複するデータコンテナを用意していても、データベースのアップグレード中は、複製サイトをリードオンリーモードで運用する必要があります。

ダウンタイムを完全にゼロにする唯一の方法は、アップグレードを一切行わないことです。単一コンテナインストールでは、/admin/upgrade 経由での更新はすでにダウンタイムゼロで実施可能です。一方、ベースイメージの更新が必要な場合など、ssh を通じて行う更新については、予算と複雑さへの許容度に応じて、ダウンタイムの程度が異なります。

ダウンタイムを回避する最善の方法は、ステージング環境のコピーを作成することです。そうしないと、プラグインやカスタマイズが互換性の問題に直面した際に、更新のたびにわずかなダウンタイムが発生するリスクが生じます。

「いいね！」 2
5

はい。重大な問題が発生しないようにするため、ステージング環境で実行して結果を確認します。つまり、上記の手順を試して、データコンテナが失敗するかどうかを確認します。

その場合、ステージング環境はデータ1、Web1で構成し、本番環境はデータ2、Web2で構成します。最も悪いシナリオでは、まずステージングで試した後、本番環境で以下を行います。

  • 読み取り専用モードに設定
  • cp -rp shared/data1 を shared/data2 にコピー
  • data2 をアップグレード
  • web2 を停止
  • data2 を web2 にリンク
  • web2 を再構築
  • data2 を web1 にリンク
  • web1 を再構築
  • 読み取り専用モードを無効化

これで理解できますか？

6

ダウンタイムの定義によります。

ユーザーがサイトにアクセスできない場合、明らかにダウンタイムです。

登録、投稿、返信、「いいね」ができない場合、それをダウンタイムとみなしますか？

大規模なコミュニティの場合、SSD 上の複数のデータコンテナを運用するコストは相当なものになります。Amazon RDS などの外部 PostgreSQL サーバーの導入を検討されましたか？

「いいね！」 1
10

@Stephen が指摘しているような詳細は非常に重要です。なぜなら、私たちは「ゼロダウンタイム」が何を意味するのかを理解する必要があるからです。例えば、以下のようにして「ゼロダウンタイム」の要件をハックすることも可能です。

「ゼロダウンタイム」を「リクエストが有効な場合、HTTP 200 以外のコードでユーザーに応答することが決してないこと（必要に応じて 300 や 400 は開けておく）」と定義します。その後、10 ドルのドロプレット上で 1 コンテナ構成で Discourse をデプロイし、Add an offline page to display when Discourse is rebuilding or starting up を追加して 500 エラーを発生させないようにします。こうすれば、サイトがダウンしているように見せることはありません。

しかし、理性的な思考を持っていれば、これが「ゼロダウンタイム」だと考えるでしょうか？決してありません。ただし、提案通りに機能するかと言えば、もちろん可能です。さらに「ゼロダウンタイム」に耐性を持たせるために、別のリージョンにスタンバイサーバーを追加することもできます。

だからこそ、条件付けと意味論が重要なのです。常に何かを表示することと、常にサイト機能を利用可能にすることは、同じではありません。

「いいね！」 3
12

状況を詳しく教えていただけますか。ダウンタイムゼロの定義を達成するために何が必要ですか？ユーザーが10〜30分間の読み取り専用状態を許容できますか？それとも、独自に解決策を構築する技術力はお持ちですか？それとも、ユーザー向けに「メンテナンス中、すぐ戻ります」というきれいなページを用意したいとお考えですか？より正確で実用的なソリューションをご提案、あるいは適切な方向をご案内するために、さらに詳細な情報が必要です。

14

この議論は少し熱くなり、話題から外れてきています。話題について議論する際は、お互いを尊重することを忘れないでください。明確化のための質問は、すべての人の環境や目標が異なるため、より正確な回答を得るために提出されます。

15

このトピックは13時間後に自動的に公開されました。