大規模Webサービスのネットワーク移行の極意と、いまどきのDDoSを語る〜第19回さくらの夕べin大阪

2014/8/29に大阪・淀屋橋で行われた「さくらの夕べ」に参加させてもらいました。そのレポート記事です。

みなさんはじめまして、フリーランスのシステムエンジニアの上村崇と申します。今回ご縁ありましてさくらのナレッジに寄稿させていただくことになりました。

大阪でさくらの夕べが行われるのは約5ヶ月ぶりです。80名弱の参加がありました。
世にある勉強会のなかで、インフラ・サーバー関連をテーマにしたものは少ないですが、「さくらの夕べ」はそういったサーバー分野の知られざるノウハウや体験談を聞ける数少ない場です。

今回は、何十台ものサーバー群で運用しているWebサービス「AD EBiS」のネットワーク構成を冗長化した体験談・苦労話と、最近のインターネットでの攻撃として知られるDDoSのメカニズムやそれに対抗するノウハウを話していただきました。

華やかなデザインや見た目に凝るフロントエンド開発と違って、サーバーの話というのは目に見えにくいところですし、簡単に試せないこともあって情報が少なくなりがちです。そんななか、自社のインフラ話や苦労話という、とても貴重な話を聞くことができました。

ネットワーク切替の成功の鍵をにぎるのは周到な準備やリハーサル、そしてコミュニケーション!

株式会社ロックオン　アドエビス開発ユニット　上原賢也さんの
「ネットワーク冗長化プロジェクトＸ～その時、ネットワークは繋がった～」のお話です。

株式会社ロックオンといえばEC-CUBEが有名ですが、AD EBiSという広告効果測定サービスも提供しているそうです。バナーなどの広告と、バナーをクリックした先の誘導先サイトの間にAD EBiSサーバーを置くことで、広告がどれくらいクリックされたか等を計測することができます。

サービスの性質上、24時間365日遅延無く動作することが求められます。AD EBiSの顧客はGoogleやYahooなどに広告費をかけた上でこのサービスを利用していますから、AD EBiSサーバーが万が一ダウンしてしまうと、ユーザーはバナーをクリックしても誘導先サイトにはたどり着けません。その損害額ははかり知れません。

2004年にサービス開始したAD EBiSですが、システム上の一部のネットワーク経路で、「この機器が壊れると一部のサービスが利用できなくなる」という単一障害点がありました。そこでサービスの信頼性ももっと高めるためにネットワーク機器の冗長化を2010年に行いました。
その冗長化に関する体験談・苦労話を語っていただきました。

ミッションクリティカルな移行プロジェクトですので、切替時のダウンタイムは極小にしなければなりません。

上原さんがこのプロジェクトで経験した、ネットワーク切替の極意があります。
・事前準備が超大事。リハーサルを重ねることで失敗しない本番移行ノウハウが確立できる。
・切替はテクニカルな作業であるが、アナログ的なコミュニケーションはもっと大事。
・移行プロジェクトやインフラ部隊の重要性を社内に認知させるためのアピールも必要。
これらを身をもって実感したそうです。

ダンスや歌など、ステージに立ってパフォーマンスをする人は、公演日に向けて何回も練習し、リハーサルして本番に臨みます。どれだけ準備できたかが、本番成功のカギになります。
ネットワーク移行も一緒です。練習せず一発でうまくいくはずなどありません。
AD EBiSネットワーク冗長化プロジェクトでは、3ヶ月ほどの期間を準備にあてました。

株式会社ロックオン自社だけではリソースが足りず、サーバーをハウジングしているさくらインターネットと、外部の協力会社の3社が関わるプロジェクトとして発足しましたので、技術的な準備だけではなく、実際に一緒にプロジェクトを進めるパートナー探しから取り組むことになります。具体的には、
1. プロジェクトの概要と協力提案を依頼する文書(RFP)の作成
2. 協力会社の選定
3. 3社体制による準備やリハーサル
というプロセスで進行していきました。

2.の協力会社の選定では、いくつかの会社に見積りをしてもらって比較検討したそうですが、ミッション・クリティカルなプロジェクトなので、価格よりも「プロジェクトを成功させるパートナーとしてふさわしい会社かどうか？」に重点を置いて決めたそうです。
会社の知名度や規模よりも、一緒に関わる担当者が信頼がおける方かどうか、プロジェクトの特性をよく理解してくれているかどうかが決め手になったそうです。

