4 つの 9 の正確な意味から始めましょう。

4 つの 9 は、月あたり 4.38 分、または年あたり 52.56 分のダウンタイムです。 つまり、電子メールが毎月 4 分間ダウンしても、世界の終わりというわけではありません。 つまり、あなたはおそらく気づきもしないでしょう。 自分だけかどうかを確認するために Twitter をチェックしに行く頃には、また復旧しているでしょう。

一般的に、優れた稼働率を得るためには、冗長性とレプリケーションを追加して、サーバーに障害が発生しても、他のサーバーがすでに稼働していてすぐにそれを引き継ぐことができるようにしようと考えます。 このアプローチの問題は、複雑で高価であるということです。 アプリとデータベースの両方に複数のサーバーが必要で、通常は3台以上、さらにその前にロードバランサーも必要です。 そして、これらすべてのマシンを管理/監視する必要があります。

さらに、アプリをより小さなサービスに分割する新しいマイクロサービスのトレンドでは、各サービスに対してこれらの複雑なセットアップを繰り返さなければなりません。 小さな API を作成するたびに、新しい複製されたデータベースをセットアップする必要はないでしょう。 私は非常に生産的でありたいし、複雑で時間を浪費するような運用に煩わされることなく、素早くサービスを作り上げたいのです。 つまり、あなたが構築するもののうち、実際に高可用性が必要なものはどれくらいあるのでしょうか。 ごくわずかなデータの損失や、年に数分のダウンタイムを許容できないようなサービスは、それほど多くはないでしょう。 サービスの地獄をアーキテクトしても、何らかの理由でどのみちダウンタイムは発生するのでしょう。 1164>

まず、いくつかの数字についてですが、平均して、AWS EC2 インスタンスは 6 か月ごとに故障するとします。 最近はもっと少ないと思いますが、誰も本当のことは知らないので、控えめにします。 1164>

1 台のマシンで 4 つの 9 を得る方法を説明します。

Step 1) サーバーの起動、アプリのデプロイ、DNS スクリプトの変更

最初に必要なものは、新しいインスタンスを起動し、アプリを起動し (Docker はこれを簡単にします)、新しいインスタンスを指すように DNS を変更できるシンプルなスクリプトです。 この記事ではこのステップについて詳しく説明するつもりはありませんが、これらのステップを実行できるワンライナー スクリプトを作成できれば、それは良いことです。 Service fails: run script.

Step 2) 自動バックアップと自動回復を備えたデータベース

Database の非常に最近のバックアップを確保し、それらを S3 などの簡単にアクセスできる場所に保存できれば、起動時に自動回復するアプリを作成できます。 組み込みデータベースを使用すると、アプリという 1 つのものをデプロイするだけでよいので、すべてがシンプルになります。

私は最近 BoltDB をよく使用しています。 だから、接続する別のデータベースを実行する必要はなく、それを実行し続けることに対処する必要があります。 ライブラリを使用するだけで、データはローカル ディスクに書き込まれます。

さて、これは Bolt の問題でもありますが、データはアプリと一緒にローカル マシンにのみ存在します。 マシンが故障すると、すべてのデータを失います。

では、1～2 分ごとにバックアップするのはどうでしょうか。 BoltDb の初期化行を変更するだけで、データベースを S3 に自動的にバックアップし、さらに、アプリを起動すると、最新のバックアップからリカバリします。 どこでアプリを再起動しても、中断したところから継続します。

これを使用したサンプル アプリがありますので、試してみてください。 https://github.com/treeder/bolt-backup/tree/master/example

結論

上記の簡単なコンセプトにより、アプリを 26 分未満で回復し、4 9 以上の稼働時間を達成することが可能です。 ただ、前述の Bolt Backup ライブラリのような起動スクリプトと自動データベース リカバリにより、すべてが自動化されていることを確認してください。

Web スケールに熱中すると、シンプルさの価値が失われることがありますが、多くの場合、シンプルにしておくと、多くの時間と悲しみを節約することが可能です。 そして、多くのお金も。