• 2019年8月24日土曜日
アリスト戦記
アリスト戦記 https://blog.aristo-solutions.net/2019/08/aws.html

AWS障害に備えたローカル環境退避について検討

2019年8月23日に発生したAWSの障害は、サーバの発熱が原因だったそうだ。

AWS障害、大部分の復旧完了 原因は「サーバの過熱」8月23日午後1時ごろに発生した、米Amazon Web Servicesのクラウドサービス「AWS」の東京リージョンでの障害について、同社は午後8時18分、クラウドサーバの復旧がほぼ完了したことを明らかにした。制御システムの障害により、サーバの温度が上がりすぎたことが原因だったという。

僕の所で発生した障害は、生きているEC2インスタンスもあれば死んでいるEC2インスタンスもあるというランダム状態で、何が生死を分けているのかと不思議だったが、ようやく理解出来た。

生死の境目

普段意識するものではないけど、AWSの東京リージョンの向こうは4つのデータセンターで構成されており、その4つのデータセンターのうちの1つのエアコンがぶっ壊れて死んだ。


だから、たまたま第1~第3データセンターを掴んでいたインスタンスは生き残ったが、第4データセンターを掴んでいたインスタンスは死んだ。

そういうことだったわけか。

縮退運転するには

まあ、AWSにも障害はzふから、こういうケースが発生することは事前に想定出来ていたんだけど、特にコレと言って対策はしていなかった会社が多かったようだな。
僕のところも同じく、対策はしていなかった。

知っててやらない理由はいくつかあるんだけど、やっぱ一番はコストだな~。

AWSの障害に備えてオンプレミス環境に縮退系、つまりコールドスタンバイを用意しておく作戦はコストが発生する。
その中でも僕が気になるのはネットワーク伝送量だ。


これね~、図で見ると実にシンプルなんだけど、ネットワーク経由で実現するのは意外にハードルが高い。

まず1つとして、エクスポートするファイル(つまり、データベース)が何十GB、何百GBもあると、転送に時間が掛かるでしょ。
一晩で終わらないとか、途中でネットワークが切れるとか、そういう可能性まで考慮しなければならないという、インフラ的なハードルがある。

もう一つは、ネットワーク伝送量課金。
AWSは外部にデータを送出する時に課金が発生する。だから、毎晩日時でDBエクスポートなんてやっていると、相当大掛かりな課金が発生すると見込まれるわけよ。

コスト対効果に見合うかどうか。

この辺りの判断があって、今日ダウンした多くのサービスの場合、縮退系は欲しいけどコスト対効果に見合わないから実施しない、という判断に倒れた、ということだろう。

「コスト対効果をどう評価したか?」という高度な領域の問題だな。

差分バックアップ作戦

しかし、今回の障害を機に人々の認識が変わって「やっぱり多少コストを積んででもオンプレミス縮退系は用意しておこう」という話になるかもしれない。

そういう時、どうすれば良いか?

僕の考えでは、差分バックアップしか無いと思う。

上述のとおり、シンプルにDBをエクスポートして転送するというやり方は、安定性においても課金においても非合理的である。

大量データ短時間ネットワーク転送なんて力業に出て、いざって時にバックアップシェルが落ちてて取れてませんでした、では元も子も無い。

そこで、差分バックアップでチンタラ同期する作戦が良いと思う。

例えばMySQLだと、以下のようなやり方で差分バックアップする方法がある。
検証はしていないが、ネットワークの向こう側と同期することも出来ると思う。
データベースソフトなら大概はこの機能は備わっていると思う。




また、データベースではなく、普通のファイルであったらどうか?
Linuxであればrsyncというコマンドでネットワーク間同期を行うことが出来る。




Windowsサーバでは「xcopy」という似たようなコマンドがあるそうだ。

いずれにせよ、差分バックアップを行うことで転送量を削減するという基本方針は同じだ。
シンプルエクスポートより高度な作業で構築も面倒だが、ネットワーク経由のバックアップを安定させるにはこのやり方しか無いのではなかろうか。

それでも今まで以上にコストが発生することは変わらないから、1にも2にもまずコストの見積もりだな。

リスクに比べてコストが見合っているかどうか。
正に孫氏の兵法の話だ。


IT業界は何事も孫氏の兵法だな。(´・ω・`)

0 件のコメント:

コメントを投稿