3社の協力体制が整ったあとは、具体的に技術的な準備にとりかかります。
本番前のリハーサルは2回ほど行いました。
移行作業は全部で9つのステップがあります。コマンドで設定する手順以外にも、ネットワークの物理結線をつけかえたりなど、人手が介入するプロセスが多々あります。
移行に関する作業拠点は、株式会社ロックオン本社、機器が置かれているデータセンター、東京のさくらインターネットオフィスの3つがあり、それぞれに配置された作業者と密に連絡をとりながら進める必要がありました。

実際にリハーサルしてみるといろいろな課題が浮かび上がってきたそうです。

「エンジニア声小さい問題」

3つの作業拠点間で電話でのやりとりを行う際に、小さくて不明瞭な発音だと正確に作業内容が伝わりません。ケーブルの結線を間違えたりタイミングがずれたりすると大変なことになります。
最初のリハーサルで、エンジニアの「声が小さい問題」が発覚してからは、声出しの練習を朝一でメンバーにさせる対応を行いました。

「電話切れる問題」

サーバーがひしめきあい密閉されたデータセンター内では、外部との電話がしづらい状況にあります。サーバーのファンの音がうるさかったり、電波状況が良くないので、電話が途中で切れたり聞き間違えが起こったりして不安定な通話を余儀なくされました。
そこで、電話機を2台用意したり、ビデオチャットシステムやskypeを併用したりして、通信できる手段を複数確保しました。
また、拠点間で連絡する手順がある場合の1つ1つについて、発言するセリフをあらかじめ決めておきました。例えば、
「○○作業を実施してください」
「はい、分かりました。○○作業を実施します」
といった決まった応答をするように台本を作って、聞き間違いが起こらないようにしました。

そういった準備の甲斐あって、リハーサルの時点では1分の停止時間が必要だったネットワーク切替作業が、本番では十数秒にまで短縮されたそうです。

最近よく聞く「DDoS」とはどういう攻撃か？加害者にも被害者にもならないためにどうするべきか？

次に、さくらインターネットの中で働いておられる基盤戦略部の吉岡渉さんが
「さくらのネットワーク担当が【DDoS】語ってみた。」
というタイトルで話してくださいました。
最近インターネット上の攻撃としてよく聞くようになったDDoSとはなにか？そしてそれに関連してDNS Amp攻撃も解説していただきました。

DDoSとは？

Distributed Denial of Service attackの略で、攻撃対象の1つのサーバーに対して、多数のコンピュータが同時にいっせいに攻撃をしかける方法です。
1つのコンピュータから標的を攻撃し、ダメージを与えるDoSの発展形の攻撃です。
DDoSは複数のコンピュータを使って攻撃をしかけるところが特徴であり、攻撃者にとってみれば、DoSよりも大きなダメージを標的に与えることができます。

最近では2014/5月〜6月にかけて、プロバイダなどが所有するDNSの障害や不調が多発し、インターネット利用ユーザがWebサイト閲覧をするのに時間がかかったり、まったく見られないという現象が発生していました。
これはDNS Amp攻撃というDDoS攻撃の一種により被害を受けていたことが原因です。

世に多く存在するオープンリゾルバと呼ばれるDNSキャッシュサーバーが踏み台にされて、標的サーバーにいっせいに大量のパケットを送りつけたため、標的にされたDNSサーバーが処理不能に陥りました。

DNS Amp攻撃とは？

DNS Amp攻撃とは、DNSへの名前解決で発生する通信パケットを攻撃対象に送りつける攻撃手法です。DDoSの仕組みと組み合わせることで、より大きな破壊力を持ちます。

本来のDNS問い合わせというのは「問い合わせ元」と「DNSキャッシュサーバー」間の二者のやりとりで終わるものなのですが、攻撃に使われる手法は、問い合わせ元がIPアドレスを詐称することにより、別の攻撃先サーバーに応答パケットを送りつけるメカニズムを利用しています。

この詐称問い合わせをウイルスに感染したゾンビサーバーから一斉に行うDDoS攻撃によって、標的のトラフィックをオーバーフローさせます。

ここで、DDoSの踏み台としてDNSが狙われる理由というのは以下の通りです。

- DNS応答はUDPプロトコルであるため、通信元IPアドレスの詐称が容易にできる。

