高負荷との戦い
インフラエンジニアをやっているとどこかで遭遇する、高負荷との戦い。先日はシャープのECサイトが高負荷と戦っていると聞きました。
シャープは、4月21日午前10時から開始した、自社生産の不織布マスク「MA-1050」の個人ユーザー向け販売において、販売開始直後から販売サイトにつながらない問題が発生したが、シャープでは、同社データセンターにおけるファイヤーウォール機能が原因の1つであるとの見方を明らかにした。
詳細については明らかにしていないが、予想を上回るアクセス数があったことで、不正アクセスによる攻撃と判断した可能性が高く、それにより、強制的にアクセスを遮断した結果、サイトにつながらないという状況に陥ったとみられる。
大昔、それこそ10年くらい前は、高負荷でサイトダウンしたときに、「おお、うちのサイトにそんなにアクセスが来てくれるのは景気がいいねえ」なんて牧歌的な対応でした。まだガラケーが半分ぐらいのアクセスもあったし、インターネットでものを買うことにまだ世間が慣れ始めたころでした。
しかし時は流れ、ちょっとでもアクセスできなかったり、スローダウンしようものなら、このサイトは使えない。というので機会損失につながる。そんな扱いを受けるようになりました。SNSには何で負荷対策しないのとか、毎回イベントのたびに落ちる貧弱なインフラとか、もう買うの止めるだの、いろいろ書かれてしまいます。
高負荷になったときに、ちゃんと対応できるのがインフラエンジニアの重要な仕事の一つになったわけですが、これが、簡単ではないのです。
高負荷との付き合い方
一言で高負荷と言ったっていろんな考慮点があります。巷で高負荷によるサイトダウンを聴いたときに、どのポイントで発生しているのかを考えるようにすれば、少し深く現象を理解できるかもしれません。
いくつか、私の考えるポイントを記載していきます。
ファイアウォール
上記のシャープの例はまさにこれですが、通常時の通信とは全く違う量、そして質でネットワーク要求がデータセンターに飛び込んできます。この普段と違う、という状態をファイアウォールが攻撃と判断すると、もうつながなくなります。
しかも、つながりにくいときって、ユーザーはリロードしますよね。リロードするたびにネットワーク要求が来るので、悪い循環が発生しトラフィックはさらに増えます。また、もともと通信プロトコル（TCP）は相手から応答がないと再送する機能がありますから、リロードせずとも似たようなことが発生します。
この普段と違う高負荷の様子を事前に確認することを負荷テストと呼びますが、机上で負荷テストするのと、実際のユーザーが高負荷をかけてくるのは意味が違います。そこまで考えてファイアウォールの限界性能や設定を行う必要があるので注意が必要です。
ロードバランサー
高負荷が来るからということでたくさんのWEBサーバーを並べたところで、ユーザーから届く要求を適切に振り分ける仕組みが必要です。それがロードバランサーで、高負荷対応に切り離されない機械です。この振り分けを行うロードバランサーも高度なことをやらせようとすると設定が難しい箇所です。WEBサーバーの台数が限られていたりシステム性能がある程度までしか上げられないときに、ロードバランサーで接続をせき止めてやり、あふれたものはソーリーサーバーという「Sorry...ただいまアクセスできません」みたいなページに振り分ける動作を仕込みます。
ただ、アクセスできる人とアクセスできない人を見分ける機構が必要となり、そのあたりをIPアドレスで確認したりクッキーで確認したりといろいろな方法があります。
いくらアプリケーション開発者がサイトを作っても、この辺りの実装で足を引っ張られ正常にアクセス負荷をさばけないというのは良くある風景です。
WEBサーバーやDBサーバーを極限まで増やして、ロードバランサーは無尽蔵に振り続けるというやり方も、最近はパブリッククラウドの隆盛で「アリ」となりました。昔はサーバーを増やすと簡単に減らせなかったので、高負荷の悩みでした。今はクラウドでは、サーバーを減らしたい場合は解約すればいいので、楽な時代となりました。
WEBサーバー
10年くらい前のサーバーの性能は本当に低くて、1コア2コアなんて言う低スペックのWEBサーバーもザラでした。また、ハードディスク全盛なので入出力が本当に遅かった。ただ、平常時はそれでも動くんですね。しかし高負荷時は、まず入出力がやられます。そして入出力待ちのためにCPUがスローダウン。WEBサーバーを起動するとロードアベレージという負荷を測るための数字が300とか500とか訳の分からない数字になって、終いにはOSがハングアップしてました。
最近はSSDを使いつつストライピングした高性能なストレージを使うことで、入出力がボトルネックになることは減りました。ただ値段も高いので、使いどころがポイントとなっています。
また、入出力を強化しても、結局はアプリケーションの「軽さ」も必要となりますのでこの辺りは開発者がメモリキャッシュを使ったり、ロジックの工夫をしたりといろいろ努力をされています。
あと、「画像」の取り扱いも結構大事で、WEBサーバーは画像をユーザーに送り終えるところまで責任を持っていますので、できるだけ画像の取り扱いを減らすと、負荷が軽くなります。具体的には、CDNを使うことで、画像についてはWEBサーバーにあまり要求を来ないようにすることが可能になっています。
DBサーバー
超大変。
いくらWEBサーバーを無限大に並べても、データベースは一つです。複数にする技術はあるのですがかなり高度であり、しかもトラブルも多いです。
冗長化すること自体が一つの技術となっていて、これにまつわるトラブルが相当多いです。
そう考えると、シングルデータベースでも滅茶苦茶性能を上げてバックアップはきちんと取る、という方がコストパフォーマンスに優れる場合が多いと判断しています。
クラウドで冗長化サポートをしているデータベースサービスもありますから、最近は選択肢は増えたと思いますが、結局お金をかけた分だけ恩恵を受ける場所です。
インターネット回線
最近は高負荷時に来るトラフィックの量もうなぎのぼりです。
インターネット回線の太さもどんどん増強されているので、例えば今回のような、みんなインターネットを使ってテレワークでしのいだり、ネットフリックスやアマゾンプライム、YouTubeの利用が増えたりして通信量が増えても、大きな問題は起きていません。
ただそれは、クラウドの中ではまだ対応できていますが、オンプレミスで専用のインターネット回線を引っ張っているケースでは限界があります。昔は100Mbpsベストエフォートなんて回線がメジャーだったのですが、今では1Gbpsあっても高負荷対応は無理でしょう。本当に高負荷対応したいなら10Gbps対応は必須と言えます。
そもそも、自宅の回線が1Gbpsとか10Gbpsとかっていうケタになっているので、普通に対応しようとしたら専用のインターネット回線では対応は無理でしょう。
もし工夫するとすれば、前述しましたがCDNをうまく使って、大容量のもととなる画像ファイルなどを外に逃がすしかないのかなと思います。
ちなみに、インターネット回線がいっぱいになったらどうなるか。通信回線をコントロールしているルーターがパンクします。こうなったら、もうどうしようもないです。回線を交換することは急にはできませんから。
そういう意味では、高負荷のサービスを企画する時点でCDNの利用は必ず検討しなければいけないですし、もしくはクラウドの利用をはじめから考える必要があるのでは、と思います。
DDoS攻撃
私はクラウドを使っていることもあり、DDoS攻撃で困ることは減りました。
というのは、クラウドはたいてい、DDoSを検知する機器を入れていることが多いからです。あるサイトだけDDoSを受けたとしても、クラウド全体がダウンするリスクがあるので、全体として大きな設備を入れているという状態です。
オンプレミスのときは、それこそ小さな攻撃であっても致命的なダウンにつながることも多く、しばらくはDDoSとの戦いという時期もありました。
高負荷？、なぜ？、何もイベントやってないのに。よくよく通信傾向をみたら攻撃で、そこから対策して。収まったと思ったら別の経路から攻撃してきて・・。みたいなことを過去経験しました。
所感
こんな話題を書いていると、これまでの自分の仕事をいろいろ思い出します。いろんな場所にボトルネックはあるのですが、インフラのことを知らない人に取っては、何のことやらわからない話題だと思います。
そもそも「サーバー」って何か、ちゃんと、非ITの人に説明するのって意外と難しいんです。
ある有名なブランドのサイトを預かっていた時に、非ITの知人に、「有名なブランドのサイトのサーバー管理をしている」、って言ったら、「じゃあこのページに書いてあるこの絵とか文とか考えているの？」と返されて。
「いや・・それを動かす機械を管理していて・・」
「へえ・・」
で会話が止まってしまいました。
まあ、よくわからん商売ではありますが、それでもこうやって、WEBサイトがユーザーエクスペリエンスが満足できる状態であるのはインフラエンジニアの能力が必要になるわけで、がんばっていくしかないですね。
