ウェブサーバーにAWSを使う案件には、障害に備えてこんな感じで提案してます
本日AWSの障害があった。Yahooのトップニュースにのるほどの扱い。
Yahooトップに #AWS障害 の件が掲載されているが、そもそもIT業界の人やエンジニアでないとAWSなんて知らないよね。そしてAWSを知らない人が、インフラの障害とそこのったサービスの違いの区別できず「はやくしてくれ」と主張してくる。この溝は大きいが、エンジニアは地道に説明していくしかない。
— 早川朋孝 | 文学部卒のWebエンジニア (@ShiroTruffe) October 22, 2020
去年もAWSの大きな障害があり、メルカリが使えないなどで騒ぎになった記憶がある。いつも当然のように使っているサービスが突然使えなくなり、困っている人は多いだろう。特にAWSを利用しているITシステムの現場では、たくさんのエンジニアが苦労しているに違いない。
「これはAWSの障害で、弊社のサービスの障害ではないのです。AWSが復旧しない限り弊社ではどうしようもありません」と、こんな会話がたくさんされているだろう。全国のエンジニアの皆さま、お疲れさまです。
今回は、ウェブサーバーの冗長化をちゃんと提案しておきましょうという、いたってシンプルな話。「そんなのとっくに知っているし、やっているよ」という人もたくさんいるだろうけど、その一方で非常に備えてのウェブサーバーの冗長化というシンプルな提案や運用体制ができていない事例をたくさん見てきたので、経験の浅いエンジニアや営業の方などの参考になればと思い書いておきます。
先ずは冗長化は本当に必要か？という問いから始まる
本番環境がどの程度クリティカルな役割を与えられたウェブサーバーであるかによるが、大抵のコーポレートサイトやブログなどを前提とした場合、つまりECサイトやテレビの大規模CMの着地となるようなLPでないとした場合、「本当に費用や手間をかけてまで冗長化する必要ありますか？」という問いが、まず必要となる。
私の経験上書くが、東証一部上場企業のコーポレートサイトであっても、たまに障害が発生してウェブサイトが表示されないくらいのことはしょうがない、とけっこう淡々と考えている企業もある。逆にそんなに大企業でないのに、ウェブサーバーの冗長化をしっかり設定し、年間のサービスレベルを99.9%も求める企業もある。要はその企業の経営におけるウェブサイトの役割がどういう位置づけなのか、を理解するところから冗長化の提案は始まるのだ。
取引先の担当者がたまたま自社のウェブの位置づけに対する理解が浅い人である可能性もある。提案側が気軽に望んでいたら実はちがった、みたいなケースもある。繰り返すが、その企業の経営におけるウェブサイトの役割がどういう位置づけなのか、を提案側は完璧に理解する必要がある。
通りやすいウェブサーバーの提案例
さて、提案側が相手のウェブの運用の重要度を理解したうえで、相手がウェブサーバーの冗長が必要だから冗長化の提案が必要となった場合に、私がよく利用する提案は以下のパターンだ。具体的な要件としては「冗長化までは不要だが、それなりの備えをしていざという時に簡単に対策できるようにしたい」というケースだ。
- 本番環境：AWSなどなんらかのクラウドサービス
- STG環境：さくらVPSなどの定額サービス
本番環境が必ずしもクラウドである必要はないのだが、すでに運用中であるなどの事情によりサービスを変更できない場合がある。そのため本番はクラウドを提案するとして、STGもそれに合わせてクラウドにする必要はまったくない。さくらインターネットやカゴヤなど、安価なわりにサービスレベルの高いVPSを提供している事業者はいるので、そういうサービスを利用する。
これであれば以下のようなメリットを享受できる。
- 本番のAWSで障害があった場合でも、一時的にSTG環境に切り替えるなどの措置がとれる
- STG環境にコストかけたくない場合、定額の安価なサービスで運用できる
こういったメリットと一緒に複数のサービスの費用を比較した表などを用意し、VPSは共有サーバーであることのデメリットもお客さんに伝える。そうすれっば相手はじっくりメリットとデメリットを検討することができ、社内での稟議も通りやすい。
このように丁寧に説明すれば、大抵のまともな取引先であれば提案を受け入れてくれる。突然の障害で苦労しているエンジニアも多いと思うけど、事前の提案でいざという時のショックを多少なり緩和できる。