TCPは通信セッション開始時に、発信側と受信側の両端の間で必ずハンドシェイクという通信開始-応答の往復があります。そのセッションが確立されてから通信を開始するので、送信元がはっきりしていないと通信を行うことができません。一方、UDPプロトコルはその手順が無く、送信側から受信側へ一方的にパケットを送りつける一方通行プロトコルなので、送信元詐称が容易にできます。
その特性が悪用されています。

- DNSの問い合わせは増幅する

DNSサーバーへの問い合わせは、リクエスト送信パケット量に対して、返ってくる受信パケット量の方が大きくなります。踏み台になるDNSキャッシュサーバーには、TXTレコードなど応答データ量が大きくなるようなDNSレコードをわざと設定しておくことで、攻撃時により大きなダメージを標的に与えられるようにしておきます。
その上で、DDoSによる一斉DNS問い合わせを行い、攻撃相手先サーバーめがけて応答が届くようにしておけば、攻撃されたサーバーは一気に大量のトラフィックを浴びるようになります。

- インターネット上にオープンリゾルバが多数存在する

誰でも利用できるようにするため、送信元IPアドレスを制限しないで一般に公開しているDNSサーバーが多くあります。
そのようなオープンリゾルバと呼ばれるDNSキャッシュサーバーが、格好の踏み台にされてしまっているようです。
現在ではそれを防ぐため、プロバイダは自サービスのネットワーク空間からのリクエストにしか応答しないように設定変更することが多くなっています。

以上がDNS Amp攻撃の概要ですが、同様の攻撃手法としてNTP Ampがあります。
攻撃手法はDNS Amp攻撃のパターンとほぼ同じで、踏み台のDNSサーバーがNTPサーバーに置き換わった形になります。
このNTPを利用した応答の増幅を利用した攻撃は、増幅率が 200倍になるとのことで、攻撃側の都合としてはDNS Ampよりも攻撃効率の高い攻撃です。

さくらインターネットでは、DoS被害にあったサーバーのうち1/4がDNS AmpまたはNTP Ampによる攻撃だそうです。

こういった被害を受けたり、また自分自身がDDoS攻撃に加担しないためには以下のような心得が必要です。

自分が加害者にならないために

・自分が管理しているサーバーが攻撃に加担しないように、必要なければDNSサービスやNTPサーバーといったサービスを止める。
・DNSやNTPサーバーを稼働する必要がある場合は、不特定多数のユーザーにサービスを利用させないために、IPによるアクセス制限を実施する。
一般家庭のブロードバンドルータにもDNS機能を持つものが存在するので、そういったルータであればDNSサービスを提供しないよう設定変更するなどの処置が必要になります。

自分が被害者にならないために

これはいちど自分のサーバーが攻撃ターゲットにされてしまうと大量パケットがやってくるのはどうしようもありませんが、さくらインターネットではユーザーのサーバーを収容するルータのIPアドレスを公開しないことで、ルータに対してDoS攻撃を受けないようにしているそうです。
また、いったんサーバーがDoS攻撃を受けてしまったら、それらを検知してトラフィックを手前でブロックするシステムを運用しています。さらに、2014年4月より、DoSの攻撃トラフィックのみをブロックし、正常な通信はサーバーに到達させるシステムを併用しています。

VPSやクラウドなど、サーバー利用の選択肢が広がってきていますが、こういったユーザー自身で構築やメンテナンスが必要になるサーバーは、より安全にサービスを運用するためのノウハウがよりいっそう必要になりますね。サーバー運用はいろいろやることがあってたいへんだなーと思いつつも、よい勉強になりました。

セミナーのあとの懇親会

セミナーのあとの懇親会にも参加させてもらいました。

多くの方と話をすることはできなかったのですが、お会いした方からは、セミナーの感想として
「コミュニケーションが大事なことがよくわかった」
「普段聞けない話が聞けてよかった」
「内容は難しかったけど、知らない世界に足を踏み入れるきっかけになりました」
などのコメントを聞けました。

セミナー１時間、懇親会１時間という短い時間でしたが、とても楽しい時間を過ごせました。
どうもありがとうございました。

次回はもっと短い頻度で「さくらの夕べ」を大阪でも行いたいとのことでしたので、興味がある方はさくらインターネット広報のTwitterアカウントをフォローして今後の情報をGETしましょう。